Quoi de neuf dans la Valhalla

Au pays du dieu Odin, il est temps de ne plus limiter l’entrée de la Valhalla uniquement aux guerriers valeureux. Mais soyons fous et acceptons tout le monde, et peu importe leurs caractéristiques (cf. Valhalla Scanner).

Je travail ainsi à la refonte complète de la structure de la base de donnée. Pour rappel, le problème majeur vient du manque de souplesse à l’insertion des méta-données. Il n’est pas possible d’y insérer des informations autres que le titre, l’année, le numéro de piste, l’auteur, l’album et le genre. De nombreux fichiers offrants bien d’autres informations il est donc indispensable de revoir le modèle complètement. Mais qui dit nouveau modèle, dit aussi nouveau code et nouvelle API. La conséquence de cette réécriture provoquera indéniablement une fracture avec le module actuellement présent dans Enna et avec les bases de données générées par le système actuel. En date de cet article, je n’ai pas encore écris les modifications mais j’ai néanmoins fais les réflexions nécessaires. Et se sont ces réflexions que je vais partager ici “en partie :-)”.

Nouveau modèle

L’idée est de se détacher des noms donnés au méta-données. Tel que “genre”, “author” et “album” par exemple. Ce ne sont finalement que des noms et devraient donc être traités comme de simple donnée dans la base de donnée. Il n’y aura donc plus de table nommée “genre”, etc. Mais une table regroupant les noms, et une seconde table regroupant les valeurs et gardant indirectement une relation entre le nom et la valeur.

Un tel système permet d’insérer une infinité de noms différents de méta-données et d’éviter en même temps les duplications. Il est important d’assurer un minimum de redondance. Si un genre est inséré, il ne faudrait pas qu’il soit réinséré trois fois si trois nouvelles données nommées “genre” seraient envoyées par le scanner. De même pour les valeurs, la valeur “rock” par exemple devrait apparaitre qu’une seule fois dans la base de donnée. Ainsi tous les fichiers qui feraient référence à “genre”->”rock” seraient tous liés à la même information. Ce qui est le cas avec l’ancien modèle, et il est important de conserver cette caractéristique pour une question de bon-sens et de qualité.

Mais rendre le modèle complètement générique apporte un nouveau problème. Il devient difficile de retrouver les informations qui concernent un même thème. Imaginez un fichier qui utilise le nom “genre” et un autre type de fichier qui utilise le nom “style”. Peut être que ces deux fichiers sont de la musique et que les deux contiennent la valeur “rock”. Mais une fois nous avons “genre”->”rock” et une fois nous avons “style”->”rock”.
Pour y remédier, il peut être judicieux de créer une troisième table qui permettrait de regrouper les paires nom->valeur sous des noms d’ensemble. Cette table se nommerait donc “group” et contiendrait une liste (pouvant être étendue si nécessaire) de différents groupes possibles. Voici une première liste de groupes (qui va encore évoluer):

Miscellaneous, Entity, Title, Classification, Personal, Temporal, Spacial, Commercial, Legal, Technical, Identifier, Musical, Contact, Organizational

Typiquement, par rapport à l’exemple précédent pour “genre” et “style”, il serait judicieux de regrouper ces paires dans le groupe “Classification”. Ainsi il serait facile de ressortir toutes les paires par groupe pour créer des listes de genre et de style en étant sûr que le nom “genre” ne fait pas référence à autre chose. On pourrait très bien imaginer que pour certains formats de fichier, ce soit des noms français et que ça ferait référence au genre (sexe) et non au style de musique. Il faudrait donc pouvoir assigner un autre groupe pour ces particularités. Ainsi, lors de l’insertion des méta-données d’un fichier, il sera obligatoire de chaque fois spécifier le groupe. Mais dans les cas “inconnu”, il sera toujours possible d’utiliser le groupe “Miscellaneous”.

Ça sera donc aux parsers de dire quel paire va dans quel groupe. Cela peut paraître un peu contraignant, car ça demande quelques réflexions sur le fonctionnement des parsers. Mais afin de pouvoir récupérer de la manière la plus exhaustives possible des informations depuis l’extérieur (comme Enna), il est indispensable de les regrouper correctement. Avec l’ancien système, ce n’est pas possible et c’est donc un plus que j’estime intéressant. Sans oublier que le nom des méta-données pourra également être récupéré depuis l’extérieur, et donc un tri pourra se faire sur les “genre” et sur les “style”, etc,.. si nécessaire. Et bien sûr, il sera qu’en même possible de récupérer tous les “genre” sans tenir compte des groupes.
(Quand je parle de “l’extérieur”, je parle donc des accès effectués depuis l’API et des valeurs récupérées. Je parle également toujours du genre, mais c’est un exemple.. l’idée est la même pour toutes les méta-données.)

Diagramme Entité/Relation

Le diagramme E/R ci-dessous résume assez bien à quoi va ressembler la base de donnée. Il se peut qu’il évolue encore, mais la forme générale (les relations) ne devraient pas trop bouger.

D’habitude je préfère travailler avec des diagrammes MERISE, mais le logiciel Dia est mieux adapté pour du E/R. Pour les non-adeptes des E/R, le rectangle/losange “is defined by” correspond à une table d’allocation ayant pour clef primaire (file_id, meta_id et data_id).

But final

Cette petite analyse du modèle est un premier pas vers une future modification de Valhalla, dans laquelle il sera possible d’y introduire directement les grabbers d’Enna (les grabbers sont les modules qui permettent de récupérer des informations et des images via Allocine, IMdB, etc,..).

Il y a quelques indications dans ce document (voir aussi ici), mais j’en parlerais plus en détail dans un nouvel article, dès que j’en aurais terminé avec le nouveau modèle et son implémentation.

A bientôt,

Mathieu SCHROETER