Database Data Models

 A model deals with the following data aspects:

o Data structure
o Data integrity
o Data manipulation
 The Relational Model (Ted Codd, IBM, 1969) uses only relations as data structures

Relations

 A relation is defined by its schema

 The schema of a relation is the set of the names of all its columns
 All tuples of a relation have the same schema
 A database is a set of schemas

Examples of a relation Relations

student {number, name, surname, address}

 The values of a relation form its extension:

o {1000, Luis, Sousa, R. Direita}
o {1010, Ana, Ribeiro, R. de Cima}
 If necessary, we could write:
o {number :1000, name:Luis, surname:Sousa, address:R. Direita}
 Things are easier in practice

Relational Model fundamentals

 The only data structure is a TABLE

 TABLES have attributes (columns)
 Attributes have TYPES (char, int, text,...)
 Attribute values are explicit (no pointers)
 Attribute values are atomic (we say there are no “repeating groups”):
o Could never have a value for column “courses” like “dbms, programming”

More fundamentals

 There is no such thing as line ordering

o A relation is not a vector, we cannot say Student[i]
 There is no such thing as column ordering
o When we insert a value we cannot rely on being the Nth column
 There are no repeating lines
o A sub-set of attributes (column values) should always be unique

Terminology

 Relation => Table

 Tuple => record, line, row
 Attribute => field, property, or column
 Domain: set of possible values for a column (eg: set of zip codes)
 Integrity rules

 Domain: a column’s values are only drawn from its domain

 Keys: superkeys are unique columns
o Candidate key: minimal superkey
o Primary key: one of the candidate keys
o Foreign key: takes values from a primary key in other relation
 Entities: primary key is never null
 Constraints are verified each time a record is inserted or updated
 Sometimes it is usefull to defer verification (“chicken” and “egg” problem), otherwise checks
fail
 When a constraint is created we can specify if we want deferred verification
o NOT NULL and CHECK constraints cannot be deferred
 At constraint creation time we can specify:
o deferrable (not deferrable): means the constraint can be deferred at the end of
transaction, by using SET CONSTRAINTS
o initially deferred (initially immediate): means the constraint is deferred at the end of
transaction
 A transaction is started by BEGIN and ends with COMMIT (to confirm) or ROLLBACK (to undo
the work done)

Keys

Example
 CREATE TABLE student (id serial PRIMARY KEY, name text, surname text, born date, gender
char(1) CHECK (gender = ‘F’ OR gender = ‘M’));
 Two constraints are defined:
o PRIMARY KEY
o CHECK: a domain constraint
 Other type of constraints
o NOT NULL: column does not accept null values
o UNIQUE: column does not accept repeated values
o REFERENCES : column is a foreign key

Example 1

 CREATE TABLE signs (student_id int REFERENCES student(id), course_id int REFERENCES
course(id), PRIMARY KEY(student_id, course_id);
 CREATE ASSERTION section_size CHECK (NOT EXISTS (SELECT COUNT(*) FROM section
GROUP BY course_id HAVING COUNT(*) > 25));
o Anytime SECTION is updated the assertion is checked; if it evaluates to FALSE the
update is rejected. Most DBMS do not implement assertions

Example 2

 CREATE DOMAIN semester AS INTEGER CHECK (VALUE = 1 OR VALUE = 2);

 This new domain can be used:
o CREATE TABLE course (id serial, semester SEMESTER…..)

Triggers

 Constraint checking can be done with TRIGGERs

 A trigger is defined in two steps:
o A function, defined by CREATE FUNCTION
o Binding the function to a table, done with CREATE TRIGGER
 A trigger can fire one for each row, or once per statement
 CREATE TRIGGER has a rich syntax, with many possibilities

Triggers 1
 A trigger can fire BEFORE or AFTER a given event (INSERT, DELETE, UPDATE)
 The function can use NEW (the new row, after the event is executed) and OLD (the old row,
as it as before the event is executed) row level triggers
 NEW can be modified in BEFORE trggers
 If several triggers are defined for the same table and event they fire in cascade

Triggers 2

 The trigger that fires BEFORE for each row can return null (the action of the event is
skipped), or a row in case of INSERT or UPDATE events
 AFTER triggers should return NULL
 A trigger that propagates information to other tables (ex. log) shoudl fire AFTER to make
sure all BEFORE triggers have already fired
 Triggers: define the function
CREATE FUNCTION CheckDegree()
RETURNS TRIGGER AS $$BEGIN IF NOT (SELECT degree_id from course WHERE id =
NEW.course_id) = (SELECT degree_id FROM signs WHERE student_id=NEW.student_id) THEN
RAISE EXCEPTION ‘Error: course does not belong to t.he degree of the student.’;
END IF; RETURN NEW; END$$
LANGUAGE plpgsql;

Triggers: bind the function

CREATE TRIGGER SignOk AFTER UPDATE OR INSERT ON signs FOR EACH ROW EXECUTE
PROCEDURE CheckDegree();

 The trigger fires once for each line

 If it was a statement level trigger it would fire exactly once, even if there was no row
inserted or modified
Triggers
CREATE FUNCTION log_degree_change()
RETURNS trigger AS $$BEGIN
IF NEW.degree_id <> OLD.degree_id THEN INSERT INTO change_degree(student_id,
degree_id,date)
VALUES(OLD.student_id,NEW.degree_id,now());
END IF;
RETURN NEW;
END$$ LANGUAGE plpgsql
Triggers
CREATE TRIGGER log_changes
BEFORE UPDATE ON student_degree
FOR EACH ROW
EXECUTE PROCEDURE log_degree_change()

Views
 Are virtual tables, showing to the user only the information he has access to
 Are the result of executing a query
 Avoids exposing at the conceptual/external level the information of the logic level
 Views can be defined from one or more relations
o They are updated anytime the underlying tables are updated
o Views are not materialized (they are not stored, they are executed every
time they’re used)

Views (example)

 CREATE MATERIALIZED VIEW allows a view to be materialized and refreshed

upon demand

 CREATE VIEW elective AS SELECT * FROM course WHERE type = ‘elective’;

 Views hide the details of the underlying tables
 Not all DBMS allow views to be updated
 Relational Algebra

 Procedural language that uses algebraic operators

o Say “what you want” not “how do you get it”
 The Relational Model in practice uses multisets (duplicates allowed),
Relational Algebra uses sets (no duplicates)

Closure property

 The algebra operands are the relations or variables that represent relations, and the
operators do common manipulations with relations in the database
 The relational algebra is a closed system: the result of an operator, being a relation, can be
fed to other operator, and so on:
o operator1(…(operatorn(expression))…)

Basic relational Operators

 SELECT/RESTRICT: selects tuples from a relation

 PROJECT: selects attributes from a relation
 JOIN: joins two relation, matching attribute values

SELECT: example

 select Wine where Price > 100

 σ Price > 100(Wine)

PROJECT: example

 project Wine over Price, Year

 πpprice,year(Wine)

JOIN: example

 join Wine and Region over Brand

 Wine ⋈ Region
 More examples
 πpprice,year,region.name(σPrice > 100Wine) ⋈ Region
 What does this query returns?

Join characteristics
 It’s an important operator, allows linking tables
 As it checks potentially all rows from each table, it’s a costly operation
 As it is generally used frequently, it’s internal execution must be optimized (will see later)

The JOIN operator

 Natural join compares common columns (not implemented in SQL)

 ϴ join: Wine ⋈brand Region
 Most common is the equi-join: ϴ is =
 The are several types of joins:
o ϴ join: INNER JOIN
o External join: LEFT JOIN, RIGHT JOIN, FULL OUTER JOIN

Join: special cases

 If R and S have the same schema, the result of R ⋈ S is their intersection

 If R and S have no common colums, their join is their product

Set operators

The relations must be compatible: they must have the same number of attributes with the same
type (same schema)

Cartesian product

 Not used
 R × S combines all rows of R with all rows of S. The cardinality of the result is the product
of the cardinality of R and S and the degree is the sum of their degrees. If there are
columns with the same name, they are renamed

SQL SELECT
SELECT [ALL | DISTINCT] select_expr, ...

FROM table_references

[WHERE where_definition]

[GROUP BY {col_name | expr | position} [ASC | DESC]]

[HAVING where_definition]

[ORDER BY {col_name | expr | position} [ASC | DESC] , ...]

[LIMIT {[offset,] row_count | row_count OFFSET offset}]

[FOR UPDATE | LOCK IN SHARE MODE]

GROUP BY

 Grouping:
o max, min
o count
o avg
o sum
o …

Result of a SELECT

 Reads all rows in the FROM relations

 Rejects those not respecting the WHERE clause
 Groups rows according to GROUP BY
 Rejects groups according to HAVING