Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Logical E/R Modeling: the Definition of
„Truth‟ for Data (#537)
Jeff Jacobs
Jeffrey Jacobs & Associates
Foster City, CA
ph...
 2 centuries of experience with data modeling and
Oracle, as consultant and trainer
Qualifications
2Copyright © Jeffrey M...
Survey
 How important is data to your organization?
 Do you have an organization responsible for
enterprise data?
 Are ...
Objective
 Learn the fundamentals of Entity Relationship
modeling
 Why?
 Improve overall quality of product requirement...
Copyright © Jeffrey M. Jacobs 5
Introduction to Entity Relationship Modeling
 ER modeling establishes the “information
re...
Copyright © Jeffrey M. Jacobs 6
ERD Example (Information Engineering)
Copyright © Jeffrey M. Jacobs 7
IDEFI1X Notation
Copyright © Jeffrey M. Jacobs 8
ERD Example (PowerDesigner “IE”)
subject of
to
subject to
for
cost center for
assigned to
...
Copyright © Jeffrey M. Jacobs 9
ERD Example (Oracle)
ER Modeling is “Semantic”
 ER modeling establishes information and data requirements,
without regard to the eventual impl...
Copyright © Jeffrey M. Jacobs 11
Entities
 “A thing of significance in the business about which
information must be kept ...
Copyright © Jeffrey M. Jacobs 12
Entity Example
Copyright © Jeffrey M. Jacobs 13
Supporting Information
Copyright © Jeffrey M. Jacobs 14
Instances and Occurrences
 Entity definition is a “type” or “class” description, e.g.
EM...
Copyright © Jeffrey M. Jacobs 15
Attributes
 “Individual, atomic pieces of data about an entity”
 Never used to refer to...
Copyright © Jeffrey M. Jacobs 16
Entity Example with Attributes
Copyright © Jeffrey M. Jacobs 17
Attribute Supporting Information
Copyright © Jeffrey M. Jacobs
18
Domains
 Domain is a centralized definition of valid values and datatype
information for...
Copyright © Jeffrey M. Jacobs 19
Domain Definition
Copyright © Jeffrey M. Jacobs 20
Relationships (not Relations)
 “A named/labeled association between two entities”
(drawn...
Copyright © Jeffrey M. Jacobs 21
Entities with Relationships Example
Copyright © Jeffrey M. Jacobs 22
Optionality
 Relationships have optionality expressed as either
mandatory or optional in...
Copyright © Jeffrey M. Jacobs 23
Cardinality
 (Maximum) Cardinality comes in two flavors
 1) “One and only one”, e.g. ea...
Copyright © Jeffrey M. Jacobs 24
Reading Relationships
 Proper reading of relationship contributes to reliability and
con...
Copyright © Jeffrey M. Jacobs 25
Optionality
 [MAY BE | MUST BE] expresses optionality; more
understandable than “zero”
...
Copyright © Jeffrey M. Jacobs 26
Relationship
 Read relationship name adjacent to entity1
 Example: EACH ENTITY1 MUST BE...
Copyright © Jeffrey M. Jacobs 27
Cardinality
 Look at symbols on line adjacent to <entity2> to determine
cardinality
 [O...
Copyright © Jeffrey M. Jacobs 28
Cardinality
 Look at symbols on line adjacent to <entity2> to determine
cardinality
 [O...
Copyright © Jeffrey M. Jacobs 29
Anthropological Examples
Copyright © Jeffrey M. Jacobs 30
Multiple Relationships Between Entities
Copyright © Jeffrey M. Jacobs 31
Reflexive/Recursive Relationships
 Relationships may exist between occurrences of the
sa...
Copyright © Jeffrey M. Jacobs 32
Relationship Reading Exercises
Copyright © Jeffrey M. Jacobs 33
Unique Identifiers (UID)
 A combination of attributes and/or relationships used to
uniqu...
Copyright © Jeffrey M. Jacobs 34
More UID
 All parts of UID must be mandatory
 Attributes that are part of UID are typic...
Copyright © Jeffrey M. Jacobs 35
UID Examples
Copyright © Jeffrey M. Jacobs 36
Super/subtype Entity Structure
 Subtype entities are “specializations” of supertype enti...
Copyright © Jeffrey M. Jacobs 37
Subtype
 Use special connectors
 May allow specification of exclusive/non-exclusive
(ak...
Copyright © Jeffrey M. Jacobs 38
Many to Many (M:M) Relationships
 The start of “conceptual modeling”
 M:M relationships...
Copyright © Jeffrey M. Jacobs 39
Resolving
 To resolve a M:M relationship:
 1) Create new entity
 2) Create relationshi...
Copyright © Jeffrey M. Jacobs 40
Resolving M:M
Copyright © Jeffrey M. Jacobs 41
 Create new entity with UID/dependant relationships
 New name is important! Not “EMP/PR...
Copyright © Jeffrey M. Jacobs 42
 Create new entity with UID/dependant relationships
 New name is important! Not “EMP/PR...
Copyright © Jeffrey M. Jacobs 43
 Re-examine for new attributes and relationships
Copyright © Jeffrey M. Jacobs 44
 Re-examine for new attributes and relationships
Copyright © Jeffrey M. Jacobs 45
QA‟ing ERDs
 For each entity:
 Is the name precise?
 Is the name a recognized business...
Copyright © Jeffrey M. Jacobs 46
QA of Relationships
 For each relationship:
 Is the optionality correct? (If it‟s manda...
Copyright © Jeffrey M. Jacobs 47
Summary (Please fill out Survery, #537)
 ERD captures information requirements
 Proper ...
Upcoming SlideShare
Loading in …5
×

Logical E/R Modeling: the Definition of ‘Truth’ for Data

553 views

Published on

Effective application development begins with understanding the requirements of business. Logical Entity/Relationship modeling is a well-defined, implementation independent, method for defining the information requirements.

This presentation teaches the fundamentals and underlying discipline of E/R modeling, with particular emphasis on the semantic approach to data modeling.

Published in: Data & Analytics, Technology
  • Be the first to comment

Logical E/R Modeling: the Definition of ‘Truth’ for Data

  1. 1. Logical E/R Modeling: the Definition of „Truth‟ for Data (#537) Jeff Jacobs Jeffrey Jacobs & Associates Foster City, CA phone: 650.571.7092 email: jmjacobs@jeffreyjacobs.com http://www.jeffreyjacobs.com
  2. 2.  2 centuries of experience with data modeling and Oracle, as consultant and trainer Qualifications 2Copyright © Jeffrey M. Jacobs
  3. 3. Survey  How important is data to your organization?  Do you have an organization responsible for enterprise data?  Are you using UML?  Does your organization have a methodology or process, such as Agile/RUP?  Developer?  Analyst?  DBA? Copyright © Jeffrey M. Jacobs 3
  4. 4. Objective  Learn the fundamentals of Entity Relationship modeling  Why?  Improve overall quality of product requirements  Ensure that all necessary data is present for all areas of products, including reporting  Understand the business requirements  Provide basis for implementation  Provide basis for UML class model 4Copyright © Jeffrey M. Jacobs
  5. 5. Copyright © Jeffrey M. Jacobs 5 Introduction to Entity Relationship Modeling  ER modeling establishes the “information requirements” of the business, e.g. What information must be kept to meet the functional requirements  An ER model consists of definitions of entities, attributes, relationships, domains and supporting detailed information  An ER Diagram (ERD) is a “picture” of the model  Numerous notations include Information Engineering (IE), IDEF1X, Oracle, Chen, UML (?)  Many tools have their own variation
  6. 6. Copyright © Jeffrey M. Jacobs 6 ERD Example (Information Engineering)
  7. 7. Copyright © Jeffrey M. Jacobs 7 IDEFI1X Notation
  8. 8. Copyright © Jeffrey M. Jacobs 8 ERD Example (PowerDesigner “IE”) subject of to subject to for cost center for assigned to EMPLOYEE ID Mand. NAME Mand. JOB TITLE SALARY HIRE DATE GENDER Mand. PROJECT ID Mand. NAME Mand. START DATE DESCRIPTION INTERNAL BUDGET Mand. JUSTIFICATION Mand. CUSTOMER CUSTOMER NAME Mand. CREDIT LIMIT DEPARTMENT ID Mand. NAME Mand. COST CENTER LOCATION WEEKLY ASSIGNMENT WEEK ENDING Mand. HOURS BILLED
  9. 9. Copyright © Jeffrey M. Jacobs 9 ERD Example (Oracle)
  10. 10. ER Modeling is “Semantic”  ER modeling establishes information and data requirements, without regard to the eventual implementation  implementation may be relational database, object stores, in-memory data or even paper  typical implementation is relational database  Also called “Semantic Data Model”  Sometime called “Conceptual”  “Physical Data Model” (PDM) has additional information for generating relational database; diagrams are similar  Disagreement over “Logical Data Model”... Copyright © Jeffrey M. Jacobs 10
  11. 11. Copyright © Jeffrey M. Jacobs 11 Entities  “A thing of significance in the business about which information must be kept and maintained”  Entity name is always singular  Entity name is meaningful to the business, part of common vocabulary  2 main categories of information  1) Attributes  2) Relationships with other entities  Drawn as square box  Additional information depends on tool, methodology
  12. 12. Copyright © Jeffrey M. Jacobs 12 Entity Example
  13. 13. Copyright © Jeffrey M. Jacobs 13 Supporting Information
  14. 14. Copyright © Jeffrey M. Jacobs 14 Instances and Occurrences  Entity definition is a “type” or “class” description, e.g. EMPLOYEE  Don‟t confuse entity “type” with “occurrence/instance” of an entity, e.g. Joan Smith is an occurrence of the entity type EMPLOYEE
  15. 15. Copyright © Jeffrey M. Jacobs 15 Attributes  “Individual, atomic pieces of data about an entity”  Never used to refer to another entity. (Attributes are not foreign keys in ER)  Some notations/tools show “foreign keys”  Attributes may be mandatory or optional  Mandatory means “every instance of the entity must, at all times, with no exceptions of any duration, have a valid, non-NULL value for the attribute”  Optional means “value may sometimes by undefined or unknown”, NULL  Usually indicated by “Not Null” or “Mand” or symbol; depends on tool
  16. 16. Copyright © Jeffrey M. Jacobs 16 Entity Example with Attributes
  17. 17. Copyright © Jeffrey M. Jacobs 17 Attribute Supporting Information
  18. 18. Copyright © Jeffrey M. Jacobs 18 Domains  Domain is a centralized definition of valid values and datatype information for attributes (and columns)  Attributes that “belong” to a domain inherit the characteristics of the domain, e.g. datatype information and allowable values  Example: “Gender” domain has datatype of VARCHAR2(1) and valid values of [M|F|U] with meanings of “Male”, “Female”, “Unknown”  Attributes can have the same name as the domain to which they belong  Domains may be “nested”, providing levels of validation, e.g. the SALARY domain belongs to the MONEY domain  No ”diagramming” technique for domains  Domains usually result in column constraints or reference tables/classes
  19. 19. Copyright © Jeffrey M. Jacobs 19 Domain Definition
  20. 20. Copyright © Jeffrey M. Jacobs 20 Relationships (not Relations)  “A named/labeled association between two entities” (drawn as a line)  Two names for a relationship, one for each direction  Naming is very important  critical to understanding  defines semantics in resulting implementation in business terms  Tools typically support additional definition, notes, etc.
  21. 21. Copyright © Jeffrey M. Jacobs 21 Entities with Relationships Example
  22. 22. Copyright © Jeffrey M. Jacobs 22 Optionality  Relationships have optionality expressed as either mandatory or optional in each direction  “Mandatory” means “every occurrence of the entity must always, at all times, with no exceptions of any duration, be associated with an instance of the entity at the other end”  “Optional” means “need not always be associated...”
  23. 23. Copyright © Jeffrey M. Jacobs 23 Cardinality  (Maximum) Cardinality comes in two flavors  1) “One and only one”, e.g. each occurrence of an entity may be associated with at most one occurrence at the other end; optionality determines if such an association must exist  2) “One or more”, e.g. each occurrence may be associated with zero (depending on optionality), one or more occurrences at the other end
  24. 24. Copyright © Jeffrey M. Jacobs 24 Reading Relationships  Proper reading of relationship contributes to reliability and confidence  Relationships should be understandable in both directions  Reading starts with <entity1>  EACH <entity1> [MAY BE | MUST BE] <rel1> [ONE OR MORE | ONE AND ONLY ONE] <entity2>  “EACH” reminds us that we are talking about instance/occurrences of entities
  25. 25. Copyright © Jeffrey M. Jacobs 25 Optionality  [MAY BE | MUST BE] expresses optionality; more understandable than “zero”  „o‟ on line at end opposite <entity1> is “MAY BE”  „|‟ on line at end opposite is “MUST BE”  [ONE OR MORE | ONE AND ONLY ONE] expresses maximum cardinality  presence of crow‟s foot at end opposite <entity1> is “ONE OR MORE”  absence of crow‟s foot at end opposite <entity1> is “ONE AND ONLY ONE”
  26. 26. Copyright © Jeffrey M. Jacobs 26 Relationship  Read relationship name adjacent to entity1  Example: EACH ENTITY1 MUST BE <rel1> ...
  27. 27. Copyright © Jeffrey M. Jacobs 27 Cardinality  Look at symbols on line adjacent to <entity2> to determine cardinality  [ONE OR MORE | ONE AND ONLY ONE] expresses maximum cardinality  1) presence of crow‟s foot at end adjacent to <entity2> is “ONE OR MORE”
  28. 28. Copyright © Jeffrey M. Jacobs 28 Cardinality  Look at symbols on line adjacent to <entity2> to determine cardinality  [ONE OR MORE | ONE AND ONLY ONE] expresses maximum cardinality  1) presence of crow‟s foot at end adjacent to <entity2> is “ONE OR MORE”  2) absence of crow‟s foot at end adjacent to <entity2> is “ONE AND ONLY ONE”
  29. 29. Copyright © Jeffrey M. Jacobs 29 Anthropological Examples
  30. 30. Copyright © Jeffrey M. Jacobs 30 Multiple Relationships Between Entities
  31. 31. Copyright © Jeffrey M. Jacobs 31 Reflexive/Recursive Relationships  Relationships may exist between occurrences of the same entity type  Recursive relationships are used for hierarchies and networks  Must be optional in both directions
  32. 32. Copyright © Jeffrey M. Jacobs 32 Relationship Reading Exercises
  33. 33. Copyright © Jeffrey M. Jacobs 33 Unique Identifiers (UID)  A combination of attributes and/or relationships used to uniquely identify and distinguish each occurrence of an entity from all others  No two occurrences may have the same set of values for all parts of the UID  UID may consist of  1) single attribute  2) multiple attributes  3) multiple relationships  4) combination of attribute(s) and relationship(s)
  34. 34. Copyright © Jeffrey M. Jacobs 34 More UID  All parts of UID must be mandatory  Attributes that are part of UID are typically in their own “box” with tool specific indicator  Relationships in a UID are indicated by a solid line in IE and IDEF1X; different in some tools (PowerDesigner and Oracle)
  35. 35. Copyright © Jeffrey M. Jacobs 35 UID Examples
  36. 36. Copyright © Jeffrey M. Jacobs 36 Super/subtype Entity Structure  Subtype entities are “specializations” of supertype entity  Subtype inherits all attributes and relationships of supertype entity  Occurrence of subtype is also occurrence of supertype; UID is always at the outermost supertype  Each subtype should (eventually) have its own attributes and/or relationships  Subtypes are “exhaustive”; all occurrences of the supertype must also be occurrence of a subtype  Subtypes are “exclusive and non-overlapping”; no occurrence can belong to more than one subtype (except via “nesting”)  Subtypes may be “complete” or “incomplete”  Complete means all subtypes are known
  37. 37. Copyright © Jeffrey M. Jacobs 37 Subtype  Use special connectors  May allow specification of exclusive/non-exclusive (aka overlapping/non-overlapping)  May allow specification of complete/incomplete
  38. 38. Copyright © Jeffrey M. Jacobs 38 Many to Many (M:M) Relationships  The start of “conceptual modeling”  M:M relationships “hide” important detail that must be discovered  M:M relationships should be eliminated by end of detailed requirements analysis  Iterative process of refinement
  39. 39. Copyright © Jeffrey M. Jacobs 39 Resolving  To resolve a M:M relationship:  1) Create new entity  2) Create relationships back to original entities  3) Include relationships as part of new entity‟s UID  4) Use meaningful names for new entity and relationships  5) Examine new entity for attributes and relationships  Major “flaw” in UML modeling techniques
  40. 40. Copyright © Jeffrey M. Jacobs 40 Resolving M:M
  41. 41. Copyright © Jeffrey M. Jacobs 41  Create new entity with UID/dependant relationships  New name is important! Not “EMP/PROJ”!!!
  42. 42. Copyright © Jeffrey M. Jacobs 42  Create new entity with UID/dependant relationships  New name is important! Not “EMP/PROJ”!!!
  43. 43. Copyright © Jeffrey M. Jacobs 43  Re-examine for new attributes and relationships
  44. 44. Copyright © Jeffrey M. Jacobs 44  Re-examine for new attributes and relationships
  45. 45. Copyright © Jeffrey M. Jacobs 45 QA‟ing ERDs  For each entity:  Is the name precise?  Is the name a recognized business term?  Is the name singular?  Can the name be improved?  For each attribute:  Is the attribute name precise?  Is the attribute name understandable?  Is the name a a recognized business term?  Is the optionality correct?  Can the name be improved?
  46. 46. Copyright © Jeffrey M. Jacobs 46 QA of Relationships  For each relationship:  Is the optionality correct? (If it‟s mandatory, are there any exceptions?)  Is the cardinality correct?  Is the name precise and meaningful? (Very important!!!)  Is the name a recognizable business term?  Can you find all of the information you need for your development area?
  47. 47. Copyright © Jeffrey M. Jacobs 47 Summary (Please fill out Survery, #537)  ERD captures information requirements  Proper reading eliminates ambiguity  ERD should be understood by all interested parties  Wording and terminology is critical

×