SYBCA (Sem.

-III)
US03FBCA01

RDBMS UNIT 1

UNIT - 1
TOPICS
Introduction:
The three-schema architecture for a Database Management System (DBMS)
Data Models: (1) Hierarchical
(2) Network
(3) Relational
Examples of current RDBMS products
Relation data models concept, terminologies: tuple, attribute, domain, relation (Definition)
Operations on data (DDL, DML)
-- Relationships and relationship types
The Three-Level Architecture Proposal for a DBMS :The architecture, show in figure is divided into three levels the external level, the conceptual level, and
the internal level.
The view at each of these levels is described by a scheme. A scheme is an outline or a plan that described
the records and relationships existing in the view. The word scheme, which means a systematic
plan for attaining some goal, is used interchangeably in the database literature with the word
scheme. The word scheme is used in the database literature for the plural instead of schemata, the
grammatically correct word. The scheme also describes the way in which entities at one level of
abstraction can be mapped to the next level.
External or user view
The external or user view is at the highest level of database abstraction where only those portion of the
database of concern to a user or application program are included. Any number of user views
(some of which may be identical) may exist for a given global or conceptual view.
Each external view is described by means of a scheme called an external 3scheme. The external scheme
consists of the definition of the logical records and the relationships in the external view. The
external scheme also contains the method of deriving the objects in the external view from the
objects in the conceptual view. The objects includes entities, attributes, and relationships. (The
terms view, scheme, and scheme are sometimes used interchangeably when there is no confusion
as to what is implied.)
View
External View

Conceptual Level

View
2

View
3

Conceptual view
Mapping supplied by DBMS

Internal Level

Internal view

Page 1 of 11

SYBCA (Sem.-III)
US03FBCA01

RDBMS UNIT 1

Conceptual or Global view

At this level of database abstraction all the database entities and the relationships among them are
include. One conceptual view represents the entire database. This conceptual view is defined by
the conceptual scheme. It describes all the records and relationships included in the conceptual
view and, therefore, in the database. There is only one conceptual scheme per database. This
scheme also contains the method of deriving the conceptual view from the objects in the internal
view.
The description of data at this level is in a format independent of its physical representation. It also
include features that specify the check to retain data consistency and integrity.
Internal view
We fine this view at the lowest level of abstraction, closest to the physical storage method used. It
indicates how the data will be stored and describes the data structures and access method to be
used by the database. The internal view is expressed by the internal scheme, which contains the
definition of the stored record, the method of representing the fields, and the stored record the
method of representing the data fields, and the access aids used.

Data Models::
Relational Data Mode:
The relational data model. After more than a decade, has emerged from the research, development, test
and trial as a commercial product. Software system using this approach are available for all sizes
of computer system. This model has the advantage of being simple in principal; users can express
their queries in a powerful query language. It is expected that many exiting database application
will be retrofitted to use this approach.
In this model, the relation is the only construct to represent the association among the attributes of an
entity as well as the relationship among different entities. One of the main reasons for introducing
this model was to increase the productivity of the main application programmer the need to change
application programs when a change is made to the database. User need not know the exact
physical structures. They are however, still required to know how the data has been partitioned into
the various relations. While is possible to infer access paths from the relational model, as we will
see later, the relational approach dose require the user to provide logical navigation through the
database for the query.

Page 2 of 11

SYBCA (Sem.-III)
US03FBCA01
EMPLOYEE

RDBMS UNIT 1
POSITION

Empl_no

Name

Skill

123456

Ron

Waiter

123457

Jon

Bartender

123458

Don

Busboy

123459

Pam

Hostess

123460

Pat

Bellboy

123461

Ian

waiter

Posting no

Skill

321

Waiter

322

Bartender

323

Busboy

324

Hostess

325

Malter d

326

waiter

The relational is the only data structure used in the relational data model to represent both entities and
the relationship between them. A relation may be visualized as a named table. Figure 2.33 show the
two relations EMPLOYEE and POSITION using a tabular structure. Each column of the table
corresponds to an attribute of the relation and is named.
Rows of the relation are referred to as tuples of the relation and the columns are its attributes.
Each attribute of a distinct name. the domains of an attribute contains the set of value that
the attribute may assume. In the relational model, note that no to rows of a relation are
identical and the ordering of the rows is not significant.
A relational represented by a table having n columns, defined on the domains D1,D2 Dn is a
subset of the Cartesian product D1 * D2 * Dn.
A relationship is represented, as in the E-R model, by combining the primary keys of the entities
involved in a relation and its attributes, if any.
A correspondence between two relation is implied by the data values of attributes in the relation defined
on common domains. Such correspondence is used in navigation through the relational database.
In the explain in figure 2.33 both the EMPLOYEE and POSITION relation contain the identically
named attribute skill defined on a common domain. Consequently we can join these two relational
to from the relation, POSITION_ELIGIBILITY using the common value of the attributes skill.
Joining the two relations involves taking two rows, one from each table, such that the value of skill
in the two row is identical, and then concatenating these rows. Note that in figure 2.34 the first
attributes skill is form the EMPLOYEE relation POSITION_ELIGIBILITY by their respective
relation names would allow us to more strictly adhere to the relational model where would allow
us to more strictly adhere to the relational model where names of attributes in the same relation are
distinct.

Page 3 of 11

SYBCA (Sem.-III)
US03FBCA01

RDBMS UNIT 1

POSITION_ELIGIBILITY
POSITION.
EMPL_NO

NAME

EMPLOYEE
SKILL

POSTING_NO
SKILL

123455

Ron

Waiter

321

Waiter

123456

Ron

Waiter

326

Waiter

123457

Jon

Bartender

322

Bartender

123458

Don

Busboy

323

Busboy

123459

Pam

Hostess

324

Hostess

123461

Ian

Waiter

321

Waiter

123461

Ian

Waiter

326

Waiter

NETWORK DATA MODELS:The network data model was formalized in the in the late 1960 by the database task grope of the
conference on data system languages (DBTG/CODASYL) their first report(CODA 71) which has
been revised a number of times contained detailed specifications for the network data model (a
model conforming to these specifications is also know as the DBTG data model) the specifications
contained in the report and its subsequent revision have been built on commercial DBMS system
using the DBTG model.
A set type is used to represent a directed relationships between two records types the so-called owner
record type, and the member record type, like the record type, is named and specified that there is a
one-to-many relationship(i:m) between the owner and member record types. The set type can have
owner in a given set type. A database could have one or more occurrence of each of owner record
type and number of occurrences of each of its member record type. A record type cannot be a
member of two distinct occurrences of the same set type.
To avoid the confusion inherent in the use of the word set to describe the mechanism for showing
relationships in the DBTG-network model, a more precise terminology has been suggested. Such
terms as co-set, owner-coupled set, CODASYL set, and DBTG set are used to refer to a set.
Bachman(Bach 69) introduced a graphical means called a data structure diagram to denote the logical
relationship implled by the set. Here a labeled rectangle represents the corresponding entity or
record type. An arrow that connects two labeled rectangles represents a set type. The arrow
direction is from the owner type to the member record type. Figure 2.36
shows two record
types (DEPARTMENT and EMPLOYEE) and the set type DEPT_EMP, with DEPARTMENT as
the member record type.
Page 4 of 11

SYBCA (Sem.-III)
US03FBCA01

RDBMS UNIT 1

The data structure diagram have been extended to include filed names in the record type rectangle. And
the arrow is used clearly identify the data filed involved in the set associations. A one-tomany(i:m) relationship is show by a set type arrow that starts from the owner filed in the owner
record type. The filed that support the relationships are clearly identified.

Each entity in an E-R diagram is represented by a logical record type with the same name. the attributes
of the entity are represented by data filed of the record. We use the term logical record to indicated
that the actual implementation may be quite different.
The conversion of the E-R diagram into a network database consists of converting each l:m binary
relationship into a set (a l:l binary relationships being a special case of l:M relationships) if there is
a l:M binary relationships R1 from entity type E1 to entity type E2, then the binary relationship is
represented by a set. An instance of this would be S1 with an instance of the record type
corresponding to entity E1 as the owner and one or more instance of the record type corresponding
to entity E2 as the member. If a relationship has attributes, unless the attributes in a separate logical
record type created for this purpose .The introduction of this additional record corresponding to the
attributes of the relationships as the member in both the sets and the record corresponding to the
entities as the owners.
Each many to-many relationships is handled by introduction a new record type to represent the
relationship wherein the attributes, if any, of the relationship are stored. We then create two
symmetrical l:M sets with the member an each of the set being the newly introduction record type.
The conversion of a many-to-many relationship into two one-to-many sets using a common
member record type is shown in figure
FIGURE

DEPARTMENT

EMPLOYE
E
Figure :- Conversion of an M:N relationship into 1:M DBTG sets.

Entity1
Entity2
M

n
Page 5 of 11

SYBCA (Sem.-III)
US03FBCA01

RDBMS UNIT 1

Record type

Record type

for entity 1

for entity 2
Set type 1

set type 2

Common member
record type
In the network model, the relationship as well as the navigation through the database creation time
When a relationship involving a weak entity set is converted to a network set, it is possible that
several identical occurrences of the logical record type corresponding to a weak entity could exist.
These identical occurrences are distinguished by their membership in different occurrences of the
set (similar to the method of distinguishing identical weak entities by their relationship with unique
strong entities).
Hierarchical model
A tree be defined as a set of nodes such that there is one specially designated node called the root (node)
and the remaining nodes are partitioned into disjoint sets, each of which in turn is a tree, the sub
tree of the root. If the relative order of the sub trees is significant, the tree is an ordered tree.
Like an organization chart or a family tree, a hierarchy is an ordered tree and is easy to understand. At
the root of the tree is the single parent; the parent can have node, one, or more children. (note that
in comparing the hierarchical tree with a family tree, we are ignoring one of the parents; in other
words, both the pare nuts are represented implicitly by the single parent. )
In a hierarchical database, the data is organized in a hierarchical or ordered tree structure and the
database is a collection of such disloint trees (sometime referred to as a forest or spanning trees).
The nodes of the tree represent record type. Each tree effectively represents a root record type and
Page 6 of 11

SYBCA (Sem.-III)
US03FBCA01

RDBMS UNIT 1

all of its dependent record types. If we define the root record type to be at level 0, then the level of
its dependent record type can be defined as being at level 1. The dependents of the record types at
level 1 are said to be level 2, and so on.
An occurrence of a heretical tree type consists of the root record type along with zero or more
occurrences of its dependent record types. Each dependent subtree is, in turn, hierarchical and
consists of a record type as its root node. In a hierarchical model, no dependent record can occur
without its parent record occurrence. Furthermore, no dependent record can occurrence may be
connected to more then one parent record occurrence.

A hierarchical model can represent a one-to-many relationship between two entities where the two are
respectively parents and child. However, to represent a many to many relationship requires
duplication of one of the record type corresponding to one of the entities involved in this
relationship. Note that such duplications could lead to inconsistencies when only one copy of a
duplicated record is updated.
Relationships and relationship types
In addition to the associations that exist between the attributes of an entity, relationships exist among
different entities. Relationships are used to model the interactions that exist among entities and the
constraint that specifies the number of instances of one entity that is associated with the others.
Even though a relationship may involve more than two entities, we concentrate on the relationship
between two entities because it is the most common type encountered in database applications.
Such a relationship is known as a binary relationship. It may be one-to-one (1:1), one to-many
(1:M), or many-to-many (M:N).the 1:1 relationship between entity sets E1 andE2 indicates that for
each entity in either set there is at most one entity in the second set that is associated with it. The
1:M relationship from entity set E1 to E2 indicates that for an occurrence of the entity from the set
E1, there could be zero, one, or more entities from the entity set E2 associated with it. Each entity
in E2 is associated with at most one entity in the set E1. In the M:N relationship between entity
sets E1 and E2, there is no restriction as to the number of one set associated with an entity in other
set.
Figure one-to-one relationship.
DEPARTMENT

MANAGER

Represented by a rectangle and the relationship between then is indicated by a direct line. The
relationship from MANAGER to DEPARTMENT and from DEPARTMENT to MANAGER is
both 1:1. Note that a one-to-one relationship between two entity sets does not imply that for an
occurrence of an entity in the other set. In the case of an organization, there could be times when a
department is without a manager or when an employee who is classified as a manager many be
without a department to manager. Figure 2.9 shows some instances of one-to-one relationship
between the entities DEPARTMENT and MANAGER. The sets of all instances are represented by
the ovals.
A one-to-many relationship exists from the entity MANAGER to the entity EMPLOYEE because there
are several employees to the manager. As we just pointed out, there could be an occurrence of the
Page 7 of 11

SYBCA (Sem.-III)
US03FBCA01

RDBMS UNIT 1

entity type MANAGER having zero occurrences of the EMPLOYEE to MANAGER, would be
many to one, since many employee may be supervised by a single manager. However, given an
instance of the entity set EMPLOYEE, there could be only one instance of the entity set
MANAGER to whom that employee reports (assuming that no employee reports to more than one
manager ). These relationships between entities are illustrated in figure 2.10. Figure 2.11 shows
some instances of these relationships.
The relationship between the entity EMPLOYEE and the entity PROJACT can be derived as following:
Each employee could be involved in a number of different projects, and a number of employees
could be working on a given project. This relationship between EMPLOYEE and PROJECT is
many-to-many. It is illustrated in Figure 2.12. Figure 2.13 shows some instances of such a
relationship.

Figure one-to-one relationship.

D1

M1

D2

M2

D3

M3

D4

M4

D5

M5

DEPARTMENT set

Figure 2.10

MANAGER set

One-to-many relationship.

MANAGER

EMPLOYEE

Figure 2.11 One-to-many relationship from MANAGER to EMPLOYEE and many-to-one reverse
relationship.

M1
M2
M3
M4

E1
E2
E3
E4
E5

Page 8 of 11

SYBCA (Sem.-III)
US03FBCA01

MANAGER set

RDBMS UNIT 1

EMPLOYEE set

Figure 2.12 Many-to-many relationship.

EMPLOYEE

Figure

PROJECT

many-to-many relationship between EMPLOYEE and PROJECT.

E1

P1
P2

E2
E3

P3
P4
P5

EMPLOYEE set

PROJECT set

Attributes and Domains

An object or entity is characterized by its properties (or attributes). In conventional file systems the term
field refers to the smallest item of data with some practical meaning, i.e., a field is used to capture some
specific property of the object. In relational database systems, attributes correspond to fields. For a given
application, an attribute may only be allowed to take a value from a set of the permissible values. This
set of allowable values for the attributes is the domain of the attributes. In Examples 4.10 and 4.11 we
illustrate the definition of domains.
Domain:
We define a domain, Di, as a set of values of same data type.
Page 9 of 11

SYBCA (Sem.-III)
US03FBCA01

RDBMS UNIT 1

The domain Di, a set having homogeneous members, is conceptually similar to the data type concept
in programming language. A domain, like a data type,may be unstructured (atomic) or structured. Domain D1
is said to be simple if all its elements are ondecomposable (i:e., atomic). (When we use the term
decomposable,we mean in terms of the DBMS.) In typical DBMSs, atomic domains are general
sets, such as the sets of integers, real numbers, character strings, and so on. Atomicdomains are
sometimes referred to as application-independent domains because these general sets are not dependent
on a particular application.
We can also define application-dependent domains by specifying the values permitted in the particular
database. Structured or composite dornains can be specified as consisting of nona' tomic values. The
domain for the attribute Address, for instance, which specifies street number, street name, city, state, bnd
zip or postal code is considered a composite domain.
It is unfortunate that many of the currently available comrnercial relational database systems do not
support the concept of domains. Such support of both 'application-independent and user-defined domains
specified as types in programming languages allows for the validation of the value assigned to an
attribute.
Attributes are defined on some underlying domain. That is, they can assume values from the set of
values in the domain. Attributes defined on the same domain are comparable, as these attributes draw
their values from the same set' It is meaningless to compare attributes defined on different domains.
Tuples
An entity type having n attributes can be represented by an ordered set of these attributes called an ntuple. Assume that these n attributes take values from the domains D1,D2,.., , Dn. The representation of
the entity must then be a member of the set Dl x D2 x X Dn, as the resulting set of this cartesian
product contains all the possible ordered n-tuples.
A tuple is comparable to a record in conventional file systems and is used for handling entities and
relationships between entities. Tuples are generally denoted by lowercase letters r, s, t, . of the alphabet.
An ntuple t can be specified as T={a1, ,an) where each ai for 1 <= i < n is a value in the domain Di;, and
is the value of attribute Ai in the tuple t. while it is required that the attribute names be different
for unambiguous identification, no such restriction exists for domains. We may have the same domain
for different attributes' in the tuple representation above, the order of the attributes is significant,
implicitly understood, and fixed (i.e., time invariant). If, however, we associate the attributes names with
the coresponding 'values, we can relax the ordering requirement. Although the ordered set (a1, a2) is not
equal to (a2, a1)' we shall treat the sets {(.A1:a1),,A2:a2) and {(A2:a2), (A1:a1)} as the same.
As a mapping from attribute names to values in the domains of the attributes'
Relation
Conceptually, a relation can be represented as a table. Remember that the contents of a relation are
positionally independent, while a table gives the impression of positional addressing. Each column of the
table represents an attribute and each row represents a tuple of the relation. Figure shows the tabular
representation of the APPLICANT relation.
It is a myth that a relation is just a flat file. A table is just one of the conceptual representations of a
relation. It is possible to store the relations using, for instance, inverted files. a tuple may be represented
either as a labeled n-tuple or as an ordered n-tuple. The labeled n-tuples are represented using distinct
attribute names a1,a2..: ., . ., An and the valuesa1,a2 . . ., a,, from the corresponding domains.
The labeled n-tuples consist of unordered attribute value pairs:. .
Page 10 of 11

SYBCA (Sem.-III)
US03FBCA01

RDBMS UNIT 1

APPLICANT
Name
A
B
C
D
E

Age
55
31
28
33
32

Profession
Analyst
Programmer
Receptionist
Programmer
Manager

An:an).ordered n-tuples arere presented simply as(a1,)where the values appear in the same order as their
domains in the cartesian product of which the relation is a subset.

Page 11 of 11