Relational Databases BORROWED WITH MINOR ADAPTATION FROM PROF. CHRISTOS FALOUTSOS, CMU /615

Similar documents
The Relational Model. Roadmap. Relational Database: Definitions. Why Study the Relational Model? Relational database: a set of relations

The Relational Model. Outline. Why Study the Relational Model? Faloutsos SCS object-relational model

The Relational Model. Chapter 3

The Relational Model. Chapter 3. Database Management Systems, R. Ramakrishnan and J. Gehrke 1

The Relational Model. Chapter 3. Comp 521 Files and Databases Fall

The Relational Model. Chapter 3. Comp 521 Files and Databases Fall

Database Applications (15-415)

The Relational Model 2. Week 3

The Relational Model. Why Study the Relational Model? Relational Database: Definitions

Relational Model. Topics. Relational Model. Why Study the Relational Model? Linda Wu (CMPT )

Data Modeling. Yanlei Diao UMass Amherst. Slides Courtesy of R. Ramakrishnan and J. Gehrke

Why Study the Relational Model? The Relational Model. Relational Database: Definitions. The SQL Query Language. Relational Query Languages

Database Systems ( 資料庫系統 )

Introduction to Data Management. Lecture #4 (E-R Relational Translation)

Introduction to Data Management. Lecture #4 (E-R à Relational Design)

Relational data model

Database Applications (15-415)

The Relational Model. Relational Data Model Relational Query Language (DDL + DML) Integrity Constraints (IC)

Database Systems. Course Administration

Introduction to Data Management. Lecture #5 Relational Model (Cont.) & E-Rà Relational Mapping

The Relational Model (ii)

High-Level Database Models (ii)

CIS 330: Applied Database Systems

High Level Database Models

From ER to Relational Model. Book Chapter 3 (part 2 )

Database Management Systems. Chapter 3 Part 2

CIS 330: Applied Database Systems. ER to Relational Relational Algebra

The Relational Data Model. Data Model

Review. The Relational Model. Glossary. Review. Data Models. Why Study the Relational Model? Why use a DBMS? OS provides RAM and disk

The Relational Model

The Entity-Relationship Model

The Relational Model of Data (ii)

Administrivia. The Relational Model. Review. Review. Review. Some useful terms

Database Management Systems. Chapter 3 Part 1

Introduction to Data Management. Lecture #5 (E-R Relational, Cont.)

The Relational Model. Week 2

The Entity-Relationship Model. Overview of Database Design

Comp 5311 Database Management Systems. 4b. Structured Query Language 3

The Relational Model

Introduction to Data Management. Lecture #3 (E-R Design, Cont d.)

Database Systems. Lecture2:E-R model. Juan Huo( 霍娟 )

EGCI 321: Database Systems. Dr. Tanasanee Phienthrakul

Introduction to Data Management. Lecture #6 E-Rà Relational Mapping (Cont.)

LAB 3 Notes. Codd proposed the relational model in 70 Main advantage of Relational Model : Simple representation (relationstables(row,

Database Management Systems. Session 2. Instructor: Vinnie Costa

Overview of db design Requirement analysis Data to be stored Applications to be built Operations (most frequent) subject to performance requirement

CONCEPTUAL DESIGN: ER TO RELATIONAL TO SQL

Translation of ER-diagram into Relational Schema. Dr. Sunnie S. Chung CIS430/530

ER to Relational Mapping. ER Model: Overview

CompSci 516 Database Systems. Lecture 2 SQL. Instructor: Sudeepa Roy

Database Design & Deployment

Lecture 2 SQL. Instructor: Sudeepa Roy. CompSci 516: Data Intensive Computing Systems

Databases Model the Real World. The Entity- Relationship Model. Conceptual Design. Steps in Database Design. ER Model Basics. ER Model Basics (Contd.

OVERVIEW OF DATABASE DEVELOPMENT

Lecture 2 SQL. Announcements. Recap: Lecture 1. Today s topic. Semi-structured Data and XML. XML: an overview 8/30/17. Instructor: Sudeepa Roy

The Relational Model. Database Management Systems

Contents. Database. Information Policy. C03. Entity Relationship Model WKU-IP-C03 Database / Entity Relationship Model

Introduction to Database Design

DBMS. Relational Model. Module Title?

Introduction to Database Design

Database Applications (15-415)

Introduction to Databases

Keys, SQL, and Views CMPSCI 645

MIS Database Systems Entity-Relationship Model.

COMP Instructor: Dimitris Papadias WWW page:

CSE 530A. ER Model to Relational Schema. Washington University Fall 2013

Conceptual Design. The Entity-Relationship (ER) Model

Announcements If you are enrolled to the class, but have not received the from Piazza, please send me an . Recap: Lecture 1.

The Entity-Relationship Model

Translating an ER Diagram to a Relational Schema

Introduction to Database Design

Entity-Relationship Diagrams

The Relational Model

Introduction to Database Design. Dr. Kanda Runapongsa Dept of Computer Engineering Khon Kaen University

Databases Model the Real World. The Entity- Relationship Model. Conceptual Design. Steps in Database Design. ER Model Basics. ER Model Basics (Contd.

Database Applications (15-415)

CSC 261/461 Database Systems Lecture 10

Introduction to Data Management. Lecture #4 E-R Model, Still Going

The Entity-Relationship Model

Conceptual Design. The Entity-Relationship (ER) Model

The Entity-Relationship Model. Overview of Database Design. ER Model Basics. (Ramakrishnan&Gehrke, Chapter 2)

VARDHAMAN COLLEGE OF ENGINEERING Shamshabad , Hyderabad B.Tech. CSE IV Semester (VCE - R11) T P C 3+1* -- 4 (A1511) DATABASE MANAGEMENT SYSTEMS

The Entity-Relationship (ER) Model

The Entity-Relationship (ER) Model 2

ER Model Overview. The Entity-Relationship Model. Database Design Process. ER Model Basics

Database Design. ER Model. Overview. Introduction to Database Design. UVic C SC 370. Database design can be divided in six major steps:

CIS 330: Web-driven Web Applications. Lecture 2: Introduction to ER Modeling

Translation of ER-diagram into Relational Schema. Dr. Sunnie S. Chung CIS430/530

CS/INFO 330 Entity-Relationship Modeling. Announcements. Goals of This Lecture. Mirek Riedewald

Database Management Systems. Chapter 2 Part 2

CS425 Midterm Exam Summer C 2012

CS275 Intro to Databases

Integrity constraints, relationships. CS634 Lecture 2

CSC 261/461 Database Systems Lecture 8. Spring 2018

Overview. Introduction to Database Design. ER Model. Database Design

L3 The Relational Model. Eugene Wu Fall 2018

Introduction to Data Management. Lecture #3 (Conceptual DB Design) Instructor: Chen Li

The Entity-Relationship Model. Steps in Database Design

CS 2451 Database Systems: Relational Data Model

Review: Where have we been?

Transcription:

Relational Databases BORROWED WITH MINOR ADAPTATION FROM PROF. CHRISTOS FALOUTSOS, CMU 15-415/615

Roadmap 3 Introduction Integrity constraints (IC) Enforcing IC Querying Relational Data ER to tables Intro to Views Destroying/altering tables

Why Study the Relational, a.k.a. SQL Model? Most widely used model. Vendors: IBM/Informix, Microsoft, Oracle, Sybase, etc. Legacy systems in older models e.g., IBM s IMS Object-oriented concepts have merged in object-relational model Informix->IBM DB2, Oracle Essentially for up to millions of records (Beyond that, think NoSQL) 4

Relational Database: Definitions Relational database: a set of relations 5 (relation = table) specifically sid name login age gpa 53666 Jones jones@cs 18 3.4 53688 Smith smith@cs 18 3.2 53650 Smith smith@math 19 3.8

Relational Database: Definitions Relation: made up of 2 parts: Schema : specifies name of relation, plus name and type of each column. Instance : a table, with rows and columns. #rows = cardinality #fields = degree / arity sid name login age gpa 53666 Jones jones@cs 18 3.4 53688 Smith smith@cs 18 3.2 53650 Smith smith@math 19 3.8 6

Relational Database: Definitions relation: a set of rows or tuples. 7 all rows are distinct no order among rows (why?) sid name login age gpa 53666 Jones jones@cs 18 3.4 53688 Smith smith@cs 18 3.2 53650 Smith smith@math 19 3.8

Ex: Instance of Students Relation sid name login age gpa 53666 Jones jones@cs 18 3.4 53688 Smith smith@cs 18 3.2 53650 Smith smith@math 19 3.8 8 Cardinality = 3, arity = 5, all rows distinct Q: do values in a column need to be distinct?

SQL - A language for Relational DBs SQL * (a.k.a. Sequel ), standard language Data Definition Language (DDL) create, modify, delete relations specify constraints administer users, security, etc. E.g.: create table student (ssn fixed, name char(20)); * Structured Query Language 9

SQL - A language for Relational DBs Data Manipulation Language (DML) 10 Specify queries to find tuples that satisfy criteria add, modify, remove tuples select * from student ; update takes set grade=4 where name= smith and cid = db ;

SQL Overview CREATE TABLE <name> ( <field> <domain>, ) INSERT INTO <name> (<field names>) VALUES (<field values>) DELETE FROM <name> WHERE <condition> 11

SQL Overview UPDATE <name> SET <field name> = <value> WHERE <condition> SELECT <fields> FROM <name> WHERE <condition> 12

Creating Relations in SQL Creates the Students relation. 13 CREATE TABLE Students (sid CHAR(20), name CHAR(20), login CHAR(10), age INTEGER, gpa FLOAT)

Creating Relations in SQL Creates the Students relation. 14 Note: the type (domain) of each field is specified, and enforced by the DBMS whenever tuples are added or modified. CREATE TABLE Students (sid CHAR(20), name CHAR(20), login CHAR(10), age INTEGER, gpa FLOAT)

Table Creation (continued) 15 Another example: CREATE TABLE Enrolled (sid CHAR(20), cid CHAR(20), grade CHAR(2))

Adding and Deleting Tuples Can insert a single tuple using: 16 INSERT INTO Students (sid, name, login, age, gpa) VALUES ( 53688, Smith, smith@cs, 18, 3.2)

Adding and Deleting Tuples mass -delete (all Smiths!) : 17 DELETE FROM Students S WHERE S.name = Smith

Roadmap 18 Introduction Integrity constraints (IC) Enforcing IC Querying Relational Data ER to tables Intro to Views Destroying/altering tables

Keys Keys help associate tuples in different relations 19 Keys are one form of integrity constraint (IC) Enrolled sid cid grade 53666 15-101 C 53666 18-203 B 53650 15-112 A 53666 15-105 B Students sid name login age gpa 53666 Jones jones@cs 18 3.4 53688 Smith smith@cs 18 3.2 53650 Smith smith@math 19 3.8

(Motivation: ) 20 In flat files, how would you check for duplicate ssn, in a student file? (horror stories, if ssn is duplicate?) sid name login age gpa 53666 Jones jones@cs 18 3.4 53688 Smith smith@cs 18 3.2 53650 Smith smith@math 19 3.8

Keys Keys help associate tuples in different relations 21 Keys are one form of integrity constraint (IC) Enrolled sid cid grade 53666 15-101 C 53666 18-203 B 53650 15-112 A 53666 15-105 B FOREIGN Key Students sid name login age gpa 53666 Jones jones@cs 18 3.4 53688 Smith smith@cs 18 3.2 53650 Smith smith@math 19 3.8 PRIMARY Key

Primary Keys A set of fields is a superkey if: No two distinct tuples can have same values in all key fields A set of fields is a key for a relation if : minimal superkey 22 Student (ssn, name, address) {ssn,name}: superkey {ssn}: superkey, AND key {name}: not superkey

Primary Keys what if >1 key for a relation? 23

Primary Keys what if >1 key for a relation? one of the keys is chosen (by DBA) to be the primary key. Other keys are called candidate keys.. Q: example of >1 superkeys? 24

Primary Keys what if >1 key for a relation? one of the keys is chosen (by DBA) to be the primary key. Other keys are called candidate keys.. Q: example of >1 superkeys? A1: student: {ssn}, {student-id#}, {driving license#, state} A2: Employee: {ssn}, {phone#}, {room#} A3: computer: {mac-address}, {serial#} 25

Primary Keys E.g. sid is a key for Students. What about name? The set {sid, gpa} is a superkey. 26

Syntax: 27 CREATE TABLE Enrolled (sid CHAR(20) cid CHAR(20), grade CHAR(2))

Syntax: 28 CREATE TABLE Enrolled (sid CHAR(20) cid CHAR(20), grade CHAR(2), PRIMARY KEY (sid,cid)) PRIMARY KEY == UNIQUE, NOT NULL

Drill: CREATE TABLE Enrolled (sid CHAR(20) vs. cid CHAR(20), grade CHAR(2), PRIMARY KEY (sid,cid)) CREATE TABLE Enrolled (sid CHAR(20) cid CHAR(20), grade CHAR(2), PRIMARY KEY (sid), UNIQUE (cid, grade)) 29

Drill: CREATE TABLE Enrolled (sid CHAR(20) vs. cid CHAR(20), grade CHAR(2), PRIMARY KEY (sid,cid)) CREATE TABLE Enrolled (sid CHAR(20) cid CHAR(20), grade CHAR(2), PRIMARY KEY (sid), UNIQUE (cid, grade)) 30 Q: what does this mean?

Primary and Candidate Keys in SQL CREATE TABLE Enrolled (sid CHAR(20) vs. cid CHAR(20), grade CHAR(2), PRIMARY KEY (sid,cid)) CREATE TABLE Enrolled (sid CHAR(20) cid CHAR(20), grade CHAR(2), PRIMARY KEY (sid), UNIQUE (cid, grade)) 31 Students can take only one course, and no two students in a course receive the same grade.

Foreign Keys 32 Enrolled sid cid grade 53666 15-101 C 53666 18-203 B 53650 15-112 A 53666 15-105 B Students sid name login age gpa 53666 Jones jones@cs 18 3.4 53688 Smith smith@cs 18 3.2 53650 Smith smith@math 19 3.8

Foreign Keys, Referential Integrity Foreign key : Set of fields `refering to a tuple in another relation. Must correspond to the primary key of the other relation. Like a `logical pointer. foreign key constraints enforce referential integrity (i.e., no dangling references.) 33

Foreign Keys in SQL Example: Only existing students may enroll for courses. 34 sid is a foreign key referring to Students: Enrolled sid cid grade 53666 15-101 C 53666 18-203 B 53650 15-112 A 53666 15-105 B Students sid name login age gpa 53666 Jones jones@cs 18 3.4 53688 Smith smith@cs 18 3.2 53650 Smith smith@math 19 3.8

Foreign Keys in SQL CREATE TABLE Enrolled (sid CHAR(20),cid CHAR(20),grade CHAR(2), PRIMARY KEY (sid,cid), FOREIGN KEY (sid) REFERENCES Students ) 35 Enrolled sid cid grade 53666 15-101 C 53666 18-203 B 53650 15-112 A 53666 15-105 B Students sid name login age gpa 53666 Jones jones@cs 18 3.4 53688 Smith smith@cs 18 3.2 53650 Smith smith@math 19 3.8

Roadmap 36 Introduction Integrity constraints (IC) Enforcing IC Querying Relational Data ER to tables Intro to Views Destroying/altering tables

Enforcing Referential Integrity Subtle issues: 37 What should be done if an Enrolled tuple with a non-existent student id is inserted? Enrolled sid cid grade 53666 15-101 C 53666 18-203 B 53650 15-112 A 53666 15-105 B Students sid name login age gpa 53666 Jones jones@cs 18 3.4 53688 Smith smith@cs 18 3.2 53650 Smith smith@math 19 3.8

Enforcing Referential Integrity Subtle issues: 38 What should be done if an Enrolled tuple with a non-existent student id is inserted? (Reject it!) Enrolled sid cid grade 53666 15-101 C 53666 18-203 B 53650 15-112 A 53666 15-105 B Students sid name login age gpa 53666 Jones jones@cs 18 3.4 53688 Smith smith@cs 18 3.2 53650 Smith smith@math 19 3.8

Enforcing Referential Integrity Subtle issues, cont d: 39 What should be done if a Student s tuple is deleted? Enrolled sid cid grade 53666 15-101 C 53666 18-203 B 53650 15-112 A 53666 15-105 B Students sid name login age gpa 53666 Jones jones@cs 18 3.4 53688 Smith smith@cs 18 3.2 53650 Smith smith@math 19 3.8

Enforcing Referential Integrity Subtle issues, cont d: What should be done if a Students tuple is deleted? Also delete all Enrolled tuples that refer to it? Disallow deletion of a Students tuple that is referred to? Set sid in Enrolled tuples that refer to it to a default sid? (In SQL, also: Set sid in Enrolled tuples that refer to it to a special value null, denoting `unknown or `inapplicable.) 40

Enforcing Referential Integrity Similar issues arise if primary key of Students tuple is updated. 41

Integrity Constraints (ICs) IC: condition that must be true for any instance of the database; e.g., domain constraints. ICs are specified when schema is defined. ICs are checked when relations are modified. 42

Integrity Constraints (ICs) A legal instance of a relation: satisfies all specified ICs. DBMS should not allow illegal instances. we prefer that ICs are enforced by DBMS (as opposed to?) Blocks data entry errors, too! 43

Where do ICs Come From? 44

Where do ICs Come From? the application! 45

Where do ICs Come From? Subtle point: We can check a database instance to see if an IC is violated, but we can NEVER infer that an IC is true by looking at an instance. 46 An IC is a statement about all possible instances! Eg., name is not a key, but the assertion that sid is a key is given to us. sid name login age gpa 53666 Jones jones@cs 18 3.4 53688 Smith smith@cs 18 3.2 53650 Smith smith@math 19 3.8

Where do ICs Come From? Key and foreign key ICs are the most common; more general ICs supported too. 47

Roadmap 48 Introduction Integrity constraints (IC) Enforcing IC Querying Relational Data ER to tables Intro to Views Destroying/altering tables

ER to tables outline: 49 strong entities weak entities (binary) relationships 1-to-1, 1-to-many, etc total/partial participation ternary relationships ISA-hierarchies aggregation

Logical DB Design: ER to Relational (strong) entity sets to tables. 50 ssn name lot Employees

Logical DB Design: ER to Relational (strong) entity sets to tables. ssn name Employees lot Ssn Name Lot 123-22-6666 Attishoo 48 233-31-5363 Smiley 22 131-24-3650 Smethurst 35 51 CREATE TABLE Employees (ssn CHAR(11), name CHAR(20), lot INTEGER, PRIMARY KEY (ssn))

Relationship Sets to Tables Many-to-many: 52 name since dname ssn lot did budget Employees Works_In Departments

Relationship Sets to Tables Many-to-many: 53 name since dname ssn lot did budget Employees Works_In Departments Ssn Name Lot 123-22-6666 Attishoo 48 233-31-5363 Smiley 22 131-24-3650 Smethurst 35 Ssn did since 123-22-6666 51 1/1/91 123-22-6666 56 3/3/93 233-31-5363 51 2/2/92

Relationship Sets to Tables key of many-to-many relationships: Keys from participating entity sets (as foreign keys). CREATE TABLE Works_In( ssn CHAR(11), did INTEGER, since DATE, PRIMARY KEY (ssn, did), FOREIGN KEY (ssn) REFERENCES Employees, FOREIGN KEY (did) REFERENCES Departments) 54 Ssn did since 123-22-6666 51 1/1/91 123-22-6666 56 3/3/93 233-31-5363 51 2/2/92

Review: Key Constraints in ER 1-to-many: 55 name since dname ssn lot did budget Employees Manages Departments

(Reminder: Key Constraints in ER) 56 1-to-1 1-to Many Many-to-1 Many-to-Many

ER to tables - summary of basics 57 strong entities: key -> primary key (binary) relationships: get keys from all participating entities - pr. key: 1-to-1 -> either key (other: cand. key ) 1-to-N -> the key of the N part M-to-N -> both keys

A subtle point (1-to-many) 58 name since dname ssn lot did budget Employees Manages Departments

Translating ER with Key Constraints name since dname 59 ssn lot did budget Employees Manages Departments CREATE TABLE Manages( ssn CHAR(11), did INTEGER, since DATE, PRIMARY KEY (did), FOREIGN KEY (ssn) REFERENCES Employees, FOREIGN KEY (did) REFERENCES Departments) CREATE TABLE Departments( did INTEGER), dname CHAR(20), budget REAL, PRIMARY KEY (did), ) Two-table-solution

Translating ER with Key Constraints name since dname 60 ssn lot did budget Employees Manages Departments CREATE TABLE Dept_Mgr( ssn CHAR(11), did INTEGER, since DATE, dname CHAR(20), budget REAL, PRIMARY KEY (did), FOREIGN KEY (ssn) REFERENCES Employees) Single-table-solution

Translating ER with Key Constraints name since dname 61 ssn lot did budget Employees Manages Departments CREATE TABLE Manages( ssn CHAR(11), did INTEGER, since DATE, Vs. PRIMARY KEY (did), FOREIGN KEY (ssn) REFERENCES Employees, FOREIGN KEY (did) REFERENCES Departments) CREATE TABLE Dept_Mgr( ssn CHAR(11), did INTEGER, since DATE, dname CHAR(20), budget REAL, PRIMARY KEY (did), FOREIGN KEY (ssn) REFERENCES Employees)

Pros and cons? 62

Drill: What if the toy department has no manager (yet)? 63 CREATE TABLE Dept_Mgr( did INTEGER, dname CHAR(20), budget REAL, ssn CHAR(11), since DATE, PRIMARY KEY (did), FOREIGN KEY (ssn) REFERENCES Employees)

Drill: ssn What if the toy department has no manager (yet)? A: one-table solution can not handle that. (ie., helps enforce thick arrow see did INTEGER, next) since name Employees lot Manages did dname Departments budget CREATE TABLE Dept_Mgr( dname CHAR(20), budget REAL, ssn CHAR(11), since DATE, PRIMARY KEY (did), FOREIGN KEY (ssn) REFERENCES Employees) 64

Rules: Thick arrow -> one-table solution Thin arrow -> two-table solution (More rules: next) 65 name ssn lot Employees since Manages dname did budget Departments CREATE TABLE Dept_Mgr( did INTEGER, dname CHAR(20), budget REAL, ssn CHAR(11), since DATE, PRIMARY KEY (did), FOREIGN KEY (ssn) REFERENCES Employees)

ER to tables outline: 66 strong entities weak entities (binary) relationships 1-to-1, 1-to-many, etc total/partial participation ternary relationships ISA-hierarchies aggregation

Review: Participation Constraints Does every department have a manager? If so, this is a participation constraint: the participation of Departments in Manages is said to be total (vs. partial). Every did value in Departments table must appear in a row of the Manages table (with a non-null ssn value!) 67 ssn name lot since did dname budget Employees Manages Departments Works_In since

Participation Constraints in SQL We can capture participation constraints involving one entity set in a binary relationship, but little else (without resorting to CHECK constraints). 68 CREATE TABLE Dept_Mgr( did INTEGER, dname CHAR(20), budget REAL, ssn CHAR(11) NOT NULL, since DATE, PRIMARY KEY (did), FOREIGN KEY (ssn) REFERENCES Employees, ON DELETE NO ACTION)

Participation Constraints in SQL Total participation ( no action -> do NOT do the delete) Ie, a department MUST have a nanager 69 CREATE TABLE Dept_Mgr( did INTEGER, dname CHAR(20), budget REAL, ssn CHAR(11) NOT NULL, since DATE, PRIMARY KEY (did), FOREIGN KEY (ssn) REFERENCES Employees, ON DELETE NO ACTION)

Participation Constraints in SQL Partial partipation, ie, a department may be headless 70 CREATE TABLE Dept_Mgr( did INTEGER, dname CHAR(20), budget REAL, ssn CHAR(11) NOT NULL, since DATE, PRIMARY KEY (did), FOREIGN KEY (ssn) REFERENCES Employees, ON DELETE SET NULL)

Participation Constraints in SQL Partial partipation, ie, a department may be headless OR (better): use the two-table solution 71 CREATE TABLE Dept_Mgr( did INTEGER, dname CHAR(20), budget REAL, ssn CHAR(11) NOT NULL, since DATE, PRIMARY KEY (did), FOREIGN KEY (ssn) REFERENCES Employees, ON DELETE SET NULL)

ER to tables outline: 72 strong entities weak entities (binary) relationships 1-to-1, 1-to-many, etc total/partial participation ternary relationships ISA-hierarchies aggregation

Review: Weak Entities A weak entity can be identified uniquely only by considering the primary key of another (owner) entity. Owner entity set and weak entity set must participate in a one-to-many relationship set (1 owner, many weak entities). Weak entity set must have total participation in this identifying relationship set. 73 ssn name lot cost dname age Employees Policy Dependents

Review: Weak Entities 74 How to turn Dependents into a table? ssn name lot cost dname age Employees Policy Dependents

Translating Weak Entity Sets Weak entity set and identifying relationship set are translated into a single table (== total participation ) 75 CREATE TABLE Dep_Policy ( dname CHAR(20), age INTEGER, cost REAL, ssn CHAR(11) NOT NULL, PRIMARY KEY (dname, ssn), FOREIGN KEY (ssn) REFERENCES Employees, ON DELETE CASCADE)

Translating Weak Entity Sets Weak entity set and identifying relationship set are translated into a single table. When the owner entity is deleted, all owned weak entities must also be deleted (-> CASCADE ) 76 CREATE TABLE Dep_Policy ( dname CHAR(20), age INTEGER, cost REAL, ssn CHAR(11) NOT NULL, PRIMARY KEY (dname, ssn), FOREIGN KEY (ssn) REFERENCES Employees, ON DELETE CASCADE)

ER to tables outline: 77 strong entities weak entities (binary) relationships 1-to-1, 1-to-many, etc total/partial participation ternary relationships ISA-hierarchies aggregation

ssn name lot Review: ISA Hierarchies Employees 78 hourly_wages hours_worked ISA contractid Hourly_Emps Contract_Emps Overlap constraints: Can Joe be an Hourly_Emps as well as a Contract_Emps entity? (Allowed/disallowed) Covering constraints: Does every Employees entity also have to be an Hourly_Emps or a Contract_Emps entity? (Yes/no)

Drill: 79 What would you do? ssn name lot Employees hourly_wages hours_worked ISA contractid Hourly_Emps Contract_Emps

Translating ISA Hierarchies to Relations General approach: 3 relations: Employees, Hourly_Emps and Contract_Emps. how many times do we record an employee? what to do on deletion? how to retrieve EMP (ssn, all name, info about lot) an employee? 80 H_EMP(ssn, h_wg, h_wk) CONTR(ssn, cid)

Translating ISA Hierarchies to Relations Alternative: Just Hourly_Emps and Contract_Emps. Hourly_Emps: ssn, name, lot, hourly_wages, hours_worked. Each employee must be in one of these two subclasses. EMP (ssn, name, lot) 81 H_EMP(ssn, h_wg, h_wk, name, lot) CONTR(ssn, cid, name, lot) Notice: black is gone!

Not in book why NOT 1 table + nulls? 82 ssn name h_wg cid all hourly contractors

Not in book why NOT 1 table + nulls? 83 TYPE ssn name h_wg cid all hourly contractors

ER to tables outline: 84 strong entities weak entities (binary) relationships 1-to-1, 1-to-many, etc total/partial participation ternary relationships ISA-hierarchies aggregation

Ternary relationships; aggregation 85 rare keep keys of all participating entity sets (or: avoid such situations: ) break into 2-way relationships or add an auto-generated key

Roadmap 86 Introduction Integrity constraints (IC) Enforcing IC Querying Relational Data ER to tables Intro to Views Destroying/altering tables

Views 87 Virtual tables CREATE VIEW YoungActiveStudents(name,grade) AS SELECT S.name, E.grade FROM Students S, Enrolled E WHERE S.sid=E.sid and S.age<21 DROP VIEW

Views and Security 88 DBA: grants authorization to a view for a user user can only see the view - nothing else

Roadmap 89 Introduction Integrity constraints (IC) Enforcing IC Querying Relational Data ER to tables Intro to Views Destroying/altering tables

Table changes 90 DROP TABLE ALTER TABLE, e.g. ALTER TABLE students ADD COLUMN maiden-name CHAR(10)

Relational Model: Summary A tabular representation of data. Simple and intuitive; widely used Integrity constraints can be specified by the DBA, based on customer specs. DBMS checks for violations. Two important ICs: primary and foreign keys also: not null, unique In addition, we always have domain constraints. Mapping from ER to Relational is (fairly) straightforward: 91

ER to tables - summary of basics 92 strong entities: key -> primary key (binary) relationships: get keys from all participating entities - pr. key: 1:1 -> either key 1:N -> the key of the N part M:N -> both keys weak entities: strong key + partial key -> primary key... ON DELETE CASCADE

ER to tables - summary of advanced 93 total/partial participation: NOT NULL; ON DELETE NO ACTION ternary relationships: get keys from all; decide which one(s) -> prim. key aggregation: like relationships ISA: 2 tables ( total coverage ) 3 tables (most general) ISA