GENERAL
Conceptual data models are used to describe a selected portion of a real or
postulated world of interest. A conceptual schema is a static, time-invariant
collection of linguistic or graphical representations that describe the
structure of the data of interest. An instance of a schema is a dynamic,
time-variant collection of data that conforms to the structure of data defined
by the schema. Each schema can have multiple instances; the state of the
information base at a particular point of time correspond to one such instance.
The model is the schema with its instances (information base).
Conceptual schema's consist of a set of modelling concepts (descriptive
elements). Conceptual schema's can be expressed using formal languages. A
language is formal if it has a grammar. A grammar is a set of rules that tells
how to produce grammatically correct strings of words.
The modelling concepts described in this document are indented to be easy to
understand and enable semantically rich descriptions.
The modelling concepts is described as templates and may be expressed in
different graphic notations.
All descriptions shall be written in good English, using complete sentences and
avoiding indistinct allusions. The language shall be adapted to the needs of the
presumptive reader. Abbreviations should be avoided; when used, their meaning
should be made clear. When there is a reference to other entity types, their
correct names shall always be used.
The following requirements apply to the modelling concepts below:
M = mandatory O = optional
DEFINITION OF ENTITY TYPE
An entity type is an abstraction that represents classes of real-world objects
e.g. Person, Car, Plant etc. An entity type properties is described by its
attribute types and relationship types.
For each entity type the following is specified:
M name:
The name shall reflect the definition in a short and concise way, be useful in
discussions, easy to understand and unique point out the fact in consideration.
The name should be a noun in singular, written in capital letters and be
unique within the schema. Abbreviations should be avoided.
M description:
Textual description in natural language to explain the meaning of the entity
type. The description shall not just repeat the information contained in other
places, such as attribute types and relationship types.
O number of instances:
Showing the average number of entity type instances and its expected
growth/reduction. Specifying the number may sometimes make it easier to
understand the meaning of the entity type. (If one person engaged in modelling
thinks the entity type shows four instances, while someone else thinks that they
are 1,000, they are likely to talk about two different entity types.)
M justification:
The justification will give the reason that the entity type is needed and for
which and what it will be used.
M identifier:
The attribute types and/or relationship types that unique determine an entity
instance. The identifier shall be chosen so it is stable over time.
O type of entity type:
Fundamental: The entity type has an independent existence in relation to other
entity types.
Attributive: The entity type is dependent of another entity type for its
existence.
Associative: The entity type is dependent of two or more entity
types for its existence.
O comments:
Supplementary details.
DEFINITION OF ATTRIBUTE TYPE
The attribute types and the relationship types together describe the properties
of an entity type.
For each of the attribute types the following is specified:
M name:
The name of the attribute types used to point out an attribute type. It must be
unique within the context of the entity type, but not within the model. That
means that the same attribute type name may be used for several entity types.
The name of the entity type should therefore not normally be part of the
attribute type name. Abbreviations should be avoided.
M description:
Textual description in natural language to explain the meaning of the attribute
type.
M cardinality:
Mapping restrictions are expressed by cardinality that gives the number of attribute instances: normally expressed with minimum (0 or 1) and maximum (1 or M(=Many)). The exact number of instances may also be shown by e.g. 2:2 instead of 1 and M.
Note that maximum cardinality can be "M" so multi-valued attributes
are allowed in this modelling approach.
M name of the value set:
The name of the value set from which the attribute values are derived.
O method of calculation:
The method of calculation for attribute types that may be calculated based on
other attribute types.
O justification:
The justification will give the reason that the attribute type is needed and for
which and what it will be used.
O comments:
Supplementary details.
DEFINITION OF RELATIONSHIP TYPE
The attribute types and the relationship types together describe the properties of an entity type. The relationship type has two directions. The properties for each entity type are described by the relationship types pointing to other entity types. The inverse relationship type describes the properties of another entity type.
Only binary relationship types are allowed.
For each of the relationship types the following is specified:
M name:
The name of the relationship outgoing from the entity type and the name of the
entity type pointed out. Relationship names are often written in lower-case
letters and the name of the entity type in capitals letters, e.g. owns CAR.
O description:
Textual description in natural language to explain the meaning of the
relationship type.
M cardinality:
Mapping restrictions are expressed by cardinality. Cardinality gives the number
of entity type instances and is normally expressed with minimum (0 or 1) and
maximum (1 or M). The exact number of instances may be shown by e.g. 2:2 instead
of 1 and M.
M inverse name:
The name of the relationship in the reverse direction.
M inverse cardinality:
The cardinality for the relationship in the reverse direction.
O justification:
The justification will give the reason why the relationship type is needed for
which and what it will be used.
O comments:
Supplementary details.
O DEFINITION OF GENERALIZATION ASPECTS
This is a special type of a relationship type and is often called an "is-a
relationship."
In a generalization all the attribute types of the generic (supertype) entity
type are inherited by all the specialized sub entity types.
Subtypes can be exhaustive (covering) or non-exhaustive (non-covering).
Exhaustive means that the specialized subsets together are the superset. This is
not used here.
O is a specialization of:
The name of the supertype.
O (or) has the following specialization(s):
The name of the subtype(s).
O specialization principle
A classification key, e.g. sex, nationality, size.
AN EXAMPLE OF A GENERALIZATION:
DEFINITION OF VALUE SET
Each unique value set referred to from the attribute types is assigned a separate definition. This definition sometimes applies too many models. Definitions of value set are sometimes produced centrally, e.g. in the form of standardized code lists.
Synonym: Information type, Domain
For each of the value sets the following is specified:
M name:
The name of the value set used to designate a certain value set. The name shall
be unique within the organization. Abbreviations should be avoided.
M description:
Textual description in natural language to explain the meaning of the value set.
M value set:
Permitted values described by enumeration of all individual values and/or with
one or more intervals. Codes shall be explained.
O datatype:
A component specifying a set of distint values for representing the value set.
Examples of datatypes are: 'character', 'integer', 'character string'.
O maximum size:
A specification of the maximum number of storage units to represent the distinct
values of the datatype specified above.
M comments:
Supplementary details.
Appendix A
A nicer solution to the metamodel is shown in the figure below. With this
redundancy is avoided. The Relationship Link Types are only specified once. This
metamodel is more complicated and harder to understand so it has not been used.
A easier to understand or a more pragmatic solution is shown in the metamodel of
the Basic Data Modelling Concepts above. In this only the Relationship Link Type
is used and it is called Relationship Type.
Appendix B:
Example of a graphic notation
Appendix C:
Metamodel of the modelling concepts
Appendix D: Version control of models
Created 1995-03-20. Last modified 1996-10-14. Björn Norén
