1. IS6145 Database Analysis and Design Lecture 7: Logical Modelling
Rob Gleasure

2. IS6145
Today’s session
Logical modelling
An exercise

3. Strong and Weak Entity Types
Strong entity types and weak entity types
Not all entries in a database need to have unique identifies, e.g. a library may have multiple copies of the exact same book
 These types of entities are called ‘weak’ entities
This is communicated by a double line around the entity and the relationship upon which it depends
Has
Building
Help desk 1 n

4. Strong and Weak Entity Types
Image from Data Modeling and Database Design, By Narayan Umanath, Richard Scamell
Partial key (means it can be combined with unique identifier from strong entity to identify weak entity)
Note that a weak entity can also have normal relationships

5. Technology-independent modelling vs
Technology-independent modelling vs. technology-dependent database design
Up to now our conceptual data modelling has been technology-independent
This is useful, as we want to pick our technologies to suit our needs (which we must first model to properly understand)
Once we are happy with our conceptual design, we then move to logical data modelling
This serves as transition from technology-independent conceptual schema to technology-dependent design
 We’re now committing to the relation (table-based) view of DBs

6. Disclaimer There are different ways to capture logical modelling
The way we’re using assumes that the schema will be used alongside a Fine Granular Design-Specific ER Diagram
Other methods can allow the FGDSERD to be left behind, however
They can’t be written as basic text (so become basically another diagram)
They add a lot of complexity for minimal practical benefit

7. Another disclaimer… Ready. Set. Terminology!
Image from

8. Terms Used By Relational Data Model
Database schema consists of
a set of relation schema
a set of constraints over the relation schema
A Relation is a two-dimensional table
Column in the table = attribute
Row in the table = related data values = a tuple
A Relation consists of a heading and a body
Heading = relation schema, schema, intension
Body = extension

9. Terms Used By Relational Data Model

10. A ‘Relation’ A relation: Is equivalent to a two-dimensional table
Has a heading and a body
Attributes of relation schema have unique names

11. Characteristics of a ‘Relation’
Each attribute value in a tuple is atomic; hence, composite and multi-valued attributes are not allowed in relational data model
Order of attributes in relation schema doesn’t matter
Order of tuples doesn’t matter
Derived attributes are not captured in relation schema 11

12. A ‘Relation Schema’ Here’s where it begins to look a bit algebraic…
If r is defined by set of attributes A1, A2, …, An, then R(A1, A2, …, An) is called relation schema of relation r
… which means
r is a relation over schema R
e.g. a schema for a car may be initially thought of as
CAR{car_licence, car_colour, car_num_doors}

13. Technical Definition of the Relational Data Model (continued)
So, the most important bits to take from that…
Database schema lists total set of Relation schemas
Each Relation schema describes the Attributes for each Tuple in a specific Relation
Each Tuple lists the attribute values for one instance
Each Relation lists all of the tuples stored

14. CAR{Car_licence,Car_colour,Car_num_doors}
Example
CAR{Car_licence,Car_colour,Car_num_doors}
Heading or intension or schema
CAR
Car_licence
Car_colour
Car_num_doors
05C12476
Silver 3
11K49571
Red 5
13C49831
Black
Body or extension or tuples

15. A note on attribute naming in relational modelling
In ER model, the same attribute name is allowed to appear in different entity types since they imply different roles for the attribute name – this duplication is not allowed in relational modelling*
Thus, mapping of attributes from ER model to logical schema requires careful attention in order to ensure unique attribute names in logical schema
The easiest way to do this is just to add a relation-specific prefix to the name of all attributes for that relation, e.g. instead of ‘licence’ we name the attribute ‘car_licence’

16. Constraints What are they? Capture semantics (meaning) of the system
Restrict possible database states
Why do we need constraints?
People implementing the system can prevent constraints violation and catch errors in input/processes
 employee age should not be less that 16
DBMS may be able to enforce specified constraints directly, meaning a safety net from other input programs

17. Constraints Domain constraints
Each attribute declared will have a type according to the schema, e.g. integer, float, date, boolean, string.
These constraints can reject insertions or modifications if they try and change the domain
Entity integrity constraints
Some fields will make data unmanageable if they contain null (empty) values, so we disallow this with an entity integrity constraint

18. Constraints Key constraints Superkey:
A set of attributes (1+) such that if two tuples agree on those attributes, then they agree on all the attributes of the relation {uniqueness property}
Candidate Key:
A superkey with no proper subset that uniquely identifies a tuple of a relation {uniqueness property + irreducibility}
Primary Key:
A candidate key with no missing values for the constituent attributes {uniqueness property + irreducibility + entity integrity constraint}

19. So, graphically…
Primary Key
Candidate Key
Superkey

20. Foreign Key and Referential Integrity Constraint
Imagine we have 2 relation schemas:
R1{A1, A2, …An} and R2{B1, B2, … Bm}
Let PK (the primary key of R1) be a subset of {A1, …,An}
Foreign Key Constraint
Establishes an explicit association between two relation schemas and maintains the integrity of such an association
A set of attributes FK is a foreign key of R2 if:
Attributes in FK have same domain as the attributes in PK
For all suitable tuples t2 in R2, there exists a tuple t1 in R1 such that t2[FK] == t1[PK]

21. Foreign Key and Inclusion Dependencies
Way of representing referential integrity constraint.
Imagine we specify the inclusion dependency R1{A1,...,An} ⊆ R2 {B1,...,Bn}
This means that the values in the first relation R1 ‘refer’ to the values in the second relation
Formally, R1{A1,...,An} ⊆ R2 {B1,...,Bn} if the following holds:
for all tuple t1 in R1, there exists a tuple t2 in R2 such that t1{A1, …, An} = t2{B1, …, Bn}

22. Foreign Key Constraint: Example
CAR(car_licence, car_colour, car_num_doors}
REGISTRATIONFORM(FormID, Owner, reg_car_licence)
-more stuff here-
Num_doors
Licence
Owner
Form ID
Registered to
Car
Registration form
(1,1)
(1,1)
Colour

23. Naming Convention for Foreign Keys
The name of a foreign key attribute in the referencing relation schema consists of:
The prefix used for the attribute names in the referencing relation schema,
An underscore, and
The referenced attribute name

24. Data Modification and Integrity Constraints
Violations of integrity constraints may potentially occur when records are changed, added, or removed
These violations include key constraint, entity identity, domain constraint, referential integrity, inclusion dependencies, functional dependencies, multivalued dependencies
Need to limit operations where such violations occur

25. Functional Dependencies
A functional dependency occurs if when two tuples agree on one value, they must also agree on another value
e.g. The key of a relation functionally determines all the other attributes in that relation
So your student number can’t be saved with some other student’s name associated with it (students’ names are functionally dependent on their student number, or student numbers functionally determine student names)
Student_number Student_name
We’ll come back to this when we cover normalisation…

26. ER to Relational Mapping
For each strong entity type
Create a relation schema
Create an attribute in each schema for every attribute of the corresponding entity type. Note that:
For composite attributes only their constituent atomic components are recorded
Derived attributes are not recorded
Choose a primary key from among the candidate keys by underlining the attribute(s) constituting the primary key.

27. ER to Relational Mapping
Example of mapping strong entity
Relation
 CHILD(Ch_name, Ch_age)

28. ER to Relational Mapping
For each weak entity type,
Create a relation schema
Create an attribute in each schema for every attribute of the corresponding entity type
Add the primary key of the identifying parent entity type as attribute(s) in the relation schema.
The attribute(s) thus added plus the partial key of the weak entity type form the primary key of the relation schema representing the weak entity type

29. ER to Relational Mapping
Example of mapping weak entity
Relation
 SPECIAL_NEED(Sn_need, Sn_form_ID, Sn_contact)

30. Broader example

31. Relation Schemas for the Example of Previous Slide
Employee (Emp_e#a, Emp_e#n, Emp_minit, Emp_lname, Emp_nametag, Emp_gender, Emp_address, Emp_salary, Emp_datehired)
Plant (Pl_name, Pl_p#, Pl_budget)
Building (Bld_building, Bld_pl_p#)
Note 1: Only the atomic attributes constituting Emp# and Name are recorded in EMPLOYEE.
Note 2: The derived attributes, No_of_dependents in EMPLOYEE and No_of_employees in PLANT are not captured here.

32. ER to Relational Mapping
For each relationship (Method 1),
Identify the referencing schema (the child in the relationship). Where relationships are one-to-many, the referencing schema will be the on the ‘many’ side
Enforce a foreign key constraint between the relation schemas participating in the relationship type
Note: This does not capture optional participation

33. ER to Relational Mapping
Example of mapping relationship
Relation
 CHILD(Ch_name, Ch_Age, Ch_Rname)
# CHILD.{Ch_Rname} ⊆ ROOM.{Rm_name}

34. ER to Relational Mapping
For each relationship (Method 2),
Create a separate relation schema representing the relationship type
Create an attribute in the schema for the primary key of each participating entity type
Note: This does capture optional participation but it less efficient

35. ER to Relational Mapping
Example of mapping relationship (Method 2)
Relation
 TEACHER(Tr_name, Tr_experience, Tr_FT/PT)
ROOM(Rm_name, Rm_size)
TEACHES_IN(Ti_Tr_name, Ti_Rm_name)
# TEACHES_IN.{Ti_Rm_name} ⊆ ROOM.{Rm_name}
# TEACHES_IN.{Ti_Tr_name} ⊆ TEACHER.{Tr_name}

36. Exercise
Convert the Fine-Granular Design-Specific ERD on the following slide to a Logical Relational Schema

37. Exercise

38. Exercise (solution)
Form (Fm_form_ID, Fm_contact, Fm_Pname, Fm_Ch_name)
#Form.{Fm_Ch_name} ⊆ Child. {Ch_name}
Child (Ch_name, Ch_age, Ch_Rm_name)
#Child.{Ch_Rm_name} ⊆ Room.{Rm_name}
Room (Rm_name, Rm_size)
Teacher (Th_name, Th_experience, Th_PT/FT)
Teaches_in (Th_name, Rm_name)
Assistant (At_name, At_PT_teach)
Helps_in (At_name, Rm_name)
Special_need (Sn_need, Fm_form_ID, Fm_contact)
Allergy (Al_allergy, Fm_form_ID, Fm_contact)
Favourite (Th_name, At_name)