The Entity/Relationship Model

In the entity-relationship model (or E/R model), the structure of the data is represented
graphically, as an "entity-relationship diagram", using three principle element types:

1. Entity sets
2. Attributes
3. Relationships

Entity Sets

An entity is an abstract object of some sort, and a collection of similar entities forms an
entity set.

An entity in some ways resembles an "object" in the sense of object-orientated

programming.

Example

Consider the design of a movie-database.

Each movie is an entity, and the set of all movies constitutes an entity set.

The stars are entitites, and the set of stars is an nentity set.

A studio is another entity, and the set of studios is a third entity set.

Attributes

Entity sets have associated attributes which are properties of the entities in that set.

For instance, the entity set Movies might be given attributes such as title, and length.

The attributes for the entity set Movies resembles the attributes of the relation Movies. It
is common for entity sets to be implemented as relations, although not every relation in
our final relational design will come from an entity set. Assume that attributes are of
primitive type, such as strings, integers, or reals.

Relationships
Relationships are connections among two or more entity sets.

For instance, if Movies and Stars are two entity sets, we could have a relationship Stars-
in that connects movies and stars.

The intent is that a movie entity m is related to a star entitys by the relationship Stars-in
if s appears in movie m.

While binary relationships, those between two entity sets, are by far the most common
type of relationship, the E/R model allows relationships to involve any number of entity
sets.

Entity-Relationship Diagrams

An E/R diagram is a graph representing entity sets, attributes, and relationships.

Elements of each of these kinds are represented by nodes of the graph and we use a
special shape of node to indicate the kind as follows:

• Entity sets are represented by rectangles

• Attributes are represented by ovals
• Relationships are represented by diamonds

Edges connect an entity set to its attributes and also connect a relationship to its entity
sets.

Example
 The Movies entitiy sets has four attributes: title, year, length, and genre. The other
two entity sets Stars and Studios happen to have the same two attributes: name
and address.

There are two relationships in the diagram:

1. Stars-in is a relationship connecting each movie to the stars of the movie. This
relationship also connects stars to the movie in ehich they appear
2. Owns conencts each movie to the studio that own the movies. The arrow
pointing to entity set Studios indicates that each movie is owned by at most one
studio

Instances of an E/R Diagram

We may imagine that a database described by an E/R diagram contains particular data,
am "instance" of the database. Since the database is not implemented in the E/R model,
only designed, the instance never existed in the sense that a relation's instances exist in
a DBMS.

Multiplicity of Binary E/R Relationships

In general, a binary relationship can connect any member of one of its entity sets to any
number of members of the other entity set.

Suppose R is a relationship connecting entity sets E and F.

• If each member of E can be connected by R to at most one member of F, then we say

that R is many-one from E to F.
• If R is both many-one from E to F and many-one from F to E, then we say that R is
one-one
• If R is neither many-one from E to F or from E to F then we say R is many-many
Multiway Relationships

For a particular star and movie there is only one studio with which the star has
contracted for that movie.

A studio may contract with several stars for a movie, and a star may contract with one
studio for more than one movie.

Roles in Relationships

It is possible that one entity set appears two or more times in a relationship.

If so we draw as many lines from the relationship to the entity set ass the entity set
appears in the relationship.

Each line to the entity set represents a different role that the entity set plays in the
relationship. We label the edges between the entity set and relationship by names, which
are called roels

We assume that movie may have many squeals, but for each sequel there is only one
original movie.
Subclasses in the E/R Model

Often an entity set contains certain entities that have special properties not associated
with all members of the set.

Special-case entity sets, or subcalsses each with its own special attributes and/or
relationships.

An isa is a special kind of relationship to emphasize that uses a tringle.

Referential Integrity

A value existing in one context must also exist in another.

A rounded arrow entering Studios from relationship Owns: every movie must be owned by
one studio, and this studio is present in the Studios entity set.

A rounded arrow entering Studios from Runs: every president runs a studio that exists in
the Studios entity set

Weak Entity Sets

It is possible for an entity set's key to be composed of attributes, some or all of which
belong to another entity set. Such an entity set is called a weak entity set
Causes of Weak Entity Sets

1. Sometimes entity sets fall into a hierarchy based on classifications unrelated to the
"isa hierarchy". If entities of set E are subunits of entities in set F, then it is possible
that names of E-entities are not unique until we take into account the name of F-
entity to which the E entity is subordinate.
2. It is a way to eliminate multiway relationships. These relationships have no attributes
of their own. Their key is formed from the attributes that the key attributes for the
entity sets they connect.

Requirements for Weak Entity Sets

If E is a weak entity set then its key consists of:

1. Zero or more of its own attributes

2. Key attributes from entity sets that are reached by certain many-one relationships
from E to entity sets. These many-one relationships are called supporting
relationships for E, and the entity sets reached from E are supporting entity sets.

From E/R Diagrams to Relational Designs

 • Turn each entity set into a relation with same set of attributes
• Replace a relationship by a relation whose attributes are the keys for connected
entity sets

1. Weak entity sets cannot be translated straightforwardly to relations

2. "Isa" relationships and subclasses require careful treatment
3. Sometimes we do well to combine two relations, especially the relation for an entity
set E and the relation that comes from a many-one relationship from E to some other
entity set

From Entity Sets to Relations

Relationships in the E/R model are also represented by relations. The relation for a given
relationship R has the following attributes:

• For each entity set involved in relationship R, we take its key attribute or attributes as
part of the schema for the relation R
• If the relationship has attributes, then these are also attributes of relation R
Handling Weak Entity Sets

1. The relation for the weak entity set W itself must include not only the attributes of W
but also the key attributes of the supporting entity sets. The supporting entity sets
are easily recognized because they are reached by supporting (double-diamond)
relationships from W.
2. The relation for any relationship in which the weak entity set W appears must use as
a key for W all of its key attributes, including those of other entity sets that
contribute to 1-V's key.
3. However, a supporting relationship R, from the weak entity set W to a supporting
entity set, need not be converted to a relation at all. The justification is that, as
discussed in Section 4.5.3, the attributes of manyone relationship R's relation will
either be attributes of the relation for W, or (in the case of attributes on R) can be
added to the schema for W's relation.

Converting Subclass Structures to

Relations
When we a have an isa-hierarchy assume that:

• There is a root entity set for the hierarchy

• This entity set has a key that servers to identify every entity represented by the
hierarchy
 • A given entity may have components that belong to the entity sets of any subtree of
the hierarchy, as long as the subtree includes the root

!! Principle Conversion Strategies:

1. Follow the E/R viewpoint. For each entity set E in the hierarchy, create a
relation that includes the key attribute form the root and any attributes
belonging to E
2. Treat entities as object belonging to a single class. For each possible
subtree that includes the root create one relation, whose schema includes
all the attributes of all the entity sets in the subtree
3. Use null values. Create one relation with all the attributes of all the entity
sets in the hierarchy. Each entity is represented by one tuple, and that
tuple has a null value for whatever attributes the entity does no have

E/R-Style Conversion

1. Movies(title, year, length, genre).

2. MurderMysteries(title, year, weapon).
3. Cartoons(title, year).
4. Voices(title, year, starName)
An Object-Orientated Approach

1. Movies alone.
2. Movies and Cartoons only.
3. Movies and Murder-Mysteries only.
4. All three entity sets.

Movies(title, year, length, genre)

MoviesC(title, year, length, genre)

MoviesMM(title, year, length, genre, weapon)

MoviesCMM(title, year, length, genre, weapon)

Voices(title, year, starName)

Using Null Values

Movie(title, year, length, genre, weapon)

Unified Modeling Language

UML offers much the same capabilities as the E/R model, with the exception of multiway
relationships. UML also offers the ability to treat entity sets as true classes with methods
as well as data

UML Classes

A class in UML is similar to an entity set in the E/R model

Keys for UML classes

The letters PK stand for primary key

Associations

A binary relationship between classes is called an association. There is no multiway

relationship in UML. Rather a multiway relationship has to broken into binary
relationships.
Every association has constraints on the number of objects from each of its classes that
can be connected to an object of the other class. We indicate these constraints by a
label of the form m .. n at each end. The meaning of this label is that each object at the
other end is connected to at least m and at most n objects at this end.

• A * in place of n, as in m .. *, stands for "infinity." That is, there is no upper limit.

• A * alone, in place of m .. n, stands for the range 0 .. *, that is, no constraint at all on
the number of objects.
• If there is no label at all at an end of an association edge, then the label is taken to be
1..1, i.e., "exactly one."
• The label 1..1 says exactly what the rounded arrow in E/R diagrams says.
• The label 1..* at the Movies end of Owns says that each studio must own at least one
movie
Association Classes

In UML, we create a new class, called an association class, and attach it to the middle of
the association.

Subclasses

Any UML class can have a hierarchy of subclasses below it. The primary key comes from
the root of the hierarchy, just as with E/R hierarchies. UML permits a class C to have four
different kinds of subclasses below it, depending on our choices of answer to two
questions:
1. Complete versus Partial. Is every object in the class C a member of some subclass?
If so, the subclasses are complete; otherwise they are partial or incomplete.
2. Disjoint versus Overlapping. Are the subclasses disjoint (an object cannot be in two
of the subclasses)? If an object can be in two or more of the subclasses, then the
subclasses are said to be overlapping.

• In a typical object-oriented system, subclasses are disjoint. That is, no object can be
in two classes. Of course they inherit properties from their parent class, so in a
sense, an object also "belongs" in the parent class. However, the object may not also
be in a sibling class.
• The E/R model automatically allows overlapping subclasses.
• Both the E/R model and object-oriented systems allow either complete or partial
subclasses. That is, there is no requirement that a member of the superclass be in
any subclass.

From UML Diagrams to Relations

UMML-to-Relations Basics

• Classes to Relations. For each class, create a relation whose name is the name of the
class, and whose attributes are the attributes of the class.
• Associations to Relations. For each association, create a relation with the name of
that association. The attributes of the relation are the key attributes of the two
connected classes. If there is a coincidence of attributes between the two classes,
rename them appropriately. If there is an association class attached to the
 association, include the attributes of the association class among the attributes of
the relation.

Subclasses

1. If a hierarchy is disjoint at every level, then an object-oriented representation is

suggested. We do not have to consider each possible tree of subclasses when
forming relations, since we know that each object can belong to only one class and
its ancestors in the hierarchy. Thus, there is no possibility of an exponentially
exploding number of relations being created.
2. If the hierarchy is both complete and disjoint at every level, then the task is even
simpler. If we use the object-oriented approach, then we have only to construct
relations for the classes at the leaves of the hierarchy.
3. If the hierarchy is large and overlapping at some or all levels, then the E/R approach
is indicated. We are likely to need so many relations that the relational database
schema becomes unwieldy.

Object Definition Language (ODL)

ODL (Object Definition Language:) is a text-based language for specifying the structure
of databases in object-oriented terms.

Class Declerations

class <name> {

<list of properties>

};

Attributes
Relationships in ODL

An ODL relationship is declared inside a class declaration

relationship Set<Star> stars