Relationships

Post on 09-Jul-2015

105 views 0 download

description

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.

Transcript of Relationships

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 relationshipsJuly 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