BBM 471 – Database Management Systems Fall 2013 Dr. Nazlı İkizler Cinbiş

Relational Model (İlişkisel Veri Modeli) Chapter 3 in the textbook

DB Modeling & Implementation Ideas Database Model (E/R, ODL) Relational Schema Physical storage Complex file organization and index structures. Diagrams (E/R) Tables: column names: attributes rows: tuples

Example of a Relation Relation = Table attributes (or columns) tuples (or rows) 4

Relational terminology Relation is composed of tuples (çoklular) Tuple = sequence of attribute values Attribute has atomic types Relation schema: (İlişki Şeması) relation name + attribute names + attribute types STUDENT Database schema: set of relation schemas INSTRUCTOR COURSE

Concepts Review Relational Model is made up of tables A row of table = a relational instance/tuple A column of table = an attribute A table = a schema/relation Cardinality = number of rows Degree = number of columns

Example of a Relation attributes (or columns) tuples (or rows) Cardinality = 12 Degree = 4 7

Attribute Types The set of allowed values for each attribute is called the domain(alan) of the attribute Attribute values are (normally) required to be atomic; that is, indivisible The special value null is a member of every domain The null value causes complications in the definition of many operations 8

Relation Schema and Instance A1, A2, …, An are attributes R = (A1, A2, …, An ) is a relation schema Example: instructor = (ID, name, dept_name, salary) Formally, given sets D1, D2, …. Dn a relation r is a subset of D1 x D2 x … x Dn Thus, a relation is a set of n-tuples (a1, a2, …, an) where each ai  Di The current values (relation instance) of a relation are specified by a table An element t of r is a tuple, represented by a row in a table 9

Relations are Unordered Order of tuples is irrelevant (tuples may be stored in an arbitrary order) Example: instructor relation with unordered tuples 10

Properties of Relations Relations are sets, so the following must hold: The order of tuples is not important All the rows must be different (No duplicates) The relation should have at least one key The order of attributes is not important All the values in the attributes belong to a domain, hence have same type. Relationship values are simple, sets or structs, composite values are not allowed. 11

Keys Let K  R K is a superkey of R if values for K are sufficient to identify a unique tuple of each possible relation r(R) Example: {ID} and {ID,name} are both superkeys of instructor. Superkey K is a candidate key if K is minimal Example: {ID} is a candidate key for Instructor One of the candidate keys is selected to be the primary key. 12

Reduction of an E-R Schema to Tables Primary keys allow entity sets and relationship sets to be expressed uniformly as tables. A database which conforms to an E-R diagram can be represented by a collection of tables. For each entity set and relationship set there is a unique table which is assigned the name of the corresponding entity set or relationship set. Each table has a number of columns which have unique names.

How to convert a E/R diagram to a set of relations? price name category Start Year name makes Company Product Stock price

How to translate an ER diagram to a relational schema Basic cases Entity set E => relation with attributes of E Relationship R => relation with attributes being keys of related entity sets + attributes of R

Entity Sets Entity set Students Name Address SSN Rel: Students ssn John Howard Name South Carolina 444-555-6666 Park Avenue 111-222-3333 Address SSN Rel: Students

How to convert a relationship to a relation price name category Start Year name makes Company Product Stock price Makes (watch out for attribute name conflicts) Product_ Name Product_ Category Company_ Name Start_Year Gizmo Gadgets GizmoWorks 1963

Multiway relationships & roles Students Courses TAs tutors graders enrolls TA_SSN Name SSN CourseID Different roles treated as different entity sets Key: keys of the many entities

Multiway relationships & roles Students TAs Courses SSN Name 111-11-1111 George 222-22-2222 Dick TA_SSN Name 333-33-3333 Wesley 444-44-4444 Howard 555-55-5555 John CourseID Name C20.0046 Databases C20.0056 Software Enrolls(S_SSN, Course_ID, Tutor_SSN, Grader_SSN) S_SSN CourseID Tutor_SSN Grader_SSN 111-11-1111 C20.0046 333-33-3333 444-44-4444 222-22-2222 555-55-5555

Relationship -> Relation name name addr type People Likes Likes(person, sport) Sports Married husband wife Married(husband, wife) Buddies 1 2 Buddies(name1, name2) Favorite Favorite(person, sport)

Combining Relations OK to combine into one relation: The relation for an entity-set E The relations for many-one relationships of which E is the “many.” Example: People(name, addr) and Favorite(person, sport) combine to make Fan(name, addr, favSport).

Risk with Many-Many Relationships Combining People with Likes would be a mistake. It leads to redundancy, as: name addr sport Sally 123 Maple Basketball Sally 123 Maple Tennis Redundancy

How to convert a weak entity set to a relation affiliation Team University schedule sport name address Team Sport Schedule University_Name Basketball <long string> Hacettepe University Do include all the attributes in the key for Team. Don’t include a separate relation for Affiliation. (why?) 23

Converting weak ESs – differences StudioName address Crew_ID Crew Unit-of Studio C2 Miramax C1 Disney Crew_ID StudioName Crew Atts of Crew Rel are: attributes of Crew key attributes of supporting ESs Supporting relships are omitted

Weak entity sets - relationships StudioName address Crew_ID Unit-of Crew Studio Subscribes 1260 7th Av.NY BlueCross 1250 6th Av.NY Aetna Address IName Insurance IName Address Insurance

Weak entity sets - relationships Non-supporting relationships for weak ESs are converted keys include entire weak ES key StudioName address Crew_ID Unit-of Crew Studio Subscribes IName C21 C22 Crew_ID Aetna BlueCross Insurer Universal Disney StudioName Subscribes Insurance Address

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

Example: Weak Entity Set -> Relation name name Logins At Hosts location billTo Hosts(hostName, location) Logins(loginName, hostName, billTo) At(loginName, hostName, hostName2) At becomes part of Logins Must be the same

Exercise 1 Convert the E/R diagram to a relational database schema. row seat Booking Customers Flights phone aircraft number SSN address day name

How to translate a subclass Product topic platforms ageGroup memory isa isa Educational Product Software Product isa isa Educational-method Educ-software Product

Three ways to translate subclasses Object-oriented : each entity belongs to exactly one class; create a relation for each class, with all its attributes. E/R style : create one relation for each subclass, with only the key attribute(s) and attributes attached to that entity set; Use null : create one relation; entities have nulls in attributes that don’t belong to them.

Option #1: the OO Approach 4 tables: each object can only belong to a single table Product(name, price, category, manufacturer) EducationalProduct( name, price, category, manufacturer, ageGroup, topic) SoftwareProduct( name, price, category, manufacturer, platforms, requiredMemory) EducationalSoftwareProduct( name, price, category, manufacturer, ageGroup, topic, platforms, requiredMemory) DRAWBACK: Redundancy

Option #2: the E/R Approach Product(name, price, category, manufacturer) EducationalProduct( name, ageGroup, topic) SoftwareProduct( name, platforms, requiredMemory) No need for a relation EducationalSoftwareProduct unless it has a specialized attribute: EducationalSoftwareProduct(name, educational-method) DRAWBACK: Have to reach multiple tables

Option #3: The Null Value Approach Have one table: Product ( name, price, manufacturer, age-group, topic, platforms required-memory, educational-method) Some values in the table will be NULL, meaning that the attribute not make sense for the specific product. Saves space unless there are lots of attributes that are usually NULL DRAWBACK: Redundancy and too many meanings for NULL

Representing Aggregation Name SSN Name Advisor Student Professor Dept SID Name member Primary Key of Advisor Dept SID Code 1234 04 5678 08 Code Primary key of Dept

Constraints (Kısıtlamalar)

Veri Tutarlılığı

Referential integrity When one table has a foreign key to another table, the concept of referential integrity states that you may not add a record to the table that contains the foreign key unless there is a corresponding record in the linked table.

Referential Integrity Constraints Idea: prevent “dangling tuples” (e.g.: a loan with a bname, Kenmore, when no Kenmore tuple in branch) Referencing Relation (e.g. loan) Referenced Relation (e.g. branch) “foreign key” bname primary key bname Ref Integrity: ensure that: foreign key value  primary key value (note: need not to ensure , i.e., not all branches have to have loans)

Other kinds of constraints Domain constraints E.g. date: must be after 1980 Enumerated type: grades A through F, no E No special E/R notation just write near line General constraints: A class may have no more than 100 students; a student may not have more than 6 courses: Enroll Students <=100 <=6 Courses

Relational Queries

Relational Queries Query languages: Allow manipulation and retrieval of data from a database. Relational model supports simple, powerful QLs: Strong formal foundation based on logic. Allows for much optimization. Query Languages != programming languages! QLs not intended to be used for complex calculations. QLs support easy, efficient access to large data sets.

Formal Relational Query Languages Two mathematical Query Languages form the basis for “real” languages (e.g. SQL), and for implementation: Relational Algebra: More operational, very useful for representing execution plans. Relational Calculus: Lets users describe what they want, rather than how to compute it. (Nonoperational,declarative.)

What is Relational Algebra? An algebra whose operands are relations or variables that represent relations. Operators are designed to do the most common things that we need to do with relations in a database. The result is an algebra that can be used as a query language for relations.

Core Relational Algebra Union, intersection, and difference. Usual set operations, but both operands must have the same relation schema. Selection: picking certain rows. Projection: picking certain columns. Products and joins: compositions of relations. Renaming of relations and attributes.

Selection R1 := σC (R2) C is a condition (as in “if” statements) that refers to attributes of R2. R1 is all those tuples of R2 that satisfy C.

Example: Selection Relation Sells: cafe drink price Joe’s Coffee 2.50 Joe’s Tea 2.75 Sue’s Coffee 2.50 Sue’s Tea 3.00 JoeMenu := σcafe=“Joe’s”(Sells): cafe drink price Joe’s Coffee 2.50 Joe’s Tea 2.75

Selection keeps only the tuples that satisfy a particular condition Diagnosis Patient Disease Temperature Winslett Strep 98.9 Zhai Meningitis 101.1 Han Ebola 96.6 Hantavirus 98.6 Chang Cholera 102.3 Find all patients who have a fever sTemperature > 98.6 (Diagnosis) You can also write this as [Temperature > 98.6] (Diagnosis)

Selection conditions can be relatively complex Attribute names Patient Disease Salary Constants “Winslett” “Meningitis” 40,000 = < > ≤ ≠ Patient = “Winslett” Salary < 40,000 and or not Patient = “Winslett” and Temperature > 98.6

Projection R1 := πL (R2) L is a list of attributes from the schema of R2. R1 is constructed by looking at each tuple of R2, extracting the attributes on list L, in the order specified, and creating from those components a tuple for R1. Eliminate duplicate tuples, if any. Result is a set of tuples, so no duplicates is allowed in a set representation.

Example: Projection Relation Sells: cafe drink price Joe’s Coffee 2.50 Joe’s Tea 2.75 Sue’s Coffee 2.50 Sue’s Tea 3.00 Prices := πdrink,price(Sells): drink price Coffee 2.50 Tea 2.75 Tea 3.00

Extended Projection Using the same πL operator, we allow the list L to contain arbitrary expressions involving attributes: Arithmetic on attributes, e.g., A+B->C. Duplicate occurrences of the same attribute.

Example: Extended Projection R = ( A B ) 1 2 3 4 πA+B->C,A,A (R) = C A1 A2 3 1 1 7 3 3