Module 1: Introduction to Database

Management System (PART 1)

- By Tina D’abreo
Content
➔ Entity–Relationship Model:
◆ Relationship constraints: Cardinality and Participation
➔ Extended Entity-Relationship (EER) Model:
◆ Generalization, Specialization and Aggregation
➔ Relational Model:
◆ Introduction to the Relational Model
◆ Relational schema and concept of keys
◆ Mapping the ER and EER Model to the Relational Model
➔ Relational Algebra
◆ Unary and Set operations
◆ Relational Algebra Queries
Entity–Relationship (ER) Model
➔ Entity-Relationship (ER) model, which is a popular high-level conceptual data model.
➔ This model and its variations are frequently used for the conceptual design of database
applications, and many database design tools employ its concepts.
➔ It develops a conceptual design for the database. It also develops a very simple and easy to
design view of data.
➔ In ER modeling, the database structure is portrayed as a diagram called an
entity-relationship diagram.
➔ The ER model describes data as Entities, relationships, and attributes.
Entity–Relationship Model
Entity–Relationship Model
➔ Entity:
◆ The basic object that the ER model represents is an entity, which is a thing in the real
world with an independent existence.
◆ An entity may be an object with a physical existence (for example, a particular
person, car, house, or employee) or it may be an object with a conceptual existence
(for instance, a company, a job, or a university course).
◆ example : entities such as teachers, students, courses, buildings, departments, etc.
Entity–Relationship Model
➔ Types of Entities:
◆ Strong Entity:
● It is an entity that has its own existence and is independent.
● A strong entity is not dependent on any other entity in the schema.
● A strong entity will always have a primary key.
● Strong entities are represented by a single rectangle.
● The relationship of two strong entities is represented by a single diamond.
● Various strong entities, when combined together, create a strong entity set.
Entity–Relationship Model
➔ Types of Entities:
◆ Weak Entity:
● A weak entity is dependent on a strong entity to ensure its existence.
● Unlike a strong entity, a weak entity does not have any primary key. It instead has a partial
discriminator key.
● A weak entity is represented by a double rectangle. The relation between one strong and
one weak entity is represented by a double diamond.
● This relationship is also known as identifying relationship.
Entity–Relationship Model
➔ Types of Entities:
◆ Weak Entity:
Entity–Relationship Model
➔ Attributes:
◆ Each entity has attributes—the particular properties that describe it.
◆ For example, an EMPLOYEE entity may be described by the employee’s name, age,
address, salary, and job.
◆ A particular entity will have a value for each of its attributes.
◆ The attribute values that describe each entity become a major part of the data stored
in the database.
Entity–Relationship Model
➔ Types of Attributes:
◆ Simple Attributes
◆ Simple Attributes
◆ Composite Attributes
◆ Single Valued Attributes
◆ Multi-Valued Attributes
◆ Derived Attributes
◆ Complex Attributes (Rarely used attributes)
◆ Key Attributes
◆ Stored Attributes
Entity–Relationship Model
➔ Types of Attributes:
◆ Simple Attributes
● Simple attributes in an ER model diagram are independent attributes that can't be
classified further and also, can't be subdivided into any other component.
● These attributes are also known as atomic attributes.
Entity–Relationship Model
➔ Types of Attributes:
◆ Composite Attributes
● Composite attributes have opposite functionality to of simple attributes as we can
further subdivide composite attributes into different components or sub-parts that
form simple attributes.
● In simple terms, composite attributes are composed of one or more simple
attributes.
Entity–Relationship Model
➔ Types of Attributes:
◆ Single Valued Attributes
● Single-valued attributes are those attributes that consist of a single value for each
entity instance and can't store more than one value.
● The value of these single-valued attributes always remains the same, just like the
name of a person.
Entity–Relationship Model
➔ Types of Attributes:
◆ Multi-Valued Attributes
● Multi-valued attributes have opposite functionality to that of single-valued attributes,
and as the name suggests, multi-valued attributes can take up and store more than one
value at a time for an entity instance from a set of possible values.
● These attributes are represented by co-centric elliptical shape, and we can also use curly
braces { } to represent multi-valued attributes inside it.
Entity–Relationship Model
➔ Types of Attributes:
◆ Derived Attributes
● Derived attributes in DBMS are those attributes whose values can be derived
from the values of other attributes.
● They are always dependent upon other attributes for their value.
● Represented by dotted ellipse.
Entity–Relationship Model
➔ Types of Attributes:
◆ Complex Attributes (Rarely used attributes)
● Complex attributes are rarely used in DBMS. They are formed by the
combination of multi-valued and composite attributes.
● These attributes always have many sub-sections in their values.
Entity–Relationship Model
➔ Types of Attributes:
◆ Key Attributes
● Key attributes are special types of attributes that act as the primary key for an
entity and they can uniquely identify an entity from an entity set.
● The values that key attributes store must be unique and non-repeating.
Entity–Relationship Model
➔ Types of Attributes:
◆ Stored Attributes
● Values of stored attributes remain constant and fixed for an entity instance and also, and they
help in deriving the derived attributes.
● For example, the Age attribute can be derived from the Date of Birth attribute, and also, the
Date of birth attribute has a fixed and constant value throughout the life of an entity.
● Hence, the Date of Birth attribute is a stored attribute.
Entity–Relationship Model
➔ Relationship:
◆ A relationship type R among n entity types E1, E2, ..., En defines a set of
associations—or a relationship set—among entities from these entity types.
◆ The example below, both the student and the course are entities, and study is the
relationship between them.
Entity–Relationship Model
➔ Relationship:
◆ A relationship type R among n entity types E1, E2, ..., En defines a set of
associations—or a relationship set—among entities from these entity types.
◆ The example below, both the student and the course are entities, and study is the
relationship between them.
Entity–Relationship Model
➔ Relationship:
◆ Cardinality: Defines the numerical attributes of the relationship between two entities
or entity sets.
◆ A relationship is represented by diamond shape in ER diagram, it shows the
relationship among entities. There are four types of cardinal relationships:
● One to One
● One to Many
● Many to One
● Many to Many
Entity–Relationship Model
➔ Relationship:
◆ One to One:
● When a single element of an entity is associated with a single element of
another entity, it is called a one-to-one relationship.
● Example: a student has only one identification card and an identification card
is given to one person.
Entity–Relationship Model
➔ Relationship:
◆ One to Many:
● 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
● Example: a customer can place many orders, but an order cannot be placed by
many customers.
Entity–Relationship Model
➔ Relationship:
◆ Many to One:
● 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.
● Example students have to opt for a single course, but a course can have many
students.
Entity–Relationship Model
➔ Relationship:
◆ Many to Many:
● 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.
● Example: an employee is assigned to many projects and a project can have
many employees.
Entity–Relationship Model
➔ Participation:
◆ Participation Constraints in database management refer to rules that determine the
minimum and maximum participation of entities or relationships in a given
relationship set.
● Total Participation
● Partial Participation
◆ For example, in a College Database, partial participation would permit courses with
no enrolled students, while entire participation might require all students to be
enrolled in at least one course.
 Entity–Relationship Model
➔ Participation:
◆ Total Participation:
● It specifies that each student must be enrolled in
at least one course where the “student” is the
entity set and relationship “enrolled in”
signifies total participation
● It means that every student must have enrolled
at least in one course
● It is represented using a double line between the
entity set and relationship set
 Entity–Relationship Model
➔ Participation:
◆ Partial Participation:
● It specifies that each entity in the entity set may or
may not participate in the relationship instance of
the relationship set, is also called as optional
participation
● It is represented using a single line between the
entity set and relationship set in the ER diagram
● A single line between the entities i.e courses and
enrolled in a relationship signifies the partial
participation,which means there might be some
courses where enrollments are not made i.e
enrollments are optional in that case
Extended Entity–Relationship (EER) Model
➔ The existing ER model needs to be enhanced or improved in order for it to better handle
the complicated application in order to reduce the modeling complexity.
➔ The requirements and complexity of complicated databases are represented using
enhanced entity-relationship diagrams, which are sophisticated database diagrams very
similar to standard ER diagrams.
➔ It includes the concepts of:
◆ SubClass and SuperClass
◆ Specialization and Generalization
◆ Union or Category
◆ Aggregation
Extended Entity–Relationship (EER) Model
➔ SubClass and SuperClass
◆ Entity type has numerous subgroupings or subtypes of its entities that are
meaningful and need to be represented explicitly because of their significance to the
database application
◆ For example, the entities that are members of the EMPLOYEE entity type may be
distinguished further into SECRETARY, ENGINEER, MANAGER, TECHNICIAN,
SALARIED_EMPLOYEE, HOURLY_EMPLOYEE, and so on.
◆ These subgroupings a subclass or subtype of the EMPLOYEE entity type, and the
EMPLOYEE entity type is called the superclass or supertype for each of these
subclasses.
◆ EMPLOYEE/SECRETARY and EMPLOYEE/TECHNICIAN are two
class/subclass relationships
Extended Entity–Relationship (EER) Model
➔ SubClass and SuperClass
◆ An entity cannot exist in the database merely by being a member of a subclass; it
must also be a member of the superclass. Such an entity can be included optionally
as a member of any number of subclasses.
◆ A salaried employee who is also an engineer belongs to the two subclasses:
● ENGINEER
● SALARIED_EMPLOYEE
◆ A salaried employee who is also an engineering manager belongs to the three
subclasses:
● MANAGER
● ENGINEER
● SALARIED_EMPLOYEE
Extended Entity–Relationship (EER) Model
➔ SubClass and SuperClass
◆ An entity that is a member of a subclass inherits all the attributes of the entity as a
member of the superclass.
◆ The entity also inherits all the relationships in which the superclass participates.
Extended Entity–Relationship (EER) Model
Extended Entity–Relationship (EER) Model
➔ Specialization:
◆ Specialization is the process of defining a set of subclasses of an entity type
◆ This entity type is called the superclass of the specialization.
◆ The set of subclasses that forms a specialization is defined on the basis of some
distinguishing characteristic of the entities in the superclass.
◆ For example, the set of subclasses {SECRETARY, ENGINEER, TECHNICIAN} is
a specialization of the superclass EMPLOYEE that distinguishes among employee
entities based on the job type of each employee entity.
◆ For example, another specialization of the EMPLOYEE entity type may yield the
set of subclasses {SALARIED_EMPLOYEE, HOURLY_EMPLOYEE}; this
specialization distinguishes among employees based on the method of pay
Extended Entity–Relationship (EER) Model
➔ Specialization:
◆ Attributes of a subclass are called specific or local attributes.
◆ For example, the attribute Typing Speed of SECRETARY
Extended Entity–Relationship (EER) Model
disjoint ,
partial
Extended Entity–Relationship (EER) Model
➔ Generalization
◆ A reverse process of abstraction in which we suppress the differences among several
entity types, identify their common features, and generalize them into a single
superclass of which the original entity types are special subclasses.
◆ The generalization process can be viewed as being functionally the inverse of the
specialization process.
◆ {CAR, TRUCK} can be viewed as a specialization of VEHICLE, rather than
viewing VEHICLE as a generalization of CAR and TRUCK.
◆
Extended Entity–Relationship (EER) Model
Disjoint,
total
constraints
Extended Entity–Relationship (EER) Model
➔ If all subclasses in a specialization have their membership condition on the same attribute
of the superclass, the specialization itself is called an attribute-defined specialization,
and the attribute is called the defining attribute of the specialization.
➔ Check diagram → ‘Job Type’
Extended Entity–Relationship (EER) Model
➔ Two basic constraints can apply to a specialization/generalization:
◆ Disjointness Constraint:
● Specifies that the subclasses of the specialization must be disjoint
● An entity can be a member of at most one of the subclasses of the
specialization
● Specified by d in EER diagram
● If not disjoint, specialization is overlapping: that is the same entity may be a
member of more than one subclass of the specialization
● Specified by o in EER diagram
Extended Entity–Relationship (EER) Model
➔ Two basic constraints can apply to a specialization/generalization:
◆ Completeness Constraint:
● The second constraint on specialization is called the completeness (or totalness) constraint,
which may be total or partial.
● A total specialization constraint specifies that every entity in the superclass must be a
member of at least one subclass in the specialization.
● For example, if every EMPLOYEE must be either an HOURLY_EMPLOYEE or a
SALARIED_EMPLOYEE, then the specialization {HOURLY_EMPLOYEE,
SALARIED_EMPLOYEE} (8.1)
● Double line is used to connect the superclass to the circle.
● A single line is used to display a partial specialization,which allows an entity not to belong
to any of the subclasses.
● For example, if some EMPLOYEE entities do not belong to any of the subclasses
{SECRETARY, ENGINEER, TECHNICIAN}
Extended Entity–Relationship (EER) Model
overlapping,
total
constraints
Extended Entity–Relationship (EER) Model
➔ Two basic constraints can apply to a specialization/generalization:
◆ Completeness Constraint:
● In general, a superclass that was identified through the generalization
process usually is total, because the superclass is derived from the subclasses
and hence contains only the entities that are in the subclasses.
Extended Entity–Relationship (EER) Model
➔ Union or Category
◆ All of the superclass/subclass relationships we have seen thus far have a single
superclass
◆ A shared subclass is a subclass in: more than one distinct superclass/subclass
relationships each relationships has a single superclass shared subclass leads to
multiple inheritance
◆ In some cases, we need to model a single, superclass/subclass relationship with
more than one superclass
◆ Superclasses can represent different entity types. Such a subclass is called a
category or UNION TYPE
Extended Entity–Relationship (EER) Model
➔ Union or Category
◆ Example: In a database for vehicle registration, a vehicle owner can be a PERSON,
a BANK (holding a lien on a vehicle) or a COMPANY.
◆ A category (UNION type) called OWNER is created to represent a subset of the
union of the three superclasses COMPANY, BANK, and PERSON
◆ A category member must exist in at least one of its superclasses
◆ Difference from shared subclass, which is a:
● subset of the intersection of its superclasses
● shared subclass member must exist in all of its superclasses
Extended Entity–Relationship (EER) Model
Extended Entity–Relationship (EER) Model
➔ Union or Category
◆ For example, suppose that we have three entity types: PERSON, BANK, and COMPANY. In a
database for motor vehicle registration, an owner of a vehicle can be a person, a bank (holding a
lien on a vehicle), or a company.
◆ We need to create a class (collection of entities) that includes entities of all three types to play the
role of vehicle owner.
◆ A category (union type) OWNER that is a subclass of the UNION of the three entity sets of
COMPANY, BANK, and PERSON can be created for this purpose.
◆ The superclasses COMPANY, BANK, and PERSON are connected to the circle with the ∪
symbol, which stands for the set union operation. An arc with the subset symbol connects the circle
to the (subclass) OWNER category.
◆ If a defining predicate is needed, it is displayed next to the line from the superclass to which the
predicate applies.
◆ In Figure 8.8 we have two categories: OWNER, which is a subclass of the union of PERSON,
BANK, and COMPANY; and REGISTERED_VEHICLE, which is a subclass of the union of CAR
and TRUCK.
Extended Entity–Relationship (EER) Model
➔ Aggregation:
◆ Aggregation is a concept wherein the connection between two entities is considered
as one unified entity. It includes combining the relationships with their respective
entities into a better-degree entity.
Extended Entity–Relationship (EER) Model
➔ Aggregation: