MODULE 2:

Data Modelling and Data

Models
  DATA MODELLING
 DATA MODEL
 IMPORTANCE OF DATA MODELS

TOPICS:  DATA MODEL BASIC BUILDING BLOCKS

 BUSINESS RULES
 THE EVOLUTION OF DATA MODELS
 DEGREES OF DATA ABSTRACTION
 DATA MODEL:

 is a relatively simple representation, usually

graphical, of more complex real-world data
structures

DEFINITION:
DATA MODELLING:

 the first step in designing a database, refers to

the process of creating a specific data model for
a determined problem domain.
  is a clearly defined area within the

real world environment,

Problem with well-defined scope and
Domain boundaries
that is to be systematically
addressed.
  In general terms, a model is an abstraction of a
more complex real-world object or event.

 A model’s main function is to help you understand

the complexities of the real-world environment.

Model  Within the database environment, a data model

represents data structures and their

characteristics, relations, constraints,

transformations, and other constructs with the
purpose of supporting a specific problem domain.
 Traditionally, database designers relied on good
judgment to help them develop a good data model.
Unfortunately, good judgment is often in the eye of
the beholder, and it often develops after much trial and
error.
 Different individuals may come up with a different
model. Which one would be the correct one?
The simple answer is
“the one that meets all the end-user requirements,”
and there may be more than one correct solution!
 THE IMPORTANCE
OF DATA MODELS

Data models can facilitate interaction among the

designer, applications programmer, and end user
 THE IMPORTANCE
OF DATA MODELS

A well-developed data model can even foster improved understanding of the

organization for which the database design is developed.
 THE IMPORTANCE
OF DATA MODELS

In short, data models are a communication tool.

  The data model is also detailed
enough to be used by the database
developers as a “blueprint” for
building the physical database.

1:  The information contained in a data

model will be used to define the
relational tables, the primary and the
foreign keys, stored procedures, and
triggers.
  A poorly designed database will
require more time in the long-run.
Without a careful planning you

2:
may:
1. create a database that omits data required to create
critical reports,
2. produces results that are incorrect or inconsistent,
and is
3. unable to accommodate changes in user’s
requirements
DATA MODEL BASIC
BUILDING BLOCKS
The basic building blocks of all data
models are entities, attributes,
relationships, and constraints.
  Entities are the principal data object about
which information is to be collected. Entities
are usually recognizable concepts, either
concrete or abstract, such as person, places,
Entities things, or events which have relevance to the
(tables) database.
 Some specific examples of entities are:
noun  EMPLOYEES
 PROJECTS
 CUSTOMER  PURCHASE ORDER
 ORGANIZATION  CUSTOMER ORDER
 PRODUCT
 INVOICES
  An attribute is a characteristic of an entity. For
example, a CUSTOMER entity would be
described by attributes such as customer last
name, customer first name, customer phone,
customer address, and customer credit limit.
Attributes Attributes are the equivalent of fields in file
(columns) systems.

 Attributes describe the entity of which they are

associated. i.e., properties used to distinguish
one entity instance from another.
  A Relationship represents an
association between two or more
entities. An example of a
relationship would be:
Relationships employees are assigned to projects
projects have subtasks departments
Managers manage one or more
projects
  Relationships are classified by their
degree, connectivity,
Relationships cardinality, direction,
type, and existence.
Not all modeling methodologies use
all these classifications.
  The connectivity of a relationship describes the
mapping of associated entity instances in the
relationship. The values of connectivity are
Connectivity "one" or "many".
and
Cardinality:  The cardinality of a relationship is the actual
number of related occurrences for each of the
two entities.
The basic types of connectivity for relations
are: one-to-one, one-to- many, and many to-
many.
One-to-many (1:M or 1..*) relationship.

A painter paints many different paintings, but each one of them is painted by only one
painter. Thus, the painter (the “one”) is related to the paintings (the “many”).

Therefore, database designers label the relationship “PAINTER paints PAINTING” as

1:M. (Note that entity names are often capitalized as a convention so they are easily
identified.)

Similarly, a customer (the “one”) may generate many invoices, but each invoice (the
“many”) is generated by only a single customer.
The “CUSTOMER generates INVOICE” relationship would also be labeled 1:M.
Many-to-many (M:M or *..*) relationship.

An employee may learn many job skills, and each job skill may be learned by many
employees.

Database designers label the relationship “EMPLOYEE learns SKILL” as M:M.

Similarly, a student can take many classes and each class can be taken by many students,
thus yielding the M:M relationship label or the relationship expressed by “STUDENT
takes CLASS.”
One-to-one (1:1 or 1..1) relationship.

A retail company’s management structure may require that each of its stores be managed
by a single employee.

In turn, each store manager, who is an employee, manages only a single store.

Therefore, the relationship “EMPLOYEE manages STORE” is labeled 1:1.

  A constraint is a restriction placed on the data.
Constraints are important because they help to
ensure data integrity. Constraints are normally
expressed in the form of rules.
For example:
 An employee’s salary must have values that are
Constraint between 6,000 and 350,000.
 A student’s GPA must be between 0.00 and
4.00.
 Each class must have one and only one teacher.
  A business rule is a brief, precise, and
unambiguous description of a policy,
procedure, or principle within a specific
organization.
Business Rules
 apply to any organization, large or small—a
business, a government unit, a religious group, or a
research laboratory—that stores and uses data to
generate information.
  derived from a detailed description of an
organization’s operations, help to create and
enforce actions within that organization’s
environment.
Business Rules
 must be rendered in writing and updated to reflect
any change in the organization’s operational
environment.
Examples of business rules are as follows:
 
1. A customer may generate many invoices. (BR) = ERD
ENTITY = noun/table
**ATTRIBUTES = charac. adj
RELATIONSHIP = verb
connectivity = 1:1 / 1:M / M:M
cardinality = actual number
 
 
2. An invoice is generated by only one customer.

ENTITY = noun/table = singular CAPITALIZE

**ATTRIBUTES = charac. adj
RELATIONSHIP = active verb
connectivity = 1:1 / 1:M / M:M
cardinality = actual number
A training session cannot be scheduled for fewer than 10 employees or for more than 30
employees.
Discovering Business Rules

The main sources of business rules are company managers, policy makers,
department managers, and written documentation such as a company’s
procedures, standards, or operations manuals. A faster and more direct
source of business rules is direct interviews with end users.
Translating Business Rules into Data Model Components

Business rules set the stage for the proper identification of entities, attributes,
relationships, and constraints. In the real world, names are used to identify objects. If
the business environment wants to keep track of the objects, there will be specific
business rules for them.

A noun in a business rule will translate into an entity in the model, and
 
A verb (active or passive) associating nouns will translate into a relationship
among the entities.
 “a customer may generate many invoices”

“a customer may generate many invoices” is complemented

by the business rule “an invoice is generated by only one
customer.”
Write 10 Business Rules for the Following Case:
1. Enrollment System (Azure)
2. Point of Sale System (CouchDB)
3. Voting System (Informix)
4. Library Management System (MongoDB)
5. Attendance monitoring system (MySQL)
6. Payroll System (Oracle)
7. Inventory system (Sybase)
8. Online booking system (Teradata)
9. Customer relation management system
10. Learning management system

Identify the Entities and Relationships in each

Business Rules
THE EVOLUTION OF DATA MODELS
The Hierarchical Model
developed in the 1960s to manage large amounts of data for complex
manufacturing projects such as the Apollo rocket that landed on the moon in
1969.

Its basic logical structure is represented by an upside-down tree.

A segment is the equivalent of a file system’s record type.

The Network Model

The network model was created to represent complex data relationships more
effectively than the hierarchical model, to improve database performance, and to
impose a database standard.

In the network model, the user perceives the network database as a collection of
records in 1:M relationships. However, unlike the hierarchical model, the network
model allows a record to have more than one parent.

In network database terminology, a relationship is called a set. Each set is composed

of at least two record types: an owner record and a member record.

A set represents a 1:M relationship between the owner and the member.
The Relational Model
The relational model was introduced in 1970 by E. F. Codd (of IBM) in his landmark paper
“A Relational Model of Data for Large Shared Databanks” ( Communications of the ACM,
June 1970, pp. 377−387). The relational model represented a major breakthrough for both
users and designers.

a relation (sometimes called a table) as a matrix composed of intersecting rows and

columns. Each row in a relation is called a tuple. Each column represents an attribute.
The relational model also describes a precise set of data manipulation constructs based on
advanced mathematical concepts.

The relationship type (1:1, 1:M, or M:N) is often shown in a relational schema, an example
of which is shown in Figure 2.4.

A relational diagram is a representation of the relational database’s entities, the

attributes within those entities, and the relationships between those entities.
Peter Chen first introduced the ER data model in 1976; it was the graphical representation of
entities and their relationships in a database structure that quickly became popular because it
complemented the relational data model concepts.

The relational data model and ERM combined to provide the foundation for tightly structured
database design. ER models are normally represented in an entity relationship diagram
(ERD), which uses graphical representations to model database components.

The ER model is based on the following components:

 
 Entity. Earlier in this chapter, an entity was defined as anything about which data are to
be collected and stored. An entity is represented in the ERD by a rectangle, also known as
an entity box
 
 Relationships. Relationships describe associations among data. Most relationships
describe associations between two entities. When the basic data model components were
introduced, three types of relationships among data were illustrated: one-to-many (1:M),
many-to-many (M:N), and one-to-one (1:1). The ER model uses the term connectivity to
label the relationship types.
 
The Object-Oriented (OO) Model
both data and their relationships are contained in a single structure known as an object.
In turn, the OODM is the basis for the object-oriented database management system (OODBMS).
 
The OO data model is based on the following components:
 
 An object is an abstraction of a real-world entity. In general terms, an object may be
considered equivalent to an ER model’s entity.
 
 Attributes describe the properties of an object
 Objects that share similar characteristics are grouped in classes. A class is a collection of
similar objects with shared structure (attributes) and behavior (methods). A class’s method
represents a real-world action
 Classes are organized in a class hierarchy. The class hierarchy resembles an upside-down
tree in which each class has only one parent.
 Inheritance is the ability of an object within the class hierarchy to inherit the attributes and
methods of the classes above it. For example, two classes, CUSTOMER and EMPLOYEE, can be
created as subclasses from the class PERSON. In this case, CUSTOMER and EMPLOYEE will
inherit all attributes and methods from PERSON.
DEGREES OF DATA ABSTRACTION

In the early 1970s, the American National Standards Institute

(ANSI) Standards Planning and Requirements Committee (SPARC)
defined a framework for data modeling based on degrees of data
abstraction. The ANSI/SPARC architecture (as it is often referred
to) defines three levels of data abstraction: external, conceptual,
and internal.
The External Model
The external model is the end users’ view of the data environment. The term end users refers
to people who use the application programs to manipulate the data and generate information.

The Conceptual Model

The conceptual model represents a global view of the entire database as viewed by the entire
organization.

The Internal Model

The internal model is the representation of the database as “seen” by the DBMS. In other
words, the internal model requires the designer to match the conceptual model’s
characteristics and constraints to those of the selected implementation model.

The Physical Model

The physical model operates at the lowest level of abstraction, describing the way data are
saved on storage media such as disks or tapes. The physical model requires the definition of
both the physical storage devices and the (physical) access methods required to reach the data
within those storage devices, making it both software- and hardware dependent.