Question No. 1 Part 1: Followings are the main features of Relational Database:1. Object storage.

To store an object in a relational database you need to flatten it create a data representation of the object because relational databases only store data. To retrieve the object you would read the data from the database and then create the object, often referred to as restoring the object, based on that data. Although storing objects in a relational database sounds like a simple thing to achieve, practice shows that it isn t. This is due to the object-relational impedance mismatch, the fact that relational database technology and object technology are based on different underlying theories, a topic discussed in The Object-Relational (O/R) Impedance Mismatch. To store objects successfully in relational databases you need to learn how to map your object schema to your relational database schema. 2. Implementing behavior within the database. Behavior is implemented in a relational database via stored procedures and/or stored functions that can be invoked internally within the database and often by external applications. Stored functions and procedures are operations that run within an RDBMS, the difference being what the operation can return and whether it can be invoked in a query. The differences aren t important for our purposes so the term stored procedure will be used to refer to both stored functions and stored procedures. In the past stored procedures were written in a proprietary language, such as Oracle s PL/SQL, although now Java is quickly becoming the language of choice for database programming. A stored procedure typically runs some SQL code, massages the data, and then hands back a response in the form of zero or more records, or a response code, or as a database error message. Effective use of stored procedures is discussed in detail in Implementation Strategies for Persisting Objects in RDBs. 3. Concurrency control. Consider an airline reservation system. There is a flight with one seat left on it, and two people are trying to reserve that seat at the same time. Both people check the flight status and are told that a seat is still available. Both enter their payment information and click the reservation button at the same time. What should happen? If the system is working properly only one person should be given a seat and the other should be told that there is no longer one available. Concurrency control is what makes this happen. Concurrency control must be implemented throughout your object source code and within your database. 4. Transaction control. A transaction is a collection of actions on your database such as the saving of, retrieval of, or deletion of data which form a work unit. A flat transactions is an all-or-nothing approach where all the actions must either succeed or be rolled back (canceled). A nested transaction is an approach where some of the actions are transactions in their own right. These sub-transactions are committed once successful and are not rolled back if the larger transaction fails. Transactions may also be short-lived, running in thousandths of a second, or long-lived, taking hours, days,

weeks, or even months to complete. Transaction control is a critical concept for all developers to understand. 5. Enforcing referential integrity. Referential integrity (RI) is the assurance that a reference from one entity to another entity is valid. For example, if a customer references an address, then that address must exist. If the address is deleted then all references to it must also be removed, otherwise your system must not allow the deletion. Contrary to popular belief, RI isn t just a database issue; it s an issue for your entire system. A customer is implemented as an object within a Java application and as one or more records in your database addresses are also implemented as objects and as rows. To delete an address, you must remove the address object from memory, any direct or indirect references to it (an indirect reference to an address would include a customer object knowing the value of the AddressID, the primary key of the address in the database), the address row(s) from your database, and any references to it (via foreign keys) in your database. To complicate matters, if you have a farm of application servers that address object could exist simultaneously on several machines. Furthermore, if you have other applications accessing your database then it is possible that they too have representations of the address in their memory as well. Worse yet, if the address is stored in several places (e.g. different databases) you should also consider taking this into account. All developers should understand basic strategies for implementing referential integrity. Semantic Data Model: The Semantic Data Model (SDM), like other data models, is a way of structuring data to represent it in a logical way. SDM differs from other data models, however, in that it focuses on providing more meaning of the data itself, rather than solely or primarily on the relationships and attributes of the data. SDM provides a high-level understanding of the data by abstracting it further away from the physical aspects of data storage. In SDM, an entity represents some aspect or item in the real world, such as an employee. An entity is akin to a record in a relational system or an object in an object-oriented system. These entities in SDM focus on types, which are more general, instead of sets of data. In SDM, an entity is a very basic notion of a real-world or conceptual object that is defined by a single attribute. For instance, an SDM entity type might be person, which provides an elementary category that can be easily understood. In a relational model, however, you might end up with a number of different tables including person, spouse, children, house, and job. Each of these things represents part of what makes up the person, but with SDM, the person is the whole entity, rather than breaking it down into parts.

In this way, an entity in SDM is very similar to a domain. Therefore, inside this domain of person, there would be a list of names of people that are to be represented by the data. The objects in this domain would then point to specific instances of a person that are represented by each person entity. For example, the domain Person names contain Bob, Sue, Jim, Betty, and Clyde. Each of these names points to a specific object instance of Person, so that Bob points to record giving details about Bob, such as name, gender, or marital status, and so on for each of the entities listed under Person. Part 2: Multivalued Dependencies: Multivalued dependencies are also referred to as tuple generating dependencies. After the Boyce -Codd normal form the results may be devoid of any functional dependencies but it may encounter multivalued dependencies as the multivalued dependencies also cause redundancy of data. For eg: If there are 3 attributes involved in a relation,A,B, and C. Then for every value of A we will have respective values for B and C. But it is a necessary in the 4th normal form that both B and C values are independent of each other. This is represented by.,, A->>B A->>C.. MVD or Multivalued Dependency is a dependency where one attribute value is potentially a "multivalued fact" about another and the attributes must be independent of each other. Projection Join Decency: If a table can be decomposed into three or more smaller tables, it must be capable of being joined again on common keys to form the original table A table is in fifth normal form (5NF) or Projection-Join Normal Form (PJNF) if it is in 4NF and it cannot have a lossless decomposition into any number of smaller tables. Question No.2 In centralized database systems all the data is managed by one server. In case of failure of the server there is no access to institution s data and the whole information system is paralyzed. Fortunately, if the server was administered properly there should be possible to restore the state of the server from the moment of failure. Even if the database management system does not guarantee this there is always an option of going back to a consistent state of the database from the most recent backup.

The issue of fault tolerance and recovery is much more complicated in case of distributed database systems. A distributed database can be defined as a collection of multiple, logically interrelated databases distributed over a computer network or a set of databases stored on multiple computers that typically appears to applications as a single database. In a distributed system a single server failure does not have to affect the whole information system. Let us assume a hospital whose all organization units have their own database servers managing their data. If one of the servers crashes only one organization unit will lose access to its data. Other organization units will suffer only partial loss of functionality due to inaccessibility of one remote server and its data. But still from a single organization unit s point of view the risk of the loss of all functionality is not less than in case of a centralized system with additional possibilities of partial failures. Moreover, if a company or institution relies on one server it will probably improve its fault tolerance by using such techniques as disk or server mirroring, which might be too expensive in case of a multi-server environment. It is no surprise that recovery complicates in a distributed system. Restoring the state of a single server after its failure from the most recent backup might not be enough because data on the restored server may be inconsistent with other servers. A distributed database management system must offer options that guarantee that results of all committed transactions will be restored after a server failure. For instance, Oracle gives an option of archiving redo logs which together with regularly made backups enable the administrator to restore a transaction consistent state of a database from the moment of failure. Centralized systems are easy to design, manage and maintain but in some cases distributed systems may be more suitable. There are two most important reasons for using distributed database systems. The first is a geographic distribution of an institution or organization for which the system is being designed. If an institution consists of many organization units which are not connected by a stable and fast Local Area Network (LAN), which might be true for some hospitals, it would be irresponsible and inefficient to base the institution s database system on one server. Such a solution would lead to long response times and in case of unstable network connection to possible problems with access to data. A much more reasonable solution would be assigning a database server to each organization unit to manage its data and organizing the system in such a way that the servers cooperate with each other to enable access to remote data. The second reason why it might be advisable to distribute the data over several servers is a need of increasing the processing power of the system. Hospitals, like other large institutions, process huge volumes of data, which even a powerful server might not be able to deal with efficiently. For big organizations, companies, or hospitals data distribution might be the only way to improve performance of the information system. Additionally, distributed database systems offer better scalability than centralized systems. Besides the possibility of upgrading a single server (vertical scalability) there is an option of adding a new server to the system (horizontal scalability). Another advantage of distributed database systems, which may be important in case of a hospital information system, is site

autonomy (each organization unit has its own server managing its data and may decide which data should be made accessible for other organization units). The biggest disadvantage of a distributed system is a possibility of losing an access to remote data in case of a remote server or network failure. Consequences of such failures are minimized by means of replication. On the above discussion we can conclude the following results. 1. For information system of particular hospital within a city, centralized database system will be recommended. 2. For information system of school (like Allied School System etc.), distributed database will be recommended.

Question No. 3. 1. Difference between entity integrity constraint, referential integrity constraint and referential existence dependency. Entity integrity constraint: Entity constraints ensure the integrity of the entities being modeled by the system. At the simplest level, the existence of a primary key is an entity constraint that enforces the rule every entity must be uniquely identifiable. In a sense, this is the entity integrity constraint; all others are technically entity-level integrity constraints. The constraints defined at the entity level can govern a single attribute, multiple attributes, or the relation as a whole. The integrity of an individual attribute is modeled first and foremost by defining the attribute against a specific domain. An attribute within a relation inherits the integrity constraints defined for its domain. At the entity level, these inherited constraints can properly be made more rigorous but not relaxed. Another way of thinking about this is that the entity constraint can specify a subset of the domain constraints but not a superset. For example, an OrderDate attribute defined against the TransactionDate domain might specify that the date must be in the current year, whereas the TransactionDate domain allows any date between the date business commenced and the current date. An entity constraint should not, however, allow OrderDate to contain dates in the future, since the attribute s domain prohibits these. Similarly, a CompanyName attribute defined against the Name domain might prohibit empty values, even though the Name domain permits them. Again, this is a narrower, more rigorous definition of permissible values than that specified in the domain. Referential integrity constraint:

Referential integrity constraint is that which depend upon the parent and child relationship. In this one of the columns have the primary key constraint and one of the column of another table have the foreign key constraint. So you cannot delete the column value which having the foreign key constraint until you never delete its related primary key column value from parent table. If you tried to do this it will show you error related to referential integrity constraint. But if you still want to delete value from child table but never want to delete parent table. Referential existence dependency: An entity that cannot exist unless another related entity exists. A mandatory relationship produces an existence dependency. Referential Dependency is another type of existence dependency which occurs when a weak entity contains as a foreign key the primary key of the corresponding strong entity. Question No. 3 Part 2: Primary Key: A key is a set of columns that can be used to identify or access a particular row or rows. The key is identified in the description of a table, index, or referential constraint. The same column can be part of more than one key. A unique key is a key that is constrained so that no two of its values are equal. The columns of a unique key cannot contain NULL values. For example, an employee number column can be defined as a unique key, because each value in the column identifies only one employee. No two employees can have the same employee number. The primary key is one of the unique keys defined on a table, but is selected to be the key of first importance. There can be only one primary key on a table. A primary index is automatically created for the primary key. The primary index is used by the database manager for efficient access to table rows, and allows the database manager to enforce the uniqueness of the primary key. Table Key Column Employee table EMPNO Department table

DEPTNO Project table PROJNO The following example shows part of the PROJECT table, including its primary key column. Table. A Primary Key on the PROJECT Table PROJNO (Primary Key) MA2100 MA2110 PROJNAME Weld Line Automation Weld Line Programming DEPTNO D01 D11

Secondary Key: Up to 40 keys can be defined for a table. The first key defined is the primary key. All the other keys are secondary keys and are optional. Secondary keys are used to view records in an order that is different from the order defined by the primary key fields. For example, an employee has an employee number, a National Insurance (NI) number and an email address. If the employee number is chosen as the primary key then the NI number and email address are secondary keys. However, it is important to note that if any employee does not have a NI number or email address (ie: the attribute is not mandatory) then it cannot be chosen as a primary key. Candidate Key: A candidate key is a column, or set of columns, in a table that can uniquely identify any database record without referring to any other data. Each table may have one or more candidate keys, but one candidate key is special, and it is called the primary key. This is usually the best among the candidate keys. The attribute set {cFirstName, cLastName, cStreet} might also be a candidate key for the Customers table, if we make the same assumption about first and last names. With more than

one ck, we try to pick the one that is most descriptive of the individual and/or least likely to change over time. There s not much difference in this example. Alternate Key: An alternate key is any candidate key which is not selected to be the primary key. An alternate key is similar to a primary key. It accepts null values; where as the primary key does not. The null values can be submitted to the attribute in a tuple. There can be a key apart from primary key in a table that can also be a key. This key may or may not be a unique key. For example, in an employee table, empno is a primary key, empname is a alternate key that may not be unique but still helps in identifying a row of the table. Super Key: A superkey is defined in the relational model as a set of attributes of a relation variable (relvar) for which it holds that in all relations assigned to that variable there are no two distinct tuples (rows) that have the same values for the attributes in this set. Equivalently a superkey can also be defined as a set of attributes of a relvar upon which all attributes of the relvar are functionally dependent. Foreign key: A foreign key (FK) is a field or group of fields in a database record that points to a key field or group of fields forming a key of another database record in some (usually different) table. Usually a foreign key in one table refers to the primary key (PK) of another table. This way references can be made to link information together and it is an essential part of database normalization