INMT 342 Exam Set
physical database design purpose - Answer- translate the logical description into technical specifications for storing & retrieving data
physical database design goal - Answer- create a design for storing data that will provide:
- performance
- data integrity
- data secur...
INMT 342 Exam Set
physical database design purpose - Answer- translate the logical description into
technical specifications for storing & retrieving data
physical database design goal - Answer- create a design for storing data that will
provide:
- performance
- data integrity
- data security
- data recoverability
- simplify application development
physical design process inputs - Answer- - normalized relations
- volume estimates
- attribute definitions
- response time expectations
- data security needs
- backup/recovery needs
- integrity expectations
- DBMS technology used
physical design process decisions - Answer- - attribute data types
- physical record designs (doesn't always match logical design)
- file organizationsterm-5
- indexes & database architectures
- hardware configuration options
data volume & usage analysis - Answer- identify likely areas requiring attention for
performance
composite usage maps - Answer- - use of tables to capture table sizes & access
rates/expectations
- requirements may also be recorded & displayed using an annotated ERD
data volumes - Answer- - volume of data
- size estimate
- disk storage requirement
how many records in entity? - Answer- data volume
how much storage needed? - Answer- disk storage requirement
normalization - Answer- - the process of GROUPING attributes together into tables
- validates & improves logical database design to SATISFY certain constraints &
avoid duplication of data
- decomposition of tables to remove anomalies & create 2 or more well-structured
tables
creating well structured tables - Answer- - contain minimal redundancy
- allows users to insert, modify, & delete the rows in the table without errors or
inconsistencies
insertion anomaly example (from normalization problems) - Answer- - built a new
Warehouse (900)
- want to add Warehouse 900 into database
- know the Location of Warehouse 900
- doesn't have inventory yet because it's brand new
- record MUST have PartNumber and Warehouse to be - able to insert the new
Warehouse
- *restricts what can be inserted*
, update anomaly example (from normalization problems) - Answer- - need to update
Warehouse 500's Location from 123 NW ST to 100 Haslam ST
- problem because it only updates one of the Warehouse 500 records
- if there was a Warehouse table there would only be one record for Warehouse 500
and you would only have to update that one record
deletion anomaly example (from normalization problems) - Answer- - stopped
making PartNumber 02
- problem because if 02 is deleted Warehouse 700 is completely lost because it
solely makes PartNumber 02
- whereas Warehouse 500 will be deleted for making PartNumber 02, but will still
exist because it makes other parts
functional dependencies - Answer- the value of one attribute determines the other
attribute
functional dependencies example - Answer- - what can be determined from a
person's social security number
- SSN# determines name, address, birth date & phone
steps to normalization - Answer- - table with multivalued attributed
* (remove multivalued attributes)
- first normal form
* (remove partial dependencies)
- second normal form
* (remove transitive dependencies)
- third normal form
0 normal form - Answer- - multi-valued attributes
- bad identifier
1st normal form - Answer- - no multi-valued attributes
- one value per "cell"
(SS#, Fname, Lname, Bdate) - Answer- good functional dependency example
partial dependency - Answer- when the attributes in a tables are dependent on
different key fields or values
2nd normal form - Answer- - already in 1term-33NF & every non-key attribute is fully
functionally dependent on the primary key
- this means that every non-key attribute must be determined by the entire primary
key, not by only part of the primary key
- can be created by breaking the original table into two related tables on the basis of
functional dependency
3rd normal form - Answer- no transitive dependencies
The benefits of buying summaries with Stuvia:
Guaranteed quality through customer reviews
Stuvia customers have reviewed more than 700,000 summaries. This how you know that you are buying the best documents.
Quick and easy check-out
You can quickly pay through credit card or Stuvia-credit for the summaries. There is no membership needed.
Focus on what matters
Your fellow students write the study notes themselves, which is why the documents are always reliable and up-to-date. This ensures you quickly get to the core!
Frequently asked questions
What do I get when I buy this document?
You get a PDF, available immediately after your purchase. The purchased document is accessible anytime, anywhere and indefinitely through your profile.
Satisfaction guarantee: how does it work?
Our satisfaction guarantee ensures that you always find a study document that suits you well. You fill out a form, and our customer service team takes care of the rest.
Who am I buying these notes from?
Stuvia is a marketplace, so you are not buying this document from us, but from seller Gurustudy. Stuvia facilitates payment to the seller.
Will I be stuck with a subscription?
No, you only buy these notes for $9.61. You're not tied to anything after your purchase.
