Wanda

h1. Documentation BDD

h2. Spécification du besoin

Selon la définition faite avec le client, voici la liste des exigences dont la mise en oeuvre dépends partiellement au moins de la base de donnés mise en place.

h3. EC1: Organisation hiérarchique du contenu

*EC1.1:* Un +site+ contient plusieurs +corpus+. Un corpus des +sessions+. Une session contient des +vues+ ou des +montages+ de vues.

*EC1.2:* Un corpus doit pouvoir contenir des +sous-corpus+.

*EC1.3:* Un montage référence plusieurs vues. Une vue contient des +vidéos+. Une vidéo doit être disponible en plusieurs formats et plusieurs résolutions.

*Ec1.4:* Une +annotation+ concerne une vidéo, une vue ou un montage.

h3. EC2: Méta-donnés

*EC2.1:* Chaque +objet concret+ doit pouvoir accueillir des méta-donnés extensibles: Il doit être possible selon le besoin d'ajouter des méta-donnés à une entité quelconque de préférence sans avoir à modifier le code source de l'application.

*EC2.2:* Les vidéos et les annotations doivent pouvoir être suivies dans leur progression via un outil de contrôle de progression du travail. Ainsi une annotation par exemple a plusieurs statuts: Validé, Non Validée, Invalidée ...

h3. EC3: Autorisations

L'accès à chaque niveau doit pouvoir être contrôlé au cas par cas (utilisateur par utilisateur) mais on doit aussi pouvoir générer des règles générales du type: "Tout utilisateur de ce corpus peut accéder à chacune de ses vidéos".

h2. Choix des entités de base

Conformément au diagramme de classe nous avons repris les objets principaux représentant les objets concrets manipulés par les parties client et serveur de l'application. On retrouve donc les entités suivantes dans la base de donnés:

* Vidéo

* Annotation

* Vue

* Corpus

* Site

* Utilisateur

h2. Organisation hiérarchique du contenu

Nous avons mis en place une hiérarchie apparente répondant à l'EC1.1 entre les divers objets décrite par les relation entre les tables représentant les entités de base. Ainsi dans la région _Concrete Objects_ on retrouve clairement ces entités liés par des relations de parties ou d'appartenance (_Part_ & _Belong_). Etant directement spécifiée dans le besoin client, cette hiérarchisation simple à comprendre et à implémenter, ne fait pas l'objet de choix de développent elle ne fera donc part d'aucune justification supplémentaire dans cette partie.

Afin qu'un corpus puisse contenir des sous-corpus conformément à l'EC1.2, il faut que l'entité _Corpus_ aie une relation de parenté avec elle même. Il s'agit maintenant de choisir la manière dont cette relation sera implémentée, en effet, plusieurs possibilités font rapidement leur apparition. Afin de simplifier, n'entrerons pas dans les détails des arités de la relation mais intéressons nous plutôt au niveau table et au choix s'offrant à nous. 

Premièrement il serait possible de mettre une clef étrangère issue d'un corpus dans un corpus. Elle pourrait donc:

# Représenter le fils du corpus

# Représenter le père du corpus

L'avantage de la solution 1 est que le développement de la hiérarchie est rapide. On navigue de père en fils via l'id indexé et donc avec un temps d'accès rapide. Ainsi pour développer 10 étages on aurai à faire 10 accès directs successifs via la clef primaire (en d'autres termes c'est plus rapide à faire qu'à dire). En revanche, il est impossible de cette façon pour un corpus d'avoir plusieurs sous corpus. Cette solution à donc été rejetée. 

L'avantage de la solution 2 est qu'il devient possible de mettre plusieurs sous-corpus dans un corpus. Cependant le temps de développement est augmenté, ce qui nous oblige à mettre un index sur la clef étrangère. De plus la solution n'est pas extensible: on ne pourrait pas faire évoluer la base de donnés de façon simple. Cette solution est acceptable mais pas entièrement satisfaisante.

Deuxièmement il est possible d'ajouter une table représentant la relation de parenté et contenant deux clefs étrangères formant la clef primaire et référençant chacune un tuple de l'entité _Corpus_ représentant respectivement le père et le fils. Ainsi il est possible à un corpus d'avoir plusieurs sous-corpus qui eux même peuvent en avoir. De plus l'accès à la hiérarchisation entre corpus est simple (parcours partiel de la clef primaire), bi-latérale (même complexité que l'on accède a la liste des pères ou celle des fils) et complète (toutes les informations sont clairement définies dans la table, il n'y a pas de "sous-entendus"). Cette solution a été retenue.

Pour pouvoir faire d'un montage un assemblement de liens de vidéos (EC1.3) nous avons définit un objet _Montage_