STRUCTURE OF RELATIONAL

DATABASE

K.MATHIYAZHAGAN
Assistant Professor
Dept. Of Computer Applications
Sri Sankara Arts and Science College
 STRUCTURE OF RELATIONAL
DATABASE
• A relational database consist of a collection of tables each
having a unique name
• A row in a table represents a relationship among a set of
values
• Thus a table represents a collection of relationships
• There is a direct correspondence between the concept of
a table and the mathematical concept of a relation
• A substantial theory has been developed
for relational databases
 Basic structure
 Database scheme
 Keys
 Query languages
 BASIC STRUCTURE

• The following figure shows the deposit and customer

table for our banking example

Deposit table Customer table

C name B name account Balance C name street city
XXX SBI SB’01 1000 Xxx gandhi Kanchi
YYY IOB IB2C3 1500 Yyy kamarajar Chennai
222 CANARA C102 2000 222 mettu kanchi
• The deposit relation has four attributes
• For each attributes there is a permitted set of
values called the domain of that attribute
• E.g: the domain Cname is the set of all customer
names
• Let D1 denote the domain of Cname and D2, D3
and D4 the remaining attributes domains
respectively
• Then, any row of deposit consists of a four-tuple(v1, v2, v3, v4)
where v1 € D1 ,v2 € D2, v3 € D3, v4€ D4
• In general, deposit contains a subset of the set of all possible
rows.
i.e., deposit is a subset of

x 4
i=1 Di

• In general a table of n columns must be a subset of

x ni=1 Di (All possible rows)

2. Mathematicians define a relation to be a
subset of a Cartesian product of a list of
domains
• We can see the correspondence with our table
• We will use the terms relation and tuple in place
of table and row from now on
3. Some more formalities:
• Let the tuple variable t refer to a tuple of the relation r
• We say t € r to denote that the tuple t is in relation r.
• Then t[Cname] = t[1] = the value of t on the Cname
attribute
• So t[Cname] = t[1] = ”yyy”,
and tbname = t[2] = ”IOB”
4. We will also require that the domains of
all attributes be indivisible units
• A domain is atomic if its elements are
indivisible units
• For eg: the set of integer is an atomic domain
 DATABASE SCHEMA

1. We distinguish between a database schema

(logical design)and a database instance(data in
the database)
2. A relation schema is a list of attributes and this
corresponding domains
3. The text uses the following conventions:
1. Italics for all names
2. Lowercase names for relations and attributes
3. Names beginning with an uppercase for
relation schemas
• For e.g: the relation schema for the deposit
relation
• Deposit-schema=(Cname, bname, accountno, balance)
• We may state that deposit is a relation on schema
Deposit-schema by writing deposit (Deposit-schema)
• If we wish to specify domains we can write
(name:string, bname:string, accountno: integer,
balance: integer)
• The figure shows the ER diagram for a banking
enterprise
 Account # Balance

Street Assets
Deposi
C name C City t B Name B city

Customer Branch

Borrow

Loan # Amount
4. The relation schema for the banking example
used throughout the text are:
• Branch-schema=(bname,assets,bcity)
• Customer-schema=(Cname, street, city)
• Deposit-schema=(Cname, bname, account#, balance)
• Borrow-schema=(bname,Cname, loan#,amount)
NOTE

• Some attributes apper in several relation

schemas
• Eg: bname, Cname. This is legal and provides a
way of relating tuples of distinct relations
5. Why not pull all attributes in one relation?
• Suppose we use one large relation instead of
customer and deposit
• Account-schema=(bname, account#, Cname,
balance, street, ccity)
• If a customer has several accounts we must duplicate
her/his address for each account
• If the customer has an account but no current
address we cannot build a tuple, as we have no
values for the address
• We would have to use null values for these fields
• Null values cause difficulties in the database
• By using two separate relations we can do this
without using null values
 KEYS
• Let K c R
• K is a superkey to R if values of K are sufficient
to identify a unique tuple of each possible
relation r(R)
• By “possible r” we mean a relation r that could
exist in the enterprize we are modelling
 EXAMPLE
• {Customername, Customerstreet} and {Customername}
are both superkey of customer
• If no two customer can possibly have the same name
• K is a candidate key if k is minimal
Example
• {Customername} is a candidate key for customer, since it
is a superkey (assuming no two customers can possibly
have the same name) and no subset of it is a superkey
 DETERMINING KEYS FROM ER SETS
Strong entity set:
• The primary key of the entity set becomes the primary key
of the relation
Weak entity set:
• The primary key of the relation consists of the union of the
primary key of the story 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
• For binary many-to-one relationship, the primary
key of the “many” entity set becomes the relations
primary key
• For one-to-one relationship sets, the relations
primary key can be that of either entity set
 QUERY LANGUAGES

• Languages in which user requests information

from the database
• Categories of languages:
Procedural
Non-procedural
• Procedural language:
Relation algebra
Tuple relational calculus
Domain relational calculus

• Pure languages from underlying basis of

query languages that people use
THANK YOU