Data is a collection of facts and figures that can be processed to produce

information.

Information is data that has been processed, organized, and presented in a meaningful way.
Database is a collection of related data. A database management
system stores data in such a way that it becomes easier to retrieve, manipulate,
and produce information.
Properties-

1. ACID Properties − DBMS follows the concepts

of Atomicity, Consistency, Isolation, and Durability (normally
shortened as ACID). These concepts are applied to transactions, which
manipulate data in a database. ACID properties help the database stay
healthy in multi-transactional environments and in case of failure.

2. Multi user and Concurrent Access − DBMS supports multi-user

environment and allows them to access and manipulate data in
parallel. Though there are restrictions on transactions when users
attempt to handle the same data item, but users are always unaware
of them.
3. Multiple views − DBMS offers multiple views for different users. A
user who is in the Sales department will have a different view of
database than a person working in the Production department. This
 feature enables the users to have a concentrate view of the database
according to their requirements.
4. Security − Features like multiple views offer security to some extent
where users are unable to access data of other users and departments.
DBMS offers methods to impose constraints while entering data into
the database and retrieving the same at a later stage. DBMS offers
many different levels of security features, which enables multiple users
to have different views with different features. For example, a user in
the Sales department cannot see the data that belongs to the Purchase
department. Additionally, it can also be managed how much data of
the Sales department should be displayed to the user. Since a DBMS is
not saved on the disk as traditional file systems (on remote server for
big projects), it is very hard for miscreants to break the code.

The architecture of a DBMS can be seen as either single tier or multi-tier.

In 1-tier architecture, the DBMS is the only entity where the user directly sits on the
DBMS and uses it. Database designers and programmers normally prefer to use
single-tier architecture.
Entity-Relationship Model
Entity − An entity in an ER Model is a real-world entity having properties
called attributes. Every attribute is defined by its set of values
called domain.(like attribute is email id, domain will ensure that
‘something@something.com’ is accepted.) For example, in a school
database, a student is considered as an entity. Student has various attributes
like name, age, class, etc.
Relationship − The logical association among entities is
called relationship.

Database schema is the skeleton structure that represents the logical view
of the entire database. It defines how the data is organized and how the
relations among them are associated. It formulates all the constraints that
are to be applied on the data. It is designed when the database doesn't exist
at all. Once the database is operational, it is very difficult to make any
changes to it. A database schema does not contain any data or information.

A database instance is a state of operational database with data at any

given time. It contains a snapshot of the database. Database instances tend
to change with time. A DBMS ensures that its every instance (state) is in a
valid state, by diligently following all the validations, constraints, and
conditions that the database designers have imposed.

Types of Attributes
 Simple attribute − Simple attributes are atomic values, which
cannot be divided further. For example, a student's phone
number is an atomic value of 10 digits.
 Composite attribute − Composite attributes are made of more
than one simple attribute. For example, a student's complete
name may have first_name and last_name.
 Derived attribute − Derived attributes are the attributes that do
not exist in the physical database, but their values are derived
from other attributes present in the database. For example,
average_salary in a department should not be saved directly in
the database, instead it can be derived. For another example,
age can be derived from data_of_birth.
 Single-value attribute − Single-value attributes contain single
value. For example − Social_Security_Number.
 Multi-value attribute − Multi-value attributes may contain more
than one values. For example, a person can have more than one
phone number, email_address, etc.
KEYS
 Super Key − A set of attributes (one or more) that collectively
identifies an entity in an entity set.
 Candidate Key − A minimal super key is called a candidate key.
An entity set may have more than one candidate key.
 Primary Key − A primary key is one of the candidate keys
chosen by the database designer to uniquely identify the entity
set.
https://www.youtube.com/watch?v=CsGalH0QKbs

ENTITY-ATTRIBUTE

AGE: DERIVED,

PHONE-MULTIVAL

Relationship in /\ boxes.

\/
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.
Eg- Information Rule,Guaranteed access rule, Data independence and other data
rules etc. Should be in table cells. Accessed by rows and columns etc
Functional dependency (FD) is a set of constraints between two attributes
in a relation. Functional dependency says that if two tuples have same
values for attributes A1, A2,..., An, then those two tuples must have to have
same values for attributes B1, B2, ..., Bn.

Functional dependency is represented by an arrow sign (→) that is, X→Y,

where X functionally determines Y. The left-hand side attributes determine
the values of attributes on the right-hand side.

Functional dependency is represented by an arrow sign (→) that is, X→Y,

where X functionally determines Y. The left-hand side attributes determine
the values of attributes on the right-hand side.

Normalization
If a database design is not perfect, it may contain anomalies, which are like a
bad dream for any database administrator. Managing a database with
anomalies is next to impossible.
 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.
Normalization is a method to remove all these anomalies and bring the
database to a consistent state.

First Normal Form

Single valued attributes

Second Normal Form

Before we learn about the second normal form, we need to understand the
following −
 Prime attribute − An attribute, which is a part of the candidate-
key, is known as a prime attribute.
 Non-prime attribute − An attribute, which is not a part of the
prime-key, is said to be a non-prime attribute

We see here in Student_Project relation that the prime key attributes are
Stu_ID and Proj_ID. According to the rule, non-key attributes, i.e. Stu_Name
and Proj_Name must be dependent upon both and not on any of the prime
key attribute individually. But we find that Stu_Name can be identified by
Stu_ID and Proj_Name can be identified by Proj_ID independently. This is
called partial dependency, which is not allowed in Second Normal Form.
Boyce-Codd Normal Form
Boyce-Codd Normal Form (BCNF) is an extension of Third Normal Form on
strict terms. BCNF states that −
  For any non-trivial functional dependency, X → A, X must be a super-
key.
In the above image, Stu_ID is the super-key in the relation Student_Detail
and Zip is the super-key in the relation ZipCodes. So,

Stu_ID → Stu_Name, Zip

and

Zip → City
Join is a combination of a Cartesian product followed by a selection process. A Join
operation pairs two tuples from different relations, if and only if a given join
condition is satisfied.
taking a Cartesian product of two relations, which gives us all the possible tuples
that are paired together. But it might not be feasible for us in certain cases to take a
Cartesian product where we encounter huge relations with thousands of tuples
having a considerable large number of attributes.

Cartesian product

Every tuple is paired with another.

Theta (θ) Join

Theta join combines tuples from different relations provided they satisfy the
theta condition. The join condition is denoted by the symbol θ.
Equijoin
When Theta join uses only equality comparison operator, it is said to be
equijoin.

Natural Join
Natural join acts on those matching attributes where the values of attributes in both
the relations are same. Like to join two tables, it takes the common attributes and
joins the tables.

Theta Join, Equijoin, and Natural Join are called inner joins. An inner join includes
only those tuples with matching attributes and the rest are discarded in the
resulting relation.
three kinds of outer joins − left outer join, right outer join, and full outer join.