WO2024042379A1

WO2024042379A1 - Application de l'optimiseur basé sur le coût de la base bayésienne-causale à une base relationnelle

Info

Publication number: WO2024042379A1
Application number: PCT/IB2023/056190
Authority: WO
Inventors: Dragutin Jastrebic
Original assignee: Lyticsware
Priority date: 2022-08-25
Filing date: 2023-06-15
Publication date: 2024-02-29
Also published as: FR3139210A1

Abstract

La version v1 de l'optimiseur de la base bayésienne/causale apporte des améliorations significatives. - L'optimiseur peut reconnaitre les types de données avancés (entités nommées), si l'analyste ne les a pas définis. - Il peut reconnaitre les rôles, si l'analyste ne les a pas définis. - Son algorithme implémente le réseau bayésien au niveau des super-types aussi (contrairement à la version v0). L'algorithme découpe le modèle de données en triplets (S, V, L) et crée l'histogramme au niveau de chaque triplet. Ceci est un autre pas important en avant dans la résolution du problème du calcul de la cardinalité dont souffrent les bases de données d'aujourd'hui. Ceci est aussi un grand pas théorique et pratique dans l'intégration complète les concepts des réseaux bayésiens dans le moteur d'une base de données. Tout ceci permet l'application de l'optimiseur basé sur le coût de la base bayésienne/causale à une base relationnelle, et permet de résoudre de façon plus efficace le calcul de la cardinalité dans le monde des bases relationnelles existantes. L'idée est de créer un schéma additionnel dans la base relationnelle et d'installer le module de génération des histogrammes du template bayésien pour un modèle de données relationnel. Ensuite, il faut modifier l'algorithme de l'optimiseur de la base de données relationnelle pour lui permettre de chercher « la cardinalité externe » et l'ordre d'accès aux tables, les 2 éléments ayant été calculés par la base bayésienne. Aussi le concept de D-séparation et D-Connections de la base bayésienne permet d'améliorer la partie BI/Big Data.

Description

Application de l'optimiseur basé sur le coût de la base bayésienne-causale à une base relationnelle

Notre brevet numéro FR3117229 - 10/06/2022 décrit un nouveau modèle de base de données que nous proposons, appelé système de gestion de base de données bayésiennes/causales.

Dans ce brevet nous présentons ce nouveau modèle qui répond aux 2 problèmes actuels non résolus de façon satisfaisante dans le monde des bases de données

Le problème du calcul correct du plan d’exécution
Le problème de séparation stricte des bases OLTP et BI/Big Data en tant que 2 modules différents

Nous avons expliqué que la base bayésienne/causale offre des outils sémantiquement plus riches à l’analyste/concepteur de la base de données, les templates, les champs avancés, et le réseau bayésien comme support à la modélisation de données. Nous avons expliqué comment un modèle conçu de cette façon dans le contexte d’une base bayésienne permet de répondre aux 2 besoins mentionnés.

Toutefois, pour répondre à ce besoin dans le contexte des bases de données relationnelles existantes, il est possible d’appliquer les méthodes d’une base bayésienne/causale directement à une base de données relationnelle. Donc, les structures d’un « template bayésien » peuvent être intégrées dans une base relationnelle traditionnelle.

Même si nous estimons que l’adoption de cette nouvelle façon de penser « bayésienne/causale » ne nécessite qu’un faible effort intellectuel dans la conception d’une base de données, si l’analyste préfère rester dans l’ancienne méthodologie en créant les tables plutôt que les templates (et indiquer le rôle de la table à l’intérieur), et en utilisant seulement les types de données primitifs tels que char, number, date, sans utiliser en plus les types de données avancés comme Person, Organisation etc, alors la base de données relationnelle, enrichie avec le module appelé base bayésienne/causale, peut se charger de reconnaitre ces nouveaux éléments.

C’est pour cette raison que, même si cette nouvelle version peut être utilisée dans une base bayésienne/causale, dans ce document, nous parlons aussi de la possibilité d’intégrer la base bayésienne/causale comme module dans une base relationnelle.

A part la possibilité de reconnaitre elle-même les types de données avancées et les rôles, cette version plus évoluée de l’optimiseur apporte des améliorations au niveau des plans d’exécutions et au niveau de l’analyse BI/Big Data.

Cette nouvelle version est appelée V1.

C’est l’objectif de cette demande de brevet.

La version précédente est appelée V0 dans le document actuel.

Note: Dans ce document, nous avons adopté quelques changements au niveau de la terminologie.

Le type avancé (Person, Organisation…) de la V0 est appelé « entité nommée » dans la V1, comme dans le traitement automatique du langage naturel.

Le type standard (char, number, date…) est appelé « caractéristique » ou « property » dans la V1.

Un super-type correspond à une table relationnelle

Un type correspond à une colonne dans la table relationnelle.

-Le template bayésien

Selon la V0 de notre brevet numéro FR3117229 - 10/06/2022, 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 bayésienne/causale 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.

La version V1 de l’optimiseur étend la notion du réseau bayésien dans le contexte de la base de données. Elle permet de créer le réseau bayésien entre les super-types aussi (dans la version V0 le réseau bayésien existe seulement au niveau des types). Ensuite les histogrammes ne sont plus générés au niveau des types avancés (Person, Product etc.) comme dans la version V0 mais au niveau des triplet super-types qui sont reconnus dans le modèle de données. De cette façon pour chaque triplet est généré un histogramme du type S, V ou L. Les types avancés gardent leurs fonctionnalités identiques de la version V0, via l’algorithme « Probabilistic Causation aux types avancés » il est possible d’aider d’avantage le calcul de l’optimiseur dans cette version, mais les types avancés (encore une fois, appelés « entités nommées ») ont aussi des nouvelles fonctionnalités au niveau BI/Big Data. (la nouvelle fonctionnalité : des partitions, D-séparation et D-Connections).

Cette nouvelle version V1, comme la version V0, combine les idées du traitement de langage naturel et des réseaux bayésiens dans le contexte de l’optimisation des bases de données mais va bien plus loin que la version V0. La partie inspirée par TAL peut paraître simple, mais personne, à notre connaissance, n’est arrivé à cette idée jusqu’à aujourd’hui. (Personne n’a vu l’utilité d’observer les choses de cette façon !). Ceci est encore plus vrai pour la partie concernant les réseaux bayésiens, la façon d’adapter pleinement les concepts des réseaux bayésiens directement au niveau du moteur de la base de données est une chose complètement ignorée par la communauté scientifique et informatique, malgré un nombre de travaux importants sur les réseaux bayésiens.

La reconnaissance des entités nommés dans le monde du langage naturel

Dans un autre domaine d’informatique/recherche scientifique, appelé le TAL (traitement automatique du langage naturel) le texte des documents (pages web, textes en word, livres) est analysé par les programmes en plusieurs étapes : part of speech taging (analyse grammaticale), chunking (découpage des phrases en VP et NP), NER (named entity recognition) etc. Dans cette dernière étape citée, les éléments tels que Person, Organisation, Location sont reconnues dans le texte écrit. L’intérêt de cette étape est de rendre l’extraction des informations effectué par le programme plus facile.

C’est avec cette idée que nous avons pensé que, si cette étape est utile dans l’analyse de données non-structurées (le texte des documents), elle peut être aussi utile dans le domaine des données structurées.

En principe, nous avons estimé que si on demande à un analyste de modéliser un template en lui demandant de préciser les champs du type Customer, Person, cela ne représente qu’un faible effort par rapport aux méthodes de modélisation actuelle, modéliser une table avec les champs du type varchar, number, date.

Toutefois, si l’analyste préfère rester dans son état d’esprit actuel, en modélisant juste les tables+ plus les champs du type varchar, number, date, alors le système peut se charger de :

- Reconnaitre des champs du type avancé (comme le NER le fait dans le cas du traitement du texte)

- Reconnaitre des rôles

Ceci est effectué via des algorithmes très simples.

La reconnaissance des entités nommées dans le domaine des données structurés semble bien plus facile que la même tache dans le domaine des données non-structurés.

L’algorithme de reconnaissance de types avancés (entités nommées) :

Analyser le dictionnaire de données pour reconnaitre les champs du type avancé (les entités nommées) manquantes :

Note : Nous montrons l’exemple en utilisant les termes en anglais et en français, bien entendu, les termes peuvent être en n’importe quelle langue.

Si le nom du champ est Nom, Prénom, Firstname, Lastname alors le type du champ est Person.
Utilisation des corpus externes comme dans le monde du TAL pour reconnaitre les noms des personnes.
Si le nom du champ Organisation, Entreprise alors le type du champ est Organisation.
Utilisation des corpus externes comme dans le monde du TAL pour reconnaitre les noms des sociétés
Si le nom du champ est Produit, Article, Product, Article alors le type du champ est product ou service
Utilisation des corpus externes comme dans le monde du TAL pour reconnaitre les noms des produits
Si le nom du champ est Langage alors le type du champ est Langage
Utilisation des corpus externes comme dans le monde du TAL pour reconnaitre les noms des produits
Si le nom du champ est Pays, State alors le type du champ est State
Utilisation des corpus externes comme dans le monde du TAL pour reconnaitre les noms des Pays
Si le nom du champ est Nationalité, Nationality alors le type du champ est Nationality
Utilisation des corpus externes comme dans le monde du TAL pour reconnaitre les noms des nationalités
Si le nom du champ est Job alors le type du champ est Job
Utilisation des corpus externes comme dans le monde du TAL pour reconnaitre les noms des métiers
Si le nom du champ contient un terme comme salaire, prime, prix, coût, capital, intérêt, salary, commission, price, cost, alors le type est money

Fin de l’algorithme

Comme pour les types avancés, si les rôles ne sont pas définis explicitement par l’analyste, ils peuvent être détectés par l’optimiseur.

L’algorithme de reconnaissance de rôles dans une base relationnelle:

Analyser le dictionnaire de données

Si la table t1 est liée avec la table t2 via une clé étrangère alors t1 est « Détail » et t2 est « Master »

Si la table t1 a plus d’une table « Master », et n’a pas d’autres champs à part les clés étrangères vers les tables « Master », alors c’est une table « Intersection ».

Note : Ce triplet sera reconnu comme une V-structure du réseau bayésien au niveau des super-types (voir l’algorithme création d’un V-histogramme)

Si la table t1 est liée à elle-même via une clé étrangère alors en même temps elle est « Master » et « Detail », il s’agit d’une hiérarchie.

Note : Cette hiérarchie sera reconnue comme une S-structure du réseau bayésien au niveau des super-types. (voir l’algorithme création d’un S-histogramme).

Si une table « Master » a 2 tables « Details », alors cette structure sera reconnue comme une L-structure du réseau bayésien au niveau des super-types (voir l’algorithme création d’un L-histogramme)

Si les contraintes ne sont pas définies alors recherche des tables dans le cache des requêtes alors

Analyser le cache

Si les tables sont liées par une jointure dans la clause where et il existe plusieurs valeurs (de lignes) d’un ou plusieurs champs (colonnes) d’une table correspondant à une seule valeur (de lignes) d’un ou plusieurs champs (colonnes) d’une autre table alors la première est « Détail » l’autre est « Master »

Si 3 tables sont liées par une jointure dans la clause where et il existe plusieurs valeurs (de lignes) d’un ou plusieurs champ (colonnes) d’une table correspondant à une seule valeur (de lignes) d’un ou plusieurs champ (colonnes) de chacune des 2 autres tables

et il n’existe pas d’autres champs dans la table au milieu à part les champs mentionnés

alors la table au milieu est « Intersection », les 2 autres sont « Master »

Fin de l’algorithme

Le réseau bayésien typé, les types et super-types

Le concept qui a été mentionné dans notre brevet FR3117229 - 10/06/2022, même s’il n’a pas été défini de façon complètement explicite, est le concept du réseau bayésien typé, sur lequel est basé une base bayésienne/causale. Un réseau bayésien typé, est un réseau bayésien qui possède des types de données, comme.la table d’une base de données relationnelle. Aussi, nous avons parlé des types et des super-types de nœuds. Un super-type est tout simplement une collection commune de plusieurs nœuds, comme une table qui est la collection de plusieurs champs. Comme expliqué précédemment, dans la version V1 les super-types sont aussi liés via un réseau bayésien.

Customer, Product sont des entités nommées, P1-P10 sont des caractéristiques

Donc, nous avons une flèche entre les super-types Customers et Products.

Nous avons aussi le champ du type avancé (entité nommée) Customer dans le super-type Customers.

Et les autres champs p1-p8 qui sont des caractéristiques (properties) qui peuvent être de n’importe quel type (char,number,date, autre).

Le même concept existe dans le super-type Product..

On voit également une flèche qui va du super-type Customer vers le super-type Product.

Également les flèches qui vont de P4 vers P7 dans le super-type Customer.

Et finalement une flèche qui va du nœud Customer.P8 -> Product.P4.

Donc les flèches du réseau bayésien peuvent exister entre 2 super-types et entre les types (entité nomme ou caractéristique) du même super-type, mais aussi entre les types de 2 super-types différents.

Une base bayésienne peut toujours être vue en tant que l’ensemble des super-types

qui sont contiennent des champs du type avancé (entités nommées) + d’autres champs, qui sont des caractéristiques (properties), et où les réseaux bayésiens existent aux 2 niveaux.

Dans l’état de l’art actuel, de façon en principe indépendante des bases de données, les réseaux bayésiens standard connaissent 3 cas de liens entre les nœuds :

Une S-structure

A=ensoleillement, C=prix du blé, B=récolte

Si le prix du blé est bas, c’est que la récolte est abondante, et je n’ai pas besoin de vérifier l’ensoleillement.

Donc B joue le rôle du d-séparateur. L’information sur A n’est pas prise en compte lors du calcul de C.

Une L-structure

X= ma pelouse, humide, Z=il a plu cette nuit, Y= la pelouse de mon voisin, humide

Ici aussi il est essentiel de comprendre si le chemin est actif ou non, ctd. si les variables X et Y sont d-séparées par Z. Par exemple, si je sais qu’il a plus cette nuit (Z), je n’ai pas besoin de vérifier l’état de ma pelouse (X) pour savoir l’état de la pelouse de mon voisin (Y).

Une V-structure

E=tremblement de terre, F=alarme, G=cambriolage

C’est la structure connue sous le nom de la V-structure. E et G sont liés par le explaining away effect dans le cas montré ici (une V-structure n’est pas nécessairement l’occurrence d’un explaining away effect, mais surtout le lien entre de variables qui semblent indépendantes)

Donc si j’entends que l’alarme a sonné et je sens le tremblement de terre, je suis rassuré qu’il n y’a pas eu de cambriolage.

Ajoutons aussi la notion du blanket de Markov, qui regroupe les nœuds parents et les nœuds parent du même enfant, pour le nœud en question.

Comment toutes ces notions peuvent-elle être utiles dans le monde des bases de données, plus concrètement pour aider l’optimiseur à trouver le bon plan d’exécution ?

Un modèle de données conceptuel d’une base de données peut contenir des centaines de tables. Un template bayésien, cependant, correspond aux tables qui sont interrogées ensemble via une ou plusieurs requêtes SQL. Même si en théorie, une requête contenant une jointure entre les tables peut contenir une centaine de tables, en pratique, une requête récupère les données d’une dizaine de tables au maximum, (et même ce chiffre est élevé, ce nombre ne dépasse pas 5-6 dans la plupart des cas des bases de données modernes)

Dans la version V0 de l’optimiseur il a été expliqué comment, via les histogrammes du template, un histogramme est créé pour chaque type avancé : Customer, Product etc.

La bonne pratique de modélisation d’une base bayésienne est d’avoir un type avancé par table (entité nommée) + les autres types standard (caractéristiques) par exemple la table T_Customer contient le type avancé Customer plus les autres champs comme sexe, adresse, la table T_Product contient le type avancé Product etc.

Chaque histogramme correspond à une table avec une ligne qui est un profile contenant la combinaison des champs avec la clause « group by » ensemble avec les clés qui correspondent.

Cependant, dans la version V0, quelques difficultés principales restent de trouver le bon découpage du modèle conceptuel en templates bayésiens et de générer les statistiques en positionnant les bons paramètres de l’échantillonnage, et finalement, l’algorithme ne donne pas l’ordre exact d’accès aux tables, même s’il donne les cardinalités.

Aussi, une base de données relationnelle n’est pas forcément modélisée de cette façon, même si, si les bonnes pratiques sont respectées, le design d’une base de données devrait être assez facilement « traduit » et adapté aux termes cités d’une base bayésienne.

Néanmoins, il n’est pas certain que chaque table contienne un type qui peut être considéré comme avancé/entité nommée. Comment faire les histogrammes dans ce cas ?

Dans la version V1 de l’optimiseur, une solution plus flexible a été trouvée, chaque requête est toujours découpée en triplets de 3 tables, correspondant aux V, S, et L structures d’un réseau bayésien. Puis les histogrammes sont générés pour chaque type de triplet. En plus les entrées envoyées à l’algorithme en tant que paramètres permettent de définir la taille des échantillons ainsi que le périmètre du traitement des statistiques (nombre de triplets, le blanket de Markov, les entités nommées, les caractéristiques).

S, L, V structures et leurs histogrammes
L’exemple d’une S structure dans le contexte d’une base de données

Dans une base bayésienne, une S-structure correspond à un triplet Master -> Master-> Detail., donc dans le cas d’une hiérarchie. Ceci est valable même si cette hiérarchie existe au sein d’une seule table avec la clé étrangère dans la même table que la clé primaire.

La S-structure est reconnue par l’optimiseur.

L’algorithme de création d’un S-histogramme

Reconnaissance d’un triplet master->detail->detail, ou d’une table contenant une clé étrangère vers elle même avec au moins 3 niveaux de hiérarchie, en tant que S-structure, les tables, ou les partitions contenant les lignes des 3 niveaux, sont nommées T1, T2, T3
Insert into T_S_ChildHistogram1

Select count(*), »l’ensemble des champs sauf la clé primaire»

From « la T1 »

Group by « l’ensemble de champs sauf la clé primaire»

Having count(*) between N1 and N2 de lignes par rapport aux nombre total de lignes de la table/partition en question

Chaque ligne insérée est un profile

Insert T_S_ChildHistogram2

Select count(*), »l’ensemble des champs sauf la clé primaire»

From « T2 »

Group by « l’ensemble de champs sauf la clé primaire»

Chaque ligne insérée est un profile

Insert into T_S_ChildHistogram3

Select count(*), »l’ensemble des champs sauf la clé primaire»

From « la table 3 »

Group by « l’ensemble de champs sauf la clé primaire»

Having count(*) between N1 a2nd N2 de lignes par rapport aux nombre total de lignes de la table/partition en question

Chaque ligne insérée est un profile

Dans la table T_S_KeysHistogram sont insérées le nom du triplet (construit par concatenation des noms des tables), toutes les valeurs de profiles et de clés qui appartiennent à un profile.

Classification des lignes de l’histogramme dans les partitions D-Séparation et D-Connections :

Si la corrélation entre la clé primaire de T1 et la clé étrangère de T3 est supérieure à la corrélation de la clé primaire de T2 et la clé étrangère de T3 alors ce paire de clé (T1,T3) va dans la partition D-Connections avec l’indicateur D-Connections par défaut

Si la corrélation entre la clé primaire de T1 et la clé étrangère de T3 est inférieure à la corrélation de la clé primaire de T2 et la clé étrangère de T3 alors le pair de clé (T2, T3) va dans la partition D-Séparation avec l’indicateur D-séparation par défaut

S’il existe une corrélation supérieure à N entre un champ entité nommée de T1 et un ou plusieurs champs entités nommées ou caractéristiques de T3 est alors l’ensemble de champs (T1, T3) va dans la partition D-Connections avec l’indicateur D-Connections au niveau des entités nommées

S’il existe une corrélation supérieure à N entre un champ entité nommée de T2 et un ou plusieurs champs entités nommées ou caractéristiques de T3 est alors l’ensemble de champs (T2, T3) va dans la partition D-séparation avec l’indicateur D-séparation au niveau des entités nommées

S’il existe une corrélation supérieure à N entre un champ caractéristiques de T1 et un ou plusieurs champs caractéristiques de T3 est alors l’ensemble de champs (T1,T3) va dans la partition D-Connections avec l’indicateur D-Connections au niveau des caractéristiques

S’il existe une corrélation supérieure à N entre un champ caractéristiques de T2 et un ou plusieurs champs entités nommées ou caractéristiques de T3 est alors l’ensemble de champs (T2, T3) va dans la partition D-séparation avec l’indicateur D-séparation au niveau des caractéristiques.

Fin de l’algorithme

Un histogramme doit toujours répondre à 3 questions essentielles

Donner la cardinalité exacte de la requête
Donner l’ordre exact d’accès aux tables du triplet
Être un point de départ pour l’analyse BI

Voici quelques exemples pour comprendre mieux les notions des D-séparation et D-Connections dans le contexte d’une base de données.

Comme mentionné, il existe :

La D-séparation/connexion de la cardinalité par défaut (sans filtres appliqués, au niveau de la clé étrangère de la table au milieu du triplet)
La D-séparation/connexion de la cardinalité au niveau des champs du type avancé
La D-séparation/connexion au niveau des caractéristiques (P1-P5)

Dans notre exemple de S-structure, on peut imaginer des cas suivants :

Le nombre de départements dépend de la division en question

On dit qu’il existe une D-connection dans la S-structure

Dans un autre exemple, certains départements engagent le plus d’employées en moyenne, peu importe la division. Ceci est une D-séparation de la cardinalité par défaut.
Dans un autre exemple, les départements du marketing engagent le plus d’employées en moyenne, peu importe la division. Ceci est une D-séparation de la cardinalité au niveau du type avancée (Job)
Dans un autre exemple, les départements qui engagent les Data-Scientistes contient les employées les mieux payées en moyenne, peu importe la division.

Ceci est une D-séparation de la cardinalité au niveau des 2 types avancée (Job,Money).

Enfin, il est possible qu’une des caractéristiques permet la D-séparation dans le même sens. Pour une certaine raison, dans un département on engage que les gens sans plombages de dents (par exemple dans le cas des pilotes d’avions militaires). C’est une D-séparation au niveau des caractéristiques. (P5).

Une V-structure

Dans une base bayésienne une V-structure correspond à un triplet Master->Detail<-Master. (ou Master->Intersection<-Master)

L’algorithme de création d’un V-histogramme

Reconnaissance d’un triplet master->detail<-master ou master->instersection<-master en tant que V-structure. Les tables sont nommées T1, T2, T3
Insert into T_V_ChildHistogram1

Select count(*), »l’ensemble des champs sauf la clé primaire»

From « T1 »

Group by « l’ensemble de champs sauf la clé primaire»

Having count(*) between N1 and N2 de lignes par rapport aux nombre total de lignes de la table en question

Chaque ligne insérée est un profile

Insert T_V_ChildHistogram2

Select count(*), »l’ensemble des champs sauf la clé primaire»

From « T2 »

Group by « l’ensemble de champs sauf la clé primaire»

Chaque ligne insérée est un profile

4) Insert into T_V_ChildHistogram3

Select count(*), »l’ensemble des champs sauf la clé primaire»

From « T3 »

Group by « l’ensemble de champs sauf la clé primaire»

Having2 count(*) between N1 and N2 de lignes par rapport aux nombre total de lignes de la table en question

Chaque ligne insérée est un profile

Dans la table T_V_KeysHistogram sont insérées le nom du triplet (construit par concatenation des noms des tables), toutes les valeurs de profiles et de clés qui appartiennent à un profile.

5)Classification des lignes de l’histogramme dans les partitions D-Séparation et D-Connections

Note :Dans le cas d’une V-structure les 2 tables détails sont indépendantes l’une de l’autre, deviennent dépendantes en cas de jointure via les tables au milieu toutefois elles peuvent avoir des champs dépendants aussi (entités nommées ou caractéristiques) est la situation que l’optimiseur détecte en tant que D-connection.

Si la corrélation entre la clé primaire de la table T1 et la clé primaire de la table T3 est supérieure à N alors le pair de clés est dans la partition d-connections avec l’indicateur la cardinalité par défaut

S’il existe des clés primaires de la table T1 ou T3 qui ne sont pas présentes dans T2 ces clés vont dans la partition D-séparation.

Si la corrélation entre un champ entité nommée de la table T1 et un autre champ entité nommé ou caractéristique de la table T2 ou T3 est supérieure à N alors l’ensemble des champs est mis dans la partition D-connections des entités nommées

Si la corrélation entre un champ caractéristique de la table T1 et un autre champ caractéristique de la table T2 ou T3 est supérieure à N alors l’ensemble des champs est mis dans la partition D-connections des caractéristiques.

Fin de l’algorithme

Les exemples de D-séparation et D-connections dans le cas d’une V-structure.

La D-séparation/connexion de la cardinalité par défaut (sans filtres appliqués au niveau des 2 clés étrangères)
La D-séparation/connexion de la cardinalité au niveau des champs du type avancé (un produit P beaucoup vendu à des clients du type C)
La D-séparation/connexion au niveau des caractéristiques (P1-P5) (Un produit ayant une caractéristique P1 est vendu à des clients ayant la caractéristique P4)

Une L-structure

Dans une base bayésienne une L-structure correspond à un triplet Detail<-Master->-Detail

L’algorithme de création d’un L-histogramme

Pour chaque L-structure détectée au niveau des super-types, un L-histogramme est créé de façon suivante :

Reconnaissance d’un triplet detail<-master->detail en tant que L-structure. Les tables sont nommées T1, T2, T3

2) Insert into T_L_ChildHistogram1

Select count(*), »l’ensemble des champs sauf la clé primaire»

From « T1 »

Group by « l’ensemble de champs sauf la clé primaire»

Chaque ligne insérée est un profile

3)Insert T_L_ChildHistogram2

Select count(*), »l’ensemble des champs sauf la clé primaire»

From « T2 »

Group by « l’ensemble de champs sauf la clé primaire»

Chaque ligne insérée est un profile

4) Insert into T_L_ChildHistogram3

Select count(*), »l’ensemble des champs sauf la clé primaire»

From « T3

Group by « l’ensemble de champs sauf la clé primaire»

Chaque ligne insérée est un profile

Dans la table T_L_KeysHistogram sont insérées le nom du triplet (construit par concatenation des noms des tables), toutes les valeurs de profiles et de clés qui appartiennent à un profile.

Note : Dans le cas d’une L-structure les 2 tables détails sont indépendantes l’une de l’autre (ne sont pas liées par une contrainte de clés étrangère) toutefois elles peuvent avoir des champs dépendants aussi (entités nommées ou caractéristiques) est la situation que l’optimiseur détecte en tant que D-connection.

S’il existe une corrélation supérieure à N d’un champ entité nommé de la table T2 avec un autre champ entité nommé ou caractéristique de la table T3 alors l’ensemble des champs est mis dans la partition D-Connections des entités nommées

S’il existe la corrélation supérieure à N d’un champ caractéristique de la table T2 avec un autre champ entité nommé ou caractéristique de la table T3 alors l’ensemble des champs est mis dans la partition D-Connections des caractéristiques.

Fin de l’algorithme

Les exemples de D-séparation et de D-connections dans le cas d’une L-structure

La D-séparation/connexion de la cardinalité par défaut (sans filtres appliqués 2au niveau des 2 clés étrangères)
La D-séparation/connexion de la cardinalité au niveau des champs du type avancé (Par exemple, l’acteur A joue le personnage B)
La D-séparation/connexion au niveau des caractéristiques (P1-P5) (Les muscles d’un acteur le font jouer dans les films d’actions)

Le contenu d’un histogramme :

-Les paramètres utilisés lors du lancement des statistiques

Les paramètres N1, N2 indiquant le pourcentage des lignes insérées dans l’histogramme sont à estimer lors du lancement de statistiques. En principe un bon point de départ est de prendre les valeurs qui ont plus de 30% par rapport nombre total de lignes.

Par exemple, si la cardinalité d’une table peut varier entre 0% et 20% pour un filtre,

dans le cas extrême l’erreur du triplet peut se propager, et la cardinalité estimée peut être erronée :

Estimée : 1

Vraie : 60

D’où l’importance de bien positionner les paramètres et éviter un histogramme trop grand aussi.

Il est toujours possible de compléter les statistiques pour s’assurer qu’elles soient de bonne qualité. Ceci est fait en créant, comme dans la version v0, le réseau bayésien entre les types.

L’algorithme Probabilistic Causation aux types avancés dans la version v1

- Via cet algorithme qui est inchangé par rapport à la version V0, mais dans cette nouvelle version il est possible de le paramétrer, le réseau bayésien entre les types peut être créé :

a) A l’intérieur d’un super-type

b) A l’intérieur d’un triplet

c) A l’intérieur du blanket de Markov

d) A l’intérieur du template bayésien.

Il est ensuite possible de créer d’autres types d’histogramme sur les V, S, L structures trouvées entre les types ou tout simplement entre les champs avec une corrélation détectée.

Fin de l’algorithme

Comme l’algorithme Probabilistic Causation ne garde que les plus fortes corrélations à cause de l’application du principe de l’indépendance conditionnelle, l’analyste peut décider de générer d’autres histogrammes entre d’autres variables ayant une certaine corrélation.

L’algorithme Probabilistic Causation :

Enfin, pour créer les partitions D-séparation et D-connections dans les histogrammes, l’analyste doit aussi donner le coefficient de corrélation N de pour classifier les données. Ceci est utilisé uniquement pour les besoins BI/BigData dans cette version.

L’ordre d’accès aux tables.

Comment l’optimiseur choisi l’ordre d’accès aux tables, une fois les cardinalités lues au niveau des histogrammes ?

Nous allons l’expliquer en prenant exemple sur une base de données connue, IMDB (Internet Movie Database) :

Si on prend la requête suivante :

SELECT cn.name, mi.info, miidx.info

FROM

Company_name cn,

company_type ct,

info_type it,

info_type it2,

title t,

kind_type kt,

movie_companies mc,

movie_info mi,

movie_info_idx miidx

WHERE cn.country_code =’US’

AND ct.kind = ’production companies’

AND it.info = ’rating’

AND it2.info = ’release dates’

AND kt.kind = ’movie’

And 13 joins

L’optimiseur doit reconnaitre les triplets suivants :

V-structure : Company_name->Movie_Companies<-CompanyType

V-structure :Info_type->Movie_Info<-Title

S-structure : Kind_Type->title->move_idx

Etc.

Ou, écrit autrement :

SELECT cn.name, mi.info, miidx.info

FROM

company_name cn, | VA1

movie_companies mc, | VA2

company_type ct, | VA3

info_type it, | VB1

movie_info mi, | VB2

info_type it2, 8 | VB3

title t, |SA2

movie_info_idx miidx |SA3

kind_type kt, |SA1

WHERE cn.country_code =’[us]’ |VA1

AND ct.kind = ’production companies’ |VA3

AND it.info = ’rating’ |VB1

AND it2.info = ’release dates’ |2VB3

AND kt.kind = ’movie’ |SA1

Nous allons démontrer le concept sur une requête simplifiée, ne contenant que 2 V-structures, et un prédicat pour chacune envoyé par l’utilisateur de la requête.

select count(*) from

company_name cn,

company_type ct,

title t,

movie_companies mc

where cn.country_code =’[us]’

and mc.company_type_id=ct.id

and mc.company_id=cn.id

and ct.kind = ’production companies’

and t.id=mc.id

and ct.id=mc.company_type_id;

Donc en interrogeant les histogrammes, qu’est-ce qu’on obtient ?

Si on utilise le pseudo-code en SQL, l’optimiseur doit trouver la réponse aux 2 V-structures suivantes :

La V-structure 1:

select count(*) from

company_name cn,

company_type ct,

movie_companies mc2

where cn.country_code ='US'

and mc.company_type_id=ct.id

and mc.company_id=cn.id;

1500000

La V-structure 2:

select count(*) from

title t,

movie_companies m2c,

company_type ct

where

ct.kind = 'production companies'

and t.id=mc.id

and ct.id=mc.company_type_id;

120000

Les 2 valeurs sont lues au niveau de l’histogramme, pour chacune des V-structures

Ensuite l’histogramme fourni aussi les valeurs au niveau des tables (avec le filtre appliqué s’il existe)

Donc min(V1,V2)=1200000 on choisit la V2

Et ensuite V1(min(T1,T2,T3))

Les 3 valeurs sont lues au niveau de l’histogramme et les tables T_V_ChildHistogramN

L’algorithme global est donc le suivant :

L’algorithme du choix d’ordre d’accès aux tables

Commencer par le triplet (S, V, L) qui renvoie le moins de données pour les filtres appliqués
Dans le triplet choisi, commencer par la table qui renvoie le moins de données pour les filtres appliqués
Refaire les 2 opérations avec les autres triplets

Fin de l’algorithme

Donc, il ne faut pas commencer par la table qui renvoie le moins de données dans la requête (si son triplet renvoie plus de données qu’un autre triplet)

On peut regarder un autre exemple, où la jointure par laquelle il faut commencer se trouve juste entre les 2 structures.

Imaginons un modèle de données qui est la fusion des 2 modèles, celui de la et de la . Donc, Division-Departement->Employees->Customer->Orders<-Articles.

Nous avons une S-structure (Division, Departement,Employees) et une V-structure (Customer, Orders, Articles)

Dans l’exemple que nous avons imaginé, il existe un lien 1 : N entre Employees et Customers. Ceci se passe dans le contexte d’une application interne de la société X, où les employées peuvent acheter des produits en ligne sur le site de la société, et peuvent avoir plusieurs avatars qui sont attachés à leur nom. Même si on peut imaginer le cas où Employees et Customers soient la même table (dans le cas du lien 1 :1) ici nous voulons montrer comment procéder dans ce cas particulier. En effet, l’algorithme va calculer les cardinalités pour la V-structure et pour la S-structure, puis pour les tables à l’intérieur de chacune, mais que faire si une cardinalité spécifique existe entre Employees et Customer, et que le meilleur plan consiste de commencer par la jointure entre les 2 ?

On peut remarquer que Employees->Customer->Orders est une S-structure aussi, pour laquelle un S-Histogramme peut être généré.

Il appartient donc à l’analyste de faire le bon découpage du modèle de données en triplets, d’autoriser ou non, le chevauchement des structures de 3 tables lors de la génération des statistiques et la création des histogrammes.

En principe, si les histogrammes sont bien faits, il n’y a plus de raison que l’optimiseur se trompe dans le calcul.

Comme partie optionnelle dans cette version, l’analyste peut décider d’utiliser les histogrammes additionnels entre les types (par exemple en créant un histogramme complet sur 2 champs).

Littérature :

-Réseaux bayésiens, Eyrolles, 2008, Patrick Naim, Pierre-Henri Wuillemin, Phillipe Leray, Olivier Pourret, Anna Becker

-How optimizers are good, really? VLDB conference 2014, Viktor Leis,Andrei Gubichev, Atanas Mirchev

- Le brevet FR3117229 - 10/06/2022 dans la base INPI, « Système de gestion de bases de données bayésiennes/causales »

Préambule :

Une base bayésienne est caractérisée par l’existence des éléments suivants :

-Les super types qui correspondent aux tables d’une base relationnelle

-Les sous types qui correspondent aux champs d’une base relationnelle

-Les liens entre les super types : Chaque relation master->master->détail est une S-structure d’une base bayésienne, chaque relation détail<-master->détail est une L-structure, et chaque relation master->détail<-master est une V-structure

-Les liens entre les sous types, chaque lien représente une relation de corrélation ou causalité

-Les sous types sont divisés en 2 catégories : types standards (quand il s’agit d’un champ numérique, alphanumérique, date) et entités nommés (quand un numérique/alphanumérique contient les données concernant un/une : Personne, Organisation, Client, Fournisseur, Produit, Langue, État, Nationalité, l’Argent) alors il est considéré comme un type spécial appelé « entité nommé ». Les entités nommées permettent d’orienter le calcul de l’optimiseur.

L’algorithme de transformation d’un modèle relationnel vers un modèle bayésien est un programme de l’ordinateur exécuté périodiquement et qui permet à l’optimiseur de la base relationnelle de générer les statistiques de qualité qui permettent aux requêtes SQL de trouver toujours le bon plan d’exécution (un problème non résolu dans l’état de l’art actuel). L’algorithme est composé de 5 étapes (sous-algorithmes). Les 2 premières étapes permettent à enrichir sémantiquement le modèle de données (en reconnaissant les types « entités nommés » ou les S,L,V structures) Une fois le modèle enrichi de cette façon, le calcul des histogrammes est beaucoup plus simple et c’est l’avantage principal par rapport aux solutions actuelles des base de données relationnelles.

Les paramètres d’entrée dans l’algorithme sont les informations récupérées dans le code des requêtes ou dans le dictionnaire de données de la base (les noms de champs qui permettent d’identifier les entités nommées) + les données des tables (récupérées dans les histogrammes construits par l’algorithme) , la sortie est la cardinalité exacte + l’ordre d’accès aux tables de la requête, retournés par l’algorithme.

Pour voir les exemples d’utilisation se référer aux pages 22-26.

Claims

L’algorithme de transformation d’un modèle conceptuel de données relationnel en réseau bayésien typé et de générations de statistiques, en tant que partie essentielle du module optimiseur de requêtes d’une base de données ou module du type « Business Intelligence », ou tout autre module ayant pour but d’optimiser les requêtes ou analyser les données, composé des super-types et types de données, contenant les algorithmes suivants :
L’algorithme de reconnaissances des entités nommées dans une base relationnelle :
-Si le nom du champ est Nom, Prénom, Firstname, Lastname alors le type du champ est Person.
-Utilisation des corpus externes comme dans le monde du TAL pour reconnaitre les noms des personnes.
-Si le nom du champ Organisation, Entreprise alors le type du champ est Organisation.
-Utilisation des corpus externes comme dans le monde du TAL pour reconnaitre les noms des sociétés
-Si le nom du champ est Produit, Article, Product, Article alors le type du champ est product ou service
-Utilisation des corpus externes comme dans le monde du TAL pour reconnaitre les noms des produits
-Si le nom du champ est Langage alors le type du champ est Langage
-Utilisation des corpus externes comme dans le monde du TAL pour reconnaitre les noms des produits
-Si le nom du champ est Pays, State alors le type du champ est State
-Utilisation des corpus externes comme dans le monde du TAL pour reconnaitre les noms des Pays
-Si le nom du champ est Nationalité, Nationality alors le type du champ est Nationality
-Utilisation des corpus externes comme dans le monde du TAL pour reconnaitre les noms des nationalités
-Si le nom du champ est Job alors le type du champ est Job
-Utilisation des corpus externes comme dans le monde du TAL pour reconnaitre les noms des métiers
-Si le nom du champ contient un terme comme salaire, prime, prix, coût, capital, intérêt, salary, commission, price, cost, alors le type est money
L’algorithme de reconnaissance de rôles dans une base relationnelle
Début de l’algorithme
-Analyser le dictionnaire de données
Si la table t1 est liée avec la table t2 via une clé étrangère alors t1 est « Détail » et t2 est « Master »
Si la table t1 a plus d’une table « Master », et n’a pas d’autres champs à part les clés étrangères vers les tables « Master », alors c’est une table « Intersection ».
Note : Ce triplet sera reconnu comme une V-structure du réseau bayésien au niveau des super-types (voir l’algorithme création d’un V-histogramme)
Si la table t1 est liée à elle-même via une clé étrangère alors en même temps elle est « Master » et « Detail », il s’agit d’une hiérarchie.
Note : Cette hiérarchie sera reconnue comme une S-structure du réseau bayésien au niveau des super-types. (voir l’algorithme création d’un S-histogramme).
Si une table « Master » a 2 tables « Details », alors cette structure sera reconnue comme une L-structure du réseau bayésien au niveau des super-types (voir l’algorithme création d’un L-histogramme)
Si les contraintes ne sont pas définies alors recherche des tables dans le cache des requêtes alors
-Analyser le cache
Si les tables sont liées par une jointure dans la clause where et il existe plusieurs valeurs (de lignes) d’un ou plusieurs champs (colonnes) d’une table correspondant à une seule valeur (de lignes) d’un ou plusieurs champs (colonnes) d’une autre table alors la première est « Détail » l’autre est « Master »
Si 3 tables sont liées par une jointure dans la clause where et il existe plusieurs valeurs (de lignes) d’un ou plusieurs champ (colonnes) d’une table correspondant à une seule valeur (de lignes) d’un ou plusieurs champ (colonnes) de chacune des 2 autres tables
et il n’existe pas d’autres champs dans la table au milieu à part les champs mentionnés
alors la table au milieu est « Intersection », les 2 autres sont « Master »
Fin de l’algorithme
L’algorithme de construction de 3 types d’histogrammes S, L, V :
Début de l'algorithme pour les statistiques d’une S-structure
-Reconnaissance d’un triplet master->detail->detail, ou d’une table contenant une clé étrangère vers elle même avec au moins 3 niveaux de hiérarchie, en tant que S-structure, les tables, ou les partitions contenant les lignes des 3 niveaux, sont nommées T1, T2, T3
-Insert into T_S_ChildHistogram1
Select count(*), »l’ensemble des champs sauf la clé primaire»
From « la T1 »
Group by « l’ensemble de champs sauf la clé primaire»
Having count(*) between N1 and N2 de lignes par rapport aux nombre total de lignes de la table/partition en question
-Chaque ligne insérée est un profile
-Insert T_S_ChildHistogram2
Select count(*), »l’ensemble des champs sauf la clé primaire»
From « T2 »
Group by « l’ensemble de champs sauf la clé primaire»
Having count(*) between N1 and N2 de lignes par rapport aux nombre total de lignes de la table/partition en question
-Chaque ligne insérée est un profile
-Insert into T_S_ChildHistogram3
Select count(*), »l’ensemble des champs sauf la clé primaire»
From « la table 3 »
Group by « l’ensemble de champs sauf la clé primaire»
Having count(*) between N1 a2nd N2 de lignes par rapport aux nombre total de lignes de la table/partition en question
-Chaque ligne insérée est un profile
Dans la table T_S_KeysHistogram sont insérées le nom du triplet (construit par concatenation des noms des tables), toutes les valeurs de profiles et de clés qui appartiennent à un profile.
-Classification des lignes de l’histogramme dans les partitions D-Séparation et D-Connections :
Si la corrélation entre la clé primaire de T1 et la clé étrangère de T3 est supérieure à la corrélation de la clé primaire de T2 et la clé étrangère de T3 alors ce paire de clé (T1,T3) va dans la partition D-Connections avec l’indicateur D-Connections par défaut
Si la corrélation entre la clé primaire de T1 et la clé étrangère de T3 est inférieure à la corrélation de la clé primaire de T2 et la clé étrangère de T3 alors le pair de clé (T2, T3) va dans la partition D-Séparation avec l’indicateur D-séparation par défaut
S’il existe une corrélation supérieure à N entre un champ entité nommée de T1 et un ou plusieurs champs entités nommées ou caractéristiques de T3 est alors l’ensemble de champs (T1, T3) va dans la partition D-Connections avec l’indicateur D-Connections au niveau des entités nommées
S’il existe une corrélation supérieure à N entre un champ entité nommée de T2 et un ou plusieurs champs entités nommées ou caractéristiques de T3 est alors l’ensemble de champs (T2, T3) va dans la partition D-séparation avec l’indicateur D-séparation au niveau des entités nommées
S’il existe une corrélation supérieure à N entre un champ caractéristiques de T1 et un ou plusieurs champs caractéristiques de T3 est alors l’ensemble de champs (T1,T3) va dans la partition D-Connections avec l’indicateur D-Connections au niveau des caractéristiques
S’il existe une corrélation supérieure à N entre un champ caractéristiques de T2 et un ou plusieurs champs entités nommées ou caractéristiques de T3 est alors l’ensemble de champs (T2, T3) va dans la partition D-séparation avec l’indicateur D-séparation au niveau des caractéristiques.
Fin de l’algorithme des statistiques d’une S-structure
L’algorithme de génération de statistiques d’une V-structure
Début de l’algorithme
Reconnaissance d’un triplet master->detail<-master ou master->instersection<-master en tant que V-structure. Les tables sont nommées T1, T2, T3
La génération des histogrammes est identique comme dans le cas d’une S-structure
Classification des lignes de l’histogramme dans les partitions D-Séparation et D-Connections dans le cas d’une V-structure :
Note: Dans le cas d’une V-structure les 2 tables détails sont indépendantes l’une de l’autre, deviennent dépendantes en cas de jointure via les tables au milieu toutefois elles peuvent avoir des champs dépendants aussi (entités nommées ou caractéristiques) est la situation que l’optimiseur détecte en tant que D-connection.
Si la corrélation entre la clé primaire de la table T1 et la clé primaire de la table T3 est supérieure à N alors le pair de clés est dans la partition d-connections avec l’indicateur la cardinalité par défaut
S’il existe des clés primaires de la table T1 ou T3 qui ne sont pas présentes dans T2 ces clés vont dans la partition D-séparation.
Si la corrélation entre un champ entité nommée de la table T1 et un autre champ entité nommé ou caractéristique de la table T2 ou T3 est supérieure à N alors l’ensemble des champs est mis dans la partition D-connections des entités nommées
Si la corrélation entre un champ caractéristique de la table T1 et un autre champ caractéristique de la table T2 ou T3 est supérieure à N alors l’ensemble des champs est mis dans la partition D-connections des caractéristiques.
Fin de l’algorithme des statistiques d’une V-structure
L’algorithme des statistiques d’une L-structure
Reconnaissance d’un triplet detail<-master->detail en tant que L-structure. Les tables sont nommées T1, T2, T3
La génération des histogrammes est identique comme dans le cas d’une S-structure
Note : Dans le cas d’une L-structure les 2 tables détails sont indépendantes l’une de l’autre (ne sont pas liées par une contrainte de clés étrangère) toutefois elles peuvent avoir des champs dépendants aussi (entités nommées ou caractéristiques) est la situation que l’optimiseur détecte en tant que D-connection.
-Classification des lignes de l’histogramme dans les partitions D-Séparation et D-Connections
S’il existe une corrélation supérieure à N d’un champ entité nommé de la table T2 avec un autre champ entité nommé ou caractéristique de la table T3 alors l’ensemble des champs est mis dans la partition D-Connections des entités nommées
S’il existe la corrélation supérieure à N d’un champ caractéristique de la table T2 avec un autre champ entité nommé ou caractéristique de la table T3 alors l’ensemble des champs est mis dans la partition D-Connections des caractéristiques.
Fin de L’algorithme des statistiques d’une L-structure
Fin de l’algorithme de construction de 3 types d’histogrammes S, L, V.
L’algorithme du choix d’ordre d’accès aux triplets S, L, V et des tables du triplet
Commencer par le triplet (S, V, L) qui renvoie le moins de données pour les filtres appliqués
-Dans le triplet choisi, commencer par la table qui renvoie le moins de données pour les filtres appliqués
-Refaire les 2 opérations avec les autres triplets
Fin de l’algorithme du choix d’ordre d’accès aux triplets S, L, V et des tables du triplet
.