ppt - using entity-relationship diagrams to count … proceedings/ifpug-2004/ifpug2004...ppt - using...
TRANSCRIPT
Using Entity-Relationship DiagramsTo Count Data Functions
Ian Brown, CFPSBooz Allen Hamilton8283 Greensboro Dr.McLean, VA 22102USA
Copyright © 2004 Booz Allen Hamilton
1Copyright © 2004 Booz Allen Hamilton
Contents
What Is an Entity-Relationship (E-R) Diagram?
E-R Vocabulary
How to Read E-R Diagrams
Applying IFPUG Counting Practice Manual (CPM) 4.2Rules to E-R Diagrams
This document contains material which has been extracted from the IFPUG Practical Guidelines for Counting Logical Files. It has been reproduced in this document with permission of IFPUG & NESMA
2Copyright © 2004 Booz Allen Hamilton
An E-R diagram is a set of common constructs and conventions used to create a model of users’ data
E-R diagrams also known as logical data models (LDM)Data modeling is the process of creating a logical representation of the structure of a database– To be accurate, the model must support the
users’ view of the data– Typically completed in design phase of a
development effort
Common notations– Chen model– Barker’s notation– Information engineering (crow’s feet)– IDEF1X– UML
Entity
Entity
Attribute
AttributeAttribute
Relationship
Relationship
Entity
Attribute Attribute
Attribute Attribute Attribute
There is no single, generally accepted standard E-R model…
E-R ModelingTools
Case WiseERwinS-DesignerER/StudioVisio
E-R ModelingTools
Case WiseERwinS-DesignerER/StudioVisio
3Copyright © 2004 Booz Allen Hamilton
…But a common terminology provides some consistency between E-R variations
Entity: represents a set of real or abstract objects about which a system manages and maintains information– Independent Entity: can be uniquely identified without determining their relationship to another
entity
– Dependent Entity: existence of an instance (record) relies upon its relationship to another entity• Key: a field that is a unique identifier for each data entry
• Associative Entity: further describes the relationship between two other entities; depends upon two or more “parent” entities and takes the entire key from both parent entities
• Attributive Entity: further describes one or more characteristics of another entity
• Subtype Entity: augments a unique occurrence of an entity with additional characteristics and/or relationships
Attribute: represents a field, or data element, of a given entity
Cardinality: the maximum or minimum number of elements allowed on each side of the relationship; specifies how many instances of one entity relate to one instance of another entity
4Copyright © 2004 Booz Allen Hamilton
Relationships define the nature of the connection between attributes within entities
One-to-one [1:1] – A determines B and B determines A; two attributes functionally determine each other– Example: person name and driver license number
One-to-many [1:N] – A determines B, but B does not determine A; single instance related to multiple instances– Example: CD title and artist name
Many-to-many [N:M] – A does not determine B and B does not determine A– Example: student name and course number
Relationships can also be optional or mandatory– Parentheses used to indicate optional relationship
– (1):N or 1:(N) Sounds like RETs, doesn’t it?
Sounds like RETs, doesn’t it?
5Copyright © 2004 Booz Allen Hamilton
E-R Diagram Example (IDEF1X)
COLLECTION ID
Collection NumberCalendar YearTitleType CodeSummaryRecords Schedule NoLegacy IdentifierEntry Date/TimeRelease Date/TimeLast Edit Date/Time
COLLECTION
COLLECTION ID
Collection NumberCalendar YearTitleType CodeSummaryRecords Schedule NoLegacy IdentifierEntry Date/TimeRelease Date/TimeLast Edit Date/Time
COLLECTION
PERSON ID (FK)COLLECTION ID (FK)PERSON ID (FK)COLLECTION ID (FK)
PERSON-COLLECTIONPERSON ID
Last NameFirst NameMiddle InitialTitleAddressCity StateZipOrganization ID (FK)
PERSON
ORGANIZATION ID
NameType
ORGANIZATION
COLLECTION-ITEM ID COLLECTION ID (FK)
Collection-Item NumberTitleAuthorDateSummaryPage CountTypeStatusMedia Type CodeRestricted Viewing Code Effective Date
COLLECTION-ITEM
ELECTRONIC-COLLECTION-ITEM NameELECTRONIC-COLLECTION-ITEM File PathCOLLECTION-ITEM ID COLLECTION ID (FK)
File TypeVersion NumberFile SizeURL
ELECTRONIC COLLECTION-ITEM
COLLECTION-ITEM ID (FK) COLLECTION ID (FK)
TypeLengthDate
AUDIO-COLLECTION-ITEM
COLLECTION-ITEM ID (FK) COLLECTION ID (FK)
HeightWidthOrientation
PAPER-COLLECTION-ITEM
(1):(N) Relationship
Independent Entity
Dependent Entity
Associative Entity
Attributive Entity
Subtype Entities
Primary Key
Entity Name
Entity Name
(1):N Relationship
Attributes
6Copyright © 2004 Booz Allen Hamilton
Applying CPM 4.2 Rules to E-R Diagrams
7Copyright © 2004 Booz Allen Hamilton
The basic methodology follows CPM 4.2 guidance
Identify and classify logical
files
Identify and classify logical
files
Identify record element types
(RETs)
Identify record element types
(RETs)
Nothing
new here!Nothing
new here!Identify data
element types (DETs)
Identify data element types
(DETs)
8Copyright © 2004 Booz Allen Hamilton
A logical file is a logical group of data from the user’s perspective
Logical files can consist of one or more data entities
Basic identification and classification process
Identify and classify logical
files
Identify and classify logical
files
Identify and classify logical
files
Identify and classify logical
files
Identify entities that should be considered
for counting
Identify entities that should be considered
for countingIdentify the
user/business view of the data
Identify the user/business view
of the dataClassify identified
logical files as ILF or EIF
Classify identified logical files as ILF or
EIF
9Copyright © 2004 Booz Allen Hamilton
Not all entities in an E-R diagram should be included in a function point analysis
Clear guiding principle: do not consider entities that are not significant to and required by the end user
Do NOT include– Entities that contain technical attributes only (index
files)
– Associative entities that contain only technical attributes or are a result of design or implementation considerations
– Associative entities that only have keys as their data elements
– Entities that are not maintained by an elementary process, either within the boundary of the application or by another application (reference tables)
Make sure to include logical files that exist based on user need, but may not show up on the E-R diagram, such as historical files
Identify and classify logical
files
Identify and classify logical
files
Identify and classify logical
files
Identify and classify logical
files
Identify entities that should be considered
for counting
Identify entities that should be considered
for counting
Identify entities that should be considered
for counting
Identify entities that should be considered
for counting
COLLECTION ID
Collection NumberCalendar YearTitleType CodeSummaryRecords Schedule NoLegacy IdentifierEntry Date/TimeRelease Date/TimeLast Edit Date/Time
COLLECTION
COLLECTION ID
Collection NumberCalendar YearTitleType CodeSummaryRecords Schedule NoLegacy IdentifierEntry Date/TimeRelease Date/TimeLast Edit Date/Time
COLLECTION
PERSON ID (FK)COLLECTION ID (FK)PERSON ID (FK)COLLECTION ID (FK)
PERSON-COLLECTIONPERSON ID
Last NameFirst NameMiddle InitialTitleAddressCity StateZipOrganization ID (FK)
Key-Only Associative Entity
Key-Only Associative Entity
10Copyright © 2004 Booz Allen Hamilton
The users’ business view of the data can be determined by how transactions will access that data
Elementary process method– With guidance from analysts or end users, identify how elementary processes will
use external inputs to maintain the entities
– Entities created and deleted together strongly suggests a single file
– Be wary of elementary processes that modify the data; modification transactions often refer to a single entity with a logical group
Entity dependency method– Assess the independence or dependence of entities to appropriately group
logically related data
Identify and classify logical
files
Identify and classify logical
files
Identify and classify logical
files
Identify and classify logical
files
Identify the user/business view
of the data
Identify the user/business view
of the data
Identify the user/business view
of the data
Identify the user/business view
of the data
Independent entity: meaningful and significant to the end user
without presence of other entities
Independent entity: meaningful and significant to the end user
without presence of other entitiesQuick
RefresherQuick
Refresher Dependent entity: has no
significance to the business without presence of other entities
Dependent entity: has no significance to the business
without presence of other entities
11Copyright © 2004 Booz Allen Hamilton
Entity (in-)dependence in a (1):(N) relationship
Relationship is completely optional in both directions– Entities can exist completely independently
– Count as two separate logical files
Identify and classify logical
files
Identify and classify logical
files
Identify and classify logical
files
Identify and classify logical
files
Identify the user/business view
of the data
Identify the user/business view
of the data
Identify the user/business view
of the data
Identify the user/business view
of the data
PERSON ID
Last NameFirst NameMiddle InitialTitleAddressCity StateZipOrganization ID (FK)
PERSON
ORGANIZATION ID
NameType
ORGANIZATION
(1):(N) Relationship
2 Logical Files - Person - Organization
2 Logical Files - Person - Organization
12Copyright © 2004 Booz Allen Hamilton
Entity (in-)dependence in a 1:(N) relationship
Relationship is optional in one direction– An instance of entity A may exist to which none, one, or many instances of B are
linked
Ask questions– Is B significant to the business apart from the A linked to it?
– If we want to delete an instance of A, what happens to the linked instances of B?• If all Bs are deleted with A, then B is dependent on A Count as a single logical file• If A is not allowed to be deleted because Bs are still linked to it, then B is independent
of A Count as two separate logical files
Identify and classify logical
files
Identify and classify logical
files
Identify and classify logical
files
Identify and classify logical
files
Identify the user/business view
of the data
Identify the user/business view
of the data
Identify the user/business view
of the data
Identify the user/business view
of the data
Job ID (PK)
Charge NumberClientContracting Officer
Job ID (PK)
Charge NumberClientContracting Officer
Time Sheet ID (PK)
Job ID (FK)Employee IDHoursDate
Time Sheet ID (PK)
Job ID (FK)Employee IDHoursDate
JOBS TIME SHEETS
1:(N) Relationship
If you cannot delete a job if it is still in use
on a time sheet, then count 1 logical file
If you cannot delete a job if it is still in use
on a time sheet, then count 1 logical file
13Copyright © 2004 Booz Allen Hamilton
Entity (in-)dependence in a (1):N relationship
Relationship is optional in one direction (not too common)– Each instance of entity A must be assigned to
one or many Bs, but B may or may not be assigned to an instance of A
Ask questions– Is A significant to the business apart from the B
linked to it?
– If we want to delete an instance of B, what happens to the linked instances of A?• If all As are deleted with B, then A is dependent
on B Count as a single logical file• If B is not allowed to be deleted because As are
still linked to it, then A is independent of B Count as two separate logical files
Identify and classify logical
files
Identify and classify logical
files
Identify and classify logical
files
Identify and classify logical
files
Identify the user/business view
of the data
Identify the user/business view
of the data
Identify the user/business view
of the data
Identify the user/business view
of the data
(1):N Relationship
COLLECTION ID
Collection NumberCalendar YearTitleType CodeSummaryRecords Schedule NoLegacy IdentifierEntry Date/TimeRelease Date/TimeLast Edit Date/Time
COLLECTION
COLLECTION ID
Collection NumberCalendar YearTitleType CodeSummaryRecords Schedule NoLegacy IdentifierEntry Date/TimeRelease Date/TimeLast Edit Date/Time
COLLECTIONCOLLECTION-ITEM ID COLLECTION ID (FK)
Collection-Item NumberTitleAuthorDateSummaryPage CountTypeStatusMedia Type CodeRestricted Viewing Code Effective Date
COLLECTION-ITEM
COLLECTION-ITEM ID COLLECTION ID (FK)
Collection-Item NumberTitleAuthorDateSummaryPage CountTypeStatusMedia Type CodeRestricted Viewing Code Effective Date
COLLECTION-ITEM
If COLLECTION-ITEM is deleted when COLLECTION
is deleted, then count 1 logical file
If COLLECTION-ITEM is deleted when COLLECTION
is deleted, then count 1 logical file
14Copyright © 2004 Booz Allen Hamilton
Entity (in-)dependence in a 1:N relationship
Relationship is mandatory in both directions– Each instance of entity A must be assigned to one or many Bs, and B must be
assigned to an instance of A
Ask questions– Is B significant to the business apart from the A linked to it?
– If the answer is “no” Count as a single logical file– If the answer is “yes” Count as two separate logical files
Identify and classify logical
files
Identify and classify logical
files
Identify and classify logical
files
Identify and classify logical
files
Identify the user/business view
of the data
Identify the user/business view
of the data
Identify the user/business view
of the data
Identify the user/business view
of the data
Supervisor ID (PK)
NameTitleOrganization
Employee ID (PK)
NameOfficeOrganizationSalary
SUPERVISOR EMPLOYEE
Supervisor ID (PK)
NameTitleOrganization
Supervisor ID (PK)
NameTitleOrganization
Employee ID (PK)
NameOfficeOrganizationSalary
Employee ID (PK)
NameOfficeOrganizationSalary
SUPERVISOR EMPLOYEEEMPLOYEE has business
significance apart from SUPERVISOR, so count 2
logical files
EMPLOYEE has business significance apart from
SUPERVISOR, so count 2 logical files
1:N Relationship
15Copyright © 2004 Booz Allen Hamilton
Check identified logical files against ILF/EIF counting rules in CPM 4.2
If the file is maintained by elementary processes within the boundary of the application being counted, classify as an internal logical file (ILF)
If the file is only referenced by the application being counted, and it is maintained by an elementary process of another application, classify as an external interface file (EIF)
Identify and classify logical
files
Identify and classify logical
files
Identify and classify logical
files
Identify and classify logical
files
Classify identified logical files as ILF or
EIF
Classify identified logical files as ILF or
EIF
Classify identified logical files as ILF or
EIF
Classify identified logical files as ILF or
EIF
16Copyright © 2004 Booz Allen Hamilton
Identify record element types
(RETs)
Identify record element types
(RETs)
Identify record element types
(RETs)
Identify record element types
(RETs)RETs represent the user’s perspective on coherent subgroups of data within a logical file
This step in the methodology primarily looks at dependent entities in the E-R diagram that were determined not to be separate logical files
Associative Entities
Attributive Entities
Subtype Entities
17Copyright © 2004 Booz Allen Hamilton
Student ID (PK)
Student NameStudent MajorStudent GPA
Student ID (PK)Course No (PK)
Course No (PK)
Course TitleCourse DescriptionCredit Hours
Course No (PK)
Course TitleCourse DescriptionCredit Hours
STUDENTSTUDENT COURSE
COURSE
Student ID (PK)
Student NameStudent MajorStudent GPA
Student ID (PK)Course No (PK)
Student Course Grade
Course No (PK)
Course TitleCourse DescriptionCredit Hours
Course No (PK)
Course TitleCourse DescriptionCredit Hours
STUDENTSTUDENT COURSE
COURSE
Identify record element types
(RETs)
Identify record element types
(RETs)
Identify record element types
(RETs)
Identify record element types
(RETs)Associative entities help to define many-to-many relationships
In order to identify RETs, follow CPM 4.2 guidelines– Identify the business need and use for the data in the associative entity
– Review the nature of the data elements within the associative entity
If the associative entity only contains primary keys from intersecting entities, then do notconsider a RET
If the associative entity contains at least one other attribute recognizable by the user, count as a RET
18Copyright © 2004 Booz Allen Hamilton
Identify record element types
(RETs)
Identify record element types
(RETs)
Identify record element types
(RETs)
Identify record element types
(RETs)Attributive entities further describe one or more characteristics of another entity
The nature of attributive entities mean that it must be included in the function point analysis, either as a RET of a logical file or an extension of a logical file– Optional attributive entities are counted as RETS
– Mandatory attributive entities are considered part of the larger logical file to which it is related
COLLECTION-ITEM ID COLLECTION ID (FK)
Collection-Item NumberTitleAuthorDateSummaryPage CountTypeStatusMedia Type CodeRestricted Viewing Code Effective Date
COLLECTION-ITEM
COLLECTION-ITEM ID COLLECTION ID (FK)
Collection-Item NumberTitleAuthorDateSummaryPage CountTypeStatusMedia Type CodeRestricted Viewing Code Effective Date
COLLECTION-ITEM
ELECTRONIC-COLLECTION-ITEM NameELECTRONIC-COLLECTION-ITEM File PathCOLLECTION-ITEM ID COLLECTION ID (FK)
File TypeVersion NumberFile SizeURL
ELECTRONIC COLLECTION-ITEM
ELECTRONIC-COLLECTION-ITEM NameELECTRONIC-COLLECTION-ITEM File PathCOLLECTION-ITEM ID COLLECTION ID (FK)
File TypeVersion NumberFile SizeURL
ELECTRONIC COLLECTION-ITEM
ELECTRONIC-COLLECTION-ITEM is an optional attributive entity, so
count as an additional RET
ELECTRONIC-COLLECTION-ITEM is an optional attributive entity, so
count as an additional RET
19Copyright © 2004 Booz Allen Hamilton
Identify record element types
(RETs)
Identify record element types
(RETs)
Identify record element types
(RETs)
Identify record element types
(RETs)Subtype entities augment a unique occurrence of an entity with additional characteristics and/or relationships
Subtypes carry the entire key of its supertype
Subtypes inherit the attributes and relationships of the supertype
Look for unique attributes and get to the user intent of separate subtypes
If there are separate add/update transactions with unique attributes for entity subtypes, this mayindicate separate RETs
COLLECTION-ITEM ID COLLECTION ID (FK)
Collection-Item NumberTitleAuthorDateSummaryPage CountTypeStatusMedia Type CodeRestricted Viewing Code Effective Date
COLLECTION-ITEM
COLLECTION-ITEM ID COLLECTION ID (FK)
Collection-Item NumberTitleAuthorDateSummaryPage CountTypeStatusMedia Type CodeRestricted Viewing Code Effective Date
COLLECTION-ITEM
COLLECTION-ITEM ID (FK) COLLECTION ID (FK)
TypeLengthDate
AUDIO-COLLECTION-ITEM
COLLECTION-ITEM ID (FK) COLLECTION ID (FK)
TypeLengthDate
AUDIO-COLLECTION-ITEM
COLLECTION-ITEM ID (FK) COLLECTION ID (FK)
HeightWidthOrientation
PAPER-COLLECTION-ITEM
COLLECTION-ITEM ID (FK) COLLECTION ID (FK)
HeightWidthOrientation
COLLECTION-ITEM ID (FK) COLLECTION ID (FK)
HeightWidthOrientation
PAPER-COLLECTION-ITEM
These subtype entities are logical subgroupings that are relevant to
the end user, so count as 2 additional RETs
These subtype entities are logical subgroupings that are relevant to
the end user, so count as 2 additional RETs
20Copyright © 2004 Booz Allen Hamilton
Attributes can give a good indication as to what data element types should be counted in the FPA
CPM 4.2 rules: count each user recognizable field maintained in or retrieved from a logical file through the execution of an elementary process
Attributes that are used together in entirety should be counted as a single DET– Person name, address are examples of attributes to consider
– But if in some situations, only parts of the attributes are used, separate DETs might be appropriate
Look for “sort” or “edit” requirements that would suggest independence from the users perspective
Make sure attributes are recognized by the user and are not the simply the result of some technical requirement
Don’t forget foreign keys – Count a DET for each piece of data required by the user to establish a relationship with another
logical file
Identify data element types
(DETs)
Identify data element types
(DETs)
Identify data element types
(DETs)
Identify data element types
(DETs)
21Copyright © 2004 Booz Allen Hamilton
COLLECTION ID
Collection NumberCalendar YearTitleType CodeSummaryRecords Schedule NoLegacy IdentifierEntry Date/TimeRelease Date/TimeLast Edit Date/Time
COLLECTION
COLLECTION ID
Collection NumberCalendar YearTitleType CodeSummaryRecords Schedule NoLegacy IdentifierEntry Date/TimeRelease Date/TimeLast Edit Date/Time
COLLECTION
PERSON ID (FK)COLLECTION ID (FK)PERSON ID (FK)COLLECTION ID (FK)
PERSON-COLLECTIONPERSON ID
Last NameFirst NameMiddle InitialTitleAddressCity StateZipOrganization ID (FK)
PERSON
ORGANIZATION ID
NameType
ORGANIZATION
COLLECTION-ITEM ID COLLECTION ID (FK)
Collection-Item NumberTitleAuthorDateSummaryPage CountTypeStatusMedia Type CodeRestricted Viewing Code Effective Date
COLLECTION-ITEM
ELECTRONIC-COLLECTION-ITEM NameELECTRONIC-COLLECTION-ITEM File PathCOLLECTION-ITEM ID COLLECTION ID (FK)
File TypeVersion NumberFile SizeURL
ELECTRONIC COLLECTION-ITEM
COLLECTION-ITEM ID (FK) COLLECTION ID (FK)
TypeLengthDate
AUDIO-COLLECTION-ITEM
COLLECTION-ITEM ID (FK) COLLECTION ID (FK)
HeightWidthOrientation
PAPER-COLLECTION-ITEM
COLLECTION ID
Collection NumberCalendar YearTitleType CodeSummaryRecords Schedule NoLegacy IdentifierEntry Date/TimeRelease Date/TimeLast Edit Date/Time
COLLECTION
COLLECTION ID
Collection NumberCalendar YearTitleType CodeSummaryRecords Schedule NoLegacy IdentifierEntry Date/TimeRelease Date/TimeLast Edit Date/Time
COLLECTION
PERSON ID (FK)COLLECTION ID (FK)PERSON ID (FK)COLLECTION ID (FK)
PERSON-COLLECTIONPERSON ID
Last NameFirst NameMiddle InitialTitleAddressCity StateZipOrganization ID (FK)
PERSON
ORGANIZATION ID
NameType
ORGANIZATION
COLLECTION-ITEM ID COLLECTION ID (FK)
Collection-Item NumberTitleAuthorDateSummaryPage CountTypeStatusMedia Type CodeRestricted Viewing Code Effective Date
COLLECTION-ITEM
ELECTRONIC-COLLECTION-ITEM NameELECTRONIC-COLLECTION-ITEM File PathCOLLECTION-ITEM ID COLLECTION ID (FK)
File TypeVersion NumberFile SizeURL
ELECTRONIC COLLECTION-ITEM
COLLECTION-ITEM ID (FK) COLLECTION ID (FK)
TypeLengthDate
AUDIO-COLLECTION-ITEM
COLLECTION-ITEM ID (FK) COLLECTION ID (FK)
HeightWidthOrientation
PAPER-COLLECTION-ITEM
Key-Only Associative Entity
Independent Entities
Attributive Entities
Subtype Entities
22Copyright © 2004 Booz Allen Hamilton
Function Point Count, assuming all logical files are maintained by the application
Average
Low
Low
Complexity
1020-50
5(collection, collection-item, electronic-collection-item,
audio-collection-item, paper-collection-item)
CollectionILF
Person
Organization
Name
24Total
7Less than 201 (person)ILF
7Less than 201 (organization)ILF
UFPDETsRETsFile Type
23Copyright © 2004 Booz Allen Hamilton
Backup Slides
24Copyright © 2004 Booz Allen Hamilton
Summary of relationships and counting guidelines
1 LF, 2 RETS, sum DETS: count each unique, non-repeated fieldB is dependent on AN:(M)
2 LF, DETS: count each unique, non-repeated field for each LFB is independent of A
2 LF, DETS: count each unique, non-repeated field for each LFB is independent of A
2 LF, DETS: count each unique, non-repeated field for each LFB is independent of A
2 LF, DETS: count each unique, non-repeated field for each LFB is independent of A
2 LF, DETS: count each unique, non-repeated field for each LFB is independent of A
2 LF, DETS: count each unique, non-repeated field for each LFB is independent of A
1 LF, 2 RETS, sum DETS: count each unique, non-repeated fieldB is dependent on AN:M
2 LF, DETS: count each unique, non-repeated field for each LFA and B are independent(N):(M)
1 LF, 2 RETS, sum DETS: count each unique, non-repeated fieldB is dependent on A1:(1)
1 LF, 2 RETS, sum DETS: count each unique, non-repeated fieldA and B are dependent1:12 LF, DETS: count each unique, non-repeated field for each LFA and B are independent(1):(1)
1 LF, 2 RETS, sum DETS: count each unique, non-repeated fieldB is dependent on A(1):N
1 LF, 2 RETS, sum DETS: count each unique, non-repeated field1B is dependent on A1:(N)
1 LF, 2 RETS, sum DETS: count each unique, non-repeated fieldB is dependent on A1:N
2 LFs, DETS to eachA and B are independent(1):(N)
FP Counting GuidelinesConditionsType of relationship between entities A
and B
25Copyright © 2004 Booz Allen Hamilton
Sources
Kroenke, David M. Database Processing: Fundamentals, Design, Implementation, 7th ed.,Prentice Hall, 2000.
International Function Point Users Group, Practical Guidelines for Counting Logical Files, Version 1.0, September 2001.
Hay, David C., “A Comparison of Data Modeling Techniques,” Essential Strategies, Inc., 1999.