DBMS Architecture:

A Database stores a lot of critical information to access data quickly and securely. Hence it is
important to select the correct architecture for efficient data management. DBMS
Architecture helps users to get their requests done while connecting to the database. We
choose database architecture depending on several factors like the size of the database,
number of users, and relationships between the users. There are two types of database
models that we generally use, logical model and physical model. Several types of
architecture are there in the database which we will deal with in the next section.
Types of DBMS Architecture:
1-Tier Architecture In 1-Tier Architecture the database is directly available to the user, the
user can directly sit on the DBMS and use it that is, the client, server, and Database are all
present on the same machine. For Example: to learn SQL we set up an SQL server and the
database on the local system. This enables us to directly interact with the relational
database and execute operations. The industry won’t use this architecture they logically go
for 2-tier and 3-tier Architecture.
The 2-tier architecture is similar to a basic client-server model. The application at the client
end directly communicates with the database on the server side. APIs like ODBC and JDBC
are used for this interaction. The server side is responsible for providing query processing
and transaction management functionalities. On the client side, the user interfaces and
application programs are run. The application on the client side establishes a connection
with the server side to communicate with the DBMS. An advantage of this type is that
maintenance and understanding are easier, and compatible with existing systems. However,
this model gives poor performance when there are a large number of users.
In 3-Tier Architecture, there is another layer between the client and the server. The client
does not directly communicate with the server. Instead, it interacts with an application
server which further communicates with the database system and then the query processing
and transaction management takes place. This intermediate layer acts as a medium for the
exchange of partially processed data between the server and the client. This type of
architecture is used in the case of large web applications.
| 1-Tier | Direct access to DBMS, easy to learn, good for SQL learning | Not suitable for large
systems, all components on same machine |
| 2-Tier | Easy maintenance, compatible with existing systems, good for small to medium
applications | Poor performance with large number of users, client-server model |
| 3-Tier | Scalable for large web applications, data exchange through intermediate layer |
More complex, requires more resources |
What is the Relational Model? The relational model represents how data is stored in Relational
Databases. A relational database consists of a collection of tables, each of which is assigned a unique
name. Consider a relation STUDENT with attributes ROLL_NO, NAME, ADDRESS, PHONE, and AGE
shown in the table.
Table Student
Roll_no : 1 , 2 , 3 ,4
Name : Ram, Ramesh , Sujit, Suresh
Address : Delhi, Gurgaon, Delhi, Patiala
Phone : 99949994, 49994949, 45454545, Empty
Age : 18 , 18, 20, 40
Types of Relational Models:
1. The One-to-Many Model
In this type of relationship, one entity is related to multiple other entities. For example, a customer may have multiple orders, a
teacher may have multiple students, and a product may be sold in multiple stores. The key feature of the one-to-many model
is that the relationship between two entities is not reciprocal. That is, the fact that a customer has multiple orders does not
mean that an order has multiple customers.
2. The One-to-One Model
The one-to-one model of relational models states that there is a direct and unique relationship between two specific objects.
In other words, each object can only be related to one other object and vice versa. This type of relationship is often used to
represent relationships between physical things, such as people and their driver's license numbers. While the one-to-one
model is relatively simple, it can be useful for representing complex real-world relationships.
3. The Many-to-Many Model
In a many-to-many model, each record in the primary table can be linked to multiple records in the foreign table and vice
versa. This type of relationship is less common. For example, a many-to-many relationship takes place between students and
courses. A student can take multiple courses, and a course can have multiple students enrolled.
To create a many-to-many relationship, we need to create a third table, called a junction table, that contains the primary keys
of the other tables. The junction table establishes the relationships between the rows in the two other tables.

1:Attribute: Attributes are the properties that define an entity. e.g.; ROLL_NO, NAME, ADDRESS
2:Relation Schema: A relation schema defines the structure of the relation and represents the name
of the relation with its attributes. e.g.; STUDENT (ROLL_NO, NAME, ADDRESS, PHONE, and AGE) is the
relation schema for STUDENT. If a schema has more than 1 relation, it is called Relational Schema.
3:Tuple: Each row in the relation is known as a tuple. 4:Relation Instance: The set of tuples of a
relation at a particular instance of time is called a relation instance. Table 1 shows the relation
instance of STUDENT at a particular time. It can change whenever there is an insertion, deletion, or
update in the database. 5:Degree: The number of attributes in the relation is known as the degree of
the relation. The STUDENT relation defined above has degree 5. 6:Cardinality: The number of tuples
in a relation is known as cardinality. The STUDENT relation defined above has cardinality 4. 7:Column:
The column represents the set of values for a particular attribute.8:NULL Values: The value which is
not known or unavailable is called a NULL value. It is represented by blank space. e.g.; PHONE of
STUDENT having ROLL_NO 4 is NULL. 9:Relation Key: These are basically the keys that are used to
identify the rows uniquely or also help in identifying tables. These are of the following types.: Primary
Key,Candidate Key,Super Key,Foreign Key,Alternate Key,Composite Key
Introduction of ER Model:
The Entity Relational Model is a model for identifying entities to be represented in the database and
representation of how those entities are related. The ER data model specifies enterprise schema that
represents the overall logical structure of a database graphically.
The Entity Relationship Diagram explains the relationship among the entities present in the database.
ER models are used to model real-world objects like a person, a car, or a company and the relation
between these real-world objects. In short, the ER Diagram is the structural format of the database.
Symbols Used in ER Model
ER Model is used to model the logical view of the system from a data perspective which consists of
these symbols:
Rectangles: Rectangles represent Entities in the ER Model.
Ellipses: Ellipses represent Attributes in the ER Model.
Diamond: Diamonds represent Relationships among Entities.
Lines: Lines represent attributes to entities and entity sets with other relationship types.
Double Ellipse: Double Ellipses represent Multi-Valued Attributes.
Double Rectangle: Double Rectangle represents a Weak Entity.
 Components of ER Diagram
ER Model consists of Entities, Attributes, and Relationships among Entities in a Database System.
 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.
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
An Entity type has a key attribute that uniquely identifies each entity in the entity set. But some entity
type exists for which key attributes can’t be defined. These are called Weak Entity types.
 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.
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.
3. 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.
Tuple vs domain relational
1.Definition |The Tuple Relational Calculus (TRC) is used to select tuples from a relation. The
tuples with specific range values, tuples with certain attribute values, and so on can be selected.
| The Domain Relational Calculus (DRC) employs a list of attributes from which to choose based
on the condition. It’s similar to TRC, but instead of selecting entire tuples, it selects attributes..
2.Representation of variables | In TRC, the variables represent the tuples from specified
relations.| In DRC, the variables represent the value drawn from a specified domain.
3.Tuple/Domain|A tuple is a single element of relation. In database terms, it is a row. | A domain
is equivalent to column data type and any constraints on the value of data.
4.Filtering|This filtering variable uses a tuple of relations.|This filtering is done based on the
domain of attributes.
5.|Return Value|The predicate expression condition associated with the TRC is used to test every
row using a tuple variable and return those tuples that met the condition.|DRC takes advantage
of domain variables and, based on the condition set, returns the required attribute or column
that satisfies the criteria of the condition.
6.Membership condition|The query cannot be expressed using a membership condition.|The
query can be expressed using a membership condition.
7.Query Language|The QUEL or Query Language is a query language related to it, |The QBE or
Query-By-Example is query language related to it.
8.Similarity|It reflects traditional pre-relational file structures.|It is more similar to logic as a
modeling language.
9.Syntax|Notation: {T | P (T)} or {T | Condition (T)}|Notation: { a1, a2, a3, …, an | P (a1, a2, a3, …,
an)}
10.Example|{T | EMPLOYEE (T) AND T.DEPT_ID = 10}|{ | < EMPLOYEE > DEPT_ID = 10 }
11.Focus |Focuses on selecting tuples from a relation|Focuses on selecting values from a relation
12.Variables|Uses tuple variables (e.g., t)|Uses scalar variables (e.g., a1, a2, …, an)
13.Ease of use |Easier to use for simple queries.|More difficult to use for simple queries.
14.Use case |Useful for selecting tuples that satisfy a certain condition or for retrieving a subset
of a relation.|Useful for selecting specific values or for constructing more complex queries that
involve multiple relations.

Types of Functional dependencies in DBMS

In a relational database management, functional dependency is a concept that specifies the relationship between two
sets of attributes where one attribute determines the value of another attribute. It is denoted as X → Y, where the
attribute set on the left side of the arrow, X is called Determinant, and Y is called the Dependent.
Types of Functional Dependencies in DBMS
1. Trivial functional dependency
2. Non-Trivial functional dependency
3. Multivalued functional dependency
4. Transitive functional dependency
1. Trivial Functional Dependency
In Trivial Functional Dependency, a dependent is always a subset of the determinant. i.e. If X → Y and Y is the subset of X,
then it is called trivial functional dependency

Example:
roll_no name age
42 abc 17
43 pqr 18
44 xyz 18
Here, {roll_no, name} → name is a trivial functional dependency, since the dependent name is a subset of determinant
set {roll_no, name}. Similarly, roll_no → roll_no is also an example of trivial functional dependency.

2. Non-trivial Functional Dependency

In Non-trivial functional dependency, the dependent is strictly not a subset of the determinant. i.e. If X → Y and Y is not
a subset of X, then it is called Non-trivial functional dependency.

Example:
roll_no name age
42 abc 17
43 pqr 18
44 xyz 18
Here, roll_no → name is a non-trivial functional dependency, since the dependent name is not a subset of determinant
roll_no. Similarly, {roll_no, name} → age is also a non-trivial functional dependency, since age is not a subset of {roll_no,
name}

3. Multivalued Functional Dependency

In Multivalued functional dependency, entities of the dependent set are not dependent on each other. i.e. If a → {b, c}
and there exists no functional dependency between b and c, then it is called a multivalued functional dependency.

For example,
roll_no name age
42 abc 17
43 pqr 18
44 xyz 18
45 abc 19
Here, roll_no → {name, age} is a multivalued functional dependency, since the dependents name & age are not
dependent on each other(i.e. name → age or age → name doesn’t exist !)

4. Transitive Functional Dependency

In transitive functional dependency, dependent is indirectly dependent on determinant. i.e. If a → b & b → c, then
according to axiom of transitivity, a → c. This is a transitive functional dependency.

For example,
enrol_no name dept building_no
42 abc CO 4
43 pqr EC 2
44 xyz IT 1
45 abc EC 2
Here, enrol_no → dept and dept → building_no. Hence, according to the axiom of transitivity, enrol_no → building_no is
a valid functional dependency. This is an indirect functional dependency, hence called Transitive functional dependency.
Joins in DBMS
Joins are a fundamental operation in relational databases that combine data from
multiple tables based on a specific condition.expand_more They allow you to
retrieve related information from different tables in a single query.expand_more
Here are the main types of joins:
Equi Join (Inner Join)
Syntax:
SELECT column_list
FROM table1 AS t1
INNER JOIN table2 AS t2
ON t1.column_name = t2.column_name;
Description: Combines rows from two tables where the values in a specified column
(column_name) are equal in both tables.
Example:

Consider tables Customers and Orders:

| Customers (CID, CustomerName) |

|---|---|
| 1, Alice |
| 2, Bob |
| 3, Charlie |

| Orders (OrderID, CID, OrderAmount) |

|---|---|---|
| 101, 1, 100 |
| 102, 2, 200 |
| 103, 3, 300 |
SELECT Customers.CustomerName, Orders.OrderAmount
FROM Customers
INNER JOIN Orders
ON Customers.CID = Orders.CID;
Output:| CustomerName | OrderAmount | |---|---| | Alice | 100 | | Bob | 200 | | Charlie | 300 |

2. Non-Equi Join
Syntax:
SELECT column_list
FROM table1 AS t1
JOIN table2 AS t2
ON t1.column_name [comparison operator] t2.column_name;
Description: Similar to equi join, but uses comparison operators other than equal (=)
to join tables. Common operators include >, <, >=, <=.
Example:Using the same tables, find orders with an order amount greater than 150:
SELECT Customers.CustomerName, Orders.OrderAmount
FROM Customers
JOIN Orders
ON Customers.CID = Orders.CID
WHERE Orders.OrderAmount > 150;
Output :| CustomerName | OrderAmount | |---|---| | Bob | 200 | | Charlie | 300 |
3. Self Join
Syntax:
SELECT column_list
FROM table_name AS t1
JOIN table_name AS t2
ON t1.column_name = t2.column_name;
Description: Joins a table to itself, using aliases (t1, t2) to distinguish between the
two instances of the table.

Example:
Find customers who placed orders for themselves (assuming a SalesPersonID
column in Orders):
SELECT c1.CustomerName AS OrderingCustomer, c2.CustomerName AS SalesPerson
FROM Customers AS c1
JOIN Customers AS c2
ON c1.CID = Orders.CID
JOIN Orders ON c2.CID = Orders.SalesPersonID;
4. Outer Joins
Syntax:
Left Outer Join:
SQL
SELECT column_list
FROM table1 AS t1
LEFT JOIN table2 AS t2
ON t1.column_name = t2.column_name;
Use code with caution.
Right Outer Join:
SELECT column_list
FROM table1 AS t1
RIGHT JOIN table2 AS t2
ON t1.column_name = t2.column_name;
Full Outer Join:Right Join -> FULL OUTER JOIN and t2.column not _name