relational database appendix
DESCRIPTION
Relational Database Appendix. Entity /relation. Entity Subtype. Relationship. Composite Entity. ER Diagram. Shorthand Description. State ( StateAbbrev , StateName, EnteredUnionOrder, StateBird, StatePopulation) - PowerPoint PPT PresentationTRANSCRIPT
Relational Database Appendix
Bus 311: Fall 2003 2
ER Diagram
Entity/relation
Relationship
Composite Entity
Entity Subtype
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 functionally determines StatePopulation•StatePopulation is functionally determined by StateAbbrev
•StateAbbrev is a determinant
Bus 311: Fall 2003 6
Determinants
• 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
Partial Dependencies
Transitive Dependency
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
• Process1. Identify functional depencies for each attribute
2. 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