Data base Management

System
[CoEg3193]

Chapter Two:
Conceptual Level Data Model
 Database Design Stages
1. Requirement Analysis
2. Conceptual Design
3. Implementation (Logical) Design
4. Physical Design
5. Implementation

2
 Requirement Analysis
• The requirement analysis is an investigation
phase, during which all the needed
information are gathered and analyzed.
• Requirement is analyzed and the following
points are identified
– Objects
– Interaction between objects
– User Forms and Reports
– …

3
Example on Requirement Analysis
• The problem is to design a database system
for “X Household and Office Furniture P.L.C”
based on the following information.
– The information are kept on daily basis about what the
employees do, what resource they use, which furniture are
made out of the resource, and all the sale and order
records.
– Furniture is produced by an employee from resource (s).
– Every furniture is described by the furniture Id, catalog no,
model type, color, production start date, production complete date
and price; and every resource is described by stock no, type,
current cost, and avail quantity.
– A sale of furniture is made with a receipt for both regular
customers and buyers.
4
… Example on Requirement Analysis
– Regular customers are described by customer Id, name,
address and contact person; where as, no detail record is
established for buyers.
– Orders for furniture are allowed only for regular
customers and in ordering a furniture, the customer may
pay part of the total price and left in debt, then pay the
debt in some other time.
– For the payment transactions three types of receipt are
used; one for sale, one for order and one for due payment
(debt).
– A single receipt of each type is prepared only for one
buyer or customer but a number of furniture can be sold
or ordered by one receipt.
– Every receipt is prepared by an employee and it has receipt
number, prepared date, total price, and tax.
5
 Conceptual Design
• The two common conceptual models for
Relational Database system are
– Entity – Relationship (E/R) model
– Object-Oriented Data Language (ODL) model

6
Entity – Relationship (E/R)
Data Model

7
Entity – Relationship (E/R) Model
• The E/R data model views the real world as a
set of
– Basic objects (called Entities), and
– Relationships among these objects.
• The three basic notions of the E/R model are:
– Entity
– Relationship
– Attribute

8
 Entity Set
• Entities are usually recognizable concepts,
either concrete or abstract, such as:
– person, company, places, things, or events which have
relevance to the database.
• An Entity Set is then a set consisting of the
same type of entities that share same
properties.
• In the requirement analysis the entities are
recognized by nouns and noun phrases.
9
 … Entity Set
• Entities can be classified as:
– Strong (independent) entity
• One that does not rely on other entities for
identification.
– Weak (dependent) entity
• one that relies on other entities for identification.
• Instance
– Instance also known as Object is an individual
occurrence of an entity set.

10
 Attributes

• Attributes are descriptive properties that are

associated with an entity.
• Value
– Value is a particular instance of an attribute.
• Domain
– The domain of an attribute is the collection of all
possible values an attribute can have.

11
 … Example
– The information are kept on daily basis about what the
employees do, what resource they use, which furniture are
made out of the resource, and all the sale and order
records.
– Furniture is produced by an employee from resource (s).
– Every furniture is described by the furniture Id, catalog no,
model type, color, production start date, production complete date
and price; and every resource is described by stock no, type,
current cost, and avail quantity.
– A sale of furniture is made with a receipt for both regular
customers and buyers.
– Regular customers are described by customer Id, name,
address and contact person; where as, no detail record is
established for buyers.

12
 … Example
– The information are kept on daily basis about what the
EMPLOYEES do, what RESOURCE they use, which
FURNITURE are made out of the resource, and all the
SALE and ORDER records.
– Furniture is produced by an employee from resource (s).
– Every furniture is described by the furniture Id, catalog no,
model type, color, production start date, production complete date
and price; and every resource is described by stock no, type,
current cost, and avail quantity.
– A sale of furniture is made with a RECEIPT for both
REGULAR CUSTOMERS and BUYERS.
– Regular customers are described by customer Id, name,
address and contact person; where as, no detail record is
established for buyers.

13
 … Example
– The information are kept on daily basis about what the
EMPLOYEES do, what RESOURCE they use, which
FURNITURE are made out of the resource, and all the
SALE and ORDER records.
– Furniture is produced by an employee from resource (s).
– Every furniture is described by the furniture Id, catalog
no, model type, color, production start date,
production complete date and price; and every
resource is described by stock no, type, current cost,
and avail quantity.
– A sale of furniture is made with a RECEIPT for both
REGULAR CUSTOMERS and BUYERS.
– Regular customers are described by customer Id, name,
address and contact person; where as, no detail record
is established for buyers.
14
 Classification of Attributes
• Identifiers
– more commonly called keys, uniquely identify an
instance of an entity.
• Descriptor
– describes a non-unique characteristic of an entity
instance.
• Example
– furniture Id
– catalog number, model type, color, …

15
 … Classification of Attributes
• Simple Attributes
– also known as Atomic Attributes that can not
be divided into subparts mainly of primitive
types.
• Composite Attributes
– are composed of smaller subparts that can be
further subdivided into the subparts
(Attributes).
• Example
– Id, type, price, color
– name, address

16
… Classification of Attributes

17
 … Classification of Attributes
• Single-valued Attributes
– are attributes having only one possible value at
any time.
• Multi-valued Attributes
– are attributes that are having possibly more than
one value.
• Example
– Id, name, type, price
– address

18
 … Classification of Attributes
• Derived Attributes
– are attributes that can be calculated from the
related stored attributes, entities or general states.
• Stored Attributes
– are attributes that can not be calculated in any
way from the stored attributes.
• Example
– Age
– Birth Date

19
 Relationship Sets
• A Relationship represents an association between
two or more entities.
• Example
– FURNITURE is produced by an EMPLOYEE
from RESOURCE
• FURNITURE is produced by EMPLOYEE
• FURNITURE is produced from RESOURCE
– A SALE of FURNITURE is made with a RECEIPT
• SALE of FURNITURE is made with RECEIPT

20
 … Relationship Sets
• A Relationship Set is then a set consisting same types of relationships.
• Classification terms in Relationships
– Degree
• number of entities associated with the relationship
– Connectivity
• describes the mapping of associated entity instances in the relationship
• One
• Many
– Cardinality
• the actual number of related occurrences for each of the two entities
– one-to-one
– one-to-many
– many-to-many
– Existence
• denotes whether the existence of an entity instance is dependent upon the
existence of another, related, entity instance
– Mandatory
– Optional
21
 … Relationship Sets
– Cardinality

22
 E/R Diagram
• Rectangles - for the Entity sets,
– Double border Rectangles - for the weak entity sets.
• Ellipses - for the Attributes,
– Double border Ellipses - for the multi-valued attributes.
– Dashed border Ellipses - for the derived attributes.
– Composite attributes are represented by linked ellipses.
• Diamonds - for the Relationships, and
• Lines - for the links between the attributes and the entity sets
and between the entity sets and the relationships.
– Arrow Head Line - for the link between an entity set with
many-to-one relationship.
• The arrow is headed to the one side entity set.

23
 … Example
stockNo cost
availQty CUSTOMERS

RESOURCES
Order cPesr
price custId
catlgNo
color

Produced FURNITURES

EMPLOYEES bDate Sold

age
addrs
empId SALES
name homeAdr phone

24
 Further on E/R Diagram
• Relationship Attributes
– Attribute (s) may be used in some relationships to describe the
relationship further
• Multi-way Relationship
– multi-way relationship can be reduced to a binary relationship with
the use of
• an entity set in place of the relationship, and
• having new relationships for the links in between the participating entity
sets and the relationship.
• Cardinality Limits of a Relationship:
– 0..* or 0..∞ indicating zero or more participation of the entity
– 1..* or 1..∞ indicating one or more participation of the entity
– 0..1 indicating zero or one participation of the entity
– 1..1 indicating exactly one participation of the entity in the
relationship. 25
 . . . Further on E/R Diagram
• Entity Set Roles in a Relationship
– Label on the link line identifies the role
– Example:
• If only two customers are allowed to make an order jointly as Primary and
Secondary
• Participation in a Relationship
– Total
• every element of the entity set is at least related to one element in the other
entity set
– Example:
» The Furniture entity set in the Produced relationship.
– Partial
• There at least one element that is not related to any element in the other set

26
 … Example
stockNo cost
availQty ordDate Primary CUSTOMERS

Secondary
RESOURCES
Order cPesr
price custId
catlgNo
color

Production FURNITURES

1..∞
EMPLOYEES bDate
Sold
age
addrs
empId
SALES
name homeAdr phone 0..1
27
 Design Issues
• Faithfulness
– classes or entity sets and their attributes should reflect reality

• Avoiding Redundancy
– be careful to say everything only once

• Simplicity
– avoid introducing more elements into your design than are absolutely necessary

• Picking the Right kind of Element

– Entity Set versus Attributes
– Entity versus Relationship Sets
– Binary versus n-ary Relationship Sets

28
 …Design Issues
 Use of Entity Set versus Attributes: Generally, of
something has more information associated with it than
just its name, it probably needs to be an entity set. However,
if it has only its name to contribute to the design, then it is
probably better to make it an attribute.
 Entity versus Relationship Sets: Since relationships
represent events there will always be confusion between the
entity sets and relations.
 Binary versus n-ary Relationship Sets: Generally, of
something has more information associated with it than
just its name, it probably needs to be an entity set. However,
if it has only its name to contribute to the design, then it is
probably better to make it an attribute. 29
 Remarks on Designing
• Choose meaningful naming for the entities,
attributes and relationships.
• Use short links.
• Cluster diagram if it has too many entities and
relationships.

30
 Keys and Constraints
• Keys
– are attributes or set of attributes that can be used to uniquely identify an
entity within the entity set
• Single-value constraints
– are requirements that specify a given attribute or set of attributes are unique
in certain context
• Referential integrity constraints
– requirements for an existence of an entity in the database so as it can be
referenced by a certain relationship
• Domain constraints
– are requirements on an attribute value to be in a specified range of values
• Participation constraints
– are assertions whether the participation of an entity in a relationship is total
or partial

31
 Keys
• Keys are attributes or set of attributes that suffice to
distinguish entities from each other.
• Super Key also known as Super Set is then a set of one
or more attributes that can identify an entity uniquely
from the entity set.
– If K is a super set (super key) then a set consisting of
K is also a super set.
• Candidate Key is the minimal super set.
• If the Candidate Key is selected as a key for an entity set
then it said to Primary Key.
• A primary key in E/R model is represented by
underlining the attribute or set of attributes.

32
 Enhanced E/R Modeling
• Weak Entity Set
• Specialization and Generalization
• Aggregation

33
 Weak Entity Set
• weak entity is uniquely identified with the help of
other entity
• The strong entity which contributes its primary key
is called the identifying or owner entity set.
• Criteria for weak entity set
– A one-to-many relationship set that relates the weak
entity set with owner entity set known as identifying
relationship or supporting relationship must exist.
– Total participation in the identifying relationship is
required.

34
 … Week Entity Set
• An attribute or set attributes with in the weak
entity set referred to as discriminator is used to
distinguish weak entities.
• Key of a weak entity set:
– Zero or more of its own attribute;
discriminator
– Key attributes of the owner (identifying)
entity set.

35
 … Week Entity Set
• Notations
– Weak Entity sets are represented by
• Double boarder Rectangles.
– The identifying many-to-one relationship is
represented by
• Double border Diamonds.
– If the entity set has a discriminator then it is
represented by
• Underlining the attribute(s)

36
 … Example (Weak entity sets)

– Each employee may have a number of

Dependents.
Name Descr
Eid Name
Descr

Employee Depenedent on DEPENDANT

• For each dependent, we keep track of their

name, sex, birth date, and relationship to the
employee.
37
 Specialization and Generalization
• Specialization
– top-down process in grouping of entities that are
similar in some way and distinct in some other
ways in which distinctions are made explicitly.
• Generalization
– bottom-up approach in which multiple entity sets
are synthesized into a higher level entity set based
on their common features.

38
… Example (Specialization & Generalization)

EMPLOYEES

ISA

FULL-TIME PART-TIME
EMPLOYEES EMPLOYEES

39
 Constraints on Specialization and
Generalization
• Condition-defined vs. User-defined Lower-level
Entity Sets
– Condition defined
• satisfying an explicit condition or predicate
– User-defined
• determined upon the entry of the entities from the
user irrespective of any constraint.
• Disjoint vs. Overlapping Specialization
– Overlapping
• allows for a higher-level entity to belong to more than
one entity
– Disjoint
40
 Constraints on Specialization and
Generalization
• Total vs. Partial Specialization or
Generalization:
– Total
• Higher level entity must belong to one of the lower-
level entity
– Partial

41
 Aggregation
• E/R modeling allows relationships only
between entity sets.
• A relationship between a relationship and an
entity set or a collection of entity sets?
– Aggregation is an abstraction through which collection
of related entity sets and relationships are treated as high-
level entities.
– It allows indicating for a relationship set (identified
through a box) to participate in another relationship set.

42
 … Example (Aggregation)

FURNITURE Production RESOURCE

Manages

EMPLOYEES

43
Summary of Symbols Used in E-R Notation
Summary of Symbols (Cont.)
Object Definition Language
(ODL) Data Model

46
 Overview
• Object Definition Language (ODL) is an object-
oriented approach in a database design that is
standardized by the ODGM (Object Data
Management Group).
• OOP Concepts
– Complex Types
• Structures (Records), Reference (Pointers) and Collections
– Classes and Objects
• State and Behavior
– Objects Identity
– Inheritance

47
 ODL Design and Syntax
• Elements of ODL Classes
Attributes – which are values associated with the
objects whose types are from the built in primitive
types or a structure of the primitive types.
Relationships – are connections between the
object and another object of some class.
Methods – are functions that may be applied to
objects of the class.

48
 ODL Design and Syntax
• ODL class declaration
– Name for the class
– Optional key declaration(s)
– Extent declaration: - name for the set of
currently existing objects of the class
– Element declarations: - An element is either an
attribute, a relationship, or a method.

49
 ODL Design and Syntax
• Declaration
class <name> {
<list of element declarations, separated by
semicolons>
};
– Attribute
attribute <type> <name>;
attribute enum <typename>
{<enumlist1>, <enumlist2>,…}<name>;
attribute struct <typename>
{<type> <name1>, <type> <name2>,…}<name>;
– Relationship
relationship <type> <name>
inverse <relationship>;
50
 … ODL Design and Syntax
• Example
class Employee {
attribute string empId;
attribute string name;
attribute integer age;
attribute enum Gender {Male, Female} gender;
attribute struct Address {string city, string hAddr,
string phone} address;
relationship <Production> works_in;
:
};

51
 Cont’d
• REMARK:
– The names for the enumerated and structured
data types are not necessary for the declaration
but giving the name helps to refer to the type
outside the class declaration using the scoped
name such as, “Employees::Gender” and
“Employees::Address”.

52
 Relationships
• Inverse Relationships
– Unlike E/R design the relationships in ODL
model are only binary. Hence for every
relationship in class C there is an inverse
relationship in the related class D.
• Suppose class C has a relationship R to class D, then
class D must have some relationship S to class C. R and
S must then be true inverses. That is; if object d is
related to object c by R, then c must be related to d by
S.
– Inverse phrase is used to indicate.
53
 Relationships
• Multiplicity of Relationships
– Many-to-many relationships, indicated by
Set<…> for the type of the relationship and its
inverse
– One-to-many relationships, have Set<…> in the
relationship of the “one” and just the class for
the relationship of the “many.”
– One-to-one relationships, have classes as the type
in both directions

54
 … Relationships
• Example
class Furnitures {
attribute string catlgNo;
attribute real price;
attribute integer age;
attribute enum Color {Mogolo, Wood} color;
relationship Set <Production> produced_in
inverse Production::produce;
relationship <Customer> ordered_by
inverse Customer::order;
relationship <Sale> sold_in
 inverse Sale::sell;
}; 55
 … Relationships
• Example:
class Production {
:
relationship Set <Furniture> produce
inverse Furniture::produced_in;
};

class Customer {
:
relationship Set <Customer> order
inverse Customer::ordered_by;
};

class Sale {
:
relationship Set <Furniture> sell
 inverse Sale:: sold_in;
}; 56
 Inheritance
• Inheritance in is indicated by the colon
operator “:”
class <Subclass>:<Superclass> {
<list of element declarations>
};
• Example
class Chair:Furniture {
attribute integer noLegs;
attribute boolean arm;
:
};
57
 Keys in ODL

• Declaration
(key <list of keys>)

• Extent
(extent <extent name> key <list of keys>)

• Example
class Employee (extent Employees key empId, nationalId, (name, bDate)) {
attribute string empid;
attribute string name;
:
relationship <Production> works_in;
inverse Production::having;
: 58
};
- End -

59