1. Structure Part 2.

A Set of Integrity Rules

 consists of a set of rules  to ensure the data
that define how the accuracy
database is to be built
3. Manipulative Part
 to define the types of
operation that allowed on
Data Model the data

1) to represent data & make the data understandable

2) to design a database
 It represents the data requirements of an organization.
 You can diagrammatically show a data model with symbols
and figures.
 Data for an organization reside in a database.
 Therefore, when designing a database, you first create a
data model.
 Three (3) broad categories of data models:
 Object-based data models
 Record-based data models
 Physical data models

 The object-based and record-based data models are used

to describe data at the conceptual and external levels.

 The physical data models is used to describe data at the

internal level.
 External level: The user’s view of the database. It describes
that part of the database that is relevant to a particular user.

 Conceptual level: It is a complete view of the data

requirements of the organization. It describes what data is
stored in the database and the relationships among the data.

 Internal level: It covers the physical implementation of the

database to achieve optimal run-time performance and
storage space utilization. It describes how the data is stored
in the database.
 There are four (4) types of object-based data models:
 Entity-relationship
 Semantic
 Functional
 Object-oriented

 There are three (3) types of record-based logical data model:

 Relational data model
 Network data model
 Hierarchical data model
 The relational data model is based on the concept of
mathematical relations.

 In the network data model, data is represented as collections

of records and relationships as represented by sets.

 In the hierarchical data model, data is represented as

collections of records and relationships are represented by
sets. It can be represented as a tree graph, with records
appearing as nodes, also called segments, and sets as edges.
 top-down approach to database design
 start ER modeling by:
1) identify the important data called entities
2) identify the relationships between the data
3) add more details such as the information we want to
hold about the entities & relationships called attributes
4) add any constraints on the entities, relationships and
attributes
 a set of objects with the same properties, which are
identified by a user or organization as having an
independent existence
 an entity can represent objects with a physical (or “real”)
existence or with a conceptual (or “abstract”) existence
 physical existence: staff, property, supplier
 conceptual existence: sale, registration, rental
 entity occurrence: a uniquely identifiable object within a
set
 each entity is shown as a rectangle labeled with the name
of the entity which is normally a singular noun
 example:
Staff
 2 types of entities:
 strong entity: each entity occurrence is uniquely
identifiable using the primary key attribute(s) of that entity
type
 weak entity: each entity occurrence cannot be uniquely
identified using only the attributes associated with that
entity type
 example:
 we can only uniquely identify each preference through the
relationship that a preference has with a client who is
uniquely identifiable using the primary key for the Client
entity type, clientNo

Staff Preference
clientNo (PK)
name states

fName
lName
 composite entity:
1) it is composed of the primary keys of each of the entities to
be connected
2) It may also contain additional attributes that play no role in
the connective process
 when to use it?
 If M : N relationships are connected, we must create a bridge
between the entities that display such relationships
 relationship: a set of meaningful associations among
participating entities
 each relationship is given a name that describes its function
 for example: an Actor entity is associated with the Role
entity through a relationship called Plays

Actor plays Role

 each relationship is shown as line connecting the associated
entities labeled with the name of the relationship
 a relationship is named using a verb
 a relationship name should be unique for a given ER model
 a property of an entity or relationship
 it represent what we want to know about entities
 for example: a Staff entity may be described by the StaffId,
StaffName, Position attributes
 5 types of attributes:
1) simple
2) composite
3) single-valued
4) multi-valued
5) derived
 simple:
 cannot be further subdivided
 example: category, price, position, salary, subjectTitle
 composite:
 can be further divided to result smaller components
 example:
1) name attribute can be subdivided into fName, lName
2) address attribute can be subdivided into street, city, postcode,
state
 single-valued:
 majority of attributes are single-valued
 example:
1) catalogNo attribute with 1233 value
2) staffNo attribute with E100 value
3) subjectCode attribute with CS1103 value
 multi-valued:
 some attributes have multiple values for a particular entity
 example:
1) studentCategory attribute (Diploma, Degree)
2) telNo attribute (03-1233 3333, 03-4566 3333)
3) courseCategory attribute (DipBC, DipCS, DipIT)
 derived:
 An attribute that represents a value that is derivable
from the value of a related attribute, or set of attributes,
not necessarily in the same entity
 example:
1) age attribute value is derived from DOB attribute
2) totalStudent attribute can be calculated by counting the total
number of Student entity occurences
3) durationProj attribute can be calculated by counting the
startDate and endDate of project
 multiplicity: the number (or range) of possible occurrences
of an entity type that may relate to a single occurrence of
an associated entity type through a particular relationship
 It limits the number of entity occurrences that relate to
other entity occurrences through a particular relationship
 = policies (business rule) established by user or organization
 example:
1) a member of staff manages a branch (1:1)
2) a branch has members staff (1:M)
3) newspapers advertise properties for rent (M:N)
 one-to-one (1:1) relationships
1) a member of staff manages a branch
 each branch is managed by one member of staff
 a member of staff can manage zero or one branch

1 1
Staff manages Branch
 one-to-many (1:M) relationships
1) a branch has members staff
 each member of staff works at one branch
 each branch has one or more staff

1 1…*
Branch has Staff
 many-to-many (M:N) relationships
1) newspapers advertise properties for rent
 each property for rent is advertised in zero or more
newspapers
 each newspapers advertises one or more properties
for rent

1…* 1…*
Newspaper advertises PropertyForRent
 multiplicity = cardinality + participation
 cardinality: describes the maximum of number of possible
relationship occurrences for an entity participating in a
given relationship type
 participation: determines whether all or only some entity
occurrences participate in a relationship
 connection traps
 It occurs due to a misinterpretation of the meaning of
certain relationships
 to identify connection traps we must ensure that the
meaning of relationship (and the business rule that it
represents) is fully understood and clearly defined
 2 main types:
1) fan traps
2) chasm traps
 fan trap: where a model represents a relationship between
entity types, but the pathway between certain entity
occurrences is ambiguous
 fan traps can be resolved by restructuring the original Entity
Relationship (ER) model to represent the correct
association between the involved entities
 chasm trap: where a model suggest the existence of a
relationship between entity types, but the pathway does
not exist between certain entity occurrences
 It may occur where there are one or more relationships with
a minimum multiplicity of zero forming part of the pathway
between related entities
 chasm traps can be resolved by adding a relationship
between related entities
 super-classes:
 an entity type that includes one or more distinct sub-
groupings of its occurrences, which require to be
represented in a data model
 sub-classes:
 an distinct sub-grouping of occurrences of an entity
type, which require to be represented in a data model
 each member of a subclass is also a member of the super-
class;
 but has a distinct role
 for example:
 Staff (super-class) / Manager (sub-class)
 concepts of super-class & sub-class is important:
 reasons:
1) to avoid describing similar concepts more than once
thereby more readable and saving time
2) it adds more semantic information to the design in a
form that is familiar to many people
 for example:
1) “Manager IS-A member of staff”
2) “Flat IS-A type of property”
 attribute inheritance:
 is a process by which a member of a subclass may
posses subclass-specific attributes, and inherit those
attributes associated with the super-class
 attribute inheritance:
 for example:
 a member of the SalesPersonnel subclass inherits all
the attributes of the Staff superclass such as staffNo,
name, position and salary and;
 specially associated with the SalesPersonnel subclass
such as salesArea, and carAllowance
 specialization:
 the process of maximizing the differences between
members of an entity by identifying their distinguishing
characteristics
 top-down approach
 try to identify differences between members of the
entity such as members with unique attributes and / or
relationships
 generalization:
 the process of minimizing the differences between
entities by identifying their common characteristics
 bottom-up approach
 try to identify similarities between the entities such as
common attributes and relationships
 constraints on specialization / generalization:
 2 types of constraints:
1) participation constraint
2) disjoint constraint
 participation constraint
 determine whether every occurrence in the super-class
must participate as a member of a subclass
 it may be mandatory or optional
 participation constraint:
 it specifies that every entity occurrence in the super-
class must also be a member of a subclass
 example:
1) vehicle specialization /generalization (Van, Bus, and
Car) has mandatory participation
 which means that every vehicle must be a van, bus
or car
 participation constraint:
 example:
2) job role specialization /generalization has optional
participation
 which means that a member of staff need not
have an additional job role such manager,
secretary or sales personnel
 disjoint constraint:
 describes the relationship between members of the
subclasses and indicates whether it’s possible for a
member of a super-class to be a member of one, or
more than one, subclass
 only applies when a super-class has more than one
subclass
 It may disjoint or non-disjoint
 example of disjoint:
 if the subclasses of the contract of employment
specialization/generalization is disjoint, which means
that a member of staff must have a full-time
permanent or a part-time temporary contract, but
not both
 disjoint constraint:
 example of non-disjoint:
 if the job role specialization / generalization is non-
disjoint, which means that an entity occurrence can
be a member of both the Manager, SalesPersonnel
and Secretary subclasses
 identify the super-class as the parent entity and the
subclass as the child entity
Example:
 Tables to represent the Staff specialization/ generalization
 Staff superclass
 Staff(staffNo, name, position, salary, branchNo)
Primary Key staffNo
Foreign Key branchNo references Branch(branchNo)
 Staff subclasses
 AllStaffSubclasses(subclassStaffNo, bonus, salesArea,
carAllowance, typingSpeed, staffNo)
Primary Key subclassStaffNo
Foreign Key subclassStaffNo references Staff(staffNo)
 Guidelines to represent super-class/ subclass
relationship
Participation Disjoint constraint Table required
constraint
Mandatory Nondisjoint {And} Single table

Optional Nondisjoint {And} Two table: one table for super-

class and one table for all
subclasses
Mandatory Disjoint {Or} Many tables: one table for each
combined super-class/subclass
Optional Disjoint {Or} Many tables: one table for each
super-class and one table for each
subclass
 Data model
 Concepts of ER Model
 Connection traps
 Concepts of EER Model