COP 5725 Fall 2012 Database Management Systems

  COP 5725 Fall 2012 Database Management

Systems

  University of Florida, CI SE Department Prof. Daisy Zhe Wang

  The Relational Data Model

  Tables, Schemas Convert from E/ R to Relations

  Data Definition Language (DDL)

  Why Study the Relational Model?

• Most widely used model (Edgar F. Codd paper 1969, Turing award 1981)

  

Vendors: I BM, I nformix, Microsoft, Oracle,

• – Sybase, etc.

  Often matches how we think about •

  data. (e.g., translated from E/ R model)

• Based on Set Theory: solid mathematical foundation

  Relational Database: Definitions Relational database : a set of relations • Relation: made up of 2 parts: •

  : a , with rows and columns.

  I nstance table

• – vs.

  cardinality degree / arity.

  : specifies name of relation, plus Schema

• – name and type of each column.

• • E.G. Students( sid : string, name : string, login :

  string, age : integer, gpa : re
• Can think of a relation as a set of rows or tuples (i.e., all rows are distinct).

  Example I nstance of Students Relation sid name login age gpa 53666 Jones jones@cs

  18

  3.4 53688 Smith smith@eecs

  18

  3.2 53650 Smith smith@math

  19

  3.8 

  Cardinality = 3, degree = 5, all rows distinct 

  Do all columns in a relation instance have to be distinct?

  Relational Query Languages

• A major strength of the relational model: supports simple, powerful

  querying of data with precise semantics

• Queries can be written intuitively, and the DBMS is responsible for efficient evaluation.

  The SQL Query Language

• Developed by I BM (system R) in the

  1970s

• Need for a standard since it is used by many vendors
• Standards:

  SQL-86

• – SQL-89 (minor revision)
• – SQL-92 (major revision)
>– SQL-99 (major extensions, current
• –

  The SQL Query Language

• To find all 18 year old students, we can write:

  sid name login age gpa

• SELECT

  53666 Jones jones@cs

  18

  3.4 FROM

  Students S

  WHERE 53688 Smith smith@ee 18

  3.2 S.age=18

• To find just names and logins, replace the first line:

  SELECT S.name, S.login ….

• What does the following query compute?

  53831 Reggae203 B 53650 Topology112 A 53666 History105 B

  19

  3.2 53650 Smith smith@math

  18

  3.4 53688 Smith smith@eecs

  18

  sid name login age gpa 53666 Jones jones@cs

  Given the following instances of Enrolled and Students: we get:

  S.name E.cid Smith Topology112 sid cid grade 53831 Carnatic101 C

  Querying Multiple Relations

  E.grade=“A”

  AND

  S.sid=E.sid

  WHERE

  Students S, Enrolled E

  FROM

  S.name, E.cid

  SELECT

  3.8

  

Creating (Declaring) a Relation

• Simplest form is:

  CREATE TABLE < name> ( < list of elements>

  );

• To delete a relation:

  DROP TABLE < name> ; Elements of Table Declarations

• Most basic element: an attribute and its type.
• The most common types are: – I NT or I NTEGER (synonyms).
• – REAL or FLOAT (synonyms).
• – CHAR( ) = fixed-length string of

  n n characters.

• – VARCHAR( ) = variable-length string of

  n up to characters. n Example: Create Table CREATE TABLE Sells ( bar CHAR(20), beer

  VARCHAR(20), price REAL ); More Examples CREATE TABLE Students CHAR(20)

  (sid: ,

  CHAR(20)

  name: ,

  CHAR(10),

  login:

  INTEGER

  age: ,

  REAL

  gpa: )

  CREATE TABLE Enrolled CHAR(20)

  (sid: ,

  CHAR(20)

  cid: ,

  CHAR

  grade: (2)) Dates and Times • DATE and TI ME are types in SQL.

• The form of a date value is:

  DATE ’yyyy-mm-dd’

  DATE ’2004-09-30’

• – Example : for Sept.

  30, 2004. Times as Values

• The form of a time value is:

  TI ME ’hh: mm: ss’ with an optional decimal point and fractions of a second following.

  TIME ’15:30:02.5’

• – Example :

  = two and a half seconds after 3: 30PM. Adding Attributes

• We may add a new attribute (“column”) to a relation schema by:

  ALTER TABLE < name> ADD < attribute declaration> ;

• Example :

  ALTER TABLE Bars ADD phone CHAR(16) DEFAULT ’unlisted’;

  Deleting Attributes

• Remove an attribute from a relation schema by:

  ALTER TABLE < name> DROP < attribute> ;

• Example: we don’t really need the license attribute for bars:

  ALTER TABLE Bars DROP license;

  Adding and Deleting Tuples

• Can insert a single tuple using:

INSERT INTO

  Students (sid, name, login, age, gpa)

  VALUES

  (53688, ‘Smith’, ‘smith@ee’, 18, 3.2)

• Can delete all tuples satisfying some condition (e.g., name = Smith):

  DELETE FROM

  Students S

  WHERE

  S.name = ‘Smith’  Powerful variants of these commands are available; more later! I ntegrity Constraints (I Cs)

• I C: condition that must be true for any instance of the database; e.g., domain constraints. ^– I Cs are specified when schema is defined. ^– I Cs are checked when relations are modified.
• A legal instance of a relation is one that satisfies all specified I Cs. ^– DBMS should not allow illegal instances.
• stored data in DB is more faithful to real-world meaning. ^–

  Avoids data entry errors, too!

  Primary Key Constraints

• A set of fields is a key for a relation if :

  1. No two distinct tuples can have same values in all key fields, and

2. This is not true for any subset of the key.

  Part 2 false? A . superkey

• – I f there’s > 1 key for a relation, one of the
• – keys is chosen (by DBA) to be the

  primary . key

• E.g., Students (name, sid, gpa) key?

  Superkey? Primary key?

  Declaring Key Constraints

• An attribute or list of attributes may be declared PRI MARY KEY or UNI QUE.
• Either says the attribute(s) so declared functionally determine all the attributes of the relation schema.

  CREATE TABLE Beers ( name CHAR(20) UNIQUE,

manf CHAR(20)

);

  

Declaring Single-Attribute Keys

• Place PRI MARY KEY or UNI QUE after the type in the declaration of the attribute.
• Example:

  Declaring Multi-attribute Keys

• • A key declaration can also be another element in

  the list of elements of a CREATE TABLE statement.
• The bar and beer together are the key for Sells:

  CREATE TABLE Sells ( bar CHAR(20), beer

  VARCHAR(20), price REAL, PRIMARY KEY (bar, beer) ); PRI MARY KEY Vs. UNI QUE

  Standard SQL requires these • distinctions:

1. There can be only one PRI MARY KEY for a relation, but several UNI QUE attributes.

  2. No attribute of a PRI MARY KEY can ever be NULL in any tuple. But attributes declared UNI QUE may have NULL’s, and there may be several tuples with NULL.

  

PRI MARY KEY Vs. UNI QUE (I I )

• The SQL standard allows DBMS implementers to make their own

  distinctions between PRI MARY KEY and UNI QUE.

• – Example: some DBMS might automatically create an

  index (data structure to speed search) in response to PRI MARY KEY, but not UNI QUE. Some Other Declarations for Attributes

  1. NOT NULL means that the value for this attribute may never be NULL.

  2. DEFAULT < value> says that if there is no specific value known for this attribute’s component in some tuple, use the stated < value> .

  Example: Default Values CREATE TABLE Drinkers ( name CHAR(30) PRIMARY KEY, addr CHAR(50) DEFAULT ’123 Sesame St.’, phone CHAR(16) );

  Effect of Defaults --- (1)

• Suppose we insert the fact that Sally is a drinker, but we know neither her address nor her phone.
• An I NSERT with a partial list of attributes makes the insertion possible:

  INSERT INTO Drinkers(name)

  VALUES(’Sally’); Effect of Defaults --- (2)

• But what tuple appears in Drinkers?

  name addr phone

  Sally 123 Sesame St NULL

• What if we had declared phone NOT

  NULL?

  Make sense? Be careful specifying keys…

PRIMARY KEY

  CHAR

  (cid, grade) )

  UNIQUE

  (sid),

  (2),

  CHAR

  , grade

  CHAR(20)

  (20) cid

  Enrolled (sid

  CREATE TABLE

  CREATE TABLE

  (sid,cid) )

  (2),

  CHAR

  , grade

  CHAR(20)

  (20) cid

  CHAR

  Enrolled (sid

PRIMARY KEY

  Foreign Keys, Referential I ntegrity Foreign key : Set of fields in one relation •

  that is used to ` refer’ to a tuple in another relation.

  Enrolled(sid: string, cid: string, grade: string) referential integrity

• is achieved, if all foreign key constraints are enforced

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 ) sid name login age gpa 53666 Jones jones@cs

  18

  3.4 53688 Smith smith@eecs

  18

  3.2 53650 Smith smith@math

  19

  3.8 sid cid grade 53666 Carnatic101 C

  53666 Reggae203 B 53650 Topology112 A 53666 History105 B

  Enrolled Students

  Enforcing Referential I ntegrity

• Consider Students and Enrolled;
• What should be done if an Enrolled tuple with a non-existent student id is inserted?

  ( Reject it! )

  

Enforcing Referential I ntegrity (I I )

• What should be done if a Students tuple is deleted? 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 or

  default sid null

  What if primary key of Students tuple is

• updated.

  Referential I ntegrity in SQL

• SQL/ 92 and SQL: 1999

  CREATE TABLE

  Enrolled

  support 4 options on CHAR

  (sid (20), deletes and updates.

  CHAR(20)

  cid ,

  CHAR

  grade (2), ^–

  NO ACTI ON (Default)

PRIMARY KEY

  (sid,cid), ^–

  CASCADE

FOREIGN KEY

  (sid)

  REFERENCES

  Students

• ^– SET NULL SET DEFAULT

  / ON DELETE CASCADE ON UPDATE SET DEFAULT

  ) Where do I Cs Come From?

• Key and foreign key I Cs are the most common; more general I Cs supported too.
• From the semantics of the real-world enterprise modeled in DB (e.g., general functional dependencies in Chap 19)

  

Logical DB Design: ER to Relational

• Entity sets to tables:

  CREATE TABLE

  Employees

  CHAR

  (ssn (11),

  name ssn lot

  CHAR

  name (20),

  INTEGER

  lot ,

PRIMARY KEY

  (ssn) ) Employees Relationship Sets to Tables

• I n translating a relationship

  CREATE TABLE

  Works_In(

  set to a relation, attributes CHAR

  ssn (11),

  of the relation must include:

  INTEGER

  did ,

• – PRIMARY KEY

  Keys for each DATE

  since ,

  (ssn, did), participating entity

FOREIGN KEY

  (ssn) set (as foreign keys).

  REFERENCES Employees,

• This set of attributes

FOREIGN KEY

  (did) forms a superkey for

  REFERENCES Departments ) the relation.

  All descriptive

• – attributes.

  Combining Relations Many-One Relationships

  OK to combine into one relation: •

1. The relation for an entity-set

  E

  2. The relations for many-one relationships of which is the “many.” E

  Example: Drinkers(name, addr) and •

  Favorite(drinker, beer) combine to make Drinker1(name, addr, favBeer) .

  Another Example _{Employees Manages Departments CREATE TABLE Manages( CHAR(11)} CREATE TABLE Dept( did INTEGER, ssn , dname CHAR(20), did ^{INTEGER ,} _DATE budget REAL, since , _{PRIMARY KEY (did), PRIMARY KEY FOREIGN KEY REFERENCES FOREIGN KEY (ssn) REFERENCES Employees,} (did))

  (did) Departments) CREATE TABLE

  Dept_Mgr( did INTEGER, dname CHAR(20), budget REAL,

_CHAR(11) ssn ,

_{DATE PRIMARY KEY (did),} since , FOREIGN KEY (ssn) REFERENCES Employees ) name addr beer Sally 123 Maple Bud Sally 123 Maple Miller

  Redundancy

  Combining Relations Many-Many Relationships

• Combining Drinkers with Likes would be a mistake. I t leads to redundancy, as:

  

Key Constraints on relationships

Translation to relational model?

  1-to-1 1-to Many Many-to-1 Many-to-Many

  Weak Entity Sets Example

  name name billTo Logins At Hosts location

  Hosts(hostName, location) Logins(loginName, hostName, billTo) At(loginName, hostName)

  At becomes part of Logins

  Handling Weak Entity Sets

• Relation for a weak entity set must include attributes for its complete key (including those belonging to other entity sets), as well as its own, nonkey attributes.
• A supporting relationship is redundant and yields no relation (unless it has attributes).

  

Review: Participation Constraints

• Does every department have a manager?

  I f so, this is a : the participation constraint

• – participation of Departments in Manages is said to be (vs. ) .

  total partial

• Every did value in Departments table must appear in a row of the Manages table (with a non-null ssn value!) _{ssn name name lot}

  since since _{did did budget budget dname dname Employees Manages} Departments Participation Constraints in SQL CREATE TABLE

  Dept_Mgr(

  INTEGER, did

  CHAR(20) dname ,

  REAL budget ,

CHAR(11) NOT NULL

  ssn ,

  DATE since ,

PRIMARY KEY

  (did),

FOREIGN KEY REFERENCES

  (ssn) Employees,

ON DELETE NO ACTION

  ) Review: Weak Entities weak entity

• A can be identified uniquely only by considering the primary key of another ( supporting/ owner ) entity.
_ssn name _{lot cost pname age Employees} Policy Dependents

  Translating Weak Entity Sets

• Weak entity set and identifying relationship set are translated into a single table.

  CREATE TABLE

  Dep_Policy (

  CHAR(20) pname ,

  INTEGER age ,

  REAL cost ,

CHAR(11) NOT NULL

  ssn

,

PRIMARY KEY

  (pname, ssn),

FOREIGN KEY REFERENCES

  (ssn) Employees,

ON DELETE CASCADE

  ) Subclasses: Three Approaches

  1. Object-oriented : One relation per subset of subclasses, with all relevant attributes.

  2. Use nulls

  : One relation; entities have NULL in attributes that don’t belong to them.

  3. E/ R style : One relation for each subclass: Key attribute(s). – Attributes of that subclass. –

  Example

  Beers Ales isa name manf color Object-Oriented

  name manf Bud Anheuser-Busch

  Beers name manf color Summerbrew Pete’s dark

  Ales

  Q1: “find the color of ales made by Pete’s.” Q2: “find all beers (including ales) made by Pete’s” E/ R Style

  name manf Bud Anheuser-Busch Summerbrew Pete’s

  Beers name color Summerbrew dark

  Ales

  Q1: “find the color of ales made by Pete’s.” Q2: “find all beers (including ales) made by Pete’s”

  Using Nulls

  name manf color Bud Anheuser-Busch NULL Summerbrew Pete’s dark

  Beers

  Q1: “find the color of ales made by Pete’s.” Q2: “find all beers (including ales) made by Pete’s” Saves space unless there are lots of attributes that are A Complicated Example CREATE TABLE

  Policies (

  policyid

  INTEGER , cost

  REAL , ssn

  CHAR(11) ,

  PRIMARY KEY (policyid).

FOREIGN KEY

  (ssn) REFERENCES

  Employees,

ON DELETE CASCADE

  ) ^{Beneficiary age pname Dependents policyid cost Policies Purchaser name Employees ssn lot} Binary vs. Ternary Relationships (Contd.) CREATE TABLE

  Dependents (

  pname CHAR(20)

  , age

  INTEGER , policyid

  INTEGER NOT NULL ,

  PRIMARY KEY (pname, policyid).

FOREIGN KEY

  (policyid)

REFERENCES

  Policies,

ON DELETE CASCADE

  ) ^{Beneficiary age pname Dependents policyid cost Policies Purchaser name Employees ssn lot} Views

• A view is just a relation, but we store a definition , rather than a set of tuples.

  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 command.

  Views can be dropped using the

   DROP TABLE

  How to handle

  if there’s a view on the table?

• DROP TABLE

  command has options to let the user specify this. Views and Security

• Views can be used to present necessary information (or a summary), while hiding details in underlying relation(s).

  

Given YoungStudents, but not Students or

• –

  Enrolled, we can find students s who have

  are enrolled, but not the of the

  cid’s courses they are enrolled in. Relational Model: Summary • A tabular representation of data.

• Simple and intuitive, currently the most widely used.
• I ntegrity constraints can be specified by the DBA, based on application semantics. DBMS checks for violations. ^–

  Two important I Cs: primary and foreign keys ^– I n addition, we always have domain constraints.

• Powerful and natural query languages exist.
• Rules to translate ER to relational model

  Additional Exercise

  Additional Exercise (I I ) Draw the ER diagram that describes the problem domain. Be sure to identify the keys and the weak entities. Use the I s-A relationship if appropriate as well.

  Additional Exercise (I I I ) Convert the ER model to a relational model. I dentify as many • constraints as possible for your model. I ndicate the method for translating the I s-A relationships if used.