1 / 17

Relational Database Appendix

Relational Database Appendix. Entity /relation. Entity Subtype. Relationship. Composite Entity. ER Diagram. Shorthand Description. State ( StateAbbrev , StateName, EnteredUnionOrder, StateBird, StatePopulation)

mandel
Download Presentation

Relational Database Appendix

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Relational Database Appendix

  2. Entity/relation Entity Subtype Relationship Composite Entity ER Diagram Bus 311: Fall 2003

  3. Shorthand Description • State (StateAbbrev, StateName, EnteredUnionOrder, StateBird, StatePopulation) • Capital (CapitalName, StateAbbrev, YearDesignated, PhoneAreaCode, CapitalPopulation) • Foreign Key: StateAbbrev to State relation • City (StateAbbrev, CityName, CityPopulation) • Foreign Key: StateAbbrev to State relation • Crop (CropName, Exports, Imports) • Production (StateAbbrev, CropName, Quantity) • Foreign Key: StateAbbrev to State relation • Foreign Key: CropName to Crop relation • Shipping (StateAbbrev, OceanShoreline, ExportTonnage, ImportTonnage) • Foreign Key: StateAbbrev to State relation Bus 311: Fall 2003

  4. Integrity Constraints • Ideally DBMS enforces integrity • MS Access does a pretty good job • Primary key constraints • Must be unique and non-null • Referential integrity • Each no-null foreign key must match a primary key • No ‘orphaned’ foreign keys • Domain integrity constraint • Rules specified for individual attributes • Data type, number of characters etc. • Validation rules Bus 311: Fall 2003

  5. Dependencies and Determinants • StateAbbrev is a determinant • StateAbbrev functionally determines StatePopulation • StatePopulation is functionally determined by StateAbbrev Bus 311: Fall 2003

  6. Determinants Transitive Dependency Partial Dependencies • StateAbbrev is a determinant for StatePopulation, StateBird, and BirdScientificName • CropName is a determinant for Exports • Quantity is functionally dependent on both StateAbbrev and CropName • StateBird is a determinant for BirdScientificName Bus 311: Fall 2003

  7. Problematic Dependencies • Partial Dependency • Funtional dependency on part of the primary key • Transitive Dependency • Functional dependency between two nonkey attributes Bus 311: Fall 2003

  8. Anomalies • Insertion Anomaly • Can’t add row if don’t know part of primary key • Can’t add new client without knowing a ChildName • Deletion Anomaly • Delete data and unintentionally lose other critical data • Delete Client 8112, and lose all info on VetID 24 • Update Anomaly • Change one attribute and changes must be made other places • Change ClientName for ClientID 4519, must change other record too Bus 311: Fall 2003

  9. Normalization • Process of bringing a relational database to an orderly form • Eliminate problems • Major process in database design • Many normal forms – we consider three • First Normal Form (1NF) • Second Normal Form (2NF) • Third Normal Form (3NF) – aka Boyce-Codd Normal Form (BCNF Bus 311: Fall 2003

  10. First Normal Form (1NF) • A relation is 1NF if it does not contain repeating groups • Process • Expand primary key to include primary key of repeating group – Independently for each repeating group • Create new relation (table) for each repeating group Bus 311: Fall 2003

  11. 1NF result • Still problems • Insertion, deletion, and update anomalies in both relations • Caused by partial dependencies (next slide) Bus 311: Fall 2003

  12. Bus 311: Fall 2003

  13. Second Normal Form (2NF) • A relation in 1NF is in 2NF if it does not contain any partial dependencies • Process • Identify functional depencies for each attribute • If necessary, create new relations to make each attribute functionally dependent on the entire primary key. • New relations should have primary keys that are subsets of the original composite key • A relation in 1NF with a single-attribute primary key is automatically in 2NF Bus 311: Fall 2003

  14. Result of converting to 2NF • Still problems? • Transitive dependency between VetID and VetName • All 3 anomalies exist in Client relation • 3NF removes transitive dependencies Bus 311: Fall 2003

  15. Third Normal Form (3NF) • Boyce-Codd Normal Form (BCNF) is an improvement over original 3NF • A 2NF relation is in 3NF when there are no transitive dependencies • Process • Remove attributes that depend on the non-candidate-key (non-primary key) • Place in new relation with determinant as primary key Bus 311: Fall 2003

  16. Result of converting to 3NF • No data redundancy • No anomalies Bus 311: Fall 2003

  17. Exercises • Gain a better understanding • Do Review Questions at end of RD appendix • RQ 1-6 will be on the exam! • RQ 7 will help you get a better understanding of how to apply to real-world situations • Some of RQ 8-14 are likely to be on the exam • If you do RQ 15-18, I will be happy to discuss your solution with you Bus 311: Fall 2003

More Related