Scribd
Upload
92 views26 pages

DBMS

Keys play an important role in relational databases by uniquely identifying records. There are different types of keys, including primary keys which uniquely identify each entity, candidate keys which can also uniquely identify entities, foreign keys which link tables, and super keys which may include non-unique attributes. Relationships can also exist between entities at different degrees, including one-to-one, one-to-many, and many-to-many relationships.

Uploaded by

Operation Research
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
92 views26 pages

DBMS

Keys play an important role in relational databases by uniquely identifying records. There are different types of keys, including primary keys which uniquely identify each entity, candidate keys which can also uniquely identify entities, foreign keys which link tables, and super keys which may include non-unique attributes. Relationships can also exist between entities at different degrees, including one-to-one, one-to-many, and many-to-many relationships.

Uploaded by

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

DATABASES

CSCP 254
LECTURE 7. KEYS

Keys play an important role in the relational


database.
It is used to uniquely identify any record or row of
data from the table. It is also used to establish and
identify relationships between tables.
For example: In Student table, ID is used as a key
because it is unique for each student. In PERSON table,
passport_number, license_number, SSN are keys since
they are unique for each person.
TYPES OF KEYS
TYPES OF KEYS
1. Primary key
It is the first key which is used to identify one and only one
instance of an entity uniquely. An entity can contain multiple keys
as we saw in PERSON table. The key which is most suitable from
those lists become a primary key.
In the EMPLOYEE table, ID can be primary key since it is unique
for each employee. In the EMPLOYEE table, we can even select
License_Number and Passport_Number as primary key since they
are also unique.
For each entity, selection of the primary key is based on
requirement and developers.
TYPES OF KEYS

2. Candidate key
A candidate key is an attribute or set of an
attribute which can uniquely identify a tuple.
The remaining attributes except for primary key
are considered as a candidate key. The
candidate keys are as strong as the primary key.
For example: In the EMPLOYEE table, id is best suited for the
primary key. Rest of the attributes like SSN, Passport Number, and
License Number, etc. are considered as a candidate key.
TYPES OF KEYS
3. Super Key
Super key is a set of an attribute which can uniquely identify a
tuple. Super key is a superset of a candidate key.
For example: In the above EMPLOYEE table,
for(EMPLOEE_ID, EMPLOYEE_NAME) the name of two
employees can be the same, but their EMPLYEE_ID can't be the
same. Hence, this combination can also be a key.
The super key would be EMPLOYEE-ID, (EMPLOYEE_ID,
EMPLOYEE-NAME), etc.
TYPES OF KEYS
4. Foreign key
Foreign keys are the column of the table which is used to point to
the primary key of another table.
In a company, every employee works in a specific department,
and employee and department are two different entities. So we
can't store the information of the department in the employee
table. That's why we link these two tables through the primary key
of one table.
We add the primary key of the DEPARTMENT table,
Department_Id as a new attribute in the EMPLOYEE table.
o Now in the EMPLOYEE table, Department_Id is the foreign
key, and both the tables are related.
GENERALIZATION
Generalization is like a bottom-up approach in which two or more
entities of lower level combine to form a higher level entity if they have
some attributes in common.
In generalization, an entity of a higher level can also combine with the
entities of the lower level to form a further higher level entity.
Generalization is more like subclass and superclass system, but the only
difference is the approach. Generalization uses the bottom-up approach.
In generalization, entities are combined to form a more generalized
entity, i.e., subclasses are combined to make a superclass.
For example, Faculty and Student entities can be generalized and
create a higher level entity Person.
SPECIALIZATION

Specialization is a top-down approach, and it is opposite to


Generalization. In specialization, one higher level entity can be
broken down into two lower level entities. Specialization is used
to identify the subset of an entity set that shares some
distinguishing characteristics.
Normally, the superclass is defined first, the subclass and its
related attributes are defined next, and relationship set are then
added.
For example: In an Employee management system, EMPLOYEE entity
can be specialized as TESTER or DEVELOPER based on what role they
play in the company.
AGGREGATION

In aggregation, the relation between two entities is treated as a


single entity. In aggregation, relationship with its corresponding
entities is aggregated into a higher level entity.
For example: Centre entity offers the Course entity act as a single
entity in the relationship which is in a relationship with another
entity visitor. In the real world, if a visitor visits a coaching centre
then he will never enquiry about the Course only or just about the
Centre instead he will ask the enquiry about both.
REDUCTION OF ER DIAGRAM TO TABLE

The database can be represented using the notations,


and these notations can be reduced to a collection of
tables.
In the database, every entity set or relationship set
can be represented in tabular form.
The ER diagram is given below:
REDUCTION OF ER DIAGRAM TO TABLE
Entity type becomes a table.
In the given ER diagram, LECTURE, STUDENT, SUBJECT and COURSE forms individual tables.
All single-valued attribute becomes a column for the table.
In the STUDENT entity, STUDENT_NAME and STUDENT_ID form the column of STUDENT table.
Similarly, COURSE_NAME and COURSE_ID form the column of COURSE table and so on.
A key attribute of the entity type represented by the primary key.
In the given ER diagram, COURSE_ID, STUDENT_ID, SUBJECT_ID, and LECTURE_ID are the key
attribute of the entity.
The multivalued attribute is represented by a separate table.
In the student table, a hobby is a multivalued attribute. So it is not possible to represent multiple values in
a single column of STUDENT table. Hence we create a table STUD_HOBBY with column name
STUDENT_ID and HOBBY. Using both the column, we create a composite key.
REDUCTION OF ER DIAGRAM TO TABLE
Composite attribute represented by components.
In the given ER diagram, student address is a composite attribute. It contains
CITY, PIN, DOOR#, STREET, and STATE. In the STUDENT table, these
attributes can merge as an individual column.
Derived attributes are not considered in the table.
In the STUDENT table, Age is the derived attribute. It can be calculated at any
point of time by calculating the difference between current date and Date of
Birth.
Using these rules, you can convert the ER diagram to tables and columns and
assign the mapping between the tables. Table structure for the given ER diagram
is as below:
Figure: Table structure
RELATIONSHIP OF HIGHER DEGREE
Relationship of higher degree
The degree of relationship can be defined as the number of occurrences in
one entity that is associated with the number of occurrences in another
entity.
There is the three degree of relationship:
 One-to-one (1:1)
 One-to-many (1:M)
 Many-to-many (M:N)
RELATIONSHIP OF HIGHER DEGREE
 . One-to-one

In a one-to-one relationship, one occurrence of an entity relates to only one


occurrence in another entity. A one-to-one relationship rarely exists in
practice.
For example: if an employee is allocated a company car then that car can
only be driven by that employee.
Therefore, employee and company car have a one-to-one relationship.
RELATIONSHIP OF HIGHER DEGREE
2. One-to-many
In a one-to-many relationship, one occurrence in an entity relates to
many occurrences in another entity.
For example: An employee works in one department, but a
department has many employees.
Therefore, department and employee have a one-to-many
relationship.
RELATIONSHIP OF HIGHER DEGREE
3. Many-to-many
In a many-to-many relationship, many occurrences in an entity
relate to many occurrences in another entity.
Same as a one-to-one relationship, the many-to-many relationship
rarely exists in practice.
For example: At the same time, an employee can work on several
projects, and a project has a team of many employees.
Therefore, employee and project have a many-to-many relationship.

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy