Difference Between Two-Tier and Three-Tier Database Architecture

• The two-tier DB architecture allows the client to communicate directly with the database-
thus making it less secure.
• The three-tier DB architecture does not allow its clients and database to communicate
directly- thus making it comparatively more secure in the long run.

Two-Tier Database Architecture Three-Tier Database Architecture

It is a Client-Server Architecture. It is a Web-based application.

In two-tier, the application logic is either In three-tier, the application logic or process
buried inside the user interface on the client resides in the middle-tier, it is separated from the
or within the database on the server (or both). data and the user interface.

Two-tier architecture consists of two layers: Three-tier architecture consists of three layers:
Client Tier and Database (Data Tier). Client Layer, Business Layer and Data Layer.

It is easy to build and maintain. It is complex to build and maintain.

Two-tier architecture runs slower. Three-tier architecture runs faster.

It is less secured as client can communicate It is secured as client is not allowed to

with database directly. communicate with database directly.

It results in performance loss whenever the It results in performance loss whenever the
users increase rapidly. system is run on Internet but gives more
performance than two-tier architecture.

Example – Contact Management System Example – Designing registration form which

created using MS-Access or Railway contains text box, label, button or a large website
Reservation System, etc. on the Internet, etc.
Schema
A schema in a database management system (DBMS) is a visual and logical representation of a
database's structure, including how data is organized and stored, and the relationships between
tables.
• The Skeleton of the database is created by the attributes and this skeleton is named Schema.
• Schema mentions the logical constraints like table, primary key, etc.
• The schema does not represent the data type of the attributes.
Details of a Customer Schema of Customer

Database Schema
• A database schema is a logical representation of data that shows how the data in a
database should be stored logically. It shows how the data is organized and the relationship
between the tables.
 • Database schema contains table, field, views and relation between different keys
like primary key, foreign key.
• Data are stored in the form of files which is unstructured in nature which makes accessing
the data difficult. Thus, to resolve the issue the data are organized in structured way with
the help of database schema.
• Database schema provides the organization of data and the relationship between the stored
data.
• Database schema defines a set of guidelines that control the database along with that it
provides information about the way of accessing and modifying the data.

Types of Database Schemas

There are 3 types of database schema:

Physical Database Schema

 • A Physical schema defines, how the data or information is stored physically in the storage
systems in the form of files & indices. This is the actual code or syntax needed to create
the structure of a database, we can say that when we design a database at a physical level,
it’s called physical schema.
• The Database administrator chooses where and how to store the data in the different blocks
of storage.
Logical Database Schema
• A logical database schema defines all the logical constraints that need to be applied to the
stored data, and also describes tables, views, entity relationships, and integrity constraints.
• The Logical schema describes how the data is stored in the form of tables & how the
attributes of a table are connected.
• Using ER modelling the relationship between the components of the data is maintained.
• In logical schema different integrity constraints are defined in order to maintain the quality
of insertion and update the data.
View Database Schema
• It is a view level design which is able to define the interaction between end-user and
database.
• User is able to interact with the database with the help of the interface without knowing
much about the stored mechanism of data in database.

Data Independence in DBMS

In the context of a database management system, data independence is the feature that allows the
schema of one layer of the database system to be changed without any impact on the schema of
the next higher level of the database system.
DBMS permits you to see data with such a generalized sight. It actually means that the ability to
change the structure of the lower-level schema without presenting the upper-level schema is called
data independence.
Types of Data Independence
There are two types of data independence.
• logical data independence
• Physical data independence
Logical Data Independence
• Changing the logical schema (conceptual level) without changing the external schema
(view level) is called logical data independence.
• It is used to keep the external schema separate from the logical schema.
• If we make any changes at the conceptual level of data, it does not affect the view level.
• This happens at the user interface level.
• For example, it is possible to add or delete new entities, attributes to the conceptual schema
without making any changes to the external schema.
Physical Data Independence
• Making changes to the physical schema without changing the logical schema is called
physical data independence.
• If we change the storage size of the database system server, it will not affect the conceptual
structure of the database.
• It is used to keep the conceptual level separate from the internal level.
• This happens at the logical interface level.
• Example – Changing the location of the database from C drive to D drive.
Difference Between Physical and Logical Data Independence
 Physical Data Independence Logical Data Independence
It mainly concerns how the data is stored in It mainly concerns about changes to the
the system. structure or data definition.
It is easier to achieve than logical It is difficult to achieve compared to physical
independence. independence.
To make changes at the physical level we To make changes at the logical level, we need
generally do not require changes at the to make changes at the application level.
application program level.
It tells about the internal schema. It tells about the conceptual schema.
There may or may not be a need for changes Whenever the logical structure of
to be made at the internal level to improve the the database has to be changed, the changes
structure. made at the logical level are important.
Example- change in compression Example – adding/modifying or deleting a new
technology, hashing algorithm, storage attribute.
device etc.

Integrity Constraints
Integrity constraints are the set of predefined rules that are used to maintain the quality of
information. Integrity constraints ensure that the data insertion, data updating, data deleting and
other processes have to be performed in such a way that the data integrity is not affected. They act
as guidelines ensuring that data in the database remain accurate and consistent. So, integrity
constraints are used to protect databases. The various types of integrity constraints are
Types of Integrity Constraints:
1. Domain Constraints
2. Not-Null Constraints
3. Entity integrity Constraints
4. Key Constraints
5. Primary Key Constrains
6. Referential integrity constraints
1. Domain Constraints
These are defined as the definition of valid set of values for an attribute. The data type of domain
include string, char, time, integer, date, currency etc. The value of the attribute must be available
in comparable domains.
Example:

Student_Id Name Semester Age

21CSE100 Ramesh 5th 20

21CSE101 Kamlesh 5th 21

2. Not-Null Constraints
It specifies that within a tuple, attributes overs which not-null constraint is specified must not
contain any null value.
Example:
Let, the not-null constraint be specified on the "Semester" attribute in the relation/table given
below, then the data entry of 4th tuple will violate this integrity constraint, because the "Semester"
attribute in this tuple contains null value. To make this database instance a legal instance, its entry
must not be allowed by database management system.

Student_id Name Semester Age

21CSE100 Ramesh 5th 20

21CSE101 Kamlesh 5th 21

21CSE102 Akash 5th 22

21CSE103 Mukesh 20

3. Entity Integrity Constraints

Entity integrity constraints state that primary key can never contain null value because primary
key is used to determine individual rows in a relation uniquely, if primary key contains null value,
then we cannot identify those rows. A table can contain null value in it except primary key field.
Example:
It is not allowed because it is containing primary key as NULL value.
 Student_id Name Semester Age

21CSE101 Ramesh 5th 20

21CSE102 Kamlesh 5th 21

21CSE103 Aakash 5th 22

Mukesh 5th 20

4. Key Constraints
Keys are the entity set that are used to identify an entity within its entity set uniquely. An entity set
can contain multiple keys, bit out of them one key will be primary key. A primary key is always
unique, it does not contain any null value in table.
Example:

Student_id Name Semester Age

21CSE101 Ramesh 5th 20

21CSE102 Kamlesh 5th 21

21CSE103 Aakash 5th 22

21CSE102 Mukesh 5th 20

It is now acceptable because all rows must be unique.

5. Primary Key Constraints
It states that the primary key attributes are required to be unique and not null. That is, primary key
attributes of a relation must not have null values and primary key attributes of two tuples must
never be same. This constraint is specified on database schema to the primary key attributes to
ensure that no two tuples are same.
Example:
Here, in the below example the Student_id is the primary key attribute. The data entry of 4th tuple
violates the primary key constraint that is specifies on the database schema and therefore this
instance of database is not a legal instance.

Student_id Name Semester Age

21CSE101 Ramesh 5th 20

21CSE102 Kamlesh 5th 21

21CSE103 Akash 5th 22

21CSE103 Mukesh 5th 20

6. Referential integrity constraints

It can be specified between two tables. In case of referential integrity constraints, if a Foreign
key in Table 1 refers to Primary key of Table 2 then every value of the Foreign key in Table 1 must
be null or available in Table 2.
Example:
Here, in below example Block_No 22 entry is not allowed because it is not present in 2nd table.

Student_id Name Semester Block_No

22CSE101 Ramesh 5th 20

21CSE105 Kamlesh 6th 21

22CSE102 Aakash 5th 20

23CSE106 Mukesh 2nd 22

 Block_No Block Location

20 Chandigarh

21 Punjab

25 Delhi

Types of Keys in DBMS

Keys are one of the basic requirements of a relational database model. It is widely used to identify
the tuples(rows) uniquely in the table. We also use keys to set up relations amongst various
columns and tables of a relational database.
Different Types of Database Keys
1. Candidate Key
2. Primary Key
3. Super Key
4. Alternate Key
5. Foreign Key
6. Composite Key
1. Candidate Key
The minimal set of attributes that can uniquely identify a tuple is known as a candidate key.
• It is a minimal super key.
• It is a super key with no repeated data is called a candidate key.
• A table can have multiple candidate keys but must have at least a single candidate key.
• The value of the Candidate Key is unique and may be null for a tuple.
Example:
2. Primary Key
There can be more than one candidate key in relation out of which one can be chosen as the primary
key.
• It is a unique key.
• It can identify only one tuple (a record) at a time.
• It has no duplicate values; it has unique values.
• It cannot be NULL.
Example:

3. Super Key
The set of attributes that can uniquely identify a tuple is known as Super Key.
• Adding zero or more attributes to the candidate key generates the super key.
• A candidate key is a super key but vice versa is not true.
• Super Key values may also be NULL.
Example:
Consider the table shown above.
STUD_NO+PHONE is a super key.
Relation between Primary Key, Candidate Key, and Super Key
4. Alternate Key
The candidate key other than the primary key is called an alternate key .
• All the keys which are not primary keys are called alternate keys.
• It is a secondary key.
• It contains two or more fields to identify two or more records.
• These values are repeated.
Example:

5. Foreign Key
If an attribute can only take the values which are present as values of some other attribute, it will
be a foreign key to the attribute to which it refers. The relation which is being referenced is called
referenced relation and the corresponding attribute is called referenced attribute. The referenced
attribute of the referenced relation should be the primary key to it.
• It is a key it acts as a primary key in one table and it acts as
secondary key in another table.
• It combines two or more relations (tables) at a time.
• They act as a cross-reference between the tables.
Example:

ER Model
Peter Chen developed the ER diagram in 1976. The Entity Relationship 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.
Why Use ER Diagrams In DBMS?
• ER diagrams represent the E-R model in a database, making them easy to convert into
relations (tables).
• ER diagrams provide the purpose of real-world modeling of objects which makes them
intently useful.
• ER diagrams require no technical knowledge and no hardware support.
• These diagrams are very easy to understand and easy to create even for a naive user.
• It gives a standard solution for visualizing the data logically.
Symbols Used in ER Model

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.
Types of Entity
There are two types of entity:
1. Strong Entity
A strong entity is not dependent on any other entity in the schema. A strong entity will always have
a primary key. Strong entities are represented by a single rectangle. The relationship of two strong
entities is represented by a single diamond. Various strong entities, when combined together, create
a strong entity set
2. Weak Entity
A weak entity is dependent on a strong entity to ensure its existence. Unlike a strong entity, a weak
entity does not have any primary key. It instead has a partial discriminator key. A weak entity is
represented by a double rectangle. The relation between one strong and one weak entity is
represented by a double diamond. This relationship is also known as an identifying relationship.
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 and Employee will be Identifying Entity type for Dependent, which means
it is a strong entity type.

Difference Between Strong and Weak Entity

Strong Entity Weak Entity

Strong entity always has a primary key. While a weak entity has a partial discriminator key.
Strong entity is not dependent on any Weak entity depends on strong entity.
other entity.
Strong entity is represented by a single Weak entity is represented by a double rectangle.
rectangle.
Two strong entity’s relationship is While the relation between one strong and one weak
represented by a single diamond. entity is represented by a double diamond.
Strong entities have either total A weak entity has a total participation constraint.
participation or partial participation.

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.

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.

The Complete Entity Type Student with its Attributes can be represented as:

Entity and Attributes

Degree of a Relationship Set

The number of different entities 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 is n entities set participating in a relationship, the relationship
is called an n-ary relationship.

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.

2. 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 Doctors. total number of tables that can used is 3.
3. 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. The total number of tables that can be used in this
is 3.

4. 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. the total number
of tables that can be used in this is 3.

Good Luck