Conceptual / semantic modelling

Overview design; conceptual design; ER model concepts; semantic aspects; problems; Enhanced ER (EER) modelling; transforming an ER (EER) model into a relational model

Design you know the mechanics for building a database system, but don’t know how to design it

Design requirements specification conceptual (semantic) design logical design physical design and implementation testing and validation maintenance

Conceptual (semantic) design constructing a model of the information used in an organisation independently of any targeted DBMS and of any physical considerations - high level of abstraction conceptual model - a more structured description (as opposed to a NL description) try to capture as much meaning as possible model - constructed within a theory terminology (ambiguity): model most popular conceptual data model (theory) ER (or E/R) model (theory) - Chen (1976) UML notation

ER model attribute

Concepts of the ER model semantic, not formal may be understood differently (by designers); results: different models of the same real life system however, an ER model is a semi-formal description (see below) not directly implementable needs to be translated into an implementable model (e.g. the relational model) why, then, doing it in the first instance? symbolic level formal description based on a set of informally defined concepts most popular: ER diagram

Entity entity type entity instance strong/regular entity type a concept identified as having an independent existence entity instance strong/regular entity type weak entity type its existence is dependent on some other entity types examples think ...

ER diagram - entity (UML) Student Student studNo Book-Loan

ER diagram - entity (before)

Attributes a property/characteristic of an entity (or relationship) type instances of the same type have properties in common attribute domain should be included in a fully developed data model attributes simple / composite single-valued / multi-valued derived candidate key / primary key / composite key (note: no foreign key!)

ER diagram - attributes (UML) Student name {PPK} dOB {PPK} day month year sex /age address no code city telNo[1..*] course /fees

ER diagram - attributes (before)

Relationships do not mistake with relation (in the relational model) relationship type a (meaningful) association between entity types participants - the entities involved in the relationship relationship instance degree number of participating entities (types) binary ternary, quaternary … recursive

ER diagram - binary relationships (UML) Book Student Borrows Title Author Edition name dOB Department Belongs To name

ER diagram - binary relationships (before)

ER diagram - ternary relationship (UML) Module code Student Teach name dOB Lecturer name

ER diagram - recursive relationships (UML) Representative Student Represents name dOB Represented

ER diagram - more than one relationship between two entities HeadofDepartment Manages Staff Department name dOB name BelongsTo Member

ER diagram - relationships with attributes (UML) IsAffiliatedTo Staff Department name dOB name date position

ER diagram - relationships with attributes (before)

Structural constraints on relationships cardinality constraints multiplicity cardinality participation relevant to all possibilities - i.e., not to a certain extension

Structural constraints on relationships (UML) Rents Room 0..1 hall no 0..1 Student 0..* Advises name dOB 1 0..* Tutor name Teaches 1..*

ER diagram - structural constraints (before) rented_house M 1 1 owns rents has M N 1 tenant landlord house history

Problems with ER models connection traps a link between two entities seems to have been represented via another entity, but the actual model does not capture that fan traps symbolically: two (1:M) relationships fan out of an entity it is not always a trap chasm traps symbolically: a pathway representing a link contains a relationship with a partial participation a good understanding of the application is required

ER diagram - fan trap Course Project Student Attends Proposes 1 1 code 1..* 1..* Student Project name name dOB

ER diagram - fan trap explanation

ER diagram - solution to a fan trap Student Attends Takes 1..* 1..* name dOB 1 1 Course Project hall no name can you think of another solution?

ER diagram - chasm trap Project Course Student Proposes Takes 1..* 0..1 name 1 0..* Course Student hall no name dOB

ER diagram - solution to a chasm trap Project Proposes Takes 1..* 0..1 name 1 0..* Course Student 1 Attends 1..* hall no name dOB why not always represent all the relationships?

The Enhanced ER model (EER) additional semantic modelling concepts for “richer” (more comprehensive) representations type hierarchies specialisation / generalisation subclass / superclass attribute inheritance aggregation hierarchies aggregation composition

Specialisation / generalisation equivalent names: specialisation hierarchy, generalisation hierarchy or IS-A hierarchy specialisation identifying classes among the instances of an entity type, by identifying distinguishing properties (attributes); a top down approach generalisation grouping entity types into one single class, by disregarding differentiating properties (attributes) a bottom up approach attribute inheritance

Specialisation / generalisation Staff empNo {PK} name salary position Manager Developer Support SalesStaff experience bonus language projects area speciality sales

Specialisation / generalisation Staff empNo {PK} name salary position Manager experience bonus Developer language projects Support area SalesStaff speciality sales FullTime PartTime notice workLoad jobLevel

Constraints overlapping of the child subclasses disjoint - {OR} overlapping - {AND} participation of the parent superclass total - {Mandatory} partial - {Optional}

Constraints Staff FullTime PartTime empNo {PK} name salary position {Optional, OR} {Mandatory, OR} Manager experience bonus Developer language projects Support area SalesStaff speciality sales FullTime PartTime notice workLoad jobLevel

Specialisation / generalisation more than one parent Manager SalesStaff experience bonus speciality sales {Optional} SalesManager target child inherits attributes of both parents

Aggregation Course Module Staff Student code 0..* 0..* 1..1 Supports IsRegisteredFor 1..* 1..* 0..* Module Staff Student code name name dOB

Composition Account Agreement Transaction Overdraft no 1..1 1..1 1..1 1..* 0..* Agreement Overdraft Transaction text date dateValidUntil amount date type amount

Summary conceptual model ER Model EER model entity attribute relationship multiplicity traps EER model generalisation/specialisation constraints aggregation