WHITE BOARD SUMMARY FOR

SS2 DATA PROCESSING (WEEKS 1&3)

TYPES OF DATA MODELS

DATA MODEL

A Data Model is a collection of tools for describing data, data relationships, data semantics and consistency
constraints.
Data models describe the structure of the data within a given domain (organization/business/company), and by
implication, the underlying structure of that domain. They visually represent (pictorial representation) the nature of
data, business rules governing the data and how it will be organized in the database. It is a representation of data
structures required for a database and is a powerful tool for expressing and communicating the business
requirements. In the same way that architects use blueprints to build their structures, IT designers use data models to
plan, design and construct systems that will meet the stated requirements.
Data models are applicable to any software development that involves creation of database objects to store and
manipulate data. They are physically implemented in a specific database management system using Database
schema.
The term "schema" refers to the organization of data as a blueprint of how the database is constructed (divided into
database tables in the case of relational databases). Database schema includes all implementation details such as data
types, constraints, foreign or primary keys.

DEFINITION OF TERMS
 Data: Raw and unprocessed facts.
 Database: A database is an organized and shared collection of related data used to support the activities of a
particular organization. A database can be viewed as a repository of data that is defined once and then accessed
by various users.
 Database management system (DBMS): A specialized computer software available from computer vendors
that is used to create, access, control, and manage the database.
Some kind of data model describe how to organize data using a database management system (DBMS) or other
data management technology
 DBA: Database Administrator. A database administrator (DBA) directs or performs all activities related to
maintaining a successful database environment.
 Data Structure: A data structure is a specialized format for organizing and storing data.
 Data Model: A collection of tools for describing data, data relationships, data semantics and consistency
constraints.
 Metadata: A data that describes other data. Metadata summarizes basic information about data, which can
make finding and working with particular instances of data easier. They are the data that describe the
structure and workings of an organization's use of information, and which describe the systems it uses to
manage that information.
Metadata don't just describe data. They describe how the organization understands not only its data, but also
its activities, people and organizations, geography, timing, and motivation. Metadata describe the entity
classes and attributes of an entity-relationship model, and the tables and columns by which these are
implemented in a computer system. They also provide, however, structure for describing the activities of the
organization and the computerized processes that implement these activities. They describe who has access
to data, and why. They describe the types of events and responses that are the nature of an organization's
activities. They describe where the data and processes are, and they describe the motivation and business
rules that drive the entire thing.
1
 An entity is something about which we want to store data. A class of persons, places, objects, events, or
concepts about which we need to capture and store data.
 An entity instance is a single occurrence of an entity.
 An attribute is a descriptive property or characteristic of an entity. Synonyms include element, property, and
field
 A key is an attribute, or a group of attributes, which assumes a unique value for each entity instance. It is
sometimes called an identifier.
Sometimes more than one attribute is required to uniquely identify an instance of an entity.
A group of attributes that uniquely identifies an instance of an entity is called a concatenated key. Synonyms
include composite key and compound key.
 A primary key: It is a unique identifier for each record in a relational database.
 Foreign key: In the context of relational databases, a foreign key is a field (or collection of fields) in one table
that uniquely identifies a row of another table or the same table. In simpler words, the foreign key is a key
defined in a second table, but it refers to the primary key or a unique key in the first table.
Differences between primary key and foreign key
BASIS FOR PRIMARY KEY FOREIGN KEY
COMPARISON
Basic Primary Key is a chosen candidate key that Foreign key in a table refers to the primary
uniquely defines a tuple in a relation. key of other table.
NULL Primary key value can never be NULL. Foreign key accepts NULL value.
Duplicate No two tuples in a relation carry duplicate Tuples can carry duplicate value for a foreign
values for a primary key attribute. key attribute.
Range There can be only one primary key of a There can be multiple foreign keys in a
relation. relation.
Temporary Table Primary key constraint can be defined on Foreign Key constraint cannot be defined on
the temporary tables. the temporary tables.
Clustered index By default, a primary key is clustered Foreign key is not clustered indexed
indexed. automatically; it has to be done manually.
Insertion We can insert a value to a primary key We cannot insert a value to a foreign key, if
attribute, even if the referencing foreign key that value is not present in the referenced
does not have that value in its column. primary key column.

Deletion Before you delete a primary key value, You can delete a value from foreign key
make sure that value is not still present in column without bothering, whether that
the referencing foreign key column of value is present in referenced primary key
referencing table. column of referenced relation.

 A relationship is a natural business association that exists between one or more entities. The relationship may
represent an event that links the entities, or merely a logical affinity that exists between the entities.

APPROACHES TO/LEVELS OF DATA MODEL

Conceptual Data Model:

2
There are some differing opinions about what a conceptual data model is. A conceptual data model is a model of the
things in the business and the relationships among them, rather than a model of the data about those things. So in a
conceptual data model, when you see an entity type called ‘Product’ for an online school tuck shop, then you should
think about provisions and stationaries, not records in databases. As a result, conceptual data models usually have
few, if any, attributes.
 A conceptual data model simply shows the entities (maybe attributes) and the relationship between them. It
can easily be drawn on paper
 It is highly abstract (no too much detail, it is at a high level)
 It is easy to understand (not technical)
 Only entities their and their relationships are visible
 It shows abstract relationships
 It can be rapidly updated

Logical Data Model

Logical data models add further information to the conceptual model elements. It defines the structure of the data
elements and set the relationships between them.
 Expands the conceptual model by adding more detail
 It contains attributes (key attributes and non-key attributes)
 It is not dependent on any specific database. It is generic
 It can be implemented using software tools
 Shows primary key – foreign key relationship
 A little more difficult to enhance than the Conceptual model

3
Physical Data Model

A Physical Data Model defines all of the logical database components and services that are required to build a
database or can be the layout of an existing database. It describes the database specific implementation, offers an
abstraction of the database and helps generate schema. This is because of the richness of meta-data offered by a
Physical Data Model.
A physical data model consists of the table's structure, column names and values, foreign and primary keys and the
relationships among the tables.
 Looks a little similar to logical model
 Entities become tables and Attributes become columns
 Database compatible names are used (It is common to write names in physical model without space)
 Includes database specific data type (It is dependent on a specific database E.g.: ME-Access, Oracle Dataase, SQL
Server)
 It includes other objects that are not immediately visible like indexes, constraints, triggers and other database
objects
 It takes more effort to be enhanced
 Software tools can be used to convert logical to physical data model

Feature Conceptual Logical Physical

Entity Names  
Entity Relationships  
Attributes 
Primary Key  
Foreign key  
Tale Names 
Column Names 

4
 Column Data type 

TYPES OF DATA MODELS

There are several data models. The most common ones include:
1. Flat file model
2. Hierarchical database model
3. Network model.
4. Relational model.
5. Object-oriented database model.
6. Object-relational database model.
7. Entity-relationship model.

You may choose to describe a database with any one of these depending on several factors. The biggest factor is
whether the database management system you are using supports a particular model. Most database management
systems are built with a particular data model in mind and require their users to adopt that model, although some do
support multiple models.

 The Flat file model

A flat file database is basically a giant collection of data in which the tables and records have no relation between
any other tables. In fact, one could have a single table (e.g., My Small Business Data) with everything stored in it,
from customers to sales to orders to invoices.

It is often messy but has its uses. One doesn't necessarily have to normalize a database. By normalize, we mean break
out all the repeating values in tables and save them into other, related tables. Sometimes simple is best.

In fact, if the data set is fairly simple, the flat file option makes more sense. A CD collection, a list of cell phone
numbers, could be stored in a flat file database. Even a web page or computer program could be written to interact
with these types of databases; in fact, from a developer's perspective, it would be easy to maintain.
If you have ever created an Excel spreadsheet, you have created a basic flat file. A workbook with multiple tabs
makes up the database of the flat-file database; there could be many values that are the same in both worksheets, but
they are not linked together.

 The hierarchical model

The hierarchical model organizes data into a tree-like structure, where each record has a single parent or root. Sibling
records are sorted in a particular order. That order is used as the physical order for storing the database. This model is
good for describing many real-world relationships. It allows one-to-many relationships.

5
  The network model
The network model builds on the hierarchical model by allowing many-to-many relationships between linked
records, implying multiple parent records. Based on mathematical set theory, the model is constructed with sets of
related records. Each set consists of one owner or parent record and one or more member or child records. A record
can be a member or child in multiple sets, allowing this model to convey complex relationships.

 The relational model (RDBMS)

The most common model, the relational model sorts data into tables, also known as relations, each of which consists
of columns and rows. Each column lists an attribute of the entity in question, such as price, zip code, or birth date.
Together, the attributes in a relation are called a domain. A particular attribute or combination of attributes is chosen
as a primary key that can be referred to in other tables, when it’s called a foreign key.

Each row, also called a tuple, includes data about a specific instance of the entity in question, such as a particular
employee.

The model also accounts for the types of relationships between those tables, including one-to-one, one-to-many, and
many-to-many relationships.
Within the database, tables can be normalized, or brought to comply with normalization rules (this will be further
discussed later) that make the database flexible, adaptable, and scalable. When normalized, each piece of data is
atomic, or broken into the smallest useful pieces.

Relational databases are typically written in Structured Query Language (SQL). The model was introduced by E.F.
Codd in 1970.

6
  Object-oriented database model (OODB)

As the name implies, the main feature of object-oriented databases is allowing the definition of objects, which are
different from normal database objects. Objects (which are reusable software elements), in an object-oriented
database, have associated features and methods. They can then be referenced, or called later, as a unit without having
to go into its complexities. This is very similar to objects used in object-oriented programming.

A real-life parallel to objects is a car engine. It is composed of several parts: the main cylinder block, the exhaust
system, intake manifold and so on. Each of these is a standalone component; but when machined and bolted into one
object, they are now collectively referred to as an engine. Similarly, when programming one can define several
components, such as a vertical line intersecting a perpendicular horizontal line while both lines have a graded
measurement. This object can then be collectively labelled a graph. When utilizing the ability to plot components,
there is no need to first define a graph; but rather the instance of the created graph can be called.

The object-oriented database model is the best known post-relational database model, since it incorporates tables, but
isn’t limited to tables. Such models are also known as hybrid database models.

7
  Object-relational model
This hybrid database model combines the simplicity of the relational model with some of the advanced functionality
of the object-oriented database model. In essence, it allows designers to incorporate objects into the familiar table
structure.
 Entity-relationship model
This model captures the relationships between real-world entities much like the network model, but it isn’t as
directly tied to the physical structure of the database. Instead, it’s often used for designing a database conceptually.
Here, the people, places, and things about which data points are stored are referred to as entities, each of which has
certain attributes that together make up their domain. The cardinality, or relationships between entities, are mapped
as well. This will be discussed in detail later.

8
 DATA MODELLING
WEEK 2
Data modelling is the analysis of data objects and their relationships to other data objects. Data modelling is often the
first step in database design.
MS Access is an RDBMS that can be used to create a computerized database using different objects. These objects
allow you to enter, store, analyse, and compile your data.
There are six different types of objects in an Access Database.

1. Table: A table stores data about an entity (a person, place, or thing) and is the basic element in any
database. A table is made up or records, which in turn are made up of fields. It is columnar in appearance, with each
record in a separate row of the table and each field in a separate column.

2. Form: A form provides a more convenient and attractive way to enter, display and/or print the data in a
table.

3. Query: A query answers a question about the database. The most common type of query specifies a set of
criteria, then searches the database to retrieve the records that satisfy that criteria.

4. Report: A report presents the data in a table or query in attractive fashion on the printed page.

5. Macro: A macro is analogous to a computer program and consists of commands that are executed
automatically one after the other. Macros are used to automate the performance of any repetitive task, it is a script
for doing some job. Macros are beyond the scope of this class.
6. Module: A module provides a greater degree of automation through programming in Access Basic. Macros
are beyond the scope of this class.

TABLE:

A table (or set of tables) is the heart of any database, as it contains the actual data. In Access a table is displayed in
one of two views:
Table design view (or datasheet view) is used to define the table initially and to specify the fields it will contain. It is
also used to modify the table definition if chances are subsequently necessary.

Datasheet view is the view you use to add, edit, or delete records.
The first row contains the field names. Each additional row contains a record. Each column represents a field (one
fact about your data) every record in the table contains the same fields in the same order.
Every database table contains a PRIMARY KEY – that is a field or combination of fields that must be unique for
every record. The primary key ensures that every record in a table is different from every other record, and prevents
the occurrence of duplicate records. Every table must have a primary key and there can be only one primary key per
table.

Access Data Types

Type of Data Description Size

9
 Text or combinations of text and numbers, Up to 255
Short Text including numbers that do not require calculating characters.
(e.g. phone numbers).

Lengthy text or combinations of text and numbers. Up to 63, 999

Long Text
characters.

Numeric data used in mathematical calculations. 1, 2, 4, or 8 bytes

Number (16 bytes if set to
Replication ID).

Date and time values for the years 100 through 8 bytes
Date/Time
9999.

Currency values and numeric data used in 8 bytes

Currency mathematical calculations involving data with one
to four decimal places.

A unique sequential (incremented by 1) number or 4 bytes (16 bytes if

AutoNumber random number assigned by Microsoft Access set to Replication
whenever a new record is added to a table. ID).

Yes and No values and fields that contain only one 1 bit.
Yes/No
of two values (Yes/No, True/False, or On/Off).

In previous versions of before Access 2013, short text and long text were called text and memo
respectively.

Here are some of the other more specialized data types, you can choose from in Access.

Data Types Description Size

Files, such as digital photos. Multiple files can Up to about 2 GB.

Attachment be attached per record. This data type is not
available in earlier versions of Access.

OLE objects can store pictures, audio, video, or Up to about 2 GB.

OLE objects
other BLOBs (Binary Large Objects)

Hyperlink Text or combinations of text and numbers Up to 8,192 (each part of

stored as text and used as a hyperlink address. a Hyperlink data type can
contain up to 2048

10
 characters).

The Lookup Wizard entry in the Data Type Dependent on the data
column in the Design view is not actually a type of the lookup field.
data type. When you choose this entry, a
wizard starts to help you define either a simple
or complex lookup field.
Lookup Wizard
A simple lookup field uses the contents of
another table or a value list to validate the
contents of a single value per row. A complex
lookup field allows you to store multiple values
of the same data type in each row.

You can create an

expression that uses data
You can create an expression that uses data
from one or more fields.
Calculated from one or more fields. You can designate
You can designate
different result data types from the expression.
different result data types
from the expression.

SIGNIFICANCE OF DATA MODEL

Data models are a great communication tool because it facilitates interaction and communication between the
designers, programmers and end users. In essence, it does not allow one party’s bias (what they consider to be most
important) towards data to take hold.
Some benefits of data model includes:
1. A well-developed data model can foster improved understanding of the organisation for which the database
is developed.
2. Data modelling will impose (implicitly or explicitly) constraints or limitations on the data placed within the
structure
3. Higher quality. Just as architects consider blueprints before constructing a building, you should consider
modelling your data before building a system. A data model helps define the problem, enabling you to
consider different approaches and choose the best one.
4. Reduced cost. You can build databases and software system at lower cost via data models.
5. 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 within the database and what is
omitted. A data model also promotes agreement on vocabulary and jargon.
6. Faster performance. A sound model simplifies database tuning. A well-constructed database typically runs
fast, often quicker than expected.
7. Fewer (data and application) errors
11
 8. 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.
9. Better documentation. Models document important concepts and jargon, proving a basis for long-term
maintenance. The documentation will serve you well through the life time of the database and through staff
turnover.

STANDARD DATA MODELS/INDUSTRY STANDARD DATA MODELS (ISDM)

A standard data model or industry standard data model is a data model that is widely applied in some industry and
shared among competitors to some degree. They are often defined by standard bodies, database vendors or operating
system vendors.
A standard defines guidelines (or a frame of reference) that encourages confidence between interacting parties. For
example, if you have some dollar notes that you wish to change to naira, the standard conversion rate of ‘dollar-to-
naira’ will assure you that you are getting the right naira equivalent for your dollars. In turn, the standard definition
of ‘naira-to-dollar" assures the bank that they are paying you the appropriate value for your dollars. In essence, a
standard is an agreement between interacting parties to the context of the interaction.
Standard data models or industry standard data models (ISDM) stipulates the data standards to be used within a
particular industry. These standards are the rules by which data are described and recorded. A data standard, at the
very least, defines entity names, data element names, descriptions, definitions and formatting rules. In addition, a
data standard may include procedures, implementation guidelines and usage directives. This enhances the
interoperability among heterogeneous information systems, facilitates increased data sharing, reduce data handling
costs and lead to better data accuracy, consistency and timeliness. The most effective standard data models have been
developed in banking, insurance, pharmaceutical and automotive industries, to reflect the stringent standards applied
to customer information gathering, customer privacy, consumer safety, etc.
The application of comprehensive vertical industry standard data models provides IT designers a way to move
forward quickly with a complete best-practices industry design without committing to a lengthy, costly and
unpredictable design effort the answer in a way that predictable, cost- effective and immediately applicable.

Examples of Standard Data Models:

 ISO 10303: ISO 10303 is an ISO (International Organization for Standardization) standard for the computer-
interpretable representation and exchange of product manufacturing information. Its official title is:
Automation systems and integration — Product data representation and exchange. It is known informally as
"STEP", which stands for "Standard for the Exchange of Product model data". ISO 10303 can represent 3D
objects in Computer-aided design (CAD) and related information.
 ISO 15926: The ISO 15926 is a standard for data integration, sharing, exchange, and hand-over between
computer systems.
 IDEAS Group: IDEAS is the International Defence Enterprise Architecture Specification for exchange. The
purpose of the project is to develop a data exchange format for military Enterprise Architectures. The
purpose is to allow seamless sharing of architectures between the partner nations regardless of which
modelling tool or repository they use. The initial scope for exchange is the architectural data required to
support coalition operations planning:

12