Date de dernière modification : 4/12/2018 · Date de dernière modification: 4/12/2018 Annexe 10 0 Les bases de données non relationnelles Outre des informations générales sur

Date de dernière modification : 4/12/2018

Annexe 10 0

Les bases de données non relationnelles

Outre des informations générales sur le terme NoSQL et sur la variétédes SGBD, cette annexe développe de manière pratique la notion deconversion de modèles. Des données organisées selon un modèlepeuvent être transformées sans perte de manière à être conformes à unautre modèles. On applique ce principe à quelques modèles dont ceuxque recouvre l’appellation NoSQL. Des informations de base sontégalement fournies sur les formats de données textuelles CSV etJSON. Une application des chaînes de blocs a été développée enSQLfast. Sa documentation est ajoutée à cette annexe.

2 Annexe 10 • Les bases de données non relationnelles

A10.1 QUE SIGNIFIE NoSQL ?

NoSQL est le #tag choisi, un peu au hasard, par un développeur londonien pouridentifier une réunion informelle qu’il organisait à San Francisco en 2009. Cetteréunion rassemblait divers acteurs du domaine des nouvelles technologies des basesde données, invités à présenter leurs offres. Très vite adopté pour désigner la familledes nouveaux SGBD, on lui a attribué dans un premier temps une sémantique guer-rière de rejet de SQL, considéré (une fois de plus depuis 1980 !) comme dépassé.Progressivement, une nouvelle interprétation plus conviviale s’est imposée : Notonly SQL. Comme nous l’avons vu au chapitre 10, celle-ci n’est guère plus perti-nente, mais a le mérite de mettre en évidence l’élargissement de l’écosystème desbases de données. Source : [Saladage,2013].

A10.2 Les SGBD les plus populaires 3

© J-

L H

aina

ut -

2015

A10.2 LES SGBD LES PLUS POPULAIRES

Le site http://db-engines.com/en/ranking1 classe chaque mois les SGBD (et plus généra-lement les gestionnaires de données) les plus populaires, par classe de modèles etpar popularité décroissante. Cette dernière est mesurée par le nombre de mentionsdans les sites web, les forums, les réseaux sociaux, offres d’emploi, etc.2 En mai2015, les SGBD se répartissaient comme suit :• Content store (2 ) : Jackrabbit, ModeShape• Document store (28) : MongoDB, CouchDB, Couchbase, RavenDB, GemFire,

Cloudant, RethinkDB, Datameer, Datomic, Mnesia, Microsoft Azure Docu-mentDB, PouchDB, Google Cloud Datastore, CloudKit, TokuMX, Clusterpoint, Terrastore, DensoDB, Djondb, EJDB, FleetDB, JasDB, LokiJS, RaptorDB, SenseiDB, Sequoiadb, SisoDb, WhiteDB

• Event Store (3) : InfluxDB, Event Store, NEventStore• Graph DBMS (10) : Neo4j, Titan, Sparksee, Giraph, InfiniteGraph, InfoGrid,

FlockDB, HyperGraphDB, GraphBase, VelocityGraph• Key-value store (44) : Redis, Memcached, Riak, Ehcache, Hazelcast, Berkeley

DB, Oracle Coherence, Amazon SimpleDB, Aerospike, Oracle NoSQL, Infi-nispan, LevelDB, GridGain, ZODB, GT.M, Tokyo Cabinet, NCache, WebSphere eXtreme Scale, WiredTiger, Tokyo Tyrant, XAP , Project Voldemort, Hibari, RocksDB, MapDB, STSdb, Scalaris, Kyoto Cabinet, Elliptics, HyperDex, Hams-terdb, ScaleOut StateServer, Bangdb, BergDB, CodernityDB, HyperLevelDB, Kyoto Tycoon, LedisDB, LightCloud, Nanolat, Quasardb, Resin Cache, Taran-tool, TomP2P

• Multi-model (14) : Amazon DynamoDB, MarkLogic, OrientDB, Virtuoso, Foun-dationDB, ArangoDB, Sqrrl, Crate.IO, GraphDB, Amisa Server, Blazegraph, CortexDB, GlobalsDB, OrigoDB

• Multivalue DBMS (10) :, Adabas, UniData, UniVerse, D3, jBASE, Model 204, Northgate Reality, SciDB, OpenInsight, Rasdaman, OpenQM

• Native XML DBMS (4) : Sedna, BaseX, Tamino, eXist-db• Navigational DBMS (2) : IMS, IDMS• Object oriented DBMS (15) : Caché, Db4o, Versant Object Database, ObjectS-

tore, Objectivity/DB, Perst, ObjectDB, GemStone/S, Eloquera, Siaqodb, Jade, Versant FastObjects, Starcounter, VelocityDB, WakandaDB

• RDF store (14) : Jena, Sesame, AllegroGraph, Algebraix, Stardog, Redland, 4store, RedStore, Strabon, BrightstarDB, CubicWeb, Dydra, Mulgara, SparkleDB

1. Les données de cette section sont publiée avec l’autorisation du responsable de ce site.2. Cette notion de popularité est à interpréter avec précaution. On peut imaginer qu’un SGBDpeu répandu mais particulièrement délicat à utiliser sera jugé plus populaire qu’un SGBD pluslargement utilisé mais ne posant pas de problèmes.


• Relational DBMS (98) : Oracle, MySQL, Microsoft SQL Server, PostgreSQL, DB2, Microsoft Access, SQLite, SAP Adaptive Server, Teradata, FileMaker, Hive, Informix, SAP HANA, MariaDB, Firebird, Netezza, Microsoft Azure SQL Database, Vertica, dBASE, Ingres, Greenplum, SAP SQL Anywhere, Amazon Redshift, Interbase, SAP IQ, Impala, HyperSQL, mSQL, Derby, H2, Google BigQuery, MaxDB, SAP Advantage Database Server,TimesTen, OpenEdge, Tera-data Aster, EnterpriseDB, Drizzle, VoltDB, Percona Server, ParAccel, Infobright, SQLBase, Oracle Rdb, MemSQL, MonetDB, DataEase, Empress, NuoDB, Red Brick, Amazon Aurora, Kdb+, Apache Drill, Altibase, NonStop SQL, R:BASE, Datacom/DB, solidDB, Clustrix, Vectorwise, 1010data, TokuDB, DBISAM, Pervasive PSQL, InfiniDB, Kognitio, FrontBase, OpenBase, VistaDB, Hadapt, NexusDB, EXASolution, Rainstor, Cubrid, ITTIA, eXtremeDB, ScimoreDB, Splice Machine, Akiban, LucidDB, XtremeData, Mimer SQL, WebScaleSQL, Dataupia, ScaleBase, ScaleDB, SQL.JS, GenieDB, Transbase, TransLattice, Tajo, SmallSQL, ElevateDB, c-treeACE, JethroData, JustOneDB, Postgres-XL, Valen-tina Server

• Search engine (15) : Solr, Elasticsearch, Splunk, Sphinx, Endeca, Google Search Appliance, Amazon CloudSearch, Microsoft Azure Search, Xapian, Indica, Compass, SearchBlox, Srch², DBSight, Exorbyte

• Wide column store (4) : Cassandra, HBase, Accumulo, Hypertable

Le recensement compte 263 gestionnaires. Les dix gestionnaires les plus populairessont à ce moment les suivants :

Rang Nom Classe Score1 Oracle Relationnel 1442.

2 MySQL Relationnel 1294

3 SQL Server Relationnel 1131

4 MongoDB Document 277

5 PostgreSQL Relationnel 274

6 DB2 Relationnel 201

7 Access Relationnel 146

8 Cassandra Colonnes 107

9 SQLite Relationnel 105

10 Redis Clé-valeur 95

A10.2 Les SGBD les plus populaires 5

© J-

L H

aina

ut -

2015

Popularité par classe :

Quelques observations– La variété et le nombre de SGBD sont impressionnants, surtout compte tenu de la

tendance naturelle du marché à la standardisation, qui, par nature, conduit à unappauvrissement de l’offre.

– La classe des systèmes relationnels est très majoritaire, tant en nombre de repré-sentants (37%) qu’en popularité (82,6%).

– Parmi les SGBD NoSQL, c’est la classe des SGBD orientés documents quioccupe la deuxième place, et particulièrement MongoDB, en 4e position absolue.

– Parmi les SGBD NoSQL toujours, c’est la population des SGBD Clé-valeurs quiest la plus nombreuse, malgré la pauvreté du modèle de données.

– 164 SGBD (62%) n’atteignent pas le score de 1 (pour rappel, celui d’Oracle est de1442); 71 n’atteignent pas le score de 0,1 et 44 n’atteignent pas le score de 0,01.

Les données de ranking au mois de mai 2015 sont disponibles sous la forme d’unebase de données dans fichier DBMS-Ranking.sql.3

Classe ScoreRelationnel 82,6%

Document 6,2%

Moteurs de recherche 3,6%

Clé-valeur 3,2%

Colonnes 2,8%

Graphe 0,6%

XML natif 0,3%

RDF 0,3%

Multivaleurs 0,2%

3. Mise à disposition avec l’autorisation de responsable du site.


A10.3 LE CONCEPT DE SCHÉMA DANS LES NOUVEAUX MODÈLES DE BASES DE DONNÉES

<A rédiger>

A10.4 Représentation de documents complexes dans une base de données relationnelle 7

© J-

L H

aina

ut -

2015

A10.4 REPRÉSENTATION DE DOCUMENTS COMPLEXES DANS UNE BASE DE DONNÉES RELATIONNELLE

<A rédiger>


A10.5 CONVERSION DE MODÈLES

L’existence, souvent dans la même organisation, de plusieurs modèles de bases dedonnées pose un problème intéressant, celui de la conversion de données d’unmodèle dans un autre. Ce problème n’est pas nouveau mais prend un accent toutparticulier avec la disponibilité des SGBD NoSQL.

Dans cette section et dans les suivantes nous étudierons le processus de conver-sion tout en restant dans le contexte du modèle relationnel. Partant du formathabituel de table, nous exprimerons un ensemble de modèles alternatifs en SQL etnous développerons les scripts de conversion. La traduction de ces données trans-formées selon l’un ou l’autre des SGBD devient alors une tâche triviale. Le modèleSQL joue dans cette approche le rôle de modèle pivot.

Cette manière de traiter le sujet est à but essentiellement didactique. Dans lapratique, la conversion se fera plus directement, l’extraction de données relation-nelles conduisant au chargement des données dans le modèle cible sans étapeintermédiaire.

Nous aborderons successivement les conversions entre le format standard detable et divers modéles généralement qualifés de schema-less.

A10.6 Le modèle de table universelle 9

© J-

L H

aina

ut -

2015

A10.6 LE MODÈLE DE TABLE UNIVERSELLE

Le terme de table universelle n’existe pas. Nous l’adopterons en hommage auconcept théorique de relation universelle dont il s’inspire. La relation universelle Ud’une base de données relationnelle B est une relation (fictive) telle que chaque rela-tion de B peut être obtenue par une projection de U. U contient toutes les données ettoutes des dépendences fonctionnelles de B, et elles seulement.4

Dans notre contexte, nous appellerons table universelle U d’une base de donnéesB une table jouissant des mêmes propriétés, c’est-à-dire en particulier qu’à toutinstant, le contenu de chaque table de B est égal à une projection de U.

Il existe plusieurs manière de définir une table universelle, par exemple par join-ture (externe) de toutes les tables, par produit relationnel ou par l’union de cestables. Nous choisirons cette dernière.

Signalons que tous les scripts relatifs au modèle de table universelle sont disponi-bles sous la forme du fichier Table-Universelle.sql.

A10.6.1Structures de la table universelleLa table universelle de la base de données CLICOM.db est structurée selon le schémaA10.1 et son contenu est illustré par la figure A10.3. Chaque ligne contient lesdonnées d’une ligne d’une table source. Chaque colonne représente une colonned’une table source. On observe cependant que les colonnes de même nom (NCLI,NCOM, NPRO n’ont qu’un seul représentant dans la table universelle. On fait en effetl’hypothèse que si deux colonnes portent le même nom, elle représentent le mêmeobjet du domaine d’application. La table universelle est dotée d’un identifiantprimaire technique EID sans signification. Toutes les colonnes sont facultatives àl’exception de l’identifiant EID.

Cette version du modèle ne distingue pas le type de l’entité représentée par uneligne (on qualifiera cette table de non typée). On peut donc à tout moment insérerune ligne constituée d’un ensemble arbitraire de valeurs. Si une colonne manquepour insérer une nouvelle ligne, elle est ajoutée par une instruction alter tableadd column. La table universelle offre une souplesse très proche de celle dumodèle historique de Cassandra.

4. Ce concept a été très controversé (voir http://infolab.stanford.edu/jdu-symposium/talks/mendelzon.pdf). Présenté par certains auteurs comme une alternative au modèle relationnel, il aété contesté par d’autres, le trouvant trop éloigné des concepts modélisés (une table = un typed’entités). Il y a cependant quelques implémentations exploitant cette idée : Lotus Notes (IBM) etSESAM, un SGBD diffusé par Siemens puis repris par Fujtsu. La technique présentée dans cettesection est très proche du modèle physique de SESAM.


Figure A10.1 - Schema de la table universelle de CLICOM.db (version non typée)

On pourrait critiquer ce modèle en arguant une perte importante de place, toute lignecomportant une valeur pour chaque colonne, qu’elle soit pertinente ou non. Il n’enest rien. Le SGBD représente la présence ou l’absence d’une valeur d’une colonnefacultative par un unique bit. La table CLICOM comporte 13 colonnes facultatives, cequi se traduit par 13 bits de présence par ligne. Le surcoût est donc négligeable.D’autre part, la conversion des quatre tables sources n’entraîne pas de redondanceautre que celle dont les données sources auraient été le siège.

Une variante de table universelle comporte une colonne additionnelle TYPE indi-quent le type de l’entité représentée par chaque ligne. Ce modèle, qui reconnaîtexplicitement l’existence de types d’entités, est proche du modèle CQL deCassandra. Il est évidemment plus contraignant puisque l’insertion d’une ligne doitrespecter, d’une part, les colonnes autorisées pour le type d’entités choisi, et d’autrepart les contraintes d’unicité et référentielles. Son schéma est donné par le scriptA10.2 et son contenu par la figure A10.4.

createOrReplaceDB CLICOM-U;create table CLICOM( EID integer not null primary key autoincrement, NCLI char(10), NOM char(32), ADRESSE char(60), LOCALITE char(30), CAT char(2), COMPTE decimal(9,2), NPRO char(15), LIBELLE char(60), PRIX integer, QSTOCK integer, NCOM char(12), DATECOM date, QCOM integer);closeDB;


© J-

L H

aina

ut -

2015

Figure A10.2 - Schema de la table universelle de CLICOM.db (version typée)

A10.6.2Les indexLes index doivent favoriser les requêtes et la validation des contraintes propres auxdonnées sources. La cohabitation de lignes d’origines différentes suggère l’utilisa-tion d’index partiels pour soutenir l’accès par les identifiants sources :

create unique index CLI_NCLI on CLICOM(NCLI) where TYPE = 'CLI';

createOrReplaceDB CLICOM-UNI.db;create table CLICOM( EID integer not null primary key autoincrement, TYPE char(18) not null, NCLI char(10), NOM char(32), ADRESSE char(60), LOCALITE char(30), CAT char(2), COMPTE decimal(9,2), NPRO char(15), LIBELLE char(60), PRIX integer, QSTOCK integer, NCOM char(12), DATECOM date, QCOM integer);closeDB;


+-----+------+-----------+----------------------+-----------+-----+--------+-------+------------+------+--------+---------------------+-------+--------+

| EID | NCLI | NOM | ADRESSE | LOCALITE | CAT | COMPTE | NCOM | DATECOM | QCOM | NPRO | LIBELLE | PRIX | QCTOCK |

+-----+------+-----------+----------------------+-----------+-----+--------+-------+------------+------+--------+---------------------+-------+--------+

| 1 | B112 | HANSENNE | 23, r. Dumont | Poitiers | C1 | 1250 | -- | -- | -- | -- | -- | -- | -- |

| 2 | C123 | MERCIER | 25, r. Lemaître | Namur | C1 | -2300 | -- | -- | -- | -- | -- | -- | -- |

| 3 | B332 | MONTI | 112, r. Neuve | Genève | B2 | 0 | -- | -- | -- | -- | -- | -- | -- |

| 4 | F010 | TOUSSAINT | 5, r. Godefroid | Poitiers | C1 | 0 | -- | -- | -- | -- | -- | -- | -- |

| 5 | K111 | VANBIST | 180, r. Florimont | Lille | B1 | 720 | -- | -- | -- | -- | -- | -- | -- |

| 6 | S127 | VANDERKA | 3, av. des Roses | Namur | C1 | -4580 | -- | -- | -- | -- | -- | -- | -- |

| 7 | B512 | GILLET | 14, r. de l'Eté | Toulouse | B1 | -8700 | -- | -- | -- | -- | -- | -- | -- |

| 8 | B062 | GOFFIN | 72, r. de la Gare | Namur | B2 | -3200 | -- | -- | -- | -- | -- | -- | -- |

| 9 | C400 | FERARD | 65, r. du Tertre | Poitiers | B2 | 350 | -- | -- | -- | -- | -- | -- | -- |

| 10 | C003 | AVRON | 8, ch. de la Cure | Toulouse | B1 | -1700 | -- | -- | -- | -- | -- | -- | -- |

| 11 | K729 | NEUMAN | 40, r. Bransart | Toulouse | -- | 0 | -- | -- | -- | -- | -- | -- | -- |

| 12 | F011 | PONCELET | 17, Clôs des Erables | Toulouse | B2 | 0 | -- | -- | -- | -- | -- | -- | -- |

| 13 | L422 | FRANCK | 60, r. de Wépion | Namur | C1 | 0 | -- | -- | -- | -- | -- | -- | -- |

| 14 | S712 | GUILLAUME | 14a, ch. des Roses | Paris | B1 | 0 | -- | -- | -- | -- | -- | -- | -- |

| 15 | D063 | MERCIER | 201, bvd du Nord | Toulouse | -- | -2250 | -- | -- | -- | -- | -- | -- | -- |

| 16 | F400 | JACOB | 78, ch. du Moulin | Bruxelles | C2 | 0 | -- | -- | -- | -- | -- | -- | -- |

| 17 | K111 | -- | -- | -- | -- | -- | 30178 | 2015-12-21 | -- | -- | -- | -- | -- |

| 18 | C400 | -- | -- | -- | -- | -- | 30179 | 2015-12-22 | -- | -- | -- | -- | -- |

| 19 | S127 | -- | -- | -- | -- | -- | 30182 | 2015-12-23 | -- | -- | -- | -- | -- |

| 20 | C400 | -- | -- | -- | -- | -- | 30184 | 2015-12-23 | -- | -- | -- | -- | -- |

| 21 | F011 | -- | -- | -- | -- | -- | 30185 | 2016-01-02 | -- | -- | -- | -- | -- |

| 22 | C400 | -- | -- | -- | -- | -- | 30186 | 2016-01-02 | -- | -- | -- | -- | -- |

| 23 | B512 | -- | -- | -- | -- | -- | 30188 | 2016-01-03 | -- | -- | -- | -- | -- |

| 24 | -- | -- | -- | -- | -- | -- | 30178 | -- | 25 | CS464 | -- | -- | -- |

| 25 | -- | -- | -- | -- | -- | -- | 30179 | -- | 20 | PA60 | -- | -- | -- |

| 26 | -- | -- | -- | -- | -- | -- | 30179 | -- | 60 | CS262 | -- | -- | -- |

| 27 | -- | -- | -- | -- | -- | -- | 30182 | -- | 30 | PA60 | -- | -- | -- |

| 28 | -- | -- | -- | -- | -- | -- | 30184 | -- | 120 | CS464 | -- | -- | -- |

| 29 | -- | -- | -- | -- | -- | -- | 30184 | -- | 20 | PA45 | -- | -- | -- |

| 30 | -- | -- | -- | -- | -- | -- | 30185 | -- | 15 | PA60 | -- | -- | -- |

| 31 | -- | -- | -- | -- | -- | -- | 30185 | -- | 600 | PS222 | -- | -- | -- |

| 32 | -- | -- | -- | -- | -- | -- | 30185 | -- | 260 | CS464 | -- | -- | -- |

| 33 | -- | -- | -- | -- | -- | -- | 30186 | -- | 3 | PA45 | -- | -- | -- |

| 34 | -- | -- | -- | -- | -- | -- | 30188 | -- | 70 | PA60 | -- | -- | -- |

| 35 | -- | -- | -- | -- | -- | -- | 30188 | -- | 92 | PH222 | -- | -- | -- |

| 36 | -- | -- | -- | -- | -- | -- | 30188 | -- | 180 | CS464 | -- | -- | -- |

| 37 | -- | -- | -- | -- | -- | -- | 30188 | -- | 22 | PA45 | -- | -- | -- |

| 38 | -- | -- | -- | -- | -- | -- | -- | -- | -- | CS262 | RAFT. PINE 200x6x2 | 75 | 45 |

| 39 | -- | -- | -- | -- | -- | -- | -- | -- | -- | CS264 | RAFT. PINE 200x6x4 | 120 | 2690 |

| 40 | -- | -- | -- | -- | -- | -- | -- | -- | -- | CS464 | RAFT. PINE 400x6x4 | 220 | 450 |

| 41 | -- | -- | -- | -- | -- | -- | -- | -- | -- | PA45 | NAILS STEEL 45 (1K) | 105 | 580 |

| 42 | -- | -- | -- | -- | -- | -- | -- | -- | -- | PA60 | NAILS STEEL 60 (1K) | 95 | 134 |

| 43 | -- | -- | -- | -- | -- | -- | -- | -- | -- | PH222 | PL. BEECH 200x20x2 | 230 | 782 |

| 44 | -- | -- | -- | -- | -- | -- | -- | -- | -- | PS222 | PL. PINE 200x20x2 | 185 | 1220 |

+-----+------+-----------+----------------------+-----------+-----+--------+-------+------------+------+--------+---------------------+-------+--------+

Figu

re A

10.3

- Ta

ble

univ

erse

lle n

on ty

pée

de la

bas

e de

don

nées

CLI

CO

M.d

b


© J-

L H

aina

ut -

2015

+-----+------+------+-----------+----------------------+-----------+-----+--------+-------+------------+------+--------+---------------------+-------+--------+

| EID | TYPE | NCLI |NOM | ADRESSE | LOCALITE | CAT | COMPTE | NCOM | DATECOM | QCOM | NPRO | LIBELLE | PRIX | QCTOCK |

+-----+------+------+-----------+----------------------+-----------+-----+--------+-------+------------+------+--------+---------------------+-------+--------+

| 1 | CLI | B112 | HANSENNE | 23, r. Dumont | Poitiers | C1 | 1250 | -- | -- | -- | -- | -- | -- | -- |

| 2 | CLI | C123 | MERCIER | 25, r. Lemaître | Namur | C1 | -2300 | -- | -- | -- | -- | -- | -- | -- |

| 3 | CLI | B332 | MONTI | 112, r. Neuve | Genève | B2 | 0 | -- | -- | -- | -- | -- | -- | -- |

| 4 | CLI | F010 | TOUSSAINT | 5, r. Godefroid | Poitiers | C1 | 0 | -- | -- | -- | -- | -- | -- | -- |

| 5 | CLI | K111 | VANBIST | 180, r. Florimont | Lille | B1 | 720 | -- | -- | -- | -- | -- | -- | -- |

| 6 | CLI | S127 | VANDERKA | 3, av. des Roses | Namur | C1 | -4580 | -- | -- | -- | -- | -- | -- | -- |

| 7 | CLI | B512 | GILLET | 14, r. de l'Eté | Toulouse | B1 | -8700 | -- | -- | -- | -- | -- | -- | -- |

| 8 | CLI | B062 | GOFFIN | 72, r. de la Gare | Namur | B2 | -3200 | -- | -- | -- | -- | -- | -- | -- |

| 9 | CLI | C400 | FERARD | 65, r. du Tertre | Poitiers | B2 | 350 | -- | -- | -- | -- | -- | -- | -- |

| 10 | CLI | C003 | AVRON | 8, ch. de la Cure | Toulouse | B1 | -1700 | -- | -- | -- | -- | -- | -- | -- |

| 11 | CLI | K729 | NEUMAN | 40, r. Bransart | Toulouse | -- | 0 | -- | -- | -- | -- | -- | -- | -- |

| 12 | CLI | F011 | PONCELET | 17, Clôs des Erables | Toulouse | B2 | 0 | -- | -- | -- | -- | -- | -- | -- |

| 13 | CLI | L422 | FRANCK | 60, r. de Wépion | Namur | C1 | 0 | -- | -- | -- | -- | -- | -- | -- |

| 14 | CLI | S712 | GUILLAUME | 14a, ch. des Roses | Paris | B1 | 0 | -- | -- | -- | -- | -- | -- | -- |

| 15 | CLI | D063 | MERCIER | 201, bvd du Nord | Toulouse | -- | -2250 | -- | -- | -- | -- | -- | -- | -- |

| 16 | CLI | F400 | JACOB | 78, ch. du Moulin | Bruxelles | C2 | 0 | -- | -- | -- | -- | -- | -- | -- |

| 17 | COM | K111 | -- | -- | -- | -- | -- | 30178 | 2015-12-21 | -- | -- | -- | -- | -- |

| 18 | COM | C400 | -- | -- | -- | -- | -- | 30179 | 2015-12-22 | -- | -- | -- | -- | -- |

| 19 | COM | S127 | -- | -- | -- | -- | -- | 30182 | 2015-12-23 | -- | -- | -- | -- | -- |

| 20 | COM | C400 | -- | -- | -- | -- | -- | 30184 | 2015-12-23 | -- | -- | -- | -- | -- |

| 21 | COM | F011 | -- | -- | -- | -- | -- | 30185 | 2016-01-02 | -- | -- | -- | -- | -- |

| 22 | COM | C400 | -- | -- | -- | -- | -- | 30186 | 2016-01-02 | -- | -- | -- | -- | -- |

| 23 | COM | B512 | -- | -- | -- | -- | -- | 30188 | 2016-01-03 | -- | -- | -- | -- | -- |

| 24 | DET | -- | -- | -- | -- | -- | -- | 30178 | -- | 25 | CS464 | -- | -- | -- |

| 25 | DET | -- | -- | -- | -- | -- | -- | 30179 | -- | 20 | PA60 | -- | -- | -- |

| 26 | DET | -- | -- | -- | -- | -- | -- | 30179 | -- | 60 | CS262 | -- | -- | -- |

| 27 | DET | -- | -- | -- | -- | -- | -- | 30182 | -- | 30 | PA60 | -- | -- | -- |

| 28 | DET | -- | -- | -- | -- | -- | -- | 30184 | -- | 120 | CS464 | -- | -- | -- |

| 29 | DET | -- | -- | -- | -- | -- | -- | 30184 | -- | 20 | PA45 | -- | -- | -- |

| 30 | DET | -- | -- | -- | -- | -- | -- | 30185 | -- | 15 | PA60 | -- | -- | -- |

| 31 | DET | -- | -- | -- | -- | -- | -- | 30185 | -- | 600 | PS222 | -- | -- | -- |

| 32 | DET | -- | -- | -- | -- | -- | -- | 30185 | -- | 260 | CS464 | -- | -- | -- |

| 33 | DET | -- | -- | -- | -- | -- | -- | 30186 | -- | 3 | PA45 | -- | -- | -- |

| 34 | DET | -- | -- | -- | -- | -- | -- | 30188 | -- | 70 | PA60 | -- | -- | -- |

| 35 | DET | -- | -- | -- | -- | -- | -- | 30188 | -- | 92 | PH222 | -- | -- | -- |

| 36 | DET | -- | -- | -- | -- | -- | -- | 30188 | -- | 180 | CS464 | -- | -- | -- |

| 37 | DET | -- | -- | -- | -- | -- | -- | 30188 | -- | 22 | PA45 | -- | -- | -- |

| 38 | PRO | -- | -- | -- | -- | -- | -- | -- | -- | -- | CS262 | RAFT. PINE 200x6x2 | 75 | 45 |



| 41 | PRO | -- | -- | -- | -- | -- | -- | -- | -- | -- | PA45 | NAILS STEEL 45 (1K) | 105 | 580 |

| 42 | PRO | -- | -- | -- | -- | -- | -- | -- | -- | -- | PA60 | NAILS STEEL 60 (1K) | 95 | 134 |

| 43 | PRO | -- | -- | -- | -- | -- | -- | -- | -- | -- | PH222 | PL. BEECH 200x20x2 | 230 | 782 |

| 44 | PRO | -- | -- | -- | -- | -- | -- | -- | -- | -- | PS222 | PL. PINE 200x20x2 | 185 | 1220 |

+-----+------+------+-----------+----------------------+-----------+-----+--------+-------+------------+------+--------+---------------------+-------+--------+

Figu

re A

10.4

- Ta

ble

univ

erse

lle ty

pée

de la

bas

e de

don

nées

CLI

CO

M.d

b


create unique index PRO_NPRO on CLICOM(NPRO) where TYPE = 'PRO';

create unique index COM_NCOM on CLICOM(NCLI) where TYPE = 'COM';

create unique index DET_NCOM_NPRO on CLICOM(NCOM,NPRO) where TYPE = 'DET';

On fera de même pour les index des clés étrangères :

create index COM_NCLI on CLICOM(NCLI) where TYPE = 'COM';

create index DET_NPRO on CLICOM(NPRO) where TYPE = 'DET';

On écarte un index sur NCOM where TYPE = 'DET', qui serait préfixe deDET_NCOM_NPRO, et donc inutile (voir chapitre 14, règle des index préfixes).

A10.6.3Migration des données standard vers une table universelle

Le processus de migration des données d’une base de données standard vers sa tableuniverselle est très simple. Il correspond au script A10.5 dans l’hypothèse où la tableCLICOM et les tables sources appartiendraient à la même base de données. Si cestables appartiennent à des bases de données différentes, on passera par un scriptintermédiaire composé de requêtes insert into CLICOM, générées à partir de labase de données CLICOM.db.

Figure A10.5 - Migration des données standard vers la table universelle typée

La table universelle permet d’éviter les auto-jointures que traduisent les jointuresbasées sur les clés étrangères des données sources, comme le montre le script A10.6,qui exploite le partage de la colonne NCOM par les lignes originaires de COMMANDEet celles issues de DETAIL.

insert into CLICOM(TYPE,NCLI,NOM,ADRESSE,LOCALITE,CAT,COMPTE)select 'CLI',NCLI,NOM,ADRESSE,LOCALITE,CAT,COMPTE from CLIENT;

insert into CLICOM(TYPE,NPRO,LIBELLE,PRIX,QCOM)select 'PROD',NPRO,LIBELLE,PRIX,QCOM from PRODUIT;

insert into CLICOM(TYPE,NCOM,NCLI,DATECOM)select 'COM',NCOM,NCLI,DATECOM from COMMANDE;

insert into CLICOM(TYPE,NCOM,NPRO,QCOM)select 'DET',NCOM,NPRO,QCOM from DETAIL;


© J-

L H

aina

ut -

2015

Figure A10.6 - La table universelle permet d’éviter certaines jointures courantes

+-------+------+------------+-------+------+| NCOM | NCLI | DATECOM | NPRO | QCOM |+-------+------+------------+-------+------+| 30184 | C400 | 2015-12-23 | -- | -- || 30184 | -- | -- | CS464 | 120 || 30184 | -- | -- | PA45 | 20 |+-------+------+------------+-------+------+

Cette requête pourra s’appuyer sur l’index suivant :

create index COMDET_NCOM on CLICOM(NCOM) where TYPE in ('COM','DET');

Pour les mêmes raisons, on créera les deux index suivants :

create index CLICOM_NCLI on CLICOM(NCLI) where TYPE in ('CLI','COM');

create index PRODET_NCPRO on CLICOM(NPRO) where TYPE in ('PRO','DET');

La technique n’est pas sans rappeler la structure des clusters d’Oracle (chapitre 4).

A10.6.4Expression des données sourcesL’extraction des données sources à partir du contenu de la table universelle esttriviale. On l’exprimera sous la forme de vues SQL.

Figure A10.7 - Expression des données sources à partir de la table universelle typée

select NCOM,NCLI,DATECOM,NPRO,QCOMfrom CLICOM where NCOM = '30184';

create view V_CLIENT asselect NCLI,NOM,ADRESSE,LOCALITE,CAT,COMPTEfrom CLICOM where TYPE = 'CLI';


A10.7 LE MODÈLE ORIENTÉ COLONNES

Dans ce modèle, chaque propriété, qui dans le modèle standard est représentée parune colonne d’une table, est représentée par une table, dite table-colonne. Une table-colonne comporte généralement deux colonnes, l’une qui identifie une entité etl’autre qui spécifie la valeur de la propriété pour cette entité.

Figure A10.8 - Modèle orienté colonnes de la base de données CLICOM.db

createOrReplaceDB CLICOM-COL.db;

create table CLI_NOM( NCLI char(10) not null primary key, NOM char(32) not null);create table CLI_ADRESSE( NCLI char(10) not null primary key, ADRESSE char(60) not null);create table CLI_LOCALITE( NCLI char(10) not null primary key, LOCALITE char(30) not null);create table CLI_CAT( NCLI char(10) not null primary key, CAT char(2));create table CLI_COMPTE( NCLI char(10) not null primary key, COMPTE decimal(9,2) not null);

create table PRO_LIBELLE( NPRO char(15) not null primary key, LIBELLE char(60) not null);create table PRO_PRIX( NPRO char(15) not null primary key, PRIX integer not null);create table PRO_QSTOCK( NPRO char(15) not null primary key, QSTOCK integer not null);

create table COM_NCLI( NCOM char(12) not null primary key, NCLI char(10) not null);create table COM_DATECOM( NCOM char(12) not null primary key, DATECOM date not null);

create table DET_QCOM( NCOM char(12) not null, NPRO char(15) not null, QCOM integer not null? primary key (NCOM,NPRO));

closeDB;

A10.7 Le modèle orienté colonnes 17

© J-

L H

aina

ut -

2015

Alors que le modèle classique représente un client par une ligne de la table CLIENT,le modèle orienté colonne le représente par les lignes extraites de chacune des cinqtables-colonnes enregistrant respectivement les noms, les adresses, les localités, lescatégories et les comptes. Le script A10.8 crée les structures orientées colonnes de labase de données CLICOM.db.

Des index seront en tout cas créés pour chaque identifiant primaire et pour lescolonnes de données susceptibles de faire l’objet de critères de sélection.

Nous avons utilisé les identifiants primaires comme identifiant d’entités. Cettetransformation pose quelques petits problèmes :– Quel est le sort des colonnes facultatives ? Deviennent-elles obligatoires dans le

schéma final ou y restent-elles facultatives ? Dans le premier cas, aucune lignen’apparaît dans la table-colonne pour les lignes sources n’ayant pas de valeurpour cette colonne. Une jointure avec une autre table-colonne doit être une join-ture externe, afin de générer les valeurs null là où la seconde table ne possède pasde ligne. En outre, les identifiants d’entités de la table source seraient perdus sitoutes les colonnes (hors identifiant primaire) étaient facultatives. Dans le secondcas, une jointure naturelle suffira, toutes les tables-colonnes ayant le mêmenombre de lignes. C’est ce dernier cas qui est adopté dans la transformation.

– Les colonnes des identifiants primaires sont traitées de manière particulièrepuisqu’elle apparaissent dans toutes les tables-colonne sans disposer de leurpropre table-colonne. Un identifiant composite conduit à des tables-colonnes nonbinaires (c’est le cas de DETAIL). Une structure alternative consisterait à utiliserun identifiant technique indépendant de manière à traiter chaque colonne de lamême manière. Se poserait alors le problème de l’expression des identifiantscomposites et des clés étrangères composites. Formellement, ces contraintesdevraient être exprimée sur des jointures qui réassemblent leurs composants. Enpratique, elles se traduiront par des déclencheurs.

– Un schéma orienté colonnes comporte deux types de clés étrangères, celles quiassurent la cohésion des données de chaque entité (les valeurs de CLI_CAT.NCLIsont les valeurs de CLI_NOM.NCLI et inversement) et celles qui existaient parmiles tables sources (les valeurs de COM_NCLI.NCLI sont des valeurs deCLI_NOM.NCLI).

La figure A10.9 montre le contenu des tables CLI_NOM, CLI_LOCALITE et CLI_CAT.

+------+-----------+ +------+-----------+ +------+-----+ | NCLI | NOM | | NCLI | LOCALITE | | NCLI | CAT | +------+-----------+ +------+-----------+ +------+-----+ | B112 | HANSENNE | | B112 | Poitiers | | B112 | C1 | | C123 | MERCIER | | C123 | Poitiers | | C123 | C1 | | B332 | MONTI | | B332 | Genève | | B332 | B2 | | F010 | TOUSSAINT | | F010 | Poitiers | | F010 | C1 | | K111 | VANBIST | | K111 | Lille | | K111 | B1 | | S127 | VANDERKA | | S127 | Namur | | S127 | C1 | | B512 | GILLET | | B512 | Toulouse | | B512 | B1 | | B062 | GOFFIN | | B062 | Namur | | B062 | B2 | | C400 | FERARD | | C400 | Poitiers | | C400 | B2 | | C003 | AVRON | | C003 | Toulouse | | C003 | B1 |


| K729 | NEUMAN | | K729 | Toulouse | | K729 | -- | | F011 | PONCELET | | F011 | Toulouse | | F011 | B2 | | L422 | FRANCK | | L422 | Namur | | L422 | C1 | | S712 | GUILLAUME | | S712 | Paris | | S712 | B1 | | D063 | MERCIER | | D063 | Toulouse | | D063 | -- | | F400 | JACOB | | F400 | Bruxelles | | F400 | C2 | +------+-----------+ +------+-----------+ +------+-----+

Figure A10.9 - Trois des tables-colonnes issues de la table source CLIENT

Ce modèle présente l’avantage de réduire la taille des tables et les temps d’accèspour certaines requêtes simples (quel est le nom du client C400 ?). Chaque table-colonne peut disposer des index qui lui sont le plus favorable. Le modèle permetaussi une évolution en souplesse du schéma, par ajout et suppression de tables-colonnes.

RemarqueContrairement à ce que le nom orienté-colonnes pourrait laisser penser, cemodèle est différent de celui des SGBD NoSQL dits orientés colonnes, danslesquels la notion de colonne est, comme nous l’avons vu, assez particulier.

A10.7.1Migration des données standard vers des tables-colonnesLe script A10.10 charge les tables-colonnes à partir des tables standard.

Figure A10.10 - Migration des données standard vers les tables-colonnes

A10.7.2Expression des données sourcesLa reconstitution des données sources est réalisée par une jointure des tables-colonnes correspondantes (script A10.11).

insert into CLI_NOM select NCLI,NOM from CLIENT;insert into CLI_ADRESSE select NCLI,ADRESSE from CLIENT;insert into CLI_LOCALITE select NCLI,LOCALITE from CLIENT;insert into CLI_CAT select NCLI,CAT from CLIENT;insert into CLI_COMPTE select NCLI,COMPTE from CLIENT;

insert into PRO_LIBELLE select NPRO,LIBELLE from PRODUIT;insert into PRO_PRIX select NPRO,PRIX from PRODUIT;insert into PRO_QSTOCK select NPRO,QSTIOCK from PRODUIT;

insert into COM_NCLI select NCOM,NCLI from COMMANDE;insert into COM_DATECOM select NCOM,NCLI from COMMANDE;

insert into DET_QCOM select NCOM,NPRO,QCOM from DETAIL;

A10.7 Le modèle orienté colonnes 19

© J-

L H

aina

ut -

2015

Figure A10.11 - Expression des données sources à partir de la table universelle typée

Les scripts relatifs au modèle orienté colonnes sont disponibles sous la forme dufichier Tables-colonnes.sql.

create view V_CLIENT asselect C1.NCLI,NOM,ADRESSE,LOCALITE,CAT,COMPTEfrom CLI_NOM C1,CLI_ADRESSE C2,CLI_LOCALITE C3, CLI_CAT C4,CLI_COMPTE C5where C1.NCLI = C2.NCLI and C1.NCLI = C3.NCLI and C1.NCLI = C4.NCLI and C1.NCLI = C5.NCLI;


A10.8 LE MODÈLE CLÉ-VALEUR AGRÉGÉ

Les modèles de table universelle et de tables-colonnes partagent avec le modèleclassique l’existence d’un schéma qui assigne aux tables et aux colonnes des nomsqui évoquent de manière explicite les concepts du domaine d’application : CLIENT,ADRESSE, QSTOCK, etc.

Les modèles Clé-valeur, et leurs variantes Attribut-valeur, vont au contrairedéfinir des structure de données de plus en plus génériques, c’est-à-dire plus indé-pendantes du domaine d’application.

Le modèle évoqué dans le titre (Clé-valeur agrégé) est de peu d’intérêt dans cettediscussion. Nous le citons simplement parce qu’il correspond aux modèles NoSQLdits clé-valeur. Chaque entité est décrite par un identifiant primaire, souvent unsimple nombre ou une adresse (URI par exemple) sans signification, accompagnéd’une chaîne de caractères ou de bits sans structure (un CLOB ou un BLOB).L’extraction de fragments significatifs de cette chaîne est de la responsabilité desprogrammes d’application5. Nous n’en dirons donc rien de plus.

5. C’est le cas d’Oracle, qui applique à Berkeley DB un codage JSON.

A10.9 Le modèle Attribut-valeur - Version 1 21

© J-

L H

aina

ut -

2015

A10.9 LE MODÈLE ATTRIBUT-VALEUR - VERSION 1

Rappelons d’abord que le terme clé-valeur désigne en toute généralité (c’est-à-direau-delà des SGBD NoSQL) une forme d’expression de propriétés constituée du nomde la propriété et de la valeur qui lui est assignée. Ce format est très répandu dansune large variété d’applications. Citons par exemple les fichiers d’initialisation quipeuplent nos disques durs, et qui sont constitués d’une liste de couples clé-valeurs,tels que SQLfast.ini dont on donne un extrait :

autoclosedb = mainscriptselect-align = Ycsv-separator = ;label-separator = |outputtype = consoleoutputmode = write

Ce pattern est parfaitement applicable à la représentation du contenu d’une base dedonnées. Pour un client particulier (C400 par exemple), on écrira NOM = FERARD.Plus généralement, on associera à l’entité C400 une liste de couples clé-valeur qui enprécise les caractéristiques. Puisque nous allons nous limiter à ce domaine, nousadopterons un vocabulaire qui lui est plus naturel. Nous parlerons désormais demodèles Attribut-valeur.

Dans cette première version du modèle, les données traduites sous la formeAttribut-valeur sont enregistrées dans des tables qui correspondent chacune à unetable du modèle standard. Nous les nommerons AV1_CLIENT, AV1_PRODUIT,AV1_COMMANDE et AV1_DETAIL.

Chaque table est constituée de trois colonnes dénommées Entite, Attribut et Valeur.Chaque ligne spécifie la valeur d’un l’attribut d’une entité. Par exemple, la tableCV1_CLIENT contiendra la ligne (C400,NOM,FERARD) indiquant que le client C400a un attribut NOM dont la valeur est FERARD.

La table AV1_CLIENT est définie par le script A10.12. La colonne Valeur estfacultative pour permettre l’enregistrement des valeurs null de CAT. Les trois autrestables sont créées de manière similaire, hormis le caractère obligatoire de la colonneValeur.

Figure A10.12 - Création de la table AV1_CLIENT

create table AV1_CLIENT( Entite varchar(32) not null, Attribut varchar(32) not null, Valeur varchar(32), primary key (Entite,Attribut));


A10.9.1Migration des données standard vers des tables attribut-valeurLe chargement des données dans les tables attribut-valeur à partir des tables standardest illustré par le script A10.13 montrant le cas des tables AV1_CLIENT etAV1_DETAIL.

La table AV1_DETAIL mérite un traitement un peu particulier. En effet, les entitésdétail sont identifiées par la colonne Entite, alors qu’elles sont, dans la table sourceDETAIL, identifiées par le couple (NCOM,NPRO). On convertit ce couple en unevaleur unique de manière telle qu’il ne s’ensuit aucune ambiguïté, par exemple, si lecaractère - ne peut apparaître dans les valeurs de NCOM et NPRO,

NCOM||'-'||NPRO

Remarquons que l’usage des valeurs des identifiants primaires pour désigner lesentités (colonne Entité) est juste une simple facilité. Toute autre valeur, telle qu’unidentifiant technique, conviendrait tout aussi bien.

Figure A10.13 - Migration des données vers les tables attribut-valeur

Ci-dessous des extraits des tables AV1_CLIENT et AV1_DETAIL.

+--------+----------+-------------------+| Entite | Attribut | Valeur |+--------+----------+-------------------+| B062 | ADRESSE | 72, r. de la Gare || B062 | CAT | B2 || B062 | COMPTE | -3200 || B062 | LOCALITE | Namur || B062 | NCLI | B062 |

insert into AV1_CLIENT (Entite,Attribut,Valeur) select NCLI,'NCLI',NCLI from CLIENT;insert into AV1_CLIENT (Entite,Attribut,Valeur) select NCLI,'NOM',NOM from CLIENT;insert into AV1_CLIENT (Entite,Attribut,Valeur) select NCLI,'ADRESSE',ADRESSE from CLIENT;insert into AV1_CLIENT (Entite,Attribut,Valeur) select NCLI,'LOCALITE',LOCALITE from CLIENT;insert into AV1_CLIENT (Entite,Attribut,Valeur) select NCLI,'CAT',CAT from CLIENT;insert into AV1_CLIENT (Entite,Attribut,Valeur) select NCLI,'COMPTE',COMPTE from CLIENT;

. . .

insert into AV1_DETAIL (Entite,Attribut,Valeur) select NCOM||'-'||NPRO,'NCOM',NCOM from DETAIL;insert into AV1_DETAIL (Entite,Attribut,Valeur) select NCOM||'-'||NPRO,'NPRO',NPRO from DETAIL;insert into AV1_DETAIL (Entite,Attribut,Valeur) select NCOM||'-'||NPRO,'QCOM',QCOM from DETAIL;


© J-

L H

aina

ut -

2015

| B062 | NOM | GOFFIN || B112 | ADRESSE | 23, r. Dumont || B112 | CAT | C1 || B112 | COMPTE | 1250 || B112 | LOCALITE | Poitiers || B112 | NCLI | B112 || B112 | NOM | HANSENNE || B332 | ADRESSE | 112, r. Neuve || B332 | CAT | B2 || B332 | COMPTE | 0 || B332 | LOCALITE | Genève || B332 | NCLI | B332 || B332 | NOM | MONTI || ... | ... | ... |+--------+----------+-------------------+

+-------------+----------+--------+| Entite | Attribut | Valeur |+-------------+----------+--------+| 30178-CS464 | NCOM | 30178 || 30178-CS464 | NPRO | CS464 || 30178-CS464 | QCOM | 25 || 30179-CS262 | NCOM | 30179 || 30179-CS262 | NPRO | CS262 || 30179-CS262 | QCOM | 60 || 30179-PA60 | NCOM | 30179 || 30179-PA60 | NPRO | PA60 || 30179-PA60 | QCOM | 20 || ... | ... | ... |+-------------+----------+--------+

A10.9.2Expression des données sourcesLa reconstitution des données d’une table source est réalisée par une auto-jointuremultiple de la table attribut-valeur correspondantes (script A10.14).

create view V_CLIENT asselect M1.Valeur as NCLI, M2.Valeur as NOM, M3.Valeur as ADRESSE, M4.Valeur as LOCALITE, M5.Valeur as CAT, cast(M6.Valeur as real) as COMPTEfrom AV1_CLIENT as M1, AV1_CLIENT as M2, AV1_CLIENT as M3, AV1_CLIENT as M4, AV1_CLIENT as M5, AV1_CLIENT as M6where M2.Entite = M1.Entite and M3.Entite = M1.Entite and M4.Entite = M1.Entite and M5.Entite = M1.Entiteand M6.Entite = M1.Entiteand M1.Attribut = 'NCLI'and M2.Attribut = 'NOM'and M3.Attribut = 'ADRESSE'and M4.Attribut = 'LOCALITE'and M5.Attribut = 'CAT'and M6.Attribut = 'COMPTE';


Figure A10.14 - Expression des données de la table source CLIENT à partir de la table attribut-valeur (première technique)

Le processus de construction d’une table multicolonnes (CLIENT) à partir dedonnées désagrégées (AV1_CLIENT) n’est en réalité pas une nouveauté pour nous.La génération de tableaux étudiée à la section A8.1 de l’annexe A8 était un premierexemple de cette manipulation. Le script A10.14 est d’ailleurs très similaire auscript A8.3. Nous avions à cette occasion suggéré une autre technique de recompo-sition des données sources basée sur un groupement des données de même valeur dela colonne Pro, qu’on pourrait ici assimiler à la colonne Entite. Le script A10.15constitue cette seconde technique appliquée à la reconstruction de la table sourceCLIENT.

Figure A10.15 - Expression des données de la table source CLIENT à partir de la table attribut-valeur (seconde technique)

Ce modèle offre un avantage évident : la souplesse d’évolution des attributs desentités. Un utilisateur peut à tout instant ajouter un nouvel attribut à une entité sansqu’il soit nécessaire de modifier le schéma de la table dédiée au type de cette entité.Les entités d’un même type n’ont pas nécessairement les mêmes attributs.

Les scripts relatifs à ce modèle attribut-valeur sont disponibles sous la forme dufichier Attribut-valeur-v1.sql.

create view V_CLIENT asselect max(case when Attribut = 'NCLI' then Valeur end) as NCLI,max(case when Attribut = 'NOM' then Valeur end) as NOM,max(case when Attribut = 'ADRESSE' then Valeur end) as ADRESSE,max(case when Attribut = 'LOCALITE' then Valeur end) as LOCALITE,max(case when Attribut = 'CAT' then Valeur end) as CAT,max(case when Attribut = 'COMPTE' then cast(Valeur as real) else -999999.9 end) as COMPTEfrom AV1_CLIENTgroup by Entite;


© J-

L H

aina

ut -

2015

A10.10LE MODÈLE ATTRIBUT-VALEUR - VERSION 2

Dans ce modèle, on élimine complètement la notion de schéma explicite, non seule-ment pour ce qui concerne les colonnes comme dans version 1, mais aussi la notionde table, qui regroupe les lignes des entités de même type. Ici, tous les triplets(Entité,Attribut,Valeur), quel soit le type de l’entité qu’ils représentent, sont rangésdans l’unique table CLICOM de la base de données.

Le type de l’entité concernée par un triplet sera indiqué par une colonne supplé-mentaire dénommée TypeE. Les triplets deviennent donc ... des quadruplets. Lescript A10.16 définit la table CLICOM.

Figure A10.16 - Création de la table CLICOM

Ci-dessous des extraits des tables AV1_CLIENT et AV1_DETAIL.

create table CLICOM( TypeE varchar(32) not null, Entite varchar(32) not null, Attribut varchar(32) not null, Valeur varchar(256), primary key (Type,Entite,Attribut));


+----------+-------------+----------+-------------------+| TypeE | Entite | Attribut | Valeur |+----------+-------------+----------+-------------------+| CLIENT | B062 | ADRESSE | 72, r. de la Gare || CLIENT | B062 | CAT | B2 || CLIENT | B062 | COMPTE | -3200 || CLIENT | B062 | LOCALITE | Namur || CLIENT | B062 | NCLI | B062 || CLIENT | B062 | NOM | GOFFIN || CLIENT | B112 | ADRESSE | 23, r. Dumont || CLIENT | B112 | CAT | C1 || CLIENT | B112 | COMPTE | 1250 || CLIENT | B112 | LOCALITE | Poitiers || CLIENT | B112 | NCLI | B112 || CLIENT | B112 | NOM | HANSENNE || CLIENT | B332 | ADRESSE | 112, r. Neuve || CLIENT | B332 | CAT | B2 || CLIENT | B332 | COMPTE | 0 || CLIENT | B332 | LOCALITE | Genève || CLIENT | B332 | NCLI | B332 || CLIENT | B332 | NOM | MONTI || ... | ... | ... | ... || DETAIL | 30178-CS464 | NCOM | 30178 || DETAIL | 30178-CS464 | NPRO | CS464 || DETAIL | 30178-CS464 | QCOM | 25 || DETAIL | 30179-CS262 | NCOM | 30179 || DETAIL | 30179-CS262 | NPRO | CS262 || DETAIL | 30179-CS262 | QCOM | 60 || DETAIL | 30179-PA60 | NCOM | 30179 || DETAIL | 30179-PA60 | NPRO | PA60 || DETAIL | 30179-PA60 | QCOM | 20 || ... | ... | ... | ... |+----------+-------------+----------+-------------------+

La migration des données des tables sources vers la table CLICOM s’effectue via unscript très semblable à celui de la version 1, auquel on ajoute les valeurs de lacolonne TypeE. Il en est de même de la reconstitution des données sources à partir dela table CLICOM.

Dans cette version, la prise en compte d’entités d’un nouveau type ne nécessite plusla création d’une nouvelle table mais simplement d’une nouvelle valeur de TypeE.

Les scripts relatifs à la version 2 du modèle attribut-valeur sont disponibles sous laforme du fichier Attribut-valeur-v2.sql.


© J-

L H

aina

ut -

2015

A10.11LE MODÈLE ATTRIBUT-VALEUR - VERSION 3

Cette troisième version du modèle attribut-valeur reprend l’idée de la deuxièmeversion mais exprime de manière différente l’information sur le type des entités. Cetype n’y est plus représenté d’une manière spéciale par la colonne TypeE, maiscomme un simple attribut de l’entité. On assigne donc à chaque entité un nouvelattribut de nom TypeE dont la valeur (Valeur) indique le type. Comme les identi-fiants primaires n’identifient pas les entités indépendamment de leur type (on peutimaginer un client et un produit possédant la même valeur de leur identifiant), nousdevrions compléter les valeurs de la colonne Entite en les préfixant d’un code uniquepour ce type (par exemple CLIENT_C400 ou CLI_C400 pour l’entité client C400.

Nous allons cependant procéder autrement, en utilisant un identifiant techniquede type integer dont nous génèrerons nous-mêmes les valeurs. C’est ce quetraduit le script A10.17. Le script A10.18 charge dans cette table les données de latable source CLIENT. De manière à attribuer à l’identifiant primaire des entiersconsécutifs, chaque série de chargement initialise la variable entite à la dernièrevaleur enregistrée.

Figure A10.17 - Création de la table CLICOM

Figure A10.18 - Migration des données sources de la table CLIENT vers la table CLICOM

create table CLICOM( Entite integer not null, Attribut varchar(32) not null, Valeur varchar(256), primary key (Entite,Attribut));

extract entite = select coalesce(max(Entite),0) from CLICOM;

for cli,nom,adr,loc,cat,cpt = [select * from CLIENT]; compute entite = $entite$ + 1; function nom = LStr:SQLquote2 {$nom$}; function adr = LStr:SQLquote2 {$adr$}; function loc = LStr:SQLquote2 {$loc$}; insert into CLICOM values($entite$,'TypeE','CLIENT'); insert into CLICOM values($entite$,'NCLI','$cli$'); insert into CLICOM values($entite$,'NOM','$nom$'); insert into CLICOM values($entite$,'ADRESSE','$adr$'); insert into CLICOM values($entite$,'LOCALITE','$loc$'); insert into CLICOM values($entite$,'CAT', case when '$cat$' = '' then null else '$cat$' end); insert into CLICOM values($entite$,'COMPTE',$cpt$);endfor;


Ci-dessous un extrait de la table CLICOM comprenant toutes les données des tablessources :

+--------+----------+----------------------+| Entite | Attribut | Valeur |+--------+----------+----------------------+| 1 | TypeE | CLIENT || 1 | ADRESSE | 23, r. Dumont || 1 | CAT | C1 || 1 | COMPTE | 1250 || 1 | LOCALITE | Poitiers || 1 | NCLI | B112 || 1 | NOM | HANSENNE || 2 | TypeE | CLIENT || 2 | ADRESSE | 25, r. Lemaître || 2 | CAT | C1 || 2 | COMPTE | -2300 || 2 | LOCALITE | Namur || 2 | NCLI | C123 || 2 | NOM | MERCIER || 3 | TypeE | CLIENT || 3 | ADRESSE | 112, r. Neuve || 3 | CAT | B2 || 3 | COMPTE | 0 || 3 | LOCALITE | Genève || 3 | NCLI | B332 || 3 | NOM | MONTI || ... | ... | ... || 31 | TypeE | DETAIL || 31 | NCOM | 30178 || 31 | NPRO | CS464 || 31 | QCOM | 25 || 32 | TypeE | DETAIL || 32 | NCOM | 30179 || 32 | NPRO | PA60 || 32 | QCOM | 20 || 33 | TypeE | DETAIL || 33 | NCOM | 30179 || 33 | NPRO | CS262 || 33 | QCOM | 60 || ... | ... | ... |+--------+----------+----------------------+

La reconstruction de la table source CLIENT est réalisée par le script A10.19.


© J-

L H

aina

ut -

2015

Figure A10.19 - Reconstruction de la table source CLIENT à partir de la table CLICOM

create view V_CLIENT asselect max(case when Attribut = 'NCLI' then Valeur end) as NCLI,max(case when Attribut = 'NOM' then Valeur end) as NOM,max(case when Attribut = 'ADRESSE' then Valeur end) as ADRESSE,max(case when Attribut = 'LOCALITE' then Valeur end) as LOCALITE,max(case when Attribut = 'CAT' then Valeur end) as CAT,max(case when Attribut = 'COMPTE' then cast(Valeur as real) else -999999.9 end) as COMPTEfrom CLICOMwhere Entite in (select Entite from CLICOM where Attribut = 'TypeE' and Valeur = 'CLIENT')group by Entite;


A10.12LE MODÈLE DE GRAPHE

Les modèles de graphes représentent les données sous la forme d’un graphe, c’est-à-dire d’un ensemble de noeuds et d’un ensemble d’arcs entre ces noeuds, un arcreprésentant une association entre deux noeuds. On assigne généralement un type àchaque noeud et à chaque arc, mais aussi, selon les besoins, d’autres attributs.

La base de données CLICOM.db se prête assez bien à une représentation sous laforme d’un graphe. Chaque entité constitue un noeud, chaque référence via une cléétrangère constitue un arc et chaque colonne un attribut des noeuds. Les clés étran-gères disparaissent puisqu’elles sont désormais traduites par des arcs. Le problèmedes clés étrangères composites ne se pose donc plus.

De manière à conserver la souplesse d’évolution des modèles attribut-valeurs,nous organiserons les données selon trois tables :

– la table ENTITE, qui reprend l’ensemble des entités avec leur type (les noeuds)– la table ATTRIBUT, qui associe à chaque entité ses attributs,– la table ASSOCIATION, qui définit les couples d’entités et leur type.

La notion d’attribut d’association n’est pas reprise ici car elle n’est pas pertinentedans le modèle source. Le script A10.20 crée les tables du modèle de graphes.

Figure A10.20 - Création des tables du modèle de graphes

Le chargement de la table ASSOCIATION nécessitera une correspondance entrel’identifiant primaire des tables sources et l’identifiant technique d’entité créé lorsdu chargement des données de la table ENTITE. Cette correspondance sera stockéedans la table temporaire IDENTITE, à supprimer après usage (script A10.21).

create table ENTITE( Entite integer not null primary key, TypeE varchar(32) not null);

create table ASSOCIATION( Source integer not null, Cible integer not null, TypeA varchar(32) not null, primary key (TypeA,Source,Cible));

create table ATTRIBUT( Entite integer not null, Attribut varchar(32) not null, Valeur varchar(256), primary key (Entite,Attribut));

A10.12 Le modèle de graphe 31

© J-

L H

aina

ut -

2015

Figure A10.21 - Table de correspondance entre les identifiants relationnels et les identifiants d’entités

La conversion des tables en graphes est assez semblable à celle du modèle attribut-valeur, dont elle s’inspire (script A10.22). Elle présente trois diffférences :

– insertion d’une ligne dans la table ENTITE, représentant un nouveau noeud dugraphe,

– insertion dans la table de correspondance IDENTITE du couple des identifiants,– absence de traduction des clés étrangères

Figure A10.22 - Chargement des entités de la table COMMANDE

La création des associations ne peut s’effectuer que lorsque tous les noeuds ont étécréés. Le script A10.23 crée les associations entre chaque entité DETAIL et les entitésCOMMANDE et PRODUIT dont elle dépend. Les jointures permettent de retrouver,pour chaque entité DETAIL, son identifiant, celui de l’entité COMMANDE associée etcelui de l’entité PRODUIT associée.

Figure A10.23 - Création des deux associations entre une entité DETAIL et ses entités COMMANDE et PRODUIT

create temporary table IDENTITE( Entite integer not null, TypeE varchar(32) not null, EID varchar(32), primary key (TypeE,EID), unique(Entite) );

for com,cli,dat = [select * from COMMANDE]; compute entite = $entite$ + 1;

insert into ENTITE values($entite$,'COMMANDE'); insert into IDENTITE values($entite$,'COMMANDE','$com$');

insert into ATTRIBUT values($entite$,'NCOM','$com$'); insert into ATTRIBUT values($entite$,'DATECOM','$dat$');endfor;

for det,com,pro = [select DI.Entite,CI.Entite,PI.Entite from DETAIL D,IDENTITE DI,IDENTITE CI,IDENTITE PI where D.NCOM||'-'||D.NPRO = DI.EID and DI.TypeE = 'DETAIL' and D.NCOM = CI.EID and CI.TypeE = 'COMMANDE' and D.NPRO = PI.EID and PI.TypeE = 'PRODUIT'];

insert into ASSOCIATION values($det$,$com$,'DETAIL(NCOM)'); insert into ASSOCIATION values($det$,$pro$,'DETAIL(NPRO)');endfor;


Remarquons qu’on peut envisager une autre conversion sous la forme de graphedans lequel chaque entité, mais aussi chaque valeur de colonne, constitue un noeud.Il existe alors deux sortes d’arcs : les arcs entre deux entités et les arcs entre uneentité et une valeur d’attribut, ces derniers arcs portant le nom de l’attribut dont ilsdérivent. Cette modélisation nous amène alors à celle des ontoilogies, telles queRDF et OWL

A10.13 Les modèles d’ontologies 33

© J-

L H

aina

ut -

2015

A10.13LES MODÈLES D’ONTOLOGIES

<à rédiger>


A10.14LE MODÈLE ORIENTÉ DOCUMENT SIMPLE

<à rédiger>

A10.15 Le modèle orienté Document complexe 35

© J-

L H

aina

ut -

2015

A10.15LE MODÈLE ORIENTÉ DOCUMENT COMPLEXE

<à rédiger>


A10.16INDEXATION DE DOCUMENTS COMPLEXES

<à rédiger>

A10.17 La notation CSV 37

© J-

L H

aina

ut -

2015

A10.17LA NOTATION CSV

CSV (comma-separated values ou valeurs séparées par des virgules) est un formattextuel de représentation de données. Un fichier au format CSV est une suite delignes, chacune représentant un enregistrement. Chaque enregistrement est constituéd’une ou plusieurs valeurs, séparées par un symbole séparateur, généralement unevirgule, d’où le nom du format.

Le format cvs est à l’origine (1972) destiné à représenter de manière lisible pardes humains des tableaux de données. Il a ensuite été utilisé pour sauver, charger etéchanger les données d’une feuille de calcul (1983). Étant donné sa simplicité, il arapidement été adopté comme format standard de transfert de données, en particu-lier entre logiciels de natures différentes. Il n’existe cependant pas de standard csvunique. Des variantes existent concernant le séparateur (virgule, point-virgule,espace, tabulation, etc), la représentation des valeurs absentes, la préservation deszéros en début de nombre, la préservation des espaces précédant et suivant unevaleur ou le(s) caractère(s) de fin de ligne.

Règles principales:– Une valeur peut être entourée de guillemets (", dit double-quote, code ASCII

hex22). Ceux-ci ne font pas partie de la valeur.– Les espaces précédant ou suivant une valeur font partir intégrante de la valeur. – Si une valeur contient un séparateur, elle doit être entourée de guillemets. – Si une valeur contient un guillemet, celui-ci doit être doublé et la valeur doit

être entourée de guillemets.– Si une valeur contient des caractères de fin de ligne elle doit être entourée de

guillemets.– Les enregistrements de données peuvent être précédés d’une ligne spécifiant le

nom des champs.

ExemplesNCLI,NOM,ADRESSE,LOCALITE,CAT,COMPTEB112,HANSENNE,"23, r. Dumont","Poitiers",C1,1250C123,MERCIER,"25, r. Lemaître","Namur",C1,-2300B332,MONTI,"112, r. Neuve","Genève",B2,0F010,TOUSSAINT,"5, r. Godefroid","Poitiers",C1,0K111,VANBIST,"180, r. Florimont","Lille",B1,720S127,VANDERKA,"3, av. des Roses","Namur",C1,-4580B512,GILLET,"14, r. de l'Eté","Toulouse",B1,-8700B062,GOFFIN,"72, r. de la Gare","Namur",B2,-3200C400,FERARD,"65, r. du Tertre","Poitiers",B2,350C003,AVRON,"8, ch. de la Cure","Toulouse",B1,-1700K729,NEUMAN,"40, r. Bransart","Toulouse",,0F011,PONCELET,"17, Clôs des Erables","Toulouse",B2,0L422,FRANCK,"60, r. de Wépion","Namur",C1,0S712,GUILLAUME,"14a, ch. des Roses","Paris",B1,0D063,MERCIER,"201, bvd du Nord","Toulouse",,-2250F400,JACOB,"78, ch. du Moulin","Bruxelles",C2,0


Références– https://en.wikipedia.org/wiki/Comma-separated_values (version française trop

sommaire)– https://tools.ietf.org/html/rfc4180– https://www.w3.org/TR/tabular-data-model/

Note relative à la gestion du format CSV dans SQLfastLe format CSV est défini par trois variables systèmes :

– csv-separator : symbole séparateur; par défaut la virgule. Utilisée en export etimport.

– csv-header : présence (1) ou absence (0) d’un enregistrement définissant lenom des champs; par défaut 0. Utilisée en export et import.

– csv-maxerrornbr : nombre maximum d’erreurs tolérées lors du chargement d’unfichier CSV par l’instruction import; par défaut 10. Utilisée en import unique-ment.

Les valeurs de ces variables peuvent être modifiées statiquement dans le fichierd’initialisation SQLfast.ini et dynamiquement dans les scripts.

L’export de données s’effectue via la requête SQL select, dont le résultat estredirigé vers un fichier de texte et dont les paramètres de mise en forme sont spéci-fiés par l’exécution du script UTIL-SELECT-parameters-for-CSV.sql.

L’import de données est effectué par l’instruction import, qui spécifie le nomd’une table (pré-existante ou à créer) et celui d’un fichier d’extension *.csv :

import PRODUIT from Produits-2019.csv;

Cette fonction gère les erreurs présentes dans le fichier, en particulier les valeursmanquantes ou en excès.

A10.18 La notation JSON 39

© J-

L H

aina

ut -

2015

A10.18LA NOTATION JSON

Le format JSON (JavaScript Object Notation) est une syntaxe qui permet de séria-liser d’objets de structure quelconque, c’est-à-dire de les transformer, de manièreréversible, en une chaîne de caractères. Cette chaîne peut ainsi être stockée dans unfichier ou échangée avec des logiciels de natures variées.

Le code JSON d’un objet représente sa structure statique arborescente, la déno-mination de ses composants ainsi que les valeurs de ses composants atomiques (lesfeuilles de l’arborescence). Les règles de composition sont simples :

– Un objet est constitué d’un ensemble de membres, chaque membre étant repré-senté par un couple "nom":valeur. Cet ensemble est entouré d’accolades.

– Un tableau est une suite de valeurs séparées par des virgules. Cet ensemble estentouré de crochets.

– Une valeur est une chaîne de caractères UNICODE (entourée de guillemets), unnombre, un objet, un tableau ou un littéral (true, false, null)

Exemple{"Table":"CLIENT", "Lignes":[{"NCLI":"B112","NOM":"HANSENNE", "ADRESSE":"23, r. Dumont","LOCALITE":"Poitiers", "CAT":"C1","COMPTE":1250}, ... {"NCLI":"K729","NOM":"NEUMAN", "ADRESSE":"40, r. Bransart","LOCALITE":"Toulouse", "CAT":null,"COMPTE":0} ... ]}

Cet exemple est la traduction en JSON de la table CLIENT de notre base de donnéesde référence CLICOM.db. L’objet global est composé de deux membres donnantrespectivement le nom de la table et son contenu. Ce contenu est traduit en untableau nommé Lignes. Chaque valeur du tableau est un objet représentant une lignede la table, dont les membres représentent les valeurs de cette ligne. On notera lamanière dont les chaînes de caractères, les nombres et la valeur null sont repré-senté(e)s. Dans une chaîne de caractères, les caractères spéciaux (guillemet, \, /,backspace, tab, newline, carriage return, etc) doivent être précédés du symbole \.

La syntaxe du format JSON s’inspire de la notation d’objet utilisée par Javascriptmais en est indépendante. Par sa puissance d’expression, sa simplicité et sa lisibilité,le format JSON est largement utilisé, tant pour la transmission de données entrelogiciels indépendants que pour la représentation d’objets complexes. Cette dernièrefonction fait partie intégrante de la plupart des SGBD et plus particulièrement desSGBD dits NoSQL.

Note relative à la gestion du format JSON dans SQLfastSQLfast n’offre pas de fonctions spécifiques de gestion du format JSON. Cepen-dant, les colonnes dynamiques (créées par les instructions insert et update et non


par create table ou alter table) sont implémentées sous la forme d’objetsJSON. Ceux-ci sont manipulés par quatre fonctions qui peuvent être également utili-sées pour traiter explicitement des formats JSON :

– setDCol(C,N,V) : introduit (ou remplace) le membre "N":"V" dans l’objetJSON C.

– getDCol(C,N) : retourne la valeur du membre de nom N dans l’objet C.Retourne null si ce membre n’existe pas.

– getDColNames(C,sep) : retourne la liste des noms des membres de l’objetC. Les noms de la liste sont séparés par le symbole sep.

– group_DColNames(C,sep) : fonction agrégative qui retourne l’union deslistes des noms des membres de l’expression C (qui est un objet JSON) danstoutes les lignes du résultat de la requête.. Les noms de la liste sont séparés parle symbole sep (fonction SQL uniquement).

Référencehttps://www.json.org/json-fr.htmlhttps://fr.wikipedia.org/wiki/JavaScript_Object_Notation

A10.19 La boite à outils BLOCKCHAIN 41

© J-

L H

aina

ut -

2015

A10.19LA BOITE À OUTILS BLOCKCHAIN

Les programmes qui permettent le fonctionnement d’une chaîne de blocs constituentun système distribué complexe. Il ne serait pas réaliste d’en proposer ici une versionsous forme d’une application complète. Considérant l’objectif didactique de cetouvrage, nous développerons plutôt une suite de fonctions indépendantes s’articu-lant sur une base de données représentant une chaîne de blocs élémentaire maisreprésentative.

L’application choisie est celle d’une cryptomonnaie s’inspirant du bitcoin. Ellecomporte les fonctions d’ouverture d’un compte, de dépôt d’une somme et detransfert d’une somme d’un compte source vers un compte destinataire. S’y ajou-tent une fonction de validation d’une transaction et la création d’un bloc, y comprisson minage. Enfin, on disposera également de fonction de visualisation des donnéesà différents degrés de granularité.

La fonction de minage sera disponible, mais nous ignorerons les aspects de distri-bution (réplication des données chez chaque membre du réseau notamment), derétribution (rémunération des mineurs) et de compétition (le premier mineur"emporte la mise"). De même, les transactions de transfert entre comptes sont limi-tées à un seul compte destinataire (par d’ouputs multiples).

Toutes les fonctions seront développées dans le langage et dans l’environnementde SQLfast, à l’exception des primitives cryptographiques, qui, pour des raisons deperformance, ont été rédigées en Python.6

A10.19.1La base de données BLOCKCHAIN.dbLes principales structures de données comprennent trois tables, contenant les infor-mations sur les transactions, les blocs et le répertoire des clés publiques.

a) Les transactionsOn retiendra trois types de transactions : ouverture d’un compte, dépôt d’un montantsur un compte et transfert d’un montant d’un compte source vers un compte destina-teire.

Considérons l’exemple d’une opération de transfert d’un montant de 100 ducompte de Marie vers le compte de Luc. La figure A10.24 montre la manière dontnous allons coder ces informations. On y indique le type d’opération, le comptesource, le compte destinataire, le montant, la date d’enregistrement de l’opération etenfin la signature de la transaction. Pour des raisons de confidentialité, les comptesde Marie et Luc sont identifiés anonymement par leur identifiant réseau, aussiappelée adresse réseau (une chaîne de 256 bits, ici représentée sous la forme d’unechaîne de caractères en base64). La signature, qui sera calculée à l’aide la clésecrète du propriétaire du compte source (ici Marie), est également représentée parune (longue) chaîne de caractères en base64. On décide que les transactions d’un

6. Comme extension de la bibliothèque LStr. Cette extension utilise les modules hashlib, base64et ras.


même compte source doivent recevoir des dates distinctes, la date est par consé-quent détaillée jusqu’à la milliseconde.

À ces données de base, nous ajouterons la référence du bloc dans lequel la tran-saction sera insérée ainsi qu’un identifiant de transaction. Pour assurer l’unicité decet identifiant au travers du réseau, nous le constituerons de l’identifiant du comptesource auquel on ajoute la date d’enregistrement

Enfin, de manière à faciliter l’expérimentation, les transactions seront dotéesd’un identifiant numérique court, appelé clé de transaction, qui sera attribué auto-matiquement. Cet identifiant ne fait évidemment pas partie de la modélisation de lachaîne de bloc.

Ces composants sont traduits sous la forme de la table BTRANSACTION7 dont leschéma est présenté dans le script de la figure A10.25.

Figure A10.24 - Exemple de données d’une transaction de transfert; seule une partie de la signature est représentée.

Figure A10.25 - Schema de la table des transactions

b) Les blocsUn bloc est créé par un mineur, dès qu’il a reçu un nombre suffisant de transactionscandidates. Fondamentalement, un bloc est constitué d’un identifiant de bloc, d’unesuite de transactions, de l’identifiant du bloc précédent et de sa date de création.

L’identifiant du bloc est obtenu par hachage de son contenu auquel on ajoute unnonce, chaîne de caractères numériques telle que le hachage de la concaténation dece contenu et du nonce produit une chaîne binaire dont les k premiers bits sont à

7. On se souviendra que le terme TRANSACTION est réservé en SQL.

create table BTRANSACTION( CleTrans integer not null primary key autoincrement, IDTrans varchar(72) not null unique, IDBloc varchar(48) references BLOC(IDBloc), Operation char(12) not null, Source varchar(48), Destin varchar(48), Montant decimal(16,10), DateEnreg datetime not null, Signature varchar(512) not null);

Operation: TRANSFERSource: FT7UzFgSpMmNsnlet_ooAKV4wWTyJAaLrnYH6TRtIBw=Destin: QWA7QEjrvrsg1lpALJi34f8Ksrzb0ANfa5tqsylm7Xw=Montant:100DateEnreg: 2019-05-23 15:58:32.113Signature: C75d4HLpm9STKHj[..]h-blt2uCmMM_mfK

Operation: TRANSFERSource: FT7UzFgSpMmNsnlet_ooAKV4wWTyJAaLrnYH6TRtIBw=Destin: QWA7QEjrvrsg1lpALJi34f8Ksrzb0ANfa5tqsylm7Xw=Montant:100DateEnreg: 2019-05-23 15:58:32.113Signature: C75d4HLpm9STKHj[..]h-blt2uCmMM_mfK


© J-

L H

aina

ut -

2015

zéro.8 Cette chaîne sera traduite dans notre boite à outil en base64. La détection dece nonce, particulièrement consommatrice de temps de calcul, constitue la preuve detravail.

Les transactions ne sont pas intégrées au bloc mais lui sont associées via la cléétrangère IDBloc de la table BTRANSACTION. On indiquera simplement le nombrede transaction associées au bloc (colonne Transact).

Un bloc qu’on vient de créer est soumis à la communauté des membres du réseau.à ce stade, il n’est qu’un projet qui doit encore être validé et sélectionné comme lebloc officiel. On caractérise les blocs par leur statut, qui indique leur état devalidation.

Tout comme nous l’avons fait pour les transactions, toujours pour faciliter l’expé-rimentation, nous associerons aux blocs un identifiant numérique, appelé clé debloc.

La traduction en structure de table est illustrée à la figure A10.26.

Figure A10.26 - Schéma de la table des blocs

c) Le répertoire des clés publiquesPour transférer un montant vers un compte destinataire, nous sommes supposésconnaître son identifiant réseau, tout comme pour effectuer un virement bancaire,nous devons connaître le numéro du compte destinataire. Pour valider une transac-tion nous devons déchiffrer sa signature pour vérifier que celle-ci correspond bienaux valeurs des différents champs de cette transaction. Ce déchiffrement est effectuépar la clé publique du créateur de la transaction, qui est le compte source de celle-cidans le cas d’un transfert.

On doit donc disposer d’un répertoire qui, à chaque identifiant d’un compte,associe sa clé publique. Ce répertoire est stocké dans la table REPERTOIRE dont leschéma est représenté à la figure A10.27. On lui a ajouté une colonne indiquant si lepropriétaire du compte est ou non un mineur.

8. Dans la version standard du prototype, k = 20, ce qui conduit à un temps de minage de 5 à 30secondes. Le nombre d’essai est limité à 5 000 000.

create table BLOC( CleBloc integer not null primary key autoincrement, IDBloc varchar(48) not null unique, Transact integer not null, Nonce varchar(32), DateEnreg datetime not null, Statut char(1) not null default 0, BlocPrec varchar(48) references BLOC(IDBloc));


Figure A10.27 - Schéma de la table des clés publiques

A10.19.2Les données d’expérimentation

Les données des tables BTRANSACTION, BLOC et REPERTOIRE sont publiques, etdonc accessibles à tous les membres du réseau de la chaîne de blocs.

À ces données, dites fonctionnelles, nous devons ajouter celles qui nous permet-tront de jouer avec les concepts des chaînes de blocs. Ces données, qui n’existentpas dans les implémentations réelles (nous les représenterons d’ailleurs en rougedans les schémas de tables), nous permettront d’effectuer expérimentalement, demanière simple et intuitive, les différentes opérations sur notre chaîne de blocs.Nous les appellerons données d’expérimentation.

Notons d’abord que les tables BTRANSACTION et BLOC comportent déjà desdonnées d’expérimentation sous la forme des clés de transaction (colonne CleTrans)et de bloc (colonne CleBloc).

Les données de l’ensemble des comptes avec lesquels nous allons jouer serontstockées dans une table COMPTE. Un compte possède une adresse réseau qui cons-titue un identifiant global au niveau du réseau (colonne AdresseCPT). Cet identifiantest généré par une fonction de hashage de qualité, soit, dans notre prototype, lafonction sha256. Codées en base64, les valeurs de cette adresse occupent 44 carac-tères d’apparence aléatoire et sont donc malaisées à mémoriser et à manipuler. Pourcette raison, nous associerons à chaque compte un pseudonyme facile à retenir, parexemple un nom de personne, que nous appellerons nom privé (colonne NomPrive).Nous pourrons ainsi décrire une opération de transfert de cette manière :

Marie transfère un montant de 100 vers le compte de Luc.de toute évidence plus naturelle que son équivalent réel :

un montant de 100 est transféré du compte FT7UzFgSpMmNsnlet_ooAKV4wWTyJAaLrnYH6TRtIBw=

vers le compte QWA7QEjrvrsg1lpALJi34f8Ksrzb0ANfa5tqsylm7Xw=.Lors de la création d’un compte, on génère un couple de clés permettant de produire(par la clé secrète) puis de déchiffrer (par la clé publique) la signature des transac-tions.9 Ces clés permettent l’utilisation des algorithmes de chiffrage/déchiffrageasymétrique RSA. Dans une implémentation réelle, le propriétaire d’un compte estle seul à connaître sa clé secrète, qu’il doit conserver et protéger avec le plus grandsoin. Dans ce prototype expérimental, nous jouerons tous les rôles : créateurs decomptes, sources, destinataires et mineurs. Nous devrons donc connaître les cléssecrètes de tous les membres du réseau de la chaîne de blocs !

create table REPERTOIRE( AdresseCPT varchar(48) not null unique, ClePublique varchar(1400) not null, Mineur integer not null default 0);


© J-

L H

aina

ut -

2015

Figure A10.28 - Schéma de la table des comptes

A10.19.3Ouverture d’un compte

L’ouverture d’un compte entraîne, d’une part, la création d’une paire de clés RSA(clé secrète et clé publique) permettant à son propriétaire d’effectuer des opérationssur ce compte et, d’autre part, la création d’une transaction qui officialise l’existencede ce nouveau compte. Plus précisément :

– La taille de la clé secrète doit être supérieure ou égale à celle des chaînesqu’elle doit chiffrer. Une clé de 1700 bits est suffisante pour chiffrer une tran-saction de transfert, la plus volumineuse des trois types. La longueur de la clésecrète ainsi générée, exprimée en base64, est de 300 caractères et celle de laclé publique est de l’ordre de 1330 caractères.10

– Le compte reçoit une adresse unique au travers du réseau de la chaîne; cetteadresse est obtenue par hachage de la clé publique.

– La clé secrète est confiée au propriétaire du compte, qui est chargé de la mémo-riser à sa meilleure convenance.

– La clé publique est stockée dans le répertoire, associée à l’adresse du compte.– Une transaction de type REGISTER est créée, composée notamment de

l’adresse du compte et de sa date de création. Elle est dotée d’un identifiantconstruit par la concaténation de l’adresse du compte et de la date de créationdu compte, précise à la milliseconde. Cette transaction inclut également unesignature, résultant du chiffrage de ses composants à l’aide de la clé secrète.

9. Il y a un conflit de dénomination lorsqu’on utilise les algorithmes RSA dans la gestion deschaînes de blocs. En chiffrement asymétrique conventionnel, tous les émetteurs de messagesadressés à un destinataire P chiffrent leurs messages à l’aide de la clé publique (accessible à tous)avant de les envoyer à P, lequel est le seul à pouvoir déchiffer ceux-ci à l’aide de sa clé privée. Laclé publique sert donc à tous pour chiffrer les messages que la clé privée permet à P de déchiffrer.Le scénario de chiffrement est inversé dans le cas des chaînes de blocs : le créateur d’une transac-tion P utilise sa clé secrète pour chiffrer cette transaction, que tous les membres du réseaupeuvent déchiffrer à l’aide de la clé publique. Lorsqu’on génère une paire de clés RSA pour gérerune chaîne de blocs, la clé publique sera appelée clé secrète et la clé privée sera appelée clépublique !

create table COMPTE( AdresseCPT varchar(48) not null primary key, NomPrive varchar(48) not null, CleSecrete varchar(360) not null unique, DateEnreg datetime not null);

10. Nous utiliserons un algorithme qui génère une clé secrète d’une taille légèrement inférieure àcelle demandée, mais dans un temps raisonnable (de 10 à 40 secondes). La génération d’une cléde la taille exacte demandée est beaucoup plus lente.


Dans la table COMPTE, nous enregistrerons l’adresse du compte, le nom privé quel’expérimenteur lui associera, la clé secrète et la date de création du compte.

L’opération d’ouverture d’un compte est codée dans le script_BC_Ouvrir_Compte.sql, dont l’essentiel est présenté dans la figure A10.29. Quel-ques explications techniques :

– Les clés RSA sont générées par la fonction generateRSAkeys de la bibliothèqueLStr. Le paramètre est le nombre de bits (suggéré) de la clé secrète.

– L’adresse du compte est obtenu par hachage de la clé publique par la fonctionhash de la même bibliothèque. Le second paramètre de la fonction spécifie leformat du résultat : hexadécimal (1) ou base64 (2).

– La date de création est constituée de la date proprement dite suivie du tempsactuel de la journée, informations obtenues par les fonctions date et time.

– L’identifiant de la transaction est l’adresse du compte concaténée à la date decréation.

– La signature de la transaction est obtenue par chiffrage à l’aide de la clé secrètede la chaîne formée de l’identifiant de la transaction, l’opération, l’adresse ducompte et la date de création du compte.

Figure A10.29 - Script de création d’un nouveau compte

A10.19.4Dépôt d’une somme

Pour simplifier, on admet que le montant déposé est issu d’une source qu’onconvient d’ignorer. Le propriétaire du compte est par conséquent le destinataired’un montant de source inconnue.

La fonction requiert l’identification d’un compte et le montant à verser sur cedernier. Pour des raisons d’ergonomie d’utilisation du prototype, le compte du desti-nataire est identifié par le nom privé de ce dernier.11

ask nom = Nom privé:;function cleS,cleP = LStr:generateRSAkeys 1700;function adr = LStr:hash {$cleP$},2;set dat = $date$ $time$;set id = $adr$-$date$_$time$;set op = REGISTER;

function sig = LStr:encryptRSA {$id$;$op$;$adr$;$dat$},{$cleS$};

insert into COMPTE (AdresseCPT,NomPrive,CleSecrete,DateEnreg) values ('$adr$','§nom§','$cleS$','$dat$');insert into REPERTOIRE (AdresseCPT,ClePublique) values ('$adr$','$cleP$');insert into BTRANSACTION (IDTrans,Operation,Source,DateEnreg,Signature) values ('$id$','$op$','$adr$','$dat$','$sig$');


© J-

L H

aina

ut -

2015

La logique de la fonction est similaire à celle de l’ouverture d’un compte, à ladifférence que la valeur de la clé secrète n’est pas calculée mais est extraite de latable COMPTE.

L’essentiel de la fonction de dépôt est présenté à la figure A10.30. À titred’exemple, la figure A10.31 représente le contenu d’une transaction de dépôt.

Figure A10.30 - Script d’exécution d’un dépôt

Figure A10.31 - Composition d’une ligne de BTRANSACTION décrivant une opéra-tion de dépôt : une somme de 60 est déposée sur le compte de Marie (signature de

284 caractères partiellement représentée)

11. Pour rappel, la fonction ask, lorsqu’elle propose à l’utilisateur de sélectionner une valeurdans une liste prédéfinie, peut renvoyer une valeur extraite d’une liste parallèle. Dans la formeask vb = a:[select A,B from T], lorsque l’utilisateur sélectionne une valeur de A, l’instruc-tion renvoie la valeur de B associée. Dans l’instruction ask du script A10.30, l’utilisateursélectionne un nom privé (colonne NomPrive) mais la valeur stockée dans la variabke cpt estl’adresse du compte (colonne AdresseCPT), qui permettra d’obtenir la clé secrète dans la tableCOMPTE.

ask cpt,mont = Votre nom:[!select NomPrive,AdresseCPT from COMPTE order by NomPrive] |Montant:;extract cleS = select CleSecrete from COMPTE where AdresseCPT = '$cpt$';set dat = $date$ $time$;set id = $cpt$-$date$_$time$;set op = DEPOSIT;function sig = LStr:encryptRSA {$id$;$op$;$cpt$;$mont$;$dat$},{$cleS$};insert into BTRANSACTION (IDTrans,Operation,Destin,Montant,DateEnreg,Signature)values ('$id$','$op$','$cpt$',$mont$,'$dat$','$sig$');

CleTrans 3

IDTrans Vmt2ONz5fHZb8JbpKyzenDLqlLH0pxbxTPeN42Pe2U8=-2018-11-21 09:32:17.028

Operation DEPOSIT

Source --

Destin Vmt2ONz5fHZb8JbpKyzenDLqlLH0pxbxTPeN42Pe2U8=

Montant 150

DateEnreg 2018-11-21 09:32:17.028

Signature Bp8tBqgkTgxdyig[..]PmWAK8q9ngBMKWf


A10.19.5Transfert d’une somme

L’utilisateur doit préciser le compte source, le compte destinataire et le montant àtransférer entre ces comptes. Les comptes sont désignés par l’utilisateur via leursnoms privés, que la fonction ask convertit en adresses du réseau de la chaîne, stoc-kées respectivement dans les variables moi (compte source) et lui (compte destina-taire).

La partie la plus intéressante de la fonction est la validation du montant à trans-férer, qui ne peut dépasser le solde du compte source. Ce solde est obtenu par uneprocédure générale qui consiste à calculer la somme des dépôts sur ce compte, àlaquelle on ajoute la somme des transferts dont ce compte est le destinataire, puis onen retire la somme des transferts dont ce compte est la source. Cette procédure sedistingue de celle du protocole Bitcoin en ce qu’elle traite la totalité de l’historiquedu compte source depuis son ouverture. Cette approche particulièrement simplepourrait sembler inefficace. Elle conviendra cependant dans la mesure où :

– L’historique du compte source comporte un nombre raisonnable de transac-tions (quelques milliers par exemple).

– Des index ont été créés respectivement sur les colonnes Source et Destin.– Une durée d’exécution d’une opération de transfert de quelques secondes est

jugée acceptable de la part de l’utilisateur.Il est possible de confier ce calcul à une unique requête SQL. Cependant, la procé-dure détaillée du script A10.33 nous a semblé plus claire.

À titre d’exemple, la figure A10.32 représente le contenu d’une transaction detransfert.

Figure A10.32 - Composition d’une ligne de BTRANSACTION décrivant une opéra-tion de transfert : Marie transfère une somme de 18.5 sur le compte de Luc)

A10.19.6Validation d’une transaction

Cette fonction vérifie que les comptes impliqués dans la transaction sont enregistrésdans la table REPERTOIRE, que le montant de la transaction de transfert est légi-times (inférieur ou égal au solde disponible à la date de création de la transaction) etque les valeurs des composants sont identiques au contenu, déchiffré via la clépublique, de la signature.

CleTrans 15

IDTrans Vmt2ONz5fHZb8JbpKyzenDLqlLH0pxbxTPeN42Pe2U8=-2018-11-27_15:58:32.113

Operation TRANSFER

Source Vmt2ONz5fHZb8JbpKyzenDLqlLH0pxbxTPeN42Pe2U8=

Destin 3YBeQfu12uhOxztWBJ0tIUrNC5L0bhJKMLIUDKTt-Sk=

Montant 18.5

DateEnreg 2018-11-27 15:58:32.113

Signature C75d4HLpm9STKHj[..]h-blt2uCmMM_mfK


© J-

L H

aina

ut -

2015

Figure A10.33 - Script d’exécution d’un transfert

A10.19.7Création et minage d’un blockCette fonction crée un bloc contenant toutes les transactions encore en attente etcalcule son nonce en fonction de la longueur de la chaîne binaire à zéro. La valeur dehash ainsi obtenue constitue l’identifiant du bloc. On ajoute également à ce dernierl’identifiant du dernier bloc créé, augmentant ainsi la chaîne de blocs d’une unité.

Ci-dessous, le contenu des lignes de la table BLOC représentant deux blocssuccessifs de la chaîne. Nous verrons ci-après la manière de visualiser les transac-tions de chaque bloc.

Bloc n° 114

ask moi,lui,mont = Votre nom:[!select NomPrive,AdresseCPT from COMPTE order by NomPrive] |Destinataire:[!select NomPrive,AdresseCPT from COMPTE order by NomPrive] |Montant:;

extract cleS = select CleSecrete from COMPTE where AdresseCPT = '$moi$';set dat = $date$ $time$;set idT = $moi$-$date$_$time$;set op = TRANSFER;

function sig = LStr:encryptRSA {$idT$;$op$;$moi$;$lui$;$mont$;$dat$},{$cleS$};

extract plusD = select coalesce(sum(Montant),0) from BTRANSACTION where operation = 'DEPOSIT' and Destin = '$moi$';extract plusT = select coalesce(sum(Montant),0) from BTRANSACTION where operation = 'TRANSFER' and Destin = '$moi$';extract minus = select coalesce(sum(Montant),0) from BTRANSACTION where operation = 'TRANSFER' and Source = '$moi$';compute balance = $plusD$ + $plusT$ - $minus$;

if ($balance$ < $mont$); showMessage Solde insuffisant.@nOperation annulée.; goto END;endif;

insert into BTRANSACTION (IDTrans,Operation,Source,Destin,Montant,DateEnreg,Signature)values ('$id$','$op$','$moi$','$lui$',$mont$,'$dat$','$sig$');


Bloc hash: AAAEqRd-Zq2PtROoXNLidrG_lYAVT5XnfkKsToEGy1w= Nbre transact: 8 Nonce: 1526497 Date création: 2018-12-02 15:41:56.402 Statut: 0 Hash precédent: DAAKayF8dzDLswTa5rb_V9nP_Gp536vaZDPuInYCIcM=

Bloc n° 113 Bloc hash: DAAKayF8dzDLswTa5rb_V9nP_Gp536vaZDPuInYCIcM= Nbre transact: 10 Nonce: 967544 Date création: 2018-11-29 12:15:25.226 Statut: 0 Hash precédent: B4AIQ7I-HfRKPSCbFK4OKoJ3vkUdLrC-UXC2GVAtECU=

A10.19.8Consultation d’un compte

L’utilisateur sélectionne un compte pour afficher la séquence des transactions qui leconcernent ainsi que le solde actuel de ce compte. Pour des raisons de lisibilité, lescomptes sont désignés par le nom privé de leur propriétaire. Le rapport ci-dessousest relatif au compte de Marie (les millisecondes des dates ont été supprimées).

Transactions de votre compte+--------+-----------+---------+---------+---------------------+--------+| Source | Operation | Montant | Destin | DateEnreg | InBloc |+--------+-----------+---------+---------+---------------------+--------+| Marie | REGISTER | -- | -- | 2018-11-29 10:02:21 | oui || -- | DEPOSIT | 100 | Marie | 2018-11-29 10:34:40 | oui || Marie | TRANSFER | 60 | Luc | 2019-01-16 09:59:08 | oui || -- | DEPOSIT | 20 | Marie | 2019-03-45 14:09:26 | oui || Anne | TRANSFER | 15 | Marie | 2019-04-23 11:11:10 | oui |+--------+-----------+---------+---------+---------------------+--------+

Solde de votre compte+--------+---------+-------+-------------+-------+| Compte | Dépôt | Reçu | Transféré | Solde |+--------+---------+-------+-------------+-------+| Marie | 120 | 15 | -60 | 75 |+--------+---------+-------+-------------+-------+

A10.19.9Visualisation des transactions de la chaîne

La fonction affiche la liste chronologique des transactions ainsi que le bilan dechaque compte. Les comptes sont désignés par le nom privé de leur propriétaire.

A10.19.10Visualisation de la chaîne de blocs

La fonction affiche le contenu de chaque bloc de la chaîne, ses propriétés et celles dechacune de ses transactions. Les comptes sont désignés par le nom privé de leurpropriétaire.


© J-

L H

aina

ut -

2015

A10.19.11Un scénario d’expérimentation

Afin d’observer le comportement d’une chaîne, on suggère d’effectuer les opéra-tions suivantes, dans cet ordre :

1. Marie ouvre un compte2. Marie dépose une somme de 100 sur son compte3. Luc ouvre un compte4. Marie transfère une somme 60 vers le compte de Luc5. Luc dépose une somme de 20 sur son compte6. Anne ouvre un compte7. Luc transfère une somme de 35 vers le compte de Anne 8. Luc transfère une somme de 15 vers le compte de Marie 9. Marie transfère une somme de 18 vers de compte de Anne10. Anne dépose une somme de 30 sur son compte11. Anne transfère une somme de 40 vers le compte de Luc12. Anne transfère une somme de 12 vers le compte de Marie

On suggère de constituer un bloc dès que 5 transactions ont été enregistrées. Lachaîne finale sera donc constituée de deux blocs et de deux transactions en attente.

Selon ce scénario, on obtient le contenu ci-dessous.

a) Visualisation des transactionsTransactions+--------+-----------+---------+--------+---------------------+--------+| Source | Operation | Montant | Destin | DateCreation | InBloc |+--------+-----------+---------+--------+---------------------+--------+| Marie | REGISTER | -- | -- | 2018-12-02 20:29:16 | oui || -- | DEPOSIT | 100 | Marie | 2018-12-02 20:29:25 | oui || Luc | REGISTER | -- | -- | 2018-12-02 20:29:38 | oui || Marie | TRANSFER | 60 | Luc | 2018-12-02 20:30:01 | oui || -- | DEPOSIT | 20 | Luc | 2018-12-02 20:30:13 | oui || Anne | REGISTER | -- | -- | 2018-12-02 20:31:29 | oui || Luc | TRANSFER | 35 | Anne | 2018-12-02 20:31:44 | oui || Luc | TRANSFER | 15 | Marie | 2018-12-02 20:32:02 | oui || Marie | TRANSFER | 18 | Anne | 2018-12-02 20:32:18 | oui || -- | DEPOSIT | 30 | Anne | 2018-12-02 20:32:31 | oui || Anne | TRANSFER | 40 | Luc | 2018-12-02 20:33:33 | -- || Anne | TRANSFER | 12 | Marie | 2018-12-02 20:33:50 | -- |+--------+-----------+---------+--------+---------------------+--------+

Solde des comptes+--------+---------+-------+-------------+-------+| Compte | Dépôt | Reçu | Transféré | Solde |+--------+---------+-------+-------------+-------+| Anne | 30 | 53 | -52 | 31 || Luc | 20 | 100 | -50 | 70 || Marie | 100 | 27 | -78 | 49 |+--------+---------+-------+-------------+-------+


b) Visualisation de la chaîne de blocsBloc n° 2 Bloc hash: AAAFlrfvAZQd7raf_sGqvZlhqYwIXQjgZfOsv0gCG5w= Nbre transact: 5 Nonce: 169540 Date création: 2018-12-02 20:32:37.710 Statut: 0 Hash precédent: AAADt822arP0Ut6IUr_FiADwwEHYYdIglWegKBJJ8aU= +--------+-----------+---------+--------+---------------------+ | Source | Operation | Montant | Destin | DateCreation | +--------+-----------+---------+--------+---------------------+ | Anne | REGISTER | -- | -- | 2018-12-02 20:31:29 | | Luc | TRANSFER | 35 | Anne | 2018-12-02 20:31:44 | | Luc | TRANSFER | 15 | Marie | 2018-12-02 20:32:02 | | Marie | TRANSFER | 18 | Anne | 2018-12-02 20:32:18 | | -- | DEPOSIT | 30 | Anne | 2018-12-02 20:32:31 | +--------+-----------+---------+--------+---------------------+

Bloc n° 1 Bloc hash: AAADt822arP0Ut6IUr_FiADwwEHYYdIglWegKBJJ8aU= Nbre transact: 5 Nonce: 1697839 Date création: 2018-12-02 20:30:19.119 Statut: 0 Hash precédent: -- +--------+-----------+---------+--------+---------------------+ | Source | Operation | Montant | Destin | DateCreation | +--------+-----------+---------+--------+---------------------+ | Marie | REGISTER | -- | -- | 2018-12-02 20:29:16 | | -- | DEPOSIT | 100 | Marie | 2018-12-02 20:29:25 | | Luc | REGISTER | -- | -- | 2018-12-02 20:29:38 | | Marie | TRANSFER | 60 | Luc | 2018-12-02 20:30:01 | | -- | DEPOSIT | 20 | Luc | 2018-12-02 20:30:13 | +--------+-----------+---------+--------+---------------------+

Transactions en attente (pas encore incluses dans un bloc) +--------+-----------+---------+--------+---------------------+ | Source | Operation | Montant | Destin | DateCreation | +--------+-----------+---------+--------+---------------------+ | Anne | TRANSFER | 40 | Luc | 2018-12-02 20:33:33 | | Anne | TRANSFER | 12 | Marie | 2018-12-02 20:33:50 | +--------+-----------+---------+--------+---------------------+

A10.19.12La boite à outils BLOCKCHAIN

Les fonctions de la boite à outils sont disponibles via l’écran de contrôle de la figureA10.34. L’exécution des trois opérations générant une transaction peut être accom-pagnée de l’affichage du contenu des tables COMPTE, REPERTOIRE et BTRANSAC-TION. On cochera pour cela la case intitulée "Afficher le contenu des tables aprèschaque transaction". Le contenu des tables peut aussi être consulté via la fonction dumenu "Database > Show DB Data" de la fenêtre principale de SQLfast.


© J-

L H

aina

ut -

2015

Figure A10.34 - L’écran de commande de la boite à outil

Les scripts de la boite à outils Blockchain sont disponibles dans le répertoire SQLfast/Scripts/BD-2018/Chapitre-10/Blockchain.


Documents

Date de dernière modification : 4/12/2018 · Date de dernière modification: 4/12/2018 Annexe 10 0 Les bases de données non relationnelles Outre des informations générales sur