Embed Size (px)
Citation preview
Entity and its types:
1) Strong2) Weak3) Recursive4) Composite
Week:
In a relational database, a weak entity is an entity that cannot be uniquely identified by its attributes alone; therefore, it must use a foreign key in conjunction with its attributes to create a primary key. The foreign key is typically a primary key of an entity it is related to. A weak entity does not have any items in its primary key other than its inherited primary key.
Example: A weak entity is one that can only exist when owned by another one. For example: a ROOM can only exist in a BUILDING. On the other hand, a TIRE might be considered as a strong entity because it also can exist without being attached to a CAR.
Just to play with it, question is strong entity type and answer is weak. Question is always there, but an answer requires a question to exist.
Strong Entity:
A Strong Entity is one that exists on its own, independent of other entities. The Strong Entity is usually referred to as the Owner or Parent entity.
For example, at a university or college we have student entities and we would define a student entity type. Universities and Colleges assign unique student numbers, one per student. Student has a key attribute and would be considered a strong entity type.
Recursive EntityA recursive entity is one in which a relation can exist between occurrences of the same entity set. This occurs in a unary relationship.
Example: sir sy pochna aa.
Composite Entities
If a Many to Many relationship exist we must create a bridge entity to convert it into 1 to Many. Bridge entity composed of the primary keys of each of the entities to be connected. The bridge entity is known as a composite entity. A composite entity is represented by a diamond shape with in a rectangle in an ER Diagram.
Attributes
Simple Attribute
The attributes of an entity that cannot be divided into smaller components, are called simple attributes. They art also referred to as atomic attributes. For example, the color, age and roll number of a student are examples of simple attributes.
Composite Attribute
The attribute of an entity that can be divided into smaller components is called composite attribute. Each component also represents simple attribute with independent meanings. For example, student's name can be divided into: first-name, middle-name and last-name.
Single Valued and Multi Valued attribute
A single valued attribute can have only a single value. For example a person can have only one 'date of birth', 'age' etc. That is a single valued attributes can have only single value. But it can be simple or composite attribute.That is 'date of birth' is a composite attribute , 'age' is a simple attribute. But both are single valued attributes.
Multivalued attributes can have multiple values. For instance a person may have multiple phone numbers,multiple degrees etc.Multivalued attributes are shown by a double line connecting to the entity in the ER diagram.
Single Valued Attribute: Attribute that hold a single valueExample1: AgeExampe2: CityExample3:Customer id
Multi Valued Attribute: Attribute that hold multiple values.Example1: A customer can have multiple phone numbers, email id's etcExample2: A person may have several college degrees
Stored and Derived Attributes
The value for the derived attribute is derived from the stored attribute. For example 'Date of birth' of a person is a stored attribute. The value for the attribute 'AGE' can be derived by subtracting the 'Date of Birth'(DOB) from the current date. Stored attribute supplies a value to the related attribute.
Stored Attribute: An attribute that supplies a value to the related attribute.Example: Date of Birth
Derived Attribute: An attribute that’s value is derived from a stored attribute.Example : age, and it’s value is derived from the stored attribute Date of Birth.
Complex Attribute
A complex attribute that is both composite and multi valued.
========================================================================
Definition and Explanation of Relationship in Database and Types of Relationships in Database:
Definition and Explanation:
A relationship is an association between the instances of one or more entity types. For example, a student may be related to a class by being enrolled in that class. Another example is the link between mother and children. One mother may have many children, but each child has only one mother.
A relationship between entities is given a relevant name. For example, there is a relationship between MANAGER and DEPARTMENT. A manager manages the department; on the other hand a department is managed by a manager. This leads to a relationship called "Manages" between MANAGER and DEPARTMENT.
Similarly, there is a relationship between AUTHOR and the BOOK. An author writes a book; on the other hand a Book is written by an Author. This leads to a relationship called "Writes" between AUTHOR and BOOK.
Diagram:
In E-R diagram, a relationship is indicated by a diamond shape labeled with relationship name. The diamond symbol is placed between the entities symbols connecting with lines. The relationships between MANAGER-DEPARTMENT and AUTHOR-BOOK are shown in figure below.
The entities can be associated /connected to one another in different ways. For example, different possible and relevant relationships between BOOK STORE and BOOK(s) are as follows.
A BOOK STORE orders BOOK(s).A BOOK STORE displays BOOK(s).A BOOK STORE stocks BOOK(s).A BOOK STORE sells BOOK(s).A BOOK STORE returns BOOK(s).
Degree of Relationships:
The entities that are participating in a given relationship are known as participants. The number of participants in a given relationship is called degree of relationship. Thus, the relationship "writes" is of degree two because only two entities are participating in this relationship, i.e. AUTHOR and BOOK.
Types of Relationships:
In E-R model, the most common relationship (with respect to degree of relationships) are:
(1) Binary relationship
(2) Unary relationship
(3) Ternary relationship
(1) Binary Relationship:
A relationship type of degree two is called binary relationship. A binary relationship is a relationship between the instances of two entity types. It is the most common type of relationship countered in data modeling.
The binary relationship is further divided into:
a. One-to-one relationship
b. One-to-many relationship
c. Many-to-many relationship
a. One-to-One (1:1) Relationship:
In one-to-one relationship, two entity types are associated in such ft way that for each instance in First entity type, there is only one matching instance in Second entity type. On the other hand, for each instance in Second entity type, there is only one matching instance in First entity type.
Examples:
The following examples show one-to-one relationships:
1. Consider the relationship between COUNTRY and CAPITAL entities.
The above relationship shows that a country has only one capital. On the other hand, a capital belongs to only one country. The sample data is given below.
2. The relationship between PRINCIPAL and COLLEGE entities is given below.
The above relationship shows that a principal runs one college. On the other hand, a college is run by only one principal.
(b) One-to-Many (1:N) Relationship:
In one-to-many relationship, two entity types are associated in such a way that for each instance in First entity type, there can be many matching instances in Second entity type. On the other hand, for each instance in Second entity type, there is only one matching instance in First entity type. For example, a mother may have many children, but a child can have one-to-
one mother. In the E-R diagram, Crow's paw is used to indicate many instances.
Examples:
The following examples show one-to-many relationships:
1. The relationship between STUDENT and TELEPHONE entities is given below.
The above relationship shows that a student may have many telephone numbers. On the other hand, a telephone number belongs to only one student.
2. The relationship between DEPARTMENT and TEACHER entities is given below.
The above relationship shows that a department of a college may have many teachers. On the other hand, a particular teacher belongs to only one department.
c. Many-to-Many (M:N) Relationship:
In many-to-many relationship, two entity types are associated in such a way that for each instance in First entity type, there can be many matching instances in Second entity type. On the other hand, for each instance in Second entity type, there can also be many matching instances in First entity type.
Examples:
The following examples show many-to-many relationships:
1. The relationship between UNCLE and NEPHEW entities is shown below.
The above relationship shows that an uncle may have many nephews, while a nephew may have many uncles.
2. The relationship between PATIENT and DOCTOR entities is given below.
The above relationship shows that a patient may be checked by many doctors. On the other hand, a doctor may check many patients.
3. The relationship between EMPLOYEE and COURSE entities is shown below to track which training courses each of the employee of an organization has completed. The name of the relationship is "completes".
The above relationship shows that each employee may have completed more than one course. On the other hand, each course may be completed by more than one employee. In this way, it can easily be determined which courses of a particular employee has been completed. Similarly, it can also be easily determined which employees have completed a particular course.
Associating Attributes with Relationship:
In many-to-many relationship, attributes may also be associated with the relationship. Suppose date is recorded when an employee of an organization completes any course. The sample data is given below.
EmpID Course Name Date Completed
IT2001 Visual Basic 06-02-2005
MN1006 Accounting 19-12-2004
MN1009 MS-OFFICE 28-01-2006
IT2001 C+ + 10-01-2006
IT2002 Visual Basic 06-02-2005
In the above sample data, the "Date Completed" attribute is not a property of EMPLOYEE and COURSE entities, since a particular course may be completed on different dates. Therefore, "Date Completed" is a property of relationship between EMPLOYEE and COURSE. It means that, there is a "Date Completed" for each instance of an employee and a course. This attribute is associated with the relationship as shown below.
(2) Unary Relationship:
The relationship between the instances of only one entity type (or participant) is known as unary relationship. It is also referred to as recursive relationship. This relationship has degree one.
Like binary relationship, unary relationship is also further divided into:
a. One-to-One relationship
b. One-to-Many relationship
c. Many-to-Many relationship
a. One-to-One Unary Relationship:
The one-to-one unary relationship is represented in the similar way as one-to-one binary relationship. Some examples are given below to explain the concept of one-to-one unary relationship.
Examples:
1. The recursive one-to-one relationship between the instances of DOCTOR entity type is given below.
The above relationship shows that a doctor is treated by another doctor. On the other hand, a doctor treats another doctor.
2. The recursive relationship between the instances of PERSON entity type is given below.
The above relationship shows that a person is married to a person. On the other hand, a person is married by another person.
b. One-to-Many Unary Relationship:
The one-to-many unary relationship is shown in figure below. This relationship is named as 'Manages' that associates employees of an organization with another employee who is their manager.
c. Many-to-Many Unary Relationship:
The many-to-many unary relationship "Treated-By" is given below. It represents the situation in which doctors give treatments to other doctors (doctors as patients).
The above relationship shows that a doctor is treated by many other doctors. On the other hand, a doctor treats many other doctors.
(3) Ternary Relationship:
A ternary relationship is a simultaneous relationship among instances of three entity types. This type of relationship has degree three. An example of ternary relationship is given below. The name of relationship is "Supplies". The Supplier supplies Parts to Project.
The above ternary relationship "Supplies" can be read as "A Supplier can supply many Parts to a particular Project".
Another example of ternary relationship "Teaches" is given below, in which three entities STUDENT, CLASS and TEACHER are associated with each other.
The above ternary relationship "Teaches" can be read as "Many teachers may teach many classes with many students".
Cardinalities of Relationship:
In a relational database model, the number of records in a table (or relation) is called cardinality. However, relationship types usually have certain constraints that limit the number of instances of one entity type that can be associated with each instance of another related entity type.
Therefore, cardinality of a relationship is defined as; the number of instances of one entity type that can be associated with each instance of another related entity type.
Suppose there are two entity types A and B that are connected by a relationship R. If there are no cardinality constraints on R, then any number of instances of A can be associated with any number of instances of B. Usually there are cardinality constraints such as:
If there is one-to-one relationship between A and B, then each instance in A will be associated with exactly one instance in B. Conversely each instance in B will be associated with exactly one instance in A.
If there is one-to-many relationship between A and B, then each instance in A will be associated with many instances in B. On the other hand, each instance in B will be associated with exactly one instance in A.
If there is many-to-many relationship between A and B, then each instance in A will be associated with many instances in B. On the other hand, each instance in B will also be associated with many instances in A.
The cardinality of one is denoted by a small vertical line ( | ) on the relationship line, next to the first entity type or before the second entity type. Similarly, the cardinality of many is denoted by
crow's paw symbol..
For example, a department may have many teachers. On the other hand, a teacher belongs to one department. The relationship between DEPARTMENT and TEACHER is shown below.
Minimum and Maximum Cardinalities:
The minimum number of instances of one entity type that may be associated with each instance of another related entity type is called minimum cardinality. Similarly, the maximum number of instances of one entity type that may be associated with each instance of another related entity type is called maximum cardinalities.
Modality of Relationship:
The modality defines the nature of relationship as either it is optional or mandatory. If the minimum instance in one entity is zero for an instance of another related entity, then the relationship is called optional. The optional relationship is denoted by small circle 'O' on the relationship line.
Similarly, if the minimum instance in one entity is one for an instance of another related entity, then the relationship is referred to as mandatory. It is denoted by a small vertical line ' | ' on the relationship line. If minimum and maximum cardinalities are both one, it is known as Mandatory One Cardinality.
For example, a relationship between STUDENT and TELEPHONE entities given below, which shows 'one optional' and 'one mandatory' cardinality.
Figure: One Optional, One Mandatory Cardinality
In the above figure, the following combined symbols are used to represent the cardinality and modality.
| | After STUDENT entity, the First vertical line represents the cardinality and second vertical line represents the modality of relationship.
Before TELEPHONE entity, the small circle 'O' represents the zero modality, while represents the cardinality.
In the relationship STUDENT Has TELEPHONE, each instance of STUDENT entity may be zero or many associated instances in TELEPHONE entity. On the other hand, each instance of TELEPHONE belongs to exactly one instance in STUDENT entity.
Figures (a) and (b) are given below that show the relationship between TEACHER and CLASS entities and recursive relationship of PERSON entity.
Definition - Explanation of Attribute and Types of Attributes - Simple Attribute - Composite Attribute - Basicsofcomputer.com
A brief description of the above relationships is given below.
1. In the relationship "TEACHER Teaches CLASS", each teacher may teach one or many classes. On the other hand, each class is taught by only one teacher, i.e. each instance of Class belongs to exactly one Teacher.
2. In the relationship "PERSON Is Married To PERSON", there is an optional zero or one cardinality in both directions, since a person may or may not be married.
The notations for relationship cardinalities are shown below.
The Database Terms of Reference (Keys)
Keys are, as their name suggests, a key part of a relational database and a vital part of the structure of a table. They ensure each record within a table can be uniquely identified by one or a combination of fields within the table. They help enforce integrity and help identify the relationship between tables. There are three main types of keys, candidate keys, primary keys and foreign keys. There is also an alternative key or secondary key that can be used, as the name suggests, as a secondary or alternative key to the primary key.
Super Key
A Super key is any combination of fields within a table that uniquely identifies each record within that table.
Candidate Key
A candidate is a subset of a super key. A candidate key is a single field or the least combination of fields that uniquely identifies each record in the table. The least combination of fields distinguishes a candidate key from a super key. Every table must have at least one candidate key but at the same time can have several.
As an example we might have a student_id that uniquely identifies the students in a student table. This would be a candidate key. But in the same table we might have the student’s first name and last name that also, when combined, uniquely identify the student in a student table. These would both be candidate keys.
In order to be eligible for a candidate key it must pass certain criteria.
It must contain unique values
It must not contain null values
It contains the minimum number of fields to ensure uniqueness
It must uniquely identify each record in the table
Once your candidate keys have been identified you can now select one to be your primary key
Primary Key
A primary key is a candidate key that is most appropriate to be the main reference key for the table. As its name suggests, it is the primary key of reference for the table and is used throughout the database to help establish relationships with other tables. As with any candidate key the primary key must contain unique values, must never be null and uniquely identify each record in the table.
As an example, a student id might be a primary key in a student table, a department code in a table of all departments in an organisation. This module has the code DH3D 35 that is no doubt used in a database somewhere to identify RDBMS as a unit in a table of modules. In the table below we have selected the candidate key student_id to be our most appropriate primary key
Primary keys are mandatory for every table each record must have a value for its primary key. When choosing a primary key from the pool of candidate keys always choose a single simple key over a composite key.
Foreign Key
A foreign key is generally a primary key from one table that appears as a field in another where the first table has a relationship to the second. In other words, if we had a table A with a primary key X that linked to a table B where X was a field in B, then X would be a foreign key in B.
An example might be a student table that contains the course_id the student is attending. Another table lists the courses on offer with course_id being the primary key. The 2 tables are linked through course_id and as such course_id would be a foreign key in the student table.
Secondary Key or Alternative Key
A table may have one or more choices for the primary key. Collectively these are known as candidate keys as discuss earlier. One is selected as the primary key. Those not selected are known as secondary keys or alternative keys.
For example in the table showing candidate keys above we identified two candidate keys, studentId and firstName + lastName. The studentId would be the most appropriate for a primary key leaving the other candidate key as secondary or alternative key. It should be noted for the other key to be candidate keys, we are assuming you will never have a person with the same first and last name combination. As this is unlikely we might consider fistName+lastName to be a suspect candidate key as it would be restrictive of the data you might enter. It would seem a shame to not allow John Smith onto a course just because there was already another John Smith.
Simple Key
Any of the keys described before (ie primary, secondary or foreign) may comprise one or more fields, for example if firstName and lastName was our key this would be a key of two fields where as studentId is only one. A simple key consists of a single field to uniquely identify a record. In addition the field in itself cannot be broken down into other fields, for example,
studentId, which uniquely identifies a particular student, is a single field and therefore is a simple key. No two students would have the same student number.
Compound Key
A compound key consists of more than one field to uniquely identify a record. A compound key is distinguished from a composite key because each field, which makes up the primary key, is also a simple key in its own right. An example might be a table that represents the modules a student is attending. This table has a studentId and a moduleCode as its primary key. Each of the fields that make up the primary key are simple keys because each represents a unique reference when identifying a student in one instance and a module in the other.
Composite
A composite key consists of more than one field to uniquely identify a record. This differs from a compound key in that one or more of the attributes, which make up the key, are not simple keys in their own right. Taking the example from compound key, imagine we identified a student by their firstName + lastName. In our table representing students on modules our primary key would now be firstName + lastName + moduleCode. Because firstName + lastName represent a unique reference to a student, they are not each simple keys, they have to be combined in order to uniquely identify the student. Therefore the key for this table is a composite key.
