1.Explain the characteristics of database Approach.

Ans: The main characteristics of the database approach

Self-describing nature of a database system

Insulation between programs and data, and data abstraction
Support of multiple views of the data
Sharing of data and multiuser transaction processing

1. Self–describing nature of a database system:

A key feature of the database approach is that it includes not
just the data but also detailed information about the data,
known as metadata. This metadata is stored in a system
catalog, which describes the structure of each file, the type and
format of each field, and the rules and constraints that the data
must follow.

2. Insulation between programs and data, and data abstraction:

-Program-Data Independence:
In traditional file systems, if you change the data structure, you
must update all related programs. In a DBMS, data structure
details are stored separately. Programs access this information from a catalog, so you can change
the data structure without altering the programs.
-Program-Operation Independence:
In object-oriented databases, you can define operations on data separately from their
implementation. Programs use these operations by name, without worrying about how they work.
You can change the implementation without affecting the programs.
-Data Abstraction:
Data abstraction allows for independence by providing a simplified view of the data. The DBMS
hides storage and implementation details, using a data model to represent data logically. This
makes it easier for users to understand and work with the data.

3. Support of multiple views of the data:

A database typically has many users, each of whom may require a different perspective or view of
the database. A view may be a subset of the database or it may contain virtual data that is derived
from the database files but is not explicitly stored. A multiuser DBMS whose users have various
applications must provide facilities for defining multiple views.

4. Sharing of data and multi users transaction processing:

A multiuser DBMS allows many users to access and update the database at the same time. This is important for
managing data for multiple applications in one place. The DBMS uses concurrency control to ensure that updates
from different users are handled correctly. For instance, if multiple agents try to assign the same seat on a flight,
the DBMS makes sure only one assignment happens at a time. These are called online transaction processing
(OLTP) applications.
A transaction is a series of database operations, like reading or updating records. The DBMS ensures:
- Isolation: Each transaction seems to run alone, even if many run together.
- Atomicity: All operations in a transaction are completed, or none are, keeping the database consistent.

2. Explain the advantages of DBMS Approach.

Ans: -Controlling Redundancy:

Data redundancy such as tends to occur in the "file processing" approach leads to wasted storage
space, duplication of effort and a higher likelihood of the introduction of inconsistency.
In the database approach, the views of different user groups are integrated during database
design. This is known as data normalization, and it ensures consistency and saves storage Space.
However, it is sometimes necessary to use controlled redundancy to improve the performance of
queries.
A DBMS should provide the capability to automatically enforce the rule that no inconsistencies are
introduced when data is updated.

-Restricting Unauthorized Access:

When multiple users share a large database, it is likely that most users will not be authorized to
access all information in the database. For example, financial data is often considered confidential
and only authorized persons are allowed to access such data. In addition, some users may only be
permitted to retrieve data, whereas others are allowed to retrieve and update. Hence, the type of
access operation retrieval or update must also be controlled. A DBMS should provide a security and
authorization subsystem, which the DBA uses to create accounts, to specify account restrictions
and enforce these restrictions automatically.

-Providing Persistent Storage for Program Objects:

The values of program variables or objects are discarded once a program terminates, unless the
programmer explicitly stores them in permanent files, which often involves converting these
complex structures into a format suitable for file storage. Object-oriented database systems make
it easier for complex runtime objects to be saved in secondary storage so as to survive beyond
program termination and to be retrievable at a later time.

-Providing Storage Structures and Search Techniques for Efficient Query Processing :
DBMS maintains indexes that are utilized to improve the execution time of queries and updates.
DBMS has a buffering or caching module that maintains parts of the database in main memory
buffers. The query processing and optimization module is responsible for choosing an efficient
query execution plan for each query submitted to the system.

-Providing Backup and Recovery :

The backup and recovery subsystem of the DBMS is responsible for recovery. For example, if the
computer system fails in the middle of a complex update transaction, the recovery subsystem is
responsible for making sure that the database is restored to the state it was in before the
transaction started executing. Disk backup is also necessary in case of a catastrophic disk failure.

-Providing Multiple User Interfaces :

Because many types of users with varying levels of technical knowledge use a database, a DBMS
should provide a variety of user interfaces. These include
*Query languages for casual users
*Programming language interfaces for application programmers
*Forms and command codes for parametric users
*Menu-driven interfaces and natural language interfaces for standalone users.

-Representing Complex Relationships among Data :

A database may include numerous varieties of data that are interrelated in many ways.
For example each section record is related to one course record and to a number of
GRADE_REPORT records one for each student who completed that section. A DBMS must have the
capability to represent a variety of complex relationships among the data, to define new
relationships as they arise, and to retrieve and update related data easily and efficiently.

-Enforcing Integrity Constraints :

Most database applications are such that the semantics of the data require that it satisfy certain
restrictions in order to make sense.
The simplest type of integrity constraint involves specifying a data type for each data item.
For example, in student table we specified that the value of Name must be a string of no more than
30 alphabetic characters.
More complex type of constraint is referential integrity involves specifying that a record in one file
must be related to records in other files.
Another type of constraint specifies uniqueness on data item values, such as every course record
must have a unique value for Course_number. This is known as a key or uniqueness constraint.
It is the responsibility of the database designers to identify integrity constraints during database
design.

-Permitting Inferencing and Actions Using Rules:

In a deductive database system, one may specify declarative rules that allow the database to infer
new data. For example, figure out which students are on academic probation. Such capabilities
would take the place of application programs that would be used to ascertain such information
otherwise.
Active database systems go one step further by allowing "active rules" that can be used to initiate
actions automatically.
-Additional Benefits of Using the Database Approach:
#Enforcing Standards: A DBA can set and enforce standards across users in a large organization,
improving communication and cooperation. Standards can include data names, formats, and report
structures.

#Reduced Development Time: Once a database is set up, creating new applications takes much
less time with a DBMS compared to traditional file systems, potentially one-sixth to one-fourth of
the time.
#Flexibility: DBMSs allow changes to the database structure without affecting the data or existing
applications.
# Up-to-date Information: DBMS ensures that the latest information is available to all users, which
is crucial for applications like reservation systems and banking.
#Economies of Scale: The DBMS approach consolidates data and applications, allowing the
organization to invest in more powerful shared resources, reducing overall costs.

3. Describe with a neat diagram of Three schema architecture.

Ans: The goal of the three-schema architecture is to separate the user applications from the
physical database. In this architecture, schemas can be defined at the following three levels:

1. The internal level has an internal schema, which describes the physical storage structure of the
database. The internal schema uses a physical data model and describes the complete details of
data storage and access paths for the database.

2. The conceptual level has a conceptual schema, which describes the structure of the whole
database for a community of users. The conceptual schema hides the details of physical storage
structures and concentrates on describing entities, data types, relationships, user operations, and
constraints. Usually, a representational data model is used to describe the conceptual schema
when a database system is implemented.

3. The external or view level includes a number of external schemas or user views. Each external
schema describes the part of the database that a particular user group is interested in and hides
the rest of the database from that user group. Each external schema is typically implemented using
a representational data model, possibly based on an external schema design in a high-level data
model.

In a DBMS based on the three-schema architecture, each user group refers to its own external
schema. Hence, the DBMS must transform a request specified on an external schema into a
request against the conceptual schema, and then into a request on the internal schema for
processing over the stored database. If the request is a database retrieval, the data extracted from
the stored database must be reformatted to match the user’s external view.
The processes of transforming requests and results between levels are called mappings.

4. Explain the following.

a. Entity and its types:

Ans: Entity: a thing in the real world with an independent existence. An entity may be an object
with a physical existence (for example, a particular person, car, house, or employee) or it may be
an object with a conceptual existence (for instance, a company, a job, or a university course).
Entity Types: An entity type defines a collection (or set) of entities that have the same attributes.
Each entity type in the database is described by its name and attributes. For example, a company
employing hundreds of employees may want to store similar information concerning each of the
employees. These employee entities share the same attributes, but each entity has its own
value(s) for each attribute.

b. Attribute and its types:

Ans: Attributes: Particular properties that describe entity. For example, an EMPLOYEE entity may
be described by the employee’s name, age ,address, salary and job.

Types of attributes:
1.Composite versus Simple (Atomic) Attribute
2.Single-valued versus multivalued
3.Stored versus derived
4.NULL values
5.Complex attributes

Types of Attributes in Databases:

-Composite vs. Simple (Atomic) Attributes:
- Composite Attributes: These can be divided into smaller parts with their own meanings. Example: Address can
be divided into Street_address, City, State, and Zip. Street_address can further be divided into Number, Street, and
Apartment_number.
- Simple (Atomic) Attributes: These cannot be divided further. Example: SSN of an employee.

-Single-Valued vs. Multivalued Attributes:

- Single-Valued Attributes: These have one value for each entity. Example: Age of a person.
- Multivalued Attributes: These can have multiple values for each entity. Example: Colors of a car, or
College_degrees of a person. There can be limits, like a car having up to three colors.

-Stored vs. Derived Attributes:

- Stored Attributes:These are directly stored in the database. Example: Birth_Date of an employee.
- Derived Attributes: These are calculated from stored attributes. Example: Age can be derived from Birth_Date.

-Null Value Attribute (Optional Attribute):

- Sometimes, an attribute may not have a value for an entity. Example: Apartment_number is NULL for a single-
family home. College_degrees is NULL for someone without a degree. NULL can also mean the value is
unknown.

-Complex Attributes:
- These combine composite and multivalued attributes. Example: A person can have multiple residences and
phones.

Addressphone {

phone {(Area Code, Phone Number)},

Address (Sector Address (Sector Number, House

Number), City, State, Pin)

c. Notations of ER diagram :
Ans:

5.Draw ER diagram for Company Database.

Ans:
6.Draw ER diagram for Banking System.

Ans:

Alternate Navathe/elsmari

8.Define the following in RDBMS.

1. Tuple : A tuple refers to a single row or record in a database table. It is an ordered set of values representing a
specific entity or object. Each attribute or column in a table corresponds to a value in the tuple.
 2. Domain: A domain D is a set of atomic values. By atomic we mean that each value in the domain is indivisible as far as
the formal relational model is concerned. A common method of specifying a domain is to specify a data type from which
the data values forming the domain are drawn. It is also useful to specify a name for the domain, to help in interpreting
its values.

3. Attributes: An attribute Ai is the name of a role played by some domain D in the relation schema
R. D is called the domain of Ai and is denoted by dom(Ai).

4. Relation Schema : A relation schema R, denoted by R(A1, A2, ...,An), is made up of a relation name
R and a list of attributes A1, A2, ...,An. Each attribute Ai is the name of a role played by some
domain D in the relation schema R. D is called the domain of Ai and is denoted by dom(Ai). A
relation schema is used to describe a relation; R is called the name of this relation.

9. Explain Relation Model Constraints.

Ans: Constraints are restrictions on the actual values in a database state. These constraints are
derived from the rules in the miniworld that the database represents. Constraints on databases can
generally be divided into three main categories:

1. Inherent model-based constraints or implicit constraints

Constraints that are inherent in the data model.
The characteristics of relations are the inherent constraints of the relational model and belong to
the first category. For example, the constraint that a relation cannot have duplicate tuples is an
inherent constraint.

2. Schema-based constraints or explicit constraints

Constraints that can be directly expressed in schemas of the data model, typically
by specifying them in the DDL.
The schema-based constraints include domain constraints, key constraints, constraints on NULLs,
entity integrity constraints, and referential integrity constraints.

3. Application-based or semantic constraints or business rules

Constraints that cannot be directly expressed in the schemas of the data model, and hence must
be expressed and enforced by the application programs.

#Domain Constraints:
- Each attribute must have an atomic value from its domain.
- Common data types include integers, floats, characters, Booleans, strings, dates, times, timestamps, and money.

#Key Constraints and NULL Constraints:

- All tuples in a relation must be distinct, meaning no duplicate rows.

- A superkey is a set of attributes where no two tuples can have the same values. Every relation has at least one
superkey, which is all its attributes combined.

-A key K of a relation schema R is a superkey of R with the additional property that removing any
attribute A from K leaves a set of attributes K that is not a superkey of R anymore. Hence, a key
satisfies two properties:
1. Two distinct tuples in any state of the relation cannot have identical values for (all) the attributes
in the key. This first property also applies to a superkey.
2. It is a minimal superkey that is, a superkey from which we cannot remove any attributes and still
have the uniqueness constraint in condition 1 hold.This property is not required by a superkey.

- A candidate key is any key in a relation that could serve as a unique identifier. For example, a CAR relation
might have License_number and Engine_serial_number as candidate keys.

- A primary key is a designated candidate key used to uniquely identify tuples. It's usually underlined. Other
candidate keys are called unique keys.
- Attributes can have constraints to disallow NULL values. For example, the Name attribute in STUDENT might
be constrained to be NOT NULL.

10. Explain the characteristics of Relation.

Ans:

#Ordering of Tuples in a Relation:

- A relation in database terms is a set of tuples (rows), where each tuple represents a
factual statement or entity.
- Tuples within a relation are considered unordered because, in set theory, elements of a
set have no inherent order.
- This means the database system does not guarantee the order in which tuples are
stored or retrieved unless explicitly specified using sorting operations.

#Ordering of Values within a Tuple and an Alternative Definition of a Relation:

- The order of attributes and their corresponding values within a tuple is not significant in
relational databases.
- What matters is that each attribute is correctly paired with its corresponding value,
maintaining the integrity and meaning of the data.
- An alternative conceptualization of a relation defines it as a set of mappings. Each tuple
maps attributes to their respective values, akin to a set of key-value pairs where the keys
are attributes and values are their corresponding data values.

#Values and NULLs in the Tuples:

- In database tuples, each value for an attribute is considered atomic, meaning it cannot
be divided further into smaller components.
- NULL values are used to represent missing or undefined data. They indicate that a
particular attribute value is not known or does not apply to the tuple.
- NULLs are essential in database modelling to handle situations where data might be
missing or not applicable without resorting to placeholder values that could potentially
mislead data interpretations.

#Interpretation (Meaning) of a Relation:

- A relation schema defines the structure or blueprint of the data stored in a relation.
- For example, a schema for a STUDENT relation might include attributes like Name, Ssn,
Home_phone, etc., which describe the characteristics of each student entity.
- Each tuple in the relation represents a specific instance or occurrence of these
attributes for a particular student.
- Alternatively, a relation schema can be interpreted as a predicate in logic, where each
tuple represents a set of attribute values that satisfy the conditions defined by the schema.

11. Explain the UPDATE operations in RDBMS.

Ans: The Update (or Modify) operation is used to change the values of one or more attributes in a
tuple (or tuples) of some relation R. It is necessary to specify a condition on the attributes of the
relation to select the tuple (or tuples) to be modified.
Examples:
1. Operation:
Update the salary of the EMPLOYEE tuple with Ssn = ‘999887777’ to 28000.
2. Operation: Update the Dno of the EMPLOYEE tuple with Ssn = ‘999887777’ to 7.
Result: Unacceptable, because it violates referential integrity.
3. Operation: Update the Ssn of the EMPLOYEE tuple with Ssn = ‘999887777’ to ‘987654321’.
Result: Unacceptable, because it violates primary key constraint by repeating a value that already
exists as a primary key in another tuple; it violates referential integrity constraints because there
are other relations that refer to the existing value of Ssn .
Updating an attribute that is neither part of a primary key nor of a foreign key usually causes no
problems; the DBMS need only check to confirm that the new value is of the correct data type and
domain.

12. Discuss the following.

a. Unary operations :

 Purpose of SELECT Operation:

 The SELECT operation in databases filters tuples (rows) from a relation based on a specified condition.
 It selectively retrieves only those tuples that satisfy the given condition, discarding others.

 Selection Condition:

 The selection condition is a Boolean expression defined on attributes of the relation R.

 It consists of clauses that compare attribute values either against constant values or against other attribute
values.
 Clauses can be combined using standard Boolean operators like AND, OR, and NOT.

In general, the select operation is denoted by σ <selection condition>(R)

where,
- the symbol is used to denote the select operator
- the selection condition is a Boolean (conditional) expression specified on the attributes of relation
R
- tuples that make the condition true are selected
*appear in the result of the operation
- tuples that make the condition false are filtered out
*discarded from the result of the operation

Example:

 Select the EMPLOYEE tuples whose department number is 4.

σ DNO = 4 (EMPLOYEE)

 Select the employee tuples whose salary is greater than $30,000.

σ SALARY > 30,000 (EMPLOYEE)

 Select the tuples for all employees who either work in department 4 and make over $25,000
per year, or work in department 5 and make over $30,000

σ (Dno=4 AND Salary>25000) OR (Dno=5 AND Salary>30000)(EMPLOYEE)

The result of a SELECT operation can be determined as follows:

*The <selection condition> is applied independently to each individual tuple t in R .
*If the condition evaluates to TRUE, then tuple t is selected. All the selected tuples appear in the
result of the SELECT operation
*The Boolean conditions AND, OR, and NOT have their normal interpretation, as follows:
- (cond1 AND cond2) is TRUE if both (cond1) and (cond2) are TRUE; otherwise,it is FALSE.
- (cond1 OR cond2) is TRUE if either (cond1) or (cond2) or both are TRUE; otherwise, it is FALSE.
- (NOT cond) is TRUE if cond is FALSE; otherwise, it is FALSE.
The SELECT operator is unary; that is, it is applied to a single relation. The degree of the relation
resulting from a SELECT operation is the same as the degree of R.The number of tuples in the
resulting relation is always less than or equal to the number of tuples in R.

The PROJECT Operation :

The PROJECT operation denoted by selects certain columns from the table and discards the other
columns Used when we are interested in only certain attributes of a relation. The result of the
PROJECT operation can be visualized as a vertical partition of the relation into two relations:
- one has the needed columns (attributes) and contains the result of the operation - the other
contains the discarded columns

The general form of the PROJECT operation is π <attribute list>(R)

where
- π(pi) - symbol used to represent the PROJECT operation,
<attributelist> - desired sublist of attributes from the attributes of relation R.
The result of the PROJECT operation has only the attributes specified in <attribute list> in the same
order as they appear in the list. Hence, its degree is equal to the number of attributes in <attribute
list>

Example : 1. To list the employee’s first and last name and salary we can use the PROJECT
operation as follows:

π Lname, Fname, Salary(EMPLOYEE)

If the attribute list includes only non-key attributes of R, duplicate tuples are likely to occur. The
result of the PROJECT operation is a set of distinct tuples, and hence a valid relation. This is known
as duplicate elimination. For example, consider the following PROJECT operation:

π gender, Salary(EMPLOYEE)

Lname Fname Salary

Smith John 30000
Wong Franklin 40000
Zelaya Alicia 25000
Wallace Jennifer 43000
Narayan Ramesh 38000
English Joyce 25000
Jabbar Ahmad 25000
Borg James 55000

The tuple <’F’,25000> appears only once in the resulting relation even though this combination of
values appears twice in the EMPLOYEE relation.

The number of tuples in a relation resulting from a PROJECT operation is always less than or equal
to the number of tuples in R. Commutativity does not hold on PROJECT

π <list1> <list2>(R <list1>(R)

as long as <list2> contains the attributes in <list1>; otherwise, the left-hand side is an incorrect
expression.
In SQL, the PROJECT attribute list is specified in the SELECT clause of a query. For example, the
following operation:

π gender, Salary(EMPLOYEE)

would correspond to the following SQL query:

SELECT DISTINCT gender, Salary FROM EMPLOYEE
b. Binary operations :

Ans:

#The JOIN operation, denoted by ⋈ , is used to combine related tuples from two relations into
single “longer” tuples. It allows us to process relationships among relations. The general form of a
JOIN operation on two relations R(A1, A2, ..., An) and S(B1, B2, ..., Bm) is R <join condition>S

Example: Retrieve the name of the manager of each department.

To get the manager’s name, we need to combine each department tuple with the employee tuple
whose Ssn value matches the Mgr_ssn value in the department tuple

DEPT_MGR <- DEPARTMENT ⋈ Mgr_ssn=Ssn EMPLOYEE

RESULT <- πDname,Lname,Fname(DEPT_MGR)

Dname Dnumber Mgr_ssn … Fname Minit Lname Ssn …

Research 5 333445555 … Franklin T Wong 333445555 …
Administration 4 987654321 … Jennifer S Wallace 987654321 …
Headquarters 1 888665555 … James E Borg 888665555 …

The result of the JOIN is a relation Q with n + m attributes Q(A 1, A2, ..., An,B1, B2, ..., Bm in that
order.Q has one tuple for each combination of tuples one from R and one from S whenever the
combination satisfies the join condition. This is the main difference between CARTESIAN PRODUCT
and JOIN. In JOIN, only combinations of tuples satisfying the join condition appear in the result,
whereas in the CARTESIAN PRODUCT all combinations of tuples are included in the result. The join
condition is specified on attributes from the two relations R and S and is evaluated for each
combination of tuples.

There are two variations of JOIN:

-EQUIJOIN
-NATURAL JOIN

#The DIVISION Operation :

The DIVISION operation, denoted by ÷, is useful for a special kind of query that sometimes occurs
in database applications. An example is to Retrieve the names of employees who work on all the
projects that ‘John Smith’ works on. To express this query using the DIVISION operation, and
proceed as follows.

-First retrieve the list of project numbers that ‘John Smith’ works in the intermediate
relation SMITH_PHNOS:

SSN_PHNOS <- πEssn,Pno(WORKS_ON)

-Next, create a relation that includes a tuple <Pno, Essn> whenever the employee whose Ssn is
Essn works on the project whose number is Pno in the intermediate relation SSN_PNOS:

SMITH_PNOS <- πPno(WORKS_ON ⋈ Essn=Ssn SMITH)

SMITH <- σFname-‘John’ AND Lname=’Smith’(EMPLOYEE)

Finally, apply the DIVISION operation to the two relations, which gives the desired employees social
security numbers;

SSNS(Ssn) <- SSN_PNOS ÷ SMITH_PNOS

RESULT <- πFname,Lname(SSNS*EMPLOYEE)
13. Explain DDL statements.

Ans: