0% found this document useful (0 votes)
32 views

Keys in Data Base Management System

Keys in a database management system help uniquely identify rows in tables. The document discusses various types of keys like primary keys, foreign keys, and composite keys. It provides an example of an employee table where the employee ID acts as the primary key. The document also covers normalization, entity relationship diagrams, and database normalization forms like 1NF, 2NF and 3NF which help reduce data redundancy and anomalies.

Uploaded by

Raghav Khemka
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
32 views

Keys in Data Base Management System

Keys in a database management system help uniquely identify rows in tables. The document discusses various types of keys like primary keys, foreign keys, and composite keys. It provides an example of an employee table where the employee ID acts as the primary key. The document also covers normalization, entity relationship diagrams, and database normalization forms like 1NF, 2NF and 3NF which help reduce data redundancy and anomalies.

Uploaded by

Raghav Khemka
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 14

Keys in Data Base Management System

What are Keys in DBMS?

KEYS in DBMS is an attribute or set of attributes which helps you to identify a row in a relation(table).
They allow you to find the relation between two tables. Keys help you uniquely identify a row in a
table by a combination of one or more columns in that table.

Example:

Employee ID FirstName LastName

11 Andrew Johnson

22 Tom Wood

33 Alex Hale

In the above-given example, employee ID is a primary key because it uniquely identifies an employee
record. In this table, no other employee can have the same employee ID.

Why we need a Key?

 Keys help you to identify any row of data in a table. In a real-world application, a table could
contain thousands of records. Moreover, the records could be duplicated. Keys in DBMS
ensure that you can uniquely identify a table record despite these challenges.
 Allows you to establish a relationship between and identify the relation between tables.
 Help you to enforce identity and integrity in the relationship.

Keys: -

 Primary Key – is a column or group of columns in a table that uniquely identify every row in
that table.
 Candidate Key – is a set of attributes that uniquely identify tuples in a table. Candidate Key is
a super key with no repeated attributes.
 Alternate Key – is a column or group of columns in a table that uniquely identify every row in
that table.
 Foreign Key – is a column that creates a relationship between two tables. The purpose of
foreign keys is to maintain data integrity and allow navigation between two different
instances of an entity.
 Composite Key – is a combination of two or more columns that uniquely identify rows in a
table. The combination of columns guarantees uniqueness, though individual uniqueness is
not guaranteed.
 Super Key – A super key is a group of single or multiple keys which identifies rows in a table.
Quick Revision of Keys in DBMS

What is key in DBMS: A key in DBMS is an attribute or set of attributes which helps you to
identify a row(tuple) in a relation(table)

Keys in RDBMS allow you to establish a relationship between and identify the relation between
tables

Eight types of key in DBMS are Super, Primary, Candidate, Alternate, Foreign, Compound,
Composite, and Surrogate Key.

A super key is a group of single or multiple keys which identifies rows in a table.

A column or group of columns in a table which helps us to uniquely identifies every row in that
table is called a primary key

All the different keys in DBMS which are not primary key are called an alternate key

A super key with no repeated attribute is called candidate key

A compound key is a key which has many fields which allow you to uniquely recognize a specific
record.

A key which has multiple attributes to uniquely identify rows in a table is called a composite key.

An artificial key which aims to uniquely identify each record is called a surrogate key.

Primary Key never accept null values while a foreign key may accept multiple null values.
Normalization

What is it?

 Normalization is the process of organizing the data in the database.


 Normalization is used to minimize the redundancy from a relation or set of relations.
It is also used to eliminate undesirable characteristics like Insertion, Update, and
Deletion Anomalies.
 Normalization divides the larger table into smaller and links them using relationships.
 The normal form is used to reduce redundancy from the database table.

Why do we need Normalization?


The main reason for normalizing the relations is removing these variances. Failure to
eliminate anomalies leads to data redundancy and can cause data integrity and other
problems as the database grows. Normalization consists of a series of guidelines that helps
to guide you in creating a good database structure.

Advantages of Normalization
 Normalization helps to minimize data redundancy.
 Greater overall database organization.
 Data consistency within the database.
 Much more flexible database design.
 Enforces the concept of relational integrity.

Disadvantages of Normalization
 You cannot start building the database before knowing what the user needs.
 It is very time-consuming and difficult to normalize relations of a higher degree.
 Careless decomposition may lead to a bad database design, leading to serious
problems.

Normal Description
Form

1NF A table is referred to as being in its First Normal Form if atomicity of the table is 1.
Here, atomicity states that a single cell cannot hold multiple values. It must hold only a
single-valued attribute.
The First normal form disallows the multi-valued attribute, composite attribute, and their
combinations.

2NF The first condition for the table to be in Second Normal Form is that the table has to be in
First Normal Form. The table should not possess partial dependency. The partial
dependency here means the proper subset of the candidate key should give a non-prime
attribute.
3NF The first condition for the table to be in Third Normal Form is that the table should be in
the Second Normal Form.
The second condition is that there should be no transitive dependency for non-prime
attributes, which indicates that non-prime attributes (which are not a part of the candidate
key) should not depend on other non-prime attributes in a table. Therefore, a transitive
dependency is a functional dependency in which A → C (A determines C) indirectly,
because of A → B and B → C (where it is not the case that B → A).
The third Normal Form ensures the reduction of data duplication. It is also used to achieve
data integrity.

Examples of 1NF 2NF 3NF


1NF
Below is a students’ record table that has information about student roll number, student
name, student course, and age of the student.

In the students record table, you can see that the course column has two values. Thus it
does not follow the First Normal Form. Now, if you use the First Normal Form to the above
table, you get the below table as a result.

By applying the First Normal Form, you achieve atomicity, and also every column has unique
values.
2NF

The Location table possesses a composite primary key cust_id, storeid. The non-key attribute
is store_location. In this case, store_location only depends on storeid, which is a part of the
primary key. Hence, this table does not fulfill the second normal form.
To bring the table to Second Normal Form, you need to split the table into two parts. This
will give you the below tables:

As you have removed the partial functional dependency from the location table, the column
store_location entirely depends on the primary key of that table, storeid.

3NF
Below is a student table that has student id, student name, subject id, subject name, and
address of the student as its columns.

In the above student table, stu_id determines subid, and subid determines sub. Therefore,
stu_id determines sub via subid. This implies that the table possesses a transitive functional
dependency, and it does not fulfill the third normal form criteria.
Now to change the table to the third normal form, you need to divide the table as shown
below:
As you can see in both the tables, all the non-key attributes are now fully functional,
dependent only on the primary key. In the first table, columns name, subid, and addresses
only depend on stu_id. In the second table, the sub only depends on subid.
ER Diagram
An Entity Relationship Diagram is a diagram that represents relationships among entities in a
database. It is commonly known as an ER Diagram. An ER Diagram in DBMS plays a crucial
role in designing the database.
Why Use ER Diagrams in DBMS?

 ER Diagram helps you conceptualize the database and lets you know which fields
need to be embedded for a particular entity.
 ER Diagram gives a better understanding of the information to be stored in a
database.
 It reduces complexity and allows database designers to build databases quickly.
 It helps to describe elements using Entity-Relationship models.
 It allows users to get a preview of the logical structure of the database.

Symbols Used in ER Diagrams


Rectangles: This Entity Relationship Diagram symbol represents entity types
Ellipses: This symbol represents attributes
Diamonds: This symbol represents relationship types
Lines: It links attributes to entity types and entity types with other relationship types
Primary key: Here, it underlines the attributes.
Double Ellipses: Represents multi-valued attributes.
You base an ER Diagram on three basic concepts:

 Entities  Derived Attribute


 Weak Entity  Relationships
 Attributes  One-to-One Relationships
 Key Attribute  One-to-Many Relationships
 Composite Attribute  Many-to-One Relationships
 Multivalued Attribute  Many-to-Many Relationships

Entities
An entity can be either a living or non-living component.
It showcases an entity as a rectangle in an ER diagram.
For example, in a student study course, both the student and the course are entities.

Strong Entity
A strong entity in DBMS is an independent table that doesn't rely on any other tables for its
existence. A primary key uniquely identifies each row in the table, and foreign keys are used
to relate this table to other tables. NULL values are not allowed in the primary key columns.  
A simple example of a strong entity type would be "customer" in a customer relational
database table. The customerID attribute would be the primary key (and it can't have
duplicate values or be NULL), and other information about the customer would be stored in
separate attributes such as "firstname," "last name," etc.
Weak Entity
An entity that makes reliance over another entity is called a weak entity
You showcase the weak entity as a double rectangle in ER Diagram.
In the example below, school is a strong entity because it has a primary key attribute - school
number. Unlike school, the classroom is a weak entity because it does not have any primary
key and the room number here acts only as a discriminator.

Attribute
An attribute exhibits the properties of an entity. 
You can illustrate an attribute with an oval shape in an ER diagram.

Simple attribute : 
An attribute that cannot be further subdivided into components is a simple attribute. 
Example: The roll number of a student, the id number of an employee. 
Key Attribute
Key attribute uniquely identifies an entity from an entity set.
It underlines the text of a key attribute.
For example: For a student entity, the roll number can uniquely identify a student from a set
of students.

Composite Attribute
An attribute that is composed of several other attributes is known as a composite attribute.
An oval showcases the composite attribute, and the composite attribute oval is further
connected with other ovals.

Single-valued attribute
The attribute which takes up only a single value for each entity instance is a single-valued
attribute. 
Example: The age of a student. 
Stored attribute:
 The stored attribute are those attribute which doesn’t require any type of further update
since they are stored in the database.
Example: DOB(Date of birth) is the stored attribute.

Multivalued Attribute
Some attributes can possess over one value, those attributes are called multivalued
attributes.
The double oval shape is used to represent a multivalued attribute.

Derived Attribute
An attribute that can be derived from other attributes of the entity is known as a derived
attribute.
In the ER diagram, the dashed oval represents the derived attribute.

Key attribute:
Key attributes are those attributes that can uniquely identify the entity in the entity set.
Example: Roll-No is the key attribute because it can uniquely identify the student. 
Relationship
The diamond shape showcases a relationship in the ER diagram.
It depicts the relationship between two entities.
In the example below, both the student and the course are entities, and study is the
relationship between them. 

One-to-One Relationship
When a single element of an entity is associated with a single element of another entity, it is
called a one-to-one relationship.
For example, a student has only one identification card and an identification card is given to
one person.

One-to-Many Relationship
When a single element of an entity is associated with more than one element of another
entity, it is called a one-to-many relationship.
For example, a customer can place many orders, but an order cannot be placed by many
customers.
Many-to-One Relationship
When more than one element of an entity is related to a single element of another entity,
then it is called a many-to-one relationship.
For example, students have to opt for a single course, but a course can have many students.

Many-to-Many Relationship
When more than one element of an entity is associated with more than one element of
another entity, this is called a many-to-many relationship.
For example, you can assign an employee to many projects and a project can have many
employees.

Drawing an ER diagram
1. Determine the Entities in Your ERD
2. Add Attributes to Each Entity
3. Define the Relationships Between Entities
4. Add Cardinality to Every Relationship in your ER Diagram
Data Models
Data Model gives us an idea that how the final system will look like after its complete
implementation. It defines the data elements and the relationships between the data
elements. Data Models are used to show how data is stored, connected, accessed, and
updated in the database management system.

You might also like