Sie sind auf Seite 1von 9

section1:A1

An entity-relationship diagram (ERD) is a graphical representation of an


information system that shows the relationship between people,
objects, places, concepts or events within that system. An ERD is a data
modeling technique that can help define business processes and can be
used as the foundation for a relational database. While useful for
organizing data that can be represented by a relational structure, an
entity-relationship diagram can't sufficiently represent semi-structured
or unstructured data, and an ERD is unlikely to be helpful on its own in
integrating data into a pre-existing information system.

Three main components of an ERD are the entities, which are objects or
concepts that can have data stored about them, the relationship
between those entities, and the cardinality, which defines that
relationship in terms of numbers.

For example, an ER diagram representing the information system for a


company's inventory might start with graphical representations of
entities such as the sales representative, the customer, the customer's
address, the customer's order, the product and the warehouse. (See
diagram) Then lines or other symbols can be used to represent the
relationship between entities, and text can be used to label the
relationships.
Finally, cardinality notations define the attributes of the relationship
between the entities. Cardinalities can denote that an entity is optional
(for example, a sales rep could have no customers or could have many)
or mandatory (for example, the must be at least one product listed in an
order.)

section 1:A2

A file system as the name states is simply a system for storing files. Just
like in character formats, theoretically anyone could develop their own
way of storing files, but this would be impractical. The earliest file
systems used a File Allocation Table (FAT), logically a table that divides
a disk into clusters and files are then assigned clusters. For historical
and simplicity purposes, FAT file systems (notably ExFAT and FAT32) are
the de facto file systems for interchanging data across multiple devices,
platforms, and operating systems. For example, when you take a picture
on a digital camera and it is stored on an SD card, it is likely using a FAT
file system. Other common ones are the New Technology File System
(NTFS) for Windows/DOS, the Extended File System (EXT2/3/4) for
Linux, and the Hierarchical File System (HFS) for Mac.

Structured data- Structured Data means that a database designer


defines what information is stored, and what format it must be stored
in.

A database is generally used for storing related, structured data, with


well defined data formats, in an efficient manner for insert, update
and/or retrieval (depending on application). Databases allow, for
example, to sort all people in alphabetical order, or to find those whose
birthday is in January.

On the other hand, a file system is a more unstructured data store for
storing arbitrary, probably unrelated data. The file system is more
general, and databases are built on top of the general data storage
services provided by file systems.

Suppose that one of the bank officers needs to find out the names of all
customers who live within a particular postal-code area. The officer asks
the data-processing department to generate such a list. Because the
designers of the original system did not anticipate this request, there is
no application program on hand to meet it. There is, however, an
application program to generate the list of all customers. The bank
officer has now two choices: either obtain the list of all customers and
extract the needed information manually or ask a system programmer
to write the necessary application program. Both alternatives are
obviously unsatisfactory. Suppose that such a program is written, and
that, several days later, the same officer needs to trim that list to
include only those customers who have an account balance of $10,000
or more. As expected, a program to generate such a list does not exist.
Again, the officer has the preceding two options, neither of which is
satisfactory.

The point here is that conventional file-system environments do not


allow needed data to be retrieved in a convenient and efficient manner.
More responsive data-retrieval systems are required for general use
therefore we need a DBMS for such situations.

section1 :A7

A)Transactions
In the context of a database, a transaction can be defined as a group of
tasks (database operations). It is a unit of a program execution that
accesses and possibly modifies various data objects (database tuples,
relations). A transaction is a logical unit of database processing that
includes one or more access operations-

Read - retrieval of information from database

Write - insert or update in the database, delete data from the


database

A: Atomicity states that every Transaction should be atomic in nature. A


Transaction in a Relational Database can contain either a single SQL
statement or multiple SQL statements. Thus by Atomic Transaction it
means all or none. Either all SQL statements/steps execute
successfully in a transaction, or fail as a single unit and none of them
should be treated as executed and the system should be returned to its
original state.

C: Consistency states that any Transaction happened in a database will


take it from one consistent state to another consistent state. The data
finally recorded in the database must be valid according to the defined
Rules, Constraints, Cascades, Triggers, etc. If in case of any failure to
these rules the changes made by any transaction should be rolled-back,
this will put the system in earlier consistent state.

I: Isolation means Transactions performing same functions should run


in Isolation and not in parallel to provide more concurrency to the data
and avoiding dirty reads & writes. One need to use proper Transaction
Isolation levels and locking in order to prevent this.

D: Durability, a transaction should be durable by storing the data


permanently and making it available in case of power failure, recovery
from system failure, crash, any error, etc.

In a multiprogramming environment where multiple transactions can be


executed simultaneously, it is highly important to control the
concurrency of transactions. We have concurrency control protocols to
ensure atomicity, isolation, and serialization of concurrent transactions.

B)Two-Phase Locking 2PL

This locking protocol divides the execution phase of a transaction into


three parts. In the first part, when the transaction starts executing, it
seeks permission for the locks it requires. The second part is where the
transaction acquires all the locks. As soon as the transaction releases its
first lock, the third phase starts. In this phase, the transaction cannot
demand any new locks; it only releases the acquired locks.

Two-phase locking has two phases, one is growing, where all the locks
are being acquired by the transaction; and the second phase is
shrinking, where the locks held by the transaction are being released.

section2:b1

Transactions are normally executed concurrently (they overlap), since


this is the most efficient way. Serializability is the major correctness
criterion for concurrent transactions' executions. Serializability is closely
related to concurrency How do different concurrent
processes/sessions/transactions serialize or synchronize their respective
access to shared/global mutable data ?

Lets take a simple example:

Two transactions T1 and T2 want to update the same row. So there are
two concurrent sessions running these transactions and we issue the
following DML statement in both the transactions:

UPDATE T SET SALARY=SALARY+10000 WHERE KEY=<BLAH>;


Because both transactions are executing concurrently and both are
interested in updating the same row, there has to be a way to prevent
race conditions and keep state of data consistent. We cant allow both
the transactions to simply execute the UPDATE statement.

One of the transactions will have to be given exclusive access to the


row ROW LEVEL LOCKS in Database terminology. The transaction will
hold the lock until it ends (either through commit or rollback). As long
as the lock is held, any other concurrent transaction will have to wait.
This is how both the transactions serialized access to table rows.

so we can say "serializability is used to enforce concurrency control in a


database system".

section2 :b2

A)Transactions
In the context of a database, a transaction can be defined as a group of
tasks (database operations). It is a unit of a program execution that
accesses and possibly modifies various data objects (database tuples,
relations). A transaction is a logical unit of database processing that
includes one or more access operations-

Read - retrieval of information from database

Write - insert or update in the database, delete data from the


database

A: Atomicity states that every Transaction should be atomic in nature. A


Transaction in a Relational Database can contain either a single SQL
statement or multiple SQL statements. Thus by Atomic Transaction it
means all or none. Either all SQL statements/steps execute
successfully in a transaction, or fail as a single unit and none of them
should be treated as executed and the system should be returned to its
original state.

C: Consistency states that any Transaction happened in a database will


take it from one consistent state to another consistent state. The data
finally recorded in the database must be valid according to the defined
Rules, Constraints, Cascades, Triggers, etc. If in case of any failure to
these rules the changes made by any transaction should be rolled-back,
this will put the system in earlier consistent state.

I: Isolation means Transactions performing same functions should run


in Isolation and not in parallel to provide more concurrency to the data
and avoiding dirty reads & writes. One need to use proper Transaction
Isolation levels and locking in order to prevent this.

D: Durability, a transaction should be durable by storing the data


permanently and making it available in case of power failure, recovery
from system failure, crash, any error, etc.

In a multiprogramming environment where multiple transactions can be


executed simultaneously, it is highly important to control the
concurrency of transactions. We have concurrency control protocols to
ensure atomicity, isolation, and serialization of concurrent transactions.

B)Two-Phase Locking 2PL

This locking protocol divides the execution phase of a transaction into


three parts. In the first part, when the transaction starts executing, it
seeks permission for the locks it requires. The second part is where the
transaction acquires all the locks. As soon as the transaction releases its
first lock, the third phase starts. In this phase, the transaction cannot
demand any new locks; it only releases the acquired locks.

Two-phase locking has two phases, one is growing, where all the locks
are being acquired by the transaction; and the second phase is
shrinking, where the locks held by the transaction are being released.

Das könnte Ihnen auch gefallen