Embed Size (px)
Citation preview
Database
Relational Model
The Relational Data Model
DataModeling
DataModeling
Relational Schema
Relational Schema
Physicalstorage
Physicalstorage
E/R diagrams Tables: column names: attributes
rows: tuples
Complexfile organization
and index structures.
Relational Data Model
Core of majority of modern databases
Virtually all business relies on some form of relational database
Solid theoretical/mathematical foundation
Relational Model Concepts
The relational Model of Data is based on the
concept of a Relation.
A Relation is a mathematical concept based
on the ideas of sets. Order of tuples not important
Order of attributes not important (in theory)
RELATION
RELATION is A table of values
A relation may be thought of as a set of
rows.
A relation may alternately be though of as a
set of columns.
Relation InstanceName Address Telephone
Ahmed 123 Main St 555-1234
Hassan 12 State St 555-1235
Ahmed 123 Main St 555-1235
Mona 456 Main St 555-2221
Sally 456 Main St 555-2221
Sally 456 Main St 555-2223
Hassan 12 State St 555-1235
ExampleState
Example Schema
Schema
The schema of a relation is the name of the relation followed by a parenthesized list of attributes (+ types of attributes).
CoursesTaken(Student, Course, Grade) A design in a relational model consists of a set of
schemas. Such a set of schemas is called a relational database
schema.
Relation Schema
StockItem
Attribute DomainItemID string(4)Description string(50)Price currency/dollarsTaxable boolean
relationname
set of attributes
attributedomains
attributenames
Relational schema
Is a direct map from ER diagram into basic table
For example, the schema (ID, phone, name,
birth_date, address)
Banking Example
branch (branch_name, branch_city, assets)
customer (customer_name, customer_street, customer_city)
account (account_number, branch_name, balance)
loan (loan_number, branch_name, amount)
depositor (customer_name, account_number)
borrower (customer_name, loan_number)
13
Example Database Schema
Student (Id: INT, Name: STRING, Address: STRING, Status: STRING)
Professor (Id: INT, Name: STRING, DeptId: DEPTS)
Course (DeptId: DEPTS, CrsName: STRING, CrsCode: COURSES)
Transcript (CrsCode: COURSES, StudId: INT, Grade: GRADES, Semester: SEMESTERS)
Department (DeptId: DEPTS, Name: STRING)
Key Constraints
key of R: A set of attributes SK of R such that no two tuples will have the same value for SK
If a relation has several candidate keys, one is chosen arbitrarily to be the primary key. The primary key attributes are underlined.
Indicate a key by underlining the key attributes. Example: If name is a key for Beers:
Beers(name, manf)
Entity Set to Relation
Product
name category
price
Product(name, category, price)
name category price
gizmo gadgets $19.99
Relationships to Relations
makes Company
Product
name category
Stock price
name
Makes(product-name, product-category, company-name, year) Product-name Product-Category Company-name Starting-year
gizmo gadgets gizmoWorks 1963
Start Year
price
Relationships to Relations
makes Company
Product
name category
Stock price
name
No need for Makes. Modify Product:
name category price StartYear companyName
gizmo gadgets 19.99 1963 gizmoWorks
Start Year
price
uses
carriesAircraft
Airport
Flight
Flight (flight#, arrival_airport, depart_airport, arrival_time, depart_time)
Airport (code, city)
Aircraft (aircraft, no_of_seats)
Identifier of flight seems strange. ‘Flight_no’ alone should identify a flight.
ERD FROM DATASTORES FLIGHTS
carries
Stops_at
Aircraft
Airport
Stopover
Flight (flight#, arrival_airport, depart_airport, arrival_time, depart_time)
Stopover (flight_no, code, arrival_time, depart_time)
Airport (code, city)
Aircraft (aircraft, no_of_seats)
Flight
Leaves_from
Departs_from
Arrives_at
ERD FROM DATASTORES FLIGHTS
Multi-way Relationships to Relations
Purchase
Product
Person
Storename price
ssn name
name address
Purchase( , , )
Drinkers
For one-one relation Married, we can choose either husband or wife as key.
Likes(drinker, beer)Favorite(drinker, beer)Married(husband, wife)Buddies(name1, name2)
BeersLikes
name manfname addr
Buddies
Married
Favorite
1 2
husband wife
Weak Entity Sets, Relationships Relations
Relation for a weak E.S. must include its full key (i.e., attributes of related entity sets) as well as its own attributes.
A supporting (double-diamond) relationship yields a relation that is actually redundant and should be deleted from the database schema.
Representing Entity Sets With Simple AttributesRepresenting Entity Sets With Simple Attributes
A strong entity set reduces to a schema with the same attributesstudent(ID, name, tot_cred)
A weak entity set becomes a table that includes a column for the primary key of the identifying strong entity set section ( course_id, sec_id, sem, year )
Example
Hosts(hostName)
Logins(loginName, hostName)
At(loginName, hostName, hostName2) In At, hostName and hostName2 must be the
same host, so delete one of them. Then, Logins and At become the same
relation; delete one of them. In this case, Hosts’ schema is a subset of Logins’ schema. Delete Hosts?
Logins Hosts@@
name name
Converting Non-identifying Attributes Single-valued (standard attribute)
Create a table column for each
Derived Omit: these values are not stored in our tables
Later, we can produce these values using a query
Multi-valued Relational model does not directly support! However, as we have discussed, a multi-valued
attribute can be conceptualized as a new (weak) entity, thus implying a separate table.
Composite and Multivalued Attributes
Composite attributes are flattened out by creating a separate attribute for each component attribute Example: given entity set instructor with
composite attribute name with component attributes first_name and last_name the schema corresponding to the entity set has two attributes name_first_name and name_last_name
Prefix omitted if there is no ambiguity Ignoring multivalued attributes, extended
instructor schema is instructor(ID,
first_name, middle_initial, last_name, street_number, street_name, apt_number, city, state, zip_code, date_of_birth)
Composite and Multivalued Attributes
A multivalued attribute M of an entity E is represented by a separate schema EM Schema EM has attributes corresponding to the
primary key of E and an attribute corresponding to multivalued attribute M
Example: Multivalued attribute phone_number of instructor is represented by a schema: inst_phone= ( ID, phone_number)
Each value of the multivalued attribute maps to a separate tuple of the relation on schema EM
For example, an instructor entity with primary key 22222 and phone numbers 456-7890 and 123-4567 maps to two tuples: (22222, 456-7890) and (22222, 123-4567)
One-to-one relationships Consider the 2 associated entity tables. The foreign key column(s) can be with either entity
As before, copy the primary key column(s) of the related table
Note: in a 1:1 relationship, the two entities often use the same identifier, in which case the existing primary key columns serve the “dual role” of both primary and foreign keys A separate foreign key column is then unnecessary!
Converting Binary Relationships
One-to-many relationships Consider the 2 associated entity tables. Within the “many side” entity’s table, we need to have
foreign key column(s) referring to the related “one side” entity instances
We use the identifier of the related entity to define the foreign key column(s)
In other words, we include a column (a “copy”) of primary key values from the related table
The copied primary key values we call “foreign keys.”
Converting Binary Relationships
Schema Diagram
Reverse engineer this relational schema to find an equivalent ER schema.
REVIEW
Many-to-many relationships Relational model does not directly support! However, each many-to-many relationship can be
conceptualized as a new (associative) entity, thus implying a separate table.
The identifier for the associative entity is the combination of the identifiers for the two related entities.
Thus, for the separate table we create for an M:M relationship, its primary key columns include the primary key columns for both of the related tables.
Converting Binary Relationships
Finding the Keys
PersonbuysProduct
name
price name ssn
buys(name, ssn, date)
date
If the relation comes from a many-many relationship, the key of the relation is the set of all attribute keys in the relations corresponding to the entity sets
PREVIEW: ER to Relational
EER Bank Schema
Step 1: Regular Entities
Regular entity types become relations include all simple attributes include only components of compound
attributes keys become primary keys if multiple keys (candidates) select a primary
key
CUSTOMER(Ssn, Name, Addr, Phone)
Step 1: Regular Entities
ACCOUNT(Acct_no, Type, Balance)
LOAN(Loan_no, Type, Amount)
BANK(Code, Name, Addr)
Step 2: Weak Entities Weak entity types become relations
include all simple attributes include only components of compound attributes create a primary key from partial key
and key of owning entity type (through identifying relationship)
attributes acquired through identifying relationship become a foreign key*
* typically, deletions and insertions will be propagated
through this foreign key
Step 2: Weak Entities Weak entity types become relations
BANK_BRANCH(Bank_code, Branch_No, Addr)
BANK(Code, Name, Addr)
FK
Step 3: Binary 1:1 Relationships Approach 1: Foreign Key
EMPLOYEE(Ssn, Name, …)
DEPARTMENT(Name, Number, Mgr, Mgr_start_date)
FK
Step 3: Binary 1:1 Relationships Approach 2: Merged Relation
AJB(x, y, p, q, r)
or
AJB(x, y, p, q, r)
Step 4: Binary 1:N Relationships 1:N Relationships become foreign key at N side
any relationship attributes also go to N side
LOAN(Loan_no, Type, Amount, Bank, Branch)
BANK_BRANCH(Bank_code, Branch_No, Addr)
Step 4: Binary 1:N Relationships 1:N Relationships become foreign key at N side
any relationship attributes also go to N side
ACCOUNT(Acct_no, Type, Balance, Bank, Branch)
BANK_BRANCH(Bank_code, Branch_No, Addr)
Step 5: Binary M:N Relationships M:N Relationships must become a new relation
contains FKs to both related entities combined FKs become PK for new relations relationship attributes go in new relation
CUSTOMER(Ssn, Name, Addr, Phone)
ACCOUNT(Acct_no, Type, Balance, Bank, Branch)
A_C(Acct, Cust)
Step 6: Multivalued Attributes Multivalued attributes must become new
relations FK to associated entity type PK is whole relation
DEPT_LOCATIONS(DName, Dno, Location)
DEPARTMENT(Name, Number, Mgr, Mgr_start_date)
Step 7: N-ary Relationships Non-Binary Relationships become new relations
FKs to all participating entity types Combine FKs to make a PK
(exclude entities with max participation of 1) Include any relationship attributes
SUPPLY(SName, PName, Part, Quantity)
SUPPLIER(SName)
PROJECT(Proj_name)PART(Part_no)
Completed Bank Schema
CUSTOMER(Ssn, Name, Addr, Phone)BANK(Code, Name, Addr)ACCOUNT(Acct_no, Type, Balance, Bank, Branch)LOAN(Loan_no, Type, Amount, Bank, Branch)BANK_BRANCH(Bank_code, Branch_No, Addr)A_C(Acct, Cust)L_C(Loan, Cust)
BANK_BRANCH(Bank_code) refers to BANKLOAN(Bank,Branch) refers to BANK_BRANCHACCOUNT(Bank,Branch) refers to BANK_BRANCHA_C(Acct) refers to ACCOUNTA_C(Cust) refers to CUSTOMERL_C(Loan) refers to LOANL_C(Cust) refers to CUSTOMER
Bank Schema: MS Access
49
Exercise A university database contains information about professors
(identified by social security number) and courses (identified by courseid). Professors teach courses; each of the following situations concerns the Teaches relationship set. For each situation, draw an ER diagram that describes it.
Professors can teach the same course in several semesters, and each offering must be recorded.
50
Professors can teach the same course in several semesters, and only the most recent such offering needs to be recorded.
Exercise
51
Every professor teaches exactly one course (no more, no less)
Every professor teaches exactly one course (no more, no less), and every course must be taught by some professor
Exercise
52
Practice
Professors have an SSN, a name, an age, a rank, and a research specialty. Projects have a project number, a sponsor name (e.g., NSF), a starting date, an
ending date, and a budget.
Graduate students have an SSN, a name, an age, and a degree program Each project is managed by exactly one professor (known as PI) Each project is worked in by one or more professors (known as Co-PIs) Each project is worked on by one or more graduate students (known as
RAs)
53
When graduate students work on a project, a professor must supervise their work on the project. Graduate students can work on multiple projects, in which case they will have a potentially different supervisor for each project.
Departments have a department number, a department name, and a main office. Department has a professor (known as Chairman) who runs the department.
54
Professors work in one or more departments, and for each department that they work in, a time percentage is associated with their job
Graduate students have one major department in which they are working on their degree.
Each graduate student must have another, more senior graduate student as an advisor.
55
A company database needs to store information about employees (identified by ssn, with salary and phone as attributes), departments (identified by dno, with dname and budget as attributes), and children of employees (with name and age as attributes).
Exercise
A company database needs to store information about employees (identified by ssn, with salary and phone as attributes), departments (identified by dno, with dname and budget as attributes), and children of employees (with name and age as attributes). Employees work in departments; each department is managed by an employee; a child must be identified uniquely by name when the parent (who is an employee; assume that only one parent works for the company) is known.
Draw an ER diagram that captures this information.
Employees work in departments; each department is managed by an employee;
a child must be identified uniquely by name when the parent (who is an employee; assume that only one parent works for the company) is known.
Exercise
You set up a database company, ArtBase, that builds a product for art galleries. The core of this product is a database with a schema that captures all the information that galleries need to maintain.
Galleries keep information about artists, their names (which are unique), birthplaces, age, and style of art. For each piece of artwork, the artist, the year it was made, its unique title, its type of art (e.g., painting, lithograph, sculpture, photograph), and its price must be stored. Pieces of artwork are also classified into groups of various kinds, for example, portraits, still lifes, works by Picasso, or works of the 19th century; a given piece may belong to more than one group. Each group is identified by a name (like those just given) that describes the group. Finally, galleries keep information about customers. For each customer, galleries keep that person’s unique name, address, total amount of dollars spent in the gallery (very important!), and the artists and groups of art that the customer tends to like. Draw the ER diagram for the database
• Galleries keep information about artists, their names (which are unique), birthplaces, age, and style of art .
• For each piece of artwork, the artist, the year it was made, its unique title, its type of art (e.g., painting, lithograph, sculpture, photograph), and its price
must be stored .
• Pieces of artwork are also classified into groups of various kinds, for example, portraits, still lifes, works by Picasso, or works of the 19th century; a given piece may belong to more than one group. • Each group is identified by a name (like those just given) that describes the group.
• Finally, galleries keep information about customers. For each customer, galleries keep that person’s unique name, address, total amount of dollars spent in the gallery (very important!), • and the artists and groups of art that the customer tends to like
Subclasses Relations
1. Object-oriented: each entity is in one class. Create a relation for each class, with all the attributes for that class.
2. E/R style: an entity is in a network of classes related by isa. Create one relation for each E.S. An entity is represented in the relation for each subclass
to which it belongs. Relation has only the attributes attached to that E.S. +
key.
3. Use nulls. Create one relation for the root class or root E.S., with all attributes found anywhere in its network of subclasses. Put NULL in attributes not relevant to a given entity.
Example
name manfBeers
Alescolor
isa
OO-Style
E/R Style
name manf
Bud A.B.
Beers Ales
name manf color
SummerBrew Pete's dark
name manf
Bud A.B.SummerBrew Pete's
name Color
SummerBrew dark
Beers Ales
name manf color
Bud A.B. NULLSummerBrew Pete's dark
Beers
Using NULLS
Design Issues Use of entity sets vs. attributes
Use of phone as an entity allows extra information about phone numbers (plus multiple phone numbers)
Design Issues Use of entity sets vs. relationship sets
Possible guideline is to designate a relationship set to describe an action that occurs between entities
Preview: Queries
•Read the following database case and then draw the EERD for that case. After that, transform that EERD into a relational
model. Assume from 3-5 attributes for each entity type .
ABC is a company whose business is to deliver shipments. The company has many branches in Egypt each of which has many stores. Each store has many employees working for it. A store receives many customer shipments to deliver to destinations. A customer is able to send many shipments and for each he/she is expecting a confirmation on delivery. A fare is payable for each delivery. However, when the shipment is lost an apology is to replace the confirmation. ABC is using many vehicles including aircrafts, trucks and ships for sending the customer shipments.
