Logical Design Readings: Elmasri&avathe: Chapter Relational Database Design by ER- and EER-to-relational mapping (Chapter 7 in the 7th and 5th edition, Chapter 9 in the 6th edition)
Conceptual Design Logical Design DMBS specific DBMS independent Physical Design
Aims of Logical Design the aim of this phase is to construct a logical schema, that correctly and efficiently represents all of the information described by the conceptual (e.g. ER) schema this is not always just a simple translation: in some cases there it no close correspondence between conceptual and logical schema e.g. if the conceptual schema is EER, and the logical schema is relational, a generalisation cannot be directly translated this is because the aim of conceptual design is to represent data accurately and naturally from a high level, computer-independent point of view, whereas logical design has to consider the performances of the final, computer based product
Decisions to take Analysis of redundancies decide whether to delete or retain possible redundancies Removing unsupported concepts e.g. replace all generalisations with other constructs (such as IS- A relationships) when using a relational logical model Partitioning and Merging partition of entity Employee to distinguish between Personal data (ame, YearOfBirth etc) and Professional data (Level, Salary, etc.) on the basis of frequency of access/modification Selection of Primary Identifiers e.g. adding new attributes to entities which do not have a natural primary key
Decisions to take decide how to deal with derived notions: e.g. derived attributes can be represented as virtual fields, as part of a form (visualisation phase), implemented as a query, or just ignored sometimes relations can be derived (cyclic relations) such as: TRAIEE ATTEDS COURSE TEACHES ISTRUCTOR ASSIGED TO need to decide whether ASSIGED TO can be derived from the other relationships, or is a relationship of its own
Step by step process After restructuring, it s just a straightforward process, which considers each concept in turn and with a specific order:. regular entities 2. weak entities 3. binary one-to-one relationships 4. binary one-to-many relationships 5. binary many-to-many relationships 6. multi-valued attributes 7. -ary relationships. (generalisations/specifications)
STEP : Regular entity types For each regular (non weak) entity type E in the ER schema, create a relation (table) that includes all the simple, primitive attributes of E all the simple components of composite attributes of E and choose one of the candidate key attributes as primary key YearBirth Code Age I ignore derived ISTRUCTOR Telephone umber ignore multivalued ame Firstame only consider components ISTRUCTOR I Firstame YearBirth
STEP 2: Weak entity types For each weak entity type W, create a relation (table) that includes all the simple, primitive attributes and all the simple components of composite attributes of W the primary key attribute(s) of the table T that corresponds to W s owner entity type and choose as primary key the combination of all attributes taken from T and the partial key of W (if any) Code I Age TRAIEE TRAIEE I Sex Age Sex IS A PROFESSIOAL PROFESSIOAL Area Title Area Title
STEP 3: Binary one-to-one rel. For each binary : relationship type R in the ER schema: identify T and S, relations corresponding to the entity types participating to R consider the relation T whose entity type has a total participation to R, if any, or choose any of the two if both have partial participation to R include the attribute(s) forming the primary key of S as foreign key in T include all the simple, primitive attributes and the simple components of attributes of R in T S ISTRUCTOR I Firstame YearBirth Telephone umber T COURSE TYPE ame StartDate I YearBirth Age DIRECTOR ISTRUCTOR Code ame COURSE TYPE Code COURSE TYPE ame DirectorCode StartDate Firstname ame
STEP 4: Regular Binary one-to-many rel. For each regular (non weak) binary : relationship type R: identify relation S that corresponds to the entity type at the Many side identify relation T that corresponds to the entity type at the One side include as foreign key in S the primary key of T include all the simple, primitive attributes and the simple components of attributes of R in S StartDate Code ame Address Telephone umber WORKS FOR EMPLOYER Level EMPLOYEE T S EMPLOYER ame Address Telephone umber EMPLOYEE Level EMPLOYEE Level EmployerCode StartDate
STEP 5: Binary many-to-many rel. For each binary :M relationship type R in the ER schema: identify the relations S and T that correspond to the entity types participating to R create a new relation and include as foreign keys all the attributes forming the primary key of S and all the attributes forming the primary key of T include in the new relation all the simple, primitive attributes and the simple components of attributes of R Code I TRAIEE Age TRAIEE I PAST EDITIO Sex Age Sex StartDate* EndDate HAS ATTEDED PAST EDITIO Mark HAS ATTEDED StartDate EndDate Participants CodeTrainee* CodeCourse* StartDate* Mark
STEP 6: Multivalued attributes For each multivalued attribute A of an entity type E in the ER schema: identify the relation T that correspond to E create a new relation S that include an attribute corresponding to A and all the attributes forming the primary key of T if the multivalued attribute is composite, include the simple components ISTRUCTOR I Firstame YearBirth YearBirth Code Age I ISTRUCTOR Telephone umber Firstame ame ISTR-TELEPHOE Telephone umber*
STEP 7: -ary relationships For each n-ary (n > 2) relationship type R in the ER schema: identify relations T, T 2,... T n that correspond to the entity types participating to R create a new relation including as foreign key the attributes forming the primary key of each of the tables T, T 2,... T n include all the simple, primitive attributes and the simple components of attributes of R Capacity Location Telephone umber StartDate Day Time Class EDITIO CLASSROOM TEACHES I YearBirth Age CLASSROOM Location* Capacity ISTRUCTOR I Firstame EDITIO StartDate* YearBirth ISTRUCTOR Code ame TEACHES Instructor Course StartDate* Location* Firstname
ame Address StartDate Code Telephone umber WORKS FOR EMPLOYER EndDate Code Age Sex Area Level I EMPLOYEE TRAIEE IS A IS A PROFESSIOAL Title Mark HAS WORKED FOR Date ATTEDS EDITIO Code ame HAS ATTEDED Class StartDate Time HELD I COURSE TYPE PAST EDITIO CLASSROOM TEACHES HAS BEE HELD I QUALIFIES Location HAS TAUGHT Telephone umber ISTRUCTOR Age Code StartDate EndDate Participants
TRAIEE I Sex Age HAS WORKED FOR Employer StartDate EndDate EMPLOYER ame Address Telephone umber ATTEDS PROFESSIOAL Area Title CodeTrainee* CodeCourse* StartDate* EMPLOYEE Level EmployerCode StartDate EDITIO CLASSES StartDate* Day Time HAS ATTEDED EDITIO StartDate* CodeTrainee* CodeCourse* StartDate* Mark COURSE TYPE ame DirectorCode StartDate PAST EDITIO StartDate* EndDate CLASSROOM Location* Capacity TEACHES Instructor Course StartDate* Location* QUALIFIES HAS TAUGHT CodeInstructor* CodeCourse* CodeInstructor* CodeCourse* StartDate* ISTRUCTOR I Firstame YearBirth ISTR-TELEPHOE Telephone umber*
TRAIEE I Sex Age (is a) ATTEDS (is a) PROFESSIOAL Area CodeTrainee* CodeCourse* StartDate* Title HAS WORKED FOR Employer StartDate EndDate EMPLOYEE Level EmployerCode StartDate EDITIO CLASSES StartDate* Day Time EMPLOYER ame Address Telephone umber (works for) HAS ATTEDED CodeTrainee* CodeCourse* StartDate* PAST EDITIO StartDate* EndDate TEACHES Mark (has been held in) EDITIO StartDate* (held in) CLASSROOM Location* Instructor Course StartDate* Location* COURSE TYPE ame DirectorCode StartDate Capacity (director) QUALIFIES HAS TAUGHT CodeInstructor* CodeCourse* StartDate* ISTRUCTOR I Firstame CodeInstructor* CodeCourse* YearBirth ISTR-TELEPHOE Telephone umber*
recursive relation
recursive relation
Remarks an alternative mapping of a One-to-One relationship type is possible by merging the two entity types and the relationship into a single relation (table) particularly appropriate when both participations are total the two entity types should not participate to other relationship types a One-to-One or a One-to-Many relationship type can always be mapped similarly to the method for Many-to-Many relationship types particularly useful when few relationship instances exist in order to avoid null values in foreign key
ER to Relational Mapping: Summary ER Entity Type Relational DB Relation (table) : relationship type foreign key or relationship relation : relationship type foreign key or relationship relation :M relationship type n-ary relationship type simple attribute composite attribute multivalued attribute key attribute relationship relation and two foreign keys relationship relation and n foreign keys attribute (column, field) set of attributes (fields) relation and foreign key primary key
Relational vs ER relational model does not allow relationship types to be represented explicitly: relationships are represented using primary keys and foreign keys as attributes in relations an operation called natural join allows combinations of all record pairs in order to materialise the relationship: binary : or : relationships require one join binary :M relationships require two joins n-ary relationships require n joins
Relational vs ER relational model does not allow multivalued attributes in relational schemas we create separate relations for each multivalued attribute key attribute of the relevant entity is repeated for each value need a join to relate the values of the multivalued attribute to values of other attributes of the entity or to relationship instances relational languages (e.g. SQL) also cannot explicitly handle set of values object-oriented, network and hierarchical models do support multivalued attributes seen as a flaw in normalised relational models
Mapping of EER constructs Extending ER-to-relational mapping algorithm with a STEP basically converting each specialisation with m subclasses S, S 2,... S m of a generalised superclass C into relation schemas several options available depending on the nature of the specialisation
STEP a: Multiple relations: superclass and subclasses works for any specialisation S, S 2,... S m of a class C (total or partial, disjoint or overlapping) create a relation for each subclass S and add the primary key of C to each equivalent to representing classes via weak entities ( IS-A rel.) Code I Sex Age TRAIEE Level U EMPLOYEE U Area PROFESSIOAL Title
STEP b: Multiple relations: Salary subclasses relations only only if: "Salaried" Subclasses are total Specialisation has disjointedness constraint DO T create a relation for the superclass, BUT add all of the superclass attributes to each subclass relations Level U "Employee" U EMPLOYEE d U o "Hourly" U Salaried "Professiona PROFESSIO PayScale Level Salary Hourly-paid Level Payscale SALARIED HOURLY-PAID can actually eliminate this
STEP c: single relation with one type attribute Salary only if: Specialisation has disjointedness constraint add all attributes to the superclass relation PROBLEM: many ULL values can be created "Salaried" Level U SALARIED "Employee" U EMPLOYEE d U o "Hourly" U HOURLY-PAID Employee "Professiona Level Salary Payscale PROFESSIO PayScale this will be empty if =Hourly this will be empty if =Salaried
STEP d: single relation with multiple type attributes to model overlapping subclasses (but also OK for disjoint) add all attributes to the superclass relation add a Boolean (flag) attribute for each subclass Code I Sex Level Age Trainee JobType = "Employee" U EMPLOYEE TRAIEE o U YOUG U Age < 30 JobType JobType = "Professional" PROFESSIOAL... EmplFlag Level YoungFlag ProfFlag Area Title Area Title Flags many empty/null fields, but controlled by the flags
Different tables for the upper classification Multiple strategies Flags for the lower classifications