1
STUDY MATERIAL
COURSE : II BCA ‘A’ & ‘B’
SEMESTER :IV
SUBJECT : RELATIONAL DATABASE MANAGEMENT SYSTEM
UNIT
: III
STAFF
: N.MALAR
SYLLABUS:
Relational database design_pitfalls_normalization
Object oriented databases: New database application object oriented data
model_object oriented languages_persistent programming languages.
Object relational databases: Nested relations - complex types and object
orientation - querying with complex data types_creation of complex values
and objects- comparison of object oriented and object relational databases.
RELATIONAL DATABASE DESIGN
Pitfalls in Relational-Database Design
Undesirable properties that a bad design may have are

Repetition of information

Inability to represent certain information
The information concerning loans is now kept in one single relation, lending,
which is defined over
Branch_na
me
Downtown
Redwood
Perryridge
Downtown
Mianus
Round hill
Pownal
North town
Downtown
Perryridge
Brighton
Branch - city
Brooklyn
Palo alto
Horseneck
Brooklyn
Horseneck
Horseneck
Bennington
Rye
Brooklyn
Horeneck
Brooklyn
assets
Customer
- name
9000000
Jones
2100000
Smith
1700000
Hayes
9000000
Jackson
400000
Jones
8000000
Turner
300000
Williams
3700000
Hayes
9000000
Johnson
17000000
Glenn
7100000
brooks
lending relation
Loan_nu
mber
L-17
L_23
L_15
L_14
L_93
L_11
L_29
L_16
L_23
L_25
L_10
Amoun
t
1000
2000
1500
1500
500
900
1200
1300
2000
2500
2200
The relation schema
Lending_schema = (branch_name, branch_city, assets, customer_name,
loan_number, amount)
Decomposition
The example of a bad design suggests that we should decompose a
relation schema that has many attributes into several schemas with fewer
attributes. Careless decomposition, however, may lead to another form of
bad design. Consider an alternative design in which lending_schema is
decomposed into the following two schemas.
1
2
Branch_customer_schema
customer_name)
=
(branch_name,
branch_city,
assets,
Customer_loan_schema = (customer_name, loan_number, amount)
We construct our new relations branch_customer (Branch_customer) and
customer_loan (Customer_loan_ schema) as follows:
Branch_customer =
 branch_name, branch_city, assts, customer_name (lending)
Customer_loan = 
Branch
name
Downtown
Redwood
Perryridge
Downtown
Mianus
Round hill
Pownal
North town
Downtown
Perryridge
Brighton
customer_name, loan_number, amount
Branch - city
Brooklyn
Palo alto
Horseneck
Brooklyn
Horseneck
Horseneck
Bennington
Rye
Brooklyn
Horeneck
Brooklyn
(lending)
assets
Customer
- name
9000000
Jones
2100000
Smith
1700000
Hayes
9000000
Jackson
400000
Jones
8000000
Turner
300000
Williams
3700000
Hayes
9000000
Johnson
17000000 Glenn
7100000
Brooks
relation branch_customer
Branch
- Loan_nu Amount
name
mber
Downtown
L-17
1000
Redwood
L_23
2000
Perryridge
L_15
1500
Downtown
L_14
1500
Mianus
L_93
500
Round hill
L_11
900
Pownal
L_29
1200
North town L_16
1300
Downtown
L_23
2000
Perryridge
L_25
2500
brighton
L_10
2200
relation customer_loan.
We need to reconstruct the lending relation. It appears that we can do so by
writing
Branch_customer X customer_loan
2
3
Branch
name
Downtown
Down town
Redwood
Perryridge
Perrytidge
Downtown
Mianus
Mianus
Round hill
Pownal
North town
Downtown
Perryridge
Brighton
- Branch - city
assets
Customer Loan_n
- name
umber
Brooklyn
9000000
Jones
L-17
Brooklyn
9000000
Jones
L - 93
Palo alto
2100000
Smith
L_23
Horseneck
1700000
Hayes
L_15
Horseneck
1700000
Hayes
L_16
Brooklyn
9000000
Jackson
L_14
Horseneck
400000
Jones
L_17
Horseneck
400000
Jones
L_93
Horseneck
8000000
Turner
L_11
Bennington
300000
Williams
L_29
Rye
3700000
Hayes
L_16
Brooklyn
9000000
Johnson
L_23
Horeneck
17000000 Glenn
L_25
Brooklyn
7100000
Brooks
L_10
The relation branch _ customer X customer_loan.
Amou
nt
1000
500
2000
1500
1300
1500
1000
500
900
1200
1300
2000
2500
2200
We
call
the
decomposition
of
lending_
schema
into
branch_customer_schema
and
customer_loan_schema
a
lossy
decomposition, or a lossy -join decomposition. A decomposition that is not a
lossy- join decomposition is a lossless- join decomposition. It should be clear
from our example that a lossy-join decomposition is, in general, a bad
database design.
Let us examine the decomposition why it is lossy. There is one
attribute in common between Branch_customer_schema and customer_loan
_schema:
Branch_customer_schema U customer_loan_schema = {customer _ name}
The only way that we can represent a relationship between, for
example, loan _ number and branch_name is through customer_name. This
representation is not adequate because a customer may have several loans,
yet these loans are not necessarily obtained from the same branch.
Let us consider another alternative design, in which lending_schema is
decomposed into the following two schemas:
Branch_schema = (Branch_Name, Branch_City, Assets)
Loan_info_schema = (branch_name, customer_name, loan_number,
amount)
We found that the decomposition of lending_schema into
branch_schema and loan_info_schema is lossless because the functional
dependency
Branch_name  branch_city assets Holds on branch_schema.
We can define several
Normalization Using Functional Dependencies
normal forms that represent good database design. Desirable Properties of
Decomposition
3
4
Lossless join Decomposition
When decomposing a relation into a number of smaller relations, it is
crucial that the decomposition be loss less. We must first present a criterion
for determining whether a decomposition is lossy.
Let R be a relation schema, and let F be a set of functional
dependencies on R. Let R1 and R2 form a decomposition of R. This
decomposition is a loss less join decomposition of R if at least one of the
following functional dependencies are in F+


R1  R2  R1
R1  R2  R2
Dependency Preservation
Dependency preservation. When an update is made to the database,
the system should be able to check that the update will not create an illegal
relation that is, one that does not satisfy all the given functional
dependencies. If we are to check updates efficiently, we should design
relational database schemas that allow update validation without the
computation of joins.
Repetition of Information
The decomposition separates branch and loan data into distinct
relations, thereby eliminating this redundancy. The lack of redundancy
exhibited by our decomposition is desirable. The degree to which we can
achieve this of redundancy is represented by several normal forms.
Boyce_Codd Normal Form
One of the more desirable normal forms that we can obtain is
Boyce_Codd normal form (BCNF). A relation schema R is in BCNF with
respect to a set F of functional dependencies if for all functional
dependencies in F+ of the form   , where   R and   R, at least one
of the following holds:


   is a trivial functional dependency (that is,   ).
 is a superkey for schema R.
Eg :
Customer_schema=(customer_name, customer_street, customer_city)
customer_name  customer_street customer_city
Branch_schema = (branch_name, assets, branch_cith)
branch_name  assets branch_city
Loan_info_schema=(branch_name,customer_name,loan_number,
amount)
loan_number  amount branch_name
We claim that customer_schema is in BCNF. We node that a candidate
key for the schema is customer_name. The only nontrivial functional
dependencies that hold on customer_schema have customer_name on the
left side of the arrow. Since customer_name is a candidate key, functional
4
5
dependencies with customer_name on the left side do not violate the
definition of BCNF. similarly, it can be shown easily that the relation schema
branch –schema is in BCNF.
The schema, loan_info_schema, however, is not in BCNF. First, note
that loan_number is not a superkey for loan_info_schema, since we could
have a pair of tuples representing a single loan made to two people_for
example,
(Downtown, Mr. Bell, L-44, 1000)
(Downtown, Ms. Bell, L-44, 1000)
Because we did not list functional dependencies that rule out the preceding
case, loan_number is not a candidate key. However, the functional
dependency
loan_number

amount
is
nontrivial.
Therefore,
Loan_info_schema does not satisfy the definition of BCNF.
Consider the decomposition of Loan_info_schema into two schemas:
Loan_schema = (branch_name, loan_number, amount)
Borrower_schema = (customer_name, loan_number)
This decomposition is a lossless_join decomposition.
The set of functional
lending_schema are
dependencies
that
we
require
to
hold
on
Branch_name  assets branch_city
Loan_number  amount branch_name.
Not every BCNF decomposition is dependency preserving. Not every BCNF
decomposition is dependency preserving. Moreover, it demonstrates that we
cannot always satisfy all there design goals:
1. BCNF
2. Loss lss join
3. Dependency preservation
Third Normal Form
BCNF requires that all nontrivial dependencies be of the form  ,
where  is a superkey. 3NF relaxes this constraint slightly by allowing
nontrivial functional dependencies whose left side is not a superkey.
A relation schema R is in 3NF with respect to a set F of functional
dependencies if, for all functional dependencies in F+ of the form   ,
where   R and   R, at least one of the following holds:



   is a trivial functional dependency.
 is a superkey for R.
Each attribute A in  -  is contained in a candidate key for R.
The definition of 3NF allows certain functional dependencies that are
not allowed in BCNF. A dependency    that satisfies only the third
condition of the 3NF definition is not allowed in BCNF, but is allowed in 3NF.
These dependencies are examples of transitive dependencies.
5
6
Banker_info_schema =
(branch_name, customer_name, banke_name, office_number)
The main difference here is that we include the banker’s office number
as part of the information. The functional dependencies for this relation
schema are
Banker_name  branch_name office_number
Customer_name branch_name  banker_name
The following schemas in our decomposition:
Banker_office_schema =
(banker_name, branch_name, office_number)
Banker_schema =
(customer_name, branch_name, banker_name)
Comparison of BCNF and 3NF
If we do not eliminate all transitive dependencies, we may have to use
null values to represent some of the possible meaningful relationships
among data items, and there is the problem of repetition of information.
In summary, we repeat that our three design goals for a relational
database design are
1. BCNF
2. Lossless join
3. Dependency preservation
If we cannot achieve all three, we accept
1. 3NF
2. lossless join
3. dependency preservation
Normalization Using Multi valued dependencies
Functional dependencies rule out certain tuples from being in a
relation. If A  B, then we cannot have two tuples with the same A value
but different B values. Multivalued dependencies do not rule existence of
certain tuples. Instead, they require that other tuples of a certain form be
preset in the relation. For this reason, functional dependencies sometimes
are referred to as equality generating dependencies, and multivalued
dependencies are referred to as tuples generating dependencies.
Let R be a relation schema and let   R and   R. The multivalued
dependency

holds on R if, in any legal relation r (R), for all pairs of tuples t1 and t2 in r
such that t1[] = t2 [], there exist tuples t3 and t4 in r such that
t1 [] = t2 [] = t3 [] = t4 []
t3 [] = t1 []
t3 [R - ] = t2 [R - ]
6
7
t4 [] = t2 []
t4 [R - ] = t1 [R - ]
If the multivalued dependency  is satisfied by all relations on
schema R, then  is a trivial multivalued dependency on schema R.
Thus,  is trivial if    or    = R.
Theory of Multivalued Dependencies
The following list of inference rules for functional and multivalued
denpencies is sound and complete.
1. Reflexivity rule. If  is a set of attributes, and   , then   
holds.
2. Augmentation rule. If    holds, and  is a set of attributes, then
 holds
3. Transitivity rule if  holds,and  holds,then holds.
4. Complementation rule. If  holds, and  holds, then  R
-  -  holds.
5. Multivalued augmentation rule. If    holds and   R and   
the    holds.
6. Multivalued transitivity rule. If    holds and    holds,
then    -  holds.
7. Replication rule. If   holds., then   .
8. Coalescence rule. If    holds, and   , and there is a  such
that   R, and    = , and   , then    holds.
We can simplify the computation of the closure of D by using the
followingrules.



Multivalued unionrule. If    holds, and    holds. Then   
 holds.
Intersection rule. If    holds, then      holds.
Difference rule. If    holds, and    holds, the    -  holds
and    -  holds.
Fourth Normal Form
A relation schema R is in 4NF with respect to a set D of
functional and multivalued dependencies if, for all multivalued dependencies
in D+ of the form   , where   R and   R, at least one of the
following holds


   is a trivial multivalued dependency
 is a superkey for schema R.
A database design if in 4NF if each member of the set of relation schemas
that constitutes the design is in 4NF. Every 4NF schema is in BCNF.
Customer_name  loan_number is a nontrivial multivalued dependency, and
customer name is not a superkey for Branch Customer schema.
Borrower_schema = (customer_name, loan_number)
Customer_schema = (customer_name, customer_street, customer_city).
Loss less join:
7
8
Let R be a relation schema., and let D be a set of functional and
multivalued dependencies on R. Let R1 and R2 form a decomposition of R.
This decomposition is a lossless_join decomposition of R if and only if at
least one of the following multivalued dependencies is in D+.
R1  R2  R1
R1  R2  R2
Recall that we stated earlier that, if R1  R2  R1 of R1  R2  R2, then R1
and R2 are a lossless_ join decomposition of R.
A set D of both functional and multivalued dependencies. The restriction of D
to Ri is the set Di, consisiting of


all functional dependencies in D+ that include only attributes of Ri
all multivalued dependencies of the form
    Ri
where   Ri and    is in D+
dependency preserving:
A decomposition of schema R into schemas R1, R2, ... , Rn is a
dependency preserving decomposition with respect to a set D of functional
and multivalued dependencies if, for every set of relations r1 (R1), r2(R2),
..., rn (Rn) such that for all i, ri satisfies Di, there exists a relation r (R) that
satisfied D and for which ri =  Ri (r) for al i.
If we are given a set of multivalued and functional dependencies, it is
advantageous to find a database design that meets the three criteria of
1. 4NF
2. dependency preservation
3. lossless join
Normalization Using Join Dependencies
Decomposition is a loss less join decomposition. Join dependencies will
lead to a normal form called project join normal form (PJNF).
Let R be a relation schema and R1, R2, ..., Rn be a decomposition of
R. The join dependency *(R1, R2, .. , Rn) is used to restrict the set of legal
relations to those for which R1, R2, .., Rn is a loss less join decomposition of
R. Formally, if R = R1  R2  ...,  Rn, we say that a relation r(R) satisfies
the join dependency *(R1, R2, .., Rn) if
R =  R1 (r) x  R2 (r) x ... x Rn (r)
A join dependency is trivial if one of the Ri is R itself.
Consider the join dependency * (R1, R2) on schema R. This
dependency requires that, for all legal r (R),
R =  R1 (r) x  R2 (r)
Project Join Normal Form
Project join normal form (PJNF) is defined in a manner similar to BCNF
and 4NF, except that join dependencies are used. A relation schema R is in
PJNF with respect to a set D of functional, multivalued, and join
8
9
dependencies if, for all join
dependencies in D+ of the form *(R1,
R2,..., Rn), where each R1  R and R = R1  R2 ....  Rn, at least one of
the following holds:

*(R1, R2, .. , Rn) is a trivial join dependency.

Every Ri is a superkey for R.
A database design is in PJNF if each member of the set of relation schemas
that constitutes the design is in PJNF. PJNF is called fifth normal form (5NF)
in some of the literature on database normalization.
Domain_Key Normal Form
Domain_key normal form (DKNF) is based on three notions.
1. Domain declaration. Let A be an attribute, and let dom be a set of
values. The domain declaration A  dom requires that the A value
of all tuples be values in dom.
2. Key declaration. Let R be a relation schema with K  R. The key
declaration key (K) requires that K be a superkey for schema R that
is K  R. Note that all key declarations are functional dependencies
but not all functional dependencies are key declarations.
3. General constraint. A general constraint is a predicate on the set of
all relations on a given schema. The dependencies that we have
studied in this chapter are examples of general constraints. In
general, a general constraint is a predicate expressed in some
agreed on form, such as first order logic.
Formally, let D be a set of domain constraints and let K be a set of
key constraints for a relation schema R. Let G denote the general
constraints for R. Schema R is in DKNF if D  K logically imply G.
Regular_acct_schema =
balance)
Special_acct_schema =
balance)
(branch_name,
account_
number,
(branch_name,
account_
number,
OBJECT ORIENTED DATABASES
Features of Earlier Systems
1. Uniformity: There are large numbers of similarly structured data items, all of which
have same size in bytes.
2. Record Orientation: It consists of fixed length of records.
3. Small Data items: Each record is short - records are few bytes to 100 bytes.
4. Atomic fields: Fields of fixed length.
1.
2.
3.
4.
5.
NEW DATABASE APPLICATION
Computer Aided Design
Computer Aided Software Engineering
Multimedia Databases
Office Information System
Hypertext Databases
9
10
Computer Aided Design
- Data pertaining engineering
- Component design
- Old version
CASE
Type - data to assist software developers
Examples - source code, dependencies
- Definition and use of variables.
Multimedia Database
- Images. Spatial data
- Music
- Video
Office automation System
- Document created / retrieval tools
- Pertaining to schedules , documents
- Contents of documents
Hypertext Documents
- Enriched with links-www is an example
OBJECT ORIENTED DATA MODEL
Object Structure:
Object corresponds to an entity. The object-oriented paradigm is
based on encapsulation data and code. Interface between object and rest of
the system is defined by set of messages.
In general objects has
A set of variables, which corresponds to, attributes in ER model.
A set of messages to which objects responds. Each message may have
zero, one or more parameters.
A set of methods each of which is a body of code to implement a
message.
Invoking a method_sending the message.
The ability to modify the definition of object without affecting the rest of the
system is the major advantage of object oriented programming.
Methods
- read only ( not changes )
- update ( changes the value of the object )
Read only objects are equivalent to derived attributes. E.g.: employment length calculation
Object consist of
- Variables.
- Function pair.
- Read.
- Update.
10
11
Object Classes:
Similar objects are grouped together to form a class.
Class Employee
{
/* Variables */
String name;
String address;
/* Messages */
Int annual salary( );
String get-name( );
String address( );
};
Here data return type is response to the message.
A Class Contain
1. A Set valued variables.
2. Implementation of a method for the message new.
Inheritance
An object-oriented database has many classes.
Person
Employee
Officer
Teller
Customer
Secretary
Class Person
{
String name;
String address;
};
Class Customer is a person
{
int Creditrating
};
Here customer is a specialization of a person. The specialization of a
class is called subclass. Conversely person is the superclass of a
customer.
The property that objects of a class contain variables defined in
its superclasses is referred to as inheritance of variables.
Inheritance speaks about reusability. Any subclass object can call the
superclass method and variables.
The keyword “isa” is used to indicate that a class is a specialization of
another class.
11
12
Multiple Inheritance
Multiple inheritance is the ability of a class to inherit variables and
methods from multiple super classes. The class_subclass relationship is
represented by a directed acyclic graph.
Before Multiple Inheritance
Person
Employee
Customer
Officer
Teller
Full time
Secretary
Part time Full time Part time
secretary
secretary
 Variables and methods for full time employees must be declared twice.
This redundancy affects inconsistency.
 No means to represent who are not officers, tellers.
With multiple inheritance
Person
Employee
Full time
Part time
Officer
Full time
Teller
Teller
Secretary
Multiple Inheritance creates multiple copies of the same data and
creates ambiguity.
Object Identity
Objects retain its identity even if some or all the values of variables or
definitions of methods change over time.
Different forms of identity: Value_A data value is used for identity. This form of identity is used in
relational system.
Name_A user supplied name is used for identity. This is used for file
systems.
12
13
Built in_Each object is automatically given an identifier by the system
when that object is created.
Object Oriented System provides
Object identifier a notion to name the objects. Object identifiers are
unique. Object identifier can also be numbers. If the identifier is generated
by the system, we should be careful since it is built specifically for the
system.
Object Containment: Object containment is references between objects. Consider an
example
Bicycle
Wheel
Frame
Gear
Brake
Rim Spokes
Tyre
Lever
Pad
Cable
Objects that contain other object are called Complex or Composite
objects. Some references to wheel, brake, gear and frame along with its
regular variables. So the class bicycle CONTAINS the wheel, brake etc.
Advantage_Independent
objects.
usage
of
objects
without
distributing
other
Object Oriented Languages
The concept of object orientation should be implemented at
programming languages.
The concept of object orientation
1. Used purely as a design tool and encoded into a relational database.
2. Incorporated into a language that is used to manipulate the database
- SQL can be extended with complexity along with object
orientation. They are called as object relational databases.
- Take an existing programming language and to extend it to
deal with databases.
Persistent programming languages
Data manipulation languages are persistent that is data exist
even after the program that created it has terminated. A persistent
Programming language is a PL extended to handle persistent data.
It differs from Embedded SQL in atleast two ways
1. Type systems of host level language and DML differs which requires the
programmer to carry out. This produces undetected errors. This occupies
space unwantedly. But PPL’s have same type mechanism for query
language and host language.
2. Any updation in the database should be rewritten back to the disk.
Examples_Object Pascal, C++.
Disadvantages –
1. Errors may damage the database.
2. Unable to reduce disk I/O.
13
14
Persistence of Objects
To make a HLL a database programming language, we need persistent
objects. To make it possible there are several approaches
1. Persistence by Class - If a class is made persistent all of its objects
are automatically persistent.
2. Persistent by Creation_In this approach the transient objects are
extended to be persistent.
Persistent by Marking
After the object are created they are explicitly marked to be
persistent.
Persistent by Reference
One or more objects are referenced, as persistent and other object is
persistent if and only if they are referred directly or through the reference.
Object Identity and Pointers :
A simple way to achieve built in identity is through pointers. There are
several degrees of permanence of identity.
1. IntraProcedure_the identity is available within a function call.
2. IntraProgram _The identity exists within the execution of a program.
Eg:- Virtual Memory Pointers.
3. InterProgram _Identity persists from one program execution to another.
Eg: - Data is stored in a file system.
Persistent
Identity persists even after the end of execution of the program. A
persistent pointer remains valid even after structural reorganization of data.
Storage and Access of Persistent Object
To find objects in a database
1. Give names to objects
2. Give numbers to objects
3. Represent objects as a collection and search the required
objects.
Object Oriented languages support all the three approaches.
Persistent C++ System
Several object-oriented qualities make C++ to support to persistent.
For example it can be declared as persistent_object. Any subclass of its also
persistent. Changes are made in C++ via class Libraries.
ODMG C++ Object Definition Languages
ODMG stands for Object Database Management groups. ODMG is
working for extending C++ capabilities of persistent. There are two parts of
the ODMG C++ extension.
1.c++ Object Definition Language. 2.Object Manipulation Language
The C++ ODL extends the type definition syntax. The C++ OML extends
C++ for making all Database Manipulation like Update, Delete etc.
14
15
OBJECT RELATIONAL DATABASE.
Object Relational Databases extend the relational data model by
providing a richer type system including object orientation and added
constructs to relational query languages.
Nested Relations
A Domain is automatic if element of the domain are considered to be
invisible units.
A table is said to be in First Normal form if all tuples are in atomic
domains. But it is not preferred in all situations. The objects are taken into
account instead of records. So there can be several records for a single
objects to be represented.
Nested Relational Model is an extension of relational model in which
domains may be either atomic or multivalued.
Example:
Document Retrieval System
Title
Author list
Date
Keyword list.
Complex Types and Object Orientation
Nested relations are one example of complex types and records with
non atomic fields also proved useful. This needs object reference and
inheritance for further use. The intro of object orientation has made many of
ER features to be implemented easily.
These features are under test and all the object oriented features are
included in XSQL.
Structured and Collection Types.
Create type Mystring char varying
Create type Mydate
( day integer,
month char(10),
year integer)
Create type Document
( name Mystring,
authorlist setof(Mystring),
date Mydate,
keyword setof(Mystring))
Create table doc of type Document.
Here it is hamed complex , because it has an attribute which is a set
and it is clearly non atomic. These are implemented by storing the type
definitions in schema and later using them in creation of the table.
Arrays and Multisets are also supported.
15
16
Inheritance.
Inheritance can be at the level of types and inheritance can also be at
the level of tables.
Create type Person
( name Mystring,
socialsecurity integer).
To store some specialized values about teachers and students
Create type student
(degree Mystring,
department Mystring)
under person
Create type Teachingassistant
Under student , teacher
He might be a student of one department but he might be a teacher of
another department the ambiguity can be resolved as follows.
Create type Teachingassistant
Under student : with (department as student-dept),
Teacher with (department as teacher-dept)
Inheritance at the level of tables
Since we have to create a subtype for each entity it is always better to
have inheritance at table level.
Create table People
( name Mystring,
socialsecurity integer).
Create table student
(degree Mystring,
department Mystring)
under people
Create table teacher
(salary integer
department Mystring)
under people.
The following consistency constraints should be satisfied.
 No two tuples should point to the same person.
 No tuple should be present ie either it does not correspond to any
tuple in people or corresponds to several tuples.
Advantages
1. The schema designer should link tables corresponding to subtables
explicitly. This needs referential integrity atc.
2. Used to create new types.
16
17
Reference Types
An attribute of a type can be a reference to an object of a specified
type.
Authorlist setof(ref(person))
Quering with Complex Types
Find the name of the book and year of publication
Select name , date year from doc
Relational Valued Attributes:
An expression evalution to a relation to appear anywhere that a
relation might appear.
Find all documents that have the word “database” as one of the keywords
Select name from pdoc where “database” in keywordlist.
Select name from authorlist .
Select name , count ( authorlist) from pdoc.
Path Expression:
The dot notation for referring to composite attributes can be used
with references.
people
Create
table
phd-students(advisor
ref(people))
under
Select phd-students.advisor.name from phd-students.
This removes the complexity of joins and referential integrities.
Nesting and Uniformity :
The transformation of a nested relation to INF is called nesting.
Select name,A as author,date.day,date.month,date.year,K as
keyword
From doc as B ,B.authorlist as A, B.keywordlist as K.
The reverse of the above process is called Nesting.
Select title , set(author) as authorlist(day,month,year) as date
, set (keyword) as keyword-list from flat-doc group by title , date.
Functions
Object relational systems allow functions to be defined by users.
Create functions authorcount(onedoc Document ) returns
integer as select count (authorlist) from one-doc.
17
18
Select
name
from
doc
where authorcount(doc) > 1.
If there is more than one value returned
1) This can be error
2) Any one value is returned.
Creation of complex values and objects
Insert into doc values ( “salesplan “, set (“smith”, “joins”),(1,”april”,89),set
(“profit” , “strategy”))
Select name , date from doc where name in set (“salesplan “ ,
“oppurtunities”, “risks”)
Comparison of Object Orientation and Object Relational Database
1. Relational Systems
Simple data types ,powerful query languages, high protection.
2. Persistent Programming Language based OODBs
Complex data types , integration with programming language , high
performance
3. Object Relational Systems
Complex data types, powerful query languages, high protection.
Questions:
1.
Explain 1NF, 2NF.
2.
Explain in detail 3NF, 4NF, 5NF and DCNF.
3.
What is dependency preservation?
4.
What is the need of decomposition?
5.
What is Loss less join and lossy join?
6.
Explain Armstrong axioms.
7.
Explain object oriented data model.
8.
What is persistent programming language?
9.
Explain nested relation.
10. Give examples for complex queries.
11. Give the difference between nesting and unnesting.
12. Explain function in ORDBMS.
13. Compare Object –oriented and object relational database.
**************
18