Database Architecture

Functional Dependencies
Normalization
Database Architecture
• The term "database architecture" refers to the structural
design and methodology of a database system, which forms
the core of a Database Management System (DBMS). This
architecture dictates how data is stored, organized, and
retrieved, playing a crucial role in the efficiency and
effectiveness of data management.
• Database architecture describes how a database
management system (DBMS) will be integrated with your
application.
Types of database models

• One of the fundamental aspects of database architecture is

its tier architecture.
• This concept refers to the physical and logical separation of
functionalities into different layers or tiers, such as data
storage and data processing.
Conti…
One-tier architecture
• In one-tier architecture, the database, user interface, and
application logic all reside on the same machine or server.
It's typically used for small-scale applications where
simplicity and cost-effectiveness are priorities. Because there
are no network delays involved, this type of tier architecture
is generally a fast way to access data.
• On a single-tier application, the application and database
reside on the same device.
Conti…
• In this architecture, the database is directly available to the
user. It means the user can directly sit on the DBMS and uses
it.
• Any changes done here will directly be done on the database
itself. It doesn't provide a handy tool for end users.
• The 1-Tier architecture is used for development of the local
application, where programmers can directly communicate
with the database for the quick response.
Conti…
Two-tier architecture
• Two-tier architecture consists of multiple clients connecting
directly to the database. This tier architecture is also known
as client-server architecture.
• This tier architecture used to be more common when a
desktop application would connect to a single database
hosted on an on-premise database server — for example, an
in-house customer relationship management (CRM) that
connects to an Access database.
Conti…
Conti…

•The 2-Tier architecture is same as basic client-server. In

the two-tier architecture, applications on the client
end can directly communicate with the database at
the server side. For this interaction, API's
like: ODBC, JDBC are used.
•ODBC (Open Database Connectivity) and JDBC (Java Database
Connectivity) are application programming interfaces (APIs) that allow
software applications to interact with relational databases. They serve as
a bridge between the application and the database management system
(DBMS), providing a standard way to access and manipulate data.
Conti…
Three-tier architecture
Most modern web applications use a three-tier architecture. In this
architecture, the clients connect to a back end, which in turn connects
to the database. Using this approach has many benefits:
• Security: Keeping the database connection open to a single back end
reduces the risks of being hacked.
• Scalability: Because each layer operates independently, it is easier to
scale parts of the application.
• Faster deployment: Having multiple tiers makes it easier to have a
separation of concerns and to follow cloud-native best practices,
including better continuous delivery processes.
Conti…
Conti…
• The 3-Tier architecture contains another layer between the client
and server. In this architecture, client can't directly communicate with
the server.
• The application on the client-end interacts with an application server
which further communicates with the database system.
• End user has no idea about the existence of the database beyond the
application server. The database also has no idea about any other
user beyond the application.
• The 3-Tier architecture is used in case of large web application.
Conti…
Functional Dependency
Full Functional Dependency
• Definition: An attribute is fully functionally dependent on another
attribute if it depends entirely on the primary key and not on any
subset of it.
• Example:
Partial Functional Dependency
• Definition: An attribute is partially dependent on a part of a
composite primary key (not on the entire key).
• Example:
Transitive Functional
Dependency
• Definition: A non-prime attribute (not part of the primary key)
depends transitively on the primary key through another non-prime
attribute.
• Example:
NORMALIZATION
Normalization of Database
• Database Normalization is a technique of organizing the data
in the database. Normalization is a systematic approach of
decomposing tables to eliminate data redundancy and
undesirable characteristics like Insertion, Update and
Deletion Anomalies. It is a multi-step process that puts data
into tabular form by removing duplicated data from the
relation tables.
Purpose of Normalization
Normalization is used for mainly two purpose,

1. Eliminating redundant(useless) data.

2. Ensuring data dependencies make sense i.e data is logically
stored.
Problem Without Normalization

Without Normalization, it becomes difficult to handle

and update the database, without facing data loss.
Insertion, Updation and Deletion Anomalies are very
frequent if Database is not Normalized.
Normalization Rules
Normalization rule are divided into following normal form.

1. First Normal Form

2. Second Normal Form
3. Third Normal Form
4. BCNF
First Normal Form
A database is in first normal form if it satisfies the following
conditions:
• Contains only atomic values
• There are no repeating groups
An atomic value is a value that cannot be divided. For
example, in the table shown below, the values in the [Color]
column in the first row can be divided into “red” and “green”,
hence [TABLE_PRODUCT] is not in 1NF.
1st Normal Form Example
• How do we bring an unnormalized table
into first normal form? Consider the
following example:
• This table is not in first normal form
because the [Color] column can contain
multiple values. For example, the first
row includes values “red” and “green.”
• To bring this table to first normal form,
we split the table into two tables and
now we have the resulting tables:
Conti…

Now first normal form is satisfied, as the columns on

each table all hold just one value.
Second Normal Form

A database is in second normal form if it satisfies the following

conditions:
• It is in first normal form
• All non-key attributes are fully functional dependent on the primary
key.
Conti…
• In a table, if attribute B is functionally dependent on A, but is not
functionally dependent on a proper subset of A, then B is considered
fully functional dependent on A.
• Hence, in a 2NF table, all non-key attributes cannot be dependent on
a subset of the primary key.
• Note that if the primary key is not a composite key, all non-key
attributes are always fully functional dependent on the primary key. A
table that is in 1st normal form and contains only a single key as the
primary key is automatically in 2nd normal form.
2nd Normal Form Example
• Consider the following example:
• This table has a composite primary key
[Customer ID, Store ID].
• The non-key attribute is [Purchase
Location].
• In this case, [Purchase Location] only
depends on [Store ID], which is only
part of the primary key.
• Therefore, this table does not satisfy
second normal form.
Conti…
• To bring this table to second normal form, we break the table into two
tables, and now we have the following:
• What we have done is to remove the partial functional dependency
that we initially had. Now, in the table [TABLE_STORE], the column
[Purchase Location] is fully dependent on the primary key of that
table, which is [Store ID].
Third Normal Form
• A relation is in third normal form if it is in 2NF and no non
key attribute is transitively dependent on the primary key.
• A bank uses the following relation:
• Vendor(ID, Name, Account_No, Bank_Code_No, Bank)
• The attribute ID is the identification key.
• All attributes are single valued (1NF). The table is also in 2NF.
Example 1
• The following dependencies exist:
1. Name, Account_No, Bank_Code_No are functionally
dependent on ID (ID → Name, Account_No, Bank_Code_No)
2. Bank is functionally dependent on Bank_Code_No
(Bank_Code_No → Bank)
Conti…
• The table in this example is in 1NF and in 2NF.
• But there is a transitive dependency between
Bank_Code_No and Bank, because Bank_Code_No is not the
primary key of this relation.
• To get to the third normal form (3NF), we have to put the
bank name in a separate table together with the clearing
number to identify it.
Example 2
Consider a table Orders with attributes: Order_ID, Customer_ID,
Customer_Name, and Customer_City.

• Order_ID is the primary key.

• Customer_Name and Customer_City depend on Customer_ID, not

directly on Order_ID.

• This is a transitive dependency. To normalize it to 3NF, we would split the

table into two:

1.Orders: Order_ID, Customer_ID

2.Customers: Customer_ID, Customer_Name, Customer_City