The Relational Model

The Relational Model

What is the Relational Model Relations Domain Constraints SQL Integrity Constraints Translating an ER diagram to the Relational Model and SQL Views

A relational database consists of a collection of tables Each table has a unique name Each row represents a single entity or relationship A table corresponds to the mathematical concept of a set Note that the definition of a relation* is not the same as the usual mathematical definition *per E.F. Codd Relations correspond to tables Tuples correspond to rows a relation is a set of tuples (d 1, d 2,..., d n ), where each element d j is a member of D j, a data domain

The key construct in the relational model is a relation A DB is a collection of relations Relations consist of a relation instance and a relation schema A relation instance corresponds to an actual table with a set of rows A relation schema consists of the column headings and domains of the table

A schema consists of The relation's name The name of each column in the table, also known as a field, or attribute The domain of each field Each domain has a set of associated values like a type For example, the Customer relation Customer = (sin, firstname, lastname, age, income) The schema also specifies the domain of each attribute

Relation schema: Customer = (sin, firstname, lastname, age, salary) sin firstname lastname age salary 111 Buffy Summers 23 43000.00 222 Xander Harris 22 6764.87 Relation instance 333 Rupert Giles 47 71098.65 444 Dawn Summers 17 4033.32 Each field (attribute) has a domain: char(11), char(20), char(20), integer, real An instance is a (small) subset of the Cartesian product of the domains

A domain of a field is similar to the type of a variable The values that can appear in a field are restricted to the field's domain A relation instance is a subset of the Cartesian product of the list of domains If a relation schema has domains D 1 to D n Where the domains are associated with fields f 1 to f n A relation must be a subset of D 1 D 2 D n-1 D n In practice a relation instance is usually some very small subset of the Cartesian product

A relation instance is a set of tuples, or records Each tuple has the same number of fields as the schema No two tuples are identical Relations are defined to be sets of unique tuples A set is a collection of distinct values In practice DBMS allow tables to have duplicate records in some circumstances The order of the tuples is not important

The degree of a relation is the number of fields Also referred to as arity The degree of the Customer relation is 5 The cardinality of a relation instance is the number of tuples it contains The cardinality of the Customer relation instance is 4 A relational database is a collection of relations with distinct relation names A relational database schema is the collection of schemas for all relations in the database

Relational model Relation schema Relation instances (relations) Fields Tuples Database Terminology Table schema Tables Columns or attributes Records or rows

SQL stands for Structured Query Language SQL is divided into two parts Data Manipulation Language (DML) which allows users to create, modify and query data Data Definition Language (DDL) which is used to define external and conceptual schemas The DDL supports the creation, deletion and modification of tables Including the specification of domain constraints and other constraints

To create a table use the CREATE TABLE statement Specify the table name, field names and domains CREATE TABLE Customer ( sin CHAR(11), firstname CHAR(20), lastname CHAR(20), age INTEGER, income REAL) Question is SQL case sensitive? Answer SQL keywords (create and table for example) are not case sensitive. Named objects (tables, columns etc.) may be.

To insert a record into an existing table use the INSERT statement The list of column names is optional If omitted the values must be in the same order as the columns INSERT INTO Customer(sin, firstname, lastname, age, income) VALUES ('111', 'Sam', 'Spade', 23, 65234)

To delete a record use the DELETE statement The WHERE clause specifies the record(s) to be deleted DELETE FROM Customer WHERE sin = '111' Be careful, the following SQL query deletes all the records in a table DELETE FROM Customer

Use the UPDATE statement to modify a record, or records, in a table Note that the WHERE statement is evaluated before the SET statement Like DELETE the WHERE clause specifies which records are to be updated UPDATE Customer SET age = 37 WHERE sin = '111'

To delete a table use the DROP TABLE statement This not only deletes all of the records but also deletes the table schema DROP TABLE Customer http://xkcd.com/327/

Columns can be added or removed to tables using the ALTER TABLE statement ADD to add a column and DROP to remove a column ALTER TABLE Customer ADD height INTEGER ALTER TABLE Customer DROP height

An integrity constraint restricts the data that can be stored in a DB To prevent invalid data being added to the DB e.g. two people with the same SIN or someone with a negative age When a DB schema is defined, the associated integrity constraints should also be specified A DBMS checks every update to ensure that it does not violate any integrity constraints

Domain Constraints Specified when tables are created by selecting the type of the data e.g. age INTEGER Key Constraints Identifies primary keys and other candidate keys Foreign Key Constraints References primary keys of other tables General constraints

A key constraint states that a minimal subset of the fields in a relation is unique i.e. a candidate key SQL allows two sorts of key constraints The UNIQUE statement identifies candidate keys Records may not have duplicate values for the set of attributes specified in the UNIQUE statement A PRIMARY KEY identifies the primary key Records may not have duplicate primary keys and May not have null values for primary key attributes

A primary key identifies the unique set of attributes that will be used to identify a record in a table In some cases there are obvious primary keys in the problem domain (e.g. SIN) In other cases, a primary key may be generated by the system Candidate keys are identified to record the fact that a set of attributes should be unique Preventing duplicate data being entered into the table for this set of attributes

Assume that a patient can be uniquely identified by either SIN or MSP number SIN is chosen as the primary key CREATE TABLE Patient ( sin CHAR(11), msp CHAR(15), firstname CHAR(20), lastname CHAR(20), age INTEGER, ) CONSTRAINT unique_msp UNIQUE (msp) PRIMARY KEY (sin) )

Consider the abbreviated ERD shown below Takes is a many-to-many relationship, so a database table must be created for it (more on this later) It makes no sense for the Takes table to be allowed to contain the student ID of students who do not exist The student ID in Takes should be identified as a foreign key, that references Student Student takes Course

A foreign key constraint references the primary key of another relation The value of the foreign key attribute(s) must match a primary key in the referenced table referenced relation Student Takes referencing relation Course

The attributes of the foreign key and the referenced primary key must be consistent The same number of attributes, with Compatible attribute types, but The attribute names may be different A foreign key references the entire primary key Where the primary key is compound the foreign key must also be compound And not multiple single attribute foreign keys

Customer owns an account must be owned by a single customer Account CREATE TABLE Account( accountnumber INTEGER, type CHAR(5), balance REAL, custsin CHAR(11), PRIMARY KEY (accountnumber)) (accountnumber), CONSTRAINT fk_customer FOREIGN KEY (custsin) REFERENCES Customer )

A DB may require constraints other than primary keys, foreign keys and domain constraints Limiting domain values to subsets of the domain e.g. limit grade to the set of legal grades Or other constraints involving multiple attributes SQL supports two kinds of general constraint Table constraints associated with a single table Assertions which may involve several tables and are checked when any of these tables are modified These will be covered later in the course

Whenever a table with a constraint is modified the constraint must be checked A modification can be a deletion, a change (update) or an insertion of a record If a transaction violates a constraint what happens? Primary key constraints A primary key constraint can be violated in two ways A record can be changed or inserted so that it duplicates the primary key of another record in the table or A record can be changed or inserted so that (one of) the primary key attribute(s) is null In either case the transaction is rejected

Consider these schema (the domains have been omitted for brevity) Customer = (sin, firstname, lastname, age, income) Account = (accountnumber, balance, type, sin) sin in Account is a foreign key referencing Customer age income sin accountnumber balance Customer owns Account lastname firstname type

number balance type sin 761 904.33 CHQ 111 856 1011.45 CHQ 333 903 12.05 CHQ 222 1042 10000.00 SAV 333 sin first last age salary 111 Buffy Summers 23 43000.00 222 Xander Harris 22 6764.87 333 Rupert Giles 47 71098.65 444 Dawn Summers 17 4033.32 Inserting {409, 0, CHQ, 555} into Account violates the foreign key on sin as there is no sin 555 in Customer The insertion is rejected To process the insertion a Customer with a sin of 555 must first be inserted into the Customer table

number balance type sin 761 904.33 CHQ 111 856 1011.45 CHQ 333 903 12.05 CHQ 222 1042 10000.00 SAV 333 Changing this record s sin to 555 violates the foreign key, again leading to the transaction being rejected sin first last age salary 111 Buffy Summers 23 43000.00 222 Xander Harris 22 6764.87 333 Rupert Giles 47 71098.65 444 Dawn Summers 17 4033.32

number balance type sin 761 904.33 CHQ 111 856 1011.45 CHQ 333 903 12.05 CHQ 222 1042 10000.00 SAV 333 sin first last age salary 111 Buffy Summers 23 43000.00 222 Xander Harris 22 6764.87 333 Rupert Giles 47 71098.65 444 Dawn Summers 17 4033.32 Deleting Buffy violates the foreign key, because a record with that sin exists in the Account table

number balance type sin 761 904.33 CHQ 111 856 1011.45 CHQ 333 903 12.05 CHQ 222 1042 10000.00 SAV 333 sin first last age salary 111 Buffy Summers 23 43000.00 222 Xander Harris 22 6764.87 333 Rupert Giles 47 71098.65 444 Dawn Summers 17 4033.32 Updating Buffy's sin to 666 also violates the foreign key, because a record with the old sin is in the Account table

A deletion or update transaction in the referenced table may violate a foreign key Different responses can be specified in SQL Reject the transaction (the default) NO ACTION Delete or update the referencing record CASCADE Set the referencing record's foreign key attribute(s) to null (only on deletion) SET NULL Set the referencing record's foreign key attribute(s) to a default value (only on deletion) SET DEFAULT The default value must be specified in the foreign key

The ER model is a high level design which can be translated into a relational schema And therefore into SQL Each entity and relationship set can be represented by a unique relation Rows in an entity set table represent unique entities Rows in a relationship set table represent associations between entities Some relationship sets do not need to be represented by separate relations SQL constraints should be created to represent constraints identified in the ERD

A table that represents an entity set should have the following characteristics One column for each attribute The domain of each attribute should be known and specified in the table The primary key should be specified in the table Other constraints that have been identified outside the ER model should also be created where possible

age income sin Customer lastname firstname CREATE TABLE Customer ( sin CHAR(11), firstname CHAR(20), lastname CHAR(20), age INTEGER, income REAL, PRIMARY KEY (sin) )

The attributes of a relationship set are The primary keys of the participating entity sets, and Any descriptive attributes of the relationship set The mapping cardinalities of the entities involved in a relationship determine The primary key of the relationship set and Whether or not the relationship set needs to be represented as a separate table Foreign keys should be created for the attributes derived from the participating entity sets

CREATE TABLE WorksIn ( sin CHAR(11), branchname CHAR(30), startdate DATETIME, FOREIGN KEY (sin) REFERENCES Employee, FOREIGN KEY (branchname) REFERENCES Branch, PRIMARY KEY (sin, branchname) ) name salary Employee sin startdate worksin branchname budget Branch city

A separate table is required to represent a relationship set with no cardinality constraints i.e. relationships that are many to many The primary key of the relationship set is the union of the attributes derived from its entity sets A compound key made up of the primary keys of the participating entity sets Attributes derived from its entity sets should be declared as foreign keys

CREATE TABLE Manages ( managersin CHAR(11), subordinatesin CHAR(11), FOREIGN KEY (managersin) REFERENCES Employee, FOREIGN KEY (subordinatesin) REFERENCES Employee, PRIMARY KEY (managersin, subordinatesin) ) salary firstname sin lastname manager subordinate manages Employee

Determine attributes for the table as for a relationship set without cardinality constraints To determine the primary key of a binary relationship set If the relationship is one to one then the primary key of either entity set can be its primary key But it must be only one of the two primary keys If the relationship is many to one, or one to many the primary key of the many entity set is its primary key That is, the entity set whose entities can only appear once in the relationship set; the entity set with the key constraint

If the relationship set has no cardinality constraints the primary key is a compound key Union of the primary keys of the participating entity sets If the relationship set has at least one cardinality constraint The primary key is taken from one of the entity sets with a many relationship That is, one of the entity sets whose entities can be involved in at most one relationship

A binary relationship does not require a table if at least one its entities has a key constraint Add the relationship set's attributes to the table for the entity set that provided the primary key If the entity s participation in the relationship is partial, some rows may not have data for these attributes Such rows will contain null for these fields, which wastes space, and has other undesirable properties The attributes from the other entity sets involved in the relationship are specified as foreign keys

CREATE TABLE Employee ( sin CHAR(11), name CHAR(40), salary REAL, branchname CHAR(30), startdate DATETIME, FOREIGN KEY (branchname) REFERENCES Branch, PRIMARY KEY (sin) ) startdate salary sin name Employee worksin Since an employee can only work in one branch there is still only one row for each employee in the Employee table No table is created for the worksin relationship branchname budget Branch address

Where possible participation constraints should be included in a table specification By declaring the attributes on which there is a foreign key as NOT NULL This approach only works when a relationship set is not represented in a separate table i.e. when the relationship is represented as a foreign key in a table that represents an entity set Specifying an attribute as NOT NULL forces every record of that entity set to have a value for the attribute Some participation constraints must be modeled using assertions, triggers or other methods

CREATE TABLE Owns ( sin CHAR(11), accountnumber INTEGER, FOREIGN KEY (sin) REFERENCES Customer, FOREIGN KEY (accountnumber) REFERENCES Account, PRIMARY KEY (sin, accountnumber) ) sin and accountnumber cannot be null but the participation constraint is not represented Why not? birthdate income sin lastname firstname accountnumber type balance Customer owns Account

CREATE TABLE Employee ( sin CHAR(11), name CHAR(40), salary REAL, Making branchname NOT NULL ensures that every Employee must branchname CHAR(30) NOT NULL, work in a branch startdate DATETIME, FOREIGN KEY (branchname) REFERENCES Branch, PRIMARY KEY (sin) ) name salary Employee sin startdate worksin branchname budget Branch address

CREATE TABLE WorksIn ( sin CHAR(11), branchid INTEGER, from DATETIME, to DATETIME, FOREIGN KEY (sin) REFERENCES Employee, FOREIGN KEY (branchid) REFERENCES Branch, PRIMARY KEY (sin, branchid, from, to) ) from Note that a table is not required for Duration as it would be redundant All durations must appear in worksin and Duration only has primary key attributes to salary sin lastname firstname Duration budget branchid branchname Employee worksin Branch

This ERD requires the following tables Account with NOT NULL foreign key, sin, references Customer and represents Owns birthdate income sin lastname firstname accountnumber type balance Customer owns Account Customer, with foreign key empsin to represent PersonalBanker And an Employee table personal banker name salary Employee sin

A weak entity set has the following characteristics Total participation in the identifying relationship A cardinality constraint with the identifying relationship A partial key Therefore the weak entity set should: Include a foreign key (to its owner entity set), the attributes of which are part of the WES' primary key Which prevents these attributes from being null Usually specify the foreign key as ON DELETE CASCADE

CREATE TABLE Room ( name CHAR(10), squarefeet REAL, taxnumber INTEGER, PRIMARY KEY (name, taxnumber), FOREIGN KEY (taxnumber) REFERENCES Building ON DELETE CASCADE) city street number taxnumber squarefeet name House contains Room

There are two basic approaches to translating class hierarchies to tables Create separate tables for the superclass and for each subclass The superclass table only contains attributes of the superclass entity The subclass tables contain their own attributes, and the primary key attributes of the superclass Superclass attributes are declared as both the primary key and a foreign key in the subclasses Cascade deletion of superclass records to subclasses Or

Create tables for the subclasses only The subclass tables contain their attributes, and all of the attributes of the superclass The primary key of the subclass is the primary key of the superclass This assumes that there are no entities in the superclass that are not entities in a subclass i.e. That a coverage constraint exists Otherwise coverage and overlap constraints must be specified using assertions

Building = (taxnumber, city, street, number, tax) and RentalProperty = (taxnumber FK, units, rate) HeritageBuilding = (taxnumber FK, buildyear) city taxnumber street number tax Building units rate ISA buildyear RentalProperty HeritageBuilding

RentalProperty = (taxnumber, city, street, number, tax, units, rate) and HeritageBuilding = (taxnumber, city, street, number, tax, buildyear) taxnumber city number street tax Building units rate ISA buildyear RentalProperty HeritageBuilding

An aggregate entity is represented by the table defining the relationship set in the aggregation The relationship set between the aggregate entity and the other entity has the following attributes: The primary key of the participating entity set, and The primary key of the relationship set that defines the aggregate entity, and Its own descriptive attributes, if any The normal rules for determining primary keys and omitting tables apply

Create tables for the entity sets Project Department Employee And the relationship sets sponsors monitors monitors In this example, each department, project pair is monitored by an employee Employee Department sponsors Project

There is a case where no table is required for an aggregate entity Even where there are no cardinality constraints If there is total participation between the aggregate entity and its relationship, and If the aggregate entity does not have any descriptive attributes Insert the attributes of the aggregate entity into the table representing the relationship with that entity

A project, department pair must be monitored by an employee, so each such pair must appear in monitors If sponsors has no descriptive attributes, create a monitors table with the primary keys of Employee, Project and Department monitors Create tables for the entity sets Project Department Employee Employee Department sponsors Project

Views are not explicitly stored in a DB but are created as required from a view definition At least conceptually, if not necessarily in practice Once defined, views may be referred to in the same way as a tables View are useful for Convenience users can access the data they require without referring to many tables Security users can only access appropriate data Independence views can help mask changes in the conceptual schema

Consider a DB containing these two tables: Branch =(branchname, managersin, budget) Employee = (sin, name, salary, birthdate, branchname) Where branchname in Employee is a foreign key A view is needed to access the employee's SIN, name and manager s SIN CREATE VIEW Emp_Manager (E.sin, E.name, B.managerSIN) AS SELECT E.sin, E.name, B.managerSIN FROM Branch B Employee E WHERE B.branchName = E.branchName

Users should be able to interact with views as if they were base tables And without being aware of the distinction This goal is achieved when running queries on views However updates to views may cause problems Particularly if a view is derived from multiple tables and does not include the primary keys of all tables Generally, updates are only allowed on views derived from a single table And, even then, there are further restrictions

Two distinct tuples in a relation instance, cannot have identical values in all the fields of a superkey Or if two entities have the same superkey values, they must have the same values for their other attributes So must, in fact, be the same entity We can describe this idea formally in this way A subset K of a relation R is a superkey of R if for all pairs of tuples t 1 and t 2 t 1 t 2 then t 1 [K] t 2 [K] That is, where K is a set of attributes of a relation R K is a superkey for R if for all pairs of different tuples there are no two tuples with the same values for K

The notion of a superkey can be generalized and applied to smaller sets of attributes e.g. Vehicle = {vin, colour, model, capacity} vin (vehicle identification number) is a superkey We can say that capacity is functionally determined by vin as there can only be one capacity for a particular vin The model and the capacity have the same relationship A particular model can only have one capacity However, unlike the vin, the model does not functionally determine the colour We call this relationship functional dependency

Denote functional dependencies as follows If R is a relation and if R and R we can express a functional dependency as holds on R if for all pairs of tuples such that t 1 [ ] = t 2 [ ] then t 1 [ ] = t 2 [ ] A subset K of a relation R is a superkey if K R In the vehicle example vin {vin, colour, model, capacity} model {capacity} means subset, proper subset

Why use functional dependencies? To specify constraints on relations To determine if a relation is legal given a set of functional dependencies To reason about whether or not the set of tables in a database is appropriate We will use functional dependencies to decompose tables into normal forms We will discuss functional dependencies in more detail later in the course