NAME:- Arjun Gondhali

BRANCH:-IT ROLL NO:-A44 ID:-TU4F2324050

Experiment : 2

MAPPING ER TO RELATIONAL SCHEMA MODEL

Aim : Mapping ER diagram to relational schema model.

Theory: The relational model is today the primary data
model for commercial data-processing applications. It has
attained its primary position because of its simplicity, which
eases the job of the programmer, as compared to earlier
data models such as the network model or the hierarchical
model.

Basic Structure:

Consider the account table of Figure 3.1. It has three

column headers: account-number, branch-name, and
balance. Following the terminology of the relational model,
we refer to these headers as attributes. For each attribute,
there is a set of permitted values, called the domain of that
attribute. For the attribute branch-name, for example, the
domain is the set of all branch names. Let D1 denote the set
of all account numbers, D2 the set of all branch names, and
D3 the set of all balances. As we saw in Chapter 2, any row
of account must consist of a 3-tuple (v1, v2, v3), where v1 is
an account number (that is, v1 is in domain D1), v2 is a
branch name (that is, v2 is in domain D2), and v3 is a
balance (that is, v3 is in domain D3). In general, account will
contain only a subset of the set of all possible rows.
Therefore, account is a subset of
D1 × D2 × D3
In general, a table of n attributes must be a subset of
D1 × D2 × ··· × Dn−1 × Dn
Thus, a relation is a set of n-tuples (a1, a2, …, an) where
each ai ∈ Di.
Example: If
customer_name = {Jones, Smith, Curry, Lindsay, …}
/* Set of all customer names */
customer_street = {Main, North, Park, …} /* set of all street
names*/
customer_city = {Harrison, Rye, Pittsfield, …} /* set of all city
names */
Then r = { (Jones, Main, Harrison),
(Smith, North, Rye),

(Curry, North, Rye),

(Lindsay, Park, Pittsfield) }
is a relation over
customer_name x customer_street x customer_city.

Database Schema:

When we talk about a database, we must differentiate

between the database schema,which is the logical design of
the database, and a database instance, which is a snap-
shot of the data in the database at a given instant in time.
The concept of a relation corresponds to the programming-
language notion of avariable. The concept of a relation
schema corresponds to the programming-language
notion of type definition.It is convenient to give a name to a
relation schema, just as we give names to type
definitions in programming languages. We adopt the
convention of using lower-case names for relations, and
names beginning with an uppercase letter for relation
schemas. Following this notation, we use Account-schema
to denote the relation schema for relation account. Thus,
Account-schema = (account-number, branch-name, balance)
We denote the fact that account is a relation on Account-
schema by
account(Account-schema)

h attribute until we discuss the SQL language in Chapter 4.

The concept of a relation instance corresponds to the
programming language no-tion of a value of a variable. The value of a given
variable may change with time; similarly the contents of a relation instance
may change with time as the relation is updated. However, we often simply
say “relation” when we actually mean “relation instance.” The schema for
that relation is

Branch-schema = (branch-name, branch-city, assets)

In a real-world database, the customer-id (which could be a

social-security number, or an identifier generated by the
bank) would serve to uniquely identify customers.
We also need a relation to describe the association between
customers and accounts. The relation schema to describe
this association is

Depositor -schema = (customer-name, account-number)

Loan-schema = (loan-number, branch-name, amount)

Borrower -schema = (customer-name, loan-number)
Keys:

The notions of superkey, candidate key, and primary key,

are also applicable to the relational model.

For example, in Branch-schema, {branch-name} and

{branch-name, branch-city} are both superkeys. {branch-
name, branch-city} is not a candidate key, because {branch-
name} is a subset of {branch-name, branch-city} and
{branch-name} itself is a superkey. However, {branch-name}
is a candidate key, and for our purpose also will serve as a primary key.
The attribute branch-city is not a superkey, since two branches in the same
city may have different names (and different asset figures).
Let R be a relation schema. If we say that a subset K of R is a superkey for R,
we are restricting consideration to relations r(R) in which no two distinct
tuples have the same values on all attributes in K. That is, if t 1 and t 2 are in r
and t 1 # = t 2 , then t 1 [K] # = t 2 [K].
If a relational database schema is based on tables derived
from an E-R schema, it is possible to determine the primary
key for a relation schema from the primary keys of the
entity or relationship sets from which the schema is derived:
• Strong entity set. The primary key of the entity set becomes the primary
key of the relation.
• Weak entity set. The table, and thus the relation, corresponding to a weak
entity set includes
-The attributes of the weak entity set
-The primary key of the strong entity set on which the weak
entity set
-The primary key of the relation consists of the union of the primary key of
the strong entity set and the discriminator of the weak entity set.

• Relationship set. The union of the primary keys of the

related entity sets becomes a superkey of the relation. If the
relationship is many-to-many, this superkey is also the primary key.
• Combined tables : A binary many-to-one relationship set
from A to B can be represented by a table consisting of the
attributes of A and attributes (if any exist) of the relationship
set. The primary key of the “many” entity set becomes the primary key of the
relation (that is,if the relationship set is many to one from A
to B, the primary key of A is the primary key of the relation).
For one-to-one relationship sets, the relation is constructed
like that for a many-to-one relationship set. However, we
can choose either entity set’s primary key as the primary key of
the relation, since both are candidate keys.

• Multivalued attributes: A Multivalued attribute ,M is

represented by a table consisting of the primary key of the
entity set or relationship set of which M is an attribute plus a column C
holding an individual value of M. The primary key of the
entity or relationship set, together with the attribute C,
becomes the primary key for the relation.

From the preceding list, we see that a relation schema, say r

1 , derived from an E-R schema may include among its attributes the primary
key of another relation schema, say r 2 . This attribute is called a foreign key
from r 1 , referencing r 2 . The relation r 1 is also called the referencing
relation of the foreign key dependency, and r 2 is called the referenced
relation of the foreign key.
For example, the attribute branch-name in
Account-schema is a foreign key from Account-schema
referencing Branch-schema, since branch-name is the
primary key of Branch-schema. In any database instance,
given any tuple, say t a , from the account relation, there
must be some tuple, say t b , in the branch relation such that
the value of the branch-name attribute of t a is the same as
the value of the primary key, branch-name, of t b .

It is customary to list the primary key attributes of a relation

schema before the other attributes; for example, the branch-name attribute
of Branch-schema is listed first,since it is the primary key.

Schema Diagram:
A database schema, along with primary key and foreign key
dependencies, can be depicted pictorially by schema
diagrams. Each relation appears as a box, with the
attributes listed in-side it and the relation name above it. If there are primary
key attributes, a horizontal line crosses the box, with the primary key
attributes listed above the line. Foreign key
dependencies appear as arrows from the foreign key attributes of the
referencing relation to the primary key of the referenced relation.
Do not confuse a schema diagram with an E-R diagram. In
particular, E-R diagrams do not show foreign key attributes
explicitly, whereas schema diagrams show them explicity.
Many database systems provide design tools with a
graphical user interface for creating schema diagrams.

OUTPUT:
CONCLUSION:
Thus we have mapped ER-Mapping to Relational Schema Model.