Database Normalization

31
DATABASE NORMALIZATION

description

dbms material

Transcript of Database Normalization

  • DATABASE NORMALIZATION

  • Normalization - ObjectivesTable should contain subject wise data.Minimum controlled redundancy.To eliminates redundancy.To eliminates dependency.

  • Data RedundancyData redundancy is less desirable in database environment.Data redundancies yield the update, insert and delete anomalies.

  • Update AnomalyAnupdate anomaly. Employee 519 is shown as having different addresses on different records

    E_IDE_ADDRSKILL42687 Sycamore GroveTyping42687 Sycamore GroveShorthand51994 Chestnut StreetPublic Speaking51996 Walnut AvenueCarpentry

  • Insert AnomalyAninsertion anomaly. Until the new faculty member, Dr. Newsome, is assigned to teach at least one course, his details cannot be recorded.New Record ?

    Faculty_IDFaculty_NameFaculty Hire DateCourse Code389Dr. Giddens10-Feb-2013ENG-206407Dr. saperstein15-JAN-2012CMP-101407Dr. saperstein15-JAN-2012CMP-201

    424Dr. New Son29-MAR-2012

  • Delete AnomalyAdeletion anomaly. All information about Dr. Giddens is lost if he temporarily ceases to be assigned to any courses..

    Faculty_IDFaculty_NameFaculty Hire DateCourse Code389Dr. Giddens10-Feb-2013ENG-206407Dr. saperstein15-JAN-2012CMP-101407Dr. saperstein15-JAN-2012CMP-201

  • Normalization- definitionsFunctional Dependency An attribute A determines attribute B then attribute B is functionally dependant on attribute A. A B Eg. Student(sid, sname, marks) sid sname, sid ? marks sid functionally determined sname

  • Normalization- definitionsGeneralized functional dependency attribute A determines attribute B if all of the rows in the table that agree in value for attribute A also agree in value for attribute B.

  • Normalization-definitionsFully functionally dependency If attribute B is functionally dependant on a composite key A but not on any subset of that composite key, the attribute B is fully functionally dependant on A.

  • Normalization-definitionsTrivial functional dependency A trivial functional dependency is a functional dependency of an attribute on a superset of itself.

    {Employee ID, Employee Address} {Employee Address} is trivial,

  • Normalization-definitionsTransitive dependency Atransitive dependencyis an indirect functional dependency, one in whichXZonly by virtue ofXYandYZ. Multivalued dependency Amultivalued dependencyis a constraint according to which the presence of certain rows in a table implies the presence of certain other rows.

  • Normalization-definitionsJoin dependency A tableTis subject to ajoin dependencyifTcan always be recreated by joining multiple tables each having a subset of the attributes ofT.Super key Asuperkeyis a combination of attributes that can be used to uniquely identify a database record. A table might have many superkeys

  • Normalization-definitionsCandidate key Acandidate keyis a special subset of superkeys that do not have any extraneous information in them: it is a minimal superkey.A table with the fields , , and has many possible superkeys. Three of these are , and . Of those, only is a candidate key as the others contain information not necessary to uniquely identify records ('SSN' here refers to Social Security Number, which is unique to each person).

  • Normalization-definitionsNon-prime attribute A non-prime attribute is an attribute that does not occur in any candidate key. Employee Address would be a non-prime attribute in the "Employees' Skills" table. Prime attribute A prime attribute, conversely, is an attribute that does occur in some candidate key.

  • Normalization-definitionsPrimary key One candidate key in a relation may be designated theprimary key. While that may be a common practice (or even a required one in some environments), it is strictly notational and has no bearing on normalization. With respect to normalization, all candidate keys have equal standing and are treated the same.

  • NORMAL FORMSFIRST NORMAL FORM (1NF).SECOND NORMAL FORM (2NF).THRID NORMAL FORM (3NF). BOYCE-CODD NORMAL FORM (BCNF).FOURTH NORMAL FORM (4NF).

  • 1NFCHARACTERISTICSTable Format.No Multi valued attribute. Primary Key Identified.

  • 2NFCHARACTERISTICS1 NF.No Partial Dependency.

  • 3NFCHARACTERISTICS2 NF.No Transitive Dependency.

  • BCNFCHARACTERISTICSSpecial Case of 3NF.Every determinant is a candidate key.

  • 4NFCHARACTERISTICS3NFNo independent multi valued dependencies

  • CONVERSION TO 1NF Assume a video library maintains a database of movies rented out. Without any normalization all information is stored in one table as shown.

    Here Movies Rented column has multiple values

  • CONVERSION TO 1NF (Cntd)1NF: Each table cell should contain single value and Each record needs to be unique

  • CONVERSION TO 1NF (Cntd)Hence we require both Full Name and Address to uniquely identify a record. This is a composite key. So primary key is identified.

  • Assignment

    If a table project has the information about the projects and employees as shown.Project (proj_num, proj_name, emp_num, job_class, chg_hour, hours); A group of employees are assigned to a given project. an employee can be assign to different projects.Each employee charges according to his job class.Then Convert the table in to first normal form?

  • CONVERSION TO 2NF2NF RulesRule 1- Be in 1NFRule 2- Single Column Primary Key (no partial dependency) .

  • CONVERSION TO 1NF The primary key PK=proj_num+emp_numDependenciesProj_num,emp_num proj_name,emp_name,job_class,chg_hour,hoursProj_num proj_nameEmp_num emp_name,job_class,chg_hourJob_class chg_hour

  • Conversion to 1 NF (cntd..)1NF(Proj_num,emp_num proj_name,emp_name,job_class,chg_hour,hours)

    Partial dependencyProj_num proj_nameEmp_num emp_name,job_class,chg_hour

    Transitive Dependency Job_class chg_hour

  • Conversion to 2 NF(cntd ..)Key Components proj_num Emp_num proj_num and emp_numAssigning dependent attributeproject( proj_num, proj_name)Employee(emp_num, emp_name,job_class,chr_hour)Assignment(proj_num,emp_num,assign_hours)

  • Conversion to 3 NF3NF RulesRule 1- Be in 2NFRule 2- Has no transitive functional dependencies

  • Conversion to 3 NF (Cntd..) Transitive dependency in the given project table Job_class chg_hour Remove the dependent attribute project( proj_num, proj_name)Employee(emp_num, emp_name,job_class) Job(Job_class, chg_hour)Assignment(proj_num,emp_num,assign_hours)