Assurons nous que notre modèle de données convient pour le problème initial posé, à savoir la comparaison de divers outils logiciels.J'ai pratiqué pendant de longues années un outil puissant appelé Uniface.

Cet outil de développement supportait alors l'affichage en mode caractère, mais aussi en mode graphique sous Unix (OpenLook, Motif) sous Windows (l'interface graphique propriétaire), sous Mac (l'interface graphique propriétaire), sous VMS. Grâce à ce qu'on appelait des drivers homme machine, l'outil Uniface permettait à l'utilisateur (et au développeur) d(utiliser au mieux le clavier, la souris (à 1,2 ou 3 boutons) et l'écran. Par ailleurs l'outil Uniface permettait d'enregistrer et de lire les données sous dbase3, sur des fichiers séquentiels(guère pratique pour de gros volumes), sur les principales bases du marché (Oracle, Sybase, Informix, Rdb, ... Solid) et ceci dans diverses versions de ces bases de données. Uniface tournait sous la plupart des systèmes d'exploitation dans leurs multiples versions. Enfin, cet outil autorisait des architectures Client serveur élaborées, ou multiposte ou encore monoposte.

Les réseaux possibles étaient Novell, le réseau propriétaire de Digital, TCP/IP qui est le seul a avoir survécu.

Le langage utilisé par Uniface était essentiellement propriétaire et interprété ce qui explique son large portage.

Uniface a évolué et propose aujourd'hui encore des architectures de ce type plus les architectures avec serveur web. De plus Uniface s'est enrichi d'une large palette d'interfaces avec les langages ou interfaces langages du marché les plus répandus (C, VB, Cobol (mais oui!), Corba, SOAP, ...)

On voit donc apparaitre les familles: Système d'exploitation, Interface Homme machine, Système de stockage avec les sous familles Système de fichiers et Base de données, Architectures, Système réseau, Langages

dans la famille Système d'exploitation on trouvera les sous familles Unix, Windows, Mac, VMS; pour chaque sous famille, les différentes versions telles que Windows3, Windows95, 98, NT, XP, ... Facile d'en déduire la même construction pour chacune des familles répertoriées.

Bien remarquer que l'ensemble des familles et leurs descendants constituent un arbre.
Ces données seront évidemment enregistrées dans l'entité OBJET avec utilisation de son sous type OBJET_PERE.

Pour illustrer un peu mieux cet enregistrement, imaginons que l'entité OBJET possède 4 champs:
ID champ clé primaire (unique),
ID_PERE champ clé de l'objet père s'il existe,
LIB champ désignation,
PARAM champ liste de paramètres attachés à l'objet.

Soit le tableau
ID ID_PERE LIB PARAM Commentaires
1 Racine Racine de tous les objets
11 1 Racine des objets
12 1 Racine des relations entre objets
15 12 Relation Outil -> Système d'exploitation
16 12 Relation Système d'exploitation -> Outil
...
111 11 Système d'exploitation
112 11 Interface Homme machine
...
119 11 Outil logiciel
...
121 111 Système Unix/Linux
122 121 Aix
123 121 Ubuntu
...
131 111 Système Windows
132 131 Windows3
...
177 119 Uniface
178 177 Uniface 5
179 177 Uniface 6
180 177 Uniface 7
181 177 Uniface 8
182 177 Uniface 9
...

On voit bien qu'il est très facile d'enregistrer dans notre structure de données toutes les caractéristiques de tous les outils logiciels possibles ainsi que ces outils eux mêmes. Reste maintenant à dire quelles sont les caractéristiques effectivement supportées par tel ou tel outil logiciel.

Nous allons pour cela, nous servir de la partie du modèle analogue à une nomenclature.
Par exemple supposons qu'Uniface 5 ne supportait que les systèmes Aix et Windows3.
Supposons également que l'entité LIEN se compose des champs suivants:
ID champ clé primaire (unique)
ID_ORIGINE champ contenant la clé de l'objet Origine
ID_DESTINATION champ contenant la clé de l'objet Destination
ID_RELATION champ contenant la clé d'un type de relation
Pour dire qu'Uniface 5 supporte les système Aix et Windows3 on a les lignes de tableau suivantes:
ID ID_ORIGINE ID_DESTINATION ID_RELATION
123 178 122 15
124 178 132 15

A l'inverse pour dire que le système Aix sait faire tourner Uniface 5, 6, 7, 8 on a:
ID ID_ORIGINE ID_DESTINATION ID_RELATION
234 122 178 16
235 122 179 16
237 122 180 16
321 122 181 16

Bien sûr on peut très facilement extrapoler ce court exemple sur toutes les autres caractéristiques.

Notre enregistrement des données permet il de faire des recherches en tous sens ? Oui, bien sûr, en voici la preuve.
Question: Quels sont les systèmes d'exploitations supportés par Uniface 5 ?
1. On recherche dans l'entité OBJET l'occurrence dont LIB=Uniface 5
2. On récupère la clé de cet objet ID=178
3. On recherche dans l'entité LIEN les occurrences telles que ID_ORIGINE=178
4. On trouve les clés lien 123 et 124 et surtout les ID_DESTINATION 122 et 132
5. On recherche dans OBJET la clé 122 qui nous donne le LIB: Aix et la clé père ID_PERE = 121
6. On recherche dans OBJET la clé 132 qui nous donne le LIB: Windows3 et la clé père ID_PERE = 131

Il est aisé d'extrapoler à toutes sortes de questions. Remarquer néanmoins que le raisonnement ci-dessus est quelque peu simplifié car la désignation Uniface 5 pourrait correspondre à tout autre chose qu'un outil logiciel (tout comme Aix peut être le système Unix vendu par IBM ou bien la ville de provence).

En fait pour éviter toute ambiguïté et être sûr de faire la bonne recherche, on peut remonter la filiation des objets de clé 122 et 132 pour s'assurer qu'ils sont bien des descendants du type Sytème d'exploitation.

5.a On recherche un OBJET dont ID = 121 (Système Unix/Linux). On trouve que son ID_PERE est 111
5.b On recherche un OBJET dont ID = 111 (Système d'exploitation), ce qui correspond bien à la question posée.
6.a On recherche un OBJET dont ID = 131 (Système Windows). On trouve que son ID_PERE est 111. On sait grâce au point 5.b que ça correspond bien à la question posée.

Une autre piste plus intéressante est d'utiliser le type de relation: en effet au point 4. on trouve également que ID_RELATION vaut 15.
Un accès dans OBJET avec ID=15 donne LIB=Relation Système d'exploitation -> Outil , ce qui correspond bien à la question posée.

Notez aussi que quelques champs supplémentaires seraient bien utiles pour gérer la perennité des données; par exemple un champ date de début de création d'une version de système d'exploitation à ajouter dans l'entité OBJET. De même un champ date de début et date de fin de validité de la relation entre 2 objets pourrait être ajouté utilement à l'entité LIEN.

A travers cet exemple un peu hard, je reconnais, j'espère vous avoir convaincu que le modèle de données à 2 entités seulement (OBJET et LIEN)convient parfaitement pour solutionner le problème initialement posé. Vous remarquerez qu'il est possible d'ajouter de nouvelles caractéristiques sans remettre en cause ce modèle.

Dans le prochain article, nous verrons que ce modèle a quelque chose d'universel !