Year – 2017

Group – B

2. Explain the different levels of abstraction of the data-base management system.

Database systems comprise complex data structures. In order to make the system efficient in terms
of retrieval of data, and reduce complexity in terms of usability of users, developers use abstraction
i.e. hide irrelevant details from the users. This approach simplifies database design.

Level of Abstraction in a DBMS

There are mainly 3 levels of data abstraction:

 Physical or Internal Level

 Logical or Conceptual Level

 View or External Level

Physical level (Internal level): The lowest level of abstraction describes how the data are actually
stored. The physical level describes complex low-level data structures in detail.

Logical level (Conceptual level): The next-higher level of abstraction describes what data are stored
in the database, and what relationships exist among those data.
 The logical level thus describes the entire database in terms of a small number of relatively
simple structures.
 Although implementation of the simple structures at the logical level may involve complex
physical-level structures, the user of the logical level does not need to be aware of this
complexity. This is referred to as physical data independence.
 Database administrators, who must decide what information to keep in the database, use
the logical level of abstraction.

View level (External level): The highest level of abstraction describes only part of the entire
database.
Even though the logical level uses simpler structures, complexity remains because of the variety of
information stored in a large database. Many users of the database system do not need all this
information; instead, they need to access only a part of the database. The view level of abstraction
exists to simplify their interaction with the system. The system may provide many views for the
same database.

3. What is contraint? Explain domain constraint and Entity Integrity constraint.

In modeling the design of the relational database we can put some restrictions like what values are
allowed to be inserted in the relation, and what kind of modifications and deletions are allowed in
the relation. These are the restrictions we impose on the relational database.

Constraints

These are the restrictions or sets of rules imposed on the database contents. It validates the quality
of the database. It validates the various operations like data insertion, updation, and other processes
that have to be performed without affecting the integrity of the data. It protects us against
threats/damages to the database. Mainly Constraints on the relational database are of 4 types

 Domain constraints

 Key constraints or Uniqueness Constraints

 Entity Integrity constraints

 Referential integrity constraints

1. Domain Constraints

 Every domain must contain atomic values(smallest indivisible units) which means composite
and multi-valued attributes are not allowed.

 We perform a datatype check here, which means when we assign a data type to a column we
limit the values that it can contain. Eg. If we assign the datatype of attribute age as int, we
can’t give it values other than int datatype.

Example:
Name Phone
EID

123456789
01 Bikash Dutta
234456678

Explanation: In the above relation, Name is a composite attribute and Phone is a multi-values
attribute, so it is violating domain constraint.

2. Key Constraints or Uniqueness Constraints

 These are called uniqueness constraints since it ensures that every tuple in the relation
should be unique.

 A relation can have multiple keys or candidate keys(minimal superkey), out of which we
choose one of the keys as the primary key, we don’t have any restriction on choosing the
primary key out of candidate keys, but it is suggested to go with the candidate key with less
number of attributes.

 Null values are not allowed in the primary key, hence Not Null constraint is also part of the
key constraint.

Example:

EID Name Phone

01 Bikash 6000000009

02 Paul 9000090009
EID Name Phone

01 Tuhin 9234567892

Explanation: In the above table, EID is the primary key, and the first and the last tuple have the same
value in EID ie 01, so it is violating the key constraint.

3. Entity Integrity Constraints

 Entity Integrity constraints say that no primary key can take a NULL value, since using
the primary key we identify each tuple uniquely in a relation.

Example:

EID Name Phone

01 Bikash 9000900099

02 Paul 600000009

NULL Sony 9234567892

Explanation: In the above relation, EID is made the primary key, and the primary key can’t take NULL
values but in the third tuple, the primary key is null, so it is violating Entity Integrity constraints.

4. Referential Integrity Constraints

 The Referential integrity constraint is specified between two relations or tables and used to
maintain the consistency among the tuples in two relations.

 This constraint is enforced through a foreign key, when an attribute in the foreign key of
relation R1 has the same domain(s) as the primary key of relation R2, then the foreign key of
R1 is said to reference or refer to the primary key of relation R2.

 The values of the foreign key in a tuple of relation R1 can either take the values of the
primary key for some tuple in relation R2, or can take NULL values, but can’t be empty.

Example:

EID Name DNO

01 Divine 12
EID Name DNO

02 Dino 22

04 Vivian 14

DNO Place

12 Jaipur

13 Mumbai

14 Delhi

Explanation: In the above tables, the DNO of Table 1 is the foreign key, and DNO in Table 2 is the
primary key. DNO = 22 in the foreign key of Table 1 is not allowed because DNO = 22 is not defined in
the primary key of table 2. Therefore, Referential integrity constraints are violated here.

Domain Constraints

In a database table, domain constraints are guidelines that specify the acceptable values for a
certain property or field. These restrictions guarantee data consistency and aid in preventing the
entry of inaccurate or inconsistent data into the database. The following are some instances of
domain restrictions in a DBMS ?
 Data type constraints ? These limitations define the kinds of data that can be kept in a
column. A column created as VARCHAR can take string values, but a column specified as
INTEGER can only accept integer values.
 Length Constraints ? These limitations define the largest amount of data that may be put in
a column. For instance, a column with the definition VARCHAR(10) may only take strings that
are up to 10 characters long.
 Range constraints ? The allowed range of values for a column is specified by range
restrictions. A column designated as DECIMAL(5,2), for example, may only take decimal
values up to 5 digits long, including 2 decimal places.
  Nullability constraints ? Constraints on a column's capacity to accept NULL values are known
as nullability constraints. For instance, a column that has the NOT NULL definition cannot
take NULL values.
 Unique constraints ? Constraints that require the presence of unique values in a column or
group of columns are known as unique constraints. For instance, duplicate values are not
allowed in a column with the UNIQUE definition.
 Check constraints ? Constraints for checking data: These constraints outline a requirement
that must hold for any data placed into the column. For instance, a column with the
definition CHECK (age > 0) can only accept ages that are greater than zero.
 Default constraints ? Constraints by default: Default constraints automatically assign a value
to a column in case no value is provided. For example, a column with a DEFAULT value of 0
will have 0 as its value if no other value is specified.

Entity Integrity Constraints

A database management system uses entity integrity constraints (EICs) to enforce rules that
guarantee a table's primary key is unique and not null. The consistency and integrity of the data in a
database are maintained by EICs, which are created to stop the formation of duplicate or incomplete
entries.

Each item in a table in a relational database is uniquely identified by one or more fields known as the
primary key. EICs make a guarantee that every row's primary key value is distinct and not null. Take
the "Employees" table, for instance, which has the columns "EmployeeID" and "Name." The table's
primary key is the EmployeeID column. An EIC on this table would make sure that each row's unique
EmployeeID value is there and that it is not null.

If you try to insert an entry with a duplicate or null EmployeeID, the database management system
will reject the insertion and produce an error. This guarantees that the information in the table is
correct and consistent.

EICs are a crucial component of database architecture and assist guarantee the accuracy and
dependability of the data contained in a database.

4. What is Relationship?

Explain different degrees of relationship. (In My Copy).

A relationship in a DBMS exists when the variable has a connection with the properties stored in
different tables. (In a database, a relationship refers to a connection or association between two or
more tables based on a common field. Relationships help organize and retrieve related data
efficiently.)

They're exhibited usually via keys in a table, which is either columns or fields that specify a distinctive
arrangement for each record.
5. "All primary keys are-the superkeys but converse is not true." - Clarify.
Define _multi-valued attribute and composite attribute with suitable example. (In Copy).

All primary keys are superkeys: This is correct. A primary key is a minimal superkey, meaning it
uniquely identifies every row in a table without redundancy. Since it fulfills the criteria of a
superkey (unique identification), every primary key is, by definition, a superkey.

But the converse is not true: This means not all superkeys are primary keys. A superkey can have
unnecessary attributes, making it non-minimal. For example, if you have a primary key {A}, a
superkey could be {A, B}, {A, C}, etc. These superkeys still uniquely identify rows but aren't
minimal, so they cannot be primary keys.

Now, the meaning of the statement:

 Every primary key is a superkey (because it uniquely identifies rows).

 But not every superkey is a primary key, because some superkeys contain extra
unnecessary attributes.

Example:

Let’s say we have a table Employee:

emp_id name phone

101 Alice 9999999999
102 Bob 8888888888

 {emp_id} → Primary key (also a superkey).

 {emp_id, phone}, {emp_id, name} → Superkeys, but not primary keys (because emp_id
alone is enough).

Final Clarification:

 Primary Key = Minimal Superkey

 Superkey = Any set of attributes that uniquely identifies rows
 So, all primary keys are superkeys, but not all superkeys are primary keys.
6. Consider the following tables with their functional

dependencies :

Professor (Professor_code)

PercenCtime)

(Department, Professor code) ~ (Head of' dept,

Percent_time)

(Department) ~ (Head of' dept]

(Headjofdept, Professor_code)

PercenCtime)

It is assumed that-

i) A Professor can work in more than one department

ii] The percentage of the time he spends in each department is given

iii) Each department has one one headjof' dept. Normalize the table up to BCNF.

Boyce-Codd Normal Form (BCNF)

Definition. A relation schema R is in BCNF if whenever a nontrivial functional dependency X → A

holds in R, then X is a superkey of R.

Boyce-Codd Normal Form (BCNF) is a stricter version of Third Normal Form (3NF) that ensures a
more simplified and efficient database design. It enforces that every non-trivial functional
dependency must have a superkey on its left-hand side. This approach addresses potential issues
with candidate keys and ensures the database is free from redundancy.

BCNF eliminates redundancy more effectively than 3NF by strictly requiring that all functional
dependencies originate from super-keys.

BCNF is essential for good database schema design in higher-level systems where consistency and
efficiency are important,

Rules for BCNF

Rule 1: The table should be in the 3rd Normal Form.

Rule 2: X should be a super-key for every functional dependency (FD) X−>Y in a given relation.
Group – c

7. a) Explain the ACID properties for a transaction.

Ans: In Copy.

b) Explain all the states of a transaction with example for each state.

Ans: In Book. Page – 784

A transaction is an atomic unit of work that should either be completed in its entirety
or not done at all. For recovery purposes, the system needs to keep track of when
each transaction starts, terminates, and commits, or aborts (see Section 20.2.3).
Therefore, the recovery manager of the DBMS needs to keep track of the following
operations:
■ BEGIN_TRANSACTION. This marks the beginning of transaction execution.
■ READ or WRITE. These specify read or write operations on the database items that
are executed as part of a transaction.
■ END_TRANSACTION. This specifies that READ and WRITE transaction operations have
ended and marks the end of transaction execution. However, at this point it may be
necessary to check whether the changes introduced by the transaction can be
permanently applied to the database (committed) or whether the transaction has to
be aborted because it violates serializability
(see Section 20.5) or for some other reason.
■ COMMIT_TRANSACTION. This signals a successful end of the transaction so that any
changes (updates) executed by the transaction can be safely committed to the
database and will not be undone.
■ ROLLBACK (or ABORT). This signals that the transaction has ended unsuccessfully, so
that any changes or effects that the transaction may have applied to the database
must be undone.