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+. Une vue contient des +vidéos+.

*EC1.3:* Un montage référence plusieurs vues. 

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

*EC1.5:* Une vidéo doit être disponible en plusieurs formats et plusieurs résolutions.

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,...

*EC2.3:* Il existe des types de vues définis: vue de face, de profil, globale ...

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 vues répondant à *l'EC1.3* nous avons définit une entité _Montage_ renseigné par les méta-donnés et liée à l'entité _View_ par la relation _MontageParts_. Cette dernière contient pour chaque montage une "liste" de vues associés.

*L'EC.14* est intéressante à traiter car elle nous oblige à lier une entité avec 3 possibles entités en exclusion mutuelle (c'est l'une des trois et une seulement pour chaque tuple). Afin d'implémenter cela une solution maison relativement propre à été mise en place. Chaque tuple de l'entité _Annotation_ contient un champ _Related_ et un champ _LinkKey_ représentant respectivement le type d'annotation (liée à une vue, à une vidéo ou à un montage) et la clef liant à l'entité décrite. Seuls inconvénients: il a fallut ajouter un index sur _LinkKey_ car les recherches d'annotations correspondant à une entité donnée sont courante et il a fallut normaliser les types des 3 entités concernés (trivial mais indispensable).

Enfin pour traiter *l'EC1.5* nous avons choisit d’implémenter une relation ternaire (_ConcreteVideo_) entre les entités _Video_ (contenant entre autres le contrôle de flux de travail et les méta-donnés), _Resolution_ et _Format_. La relation, et elle seule contient le lien vers la vidéo sur le disque. Ce fonctionnement permet d'avoir plusieurs formats d'une même vidéo de résolutions égales ou différentes. Cette solution est celle qui semble la plus adaptée du fait de sa souplesse et sa granularité.

h2. Méta-Donnés

En ce qui concerne les méta-donnés, nous avons crée un modèle permettant l'extensibilité des champs (cf *EC2.1*), c'est à dire qu'il est possible d'ajouter (ou enlever) des méta-donnés en précisant leur caractère (obligatoire ou non), en ajoutant un court descriptif de survol de souris (_hoover_), une description complète ainsi qu'un intitulé. Cela permet de faire évoluer les méta-donnés dans le temps en s'adaptant au mieux au besoin des utilisateurs. Afin d'utiliser au mieux ce modèle nous avons crée une entité _Metadata_ regroupant les méta-donnés et leur caractéristiques particulière.

Pour chaque objet il existe donc une relation avec l'entité _Metadata_ traduite par une table contenant l'id de chaque méta-donnés associée à l'id de chaque instance qu'elle renseigne ainsi qu'au contenu renseigné. Ces tables étant fortement sollicités il peut être utile de rajouter des vues relatives à chaque tuple de l'entité concrète. 

Le suivi de l'avancement des annotations et vidéos spécifié dans *l'EC2.2* est assuré par la table _Workflow_ qui contient les différents statuts permettant le suivi de progression. L'avantage de mettre ces statuts dans une entité autre que celle qu'elle renseigne est de pouvoir ajouter/modifier/supprimer simplement les différents étapes de la progression.

Enfin, la même solution a été adoptée pour répondre à *l'EC2.3* qui stipule que les vues sont des vues génériques et que les vues possibles sont les mêmes pour toutes les sessions.

h2. Droits d'accès

Voici la section la plus difficile à aborder bien que la définition du besoin soit simple son implémentation comporte des variantes facilitant plus ou moins la maintenance et étant plus ou moins rapides. Ici, nous avons fait le choix d'avoir une granularité maximale au niveau de la base de donnés. Chaque entité _User_ est donc liée à chaque entité concrète (site, session, vidéo ...) par une relation d'accès dans laquelle est spécifié un droit d'accès parmi ceux contenu dans la table des accès (_Rights_). Cela permet de contrôler les accès utilisateur par utilisateur.

De plus pour pouvoir créer des généralités simples, chaque conteneur (site, vue, ...) a un règle générale parmi celles définies dans la table _Rules_. Cette règle générale permet de spécifier le comportement du contenu face aux utilisateurs autorisés à accéder au conteneur.  Par exemple: un membre (utilisateur) d'un corpus veux accéder a une vidéo contenue dans le corpus. Si la règle du corpus spécifie que tout membre peut accéder à l'ensemble du contenu alors il n'y aura pas d'autre vérifications de droits et il n'y aura pas eu de recherche dans la relation entre l'utilisateur et la vidéo (_UserAccesVideo_) qui peut contenir beaucoup de tuples.

Le seul problème qui se pose est celui de la re-généralisation: quand un conteneur n'ayant pas de règle générale en acquiert une il faut supprimer les tuples inutiles des tables correspondant aux relations utilisateur-contenu.