The Ariadne Data Model
Contents 1. Introduction 2. Object definition model 3. Conceptual data model 4. Table model 5. Database design 6. Database table descriptions

1. Introduction

This document specifies the Object definition model and the Conceptual Data model (both in UML ) for a (canoe/kayak) competition. Further it specifies the Table Model (logical data model / ERD), and the Database Design for the information system for managing a (canoe/kayak) competition.

1.1 References

Terms, concepts and procedures are based on the ICF rules [ref.1].

1.2 Modeling steps

Step 1 - The Object Definition Model

The Object Definition Model is an ontological model. It specifies the definitions of the relevant object types. Relations in a Object definition model between object types are constituting, that is, always apply (because defined so, but only so in the context of a (canoe/kayak) competition).

The Object Definition Model specifies the object types which are meaningful for a (canoe/kayak) competition. Object types which are meaningful in the process of a competition do not necessarily appear in the database model. For instance, a finish line is a meaningful object type in a competition, but you will not find it in the database model. Only derived concepts as a finish line passage ( 'a finish') you find will in the database model.

Step 2 - The Conceptual Data Model

The Conceptual Data Model specifies the properties of object types (classes) and the contingent relations that hold between object types, as relevant for the processes related to the (canoe/kayak) competition. These relations are contingent, e.g. may or may not be mandatory. Example: not every person in a competion is a competitor. Example 2: You only can have a valid run, if there is a start-event and a finish-event.

The positioning of multiplicity values in the UML model, and their meaning is often not very clear. The example below specifies the positioning of multiplicity and their meaning:

Legenda on multiplicity (synonym: cardinality) :

For each object 1, there is just one and only one object 2; for each object 2, there are zero, one, or more object1's. The multiplicity indicators are placed clockwise to the direction of the relation.

Step 3 - The Table Model

In step 2 the Conceptual Data Model specifies object types (classes) and their relations in the real world. If we want to register and manage these real objects, we project an informational view of the Conceptual Date model onto database tables. The Table Data Model (logical data model / ERD) defines the tables in which data will be stored, in principle in 3rd normal form.

Step 4 - The Database design

The final data model is the database design. For performance reasons, or for ease of design, the table date model may be de-normalized. E.g. repeating groups may occur again, or data may be replicated in more tables. Validation tables may be added.

Change history