Web Answers for Database Management System (BCA)

Chapter 1: Introduction

Q1.What is difference between DBMS and RDBMS?

Answer: RDBMS is DBMS plus Referential Integrity. DBMS is mainly a storage area and it does not employ any tables for storing the data or does not use any special function keys or foreign keys for the retrieval of the data. RDBMS has the major difference of solving the queries easily as they are stored in table format and use many functional keys in solving the queries. DBMS Doesnt follow the normalization while RDBMS follows the normalization. This is the major difference between them. They follow the 12 Codd's rules. DBMS does not support client/server Architecture but RDBMS supports client/server Architecture. Only one user can access the database at a time in DBMS. But RDBMS allows simultaneous access of users to the database.

Chapter 2: Entity Relationship Model

Q1. State the rules for naming an entity.

Answer: 1. "Create a name that accurately, clearly and unambiguously identifies the subject of a table. 2. Use the minimum number of words necessary to convey the subject of the table. 3. Do not use words that convey physical characteristics of the database. Avoid using words such as 'File', 'Record,' and 'Table.' 4. Do not use acronyms and abbreviations. 5. Do not use proper names or other words that will unduly restrict the data that can be entered into the table. 6. Do not use a name that implicitly or explicitly identifies more than one concept (e.g. facility or branch entity). 7. Do not use the plural form of the name."

Chapter 4: SQL & Integrity Constraints

Q1. What to connect to an oracle database from java program?
Answer: A: There are six things that need to know to connect to an oracle database from a Java program: 1. DRIVER 2. IP ADDRESS 3. PORT NUMBER: The well-known port for oracle is 1521 4. ORACLE INSTANCE: The default at Pace is ORA1 5. USERNAME as given by DBA 6. PASSWORD as given by DBA

Q2. What is a Stored Procedure?

Answer: A stored procedure is a set of SQL commands that has been compiled and stored on the database server. Once the it is "stored", client applications can execute the stored procedure repeatedly without sending it to the database server again and without compiling it again. Stored procedures improve performance by reducing network traffic and CPU load.

Chapter 5: Relational Database Design

Answer to Review Question No 7
Banker-schema is not in BCNF since banker-name is not a superkey. If we apply BCNF decomposition algorithm, we obtain the following BCNF decomposition. banker-branch-schema = (banker-name, branch-name) customer-banker-schema = (customer-name, banker-name) The decomposed schemas preserve only banker-name the closure of {banker-name branch-name (and trivial dependencies) but branch-name} does not include customer-name branch-name

banker-name. The violation of this dependency cannot be detected unless a join is computed. To see why the decomposition of Banker-schema into the schemas Banker-branch-schema and customer-banke-schema is not dependency preserving, we apply the algorithm of testing for dependency preservation, we find that the restrictions F1 and F2 of F to each schema are as follows: F1 = {banker-name, branch-name} F2 = (only trivial dependencies hold on customer-banker-schema) banker-name is not in F + even Thus, a canonical cover for the set F is F1. It is easy to see that dependency Customer-name branch-name though it is in F+. Therefore, F + F+, and the decomposition is not dependency preservation.

Answer to Review Question No 13

There are relation schemas that are in BCNF that do not seem to be sufficiently normalized, in the sense that they still suffer from the problem of repetition of information. Consider banking example. Let us assume that, in an alternative design for the bank database schemas, we have the schema BC-schema = (loan-number, customer-name, customer-street, customer-city) The astute reader will recognize this schema as a non-BCNF schema because of the functional dependency Customer-name customer-street customer-city that we asserted and because customer-name is not a key for BC-schema. However, let us assume that out bank is attracting wealthy customers who have several addresses (say, a winter home and a summer home). Then, we no longer wish to enforce the functional dependency customer-name customer-street customer-city. If we remove this functional dependency, we find BC-schema to be in BCNF with respect to our modified set of functional dependencies. Yet, even though BC-schema is now in BCNF, we still have the problem of repetition of information. To deal with this problem, we must define a new form of constraint, called a multivalued dependency. (We use multivalued dependencies to define a normal form for relation schemas. This normal form, called fourth normal form (4 NF), is more restrictive than BCNF).

Chapter 6: Internal Structure of RDBMS

Q1. What is a Transactional Database?
Answer: A transactional database is a DBMS where write operations on the database are able to be rolled back if they are not completed properly. If a transactional database system loses electrical power half-way through a transaction, the partially completed transaction will be rolled back and the database will be restored to the state it was in before the transaction started. Assume that a front-end application is sending a customer order to a database system. The front-end application sends the request to product to the customer and subtracts the product from inventory. The front-end application is about to send the request to create an invoice for the customer and suddenly the front-end application crashes. A transactional database can then roll back the partially completed transaction. An alternative to using a transactional database is to use atomic operations.

Q2. What is Database Replication? List the advantages of Replication.

Answer: Database replication is the creation and maintenance of multiple copies of the same database. In most implementations of database replication, one database server maintains the master copy of the database and additional database servers maintain slave copies of the database. Database writes are sent to the master database server and are then replicated by the slave database servers. Database reads are divided among all of the database servers, which results in a large performance advantage by load sharing. Database replication can also improve availability because the slave database servers can be configured to take over the master role if the master database server becomes unavailable. Advantages of Replication: Availability: Failure of site containing relation r does not result in unavailability of r as its replicas exist. Parallelism: Queries on r may be processed by several nodes in parallel. Reduced data transfer: Relation r is available locally at each site containing a replica of r.

Q3. What is fragmentation?

Answer: A fragment is a distribution unit that is a subset of a relation (or object in a more general sense) that can be obtained by an expression on the data model language. Common expressions used for fragmentation of relations include: selections, projections and semi-joins. In addition to reduce network transfer cost, fragmentation also maximizes concurrency by allowing concurrent transactions that access disjoint sets of a relation to proceed independently one of the other. In addition, a single query can also benefit from fragmentation by accessing in parallel different fragments.

Chapter 7: File Organization & Index Structures

Q1. What is a BLOB?
Answer: A BLOB (Binary Large Object) is a large chunk of data which is stored in a database. A BLOB differs from regular database data. It is not forced into a certain schema. A normal database field might be structured to be 14 characters long and accept lowercase letters only. A BLOB field is not usually restricted in content type. A content can be several gigabytes in size. Normal database fields have space allocated for them whether they are utilized or not. BLOB fields are only allocated space when they are utilized. BLOB fields are normally used to store graphics, audio, video, or documents. BLOB fields can be added, changed, and deleted. However, they cannot be searched and manipulated with standard database commands.

Q2. What is a DSN?

Answer: A DSN (Data Source Name) is an identifier which defines a data source for an ODBC driver. A DSN consists of information such as: Database name Directory Database driver User ID Password Under Unix, DSN configuration is usually stored in /etc/odbc.ini. In Microsoft Windows, DSN configuration is normally stored in the registry, although it may also be stored in configuration files with a .dsn extension

Q3. What is B-TREE-P?

Answer: B-TREE-P is software that allows data to be instantly located and output, without having to wait for lengthy file sorts or searches. B-TREE-P is a software product from Semaphore Corporation that enhances the Pick operating system and makes it easier to use.

Q4. How much disk space do B-trees require?

Answer: Each B-tree is only a list of item identifiers, along with a few extra pointers, so a B-tree only takes about 10% more than the number of frames used by a SELECT list of the items being indexed. For example, if a SELECT list of a vendor file takes about 200 frames, than a B-tree for the same file will probably take about 220 frames. Each data files can have any number of B-trees. B-trees are stored in their own file space, any number of B-trees can be saved in one file, and B-trees and indexed data files can grow to any size. As only item identifiers are saved, a B-tree takes the same amount of space

regardless of how the data file is indexed and sorted. For example, a B-tree for vendor lookups by ZIP codes takes the same amount of space as a B-tree for lookups by company name or by phone number or by invoice date.

Q5. B-trees are better than inverted files justify the proposition
Answer: Inverted files usually fail if the inverted list of identifiers grows beyond the Pick item limit of 32K, and can require slow sequential searches of those large items. B-tree items always stay very small and never run into any Pick size limitations. Inverted files can only find actual keys known to already exist in the data. If a look up for any ZIP code 95003, and it's not in the file, an inverted file can do nothing. But a B-tree can tell the next closest match, such as ZIP 95005, and even identify any size "neighborhood" of adjacent records before and after the match. Inverted files only allow searches for a complete key. However, with B-trees search for the name JOTIN, or just JOT, or just the letter J, or as many characters correctly specified and B-TREE-P will immediately find the closest match. If an inverted file tries to store all those substrings, it requires enormous amounts of disk space. Inverted files cannot step sequentially through the index file. Whereas B-trees can start at any key, then step sequentially through all preceding or following keys. Inverted files allow searches for a primary key only ,while with B-trees immediate retrieval of the list of items having ZIP 10020.. Software for inverted files is usually tied closely to the data being indexed, and must often be modified if a new type of data file or field is to be indexed. B-trees are much more efficient, flexible, and user-friendly than inverted files.

Q6. How were B-trees invented?

Answer: B-tree algorithms were developed by various computer manufacturers and independent research groups beginning in about the late 1960s, and are now the basis for many commercial database systems, although not the Pick system. After deciding to abandon the use of inverted files on its Pick system in late 1985, Semaphore Corporation developed its own B-tree software to simplify and improve various applications used internally at the company. Articles published by Semaphore about those efforts attracted numerous requests from other Pick users asking to acquire the software, so it was packaged as B-TREE-P beginning in April 1986.