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.

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

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.

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).

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.

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

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

Set Attributes Name SSN Phone Number Fred (201) Fred (206) Joe (908) Joe (212) One option: have a tuple for every value in the set: Disadvantages?

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:

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?

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

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; }

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 $ Montezuma

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?