1 The Relational Model Mapping the ER Model to a Database Implementation.
-
date post
15-Jan-2016 -
Category
Documents
-
view
217 -
download
0
Transcript of 1 The Relational Model Mapping the ER Model to a Database Implementation.
1
The Relational Model
Mapping the ER Model to a Database Implementation
2
The Relational Model• Mathematically based• Can develop theoretical design improvements &
enhancements that result in applications to many different applications
• Can use exact mathematical notation• Basic structure is simple, easy to understand
– Separates logical from physical level– Operations do not require user to know storage
structures used– Data operations easy to express, using a few
powerful commands
3
Tables
• Relations are represented logically as tables– Tables are related to one another– Table holds information about entities
• Table rows correspond to individual records
• Table columns correspond to attributes– A column contains values from one domain– Domains consist of atomic (single) values
4
Properties of Tables
• Each cell contains at most one value – It is a single piece of data
• Each column has a distinct name– This is the name of the attribute it represents
• Values in a column all come from the same domain
• Each tuple is distinct – no duplicate tuples
5
Sample: ER to Relational Model
Student
stuId lastName firstName major credits
S1001 Smith Tom History 90
S1002 Chin Ann Math 36
S1005 Lee Perry History 3
S1010 Burns Edward Art 63
S1013 McCarthy Owen Math 0
S1015 Jones Mary Math 42
S1020 Rivera Jane CSC 15
Faculty
facId name department rank
F101 Adams Art Professor
F105 Tanaka CSC Instructor
F110 Byrne Math Assistant
F115 Smith History Associate
F221 Smith CSC Professor
STUDENT CLASS FACULTYEnrolls Taught by
Class
classNum facId schedule room
ART103A F101 MWF9 H221
CSC201A F105 TuThF10 M110
CSC203A F105 MThF12 M110
HST205A F115 MWF11 H221
MTH101B F110 MTuTh9 H225
MTH103C F110 MWF11 H225
Enroll
stuId classNum grade
S1001 ART103A A
S1001 HST205A C
S1002 ART103A D
S1002 CSC201A F
S1002 MTH103C B
S1010 ART103A
S1010 MTH103C
S1020 CSC201A B
S1020 MTH101B A
Student (stuId, lastName, firstName, major, credits)Class (classNum, facId, schedule, room)Faculty (facId, name, department, rank) Enroll(stuId,classNum,grade)
6
Representing Relational Database Schemas
• Can have any number of relation schemas
• Example: University database schemaStudent (stuId, lastName, firstName, major, credits)
Class (classNumber, facId, schedule, room)
Faculty (facId, name, department, rank)
Enroll(stuId,classNumber,grade)
• This could also be represented by the relationships screen of the DBMS.
7
Properties of Relations (Tables)
• Degree: the number of attributes – Binary, ternary, n-ary
• Connectivity:– 1:1, 1:N, M:N
• Cardinality: the number of tuples– Changes as tuples are added or deleted
• Keys
• Constraints
8
Keys
• Relations never have duplicate tuples (rows)– You can always tell tuples apart / there is always a key
• Superkey: set of attributes that uniquely identifies tuples
• Candidate key: minimal superkey – No proper subset of itself is also a superkey
• Primary key (PK): candidate key chosen to uniquely identify tuples– You cannot verify a key by looking at an instance – why?
• Foreign key (FK) is an attribute or combination of attributes of a relation that is the PK of another relation
9
Selecting the Primary Key
• An ideal primary key is short, numeric, and seldom changing
• If there is more than one candidate key, each should be carefully evaluated
• If the entity has no identifier, some attribute must be selected as the PK– In some situations, a surrogate key may be
defined
10
Surrogate Keys• These are unique, DBMS-supplied identifiers used
as the PK of a relation• The values of a surrogate key have no meaning to
users and are normally hidden on forms and reports
• The DBMS does not allow the value of a surrogate key to be changed
• Disadvantages: – FK’s based on surrogate keys have no meaning to users– When data shared among different databases contain the
same ID, merging those tables might yield unexpected results
11
Constraints
• Integrity constraints – to ensure “correctness and internal consistency”– Rules or restrictions that apply to all instances of the database– Enforcing them ensures only legal states of the database are
created
• Types of integrity constraints– Domain constraint - limits set of values for an attribute– Entity integrity - no part of a PK can be null– Referential integrity - each FK value must match the primary
key value of some tuple in its related relation, or be null
• General constraints are the business rules– These may be expressed as table constraints or assertions
• Participation constraints reflect the extent of entities’ involvement in given relationships
12
The Database Implementation Process
• This is the step in the database design process that follows the conceptual design/ERD– Create tables and columns from entities and
attributes– Select primary keys– Represent relationships– Specify constraints– Performance tuning
13
Mapping the ERD to a Relational Model
• Entities– Issues with composite & multi-valued attributes– Issues with weak entities
• Relationships– 1:1, 1:N and M:N– Participation constraints
14
Mapping an Entity to a Table
• Each entity maps onto a table– Its non-composite, single-valued attributes comprise
the table’s column headings– For composite attributes, there are 3 possible ways:
• Make the composite into a single attribute• Create several individual attributes to replace the composite• Create a new entity
– For multi-valued attributes, we create a new table• The PK of this new table is the composite of the original
attribute coupled with the PK of the original table • This new table is created as a weak entity
– Example: multiple email accounts
15
Mapping a Relationship• Binary Relationships:
– 1:M • PK of 1-side becomes a FK of the M-side table
– 1:1• First, make sure they are not the same entity. If not, use
either PK as the FK in the other table– M:M
• Create a relationship table (bridge, composite) with a composite PK consisting of the PK’s of the related entities, along with any relationship attributes
• Ternary or higher degree relationships: construct relationship table of keys, along with any relationship attributes
• With all relationships, we must preserve referential integrity, participation & cardinality constraints
16
1:1 Relationship
EMPLOYEE AUTOHas1 1
17
1:N Relationship
Class
classNum facId schedule room
ART103A F101 MWF9 H221
CSC201A F105 TuThF10 M110
CSC203A F105 MThF12 M110
HST205A F115 MWF11 H221
MTH101B F110 MTuTh9 H225
MTH103C F110 MWF11 H225
FACULTY CLASSTeaches1 N
Faculty
facId name department rank
F101 Adams Art Professor
F105 Tanaka CSC Instructor
F110 Byrne Math Assistant
F115 Smith History Associate
F221 Smith CSC Professor
18
M:N Relationship
Student
stuId lastName firstName major credits
S1001 Smith Tom History 90
S1002 Chin Ann Math 36
S1005 Lee Perry History 3
S1010 Burns Edward Art 63
S1013 McCarthy Owen Math 0
S1015 Jones Mary Math 42
S1020 Rivera Jane CSC 15
STUDENT CLASSEnrolls
Class
classNum facId schedule room
ART103A F101 MWF9 H221
CSC201A F105 TuThF10 M110
CSC203A F105 MThF12 M110
HST205A F115 MWF11 H221
MTH101B F110 MTuTh9 H225
MTH103C F110 MWF11 H225
Enroll
stuId classNum grade
S1001 ART103A A
S1001 HST205A C
S1002 ART103A D
S1002 CSC201A F
S1002 MTH103C B
S1010 ART103A
S1010 MTH103C
S1020 CSC201A B
S1020 MTH101B A
Student (stuId, lastName, firstName, major, credits)Enroll(stuId,classNum,grade)Class (classNum, facId, schedule, room)
19
Weak entities
• Weak entities become tables by adding the PK of the parent (strong) entity– What is the primary key in such a table?
• What about the total participation (and existence dependence) constraint?– What do we need to ensure?– How do we do this?
20
RDBMS Rules Regarding FK’s
• Choices made when relationships are established between tables – Cascade deletes
• If parent instance is deleted, so are all its children
– Restrict deletes• Cannot delete a parent instance if it has a child
– Set to NULL • If parent instance is deleted, set the FK of the child to NULL
– Cascade updates• If parent instance gets new PK, change the FK of all its
children
21
Total participation
• Referential integrity actions need to be specified to ensure that – When the parent entity instance is deleted,
the weak entity instance is deleted as well– Each new weak entity instance must have a
parent instance with which to connect
• Other participation situations also require careful attention.– They must be reasoned out.
22
Weak Entity Example
23
Enforcing Minimum Cardinality
• If the minimum cardinality on the child is 1, at least one child row must be connected to the parent
• A required parent can be specified by making the foreign key value NOT NULL
• A required child can be represented by creating update and delete referential integrity actions on the child and insert referential integrity actions on the parent
• Such referential integrity actions must be declared during database design and trigger codes must be written during implementation
24
Subtype Relationship
25
Entity Supertypes and Subtypes
• Generalization hierarchy– Depicts a relationship between a higher-
level supertype entity and a lower-level subtype entity
• Supertype entity – Contains shared attributes
• Subtype entity – Contains unique attributes
26
Nulls Created with No Supertypes/Subtypes
27
A Generalization Hierarchy
28
Disjoint Subtypes
• Also known as non-overlapping subtypes– Subtypes that contain a subset of the
supertype entity set– Each entity instance (row) of the supertype
can appear in only one of the disjoint subtypes
• Supertype and its subtype(s) maintain a 1:1 relationship– So, how is it implemented in an rdbms?
29
EMPLOYEE/PILOT Supertype/Subtype Relationship
30
A Generalization Hierarchy with Overlapping Subtypes
31
Recursive Relationships
• A recursive relationship is a relationship among entities of the same class
• For 1:1 and 1:N recursive relationships, add a foreign key to the relation that represents the entity
32
1:1 Recursive Relationships
33
1:N Recursive Relationships
34
Some issues with conceptual design using the ER model
• Design choices:– Should a concept be modeled as an entity or an attribute?– Should a concept be modeled as an entity or a
relationship?– Identifying relationships: Binary or ternary?– When to allow NULL values? – How should privacy concerns/sensitive data collection be
handled?
• Constraints in the ER Model:– A lot of data semantics can (and should) be captured.– But some constraints cannot be captured in ER diagrams.
35
Entity vs. Attribute• Should address be an attribute of EMPLOYEE or
an entity (connected to EMPLOYEE by a relationship)?
• Depends upon the use we want to make of address data, and the semantics of the data:– If we have several addresses per employee, address
must be an entity – If the structure (city, street, etc.) is important, e.g., we
want to retrieve employees in a given city, address can be modeled as an entity or as several attributes
36
Entity vs. Attribute example
• Works_In does not allow an employee to work in a department for two or more periods.
• Similar to the problem of wanting to record several addresses for an employee: We want to record several values of the descriptive attributes for each instance of this relationship.
• Accomplished by introducing new entity set, Duration.
name
Employees
eid lot
Works_In
from todname
budgetdid
Departments
dnamebudgetdid
name
Departments
eid lot
Employees Works_In
Durationfrom to
37
Entity vs. Relationship
• First ER diagram OK if a manager gets a separate discretionary budget for each dept.
• What if a manager gets a discretionary budget that covers all managed depts?
Manages
name dnamebudgetdid
Employee Department
eid lot
dbudgetsince
dnamebudgetdid
DepartmentManages
Employee
nameeid lot
since
Manager dbudget
Is aCould
also be a supertyp
e
38
Binary vs. Ternary Relationships
What are the differences between these two diagrams?
agepname
Covers
name
Employee
eid lot
Policy
policyid cost
Beneficiary
agepname
Dependent
policyid cost
Policy
Purchaser
name
Employee
eid lot
Design 1
Design 2
Dependent
39
Binary vs. Ternary Relationships
• An example where a ternary relation is required – Contracts relates entity sets PART, DEPT and
SUPPLIER, and has attribute qty. • No combination of binary relationships is an
adequate substitute:• S “can-supply” P, D “needs” P, and D “deals-with”
S does not imply that D has agreed to buy P from S.• And, furthermore, how would we record qty?
40
Null values
• A null value is an attribute value that has not been supplied
• Null values are ambiguous as they can mean– The value is unknown– The value is inappropriate– The value is known to be blank
• Inappropriate nulls can be avoided by– Defining subtype or category entities– Forcing attribute values through the use of not null– Supplying initial values
• Ignore nulls if the ambiguity is not a problem to the users
41
Surrogate Key Example