2.

4 The Database System Environment

• 2.4.1 DBMS Component Modules
 2.4.2 Database System Utilities
• Loading
• Backup
• Database storage reorganization
• Performance monitoring
 2.4.3 Tools, Application Environments, and
Communications Facilities
• data dictionary (or data repository) system
• information repository
• Application development environments
• communications software
3.3 Entity Types, Entity Sets, Attributes, and
Keys
• 3.3.1 Entities and Attributes
• Composite versus Simple (Atomic) Attributes
• Single-Valued versus Multivalued Attributes
• Stored versus Derived Attributes
• NULL Values
• Complex Attributes
 3.3.2 Entity Types, Entity Sets, Keys, and
Value Sets
• Entity Types and Entity Sets.
• Key Attributes of an Entity Type
• Value Sets (Domains) of Attributes
Using High-Level Conceptual Data Models
for Database Design
3.2 A Sample Database Application
• The company is organized into departments. Each department has a unique
name, a unique number, and a particular employee who manages the
department. We keep track of the start date when that employee began
managing the department. A department may have several locations.
• A department controls a number of projects, each of which has a unique name,
a unique number, and a single location.
• The database will store each employee’s name, Social Security number,2
address, salary, gender, and birth date. An employee is assigned to one
department, but may work on several projects, which are not necessarily
controlled by the same department. It is required to keep track of the current
number of hours per week that an employee works on each project, as well as
the direct supervisor of each employee (who is another employee).
• The database will keep track of the dependents of each employee for insurance
purposes, including each dependent’s first name, gender, birth date, and
relationship to the employee.
 3.3.3 Initial Conceptual Design of the
COMPANY Database
• We can now define the entity types for the COMPANY database, based on the requirements
described in Section 3.2. According to the requirements listed in Section 3.2, we can identify
four entity types—
• 1. An entity type DEPARTMENT with attributes Name, Number, Locations, Manager, and
Manager_start_date. Locations is the only multivalued attribute. We can specify that both
Name and Number are (separate) key attributes because each was specified to be unique.
• 2. An entity type PROJECT with attributes Name, Number, Location, and
Controlling_department. Both Name and Number are (separate) key attributes.
• 3. An entity type EMPLOYEE with attributes Name, Ssn, Gender, Address, Salary, Birth_date,
Department, and Supervisor. Both Name and Address may be composite attributes; however,
this was not specified in the requirements. We must go back to the users to see if any of
them will refer to the individual components of Name—First_name, Middle_initial,
Last_name—or of Address. In our example, Name is modeled as a composite attribute,
whereas Address is not, presumably after consultation with the users.
• 4. An entity type DEPENDENT with attributes Employee, Dependent_name, Gender,
Birth_date, and Relationship (to the employee). Another requirement is that an employee
can work on several projects, and the database has to store the number of hours per week an
employee works on each project. This requirement is listed as part of the third requirement
in Section 3.2, and it can be represented by a multivalued composite attribute of EMPLOYEE
called Works_on with the simple components (Project, Hours).
 3.4 Relationship Types, Relationship Sets,
Roles, and Structural Constraints
• When an attribute of one entity type refers to another entity
type, some relationship exists.
• For example, the attribute Manager of DEPARTMENT refers to
an employee who manages the department;
• The attribute Controlling_department of PROJECT refers to the
department that controls the project;
• The attribute Supervisor of EMPLOYEE refers to another
employee (the one who supervises this employee);
• The attribute Department of EMPLOYEE refers to the
department for which the employee works; and so on. In the
ER model, these references should not be represented as
attributes but as relationships.
 3.4.1 Relationship Types, Sets, and
Instances
3.4.1 Relationship Types, Sets, and Instances

• 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.
• Mathematically, the relationship set R is a set of relationship
instances ri, where each ri associates n individual entities (e1,
e2, . . . , en)
• Hence, a relationship set can be defined as a subset of the Cartesian
product of the entity sets E1 × E2 × . . . × En. Each of the entity types
E1, E2, . . . , En is said to participate in the relationship type R;
similarly, each of the individual entities e1, e2, . . . , en is said to
participate in the relationship instance ri = (e1, e2, . . . , en).
 3.4 Relationship Types, Relationship Sets,
Roles, and Structural Constraints
• 3.4.1 Relationship Types, Sets, and Instances
3.4.2 Relationship Degree, Role Names, and
Recursive Relationships
• a)Degree of a Relationship Type
-Binary
• -Ternary
b)Relationships as
Attributes.
• In attribute Department of the
EMPLOYEE entity type, the value of
Department for each EMPLOYEE entity
is the DEPARTMENT entity for which
that employee works.
• The value set for this Department
attribute is the set of all DEPARTMENT
entities, which is the DEPARTMENT
entity set.
• The alternative point of view is to
think of a multivalued attribute
Employees of the entity type
DEPARTMENT whose value for each
DEPARTMENT entity is the set of
EMPLOYEE entities who work for that
department.
• The value set of this Employees
attribute is the power set of the
EMPLOYEE entity set.
• Either of these two attributes—
Department of EMPLOYEE or
Employees of DEPARTMENT—can
represent the WORKS_FOR
relationship type.
c)Role Names and Recursive Relationships
3.4.3 Constraints on
Binary Relationship
Types
• Relationship types usually
have certain constraints that
limit the possible
combinations of entities
that may participate in the
corresponding relationship
set.
• These constraints are
determined from the
miniworld situation that the
relationships represent.
• For example, in Figure 3.9, if
the company has a rule that
each employee must work
for exactly one department.
 2 types of binary relationship constraints:
cardinality ratio and participation
a)Cardinality Ratios for Binary Relationships.
- maximum number of relationship instances that an entity can
participate in
• 1:1 relationship
• 1:N relationship

Note- no maximum (N) or a maximum of one (1)

• M:N relationship
 b)Participation Constraints and Existence
Dependencies
• The participation constraint specifies whether the
existence of an entity depends on its being related
to another entity via the relationship type.
• This constraint specifies the minimum number of
relationship instances that each entity can
participate in and is sometimes called the minimum
cardinality constraint.
• Cardinality ratio and participation constraints, taken
together, as the structural constraints of a
relationship type.
Total Participation Partial
Participation
(minimum of one) (no minimum)
 3.4.4 Attributes of Relationship Types
• Relationship types can also have attributes,
similar to those of entity types
-for 1:1 relationship
-for 1:N relationship
-for M:N relationship
• 3.5 Weak Entity Types
• Identifying entity type (parent entity type/dominant
entity type/owner entity type)
• Identifying relationship
• Weak entity type(child entity type/dominant entity type)
• A weak entity type always has a total participation
constraint (existence dependency) with respect to its
identifying relationship because a weak entity cannot be
identified without an owner entity
• Partial key(discriminator)
 3.6 Refining the ER Design for the
COMPANY Database
■ MANAGES, which is a 1:1(one-to-one) relationship type between EMPLOYEE and DEPARTMENT.
EMPLOYEE participation is partial. DEPARTMENT participation is not clear from the requirements.
We question the users, who say that a department must have a manager at all times, which
implies total participation. The attribute Start_date is assigned to this relationship type.
■ WORKS_FOR, a 1:N (one-to-many) relationship type between DEPARTMENT and EMPLOYEE.
Both participations are total.
■ CONTROLS, a 1:N relationship type between DEPARTMENT and PROJECT. The participation of
PROJECT is total, whereas that of DEPARTMENT is determined to be partial, after consultation
with the users indicates that some departments may control no projects.
■ SUPERVISION, a 1:N relationship type between EMPLOYEE (in the supervisor role) and
EMPLOYEE (in the supervisee role). Both participations are determined to be partial, after the
users indicate that not every employee is a supervisor and not every employee has a supervisor.
■ WORKS_ON, determined to be an M:N (many-to-many) relationship type with attribute Hours,
after the users indicate that a project can have several employees working on it. Both
participations are determined to be total.
■ DEPENDENTS_OF, a 1:N relationship type between EMPLOYEE and DEPENDENT, which is also
the identifying relationship for the weak entity type DEPENDENT. The participation of EMPLOYEE
is partial, whereas that of DEPENDENT is total.
3.7 ER Diagrams, Naming Conventions, and
Design Issues
• 3.7.1 Summary of Notation for ER Diagrams
• 3.7.2 Proper Naming of Schema Constructs
• 3.7.3 Design Choices for ER Conceptual Design
3.7.4 Alternative Notations for ER Diagrams
Example of Other Notation: UML Class
Diagrams
3.10 Another Example: A UNIVERSITY
Database