ACS-3902 Fall Ron McFadyen 3D21 Slides are based on chapter 5 (7 th edition) (chapter 3 in 6 th edition)

Transcription

1 ACS-3902 Fall 2016 Ron McFadyen 3D21 Slides are based on chapter 5 (7 th edition) (chapter 3 in 6 th edition) 1

2 The Relational Data Model and Relational Database Constraints Relational model Ted Codd (IBM) 1970 First commercial implementations available in early 1980s Widely used 2

3 Relational Model Concepts Database is a collection of relations Implementation of relation is a table comprising rows and columns In practice a table/relation represents an entity type or relationship type (entity-relationship model later) At intersection of a row and column in a table there is a simple value Row Represents a collection of related data values Formally called a tuple Column names Columns may be referred to as fields, or, formally as attributes Values in a column are drawn from a domain of values associated with the column/field/attribute 3

4 Relational Model Concepts 7 th edition Figure 5.1 4

5 Domain Atomic Domains A domain is a collection of values where each value is indivisible Not meaningful to decompose further Specifying a domain Name, data type, rules Examples domain of department codes for UW is a list: { ACS, MATH, ENGL, HIST, etc} domain of gender values for UW is the list ( male, female ) domain for credit hours is a value in the range [0,9] domain for salary is a Canadian dollar value >= $0 Cardinality: number of values in a domain Database implementation & support vary 5

6 Domain example - PostgreSQL CREATE DOMAIN us_postal_code AS TEXT CHECK( VALUE ~ '^\d{5}$' OR VALUE ~ '^\d{5}-\d{4}$' ); CREATE TABLE us_snail_addy ( address_id SERIAL PRIMARY KEY, street1 TEXT NOT NULL, street2 TEXT, street3 TEXT, city TEXT NOT NULL, postal us_postal_code NOT NULL ); 6

7 Domain example - PostgreSQL CREATE DOMAIN dom_payday AS date CONSTRAINT check_dow CHECK (trim(to_char(value, 'day')) = 'friday'); But now before April 1st 2011 our pay day was every Friday, but after April 1st 2011, pay day every Saturday. ALTER DOMAIN dom_payday DROP CONSTRAINT check_dow; ALTER DOMAIN dom_payday ADD CONSTRAINT check_dow CHECK ( (VALUE < ' '::date AND trim(to_char(value, 'day')) = 'friday') OR (VALUE >= ' '::date AND trim(to_char(value, 'day')) = 'saturday' ) ); 7

8 Relation schema R Relation Name R and has a listof attributes: Denoted by R (A 1, A 2,...,A n ) List of attributes A 1, A 2,..., A n Attribute A i Name of a role played by some domain D in the relation schema R Each attribute has a name and a domain Degree (or arity) of a relation Number of attributes (n) in its relation schema 8

9 Relations The relation (or relation state) r(r) Set of n-tuples r = {t 1, t 2,..., t m } Each n-tuple t Ordered list of n values t =<v 1, v 2,..., v n > m tuples in relation each tuple has n values each value comes from a domain Each value v i, 1 i n, is an element of domain A i or is NULL r(r) is a subset of the Cartesian product of the domains of R: r(r) (domain(a 1 ) domain (A 2 )... domain (A n )) 9

10 Relational Databases and Relational Database Schemas Relational database schema S Set of relation schemas S = {R 1, R 2,..., R m } Set of integrity constraints IC Relational database state Set of relation states DB = {r 1, r 2,..., r m } Each r i is a state of R i and such that the r i relation states satisfy integrity constraints specified in IC 10

11 Characteristics of Relations No ordering of tuples in a relation Relation defined as a set of tuples Order of attributes is not that important (some database systems may have some practical tips) 11

12 Characteristics of Relations (cont d.) Two ways of defining a tuple Definition 1 Each n-tuple is an ordered list of n values t =<v 1, v 2,..., v n > Definition 2 Each value v i, 1 i n, is an element of domain A i (or is a special NULL value) Each n-tuple is a set of (<attribute>, <value>) pairs Each pair gives the value of the mapping from an attribute A i to a value v i from dom(a i ) (or is a special NULL value) First definition of relation where attributes and the values within tuples are ordered leads to simpler notation 12

13 Characteristics of Relations (cont d.) Figures 5.1 and 5.2 show the same relation state order of tuples is not important 7 th edition Figure

14 Values Characteristics of Relations (cont d.) Each value in a tuple is atomic Flat relational model Composite and multivalued attributes not allowed First normal form assumption Multivalued attributes Must be represented by separate relations Composite attributes Represented only by simple component attributes in basic relational model Later we cover mapping ER and EER diagrams to relations 14

15 NULLs Characteristics of Relations (cont d.) Represent the values of attributes that may be unknown or may not apply to a tuple Meanings for NULL values Value unknown Value exists but is not available Attribute does not apply to this tuple (also known as value undefined) 15

16 Characteristics of Relations (cont d.) Interpretation (meaning) of a relation Each tuple in the relation is a fact In the Student relation there are five assertions : five students exist and have the characteristics given We must be able to make statements regarding the meaning of tuples. E.g. Dick Davidson is identified by the SSN , has an unknown home phone number, lives at 3452 Elgin Road, has an office phone number (817) , is of age 25 and has a current gpa of

17 Relational Model Notation To refer to the current set of tuples (its state): STUDENT To refer to the schema: STUDENT ( Name, Ssn, Home_phone, Address, Office_phone, Age, Gpa) An attribute can be qualified with the relation name to which it belongs by using dot notation: STUDENT.Name 17

18 Constraints Constraints Restrictions on the actual values in a database state Derived from the rules in the miniworld that the database represents Three categories: Constraints inherent in the data model Constraints expressed in the schema General constraints not falling into the first two categories Expressed in application code 18

19 Constraints Constraints expressed in a data model: there are no duplicate tuples There is at least one attribute value that differentiates one student from another Values for an attribute must come from its domain Each Ssn value is numeric and properly formatted However, in practice these are expressed in the DDL 19

20 Relational Model Constraints (cont d.) Schema-based constraints Domains Keys NULLs Entity integrity Referential integrity 20

21 Domain Constraints In DDL we specify a datatype for an attribute Numeric data types for integers and real numbers Characters Booleans etc. CREATE TABLE Customer( First_Name char(50), Last_Name char(50), Address char(50), City char(50), Country char(25), Birth_Date datetime ); 21

22 Domain Constraints In DDL we can specify a check constraint for an attribute E.g. suppose the value of the age attribute in row must be greater than zero. The following will cause INSERT Customer( joe, smith,0) to be rejected CREATE TABLE Customer( First_Name char(50), Last_Name char(50), Age int check (age >0) ); 22

23 Domain Constraints In DDL we can ensure each row has a value for an attribute E.g. suppose the value of the age attribute in row must be known. The following will cause INSERT Customer( joe, smith,null) to be rejected CREATE TABLE Customer( First_Name char(50), Last_Name char(50), Age int NOT NULL ); 23

24 Domain Constraints SQL has a create domain statement (see page 94). Examples: CREATE DOMAIN persons_name CHAR(30) ; CREATE DOMAIN street_address CHAR(35) ; domain definitions can be used in DDL: CREATE TABLE Customers ( ID INT DEFAULT AUTOINCREMENT PRIMARY KEY, Name persons_name, Street street_address); 24

25 Key Constraints No two tuples can have the same combination of values for all their attributes. Superkey: combination of attributes such that every tuple will have a unique value Key Of course, a key is a superkey But a key is minimal in the sense that if you remove an attribute from the key it is no longer a superkey 25

26 Key Constraints Candidate key Relation schema may have more than one key SQL: unique constraint Primary key of the relation Only one CK is designated as the PK Other candidate keys are designated as unique keys ( secondary keys or alternate keys) SQL: primary key clause 26

27 Key Constraints CREATE TABLE Schedule ( eventid INT, room CHAR(10), starttime DATETIME, endtime DATETIME, eventdescription VARCHAR(255), CONSTRAINT pk PRIMARY KEY (eventid), CONSTRAINT ck1 UNIQUE (room, starttime), CONSTRAINT ck2 UNIQUE (room, endtime), ); 27

28 Referential Integrity Constraints Empid Mgrid Empname Salary 1 NULL Nancy Andrew Janet Margaret Steven Michael Robert Laura Ann Ina David Ron Dan James Mgrid must be null or have a value that exists in a row of Employee 28

29 Referential Integrity Constraints Mgrid must be null or have a value that exists in a row of Employee CREATE TABLE Employees ( empid int NOT NULL, mgrid int NULL, empname varchar(25) NOT NULL, salary money NOT NULL, CONSTRAINT PK_Employees_empid PRIMARY KEY(empid), CONSTRAINT FK_Employees_Employees FOREIGN KEY(mgrid) REFERENCES Employees(empid) ) ; 29

30 PK PK composite PK 30

31 5.7 FK references a PK 31

32 Foreign key rules: Referential Integrity The attributes in FK have the same domain(s) as the primary key attributes PK Value of FK in a tuple t 1 of the current state r 1 (R 1 ) either occurs as a value of PK for some tuple t 2 in the current state r 2 (R 2 ) or is NULL 32

33 Semantic integrity constraints Other Types of Constraints The UoD may require constraints that cannot be expressed in DDL Can use: Application code Triggers (section 5.2) Section 7.2 Section 10.2 Automatically executed on an event such as an insert Stored procedures (section Section ) Procedure stored in the db engine Assertions (section Section 5.2) 7.2 An sql statement that specified a condition (like a SQL Select) that must be true at all times 33

34 Database Operations Operations of the relational model can be categorized into retrievals and updates Basic operations that change the states of relations in the database: Insert Delete Update (or Modify) 34

35 Transaction Transactions An executing program includes database operations surrounded by Begin, Commit, Rollback Unit of work ACID properties (see ACS-4902) Example using pseuodocode: Begin transaction Update account set balance = balance 100 where accno = 1 Update account set balance = balance where accno = 2 If no errors then Commit the transaction Otherwise Rollback the transaction More on transactions ACS

36 Transactions in PostgreSQL BEGIN; UPDATE accounts SET balance = balance WHERE name = 'Alice'; UPDATE accounts SET balance = balance WHERE name = 'Wally '; COMMIT; 36

37 Transactions in PostgreSQL BEGIN; UPDATE accounts SET balance = balance WHERE name = 'Alice'; SAVEPOINT my_savepoint; UPDATE accounts SET balance = balance WHERE name = 'Bob'; Nested transaction -- oops... forget that and use Wally's account ROLLBACK TO my_savepoint; UPDATE accounts SET balance = balance WHERE name = 'Wally'; COMMIT; 37

38 Transactions in MySQL START TRANSACTION; UPDATE accounts SET balance = balance WHERE name = 'Alice'; SAVEPOINT my_savepoint; UPDATE accounts SET balance = balance WHERE name = 'Bob'; Nested transaction -- oops... forget that and use Wally's account ROLLBACK TO my_savepoint; UPDATE accounts SET balance = balance WHERE name = 'Wally'; COMMIT; 38