Published on

Relationships in depth. We typically conclude our modeling effort much too soon. Pursuing relationships will add value to the database application, give it a longer life and increase satisfaction.

Published in: Technology, Health & Medicine
  • Be the first to comment

  • Be the first to like this


  1. 1. Relationships The [Missing] Link Michael P. Meier Michael Meier Data Management
  2. 2. What I’m Going to Tell You  Data Architects ignore relationships  This includes all types  Inter-personal  Logical  Physical (data)  We’re suffering without relationship  Here’s what we need to do. July 2013 2
  3. 3. Modeling Formalisms  ERA (entity-relationship-attribute and variants)  UML (unified modeling language)  ORM (object-role model)  None today give more than lip service July 2013 3
  4. 4. It wasn’t always so  Peter Chen (1976)* represented relationships as diamond-shaped  Two-dimensional symbols gave relationships equal weight with entities  3NF relational schemas were the goal *1976 article published in ACM’s Transactions on Database Systems July 2013 4
  5. 5. Chen Diagram doctor doctor consultation Dr-pt residency July 2013 5
  6. 6. Chen Diagram Suggests  Three different relationships exist between two doctors  An implementation consisting of three tables to represent the relationships  The relationships may have additional properties that are different  Dates (start, end)  Relationships to other entities  Rotation, Diagnosis, Recommendation,… July 2013 6
  7. 7. “Modern” Interpretation Doctor Doctor or Doctor We usually don’t even get names on the “relationships.” July 2013 7
  8. 8. Which Suggests  Three foreign key references to Doctor within the Doctor table  Meaning that  Additional relationships and attributes are lost.  Or, 3NF is lost (by including information about the relationship in the Doctor entity) July 2013 8
  9. 9. More Importantly  The relationship is a detail  A connector on a diagram  When it should be a core piece of intelligence about the business  The majority of business rules are about relationships.  Models and applications suffer from trivializing relationships July 2013 9
  10. 10. Even Worse Doctor This is what we usually see. This is the barest hint about the possible existence of relationships July 2013 10
  11. 11. Effect on Data Quality  Inattention to relationships leads to the worst sort of data quality problem.  The “I meant” problem  A foreign key column in a table contains values that share  Data type  Domain  Range  But were placed there for different reasons  Therefore have different semantic values July 2013 11
  12. 12. Undefined Relationships  Result in poorly designed user interfaces  Undocumented rules  Reporting nightmares  Data degradation  Unattributed or improperly attributed costs to the business July 2013 12
  13. 13. Suggestions  Always name relationships—including role names  Supply a description for the relationship  Model relationships as entities  Most relationships have attributes  Events are really relationships  Often n-ary relationships (more than two participants)  Generation of relationships as entities (tables) is a preference item in your modeling tool  Think, really think, before you “denormalize” your physical model  Don’t “denormalize” without normalizing  At least start with a normalized model  Many use “denormalize” as an excuse not to do the work. July 2013 13
  14. 14. There is nothing simple about a relationship. Ask your spouse, significant other, friends, neighbors… Relationships are continuously being renegotiated (changing). Give them attention up front or pay dearly later. July 2013 14