140 likes | 339 Views
Chapter 5. Normalization of Database Tables Example Database Systems: Design, Implementation, and Management, Rob and Coronel Special adaptation for INFS-3200. Database Tables and Normalization. Original Data. Data in 1NF. Dependency Diagram (1NF).
E N D
Chapter 5 Normalization of Database Tables Example Database Systems: Design, Implementation, and Management, Rob and Coronel Special adaptation for INFS-3200
Database Tables and Normalization Original Data Database Systems: Design, Implementation, & Management, Rob & Coronel
Data in 1NF Database Systems: Design, Implementation, & Management, Rob & Coronel
Dependency Diagram (1NF) 1NF (PROJ_NUM, EMP_NUM, PROJ_NUM,EMP_NAME, JOB_CLASS, CHG_HOUR, HOURS) Partial Dependencies: (PROJ_NUM -> PROJ_NAME) (EMP_NUM -> EMP_NAME, JOB_CLASS, CHG_HOUR) Transitive Dependencies: (JOB_CLASS -> CHG_HOUR) Database Systems: Design, Implementation, & Management, Rob & Coronel
2NF Conversion 1NF 2NF Table name: PROJECT PROJ_NUM PROJ_NAME EMP_NUM EMP_NAME JOB_CLASS CHG_HOUR Table name: EMPLOYEE Transitive dependency PROJ_NUM EMP_NUM ASSIGN_HOURS PROJECT (PROJ_NUM, PROJ_NAME) EMPLOYEE (EMP_NUM, EMP_NAME, JOB_CLASS, CHG_HOUR) ASSIGN (PROJ_NUM, EMP_NUM, ASSIGN_HOURS) Transitive Dependencies: (JOB_CLASS -> CHG_HOUR) Table name: ASSIGN Database Systems: Design, Implementation, & Management, Rob & Coronel
3NF Conversion Table name: PROJECT JOB_CLASS EMP_NUM EMP_NAME JOB_CLASS JOB_CLASS CHG_HOUR CHG_HOUR Table name: EMPLOYEE Table name: JOB PROJ_NUM PROJ_NAME Transitive dependency Table name: ASSIGN PROJ_NUM EMP_NUM ASSIGN_HOURS PROJECT (PROJ_NUM, PROJ_NAME) EMPLOYEE (EMP_NUM, EMP_NAME, JOB_CLASS) JOB (JOB_CLASS, CHG_HOUR) ASSIGN (PROJ_NUM, EMP_NUM, ASSIGN_HOURS) Database Systems: Design, Implementation, & Management, Rob & Coronel
Improving the Design • Evaluate PK Assignment (meet PK guidelines) • Evaluate Naming Conventions • Refine Attribute Atomicity (simple, single-valued) • Identify New Attributes • Identify New Relationships (decompose M:M) • Refine Primary Keys (as required for data granularity) • Maintain Historical Transactional Accuracy • Identify Use of Derived Attributes Database Systems: Design, Implementation, & Management, Rob & Coronel
Evaluate PK Assignment Introduce a better suited PK free of semantic content (non-intelligent PK) Add JOB_CODE as surrogate PK. To reduce data entry errors Repeat for other tables (see # 6 – Assign)* Evaluate Naming Conventions JOB_CLASS is actually a description of the job, change to JOB_DESCRIPTION. CHG_HOURS should be JOB_CHG_HOUR Improving the Design(Job Table) Database Systems: Design, Implementation, & Management, Rob & Coronel
Refine Attribute Atomicity Decompose composite attributes into simple attributes EMP_NAME should be EMP_LNAME EMP_FNAME EMP_INITIAL Identify New Attributes Add new attributes that describe real world entity characteristics EMP_HIREDATE Improving the Design(Employee Table) Database Systems: Design, Implementation, & Management, Rob & Coronel
Improving the Design(Project Table) • Identify New Relationships • Add new relationships as required by business rules. • A project is managed by an employee, an employee can be the manager of only one project. • Add EMP_NUM as FK in PROJECT Database Systems: Design, Implementation, & Management, Rob & Coronel
Improving the Design(Assign Table) • Identify new attributes • Add ASSIGN_DATE • Refine Primary Keys • Consider the “granulity” of the data being represented in order to determine the PK. • Can an employee have multiple hours worked entries for a given day in a given project? • If yes, add ASSIGN_NUM as surrogate PK. • Maintain Historical Transaction Accuracy • Add ASSIGN_CHG_HOUR • Identify Use of Derived Attributes • Add ASSIGN_CHARGE Database Systems: Design, Implementation, & Management, Rob & Coronel
Final Normalized Design Database Systems: Design, Implementation, & Management, Rob & Coronel
Limitations of System Assigned PK • Surrogate PK ensures that each row has an unique ID, not that the row’s dependent values are unique. • JOB_CODE system assigned PK • We still could have duplicate values: • 511 Programmer 35.75 • 512 Programmer 35.75 • Clearly, entries are duplicated! • To ensure unique values we must have create an unique index on all candidate keys. • Unique index on JOB_DESCRIPTION • This still will still not avoid data entry errors! • 513 Progranmer 35.75 Database Systems: Design, Implementation, & Management, Rob & Coronel