Chapter 3 An Introduction to Relational Databases

Copyright © 2004 Pearson Addison-Wesley. All rights reserved.3-2 Topics in this Chapter The Relational Model Relations and Relvars What Relations Mean Optimization The Catalog Base Relvars and Views Transactions

Copyright © 2004 Pearson Addison-Wesley. All rights reserved.3-3 The Relational Model – Informally Structural –Data is perceived by users as tables Integrity –Data subject to specific integrity requirements Manipulation –Operators derive tables from other tables Restrict Project Join

Copyright © 2004 Pearson Addison-Wesley. All rights reserved.3-4 The Relational Model – Operators, Informally Restrict –Extracts specified rows (a/k/a “Select”) Project –Extracts specified columns Join –Combines two tables into one –Based on common values in common column

Copyright © 2004 Pearson Addison-Wesley. All rights reserved.3-5 Fig.3.1 The departments-and-employees database (sample values) Fig.3.2 Restrict, project, and join (examples)

Copyright © 2004 Pearson Addison-Wesley. All rights reserved.3-6 The Relational Model – Materialization, and Set Processing, Informally Materialized evaluation of operators –Generates tables for all steps Pipelined evaluation of operators –Piecemeal intermediate steps Relational operators are set operators –No “row at a time” processing

Copyright © 2004 Pearson Addison-Wesley. All rights reserved.3-7 The Relational Model – Logical/Physical, Informally Data is perceived by the user as tables DBMS can store the data on disk in other formats –Sequential files, indexes, pointer chains, hashing The Information Principle: Information represented by rows and columns, only No user-detected pointers Tables are joined logically based on user understood column values

Copyright © 2004 Pearson Addison-Wesley. All rights reserved.3-8 The Relational Model – Integrity, Informally Every table has a “primary key” –Column whose value implies values in the other columns Some tables have a “foreign key” –References primary key of another table –Used to maintain links between tables –Column whose value implies values in columns in another table

Copyright © 2004 Pearson Addison-Wesley. All rights reserved.3-9 The Relational Model – More Formally An open-ended collection of scalar types A relation type generator Facilities to define relation variables in generated types A relation assignment operator to assign values to relation variables An open-ended set of relational operators used to derive relation values from other relation values

Copyright © 2004 Pearson Addison-Wesley. All rights reserved.3-10 Relations Relation is a mathematical term A table is a relation, mathematically speaking Codd was the first to promulgate this Relations have tuples or rows, not records And attributes or columns, not fields In Codd we trust

Copyright © 2004 Pearson Addison-Wesley. All rights reserved.3-11 Relations and Relvars Relation is a mathematical term A relation is inherently a specific set of values A relation variable, or relvar, is the structure into which values are set Relvars can have different values at different times Most writers use “relation” (or “table’) to mean both the structure and the instantiated values But not from this Date forward DELETE EMP WHERE EMP# = EMP#(‘E4’); EMP := EMP WHERE NOT (EMP# = EMP#(‘E4’)); Fig.3.3 Relation variable EMP after deleting E4 row

Copyright © 2004 Pearson Addison-Wesley. All rights reserved.3-12 Formally, What Relations Mean: Relations vs. Types Relational model includes an open-ended set of types i.e. users can define their own types A type can be regarded as the set of all its possible instances e.g. Emp# as a type is the set of all possible employee numbers

Copyright © 2004 Pearson Addison-Wesley. All rights reserved.3-13 Formally, What Relations Mean: Types and their Predicates Every relation – that is to say – every relation value – is divided into two – head and body Head has name and type for the column Body has rows that conform to the head e.g. Emp# is the name of the column, and could also be its type, if we have defined such a type; otherwise the type could be NUM Fig.3.4 Sample EMP relation value, showing column types

Copyright © 2004 Pearson Addison-Wesley. All rights reserved.3-14 Formally, What Relations Mean: Types and their Predicates, continued For any relation, the head denotes a predicate A predicate is a truth-valued function that can take (as any function can) parameters For any relation, each row of the body denotes a true proposition A true proposition is obtained from the predicate by instantiating it (sending in arguments in place of the parameters)

Copyright © 2004 Pearson Addison-Wesley. All rights reserved.3-15 Formally, What Relations Mean: Types and their Predicates, continued Predicate example: –Employee EMP# is named ENAME, works in department DEPT#, and earns salary SALARY –EMP#, ENAME, DEPT#, and SALARY are parameters as well as table column headings True proposition example: –Employee E1 is named Lopez, works in department D1, and earns salary 40k –E1, Lopez, D1, and 40k are arguments as well as table atomic values

Copyright © 2004 Pearson Addison-Wesley. All rights reserved.3-16 Formally, What Relations Mean: Types and their Predicates, continued Types are sets of things we can talk about Relations are sets of things we say about the things we can talk about A relvar is a predicate A relation is a set of true propositions

Copyright © 2004 Pearson Addison-Wesley. All rights reserved.3-17 Optimization Relational operators are set operators Relational languages are less procedural than procedural languages Relational languages function at a higher level of abstraction than do procedural languages Relational Database Management implementations require an optimizer Optimizer handles the “how” after the user specifies the “what result”

Copyright © 2004 Pearson Addison-Wesley. All rights reserved.3-18 Fig.3.5 Automatic vs. manual navigation

Copyright © 2004 Pearson Addison-Wesley. All rights reserved.3-19 The Catalog System catalog is required to keep track of all database objects Can be thought of as a dictionary Implemented in relvars (known to the DBMS as tables) that can be queried ex) - (COLUMN WHERE TABNAME = ‘DEPT’) { COLNAME } - (COLUMN WHERE COLNAME = ‘EMP#’) {TABNAME} - ((TABLE JOIN COLUMN) WHERE COLCOUNT < 5) {TABNAME, COLNAME}

Copyright © 2004 Pearson Addison-Wesley. All rights reserved.3-20 Fig.3.6 Catalog for the departments-and-employees database (in outline)

Copyright © 2004 Pearson Addison-Wesley. All rights reserved.3-21 Base Relvars and Views Base relvars –Created in SQL via CREATE TABLE Views can be derived from base relvars –Created in SQL via CREATE VIEW View relvars are stored in the catalog View values do not exist separately View values are whatever populates the base relation at the time the user queries the view The user perceives the view as a real relation

Copyright © 2004 Pearson Addison-Wesley. All rights reserved.3-22 CREATE VIEW TOPEMP AS (EMP WHERE SALARY > 33K) {EMP#, ENAME, SALARY}; (TOPEMP WHERE SALARY < 42K) {EMP#, SALARY } Fig.3.7 TOPEMP as a view of EMP (unshaded portions)

Copyright © 2004 Pearson Addison-Wesley. All rights reserved.3-23 Transactions A transaction is a logical unit of work May encompass one or many operations –SQL uses BEGIN TRANSACTION, COMMIT, and ROLLBACK to support transactions Transactions are atomic, durable, isolated, and serializable More detail on this to come (ch 15-16) ex) BEGIN TRANSACTION; UPDATE account A = A – 10; UPDATE account B = B + 10; IF everything worked fine THEN COMMIT; ELSEROLLBACK; END IF;

Copyright © 2004 Pearson Addison-Wesley. All rights reserved.3-24 Suppliers-and-parts Database Fig.3.8 The suppliers-and-parts database (sample values)

Copyright © 2004 Pearson Addison-Wesley. All rights reserved.3-25 Fig.3.9 The suppliers-and-parts database (data definition)