Module 1

CHAPTER 1
Introduction to Databases
A database is a collection of related data.

A data mean known facts that can be recorded and that have implicit meaning.

For eg, consider the names, telephone numbers, and addresses of the people you know. You may
have recorded this data in an indexed address book or you may have stored it on a hard drive, using
a personal computer and software such as Microsoft Access or Excel. This collection of related data
with an implicit meaning is a database.

A database has the following implicit properties:

 A database represents some aspect of the real world, sometimes called the miniworld or
the Universe of Discourse(UoD). Changes to the miniworldare reflected in the database.
 A database is a logically coherent collection of data with some inherent meaning. A
random assortment of data cannot correctly be referred to as a database.
 A database is designed, built, and populated with data for a specific purpose. It has an
intended group of users and some preconceived applications in which these users are
interested.
Other properties:
 A database can be of any size and complexity. For example, the list of names and
addresses referred to earlier may consist of only a few hundred records, each with a
simple structure.An example of a large commercial database is Amazon.com.
 A database may be generated and maintained manually or it may be computerized. For
example, a library card catalog is a database that may be created and maintained
manually. A computerized database may be created and maintained either by a group of
application programs written specifically for that task or by a database management
system.

A Database Management System (DBMS) is a collection of programs that enables users to create
and maintain a database.
The DBMS is a generalpurpose software system that facilitates the processes of defining,
constructing, manipulating, and sharing databases among various users and applications.
 Defining a database involves specifying the data types, structures, and constraints of the
data to be stored in the database. The database definition or descriptive information is
also stored by the DBMS in the form of a database catalog or dictionary; it is called
metadata.
 Constructing the database is the process of storing the data on some storage medium
that is controlled by the DBMS.
 Manipulating a database includes functions such as querying the database to retrieve
specific data, updating the database to reflect changes in the miniworld, and generating
reports from the data.
 Sharing a database allows multiple users and programs to access the database
simultaneously
 An application program accesses the database by sending queries or requests for data
to the DBMS.

A Query typically causes some data to be retrieved; a transaction may cause some data to be read
and some data to be written into the database.
Characteristics of the Database Approach:

The main characteristics of the database approach versus the file processing approach are the
following:
 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

Here’s a concise explanation of the key characteristics of a database system:

 Self Describing Nature of a Database System
 Metadata: Stores data about data (e.g., schema, data types) within the
database, making the system self describing and flexible.

 Insulation Between Programs and Data, and Data Abstraction

 Data Independence: Changes in data structure do not affect application
programs.
 Logical Independence: Changing the logical schema doesn't affect
applications.
 Physical Independence: Changing physical storage doesn't affect the logical
schema.
 Data Abstraction: Simplifies complex data by providing different levels of
abstraction (physical, logical, view).

 Support of Multiple Views of the Data

 Views: Customized presentations of data for different users, improving
accessibility and security by restricting access to specific data.

 Sharing of Data and MultiUser Transaction Processing

 Data Sharing: Multiple users can access and modify data concurrently.
 Concurrency Control: Manages simultaneous operations to ensure data
consistency.
 Transaction Processing: Supports reliable multiuser transactions adhering to
ACID properties (Atomicity, Consistency, Isolation, Durability).
These characteristics ensure efficient, secure, and flexible data management.

Actors on the Scene

 Database Administrators
 In a database environment, the primary resource is the database itself, and the
secondary resource is the DBMS and related software.
 Administering these resources is the responsibility of the database administrator
(DBA).
 The DBA is responsible for authorizing access to the database, coordinating and
monitoring its use, and acquiring software and hardware resources as needed.
 The DBA is accountable for problems such as security breaches and poor system
response time. In large organizations, the DBA is assisted by a staff that carries out
these functions.
 Database Designers
 Database designers are responsible for identifying the data to be stored in the
database and for choosing appropriate structures to represent and store this data.
 It is the responsibility of database designers to communicate with all prospective
database users in order to understand their requirements and to create a design that
meets these requirements.
  Database designers typically interact with each potential group of users and develop
views of the database that meet the data and processing requirements of these groups.
Each view is then analyzed and integrated with the views of other user groups. The
final database design must be capable of supporting the requirements of all user
groups.
 End Users
End users are the people whose jobs require access to the database for querying,
updating, and generating report.
There are several categories of end users:
 Casual end users occasionally access the database, but they may need different
information each time. They use a sophisticated database query language to
specify their requests and are typically middle or highlevel managers or other
occasional browsers.
 Naive or parametric end users make up a sizable portion of database end users.
Their main job function revolves around constantly querying and updating the
database, using standard types of queries and updates—called canned
transactions—that have been carefully programmed and tested.
The tasks that such users perform are varied:
 Bank tellers check account balances and post withdrawals and deposits.
 Reservation agents for airlines, hotels, and car rental companies check
availability for a given request and make reservations.
 shipping clerks (e.g., at UPS) who use buttons, bar code scanners, etc., to
update status of in transit packages.
 Sophisticated end users include engineers, scientists, business analysts, and
others who thoroughly familiarize themselves with the facilities of the DBMS in
order to implement their own applications to meet their complex requirements.
 Standalone users Use "personal" databases, possibly employing a special
purpose (e.g., financial) software package.
 Mostly maintain personal databases using readytouse packaged
applications.
 An example is a tax program user that creates its own internal database.
 System Analysts, Application Programmers, Software Engineers:
 System Analysts: determine needs of end users, especially naive and parametric
users, and develop specifications for canned transactions that meet these needs.
 Application Programmers: Implement, test, document, and maintain programs that
satisfy the specifications mentioned above.

Workers behind the Scene

Persons are typically not interested in the database content itself known as workers behind the
scene, and they include the following categories:
 DBMS system designers and implementers design and implement the DBMS modules
and interfaces as a software package.
 Tool developers design and implement tools—the software packages that facilitate
database modeling and design, database system design, and improved performance.They
include packages for database design, performance monitoring, natural language or
graphical interfaces, prototyping, simulation, and test data generation.
 Operators and maintenance personnel (system administration personnel) are
responsible for the actual running and maintenance of the hardware and software
environment for the database system.

Advantages of Using the DBMS Approach

1. Controlling Redundancy: Reducing data duplication to save storage space and
maintain consistency by organizing data efficiently.
 2. Restricting Unauthorized Access: Implementing security measures such as user
authentication and access controls to ensure only authorized users can access or modify
data.
3. Providing Persistent Storage for Program Objects: Ensuring that data and objects
used by programs are stored permanently, even after the program has finished executing.
4. Providing Storage Structures and Search Techniques for Efficient Query
Processing: Utilizing indexes, hashing, and other data structures to optimize the speed
and efficiency of data retrieval operations.
5. Providing Backup and Recovery: Regularly saving data copies and providing
mechanisms to restore data in case of system failures or data corruption.
6. Providing Multiple User Interfaces: Offering various ways for users to interact with
the database, such as graphical interfaces, commandline interfaces, and webbased
interfaces.
7. Representing Complex Relationships Among Data: Supporting advanced data models
and relationships (e.g., onetomany, manytomany) to accurately reflect realworld
complexities.
8. Enforcing Integrity Constraints: Applying rules (e.g., primary keys, foreign keys,
unique constraints) to ensure data accuracy and validity.
9. Permitting Inferencing and Actions Via Rules: Allowing the database to perform
logical deductions and automated actions based on predefined rules (e.g., triggers, stored
procedures).

A Simplified Database System Environment

A simplified database system environment includes several key components:

1. Application Program: Interfaces with users, sending queries to the database and
displaying results.
2. Query Processor: Interprets and executes highlevel queries, optimizing them and
generating execution plans.
 3. Database Engine: Manages the storage, retrieval, and update of data, ensuring data
integrity and consistency.
4. Metadata: Data about the data's structure and constraints, helping the system understand
and optimize data access.
5. Stored Database: The actual repository where user data is kept, accessed and
manipulated by the database engine.

Interactions
The application program sends queries to the query processor.
The query processor translates these queries and instructs the database engine.
The database engine accesses the stored database and consults metadata.
Results are sent back through the chain to the application program and presented to the user.
This structure ensures efficient data management and retrieval.

A Brief History of Database Applications

 Early Database Applications
 1960s70s: Introduction and dominance of Hierarchical and Network Models.
 Current: Significant database processing still uses these models.

 Relational Model
 1970: Introduction of the relational model by IBM and universities.
 1980s: Emergence of commercial relational DBMS products.

 ObjectOriented and Emerging Applications

 Late 1980s90s: Introduction of ObjectOriented Database Management Systems
(OODBMSs) for complex data processing in CAD and similar applications, but
limited adoption.
 ObjectRelational DBMSs (ORDBMSs): Integration of object database concepts into
relational DBMSs, adding support for multimedia, XML, etc.

 Web Data and Ecommerce

 Web Data: HTML with links among pages.
 Ecommerce: Use of XML and dynamic web page generation via scripting languages
like PHP and JavaScript.

 New DBMS Functionality

 Scientific Applications
 XML Data Management
 Image, Audio, and Video Data Management
 Data Warehousing and Data Mining
 Spatial Data Management
 Time Series and Historical Data Management

These advancements lead to new research and development in incorporating diverse data
types, complex structures, new operations, and storage/indexing schemes, including database
updates through web pages.

When Not to Use a DBMS

1. Main Inhibitors (Costs)
 High Initial Investment: Significant cost and possible need for extra hardware.
 Overhead: Generality, security, concurrency control, recovery, and integrity
functions add overhead.
2. When a DBMS May Be Unnecessary
 Simple, WellDefined Database: Applications that are simple and unlikely to change.
 RealTime Requirements: Stringent realtime needs that DBMS overhead can't meet.
 SingleUser Access: No need for multiuser data access.

3. When No DBMS May Suffice

 Complex Data: DBMS can't handle complex data due to modeling limitations.
 Special Operations: Users require operations not supported by the DBMS.Structural
constraints in Database Management Systems (DBMS)
 CHAPTER 2
Overview of Database Languages and Architectures
Data Models in Databases
A data model describes the structure of a database, including data types, relationships, and
constraints, and provides operations for data retrieval and updates.

Categories of Data Models

1. High Level (Conceptual) Data Models

 Close to user perception of data.
 Use entities, attributes, and relationships.
 Entity: Real world object (e.g., employee, project).
 Attribute: Property of an entity (e.g., employee’s name, salary).
 Relationship: Association between entities (e.g., employee works on a project).

2. Low Level (Physical) Data Models

 Describe how data is stored on computer media (e.g., magnetic disks).
 Intended for computer specialists, not end users.

3. Representational (Implementation) Data Models

 Easily understood by end users, close to physical storage.
 Intermediate between high level and low level.
 Hide storage details but can be directly implemented.

Schemas and Database States

Schema diagram for the College database

 Database Schema: The fixed description of a database, specified during design,

includes constructs like STUDENT or COURSE.
 Schema Construct: An object within the schema, such as STUDENT or COURSE.
 Schema Diagram: A partial display of a schema, showing names of record types, data
items, and some constraints.
 Database State (Snapshot): The actual data in the database at a specific moment,
reflecting changes like new students or grades. Each schema construct (e.g., STUDENT)
has a current set of instances in this state.
 Defining a Database: Specify the database schema to the DBMS, starting with an empty
state.
  Initial State: Achieved when the database is first populated with data.
 Database State: Updated with each database operation, representing the current data at
any point in time.
 DBMS Role: Ensures each database state is valid, adhering to schema structure and
constraints.
 Metadata: Schema constructs and constraints stored in the DBMS catalog.

The Three Schema Architecture

Database Schema Levels

1. Internal Level
 Internal Schema: Describes the physical storage structure of the database.
 Uses a physical data model to detail data storage and access paths.

2. Conceptual Level
 Conceptual Schema: Describes the structure of the entire database for a community
of users.
 Hides physical storage details, focusing on entities, data types, relationships, user
operations, and constraints.
 Uses a representational data model for implementation, often based on a highlevel
data model design.

3. External or View Level

 External Schemas/User Views: Describe specific parts of the database relevant to
particular user groups, hiding the rest.
 Implemented using a representational data model, possibly based on a highlevel data
model design.
DBMS Languages
1. Data Manipulation Language (DML)
 Operations: Retrieval, insertion, deletion, and modification of data.
 Commands: INSERT, UPDATE, DELETE.

2. Data Query Language (DQL)

 Purpose: Retrieve data from the database.
 Command: SELECT.

3. Data Definition Language (DDL)

 Purpose: Define database schemas, used by DBAs and designers.
 Commands: CREATE, DROP, ALTER, RENAME, TRUNCATE.

4. Storage Definition Language (SDL)

 Purpose: Specify the internal schema.

5. View Definition Language (VDL)

 Purpose: Specify user views and their mappings to the conceptual schema.

6. Data Control Language (DCL)

 Purpose: Grant and revoke permissions.
 Commands: GRANT, REVOKE.

DBMS Interfaces
1. Menu ased Interfaces for Web Clients or Browsing
 Presents lists of options (menus) to guide users through request formulation.

2. Forms Based Interfaces

 Displays forms for users to insert new data or retrieve matching data by filling out
specific entries.

3. Graphical User Interfaces (GUIs)

 Displays schema diagrams for users to manipulate and specify queries.
 Combines menus and forms, typically using a pointing device.

4. Natural Language Interfaces

 Accepts requests in natural language (e.g., English) and attempts to understand and
process them.

5. Speech Input and Output

 Uses speech for input queries and outputs responses verbally.
 Relies on predefined word libraries to set query parameters.

6. Interfaces for Parametric Users

 Designed for users with repetitive tasks (e.g., bank tellers) providing a small set of
frequently used operations.

7. Interfaces for the DBA

 Provides privileged commands for database administration tasks such as creating
accounts, setting parameters, granting authorizations, modifying schemas, and
reorganizing storage structures.

Database System Environment

Top Half:
 User Interfaces
 DBA Staff: Define and tune database using DDL.
 Casual Users: Interact through interactive query interface.
 Application Programmers: Write programs in host languages (e.g., Java) submitted to
precompiler.
 User Interfaces
 DBA Staff: Define and tune database using DDL commands.
 Casual Users: Interact through interactive query interface.
 DBA Staff Responsibilities
 DDL Compiler: Processes schema definitions, stores metadata in DBMS catalog.
 Catalog: Stores file details, data item names/types, schema mapping, constraints.
 Casual User Interactions
 Interactive Query Interface: Parses and validates queries, performs optimization.
 Query Optimization: Rearranges operations, eliminates redundancies, consults
system catalog for data statistics.

 Application Programmers Workflow

 Write programs in host languages, precompiler extracts DML commands.
 DML commands compiled, rest of program sent to host language compiler.
 Linked object codes form canned transactions.
Lower Half: DBMS Internals
 Runtime Database Processor: Executes privileged commands, query plans, canned
transactions with run time parameters.
 Works with system catalog, may update with statistics.
 Manages data transfer, buffers, concurrency control, backup, and recovery systems using
OS services.
 Module 2

CHAPTER 1
Conceptual Data Modelling using Entities and Relationships

Entity Types, Entity Sets

In a database management system (DBMS), entity types and entity sets are fundamental concepts in
the entity relationship model, used to organize and represent data.

Entity Type:
 An entity type represents a collection of similar entities, having the same properties or
attributes.
 It describes a category of objects or entities within the database schema.
 For example, in a university database, "Student" and "Professor" could be entity types.

Entity Set:
 An entity set is a collection of all entities of a particular entity type at a given point in
time.
 It is the actual instance or occurrence of an entity type.
 Each entity in an entity set has a unique identifier (primary key) that distinguishes it
from other entities in the same set.
 For instance, the set of all enrolled students in a semester forms the "Student" entity set
in the university database.

Structural constraints / Relational Model Constraints in Database Management

Systems (DBMS)

Structural constraints in Database Management Systems (DBMS) are rules that define certain
conditions on the structure of a database schema to ensure data integrity and consistency. These
constraints are enforced by the DBMS and are critical in designing a robust database. Here are the
key types of structural constraints in DBMS:
1. Domain Constraints:
 Definition: These constraints restrict the values that can be stored in a column based
on the data type and, optionally, a set of permissible values.
 Example: If a column is defined to store integers, inserting a string would violate a
domain constraint.
2. Entity Integrity Constraints:
  Definition: These constraints ensure that each entity (row) in a table is uniquely
identifiable. This is typically enforced through primary keys.
 Example: A primary key column cannot have null values and must have unique
values across all rows in the table.
3. Referential Integrity Constraints:
 Definition: These constraints ensure that a foreign key value always points to an
existing row in another table, maintaining consistency across related tables.
 Example: If a table `Orders` has a foreign key `CustomerID` referencing the
`Customers` table, an order cannot be added with a `CustomerID` that does not exist
in the `Customers` table.
4. Unique Constraints:
 Definition: These constraints ensure that all values in a column or a set of columns
are unique across the table, excluding duplicates.
 Example: An email address column in a users table must have unique values for
each user.
5. Not Null Constraints:
 Definition: These constraints ensure that a column cannot have null values, requiring
a valid data entry in every row.
 Example: A column `birthdate` in a `Persons` table cannot be null, ensuring every
person has a birthdate recorded.
6. Check Constraints:
 Definition: These constraints allow the definition of a condition that each row must
satisfy. They are used to enforce specific rules on data.
 Example: A column `salary` in an `Employees` table must have values greater than
zero.
7. Default Constraints:
 Definition: These constraints provide default values for a column when no value is
specified during insertion.
 Example: A `status` column in an `Orders` table may have a default value of
'pending'.
8. Foreign Key Constraints:
 Definition: These constraints establish a link between two tables, enforcing a
relationship between columns in different tables.
 Example: A `department_id` in an `Employees` table must match a valid `id` in the
`Departments` table.
9. Tuple Uniqueness Constraints:
 Definition: These constraints ensure that no two rows in a table can have identical
values in certain specified columns.
 Example: A combination of `first_name` and `last_name` in a table may be required
to be unique to avoid duplication of names.
10. Key Constraints:
 Definition: These constraints involve the designation of primary keys and candidate
keys that uniquely identify rows within a table.
 Example: A `student_id` column in a `Students` table is the primary key ensuring
each student has a unique identifier.
Each of these constraints plays a crucial role in maintaining data integrity and consistency in
a relational database. By enforcing these rules, DBMS systems help prevent data anomalies
and ensure reliable database operations.

Notations of ER Diagram
Relationship in DBMS
What is a Relationship In Database?
A relationship in a DBMS exists when the variable has a connection with the properties stored in
different tables. Such relationships help the organization of entities intertwined with each other,
ultimately enabling efficient data processing. They’re exhibited usually via keys in a table, which is
either columns or fields that specify a distinctive arrangement for each record.

As another example, one can think of the university database. Students, courses, and instructors,
variably, might become tables. The relationship between the two tables is that courses indicate
which courses the student can enroll in. Database management facilitates the reliable data
apostrophe and performance of complex operations due to the fact that it guarantees the quality and
identity of the data.

Why are Relationships Important in a Database?

Relationships are crucial in a database for several reasons:
 Data Integrity: The relationships make the necessary links between data sets and ensure
that information kept and joined together is accurate. In this way, the consistency and
correctness of the data are maintained.
 Efficient Data Retrieval: The relationship permits the complete search of data among
multiple tables, storing fewer inputs and executing the query quickly, respectively.
 Normalization: Relations remain priorities that ensure the sync of data and achieving a
level of relevance.
 Complex Data Analysis: Relationships empower users for state-of-the-art querying,
aggregation, and analysis; thereby, users would be deriving meaningful insights from
their data.
 Scalability: It has turned out that well-defined relationships, in their turn, are the key
issue that helps the database to be scalable, thus having a structure that is easy to manage
and could be further adapted to possible expanding business needs.
Types of Relationships in a Database

1. One-to-One (1:1) Relationship

 Definition: A relationship where each record in one table corresponds to a single
record in another table.
 Usage: Less common, used for normalization or security purposes.
 Example:
 A human resources database where each employee's personal details are stored
in a separate "personal details" table.
 Each employee has one set of personal details, and those details are unique to
that employee.
2. One-to-Many (1:N) Relationship
 Definition: A relationship where a record in one table can be associated with
multiple records in another table.
 Usage: Commonly used to describe hierarchical data or parentchild relationships.
 Example:
 An online store database where each customer can place multiple orders.
 A single customer record in the "customers" table can be linked to multiple
records in the "orders" table.
3. Many-to-Many (N:M) Relationship
 Definition: A relationship where multiple records in one table can be associated with
multiple records in another table.
 Usage: Complex relationships managed through a junction table that links the two
tables.
 Example:
 A music streaming service database where each track can appear in multiple
playlists, and each playlist can contain multiple tracks.
 A junction table is used to manage the relationships between tracks and playlists.

Generalization

 Generalization is the process of extracting common properties from a set of entities and
creating a generalized entity from it. It is a bottomup approach in which two or more
entities can be generalized to a higherlevel entity if they have some attributes in common.
 For Example, STUDENT and FACULTY can be generalized to a higherlevel entity
called PERSON as shown in below Figure.
 In this case, common attributes like P_NAME, and P_ADD become part of a higher
entity (PERSON), and specialized attributes like S_FEE become part of a specialized
entity (STUDENT).
 Generalization is also called as ‘ Bottomup approach”.
Specialization

 In specialization, an entity is divided into subentities based on its characteristics. It is a

topdown approach where the higherlevel entity is specialized into two or more
lowerlevel entities.
 For Example, an EMPLOYEE entity in an Employee management system can be
specialized into DEVELOPER, TESTER, etc. as shown in Figure.
 In this case, common attributes like E_NAME, E_SAL, etc. become part of a higher
entity (EMPLOYEE), and specialized attributes like TES_TYPE become part of a
specialized entity (TESTER).
 Specialization is also called as ” TopDown approch”.
 Module 2
CHAPTER 1
Conceptual Data Modelling using Entities and Relationships

Relational Model Concepts

The relational model is a foundational concept in database management, representing data in a structured
format using relations (tables). Here are the key concepts of the relational model:

1. Relation:
 A relation is essentially a table with rows and columns.
 Each relation is made up of tuples (rows) and attributes (columns).

2. Attributes:
 Attributes are the columns of a relation.
 Each attribute has a specific domain, which defines the type of values it can hold.
 Attribute names must be unique within a relation.

3. Tuples:
 Tuples are the rows in a relation.
 Each tuple represents a single record and contains values for each attribute.
 Tuples in a relation are unique; no two tuples can be identical.

4. Domains:
 A domain is the set of permissible values for a given attribute.
 For example, the domain for an attribute "Age" might be the set of all non negative integers.

5. Relation Schema:
 The schema of a relation defines its structure, including the relation's name, its attributes, and the
domains of these attributes.
 A relation schema is typically represented as `R(A1, A2, ..., An)`, where `R` is the relation name
and `A1, A2, ..., An` are the attributes.

6. Relation Instance:
 A relation instance is a specific set of tuples that conforms to the schema at a particular moment
in time.
 The instance is a snapshot of the data in the relation at a given point.

Relational Model Constraints

1. Domain Constraints:
 Definition: These constraints restrict the values that can be stored in a column based
on the data type and, optionally, a set of permissible values.
 Example: If a column is defined to store integers, inserting a string would violate a
domain constraint.
2. Entity Integrity Constraints:
 Definition: These constraints ensure that each entity (row) in a table is uniquely
identifiable. This is typically enforced through primary keys.
 Example: A primary key column cannot have null values and must have unique
values across all rows in the table.
3. Referential Integrity Constraints:
 Definition: These constraints ensure that a foreign key value always points to an
existing row in another table, maintaining consistency across related tables.
  Example: If a table `Orders` has a foreign key `CustomerID` referencing the
`Customers` table, an order cannot be added with a `CustomerID` that does not exist
in the `Customers` table.
4. Unique Constraints:
 Definition: These constraints ensure that all values in a column or a set of columns
are unique across the table, excluding duplicates.
 Example: An email address column in a users table must have unique values for
each user.
5. Not Null Constraints:
 Definition: These constraints ensure that a column cannot have null values, requiring
a valid data entry in every row.
 Example: A column `birthdate` in a `Persons` table cannot be null, ensuring every
person has a birthdate recorded.
6. Check Constraints:
 Definition: These constraints allow the definition of a condition that each row must
satisfy. They are used to enforce specific rules on data.
 Example: A column `salary` in an `Employees` table must have values greater than
zero.

Characteristics of Relations
 Ordering of Tuples in a Relation
 Ordering of Values within a Tuple
 Values and NULLs in the Tuples
 Interpretation (Meaning) of a Relation

1. Ordering of Tuples in a Relation:

 In a relation, tuples (rows) are considered to be unordered. This means that there is
no inherent order in which tuples are stored or retrieved from the relation.
 The DBMS is responsible for managing the physical storage of tuples, and the order
in which tuples are returned in a query result may not necessarily reflect the order in
which they were inserted.

2. Ordering of Values within a Tuple:

 Similarly, the values within a tuple (attributes or columns) are also considered to be
unordered.
 The DBMS treats each attribute as independent of others, and there is no inherent
sequence in which attributes are stored or accessed within a tuple.

3. Values and NULLs in the Tuples:

 Tuples in a relation can contain values for each attribute or can have NULL values,
which represent missing or unknown information.
 NULL is a special marker used in databases to indicate the absence of a value.
 Each attribute in a tuple can either contain a value or a NULL, depending on
whether the information is available.

4. Interpretation (Meaning) of a Relation:

 A relation represents a mathematical concept of a table, where each tuple represents
a row and each attribute represents a column.
 In a database context, a relation typically represents a table, and each tuple
corresponds to a record or instance of that table.
 The meaning of a relation is defined by its attributes and the relationships between
them, which are specified by the schema or structure of the database.

Update Operations in DBMS

Update operations in a DBMS are used to modify existing records in a table. Here are the main
update operations with suitable commands as examples:

1. UPDATE Operation
 The `UPDATE` statement is used to modify existing records in a table.
Syntax:sql
UPDATE table_name
SET column1 = value1, column2 = value2, ...
WHERE condition;

 Example:
sql
UPDATE employees
SET salary = 5000
WHERE employee_id = 101;

 This command updates the `salary` of the employee with `employee_id` 101 to 5000.

2. INSERT Operation
 The `INSERT` statement is used to add new records to a table.
Syntax: sql
INSERT INTO table_name (column1, column2, ...)
VALUES (value1, value2, ...);

 Example:
sql
INSERT INTO employees (employee_id, first_name, last_name, salary)
VALUES (102, 'John', 'Doe', 4500);

 This command inserts a new record into the `employees` table with specified values.

3. DELETE Operation
 The `DELETE` statement is used to remove existing records from a table.
Syntax:sql
DELETE FROM table_name
WHERE condition;

 Example:
sql
DELETE FROM employees
WHERE employee_id = 103;

 This command deletes the record of the employee with `employee_id` 103 from the
`employees` table.

4. ALTER Operation
 The `ALTER` statement is used to modify the structure of an existing table.

 Syntax:
sql
ALTER TABLE table_name
ADD column_name datatype;
  Example:
sql
ALTER TABLE employees
ADD date_of_birth DATE;

 This command adds a new column `date_of_birth` of type `DATE` to the

`employees` table.

Transaction in DBMS
A transaction in a Database Management System (DBMS) is a sequence of one or more SQL
operations that are executed as a single unit of work. Transactions ensure that a series of operations
are performed completely and correctly, maintaining the integrity of the database. Transactions are
crucial for maintaining consistency, especially in systems where multiple operations must be
executed in sequence without interruption.

Key Properties of Transactions (ACID Properties)

1. Atomicity: Ensures that all operations within a transaction are completed successfully. If
any operation fails, the entire transaction is rolled back.
2. Consistency: Ensures that a transaction brings the database from one valid state to
another valid state, maintaining all predefined rules, such as constraints.
3. Isolation: Ensures that operations in a transaction are isolated from those in other
transactions. Intermediate transaction results are not visible to other transactions until the
transaction is committed.
4. Durability: Ensures that once a transaction is committed, its changes are permanent and
will survive system failures.

Transaction Commands

1. BEGIN TRANSACTION: Marks the beginning of a transaction.

 Eg:- START TRANSACTION;
-- or
BEGIN;
2. COMMIT: Saves all changes made by the transaction to the database.
3. ROLLBACK: Undoes all changes made by the transaction.
4. SAVEPOINT
 Sets a savepoint within a transaction. You can roll back to this savepoint without
affecting the entire transaction.
Example:
SAVEPOINT savepoint_name;

Example of a Transaction
 Consider a banking system where we need to transfer money from one account to
another.
 This operation requires multiple steps:
 Deduct money from the sender's account.
 Add money to the receiver's account.
 These operations must be executed as a single transaction to ensure consistency.
The COMPANY database keeps track of a company's employees, departments, and projects.
 The company is organized into departments. Each department has a unique name, a
unique number, and a particular employee who manages the department. We keep track
of the start date when that employee began managing the department. A department may
have several locations.
 A department controls a number of projects, each of which has a unique name, a unique
number, and a single location.
 The database will store each employee's name, Social Security number, address, salary,
sex (gender), and birth date. An employee is assigned to one department, but may work
on several projects, which are not necessarily controlled by the same department. It is
required to keep track of the current number of hours per week that an employee works
on each project, as well as the direct supervisor of each employee (who is another
employee).
 The database will keep track of the dependents of each employee for insurance purposes,
including each dependent's first name, sex, birth date, and relationship to the employee.
Outline an ER diagram for the above given scenario.