2: Database SystemsPart IV: Logical Database Design

Logical Database DesignThe process of transforming the conceptual data model (i.e. ERDs) into a logical database model (i.e. relational)A logical database model is a design that conforms to the data model for a class of DBMS

Review: Data ModelsHierarchicalNetworkRelational Object-oriented

Overview of Logical Design Represent entitiesEach entity type in an ERD is represented as a relation Represent relationshipsEach relationship in the ERD must be represented in the relational model

Overview of Logical DesignNormalize relationsRelations must be refined to avoid unnecessary redundancies and anomaliesMerge relationsRedundant relations must be merged

Relational Database ModelData is stored in relations (entities)A relation consists of tuples/rows (instances) and attributesGoal: To store data without unnecessary redundancy and to be able to process information easily

Components of Relational Database ModelData structureData are organized in the form of tablesData manipulationPowerful data manipulation operations are usedData integrityBusiness rules are included to maintain data integrity

KeysKeyMinimal set of attributes that uniquely identifies each row in a relationComposite keyA key consisting of more than one attribute

KeysCandidate keyAny set of attributes that could be chosen as a key of a relationShould be unique and non-redundant Primary keyThe candidate key designated for principal use in uniquely identifying rows in a relation

KeysForeign keyA set of attributes in one relation that constitutes a key in some other (possibly the same) relationUsed to indicate logical links between relations

Foreign Key

EMP DEPT EMPNO ENAME DEPTNO------ ------- ------- 7839 KING 10 7698 BLAKE 30 7782 CLARK 10 7566 JONES 20 7654 MARTIN 30 7499 ALLEN 30 7844 TURNER 30 7900 JAMES 30 7521 WARD 30 7902 FORD 20 7369 SMITH 20...

DEPTNO DNAME LOC ------- ---------- -------- 10 ACCOUNTING NEW YORK 20 RESEARCHDALLAS 30 SALES CHICAGO...

RelationsA named, two-dimensional table of dataConsists of a set of named columns and an arbitrary number of unnamed rowsCan be expressed as:RELATION (attribute1, attribute2,)ExampleSTUDENT (ID_Num, Name, Address, Birthday)

Properties of Relations Entries in columns are atomic (single-valued)Entries in columns are from the same domainEach row is unique (no duplicate rows)The sequence of columns is insignificantThe sequence of rows is insignificant

AnomaliesErrors or inconsistencies that may result when manipulating data in a table that contains redundanciesTypes of anomalies:Insertion anomalyDeletion anomalyModification anomaly

Anomalies: An ExampleEMPLOYEE COURSE

EMPIDNAMEDEPTSALARYCOURSEDATE COMPLETED100Dana ScullyMarketing42,000Planning5/6/99100Dana ScullyMarketing42,000Management5/27/95140Fox MulderInfo Systems39,000C++12/28/93110Walter SkinnerAdministration41,500Management5/27/95110Walter SkinnerAdministration41,500Budgeting6/6/86190Alex KrycekFinance38,000Tax Acct.10/1/93

Well-Structured RelationsContains a minimum amount of redundancy and allows users to manipulate data without errorsNormalization is used to achieve well-structured relations

NormalizationProcess of converting a relation to a standard formUsed to derive well-structured relations that are free of anomalies when manipulatedOften accomplished in stages or normal forms

Normal FormState of a relation that can be determined by applying dependency rules to that relationNormal Forms:First Normal Form (1NF)Second Normal Form (2NF)Third Normal Form (3NF)Boyce-Codd Normal Form (BCNF)Fourth Normal Form (4NF)Fifth Normal Form (5NF)

Functional DependencyThe value of an attribute in a relation determines unique value of another (one or more) attributes in the relationExampleStd_ID -> Name, Bday, MajorLeft-side attribute (Stud_ID) is called a determinant which determines unique values of other attributes in the relation

Partial Functional DependencyOne or more non-key attributes are functionally dependent on only part of the primary keyExampleEMPLOYEE COURSE (Emp_ID, Name, Dept, Salary, Course, Date_Completed)Functional dependencies:Emp_ID, Course -> Date_CompletedEmp_ID -> Name, Dept, SalaryEmp_ID is only part of the primary key

Transitive DependencyA non-key attribute is functionally dependent on one or more other non-key attributesExampleSALES (Cust_No, Name, Salesperson, Region)Functional dependencies: Cust_No -> Name, Salesperson, RegionSalesperson -> Region Salesperson is not a primary key!

Steps in NormalizationFirst normal form (1NF)Repeating groups have been removedGrade Report

STUDENT IDSTUDENT NAMECAMPUS ADDRESSMAJORCOURSE IDCOURSE TITLEINSTRUCTOR NAMEINSTRUCTOR LOCATIONGRADE143Mulder101 CerviniMISCS 122CS 161DB Sys.O/SCoddTannenbaumF 227F 104B+A434Scully304 EliazoPsyPsy 101Th 141En 12Basic PsyMarriageBasic Eng.FreudPope John PaulShakespeareBel 204B 102B 202AAB+

Steps in NormalizationFirst normal form (1NF)Repeating groups have been removedGrade Report

STUDENT IDSTUDENT NAMECAMPUS ADDRESSMAJORCOURSE IDCOURSE TITLEINSTRUCTOR NAMEINSTRUCTOR LOCATIONGRADE143Mulder101 CerviniMISCS 122DB Sys.CoddF 227B+143Mulder101 CerviniMISCS 161O/STannenbaumF 104A434Scully304 EliazoPsyPsy 101Basic PsyFreudBel 204A434Scully304 EliazoPsyTh 141MarriagePope John PaulB 102A434Scully304 EliazoPsyCS 161O/STannenbaumF 104B+

Steps in NormalizationSecond normal form (2NF)Partial functional dependencies have been removedAssumeStudent cannot have multiple majorsStudent cannot repeat a subjectOnly one teacher is available per course

STUDENT (STUDENT ID, STUDENT NAME, CAMPUS ADDRESS, MAJOR)COURSE INSTRUCTOR (COURSE ID, COURSE TITLE, INSTRUCTOR NAME, INSTRUCTOR LOCATIONREGISTRATION (STUDENT ID, COURSE ID, GRADE)

Steps in NormalizationThird normal form (3NF)Transitive dependencies have been removedAssumeInstructor teaches only in one classroomPrevious assumptions holdSTUDENT (STUDENT ID, STUDENT NAME, CAMPUS ADDRESS, MAJOR)COURSE INSTRUCTOR (COURSE ID, COURSE TITLE, INSTRUCTOR NAME)INSTRUCTOR (INSTRUCTOR NAME, INSTRUCTOR LOCATION)REGISTRATION (STUDENT ID, COURSE ID, GRADE)

Steps in NormalizationBoyce-Codd normal form (BCNF)Remaining anomalies from functional dependencies are removedIn BCNF if and only if every determinant is a candidate keyExample: STUDENT ADVISOR (Student ID, Major, Advisor)For each major a student has only one advisorEach advisor advises only one majorEach advisor advises several students in one majorEach major has several advisorsEach student may major in several subjects

Student IDMajorAdvisor123PhysicsEinstein123MusicMozart456BiologyDarwin789PhysicsBohr143PhysicsEinstein

Steps in NormalizationFourth normal form (4NF)Any multivalued dependencies have been removed

Course

Instructor

Textbook

Management

White

Drucker

Management

White

Peters

Management

Green

Drucker

Management

Green

Peters

Management

Black

Drucker

Management

Black

Peters

Finance

Gray

Weston

Finance

Gray

Chang

Steps in NormalizationFifth normal form (5NF)Any remaining anomalies (join dependencies) have been removedJoin dependency - data in relations broken down cannot be recombined to form the original

Steps in NormalizationDomain-Key Normal Form (DK/NF)Proposed by Fagin in 1981Showed that any relation in DK/NF is automatically in 5NF, 4NF, etc.Does not provide methodology for converting to DK/NF

Transforming ERDs to RelationsRepresent entitiesEntity = RelationPrimary key of entity = Primary key of relationConvert:Multivalued attributesComposite attributesWeak entities

Transforming ERDs to RelationsRepresent entitiesConverting multivalued attributesEMPLOYEEEmployee_IDNameAddressSKILLhasSkill_IDSkill_NameEMPLOYEEEmployee_IDNameAddressSkill_Nameconvert many-to-many

Transforming ERDs to RelationsRepresent entitiesConverting composite attributesSTUDENTStudent_IDNameAddressLastFirstMISTUDENTStudent_IDAddressLastFirstMI

Transforming ERDs to RelationsRepresent entitiesConverting weak entitiesEMPLOYEEEmployee_IDNameAddressDEPENDENThasDep_NameBirthdateEMPLOYEEEmployee_IDNameAddressDEPENDENThasDep_NameBirthdateEmployee_ID

Transforming ERDs to RelationsRepresent relationshipsDepends on:Degree of the relationshipCardinalities of the relationship

Transforming RelationshipsBinary one-to-many relationshipPrimary key attributes of the entity on the one-side of the relationship = foreign key in the relation on the many side

DEPTDeptNoDNameLocEMPhasEmpNoENameDEPTDeptNoDNameLocEMPhasEmpNoENameDeptNo

Transforming RelationshipsBinary one-to-many relationship

EMP DEPT EMPNO ENAME DEPTNO

7839 KING 10 7698 BLAKE 30 7782 CLARK 10 7566 JONES 20 7654 MARTIN 30 7499 ALLEN 30 7844 TURNER 30 7900 JAMES 30 7521 WARD 30 7902 FORD 20 7369 SMITH 20...

DEPTNO DNAME LOC

10 ACCOUNTING NEW YORK 20 RESEARCHDALLAS 30 SALES CHICAGO...

Transforming RelationshipsBinary one-to-one relationshipSimilar situation as one-to-many relationshipCreate foreign key on any side of the relationship

EMPLOYEEEmployee_IDNameAddressCOMPUTERassignedTerminal_IDDescriptionEMPLOYEEEmployee_IDNameAddressCOMPUTERassignedTerminal_IDDescriptionEmployee_ID

Transforming RelationshipsBinary one-to-one relationshipPrimary key of relation A = foreign key of relation BPrimary key of relation B = foreign key of relation ABoth situations apply

STUDENTStudent_IDNameAddressPICTUREhasStudent_IDJPG_Image

Transforming RelationshipsBinary many-to-many relationshipCreate a separate relationPrimary key is a composite key consisting of the primary key of each of the two entitiesOccasionally requires a primary key that includes more than just the primary keys of the two relations

Transforming RelationshipsBinary many-to-many relationship exampleEMPLOYEEEmployee_IDNameAddressPROJECTassigned toProject_IDProject_NameRoleEMPLOYEEEmployee_IDNameAddressPROJECTProject_IDProject_NameRolePROJECT_ASSIGNMENTProject_IDEmployee_IDDateAssignedrefers tois given

Transforming RelationshipsBinary many-to-many relationship exampleEMPLOYEEPROJECTPROJECT_ASSIGNMENT

Project_IDProject_Name100Looking for Clues101Monsters, Inc.

Transforming RelationshipsUnary relationshipsUnary one-to-manyA recursive foreign key is added to reference the primary key values of the same relationEMPLOYEEEmployee_IDNamemanagesEMPLOYEEEmployee_IDNamemanagesManager_ID

Transforming RelationshipsUnary relationshipsUnary one-to-many

EMPLOYEEEMPLOYEE_IDNAME MANAGER_ID 7839KING 7698BLAKE7839 7782CLARK7839 7566JONES7839 7654MARTIN7698 7499ALLEN7698

Transforming RelationshipsUnary relationshipsUnary many-to-manyCreate a separate relation to represent the many-to-many relationshipPrimary key = composite key of the two attributes from the same primary key domain

ITEMItem_No.NameUnit_Costpart ofQuantityITEMItem_No.NameUnit_CostconsistsofComp_No.COMPONENTItem_No.refers toQuantity

Transforming RelationshipsUnary relationshipsUnary many-to-manyCOMPONENTITEM

Item_No.NameUnit_Cost500Hard Drive3,000006Pentium 4 PC27,000101Keyboard400999Screw0.50

Transforming RelationshipsSubtypesCreate a separate relation for the supertype and for each subtypeSupertype relation consists of attributes common to all of the subtypesRelation for each subtype contains primary key and attributes unique to that subtypePrimary keys of type and subtypes are from the same domain

Transforming RelationshipsSubtypes exampleEMPLOYEEEmp_IDNameAddressHOURLYSALARIEDCONSULTANTdEmp_Type =HCSHourly_RateMonthly_SalBilling_RateEMPLOYEEEmp_IDNameAddressHOURLYSALARIEDCONSULTANTHourly_RateMonthly_SalBilling_RateEmp_TypeEmp_Typemay beEmp_IDEmp_IDEmp_IDmay bemay be

Transforming RelationshipsSubtypes exampleEMPLOYEECONSULTANTSALARIEDHOURLY

Emp_IDMonthly_Sal4078012,0002129530,0001524920,000

Merge Relations: View IntegrationMerge relations that refer to the same entity to remove redundancyView integration problemsSynonymsHomonymsTransitive DependenciesSubtypes

SynonymsTwo or more attributes may have different names but the same meaningChoose either of the two attribute names and eliminate the other synonym or use a new attribute name to replace both synonyms

HomonymsA single attribute may have more than one meaningCreate new attribute names

Transitive DependenciesMay result when two 3NF relations are merged to form a single relationExampleSTUDENT1 (Student ID, Major)STUDENT2 (Student ID, Advisor)STUDENT (Student ID, Major, Advisor)Note: Assume only one advisor per majorRemove transitive dependencies by creating 3NF relations

SubtypesIf there are two or more different types of a relation but they contain some characteristics common to allCreate supertype-subtype relationshipsExamplePATIENT1 (Patient No., Name, Address)PATIENT2 (Patient No., Room No.)PATIENT (Patient No., Name, Address)INPATIENT (Patient No., Room No.)OUTPATIENT (Patient No., Date Treated)