A database is a collection of information that is organized in tables and stored on a computer system.

This information can be updated or modified as

required.
database management system (DBMS) is a software for creating and managing data in the databases. The DBMS provides users and programmers a
defined process for data retrieval, management, updating, and creation.
Database Management Software also keeps data guarded and safe. These tools help in reducing data redundancy and maintaining the efficiency of data.
Some of them are open-source and some are commercial with specific features.

Based on the usage and requirement we can choose a software tool that has needed features and the desired output.
https://
www.geeksforgeeks.or
g/cardinality-in-dbms/
The relationship that relates the weak entity type to an owner entity type is known as identifying relationship. The weak entity type
always has total participation(existence dependency) in a relationship because the weak entity type can not be identified without an
owner identity. This doesn’t mean that every existence dependency(total participation) results in a weak entity type.
https://www.g
Dr Edgar F. Codd, after his extensive research on the Relational Model of database systems, came
up with twelve rules of his own, which according to him, a database must obey in order to be
regarded as a true relational database.
These rules can be applied on any database system that manages stored data using only its
relational capabilities. This is a foundation rule, which acts as a base for all the other rules.

Rule 1: Information Rule

The data stored in a database, may it be user data or metadata, must be a value of some table cell.
Everything in a database must be stored in a table format..

Rule 2: Guaranteed Access Rule

Every single data element (value) is guaranteed to be accessible logically with a combination of
table-name, primary-key (row value), and attribute-name (column value). No other means, such as
pointers, can be used to access data.

Rule 3: Systematic Treatment of NULL Values

The NULL values in a database must be given a systematic and uniform treatment. This is a very
important rule because a NULL can be interpreted as one the following − data is missing, data is not
known, or data is not applicable.

Rule 4: Active Online Catalog

The structure description of the entire database must be stored in an online catalog, known as data
dictionary, which can be accessed by authorized users. Users can use the same query language to
access the catalog which they use to access the database itself.

Rule 5: Comprehensive Data Sub-Language Rule

A database can only be accessed using a language having linear syntax that supports data
definition, data manipulation, and transaction management operations. This language can be used
directly or by means of some application. If the database allows access to data without any help of
this language, then it is considered as a violation.

Rule 6: View Updating Rule

All the views of a database, which can theoretically be updated, must also be updatable by the
system.

Rule 7: High-Level Insert, Update, and Delete Rule

A database must support high-level insertion, updation, and deletion. This must not be limited to a
single row, that is, it must also support union, intersection and minus operations to yield sets of data
records.

Rule 8: Physical Data Independence

The data stored in a database must be independent of the applications that access the database.
Any change in the physical structure of a database must not have any impact on how the data is
being accessed by external applications.

Rule 9: Logical Data Independence

The logical data in a database must be independent of its user’s view (application). Any change in
logical data must not affect the applications using it. For example, if two tables are merged or one is
split into two different tables, there should be no impact or change on the user application. This is
one of the most difficult rule to apply.

Rule 10: Integrity Independence

A database must be independent of the application that uses it. All its integrity constraints can be
independently modified without the need of any change in the application. This rule makes a
database independent of the front-end application and its interface.

Rule 11: Distribution Independence

The end-user must not be able to see that the data is distributed over various locations. Users
should always get the impression that the data is located at one site only. This rule has been
regarded as the foundation of distributed database systems.

Rule 12: Non-Subversion Rule

If a system has an interface that provides access to low-level records, then the interface must not be
able to subvert the system and bypass security and integrity constraints.
relationship between attributes of a table dependent on
each other. Introduced by E. F. Codd, it helps in preventing
data redundancy and gets to know about bad designs.
To understand the concept thoroughly, let us consider P is a
relation with attributes A and B. Functional Dependency is
represented by -> (arrow sign)
Then the following will represent the functional dependency
between attributes with an arrow sign −

A -> B
Above suggests the following:

Example
The following is an example that would make it easier to
understand functional dependency −
We have a <Department> table with two attributes −
DeptId and DeptName.

DeptId = Department ID
DeptName = Department Name
The DeptId is our primary key. Here, DeptId uniquely
identifies the DeptName attribute. This is because if you
want to know the department name, then at first you need to
have the DeptId.

DeptId DeptName
001 Finance
002 Marketing
003 HR
Therefore, the above functional dependency between
DeptId and DeptName can be determined as DeptId is
functionally dependent on DeptName −

DeptId -> DeptName

Types of Functional Dependency

Functional Dependency has three forms −
• Trivial Functional Dependency
• Non-Trivial Functional Dependency
• Completely Non-Trivial Functional Dependency
Let us begin with Trivial Functional Dependency −

Trivial Functional Dependency

It occurs when B is a subset of A in −

A ->B
Example
We are considering the same <Department> table with two
attributes to understand the concept of trivial dependency.
The following is a trivial functional dependency since
DeptId is a subset of DeptId and DeptName

{ DeptId, DeptName } -> Dept Id

Non –Trivial Functional Dependency

It occurs when B is not a subset of A in −

A ->B
Example

DeptId -> DeptName

The above is a non-trivial functional dependency since
DeptName is a not a subset of DeptId.

Completely Non - Trivial Functional Dependency

It occurs when A intersection B is null in −

A ->B

Armstrong’s Axioms Property of Functional Dependency

Armstrong’s Axioms property was developed by William
Armstrong in 1974 to reason about functional dependencies.
The property suggests rules that hold true if the following are
satisfied:
• TransitivityIf A->B and B->C, then A->C i.e. a transitive relation.
• ReflexivityA-> B, if B is a subset of A.
• AugmentationThe last rule suggests: AC->BC, if A->B
 https://
www.gee
ksforgeek
s.org/
types-of-
keys-in-
relational-
The set of attributes model-
The candidate that can uniquely
There can be more
than one candidate
key other than identify a tuple is candidate
The minimal set key in relation out
the primary key
is called an
known as Super -super-
Key.
of attributes that
can uniquely
of which one can be
alternate key. • Adding zero or
primary-
chosen as the
identify a tuple is primary key. more attributes to alternate-
known as a
candidate key.
the candidate key
generates the
and-
super key. foreign/
• A candidate key
is a super key but
vice versa is not
true.
 Normalization is the process of minimizing redundancy from a
relation or set of relations. Redundancy in relation may cause
insertion, deletion, and update anomalies. So, it helps to minimize
the redundancy in relations. Normal forms are used to eliminate or
reduce redundancy in database tables.

• Update anomalies − If data items are scattered and are not linked to each other properly, then it could lead to strange situations. For example,
when we try to update one data item having its copies scattered over several places, a few instances get updated properly while a few others
are left with old values. Such instances leave the database in an inconsistent state.
• Deletion anomalies − We tried to delete a record, but parts of it was left undeleted because of unawareness, the data is also saved
somewhere else.
• Insert anomalies − We tried to insert data in a record that does not exist at all.
https://mycareerwise.com/content/membership-test/content/exam/gate/computer-science
Given a Relation with different FD sets for that relation, we have to find out whether one FD set is a subset of another or both are equal.
How do find the relationship between two FD sets? Let FD1 and FD2 be two FD sets for a relation R.
1 If all FDs of FD1 can be derived from FDs present in FD2, we can say that FD2 ⊃ FD1.
2 If all FDs of FD2 can be derived from FDs present in FD1, we can say that FD1 ⊃ FD2.
3 If 1 and 2 both are true, FD1=FD2.
All these three cases can be shown using the Venn diagram:
 https://www.javatpoint.com/dbms-normalization

1. First Normal Form –

If a relation contain composite or multi-valued attribute, it violates first normal form or a relation is in first normal form if it does not contain
any composite or multi-valued attribute. A relation is in first normal form if every attribute in that relation is singled valued attribute.

• Example 1 – Relation STUDENT in table 1 is not in 1NF because of multi-valued attribute STUD_PHONE. Its decomposition into 1NF
has been shown in table 2.

1. First Normal Form –

If a relation contain composite or multi-valued attribute, it violates first normal form or a

relation is in first normal form if it does not contain any composite or multi-valued attribute.
A relation is in first normal form if every attribute in that relation is singled valued
attribute.

• Example 1 – Relation STUDENT in table 1 is not in 1NF because of multi-valued

attribute STUD_PHONE. Its decomposition into 1NF has been shown in table 2.
2. Second Normal Form –

To be in second normal form, a relation must be in first normal form and relation must not contain any partial dependency. A relation is in
2NF if it has No Partial Dependency, i.e., no non-prime attribute (attributes which are not part of any candidate key) is dependent on
any proper subset of any candidate key of the table.
Partial Dependency – If the proper subset of candidate key determines non-prime attribute, it is called partial dependency.
Whenever some indirect relationship happens to cause
functional dependency (FC), it is known as Transitive
Dependency. Thus, if A -> B and B -> C are true, then A -> C
happens to be a transitive dependency. Thus, to achieve 3NF,
one must eliminate the Transitive Dependency.
3. Third Normal Form –
A relation is in third normal form, if there is no transitive dependency for non-prime attributes as well as it is in second normal form.
A relation is in 3NF if at least one of the following condition holds in every non-trivial function dependency X –> Y

1 X is a super key.
2 Y is a prime attribute (each element of Y is part of some candidate key).