Ariadne index page

The Ariadne Data Model

 

  
Contents
1. Introduction
2. Object definition model
3. Conceptual data model
4. Table model
5. Database model
6. Database table descriptions		 author: Gerrit van Dalfsen
version: 1.5
date: 24 Sep 2002

4. Table Model (logical data model / ERD)

4.1. Design decisions

1. System architecture requires there to be four basic modules in Ariadne: Current competition module, Run event module (start and finish events), archive module and system management module.

2. All tables with data about the current competition are put is the module Current competition, including the event buffer table from the Run event module. The tables with archive data are put in the Archive module, tables with system management data are put in the System module.

3. With the Table Data Model for the Current competition, in principle more Slalom competitions can be held at the same time. For reasons of safety (e.g. not having a chance that somehow data of two competitions get mixed, the current competition module is to hold data of only one competition.

4. Archive data is to viewed without a current competition attached.This means that for instance Category, Person and Kayak club are also held in the Archive module. Archive results of a person have to be available in the current competition. So some linking mechanism has to be established on Person between Current competition and Archive data.

4.2 Current Competition - Table Model

(indexes between parentheses (*) refer to modeling decisions)

4.2.1 Current Competition Table Model - modeling decisions

(1) - Till Ariadne 3.0, BOAT TYPE, AGE GROUP, GENDER and CATEGORY were put together in one table: Category (In accordance with the ICF Slalom rules). After all, it appears more convenient to put GENDER, AGE-GROUP and BOAT-TYPE into separate tables.

(2) - START and FINISH are parts of RUN. They will be put into the table RUN.

(3) - Requirements state that there should be a choice to record the penalty point of Gate negotiations as individual Gate negotiations; as gate section aggregates; or as run aggregates. The individual gate negotiations can be put in the table GATE NEGOTIATION. The run aggregate can also be put in table GATE NEGOTIATION, under gate number 0. Gate section aggregates are not implemented.

(4) - Disqualification is not implemented as a separate table. It may appear as a status indication of RUN.

(5) - The relation between EVENT and COMPETING UNIT is derived via CATEGORY IN EVENT and CATEGORY.. This has the danger op the possibility that COMPETING UNIT is assigned to CATEGORY, which are not assigned to a EVENT. An signalling report function is required in this respect. See also modelling decision 10.

(6) - SERIES BLOCK is not necessary as a table. Series block has no attributes of its own, and is derivable from the sorting order of PROGRAM BLOCK, EVENT and SERIES.

(7) - PERSON and COMPETITOR is put in one table (Person), because the occurrences are nearly one to one.

(8) - If we relate SERIES directly to Run (c.f. figure below) , them the then the danger is apparent that when a CATEGORY is transferred to an other EVENT, the event results will be shown under the former event. In preventing this risk the relation between Series and Run wil not be maintained.

(9) - The more general designation for KAYAK CLUB is ORGANISATION. This opens the possibiltity to add more types of organisations with their officials. e.g. Police, First Aid, Waterregulation Authorities etc. This addition will be left for future extensions. (At first, it wil be left Kayak club).

(10) - (13-Jan-02): Modeling decision 10 concerned the decision to have a direct relation between EVENT and COMPETING UNIT in the execution phase of the slalom competition. This decision is recalled per Ariadne version 3.30. The relation between EVENT and COMPETION UNIT now always follows the relation tabel CATEGORY-IN-EVENT.

(11) - Depicted multiple times for the ease of the schema.

(12) - The extra relation between Slalom Competition and Event is necessary because the relation via Program Block is optional.

(13) - Both persons and Kayak clubs can have adresses.

(14) - Slalom competition, Category, Event and Person can have Remarks.

(15) - Club members are not recorded in Ariadne. Club membership is not relevant for the relation person - competing unit, and club membership can not be maintained adequately on the basis of entries.

(16) - The Run event buffer is part of the run event processing module. This module receives run events (start, finish, initialization, capsize) from the Time-PC, and processes these events into the Run-table.

(17) - Depicted to state the relation to Archive data. The table ARCHIVE-PERSON is not part of the current competition module.

4.3 Ariadne Archive - Table Model

4.3.1 Ariadne Archive - modeling decisions

(1) - Person, and not Competing unit is added to archive. If a competing unit consists of more persons, the result of the competing unit is listed with each of the persons.

 

4.4 Ariadne System management - Table Model

 

4.4.1 Modeling decisions

(1) - Authorisation so far not implemented.