You are on page 1of 15

ADS QB

1) Explain complex data types with examples?


I. Traditional database applications have conceptually simple data types.
II. In recent years, demand has grown for ways to deal with more complex data
types.
III. Eg: address (Street, city, state, postal code) : Composite attribute or employee
phone_no: Multivalued attribute.
IV. With complex type systems we can represent E-R model concepts, such as
composite attributes, multivalued attributes, generalization, and specialization
directly, without a complex translation to the relational model.
V. Not all applications are best modeled by 1NF relations. For example, rather than
view a database as a set of records, users of certain applications view it as a set of
objects (or entities).
VI. Motivation:
• Permit non-atomic domains (atomic indivisible)
• Example of non-atomic domain: set of integers, or set of tuples
• Allows more intuitive modeling for applications with complex data
VII. Intuitive definition:
• allow relations whenever we allow atomic (scalar) values — relations within
relations
• Retains mathematical foundation of relational model
• Violates first normal form.
VIII. Example: library information system
IX. Each book has • title, • a list (array) of authors, • Publisher, with subfields name
and branch, and • a set of keywords
X. Non-1NF relation books
XI. Example of Nested Relation -
Authors - A book may have a list of authors, which we can represent as an array.
Keywords - If we store a set of keywords for a book, we expect to be able to
retrieve all books whose keywords include one or more specified keywords. Thus,
we view the domain of the set of keywords as nonatomic.
Publisher - Unlike keywords and authors, publishers do not have a set-valued
domain. However, we may view publishers as consisting of the subfields name
and branch. This view makes the domain of the publisher nonatomic.
XII. Extensions introduced in SQL:1999 to support complex types:
• Collection and large object types
• Nested relations are an example of collection types
• Structured types
• Nested record structures like composite attributes
• Inheritance
• Object orientation
• Including object identifiers and references
XIII. Not fully implemented in any database system currently
• But some features are present in each of the major commercial database systems

2) Explain oracle sequences with examples?


I. Oracle sequences are an independent object in the database and are not a data
type.
II. Oracle sequences have a name and can be used anywhere a value is expected.
III. Oracle sequences generate a numeric value that can be assigned to any column in
any table.
IV. The table attribute to which you assigned a value based on a sequence can be
edited and modified.
V. An Oracle sequence can be created and deleted anytime.
VI. The basic syntax to create a sequence in Oracle is:
CREATE SEQUENCE name [START WITH n] [INCREMENT BY n] [CACHE |
NOCACHE]
VII. where:
- name is the name of the sequence.
- n is an integer value that can be positive or negative.
- START WITH specifies the initial sequence value. (The default value is
1.)
- INCREMENT BY determines the value by which the sequence is
incremented. (The default increment value is 1. The sequence increment
can be positive or negative to enable you to create ascending or
descending sequences.)
- The CACHE or NOCACHE clause indicates whether Oracle will
preallocate sequence numbers in memory. (Oracle pre-allocates 20 values
by default.)
VIII. Example:
1. CREATE SEQUENCE CUS_CODE_SEQ START WITH 20010 NOCACHE;
2. CREATE SEQUENCE INV_NUMBER_SEQ START WITH 4010
NOCACHE;
IX. Sequences created can be checked by using the following SQL command:
SELECT * FROM USER_SEQUENCES;
X. To use sequences during data entry, we must use two special pseudo-columns:
NEXTVAL and CURRVAL. NEXTVAL retrieves the next available value from a
sequence, and CURRVAL retrieves the current value of a sequence.
XI. Example -

XII. We can drop a sequence from a database with a DROP SEQUENCE command.
For example, to drop the sequences created earlier-
DROP SEQUENCE CUS_CODE_SEQ; DROP SEQUENCE
INV_NUMBER_SEQ; Dropping a sequence does not delete the values we
assigned to table attributes (CUS_CODE and INV_NUMBER); it deletes only the
sequence object from the database. The values we assigned to the table columns
(CUS_CODE and INV_NUMBER) remain in the database.

3) Illustrate two phase commit protocol?


I. Commit protocols are used to ensure atomicity across sites
- a transaction which executes at multiple sites must either be committed at all the
sites, or aborted at all the sites.
- not acceptable to have a transaction committed at one site and aborted at another
II. The two-phase commit (2PC) protocol is widely used
III. Assumes a fail-stop model – failed sites simply stop working, and do not cause
any other harm,such as sending incorrect messages to other sites.
IV. Execution of the protocol is initiated by the coordinator after the last step of the
transaction has been reached.
V. The protocol involves all the local sites at which the transaction executed
VI. Let T be a transaction initiated at site Si , and let the transaction coordinator at Si
be Ci
VII. Phase 1 - Obtaining a decision -
a. Coordinator asks all participants to prepare to commit transaction Ti .
- Ci adds the records to the log and forces log to stable storage
- sends prepare T messages to all sites at which T executed
b. Upon receiving message, transaction manager at site determines if it can commit
the transaction
- if not, add a record to the log and send abort T message to Ci
- if the transaction can be committed, then:
- add the record to the log
- force all records for T to stable storage send ready T message to Ci
VIII. Phase 2- Recording the Decision -
a. T can be committed if Ci receives a ready T message from all the participating
sites: otherwise T must be aborted.
b. Coordinator adds a decision record, or , to the log and forces record onto stable
storage. Once the record stable storage it is irrevocable (even if failures occur)
c. Coordinator sends a message to each participant informing it of the decision
(commit or abort)
d. Participants take appropriate action locally

4) Explain fragment and replicate join with example?


I. Partitioning not possible for some join conditions eg: if the join condition is an
inequality,
- E.g., non-equijoin conditions,such as r.A > s.B.
II. For joins were partitioning is not applicable, parallelization can be
accomplished by fragment and replicate technique
III. Special case – asymmetric fragment-and-replicate:
- One of the relations, say r, is partitioned; any partitioning technique can be
used.
- The other relation, s, is replicated across all the processors.
- Processor Pi then locally computes the join of r i with all of s using any
join technique.

IV. General case:reduces the sizes of the relations at each processor.


- r is partitioned into n partitions, r0 , r1 , ..., r n-1 ;
- s is partitioned into m partitions,s0 , s1 , ..., sm-1 .
- Any partitioning technique may be used.
- There must be at least m * n processors.
- Label the processors as: P0,0 , P0,1 , ..., P0,m-1 , P1,0 , ..., Pn-1m-1 .
- Pi,j computes the join of r i with sj . In order to do so, r i is replicated to Pi,0 , Pi,1
, ..., Pi,m-1 , while si is replicated to P0,i, P1,i , ..., Pn-1,i
- Any join technique can be used at each processor Pi,j.

V. Both versions of fragment-and-replicate work with any join condition, since every
tuple in r can be tested with every tuple in s.
VI. Usually has a higher cost than partitioning, since one of the relations (for asymmetric
fragment-and-replicate) or both relations (for general fragment-and-replicate) have to be
replicated.
VII. Sometimes asymmetric fragment-and-replicate is preferable even though partitioning
could be used.
E.g., say s is small and r is large, and already partitioned. It may be cheaper to replicate s
across all processors, rather than repartition r and s on the join attributes.
VIII. General Fragment and replicate reduces the sizes of the relations at each processor,
compared to asymmetric fragment and replicate.
5) Explain procedural SQL with an example?
I. This Isolate critical code
- All applications access shared code
- Better maintenance and logic control
II. Persistent stored module (PSM) is a block of code containing:
- Standard SQL statements
- Procedural extensions
- Stored and executed at the DBMS server
III. Procedural SQL (PL/SQL) enables you to:
Store procedural code and SQL statements in database
Merge SQL and traditional programming constructs
IV. Procedural code executed by DBMS when invoked by end user
- Anonymous PL/SQL blocks
- Triggers
- Stored procedures and
- PL/SQL functions
A. Anonymous PL/SQL blocks -
- Anonymous PL/SQL code block is a collection of the commands enclosed inside
BEGIN and END clauses and does not have a specific name.
- Ex - The following anonymous PL/SQL block inserts a row in the VENDOR
table and displays the message “New Vendor Added!”
BEGIN
INSERT INTO VENDOR VALUES (25772,'Clue Store', 'Issac Hayes',
'456','323-2009', 'VA', 'N');
DBMS_OUTPUT.PUT_LINE('New Vendor Added!');
END;
/
B. Triggers -
- A trigger is procedural SQL code that is automatically invoked by the RDBMS
upon the occurrence of a given data manipulation event.
- Syntax -
CREATE OR REPLACE TRIGGER trigger_name [BEFORE / AFTER]
[DELETE / INSERT / UPDATE OF column_name]
ON table_name
[FOR EACH ROW]
[DECLARE]
[variable_name data type[:=initial_value] ]
BEGIN
PL/SQL instructions;
..........
END;
- Example -

C. Stored Procedure -
I. It is Named collection of procedural and SQL statements. Stored
procedures are stored in the database.
II. Syntax -
CREATE OR REPLACE PROCEDURE procedure_name [(argument
[IN/OUT] data-type, )] [IS/AS] [variable_name data type[:=initial_value] ]
BEGIN
PL/SQL or SQL statements;
...
END;
III. Example -

D. PL/SQL Function -
- A stored function is basically a named group of procedural and SQL
statements that returns a value.
- Syntax to create a function:
CREATE FUNCTION function_name (argument IN data-type, )
RETURN data-type [IS]
BEGIN
PL/SQL statements;
...
RETURN (value or expression);
END;
6) Compare between Object Relational and Object Oriented Databases?
• Relational systems
• simple data types, powerful query languages, high protection.
• Persistent-programming-language-based OODBs
• complex data types, integration with programming language, high performance.
• Object-relational systems
• complex data types, powerful query languages, high protection.
• Object-relational mapping systems
• complex data types integrated with programming language, but built as a layer
on top of a relational database system
• Note: Many real systems blur these boundaries
• E.g. A persistent programming language built as a wrapper on a relational
database offers the first two benefits, but may have poor performance.

7) Illustrate the inheritance in structured types?


1) Type Inheritance:
● Suppose that we have the following type definition for people:
create type Person (name varchar(20), address varchar(20))
● Using inheritance to define the student and teacher types
create type Student under Person (degree varchar(20), department
varchar(20))
create type Teacher under Person (salary integer, department varchar(20))
● Both Student and Teacher inherit the attributes of Person—namely, name and
address. Student and Teacher are said to be subtypes of Person, and Person is a
supertype of Student, as well as of Teacher.
● Methods of a structured type are inherited by its subtypes, just as attributes are.
● Subtypes can redefine methods by using overriding method in place of method in
the method declaration.
● The SQL standard requires an extra field at the end of the type definition, whose
value is either final or not final.
● The keyword final says that subtypes may not be created from the given type,
while not final says that subtypes may be created.
2) Multiple Type inheritance:
● The attribute department is defined separately in Student and Teacher. In fact, a
teaching assistant may be a student of one department and a teacher in another
department.
● To avoid a conflict between the two occurrences of department we can rename
them create type Teaching Assistant under Student with (department as
student_dept ), Teacher with (department as teacher_dept )
● Each value of a structured type must have a most-specific type - each value must
be associated with one specific type. For example, suppose that an entity has the
type Person, as well as the type Student. Then, the most-specific type of the entity
is Student, since Student is a subtype of Person.
3) Table Inheritance:
● Tables created from subtypes can further be specified as subtables
● E.g. create table people of Person; create table students of Student under people;
create table teachers of Teacher under people;
● The types of the subtables (Student and Teacher) are subtypes of the type of the
parent table (Person).
● As a result, every attribute present in the table people is also present in the
subtables students and teachers.
● When we declare students and teachers as subtables of people, every tuple present
in students or teachers becomes implicitly present in people.
● Tuples added to a subtable are automatically visible to queries on the supertable.
Similarly updates/deletes on people also result in updates/deletes on subtables
● E.g. a statement: delete from people where P; would delete all tuples from the
table people, as well as its subtables students and teachers, that satisfy P.
● To override this behavior, use “only people” in query
● If the only keyword is added to the above statement, tuples that were inserted in
subtables are not affected, even if they satisfy the where clause conditions.
● Conceptually, multiple inheritance is possible with tables
• e.g. teaching_assistants under students and teachers create table teaching
assistants of TeachingAssistant under students, teachers;
• Every tuple present in the teaching assistants table is also implicitly present in
the teachers and in the students table, and in turn in the people table.
• But it is not supported in SQL currently ,So we cannot create a person (tuple in
people) who is both a student and a teacher.
8) Compare Between Two Phase Commit and Three Phase Commit Protocol?
Commit protocols are used to ensure atomicity across sites; a transaction which
executes at multiple sites must either be committed at all the sites, or aborted at all the
sites. not acceptable to have a transaction committed at one site and aborted at another
The two-phase commit (2PC) protocol is widely used.
The three-phase commit (3PC) protocol is more complicated and more expensive, but
avoids some drawbacks of two-phase commit protocol. This protocol is not used in
practice.
1) Two phase commit(2PC):
Assumes a fail-stop model – failed sites simply stop working, and do not cause
any other harm,such as sending incorrect messages to other sites.
Execution of the protocol is initiated by the coordinator after the last step of the
transaction has been reached.
The protocol involves all the local sites at which the transaction executed Let T
be a transaction initiated at site Si , and let the transaction coordinator at Si be Ci.
● Phase 1: Obtaining a Decision
Coordinator asks all participants to prepare to commit transaction Ti . Ci
adds the records to the log and forces log to stable storage sends prepare
T messages to all sites at which T executed Upon receiving message,
transaction manager at site determines if it can commit the transaction if
not, add a record to the log and send abort T message to Ci if the
transaction can be committed, then: add the record to the log force all
records for T to stable storage send ready T message to Ci
● Phase 2: Recording the Decision
T can be committed if Ci receives a ready T message from all the
participating sites: otherwise T must be aborted. Coordinator adds a
decision record, or , to the log and forces record onto stable storage. Once
the record stable storage is irrevocable (even if failures occur) the
Coordinator sends a message to each participant informing it of the
decision (commit or abort) Participants take appropriate action locally.
2) Three Phase Commit (3PC):
● Assumptions: No network partitioning At any point, at least one site must be up.
At most K sites (participants as well as coordinator) can fail
● Phase 1: Obtaining Preliminary Decision: Identical to 2PC Phase 1. Every site is
ready to commit if instructed to do so
● Phase 2 of 2PC is split into 2 phases, Phase 2 and Phase 3 of 3PC In phase 2
coordinator makes a decision as in 2PC (called the pre-commit decision) and
records it in multiple (at least K) sites In phase 3, coordinator sends commit/abort
message to all participating sites,
● Under 3PC, knowledge of pre-commit decision can be used to commit despite
coordinator failure Avoids blocking problem as long as < K sites fail
● Drawbacks: higher overheads assumptions may not be satisfied in practice

9) Explain PL SQL Triggers in ORACLE?


A trigger is procedural SQL code that is automatically invoked by the RDBMS
upon the occurrence of a given data manipulation event. It is useful to remember that:
● A trigger is invoked before or after a data row is inserted, updated, or
deleted.
● A trigger is associated with a database table. Each database table may
have one or more triggers.
● A trigger is executed as part of the transaction that triggered it.
Triggers are critical to proper database operation and management.
For example: Triggers can be used to enforce constraints that cannot be enforced
at the DBMS design and implementation levels. Triggers add functionality by
automating critical actions and providing appropriate warnings and suggestions for
remedial action. In fact, one of the most common uses for triggers is to facilitate the
enforcement of referential integrity. Triggers can be used to update table values, insert
records in tables, and call other stored procedures.
Oracle recommends triggers for:
● Auditing purposes (creating audit logs).
● Automatic generation of derived column values.
● Enforcement of business or security constraints.
● Creation of replica tables for backup purposes
Syntax:
CREATE OR REPLACE TRIGGER trigger_name
[BEFORE / AFTER] [DELETE / INSERT / UPDATE OF column_name] ON
table_name
[FOR EACH ROW]
[DECLARE] [variable_name data type[:=initial_value] ]
BEGIN
PL/SQL instructions;
..........
END;

10) Explain Nesting and Unnesting with examples?


Unnesting:
The transformation of a nested relation into a form with fewer (or no)
relation-valued attributes is called unnesting.
Ex: select title, A as author, publisher.name as pub_name, publisher.branch as
pub_branch, K.keyword
from books as B, unnest(B.author_array ) as A (author ), unnest (B.keyword_set )
as K (keyword )

Nesting:
● Nesting is the opposite of unnesting, creating a collection-valued attribute
● Nesting can be done in a manner similar to aggregation, but using the function
collect() in place of an aggregation operation, to create a multiset
● To nest the flat_books relation on the attribute keyword:
○ select title, author, Publisher (pub_name, pub_branch ) as publisher,
collect (keyword) as keyword_set from flat_books group by title, author,
publisher.

To nest on both authors and keywords:


select title, collect (author ) as author_set, Publisher (pub_name,
pub_branch) as publisher, collect (keyword ) as keyword_set from
flat_books group by title, publisher.
11) Explain Horizontal Fragmentation with an example?
Fragmentation:
Division of relation r into fragments r1 , r2 , …, r n which contain sufficient information
to reconstruct relation r.
Horizontal fragmentation: each tuple of r is assigned to one or more fragments
Vertical fragmentation: the schema for relation r is split into several smaller schemas .
All schemas must contain a common candidate key (or superkey) to ensure
lossless join property.
A special attribute, the tuple-id attribute may be added to each schema to serve as
a candidate key.
Example of horizontal frag.:

Advantages:
● allows parallel processing on fragments of a relation
● allows a relation to be split so that tuples are located where they are most
frequently accessed.
12) Compare between parallel databases and distributed databases?
Parallel Database: A parallel DBMS is a DBMS that runs across multiple
processors and is designed to execute operations in parallel, whenever possible.
The parallel DBMS links a number of smaller machines to achieve the same
throughput as expected from a single large machine.
Features:
● Completes work very quickly.
● There are parallel working of CPUs
● It improves performance.
● It divides large tasks into various other task
Distributed database: is defined as a logically related collection of data that
is shared which is physically distributed over a computer network on different
sites. The Distributed DBMS is defined as, the software that allows for the
management of the distributed database and makes the distributed data
available for the users.
Features :
● It is a group of logically related shared data
● The data gets split into various fragments
● There may be a replication of fragments
● The sites are linked by a communication network
● The main difference between the parallel and distributed databases is that the
former is tightly coupled and then later loosely coupled.
Parallel Databases Distributed Databases

In parallel databases, processes are tightly In distributed databases, the sites are loosely
coupled and constitutes a single database coupled and share no physical components
system i.e., the parallel database is a i.eThe distributed database is our
centralized database and data reside in a geographically departed, and data is
single location distributed at several locations.

In parallel databases, query processing and In distributed databases, query processing and
transaction is complicated. transaction is more complicated in distributed
database systems

In parallel databases, it’s not applicable. In distributed databases, a local and global
transaction can be transformed into
distributed database systems

Parallel databases are generally homogeneous Distributed databases may be homogeneous


in nature or heterogeneous in nature.

Skew is the major issue with the increasing Blocking due to site failure and transparency
degree of parallelism in parallel databases. are the major issues in distributed databases.

In parallel databases, there are 3 types of Distributed databases are generally a kind of
architecture: shared memory, shared disk, and shared-nothing architecture
shared-nothing.

In parallel databases, the data is partitioned In distributed databases, each site preserve a
among various disks so that it can be retrieved local database system for faster processing
faster. due to the slow interconnection between sites

You might also like