Scribd
Upload
19 views7 pages

APCE9B~1

Uploaded by

reyadblock123
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOC, PDF, TXT or read online on Scribd
19 views7 pages

APCE9B~1

Uploaded by

reyadblock123
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOC, PDF, TXT or read online on Scribd
You are on page 1/ 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.
 For example, ID is used as a key in the Student table because it is unique for
each student.
 In the PERSON table, passport_number, license_number, SSN are keys
since they are unique for each person.

Types of keys:
1. Primary key
 It is used to identify an entity uniquely.
 An entity can contain multiple keys, as we saw in the PERSON table.
 The key which is most suitable from those lists becomes a primary key.
 In the EMPLOYEE table, ID can be the primary key since it is unique for
each employee.
 In the EMPLOYEE table, we can even select License_Number and
Passport_Number as primary keys since they are also unique.
 For each entity, the primary key selection is based on requirements and
developers.
2. Candidate key
 A candidate key is an attribute or set of attributes that can uniquely identify a
tuple. The candidate keys are as strong as the primary key.
 For example: In the EMPLOYEE table, id is best suited for the primary key.
 The rest of the attributes, like SSN, Passport_Number, License_Number,
etc., are considered a candidate key.

3. Super Key
 super key is a set of attributes that uniquely identifies each tuple of a relation.
 A super key is a superset of a candidate key.

 For example: In the above EMPLOYEE table,


(EMPLOEE_ID, EMPLOYEE_NAME) is considered as super key.
 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.

4. Foreign key
 Foreign keys are the column of the table used to point to the primary key of
another table.
 Every employee works in a specific department in a company, and employee
and department are two different entities. So we can't store the department's
information 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.
 In the EMPLOYEE table, Department_Id is the foreign key, and both the
tables are related.

5. Alternate key
 There may be one or more attributes that uniquely identify each tuple in a
relation. These attributes are called the candidate keys.
 One key is chosen as the primary key from these candidate keys, and the
remaining candidate key, if it exists, is termed the alternate key.
 In other words, the total number of the alternate keys is the total number of
candidate keys minus the primary key.
 The alternate key may or may not exist. If there is only one candidate key in
a relation, it does not have an alternate key.
 For example, employee relation has two attributes, Employee_Id and
PAN_No, that act as candidate keys.
 In this relation, Employee_Id is chosen as the primary key, so the other
candidate key, PAN_No, acts as the Alternate key.
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, 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.
 Normally, the superclass is defined first, the subclass and its related
attributes are defined next.
 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.
 For example: Center 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 center then he will never
enquiry about the Course only or just about the Center 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:
There are some rules for converting the ER diagram to the 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.

 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:

You might also like