Conceptual Database Design

(ER modeling)
Chapter Three

1
 Agenda (Chapter Three)
 Overview-database design
 Conceptual Design (E-R Modeling)
 Structural Constraints
 EER- Generalization and Specialization
 Reducing E-R Model to Table (logical
Design)

2
 Objective
 Learn skills and methods of Modeling organizational data
using Entity relationship diagram
 Implementing the rules of relational data model through the
process of normalization

3
 Overview-database design
 Database design is the process of coming up with different
kinds of specification for the data to be stored in the database

 The database design part is one of the middle phases we have

in information systems development where the system uses a
database approach.

4
 Cont…
 Design is the part on which we would be engaged to
describe
 how the data should be perceived at different levels
and
 finally how it is going to be stored in a computer
system

5
 Cont…
 Information System development with Database
application consists of several tasks which include:
 Planning of Information systems Design
 Requirements Analysis,
 Database Design (Conceptual, Logical and Physical
Design)
 Interface, program etc designs are also there
 Implementation
 Operation and Support

6
 Cont…
 From these different phases, the prime interest of this
courses will be the Database Design part which is again
sub divided into other three sub-phases.
 These sub-phases are:
 Conceptual Design
 Logical Design, and
 Physical Design

7
 Cont…
 In general, one has to go back and forth between these
tasks to refine a database design, and decisions in one
task can influence the choices in another task.
 In developing a good design, one should answer such
questions as:
 What are the relevant Entities for the Organization
 What are the important features of each Entity
 What are the important Relationships
 What are the important queries from the user
 What are the other requirements of the Organization and the
Users

8
 Conceptual Database Design
 Conceptual design revolves around discovering and analyzing
organizational and user data requirements
 The important activities are to identify
 Entities
 Attributes
 Relationships
 Constraints
 And based on these components develop the ER model using
ER diagram components

9
 Cont…
 Designing conceptual model for the database is not a one
linear process but an iterative activity where the design is
refined again and again.
 Important steps then could be
 Identification of components
 Use of notations to model
 Review, refine and validate

10
 Cont…
 Before working on the conceptual design of the
database, one has to know and answer the
following basic questions

 What are the entities and relationships in the

enterprise?

 What information about these entities and relationships

should we store in the database?

11
 Cont…
 What are the integrity constraints that hold?
 Constraints on each data with respect to update, retrieval and
store

 Represent this information pictorially in ER

diagrams, then map ER diagram into a relational
schema.

12
 Modeling tools
 Be professional- use the right tool symbols are languages
 There are many ER diagramming tools
 Rational Rose
 Microsoft Visio
 Oracle Designer
 Power Designer

13
 E-R Model Constructs (recall)
 Entities:
 Entity instance–person, place, object, event, concept (often
corresponds to a row in a table)
 Entity Type–collection of entities (often corresponds to a table)
 Relationships:
 Relationship instance–link between entities (corresponds to primary
key-foreign key equivalencies in related tables)
 Relationship type–category of relationship…link between entity types
 Attribute–property or characteristic of an entity or relationship type (often
corresponds to a field in a table)

14
 Cont…
 To identify the entities, attributes, relationships, and
constraints on the data, there are different set of
methods used during the analysis phase.
 These include information gathered through
 Interviewing end users individually and in a group
 Questionnaire survey
 Direct observation
 Examining different documents
 Generally understand the business rules

15
 Cont…
 Business Rules
 Statements that define or constrain some aspect of the
business
 Assert business structure
 Control/influence business behavior
 Expressed in terms familiar to end users
 Automated through DBMS software

16
 Cont…
 A Good Business Rule is:
 Declarative–what, not how
 Precise–clear, agreed-upon meaning
 Atomic–one statement
 Consistent–internally and externally
 Expressible–structured, natural language
 Distinct–non-redundant
 Business-oriented–understood by business people

17
 Cont…

 A Good Data Name is:

 Related to business, not technical, characteristics
 Meaningful and self-documenting
 Unique
 Readable
 Composed of words from an approved list

18
 Cont…
 Describing the business in terms of data (Data Definitions;
modeling)
 Explanation of a term or fact
 Term–word or phrase with specific meaning
 Fact–association between two or more terms
 Guidelines for good data definition
 Gathered in conjunction with systems requirements
 Accompanied by diagrams
 Iteratively created and refined
 Achieved by consensus

19
 Constructs Identification-ERD

Entity; Attribute; Relationship

20
 Steps: Creating an ERD
 Here are the steps you may follow to create an entity-
relationship diagram.
 Identify Entities:
 These are typically the nouns and noun-phrases in the descriptive data
produced in your analysis.
 Do not include entities that are irrelevant to your domain.
 Find Relationships:
 Discover the semantic relationships between entities.
 These are usually the verbs that connect the nouns.
 Not all relationships are this blatant, you may have to discover some
on your own.
 The easiest way to see all possible relationships is to build a table with
the entities across the columns and down the rows, and fill in those
cells where a relationship exists between entities.
21
 Cont…
 Draw Rough ERD
 Draw the entities and relationships that you have discovered.
 Fill in Cardinality
 Determine the cardinality of the relationships.You may want to
decide on cardinality when you are creating a relationship table.
 Define Primary Keys
 Identify attribute(s) that uniquely identify each occurrence of
that entity.
 Draw Key-Based ERD
 Now add them (the primary key attributes) to your ERD.
 Revise your diagram to eliminate many-to-many relationships,
and tag all foreign keys .

22
 Cont…
 Identify Attributes
 Identify all entity characteristics relevant to the domain being analyzed.
 Map Attributes
 Determine to which entity each characteristic belongs.
 Do not duplicate attributes across entities.
 Draw fully attributed ERD
 Now add these attributes.
 The diagram may need to be modified to accommodate necessary new
entities.
 Check Results
 Is the diagram a consistent and complete representation of the domain.

23
 Cont…
 In this all tasks
 Keep in mind –Business rule
 Business functions are expressed in terms of
business rules

24
 Example business function-to-data entity
matrix

25
 Sample E-R Diagram- what it looks like

26
 What Should an Entity Be?
 SHOULD BE:
 An object that will have many instances in the database
 An object that will be composed of multiple attributes
 An object that we are trying to model
 SHOULD NOT BE:
 A user of the database system
 An output of the database system (e.g., a report)

27
Example of inappropriate entities

System System
user Inappropriate output
entities

Appropriate
entities

28
 Attributes

 Attribute–property or characteristic of an entity or relationahip

type
 Classifications of attributes:
 Required versus Optional Attributes
 Simple versus Composite Attribute
 Single-Valued versus Multivalued Attribute
 Stored versus Derived Attributes
 Identifier Attributes

29
 Identifiers (Keys)
super key

 Identifier (Key)–An attribute (or combination

of attributes) that uniquely identifies individual
instances of an entity type
 Simple versus Composite Identifier
 Candidate Identifier–an attribute that could be
a key…satisfies the requirements for being an
identifier minimal super key

 Will not be null

30
 A composite attribute

An attribute
broken into
component parts

Entity with multivalued attribute (Skill)

and derived attribute (Years_Employed)

Multivalued
an employee can have
Derived
more than one skill
from date
employed and
current date
31
 Simple and composite identifier attributes

The identifier is boldfaced and underlined

32
 More on Relationships
 Relationship Types vs. Relationship Instances
 The relationship type is modeled as lines between
entity types…the instance is between specific entity
instances
 Relationships can have attributes
 These describe features pertaining to the association
between the entities in the relationship
 Associative Entity –combination of
relationship and entity

33
 Relationship types and instances

a) Relationship type

b) Relationship
instances

34
 Degree of relationships

Entities of
One entity two different
related to types related
another of to each other Entities of three
the same different types
entity type related to each
other
35
 Examples of relationships of different degrees

a) Unary relationships

36
 Examples of relationships of different degrees (cont.)

b) Binary relationships

37
 Examples of relationships of different degrees (cont.)

c) Ternary relationship

Note: a relationship can have attributes of its own

38
 Structural Constraints
(Cardinality Constraints)

 Cardinality Constraints - the number of instances

of one entity that can or must be associated with
each instance of another entity
 Minimum Cardinality
 If zero, then optional
 If one or more, then mandatory
 Maximum Cardinality
 The maximum number of tuples taking part in the
relationship

39
 Cont…
 One-to-One
 Each entity in the relationship will have exactly one related entity

E.g.: Relationship Manages between EMPLOYEE and

BRANCH
The multiplicity of the relationship is:
One branch can only have one manager
One employee could manage either one or no branches

1..1 0..1
Manages Branch
Employee

40
 Cont…
 One-to-Many
 An entity on one side of the relationship can have many related entities, but
an entity on the other side will have a maximum of one related entity

E.g.: Relationship Leads between EMPLOYEE and PROJECT

The multiplicity of the relationship
One employee may Lead no, one or more project(s)
One project is Lead by one staff

1..1 Leads
0..*
Employee Project

41
 Cont…
 Many-to-Many
 Entities on both sides of the relationship can have many related
entities on the other side

E.g.: Relationship Teaches between INSTRUCTOR and

COURSE
The multiplicity of the relationship
One Instructor Teaches one or more Course(s)
One Course Thought by no, one or more Instructor(s)
0..* 1..*
Instructor Teaches Course

when u are in this side try to make

it the object and the subject the other side
42
Examples of cardinality constraints

a) Mandatory cardinalities

A patient history is A patient must have recorded

recorded for one and only at least one history, and can
one patient have many

43
Examples of cardinality constraints (cont.)

b) One optional, one mandatory

A project must be An employee can be assigned

assigned to at least one to any number of projects, or
employee, and may be may not be assigned to any at
assigned to many all

44
Examples of cardinality constraints (cont.)

a) Optional cardinalities

A person is married
to at most one other
person, or may not
be married at all

45
Examples of multiple relationships
Employees and departments

Entities can be related to one another in more than one way

46
 Multivalued attributes can be represented as
relationships and entity

simple

composite
47
 Identifying relationship

Strong entity Weak entity

48
 Associative Entities
 An Entity–which has attributes
 A relationship–links entities together
 When should a relationship with attributes instead be an associative entity?
 All relationships for the associative entity should have many cardinality
 The associative entity could have meaning independent of the other
entities
 The associative entity preferably has a unique identifier, and should also
have other attributes
 The associative entity may participate in other relationships other than
the entities of the associated relationship
 Ternary relationships should be converted to associative entities

49
 Example

What if we want to keep the date the employee completed

the course

50
 A binary relationship with an attribute

Here, the date completed attribute pertains specifically to the

employee’s completion of a course…it is an attribute of the
relationship

51
 An associative entity (CERTIFICATE)

Associative entity is like a relationship with an attribute, but it is

also considered to be an entity in its own right.

Note that the many-to-many cardinality between entities will be

replaced by two one-to-many relationships with the associative
entity.
52
 An associative entity – bill of materials structure

This could just be a relationship with

attributes…it’s a judgment call

53
 Ternary relationship as an associative entity

54
 Notation Standards

ER Diagramming

55
 Cont…
 Related diagramming convention techniques:
 Peter Chen notation
 Crow’s Foot Notation
 Bachman notation
 EXPRESS
 IDEF1X[4]
 Martin notation
 (min, max)-notation of Jean-Raymond Abrial in 1974
 UML class diagrams

56
Basic E-R notation

Entity
symbols Attribute
symbols

A special entity
that is also a Relationship
relationship symbols

Relationship
degrees specify
number of
entity types Relationship
involved cardinalities
specify how
many of each
entity type is
allowed
57
 Crow’s Foot
Notation
58
 Symbols

59
 Example-1

On ER

60
 Cont….
The University of Toronto has several departments. Each department is
managed by a chair, and has at least one professor working for it.
Professors must be assigned to one, but possibly more departments.
At least one professor teaches each course, but a professor may be
on sabbatical and not teach any course. Each course may be taught
more than once by different professors. We know of the department
name, the professor name, the professor employee id, the course
names, the course schedule, the term/year that the course is taught,
the departments the professor is assigned to, the department that
offers the course.

61
 Cont….
The University of Toronto has several departments. Each department
is managed by a chair, and has at least one professor working for
it. Professors must be assigned to one, but possibly more
departments. At least one professor teaches each course, but a
professor may be on sabbatical and not teach any course. Each
course may be taught more than once by different professors. We
know of the department name, the professor name, the professor
employee id, the course names, the course schedule, the
term/year that the course is taught, the departments the professor
is assigned to, the department that offers the course.

62
 Solution
 Identify Entities
 These are typically the nouns and noun-phrases in the descriptive data
produced in your analysis. Do not include entities that are irrelevant
to your domain.
 The entity candidates are departments, chair, professor, course,
and course section.
 Since there is only one instance of the University of Toronto, we
exclude it from our consideration.

63
 Finding Relationships

64
 Draw Rough ERD
Draw the entities and relationships that you have discovered.

65
 Fill in Cardinality: Determine the cardinality of the relationships. You may
want to decide on cardinality when you are creating a relationship table.

66
 Cont…
 Here we must eliminate many-to-many relationships, and
collapse one-to-one relationships where it makes sense.
 For example, the chair, without any behaviours, is really just
an attribute of a department. So we can remove it as an
entity and later add it as an attribute.

67
68
 Cont…
 Define Primary Keys
 Identify attribute(s) that uniquely identify each occurrence of
that entity.

69
 Cont…
 Draw Key-Based ERD
 Now add them (the primary key attributes) to your ERD.
Revise your diagram to
 eliminate many-to-many relationships, and tag all foreign keys

70
71
 Cont…
 Identify Attributes
 Identify all entity characteristics relevant to the domain being analyzed.
 Excluding those keys already identified:
 Schedule, Term, Professor name, Department Chair (which is an employee
ID, a foreign key to Professor)
 Map Attributes
 Determine to which entity each characteristic belongs.
 Do not duplicate attributes across entities.
 If necessary, contain them in a new, related, entity. Schedule -- Prof-Course,
Term -- Prof-Course, Chair -- Department

72
 Cont…
 Draw fully attributed ERD
 Now add these attributes
 The diagram may need to be modified to accommodate
necessary new entities.

73
74
 Cont…
 Check Results
 Is the diagram a consistent and complete representation of the
domain.
 If not - fix it.

75
 Example 2

ERD

76
 Cont…
 A company has several departments. Each
department has a supervisor and at least one
employee. Employees must be assigned to at least
one, but possibly more departments. At least one
employee is assigned to a project, but an
employee may be on vacation and not assigned to
any projects. The important data fields are the
names of the departments, projects, supervisors
and employees, as well as the supervisor and
employee number and a unique project number.

77
 Conceptual Database Design
(EER modeling)

78
 Cont…
 Enhanced E-R (EER) Models
 Object-oriented extensions to E-R model
 EER is important when:
 Some tuples have special attribute to be described with
 a relationship between two entities is partial

 EER Concepts
 Generalization…….Superclass/Supertype
 Specialization………Subclass/Subtype
 Attribute Inheritance
 Subtype entities inherit values of all attributes of the super-type
 An instance of a subtype is also an instance of the super-type

 Constraints on specialization and generalization

79
 Supertypes and Subtypes
 Subclass/Subtype
 An entity type whose tuples have attributes that distinguish its
members from tuples of the generalized or Superclass entities.
 Subclasses can be either mutually exclusive (disjoint) or
overlapping (inclusive).
 A single subclass may inherit attributes from two distinct
superclasses.
 A mutually exclusive category/subclass is when an entity instance
can be in only one of the subclasses.
 E.g.: An EMPLOYEE can either be SALARIED or PART-TIMER but not both.
 An overlapping category/subclass is when an entity instance may be
in two or more subclasses.
 E.g.: A PERSON who works for a university can be both EMPLOYEE and a
STUDENT at the same time.
80
 Supertypes and Subtypes…
 Superclass /Supertype
 An entity type whose tuples share common attributes.
 Attributes that are shared by all entity occurrences (including
the identifier) are associated with the supertype.
 Is the generalized entity

81
 Relationship of Superclass and Subclass
 An instance ca not only be a member of a subclass. i.e. Every instance of a
subclass is also an instance in the Superclass.
 A member of a subclass is represented as a distinct database object, a
distinct record that is related via foreign key attribute to its super-class.
 The relationship between a subclass and a Superclass is an “IS A” or
“IS PART OF” type.
 Subclass IS PART OF Superclass
 Manager IS AN Employee

82
 Notation
• All subclasses or
specialized entity sets
should be connected with
the superclass using a line
to a circle where there is a
subset symbol indicating
the direction of
subclass/superclass
relationship.

83
 Basic notation for supertype/subtype notation

a) EER
notation

84
 Cont…
 Attribute Inheritance
 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.
 An entity may have more than one subclass
categories.
 All subclasses of a superclass share a common
unique identifier attribute (primary key). i.e.

85
  Consider the EMPLOYEE supertype
entity shown above.
 This entity can have several different
subtype entities (for example: HOURLY
and SALARIED), each with distinct
properties not shared by other subtypes.
 But whether the employee is HOURLY
or SALARIED, same attributes
(EmployeeId, Name, and DateHired) are
shared.
 The Supertype EMPLOYEE stores all
properties that subclasses have in
common.
 And HOURLY employees have the
unique attribute Wage (hourly wage rate),
while SALARIED employees have two
86 unique attributes, Pension and Salary.
 Generalization and Specialization
 Generalization: The process of defining a more general
entity type from a set of more specialized entity types.
BOTTOM-UP

 Specialization: The process of defining one or more

subtypes of the supertype and forming supertype/subtype
relationships.
TOP-DOWN

87
 Example of generalization
a) Three entity types: CAR, TRUCK, and MOTORCYCLE

All these types of vehicles have common attributes

88
 Example of generalization (cont.)
b) Generalization to VEHICLE supertype

So we put
the shared
attributes in
a supertype

Note: no subtype for motorcycle, since it has no unique attributes

89
 Example of specialization

a) Entity type PART

Only applies to
manufactured parts

Applies only to purchased parts

90
 Example of specialization (cont.)
b) Specialization to MANUFACTURED PART and PURCHASED PART

Created 2
subtypes

SupplierID
Unite_Price

91
 Example of specialization (cont.)
b) Specialization to MANUFACTURED PART and PURCHASED PART

Created 2
subtypes

Note: multivalued attribute was replaced by an

associative entity relationship to another entity
92
 ERD-to- Relation Mapping

93
 Cont…
 Why
 ER is
 very high level closer to end users understanding
 Not directly possible to implement
 Needs transformation to fit to all business rules
required

94
 Cont…
 How
 The first step is converting the conceptual design to a form
suitable for relational logical model, which is in a form of
tables- mapping
 The next is Normalization (applying the rules in relational
data model)- Chapter 4

95
 ER Diagrams into Relations
Mapping Regular Entities to Relations/Tables
Every Entity will be a Tables
1. Simple attributes: E-R attributes map directly onto the
relation
2. Composite attributes: Use only their simple, component
attributes
3. Multivalued Attribute–Becomes a separate relation with a
foreign key taken from the superior entity

96
 Mapping a regular entity

(a) CUSTOMER
entity type with
simple
attributes

(b) CUSTOMER relation

97
 Mapping a composite attribute

(a) CUSTOMER
entity type with
composite
attribute

(b) CUSTOMER relation with address detail

98
 Mapping an entity with a multivalued attribute
(a)

Multivalued attribute becomes a separate relation with foreign key

(b)

One–to–many relationship between original entity and new relation

99
 ER Diagrams into Relations
Mapping Weak Entities
 Becomes a separate relation with a foreign key
taken from the superior/Strong entity
 Primary key composed of:
 Partial identifier of weak entity
and/or
 Primary key of identifying relation (strong entity)

100
 Example of mapping a weak entity

a) Weak entity DEPENDENT

101
 Example of mapping a weak entity (cont.)

b) Relations resulting from weak entity

NOTE: the domain constraint

for the foreign key should
NOT allow null value if
DEPENDENT is a weak
entity

Foreign key

Composite primary key

102
 Mapping Relationships
The cardinality will be the basis for mapping relationship
 One-to-One:
 Primary key of one of the side can be taken into the other as a foreign key.
 Recommendation: Primary key on the optional side becomes a foreign key
on the mandatory side
 One-to-Many:
 Primary key on the one side becomes a foreign key on the many side
 Many-to-Many:
 Create a new relation with the primary keys of the two entities becomes the
foreign key in the new table. The foreign keys will as well be part of the
primary key in the new table.

103
 Example of mapping a 1:M relationship
a) Relationship between customers and orders

Note the mandatory one

b) Mapping the relationship

Again, no null value in the

foreign key…this is because
of the mandatory minimum
cardinality
Foreign key
104
 Example of mapping an M:N relationship
a) Many to Many relationship (M:N)

The Completes relationship will need to become a separate relation

105
 Example of mapping an M:N relationship (cont.)
b) Three resulting relations

Composite primary key

Foreign key New

Foreign key
intersection
relation

106
 Example of mapping a binary 1:1 relationship
a) One to one relationship (1:1)

Often in 1:1 relationships, one direction is optional.

107
 Example of mapping a binary 1:1 relationship (cont.)
b) Resulting relations

Foreign key goes in the relation on the optional side,

Matching the primary key on the mandatory side

108
 Example of mapping an associative entity
a) An associative entity

109
 Example of mapping an associative entity (cont.)
b) Three resulting relations

Composite primary key formed from the two foreign keys

110
 Example of mapping an associative entity with
an identifier
a) SHIPMENT associative entity

111
 Example of mapping an associative entity with
an identifier (cont.)
b) Three resulting relations

Primary key differs from foreign keys

112
 ER Diagrams into Relations
Mapping Unary Relationships
 One-to-One:
 Recursive foreign key in the same relation
 One-to-Many:
 Recursive foreign key in the same relation
 Many-to-Many:
 Create a new relation and the primary key of the entity will be taken as a
foreign key twice playing both roles in the recursive relationship. (N.B:
make sure that the two foreign key names are different from one another
even though they refer to same primary key value in the main table)

113
 Mapping a unary 1:N relationship

(a) EMPLOYEE entity with

unary relationship

(b) EMPLOYEE
relation with
recursive foreign
key

114
 Mapping a unary M:N relationship

(a) Bill-of-materials
relationships (M:N)

(b) ITEM and

COMPONENT
relations

115
 ER Diagrams into Relations
Mapping Ternary (and n-ary) Relationships
 Create a new relation an post the primary key of all
participating entities into the new table.
 Include if there are any attributes that would be
meaningful only if the relationship takes place.

116
 Mapping a ternary relationship

a) PATIENT TREATMENT Ternary relationship with

associative entity

117
 Mapping a ternary relationship (cont.)

b) Mapping the ternary relationship PATIENT TREATMENT

Remember This is why But this makes a It would be

that the treatment date very better to create a
primary key and time are cumbersome surrogate key
MUST be included in the key… like Treatment#
unique composite
118 primary key
 EER Diagrams into Relations
Mapping Supertype/Subtype Relationships
 A separate relation for supertype and for each subtype
 Supertype attributes (including the subtype
discriminator) go into supertype relation
 Subtype attributes go into each subtype; primary key of
supertype relation also becomes primary key of subtype
relation

119
 Supertype/subtype relationships

120
 Mapping Supertype/subtype relationships to relations

These are implemented as one-to-one

relationships

121
 Example

122
 Example

Department Run_By

Employee
Works_for

assigned

Project

123
 Solution
 Convert the ERD into Relation
 The simple process is
1. Create a table/relation for each entity from the ERD.
2. The entity attributes become the attributes/columns
for the table/relation.
3. Potentially, include some foreign keys to represent
relationships shown in the ERD.

124
 Cont…
 Create a table for each ERD entity
 There are 6 entities in the above Figure so there are six tables
with the same names:
 Department,
 Supervisor,
 EmployeeDepartment,
 Employee,
 EmployeeProject,
 Project.

125
 Cont…
 Entity attributes become table attributes
 DEPARTMENT( DepartmentName )
 SUPERVISOR( SupervisorNumber, SupervisorName )
 EMPLOYEEDEPARTMENT( DepartmentName, EmployeeNumber )
 EMPLOYEE( EmployeeNumber, EmployeeName )
 EMPLOYEEPROJECT( EmployeeNumber, ProjectNumber )
 PROJECT( ProjectNumber )

126
 Cont…
 Include some foreign keys to represent relationships
 Let's list the relationships and take each in turn
 Run By
 Can be represented by adding SupervisorNumber to the
Department table
 DEPARTMENT( DepartmentName, SupervisorNumber )
 Is assigned (employee-department)
 Is already represented in the EmployeeDepartment table

127
 Cont…
 Involves
 Also represented in the EmployeeDepartment table
 Works on
 Represented in the EmployeeProject table
 Is assigned (employ-project)
 Also represented by the EmployeeProject table.

128
 Cont…
 This means no other foreign keys are really needed.
 This leaves the Project table with only a primary key.
 But
 The primary key is meant to uniquely identify instances of
an entity.
 The only data being stored in this table is the primary key, it
has nothing to identify.
 The choices are
 Remove the table. It's not needed if it only has the primary key.
 Add more attributes to the table.
 So the Project table becomes
 PROJECT(ProjectNo, ProjectName, Budget, EndDate )
129
 Cont…
 Add more required attributes to other table
 EMPLOYEEDEPARTMENT
( DepartmentName, EmployeeNumber, StartDate )

 EMPLOYEEPROJECT
( EmployeeNumber, ProjectNumber, StartDate )

 Normally, this sort of process would not be required.

130
 PROJECT
CLIENT
ProjectID
ClientID
Description
ClientName STAFF
EstimatedPrice
PostalAddress StaffID
EstimatedStartDate managed
(Street, Suburb, requests StaffName
EstimatedFinishDate by
State, PostCode) Mobile
ActualStartDate
Phone {(PhoneType, JobTitle
ActualFinishDate
PhoneNbr)}
CurrentStatus
ClientType
[ActualDuration]

involves

TASK
pre-req TaskID
Description
EstimatedHours
ActualStartDate
ActualFinishDate

Exercise
CurrentStatus
[ActualDuration]

incurs submits

TIMESHEET
TimesheetID
WorkDate
WorkDescription
HoursWorked
Billable

131
 End of Chapter Three

132