DATABASE ANALYSIS
An entity is something in the real world, which is distinguishable from other objects,
which we want to model. It is often useful to identify a collection of similar entities. Such
a collection is called an entity set. Note that the entity sets need not be disjoint. An entity
is described using a set of attributes. All entities in a given entity set have the same
attributes; this is essentially what we mean by similar. The choice of attributes reflects
the level of detail at which we want to represent information about entities. For each
attribute associated with an entity set, we should identify a domain of possible values.
A simple attribute is composed of a single component with an independent existence. A
composite attribute is composed of multiple components each with an independent
existence. A single-valued attribute holds a single value for each occurrence of an entity
type. A multi-valued attribute holds multiple values for each occurrence of an entity
type. A derived-attribute represents a value that is derivable from the value of a related
attribute or set of attributes, not necessarily in the same entity. A key is the minimum set
of attributes whose values uniquely a particular entity in the entity set. There could be
more than one candidate for the key; if so, we designate one of them as the primary key.
Each entity set should contain at least one set of attributes that uniquely identifies an
entity in the entity set; that is, the set of attributes contains a key. A composite key is a
key which consists of two or more attributes. A relationship is an association among two
or more entities. As with entities, we may want to collect a set of similar relationships
into a relationship set. Note that several relationship sets may involve the same entity
sets. The entity sets that participate in a relationship need not be distinct; a relationship
may involve two entities in the same entity set.
Compare to OO analysis………
A class is a generic description of an entity (it describes an entity set) and includes
attributes (properties)
behavior (methods)
relationships (associations)
to other classes
Relationships are represented via connections between attributes directly or indirectly
thru methods. An object is one particular instance of a class
DB analysis……………………
Table meta data is a generic description of an entity (it describes an entity set) and
includes
attributes
behavior
relationships
between other tables
Relationships are represented via connections between attributes (FK, PK, etc) or thru
procedures which operate on the tables. A row (tuple) is one particular instance of the
table meta data.
In a typical relational DB the attributes and relationships are stored together as part of the
table meta data. The behaviors are stored separately as stored procedures, triggers etc.
In an OO DB the behaviors are stored as part of the table meta data. Thus attributes,
behavior and relationships are all encapsulated into a single unit. It is also possible to
descend new tables from old ones (inheritance).
Fundamental entity/relationship Analysis
(1)Strong entity types
Create a table that includes all simple attributes of that entity.
For composite attributes, include only constituent simple attributes.
(2) Weak entity types
Create a table that includes all simple attributes of that entity.
Primary key is partially or fully derived from each owner entity.
(3) 1:* binary relationship types
Entity on ‘one side’ is designated the parent table and entity on ‘many side’
is the child table.
Post copy of the primary key attribute(s) of parent entity into
table representing child entity, to act as a foreign key.
(4) 1:1 binary relationship types
More complex as cardinality cannot be used to identify parent and child entities
in a relationship.
Instead, participation used to decide whether to combine entities into one table
or to create two tables and post copy of primary key from one table to the other.
Consider following:
(a) mandatory participation on both sides of 1:1 relationship;
(b) mandatory participation on one side of 1:1 relationship;
(c) optional participation on both sides of 1:1 relationship.
(a) Mandatory participation on both sides of 1:1 relationship
Combine entities involved into one table and choose one of the primary keys
of original entities to be primary key of new table, while other
(if one exists) is used as an alternate key.
(b) Mandatory participation on one side of a 1:1 relationship
Identify parent and child entities using participation constraints.
Entity with optional participation is designated parent entity, and other entity
designated child entity.
Copy of primary key of parent placed in table representing child entity.
If relationship has one or more attributes, these attributes should follow the posting
of the primary key to the child table.
(c) Optional participation on both sides of a 1:1 relationship
Designation of the parent and child entities is arbitrary unless can find out more
about the relationship.
(5) 1:1 recursive relationships - follow rules for participation for a 1:1 relationship.
mandatory participation on both sides: single table with two copies of the primary key.
mandatory participation on only one side: option to create a single table
with two copies of the primary key, or create a new table to represent the relationship.
The new table would only have two attributes, both copies of the primary key.
optional participation on both sides, again create a new relation as described above.
(6) Superclass/subclass relationship types
Identify superclass as parent entity and subclass entity as child entity.
There are various options on how to represent such a relationship as one or more tables.
Most appropriate option dependent on number of factors such as:
disjointness and participation constraints on the superclass/subclass relationship,
whether subclasses are involved in distinct relationships,
number of participants in superclass/subclass relationship.
(7) *:* binary relationship types
Create table to represent relationship and include any attributes that are part of
relationship. This is an intersection table.
Post a copy of the primary key attribute(s) of the entities that participate in relationship
into new table, to act as foreign keys.
These foreign keys will also form primary key of the new table, possibly in combination
with some of the attributes of the relationship.
(8) Complex relationship types
Create table to represent relationship and include any attributes that are part of
the relationship.
Post copy of primary key attribute(s) of entities that participate in the complex
relationship into new table, to act as foreign keys.
Any foreign keys that represent a ‘many’ relationship (for example, 1..*, 0..*)
generally will also form the primary key of new table, possibly in combination with
some of the attributes of the relationship.
(9) Multi-valued attributes
Create new table to represent multi-valued attribute and include primary key
of entity in new table, to act as a foreign key.
Unless the multi-valued attribute is itself an alternate key of the entity,
primary key of new table is combination of the multi-valued attribute and
the primary key of the entity.