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.
As a general rule, 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.
11
DATABASE SYSTEMS, 13TH EDITION
Translating Business Rules into Data
Model Components

For example, the business rule “a customer may

generate many invoices” contains two nouns
(customer and invoices) and a verb (generate) that
associates the nouns. From this business rule, you
could deduct that:
Customer and invoice are objects of interest for
the environment and should be represented by
their respective entities.
There is a “generate” relationship between
customer and invoice.
12
DATABASE SYSTEMS, 13TH EDITION
 Translating Business Rules into Data
Model Components
To properly identify the type of relationship, you
should consider that relationships are
bidirectional; that is, they go both ways.
For example, the business rule “a customer may
generate many invoices” is complemented by the
business rule “an invoice is generated by only
one customer.”
In that case, the relationship is one-to-many
(1:M). Customer is the “1” side, and invoice is the
“many” side.
13
DATABASE SYSTEMS, 13TH EDITION
Translating Business Rules into Data
Model Components
In short
Nouns translate into entities
Verbs translate into relationships among entities
How Relationships are bidirectional
Two questions to identify the relationship type:
 How many instances of B are related to one instance
of A?
 How many instances of A are related to one instance of
B?

14
DATABASE SYSTEMS, 13TH EDITION
Translating Business Rules into Data
Model Components
For example, you can assess the relationship
between student and class by asking two
questions:
 In how many classes can one student
enroll? Answer: many classes.
 How many students can enroll in one class?
Answer: many students.

15
DATABASE SYSTEMS, 13TH EDITION
Translating Business Rules into Data
Model Components
Therefore, the relationship between student and
class is many-to-many (M:N). You will have many
opportunities to determine the relationships
between entities as you proceed through given
contents and soon the process will become
second nature.

16
DATABASE SYSTEMS, 13TH EDITION
Translating Business Rules into Data Model
Components:
To properly identify the type of relationship, you
should consider that relationships are bidirectional;
that is, they go both ways.
For example, the business rule “a customer may
generate many invoices” is complemented by the
business rule “One of many invoices is generated by
only one customer.”
In that case, the relationship is one-to-many (1:M).
Customer is the “1” side, and invoice is the
“many” side.
17
DATABASE SYSTEMS, 13TH EDITION
The Evolution of Data Models

18
DATABASE SYSTEMS, 13TH EDITION
Database Models: Historic
Overview
Flat files - 1960s - 1980s
Hierarchical – 1970s - 1990s
Network – 1970s - 1990s
Relational – 1980s - present
Object-oriented – 1990s - present
Object-relational – 1990s - present
Data warehousing – 1980s - present
Web-enabled – 1990s - present
19
DATABASE SYSTEMS, 13TH EDITION
Hierarchical Database Model
Logically represented by an upside down tree
Each parent can have many children
Each child has only one parent

20
DATABASE SYSTEMS, 13TH EDITION
Hierarchical Database Model
Advantages
 Conceptual simplicity
 Database security and integrity
 Data independence
 Efficiency
Disadvantages
 Complex implementation
 Difficult to manage and lack of standards
 Lacks structural independence
 Application programming and use complexity
 Implementation limitations
21
DATABASE SYSTEMS, 13TH EDITION
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.

22
DATABASE SYSTEMS, 13TH EDITION
Network Database Model
Each record can have multiple parents
 Composed of sets
 Each set has owner record and member record
 Member may have several owners

23
DATABASE SYSTEMS, 13TH EDITION
Network Model
The lack of database standards was troublesome
to programmers and application designers
because it made database designs and
applications less portable.
To help establish database standards, the
Conference on Data Systems Languages
(CODASYL) created the Database Task Group
(DBTG) in the late 1960s. The DBTG was charged
to define standard specifications for an
environment that would facilitate database
creation and data manipulation.
24
DATABASE SYSTEMS, 13TH EDITION
Network Model
The final DBTG report contained specifications
for three crucial database components:
The schema, which is the conceptual
organization of the entire database as viewed
by the database administrator. The schema
includes a definition of the database name, the
record type for each record, and the components
that make up those records.

25
DATABASE SYSTEMS, 13TH EDITION
Network Model
The subschema, which defines the portion of the
database “seen” by the application programs that
actually produce the desired information from the
data contained within the database.
The existence of subschema definitions allows all
application programs to simply invoke the
subschema required to access the appropriate
database file(s).
A data management language (DML) that defines
the environment in which data can be managed.
26
DATABASE SYSTEMS, 13TH EDITION
Network Model
To produce the desired standardization for each of the
three components, the DBTG specified three distinct
DML components:
A schema data definition language (DDL), which
enables the database administrator to define the
schema components.
-A subschema DDL, which allows the application
programs to define the database components that will
be used by the application.
-A data manipulation language to work with the data
in the database. 27
DATABASE SYSTEMS, 13TH EDITION
Network Database Model
Advantages
◦ Conceptual simplicity
◦ Handles more relationship types
◦ Data access flexibility
◦ Promotes database integrity
◦ Data independence
◦ Conformance to standards
Disadvantages
◦ System complexity
◦ Lack of structural independence
28
DATABASE SYSTEMS, 13TH EDITION