1. IS6145 Database Analysis and Design Lecture 6: Logical Modelling Rob Gleasure R.Gleasure@ucc.ie www.robgleasure.com

2. IS6145 Today’s session  Logical modelling  An exercise

3. 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

4. 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 actual benefit

5. 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. 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

7. Terms Used By Relational Data Model

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

9. 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

10. A ‘Relation Schema’ Here’s where it begins to look a bit algebraic…  If r is defined by set of attributes A 1, A 2, …, A n, then R(A 1, A 2, …, A n ) 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}

11. 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

12. Example Car_licenceCar_colourCar_num_doors 05C12476Silver3 11K49571Red5 13C49831Black5 CAR CAR{Car_licence,Car_colour,Car_num_doors} Heading or intension or schema Body or extension or tuples

13. 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’

14. 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

15. 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

16. 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}

17. So, graphically… Superkey Candidate Key Primary Key

18. Foreign Key and Referential Integrity Constraint Imagine we have 2 relation schemas:  R1{A1, A2, …An} and R2{B1, B2, … Bm}  Let PK be subset of {A1, …,An} and be the primary key of R1 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 tuples t2 in R2, there exists a tuple t1in R1 such that t2[FK] == t1[PK]

19. Foreign Key and Inclusion Dependencies Way of representing referential integrity constraint. Inclusion dependency R1{A1,...,An} ⊆ R2 {B1,...,Bn} 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}

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

21. 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

22. 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

23. 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_numberStudent_name We’ll come back to this when we cover normalisation…

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

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

26. ER to Relational Mapping For each weak entity type, 1. Create a relation schema 2. Create an attribute in each schema for every attribute of the corresponding entity type 3. Add the primary key of the identifying parent entity type as attribute(s) in the relation schema. 4. 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

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

28. Broader example

29. 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.

30. ER to Relational Mapping For each relationship (Method 1), 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 2. Enforce a foreign key constraint between the relation schemas participating in the relationship type Note: This does not capture optional participation

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

32. ER to Relational Mapping For each relationship (Method 2), 1. Create a separate relation schema representing the relationship type 2. 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

33. 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}

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

35. Exercise