Database Applications 15 415 The Entity Relationship Model

Database Applications (15 -415) The Entity Relationship Model Lecture 2, January 14, 2020 Mohammad Hammoud

Today… § Last Session: § Course overview and a brief introduction to databases § Today’s Session: § § Introduction to databases and database systems (Continue) Main steps involved in designing databases Constructs of the entity relationship (ER) model Integrity constrains that can be expressed in the ER model § Announcements: § The first Problem Solving Assignment (PS 1) will be posted by tonight on the course webpage. It is due on January 26 by midnight § Thursday, January 16 is the first recitation § A case study on the ER model will be solved together

Outline A Primer on Databases Database Design ER Model: Constructs and Constraints ü

Levels of Abstraction § The data in a DBMS is described at three levels of abstraction, the conceptual (or logical), physical and external schemas § The conceptual schema describes data in terms of a specific data model (e. g. , the relational model of data) View 1 § The physical schema specifies how data described in the conceptual schema are stored on secondary storage devices View 2 View 3 Conceptual Schema Physical Schema Disk § The external schema (or views) allow data access to be customized at the level of individual users or group of users (views can be 1 or many)

Views § A view is conceptually a relation § Records in a view are computed as needed and usually not stored in a DBMS § Example: University Database Conceptual Schema Physical Schema External Schema (View) • Students(sid: string, name: • Relations stored as heap files Students can be allowed to find string, login: string, dob: string, • Index on first column of out course enrollments: gpa: real) Students • Course_info(cid: string, • Courses(cid: string, enrollment: integer) cname: string, credits: integer) Can be computed from the relations in • Enrolled(sid: string, cid: string, the conceptual schema (so as to avoid grade: string) data redundancy and inconsistency).

Iterating: Data Independence § One of the most important benefits of using a DBMS is data independence § With data independence, application programs are insulated from how data are structured and stored § Data independence entails two properties: § Logical data independence: users are shielded from changes in the conceptual schema (e. g. , add/drop a column in a table) § Physical data independence: users are shielded from changes in the physical schema (e. g. , add index or change record order)

Queries in a DBMS § The “ease” (plus efficiency & effectiveness) with which information can be queried from a database determines its value to users § A DBMS provides a specialized language, called the query language, in which queries can be posed § The relational model supports powerful query languages § Relational calculus: a formal language based on mathematical logic § Relational algebra: a formal language based on a collection of operators (e. g. , selection and projection) for manipulating relations § Structured Query Language (SQL): § Builds upon relational calculus and algebra § Allows creating, manipulating and querying relational databases § Can be embedded within a host language (e. g. , Java)

Concurrent Execution and Transactions § An important task of a DBMS is to schedule concurrent accesses to data so as to improve performance T 1 T 2 R(A) W(A) R(B) W(B) An atomic sequence of database actions (read/writes) is referred to as “transaction” R(C) W(C) § When several users access a database concurrently, the DBMS must order their requests carefully to avoid conflicts § E. g. , A check might be cleared while account balance is being computed! § DBMS ensures that conflicts do not arise via using a locking protocol § Shared vs. Exclusive locks

Ensuring Atomicity § Transactions can be interrupted before running to completion for a variety of reasons (e. g. , due to a system crash) § DBMS ensures atomicity (all-or-nothing property) even if a crash occurs in the middle of a transaction § This is achieved via maintaining a log (i. e. , history) of all writes to the database § Before a change is made to the database, the corresponding log entry is forced to a safe location (this protocol is called Write-Ahead Log or WAL) § After a crash, the effects of partially executed transactions are undone using the log

The Architecture of a Relational DBMS Web Forms Application Front Ends SQL Interface SQL Commands Plan Executer Parser Operator Evaluator Optimizer Transaction Manager Lock Manager Files and Access Methods Buffer Manager Recovery Manager Disk Space Manager DBMS Concurrency Control Database Query Evaluation Engine Index Files Data Files System Catalog

People Who Work With Databases § There are five classes of people associated with databases: 1. End users § Store and use data in DBMSs § Usually not computer professionals 2. Application programmers § Develop applications that facilitate the usage of DBMSs for end-users § Computer professionals who know how to leverage host languages, query languages and DBMSs altogether 3. Database Administrators (DBAs) § § Design the conceptual and physical schemas Ensure security and authorization Ensure data availability and recovery from failures Perform database tuning 4. Implementers § Build DBMS software for vendors like IBM and Oracle § Computer professionals who know how to build DBMS internals 5. Researchers § Innovate new ideas which address evolving and new challenges/problems

The Architecture of a Relational DBMS Web Forms Application Front Ends End Users (e. g. , university staff, travel agents, etc. ) SQL Commands Plan Executer Parser Operator Evaluator Optimizer Transaction Manager Lock Manager SQLApplication Interface Programmers & DBAs Files and Access Methods Implementers and Researchers Buffer Manager Recovery Manager Disk Space Manager DBMS Concurrency Control Database Query Evaluation Engine Index Files Data Files System Catalog

Summary § We live in a world of data § The explosion of data is occurring along the 3 Vs dimensions § DBMSs are needed for ensuring logical and physical data independence and ACID properties, among others § The data in a DBMS is described at three levels of abstraction § A DBMS typically has a layered architecture

Summary § Studying DBMSs is one of the broadest and most exciting areas in computer science! § This course provides an in-depth treatment of DBMSs with an emphasis on how to design, create, refine, use and build DBMSs and real-world enterprise databases § Various classes of people who work with databases hold responsible jobs and are well-paid!

Outline A Primer on Databases Database Design ER Model: Constructs and Constraints ü

Database Design § Requirements Analysis § Users needs § Conceptual Design § A high-level description of the data (e. g. , using the ER model) § Logical Design § The conversion of an ER design into a relational database schema § Schema Refinement § Normalization (i. e. , restructuring tables to ensure some desirable properties) § Physical Design § Building indexes and clustering some tables § Security Design § Access controls

Outline A Primer on Databases Database Design ER Model: Constructs and Constraints ü

Entities and Entity Sets § Entity: § A real-world object distinguishable from other objects in an enterprise (e. g. , University, Students and Faculty) § Described using a set of attributes § Entity set: § A collection of similar entities (e. g. , all employees) § All entities in an entity set have the same set of attributes (until we consider ISA hierarchies, anyway!) § Each entity set has a key § Each attribute has a domain

Tools and An ER Diagram Entities (‘Entity Sets’) Attributes “ssn” is the ssn primary key, hence, underlined name Employees lot

Relationship and Relationship Sets § Relationship: § Association among two or more entities (e. g. , Mohammad is teaching 15 -415) § Described using a set of attributes § Relationship set: § Collection of similar relationships § Same entity set could participate in different relationship sets, or in different “roles” in the same set

More Tools and ER Diagrams N M Relationships (‘rel. sets’) and mapping constraints P name ssn since name ssn lot Employees dname budget did Works_In Departments lot Employees supervisor subordinate Reports_To A Binary Relationship A Self-Relationship

Ternary Relationships § Suppose that departments have offices at different locations and we want to record the locations at which each employee works § Consequently, we must record an association between an employee, a department and a location since name ssn lot Employees address dname did Works_In Locations budget Departments capacity This is referred to as a “Ternary Relationship” (vs. Self & Binary Relationships)

Key Constraints § Consider the “Employees” and “Departments” entity sets with a “Manages” relationship set § An employee can work in many departments § A department can have many employees § Each. This department can have at mostofone manager restriction is an example a “key constraint” since name ssn dname lot Employees did Manages budget Departments Key constraints are denoted by thin arrows

Cardinalities § Entities can be related to one another as “one-to-one”, “one-tomany” and “many-to-many” § This is said to be the cardinality of a given entity in relation to another One-to-One One-to-Many-to-One Many-to-Many 1 1 1 N N M

Cardinalities: Examples 1 COUNTRY PERSON 1 N STUDENT has owns takes 1 N M CAPITAL CAR SECTION

Cardinalities: Examples COUNTRY Book’s notation: has CAPITAL PERSON owns CAR STUDENT takes SECTION

Cardinalities: Examples 1 COUNTRY Book’s notation vs 1 to N notation PERSON 1 N STUDENT has owns takes 1 N M CAPITAL CAR SECTION

A Working Example § Requirements: Students take courses offered by instructors; a course may have multiple sections; one instructor per section § How to start? § Nouns -> entity sets § Verbs -> relationship sets

. . . name STUDENT ssn issn INSTRUCTOR Primary key = unique identifier underline

. . . name STUDENT c-id ssn c-name COURSE issn INSTRUCTOR But: sections of a course (with different instructors)?

ssn STUDENT c-id s-id issn SECTION INSTRUCTOR COURSE But: s-id is not unique. . . (see later)

ssn STUDENT c-id s-id issn SECTION INSTRUCTOR COURSE Q: how to record that students take courses?

ssn STUDENT N takes M s-id issn SECTION INSTRUCTOR c-id COURSE

STUDENT N takes c-id M s-id SECTION COURSE N teaches 1 INSTRUCTOR

STUDENT N c-id takes M s-id SECTION N teaches 1 INSTRUCTOR N has 1 COURSE

Participation Constraints § Consider again the “Employees” and “Departments” entity sets as well as the “Manages” relationship set § Should every department have a manager? § If so, this is a participation constraint § Such a constraint entails that every Departments entity must appear in an instance of the Manages relationship § The participation of Departments in Manages is said to be total (vs. partial) since name ssn did lot Employees Total participation is denoted by a thick line dname Manages Works_In since budget Departments Total participation + key constraint are denoted by a thick arrow

Total vs. Partial Participations Total, Total COUNTRY has CAPITAL ? ? PERSON owns CAR ? ? STUDENT takes SECTION

Total vs. Partial Participations Total, Total COUNTRY has CAPITAL Partial, Total PERSON owns CAR ? ? STUDENT takes SECTION

Total vs. Partial Participations Total, Total COUNTRY has CAPITAL Partial, Total PERSON owns CAR Partial, Total STUDENT takes SECTION

Weak Entities § A weak entity can be identified uniquely only by considering the primary key of another (owner) entity § § § Owner entity set and weak entity set must participate in a oneto-many relationship set (one owner, many weak entities) Weak entity set must have total participation in this identifying relationship set The set of attributes of a weak entity set that uniquely identifies a weak entity for a given owner entity is called partial key

Weak Entities: An Example § “Dependents” has no unique key of its own § “Dependents” is a weak entity with partial key “pname” § “Policy” is an identifying relationship set § “pname” + “ssn” are the primary key of “Dependents” Partial keys are underlined using broken lines name ssn lot Employees cost Policy pname age Dependents Weak entities and identifying relationships are drawn using thick lines

ISA (`is a’) Hierarchies § Entities in an entity set can sometimes be classified into subclasses (this is “kind of similar” to OOP languages) § If we declare B ISA A, every B entity is also considered to be an A entity name ssn “Employees” is specialized into subclasses lot Employees hourly_wages hours_worked ISA contractid Hourly_Emps Contract_Emps “Hourly_Emps” and “Contract_Emps” are generalized by “Employees”

Overlap and Covering Constraints § Overlap constraints A § Can an entity belong to both ‘B’ and ‘C’? § Covering constraints § Can an ‘A’ entity belong to neither ‘B’ nor ‘C’? B C

Overlap Constraints: Examples § Overlap constraints A § Can John be in Hourly_Emps and Contract_Emps? Intuitively, no § Can John be in Contract_Emps B and in Senior_Emps? Intuitively, yes “Contract_Emps OVERLAPS Senior_Emps” C

Covering Constraints: Examples § Covering constraints § Does every one in Employees belong to a one of its subclasses? Intuitively, no A § Does every Motor_Vehicles B C entity have to be either a Motorboats entity or a Cars entity? Intuitively, yes “Motorboats AND Cars COVER Motor_Vehicles”

More Details on ISA Hierarchies § Attributes are inherited (i. e. , if B ISA A, the attributes defined for a B entity are the attributes for A plus B) § We can have many levels of an ISA hierarchy § Reasons for using ISA: § § To add descriptive attributes specific to a subclass To identify entities that participate in a relationship

Aggregation § Aggregation allows indicating that a relationship set (identified through a dashed box) participates in another relationship set ssn name lot Employees Monitors since started_on pid pbudget Projects until dname did Sponsors budget Departments

Next Class Continue the ER Model and Start with the relational Model