THIS IS DATABASE ASSIMENT

Q1

New-1a

NEW-1B

 phase field model is a mathematical model for solving interfacial problems. It has mainly been applied to solidification dynamics but it has also been applied to other situations such as viscous fingering  fracturedynamics,vesicle dynamicsetc.

The method substitutes boundary conditions at the interface by a partial differential equation for the evolution of an auxiliary field (the phase field) that takes the role of an order parameter. This phase field takes two distinct values (for instance +1 and −1) in each of the phases, with a smooth change between both values in the zone around the interface, which is then diffuse with a finite width. A discrete location of the interface may be defined as the collection of all points where the phase field takes a certain value (e.g., 0).

A phase field model is usually constructed in such a way that in the limit of an infinitesimal interface width (the so-called sharp interface limit) the correct interfacial dynamics are recovered. This approach permits to solve the problem by integrating a set of partial differential equations for the whole system, thus avoiding the explicit treatment of the boundary conditions at the interface.

New-1c

The internal view is the database as physically stored. * The
internal schema is the definition of that internal view. The
internal DDL is a language for writing internal schemas.
Note: The book usually uses the more intuitive terms "stored database" and "stored database definition" in place of "internal view" and "internal schema," respectively.

An external view is a more or less abstract representation of some portion of the total database. An external schema is a definition of such an external view. An external DDL is a language for writing external schemas.

Q2

New-2a

functional dependencies

We can formalize this intuition through the notion of functional dependencies. Suppose X is a set of attributes of a relation R, and A is a single attribute of R. We say that X determines A or that the functional dependency X → A holds for R if the following is true: for any relation instance I of R, whenever there are two records r and r′ in I with the same X values, they have the same A values as well. The functional dependency X → A is interesting (or, to use the term of the research community, nontrivial) if A is not an attribute of X.

EX:

Suppose that a bank associates each customer with his or her home branch, that is, the branch where the customer opened his or her first account. Each branch is in a specific legal jurisdiction, denoted jurisdiction. Is the relation (customer, branch, jurisdiction) normalized?

Let us look at the functional dependencies. Because each customer has one home branch, we have customer → branch Because each branch is in exactly one jurisdiction, we have branch → jurisdiction So, customer is the key, yet the left-hand side of the functional dependency branch → jurisdiction is not customer. Therefore, (customer, branch, jurisdiction) is not normalized. Its problems are exactly the problems of Onorder1 earlier. Relation (customer, branch, jurisdiction) will use more space than the two relations (customer, branch) and (branch, jurisdiction). Further, if a branch loses its customers, then the database loses the relationship between branch and jurisdiction. (The bank directors may not care, but information scientists dislike losing information by accident.)

Q.3

New-3

1. (Physical) data independence is the immunity of applications to changes in storage structure (how the data is physically stored) and access technique (how it is physically accessed).
   Note: Logical data independence is discussed in Chapters 2, 3, and especially 10. See also Appendixes A and D
2. The database management system (DBMS) is a software component that manages the database and shields users from low-level details (in particular, details of how the database is physically stored and accessed). All requests from users for access to the database are handled by the DBMS.
3. A transaction is a logical unit of work, typically involving several database operations (in particular, several update operations), whose execution is guaranteed to be atomic──i.e., all or nothing──from a logical point of view.
4. The data dictionary is a system database that contains "data about the data"──i.e., definitions of other objects in the system, also known as metadata (in particular, all of the various schemas and mappings will physically be stored, inboth source and object form, in the dictionary). A comprehensive dictionary will also include cross-reference information, showing, for instance, which applications use which pieces of the database, which users require which reports, what terminals or workstations are connected to the system, and so on. The dictionary might even──in fact, probably should──be integrated into the database it defines, and thus include its own definition (i.e., be "selfdescribing").
5. The degree of relationship (also known as cardinality) is the number of occurrences in one entity which are associated (or linked) to the number of occurrences in another.
6. The cardinality of relationship (also known as cardinality) is the number of occurrences in one entity which are associated (or linked) to the number of occurrences in another
7. A candidate key is a combination of attributes that can be uniquely used to identify a database record without any extraneous data. Each table may have one or more candidate keys. One of these candidate keys is selected as the table primary key.
8. Referential integrity is a database concept that ensures that relationships between tables remain consistent. When one table has a foreign key to another table, the concept of referential integrity states that you may not add a record to the table that contains the foreign key unless there is a corresponding record in the linked table.

New 4a

New4-b

New-5a

1. cascading rollback:

Is when, in a database system, you have several concurrent transactions, and if they are dependant, when one fails, all the dependant transactionswill fail, and therefore the system must generate a rollback of the othertransactions, if they have been executed

ii)

iii) logical logging

The logical log is actually a set of files that keep history of database transactions and database server changes since the last level 0 backup. Logical log files are not ordinary operating system files. They are created automatically by Informix Dynamic Server during first initialization and then managed by Informix Dynamic Server onparams utility. Logical log files are circular. In other words, they can be used again and again after they are filled up.

New-5b

conflict equivalent

conflict serializable

The schedules S1 and S2 are said to be conflict-equivalent if the following conditions are satisfied: Both schedules S1 and S2 involve the same set of transactions (including ordering of actions within each transaction). The order of each pair of conflicting actions in S1 and S2 are the same.

Conflict-serializable:- A schedule is said to be conflict-serializable when the schedule is conflict-equivalent to one or more serial schedules. Another definition for conflict-serializability is that a schedule is conflict-serializable if and only if its precedence graph/serializability graph, when only committed transactions are considered, is acyclic (if the graph is defined to include also uncommitted transactions, then cycles involving uncommitted transactions may occur without conflict serializability violation).

New-6a

Some of the advantages are as follows:
• Compactness
• Speed
• Less drudgery
• Currency
• Centralized control
• Data independence Some of the disadvantages are as follows:
• Security might be compromised (without good controls).
• Integrity might be compromised (without good controls).

• Additional hardware might be required.
• Performance overhead might be significant.
• Successful operation is crucial (the enterprise might be highly vulnerable to failure).
• The system is likely to be complex (though such complexity should be concealed from the user)

New-6b

(a) Hierarchical model:

This model presents data to users in a hierarchy of data elements that can be represented in a sort of inverted tree. In a sales order processing system, a customer may have many invoices raised to him and each invoice may have different data elements. Thus, the root level of data is customer, the second level is invoice and the last level is line items such as invoice number, date, product, quantity, etc.

This structure is quite natural when seen from the event point of view. However, the lower levels are owned by higher level data elements, and elements at the same level have no linkage at all. As a result, the query such as what products are purchased by which customer, in the above example, shall be difficult to carry out in the hierarchical structure.

The query as to which customer purchased which product would be convenient. Thus, where there are many-to-many relationships between two entities, this model would not be appropriate. Figure 9.4 shows the hierarchical model of data for a sales order processing application.

(b) Network model:

In the network model of database, there are no levels and a record can have any number of owners and also can have ownership of several records. Thus, the problem raised above in the sales order processing will not arise in the network model.

As there is no definite path defined for retrieval of data, the number of links is very large and thus network databases are complex, slow and difficult to implement. In view of the difficulty in implementation, network model is used only when all other options are closed.

The typical example of a network database may be the employee and the department he/she has worked or can work with in future. Figure 9.5 shows the network model of data for an employee information system.