Introduction to business

information system
Data Model
Chapter 8
Data Models
• Data Model:
• A set of concepts to describe the structure of a database, the operations for
manipulating these structures, and certain constraints that the database should
obey.
• Data Model Structure and Constraints:
• Constructs are used to define the database structure
• Constructs typically include elements (and their data types) as well as groups of
elements (e.g. entity, record, table), and relationships among such groups
• Constraints specify some restrictions on valid data; these constraints must be
enforced at all times
Data Models
• Data Model Operations:
• These operations are used for specifying database retrievals and updates by
referring to the constructs of the data model.
• Operations on the data model may include basic model operations (e.g.
generic insert, delete, update) and user-defined operations (e.g.
compute_student_gpa, update_inventory)
Categories of Data Models
• Conceptual (high-level) data models:
• Provide concepts that are close to the way many users perceive data.
• (Also called entity-based or object-based data models.)
• Physical (low-level) data models:
• Provide concepts that describe details of how data is stored in the computer.
These are usually specified in an ad-hoc manner through DBMS design and
administration manuals
• Implementation (representational) data models:
• Provide concepts that fall between the above two, used by many commercial
DBMS implementations (e.g. relational data models used in many commercial
systems).
Categories of Data Models
Uses of Data Model
• The entities and concepts are defined by using this model. All the
important entities and relationships are initially find out by using this
model.
• The project scope is defined by a conceptual data model. By defining
the project scope the time scheduling and time management can be
properly managed.
• The conceptual data model is used to get a high-level understanding of
the system throughout the complete software development lifecycle. By
using the conceptual model the business executives and business
managers can understand the system easily and will get a high level of
knowledge about the system.
Uses of Data Model
• Let us see some of the uses of data models which are as follows:
• It is used to represent all the data objects in the database accurately. If any data is
omitted it can create problems while performing database operations.
• The data model helps to represent the data in logical and physical levels. ‘
• The relational tables, foreign and primary keys are all defined by the data models.
• The data redundancy can be eliminated from the database as the data model can easily
identify the redundant data. The data models can also be used to identify the missing
data and can take appropriate actions according to that.
• As the data models help to represent the data virtually the developers use this virtual
representation to create an actual database from that.
• Using the data models while creating the database helps to maintain the database and
helps to upgrade the database with fewer efforts.
What is Conceptual Data Model?
• It is used to provide information about business rules and business
concepts that can be developed by business domain people. This
model is used to define the relationship and the data entities which
are used by the model. The entity can be defined as a real-world
object whereas the relationship is the dependency between any two
entities.
What is Conceptual Data Model?
• As the conceptual data model is of high level it usually not contains
attributes in its structure. This model is used to define the relationship
among the data entities but does not provide information about
cardinality properties. The aim of the conceptual data model is to
define a model that is independent of any database management
system or any database technology. This model is usually constructed
initially which covers the initial requirements and also contains high-
level concepts for defining the business structures.
Components of ER Model:

• Entity: An entity is referred to as a real-world object. It can be a

name, place, object, class, etc. These are represented by a rectangle
in an ER Diagram.
• Attributes: An attribute can be defined as the description of the
entity. These are represented by Ellipse in an ER Diagram. It can be
Age, Roll Number, or Marks for a Student.
• Relationship: Relationships are used to define relations among
different entities. Diamonds and Rhombus are used to show
Relationships.
Characteristics of a conceptual
data model
• Offers Organization-wide coverage of the business concepts.
• This type of Data Models are designed and developed for a business
audience.
• The conceptual model is developed independently of hardware
specifications like data storage capacity, location or software
specifications like DBMS vendor and technology. The focus is to
represent data as a user will see it in the “real world.”
Data Flow Diagram

Data Flow Diagram: Developed By Larry Constantine as a way of expressing system requirements
in graphical Form:

 Data Flow Models (DFMs) are easy to understand and, with a little practice, reasonably quick and
straightforward to develop

 They consist of two parts: a set of Data Flow Diagrams (DFDs) and a set of associated textual
descriptions

 … that provide us with the truly effective tool for understanding the information processes of a
system
Objectives of Data Flow Diagram

 To define what is meant by structured analysis.

 To define the symbols used in a Data Flow Diagram (DFD).

 To draw a context diagram (Level 0 DFD) for a given scenario.

 To refine a DFD to a more detailed (lower-level) view.

Using Data Flow Diagrams
 structured approach - take a top-down approach to system development.

 system is defined first at a general level – overview.

 successive refinement occurs until the bottom (primitive) levels are defined.

 primitive level - point where specifications can be translated into lines of

code.

 So...system is decomposed into small modules that perform simple tasks.

Structured Development

 definition is from top to bottom in increasing levels of detail.

 major flows and processes identified .

 These are exploded into subprocesses.

 Subprocesses are exploded into more detail.

 This process can continue to the primitive level, where programming

begins directly from the exploded diagram.
Structured Terms

 data elements - lowest level of information on which a process can act i.e. DB
attributes/record fields - e.g. unit price.

 data stores - places where data are stored; e.g. files; microfiche, filing cabinets.

 data flows - represent movement of data in a system; consist of data input and
data output e.g. forms, reports, invoices, letters.

 show movement of data about a physical “thing”.

Logical DFDs
 shows sources and sinks (destinations) of data

 identifies and names the logical functions (processes) of the system.

 identifies and names the groups of data elements that connect one process to
another.

 identifies the data stores.

 each function broken down into more detailed DFD (levels).

 descriptions of processes, flows, stores, elements recorded in data dictionary.

Logical DFDs

 All of the above documentation comprises a logical functional

specification for an existing or new system.
 A detailed statement of what the system does/is to do.

 Free from physical considerations of how it will be implemented.

Data Flow Diagrams Symbol
The following four symbols are used in data flow diagrams:
External entity

Process

Data store

Data flow
Data flow diagram of part of an order processing
system

Order
Available stock
Customer
stock
Invoice Process
order
Unfilled order
Out-of-stock backorders
notice

Despatch note

Warehous
e
Data flow diagram of a travel agent booking
system

Customer
Travel-query Available flights
Book flights
flight
Booking
Booking
confirmation
Entity-Relationship Model( ER Model)

• Entity-Relationship Model( ER Model): It is a high-level data model

which is used to define the data and the relationships between them.
It is basically a conceptual design of any database which is easy to
design the view of data.
Entity-Relationship Model( ER Model)

• The major activity of this phase is identifying entities,

attributes, and their relationships to construct model
using the Entity Relationship Diagram.
• Entity  table
• Attribute  column
• Relationship  line
• Basics of Data Modeling Video
• Until business rules # 3 (9:20)

23
How to find entities?
• Entity:
• "...anything (people, places, objects, events, etc.) about
which we store information (e.g. supplier, machine tool,
employee, utility pole, airline seat, etc.).”
• Tangible: customer, product
• Intangible: order, accounting receivable
• Look for singular nouns (beginner)
• BUT a proper noun is not a good candidate….

24
Entity Instance
Entity instance: a single occurrence of an entity.
• 6 instances

Entity: student Student Last First

ID Name Name
2144 Arnold Betty
3122 Taylor John
3843 Simmons Lisa
instance 9844 Macy Bill
2837 Leath Heather
2293 Wrench Tim
25
How to find attributes?

• Attribute:
• Attributes are data objects that either identify or
describe entities (property of an entity).
• In other words, it is a descriptor whose values are
associated with individual entities of a specific entity type
• The process for identifying attributes is similar except now you
want to look for and extract those names that appear to be
descriptive noun phrases.

26
How to find relationships?

• Relationship:
• Relationships are associations between entities.
• Typically, a relationship is indicated by a verb connecting
two or more entities.
• Employees are assigned to projects
• Relationships should be classified in terms of cardinality.
• One-to-one, one-to-many, etc.

27
How to find cardinalities?
• Cardinality:
• The cardinality is the number of occurrences in one
entity which are associated to the number of occurrences
in another.
• There are three basic cardinalities (degrees of
relationship).
• one-to-one (1:1), one-to-many (1:M), and many-to-many
(M:N)

28
Identifier

“attributes that uniquely identify entity instances”

• Becomes a PK in RDS
• Composite identifiers are identifiers that consist of two or more
attributes
• Identifiers are represented by underlying the name of the
attribute(s)
• Employee (Employee_ID), student (Student_ID)

29
Entity
• Entity:
• Represented by a rectangle, with its name on the top.
The name is singular (entity) rather than plural
(entities).

30
Attributes

• Identifiers are represented by underlying the name

of the attribute(s)

31
Basic Cardinality Type

• 1-to-1 relationship

• 1-to-M relationship

• M-to-N relationship
Basic Cardinality Type
Example Model

34
Example Model
Business Rule Example 1

• Finalized business rules must be bi-directional.

• Draft: one sentence
• Finalized: two sentences
• A professor advises many students (professor
to student). Each student is advised by one
professor (student to professor).
• A professor must teach many classes. Each
class must be taught by one professor.
Business Rule 1
• Business Rules are used to define entities, attributes, relationships and
constraints.
• Usually though they are used for the organization that stores or uses data to be
an explanation of a policy, procedure, or principle.
• The data can be considered significant only after business rules are defined.
• W/o them it cannot be considered as data for RDS but just records.
Business Rule 2
• When creating business rules, keep them simple, easy to understand, and keep
them broad.
• so that everyone can have a similar understanding and interpretation.
• Sources of business rules:
• Direct interviews with internal & external stakeholders
• Site visitations (collect data) and observation of the work process or procedure
• Review and study of documents (Policies, Procedures, Forms, Operation manuals, etc..)

38
Discovering Business Rules
• Real world example on the class website
• After reviewing and studying the interview and various forms, develop a draft
business rules - does not need to be bi-directional and less precise wording…
• Keep on going until “optimized”
• Then, finalize Business Rules: bi-directional.
Business Rule Example 2

• A sales representative must write many

invoices. Each invoice has to be written by one
sales representative.
• Each sales representative must be assigned to
many department. Each department has only
one sales representative.
• A customer has to generate many invoices. An
invoice is generated by only one customer.
Attributes

“Describe detail information about an entity ”

• Entity: Employee
• Attributes:
• Employee-Name
• Address (composite)
• Phone Extension
• Date-Of-Hire
• Job-Skill-Code
• Salary
Example - “Movie Database”

• Entity:
• Movie Star
• Attributes:
• SS#: “123-45-6789” (single-valued)
• Cell Phone: “(661)123-4567, (661)234-5678” (multi-
valued)
• Name: “Harrison Ford” (composite)
• Address: “123 Main Str., LA, CA” (composite)
• Gender: “Female” (simple)
• Age: 24 (derived)

47
Procedure of ERD
• Relatively simple representations of complex real-
world data structures
• Data modeling is iterative process.
• “complete” and “100% error free” model is not
possible!
• Only “Optimized” model is possible….

48
Physical Data Model

The physical Data Model is used to practically implement Relational

Data Model. Ultimately, all data in a database is stored physically on a
secondary storage device such as discs and tapes. This is stored in the
form of files, records, and certain other data structures. It has all the
information on the format in which the files are present and the
structure of the databases, the presence of external data structures,
and their relation to each other. Here, we basically save tables in
memory so they can be accessed efficiently. In order to come up with a
good physical model, we have to work on the relational model in a
better way. Structured Query Language (SQL) is used to practically
implement Relational Algebra.
Characteristics of a physical
data model
• The physical data model describes data need for a single project or
application though it maybe integrated with other physical data models
based on project scope.
• Data Model contains relationships between tables that which addresses
cardinality and nullability of the relationships.
• Developed for a specific version of a DBMS, location, data storage or
technology to be used in the project.
• Columns should have exact datatypes, lengths assigned and default values.
• Primary and Foreign keys, views, indexes, access profiles, and
authorizations, etc. are defined