Using Entity-Relationship Diagrams To Count Data Functions Ian Brown, CFPS Booz Allen Hamilton 8283 Greensboro Dr. McLean, VA USA

Transcription

1 Using Entity-Relationship Diagrams To Count Data Functions Ian Brown, CFPS Booz Allen Hamilton 8283 Greensboro Dr. McLean, VA USA

2 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.2 Rules 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 1

3 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 Attribute Attribute Attribute Entity Relationship Entity Attribute Attribute Relationship Attribute Attribute There is no single, generally accepted standard E-R model Entity Attribute E-R E-R Modeling Modeling Tools Tools Case Case Wise Wise ERwin ERwin S-Designer S-Designer ER/Studio ER/Studio Visio Visio 2

4 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 3

5 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? 4

6 E-R Diagram Example (IDEF1X) Entity Name Entity Name Primary Key Independent Entity (1):N Relationship AUDIO- COLLECTION- ITEM COLLECTION COLLECTION ID Collection Number Calendar Year Type Code Summary Records Schedule No Legacy Identifier Entry Date/Time Release Date/Time Last Edit Date/Time COLLECTION-ITEM ID (FK) Type Length Date Subtype Entities PERSON-COLLECTION PERSON ID (FK) COLLECTION-ITEM COLLECTION-ITEM ID Collection-Item Number Author Date Summary Page Count Type Status Media Type Code Restricted Viewing Code Effective Date COLLECTION-ITEM ID (FK) Height Width Orientation Associative Entity PAPER- COLLECTION- ITEM PERSON PERSON ID Last Name First Name Middle Initial Address City State Zip Organization ID (FK) ELECTRONIC COLLECTION-ITEM ORGANIZATION ORGANIZATION ID Name Type ELECTRONIC-COLLECTION-ITEM Name ELECTRONIC-COLLECTION-ITEM File Path COLLECTION-ITEM ID File Type Version Number File Size URL Attributes Dependent Entity (1):(N) Relationship Attributive Entity 5

7 Applying CPM 4.2 Rules to E-R Diagrams 6

8 The basic methodology follows CPM 4.2 guidance Identify and and classify logical Identify record element types (RETs) Nothing Nothing new new here! here! Identify data data element types (DETs) 7

9 A logical file is a logical group of data from the user s perspective Logical can consist of one or more data entities Basic identification and classification process Identify and and classify logical Identify Identify entities entities that that should should be be considered considered for for counting counting Identify Identify the the user/business user/business view view of of the the data data Classify Classify identified identified logical logical as as ILF ILF or or EIF EIF 8

10 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 ) 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) COLLECTION COLLECTION ID Collection Number Calendar Year Type Code Summary Records Schedule No Legacy Identifier Entry Date/Time Release Date/Time Last Edit Date/Time Key-Only Associative Entity PERSON-COLLECTION PERSON ID (FK) Identify and and classify logical Identify Identify entities entities that that should should be be considered considered for for counting counting PERSON ID Last Name First Name Middle Initial Address City State Zip Organization ID (FK) Make sure to include logical that exist based on user need, but may not show up on the E-R diagram, such as historical 9

11 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 Identify and and classify logical Identify Identify the the user/business user/business view view of of the the data data Entity dependency method Assess the independence or dependence of entities to appropriately group logically related data Quick Quick Refresher Refresher Independent Independent entity: entity: meaningful meaningful and and significant significant to to the the end end user user without without presence presence of of other other entities entities Dependent Dependent entity: entity: has has no no significance significance to to the the business business without without presence presence of of other other entities entities 10

12 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 Identify and and classify logical Identify Identify the the user/business user/business view view of of the the data data PERSON PERSON ID Last Name First Name Middle Initial Address City State Zip Organization ID (FK) ORGANIZATION ORGANIZATION ID Name Type (1):(N) Relationship 2 Logical Logical Files Files --Person Person --Organization 11

13 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 Identify and and classify logical Identify Identify the the user/business user/business view view of of the the data data JOBS Job ID (PK) Charge Number Client Contracting Officer 1:(N) Relationship TIME SHEETS Time Sheet ID (PK) Job ID (FK) Employee ID Hours Date If If you cannot delete a job if if it it is is still in in use on on a time sheet, then count 1 logical file 12

14 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 COLLECTION COLLECTION ID Collection Number Calendar Year Type Code Summary Records Schedule No Legacy Identifier Entry Date/Time Release Date/Time Last Edit Date/Time (1):N Relationship Identify and and classify logical Identify Identify the the user/business user/business view view of of the the data data COLLECTION-ITEM COLLECTION-ITEM ID If If COLLECTION-ITEM is is deleted when COLLECTION is is deleted, then count 1 logical file Collection-Item Number Author Date Summary Page Count Type Status Media Type Code Restricted Viewing Code Effective Date 13

15 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 Identify and and classify logical Identify Identify the the user/business user/business view view of of the the data data SUPERVISOR Supervisor ID (PK) Name Organization EMPLOYEE Employee ID (PK) Name Office Organization Salary EMPLOYEE has business significance apart from SUPERVISOR, so so count 2 logical 1:N Relationship 14

16 Check identified logical 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) Identify and and classify logical Classify Classify identified identified logical logical as as ILF ILF or or EIF EIF 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) 15

17 RETs represent the user s perspective on coherent subgroups of data within a logical file Identify record element types (RETs) This step in the methodology primarily looks at dependent entities in the E-R diagram that were determined not to be separate logical Associative Entities Attributive Entities Subtype Entities 16

18 Associative entities help to define many-to-many relationships Identify record element types (RETs) 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 not consider a RET STUDENT Student ID (PK) Student Name Student Major Student GPA STUDENT COURSE Student ID (PK) Course No (PK) COURSE Course No (PK) Course Course Description Credit Hours If the associative entity contains at least one other attribute recognizable by the user, count as a RET STUDENT Student ID (PK) Student Name Student Major Student GPA STUDENT COURSE Student ID (PK) Course No (PK) Student Course Grade COURSE Course No (PK) Course Course Description Credit Hours 17

19 Attributive entities further describe one or more characteristics of another entity Identify record element types (RETs) 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 COLLECTION-ITEM ID Collection-Item Number Author Date Summary Page Count Type Status Media Type Code Restricted Viewing Code Effective Date ELECTRONIC COLLECTION-ITEM ELECTRONIC-COLLECTION-ITEM Name ELECTRONIC-COLLECTION-ITEM File Path COLLECTION-ITEM ID File Type Version Number File Size URL ELECTRONIC-COLLECTION-ITEM is is an an optional attributive entity, so so count as as an an additional RET 18

20 Subtype entities augment a unique occurrence of an entity with additional characteristics and/or relationships Identify record element types (RETs) 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 may indicate separate RETs These subtype entities are logical subgroupings that are relevant to to the end user, so so count as as 2 additional RETs AUDIO- COLLECTION-ITEM COLLECTION-ITEM ID (FK) Type Length Date COLLECTION-ITEM COLLECTION-ITEM ID Collection-Item Number Author Date Summary Page Count Type Status Media Type Code Restricted Viewing Code Effective Date PAPER-COLLECTION-ITEM COLLECTION-ITEM ID (FK) Height Width Orientation 19

21 Attributes can give a good indication as to what data element types should be counted in the FPA Identify data data element types (DETs) 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 20

22 COLLECTION COLLECTION ID Collection Number Calendar Year Type Code Summary Records Schedule No Legacy Identifier Entry Date/Time Release Date/Time Last Edit Date/Time AUDIO- COLLECTION- ITEM COLLECTION-ITEM ID (FK) Key-Only Associative Entity PERSON-COLLECTION PERSON ID (FK) COLLECTION-ITEM COLLECTION-ITEM ID Collection-Item Number Author Date Summary Page Count Type Status Media Type Code Restricted Viewing Code Effective Date PERSON PERSON ID Last Name First Name Middle Initial Address City State Zip Organization ID (FK) ORGANIZATION ORGANIZATION ID Name Type ELECTRONIC COLLECTION-ITEM ELECTRONIC-COLLECTION-ITEM Name ELECTRONIC-COLLECTION-ITEM File Path COLLECTION-ITEM ID File Type Version Number File Size URL Independent Entities Attributive Entities Type Length Date COLLECTION-ITEM ID (FK) Height Width Orientation PAPER- COLLECTION- ITEM Subtype Entities 21

23 Function Point Count, assuming all logical are maintained by the application File Type Name RETs DETs Complexity UFP ILF Organization 1 (organization) Less than 20 Low 7 ILF Person 1 (person) Less than 20 Low 7 ILF Collection 5 (collection, collection-item, electronic-collection-item, audio-collection-item, papercollection-item) Average 10 Total 24 22

24 Backup Slides 23

25 Summary of relationships and counting guidelines Type of relationship between entities A and B (1):(N) 1:N 1:(N) (1):N (1):(1) 1:1 1:(1) (N):(M) N:M N:(M) Conditions A and B are independent B is dependent on A B is independent of A B is dependent on A B is independent of A B is dependent on A B is independent of A A and B are independent A and B are dependent B is dependent on A B is independent of A A and B are independent B is dependent on A B is independent of A B is dependent on A B is independent of A FP Counting Guidelines 2 LFs, DETS to each 1 LF, 2 RETS, sum DETS: count each unique, non-repeated field 2 LF, DETS: count each unique, non-repeated field for each LF 1 LF, 2 RETS, sum DETS: count each unique, non-repeated field1 2 LF, DETS: count each unique, non-repeated field for each LF 1 LF, 2 RETS, sum DETS: count each unique, non-repeated field 2 LF, DETS: count each unique, non-repeated field for each LF 2 LF, DETS: count each unique, non-repeated field for each LF 1 LF, 2 RETS, sum DETS: count each unique, non-repeated field 1 LF, 2 RETS, sum DETS: count each unique, non-repeated field 2 LF, DETS: count each unique, non-repeated field for each LF 2 LF, DETS: count each unique, non-repeated field for each LF 1 LF, 2 RETS, sum DETS: count each unique, non-repeated field 2 LF, DETS: count each unique, non-repeated field for each LF 1 LF, 2 RETS, sum DETS: count each unique, non-repeated field 2 LF, DETS: count each unique, non-repeated field for each LF 24

26 Sources Kroenke, David M. Database Processing: Fundamentals, Design, Implementation, 7 th ed., Prentice Hall, International Function Point Users Group, Practical Guidelines for Counting Logical Files, Version 1.0, September Hay, David C., A Comparison of Data Modeling Techniques, Essential Strategies, Inc.,