CS 325 - Week 5 Lecture 2 - 2016-09-22
* CONTINUING with intro to entity-relationship
modeling, part 1
* we discussed entity classes and entities;
* next: ATTRIBUTES or PROPERTIES
* describe entity CHARACTERISTICS that are
important to the users in a scenario
* one classic way of depicting is to
put each in an oval attached by a
line to the entity class rectangle
it is for
* ...we aren't doing that!!
we'll use a list format, putting
the entity class, a line,
and list its attributes/properties
one per line,
on the page near the rectangle
or at the bottom of the page
or on the next page if necessary
...but in any case, they ARE part of the
E/R model!
* canceptually,
an attribute/property CAN be simple or
composite,
or single-valued or multi-valued;
* simple or composite?
* simple attribute - cannot be subdivided
(or don't ever care to in the scenario)
* composite - can be subdivided
a Name attribute
might include a last name, first
name, etc.
* to make future detailed queries
easier, we tend to change these
to a series of
simple attributes --
Last name, First name,
etc.
* single- or multi-valued?
* single-valued - each instance
of an entity class can have
AT MOST ONE value
for a single-valued attribute/property
* multi-valued - AN instance
of an entity class MIGHT
have MORE THAN ONE value
for that attribute/property
BE CAREFUL -- when you say an
attribute is multi-valued,
you are saying that for ONE
entity instance, that instance
could have multiple values for
THAT attribute
(a given movie disk might
have multiple languages-supported,
French AND Spanish AND Japanese...)
* for OUR class E/R models,
we'll MARK multi-valued attributes
with an:
(MV)
...after their name in the
entity class' attribute list
* JUST list attributes for characteristics
of instances of THIS entity class...
* another wrinkle:
IDENTIFYING attributes --
Identifiers
* each instance of an entity class
has IDENTITY -- it is separate
from the other instances
how do those in the scenario
TEND to tell them apart
(even if IMPERFECTLY?)
...we'll write the names of such
IDENTIFYING ATTRIBUTES in all-uppercase
in the entity class' attributes list
(and some entity classes have NO
identifying attributes --
ok, because they are identified by
their relationships...!)
* RELATIONSHIPS!
* a relationship is an association
among several entity instances
...a relationship class is an association
between entity classes
(people tend to just say relationship
and let the context tell whether
it is a relationship class or instance...)
* OK -- theoretically,
these can be between any number of
entity classes,
BUT for Relational databases
we'll break these all down
into BINARY relationships,
between TWO entity classes
* we'll give a NAME to each relatioship,
(can be based on a verb,
or some combo of the entity class names,
or some combo of the above,
DON'T make them all the same!!)
in an ERD,
you DRAW a relationship by drawing a line
with a diamond on it between the
related entity classes,
and put its name on or near the
diamond
* NEXT: MAXIMUM cardinalities and
MINIMUM cardinalities!