1.

Instance

 Definition: An instance refers to the actual data stored in the database at a specific
moment in time. It represents the current state of the database, including all the
records, rows, and values in the tables.

 Key Points:

o An instance is dynamic and changes over time as data is inserted, updated, or

deleted.

o It is a snapshot of the database at a particular point in time.

o The schema (structure) remains the same, but the data within it (the instance)
can change.

 Example:

o Consider a Student table with the following schema:

At a given time, the instance of the Student table might look like this:

 If a new student is added, the instance changes, but the schema remains the same.

2. Data Independence

 Data independence refers to the ability to modify the schema at one level of the
database system without affecting the schema at the next higher level. It ensures that
changes in the database structure do not impact the applications or users accessing the
data.

o Example:
 Adding a new column to a table.
 Splitting a table into two tables.
 These changes do not require rewriting the views or
queries used by applications.
Example of Data Independence

 Scenario:

o A Student table has the following schema:

 An application uses this table to display student names and DOBs.

o A new column, Email, is added to the Student table.

o The application continues to work without any changes because
it does not use the new column.

Three-Tier Schema Architecture

The Three-Tier Schema Architecture in DBMS is a framework that helps achieve data
independence, meaning changes in one level of the database do not affect the other levels. This
architecture separates the database into three layers:

1. External Level (View Level)

2. Conceptual Level (Logical Level)

3. Internal Level (Physical Level)

1. External Level (View Level)
 This is the top layer where users interact with the database.

 It provides a customized view of the database for different users or applications.

 Each user sees only the data they need, and irrelevant data is hidden.

Example:
Imagine a school database.

 A student logs in and sees only their grades, attendance, and personal details.

 A teacher sees the list of students, their grades, and course details.

 The admin sees everything, including financial data and staff details.

2. Conceptual Level (Logical Level)

 This is the middle layer that defines the overall structure of the database.

 It describes what data is stored, how it is related, and the constraints (rules) applied to
the data.

 It acts as a bridge between the external and internal levels.

Example:
In the school database, the conceptual level defines:

 Tables like Students, Teachers, Courses, and Grades.

 Relationships like "a student enrolls in a course" or "a teacher teaches a course."

 Rules like "a student cannot have more than 5 courses."

3. Internal Level (Physical Level)

 This is the bottom layer that deals with how the data is physically stored in the
database.

 It includes details like file storage, indexing, compression, and data access methods.

Example:
In the school database, the internal level defines:

 How the Students table is stored on the hard disk (e.g., in a file called students.dat).

 Whether the data is stored in a B-tree or hash index for faster searching.

 How data is compressed to save space.

This level is hidden from users and is managed by the database administrators.

EXAMPLE:
1. External Level:

o A customer sees product details, prices, and order history.

o A seller sees inventory, sales, and customer reviews.

o A manager sees sales reports, profits, and employee performance.

2. Conceptual Level:

o Defines tables like Products, Orders, Customers, and Sellers.

o Establishes relationships like "a customer places an order" or "a seller lists a
product."

3. Internal Level:

o Stores data in files like products.dat and orders.dat.

Database System Structure
A database system is made up of several components that work together to store, manage, and
retrieve data efficiently. The main components are:

1. Database: The actual storage of data (e.g., tables, files).

2. DBMS (Database Management System): Software that manages the database (e.g.,
MySQL, Oracle).

3. Users: People or applications that interact with the database (e.g., students, teachers,
apps).

4. Applications: Programs that use the database (e.g., a school management system).

5. Hardware: The physical devices like servers, storage, and computers.

Example:
Think of a library system:

 The database is the collection of books and their details (title, author, etc.).

 The DBMS is the librarian who manages the books (adds, removes, or finds books).

 The users are students or teachers who borrow or return books.

 The application is the software used to search for books or issue them.

 The hardware is the library building, shelves, and computers.

Database Environment
The database environment refers to the setup where the database system operates. It includes:

1. Data: The actual information stored (e.g., student records, product details).

2. Software: DBMS and applications that interact with the database.

3. Hardware: Servers, storage devices, and networking equipment.

4. Procedures: Rules for using the database (e.g., how to add or delete data).

5. People: Database administrators (DBAs), developers, and end-users.

Real-Time Example:
In a hospital management system:

 Data: Patient records, doctor details, appointments.

 Software: The hospital management software (e.g., Cerner).

 Hardware: Servers storing patient data and computers used by staff.

 Procedures: Rules for updating patient records or scheduling appointments.

 People: Doctors, nurses, IT staff, and patients.

Centralized Database Architecture

In a centralized architecture, all the data is stored and managed in a single location (one
server). Users access the database from this central location.

Example:
A small bank may store all customer and transaction records on one central server in its data
centre.

Advantages:

 Easy to manage and maintain.

 Low cost for small setups.

Disadvantages:

 Single point of failure (if the server crashes, everything stops).

 Limited scalability (cannot handle too many users or large amounts of data).
 

Client-Server Database Architecture

In a client-server architecture, the database is stored on a server, and users (clients) access it
over a network. The server handles requests from multiple clients.

Example:
Think of an online shopping platform like Amazon:

 The server stores all the product details, customer orders, and payment information.

 The clients are users accessing the platform through their laptops, phones, or tablets.

 When you search for a product, your device (client) sends a request to the server, which
processes it and sends back the results.
Advantages:

 Scalable (can handle many users and large amounts of data).

 No single point of failure (backup servers can be used).

 Efficient for distributed environments.

Disadvantages:

 More complex to set up and maintain.

 Requires good network infrastructure.

Entity Relationship Model:

o ER model stands for an Entity-Relationship model. This model is used to
define the data elements and relationship for a specified system.
o Symbols Used in ER Model
o
Components of ER Diagram

Entity
An Entity may be an object with a physical existence – a particular person, car,
house, or employee – or it may be an object with a conceptual existence – a
company, a job, or a university course.
Entity Set
An Entity Set is a collection of similar entities that belong to the same entity type
in a database or data model.
Example:
 Entity Type: Student
 Entity Set: All the students in the system
In this table:
 Entity Type: Student
 Entity Set: {Rahul K, Priya M, Arjun N}

Types of Entity
1. Strong Entity
A Strong Entity is a type of entity that has a key Attribute. Strong Entity does not
depend on other Entity in the Schema. It has a primary key, that helps in
identifying it uniquely, and it is represented by a rectangle. These are called Strong
Entity Types.
2. Weak Entity
A Weak Entity is an entity that cannot be uniquely identified by its own
attributes alone. It depends on a related strong entity (owner entity) for its
identification.
For Example, A company may store the information of dependents (Parents,
Children, Spouse) of an Employee. But the dependents can’t exist without the
employee. So Dependent will be a Weak Entity Type.
A weak entity type is represented by a Double Rectangle.
The participation of weak entity types is always total. The relationship between
the weak entity type and its identifying strong entity type is called identifying
relationship and it is represented by a double diamond.
Attributes
Attributes are the properties that define the entity type. For example, Roll_No,
Name, DOB, Age, Address, and Mobile_No are the attributes that define entity
type Student. In ER diagram, the attribute is represented by an oval.

Types of Attributes
1. Key Attribute
The attribute which uniquely identifies each entity in the entity set is called the
key attribute. For example, Roll_No will be unique for each student. In ER diagram,
the key attribute is represented by an oval with underlying lines.

2. Composite Attribute
An attribute composed of many other attributes is called a composite attribute.
For example, the Address attribute of the student Entity type consists of Street,
City, State, and Country. In ER diagram, the composite attribute is represented by
an oval comprising of ovals.
Multivalued Attribute
An attribute consisting of more than one value for a given entity. For example,
Phone_No (can be more than one for a given student). In ER diagram, a
multivalued attribute is represented by a double oval.

4. Derived Attribute
An attribute that can be derived from other attributes of the entity type is known
as a derived attribute. e.g.; Age (can be derived from DOB). In ER diagram, the
derived attribute is represented by a dashed oval.

The Complete Entity Type Student with its Attributes can be represented as:
Relationship Type and Relationship Set
A Relationship Type represents the association between entity types. For example,
‘Enrolled in’ is a relationship type that exists between entity type Student and
Course. In ER diagram, the relationship type is represented by a diamond and
connecting the entities with lines.

A set of relationships of the same type is known as a relationship set. The

following relationship set depicts S1 as enrolled in C2, S2 as enrolled in C1, and S3
as registered in C3.
Degree of a Relationship Set
The number of different entity sets participating in a relationship set is called
the degree of a relationship set.
1. Unary Relationship: When there is only ONE entity set participating
in a relation, the relationship is called a unary relationship. For
example, one person is married to only one person.
2. Binary Relationship: When there are TWO entities set participating in
a relationship, the relationship is called a binary relationship. For
example, a Student is enrolled in a Course.

3. Ternary Relationship: When there are three entity sets

participating in a relationship, the relationship is called a ternary
relationship.
4. N-ary Relationship: When there are n entities set participating in a
relationship, the relationship is called an n-ary relationship.
What is Cardinality?
The number of times an entity of an entity set participates in a
relationship set is known as cardinality . Cardinality can be of
different types:
1. One-to-One: When each entity in each entity set can take part only
once in the relationship, the cardinality is one-to-one. Let us assume
that a male can marry one female and a female can marry one male.
So the relationship will be one-to-one.
the total number of tables that can be used in this is 2.
 Doctors.

3. One-to-Many: In one-to-many mapping as well where each entity can be related

to more than one entity and the total number of tables that can be used in this is
2. Let us assume that one surgeon department can accommodate many doctors.
So the Cardinality will be 1 to M. It means one department has many

4. Many-to-One: When entities in one entity set can take part only once
in the relationship set and entities in other entity sets can take part
more than once in the relationship set, cardinality is many to one. Let
us assume that a student can take only one course but one course
can be taken by many students. So the cardinality will be n to 1. It
means that for one course there can be n students but for one
student, there will be only one course.
 5. Many-to-Many: When entities in all entity sets can take part more
than once in the relationship cardinality is many to many. Let us
assume that a student can take more than one course and one course
can be taken by many students. So the relationship will be many to
many.

Participation Constraint
Participation Constraint is applied to the entity participating in the
relationship set.
1. Total Participation – Each entity in the entity set must participate in the
relationship. If each student must enroll in a course, the participation of
students will be total. Total participation is shown by a double line in the ER
diagram.
2. Partial Participation – The entity in the entity set may or may NOT
participate in the relationship. If some courses are not enrolled by any of the
students, the participation in the course will be partial.