1 / 27

Database Management System

Database Management System. Lecture - 11. Normalization Summary. A step by step process to make DB design more efficient and accurate A strongly recommended activity performed after the logical DB design phase. Normalization Summary.

jacksonmark
Download Presentation

Database Management System

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. DatabaseManagement System Lecture - 11

  2. Normalization Summary • A step by step process to make DB design more efficient and accurate • A strongly recommended activity performed after the logical DB design phase

  3. Normalization Summary • Un-normalized relations are more prone to errors or inconsistencies • Normalization is based on the FDs • FDs are not created rather identified by the designer/analyst

  4. Normalization Summary • Normalization forms exist up to 6NF, however, for most of the situations 3NF is sufficient • Performed through Analysis or Synthesis process

  5. Normalization Example • Identify FDs • Apply on the relevant tables; see if any normalization requirement is being violated, that is, causing some anomaly

  6. Normalization Example Different Data as mentioned in the book…

  7. PROJNAME PROJMGR Some Facts 1.Each project has a unique name, but names of employees andmanagers are not unique 2.Each project has one manager, whose name is stored in PROJMGR

  8. PROJNAME, EMPID HOURS 3. Many employees may be assigned to work on each project, and an employee may be assigned to more than one project. HOURS tells the number of hours per week that a particular employee is assigned to work on a particular project

  9. PROJNAME PROJMGR, BUDGET, STARTDATE 4. Budget stores the amount budgeted for a project, and STARTDATE gives the starting date for a project

  10. EMPID SALARY 5. Salary gives the annual salary of an employee

  11. EMPID EMPMGR 6. EMPMGR gives the name of the employee’s manager, who is not the same as the project manager

  12. EMPDEPT EMPMGR 7. EMPDEPT gives the employee’s department. Department names are unique. The employee’s manager is the manager of the employee’s department

  13. PROJNAME, EMPID RATING 8. RATING gives the employee’s rating for a particular project. The project manager assigns the rating at the end of the employee’s work on that project

  14. 2 4 4 5 6 6,7 3 8 7 PROJNAME PROJMGR, BUDGET, STARTDATE EMPID EMPNAME, SALARY, EMPMGR, EMPDEPT PROJNAME, EMPID HOURS, RATING EMPDEPT EMPMGR

  15. WORK (PROJNAME, PROJMGR, EMPID, HOURS, EMPNAME, BUDGET, STARTDATE, SALARY, EMPMGR, EMPDEPT, RATING) Original relation: New relations: PROJ ( PROJNAME, PROJMGR, BUDGET, STARTDATE) EMP ( EMPID, EMPNAME, SALARY, EMPMGR, EMPDEPT) WORK ( PROJNAME, EMPID, HOURS, RATING)

  16. PROJ ( PROJNAME, PROJMGR, BUDGET, STARTDATE) EMP ( EMPID, EMPNAME, SALARY, EMPMGR, EMPDEPT) WORK ( PROJNAME, EMPID, HOURS, RATING)

  17. PROJ ( PROJNAME, PROJMGR, BUDGET, STARTDATE) EMP ( EMPID, EMPNAME, SALARY, EMPDEPT) DEPT ( EMPDEPT, EMPMGR) WORK ( PROJNAME, EMPID, HOURS, RATING)

  18. Checking for BCNF

  19. PROJNAME PROJMGR, BUDGET, STARTDATE PROJ ( PROJNAME, PROJMGR, BUDGET, STARTDATE)

  20. EMPID EMPNAME, SALARY, EMPMGR, EMPDEPT EMP ( EMPID, EMPNAME, SALARY, EMPDEPT)

  21. PROJNAME, EMPID HOURS, RATING WORK ( PROJNAME, EMPID, HOURS, RATING)

  22. EMPDEPT EMPMGR DEPT ( EMPDEPT, EMPMGR)

  23. Physical Database Design

  24. Objective • Basic goal is data processing efficiency • Transforms logical DB design into technical specifications for storing and retrieving data • Does not include practically implementing the design however tool specific decisions are involved

  25. Inputs Required • Normalized relations • Definitions of each attribute • Descriptions of data usage • Requirements for response time, data security, backup etc. • Tool to be used

  26. Decisions Involved • Choosing data types • Grouping attributes (although normalized) • Deciding file organizations • Selecting structures • Preparing strategies for efficient access

  27. DatabaseManagement System Lecture - 21

More Related