Content deleted Content added
Stephenpace (talk | contribs) See also |
|||
Line 27:
A generic data model obeys the following rules:
# Candidate attributes are treated as representing relationships to other entity types.
# Entity types are represented, and are named after, the underlying nature of a thing, not the role it plays in a particular context. Entity types are chosen. Thus as a result of this principle, any occurrence of an entity type will belong to it from the time it is created to the time it is destroyed, not just whilst it is of interest. This is important when managing the underlying data, rather than the views on it used by applications. We call entity types that conform to this principle generic entity types.
# Entities have a local identifier within a database or exchange file. These should be artificial and managed to be unique. Relationships are not used as part of the local identifier.
# Activities, relationships and event-effects are represented by entity types (not attributes).
# Entity types are part of a sub-type/super-type hierarchy of entity types, in order to define a universal context for the model. As types of relationships are also entity types, they are also arranged in a sub-type/super-type hierarchy of types of relationship.
# Types of relationships are defined on a high (generic) level, being the highest level where the type of relationship is still valid. For example, a composition relationship (indicated by the phrase: 'is composed of') is defined as a relationship between an 'individual thing' and another 'individual thing' (and not just between e.g. an order and an order line). This generic level means that the type of relation may in principle be applied between any individual thing and any other individual thing. Additional constraints are defined in the 'reference data', being standard instances of relationships between kinds of things.
== Examples ==
| |||