Transcript The Entity-Relationship Model

Chapter 2
Modeling Data in the
Organization
Jason C. H. Chen, Ph.D.
Professor of MIS
School of Business Administration
Gonzaga University
Spokane, WA 99258
[email protected]
Copyright © Addison Wesley Longman, Inc. & Dr. Chen, BMIS341
TM 3-1
Objectives
Definition of terms
Importance of data modeling
Write good names and definitions for entities,
relationships, and attributes
Distinguish unary, binary, and ternary relationships
Model different types of attributes, entities,
relationships, and cardinalities
Draw E-R diagrams for common business situations
Convert many-to-many relationships to associative
entities
Model time-dependent data using time stamps
Copyright © Addison Wesley Longman, Inc. & Dr. Chen, Business Database Systems
TM 3-2
EMPLOYEE
composite
multi-valued
e_id
e_name
e_address
dob
date_employed
skill
1234
John smith
502 Boone
Spokane, WA
99258
1-11988
1-1-2005
programming,
painting,
drawing,
5678
Mary Jones
567 SE Main st,
Seattle, WA
98059
2-9-87
3-3-2007
Gardening
EMPLOYEE
e_id
e_name
e_address (street, city, state, zip)
dob
date_employed
{skill}
[years_employed]
[age]
…
derived/
computed
years_employed age
• Should we create “composite”
attributes? (see next slide)?
• Should we create “derived/computed”
attributes and save physically/
permanently in the database and why?
• How to insert values into “multi-valued”
attributes? (later this semester)
Copyright © Addison Wesley Longman, Inc. & Dr. Chen, Business Database Systems
TM 3-3
CUSTOMER
c_id
1234
c_name
John smith
5678
Mary Jones
3456
Jerry Walker
c_address
502 Boone Spokane,
WA 99258
567 SE Main St,
Seattle, WA 98059
450 3rd Ave, San Jose,
CA 95130
c_phone
What is (are) the draw back of creating a CUSTOMER
TABLE with “Composite” attribute of c_address?
•Can you find out “total number of customers” from state of
Washington?
•Can you find out all customers (with their detailed
information) from city of Spokane?
•and more …
Copyright © Addison Wesley Longman, Inc. & Dr. Chen, Business Database Systems
TM 3-4
Abstraction
Concealing irrelevant details from the user.
– Abstraction is the process of temporarily
ignoring underlying details so we can
focus on the big picture of the large
problem at hand
Copyright © Addison Wesley Longman, Inc. & Dr. Chen, Business Database Systems
TM 3-5
E/R Modeling
The E/R model is used
to construct a
conceptual data model -a representation of the
structure and constraints
of a database and is the
technology independent.
Copyright © Addison Wesley Longman, Inc. & Dr. Chen, Business Database Systems
TM 3-6
Why Data Modeling is Important?
• The characteristics of the data are crucial in
the design of the database, programs, and
other system components.
• Data are the most complex aspects of many
modern MIS - not the processes.
• Data tend to be more stable than the
business processes that use that data.
Copyright © Addison Wesley Longman, Inc. & Dr. Chen, Business Database Systems
TM 3-7
SDLC Revisited – Data Modeling is an
Analysis Activity (see also Figure 1-7)
Project Identification
and Selection
Purpose –thorough analysis
Deliverable – functional system specifications
Project Initiation
and Planning
Analysis
Logical Design
Physical Design
Database activity –
conceptual data modeling
Implementation
Maintenance
Growth and Change
Copyright © Addison Wesley Longman, Inc. & Dr. Chen, Business Database Systems
TM 3-8
Business Rules
Statements that define or constrain some
aspect of the business
Assert business structure
Control/influence business behavior
Are expressed in terms familiar to end users
Are automated through DBMS software
(What/Why and How?)
Copyright © Addison Wesley Longman, Inc. & Dr. Chen, Business Database Systems
TM 3-9
A Good Business Rule is: (Table 2-1)
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
Copyright © Addison Wesley Longman, Inc. & Dr. Chen, Business Database Systems
TM 3-10
A Good Data Name is:
Related to business, not __________,
technical
characteristics
Meaningful and self-documenting
Unique
_________
Readable
Composed of words from an approved list
Repeatable
Written in standard syntax
Copyright © Addison Wesley Longman, Inc. & Dr. Chen, Business Database Systems
TM 3-11
Data Definitions
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
Concise description of essential data meaning
Achieved by consensus, and iteratively refined
Copyright © Addison Wesley Longman, Inc. & Dr. Chen, Business Database Systems
12
TM 3-12
E-R Model Constructs
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).
– entity type is always SINGULAR
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)
Copyright © Addison Wesley Longman, Inc. & Dr. Chen, Business Database Systems
TM 3-13
Sample E-R Diagram (Figure 2-1)
Copyright © Addison Wesley Longman, Inc. & Dr. Chen, Business Database Systems
TM 3-14
Basic E-R notation (Figure 2-2)
Entity
symbols
A special
entity that is
also a
relationship
Relationship
degrees
specify
number of
entity types
involved
Copyright © Addison Wesley Longman, Inc. & Dr. Chen, Business Database Systems
Attribute
symbols
Relationship
symbols
Relationship
cardinalities
specify how
many of each
entity type is
allowed
TM 3-15
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)
Copyright © Addison Wesley Longman, Inc. & Dr. Chen, Business Database Systems
TM 3-16
Figure 2-4 Example of inappropriate entities
System
user
Inappropriate
entities
System
output
Appropriate
entities
Copyright © Addison Wesley Longman, Inc. & Dr. Chen, Business Database Systems
TM 3-17
Attributes
Attribute - property or characteristic of an
entity type that is of interest to the
organization.
Classifications of attributes:
–
–
–
–
–
Required versus Optional Attributes
Simple versus Composite Attribute
Single-Valued versus Multi-valued Attribute
Stored versus Derived Attributes
Identifier Attributes
Copyright © Addison Wesley Longman, Inc. & Dr. Chen, Business Database Systems
TM 3-18
Identifiers (Keys)
Identifier (Key) - An attribute (or
combination of attributes) that uniquely
identifies individual instances of an entity
type
Simple Key versus Composite Key
Candidate Key – an attribute that could be a
key…satisfies the requirements for being a
key
Copyright © Addison Wesley Longman, Inc. & Dr. Chen, Business Database Systems
TM 3-19
Strong vs. Weak Entities, and
Identifying Relationships
Strong entities
– exist independently of other types of entities
– has its own unique identifier
– identifier underlined with single-line
Weak entity
– dependent on a strong entity (identifying owner)…cannot exist
on its own
– does not have a unique identifier (only a partial identifier)
– Partial identifier underlined with double-line
– Entity box has double line
Identifying relationship
– links strong entities to weak entities
Copyright © Addison Wesley Longman, Inc. & Dr. Chen, Business Database Systems
TM 3-20
Figure 2-5 Example of a weak identity and its identifying relationship
Strong entity
Copyright © Addison Wesley Longman, Inc. & Dr. Chen, Business Database Systems
Weak entity
TM 3-21
Q: (Review Q:#12; p.101) Another example of Weak Entity
Phone Call (see below) is an example of a weak entity because a
phone call must be placed by a PERSON. In this simple example,
PHONE CALL is related to only one other entity type, thus, it is
not necessary to show the identifying relationship; however, if
this data model were ever expanded so that PHONE CALL
related to other entity types, it is good practice to always indicate
the identifying relationship.
Strong entity
Copyright © Addison Wesley Longman, Inc. & Dr. Chen, Business Database Systems
Weak entity
TM 3-22
Required vs. Optional Attributes
Required – must have a value for
every entity (or relationship)
instance with which it is
associated
Copyright © Addison Wesley Longman, Inc. & Dr. Chen, Business Database Systems
Optional – may not have a value
for every entity (or relationship)
instance with which it is
associated
TM 3-23
23
E-R Model Constructs (Continued)
Attribute - property or characteristic of an
entity type that is of interest to the
organization.
Simple versus Composite Attribute
– Fig. 2-7
Single-Valued versus Multivalued Attribute
– Fig. 2-8
Stored versus Derived Attributes
– Fig. 2-8
Copyright © Addison Wesley Longman, Inc. & Dr. Chen, Business Database Systems
TM 3-24
Figure 2-7 A composite attribute: An attribute that has meaningful
component parts (attributes)
An attribute
broken into
component parts
Figure 2-8 Entity with multivalued attribute (Skill)
and derived attribute (Years Employed)
Multivalued
an employee can
have
more than one skill
Copyright © Addison Wesley Longman, Inc. & Dr. Chen, Business Database Systems
Derived
from date
employed
and current
date
TM 3-25
CUSTOMER (How to solve potential problems on “composite attributes”)
e_id
1234
e_name
John smith
5678
Mary Jones
e_address
502 Boone
Spokane, WA
99258
567 SE Main
st, Seattle, WA
98059
dob
1-11988
date_employed
1-1-2005
2-9-87
3-3-2007
skill
programming,
painting,
drawing,
Gardening
…
years_employed
age
CUSTOMER (after “breaking” the ‘composite’ address)
c_id
1234
c_name
John Smith
5678
Mary Jones
3456
Jerry Walker
street
502
Boone
567 SE
Main St
450 3rd
Ave
city
Spokane
state
WA
zip
99258
Seattle
WA
98059
San Jose
CA
95130
c_phone
•Now we are able to find out “total number of customers” from state of
Washington?
•HOW?
•We can find out all customers (with their detailed information) from city of
Spokane?
•HOW?
•and more …
Copyright © Addison Wesley Longman, Inc. & Dr. Chen, Business Database Systems
TM 3-26
E-R Model Constructs (Continued)
Identifier or Key - An attribute (or
combination of attributes) that uniquely
identifies individual instances of an entity
type.
Simple Key versus Composite Key (Fig. 29)
Candidate Key
Copyright © Addison Wesley Longman, Inc. & Dr. Chen, Business Database Systems
TM 3-27
Figure 2-9 Simple and composite identifier attributes
The identifier
is boldfaced
and
underlined
Copyright © Addison Wesley Longman, Inc. & Dr. Chen, Business Database Systems
TM 3-28
E-R Model Constructs (Continued)
Criteria for Selecting Identifiers
– Will not change in value over the life of each
instance of the entity type.
– Will not be NULL.
– No intelligent identifiers (containing e.g.
locations or people that might change)
– Substitute new, simple (e.g., surrogate
attribute) keys for long, composite keys (e.g.,
entity type of Game: Game# instead of
Home_Team and Visitor_Team)
Copyright © Addison Wesley Longman, Inc. & Dr. Chen, Business Database Systems
TM 3-29
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
Two entities can have more than one type of
relationship between them (multiple relationships)
Associative Entity–combination of relationship
and entity
Copyright © Addison Wesley Longman, Inc. & Dr. Chen, Business Database Systems
TM 3-30
Modeling Relationships
Relationship Type versus Instance
– Fig. 2-10
An associative entity
– An entity type that associates the instances that
are peculiar to the relationship between those
entity instances.
Attributes on Relationships
– Fig. 2-11
Copyright © Addison Wesley Longman, Inc. & Dr. Chen, Business Database Systems
TM 3-31
Figure 2-10 Relationship types and instances
a) Relationship
type
(Completes)
b)
Relationship
instances
Smith
Copyright © Addison Wesley Longman, Inc. & Dr. Chen, Business Database Systems
TM 3-32
Associative Entities
An entity - has attributes
A relationship - links entities together
Associative Entity–combination of relationship and entity
When should a relationship with attributes instead be an
associative entity?
– All relationships for the associative entity should be many
– 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
Copyright © Addison Wesley Longman, Inc. & Dr. Chen, Business Database Systems
TM 3-33
Figure 2-11(a) Associate Entnty - A binary relationship with an attribute
Attribute on a relationship (Link Attribute/Associative)
Here, the date completed attribute pertains specifically to the
employee’s completion of a course…it is an attribute of the
relationship
Copyright © Addison Wesley Longman, Inc. & Dr. Chen, Business Database Systems
TM 3-34
Figure 2-11(b) 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 in Figure
2-11a has been replaced by two one-to-many relationships with
the associative entity
Copyright © Addison Wesley Longman, Inc. & Dr. Chen, Business Database Systems
TM 3-35
Fig. 2-11: (b) An associative entity (CERTIFICATE)
Employee_ID
Course_ID
What is an alternative to assign the pk?
Copyright © Addison Wesley Longman, Inc. & Dr. Chen, Business Database Systems
TM 3-36
Fig. 2-11: (b) An associative entity (CERTIFICATE)
Employee_ID
Course_ID
grade
(P/F)
What is an alternative to assign the pk?
Copyright © Addison Wesley Longman, Inc. & Dr. Chen, Business Database Systems
TM 3-37
Figure 2-11(c )An associative entity using Microsoft VISIO
Copyright © Addison Wesley Longman, Inc. & Dr. Chen, Business Database Systems
TM 3-38
JustLee E-R Model (Fig. 1-5; p.11 Oracle Text)
PUBLISHER
PubID
CUSTOMERS
Customer#
ORDERS
Order#
Copyright © Addison Wesley Longman, Inc. & Dr. Chen, Business Database Systems
BOOKS
ISBN
AUTHOR
AuthorID
TM 3-39
JustLee E-R Model (Fig. 1-5; p.11 Oracle Text)
PUBLISHER
PubID
CUSTOMERS
Customer#
ORDERS
Order#
ORDERITEMS
Order#
Item#
Copyright © Addison Wesley Longman, Inc. & Dr. Chen, Business Database Systems
BOOKS
ISBN
AUTHOR
AuthorID
BOOKAUTHOR
ISBN
AuthorID
TM 3-40
JustLee E-R Model (Fig. 1-5; p.11 Oracle Text)
PROMOTION
Gift
CUSTOMERS
Customer#
ORDERS
Order#
ORDERITEMS
Order#
Item#
Copyright © Addison Wesley Longman, Inc. & Dr. Chen, Business Database Systems
PUBLISHER
PubID
BOOKS
ISBN
AUTHOR
AuthorID
BOOKAUTHOR
ISBN
AuthorID
TM 3-41
JustLee E-R Model (Fig. 1-5; p.11 Oracle Text)
PROMOTION
Gift
CUSTOMERS
Customer#
ORDERS
Order#
ORDERITEMS
Order#
ISBN
Copyright © Addison Wesley Longman, Inc. & Dr. Chen, Business Database Systems
PUBLISHER
PubID
BOOKS
ISBN
AUTHOR
AuthorID
BOOKAUTHOR
ISBN
AuthorID
TM 3-42
E-R Model vs. O-O Model
Entity Type
/Entity
(attributes)
Class
Attributes +
operations
Entity Instance
Object
A collection of
entities that
share common
properties or
characteristics
A single
occurrence of
an entity
type/class
Value
Copyright © Addison Wesley Longman, Inc. & Dr. Chen, Business Database Systems
TM 3-43
E-R Model vs. O-O Model
Entity Type
/Entity
(attributes)
Class
Attributes +
operations
Entity Instance
Object
A collection of
entities that
share common
properties or
characteristics
A single
occurrence of
an entity
type/class
Value
Copyright © Addison Wesley Longman, Inc. & Dr. Chen, Business Database Systems
TM 3-44
Break ! (Ch. 2 - Part I)
In class exercise
- #7 (p. 87)
HW
- 1). #10; p. 87
[Draw ER-D (use Word/Visio) ]
Copyright © Addison Wesley Longman, Inc. & Dr. Chen, Business Database Systems
TM 3-45
Relationships
Degree of a Relationship - number of
________
entity types that participate in it (Fig. 2-12)
– Unary (or Recursive) Relationship
(degree 1)
Bill-of-Materials (Fig. 2.12; 2-13)
– Binary Relationship
(degree 2)
– Ternary Relationship
(degree 3)
Copyright © Addison Wesley Longman, Inc. & Dr. Chen, Business Database Systems
TM 3-46
Cardinality of Relationships
One – to – One
– Each entity in the relationship will have exactly one
related entity
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
Many – to – Many
– Entities on both sides of the relationship can have many
related entities on the other side
Copyright © Addison Wesley Longman, Inc. & Dr. Chen, Business Database Systems
TM 3-47
Degree of relationships – from Figure 2-2
One entity
related to
another of
the same
entity type
Entities of
two different
types related
to each other
Copyright © Addison Wesley Longman, Inc. & Dr. Chen, Business Database Systems
Entities of three
different types
related to each
other
TM 3-48
Fig. 2-12: Example of relationships of different degrees
(a) Unary relationships
Copyright © Addison Wesley Longman, Inc. & Dr. Chen, Business Database Systems
TM 3-49
Fig. 2-12: (b) Binary relationships
Copyright © Addison Wesley Longman, Inc. & Dr. Chen, Business Database Systems
TM 3-50
c) Ternary relationship
PART
VENDOR
Copyright © Addison Wesley Longman, Inc. & Dr. Chen, Business Database Systems
WAREHOUSE
TM 3-51
Figure 2-12 Examples of relationships of different degrees (cont.)
c) Ternary relationship
Note: a relationship can have attributes of its own
Copyright © Addison Wesley Longman, Inc. & Dr. Chen, Business Database Systems
TM 3-52
Figure 2-12 Examples of relationships of different degrees (cont.)
c) Ternary relationship
Note: a relationship can have attributes of its own
Copyright © Addison Wesley Longman, Inc. & Dr. Chen, Business Database Systems
TM 3-53
Fig. 2-14: Ternary relationships as an associative entity
Copyright © Addison Wesley Longman, Inc. & Dr. Chen, Business Database Systems
TM 3-54
Fig. 2-18: Cardinality constraints in a ternary relationship
part_id
vendor_id
Copyright © Addison Wesley Longman, Inc. & Dr. Chen, Business Database Systems
???
warehouse_id
TM 3-55
Fig. 2-18: Cardinality constraints in a ternary relationship
Each vendor can
supply many parts to
any number of
wareshouses, but
need not supply any
parts.
Each part can be
supplied by any
number of vendors to
more than one WH,
but each part must
supplied by at least
one vendor to a WH.
Each WH can be supplied with any number of
parts from more than one vendor, but each WH
must be supplied with at least one part
Copyright © Addison Wesley Longman, Inc. & Dr. Chen, Business Database Systems
TM 3-56
Basic E-R notation (Figure 2-2)
Entity
symbols
A special
entity that is
also a
relationship
Relationship
degrees
specify
number of
entity types
involved
Copyright © Addison Wesley Longman, Inc. & Dr. Chen, Business Database Systems
Attribute
symbols
Relationship
symbols
Relationship
cardinalities
specify how
many of each
entity type is
allowed
TM 3-57
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
– Mandatory One - when min
& max both = 1
Maximum Cardinality
– The maximum number
Copyright © Addison Wesley Longman, Inc. & Dr. Chen, Business Database Systems
TM 3-58
Fig. 2-16: Introducing cardinality constraint
(a) Basic relationship
(a) Relationship with cardinality constraints
Copyright © Addison Wesley Longman, Inc. & Dr. Chen, Business Database Systems
TM 3-59
Figure 2-17 Examples of cardinality constraints
a) Mandatory cardinalities
A patient history is
recorded for one and
only one patient
Copyright © Addison Wesley Longman, Inc. & Dr. Chen, Business Database Systems
A patient must have
recorded at least one
history, and can have
many
TM 3-60
Figure 2-17 Examples of cardinality constraints (cont.)
b) One optional, one mandatory
(4)
A project must be
assigned to at least one
employee, and may be
assigned to many
Copyright © Addison Wesley Longman, Inc. & Dr. Chen, Business Database Systems
An employee can be
assigned to any number of
projects, or may not be
assigned to any at all
TM 3-61
Figure 2-17 Examples of cardinality constraints (cont.)
c) Optional cardinalities
A person is
married to at
most one other
person, or may
not be married
at all
Copyright © Addison Wesley Longman, Inc. & Dr. Chen, Business Database Systems
TM 3-62
Relationships
Modeling Time-Dependent Data
– Time Stamps: a time value that is associated with
a data value (Fig. 2-19; 2-20)
– managing time-dependent data is inadequate
using current data models --> data warehousing
Multiple Relationship: Business Rules
– more than one relationship between the same
entity types (Fig. 2-21)
Copyright © Addison Wesley Longman, Inc. & Dr. Chen, Business Database Systems
TM 3-63
Figure 2-19 Simple example of time-stamping
This attribute is both
multivalued and
composite
Copyright © Addison Wesley Longman, Inc. & Dr. Chen, Business Database Systems
TM 3-64
Fig. 2-20: Examples of multiple relationships
(a) Employees and departments
Entities can be related to one another in more than one way
Copyright © Addison Wesley Longman, Inc. & Dr. Chen, Business Database Systems
TM 3-65
Fig. 2-20: (b) Professors and courses (fixed upon constraint)
??
Here, minimum cardinality constraint is 2, what’s for?
At least two professors must be qualified to teach each course.
Each professor must be qualified to teach at least one course.
Copyright © Addison Wesley Longman, Inc. & Dr. Chen, Business Database Systems
TM 3-66
Database Processing: SQL
Showing Product Information
List all details for the various computer desks that are stocked by the
company?
SELECT *
FROM PRODUCT
WHERE product_Description LIKE “Computer Desks%”;
Showing Customer Order Status
How many orders have we received from “Value Furniture?
SELECT COUNT (Order_ID)
FROM ORDER
WHERE Customer_ID =
(SEELCT Customer_ID
FROM CUSTOMER
WHERE Customer_Name = “Value Furniture”);
Copyright © Addison Wesley Longman, Inc. & Dr. Chen, Business Database Systems
TM 3-67
Levels of Database Schemas
Different schemas are presented to different users
Enterprise
Data Model
External Level
Conceptual to Internal mapping
Conceptual Schema
Conceptual Level
Internal to conceptual mapping
Internal Schema
Logical
Schema
Physical
Schema
Internal Level
Figure 1-12: Three-schema database architecture
External
View
Ch. 4
Ch. 2,3,4
Meta-data/
Repository/
D.D.
E/R, OO …
Relations
Ch. 5
Database
Internal
View
Copyright © Addison Wesley Longman, Inc. & Dr. Chen, Business Database Systems
TM 3-69
The Entity Relationship (E-R) Model
Congratulation !!
You have just learned
one of the most
important modeling
concept (E-R) for
developing the data
base systems.
Copyright © Addison Wesley Longman, Inc. & Dr. Chen, Business Database Systems
TM 3-70
MVC_Hospital HW
Phase I - Logical Design Phase
Draw a entity-relationship diagram (enterprise model) for Mountain
View community Hospital, based on the narrative description of the case
and this handout (but the entities are from the five (5) figures/reports
shown in the assignment sheet). You should create a file and turn in with
a hardcopy (file name: MVC_Phase I_ERD_Lname_Fname.docx)
contains the following materials:
1. Read and employ materials from chapters 1 and 2
2. Include entities, associations (with detail multiplicity), and attributes.
3. Determine and draw the order of entering data
Upload ONLY the .docx file to the Blackboard (under “Assignments”) with the following
file name: bmis441_MVC-Phase I_Lastname_Firstname.docx
Copyright © Addison Wesley Longman, Inc. & Dr. Chen, Business Database Systems
TM 3-71
Problems and Exercises
In class exercise
- #11 (a-c), p.87 [ Cardinality]
- #15 [Review Questions, p.87]
HW (using Visio)
1. #20 ( p.90)
-turn in with hardcopy
2. MVC mini project- Phase I
(ERD both hard and soft
copies)
Copyright © Addison Wesley Longman, Inc. & Dr. Chen, Business Database Systems
TM 3-72