Embed Size (px)
Citation preview
IS6145
Today’s session Logical modelling An exercise
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
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
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
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
Terms Used By Relational Data Model
A ‘Relation’
A relation: Is equivalent to a two-dimensional table Has a heading and a body
Attributes of relation schema have unique names
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
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}
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
Example
Car_licence Car_colour Car_num_doors
05C12476 Silver 3
11K49571 Red 5
13C49831 Black 5
CAR
CAR{Car_licence,Car_colour,Car_num_doors}
Heading or intension or schema
Body or extension or tuples
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’
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
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
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}
So, graphically…
SuperkeyCandidate Key
Primary Key
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]
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}
Foreign Key Constraint: Example
CarRegistration
formRegistered
to
1 1
LicenceNum_doors
Colour
Owner Form ID
CAR(car_licence, car_colour, car_num_doors}REGISTRATIONFORM(FormID, Owner, reg_car_licence)-more stuff here-
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
Data Modification and IntegrityConstraints 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
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…
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.
ER to Relational Mapping
Example of mapping strong entity
Relation
CHILD(Ch_name, Ch_age)
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
ER to Relational Mapping
Example of mapping weak entity
Relation
SPECIAL_NEED(Sn_need, Sn_form_ID, Sn_contact)
EMPLOYEE PLANTWorks_in
(0, n)
(3, n)
[A,20]Fname
Emp#
[N,6]Salary[X,50]
Address
Name
[A,20]Lname
[A,1]Minit
[A,30]Pl_name [N,2]
Pnumber
[A,20]Building
[N,3]No_of_employees
R
[N,1]Name_tag
[N,2]No_of_dependents
BUILDING
- - - - -
(1,1)Houses
R
(1, 1)
[A,1]Emp_a
[N,5]Emp_n
[N,7]Budget
[A,1]Gender
[Dt,8]Date_hired
Broader example
Relation Schemas for the Example of Previous SlideEmployee (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.
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
ER to Relational Mapping
Example of mapping relationship
Relation
CHILD(Ch_name, Ch_Age, Ch_Rname)
# CHILD.{Ch_Rname} ⊆ ROOM.{Rm_name}
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
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}
Exercise
Convert the Fine-Granular Design-Specific ERD on the following slide to a Logical Relational Schema
Exercise
