Relationship

Search this site with Google

The connection, association or involvement between two or more items

Theory

There are many ways to represent information, for example it is common to define a data model and populate it with the values we wish to store. This works well if we know the structure of the data before we start gathering it. In this case the way that one entity is related to another is described by the attributes within the model.

However it is unusual to know before hand what all the relationships will be as more categories are added. The most generic way to represent relationships is by defining combinations that hold the relationship and roles. For example we can define the "isPartOf" relationship as a triple {"isPartOf","engine","car"}. This is the most common way to define a general ontology.

Unlike in the fixed data model this approach is completely flexible, it allows us to describe any set of relationships we want. Or to put it another way. Unlike the precise definitions in a data model this approach is completely uncontrolled, any interaction that pops into the implementors head can be added without them having to define exactly what they mean.

Another approach that avoids the inflexibilty of the fixed model and reduces the potential chaos of the generic ontology is to divide relationships into two groups:

  • Hierarchical: Such as parent, child relations
  • Inter-Entity: Where pairs of entities are related

The first relationship can be handled by defining entities within a valid taxonomy. The second by defining a matrix that relates the lowest level of one hierarchy to the other.

This approach simplifies the task of describing the relationships, however it still delivers enough flexibility to make maintaining the complete picture an issue. The information architect still needs to be cautious.

Relationship Count

If a relationship between two {entity|entities} exists it can be one of four types:

  • One to One: Each source entity relates to exactly one target, each target relates to a single source
  • One to Many: Each source entity can relate to one or more targets, but each target only relates to a single source
  • Many to One: Each source entity relates to exactly one target, but that can be related to many sources
  • Many to Many: Any number of sources and targets are related to each other

The first of these is not commonly encountered, when it is there may be an issue with the definitions of the two entities involved, are they really just two parts of the same thing?

The second and third are common. And usually good candidates for inclusion in a data model.

The last is often the most difficult to deal with. It imposes no restrictions on the entities and may have to be modeled in an innovative way. Unfortunately it is also probably the most commonly encountered of the four.

Ontology

Ontology, Taxonomy Relational Data Model

  • Part of:
  • Contains:
  • Type Of:
  • Parent:
  • Child:
  • Grandparent:
  • Leaf:

Practice

Rendition

Implementation

Links to this page

The following pages link to here: Aspect, Classification, Computer Science, Concept Map, Data Form, Data Migration, Data Model, Hierarchical, IA Best Practice, Implementing IA, Inference, Knowledge Based Systems, Many to Many, Many to One, One to Many, One to One, Ontology, UML Structure Diagrams, Unified Modeling Language, Uses for IA


Comment on the contents of the 'Relationship' page
Subject: Email to Reply To (optional):