Data Modeling Concepts

Data modelling, the first step in designing a database refers to the process of creating a specific data model for
a determined problem domain. Data models are communication tool that can facilitate interaction among the
designer, the applications programmer, and the end user.

Basic Building Blocks of Data Model

The basic building blocks of all data models are:
a. Entity: An entity is a person, place, thing, or event about which data will be collected and stored. An entity
represents a particular type of object in the real world, each entity occurrence is unique and distinct. For
example, a CUSTOMER entity would have many distinguishable customer occurrences, such as Vishwas
Singh, Vijay Gupta, and Rakesh Kumar. Entities may be physical objects, such as customers or products,
and may also be abstractions, such as flight routes or musical concerts. Entity names are often capitalized
as a convention, so they are easily identified.
b. Attribute: An attribute is a characteristic of an entity. For example, a CUSTOMER entity would be
described by attributes such as customer first name, customer last name, customer phone number,
customer address, and customer credit limit. Attributes are the equivalent of fields in file systems.
c. Relationship: A relationship describes an association among entities. For example, a relationship exists
between customers and agents that can be described as follows: an agent can serve many customers, and
each customer may be served by one agent.

Data models use three types of relationships: one-to-many (1:M), many-to-many (M:N), and one-to-one
(1:1):
• One-to-many (1:M) relationship. A painter creates many different paintings, but each is painted by
only one painter. Thus, the painter (the “one”) is related to the paintings (the “many”). Therefore, the
relationship “PAINTER paints PAINTING” is labelled as 1:M.
• Many-to-many (M:N) relationship. An employee may learn many job skills, and each job skill may be
learned by many employees. This relationship “EMPLOYEE learns SKILL” is labelled as M:N.
• One-to-one (1:1) relationship. A retail company’s management structure may require that each of its
stores be managed by a single employee. In turn, each store manager, who is an employee, manages
only a single store. Therefore, the relationship “EMPLOYEE manages STORE” is labeled 1:1.

The preceding discussion identified each relationship in both directions; that is, relationships are
bidirectional:
• One CUSTOMER can generate many INVOICEs.
• Each of the many INVOICEs is generated by only one CUSTOMER.

d. Constraint: A constraint is a restriction placed on the data. Constraints are important because they
help to ensure data integrity. Constraints are normally expressed in the form of rules. For example:
• An employee’s salary must have values that are between 6,000 and 350,000.
• A student’s GPA must be between 0.00 and 4.00.

Business Rules
A business rule is a brief, precise, and unambiguous description of a policy, procedure, or principle within a
specific organization. Business rules apply to any organization. Examples of business rules are as follows:
• A customer may generate many invoices.
• An invoice is generated by only one customer.
• A training session cannot be scheduled for fewer than 10 employees or for more than 30 employees.

1
The business rules establish entities, relationships, and constraints. For example, the first two business rules
establish two entities (CUSTOMER and INVOICE) and the type of relationship between those two entities. The
third business rule establishes a constraint (no fewer than 10 people and no more than 30 people), two
entities (EMPLOYEE and TRAINING), and a relationship between EMPLOYEE and TRAINING.

Translating Business Rules into Data Model Components

Business rules set the stage for the proper identification of entities, attributes, relationships, and constraints.
As a general rule, a noun in a business rule will translate into an entity in the model, and a verb (active or
passive) that associates the nouns will translate into a relationship among the entities. 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 deduce that:
• Customer and invoice are entities.
• “generate” is a relationship between customer and invoice.

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.

The Evolution of Data Models

Data models describe the organization of different database objects like records, data dictionary elements and
so on. These also define integrity rules for the DBMS. Following are the types of data models:

1. Hierarchical Data Model

The hierarchical data model was developed in the 1960s to manage large amounts of data for complex
manufacturing projects. The model’s basic logical structure is represented by an upside-down tree. The
hierarchical structure contains levels, or segments. A segment is the equivalent of a file system’s record type.
Within the hierarchy, a higher layer is perceived as the parent of the segment directly beneath it, which is
called the child. The hierarchical model depicts a set of one-to-many (1:M) relationships between a parent and
its children segments. Each parent can have many children, but each child has only one parent. The basic
structure of the hierarchical data model is shown Figure 1.

Figure 1: The Structure of the Hierarchical Data Model

Retrieving the data in a hierarchical database requires navigating through the records, moving up, down, and
sideways one record at a time.

2
Consider the example of database containing of record structure Supplier, Parts and Shipment given by Table
below. The possible hierarchical view is shown in Figure 20.2. There are 4 individual trees, a tree for each part.
The tree structure has parts superior to suppliers. This means that Parts form the parent and Supplier form the
children.

SNo Name Status City

S1 Shyam 20 Mumbai
S2 Ram 10 Kolkata
S3 Amit 30 Kolkata
Table 20.1: The Supplier Record

PNo Name Color Weight City

P1 Nut Red 12 Mumbai
P2 Bolt Green 17 Kolkata
P3 Screw Blue 17 Goa
P4 Screw Red 14 Mumbai
Table 20.2: The Parts Record
SNo PNo Qty
SI P1 300
S1 P2 200
S1 P3 400
S2 P1 300
S2 P2 400
S3 P3 200
Table 20.3: The Shipments Record

(a) (b)

(c) (d)
Figure 20.2: Example of the Hierarchical Data Model

Each of the four trees in the Figure 20.2 consists of one Part record occurrence, together with a set of
subordinate Supplier record occurrence. There is one supplier record for each supplier of a particular part.
Each supplier occurrence includes the corresponding shipment quantity, for example, supplier S3 supplies 300
quantities of part P2 (Figure 20.2b). Note that the set of supplier occurrences for a given part occurrences may
contain any number of members including zero (Figure 20.2d). It can be seen that part P1 is supplied by two
suppliers S1 and S2; part P2 is supplied by three suppliers S1, S2 and S3; and part P3 is supplied by only one
supplier S1.

The disadvantages of hierarchical model are as follows:

3
• Cannot represent all the relationship that occur in the real-world
• Cannot demonstrate the overall data model for the enterprise because actual data may not be available at
time of designing the data model
• Can be used only when there is a hierarchical feature in the concerned database
• Cannot represent M:N relationship
• Insertion, deletion and updation results in inconsistency

2. Network Data Model

In network data model, data are represented by records using links among them. The model was created to
represent complex data relationships more effectively than the hierarchical model, to improve database
performance and to impose a database standard. In the network model, the user perceives the network
database as a collection of records in 1:M relationships. However, unlike the hierarchical model, the network
model allows a record to have more than one parent.

Figure 20.3: The Structure of the Network Data Model

Network databases had several advantages:

• Flexibility: Multiple parent/child relationships allowed a network database to represent data that did not
have a simple hierarchical structure.
• Standardization: The CODASYL standard boosted the popularity of the network model, and minicomputer
vendors such as Digital Equipment Corporation and Data General implemented network databases.
• Performance: Despite their greater complexity, network databases boasted performance approaching
that of hierarchical databases. Sets were represented by pointers to physical data records, and on some
systems, the database administrator could specify data clustering based on a set relationship.

Network databases had their disadvantages too, these were very rigid; the set of relationships and the
structure of the records had to be specified in advance; changing the database structure required rebuilding
the entire database.

3. The Relational Data Model

The relational data model was introduced in 1970 by E. F. Codd. The model represents a major breakthrough
for both users and designers. The relational model’s foundation is a mathematical concept known as a relation
(also called a table). A relation can be thought of as a matrix composed of intersecting rows and columns. Each
row in a relation is called a tuple. Each column represents an attribute. The relational model also describes a
precise set of data manipulation constructs based on advanced mathematical concepts.

20.5 The Relational Data Model

The relational data model is implemented through a relational database management system (RDBMS). The
RDBMS performs the same basic functions provided by the hierarchical and network DBMS systems, in
addition to a host of other functions that make the relational data model easier to understand and implement.

4
The most important advantage of the RDBMS is its ability to hide the complexities of the relational model
from the user. The RDBMS manages all of the physical details, while the user sees the relational database as a
collection of tables in which data are stored. The user can manipulate and query the data in a way that seems
intuitive and logical.

Tables are related to each other through the sharing of a common attribute (a value in a column). For
example, the BOOK table (Figure 5) contains the author’s-id that is also contained in the AUTHOR table.

FIGURE 5 Linking relational tables

The common link between the BOOK and AUTHOR tables enables to match the book to the author, even
though the book data are stored in one table and the author data are stored in another table. For example, it
can easily be determine that the book Database Management is written by C. J. Date because for this book,
the BOOK table’s AUHTOR_ID is 501, which matches the AUTHOR table’s AUHTOR_ID for C. J. Date. Although
the tables are independent of one another, you can easily associate the data between tables. The relational
model provides a minimum level of controlled redundancy to eliminate most of the redundancies commonly
found in file systems.

The relationship type (1:1, 1:M, or M:N) is often 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.

The reason for relational data model’s popularity is 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. The RDBMS uses SQL to translate user queries into instructions for retrieving the
requested data. SQL makes it possible to retrieve data with far less effort than any other database or file
environment.

A relational model has three well-defined components:

1. A logical data structure represented by relations.
2. A set of integrity rules to enforce that the data are and remain consistent over time.
3. A set of operations that defines how data are manipulated.

A Logical View of Data

The logical view serves as a reminder of the simple file concept of data storage. Although the use of a table,
quite unlike that of a file, has the advantages of structural and data independence, a table does resemble a file
from a conceptual point of view.

The characteristics of a relational table are:

1. A table is perceived as a two-dimensional structure composed of rows and columns.
2. Each table row (tuple) represents a single entity occurrence within the entity set.

5
3. Each table column represents an attribute, and each column has a distinct name.
4. Each intersection of a row and column represents a single data value.
5. All values in a column must conform to the same data format.
6. Each column has a specific range of values known as the attribute domain.
7. The order of the rows and columns is immaterial to the DBMS.
8. Each table must have an attribute or combination of attributes that uniquely identifies each row.

The table shown in Figure 20.6 illustrates the characteristics listed above:

FIGURE 6: STUDENT table attribute values

Using the STUDENT table shown in Figure 6, the following conclusions can be drawn:
1. The STUDENT table is perceived to be a two-dimensional structure composed of four rows (tuples) and 9
columns (attributes).
2. Each row in the STUDENT table describes a single entity occurrence within the entity set. (The entity set is
represented by the STUDENT table.) For example, row 1 in Figure 20.6 describes a student named Ayushi
Gupta. Given the table contents, the STUDENT entity set includes 4 distinct entities (rows), or students.
3. Each column represents an attribute, and each column has a distinct name.
4. All of the values in a column match the attribute’s characteristics. For example, the grade point average
(STU_GPA) column contains only STU_GPA entries for each of the table rows. Data must be classified
according to their format and function.

Although various DBMSs can support different data types, most support at least the following:
a. Numeric: Numeric data can be used to perform meaningful arithmetic procedures. For example, in the
Figure STU_GPA is a numeric attribute.
b. Character: Character data, also known as text data or string data, can contain any character or symbol
not intended for mathematical manipulation. In the Figure STU_CLASS is an example of character
attribute.
c. Date: Date attributes contain calendar dates stored in a special format known as the Julian date
format. In the Figure, STU_DOB is a date attribute.
d. Logical: Logical data can only have true or false (yes or no) values. In Figure 20.6, the STU_TRANSFER
attribute uses a logical data format.
5. The column’s range of permissible values is known as its domain. Because the STU_GPA values are limited
to the range 0–9, inclusive, the domain is [0,9].
6. The order of rows and columns is immaterial to the user.
7. Each table must have a primary key. In general terms, the primary key is an attribute or combination of
attributes that uniquely identifies any given row. In this case, STU_RNO (the student roll number) is the
primary key. Using the data in Figure 20.6, observe that a student’s last name (STU_LNAME) would not be

6
a good primary key because several students have the last name of Gupta. Even the combination of the
last name and first name (STU_FNAME) would not be an appropriate primary key because more than one
student is named Ayushi Gupta.

Primary Key
A Candidate Key that is used by the database designer for unique identification of each row in a table is
known as Primary Key. A Primary Key can consist of one or more attributes of a table. Example includes
STDU_RNO.

In addition to its role in providing a unique identity to each row in the table, the primary key may play an
additional role in the controlled redundancy that allows the relational model to work.

Foreign key
A foreign key is the primary key of one table that has been placed into another table to create a common
attribute. A foreign key is an attribute or combination of attribute in one base table that points to the
candidate key (generally it is the primary key) of another table. The purpose of the foreign key is to ensure
referential integrity of the data i.e. only values that are supposed to appear in the database are permitted.

One advantage of using a proper naming convention for table attributes is that you can identify foreign
keys more easily. From the STUDENT table in Figure 6 two foreign keys can be identified (DEPT_CODE and
PROF_NUM) that imply the existence of two other tables in the database (DEPARTMENT and PROFESSOR)
related to STUDENT.