Data Models

2-1 : Data Modeling and Data Models

• Database design focuses on how the database structure will be used to store
and manage end-user database.
• Data modeling – is the process of creating a specific data model for a
determined problem domain.
• A problem domain is a clearly defined area within the real-world environment, with
a well-defined scope and boundaries that will be systematically addressed.
• A data model is a representation of a complex “real world” data structure.
• A data model represents data structures and their characteristics, relations,
constraints, transformations, and other constructs with the purpose of supporting a
specific problem domain.
• Data modeling is an iterative, progressing process. You start with a simple
understanding of the problem domain, and as your understanding increases, so does
the level of detail. When done properly, the final data model is a blueprint with all the
instructions to build a database that will meet all end-user requirements.
2-2 : The Importance of Data Models
• Data models can facilitate interaction among the designer, the applications
programmer, and the end user.
• The importance of data modeling cannot be overstated. Data constitutes the most
basic information employed by a system. Applications are created to manage data and
to help transform data into information.
• Applications programmers have yet another view of data, being more concerned
with data location, formatting, and specific reporting requirements.
• When a good database blueprint is available, it does not matter than an
applications programmer’s view of the data is different from that of the manager
or the end user.
• The data model is an abstraction. You are unlikely to create a good database without
first creating an appropriate data model.
2-3 : Data Model Basic Building Blocks
• The basic building blocks of all data models are entities, attributes, relationships,
and constraints.
• An entity – is a person, place, thing, concept, or event for which data can be stored.
• An attribute – is a characteristic of an entity or object. An attribute has a name and
a data type.
• A relationship – is an association between entities.
 • One-to-many (1:M or 1...*) relationship – is an association among two or more
entities that are used by data models. In a 1:M relationship, one entity instance is
associated with many instances of the related entity.
• Many-to many (M:N) relationship – is an association among two or more entities in
which one occurrence of an entity is associated with many occurrences of a related
entity and one occurrence of the related entity is associated with many occurrences
of the first entity.
• One-to-one (1:1 or 1..1) relationship- is an association among two or more entities that
are used by data models. In a 1.1 relationship, one entity instance is associated with
only one instance of the related entity.
• A constraint – is a restriction placed on data, usually expressed in the form of
rules. Constraints are important because they help to ensure data integrity.
2-4 : Business Rules
• From a database point of view, the collections of data becomes meaningful only when
it reflects properly defined business rules.
• A business rule is a brief, precise, and unambiguous description of a policy, procedure,
or principle within a specific organization.
• Business rules are misnamed: they 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.
• Business rules derived from a detailed description of an organization’s operations help
to create and enforce actions within that organization’s environment. They must be
rendered in writing and updated to reflect any change in the organization’s operational
environment.
2-4a: Discovering Business Rules
• The main sources of business rules are company managers, policy managers,
department managers, and written documentation such as a company’s
procedures, standards, and operations manuals.
• A faster and more direct source of business rules is direct interviews with end users.
• Although end users are crucial contributors to the development of business rules, it
pays to verify end-user perceptions.
• The process of identifying and documenting business rules is essential to
database design for several reason:
o It helps to standardize the company’s view of data.
o It can be a communication tool between users and designers.
o It allows the designer to understand business
processes. 2-4b: Translating Business Rules into Data Model
Components
• Business rules set the stage for the proper identification of entities,
attributes, relationships, and constraints.
• For example, the business rule “a customer may generate many invoives” contains
two nouns (customer and invoices) and a verb (generate) that associates the nouns.

• From this business rule, you could deduce the following:

 o Customer and invoice are objects of interest for the environment and should
be represented by their respective entities.
o There is a generate relationship between customer and
invoice. 2-5: The Evolution of Data Models
• The quest for better data management has led to several models that attempt to
resolve the previous model’s critical shortcomings and to provide solutions to ever-
evolving data management needs.
2-5a: Hierarchical and Network Models
• The hierarchical model was 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.
• It is an early database model whose basic concepts and characteristics formed the
basis for subsequent database development. The model is based on an upside-down
tree structure in which each record is called a segment. The top record is the root
segment. Each segment has a 1:M relationship to the segment directly below it.
• A segment – is the equivalent of a file system’s record type.
• 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.
• The definitions of standard database concepts that emerged with the network model
are still used by modern data models:
o The schema - is a logical group of database objects, such as tables,
indexes, views, and queries, that are related to each other.
o The subschema – is the portion of the database that interacts with
application programs.
o A data manipulation language (DML) – is the set of commands that allows
an end user to manipulate the data in the database, such as SELECT,
INSERT, UPDATE, DELETE, COMMIT, and ROLLBACK.
o A data definition language (DDL) – is the language that allows a
database administrator to define the database structure, schema, and
subschema.
2-5 b: The Relational Model
• The relational model – developed by E.F. Codd of IBM in 1970, the relational model
is based on mathematical set theory and represents data as independent relations.
Each relation (table) is conceptually represented as a two-dimensional structure of
intersecting rows and columns.
• The relational model’s foundation is a mathematical concept known as a relation.
To avoid the complexity of abstract mathematical theory, you can think of a
relation (sometimes referred to as a table) as a two-dimensional structure
composed of intersecting rows and columns. Each row in a relation is called a
tuple. Each column represents an attribute.
 • The relational data model is implemented through a very sophisticated relational
database management system (RDBMS). The RDBMS performs the same basic
functions provided by the hierarchical and network DBMS systems.
o An advantage of the RDBMS is its ability to hide the complexities of the
relational model from the user.
o The RDBMS manages all of the physical details, while the user sees the
relational database as a collection of tables in which data is stored.
• The relationship type (1:1, 1:M, or M:N) is shown in a relational schema.
• A relational diagram – is a representation of the relational database’s entities,
the attributes within those entities, and the relationships between those
entities.
• A relational table stores a collection of related entities. The relational database table
resembles a file, but there is a crucial difference between a table and a file: a table
yields complete data and structural independence because it is a purely logical
structure.
• Another reason for the relational data model’s rise to dominance in its powerful and
flexible query language. Most relational database software uses Structured Query
Language (SQL), which allows the user to specify what must be done without
specifying how.
• From an end-user perspective, any SQL-based relational database application
involves three parts: a user interface, a set of tables stored in the database, and the
SQL “engine.”
o The end-user interface.
o The collection of tables stored in the database.
o SQL engine.
2-5c: The Entity Relationship Model
• Complex design activities require conceptual simplicity to yield successful results.
Although the relationship model was a vast improvement over the hierarchical
and network models, it still lacked the features that would make it an effective
database design tool.
• Database designers prefer to use a graphical tool in which entities and their
relationships are pictured.
• The entity relationship (ER) model (ERM) – is a model that describes relationships
(1:1, 1:M, and M:N) among entities at the conceptual level with the help of ER
diagrams.
• The graphical representation of entities and their relationships in a database
structure 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 composed of:

 o Entity
o Relationships
• The different types of relationships using three ER notations:
o Chen notation
o Crow’s Foot notation
o Class diagram notation (part of the Unified Modeling Language)
• The ER model’s visual simplicity makes it the dominant database modeling and
design tool.
2-5d: The Object-Oriented (OO) Model
• The object-oriented data model (OODM), both data and its relationships are
contained in a single structure known as an object.
• Like the relational model’s entity, an object is described by its factual content. But
quite unlike an entity, an object includes information about relationships between the
facts within the object, as well as information about its relationships with other
objects. The facts within the object are given a greater meaning.
• The OODM is said to be a semantic data model because the word semantic
indicates meaning.
• OODM development has allowed an object to contain all operations that can be
performed on it, such as changing its data values, finding a specific data value,
and printing data values.
• The OO data model is composed of:
o An object is an abstraction of a real-world entity.
o Attributes describe the properties of an object.
o Objects that share similar characteristics are grouped in classes.
o Classes are organized in a class hierarchy.
o Inheritance is the ability of an object within the class hierarchy to inherit
the attributes and methods of the classes above it.
o Object-oriented data models are typically depicted using Unified
Modeling Language (UML class diagrams).
2-5e: Object/Relational and XML
• An object/relational database management system (O/R DBMS) – is a DBMS based
on the extended relational model (ERDM). The ERDM, championed by many
relational database researchers, constitutes the relational model’s response to the
OODM.
• Extensive Markup Language (XML) – is a metalanguage used to represent
and manipulate data elements. Unlike other markup languages, XML
permits the manipulation of a document’s data elements.
2-5f: Emerging Data Models: Big Data and NoSQL
• Big Data has been used in many different frameworks, from law to statistics
to economies to computing.
• The basic characteristics of Big Data databases: volume, velocity, and variety.