Documentation BDD¶

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.

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.

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 ...
EC2.3: Il existe des types de vues définis: vue de face, de profil, globale ...

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

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

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:

1. Représenter le fils du corpus
2. 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é.

Méta-Donnés¶