Final Exam Revision 5 Prof. Sin-Min Lee Department of Computer Science

Entity Sets customer and loan customer-id customer- customer- customer- loan- amount name street city number

Attributes An entity is represented by a set of attributes, that is descriptive properties possessed by all members of an entity set. Domain – the set of permitted values for each attribute Attribute types: –Simple and composite attributes. –Single-valued and multi-valued attributes E.g. multivalued attribute: phone-numbers –Derived attributes Can be computed from other attributes E.g. age, given date of birth Example: customer = (customer-id, customer-name, customer-street, customer-city) loan = (loan-number, amount)

Composite Attributes

Relationship Sets A relationship is an association among several entities Example: HayesdepositorA-102 customer entityrelationship setaccount entity A relationship set is a mathematical relation among n  2 entities, each taken from entity sets {(e 1, e 2, … e n ) | e 1  E 1, e 2  E 2, …, e n  E n } where (e 1, e 2, …, e n ) is a relationship –Example: (Hayes, A-102)  depositor

Relationship Set borrower

Relationship Sets (Cont.) An attribute can also be property of a relationship set. For instance, the depositor relationship set between entity sets customer and account may have the attribute access- date

RELATIONSHIPS A relationship set is represented as a A relationship may involve two entities, binary relationship: A relationship may involve three entities, ternary relationship: Football Teams fans People Football Teams fans People Date

RELATIONSHIPS (Cont…) A relationship may involve n entities, N-ary relationship It is always possible to replace a non-binary relationship set by a number of distinct binary relationship sets Football Teams fans People Date on

BINARY RELATIONSHIP A binary relationship between entity set A and B might be: 1:1 Women marrying Men (function) N:1 Children having mothers (function) 1:N Mothers having children (inverse function) M:N Students enrolled in a class women marry men children having mothers having children students enrolled classes 1 n n1 A B A B A B A B

E-R Diagrams Rectangles represent entity sets. Diamonds represent relationship sets. Lines link attributes to entity sets and entity sets to relationship sets. Ellipses represent attributes Double ellipses represent multivalued attributes. Dashed ellipses denote derived attributes. Underline indicates primary key attributes (will study later)

E-R Diagram With Composite, Multivalued, and Derived Attributes

Relationship Sets with Attributes

Cardinality Constraints We express cardinality constraints by drawing either a directed line (  ), signifying “one,” or an undirected line (—), signifying “many,” between the relationship set and the entity set. E.g.: One-to-one relationship: –A customer is associated with at most one loan via the relationship borrower –A loan is associated with at most one customer via borrower

One-To-Many Relationship In the one-to-many relationship a loan is associated with at most one customer via borrower, a customer is associated with several (including 0) loans via borrower

Many-To-One Relationships In a many-to-one relationship a loan is associated with several (including 0) customers via borrower, a customer is associated with at most one loan via borrower

Many-To-Many Relationship A customer is associated with several (possibly 0) loans via borrower A loan is associated with several (possibly 0) customers via borrower

Participation of an Entity Set in a Relationship Set Total participation (indicated by double line): every entity in the entity set participates in at least one relationship in the relationship set E.g. participation of loan in borrower is total every loan must have a customer associated to it via borrower Partial participation: some entities may not participate in any relationship in the relationship set E.g. participation of customer in borrower is partial

Example: Company Database Description of Data Requirements 1.The company is organized into departments. Each department has a unique name, a unique number, and a particular employee who manages the department. We keep track of the start date when that employee began managing the department. A department may have several locations. 2.A department controls a number of projects, each of which has a unique name, a unique number, and a single location.

Example: Company Database 3.We store each employee's name, SSN, address, salary, sex, and birth date. An employee is assigned to one department but may work on several projects, which are not necessarily controlled by the same department. We keep track of the number of hours per week that an employee works on each project. We also keep track of the direct supervisor of each employee. 4.We want to keep track of the dependents of each employee: first name, sex, birth date, relationship to the employee

Roles Entity sets of a relationship need not be distinct The labels “manager” and “worker” are called roles; they specify how employee entities interact via the works-for relationship set. Roles are indicated in E-R diagrams by labeling the lines that connect diamonds to rectangles. Role labels are optional, and are used to clarify semantics of the relationship

RELATIONSHIPS (Cont…) Example: A library database contains a listing of authors that have written books on various subjects (one author per book). It also contains information about libraries that carry books on various subjects.

KEY Entities and relationships are distinguishable using various keys A key is a combination of one or more attributes, e.g., social-security number, combination of name and social- security number. A superkey is a key defined either for an entity set or relationship set that uniquely identifies an entity, e.g., social-security number, phone number, combination of name and social-security number. A candidate key is a minimal superkey that uniquely identifies either an entity or a relationship, e.g., social- security number, phone number. A primary key is a candidate key that is chosen by the database designer to identify the entities of an entity set.

KEY (Cont…) A foreign key is a set of one or more attributes of a strong entity set that are employed to construct the discriminator of a weak entity set. The primary key of a weak entity set is formed by the primary key of the strong entity set on which it is existence- dependent. Relationship sets also have primary keys. Assume R is a relationship set involving entity sets E 1, E 2,..., E n. Let primary-key(E i ) denote the primary key for entity set E i. Assume primary-key(E i ) is unique for 1 ≤ i ≤ n. If R has no attributes then its superkey is: primary-key(E 1 ) ∪ primary-key(E 2 ) ∪... ∪ primary-key(E n ) This is a primary key if the mapping constraint is many-to-many. If the mapping constraint is many to one from E 1 to E 2 then the primary key of R is primary key of E 1. books wrote authors SS# name title edition E1E1 R E2E2

GENERALIZATION AND SPECIALIZATION Generalization is the result of computing the union of two or more entity sets to produce a higher-level entity set. It represents the containment relationship that exists between the higher-level entity set and one or more lower-level entity sets. Specialization constructs the lower level entity sets that are a subset of a higher level entity set. sid student name is A graduate Undergrad Specialization Generalization

GENERALIZATION AND SPECIALIZATION Undergrad and graduate are termed subclasses of the superclass student. This is a superclass/subclass or simply class/subclass relationship. A member of a subclass MUST be a member of the superclass. An alternative notation is the Union symbol The circle with d specifies that the specializations are disjoint. A member of Undergrad entity set may NOT be a member of the graduate entity set. sid student name graduate Undergrad Specialization Generalization d U U

GENERALIZATION AND SPECIALIZATION A design may require all members of an entity-set to be specialized. For example, an employee MUST be a member of either a Salaried or Part-time. Use double lines to dictate this constraint. sid Emp name Part-time Salaried Specialization Generalization d U U

GENERALIZATION AND SPECIALIZATION One may allow the specialized entity sets to overlap. For example, an entity might be both a Salaried and Part-time. “o” stands for Overlap when specializing. sid Emp name Part-time Salaried Specialization Generalization o U U

EXAMPLE Employees of a large company, e.g., IBM, where an employee reports to a manager. The manager is also an employee who reports to another manager. This chain of command continues to the very top where the CEO is the only employee who is not reporting to a manager. Draw the ER diagram for this example.

Creating Tables

Creating a Table The basic format of the CREATE TABLE command is: CREATE TABLE TableName( Column1 DataType1 ColConstraint, … ColumnN DataTypeN ColConstraint, TableConstraint1, … TableConstraintM );

An Example CREATE TABLE Student ( ID NUMBER, Fname VARCHAR2(20), Lname VARCHAR2(20), );

Constraints in Create Table Adding constraints to a table enables the database system to enforce data integrity. Different types of constraints: * Not Null* Default Values * Unique * Primary Key * Foreign Key* Check Condition

Not Null Constraint CREATE TABLE Student ( ID NUMBER, Fname VARCHAR2(20) NOT NULL, Lname VARCHAR2(20) NOT NULL, );

Primary Key Constraint Primary Key implies: * NOT NULL * UNIQUE. There can only be one primary key. CREATE TABLE Student ( ID NUMBER PRIMARY KEY, Fname VARCHAR2(20) NOT NULL, Lname VARCHAR2(20) NOT NULL, );

Primary Key Constraint (Syntax 2) CREATE TABLE Students ( ID NUMBER, Fname VARCHAR2(20) NOT NULL, Lname VARCHAR2(20) NOT NULL, PRIMARY KEY(ID) ); Needed when the primary key is made up of two or more fields

Another Table CREATE TABLE Studies( Course NUMBER, Student NUMBER ); What additional constraint do we want on Student? What should be the primary key?

Foreign Key Constraint NOTE: ID must be unique (or primary key) in Student CREATE TABLE Studies( Course NUMBER, Student NUMBER, FOREIGN KEY (Student) REFERENCES Students(ID) );

Translating ER-Diagrams to Table Definitions

General Principals When converting ER diagrams to Relations, we should try to: 1.Reduce duplicate information 2.Constrain as tightly as possible Note: 1.Some scenarios can be represented in different ways. 2.Sometimes we will not be able to fully represent constraints, or will be forced to represent information more than once.

Relations vs. Tables We show how to translate ER-Diagrams to table definitions Sometimes, people translate ER-Diagrams to relation definition, which is more abstract than table definitions. –e.g., Employee(SSN, Fname, Lname, Gender, Salary, Dept); –table definitions contain, in addition, constraints and datatypes

Simple entity translation General Rule: Create a table with the name of the Entity. There is a column for each attribute The key in the diagram is the primary key of the table Actor id name address birthday

Relations vs. Tables We show how to translate ER-Diagrams to table definitions Sometimes, people translate ER-Diagrams to relation definitions, which is more abstract than table definitions. –e.g., Student(ID, Fname, Lname); –table definitions contain, in addition, constraints and datatypes

Translating Entities General Rule: Create a table with the name of the Entity. There is a column for each attribute The key in the diagram is the primary key of the table Actor id name address birthday

Translating Entities create table Actor(id varchar2(20) primary key, name varchar2(40), birthday date, address varchar2(100)); Actor id name address birthday Relation: Actor (id, name, birthday, address)

Translating Relationships (without constraints) General Rule: Create a table with the name of the relationship The table has columns for all of the relationship's attributes and for the keys of each entity participating in the relationship What is the primary key of the table? What foreign keys are needed? Actor id name address birthday Acted In Film title type year salary

Translating relationships (without constraints) What would be the relation for ActedIn? How would you define the table for ActedIn? Actor id name address birthday Acted In Film title type year salary

Translating Recursive Relationships (without constraints) Employee id name address Manages manager worker Relation: Actor (worker-id, manager-id) What would be the table definition?

Translating relationships (key constraints): Option 1 General Rule for Option 1: Same as without key constraints, except that the primary key is defined differently Director id name Directed Film title salary year

Translating relationships (key constraints): Option 1 create table Directed( id varchar2(20), title varchar2(40), salary integer, ) Director id name Directed Film title salary year What primary and foreign keys are missing?

Translating relationships (key constraints): Option 2 General Rule for Option 2: Do not create a table for the relationship Add information columns that would have been in the relationship's table to the table of the entity with the key constraint What is the disadvantage of this method? What is the advantage of this method? Director id name Directed Film title salary year

Translating relationships (key constraints): Option 2 create table Film( title varchar2(40), year integer, primary key (title), ) Director id name Directed Film title salary year What 3 lines are missing?

Translating relationships (key constraints) What are the different options for translating this diagram? A R B C

Translating relationships (participation constraints) General Rule: If has both participation and key constraint, use Option 2 from before. Add the not null constraint to ensure that there will always be values for the key of the other entity Director id name Directed Film title salary year

Translating relationships (participation constraints) create table Film( title varchar2(40), year integer, id varchar2(20), salary integer, foreign key (id) references Director, primary key (title)) Director id name Directed Film title salary year Where should we add NOT NULL?

Translating relationships (participation constraints) How would we translate this? Actor id name Acted In Film title salary year

Translating Weak Entity Sets create table award( name varchar2(40), year integer, money number(6,2), o_name varchar2(40), primary key(name, year, o_name), foreign key (o_name) references Organization(name) on delete cascade ) Award Organization Gives year name phone number money

Translating ISA: Option 1 create table MoviePerson(... ) create table Actor(id varchar2(20), picture bfile, primary key(id), foreign key (id) references MoviePerson)) create table Director(...) Movie Person ISA id name address picture Director Actor

Translating ISA: Option 2 No table for MoviePerson! create table Actor(id varchar2(20), address varchar2(100), name varchar2(20), picture blob, primary key(id)); create table Director(...) Movie Person ISA id name address picture Director Actor

Which Option To Choose? What would you choose if: –Actor and Director DO NOT COVER MoviePerson? –Actor OVERLAPS Director?

Translating Aggregation Create table for Won using: –key of ActedIn –key of Award (careful, award is a weak entity) Actor picture Film year type title Acted In salary Award Organization Gives year name phone number Won

E-R Design Refined Defining Relationship Types Change the attributes that represent relationships into relationship types: Manager from DEPT., Supervisor from EMPLOYEE Determine cardinality ratio and participation constraints Company Database Example (fig3.2)fig3.2 MANAGES (EMPOYEE:DEPARTMENT) = 1:1 (partial:total), has ‘StartDate’ attribute

E-R Design Refined Company Database Example WORKS_FOR (EMPLOYEE:DEPT) = N:1 (t:t) CONTROLS (DEPT:PROJECT) = 1:N (p:t) SUPERVISION (EMPLOYEE_supervisor: EMPLOYEE_supervisee) = 1:N (p:p) WORKS_ON(EMPOYEE:PROJECT) = M:N (t:t), has ‘Hours’ attribute DEPENDENTS_OF (EMPOYEE:DEPENDENT) = 1:N (p:t), DEPENDENT as a weak entity type

Summary TablesPrimary keyRemarks Simple EntitySingle tableThe entity keya column for each attr. Simple Relationship 3 (2 entities +relationship) For the relation: Both entity keys Foreign keys from rel. Table Key constraint3 as before or 2 (one for each entity) Key of constrained ent. Foreign keys from rel. Table Foreign key from constr. Entity Key and Participation constr. 2RegularConstrained entity has a non-null f. key

TablesPrimary keyRemarks Weak Entity2: parent and weak entities Weak: its own and parent keys Foreign keys from weak ent. ISA: covers and no overlap 2: only child entities Parent key ISA: otherwise3: parent and child entities Parent keyForeign keys from child ent. Aggregation3: 2 aggregates and relationship For relationship: keys of both aggregates Foreign keys from relationship table