Simplified phases of Database Design
Mini World (Extended) Entity Relationship Modelling Requirements collection & analysis
and Database requirements
Mappings to the Relational Data Model Conceptual design DBMS Independent Conceptual schema (in a high level data model)
Data model design
Conceptual schema (in the data model of a specific DBMS DBMS specific Physical design
Internal schema (for the same DBMS) Data Definition Language Statements
Conceptual Data Model Concepts Conceptual Data Model Concepts “There exist things which have certain properties and which may be related in some Attribute way(s) to other things. Data represents fact about an Entity Type or Relationship Type specific facts about the things” an entity is often expressed as a set of attributes Entity thing or object that exists in its own right and is Entity Set or Extent distinguishable, represented by an Entity Type of which there will be many Entity Instances…... Set of all Entity Instances of the same Entity Type physical objects, events, activities, associations Relationship Relationship Set or Extent an association between several entities Set of all Relationship Instances of the same represented by a Relationship Type of which there Relationship Type will be many Relationship Instances
Entity Types and Relationship Types Optional Relationship Types Staff Works_for Department Staff Manages Department
ST1 r1 ST1 r1 D1 D1 ST2 ST2 r2 ST3 D2 ST3 D2 r3 D3 r2 D3 ST4 ST4 r4 r3 ST5 ST5 …. …. ST6 r5 ST6 …. r6 …. …. …. Many:many Relationship Types Recursive Relationship Types
Course Staff Teaches Staff r1 Manages ST1 r1 ST1 1 C1 ST2 unmanaged ST2 1 r2 2 ST3 C2 ST3 r2 r3 C3 2 ST4 ST4 2 r3 C4 r4 1 ST5 2 …. r4 …. r5 2 ST6 r5 1 …. r6 …. …. 1 1. Manager 2. Employee
Entity Relationship Model Attributes in Conceptual Modelling
given family 1 For each and every attribute must define domain, SCHOOL REG studno name data type, format and whether it can be null m hons STUDENT faculty m Every entity type must have a key attribute or set n m YEARREG year of attributes 1 labmark YEAR Composite or Atomic ENROL TUTOR 1 exammark Single-valued or Multi-valued slot YEARTUTOR Derived given courseno 1 family courseno m 1 Null valued no. of m n labmark equip TEACH name students COURSE name STAFF m m n subject roomno 1 STUDENT ENROL COURSE equip appraisee appraiser exammark studno subject APPRAISAL
Properties of Relationship Types Semantic Data Models Degree Extended-Entity-Relationship Modelling The number of participating entity types Cardinality ratios Entity Attribute Relationship Modelling The number of instances of each of the Entity Relationship Attribute Modelling participating entity types which can partake in a Entity Modelling single instance of the relationship type 1:1, 1:many, many:1, many:many Object Modelling Participation (optionality) IFO, The relationship instance doesn’t have to exist NIAM etc.… Whether an entity instance has to participate in a Extensions for temporal, constraints, rules etc relationship instance Role Chen 1976 The function that a particular entity type plays in a relationship type Entity Relationship Modelling Roles & Recursive Relationships Composite Keys The function of an entity type in a name relationship type
PERSON
STAFF dateofbirth name m roomno 1 appraisee appraiser
APPRAISAL
Roles & Association Relationships Non-binary Relationship
The function of an entity type in a roomno STAFF relationship type name STAFF p
given family courseno given family equip name TUTORS m n name name COURSE STUDENT SUPERVISE slot 1 m subject studno STAFF STUDENT 1 m
EXAMINER roomno studno
Entity Relationship Model Mapping Entity Types to Relations For every entity type create a relation given family 1 SCHOOL name REG { primary_key (E) U {a1…am} } studno STUDENT m hons Every attribute in entity becomes a relation attribute STUDENT faculty (studno, givenname, m familyname, hons, n m The relation is a subset of the X of the domains of the YEARREG year tutor, slot, year) attributes 1 ENROL(studno, courseno, Composite attributes—just include all the atomic attributes labmark YEAR labmark,exammark) ENROL TUTOR Derived attributes are not included but their derivation 1 exammark slot COURSE(courseno, subject, equip) rules are YEARTUTOR STAFF(lecturer, roomno, appraiser) given family courseno m 1 1 courseno m n TEACH(courseno, lecturer) no. of TEACH labmark equip COURSE name STAFF name students YEAR(year, yeartutor) subject 1 m m ENROL n roomno STUDENT COURSE equip appraisee appraiser SCHOOL(hons, faculty) exammark studno subject APPRAISAL Mapping many:many Relationship Types to Mapping one:many Relationship Types to Relations Relations Mostly: ‘Posting the primary key’ Create a relation: Given E1 at ‘many’ end of relationship and E2 at ‘one’ end of relationship, add to the relation for E1 n (degree of relationship) Make the primary key of the entity at the ‘one’ end (the determined U primary_key(E ) U {a …a } entity) a foreign key in the entity at the ‘many’ end (the determining i 1 m entity). Include any relationship attributes with the foreign key entity i=1 primary keys of each attributes on the { E1 U primary_key(E2) U {a1…an} } participating entity relationship type (if any) type in the relationship attributes on relation for primary key for E2, is given family courseno entity E1 the relationship no. of now a foreign key to E2 labmark equip type (if any) name students m given family ENROL n name STUDENT COURSE slot roomno name exammark m studno subject TUTOR 1 studno STUDENT STAFF
Mapping one:many Relationship Types to Mapping one:many Relationship Types to Relations Relations Sometimes... If relationship type is optional to both entity types and an instance of the relationship is rare, and there are lots of STUDENT STAFF attributes on the relationship then… studno given family tutor slot name roomno Create a relation for the relationship type: s1 fred jones bush 12B kahn IT206 s2 mary brown kahn 12B bush 2.26 {primary_key(E1) U primary_key(E2) U {a1…am} s3 sue smith goble 10A goble 2.82 s4 fred bloggs goble 11A zobel 2.34 s5 peter jones zobel 13B watson IT212 primary key for E1, is now a primary key for attributes on the s6 jill peters kahn 12A woods IT204 foreign key to E1; E2, is now a relationship type capon A14 also the PK for this relation foreign key to E2 (if any) lindsey 2.10 barringer 2.125 given family name slot roomno name m TUTOR 1 studno STUDENT STAFF
Mapping one:many Relationship Types to Relations Optional Participation of Determined Entity (‘one end’) STUDENT studno given family A school entity instance s1 fred jones A student entity instance STAFF does not have to s2 mary brown must participate in a name roomno participate in a relationship s3 sue smith relationship instance of REG kahn IT206 instance of REG s4 fred bloggs bush 2.26 s5 peter jones goble 2.82 given family s6 jill peters 1 zobel 2.34 SCHOOL name REG watson IT212 studno TUTOR m hons studno tutor slot woods IT204 STUDENT faculty s1 bush 12B capon A14 s2 kahn 12B lindsey 2.10 barringer 2.125 s3 goble 10A SCHOOL(hons,faculty) s4 goble 11A s5 zobel 13B STUDENT(studno,givenname,familyname, ??? ) s6 kahn 12A Optional Participation of Determined Entity Optional Participation of the Determinant STUDENT Entity (‘many end’) studno given family hons s1 fred jones ca hons can’t be null s2 mary brown cis because it is mandatory s3 sue smith cs given s4 fred bloggs ca for a student to be family name slot roomno s5 peter jones cs registered for a school. name m s6 jill peters ca TUTOR 1 studno STUDENT STAFF SCHOOL hons faculty ca accountancy no-one registered for mi A student entity instance A staff entity instance cis information systems so doesn’t occur as a does not have to must participate in a cs computer science participate in a relationship relationship instance of ce computer science foreign key value instance of TUTOR TUTOR mi medicine cm mathematics
Optional Participation of the Determinant Entity (‘many end’) Optional Participation of the Determinant Entity 1. STUDENT (studno,givenname,familyname,tutor,slot) STAFF(name, roomno) STUDENT STAFF Integrity constraints: studno given family tutor slot name roomno π STAFF – π STUDENT = ∅ s1 fred jones bush 12B kahn IT206 (name) (tutor) s2 mary brown kahn 12B bush 2.26 s3 sue smith goble 10A goble 2.82 s4 fred bloggs null null zobel 2.34 s5 peter jones zobel 13B 2. STUDENT(studno,givenname,familyname) watson IT212 s6 jill peters null null STAFF(name,roomno) woods IT204 capon A14 TUTOR(studno,tutor,slot) lindsey 2.10 barringer 2.125 3. same as 2 if lots of attributes on TUTOR
Mapping one:one Relationship Types to Relations Multi-Valued Attributes 1. Post the primary key of one of the entity types Create a relation for each multi-valued attribute
into the other entity type as a foreign key, { primary_key(Ei) U multi-valued attribute } including any relationship attributes with it or The primary key is (primary_key(Ei) U multi-valued attribute) 2.Merge the entity types together STUDENT studno given family dateofbirth contact STAFF year s1 fred jones 10/4/78 Mr. Jones name roomno 1 Mrs Jones kahn IT206 YEAR s2 mary brown 12/1/72 Bill Brown given family bush 2.26 Mrs Jones 1 dateofbirth goble 2.82 YEAR name Billy-Jo Woods YEARTUTOR zobel 2.34 year yeartutor studno STUDENT STUDENT_CONTACTS watson IT212 1 zobel studno contact name roomno woods IT204 2 bush 1 s1 Mr. Jones contact s1 Mrs Jones capon A14 3 capon STAFF s2 Bill Brown lindsey 2.10 s2 Mrs Jones barringer 2.125 s2 Billy-Jo Woods Mapping Roles & Recursive Relationships Multiple Roles between Entity Types 1. Treat each relationship type separately The function of an entity type in a relationship 2. Distinct roles are represented by different foreign
type keys drawing on the same relation given family
name name SUPERVISE name STAFF 1 m m roomno 1 STAFF appraisee m STUDENT appraiser 1 EXAMINER APPRAISAL roomno studno STAFF(name,roomno) STUDENT(studno,given,family, ??? ) STAFF(name,roomno) EXAMINER( ??? ) STAFF(name, roomno, ??? ) SUPERVISOR( ??? ) EXAM-SUPER( ??? )
Non-binary Relationship Comparative Terms
roomno EER Relational STAFF STAFF Formal Informal name p Entity Type Schema Relational Schema Table description
given family courseno Entity Type Relation Table equip Entity instance Tuple Row name TUTORS m n 1:many relationship type Use foreign keys Use foreign keys COURSE STUDENT slot 1:many relationship instance Use foreign keys Use foreign keys subject Attribute Attribute Column studno Domain or Value Set Domain Data Type Key Candidate Key Candidate Key COURSE(courseno, subject, equip) No equivalent Primary Key Primary Key STUDENT(studno, givenname, familyname) Multivalued attribute No equivalent No equivalent STAFF(staffname, roomno) Composite attribute No equivalent No equivalent TUTORS( ??? )
Superclasses, Subclasses; Constraints on Specialisation & Generalisation Specialisation & Generalisation Relationships Specialisation the process of defining a set of more specialised Subclasses and Superclasses entity types of an entity type a subclass entity type is a specialised type Generalisation of superclass entity type the process of defining a generalised entity type from a set of entity types a subclass entity type represents a subset or subgrouping of superclass entity type’s Predicate/Condition defined instances determine the entities that will become members of each subclass by a condition on an attribute value. All e.g. undergraduates and postgraduates member instances of the subclass must satisfy the are subclasses of student superclass predicate Attribute Inheritance e.g. first years and second years are subclasses of undergraduates based on their year attribute. subclasses inherit properties (attributes) of their superclasses User defined no condition for determining subclass membership Constraints on Specialisation & Generalisation Specialisation & Generalisation Relationships
Disjointness given family Overlap name studno the same entity instance may be a member of more than one subclass of the specialisation STUDENT Disjoint the same entity instance may be a member of only one
subclass of the specialisation d
STAFF ∩ 1 ∩ Completeness year Total tutor m undergraduate postgraduate every entity instance in the superclass must be a member of some subclass in the specialisation thesis title Partial an entity instance in the superclass need not be a member of any subclass in the specialisation
Superclasses, Subclasses Superclasses, Subclasses Specialisation & Generalisation Relationships Specialisation & Generalisation Relationships
name PERSON payroll no name STAFF address
O
∩ salary ∩ length of service fee
EMPLOYEE STUDENT
O
∩
O ∩
d ∩ ∩
level ∩ thesis ∩ ∩ grade RESEARCH TEACHING
POST UNDER
1-2 GRAD GRAD
∩
ACADEMIC ∩
TECHNICAL ADMIN O year = 3 ∩
TUTORS 1-2 LECTURING SUPERVISOR FINAL YEAR project
courseno project
Categories and Categorisation Specialisation & Generalisation Option A 1. Create a relation for superclass a single superclass/subclass relationship with more than one superclass, where the 2. Create a relation for each subclass such that: superclasses represent different entity types {primary_key of superclass} U {attributes of subclass} (sometimes with different keys) key for subclass is (primary_key of superclass)
given Inclusion dependency: family COMPANY π ⊇π name studno PERSON
U ∪ π (subclass ) = π (superclass)
i=1 ∩ ∩ duration of ownership ∩ Disjoint dependency: year n (number of subclasses) undergraduate postgraduate OWNER ∩ π ∅
given family given family
name studno name studno STUDENT •Many ‘not-applicable’ nulls STUDENT •Does away with joins •Works for total and disjoint •Disjoint: one type which indicates
constraints d which subclass the tuple represents d
∩ •Partial: lose any entity that is not in ∩ •Overlap: set of types = number of
∩ a subclass ∩ subclasses year year •Overlapping: redundancy •Partial: type is null ∴ represents •To recover the superclass can do undergraduate postgraduate superclass undergraduate postgraduate an OUTER UNION on the subclass relations thesis title thesis title
Specialisation & Generalisation Overlapping Specialisation & Generalisation Relationships
1.STAFF(payrollno,name,lengthofservice) ACADEMIC(payrollno,level) name PERSON payroll no name STAFF TECHNICAL(payrollno,project) address
ADMIN(payrollno,grade) O
length of service ∩ salary ∩ 2.ACADEMIC(payrollno,name,lengthofservice, fee
O
level) EMPLOYEE STUDENT ∩
∩ TECHNICAL(payrollno,name,lengthofservice,
level ∩
grade project) O ∩
d ∩
∩ thesis ADMIN(payrollno,name,lengthofservice,grade) ∩ ACADEMIC RESEARCH TEACHING
TECHNICAL ADMIN 3.STAFF(payrollno,name,lengthofservice,level, POST UNDER
1-2 GRAD GRAD
project,grade,type1,type2,type3) ∩ project STAFF(payrollno,name,lengthofservice,level, O ∩ year = 3
project,grade,type) ∩ TUTORS 1-2 LECTURING SUPERVISOR FINAL type = powerset of classes YEAR
courseno project
Specialisation Lattice with Shared Subclass Categories and Categorisation To be a shared subclass the superclasses must have the A category is a subclass of the union of two or more same key, so any of the options A, B or C stand. superclasses that can have different keys because they can be of different entity types If defining superclasses have different keys, specify a
payroll no Staff new surrogate key
∩ d ∩
COMPANY
d ∩ PERSON
∩ Manager Hourly Staff ∩ ∩
personid compid
∩ U
AcademicTechnical Admin Salaried Staff
∩
∩ duration of ownership ∩ OWNER( ??? ) PERSON( ??? ) Admin Manager OWNER COMPANY( ??? ) Entity Constraints Strong and Weak Entities (identifier dependency)
If an entity instance X depends on the a strong entity type has an identifying primary key existence of an entity instance Y, then X is a weak entity type does not have a primary key but existence dependent on does have a discriminator entity type Y is dominant
entity type X is subordinate customer CUSTOMER address customer orderid date part quantity 1 RipOff Inc 123 23/6/94 widget 20 CUST-ORDER thingie 24 m orderid RipOff Inc 678 3/10/94 widget 20 ORDER UpYa Ltd 123 27/9/94 wotsits 800 date widget 50 thingie 24
Mapping Weak Entities to Relations Weak Entity Create a relation customer n CUSTOMER U primary_key(Ei) U partial_key U {ai…an} address 1 i=1 Primary key of each Attributes of the CUST-ORDER Partial key of participating identifying weak entity (if weak entity type m orderid entity type any) (if any) ORDER date customer 1 CUSTOMER address 1 ORDER-MAKEUP CUST-ORDER m part m orderid ORDER_ORDER LINESLINES quantity ORDER date
Association Entity Type Association Entity Type plus Mapping An entity type that represents an association An entity type that represents an association relationship type relationship type Useful if: given family a relationship has lots of attributes courseno you want a relationship type with a relationship name equip m type STUDENT COURSE labmark exammark 1 1 subject m n studno STUDENT ENROL COURSE STUD_ENROL mmCOURSE_ENROL ENROL labmark exammark TUTOR
COURSE(courseno, subject, equip) STAFF STUDENT(studno, givenname, familyname ) Aggregation Aggregation
Aggregation is an abstraction concept for STUDENT ENROL COURSE building composite entities from their components
COURSE 1. aggregate attribute values to form a whole TUTORIAL entity studno courseno
2. combining entities that are related by an STAFF association relationship into higher-level STUDENT ENROL COURSE aggregate entity IS-A-PART-OF slot COURSE IS-A-COMPONENT-OF TUTORIAL Sadly, not catered for in EER modelling.
TUTORS STAFF
Hints for EER Modelling Lets Practice! A record company wishes to use a computer database to help with identify entity types by searching for nouns and noun its operations regarding its performers, recordings and song phrases catalogue. assume all entities are strong and check for weak ones Songs have a unique song number, a non-unique title and a on a later pass composition date. A song can be written by a number of need an identifier for each strong entity composers; the composer’s full name is required. Songs are recorded by recording artists (bands or solo performers). A song is assume all relationships are partial participation recorded as a track of a CD. A CD has many songs on it, called (optional) and check for total (mandatory) ones on a tracks. CDs have a unique record catalogue number, a title and later pass must have a producer (the full name of the producer is required). expect to keep changing your mind about whether Each track must have the recording date and the track number of things are entities, relationships or attributes the CD. keep level of detail relevant and consistent (for A song can appear on many (or no) CDs, and be recorded by many example leave out attributes at first) different recording artists. The same recording artist might re-record the same song on different CDs. A CD must have only 1 recording approach diagram through different views and merge artist appearing on it. CDs can be released a number of times, and them each time the release date and associated number of sales is required.