Scribd
Upload
900 views24 pages

Structure of Relational Database: K.Mathiyazhagan

1. A relational database consists of a collection of tables, with each table representing a relationship among a set of values. Each row represents a tuple with values corresponding to each attribute. 2. Tables have a direct correspondence to mathematical relations, with each tuple being a member of the Cartesian product of the attribute domains. 3. Keys such as candidate keys are used to uniquely identify tuples and enforce relationships between tables according to an entity-relationship schema. Query languages allow users to request information from the database.

Uploaded by

madhu mitha
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
900 views24 pages

Structure of Relational Database: K.Mathiyazhagan

1. A relational database consists of a collection of tables, with each table representing a relationship among a set of values. Each row represents a tuple with values corresponding to each attribute. 2. Tables have a direct correspondence to mathematical relations, with each tuple being a member of the Cartesian product of the attribute domains. 3. Keys such as candidate keys are used to uniquely identify tuples and enforce relationships between tables according to an entity-relationship schema. Query languages allow users to request information from the database.

Uploaded by

madhu mitha
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 24

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

You might also like