1. Compe 301 ER - Model

2. Today DBMS Overview Data Modeling Going from conceptual requirements of a application to a concrete data model E/R Model

3. Example Simple Banking Application Need to store information about: Accounts Customers Need to support: ATM transactions Queries about the data Why we can’t use a file-system based solution ?

4. DBMS at a Glance 1. Data Modeling 2. Data Retrieval 3. Data Storage 4. Data Integrity

5. Data Modeling A data model is a collection of concepts for describing data properties and domain knowledge: Data relationships Data semantics Data constraints We will discuss two models extensively in this class Entity-relationship Model Relational Model Probably discuss XML as well

6. Data Retrieval Query = Declarative data retrieval program describes what data to acquire, not how to acquire it Non-declarative: scan the accounts file look for number 55 in the 2 nd field subtract $50 from the 3 rd field Declarative (posed against the tables abstraction): Subtract $50 from the column named balance for the row corresponding to account number 55 in the accounts table How to do it is not specified. Why ? Easier to write More efficient to execute (why ?)

7. Data Storage Where and how to store data ? Main memory ? What if the database larger than memory size ? Disks ? How to move data between memory and disk ? Etc etc…

8. Data Integrity Manage concurrency and crashes Transaction: A sequence of database actions enclosed within special tags Properties: Atomicity: Entire transaction or nothing Consistency: Transaction, executed completely, take database from one consistent state to another Isolation: Concurrent transactions appear to run in isolation Durability: Effects of committed transactions are not lost Consistency: Transaction programmer needs to guarantee that DBMS can do a few things, e.g., enforce constraints on the data Rest: DBMS guarantees

9. Data Integrity Semantic constraints Typically specified at the logical level E.g. balance > 0

10. DBMS at a glance Data Models Conceptual representation of the data Data Retrieval How to ask questions of the database How to answer those questions Data Storage How/where to store data, how to access it Data Integrity Manage crashes, concurrency Manage semantic inconsistencies Not fully disjoint categorization !!

11. Recap Data Models Conceptual representation of the data Data Retrieval How to ask questions of the database How to answer those questions Data Storage How/where to store data, how to access it Data Integrity Manage crashes, concurrency Manage semantic inconsistencies

12. Data Modeling Goals: Conceptual representation of the data “Reality” meets “bits and bytes” Must make sense, and be usable by other people We will study: Entity-relationship Model Relational Model Note the difference !! May study XML-based models or object-oriented models Why so many models ??

13. Motivation You’ve just been hired by Bank of America as their DBA for their online banking web site. You are asked to create a database that monitors: customers accounts loans branches transactions, … Now what??!!!

14. 14 Database Design Steps Three Levels of Modeling info Conceptual Data Model Logical Data Model Physical Data Model Conceptual DB design Logical DB design Physical DB design Entity-relationship Model Typically used for conceptual database design Relational Model Typically used for logical database design

15. Entity-Relationship Model Two key concepts Entities: An object that exists and is distinguishable from other objects  Examples: Ali Canturk, END_Engg, Compe301 Have attributes (people have names and addresses) Form entity sets with other entities of the same type that share the same properties  Set of all people, set of all classes Entity sets may overlap  Customers and Employees

16. 16 ER Diagram: Starting Example Rectangles: entity sets Diamonds: relationship sets Ellipses: attributes customer has cust-street cust-id cust-name cust-city account balance number access-date

17. Rest of the class Details of the ER Model How to represent various types of constraints/semantic information etc. Design issues A detailed example

18. Next: Relationship Cardinalities We may know: One customer can only open one account OR One customer can open multiple accounts Representing this is important Why ? Better manipulation of data If former, can store the account info in the customer table Can enforce such a constraint Application logic will have to do it; NOT GOOD Remember: If not represented in conceptual model, the domain knowledge may be lost

19. Mapping Cardinalities One-to-One One-to-Many Many-to-One Many-to-Many customer has account customer has account customer has account customer has account

20. Next: Types of Attributes Simple vs Composite Single value per attribute ? Single-valued vs Multi-valued E.g. Phone numbers are multi-valued Derived If date-of-birth is present, age can be derived Can help in avoiding redundancy, enforcing constraints etc…

21. Types of Attributes customer has cust-street cust-id cust-name cust-city account balance number access-date

22. Types of Attributes customer cust-street cust-id cust-name cust-city has account balance number access-date phone no. date-of-birth age month dayyear Composite Attribute

23. customer cust-street cust-id cust-name cust-city phone no. age date-of-birth Possible Keys: {cust-id} {cust-name, cust-city, cust-street} {cust-id, age} cust-name ?? Probably not. Domain knowledge dependent !! Entity Keys

24. Superkey any attribute set that can distinguish entities Candidate key a minimal superkey Can’t remove any attribute and preserve key-ness  {cust-id, age} not a candidate key  {cust-name, cust-city, cust-street} is  assuming cust-name is not unique Primary key Candidate key chosen as the key by DBA Underlined in the ER Diagram

25. Entity Keys {cust-id} is a natural primary key Typically, SSN forms a good primary key Try to use a candidate key that rarely changes e.g. something involving address not a great idea customer cust-street cust-id cust-name cust-city phone no. age date-of-birth

26. Relationship Set Keys What attributes are needed to represent a relationship completely and uniquely ? Union of primary keys of the entities involved, and relationship attributes {cust-id, access-date, account number} describes a relationship completely customer has cust-id account number access-date

27. Relationship Set Keys Is {cust-id, access-date, account number} a candidate key ? No. Attribute access-date can be removed from this set without losing key-ness In fact, union of primary keys of associated entities is always a superkey customer has cust-id account number access-date

28. Relationship Set Keys Is {cust-id, account-number} a candidate key ? Depends customer has cust-id account number access-date

29. Relationship Set Keys Is {cust-id, account-number} a candidate key ? Depends customer has cust-id account number access-date If one-to-one relationship, either {cust-id} or {account-number} sufficient Since a given customer can only have one account, she can only participate in one relationship Ditto account

30. Relationship Set Keys Is {cust-id, account-number} a candidate key ? Depends customer has cust-id account number access-date If one-to-many relationship (as shown), {account-number} is a candidate key A given customer can have many accounts, but at most one account holder per account allowed