ZEIT2301 Design of Information Systems Relational Database Schema School of Engineering and Information Technology 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 nameAttributes 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 Every row in a table must be distinguishable from every other row Must have a PK

7 Primary Key Primary key (table in “design view” in MsAccess)

Session 2, A Composite Key Composite key

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 EditionPublisher ID Database Systems P091 Database Processing Analysis and Design null Textbook Primary Key Publisher ID Name P091 Longman P473 University Press Publisher Foreign Key P473 P091 Primary Key

11 A Foreign Key in MSAccess Foreign key Primary key of Lecturer table Primary key of Course table 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 EditionPublisher ID Database Systems null Database Processing Analysis and Design null Textbook Violates referential integrity Publisher ID Name P091 Longman P473 University Press Publisher Foreign Key P473 P807 Primary Key

14 Referential Integrity Constraint Name Level CreditsLecturer ID Database Systems Undergrad Data Networks Undergrad 6 Speech ProcessingPostgrad null Course Primary Key Staff ID StaffName Goscinski Nguyen Lecturer Foreign Key null 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 integrity link 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-one1:1 one-to-many1:* 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 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 * 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, 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..* * 1..*

In-class exercise Step 1: Create tables for entities yacht(yachtNo, name, length, breadth, depth, ….) berth(jetty, berthNo, length, depth, ….) member(memberNo, name, address, phoneNo, ….)

In-class exercise Step 2: Implement 1:* relationship berth(jetty, berthNo, length, depth, ….) member(memberNo, name, address, phoneNo, ….) yacht(yachtNo, yachtName, length, breadth, depth, jettyTied, berthTied)

In-class exercise Step 3: implement *:* relationship yacht(yachtNo, yachtName, length, breadth, depth, jettyTied, berthTied) berth(jetty, berthNo, length, depth) member(memberNo, name, address, phoneNo) ownedBy(yachtNo, memberNo)