A CD database


A complete interaction example

Here is one of the first examples I settled in my mind when designing what I then called the OSLm project, down in '91: how I would manage my own personal database of classic music compact disks.

Actually, it was by seeing how such thing was not just impossible, but even unconceivable in existing systems, that I decided that my project would be more than a language or piece of software running on an existing operating system, but a whole computing system of its own. I remembered it when later chosing the name Tunes for the project.

Here is a complete system interaction description...


Goal of this Tunes session

In this document, we tell how a Tunes user, who never read the docs, but knows the general principles of Tunes computing, will try to write a catalog of all the CD's in his collection. This database should allow him to compare the disks, to classify them according to the work piece, to the quality of the interpretation, to his taste; it should allow to find quickly if a some music work is in the collection; it should allow classification of works or songs, and their interpretation even though they are not (yet) in the collection. Ideally, it should allow to retrieve entries according to a tune (hehe), and play the melodies of pieces in the database. It should help him manage the way he will listen to his collection, enrich it, etc.

This may seem an ambitious project, but hey, why shouldn't it be possible ? We'll prove that it is, and show how the techniques proposed in the Tunes project allow do it incrementally, just the way a human actually thinks about things when designing a database, through automatic rewrite of the database as the structure evolves...


How to read this document

This document describes an interaction between a Tunes user, who will be refered to as F., and the Tunes system.
The Tunes system will dynamically divide into objects during the session. In this document, objects will be refered to by the list of names or code numbers that were successively attributed to subobjects to reach the object from the topmost user-visible one: () will be this topmost object; (aaa) will be some object accessible as aaa from object (); (aaa.bbb) will be some object accessible as bbb from object (aaa); (aaa.bbb.ccc) will be some object accessible as ccc from object (aaa.bbb); (xx.1) will be some object with code number 1 accessible from object (xx).
These objects communicate with the human user, and with each other, which will be denoted by a sequence with the message originator, followed by an arrow, followed by the message recipient, followed by a colon, followed by the message contents, e.g. () -> (aa.1.xx) : "how are you ?"

() () () () () () () () () .....
Cette session est un perpétuel dialogue entre divers interlocuteurs: F. l'utilisateur, et les différentes fenêtres (notons bien que les fenêtres discutent aussi entre elles). Avant tout "message" se trouve la source du message et sa destination. Les acteurs du départ sont F. l'utilisateur, et (0) la fenêtre de départ du système (d'autres fenêtres du système peuvent coexister mais seule celle-là nous interesse). D'autres fenêtres apparaissent et disparaissent. On ne donnera de numéro dans ce texte qu'aux fenêtres les plus importantes dans notre propos. ***** Chapître I : création d'une base de données ***** - F. au système (0) « Je veux créer un nouvel objet.» - Le système (0) à lui-même « Créons un nouvel objet. Par défaut, donnons lui la classe vide (et donc aucun contenu). » « Ouvrons pour lui une fenêtre d'édition d'objet numérotée (1), permettant d'éditer les champs classe et contenu (ce dernier champ est pour l'instant inaccessible, puisque le contenu est de longueur nulle). » - F. à l'objet (1) « Change la classe de l'objet ! » - (1) à (0) « Crée un objet de type (méta)classe, et ouvre lui une fenêtre d'édition permettant d'éditer son seul contenu (a priori: "vide"). » - (0) à (1) et F. « J'ouvre une fenêtre d'édition d'objet comme me le demande (1), avec le numéro (2). Toute modification de (2) entraînera une modification de (1) via un lien de mise à jour a priori automatique.» - F. à (2) « Mets-moi la métaclasse "base de données" » - (2) à (2) et (1) « La métaclasse de (1) sera "base de données"; elle a de nombreux champs d'information. Pour l'instant, considérer la base comme ayant une seule liste d'éléments, cette liste étant vide, et ses éléments étant de type vide (2.1). » Remarque: on ouvre une liste tout de même pour que l'utilisateur n'ait pas à le faire, sachant que lorsqu'un utilisateur ouvre une base de données, c'est rarement pour ne lui intégrer aucune liste. - (1) à F. « J'ouvre une liste (1.1) correspondant à (2.1) dans la fenêtre de (1). » - F. à (2.1) « Donne le nom "titre" au type des éléments de la liste, ce type étant une chaîne de caractère de longueur fixe égale à 60, pour l'instant. (Je choisis des options aussi faciles que possible, qui me mènent à un fichier de même type que dBase). » - (2) à (1) « Mets-toi à jour avec cet ajoût dans ton type. » - F. à (1.1) « Voilà quelques titres de CD en ma possession » - F. à F. « Le titre ne suffit pas, entrons aussi le nom de l'auteur. » - F. à (2.1) « Inclus-moi "titre" dans un type enregistrement. » - (2.1) à (1) « Ok. Je donne le numéro (2.1) à l'enregistrement, et le numéro (2.1.1) à l'ancien champ "titre". A priori, l'enregistrement comme son sous-champ porteront tous deux le nom "titre". » Remarque: (1) sait que cette commande ne modifiera pas l'organisation de ses données, mais a intégré ce changement. - F. à (2.1) « Donne le nom "CD" à l'enregistrement ; oh puis non ! Donne lui le nom "Disque compact". » « Ajoute-moi le champ "Auteur" à (2.1); ce sera un champ de type chaîne de caractère. » Remarque: Il existe un type Nom de personne, mais F. ne l'a pas vu dans la liste (peut-être n'a-t-il pas pris la peine de consulter cette longue liste, ou n'a-t-il pas su restreindre cette liste aux types apparentés aux chaînes de caractères, et a-t-il été noyé sous la masse des types disponibles, choisissant le plus familier, mais aussi le plus primitif). - (2.1) à (1) « Mets-toi à jour en insérant la place pour le champ "Auteur" » - F. à (1) « Voilà les noms des auteurs des oeuvres déjà entrées » Remarque : F. n'a rentré que le nom des auteurs, pas leur prénom. « Voilà quelques oeuvres supplémentaires. (titre+auteur) » ***************** Chapître II : aménagement de la base de données ************ - F. à F. « Zut ! ... -> prénom ****** Chapître III : une base de données commune se révèle insuffisante ***** - F. à F. ... -> -> structure hiérarchique de bases de données (l'une puisant dans les inférieures) lieu d'un grand tableau hyper redondant. structure hiérarchique. -> multiples occurences d'une -> plusieurs ensembles interliés au lieu d'un grand redondant ou même d'une structure hiérarchique. -> malgré tous les autres ensembles construits, celui qui est le plus représentatif (car correspondant le plus à un objet physique) est celui des CD eux-mêmes, que l'on peut choisir, prendre, jouer, etc. ****** Chapître IV : optimisation de la structure de la base de données ****** - F. à F. « J'ai tout bien défini, mais l'accès est très lent » -> jusqu'ici, on s'intéressait aux structures logiques; maintenant que celles- ci sont bien établies, on va s'interesser à leur représentation physique. -> on commence par des améliorations manuelles. -> optimisation automatique possible: -> utilise les données précédemment accumulées, ainsi que des statistiques sur les modifications effectuées: quels champs changent le plus souvent, lesquels font quelle longueur; -> calcule les redondances dans les données; -> se réfère à une bibliothèque de schémas classiques de codage. -> à tout moment, l'ordinateur permet à l'utilisateur de savoir ce qu'il fait; il donne même des explications détaillées (si celles-ci existent); -> l'utilisateur peut exprimer son désaccord avec l'ordinateur; -> l'ordinateur peut aussi exprimer son désaccord avec l'utilisateur; -> l'ordinateur est prêt à discuter; mais c'est l'utilisateur qui tranchera en dernier ressort (!) plusieurs user -> des fonctionnalités peuvent être débranchées (pour aller plus vite) et rebranchées; -> on peut les débrancher dans l'optique de les rebrancher, et demander à l'ordinateur de collecter au fur et à mesure les infos que l'on sait qu'elles demanderont (au lieu de tout faire d'un coup), sans les traiter pour en tirer des conclusions. ... ****** Appendice A : ****** Résumé des acteurs de la session: F. L'utilisateur (0) Le système (1) L'objet base de données (1.n) La n-ième liste d'éléments de (1) (1.n.p) Le p-ième élément de (1.n) (2) La classe de la base de données (sous-fenêtre de (1), mais assez importante pour avoir un numéro distinct dans l'exemple (mais pas dans le système OSL lui-même) (2.n) La classe de (1.n) (2.n.p) La classe du p-ième champ de (2.n) ****** Appendice B : Résultat de la session ****** Voici la structure de la base, comme elle a évolué depuis sa création: * à la création, après que (1) soit devenu une base de données: une liste, vide, d'éléments de type vide. * à la fin du chapître 1, la base contient une liste non vide, structurée de manière interne comme un tableau, avec pour éléments des enregistrements contenant le titre et l'auteur, deux chaînes de caractères de longueur fixe. * ... settled établi feature fonctionnalité

Conclusion
As we see, a database is not a fixed structure; even it's "type" evolves. Database means that the computer integrates knowledge, and allows the human to access it. Knowledge is due to evolve unpredictably (see Karl Popper's works about this); no static structure can restrict it. That's why no static database structure can dynamically satisfy the human's needs; that's why we need dynamical structure modification and automatic data rewrite.
.....


To Do on this page

  • Annotate example points by the more generic issues they tackle.
  • Finish translating this existing examples from French to English...
  • Complete the example.


    Back to the Examples page, or
    the Tunes Home page.


    Page Maintainer:
    Faré -- rideau@clipper.ens.fr