1. Modeling Constraints
Extracting constraints is what modeling is all about. But how do
we express them?
Examples:
Keys: social security number uniquely identifies a person.
Single-value constraints: a person can have only one father.
Referential integrity constraints: if you work for a company, it
must exist in the database.
Domain constraints: peoples’ ages are between 0 and 150.
Why are these constraints useful in the implementation?

2. Single Value Constraints
An entity (or object) may have at most one value for a given
attribute or relationship.
Person: name, social-security number
Company: stock price
How do we do this in ODL?
In E/R, every attribute has at most one value.
Arrows tell us about multiplicity of relations.
If we have a single-valued constraint, we can either:
1. Require that the value exist (see referential integrity shortly)
2. Allow null values.

3. Referential Integrity Constraints
A relationship has one value and the value must exist.
Example:
Product madeBy Company: company must exist.
How do we enforce referential integrity constraints? (otherwise,
we get dangling pointers)
- forbid to delete a reference object, or
- delete the objects that reference an object we’re deleting.
In E/R diagrams:
makes 
Company
Product

4. Weak Entity Sets
Entity sets are weak when their key attributes come from other
classes to which they are related.
This happens if:
- part-of hierarchies
- splitting n-ary relations to binary.
affiliation
Team
University
sport
number
name

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

6. Terminology Attribute names Product table
Name Price Category Manufacturer
gizmo $ gadgets GizmoWorks
Power gizmo $ gadgets GizmoWorks
SingleTouch $ photography Canon
MultiTouch $ household Hitachi
tuples
What can’t you say in the relational model?

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

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

9. 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. Why?

10. 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}
Class becomes a relation, and every attribute becomes a relation attribute:
Product
Name Price Category
Gizmo $ gadgets

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

12. Set Attributes Interface person{ string name; integer SSN;
set of integers Phone Number;}
One option: have a tuple for every value in the set:
Name SSN Phone Number
Fred (201)
Fred (206)
Joe (908)
Joe (212)
Disadvantages?

13. Modeling Collection Types
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:
How can we model bags?
Lists?
Fixed length arrays?

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

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

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

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

18. 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?

19. From E/R Diagrams to Relational Schema
Easier than ODL (using a liberal interpretation of the word “easy”)
- relationships are already independent entities
- only atomic types exist in the E/R model.
Entity sets relations
Relationships relations
Special care for weak entity sets.

20. name
category
name
price
makes
Company
Product
Stock price
buys
employs
Person
name
ssn
address

21. Entity Sets to Relations
name
category
price
Product
Product:
Name Category Price
gizmo gadgets $19.99

22. Relationships to Relations
price
name
category
Start Year
name
makes
Company
Product
Stock price
Relation Makes (watch out for attribute name conflicts)
Product-name Product-Category Company-name Starting-year
gizmo gadgets gizmoWorks

23. Handling Weak Entity Sets
affiliation
Team
University
sport
number
name
Relation Team:
Sport Number Affiliated University
mud wrestling Montezuma State U.
- need all the attributes that contribute to the key of Team
- don’t need a separate relation for Affiliation.

24. Modeling Subclass Structure
Product
ageGroup
topic
Platforms
required memory
isa
isa
Educational
Product
Software
Product
isa
isa
Educ-software
Product
Educational-method

25. Option #1: the ODL Approach
4 tables: each object can only belong to a single class
Product(name, price, category, manufacturer)
EducationalProduct( name, price, category, manufacturer, ageGroup,
topic)
SoftwareProduct( name, price, category, manufacturer, platforms,
requiredMemory)
EducationalSoftwareProduct( name, price, category, manufacturer,
ageGroup, topic, platforms,

26. Option #2: the E/R Approach
Product(name, price, category, manufacturer)
EducationalProduct( name, ageGroup, topic)
SoftwareProduct( name, platforms, requiredMemory)
No need for a relation EducationalSoftwareProduct
Unless, it has a specialized attribute:
EducationalSoftwareProduct(name, educational-method)

27. Option #3: The Null Value Approach
Have one table:
Product ( name, price, manufacturer, age-group, topic, platforms,
required-memory, educational-method)
Some values in the table will be NULL, meaning that the attribute
not make sense for the specific product.
How many more meanings will NULL have??