zeit2301 design of information systems relational database schema school of engineering and...
TRANSCRIPT
ZEIT2301Design of Information Systems
Relational Database Schema
School of Engineering and Information TechnologyUNSW@ADFA
Dr Kathryn Merrick
Topic 09: Relational Database Schema
Objectives To study relational database schema in practice To study the conversion between ER diagrams and
relational database schema
We will also start to look at MS Access today
3
Relational Data Model (Review)
Identifies entities, attributes and relationships.
Is the theoretical basis for Relational Database Management Systems Dominant model for data-processing in use in enterprises today
Data is organised into tables (relations), with columns (attributes) and rows (records) Can be accessed in any sorted order Doesn’t have hidden pointers to connect entities - just uses data Any entity can be connected to any other entity by using data
Relational model is therefore VERY flexible
5
Missing (Null) Values
Null
Null means “no value/unknown”, and is not the same as zero, blank or an empty string
6
Primary Key
Primary Key
Every row in a table must be distinguishable from every other row Must have a PK
9
Foreign Keys
A foreign key (FK) is a “copy” of a primary key that has been exported from one table and added as a new column in another table to represent the relationship between them
A foreign key is a copy of the whole of its parent primary key if the primary key is composite then so is the foreign key
Foreign keys are crucial in the relational model (and consequently in relational databases)
They are the ‘glue’ that connects the relations in the database
10
Foreign Key - Example
Title ISBN Edition Publisher ID
Database Systems 0-201-34287-1 2 P091Database Processing 0-02-366881-4 5Analysis and Design 0-202-36995-4 null
Textbook
Primary Key
Publisher ID Name
P091 LongmanP473 University Press
Publisher
Foreign Key
P473P091
Primary Key
11
A Foreign Key in MSAccess
Foreign key
Primary keyof Lecturertable
Primary keyof Coursetable
NB. The name of the FK attribute does not need to match the PK – but the data type should be the same.
Foreign Keys & Referential Integrity
A foreign key can only take on a value that matches a valid value in its parent primary key, or (possibly) be null
A database in which all foreign keys contain such matching values is said to exhibit referential integrity Helps ensure database consistency if the DBMS enforces
referential integrity
Referential Integrity Constraint
Title ISBN Edition Publisher ID
Database Systems 0-201-34287-1 2 nullDatabase Processing 0-02-366881-4 5Analysis and Design 0-202-36995-4 null
Textbook
Violates referential integrity
Publisher ID Name
P091 LongmanP473 University Press
Publisher
Foreign Key
P473
P807
Primary Key
14
Referential Integrity Constraint
Name Level Credits Lecturer ID
Database Systems Undergrad 3 38421Data Networks Undergrad 6Speech Processing Postgrad null
Course
Primary Key
Staff ID StaffName
91027 Goscinski38421 Nguyen
Lecturer
Foreign Key
null38421
Primary Key
Note:
Foreign Key attribute name not necessarily the same as primary key
Relation Schema
The Schema for a relation represents its structure.
Single table example:
Book (ISBN, Title, Edition, Pages) where Book is the name of the relation and “ISBN, Title, Edition
and Pages” is the unordered list of its attributes Primary Key is underlined and, by convention, shown first
16
Relational Database Schema
The complete design of a database is termed its schema
A Relational Database Schema consists of a number of relation (tables)
Table attributes and PKs are listed Foreign keys that link the tables, are identified either by arrows
(see next slide) or by a textual description of the links
17
A Relational Database Schema
lecturer (lecturerName, school, address, telephone, title)
course (courseCode, courseName, lecturerName)
contact (lecturerName, courseCode, hours)
enrol (studentID, courseCode, mark)
student (studentID, name, DOB, address, telephone, gender, degree)
referential integritylink
foreign key
primary key
table (relation) name
attribute name(s)
18
Summary of key features of the Relational Model
In the relational model data is stored in relations, represented as tables with columns and rows. Columns represent attributes Rows represent entity instances
Primary Keys uniquely identify each row.
Foreign Keys provide the link between tables.
19
Converting ER diagrams to a Relational Schema
Once an ER model has been developed it needs to be converted into a “relational schema” A relational schema is a specification of the required table definitions
and their foreign key links
The basis for design of a relational database
There are well-defined principles for converting from one to the other
20
Conversion Rules for Entities
Each entity becomes a relation (table)
Each single-valued attribute of the entity becomes a column (attribute) of the table representing the entity
Composite attributes are represented only by their components
Derived attributes are ignored (record in data dictionary)
ER key primary key
21
Entity Example
Relation/table:
player(playerID, name, DOB, height, weight, gender)
player
playerID {PK}
name
DOB
height
weight
gender
Solution
car
regoNo {PK}
make
model
year
engineCapacity
car (regoNo, make, model, year, engineCapacity)
In-class exercise: Derive the relational schema
player
playerID {PK}
name
DOB
/age
address
street
suburb
postcode
25
Solution
player(playerID, name, DOB, street, suburb, postcode)
Derived attribute ‘age’ not included in relational schema.
Composite attribute ‘address’ not included (only component parts)
player
playerID {PK}
name
DOB
/age
address
street
suburb
postcode
26
Multivalued Attributes
Multivalued attributes are not dealt with by having repeating columns in the table.
That is:
should not be represented by: person (... qual1, qual2, qual3, ... )
person
personID {PK}
qualification [1..*]
……..
…….
27
Multivalued Attributes
The correct way to represent multivalued attributes is with another table
Example:
person (personID, name… , address… , ...etc...)
personQual (personID, qualification)
person
personID {PK}
qualification [1..*]
……..
…….
Note: Composite PK consists of PK from original table plus the multi-valued attribute
In-class exercise: Derive the relational schema
wine
wineID {PK}
wineName
year
producer
winemaker
type
prize [0..*]
tastingNote [1..*]
tastingNote (wineID, tastingNote)
wine (wineID wineName, year, producer, winemaker, type)
winePrize (wineID, prize)
Solution
Representing Relationships
How an ER relationship is represented depends on the degree (unary, binary, ternary) of the relationship and its multiplicity
We consider binary relationships here Three possible multiplicities are:
one-to-one 1:1 one-to-many 1:* many-to-many *:*
Note: * includes zero
1:1 Relationships
To represent a 1:1 relationship, a foreign key is migrated from either relation into the other - but not both ways
Which direction is chosen generally depends on how the connected entities participate in the relationship
If the relationship itself has attributes, those attributes are included in the relation that contains the foreign key
32
1:1 Relationship – Schema
Could be represented by the schema:
staff (staffID, name, ...etc... )
department (deptName, location, deptHead)
department
deptName {PK}
location
staff
staffID {PK}
name is head of
1..1 0..1
To implement the relationship, staffID is migrated to the department relation as a FK called deptHead.
1:1 Relationships
The 1:1 relationship could also be represented by the schema:
staff (staffID, name, ..... , headOfDept)
department (deptName, ...etc...)
The first option (previous slide) is better because all departments have heads but few staff are heads of departments
To implement the relationship, deptName is migrated to the staff relation, as a FK called headOfDept.
34
1:* Relationships
Convert entities into relations (tables)
Include the primary key from the ‘one’ side relation as a foreign key in the ‘many’ side relation
Include attributes of the relationship, if any, in the relation containing the foreign key
35
1:* Relationship - schema
club(clubName, contactNo)
team(teamName, grade, clubName)
team
teamName {PK}
grade
club
clubName {PK}
contactNo has
1..1 1..*
Migrate the PK from the one side of the relationship as a Foreign Key in the many side.
*:* Relationships
Represented by a new table (often called an associative relation)
New table contains two foreign keys - one from each of the participants in the relationship
The PK of the new table is a composite of the two foreign keys
Attributes of the relationship, if any, become attributes of the new table
*:* Relationship - schema
team(teamName, grade)
player(playerID, name, DOB, ….. )
playsIn(playerID, teamName)
team
teamName {PK}
grade
player
playerID {PK}
Name
DOB
….
playsIn
1..* 0..*
New table (from *..* relationship)
38
*:* Relationship with an attribute
student (studentID, name, ...etc...)
enrolment (studentID, courseCode, mark)
course (courseCode, name, ...etc...)
course
courseCode {PK}
student
studentID {PK} enrols In
1..* 1..**
mark
New table (from *..* relationship)
Session 2, 2010
39
In-class exercise: Convert to relational schema
berth
jetty {PK}
berthNo {PK}
length
depth
yacht
yachtNo {PK}
name
length
breadth
depth
member
memberNo {PK}
name
address
phoneNo
tiedTo
ownedBy
0..* 0..1
0..*
1..*
In-class exerciseStep 1: Create tables for entities
yacht(yachtNo, name, length, breadth, depth, ….)
berth(jetty, berthNo, length, depth, ….)
member(memberNo, name, address, phoneNo, ….)
In-class exerciseStep 2: Implement 1:* relationship
berth(jetty, berthNo, length, depth, ….)
member(memberNo, name, address, phoneNo, ….)
yacht(yachtNo, yachtName, length, breadth, depth, jettyTied, berthTied)