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 ?".
How those messages are actually passed is not in this paper's scope. The Tunes User Interface should manage the interaction between computer objects and the human, while other meta-protocols decide how objects communicate one to the other.


Chapter I: Creating the Database

  • F -> (): I wanna create a new variable object.
  • () -> F: Easy, guy: here's an object (1). Initially, it'll have no particular attribute.
  • F -> (1): Hello ! I'd like to extend your context
  • (1) -> (): Dear (), could you please extend my context ?
  • () -> F: Ok, fellow; object (1) wants to extend its context. How do you want to do it ?
  • F -> (): Well, use the best database management module you know.
  • (): Let's look into the distributed database of available modules (well, considering only modules that I trust).
  • (): Hey, here's the latest and greatest (db) module from the Tunes team.
  • () -> (db): Hi, there. Could you tell me what to do about this object (1) ?
  • (db) -> (1): There, initialize those attributes. For the moment, you'll be just a raw list of data, currently empty.
  • () -> F: done.
  • F -> (1):
  • () -> (1):

    .....
    () ()

    .....
    To translate from french, and complete:

    
    « 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.
  • Talk about how lazy evaluation and futures can help use of the database while still using structural rewrite with human interaction...


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


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