CSC 3800 Database Management Systems
Download
1 / 50

CSC 3800 Database Management Systems - PowerPoint PPT Presentation


  • 102 Views
  • Updated On :

CSC 3800 Database Management Systems. Fall 2009. Time: 1:30 to 2:20. Meeting Days: MWF. Location: Oxendine 1237B. Textbook : Databases Illuminated , Author: Catherine M. Ricardo, 2004, Jones & Bartlett Publishers. Chapter 4 The Relational Model. Dr. Chuck Lillie.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'CSC 3800 Database Management Systems' - bryce


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Slide1 l.jpg

CSC 3800 Database Management Systems

Fall 2009

Time: 1:30 to 2:20

Meeting Days: MWF

Location: Oxendine 1237B

Textbook: Databases Illuminated, Author: Catherine M. Ricardo, 2004, Jones & Bartlett Publishers

Chapter 4

The Relational Model

Dr. Chuck Lillie


History of relational model l.jpg
History of Relational Model

  • 1970 Paper by E.F. Codd “A Relational Model of Data for Large Shared Data Banks” proposed relational model

  • System R, prototype developed at IBM Research Lab at San Jose, California – late 1970s

  • Peterlee Test Vehicle, IBM UK Scientific Lab

  • INGRES, University of California at Berkeley

  • System R results used in developing DB2 from IBM and also Oracle

  • Early microcomputer based DBMSs were relational - dBase, R;base, Paradox

  • Microsoft’s Access, now most popular microcomputer-based DBMS, is relational

  • Oracle, DB2, Informix, Sybase, Microsoft’s SQL Server, MySQL - most popular enterprise DBMSs, all relational


Advantages of relational model l.jpg
Advantages of Relational Model

  • Based on mathematical notion of relation

  • Can use power of mathematical abstraction

  • Can develop body of results using theorem and proof method of mathematics – results then apply to many different applications

  • Can use expressive, exact mathematical notation

  • Theory provides tools for improving design

  • Basic structure is simple, easy to understand

  • Separates logical from physical level

  • Data operations easy to express, using a few powerful commands

  • Operations do not require user to know storage structures used


Data structures l.jpg
Data Structures

  • Relations are represented physically as tables

  • Tables are related to one another

  • Table holds information about objects

  • Rows (tuples) correspond to individual records

  • Columns correspond to attributes

  • A column contains values from one domain

  • Domains consist of atomic values


Properties of tables l.jpg
Properties of Tables

  • Each cell contains at most one value

  • Each column has a distinct name, the name of the attribute it represents

  • Values in a column all come from the same domain

  • Each tuple is distinct – no duplicate tuples

  • Order of tuples is immaterial


Example of relational model l.jpg
Example of Relational Model

  • See Figure 4.1

  • Student table tells facts about students

  • Faculty table shows facts about faculty

  • Class table shows facts about classes, including what faculty member teaches each

  • Enroll table relates students to classes


Simple university database l.jpg
Simple University Database

Figure 4.1(c) The Class Table

Figure 4.1(a) The Student Table

Figure 4.1(b) The Faculty Table

Figure 4.1(d) The Enroll Table

  • Each row of Student table represents one student

  • Each row of Class table represents one class

  • Each row of Enroll represents relationship between one student and one class


Mathematical relations l.jpg
Mathematical Relations

  • For two sets D1 and D2, the Cartesian product,

    D1 XD2 , is the set of all ordered pairs in which the first element is from D1 and the second is from D2

  • A relation is any subset of the Cartesian product

  • Could form Cartesian product of 3 sets; relation is any subset of the ordered triples so formed

  • Could extend to n sets, using n-tuples


Database relations l.jpg
Database Relations

  • A relation schema, R, is a set of attributes A1, A2,…,An with their domains D1, D2,…Dn

  • A relation r on relation schema R is a set of mappings from the attributes to their domains

  • r is a set of n-tuples (A1:d1, A2:d2, …, An:dn) such that d1ε D1, d2εD2 , …, dnεDn

  • In a table to represent the relation, list the Ai as column headings, and let the (d1, d2, …dn) become the n-tuples, the rows of the table


Properties of relations l.jpg
Properties of Relations

  • Degree: the number of attributes

    • 2 attributes - binary; 3 attributes - ternary; n attributes - n-ary

    • A property of the intension – does not change

  • Cardinality: the number of tuples

    • Changes as tuples are added or deleted

    • A property of the extension – changes often

  • Keys

  • Integrity constraints


Relation keys l.jpg
Relation Keys

  • Relations never have duplicate tuples, so you can always tell tuples apart; implies there is always a key (which may be a composite of all attributes, in worst case)

  • Superkey: set of attributes that uniquely identifies tuples

  • Candidate key: superkey such that no proper subset of itself is also a superkey (i.e. it has no unnecessary attributes)

  • Primary key: candidate key chosen for unique identification of tuples

  • Cannot verify a key by looking at an instance; need to consider semantic information to ensure uniqueness

  • A foreign key is an attribute or combination of attributes that is the primary key of some relation (called its home relation)


Integrity constraints l.jpg
Integrity Constraints

  • Integrity: correctness and internal consistency

  • Integrity constraints are rules or restrictions that apply to all instances of the database

  • Enforcing integrity constraints ensures only legal states of the database are created

  • Types of constraints

    • Domain constraint - limits set of values for attribute

    • Entity integrity: no attribute of a primary key can have a null value

    • Referential integrity: each foreign key value must match the primary key value of some tuple in its home relation or be completely null.

    • General constraints or business rules: may be expressed as table constraints or assertions


Representing relational database schemas l.jpg
Representing Relational Database Schemas

  • Can have any number of relation schemas

  • For each relation schema list name of relation followed by list of attributes in parentheses

  • Underline primary key in each relation schema

  • Indicate foreign keys (We use italics – arrows are best)

  • Database schema actually includes domains, views, character sets, constraints, stored procedures, authorizations, etc.

  • Example: University database schema

    Student (stuId, lastName, firstName, major, credits)

    Class (classNumber, facId, schedule, room)

    Faculty (facId, name, department, rank)

    Enroll(stuId,classNumber,grade)


Types of relational data manipulation languages l.jpg
Types of Relational Data Manipulation Languages

  • Procedural: proscriptive - user tells system how to manipulate data - e.g. relational algebra

  • Non-procedural: declarative - user tells what data is needed, not how to get it - e.g. relational calculus, SQL

  • Other types:

    • Graphical: user provides illustration of data needed e.g. Query By Example(QBE)

    • Fourth-generation: 4GL uses user-friendly environment to generate custom applications

    • Natural language: 5GL accepts restricted version of English or other natural language


Relational algebra l.jpg
Relational Algebra

  • Theoretical language with operators that apply to one or two relations to produce another relation

  • Both operands and results are tables

  • Can assign name to resulting table (rename)

  • SELECT, PROJECT, JOIN allow many data retrieval operations


Select operation l.jpg
SELECT Operation

  • Applied to a single table, returns rows that meet a specified predicate, copying them to new table

  • Returns a horizontal subset of original table

    SELECT tableName WHERE condition [GIVING newTableName]

    Symbolically, [newTableName = ] predicate (table-name)

  • Predicate is called theta-condition, as in (table-name)

  • Result table is horizontal subset of operand

  • Predicate can have operators <, <=, , =, =, <>, (AND), (OR),  (NOT)


Select example l.jpg
SELECT Example

SELECT Student WHERE stuId = ‘S1013’ GIVING Result

Result =  STDID=‘S1013’ (Student)


Select example18 l.jpg
SELECT Example

SELECT Class WHERE room = ‘H225’ GIVING Answer

Answer=  ROOM=‘H225’ (Class)


Select example19 l.jpg
SELECT Example

SELECT Student WHERE major= ‘Math’ AND credits > 30

 major=‘Math’ ^ credits > 30 (Student)


Project operator l.jpg
PROJECT Operator

  • Operates on single table

  • Returns unique values in a column or combination of columns

    PROJECT tableName OVER (colName,...,colName) [GIVING newTableName]

    Symbolically

    [newTableName =] colName,...,colName (tableName)

  • Can compose SELECT and PROJECT, using result of first as argument for second


Project example l.jpg
PROJECT Example

PROJECT Student OVER major GIVING Temp

Temp =  major (Student)


Project example22 l.jpg
PROJECT Example

PROJECT Class OVER (facId, room)

 facId, room (Class)


Project and select combination example l.jpg
PROJECT and SELECT Combination Example

Want the names and student IDs of History majors

SELECT Student WHERE major = ‘History’ GIVING Temp

PROJECT Temp OVER (lastName, firstName, stuId) GIVING Result


Product and theta join l.jpg
Product and Theta-join

  • Binary operations – apply to two tables

  • Product: Cartesian product – cross-product of A and B – A TIMES B, written A x B

    • all combinations of rows of A with rows of B

    • Degree of result is deg of A + deg of B

    • Cardinality of result is (card of A) * (card of B)

  • THETA join: TIMES followed by SELECT

    A |x| B = (A x B)


Product example l.jpg
PRODUCT Example

Student X Enroll (Produce 63 tuples)

X


Equi join and natural join l.jpg
Equi-join and Natural Join

  • EQUIJOIN formed when  is equality on column common to both tables (or comparable columns)

  • The common column appears twice in the result

  • Eliminating the repeated column in the result gives the NATURAL JOIN, usually called just JOIN

    A |x| B


Equijoin example l.jpg
EQUIJOIN Example

Student EQUIJOIN Enroll (Produce 9 tuples)

Equivalent to:

Student TIMES Enroll GIVING Temp3

SELECT Temp3 WHERE Student.stuId = Enroll.stuId

TIMES


Natural join example l.jpg
NATURAL JOIN Example

Student JOIN Enroll or Student |X| Enroll

Equivalent to:

Student TIMES Enroll GIVING Temp3

SELECT Temp3 WHERE Student.stuId = Enroll.stuId GIVING Temp4

PROJECT Temp4 OVER (Student.stuId, lastName,, firstName, major, credits, classNumber, grade)

TIMES


Join example l.jpg
JOIN Example

Faculty JOIN Class or Faculty |X| Class

|X|


More complicated queries l.jpg
More Complicated Queries

Find classes and grades of student Ann Chin

SELECT Student WHERE lastName=‘Chin’ AND firstName=‘Ann’ GIVING Temp1

Temp1 JOIN Enroll GIVING Temp2

PROJECT Temp2 OVER (classNo, grade) GIVING Answer

classNo,grade((lastName=‘Chen’ ^ firstName=‘Ann’(Student))|X|Enroll)


More complicated queries cont l.jpg
More Complicated Queries (cont.)

SELECT Student WHERE lastName=‘Chin’ AND firstName=‘Ann’ GIVING Temp1

Temp1 JOIN Enroll GIVING Temp2

PROJECT Temp2 OVER (classNo, grade) GIVING Answer


More complicated queries cont32 l.jpg
More Complicated Queries (cont.)

Since we only need the stuId from Temp1, we can do a PROJECT on Temp1 before we make the JOIN

classNo,grade(stuId(lastName=‘Chen’ ^ firstName=‘Ann’(Student))|X|Enroll)

A third way is:

JOIN Student, Enroll GIVING Tempa

SELECT Tempa WHERE lastName=‘Chin’ AND firstName = ‘Ann’ GIVING Tempb

PROJECT Tempb Over (classNo, grade)

But it requires more work by the JOIN (produces 54 tubles), so is less efficient


Semijoins and outerjoins l.jpg
Semijoins and Outerjoins

  • Left semijoin A|x B is formed by finding

    A|x|B and projecting result onto attributes of A

  • Result is tuples of A that participate in the join

  • Right semijoin A x| B defined similarly; tuples of B that participate in join

  • Semijoin is not commutative

    • Student LEFT-SEMIJOIN Enroll is different from Enroll LEFT-SEMIJOIN Student

  • Outerjoin is formed by adding to the join those tuples that have no match, adding null values for the attributes from the other table e.g.

    A OUTER- EQUIJOIN B

    consists of the equijoin of A and B, supplemented by the unmatched tuples of A with null values for attributes of B and the unmatched tuples of B with null values for attributes of A

  • Can also form left outerjoin or right outerjoin


Semijoins example l.jpg
SemijoinsExample

Student LEFT-SEMIJOIN Enroll or Student |X Enroll

|X


Outerjoin example l.jpg
Outerjoin Example

Student OUTERJOIN Faculty

OUTERJOIN


Left outer equijoin example l.jpg
Left-Outer-Equijoin Example

Student LEFT-OUTER-EQUIJOIN Faculty

LEFT-OUTER-EQUIJOIN


Right outer equijoin example l.jpg
Right-Outer-Equijoin Example

Student RIGHT-OUTER-EQUIJOIN Faculty

LEFT-OUTER-EQUIJOIN


Division l.jpg
Division

  • Binary operator where entire structure of one table (divisor) is a portion of structure of the other (dividend)

  • Result is projection onto those attributes of the dividend that are not in the divisor of the tuples of dividend that appear with all the rows of the divisor

  • It tells which values of those attributes appear with all the values of the divisor


Divide example l.jpg
Divide Example

Club DIVIDED BY Stu or Club  Stu


Set operations l.jpg
Set Operations

  • Tables must be union compatible – have same basic structure

    • Have the same degree

    • Attributes in corresponding position have same domain

      • Third column in first relation must have same domain as third column in second relation


Set operations cont l.jpg
Set Operations (cont.)

  • A UNION B: set of tuples in either or both of A and B, written A  B

    • Remove duplicates


Set operations cont42 l.jpg
Set Operations (cont.)

  • A INTERSECTION B: set of tuples in both A and B simultaneously, written A ∩ B


Set operations cont43 l.jpg
Set Operations (cont.)

  • Difference or A MINUS B: set of tuples in A but not in B, written A – B

  • MainFac - BranchFac

-

  • BranchFac - MainFac

-


Relational calculus l.jpg
Relational Calculus

  • Formal non-procedural language

  • Two forms: tuple-oriented and domain-oriented

  • Based on predicate calculus


Tuple oriented predicate calculus l.jpg
Tuple-oriented predicate calculus

  • Uses tuple variables, which take tuples of relations as values

  • Query has form {S  P(S)}

    • S is the tuple variable, stands for tuples of relation

    • P(S) is a formula that describes S

    • Means “Find the set of all tuples, s, such that P(S) is true when S=s.”

  • Limit queries to safe expressions – test only finite number of possibilities


Example tuple oriented relational calculus l.jpg
Example Tuple-oriented Relational Calculus

Example 1: Find the names of all faculty members who are Professors in CSC Department

{F.name | F  Faculty ^ F.department = ‘CSC’ ^ F.rank = ‘Professor’}

Example 2: Find the last names of all students enrolled in CSC201A

{S.lastName | S  Student ^ EXISTS E (E  Enroll ^ E.stuId = S.stuId ^ E.classNo = ‘CSC201A)}

Example 3: Find the first and last names of all students who are enrolled in at least one class that meets in room H221.

{S.firstName, S.lastName | S  Student ^ EXISTS E(E  Enroll ^ E.stuId = S.stuId ^ EXISTS C (C  Class ^ C.classNo = E.classNo ^ C.room = ‘H221’))}


Domain oriented predicate calculus l.jpg
Domain-oriented predicate calculus

  • Uses variables that take their values from domains

  • Query has form

    {<x1,x2,...,xn>  P(x1,x2,...,xm )}

    • x1,x2,...,xn are domain variables

    • P(x1,x2,...,xm) is a predicate

    • n<=m

    • Means set of all domain variables x1,x2,...,xn for which predicate P(x1,x2,...,xm) is true

  • Predicate must be a formula

  • Often test for membership condition, <x,y,z > X


Example domain oriented relational calculus l.jpg
Example Domain-oriented Relational Calculus

  • Example 1: Find the name of all faculty members who are professors in CSC Department

    • {LN |  FI, DP, RK (<F1, LN, DP, RK>  Faculty ^ RK = ‘Professor’ ^ DP = ‘CSC’)}

  • Example 2: Find the last names of all students enrolled in CSC201A.

    • {LN |  SI, FN, MJ, CR (<SI, LN, FN, MJ, CR>  Student ^  CN, GR (<SI, CN, GR>  Enroll ^ CN = ‘CSC201A’))}

  • Example 3: Find the first and last names of all students who are enrolled in at least one class that meets in room H221.

    • {FN, LN |  SI, MJ, CR (<SI, LN, FN, MJ, CR>  Student ^  CN, GR (<SI, CN, GR>  Enroll ^  FI, SH, RM (<CN, FI, SH, RM>  Class ^ RM = ‘H221’)))}

SI: stuId, LN: lastName, FN: firstName, MJ: major, CR: credits, CN: calssNo, FI: facId, SH: schedule, RM: room, DP: department, RK: rank, GR: grade


Views l.jpg
Views

  • External models in 3-level architecture are called external views

  • Relational views are slightly different

  • Relational view is constructed from existing (base) tables

  • View can be a window into a base table (subset)

  • View can contain data from more than one table

  • View can contain calculated data

  • Views hide portions of database from users

  • External model may have views and base tables


Mapping er to relational model l.jpg
Mapping ER to Relational Model

  • Each strong entity set becomes a table

  • Non-composite, single-valued attributes become attributes of table

  • Composite attributes: either make the composite a single attribute or use individual attributes for components, ignoring the composite

  • Multi-valued attributes: remove them to a new table along with the primary key of the original table; also keep key in original table

  • Weak entity sets become tables by adding primary key of owner entity

  • Binary Relationships:

    • 1:M-place primary key of 1 side in table of M side as foreign key

    • 1:1- make sure they are not the same entity. If not, use either key as foreign key in the other table

    • M:M-create a relationship table with primary keys of related entities, along with any relationship attributes

  • Ternary or higher degree relationships: construct relationship table of keys, along with any relationship attributes


ad