Chapter 3: Topic 1 essential in assuring data

Entity Relationship Model integrity in an information

system.
Business Rules
2. Data rather than processes are
 Business rules are derived from the most complex aspects of
policies, procedures, events, many modern information
functions, and other business objects, systems and hence require a
and state constraints on the central role in structuring system
organization. requirements. Often the goal is to
 Business rules are important in data provide a rich data resource that
modeling because they govern how might support any type of
data are handled and stored. information inquiry, analysis, and
 Basic business rules are data names summary.
and definitions. 3. Data tend to be more stable than
e.g: Entity (Customers), Attributes the business processes that use
(Customer Name), Relationship that data. Thus, an information
(Customer Places Orders) system design that is based on a
data orientation should have
Entity Relationship Model longer useful life than one based
 The ER model remains the on a process orientation.
mainstream approach for conceptual Overview of Database Design
data modeling.
 ER model is a tool for  The database design process can be
communications between database divided into six steps. The ER model
designers and users during the is most relevant to the first three
analysis phase of database steps.
development. 1. Requirement Analysis:
 The E-R model is used to construct a  What data is to be stored in the
conceptual data model, which is a database.
representation of the structure and  What applications must be built
constraints of a database. on top of it.
 According to Chen (1976) he  We must find out what the users
described entity-relationship model want from the database.
as the main constructs of E-R model 2. Conceptual Database Design:
entities and relationship and their  To develop a high-level
associated attribute. description of the data to be
 According to Hoffer, George, and stores in the database.
Valacich (2002)  These are the entity types,
1. The characteristics of data relationships and constraints.
captured during data modeling 3. Logical Database Design:
are crucial in the design of  Actual implementation of
databases, programs, and other database design.
system components. The facts  Converting the conceptual
and rules captured during the database design into a database
process of data modeling are
 schema in the data model of the
chosen DBMS(MySql).
DATABASE DESIGN PROCESS
 The task in the logical design step
is to convert an ER schema into a
relational database schema
4. Schema Refinement:
 To analyze the collection of
relations in our relational
database schema to identify
potential problems, and to refine
it.
 Schema refinement can be guided
by some elegant and powerful
theory. (Normalization)
5. Physical Database Design:
 Typical expected workloads that
our database must support and The Entity Relationship (ER) Data
further refine the database design Model
to ensure that it meets desired  It is a detailed, logical representation
performance criteria. of the data for an organization or for
 Simply involve building indexes a business area.
on some tables and clustering  It is expressed in
some tables, or it may involve a  terms of entities in the business
substantial redesign of parts of environment, the relationships (or
the database schema obtained associations) among those entities,
from the earlier design steps. and the attributes (or properties) of
6. Security Design: both the entities and their
 We identify different user groups relationships.
and different roles played by  It is normally expressed as an entity-
various users. relationship diagram (or E-R
 (e.g., the development team for a diagram), which is a graphical
product, the customer support representation of an E-R model.
representatives, the product
manager). Entity, Attributes, and Domain
 We must identify the parts of the
 ENTITY
database that they must be able
 A person, a place, an object, an event,
to access and the parts of the
or a concept in the user environment
database that they should not be
about which the organization wishes
allowed to access, and take steps
to maintain data
to ensure that they can access
 Entity Type – is a collection of entities
only the necessary parts.
that have the same attributes.
  Start with the result and do not make
the design more complex that it
TIPS OF IDENTIFYING ENTITY
needs to be.
 Nouns and verbs used will be  Find exceptions – it is important to
candidate entities identify all the exceptions: you must
design the system to handle as many
Example: “Customer buys products. exceptions as you can without
Employee sells products. Suppliers sell us confusing users.
products.”  NOTE: Attributes do not have to be
 The Nouns: “Customer, Products, recognized and defined during the
Employees, and Suppliers” are all early stages of entity definition.
clearly entities. Entity definition is an iterative
 The Verb: “buy and sell” are also process, and it is unlikely that a
entities. completely satisfactory Entity-
 Input forms, reports and procedures Relationship Model will be obtained
manual are also good sources of on the first iteration.
candidate entities. CATEGORIES OF ATTRIBUTES
 A review for completeness and
consistency must be done after  Descriptive Attributes – provide
identifying your initial entities. facts intrinsic to each instance of the
 You need to find for duplicates and entity.
distinct entities that are
For example, the Salary of Employee or
masquerading as the same entity.
the Address of Customer.
Entity, Attributes, and Domain
 Naming Attributes – provide facts
 ATTRIBUTES about arbitrary labels and names
 Each entity type has a set of carried by each instance of an entity.
attributes associated with it.
For example, the Employee Name of
 An attribute is a property or
Employee or the Employee ID of
characteristic of an entity type that is
Employee.
of interested to the organization.
Each attribute must have a domain.  Referential Attributes (Foreign
keys) – provide facts which tie an
instance of one entity to an instance
of another entity.

TIPS OF IDENTIFYING For example, the Department Number of

ATTRIBUTES the Department to which an Employee
is assigned ties the Employee to the
 Think of anything that would Department.
describe the entity. Items that
describe the entity and that need to TYPES OF ATTRIBUTE:
be stored.
 Simple and composite attributes –
 Think of the data flows passed by the
Simple attributes are attributes that
external entities
cannot be divided into subparts while
 a composite attributes can be divided
into subparts.
 Single-valued, Null and multi-
valued attributes – Single-valued  Rectangle – represent entity sets
attribute has only one value while a  Ellipses – represent attributes
Null might have a zero value and  Diamonds – represent relationship
multi valued has more than one sets
values.  Lines – links attributes to entity sets
 Derived attribute – are attributes and entity sets to relationship sets
that can be derived from the values of  Double Ellipses – represent multi-
other related attributes or entities valued attributes
using calculations, algorithms or  Dashed Ellipses – denote derived
procedures. attributes
 Primary key Attributes are
Entity, Attributes, and Domain
underlined
 DOMAIN - Specifies the kind of data
represented by the attribute. It is a
set of all possible values that an
attribute may validly contain.

TIPS OF IDENTIFYING DOMAIN MODELING RELATIONSHIP

 List all possible values (e.g., for an  Relationships are the glue that holds
attribute named color, possible together the various components of
values are red, green, blue, etc). an E-R model.
 Identify source (e.g., procedures  A relationship is an association
manual) that contains the valid representing an interaction among
values. the instances of one or more entity
 List an acceptable range of values for types that is of interest to the
the domain (e.g., for an attribute organization.
named weight, possible values range  A relationship type is a meaningful
from one to five pounds) association between (or among)
 Define a business rule that permits entity types.
determination of validity of a value DEGREE OF RELATIONSHIP
assigned to an attribute (e.g.,
discount greater than five percent  The degree of a relationship is the
only apply to commercial customers) number of entity types that
participate in that relationship.
SAMPLE ENTITY DEFINITION  The three most common relationship
degrees in E-R models are unary
 (degree 1), binary (degree 2), and  Consider an entity-relationship
ternary (degree 3). model for a university database. You
 A unary relationship is a relationship might have a "Course" entity and a
between the instances of a single "Section" entity. The "Section" entity
entity type. Unary relationships are might be a weak entity because it
also called recursive relationships. cannot be uniquely identified by its
 A binary relationship is a relationship own attributes alone; it depends on
between the instances of two entity the combination of the course
types and is the most common type of identifier and the section number.
relationship encountered in Data The course identifier and section
modeling. number together form a composite
primary key for the "Section" entity,
and they are also attributes of the
owning "Course" entity.
 In this example, the "Course" entity is
the owner, and the "Section" entity is
 A ternary relationship is a the weak entity. The identifying
simultaneous relationship among the relationship between them is
instances of three entity types. A represented in the ER diagram,
typical business situation that leads indicating that the section is
to a ternary relationship is shown. identified by its relationship with a
 Vendors can supply various parts to specific course.
warehouses. The relationship Mandatory (Required) and
Supplies is used to record the specific Optional Attributes
parts that are supplied by a given
vendor to a particular warehouse.  A required attribute is an attribute
that must have a value; in other
words, it cannot be left empty.
 An optional attribute is an attribute
that does not require a value;
therefore, it can be left empty.
 Example: Student Last Name and
First Name is a required data while
Middle Name can be left empty.
Keys in ERD Model

Symbols used in ER Diagram  It is used to uniquely identify any

record or row of data from the table.
It is also used to establish and
identify relationships between tables.
 Types of Keys:
1. Candidate Key
2. Primary Key
3. Foreign Key
Strong Entity VS. Weak Entity
Candidate Key, Primary Key and  It reflects business rule that many
Foreign Key entities can be associated with just
one entity.
 Candidate Key
 For example, Student enrolls for only
 An attribute or group of attributes
one Course but a Course can have
that identifies a unique row in a
many Students.
relation. One of the candidate key is
chosen to be the Primary Key.
 Primary Key
Many to Many Relationship (M: N)
 Any of the candidates that is selected
to be the key or an attribute that  One student may belong to more than
uniquely identifies each row in a one student organizations, and one
relation organization can admit more than
 Foreign Key one student.
 An attribute in one table whose
values must match the primary key in
another table. ERD NOTATIONS
CARDINALITY  Creation of an ERD requires the
 Cardinality - The degree of choice of specific set of notations,
relationship (cardinality) is which the best suits for your
represented by characters “1”, “N” or database design.
“M” usually placed at the ends of the  Two Notations:
relationships. 1. Chen’s Notations
2. Crow’s Notations
One to One Relationship (1:1)
Chen’s Notation
This type of relationship is rarely seen in
real world.  The first standard notation for ERD
was proposed by Chen. Chen's
notation is very rich on the data
modeling tools and standard notation
 The example describes that one
symbols and elements for drawing
student can enroll only for one course
easy understandable Entity-
and a course will also have only one
relationship diagrams, Attribute
Student. This is not what you will
diagrams, Decomposition charts,
usually see in real-world
which are especially popular for
relationships.
designing relational databases.
One to Many Relationship (1: N)

 The example describes that one

student can enroll many courses but
course can only have 1 student.
Many to One Relationship (N:1)
Chen’s Notation Example

Crow’s Foot Notation

 Crow's Foot notation proposed by

Gordon Everest represents the entity
by rectangle containing its name
(name must be unique within this
model), and relation - by the line
which links two entities involved in
relationship.
 The originator of Crow’s Foot Crow’s Foot Notation Example
notation offered the idea of how to
visually represent the different types
of relationships that can exist
between objects in an entity
relationship diagram (ERD).  A Student assigned in Courses. A
student must be assigned to at least
one or more Courses.
 Each course is taught by a single
Professor. To maintain instruction
quality, a Professor can deliver only
one course.