Upload
denny-england
View
12
Download
0
Tags:
Embed Size (px)
Citation preview
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)