• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content




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.

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.



Total Views
Views on SlideShare
Embed Views



0 Embeds 0

No embeds


Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment

    Relationships Relationships Presentation Transcript

    • Relationships The [Missing] Link Michael P. Meier Michael Meier Data Management
    • 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 www.michaelmeierdata.com 2
    • 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 www.michaelmeierdata.com 3
    • 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 www.michaelmeierdata.com 4
    • Chen Diagram doctor doctor consultation Dr-pt residency July 2013 www.michaelmeierdata.com 5
    • 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 www.michaelmeierdata.com 6
    • “Modern” Interpretation Doctor Doctor or Doctor We usually don’t even get names on the “relationships.” July 2013 www.michaelmeierdata.com 7
    • 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 www.michaelmeierdata.com 8
    • 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 www.michaelmeierdata.com 9
    • Even Worse Doctor This is what we usually see. This is the barest hint about the possible existence of relationships July 2013 www.michaelmeierdata.com 10
    • 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 www.michaelmeierdata.com 11
    • Undefined Relationships  Result in poorly designed user interfaces  Undocumented rules  Reporting nightmares  Data degradation  Unattributed or improperly attributed costs to the business July 2013 www.michaelmeierdata.com 12
    • 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 www.michaelmeierdata.com 13
    • 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 www.michaelmeierdata.com 14