La technologie Armadillo est une technologie ensembliste. Le langage SQL est destiné à manipuler des ensembles. Il est donc cohérent (et intelligent) de concevoir une technologie qui va considérer les ensembles comme des objets à part entière, compacts, et manipulables tels quels.
Pour cela, on utilise les index ensemblistes.

Qu’est ce qu’un index ensembliste ?

Un index est un accélérateur de recherche. Il existe différentes structures d’index. L’index ensembliste associe à chaque clé l’ensemble des documents concernés.

L’algorithme utilisé pour la compression des index est conçu de telle façon que la taille de l’index ne dépend pas de la taille de l’ensemble (plus précisément, la taille de l’index ne croit pas avec la taille de l’ensemble).
Ce même algorithme optimise les opérations ensemblistes : on peut effectuer l’union, l’intersection, la différence entre deux ensembles (opérateurs booléens OU, ET, SAUF) ou calculer le complémentaire d’un ensemble sans décompresser l’index.
Les opérations classiques en base de données (insertion, suppression, mise à jour) sont optimisées.

Et alors ?

Plusieurs index peuvent être utilisés simultanément (ce qui n’est pas le cas pour les technologies non-ensemblistes). En général, on utilise autant d’index que de colonnes figurant dans la clause where de la requête.
Il n’est plus nécessaire de faire le choix de l’index utilisé. Les optimiseurs de requêtes disparaissent.

Chaque colonne citée dans la clause where appelle son index respectif (un accès disque), les ensembles correspondants sont rapatriés puis, sans autre manipulation sur les ensembles, on effectue les opérations ensemblistes. Il n’est pas nécessaire de parcourir les ensembles réponses.
Les temps de réponse dépendent de la complexité de la requête et non de la taille de l’ensemble réponse. Les performances sur des requêtes complexes sont exceptionnelles.

Les index étant suffisamment compressés pour tenir en mémoire vive, un appel à l’index correspond à au plus un accès disque. Les opérations ensemblistes se font en mémoire.
Les performances sont CPU intensives et non disque intensives.

Enfin et dernièrement, l’écriture d’un sous select n’est plus déconseillée, mais au contraire naturelle et recommandée.
Les jointures disparaissent.

Retour au sommaire

Index programmables

Les index d’Armadillo sont programmables, c'est-à-dire qu’entre la donnée initiale et la donnée indexée, on peut faire appel à une routine d’index qui va traiter les données comme on le souhaite.
La routine appelée peut être de n’importe quelle nature, y compris être un programme extérieur. La donnée indexée peut être interrogée en tant que telle. Ceci permet de définir de nombreux types d’index.

Et alors ?

Au fil des années, suivant l’évolution des demandes et se combinant aux autres innovations technologiques d’Armadillo, certains index ont su se distinguer des autres par leur importance.

Indexer à la fois les métadonnées et le contenu d’un document, sans stocker le document lui-même :

On utilise un index qui extrait et index tous les mots du document. Le document n’a pas à être lui-même stocké.
Le volume de la base indexée est inférieur au volume des données initiales !

Combiner dans une même requête des critères documentaires et des critères structurés :

Une recherche avancée très fine est possible.
Exemple : Rodin sauf Musée = Rodin
Trouve tous les documents contenant le terme « Rodin » sauf ceux exposés au Musée Rodin.

Apparition de champs multivalués :

Le modèle relationnel classique interdit d’entrer plusieurs valeurs dans une colonne de table, ce qui a pour conséquence (entre autre) l’apparition et la multiplication exponentielle des tables de jointures. Une base classique repose sur des centaines de tables, ce qui donne des applications figées, impossibles à faire évoluer ou maintenir (l’ajout ou la modification d’une table peut être un cauchemar), à la merci d’un DBA tout puissant.
Un index programmable permet de définir des champs multivalués.

L’index associatif :

Index à deux niveaux sur le modèle tag/value. Permet d’envisager l’ensemble des tables d’une base de données comme un ensemble de tables virtuelles, rassemblées en une table unique de données.

Ces index étant toujours ensemblistes, les performances restent les mêmes.

Retour au sommaire

La table unique

L’index associatif d’Armadillo a permis une évolution importante en introduisant un attribut de type nouveau, le type list.

Une liste fonctionne sur le principe tag/value bien connu en XML
Id -> 123 -> Titre -> Exercices de mathématiques pour la Licence
-> auteurs -> Dellinger ; Vaugon ; Collion -> Collection -> Pearson Education...

Les données contenues dans une ligne de table sont maintenant rassemblées dans une colonne.
On accède à la valeur d’un tag par la syntaxe $field(’tag’).

Et alors ?

Les applications tournent sur seulement deux tables : une table de description de données (table Structure) et une table de données (table Donnée).
Les tables d’une base sont remplacées par des tables virtuelles, rassemblée dans la table Structure. Toutes les données de la base sont rassemblées dans une table unique.

La table Structure décrit les tables virtuelles : leurs noms et le type des colonnes (nom, existence index, multivalué, liste fermée...).
La mise en place d’une base de données peut donc se faire par une interface graphique très simple.
L’opération d’ajout d’une table à la base devient un ajout de ligne à la table Structure. Les modifications de tables sont possible à tout moment : ajout ou modification de colonnes, ajout de table...

• Les délais de prototypage disparaissent.
• L’évolutivité est permanente.
• La maintenance est simplifiée.
• L’utilisateur devient DBA et garde le contrôle, sans risque.

Enfin, les applications ne sont plus écrites pour des univers d’intérêt spécifiques, mais sont au contraire complètement génériques. Chaque nouvelle fonctionnalité se propage à tous les utilisateurs.

Retour au sommaire

Syntaxe

Le SQL d’Armadillo est un SQL étendu. Le SQL classique est entièrement contenu dans le SQL Armadillo.

En revanche, il est utilisé différemment, d’une part grâce à l’approche ensembliste, d’autre part en raison de l’existence des attributs nouveaux.

La syntaxe de base est prévue pour gérer les cas select [...] from [...] where = FONCTION
Le cas colonne = valeur est un cas particulier !

Exemples de requêtes

Sous select :

On veut trouver les clients ayant commandé un article coûtant plus de 100 euros.

Select * from Customer where custid in (select custid from Invoice where invoiceid in (select invoiceid from InvoiceLine I where itemid in (select itemid from Item where unitprice>100)))

1.000 articles de prix > 100 euros.
100.000 lignes de factures qui renvoient l’un de ces 1000 articles.
10.000 factures correspondant à ces 100.000 lignes.
1.000 clients pour ces 10.000 factures.

Armadillo : 1 accès aux articles (index ensembliste) + 1.000 accès aux lignes + 100.000 accès aux factures + 10.000 accès aux clients + 1.000 accès pour afficher les clients.
Total : 112.001 accès logiques aux lignes de la base. Quelques secondes.

Technologie non ensembliste :

Boucle sur des selects imbriqués, i.e : 1000*100.000*10.000*1.000 = 10^15, un million de milliards d’accès !
Le temps de réponse est de 30 ans si la machine fait un million de selects par seconde.
Une jointure est donc utilisée au lieu d’un sous select :

Select C.name,... from Customer C, Invoice I, InvoiceLine L,Item T where C.custid=I.custid and I.invoiceid=L.invoiceid and L.itemid=T.itemid where T.unitprice>100

Le temps de réponse est meilleur que 30 ans... mais reste moins bon que celui d’une technologie ensembliste! De plus une jointure ne peut pas être mise à jour.

Requêtes dans Document

Trouver les films dont une séquence contient un joueur précis :

sel Document where tbname=’film’ and rix[’titre’]=’coupe du monde 2007’ and pid in (sel id from Document where tbname=’sequence’ and rix[’joueur’]=’michalak’)

Utilisation d’une fonction dans la clause where :

Armadillo étant optimisée pour la manipulation d’ensembles, il est naturel d’introduire des fonctions ensemblistes dans la clause where.

Trouver les films dont le réalisateur est un des acteurs

sel $(fields, ’titre’) from Document where Intersect($(fields, ’realisateur’), $(fields, ’acteur’))>0

NB : Ici on ne peut pas utiliser $(fields,’realisateur’) = $(fields,’acteur’) car le champs ‘acteur’ peut être multivalué !