ZEIT2301 Design of Information Systems Relational Database Schema School of Engineering and Information Technology UNSW@ADFA Dr Kathryn Merrick.

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

4

A Relation (table)

Relation or table name Attributes or columns

Row: an entity instance

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

7

Primary Key

Primary key(table in “designview” in MsAccess)

Session 2, 2010 8

A Composite Key

Compositekey

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

In-class exercise: Derive the relational schema

Car

regoNo {PK}

make

model

year

engineCapacity

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)

In-class exerciseStep 3: implement *:* relationship

yacht(yachtNo, yachtName, length, breadth, depth, jettyTied, berthTied)

berth(jetty, berthNo, length, depth)

member(memberNo, name, address, phoneNo)

ownedBy(yachtNo, memberNo)