PRELIM

DATA
MODELING
 DATA MODELING
It is the process of documenting a complex
software system design as an easily
understood diagram, using text and symbols
to represent the way data needs to flow. The
diagram can be used as a blueprint for the
construction of new software or for re-
engineering a legacy application.
Traditionally, data models have been built
during the analysis and design phases of a
project to ensure that the requirements for a
new application are fully understood. A data
model can be thought of as a flowchart that
illustrates the relationships between data.
Although capturing all the possible relationships
in a data model can be very time-intensive, it's
an important step that shouldn't be rushed.
Well-documented conceptual, logical and
physical data models allow stake-holders to
identify errors and make changes before any
programming code has been written.
 Different approaches to data modeling:
• Conceptual Data Modeling - identifies the highest-
level relationships between different entities.
• Enterprise Data Modeling - similar to conceptual
data modeling, but addresses the unique
requirements of a specific business.
• Logical Data Modeling - illustrates the specific
entities, attributes and relationships involved in a
business function. Serves as the basis for the
creation of the physical data model.
• Physical Data Modeling - represents an application
and database-specific implementation of a logical
data model.
 Benefits of Data Models:
1. Higher quality. Just as architects consider blueprints before
constructing a building, you should consider data before
building an app. On average, about 70 percent of software
development efforts fail, and a major source of failure is
premature coding. A data model helps define the problem,
enabling you to consider different approaches and choose
the best one.
2. Reduced cost. You can build applications at lower cost via
data models. Data modeling typically consumes less than 10
percent of a project budget, and can reduce the 70 percent
of budget that is typically devoted to programming. Data
modeling catches errors and oversights early, when they are
easy to fix. This is better than fixing errors once the software
has been written or – worse yet – is in customer hands.
3. Quicker time to market. You can also build software
faster by catching errors early. In addition, a data
model can automate some tasks – design tools can
take a model as an input and generate the initial
database structure, as well as some data access
code.
4. Clearer scope. A data model provides a focus for
determining scope. It provides something tangible
to help business sponsors and developers agree
over precisely what is included with the software
and what is omitted. Business staff can see what the
developers are building and compare it with their
understanding. Models promote consensus among
developers, customers and other stakeholders.
5. Faster performance. A sound model simplifies
database tuning. A well-constructed database
typically runs fast, often quicker than expected.
To achieve optimal performance, the concepts in
a data model must be crisp and coherent (see
first bullet). Then the proper rules must be used
for translating the model into a database design.
6. Better documentation. Models document
important concepts and jargon, proving a basis
for long-term maintenance. The documentation
will serve you well through staff turnover.
7. Fewer application errors. A data model causes
participants to crisply define concepts and
resolve confusion. As a result, application
development starts with a clear vision.
Developers can still make detailed errors as they
write application code, but they are less likely to
make deep errors that are difficult to resolve.
8. Fewer data errors. Data errors are worse than
application errors. It is one thing to have an
application crash, necessitating a restart. It is
another thing to corrupt data in a large database.
9. Managed risk. You can use a data model to estimate
the complexity of software, and gain insight into the
level of development effort and project risk. You
should consider the size of a model, as well as the
intensity of inter-table connections.
10. A good start for data mining. The documentation
inherent in a model serves as a starting point for
analytical data mining. You can take day-to-day
business data and load it into a dedicated database,
known as a “data warehouse.” Data warehouses are
constructed specifically for the purpose of data
analysis, leveraging that data from routine
operations.
 Remember:
• These 10 benefits of using data models to
build business applications underscore the
bottom line: Data models provide the means
for building quality software in a predictable
manner.
 Why data models are important?
• Data models can facilitate interaction among
the designer, the application programmer and
the end user.
• A well developed data model can even foster
improved understanding of the organization
for which the database design is developed.
• Data models are a communication tool.
 Basic data modeling building blocks:
Entities – is anything, such as person, place, thing, or event, about which data are to
be collected and stored. Entities may be physical objects such as customers or
products. But entities may also be abstractions such as flight routes or musical
concerts.

Attributes - 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. The attributes are
the equivalent of fields in file systems.

Relationships - describes an association among (two or more) entities. For example,

there is a relationship between customers and agents that may be described as
“an agent can serve many customers and eachcustomer may be served by one
agent. Data models use three types of relationships: one-to-many, many-to-many,
and one-to-one. Database designers usually use the shorthand notations 1:M,
M:N, and 1:1 for them, respectively. (Although the M:N notation is a standard
label for the many-to-many relationship, the label M:M may also be used.) The
following examples illustrate the distinctions among the three.
 Cardinality and Relationship models
The degree of relationship (also known as
cardinality) is the number of occurrences in one
entity which are associated (or linked) to the
number of occurrences in another.
There are three degrees of relationship, known as:

• one-to-one (1:1)
• one-to-many (1:M)
• many-to-many (M:N)
 References:
http://
searchdatamanagement.techtarget.com/
definition/data-modeling
http://pabipedia.wikidot.com/data-model:basic-
building-blocks
https://www.sqa.org.uk/e-learning/
SoftDevRDS02CD/page_44.htm