CUAP DBMS Notes Unit2 2021
CUAP DBMS Notes Unit2 2021
CUAP DBMS Notes Unit2 2021
Our focus now is on the second phase, conceptual design, for which The Entity-Relationship
(ER) Model is a popular high-level conceptual data model.
In the ER model, the main concepts are entity, attribute, and relationship.
1
DATABASE MANAGEMENT SYSTEMS
EX:
EMPLOYEE
Weak Entity: An entity which is depend upon another entity for its existence. Then that type
of entity can be known as a weak entity
A weak entity can be represented by double rectangle DEPENDENT
NOTE: A strong entity is having primary key attributes whereas a weak entity cannot have
primary key attributes.
Entity Set:
2
DATABASE MANAGEMENT SYSTEMS
Entity Set:
An entity set is a set of entities of the same type that share the same properties, or
attributes.
Ex: The set of all persons who are customers at a given bank.
Attributes:
Attributes are characteristics or properties of entities.
For example, the EMPLOYEES entity includes the attributes SSN, NAME, and LOT
In the original Chen notation, attributes are represented by ovals and are connected
to the entity rectangle with a line. Each oval contains the name of the attribute it
represents.
Required Attribute:
A Required attribute is an attribute that must have a value i.e., it cannot be left empty. I n
Crow’s foot notation, such attributes are indicated in bold face
Optional Attribute:
An Optional attribute is an attribute that does not require a value. Therefore, it can be left
empty.
Domains:
Attributes have a domain. A Domain is a set of possible values for a given attributes.
For example, the domain for the (numeric) attribute grade point average (GPA) is written
(0, 4) because the lowest possible GPA value is 0, and the highest possible value is 4. The
domain for the attribute SEX consists of only two possibilities, M or F.
Types of Attributes:
To describe the structure of a composite attribute, one can draw a tree as shown in below
figure.
3
DATABASE MANAGEMENT SYSTEMS
In case we are limited to using text, it is customary to write its name followed by a
parenthesized list of its sub-attributes. For the examples mentioned in below figure, we
would write
BirthDate(Month,Day,Year)
Address(StreetAddr(StrNum, StrName, AptNum), City, State, Zip)
Atomic attribute:
An atomic attribute is indivisible or indecomposable. For example, age, sex, marital status
would be classified as Simple attributes.
4
DATABASE MANAGEMENT SYSTEMS
year. Thus, AcademicDegrees is not only multi-valued but also composite. We refer to an
attribute that involves some combination of multi-valuedness and compositeness as a
complex attribute.
Stored Attribute:
The value of some attributes can’t be derived such type of attributes is known as
Stored Attributes.
Example: The attributes accno, DOB can’t be derived using some other attributes.
Advantages and Disadvantages of Storing Derived attributes
4. The Null value: In some cases, a particular entity might not have an applicable value
for a particular attribute. Or that value may be unknown. Or, in the case of a multi-valued
attribute, the appropriate value might be the empty set.
Example: The attribute DateOfDeath is not applicable to a living person and its correct value
5
DATABASE MANAGEMENT SYSTEMS
In such cases, we use a special attribute value (non-value?), called null. There has been
some argument in the database literature about whether a different approach (such as having
distinct values for not applicable and unknown) would be superior.
5. Complex Attribute:
For an entity, if an attribute is made using the multi valued attributes and composite
attributes then it is known as complex attributes.
• Example: A person can have more than one residence; each residence can have more
than one phone.
6. Key Attributes:
This attribute represents the main characteristic of an entity i.e. primary key. Key
attribute has clearly different value for each element in an entity set.
• Example: The entity student ID is a key attribute because no other student will have
the same ID.
7. Non-Key Attributes:
These are attributes other than candidate key attributes in a table. For example, Firstname
is a non-key attribute as it does not represent the main characteristics of the entity.
8. Required Attribute: A required attribute is an attribute that must have a
data value. These attributes are required because they describe what is
important in the entity. For example, in a STUDENT entity, firstname and
lastname is a required attribute. In the above example there are two bold
faced attributes, this indicates that data is required for that attributes.
Suppose that Requirements Collection and Analysis results in the following (informal)
description of the COMPANY miniworld:
6
DATABASE MANAGEMENT SYSTEMS
➢ Each department
o has a unique name
o has a unique number
o is associated with a set of locations
o has a particular employee who acts as its manager (and who assumed that
position on some date)
o has a set of employees assigned to it
o controls a set of projects
➢ Each project
o has a unique name
o has a unique number
o has a single location
o has a set of employees who work on it
o is controlled by a single department
➢ Each employee
o has a name
o has an SSN that uniquely identifies her/him
o has an address
o has a salary
o has a sex
o has a birth date
o has a direct supervisor
o has a set of dependents
o is assigned to one department
o works some number of hours per week on each of a set of projects (which
neednot all be controlled by the same department)
➢ Each dependent
o has first name
o has a sex
o has a birth date
o is related to a particular employee in a particular way (e.g., child, spouse, pet)
o is uniquely identified by the combination of her/his first name and the employee
of which (s)he is a dependent.
Using the above structured description as a guide, we get the following preliminary design for
entity types and their attributes in the COMPANY database:
7
DATABASE MANAGEMENT SYSTEMS
Note: Note that the attribute WorksOn of EMPLOYEE (which records on which projects the
employee works) is not only multi-valued (because there may be several such projects) but also
composite, because we want to record, for each such project, the number of hours per week that
the employee works on it. Also, each candidate key has been indicated by underlining.
For similar reasons, the attributes Manager and ManagerStartDate of DEPARTMENT really
ought to be combined into a single composite attribute. Not doing so causes little or no
harm, however, because these are single-valued attributes. Multi-valued attributes would pose
some difficulties, on the other hand. Suppose, for example, that a department could have two or
more managers, and that some department had managers Mary and Harry, whose start dates were
10- 4-1999 and 1-13-2001, respectively. Then the values of the Manager and
ManagerStartDate attributes should be { Mary, Harry } and { 10-4-1999, 1-13-2001 }. But
from these two attribute values, there is no way to determine which manager started on
which date. On the other hand, by recording this data as a set of ordered pairs, in which
each pair identifies amanager and her/his starting date, this deficiency is eliminated.
8
DATABASE MANAGEMENT SYSTEMS
Relationship:
• The relationship is an association between entities.
• The entities that participate in a relationship are also known as participants, and each
relationship is identified by a name that describes the relationship.
• The relationship name is an active or passive verb.
• For example, a STUDENT takes a CLASS, a PROFESSOR teaches a CLASS, a
DEPARTMENT employs a PROFESSOR and an AIRCRAFT is flown by CREW
Relationships between entities always operate in both directions. For example, to define
the relationship between the entities named CUSTOMER and INVOICE, we can specify
that:
• A CUSTOMER may generate many INVOICEs
• Each INVOICE is generated by one CUSTOMER.
This relationship can be classified as 1: M
The relationship between DIVISION and EMPLOYEE can be specified as
• A DIVISION is managed by one EMPLOYEE
• An EMPLOYEE may manage only one DIVISION. This relationship is in 1:1
Relationship set
• Relationship set is a set of relationships of the same type.
Recursive relationship set
• The same entity set participates in a relationship set more than once then it is
called recursive relationship set.
• E.g.: An Employee entity participated in relationship under with department
entity as an employee as well manager also.
Connectivity and Cardinality:
The term Connectivity is used to describe the relationship classification.
Cardinality expresses the minimum and maximum number of entity occurrences associated
with one occurrence of the related entity.
In the ERD, cardinality is indicated by placing the appropriate numbers besides the
entities, using the format (x, y).The first value represents the minimum no. of
associated entities and the second value represents the maximum no. of associated
entities
As you examine the Chen model in Figure, Chen cardinalities represent the number of
occurrences in the related entity. For example, the cardinality (1,4) written next to the
PROFESSOR entity in the "PROFESSOR teaches CLASS" relationship indicates that the
PROFESSOR table's foreign key value occurs at least once and no more than four times
in the CLASS table. Similarly, the cardinality (1, 1) written next to the CLASS entity
indicates that each class is taught by one and only one professor.
9
DATABASE MANAGEMENT SYSTEMS
RELATIONSHIP PARTICIPATION
Participation in an entity relationship is either optional or mandatory.
Optional: Participation is optional if one Entity occurrence does not require a
corresponding entity occurrence in a particular relationship.
For example, “COURSE generates CLASS" relationship, an entity occurrence (row) in the
COURSE table does not necessarily require the existence of a corresponding entity
occurrence in the CLASS table.
Therefore, the CLASS entity is considered to be optional to the COURSE
entity.
In the Chen and Crow's Foot models, an optional relationship between entities is
shown by drawing a small circle (0) on the side of the optional entity, as shown in
Figure below. The existence of optionality indicates that the minimum cardinality is 0 for
the optional entity.
10
DATABASE MANAGEMENT SYSTEMS
terms, each COURSE in the "generates" relationship must have at least one CLASS.
Therefore, a CLASS must be created as the COURSE is created.
Relationship Degree:
A relationship's degree indicates the number of associated entities
or participants associated with a relationship.
A unary relationship exists when an association is maintained within a
single entity.
A binary relationship exists when two entities are associated.
A ternary relationship exists when three entities are associated.
Unary Relationship:
In Unary relationship shown in below fig, an employee within
the EMPLOYEE entity is the manager for one or more employees
within that entity. In this case, the existence of the “manages
“relationship means that EMPLOYEE requires another EMPLOYEE
to be the manager-that is EMPLOYEE has a relationship with
itself. Such a relationship is known as a Recursive Relationship.
Binary Relationship:
A Binary relationship exists when two entities are associated in a relationship .TO simplify the
conceptual design, whenever possible, most higher order relationships are decomposed into
appropriate equivalent binary relationships. In the figure, “a PROFESSOR teaches one or more
CLASSes” represents a binary relationship.
11
DATABASE MANAGEMENT SYSTEMS
Recursive Relationships:
A recursive relationship is one in which a relationship can exist between occurrences of
the same entity set.
For example, a 1: M unary relationship can be expressed by “an Employee may manage
many EMPLOYEEs and each EMPLOYEE is managed by one EMPLOYEE.”
Finally, the M: N unary relationship may be expressed by a “COURSE may be a
prerequisite to many other COURSEs, and each COURSE may have many other
COURSEs as prerequisites “
Types of Relationships:
A relationship describes an association among entities. Data models use three types of
relationships:
• one-to-many(1:M)
• many-to-many (M: N)
• one-to-one (1:1)
12
DATABASE MANAGEMENT SYSTEMS
A painter paints many different paintings, but each one of them is painted by only one
painter. Thus, the painter (the “one”) is related to the paintings (the “many”). Therefore,
database designers label the relationship “PAINTER paints PAINTING” as 1: M.
13
DATABASE MANAGEMENT SYSTEMS
Existence Dependency:
If an entity's existence depends on the existence of one or more other entities,
it is said to be Existence-dependent.
For Example, if an XYZ Corporation employee wants to claim one or more
dependents for tax, the relationship is "EMPLOYEE claims DEPENDENT". In this case,
the DEPENDENT entity is clearly existence-dependent on the EMPLOYEE entity,
because it is impossible for the dependent to exist apart from the EMPLOYEE in the
XYZ Company's database.
If an en tit y c a n e x i s t a p a r t f r o m o n e o r m o r e r el a t e d e n t i t i e s , i t i s s a i d t o b e
Existence-independent (strong entity).
In this case, a weak relationship exists between COURSE and CLASS, because the
CLASS CODE is the CLASS entity's PK, while the CRS_CODE in CLASS is only an FK.
In this case, the CLASS PK did not inherit the PK component from the COURSE
entity. Figure below shows that the Crow's Foot model depicts a weak
relationship by placing a dashed relationship line between the related entities.
The Chen model does not make a distinction between weak and strong
relationships.
14
DATABASE MANAGEMENT SYSTEMS
Below Figure shows that the Crow's Foot model depicts the strong (identifying)
relationship with a solid line between the entities
The Chen’s model identifies the weak entity by using a double-walled entity rectangle.
15
DATABASE MANAGEMENT SYSTEMS
A strong (identifying) relationship indicates that the related entity is weak, because such
a relationship means that both conditions for the weak entity definition have been met-
the related entity is existence-dependent and the PK of the related entity contains a
PK component of the parent entity
16
DATABASE MANAGEMENT SYSTEMS
ER-Diagram Notations:
17
DATABASE MANAGEMENT SYSTEMS
18