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

1. Introduction

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

1.1 References

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

1.2 Modeling steps

Step 1 - The Class Definition Model

The Class Definition Model is a defining model. It specifies the definitions of the relevant concepts and terms (e.g. object classes). Relations in a Class definition model between object types are necessary, that is, always apply (because defined so, but only so in the context of a kayak slalom competition).

The Class Definition Model specifies the concepts which are meaningful for a kayak slalom competition. Objects which are meaningful in the process of a slalom competition do not necessarily appear in the database model. For instance, a finish line is a meaningful object 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 classes and the contingent relations that hold between object classes, as relevant for the processes related to the kayak slalom competition. These relations are contingent, e.g. may or may not hold. Example: not every participant in het slalom competion is a jury member. But: You can only have a valid run, if you have 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

Step 3 - The Table Model

In step 2 the Conceptual Data Model specifies objects and their relations in the real world. If we want to register and manage these real objects, we project an informational view of these object 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 Model

The final data model is the Database Data Model or 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