FR3117229A1 - Système de gestion des bases de données bayésiennes (causales) - Google Patents

Abstract

La sémantique pauvre qui correspond à l’état de l’art des bases de données d’aujourd’hui rend encore assez difficile les taches suivantes : • Le calcul du plan d’exécution des requêtes • L’analyse des données dans les bases décisionnelles. La sémantique riche de la base STD qui s’appuie sur un nouveau modèle, appelé système de gestion de bases de données bayésiennes (causales) offre les concepts suivants : • Les templates composés de plusieurs tables qui stockent les données : Base, Lookup, Relation, Master, Detail • Les champs des types avancés : Person, Organisation, Customer, Supplier,Product, Language, State, Nationality, Money qui sont utilisés comme les champs « pivots » des calculs • Les réseaux bayésiens : En effet chaque template en tant qu’ensemble de quelques tables stockant les données est vu comme un réseau bayésien. Un système de gestion des bases de données bayésiennes (causales) permet d’avoir un seul module capable d’effectuer les calculs nécessaires ainsi que les opérations d’analyse dans la partie décisionnelle (sans forcement les transférer dans une autre base) via : • Les statistiques au niveau des templates et non seulement au niveau des tables. • Les histogrammes qui sont générés entre les champs du type avancé (Person, Organisation..) et les autres champs standard, numériques, charactère ou date(char, number,date) • L’apprentissage bayésien : l’apprentissage de la structure et l’apprentissage des paramètres. Enfin, il s’agit d’une nouvelle philosophie que les concepteurs pourront utiliser dans la phase du design de la base de données.

Description

Système de gestion des bases de données bayésiennes (causales) - Bayesian (causal) database management system

Le but de ce document est de décrire les caractéristiques techniques d’un nouveau produit, la base de données Smart Templates, que la société Lyticsware souhaite développer. Smart Templates est imaginée comme une base de données orientée Big Data facilitant le machine learning. En la comparant avec les solutions existantes elle se trouve entre une base de données relationnelle et une base données orientée graphe, même si rien n’empêche d’y introduire d’autres notions (données non structurées comme dans une base orientée documents). Il s’agit d’un nouveau model que nous proposons, système de gestion de base de données bayésiennes/causales.

Les différentes générations des bases de données

A. Les bases de données existantes

1. Les générations de bases de données

Les premières bases de données ont été créées dans les années 1950. Il s’agissait des bases ayant le modèle hiérarchique. D’après (1), leur structure s’exprime à l’aide d’une hiérarchie arborescente. Cette hiérarchie peut être exprimée par exemple avec le langage COBOL. Le plus représentatif de ces SGBD est IMS dont le langage de manipulation est DL1.

Dans les années de 1960, les bases de données en réseau sont apparues. La structure en réseau permet une meilleure séparation entre la logique et le physique. Les SGBD les plus connus sont IDMS (IBM), IDS-II (Honeywell), SOCRATE (Bull).

Finalement, dans les années 1970 le modèle relationnel, de E.F Codd, est proposé (2). Les bases de données relationnelles (SGBDR), font l’apparition sur le marché. (Oracle 1977, DB2 …).

Il s’agit du modèle dominant le marché encore aujourd’hui, malgré certaines vagues technologiques qui ont, occasionnellement, fait concurrence au modèle relationnel (modèle objet, XML etc.).

Finalement, la toute dernière mouvance NOSQL (not only SQL) est présente ces dernières années et prend certaines parties du marché, notamment celui des systèmes décisionnels. Notre estimation est que le marché des systèmes transactionnels gardera le modèle relationnel dans les années qui suivent et que NOSQL coexistera avec le modèle relationnel sur le marché décisionnel.

Dans la nombreuse littérature qui décrit le monde des bases de données, dans les articles scientifiques et techniques qu’on peut trouver sur Internet, ou dans la documentation qui accompagne les logiciels, il existe parfois des ambigüités dans les définitions et dans les classifications des bases de données.

Par exemple, quand on parle des bases relationnelles/non-relationnelles on considère surtout le modèle mathématique sous-jacent.

Cependant, selon leur implémentation technique dans un logiciel, on peut distinguer les bases de données orientées lignes, ou orientées colonnes, utilisant ou non le sharding des données ou non (le sharding est la distribution sur plusieurs nœuds). La notion des colonnes est utilisée différemment. Par exemple, Cassandra est considérée comme une base de données en colonnes selon son modèle mathématiques sous-jacent, alors que Sybase IQ est orientée colonnes en termes de son implémentation physique.

On peut mentionner la blockhain comme un modèle introduisant des nouveaux défis mathématiques au mécanisme de la base de données (le problème des généraux byzantins etc.), mais une méthode de stocker physiquement les données également, donc il est dans les des deux catégories.

Selon le site web suivant : https://db-engines.com/en/, il existe actuellement 250 logiciels bases de données sur le marché. Vu que dans notre document, le but est de montrer la rupture technologique que présente la base Smart Templates par rapport aux solutions existantes, il nous a paru impossible de décrire individuellement chacune de ces bases. Cependant, nous avons décrit les lacunes essentielles liés à la sémantique des bases de données existantes et leur optimiseurs de requêtes, partagés par la majorité des solutions existantes et surtout par les bases leaders sur le marché.

Nous sommes convaincus que les lecteurs de ce document obtiendront une vision claire de notre produit et des avantages qu’il offre par rapport à l’état de l’art actuel.

Un autre site, https://dbdb.io/,montre la dynamique des nouvelles solutions qui arrivent sur le marché des bases de données.

Néanmoins, il faut comprendre que ces nouvelles solutions ne sont pas là pour remplacer les anciennes qui sont toujours les leaders sur le marché. Les nouvelles solutions arrivent principalement pour créer d’autres marchés (Big Data, Blockchain). Elles simplifient, volontairement, certaines fonctionnalités des leaders sur le marché et proposent des possibilités alternatives.

2. Les bases de données relationnelles

On appelle « relation » un ensemble d'attributs qui caractérisent une proposition ou une combinaison de propositions comme "un employé a un matricule, il a un nom, il a un employeur". Dans cet exemple, les attributs de l'employé sont : son matricule, son nom et son employeur. Chaque combinaison de propositions ainsi formée est appelée tuple ou collection ordonnée d'objets. Par exemple l'ensemble ("7369", "Edgar Smith", "Albin Michel") constitue un tuple de relation "employé". Les relations sont d'ordinaire représentées sous la forme de tables. Dans l'exemple précédent, la table serait libellée "employé".

D’habitude, on accorde la même signification aux concepts de "relation" et de "table". De même, la "ligne dans la table" est une tuple, et la colonne ou le champ d’une table est l'attribut. Par définition, chaque tuple d'une relation est unique. Il est identifié par un attribut (un identifiant unique appelé "clé primaire") ou une combinaison de plusieurs attributs qui forme la clé. L'ordre des tuples n'est pas significatif, c’est-à-dire, ils peuvent être insérés dans n’importe quel ordre car il n’y aura jamais de recherche du type « quel est la première ligne » mais uniquement quelle est la ligne dont l’attribut <nom> est égal à <un nom>.

E.F Codd (1923-2003) a défini la théorie relationnelle, inspirée par la théorie mathématique des ensembles dans son document de recherche fait pour la compagnie IBM (2). Il explique son concept des « cinq formes normales » dont les deux dernières permettent normaliser les tables et d’éliminer les redondances.

Une relation binaire de l’ensemble A vers l’ensemble B est un sous-ensemble de leur produit cartésien AxB (source : Wikipedia)

A :={X,Y,Z}

B :={1,2}

AxB = R1 :={ (X ;1),(X ;2), (Y ;1), (Y ;2),(Z ;1),(Z ;2)}

(∀ p ∈ R1 : p ∈ AxB)

Une fonction est une relation binaire, avec le premier élément qui est toujours différent.

F ∈ φ (AxB) (⩝ p1,p2 ∈ F : p1 ≠ p2 => π (p1) ≠ π (p2)) { π (p) | p ∈ F } =A

L’ensemble de toutes les premières cordonnées de la fonction F est le domaine de la fonction.

dom(F2) = dom (F3) = {X,Y,Z}

dom (F4)= {Z}

dom (F5)= ∅

dom(F6)={empno,ename, born}

L’ensemble de tous les domaines est la plage.

rng(F2)={1,2}

rng(F3)={1}

rng(f4)={2}

rng(F5)= ∅

rng(F6)={126,’Lex’,’11-aug-1954’}

Deux fonctions sont compatibles si leur premier élément est identique.

Si deux fonctions sont compatibles, leur union est une fonction.

R :={(a;1), (b;2), (C;3)}

S:={(a;2), (d;4)}

Les opérations sur les fonctions :

Comme les fonctions sont des ensembles, il est possible d’appliquer les opérations standard sur les ensembles, comme l’union, l’intersection, différence ou produit cartésien.

Empno	Ename	Job
101	Anne	TRAINER
102	Thomas	SALESMAN
103	Lucas	PRESIDENT

E1

Empno	Ename	Job
102	Thomas	SALESMAN
104	Pete	MANAGER

E2

Empno	Ename	Job	Sal
101	Anne	TRAINER	3000
102	John	MANAGER	5000

E3

Union:

E1 ∪ E2 ={(empno;101),(ename; ‘Anne’),(JOB;’TRAINER’)}

, {(empno;102),(ename; ‘Thomas’),(JOB;’SALESMAN’)}

, {(empno;103),(ename; ‘Lucas’),(JOB;’PRESIDENT’)}

, {(empno;104),(ename; ‘Pete’),(JOB;’MANAGER’)}}

E1 ∪ E3=

{(empno;101),(ename; ‘Anne’),(JOB;’TRAINER’)}

, {(empno;102),(ename; ‘Thomas’),(JOB;’SALESMAN’)}

, {(empno;103),(ename; ‘Lucas’),(JOB;’PRESIDENT’)}

, {(empno;101),(ename; ‘Anne’),(JOB;’TRAINER’), (SAL;3000)}

, {(empno;101),(ename; ‘John’),(JOB;’MANAGER’), (SAL; 5000)}

Intersection:

E1 ∩ E2 = { {(empno;102), (ENAME;’Thomas’),(JOB;’SALESMAN’)}}

Difference:

E1 – E2

{{(empno; 101),(ename,’Anne’),(JOB; ‘TRAINER’)}

,{(empno;103),(ename;’Lucas’),(JOB;’PRESIDENT’)}}

Cependant, les 2 opérations très importantes et les plus souvent utilisées sont a) la jointure et b) la sélection

1. RxS={(a,b,c) : (a,b) ∈ R xR et (b,c) ∈ SxS)
2. σF (R) = { r ∈ R : r satisfait la condition donnée par F }

Nous pouvons également déterminer des domaines types atomiques de données.

• Numérique : entier, décimal etc. (SQL : Int, Float, etc.);

• Chaîne de caractères (SQL : Char(20), VarChar(32), etc.);

• Date (SQL: DATE, TIME, YEAR, etc.);

Qu’est-ce que cela donne en pratique ?

Le langage SQL est utilisé pour créer les tables et insérer, modifier et extraire les données.

L’exemple est sur la .

Les tables d’une base relationnelle

Note : L’existence de juste 3 types de champs primitifs (varchar, number, date) est une pauvreté sémantique et une grande faiblesse des bases relationnelles.

3. Les bases de données NOSQL

En quoi elles sont différentes des bases relationnelles ? NOSQL veut dire Not only SQL (et non l’absence totale du SQL).

On peut distinguer au moins 3 représentations de bases de données NOSQL.

• Bases de données clé-valeur : Ces structures fonctionnent comme des grands tableaux associatifs et retourne une valeur, éventuellement complexe, à partir d’une clé. Les exemples sont Cassandra, Riak, Redis, Oracle NoSQL, MemBase.

L’idée du modèle est de simplifier les recherches, notamment d’éliminer les jointures du model relationnel, qui peuvent être très coûteuses. Déjà, il faut choisir le type de l’algorithme pour exécuter la jointure (nested loop, hash join ou merge, voir plus loin dans notre document), ce qui peut s’avérer complexe. Ensuite, la jointure nécessite au moins deux lectures, ce qui peut être coûteux quand les tables sont volumineuses.

Donc, le modèle clé-valeur élimine la jointure, en dénormalisant les tables et autorisant les champs redondants, contrairement à l’idée des cinq formes normales du modèle relationnel. Dans notre model dept et emp, il s’agit de créer une seule table/structure, qui contiendra les champs de la table dept (dname, loc) ensemble avec la table emp:

Comme les bases NOSQL utilisent aussi d’autres langages pour accéder aux données, on peut aussi imaginer une structure en Java que nous allons accéder via les commandes Java, l’exemple de Oracle NoSQL :

• Bases de données orientées document : Un document est une représentation qui ajoute au modèle clé-valeur l’association d’une valeur complexe, qui nécessiterait un ensemble de jointures en logique des bases relationnelles. Des exemples sont MongoDB, CouchDB.

Un document correspond à une ligne dans la base de données relationnelle. Une collection est l’ensemble de lignes, et correspond donc à une table relationnelle.

Où est la différence ?

Tous les documents d’une collection n’ont pas obligatoirement la même structure.

Empno	Ename	Job
101	Anne	TRAINER

E1

Empno	Ename	Dname
101	Lucas	DALLAS

E2

Empno	Ename	Comment
101	Thomas	Part time

E3

Une union des trois ensembles E1 ∪ E2 ∪ E3 produira cette fois un document (une table dans le sens des bases relationnelles) correct:

E1 ∪ E2 ∪ E3

{(empno;101),(ename; ‘Anne’),(JOB;’TRAINER’)}

, {(empno;101),(ename; ‘Thomas’),(DNAME;’DALLAS’)}

, {(empno;101),(ename; ‘Lucas’),(Comment;’Part time’)}

En MongoDB cela se fait via les commandes suivantes :

Les collections et documents d’une base orientée document

On voit l’apparition d’un autre champ, objectid, que la base MongoDB a ajouté automatiquement, et qui joue le rôle de la clé primaire.

• Bases de données orientées graphe : Un graphe est une représentation qui permet la modélisation, le stockage et la manipulation de données très complexes liées par des relations variées. L’exemple est Neo4J, la base de données orienté graphes. Un base données orientée graphes est inspirée de la théorie des graphes.

La théorie des graphes est la discipline mathématique et informatique qui étudie les graphes, qui sont des modèles abstraits de dessins de réseaux reliant des objets. Ces modèles sont constitués par la donnée de « points », appelés nœuds ou sommets et de « liens » entre ces points ; ces liens sont souvent symétriques (les graphes sont alors dits non orientés) et sont appelés des arêtes. ( Les graphes)

Une des critiques des bases de données relationnelles est que les liens entre les objets sont cachés. Par exemple, dans 3), on montre comment un modèle relationnel peut être remplacé par un modèle graphe Observer l’exemple suivant :

Le modèle relationnel et le model graphe

Enfin, les bases de données en colonnes, comme Cassandra, permettent de stocker plusieurs champs dans un seul (super champ), et n’ont pas de jointures.

Une récapitulation des bases NOSQL:

Les bases NOSQL

Pour résumer, les bases NOSQL relâchent certaines contraintes fortes des bases de données, (le type des données définie à l’avance, les lignes contenant les champs identiques). Les bases de données NOSQL sont ont été surtout créées pour traiter les volumes massifs de données non-structurées (les données texte des articles sur Internet par exemple).

De l’autre côté, les base de données clé-valeurs et les bases de données orientées document, parce qu’elles simplifient les structures de données, en principe n’ajoutent pas de nouveautés dans les algorithmes de recherche de l’optimiseur, ce qui est le sujet principal de notre document.

Il est évident que les bases de données orientées graphes offrent des possibilités mathématiques intéressantes par rapport à l’optimisation. La base STD est une base entre une base relationnelle et une base orientée graphes car ses types avancés sont un bon point de départ pour intégrer les concepts des graphes. Nous en reparlerons dans la partie liée à l’optimiseur.

Note : Dans le cas des bases NOSQL aussi, l’existence de juste 3 types de champs primitifs (varchar, number, date) est une pauvreté sémantique et une grande faiblesse.

B. Notre solution : Smart Templates Database

Dans la Smart Templates Database (STD dans la suite du document) les templates, les types de données avancés et les réseaux bayésiens sont des concepts essentiels. Leur but est d’offrir une sémantique plus riche, pouvant être gardée directement dans les structures de données de la base, par rapport aux solutions d’aujourd’hui. Cela permettra :

• Des solutions plus efficaces pour l’optimiseur basé sur le coût.

• Des solutions plus effaces pour développer les modules Datawarehousing/BI et Big Data

• Une nouvelle philosophie du design des modèles conceptuels des données.

C. Les imperfections des optimiseurs actuels

(1) La qualité des statistiques collectionnées dans les dictionnaires de données

Toutes les bases possèdent leur optimiseur basé sur le cout, qui permet de calculer le cout d’exécution d’une requête qui fait la recherche des données et choisi le chemin le moins couteux. Par exemple, lorsqu’il faut récupérer une seule ligne correspondant à une clé primaire, ou quelques lignes correspondant à une petite plage de données, il est préférable d’indexer le champ en question et de passer par l’index, qui contient les valeurs des champs accompagnées avec leur adresses physiques exactes.

Si, de l’autre côté, la requête récupère une grande plage de données, il est préférable de faire un balayage complet de la table, plutôt que de faire des allés retours fréquents entre la table et l’index. L’optimiseur fait aussi ses calculs en cas des jointures, pour comprendre quel est le meilleur ordre pour accéder aux tables etc. Une fois le plan d’exécution calculé, la requête est ensuite exécutée par le runtime engine.

Le vrai coût de la requête peut être différent du coût estimé par optimiseur.

Les raisons sont les suivantes :

• Le modèle mathématique de l’optimiseur n’est pas parfait, ctd. il est simplifié.

• Les statistiques sur la distribution des données sont basées sur l’échantillonnage des données.

Il s’agit des données échantillonnées et collectés dans un temps restreint (par exemple, en 2 heures, pendant la nuit). Une analyse très détaillée sera trop coûteuse en termes de performances et trop longue. Une analyse complète comprendra la recherche des corrélations statistiques entre les données, création de histogrammes à plusieurs dimensions, classifications des données via les différentes méthodes de clustering par exemple, ou en trouvant des séparateur linéaires/non linéaires entre les données, etc., mais les bases de données d’aujourd’hui n’implémentent pas d’algorithme de ce type dans leurs modules de statistiques pour l’optimiseur. Les statistiques typiques d’une base de données Oracle sont gardées dans les tables système suivantes :

• Dba_tab (contient la liste de toutes les tables, le nombre de lignes dans chacune)

• Dba_tab_columns (contient la liste des champs, la valeur minimale, maximale,le nombre de valeurs différentes pour chaque champ)

• Dba_histograms (contient les histogrammes des valeurs pour les champs ayant des distributions non uniformes)

Les autres bases possédent ses tables système dans lesquelles elles stockent les informations similaires à celles d’un dictionnaire de données Oracle.

Sans parler de statistiques plus avancées, un des problèmes majeurs des bases de données d’aujourd’hui reste l’absence des histogrammes multi-colonnes, nous en reparlerons dans la partie consacrée à la corrélation des données.

Les statistiques et les histogrammes, Postgresql et MariaDB

Les histogrammes d’Oracle

(2) Le problème avec les jointures

Les jointures sont un sujet à part entière, vu que l’amélioration des algorithmes de jointures (boucles imbriquées, merge (fusion) et hash) sont encore aujourd’hui des sujets de recherches. Ce qui nous intéresse ici est de lier le problème des jointures au sujet central de notre analyse, les lacunes de l’optimiseur à cause de la qualité mediocre des statistiques générées dans les dictionnaires des données.

Il existe des cas que l’optimiseur ne détecte pas facilement, par exemple en cas de jointures. Dans la littérature, le cas le souvent cité est le suivant.

La cardinalité de la jointure est calculée comme suit :

• Cardinalité= card(A) * card(B) * selectivité de la jointure

Où la selectivité de la jointure = 1/max (nombre de valeurs différents de A, nombre de valeurs différents de B). Cette formule suppose le principe de l’inclusion, ctd. chaque valeur du petit domaine a une valeur équivalente dans le grand. Ceci est vrai pour les jointures du type clé primaire=clé étrangère, et c’est le cas a) sur le schéma .

Cependant, dans le cas b) présenté sur le schéma , quand il existe des lignes sans paire dans l’autre domaine, la formule mentionnée surestime la cardinalité.

Enfin, un autre cas c), où la cardinalité de la jointure est sous-estimée, même si le principe de l’inclusion n’est pas violé.

Les distributions non-uniformes posent beaucoup de problèmes à l’optimiseur, même si les histogrammes reflètent les courbes des valeurs individuelles, la cardinalité des combinaisons des champs (en cas des jointures ou en cas des multiples prédicats) est plus difficile à calculer.

Le problème des jointures

(3) Le problème de la corrélation des données

Il s’agit probablement du problème principal lié à l’optimisation des requêtes.

Dans le cas d’une requête utilisant plusieurs prédicats dans sa clause where (select * from table where a= :p1 and b= :p2) ou select * from table where a = :p1 or b= :p2) l’optimiseur considère que les deux champs sont indépendants, ctd. applique les formules standard de la probabilité des variables indépendantes. (P(A and B) =P(A) * P(B),P(A or B)=P(A) + P(B) – P(A and B),P(NOT(A))=1-P(A)).Donc la cardinalité d’une valeur de n% sur l’ensemble des valeurs du champs en question est tout simplement vue comme la probabilité statistique de cette valeur P(0=<n<=1).

Ce n’est pas surprenant. Si la probabilité d’une valeur est égale au nombre d’occurrences dans les tests précédents (selon les théories statistiques appelées « fréquentistes » au moins), la sélectivité d’un prédicat est la fraction des lignes qui lui correspondent.

Si les valeurs sont statistiquement indépendantes, le calcul des probabilités combinées est simple et est effectué via les formules mentionnées.

Le problème des prédicats dépendants est beaucoup plus compliqué qu’il ne pourrait paraitre. Dans l’exemple suivant pour l’être humain il est évident que les lignes ayant pour la valeur codepostal=93000 sont les mêmes que celles ayant pour la valeur de la ville=’Bobigny’ mais c’est moins évident pour l’optimiseur d’une base de données. Nous prenons l’exemple suivant, très souvent cité dans la littérature.

Select * from T_Citoyens where codepostal=93000 and ville=’Bobigny’

Code postal	Ville	Name
93000	Bobigny	Durant Jacques
93000	Bobigny	Durant Jeanne
75001	Paris	Dupont Jacques
75001	Paris	Dupont Jeanne

Citoyens

Select * from T_Citoyens where codepostal=93000 and ville=’Paris’

Code postal	Ville	Name
93000	Bobigny	Durant Jacques
93000	Bobigny	Durant Jeanne
75001	Paris	Dupont Jacques
75001	Paris	Dupont Jeanne

Citoyens

Dans le premier cas, la requête retournera potentiellement beaucoup de lignes alors que dans le deuxième, le résultat sera 0 lignes. Cependant, en absence d’information sur la corrélation entre les champs « Code postal » et « Ville » et/ou en absence d’un histogramme multi-colonnes, l’optimiseur estime la même cardinalité pour les deux cas.

Dans notre exemple, les histogrammes qui existent sur les champs codepostal et ville auraient dit que, par exemple 20% d’articles sont achetés à Bobigny et également que 20% d’articles sont achetés dans le département 93000. Le calcul probabiliste avec deux variables indépendantes P(A)*P(B) aurait donné 20% x 20% = 4% comme cardinalité de la requête, mais ce résultat est faux, vu que dans le cas de codepostal=93000 et ville=Bobigny, il s’agit des mêmes lignes dans la table T_Articles.

D’une certaine façon, la corrélation des données reste le problème central des optimiseurs d’aujourd’hui, pour lequel l’état de l’art n’a pas trouvé de solution satisfaisante. (Dans les sciences statistiques ce problème n’est pas nouveau et certaines méthodologies probabilistes (la classification Naïve Bayésienne etc.) simplifient volontairement des conditions pour faciliter les calculs et obtiennent des résultats satisfaisants dans de nombreux cas d’utilisation (55)).

Plus globalement, pour les données d’une table relationnelle, on pourrait imaginer tous les types de corrélation statistiques qui existent (corrélation linéaire, inversée…) ensuite le problème des variables cachées etc. Des suppositions simples, (« naïves »), ont été intégrées dans les premières versions des optimiseurs basés sur les coûts des bases de données. Cependant, même les versions récentes, n’introduisent que très peu de notions de corrélation entre les données. La raison est sans doute la complexité de calculer et de maintenir ces statistiques multiples dans les conceptions existantes (les histogrammes à 2 dimensions).

Pour pallier au problème de la corrélation des données, Oracle a introduit les statistiques étendues (Dbms_ stats.create _extended_stats(owname=>’’,tabname=>’’,extension(codepostal,ville)),SQL Server utilise une fonction similaire, (Create statistics s1 on citoyens( codepostal,ville )) et d’autres bases de données (PostgreSQL, MySQL, MariaDB etc.) connaissent le concept des statistiques multicolonnes.

Également, le concept ducardinality feedbackexiste (Oracle, SQL Server) où les requêtes utilisent les erreurs faites lors de l’exécution pour se corriger. DB2 connait un concept similaire appelé learning optimizer.

Cependant, selon nos recherches, aucune base de données à l’état actuel ne crée des histogrammes multicolonnes par défaut (une action manuelle de la part des développeurs/administrateurs de la base est nécessaire) qui seraient utiles pour prévoir les cardinalités des requêtes avec plusieurs prédicats dans la clause where. Également, aucune base de données ne crée les histogrammes multicolonnes avec les champs des tables différentes.

4) Le problème de permutation des tables lors du calcul du plan d’exécution

Par exemple, dans une SGBDR traditionnelle, la requête suivante :

Select * from

T1,T2,T3,T4,T5

Where

T1.a=:bind1

And

T2.b=:bind2

And

T3.c=bind3

L’optimiseur pourrait faire 5 ! combinaisons, en cherchant est-ce qu’il faut commencer par t1.a t2.b ou t3.c … etc.

Dans le cas d’Oracle :

Le nombre Permutations Proportions

de tables

(n) (n!) ( 80,000 / n! * 100)

1 1 Not Relevant

2 2 Not Relevant

3 6 Not Relevant

4 24 Not Relevant

5 120 Not Relevant

6 720 Not Relevant

7 5040 Not Relevant

8 40320 Not Relevant

9 362880 22%

10 3628800 2.2%

11 39916800 0.2%

12 479001600 0.016%

13 6226020800 0.001284%

14 87178291200 0.0000920%

15 1307674368000 0.000006%

Le nombre de permutation est important, plus le nombre de table dans la jointure augmente.

5) Les recherches scientifiques sur le sujet

Les conférences internationales (VLDB (Very Large Databases), Database Systems for advanced applications etc.) rassemblent chaque année un public large et publient les travaux académiques ou industriels sur le sujet des bases de données et Big Data. Les publications liées à l’amélioration de l’optimiseur apparaissent de temps en temps.

Les problèmes que nous avons évoqués se trouvent de façon assez concise dans « How optimizers are good, really ? » (VLDB conférence 2015)

Dans « Preventing bad plans by bounding the impact of cardinality estimation errors « (VLDB confèrence 2009) , les auteurs cherchent à minimiser la propagation de l’erreur via différentes méthodes mathèmatiques lors du calcul du coût.

Dans « Uncertainty Aware Query Execution Time Prediction » (VLDB conférence 2015) les auteurs traitent le sujet de la probabilité du temps d’exécution.

D’autres documents similaires traitent le sujet dans différents aspects.

La conférence VLDB 2019 à Los Angeles se déroule juste au moment où nous finissons l’écriture de notre document. D’après le planning, au moins une présentation est liée aux différents aspects de l’optimiseur dans le monde Big Data en proposant le machine learning comme une des possibilités.

Cependant, nous ne nous pencherons pas d’avantage sur les solutions proposées car elles essayent de trouver des solutions tout en gardant la structure simple des sémantiques dans les bases de données relationnelles ou NOSQL, mais notre idée est différente, comme nous le montrerons dans la suite du document.

6) Le problème de séparation des bases OLTP, Datawarehouse et BI/Big Data

Selon leur utilisation, toutes les bases de données et les applications qu’elles supportent et hébergent peuvent être classés dans 2 grandes catégories, OLTP (online transaction processing) et Data Warehouses (les bases qui contiennent les données historiques), avec l’existence des bases intérmediaires entre les deux (ODS, operational data store)

Le job qui fait le transfert entre les bases s’appelle ETL (extract, transform and load).

Il tourne entre la base OLTP et DW périodiquement. Le cycle habituel de l’installation d’une DW est que la base OLTP tourne un certain temps en production, ensuite l’équipe en place songe à créer une DW et crée les jobs nécessaires, identifie les données intéressantes à être transférées. Dans un déploiement traditionnel d’un applicatif, la base de données OLTP est d’abord créée. Ensuite, 6 ou 12 mois après, une DW est ajoutée et les développeurs sont demandés de réfléchir comment extraire, transformer les données pour alimenter la DW. Notre base de données offre une alternative.

Les bases OLTP, ETL, et la base datawarehouse

Ici, nous sommes arrivés à la fin de notre présentation des solutions existantes, que quelqu’un trouvera longue peut-être. Mais notre idée était de montrer ces solutions de façon exhaustive pour mieux souligner leurs limites, dues à la pauvreté sémantique des bases de données d’aujourd’hui. Maintenant, nous allons aborder nos solutions innovantes.

D. Les concepts de la base de données STD

L’idée essentielle, sur laquelle reposent toutes les autres fonctionnalités de la base STD, est d’intégrer plus d’information dans la sémantique des tables et les rôles qu’elles jouent dans le modèle conceptuel de données, pour pouvoir les utiliser dans les opérations d’extraction, de manipulation et d’analyse de données ensuite.

Plus précisément, il s’agit des concepts suivants :

• Utilisation des templates de tables. Chaque template contient des tables, avec les relations spécifiques et les rôles de chacune des tables dans le template (Master,Detail, Base, Lookup, Relation)

• Utilisation de la sémantique avancée des types de données. Cette sémantique est, en partie, inspirée de la sémantique provenant du Traitement automatique du langage naturel (TAL) et de son concept appelé Named Entities (NE). Ainsi, en plus des types standard comme varchar, number, date, des nouveaux types de données sont proposés : Person, Organisation, Consumer, Supplier, Product, Service, Language, Nationality, Location, Job, Money.

Note : Les bases de données existantes intègrent les notions orientées objets, qui permettent de créer des types abstraits, comme Person, Organisation etc. En aucun cas, il ne s’agit de la même conception. Ces types abstrait ont comme types sous-jacents les types primitifs standard (varchar, number) et n’ont aucune valeur ajoutée pour l’optimiseur. Ils servent juste aux développeurs pour encapsuler leurs données, et sont d’ailleurs rarement utilisés.

Avec ces deux concepts présents, il sera ensuite d’utiliser d’autres méthodes provenant du monde des algorithmes et d’optimisation.

• Les statistiques au niveau des templates (et non seulement au niveau des tables) pour le calcul des plans de recherche de données (plans d’exécution).

• Les algorithmes de l’intelligence artificielle pour le calcul des plans de recherche de données. Comme nous le verrons, les templates facilitent l’utilisation des principes notamment desr éseaux bayésienset aussi desr éseaux de neuronessur les données.

Enfin, du point de vue de l’implémentation technique, un nouveau concept, appelé Les statistiques à apprentissage lent, permet au moteur du calcul de plan de faire une partie lors de chaque exécution et de peaufiner leur apprentissage au fur et à mesure, et également permettent de constituer une partie de la base décisionnelle.

Si, en une phrase, on résume quelle est la nouveauté que le concept de la base STD apporte par rapport aux autres bases de données, cette base possède :

• Ses templates (Master-Detail, Base-Lookup, Relation …), et sa sémantique des types de données (Person,Language… ), qui,

• …couplés avec les possibilités de l’optimiseur permettent de faire les analyses du type data mining, en utilisant les méthodes de l’intelligence artificielle (les réseaux bayésiens, les réseaux de neurones et autres, IA dans la suite du texte) qui, à leur tour,

• …permettent de faciliter le travail de l’optimiseur qui calcule le meilleur plan d’exécution pour trouver les données, et

• …permettent également de préparer les données pour le datawarehousing.

Il s’agit de plusieurs ruptures technologiques.

D’abord, comme démontré dans ce document, les méthodes des statistiques classiques sont surtout utilisées pour tous les calculs de l’optimiseur qui cherche à trouver le plan d’exécution optimal et cette tache est faite par le batch de statistiques.

D’autres modules sont utilisés pour alimenter la base datawarehouse (ETL) et analyser ses données (BI).

Comme nous avons vu, dans notre cas, il s’agit du même module.

Dans la conception Big Data, les données sont censées être disponible et analysées sur la DW presque « en temps réel «.

Donc, le but de la base de données STD est d’être un nouvel outil puissant, dans le monde des bases de données OLTP, Data Warehouse/BI et Big Data.

E. L’optimiseur de la base STD

Une base de données STD est une base organisée en templates. Les templates sont composés de plusieurs types de tables: Base, Lookup, Relation, Master, Detail ainsi que les champs, Person, Organisation (Customer, Supplier), Location, Language, Nationality, Product, Service, Job, Money. Il est également possible d’ajouter d’autres types de champs comme sous ensemble de ces types élémentaires (catégories typiques pour Person ou Organisation peuvent être Client et Fournisseur comme dans notre exemple). Rien que ce typage de tables et de champs donnera des informations additionnelles à l’optimiseur dans son calcul de plan d’exécution. Il est possible de calculer les statistiques au niveau des tables ainsi qu’au niveau des templates. De l’autre côté, tous les types de champs mentionnés permettent d’insérer tout simplement les données du type charactère, à l’exception de money, qui permet d’insérer les données numériques. (int, float, double etc.). Quelle est donc la différence avec une base de données relationnelle/NOSQL ordinaire ? Dans le cas des bases existantes, il n’y a pas de différence entre par exemple un champ appelé Person du type « varchar » et un champ appelé Organisation du type « varchar », l’optimiseur verra deux « varchars » tout simplement. Ce n’est pas le cas avec la base STD, l’optimiseur verra deux types de champs différents, et c’est l’information qu’il pourra utiliser.

On peut dire que les types de tables donnent plus d’information à l’optimiseur quant à l’utilisation de ces tables dans la base de données (par exemple, une table de type lookup est surtout utilisée en lecture), alors que les types avancés des champs donnent l’information sur la nature des données.

Note : La notion des types (ou des rôles que jouent les tables dans un modèle relationnel) Master, Detail, Lookup sont connus dans la terminologie des bases de données, cependant, dans la base STD, ils sont intégrés directement dans la sémantique du moteur de la base.

Dans le cas de l’optimiseur STD aussi, la génération des statistiques indispensables pour trouver le meilleur plan d’exécution sera faite via les statistiques à apprentissage lent. Il n’est pas indispensable que tout soit appris dans un seul cycle comme c’est le cas aujourd’hui dans la plupart des bases de données et leur batch de statistiques de l’optimiseur (typiquement ces batch tournent pendant la nuit et durent une ou deux heures). Avec les statistiques à apprentissage lent, une partie pourra être apprise chaque jour, et l’optimiseur, qui initialement avait trouvé des statistiques satisfaisantes pour la plupart des distributions de données, pourra encore peaufiner ses connaissances.

Ces mêmes statistiques peuvent être utilisées pour alimenter la datawarehouse. Dans ce sens, elles jouent aussi une partie du rôle d’un ETL classique. En plus, comme elles produisent des données classifiées (le groupes de clients, par exemple) les résultats de leurs analyses peuvent de facto être utilisés par les data scientistes, le marketing ou d’autres équipes.

Cette double fonctionnalité n’est pas étonnante, car finalement la même analyse de données permet de donner la réponse aux deux questions différentes.

• Comment trouver le plus facilement la donnée demandée, ce qui est l’objectif de l’optimiseur. (Car le principe de l’optimiseur est surtout d’éliminer les recherches inutiles, ctd. ne pas chercher les données ou elles n’existent pas. Pratiquement, toutes les requêtes lentes, qui pénalisent les performances d’une base de données, sont des requêtes de ce type)

• Comment classifier les données pour répondre au besoin du business.

Comme les cycles de livraisons des nouvelles versions des logiciels sont devenus fréquents dans les méthodologies comme Agile, Scrum, DEVOPS, il appartient aux statistiques à apprentissage lent d’en détecter les évolutions et de les intégrer dans ce qui a été déjà appris.

: L’exemple de templates master-detail et lookup

: L’exemple de template Base et Lookup

L’exemple de template Bases et Relations

Un modèle relationnel d’une application quelconque (un système de commerce ou autre) sera composé de plusieurs templates, ctd. d’une dizaine voire centaine de tables à l’intérieur. Dans la conception STD, rien n’empêche une table d’être présente dans plusieurs templates. Si elle joue des rôles différents dans des templates différents, il est dans la responsabilité du développeur de la base de choisir le bon type, celui qui convient le plus pour l’ensemble des rôles.

Le choix du type permet au moteur de la base de choisir le type de stockage le mieux adapté (ligne,colonne ou sharding), et aussi à l’optimiseur d’avoir l’idée initiale quant au plan d’exécution optimal.

a) Les types de données avancés

Si nous ajoutons les types avancés de données dans notre modèle, nous obtenons l’exemple sur le schéma 14.

: L’exemple de templates avec des types de champs avancés

L’optimiseur peut automatiquement s’intéresser pour trouver différentes statistiques de corrélation qui existent entre les variables du template =>

F(person, organisation,location, produit)

L’optimiseur de STD commence par étudier les corrélations qui existent entre les champs du types avancés, mais peut étendre son analyse sur d’autres champs aussi, et faire d’autres types de statistiques (nous en parlerons plus dans la partie dédiée à l’intelligence artificielle).

Aussi, l’optimiseur calcule automatiquement la corrélation des champs qui font partie des jointures.

Bien entendu, il est parfois difficile de calculer les relations complexes qui existent entre les données. Egalement, dans un modèle de n tables avec beaucoup de champs, comment comprendre quels sont des champs statistiquement liés ? Et le temps de calcul de statistiques est limité (1/2 heures chaque jour) dans un applicatif type d’aujourd’hui. Quelle est la solution possible? Les statistiques à apprentissage lent, déjà décrites.

b) Les statistiques de base au niveau des templates

EXEMPLE DE MODE DE REALISATON 1 :

Avec les types de champs avancés (Person, Location, Customer,Supplier ) ensemble avec les templates il est possible d’avoir d’autres critères pour trouver la cardinalités des prédicats d’une requête qui sélectionne les champs de plusieurs tables.

Si nous ajoutons les types avancés de données dans notre modèle, nous obtenons l’exemple sur le schéma 15.

: L’exemple de template avec les champs avancés et primitifs

Les autres champs (champ1,champ2,champ3) sont des types primitifs comme varchar,number,date.

L’idée est d’avoir quelques champs « pivots » (person,organisation,produit,location) et de construire des statistiques plus poussées au niveau de ces champs, ctd. de chercher la correlation qui existe parmi ces champs pivots et également entre ces champs pivots et tous les autres champs non-pivots (champ1,champ2,champ3,champ4).

(Person,Organisation,Produit,Location)

(Person, champ3,champ4,champ5,…)

(Organisation, champ3,champ4,champ5,…)

(Produit, champ2,champ3,champ4,…)

(Location, champ2,champ3,champ4,…)

De cette manière, il serait plus facile de construire des histogrammes à plusieurs dimensions pour les champs pivots, et passer par un des champ pivot à chaque fois qu’il existe besoin de connaitre les rapports de corrélation entre les champs non-pivots (champ2 et champ3 par exemple). En effet la sémantique faible qui existe dans les bases de données existantes fait en sorte que de point de vue du calcul fait par l’optimiseur tous les champs d’une table sont au même niveau, il n’y a pas de champ plus important qu’un autre.

Revenons à notre exemple du début du document sur le schéma 18.

: Un template Master Détail des tables EMP et DEPT avec types de champs avancés

c) Intelligence Artificielle et Machine Learning au niveau des templates

1. Réseaux bayésiens

Nous avons examiné des différentes méthodes de l’intelligence artificielle, et les réseaux bayésiens semblent particulièrement intéressants dans notre contexte. Les réseaux bayésiens sont un mariage entre le théorème de Bayes et la théorie des graphes.

• Le théorème de Bayes

Le théorème de Bayes et les statistiques bayésiennes suscitent un intérêt croissant de la communauté scientifique depuis l’an 2000. Les dernières versions des réseaux de neurones et de l’apprentissage profond (Deep learning) incluent également les concepts bayésiens. Dans le concept de la probabilité Bayésienne, il est possible de commencer avec des probabilités à priori, qui peuvent être subjective et/ou basées sur des données incomplètes pour arriver à la probabilité à postériori après avoir intégré plus de données.

P(A|B)=P(B|A)*P(A)/P(B)

P(A|B) - la probabilité à postériori

P(B|A) - la vraisemblance

P(A) – l’hypothèse, la probabilité à priori

P(B) – la constante de normalisation, la probabilité marginale

• Les graphes orientés sans circuit

De son côté, un réseau bayésien est défini comme un DAG (direct acyclic graph, graphe orienté sans circuit), plus précisément :

Il s’agit d’un graphe orienté sans circuit G={V,E}, où V est l’ensemble des nœuds de G, et E l’ensemble des arcs de G.

Quelques exemples d’inférence bayésienne sont sur la page suivante.

:

: Circulation de données dans un graph causal (source : 22), voir la bibliographie)

: La notion de d-séparation : (source : 22), voir la bibliographie)

Comment on calcule les probabilités dans un réseau bayésien ? Dans un réseau simple comme le suivant :

B dépend de A, et C dépend de directement de B, mais indirectement de A aussi.

Il s’agit des notions de causalités, subjectives, qu’on transforme ensuite en probabilités mathématiques.

Donc, en utilisant le théorème de Bayes, nous calculons d’abord la probabilité à postériori de B :

P(B|A)= P(A|B)*P(B)/P(A)

Et ensuite, en utilisant cette valeur, la probabilité à postériori de C :

P(C|B)=P(B|C)*P(C)/P(B)

Un réseau bayésien est donc défini comme :

• Un graphe orienté sans circuit G={V,E}, où V est l’ensemble des nœuds de G, et E l’ensemble des arcs de G.

• Un espace probabilisé fini {@,Z,p} .

• Un ensemble de variables aléatoires associés aux nœuds du graphe et défini sur {@,Z,p} tel que :

P(V1,V2,V3,V4…..Vn)= p(v1|c(V1))

où c(v) est l’ensemble des causes (parents) de Vi dans le graphe G.

Dans un modèle de n variables, il existe 2n-1 nombres qui peuvent être attribués pour avoir une distribution de probabilités conditionnelles complètes, si nous partons du principe que chaque variable peut influencer une autre, ce qui peut donner un calcul complexe et peut-être impossible à faire. Il est donc important d’identifier les variables indépendantes pour un calcul plus efficace.

Une variable aléatoire X est conditionnellement indépendante de la variable aléatoire Y en prenant en compte l’ensemble des variables Zs si

P(X| Y,Zs)=P(X|Zs)

Donc, sachant les valeurs de Z, connaissant la valeur de Y ne change pas de probabilité de la valeur de X.

Dans un réseau bayésien, donc :

• En isolant les variables du graphe avec les d- séparateurs, nous pouvons faire les calculs des probabilités locales.

• Seulement les noeuds parents directes influence directement les probabilités des noeuds enfants.

Pour résumer, un réseau bayésien peut être vu comme un graphe causal auquel on a associé une représentation probabiliste sous-jacente. Cela permet de rendre quantitatif les raisonnements sur des causalités que l’on peut faire à l’intérieur du graphe. Les notions de d-séparation et d’indépendance sont très importantes, car elles permettent de calculer les probabilités locales plutôt que de calculer les probabilités entre tous les nœuds du graphe ce qui est coûteux en termes de performance. L’utilisation essentielle des réseaux bayésiens est donc de calculer des probabilités conditionnelles d’événements reliés les uns aux autres par des relations cause à effet. Aussi, en tant qu’outil de machine learning, un réseau bayésien est également capable d’apprendre. Il peut apprendre la structure et les paramètres du réseau. Si les probabilités subjectives peuvent être définies lors de la conception du réseau, l’apprentissage d’un réseau est fait en ajustant les paramètres en utilisant les valeurs réelles, donc nous revenons dans les statistiques fréquentistes. Tout cela nous parait particulièrement intéressant dans notre contexte.

Dans le chapitre 2 nous avons expliqué la théorie des bases de données relationnelles. Cette théorie, modélise les relations entre différentes entités et leurs attributs, mais ne modélise pas les relations cause à effet explicitement. Les autres modèles, (NOSQL, orientés documents ou graphe) ont le même problème. Cependant, en y intégrant plus explicitement la casualité dans le MCD (modèle conceptuel de données), on pourra obtenir plus d’informations intéressantes pour le calcul de l’optimiseur. Par exemple, dans nos tables EMP et DEPT, il est évident que les valeurs du champ SAL dépendent des valeurs du champ JOB etc.

La causalité est une notion intuitive, qu’on humain comprend plus facilement que la corrélation statistique, qui est une notion mathématique. D’où l’intérêt d’utiliser le terme causalité lors de la modélisation du MCD par les ingénieurs informaticiens, et le terme corrélation lors de l’exécution des algorithmes de calcul de l’optimiseur.

Note: Il s’agit d’un débat dans la communauté scientifique sur comment traiter la causalité. Par exemple, dans son livre « Causality, models, reasoning and performance » Judea Pearl fait démonstration de nombreux formalismes mathématiques du concept de la causalité par rapport aux concepts statistiques. Par exemple, les concepts statistiques sont : corrélation, régression, indépendance, vraisemblance, ratios, alors que les concepts de la causalité sont: randomisation, perturbation, influence, ignorance, effet etc.

Dans le chapitre qui parle des imperfections des optimiseurs actuels on explique le problème de données corrélées et leur impact sur le raisonnement des optimiseurs. En effet les optimiseurs des bases d’aujourd’hui cherchent en permanence des corrélations éventuelles qui pourraient exister entre les différents prédicats de la clause where (et parfois simplifient volontairement cette tache en supposant l’indépendance) et une des raisons est la pauvreté sémantique du modèle relationnel. Dans notre modèle, ces relations pourraient être plus explicitement définies dans l’étape de la conception du MCD. Ensuite, l’apprentissage au niveau du réseau bayésien pourrait être utilisé pour apprendre la structure et apprendre les paramètres. L’utilisation des types avancés comme champs pivot sera utilisé pour simplifier les calculs. Cela donne finalement un modèle de base de données jusqu’à présent inconnu, basé d’un côté sur la philosophie des réseaux bayésiens et de l’autre sur le concept des Named entities provenant du monde TAL, système de gestion de bases de données bayésiennes ou système de gestion de bases de données causales.

EXEMPLE DE MODE DE REALISATON 2 :

Donc un template de la base STD peut être aussi vu comme un réseau bayésien.

Construisons maintenant un réseau bayésien à partir de l’exemple EMP et DEPT que nous avons déjà utilisé.

Dans notre exemple Les champs empno, ename, mgr sont des variables statistiquement indépendantes.

Les autres job, sal, comm, hiredate, deptno dependent les uns des autres.

Dans notre modèle, le salaire et la commission dépendent de la date d’embauche, du département et du job.

Le job dépend du département et la date d’embauche, et du pays (location)

Le salaire dépend du job,de la date d’embauche et du département et du pays.

La date d’embauche dépend du pays.

Les trois champs du type avancé sont organisation, location, person.

: Le modèle conceptuel de données d’une base de données bayésiennes (causale)

Un template, avec les types de champs avancés, vu comme un réseau bayésien.

P(Hiredate|Location)= ?

P(Job|Hiredate,Deptno, Location)= ?

P(sal|Job,Deptno,Location)= ?

Avec les réseaux bayésiens, différentes méthodes ont été proposées pour apprendre la structure et les valeurs de paramètres.

-L’apprentissage de la structure

Plusieurs algorithmes ont été proposés dans la littérature. Ils peuvent être classifiés en 3 catégories :

Basés sur les contraintes :

• IC inductive causation (Verma et Pearl 1991)

• PC probabilistic causation (Spirtes 2000)

• GS Grow shrink Markov blanket (Margaritis 2003)

• IAMB Incremental Association (Tsamardinos 2003) (avec Fast incremental association (Yaramakala et Margaritis 2005) et Interleaved incremental association (Tsamardinos 2003)

Basés sur les scores :

• Les algorithmes gloutons (Hill climbing avec Random restarts ou Tabu search, Bouckaert 1995)

• Les algorithmes génétiques

• Simulated annealing

Les algorithmes hybrides qui sont la combinaison des deux.

L’algorithme IC est un travail pionnier. L’idée est de :

• Chercher les indépendances conditionnelles entre les variables

• Identifier les v- structures parmi les pairs de nœud A et B non voisins, ayant un voisin commun C. Donc le nœud C est la d-séparation entre A et B.

• Enfin, il faut orienter les arcs de façon récursive pour obtenir un graphe acyclique.

L’algorithme est trop complexe pour être mis en pratique en cas de nombreuses variables car le nombre de tests d’indépendances est exponentiel.

L’algorithme PC est la première réalisation pratique de l’algorithme IC. Il limite les tests d’indépendance aux indépendances d’ordre 0 (P(A|B)) et 1 (P(A,B|C)).

L’idée de base est d’isoler les variables indépendantes et de faire de cette façon des calculs probabilistes locaux. L’algorithme PC (probabilistic causation), commence par un graphe non-orienté complètement connecté pour finir avec un graphe orienté qui garde seulement les liens dépendants.

: L’algorithme d’apprentissage PC de la structure dans un réseau bayésien (source : 22), voir la bibliographie)

D’autres algorithmes basés sur les contraintes apprennent d’abord les couvertures de Markov.

Dans notre contexte, il semble intéressant d’utiliser notamment les algorithmes basés sur les contraintes.

Dans tous les cas, notre structure des templates contenant les champs du type avancés comme pivots offre l’avantage à l’algorithme choisi, par exemple en cas du PC, l’idée est de ne faire que les calculs juste entre les champs du type avancés ou entre les champs du type avancés et d’autres types primitifs, mais pas entre les champs primitifs. Cela réduit de façon significative le nombre de calculs à effectuer.

-L’apprentissage des paramètres

L’apprentissage des paramètres appartient au champ vaste des statistiques bayésiennes, où il est possible d’apprendre les paramètres de la distribution. (Contrairement aux statistiques fréquentistes, où les paramètres comme la moyenne, la variance etc. pour une distribution sont fixes, ici ces paramètres sont vus comme des probabilités).

De nombreuses méthodes sont testées aujourd’hui. L’idée est de partir avec une distribution à priori et d’obtenir des distributions plus précises à posteriori.

-L’apprentissage statistique

Par exemple, on peut faire l’apprentissage en calculant le maximum de vraisemblance (MLE – maximum of likelihood).

Souvenons-nous que dans la formule P(A|B)=P(B|A)*P(A)/P(B), la vraisemblance est égale à P(B|A). Il est possible d’utiliser une distribution statistique qu’on considère représentative (continue ou discrète : Gaussienne, Dirichlet, Binomiale) et de trouver le paramètre (la moyenne et la variance dans l’exemple d’utilisation de la distribution Gaussienne par exemple) qui intègre le mieux possible la distribution dans les vraies données, la rendant la plus représentative possible.

-L’apprentissage bayésien

Note : L’apprentissage bayésien est un domaine récent et large qui suscite l’intérêt croissant de la communauté scientifique.

Par exemple on peut faire le calcul du MAP – maximum a posteriori.

La probabilité à postériori, P(A|B), il s’agit de trouver les mêmes paramètres qui maximisent la fonction, qui de nouveau, est une distribution statistique.

: L’exemple de l’apprentissage bayésien

Pour plus d’information sur l’apprentissage bayésien, voir par exemple « Variational Bayesian Learning Theory » (S. Nakajima,K.Watanabe,M ;Sugiyama, Cambridge university press june 2019).

Dans notre cas l’avantage des réseaux Bayésiens est qu’ils peuvent être construit par un expert (dans le cas de la base STD, par un administrateur de la base/data scientiste). Ensuite, le logiciel peut compléter les probabilités/structures manquantes lors de la génération des statistiques, l’étape du bind peeking et du dynamique sampling.

En effet une autre façon d’observer le théorème de Bayes est :

P(H|D)=P(D|H)*P(H)/P(D)

P(H|D) - la probabilité de l’hypothèse après avoir vu les données (dans notre cas, cela pourrait être après avoir collectionné les statistiques, avoir appliqué le dynamique sampling et le bind variable peeking)

P(D|H) - la probabilité des données, après avoir vu l’hypothèse (après avoir collectionné des statistiques élémentaires sur les distributions)

P(H) – la probabilité de l’hypothèse

P(D) – la probabilité des données

Dans un document récent (la conférence Database Systems for advanced applications 2019) les auteurs de l’article « An approach based on Bayesian networks for query selectivity estimation », proposent également quelques solutions intéressantes en utilisant des réseaux bayésiens pour calculer la cardinalité d’une requête dans une base de données. Cependant l’article reste au niveau des bases de données relationnelles (donc avec les types de champs classiques char, number, date, et avec les tables, donc sans templates) et utilise les réseaux bayésiens non comme modèle de données (ce qui est notre idée) mais juste comme une des méthodes de calculs de valeurs de l’optimiseur, et enfin, il s’agit de l’apprentissage de la structure uniquement et non de l’apprentissage de paramètres.

2. Réseaux de neurones

Les réseaux de neurones sont utilisés comme classificateurs non-linéaires et approximateurs universels des fonctions. Dans le contexte de la base STD les deux fonctionnalités peuvent être intéressantes. En tant approximateurs universels des fonctions, un réseau de neurone pourrait être utilisé pour apprendre les données et donner la réponse grâce à la sémantique riche de la base STD.

Par exemple, si l’optimiseur hésite entre :

• 0 – balayage complet de la table

• 1 – balayage de plage d’index

Le réseau de neurones qui est entrainée correctement peut donner la réponse.

Un réseau de neurones comme classifieur/approximateur universel (Source : 35),

Quand il s’agit de la classification nous pouvons définir une requête standard du template.

Note : Nous définissons une requête standard du template comme une requête qui interroge les champs avancés principaux (dans ce cas customer, product) avec un critère de plages de dates, par exemple :

Select * from

master,

detail,

detail_of_detail,

lookup

Where lookup.id in ()

and details_details.date between <date_debut> and <date_fin>

and master=<master_id>

par exemple,

Select * from

customers,

orders,

order_details,

articles

Where article.id in ()

and order_details.date between <date_debut> and <date_fin>

and customer=<customer_id>

Ensuite la classification des customers faite via un réseau de neurones permettra de trouver le bon plan d’exécution de la requête (index ou balayage complèt).

D. Bibliographie:

1. Next Generation Databases, Guy Harisson, 2016, Apress

2. A Relational model of data for large shared data banks, E.F Codd,1972, IBM Research Labaratory, San Jose, California.

3. Graph Databases, Ian Robinson & Jim Weber & Emil Eifrem, 2015,O’Reilly

4. Algorithmique, Cormen & Leiserson & Rivest & Stein, 2010, Dunod Paris

5. COST BASED QUERY TRANSFORMATIONS CONCEPT AND ANALYSIS USING 10053 TRACE – Ryad Shamsudeen

6. New density calculation in Oracle 11g – Alberto Dell’era

7. A Look under the Hood of CBO - the 10053 Event, Wolfgang Breitling, Centrex consulting corporation

8. Exadata and the Optimizer, Maria Collgan, Oracle Corporation

9. Fallacies of the Cost Based Optimizer, Wolfgang Breitling, Centrex consulting corporation

10. Tuning by Cardinality Feedback, Wolfgang Breitling, Centrex consulting corporation

11. Joins, Skew and Histograms, Wolfgang Breitling, Centrex consulting corporation

12. The Effects of OIC and OICA on Access Plans Notes, Wolfgang Breitling, Centrex consulting corporation

13. What is new in the Oracle 9i CBO, Wolfgang Breitling, Centrex consulting corporation

14. Using DBMS_STATS in Access Path Optimization, Wolfgang Breitling, Centrex consulting corporation

15. Cost based optimizer, Jonathan Lewis, 2005, Apress,

16. Practical Oracle8i: Building Efficient Databases

Jonathan Lewis, 2000, Addison-Wesley Professional

17. Oracle Core: Essential Internals for DBAs and Developers, Jonathan Lewis 2012, Apress

18. Troubleshooting Oracle Performance, Christian Antognini, 2008,Apress

19. Adaptive statistics in Oracle 12c, Sunin Chakappen, Suratna Budalakoti

20. Preventing Bad Plans by bounding the impact of Cardinality Estimation errors, Guido Merkotte, Thomas Neuman, Gabrielle Steidi, VLDB Conference 2015

21. How good are query optimizers, really?, Viktor Leis,Andrey Gubichev, Atanas Mirchev, VLDB Conference 2015

22. Réseaux Bayésiens, Patrick Naim, Pierre-Henri Wuillemin, Philippe Leray, Oliiver Pourret, Anna Becker, 2008, Eyrolles

23. Microsoft SQL Server 2008 Internals,(Kalen Delaney,Paul S. Randal, Kimberly L. Tripp, Conor Cunningham, Adam, Machanic, Ben Nevarez) , 2009, Microsoft Press

24. The Art of SQL, Stephane Farroult, 2006, O’Reilly,

25. Refactoring of SQL Applications, Stephane Farroult, 2008, O’Reilly

26. Applied Mathematics for Database Professionals, Lex de Haan & Toon Koppelears, 2007, Apress

27. SQL and relational theory, C.J. Date, 2012, O’Reilly

28. Les bases de données NoSQL et le big data, Rudi Bruchez, 2013, Eyrolles,

29. Database Systems, Elvis C.Foster & Shripad Godbole, 2016, Apress

30. Les bases de données relationnelles, André Flory & Frédérique Laforest, 2005, Economica

31. Based de données NoSQL et Big Data, Phillipe Lacomme & Sabeur Aridhi & Raksmey Phan, 2014, Ellipses

32. Thoughtful Machine Learning, Matthew Kirk, 2015, O’Reilly

33. Data science - fondamentaux et études de cas, Eric Biernant & Michel Lutz, 2015, Eyrolles

34. Efficient Learning Machines, Matthew Awad & Rahul Khanna, 2015 ,Apress

35. Réseaux neuronaux, Jean-Phillipe Rennard, 2006, Vuilbert

36. The Art of Computer Programming, Volume 1 Fundamental Algorithms, Donald E.Knuth, 2012, Addison-Vesley

37. The Art of Computer Programming, Volume 3 Sorting and Searching, Donald E.Knuth, 2012, Addison-Vesley

38. Natural Language Processing with Python, Steven Bird, Ewan Klein & Edward Loper, 2009,O’Reilly

39. Natural Language Annonation for Machine Learning, James Pustejovsky & Amber Stubbs, 2013, O’Reilly

40. Hadoop par la pratique, Jonathan R. Owens, Jon Lentz, Brian Femiano, 2013, Pearson

41. Hadoop The definitive guide, Tom White, 2012,O’Reilly

42. Hadoop in practice, Alex Holmes, Maning, 2015, Shelter Island,

43. Data algorithms, Mahmoud Parsian, 2015, O’Reilly

44. The pragmatic programmer, Andrew Hunt & David Thomas,2000, Addison-Wesley

45. MongoDB the definitive guide, Kristina Chodorow, 2013, O’Reilly

46. Think Bayes, Alain B.Dawney, 2012, Green Tea Press

47. Harry Zhang "The Optimality of Naive Bayes

48. Python pour le data scientist, Emmanuel Jakobowicz, Dunod 2018

49. Introduction au Machine Learning, Chloé-Agathe Azencourt, Dunod 2018

50. L’intelligence artificielle par la pratique, Bob Faltings et Micheal Schumaher, Presses polytechniques et universitaires romandes, 2017

51. Deep learning en action, Josh Patterson, Adam Gibson, O’Reilly, 2018

52. Data science pour l’entreprise, Foster Provost, O’Reilly, 2013

53. TensorFlow pour le deep learning, Bhararth Ramsunder, Reza Bosagh Zadeh, O’Reilly 2018

54. Deep Learning, Ian Goodfellow, Youshua Bengio, Aaron Courville, 2016

55. Articifial Intelligence, David L.Poole, 2018, Cambrigde University Press

56. Probabilty and Computing, Micheal Mitzenmacher et Eli Upfal, Cambridge University Press, 2018

57. Learning Kernel Classifiers, Ralf Herbrich, The MIT Press, 2002

58. Bayesian Networks, Marco Scutari, Jean-Baptiste Denis, CRC Press, 2015

59. Machine Learning avec Scikit-Learn, Aurélien Géron, Dunod,2017

60. Deep learning avec TensorFlow , Aurélien Géron, Dunod,2017

Claims (1)

1. Nous revendiquons donc :
   A. Les templates composés de plusieurs tables qui stockent les données : Base, Lookup, Relation, Master, Detail
   ensemble avec
   B. Les champs des types avancés : Person, Organisation, Customer, Supplier, Product, Service, Language, State, Nationality, Job, Money qui sont utilisés comme les champs « pivots » des calculs
   ensemble avec
   C. Des réseaux bayésiens (comme chaque template, en tant que ensemble de quelques tables stockant les données, est vu comme un réseau bayésien),
   comme la solution que nous voulons protéger.