DATA MODELS ppsx

1B.1 Relational Database Desi
g
n
L
L
E
E
S
S
S
S
O
O
N
N
:
:
1
1
B
B
D
D
A
A
T
T
A
A
M
M

O
O
D
D
E
E
L
L
S
S
O
O
b
b
j
j
e
e
c
c
t
t
i
i
v
v
e
e
s
s

In this lesson, you will learn to:
 Describe the types of data models
 Create an entity-relationship model
 List the types of relationships between entities
 Define a Relational Database Management System (RDBMS)
 Describe the operators that work on relations
1B.2
Relational Database Desi
g
n
Data Models Lesson 2 / Slide 1 of 14©NIIT
Data Models
Objectives
In this section, you will learn to:
•
Describe the types of data models
•
Create an entity-relationship model
•
List the types of relationships between entities
•
Define a Relational Database Management System (RDBMS)
•
Describe the operators that work on relations
I
I
N
N
S
S

T
T
R
R
U
U
C
C
T
T
O
O
R
R
N
N
O
O
T
T
E
E
S
S
Lesson Overview
The lesson identifies the types of data models. This lesson also explains the entity-
relationship model and the relational model. In addition, this lesson covers the
operators that work on relations.
1B.3 Relational Database Desi
g

n
Data Models©NIIT
Data Models
Pre-assessment Questions
1. The scope of the database is determined at which stage of the DDLC?
2. Which DBMS user performs only basic operations on the database?
3. Mary Peterson is designing a database system for IMC Inc. She has performed the
activities involved in the first four stages of the DDLC. What activity does she need
to perform at the implementation stage?
4. Who performs the task of concurrency control in a DBMS?
5. The three-level architecture of a DBMS helps achieve ______.
Lesson 2 / Slide 2 of 14
1B.4
Relational Database Desi
g
n
Data Models©NIIT
Data Models
Solutions
Ans1. Requirements definition
Ans2. End user
Ans3. Select a DBMS, purchase it, and populate the database with data.
Ans4. Database manager
Ans5. Data independence
Lesson 2 / Slide 3 of 14
1B.5 Relational Database Desi
g
n
D
D

A
A
T
T
A
A
M
M
O
O
D
D
E
E
L
L
S
S
Data Models Lesson 2 / Slide 4 of 14©NIIT
Data Models
Data Models
•
A data model is a description of the organization of data in a
database.
•
The data model also describes the relationship among data and
any constraints that have to be defined on the data.
•
Data models can broadly be classified into two categories:
•

Object-based logical model – focuses on describing the data,
the relationship among the data, and any constraints defined.
•
Record-based logical model – focuses on describing the data
structure and the access techniques in a Database
Management System.
A data model is a description of the organization of data in a database. In addition to
the organization of data, the data model also describes the relationship among data
and any constraints that have to be defined on the data. Data models can broadly be
classified into two categories:
Object-based logical model – focuses on describing the data, the relationship
among the data, and any constraints defined.
Record-based logical model – focuses on describing the data structure and the
access techniques in a Database Management System.
Object-Based Logical Model
There are various object-based models. The most widely used is the entity-
relationship model (E/R model). It is accepted as the ideal data model for database
1B.6
Relational Database Desi
g
n
design. Peter Chen introduced this model in 1976, and since then, several people have
added value to it.
The Entity-Relationship Model
Data Models Lesson 2 / Slide 5 of 14©NIIT
Data Models
Entity-Relationship Model
•
There are various object-based models. The most widely used is
the entity-relationship model (E/R model).

•
The entity-relationship model is based on a real-world perception
that comprises a collection of objects or entities and the
relationships among these.
•
The diagram used to represent an E/R model is called an E/R
diagram.
•
The components of an E/R diagram are:
•
Entities
•
Relationships
•
Attributes
The entity-relationship model is based on a real-world perception that comprises a
collection of objects or entities and the relationships among these. Chen introduced
not only the E/R model, but also a corresponding diagramming technique. Consider
the following diagram:
1B.7 Relational Database Desi
g
n
Sample E/R Diagram
This diagram has various components and depicts the relationship between the
components. The various components of the diagram are entities – course and
semester, relationship – taught, and attributes – title, code, start-dt, end-dt, and sem
#.
1B.8
Relational Database Desi
g

n
Entities
Data Models Lesson 2 / Slide 6 of 14©NIIT
Data Models
Entities
•
An entity is any object, place, person, or activity about which data
is recorded.
•
Entities are named and represented inside a box.
•
There are two types of entities:
•
Dependent
•
Independent
•
Dependent entities are also called weak entities, and independent
entities are called regular entities.
•
Weak entities are represented by double-lined boxes.
Chen defined an entity as “a thing, which can be easily identified”. An entity is any
object, place, person, or activity about which data is recorded. Some examples of
entities are Student, Course, and Grade. In the diagramming technique, entities are
named and represented inside a box.

Entities
It is important to distinguish between an entity type and an entity instance. An entity
type is a set of things that share common properties. For example, STUDENT,
1B.9 Relational Database Desi

g
n
COURSE, and GRADE. An entity type is usually in uppercase. An entity instance is a
specific individual thing. For example, Jack Ripper is the entity instance of the entity
STUDENT, Philosophy is the entity instance of the entity COURSE, and A is the entity
instance of the entity GRADE.
There are two types of entities: dependent and independent. An entity whose
existence depends on the existence of another entity is called a dependent entity.
Consider the entity type OFFERING. OFFERING entity refers to the various
combinations of subjects offered in a course. A course with the same code can be
offered in different semesters on different campuses. The existence of OFFERING
depends on the existence of the entity type COURSE.
Entity B is existence-dependent on entity A when:
Some instance of A must exist before B can exist.
Entity A ceases to exist, which causes B to cease to exist.
For example, the university offers a COURSE in database design in the second
semester. The university can offer this course only if the entity instance “database
design” already exists. If the university decides to drop the entity instance “database
design” from the curriculum, the offering of the course must also cease to exist. A
dependent entity is depicted by a double-lined box and is connected by a line to the
entity it depends on.
An independent entity does not depend on any other entity for existence. Dependent
entities are also called weak entities, and independent entities are called regular
entities.
Dependent Entity
A regular entity and its weak entities can be considered as a single
object in a database. This is because weak entities are dependent on
the regular entity.
1B.10
Relational Database Desi

g
n
Relationships
Data Models Lesson 2 / Slide 7 of 14©NIIT
Data Models
Relationships
•
A relationship is an association among entities.
•
A relationship is depicted as a diamond with the name of the
relationship type.
•
A relationship can associate an entity with itself.
•
Multiple relationships can also exist between the same entities.
•
There are three types of relationships:
•
One-to-One
•
One-to-Many
•
Many-to-Many
Chen defined a relationship as “an association among entities”. For example, there is a
relationship between students and instructors. This relationship represents the fact
that an instructor teaches several students and a student is taught by several
instructors. This relationship could be named TEACH. As with entities, it is necessary
to distinguish between relationship types and instances.
A relationship type is an association of entity types. For example, the association
between a STUDENT and an INSTRUCTOR where STUDENT and INSTRUCTOR are both

entity types. A relationship instance is an association of entity instances, for example,
the association between a student called J. Reins and the instructor called Dr. Jack.
A relationship is depicted as a diamond with the name of the relationship type.
1B.11 Relational Database Desi
g
n
Relationships
A relationship can associate an entity with itself. For example, one instructor in a
university may marry another instructor. Therefore, the following relationship is
possible:
Relating an Entity with Itself
Also, another example of an entity associating with itself can be a student giving a
seminar presentation to other students.
Relating an Entity with Itself
Multiple relationships can also exist between the same entities. Here is an example:
STUDENT
SEMINA
R
1B.12
Relational Database Desi
g
n
Multiple Relationships Between Same Entities
Types of Relationships
There are three types of relationships:
One-to-One
One-to-Many (or Many-to-One)
Many-to-Many
Consider the example of a university. For a particular DEPARTMENT (like the
department of social sciences) there can be only one DEPARTMENT HEAD. This is an

example of a one-to-one relationship.
One-to-One Relationship
A STUDENT can MAJOR in only one course, but many STUDENTs can register for a
given MAJOR course. This is an example of many-to-one relationship.
1B.13 Relational Database Desi
g
n
Many-to-One Relationship
A STUDENT can take many COURSEs and many STUDENTs can register for a given
COURSE. This is an example of a many-to-many relationship.
Many-to-Many Relationship
The types of relationships between two entities are represented in E/R diagrams by
certain symbols. An entity may be associated with one, none, or many occurrences of
another entity.
1B.14
Relational Database Desi
g
n
Attributes
Data Models Lesson 2 / Slide 8 of 14©NIIT
Data Models
Attributes
•
An attribute is a property of a given entity.
•
Attributes are depicted as ellipses, labeled with the name of the
property. The key properties are underlined.
•
A relationship can also have attributes.
An attribute is a property of a given entity. For example, ROLL_NO is a property of an

entity STUDENT. An attribute instance is a particular property of an individual entity
instance. For example, Peter is the instance of STUDENT entity and the roll number
101 is the instance of attribute ROLL_NO and also the property of the entity instance
Peter. An attribute type is a property of the entity type. For example, “male” is an
attribute instance, while “gender” is an attribute type. Attributes are depicted as
ellipses, labeled with the name of the property. The key properties are underlined. A
key property uniquely identifies an entity instance. In the example below, a particular
student can be uniquely identified from the roll number rather than the name. It is
possible for more than one student to have the same name, but a roll number is never
duplicated. A relationship can also have attributes.
1B.15 Relational Database Desi
g
n
Attributes
Subtypes and Supertypes
A subtype is a subset of another entity. For example, consider the entity COURSE.
There are two types of COURSES—semester courses and standalone courses. In the
following figure, COURSE is the supertype, and SEMESTER and STANDALONE are the
subtypes.
There are some attributes that are common to both the subtypes, for example,
“name” and “content”. STANDALONE courses have some attributes, like “course code”
that do not belong to the subtype SEMESTER. The subtype SEMESTER has some
attributes like “semester_no” that do not belong to the subtype STANDALONE.
1B.16
Relational Database Desi
g
n
Subtypes and Supertypes
A subentity or subtype is always dependent on the supertype for its existence. The
attributes of a supertype apply to all of its subtypes. The converse is not true.

Subtypes are connected to the supertype by an unnamed relationship. The supertype
is connected to the relationship with a line containing a crossbar, as indicated in the
above figure. The supertype is described by attributes that belong to all subtypes. The
subtype is described by the attributes that are unique to it.
Record-Based Logical Model
Now that you are familiar with the E/R model, which is an example of an object-based
logical model, we will look at other data models.
The three types of record-based models are:

Hierarchical model
Network model
Relational model
In a hierarchical model, data is represented in the form of a tree. Data in a
hierarchical model is represented by a collection of records, and relationships between
the data are represented by links.
1B.17 Relational Database Desi
g
n
A network model is similar to a hierarchical model in the way that data and the
relationships among them are represented in the form of records and links. However,
records in a database are represented graphically.
In the relational model, the database is structured in fixed-format records of several
types. Each record type has a fixed number of attributes or fields, which are usually of
fixed length.
Of these three models, the relational model is the most popular.
Relational Model
Data Models Lesson 2 / Slide 9 of 14©NIIT
Data Models
Relational Model
•

The three types of record-based models are:
•
Hierarchical model
•
Network model
•
Relational model
•
The relational model is an attempt to simplify the database
structure. It represents all data in the database as simple tables in
the row-column format.
•
A Relational Database Management System (RDBMS) can be
defined as a database management system where all data visible
to the user is organized strictly as tables of data values, and where
all database operations work on these tables.
Dr. E. F. Codd first described the relational model in 1970. The relational model is an
attempt to simplify the database structure. It represents all data in the database as
simple tables in the row-column format.
1B.18
Relational Database Desi
g
n
I_CODE NAME AGE SEMESTER
I1001 NANCY
MATHEWS
27 I
I1002 CATHERINE 38 II
I1003 MAC THAMES 50 IV
I1004 JOE NELSON 35 III

Instructor Table
A Relational Database Management System (RDBMS) can be defined as a database
management system where all data visible to the user is organized strictly as tables of
data values, and where all database operations work on these tables.
Let’s take a look at the data structure of an RDBMS.
Relational Data Structure
Data Models Lesson 2 / Slide 10 of 14©NIIT
Data Models
Relational Data Structure
•
A table is called a relation, the row (or record) in the table is called
a tuple, and the column (or field) is called an attribute.
•
The number of tuples is called the cardinality of the table, and the
number of attributes is called the degree of the table.
•
A table where every row is different from all other rows is called a
relation in mathematical terms.
•
One important property of a relation is that its rows are unordered.
•
Every table must have some column or combination of columns
that uniquely identifies each row in the table. This column (or
columns) is called the primary key of the table.
•
A domain is a pool of values from which one or more attributes
(columns) draw their actual values.
•
In an RDBMS, missing or unknown information is represented as a
NULL value in a table.

1B.19 Relational Database Desi
g
n
Data Models Lesson 2 / Slide 11 of 14©NIIT
Data Models
Relational Data Structure (Contd )
•
Relationships are represented by common data values stored in
two or more tables.
•
A column in one table whose value matches the primary key in
some other table is called a foreign key.
•
Together, a primary key and a foreign key create a parent-child
relationship between the tables that connect them.
The organizing principle in a relational database is the table, a rectangular row-column
arrangement of data values. Each table in a database has a unique table name that
identifies its contents. A table is called a relation.
The row (or record) in the table is called a tuple, and the column (or field) is called an
attribute. Every column in a table must have a unique name. The number of tuples is
called the cardinality of the table, and the number of attributes is called the degree of
the table.
One important property of a relation is that its rows are unordered. A row cannot be
identified by its position in the table. Every table must have some column or
combination of columns that uniquely identifies each row in the table. At any given
time, no two rows of the table contain the same values in that column or column
combination. This column (or columns) is called the primary key of the table. For
example, in the student table, ROLL_NO is the primary key as it uniquely identifies
each student. A table where every row is different from all other rows is called a
relation in mathematical terms. The term relational database comes from this

mathematical term.
A domain is a pool of values from which one or more attributes (columns) draw their
actual values. For example, the domain for the attribute CODE would be the set of all
1B.20
Relational Database Desi
g
n
legal supplier codes. A set of values appearing in that column at any given time, would
be a subset of that domain.
SUPPLIER Table
Data Structure of an RDBMS
Representing Missing Information
The problem of missing or unknown information is common in the real world. For
example, a person does not know the date of a seminar that is yet to be announced.
In an RDBMS, missing or unknown information is represented as a NULL value in a
table. If a row has the value NULL in a column, it means that a particular attribute for
that row is unknown. NULL is not the same as space or zero.
Representing Relationships in an RDBMS
One major difference between the relational model and earlier data models is that
explicit pointers such as parent-child relationships of the hierarchical model are
banned from the relational model. Yet, these relationships do exist in the relational
model. However, these relationships are represented by common data values stored in
two or more tables. All relationships are represented in an RDBMS in this manner.
A column in one table whose value matches the primary key in some other table is
called a foreign key. Together, a primary key and a foreign key create a parent-child
relationship between the tables that connects them.
CODE NAME ADDRESS STATUS
S24 Anthony C.Place 20
S51 Derry 641, Golf
Link

10
S52 Kerry 71/42, Safe
End
15
DOMAIN
CODE
DOMAIN
NAME
DOMAIN
ADDRESS
DOMAIN
STATUS
Primary Key
Relation
Attributes
Tuples
1B.21 Relational Database Desi
g
n
Parent-Child Relationship in a Relational Model
Just as a combination of columns can serve as the primary key of the table, a foreign
key can also be a combination of columns. The number of columns and the data types
of the key must be identical to one another. A table can contain more than one foreign
key if it is connected to more than one table.
INSTRUCTOR Table
I_CODE NAME AGE SEMESTER
I1001 NANCY
MATHEWS
27 I
I1002 CATHERINE 38 II

I1003 MAC THAMES 50 IV
I1004 JOE NELSON 35 III
BATCH Table
BATCH_CODE COURSE_CODE SEMESTER I-CODE
B001 C0001 I I1001
B002 C0002 II I1002
B003 C0003 III I1003
B004 C0001 I I1001
Parent-Child Relationship in a Relational Model
Foreign
Key
Primary
Key
1B.22
Relational Database Desi
g
n
In the Instructor table, the Instructor Code (I_CODE) is the primary key and in the
Batch table the I-CODE is the foreign key. Only the instructor codes that are present
in the Instructor table can be entered in the Batch table.
I
I
N
N
S
S
T
T
R
R

U
U
C
C
T
T
O
O
R
R
N
N
O
O
T
T
E
E
S
S
Data Models
You can take the following additional example to explain an entity:
BRANCH - is a set of all branches of a particular bank.

CUSTOMER - is a set all people who have their account in the bank.

EMPLOYEE - is a set of all people who work in the bank.
ACCOUNT - is a set of all accounts that are maintained in the bank.
You can take the following entities to explain an attribute:
BRANCH - has attributes such as branch_code, branch_name, and location.


CUSTOMER - has attributes such as customer_code, customer_name,
customer_address, and account_number.
EMPLOYEE - has attributes such as employee_code, employee_name, and
employee_address.
ACCOUNT - has attributes such as account_number, account_type, and
balance_amount.
For the above mentioned entities and attributes, unique identifiers will be:
BRANCH - branch_code
CUSTOMER - customer_code, account_number
EMPLOYEE - employee_code
ACCOUNT - account_number
You can ask the following question to test whether the students understand the
difference between an entity type and entity instance:
Classify the following into entity type and entity instance:
1B.23 Relational Database Desi
g
n
1. Ken Burton
2. Employee
3. Department
4. Research and Development division
5. Supplier
Solutions:
1. Entity instance
2. Entity type
3. Entity type
4. Entity instance
5. Entity type
You can give the following additional information while explaining hierarchical and

network models:
In a Hierarchical Database Management System (HDBMS), the data is stored
conceptually in a hierarchical format. An example of such kind of data storage is an
XML data island where there is a root tag and there are child tags below the root tag.
Each of these child tags can in turn have child tags. This kind of a formation resembles
a tree. An example can be a Firm that can have a child called Factory(s), which in turn
can have a child called Employee(s). In an HDBMS, a one-to-one or a one-to-many
relationship can be very easily implemented but implementing a many-to-many
relationship is not possible. In a Networked Database Management System (NDBMS),
the child node of an HDBMS can be associated to multiple parent nodes. Like HDBMS a
many-to-many relationship cannot be implemented in an NDBMS.
Object-Relational Database Management System (ORDBMS) are extensions of existing
RDBMS that can be used to fulfill complex jobs of storing and managing objects. For
instance, using an ORDBMS, image objects can be stored and managed. Examples of
ORDBMS are Informix Universal Server and Adaptive Server of Sybase Inc.
You can support your explanation of the relational model with the following
information:
A relationship is an association established between the common fields (columns) in
two tables.
A field is a space allocated for a particular item of information. For example, a tax
form can contain a number of fields to store information like your name, your Social
Security number, your income, and so on. In database systems, fields are the smallest
units of information that can be accessed.
1B.24
Relational Database Desi
g
n
Fields have certain attributes associated with them. For example, some fields are
numeric whereas others are textual. In addition, every field has a name, called the
field name.

In an RDBMS, a field is also referred to as a key that you use to sort data. It can also
be called a key field, sort key, index, or key word. For example, if you sort records by
age, then the age field is a key. Most database management systems allow you to
have more than one key so that you can sort records in different ways. One of the
keys is designated as the primary key, and must hold a unique value for each record.
The field that identifies records in a different table is called a foreign key.
Consider a situation where each customer is assigned a customer number. The
customer number is unique for that customer. This might be a customer number that
is used by your company or a number that is automatically assigned by the computer,
which the user may never even see. It is essential, however, that there be only one
customer at any time having that customer number. The customer number uniquely
identifies each customer "record". A "record" is a single entry in a table. For instance,
in the Customers table, each customer's information constitutes a record and in the
Sales table, each sale constitutes a record.
The customer number in the Customer table is called a "primary key".
A primary key is also required in the Sales table. In addition, the customer number of
the customer should also appear in this table as a "field". A field is a single type of
information in a table. In the Customers table, we would have a customer name field,
a customer number field, etc.
The customer number in the Sales table is called a "foreign key". A foreign key is a
copy of a primary key that appears elsewhere.
Two foreign keys can be collectively set to create a primary key, called a composite
key. Some RDBMSs will then automatically prevent the duplication of any combination
of those fields. Any number of fields may be identified as a composite key together.
However, composite keys should not be used too widely, as they are slower than
single-field primary keys (since the RDBMS has to check two or more full fields of
information in each table rather than just one field). Also, composite keys become
awkward when more than two or three fields are in use, and it is more difficult to refer
to specific records through composite keys than through single keys.
You can ask the following question to the students to make them think about primary

keys:
What kinds of fields make good primary keys?
Answer: One type of field that makes an excellent primary key is a "counter" field.
This is a field with a whole number as its value, which automatically creates a new,
unique number for each record. As a rule, numeric keys are preferable to text keys
because they take up less memory and therefore are faster and require less data
storage space. The counter field additionally removes the concern of generating a
unique value for the primary key field for each new record.
Date/time stamps make tolerable primary keys in some RDBMSs, as long as the
program is never being used by more than one person at a time.
1B.25 Relational Database Desi
g
n
A social security number may not be the best primary key, for several reasons: first,
they take up more digits than would generally be required. Second, the U.S.
government sometimes assigns the same social security number twice (usually when
the first holder is deceased). Third, anyone who is not a U.S. citizen may not have a
social security number. Fourth, we are told that it is not permissible by law to require
a person to supply their social security number; tax ID numbers can be assigned and
used instead in some cases.