Saturday, February 28, 2015

DMC 1971 Advanced Databases February 2014 Question Paper

Anna University MCA Distance Education Advanced Databases Question Paper / Anna University MCA Distance Education Previous Year Question Paper / DMC 1971 Advanced Databases Question Papers with Answers / DMC 1971 Advanced Databases February March Question Papers with Answers / February March DMC1971


Question Paper Code : 96324
M.C.A. DEGREE EXAMINATION, FEBRUARY/MARCH 2014
Elective
DMC 1971 – ADVANCED DATABASES
(Regulation 2009)
Time : Three Hours                                               Maximum : 100 Marks
Answer ALL Questions
PART A – (10 X 2 = 20 Marks)
1. What is referential key constraint?
2. State the purpose of query optimization.
3. Differentiate transient and persistent objects.
4. Justify the need for concurrency control.
5. What is client/server model?
6. Define: mobile database.
7. What is active rule?
8. Give advantages of distributed database systems.
9. When did you say that the consistency of a database is lost?
10. What is authentication? How does it differ from authorization?
PART B – (5 X 16 = 80 Marks)
11. (a) (i) Describe in detail about hashing techniques. (8)
(ii) Briefly explain about relational model concepts. (8)
Or
(b) Why normalization is required? Explain 1NF, 2NF, 3NF, and BCNF in detail with suitable examples. (16)
12. (a) How will you model and design an object oriented database? Explain in detail. (16)
Or
(b) Write short notes on the following;
(i) Database administration (8)
(ii) Recovery (8)
13. (a) What is enhanced data model? Explain each of them. (16)
Or
(b) Write a detailed note on web databases. (16)
14. (a) Write short notes on:
(i) Active databases. (8)
(ii) Deductive databases. (8)
Or
(b) (i) Explain any one of the concurrency control protocol in detail with example. (8)
(ii) Discuss in detail the parallel database. (8)
15. (a) Describe the database tuning techniques in detail. (16)
Or
(b) (i) Explain the integrity issues in database design. (8)
(ii) Discuss the research issues related to security in database design. (8).
________________



Friday, February 27, 2015

Codd's Twelve Rules - Rule 10 - Integrity Independence

Codd's Twelve Rules - Rule 10 - Integrity Independence


Rule 10
Integrity Independence
Rule
Integrity constraints specific to a particular relational database must be definable in the relational data sublanguage and storable in the catalog, not in the application programs.
A minimum of the following two integrity constraints must be supported:
1. Entity integrity: No component of a primary key is allowed to have a null value. That is, no records can have NULL values in its Primary Key attribute.
2. Relational integrity: For each distinct non-null foreign key value in a relational database, there must exist a matching primary key value from the same domain. In other words, if a foreign key cannot have null values as its component then it must refer a matching primary key value with the same set of permitted values to accept any new records.
Description
This rule insists that the declaration of integrity constraints must be part of the language that is used to define the database structure. Also, these integrity constraints should be stored as part of Data dictionary.
For example, if you define a new table in Oracle using SQL, then SQL must provide facilities to define the integrity constraints. These integrity constraints are stored as part of SYSTEM tablespace.
Example
(Green color - primary key, red color - foreign key)
CREATE TABLE Emp(Eno CHAR(5) PRIMARY KEY, Ename VARCHAR(25), Phone NUMBER(10), dno NUMBER(3), FOREIGN KEY dno REFERENCES Dept(dno));
In this definition PRIMARY KEY means UNIQUE + NOT NULL, and we have defined PRIMARY KEY as part of table definition itself using SQL.
Secondly, if we have attribute dno as a NON-NULL foreign key, then there should be a table definition like the one follows and dno should refer the PRIMARY KEY;
CREATE TABLE Dept(Dno NUMBER(3) PRIMARY KEY, Dname VARCHAR(35), Dlocation VARCHAR(30), Phone NUMBER(10));
Some DBMS that fulfills this property
SQL Server, Oracle, MySQL, IBM DB2



Go to Home - Codd's Twelve Rules


Tuesday, February 24, 2015

Codd's Twelve Rules - Rule 9 - Logical Data Independence


Codd's Twelve Rules - Rule 9 - Logical Data Independence



Rule 9
Logical Data Independence
Rule
“The ability to change the conceptual (logic) schema without having to change the next higher level external schema or application programs”.
“Insulation of application programs and terminal users from the negative effects of information-preserving changes of the logical database schema”.
Description
1. The addition or removal of new entities, attributes, or relationships to the conceptual schema should be possible without having to change existing external schemas or having to rewrite existing application programs.
2. Logical Data independence means if we add some new columns or remove some columns from table then the user view and programs should not change.
3. The term "Logical Data Independence" refer to the ability to present the stored information in different ways to different users. The way you store the data and the way you present it to a particular user is independent. Different users perceive the same data differently.
Example
If user B add a new column salary in his view/table then it will not effect the external view user; user A, but internal view of database has been changed for both users A & B. Now user A can also print the salary. It means if we change in view then program which use this view need not to be changed.
For a table with the schema Employee(Eno, Ename, Street, City, Salary), a view with the attributes (Eno, Ename) will not be affected if any other attributes of Employee is altered.
More examples/illustrations can be tried in the following links;

Achievement
Logical Data Independence is more difficult to achieve when compared to Physical Data Independence since application programs are heavily dependent on the logical structure of the data that they access.
Some DBMS that fulfills this property
Almost all Relational DBMSs support this property with certain limits (say for example if columns or tables removed).
Together, Rule 8 Physical Data Independence and Rule 9 Logical Data Independence, specify that specific access or storage techniques used by the RDBMS—and even changes to the structure of the tables in the database—shouldn’t affect the user’s ability to work with the data.