Documentation BDD » Historique » Révision 8
Révision 7 (Anonyme, 29/01/2013 09:40) → Révision 8/9 (Anonyme, 29/01/2013 09:41)
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,... Validée, Invalidé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