1. The Relational Data Model Database Model (ODL, E/R) Relational Schema Physical storage ODL definitions Diagrams (E/R) Tables: row names: attributes rows: tuples Complex file organization and index structures.

2. Terminology Name Price Category Manufacturer gizmo $19.99 gadgets GizmoWorks Power gizmo $29.99 gadgets GizmoWorks SingleTouch $149.99 photography Canon MultiTouch $203.99 household Hitachi tuples Attribute names

3. More Terminology Every attribute has an atomic type. Relation Schema: relation name + attribute names + attribute types Relation instance: a set of tuples. Only one copy of any tuple! Database Schema: a set of relation schemas. Database instance: a relation instance for every relation in the schema.

4. More on Tuples Formally, a mapping from attribute names to (correctly typed) values: name gizmo price $19.99 category gadgets manufacturer GizmoWorks Sometimes we refer to a tuple by itself: (note order of attributes) (gizmo, $19.99, gadgets, GizmoWorks) or Product (gizmo, $19.99, gadgets, GizmoWorks).

5. Updates The database maintains a current database state. Updates to the data: 1) add a tuple 2) delete a tuple 3) modify an attribute in a tuple Updates to the data happen very frequently. Updates to the schema: relatively rare. Rather painful.

6. From ODL to Relational Schema Start simple: a class definition has only single valued attributes Interface product{ float price; string name; Enum {telephony, gadgets, books} category} Every attribute becomes a relation attribute: Name Price Category Gizmo $19.99 gadgets

7. Adding Non atomic Attributes Name Currency Amount Category Gizmo US$ 19.99 gadgets Power Gizmo US$ 29.99 gadgets Price is a record: {string currency, float amount}

8. Set Attributes Name SSN Phone Number Fred 123-321-99 (201) 555-1234 Fred 123-321-99 (206) 572-4312 Joe 909-438-44 (908) 464-0028 Joe 909-438-44 (212) 555-4000 One option: have a tuple for every value in the set: Disadvantages?

9. Modeling Collection Types How can we model bags? Lists? Fixed length arrays? The problem becomes even more significant if a class has several attributes that are set types? Question: how bad is the redundancy for n set type attributes, each with possibly up to m values? Questions:

10. Modeling Relationships Interface Product { attribute string name; attribute float price; relationship madeBy; } Interface Company { attribute string name; attribute float stock-price; attribute string address; } How do we incorporate the relationship madeBy into the schema?

11. Option #1 Name Price made-by-name made-by-stock-price made-by-address Gizmo $19.99 gizmoWorks 0.0001$ Montezuma What’s wrong?

12. Hint Interface Product { attribute string name; attribute float price; relationship madeBy; } Interface Company { attribute string name; attribute float stock-price; attribute string address; relationship set makes; }

13. Better Solution Name Price made-by-name Gizmo $19.99 gizmoWorks Product relation: (assume: name is a key for company) Company relation: Name Stock Price Address Gizmo $0.00001 Montezuma

14. Additional Issues 1. What if there is no key? 2. What if the relationship is multi-valued? 3. How do we represent a relationship and its inverse?