07 - Logical Design

Logical Design

Readings: Elmasri&Navathe: 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)

COMP102 week 6 (1/2)

DM

BS

spec

ific

DB

MS

inde

pend

ent

Physical Design

Logical Design

Conceptual 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 (Name, 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

COURSE TEACHES INSTRUCTORTRAINEE

ASSIGNED TO

ATTENDS

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:

• need to decide whether ASSIGNED 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:

1. 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. N-ary relationships

8. (generalisations/specifications)

STEP 1: 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

Telephone NumberINSTRUCTOR

Name

FirstName

TownBirth Position

Surname

Code

AgeYearBirthNIN

INSTRUCTORCode* PositionYearBirthTownBirthSurnameFirstNameNIN

ignore multivalued

ignore derived

only consider components

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)

IS A

1

1

TRAINEE

NINCode

Age

Surname

Sex

TownBirth

Area

Title

TRAINEE

Surname Sex

PROFESSIONAL

PROFESSIONAL

Code* Title

TownBirthAgeCode* NIN

Area

STEP 3: Binary one-to-one rel.• For each binary 1:1 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

NameCode*

COURSE TYPE

COURSE TYPECode* Name DirectorCode StartDate

INSTRUCTOR

Code

TownBirth

Telephone Number

Position

COURSE TYPE

Code

Name

SurnameFirstname

Name

DIRECTOR

1

1

Age

YearBirthNIN

StartDateT

S PositionYearBirthTownBirthSurnameFirstNameNINCode*

INSTRUCTOR

STEP 4: Regular Binary one-to-many rel.• For each regular (non weak) binary 1:N 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

EMPLOYEELevel PositionCode* EmployerCode StartDate

WORKS FOR EMPLOYER

N

1

EMPLOYEE

Level

Position

StartDateCode

Name Address

Telephone Number

EMPLOYERName Address Telephone NumberCode*T

S EMPLOYEEPositionCode* Level

STEP 5: Binary many-to-many rel.• For each binary N: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

TRAINEE

Surname Sex TownBirthAgeCode* NIN

Mark

HAS ATTENDED PAST EDITION

EndDateParticipants

TRAINEE

NINCode

Age

Surname

Sex

TownBirth

N

HAS ATTENDED

CodeTrainee* CodeCourse* StartDate*

Code* StartDate*

PAST EDITION

N

StartDate

Mark

EndDate

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

INSTRUCTORCode* PositionYearBirthTownBirthSurnameFirstNameNIN

Telephone NumberINSTRUCTOR

Name

FirstName

TownBirth Position

Surname

Code

AgeYearBirthNIN

INSTR-TELEPHONECode* Telephone Number*

STEP 7: N-ary relationshipsFor each n-ary (n > 2) relationship type R in the ER schema:

• identify relations T1, T2, ... Tn 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 T1, T2, ... Tn

• include all the simple, primitive attributes and the simple components of attributes of R

INSTRUCTOR

Code

TownBirth

Telephone Number

YearBirth

Name

Surname

Firstname

NIN

TEACHESEDITION

ClassTime

INSTRUCTORPositionYearBirthTownBirthSurnameFirstNameNINCode*

EDITIONCode* StartDate*

Age

CLASSROOM

N

N

N

Position

Location

StartDate

TEACHESInstructorCode* CourseCode* StartDate*

CLASSROOMLocation*

Location*

Capacity

Capacity

Day

Name Address

Surname

Age

Sex

TownBirth

Telephone NumberStartDate

NINCode

Mark

TRAINEE INSTRUCTOR

IS A

EMPLOYEE

PROFESSIONAL

TEACHES

HAS WORKED FOR

ATTENDS EDITION

HAS ATTENDED

COURSE TYPE

PAST EDITION HAS TAUGHT

EndDate

StartDate

StartDate EndDateParticipants

ClassDate Time

Area

Position

Level

Title

Code

NameQUALIFIES

N

N

Age

Code

TownBirth

Code

Telephone Number

Position

Surname

CLASSROOM

WORKS FOR EMPLOYER

HELD IN

HELD INHAS BEEN

1

1

1

1

N

N

N N N

1

1

1

N

N

N N

Location

N

N

N

IS A

N

1

TRAINEE



ATTENDS

HAS ATTENDED

CodeTrainee* CodeCourse* StartDate* Mark


PROFESSIONAL

Code* TitleArea

Code*

HAS WORKED FOREmployerCode* StartDate EndDate

EMPLOYERName Address Telephone NumberCode*

Code*

EDITION CLASSESDay TimeStartDate*


QUALIFIES

CodeInstructor* CodeCourse*

Code* StartDate*

PAST EDITION

EndDate

CLASSROOMLocation* Capacity


TEACHESInstructorCode* CourseCode* StartDate* Location*

HAS TAUGHT

CodeInstructor* CodeCourse* StartDate*

Code* Name DirectorCode StartDate

Code* StartDate*

EDITION

COURSE TYPE

TRAINEE



ATTENDS

HAS ATTENDED

CodeTrainee* CodeCourse* StartDate* Mark


PROFESSIONAL

Code* TitleArea

Code*

HAS WORKED FOREmployerCode* StartDate EndDate

EMPLOYERName Address Telephone NumberCode*

Code*

EDITION CLASSESDay TimeStartDate*


QUALIFIES

CodeInstructor* CodeCourse*

Code* StartDate*

PAST EDITION

EndDate

CLASSROOMLocation* Capacity

EDITIONCode* StartDate*


TEACHESInstructorCode* CourseCode* StartDate* Location*

1 11

8

1

8 8

8

1

1

1

1

8

8

8

1

1

1

1

11

8

8

88 8

1

11

1

8

8

8

8

1

1 1

8 8

1

8

(works for)

1

1

11

8

HAS TAUGHT

CodeInstructor* CodeCourse* StartDate*

8

18 (director)

(held in)

(has been held in)

(is a)

(is a)

1111

Code* Name DirectorCode StartDate

COURSE TYPE

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 Relational DB

Entity Type Relation (table)

1:1 relationship type foreign key or relationship relation

1:N relationship type foreign key or relationship relation

N:M relationship type relationship relation and two foreign keys

n-ary relationship type relationship relation and n foreign keys

simple attribute attribute (column, field)

composite attribute set of attributes (fields)

multivalued attribute relation and foreign key

key attribute 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 1:1 or 1:N relationships require one join

• binary N: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 8

• basically converting each

• specialisation with m subclasses S1, S2, ... Sm

• of a generalised superclass C

• into relation schemas

• several options available

• depending on the nature of the specialisation

STEP 8a: Multiple relations: superclass and subclasses

• works for any specialisation S1, S2, ... Sm of a class C (total or partial, disjoint or overlapping)

• create a relation for each subclass S1 and add the primary key of C to each

• equivalent to representing classes via weak entities (“IS-A” rel.)

Surname

Age

NINCode

TRAINEE

TownBirthSex

EMPLOYEEPosition

Level Area

Title

PROFESSIONAL

UU

• only if:

• Subclasses are total

• Specialisation has disjointedness constraint

• DON’T create a relation for the superclass, BUT add all of the superclass attributes to each subclass relations

STEP 8b: Multiple relations: subclasses relations only

Surname

Age

NINCode

TRAINEE

TownBirthSex

Title

Area

EMPLOYEE

Level

PROFESSIONAL

JobType

"Employee" "Professional"

JobType

U U

U U

SALARIED

Position

Position

"Hourly""Salaried"

HOURLY-PAID

SalaryPayScale

d

o SalariedCode* Level Position Salary

Code* Level Position Payscale

Hourly-paid

can actually eliminate this

• only if:

• Specialisation has disjointedness constraint

• add all attributes to the superclass relation

• PROBLEM: many NULL values can be created

STEP 8c: single relation with one type attribute

Surname

Age

NINCode

TRAINEE

TownBirthSex

Title

Area

EMPLOYEE

Level

PROFESSIONAL

JobType

"Employee" "Professional"

JobType

U U

U U

SALARIED

Position

Position

"Hourly""Salaried"

HOURLY-PAID

SalaryPayScale

d

o EmployeeCode* Level Position Salary Payscale

this will be empty if Position=Hourly

this will be empty if Position=Salaried

STEP 8d: 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

Surname

Age

NINCode

TRAINEE

TownBirthSex

EMPLOYEEPosition

Level

Title

Area

PROFESSIONAL

U U

JobType

YOUNG

"Professional"JobType ="Employee"

JobType =

Age < 30

U

TraineeCode* ....... EmplFlag Position Level YoungFlag ProfFlag Area Title

Flags

omany empty/null fields, but controlled by the flags

Different tables for the upper classification

Flags for the lower classifications

Multiple strategies

07 - Logical Design

Documents

Transcript of 07 - Logical Design