Bases de données avancées

Transcription

Bases de données avancées
Rémi Gilleron
Inria Lille - Nord Europe & LIFL & Univ Lille 3
septembre 2013
Rémi Gilleron (Mostrare)
Informatique M1 MIASHS
septembre 2013
1 / 143
Objectifs et organisation
Objectifs du cours
comprendre l’environnement informatique des entreprises ;
connaı̂tre les concepts avancés sur les bases de données relationnelles :
optimisation, contraintes d’intégrité et accès concurrents ;
connaı̂tre les autres modèles de données associés au décisionnel, au
Web et au“Big Data” : modèle en étoile, modèle clé-valeur, modèle
colonne, modèle document, modèle graphe
Organisation du cours
12 séances de 2 heures
septembre 2013
2 / 143
Plan
1
Systèmes d’information
2
Bases de données relationnelles
Notions fondamentales
Calcul relationnel et optimisation de requêtes
3
Compléments sur les BDs relationnelles
SQL- Le langage de définition des données
archhitecture BDR – les utilisateurs, les droits, les vues
SQL- gérer la concurrence
4
Autres modèles de données
Décisionnel et modèle en étoile
Big Data et bases NoSQL
Modèles NoSQL de données
septembre 2013
3 / 143
Schéma général
Le Système d’information (SI)
est la mémoire de l’activité de l’entreprise,
est l’interface entre le système de pilotage et le système opérant.
Le Système d’information (SI)
est constitué d’un système opérationnel
et d’un système décisionnel,
il est désormais intégré dans un système d’information et de
communication (SIC).
septembre 2013
4 / 143
Informatique opérationnelle 70 –
est axée sur la production, la mémorisation et le traitement des données de
l’activité de l’entreprise. On peut distinguer :
l’aspect statique : enregistrement des données, faits, règles et
contraintes ;
l’aspect dynamique : mise à jour (ajout, modification et suppression)
des données, faits, règles et contraintes.
Elle est centrale pour l’activité de l’entreprise et est organisée autour de
bases de données relationnelles avec les suites logicielles associées (SGBDR
tels que Oracle) et le langage SQL.
septembre 2013
5 / 143
Informatique décisionnelle 90 –
est axée sur l’aide à la décision.
Les données sur l’activité issues du système opérationnel et de sources
externes sont extraites, filtrées, historisées et traitées à l’aide d’outils
d’ETL (“Extraction Treatment Loading”) pour être déposées dans des
infocentres et/ou des entrepôts de données (datawarehouse).
Ces données sont alors utilisées pour la production de synthèses et de
rapports afin de faciliter la prise de décision. Ceci à l’aide de suites
logicielles telles que Business Object.
septembre 2013
6 / 143
Système d’information et de communication 00 –
ne se contente plus de stocker, traiter et synthétiser les données pour
l’activité de l’entreprise mais prend en compte les aspects de
communication : communication interne et externe de l’entreprise,
échange de données informatisées (EDI) avec tous les partenaires, ...
On parle d’Intranet, d’Extranet, de portail d’entreprise. Il concerne toutes
les bases et entrepôts de données l’entreprise mais aussi les bases de
documents (gérées par des CMS “Content Management Systems”). Ils
utilisent les technologies Web.
septembre 2013
7 / 143
Exemple d’une banque
le système opérationnel va mémoriser toutes les informations sur les
clients, leurs différents comptes et les opérations sur ces comptes :
débit, crédit, virement, change, ... ; déclencher des actions (envoi de
relevés, ...) ; ...
le système décisionnel conserve sur une période, par exemple
mensuelle, le nombre d’opérations, leur montant moyen, la moyenne
des soldes sur les différents comptes, ... sur une durée historique de
une ou plusieurs années. Il dispose également d’informations (très,
trop) personnelles sur le client.
le système de communication met à disposition des clients un portail
d’entreprise pour leurs activités : solde, virement, prêts, ... ; il permet
également des échanges avec les partenaires (mouvements financiers,
virements internationaux, ...) ; ...
septembre 2013
8 / 143
Conclusion
Existant
des systèmes d’information et de communication contenant des bases de
données, des bases de documents et des entrepôts de données. Les
technologies sont éprouvées : technologies Internet, bases de données
relationnelles, systèmes de gestion de contenus, entrepôts de données et
outils de production de rapports.
Évolutions en cours
développement des petits objets portables communicants et leur
intégration dans le SIC avec images et videos,
développement des capteurs et génération de flux de données
(positionnement GPS, consommation électrique, ...)
des masses de données et le phénomène “Big Data” : cloud, gestion
et traitement de données réparties, analyse de masses de données, ...
septembre 2013
9 / 143
Plan
1
2
3
4
septembre 2013
10 / 143
Bases de Données
Un système d’information est construit autour de volumes de données de
plus en plus important. Ces données doivent être stockées sur des supports
physiques. Les données sont stockées et organisées dans des bases de
données – BD (databases – DB).
Un utilisateur doit pouvoir les retrouver. Il faut pouvoir les interroger par
des requêtes.
Les données évoluent, il faut donc pouvoir les manipuler : ajouter,
modifier, supprimer des données.
Le logiciel de base qui permet de manipuler ces données est appelé un
système de gestion de bases de données – SGBD (database management
system – DBMS).
Tout système d’information est construit autour de bases de
données
septembre 2013
11 / 143
Exemple - BD gestion de commandes
Contenu : les clients, les produits, les prix, les fournisseurs, la
facturation, la livraison, ...
Applications : toutes les applications de gestion de l’entreprise,
Manipulation : par les services de l’entreprise mais aussi de l’extérieur
(commandes par le site web, ...)
Variabilité : forte, des ajouts et modifications fréquentes ;
Consultation : par les services de l’entreprise mais aussi de l’extérieur
(suivi de commande, ...)
septembre 2013
12 / 143
Exemple - BD et Web
Un site dynamique est construit sur une base de données.
l’utilisateur sollicite une page, la demande est envoyée au site, le
serveur exécute un programme,
les informations utiles sont extraites de la base de données et
rapatriées au serveur,
une feuille de style est appliquée, un document html est construit et
envoyé sur le réseau,
le document est affiché dans le navigateur de l’utilisateur.
l’intérêt est de distinguer les données des traitements et de l’affichage :
pour modifier le contenu du site, il suffit de mettre à jour les informations
dans la base de données ; pour modifier la présentation, il suffit de modifier
le style du document Web.
septembre 2013
13 / 143
Fonctionnalités principales
BD
mémoriser de grandes quantités de données essentielles à la vie de
l’entreprise,
les organiser, faciliter les requêtes et permettre l’évolution,
donner l’accès à des applications diverses, à des utilisateurs différents
avec des modes d’accès variés.
SGBD
gérer le stockage sur des supports physiques éventuellement répartis
et distants,
assurer la rapidité des accès, l’indépendance des données et des
applications,
assurer le contrôle de la concurrence car les données sont partagées et
réparties,
assurer la protection des données : reprise sur panne, vérifier les droits
d’usage et d’accès,
septembre 2013
14 / 143
Le modèle relationnel
Dans un contexte opérationnel où les données sont en volume important,
où les données évoluent, où les utilisateurs sont nombreux avec des accès
concurrents, le modèle de référence est
le modèle relationnel basé sur des tables vérifiant des propriétés de
forme normales implanté dans
des systèmes de gestion de bases de données relationnelles (SGBR tels
que Oracle, PosGres, SQLite, ...) et utilisant
un langage d’interrogation standardisé SQL et
des transactions vérifiant les propriétés ACID : Atomicité, Cohérence,
Isolation et Durabilité.
septembre 2013
15 / 143
Les relations
Un domaine est l’ensemble des valeurs que peut prendre une donnée.
Une relation (ou table) est un sous ensemble du produit des domaines
qui porte un nom.
Un attribut est une colonne de relation caractérisée par un nom.
Une relation peut être définie en extension par l’ensemble des
enregistrements (lignes, tuples) constituant la relation à un instant
donné ou en intention par le schéma de la relation qui contient le
nom de la relation, la liste des attributs, le domaine de chaque
attribut et des contraintes d’intégrité associées à la relation.
Toute relation possède une clé primaire qui est un attribut dont la
valeur est toujours définie et dont la valeur détermine un et un seul
enregistrement.
septembre 2013
16 / 143
Les formes normales
Dépendance fonctionnelle
Un modèle relationnel est donc constitué de relations. Pour s’assurer que
le modèle est bien construit pour préserver la cohérence des données, on a
défini des formes normales.
Dépendance fonctionnelle
Soit X et Y deux ensembles d’attributs, on dit que Y est en dépendance
fonctionnelle de X , noté X → Y , si à toute valeur de X correspond au
plus une valeur de Y
Exemple : soit la relation PERSONNEL(Nom, Sexe, Age, Ville), on a :
Nom → Sexe ; Nom → Age ; Nom → Ville ; Nom, Sexe → Ville ; Sexe
6→ Age ; Sexe, Age 6→ Ville
septembre 2013
17 / 143
Première et deuxième formes normale
Définitions
Une relation est en première forme normale (1FN) si tous les attributs
sont en dépendance fonctionnelle de la clé. Soit encore : tout attribut
a au plus une valeur et la valeur de la clé détermine la valeur des
autres attributs.
Une relation est en deuxième forme normale (2FN) si elle est en 1FN
et les dépendances fonctionnelles liant la clé aux attributs sont
élémentaires : un attribut ne dépend pas fonctionnellement d’une
partie de la clé.
Exemple
LIGNEARTICLE(numcommande, numproduit, quantité,
prixproduit) dont la clé est numcommande + numproduit n’est pas en
2FN car prixproduit dépend fonctionnellement de numproduit
septembre 2013
18 / 143
Troisième forme normale
Définition
Une relation est en troisième forme normale (3FN) si elle est en 2FN et les
dépendances fonctionnelles liant la clé aux attributs sont directes,
c’est-à-dire ne peuvent être obtenues par transitivité.
Exemples
PRODUIT(numproduit, ..., numfournisseur, nomfournisseur,
adressefournisseur, ...) de clé numproduit n’est pas en 3FN car
nomfournisseur et adressefournisseur dépendent fonctionnellement
de numfournisseur.
Une solution est d’éclater la relation en deux relations :
la relation PRODUIT(numproduit, ..., numfournisseur) et la relation
FOURNISSEUR(numfournisseur, nomfournisseur, adresse
fournisseur).
septembre 2013
19 / 143
Conception de bases de données
Formes normales
un modèle relationnel en forme normale 3FN assure la non-redondance des
informations pour conserver l’intégrité de la BD au cours de son cycle de
vie. Il existe des formes normales plus strictes : Boyce-Codd, quatrième
forme normale, ...
Analyse
désigne tout le travail de conception d’une base de données.
les méthodes de conception (UML, Merise) ont pour objectif de
modéliser des problèmes réels pour construire des applications.
elles traitent de la modélisation des données et des traitements
le modèle entité association (EA) permet de concevoir des bases
relationnelles en forme normale
elles sont découpées en différentes phases : étude préalable dont
analyse de l’existant, étude détaillée, réalisation et tests, implantation
et formation.
septembre 2013
20 / 143
BD relationnelle
Une base de données relationnelle est une base de données qui a été
définie relativement au modèle relationnel en satisfaisant les
propriétés de forme normale. La phase de conception est une tâche
complexe et de haut niveau.
une BD relationnelle est définie par un schéma relationnel :
I
I
I
les relations (ou tables). Une relation est définie par la liste des
attributs, le domaine de chaque attribut, la précision de la clé primaire ;
les associations (ou jointures) naturelles entre les tables ;
les contraintes d’intégrité : de domaine qui expriment des conditions
remplies par les valeurs d’un attribut, de structure sur les clés et de
référence qui expriment des propriétés pour les associations et des
contraintes liées à la dénormalisation.
septembre 2013
21 / 143
une BD simplifiée
CLIENTS(numclient, nom, prénom, ...)
COMMANDES(numcommande, datecommande, refclient, refvendeur)
LIGNECOMMANDES(refcommande, refproduit, quantité)
PRODUITS(numproduit, nom, couleur, ...)
VENDEURS(numvendeur, nom, prénom, ...)
contrainte de domaine : LIGNECOMMANDES.quantité est un entier >0
et <=100.
contrainte de structure : LIGNECOMMANDES.refcommande +
LIGNECOMMANDES.refproduit est la clé primaire de LIGNECOMMANDES
contrainte de référence : COMMANDES.refclient toujours défini et réfère à
un client existant. COMMANDES.refvendeur peut être non défini et s’il est
défini il réfère à un vendeur existant.
septembre 2013
22 / 143
BD en contexte réel
Considérations de volume
peut contenir plusieurs dizaines de tables, voire plusieurs centaines.
Les noms des tables et des champs peuvent être cryptiques ;
une table a en général plusieurs dizaines d’attributs, une table peut
avoir de plusieurs milliers à plusieurs millions de lignes.
La vision utilisateur
un utilisateur ne voit, en général, qu’une partie de la base grace à des
vues que l’on peut voir comme une requête qui vous montre une
partie compréhensible de la base de données
un utilisateur dispose alors de droits pour les actions de lecture
(interrogation), d’écriture (ajout, modification, suppression) sur les
éléments de la vue.
septembre 2013
23 / 143
SGBDR
Le logiciel de base pour les BD relationnelles sont les systèmes de
gestion de bases de données relationnelles – SGBDR .
Une BD relationnelle est gérée par un administrateur (DBA – database
administrator).
Les principaux SGBDR sont : Access sur micro-ordinateurs ; Oracle,
Informix, SQLserver en informatique de gestion d’entreprise ;
SQLite, Posgres dans le monde du Web.
Le SGBDR gére le stockage physique, assure la rapidité des accès,
l’indépendance des données et des applications, le contrôle de la
concurrence avec la gestion des transactions, assure la reprise sur
panne et la vérification des droits d’usage et d’accès.
Le SGBDR contient un moteur SQL
septembre 2013
24 / 143
SQL : LE langage des bases de données relationnelles
Le besoin
de séparer les données et les traitements pour manipuler
des bases de données complexes (un grand nombre de tables) et
volumineuses ;
dans des environnements hétérogènes : matériels et logiciels.
SQL
il est normalisé (normes SQL 2 et SQL 3) mais ... ;
c’est un langage algébrique basé sur le calcul relationnel ;
c’est un langage déclaratif : on décrit le résultat (pas l’algorithme) ;
il est composé de trois parties : le LDD : langage de définition des
données ; le LMD : langage de manipulation des données ; le LCD :
langage de contrôle des données.
septembre 2013
25 / 143
SQL - le langage de manipulation des données
Interroger une base de données relationnelle
avec SQL et l’instruction SELECT . C’est une instruction très riche
permettant la réalisation de requêtes complexes.
avec une interface graphique de conception des requêtes. Mais, une
interface repose sur un moteur SQL donc une requête SELECT SQL est
générée.
L’instruction SELECT
SELECT
attributs
expressions extraites
FROM expressions de tables
WHERE conditions de filtrage
GROUP BY conditions de groupe
HAVING conditions de filtrage sur les groupes
ORDER BY critères de tri
septembre 2013
26 / 143
écrire une requête SQL avec un SELECT
Pré-requis
bien connaı̂tre le modèle relationnel : tables, attributs, domaines des
attributs, clés primaires et clés étrangères ;
bien connaı̂tre sa sémantique : dictionnaire des données, modèles
entité-association et/ou UML.
Stratégie d’écriture
déterminer les relations et les jointures à réaliser dans la clause FROM
déterminer les champs à afficher avec répétition ou pas ;
déterminer les conditions limitant la recherche dans la clause WHERE ;
déterminer les groupes et les conditions sur les résultats ;
pensez à comprendre les opérations qui vont être faites, pensez à
valider la requête avec un expert du domaine en l’appliquant sur des
exemples, sur une base simplifiée.
septembre 2013
27 / 143
Plan
1
2
3
4
septembre 2013
28 / 143
Comment un moteur SQL calcule une requête SQL ?
Moteur SQL
désigne les processus qui transforment une requête SQL écrite dans un
langage déclaratif en un programme de calcul qui va prendre en entrée
l’état courant de la base de données et va produire en résultat la relation
résultat de la requête.
Exemple de requête et de calcul
SELECT c.numcommande, c.datecommande
FROM (COMMANDES c JOIN LIGNECOMMANDES l ON
c.numcommande=l.refcommande) JOIN
PRODUITS p ON l.refproduit = p.numproduit
WHERE p.couleur =’’rouge’’
Prendre des tables très simples en exemple et réfléchir à différentes façons
possibles de calculer la relation résultat.
septembre 2013
29 / 143
Les opérations du modèle relationnel
Le calcul des requêtes repose sur le calcul relationnel. Ce calcul est basé
sur 5 opérations de base :
1
la projection ou sélection verticale,
2
la sélection ou sélection horizontale,
3
le produit,
4
l’union,
5
la différence.
Ces opérations peuvent être combinées car elles portent sur des relations
et produisent des relations permettant de définir le langage SQL qui est le
langage d’interrogation de BD relationnelle.
septembre 2013
30 / 143
La projection
Définition
La projection ou sélection verticale prend en entrée une relation A et une
liste d’attributs de A et sort la relation restreinte à cette liste d’attributs.
Exemple
Dupont
1 35 Lille
Étant donné la table PERSONNEL : Gilleron 1 38 Lomme
Lemoine
30 Leers
et la projection : AGES=PROJECT(PERSONNEL) OVER Nom, Age, on
Dupont
35
obtient en résultat la relation : Gilleron 38
Lemoine
30
septembre 2013
31 / 143
La sélection
Définition
La sélection ou sélection horizontale prend en entrée une relation et une
expression logique portant sur des valeurs d’attributs et sort la relation
restreinte aux lignes qui satisfont l’expression logique (i.e. l’expression
logique est vraie).
Exemple
Dupont
1 35 Lille
Étant donné la table PERSONNEL : Gilleron 1 38 Lomme
Lemoine
30 Leers
la sélection : SELECT PERSONNEL WHERE Ville = ‘‘Lille’’, produit
en résultat la relation : Dupont 1 35 Lille
la sélection : SELECT PERSONNEL WHERE Ville = ‘‘Lomme’’ or
Gilleron 1 38 Lomme
Age=30, produit en résultat la relation :
Lemoine
30 Leers
septembre 2013
32 / 143
Le produit (1)
Pourquoi des opérations binaires
Les opérations de sélection horizontale et verticale sont des opérations
essentielles ;
elles peuvent être combinées ;
ce sont des opérations unaires (sur une table) ;
cependant, nous avons vu que, pour obtenir un modèle robuste, il était
recommandé d’éclater en plusieurs relations. Par exemple :
PRODUIT(numproduit, nomproduit, ..., numfournisseur)
FOURNISSEUR(numfournisseur, nomfournisseur, ...)
Il faut donc avoir également des opérations binaires sur les relations.
septembre 2013
33 / 143
Le produit (2)
Définition
Le produit est une opération binaire qui prend deux relations A et B en
entrée et produit en sortie la relation PRODUIT (A, B) ou A × B qui
correspond au produit cartésien.
Exemple
X
Y
1
5
×
1
2
5
M
N
N
xx
yy
zz
Attention : la taille de A × B est le
10 000 × 100 000 = 1 000 000 000.
X
X
X
=
Y
Y
Y
produit des tailles de
1 1
1 2
1 5
5 1
5 2
5 5
A et B
M
N
N
M
N
N
et
septembre 2013
xx
yy
zz
xx
yy
zz
34 / 143
L’union
Définition
L’union prend en entrée deux relations de même structure et sort une
relation de même structure en effectuant l’union ensembliste des lignes des
deux relations. On ne répète pas deux fois des lignes identiques.
Exemple
1
2
5
M
N
N
xx
yy
zz
∪
3
2
7
P
N
Q
zz
yy
xx
=
1
2
5
3
7
M
N
N
P
Q
septembre 2013
xx
yy
zz
zz
xx
35 / 143
La différence
Définition
La différence prend en entrée deux relations de même structure et sort une
relation de même structure en prenant toutes les lignes de la première
relation qui ne sont pas dans la seconde.
Exemple
1
2
5
3
7
M
N
N
P
Q
xx
yy
zz
zz
xx
–
1
7
M
Q
xx
xx
=
2
5
3
N
N
P
septembre 2013
yy
zz
zz
36 / 143
La jointure (1)
Définition
La jointure est une opération fondamentale qui prend deux tables A et B,
un attribut de A, un attribut de B et une condition logique liant un
attribut de A et un attribut de B.
Le résultat est une relation obtenue en juxtaposant les lignes de A et de B
pour lesquelles la condition est vraie.
Exemple
A JOIN B ON A.2=B.1
A:
X
Y
1
5
1
B: 2
5
M
N
N
xx
yy
zz
X
Y
1
5
M
N
septembre 2013
xx
zz
37 / 143
La jointure (2)
Fait
L’opération de jointure peut effectivement être définie à partir de la
sélection (horizontale), de la projection (sélection verticale) et du produit.
A titre de vérification par l’exemple, Considérons la jointure suivante :
R(1,2,3,4) ← A(1,2) JOIN B(1,2,3) ON A.2=B.1
Elle peut être définie par la séquence suivante : le produit
C(1,2,3,4,5) ← PRODUIT(A,B)
suivi de la sélection hrizontale
D(1,2,3,4,5) ← SELECT C WHERE C.2 = C.3
suivi de la projection
R(1,2,3,4) ← PROJECT D OVER D.1, D.2, D.4, D.5
septembre 2013
38 / 143
Algèbre relationnelle
Les cinq opérations de projection, sélection, produit, union et
différence permettent de définir un calcul sur les relations suffisant
pour l’interrogation de modèles relationnels ;
Les relations et les opérations forment l’algèbre relationnelle
TOUT EST RELATION : on effectue des opérations sur des relations
(ou tables), on produit des relations (ou tables) qui peuvent, à leur
tour, être utilisées dans de nouvelles opérations.
quelques opérations supplémentaires (par exemple, les opérations sur
les groupes) sont ajoutées pour obtenir un langage d’interrogation
plus riche.
septembre 2013
39 / 143
Gestion des performances
La norme SQL se limite à la définition, la manipulation et au contrôle
des données.
Pour une requête, on spécifie le résultat attendu dans un langage
logique déclaratif. On ne spécifie rien quant à la façon dont sera
effectué le calcul de le requête de manière à assurer des performances
satisfaisantes. Le moteur SQL tranforme la description en un calcul.
La gestion des performances est du ressort de l’administrateur de la
base de données et pas de l’utilisateur.
Cependant, un utilisateur averti doit connaı̂tre les optimisations
principales : définition de la requête et du plan de calcul, utilisation
d’index, ajout d’informations calculées dans la base.
septembre 2013
40 / 143
Modifier la requête et/ou son plan de calcul
Faits
Un même résultat peut être obtenu avec des requêtes différentes
Une même requête peut être calculée de différentes façons
Les moteurs SQL sont en général efficaces pour les requêtes simples
Si une requête est trop lente
Réfléchir à d’autres écritures de la requête : remplacer des clauses par
des requêtes imbriquées, remplacer une requête imbriquée par une
jointure, ... et voir si les performances s’améliorent
Vous pouvez regarder les plans de calcul générés par les requêtes pour
vous aider. Mais, modifier les plans de calcul est plutôt du ressort de
l’administrateur.
ce cours : définir un nouvel index
ce cours : dénormaliser le schéma relationnel
septembre 2013
41 / 143
Qu’est-ce qu’un index ?
Définition
Un index est une table à deux champs. Le premier est le champ sur lequel
porte l’index. Le second est le numéro d’enregistrement correspondant
dans la table. La table d’index est triée sur les valeurs du premier champ.
Exemple
Soit une table CLIENTS(numclient, nom, prénom, ...). Un index sur
le cham CLIENTS.nom est une table :
...
...
Dupond 135 487
Dupond 23 788
Dupont 357 302
...
...
septembre 2013
42 / 143
Intérêts et limites des index
Un index sur un champ permet un accès rapide sur les valeurs de ce
champ. En effet, le temps moyen d’accès à un élément est de N/2
sans index à comparer avec log2 N avec un index
Les index permettent d’accélérer les sélections horizontales et donc
aussi les jointures. Donc ils permettent d’accélérer les calculs de
requêtes.
MAIS
1
2
ils doivent être mis à jour (par le SGBDR) lors de toute mise à jour de
la table,
ils prennent de la place car c’est une nouvelle table. On parle de
compromis temps-espace.
septembre 2013
43 / 143
Définir un index ?
sur quels champs ?
règle 1 La table doit avoir un grand nombre de lignes
règle 2 l’attribut doit avoir beaucoup de valeurs différentes
règle 3 indexer les attributs servant aux jointures et donc les clés
primaires et clés étrangères (souvent fait par le SGBDR)
règle 4 indexer les attributs qui interviennent dans les clauses WHERE
et ORDER BY de requêtes très souvent exécutées
et pas tous les champs à cause du compromis temps-espace !
Optimiser une requête
Si une requête a un temps de calcul trop long, on peut voir si il ne serait
pas utile d’ajouter un index sur un des champs de la requête.
septembre 2013
44 / 143
Comment définir un index ?
par l’instruction CREATE [ UNIQUE ] INDEX name index ON
table ( column | ( expression ) [, ...] )
on peut créer un index sur un ou plusieurs attributs et même un
champ calculé, le déclarer unique ou pas
souvent en SQL des index sont créés par le SGBDR lors de la création
de la base de données pour les clés primaires, clés étrangères,
attributs précisés UNIQUE
septembre 2013
45 / 143
Revisiter la normalisation
Un modèle relationnel en forme normale permet, avec les propriétés
ACID des transactions, d’assurer la cohérence et l’intégrité d’une base
de données dans son cycle de vie ;
Ceci implique que les données soient non redondantes dans le modèle.
En particulier, une règle de conception affirme que : une donnée
calculée ne doit pas apparaı̂tre dans le modèle
Pour des questions d’efficacité, on peut déroger à cette règle et
dénormaliser le modèle. Mais, cette dénormalisation devra être
controlée et assurée à l’aide de contraintes d’intégrité
supplémentaires.
septembre 2013
46 / 143
Exemple classique
Soit (un extrait de) la BD relationnelle :
PRODUIT(numproduit, ...,prixproduitht, ...)
COMMANDE(numcommande, datecommande, ..., numclient)
LIGNECOMMANDE(numcommande, numproduit, ..., quantite)
Le montant de la commande peut être calculé et n’apparait pas pour des
raisons de normalisation. Mais de nombreuses requêtes (montant d’une
commande, montant total des commandes par période, par type de
produit, ...) nécessite son calcul. On peut alors dénormaliser le modèle et
l’ajouter.
COMMANDE(numcommande, datecommande, montantcommande, ...)
La cohérence devra alors être controlée par des contraintes d’intégrité.
Note : situation réelle plus complexe avec dates, réductions, promotions,
...
septembre 2013
47 / 143
Exemple emprunts
Soit (un extrait de) la BD relationnelle :
OEUVRE(numoeuvre, titre, isbn, ..., numediteur)
LIVRE(cotelivre, numoeuvre, dateachat, ...)
EMPRUNT(cotelivre, numadherent, datedebut, dateretour)
Le fait qu’un livre soit présent dans la bibliothèque ou emprunté peut être
calculé. On peut alors dénormaliser le modèle et ajouter un champ dans la
table des livres :
LIVRE(cotelivre, numoeuvre, dateachat, sorti, ...)
La cohérence devra alors être controlée par des contraintes d’intégrité : il
faudra vérifier lors de toute rentrée de livre que l’on met a jour
dateretour dans EMPRUNT mais aussi le champ sorti dans LIVRE. De
même pour tout emprunt.
septembre 2013
48 / 143
Conclusion sur l’optimisation
de requêtes SQL
Essayer d’écrire différemment votre requête (vous) ;
Regarder le plan de calcul (vous et DBA) ;
Voir si un index peut être ajouté (DBA) ;
Voir si on peut dénormaliser le schéma mais modification très
importante car modifie le schéma de la base (DBA).
de calculs de rapport
On peut agir sur la requête nécessaire au calcul du rapport.
On peut précalculer la requête et importer les résultats.
On peut agir sur le rapport.
septembre 2013
49 / 143
Plan
1
2
3
4
septembre 2013
50 / 143
BD relationnelle
Une base de données relationnelle est une base de données définie
relativement au modèle relationnel.
une BD relationnelle est définie par un schéma relationnel :
I
I
I
les relations (ou tables). Une relation est définie par la liste des
attributs, le domaine de chaque attribut, la précision de la clé primaire ;
les associations (ou jointures) naturelles entre les tables ;
les contraintes d’intégrité (plus tard dans ce cours, maintenant ! ).
septembre 2013
51 / 143
La nécessité de contraintes
une base de données relationnelle en forme normale permet d’assurer
la consistance des données
à condition que les propriétés assurant la forme normale soient
vérifiées lors des évolutions de la base de données.
ces propriétés qui doivent être vérifiées par la base de données sont les
les contraintes d’intégrité
Souvent s’ajoutent des contraintes spécifiques à la base de données
considérée.
septembre 2013
52 / 143
Les contraintes d’intégrité
les contraintes d’intégrité de domaine : vérifier que les valeurs d’un
attribut appartiennent à un domaine de valeurs
les contraintes d’intégrité de structure ou d’entité : vérifier que la clé
primaire et les clés candidates sont toujours définies par une valeur
unique
les contraintes d’intégrité référentielles : elles sont relatives aux
jointures naturelles entre les tables du modèle.
les autres contraintes : sont relatives à des propriétés particulières de
la base ou à la vérification de règles de gestion sur plusieurs tables.
septembre 2013
53 / 143
Le LDD
Le langage de définition des données est l’ensemble des instructions
SQL permettant la création d’une base de données relationnelles :
I
I
I
I
I
I
la création des tables,
et donc des attributs,
les contraintes de domaine,
les contraintes de structure,
les contraintes de référence,
les contraintes spécifiques.
les instructions principales sont : CREATE TABLE, ALTER TABLE,
DROP TABLE
septembre 2013
54 / 143
La création de tables
CREATE TABLE table name
(
column name data type [DEFAULT default exp]
[column constraint],
column name data type [DEFAULT default exp]
[column constraint],
[...]
[table constraint] [...]
)
construit une table vide dans la base de données courante avec pour
propriétaire celui qui exécute l’instruction.
septembre 2013
55 / 143
La création de tables
l’exécution de l’instruction
CREATE TABLE CLIENTS (
numclient INTEGER,
nom VARCHAR(20), prenom VARCHAR(20),
datenaissance DATE
numrue INTEGER, nomrue VARCHAR(40),
codepostal CHAR(5), ville VARCHAR(20),
typeclient VARCHAR(16) )
crée une table CLIENTS dans la base courante. La table est définie avec ses
attributs et leur type mais il faut aussi préciser les contraintes d’intégrité.
septembre 2013
56 / 143
Donner une valeur par défaut
on peut spécifier une valeur par défaut par l’intermédiaire de DEFAULT.
la valeur par défaut est du même type que l’attribut
si on ajoute une ligne sans préciser la valeur de cet attribut, c’est la
valeur par défaut qui est donnée, sinon, c’est la valeur NULL.
on utilise DEFAULT pour éviter des saisies inutiles (la date du jour
pour une commande, particulier pour l’attribut type de client)
on utilise DEFAULT pour incrémenter une séquence de type entier pour
une clé primaire
septembre 2013
57 / 143
La contrainte de domaine NOT NULL
l’attribut considéré ne peut pas prendre la valeur NULL , on lui impose
d’avoir une valeur.
pour les champs qui doivent avoir une valeur (un nom de client)
pour les clés étrangères dont la valeur doit être obligatoirement
renseignée (la référence du client faisant une commande)
la vérification est effectuée lors de toute action sur la valeur de cet
attribut dans une ligne de la table. L’ajout ou la mise à jour est
refusée si une valeur NULL est affectée.
en son absence, la valeur NULL est autorisée
septembre 2013
58 / 143
La contrainte de domaine UNIQUE
elle permet de préciser qu’un attribut a une valeur unique
cette contrainte est utilisée pour les clés candidates
il est conseillé de l’associer à la contrainte de domaine NOT NULL
la vérification est effectuée lors de toute action sur la valeur de cet
attribut dans une ligne de la table. L’ajout ou la mise à jour est
refusée si la contrainte est violée
il est conseillé de donner un nom à toute contrainte pour que le
message d’erreur soit compréhensible
on peut avoir une clause UNIQUE portant sur plusieurs champs
septembre 2013
59 / 143
autres contraintes de domaine
On peut spécifier des contraintes de domaine plus complexes portant sur
un ou plusieurs attributs d’une même table à l’aide de la clause CHECK
précisée après le type du champ si elle porte sur un attribut
(contrainte d’attribut), après la définition des attributs si elle porte
sur plusieurs attributs (contrainte de table).
le type de client est limité aux valeurs particulier, administration,
grand compte et pme
le prix de vente est supérieur au prix d’achat
la date de commande est inféreure à la date de livraison
septembre 2013
60 / 143
définir un domaine
Il est fréquent que plusieurs attributs de tables d’une même base de
données soient construits sur les mêmes domaines. On peut définir
des domaines à l’aide de l’instruction CREATE DOMAIN
définir un domaine pour des quantités d’articles :
CREATE DOMAIN quantite INTEGER
DEFAULT 0
CHECK (VALUE >=0)
Il suffit alors d’utiliser le nom du domaine pour définir un attribut
comme on utilise un type existant.
septembre 2013
61 / 143
contraintes d’intégrité de structure
Également appelées contraintes d’intégrité d’entité, elles permettent
de préciser la clé primaire de la table.
Grâce à la contrainte PRIMARY KEY
Elle vérifie que la clé primaire est toujours définie et a une valeur
unique et est donc équivalente à la conjonction des contraintes NOT
NULL et UNIQUE
précisée après le type du champ si elle porte sur un attribut
(contrainte d’attribut), après la définition des attributs si elle porte
sur plusieurs attributs (contrainte de table)
septembre 2013
62 / 143
contraintes d’intégrité de référence
Elles permettent de vérifier que les liaisons ou jointures naturelles entre les
tables sont correctement définies. Elles sont donc essentielles à la
correction d’une base de données relationnelle. Quelques rappels :
clé étrangère : attribut ou groupe d’attributs d’une table T1 dont les
valeurs doivent exister comme valeurs de la clé primaire (ou
candidate) d’une table T2 (non nécessairement distincte de T1)
table qui référence : la table T1 qui contient la clé étrangère, parfois
appelée table secondaire
table référencée : la table T2 qui contient la clé primaire (ou
candidate) à laquelle la clé étrangère fait référence, parfois appelée
table primaire
septembre 2013
63 / 143
du côté de la table qui référence
Il faut contrôler l’ajout d’une nouvelle ligne et donc d’une nouvelle
valeur de cette clé étrangère
Il faut contrôler la modification de cette clé étrangère
Il faut vérifier que la valeur donnée à la clé étrangère existe dans la
table référencée. Pour cela :
I
I
I
I
contrôler les saisies
écrire une fonction par le programmeur
assurer le contrôle par le SGBDR
exécuter un “trigger”
septembre 2013
64 / 143
la clause REFERENCES
Elle permet de déléguer au SGBDR le contrôle d’intégrité de référence
sa syntaxe : REFERENCES nom table référencée
[(cle candidate)]
si le nom de la table est seul, il est supposé que c’est la clé primaire
qui est référencée.
Effet : lors de tout ajout ou modification, la nouvelle valeur est
recherchée dans la table référencée. Si cette valeur n’existe pas, le
SGBDR refusera l’ajout ou modification
Note : les clauses REFERENCES et NOT NULL sont complémentaires
mais différentes.
septembre 2013
65 / 143
la clause FOREIGN KEY
Elle permet de déléguer au SGBDR le contrôle d’intégrité de référence
sa syntaxe : FOREIGN KEY cle etrangere REFERENCES
nom table référencée [(cle candidate)]
cette clause est utilisée comme contrainte de table, c’est-à-dire, après
la définition des attributs. Son utilisation est obligatoire si la clé
étrangère est constituée de plusieurs attributs.
Effet : identique
septembre 2013
66 / 143
du côté de la table référencée (1)
On peut être amené à modifier ou à supprimer la valeur de la clé
primaire de la table référencée :
I
I
supprimer un client ou
modifier un numéro de client
Que faire pour les lignes qui faisaient référence à cette valeur :
I
I
les commandes faisant référence au client supprimé ou
les commandes faisant référence au client dont on change le numéro
septembre 2013
67 / 143
Différentes attitudes sont possibles :
I
I
I
interdire toute suppression ou modification ;
interdire toute suppression ;
autoriser suppression et modification.
Si on autorise, il faut dire les actions à mener en cas de suppression et
en cas de modification.
Un SGBDR et SQL permettent de préciser ces autorisations et ces
actions
septembre 2013
68 / 143
La clause REFERENCES peut être complétée par les clauses ON DELETE
et ON UPDATE
En cas de modification ou de suppression d’une valeur de clé
étrangère de la table référencée, quatre possibilités :
I
I
I
I
NO ACTION : interdire
CASCADE : autoriser et propager
SET NULL : autoriser et mettre à NULL
SET DEFAULT : autoriser et mettre à valeur par défaut
par défaut les suppressions et modifications sont interdites si la clause
REFERENCES est présente
septembre 2013
69 / 143
autres contraintes
contraintes de domaine : sur un attribut d’une table ou plusieurs
attributs d’une même table
contraintes d’entité : sur la clé primaire d’une table
contraintes de référence : sur la clé étrangère d’une table en lien avec
les valeurs de la clé primaire référencée
les autres contraintes servent :
I
I
à vérifier au niveau de la BD des règles de gestion
à vérifier la consistance lorsque la base contient des redondances.
septembre 2013
70 / 143
assertions et triggers
assertions : permettent d’exprimer des contraintes ne portant pas sur
une table en particulier : le prix de vente d’un article dans une
commande ne peut pas avoir obtenu une réduction supérieure à 20%
du prix catalogue
les assertions ne sont pas supportées par PostgreSQL.
triggers : suite d’instructions SQL ou procédure compilée qui
s’exécute automatiquement chaque fois que l’événement déclenchant
associé se produit : à chaque ajout d’une ligne de livraison mettre à
jour la quantité livrée dans la ligne de commande correspondante
les triggers ont un grand pouvoir d’expression : les contraintes
“classiques” sont implantées avec des triggers.
septembre 2013
71 / 143
exemple de trigger
à chaque ajout d’une ligne de livraison mettre à jour la quantité livrée
dans la ligne de commande correspondante
CREATE TRIGGER calcultotalqtelivreesiajoutlivraison
AFTER INSERT ON ligneslivraisons
UPDATE lignescommandes SET quantiteliv =
(SELECT SUM(ligneslivraisons.quantiteliv) FROM
ligneslivraisons
WHERE ligneslivraisons.refcommande=
lignescommandes.refcommande
AND ligneslivraisons.refarticle =
lignescommandes.refarticle)
septembre 2013
72 / 143
base des ventes et livraisons (1)
CREATE TABLE magasins
(nummagasin INTEGER CONSTRAINT PRIM MAGASINS PRIMARY KEY,
ville VARCHAR(25) NOT NULL,
gerant VARCHAR(20) ) ;
CREATE TABLE fournisseurs
(numfournisseur INTEGER CONSTRAINT PRIM FOURNISSEURS
PRIMARY KEY,
nom VARCHAR(25) CONSTRAINT NOM UNIQUE FOURNISSEURS NOT NULL
UNIQUE,
ville VARCHAR(20), pays VARCHAR(20) ) ;
septembre 2013
73 / 143
CREATE TABLE clients
(numclient INTEGER CONSTRAINT PRIM CLIENTS PRIMARY KEY ,
nom VARCHAR(20) NOT NULL,
prenom VARCHAR(20),
codepostal CHAR(5),
ville VARCHAR(25) NOT NULL,
pays VARCHAR(20),
ca INTEGER DEFAULT 0,
type VARCHAR(16) DEFAULT ’particulier’
CONSTRAINT TYPE CLIENT CHECK (type IN (’particulier’,
’administration’, ’grand compte’, ’pme’)) CONSTRAINT
TYPE CLIENT ) ;
septembre 2013
74 / 143
CREATE TABLE articles
(numarticle INTEGER PRIMARY KEY CONSTRAINT PRIM ARTICLES,
nom VARCHAR(20) NOT NULL,
poids NUMERIC(10,1), couleur VARCHAR(20),
stock INTEGER NOT NULL DEFAULT 0 CONSTRAINT STOCK ARTICLES
CHECK (stock >=0),
prixachat INTEGER NOT NULL,
prixvente INTEGER NOT NULL,
reffournisseur INTEGER CONSTRAINT ARTICLES REF FOURNISSEURS
REFERENCES fournisseurs ON UPDATE CASCADE ON DELETE SET
NULL
CHECK (prixvente >= prixachat /0.9) CONSTRAINT
PVPA ARTICLES) ;
septembre 2013
75 / 143
CREATE TABLE commandes
(numcommande INTEGER PRIMARY KEY CONSTRAINT PRIM COMMANDES,
date DATE NOT NULL,
refclient INTEGER NOT NULL CONSTRAINT COMMANDES REF CLIENTS
REFERENCES clients ON UPDATE CASCADE ON DELETE NO ACTION
refmagasin INTEGER NOT NULL CONSTRAINT
COMMANDES REF MAGASINS REFERENCES magasins ON UPDATE CASCADE
ON DELETE NO ACTION ) ;
septembre 2013
76 / 143
CREATE TABLE lignescommandes
(refcommande INTEGER NOT NULL, refarticle INTEGER NOT NULL,
quantitecom INTEGER NOT NULL, quantiteliv INTEGER NOT NULL,
prixventecom INTEGER NOT NULL, dateprevueliv DATE,
CONSTRAINT PKLC PRIMARY KEY (refcommande, refarticle),
CONSTRAINT FKLCRC FOREIGN KEY refcommande REFERENCES
commandes ON UPDATE CASCADE ON DELETE CASCADE,
CONSTRAINT FKLCRA FOREIGN KEY refarticle REFERENCES
articles ON UPDATE CASCADE ON DELETE NO ACTION,
CONSTRAINT QLC CHECK (quantiteliv <= quantitecom) ) ;
septembre 2013
77 / 143
CREATE TABLE livraisons
(numlivraison INTEGER PRIMARY KEY CONSTRAINT
PRIM LIVRAISONS,
date DATE DEFAULT CURRENT DATE,
refclient INTEGER REFERENCES clients ON UPDATE CASCADE ON
DELETE NO ACTION CONSTRAINT LIVRAISONS REF CLIENTS
refmagasin INTEGER REFERENCES magasins ON UPDATE CASCADE ON
DELETE NO ACTION CONSTRAINT LIVRAISONS REF MAGASINS) ;
septembre 2013
78 / 143
CREATE TABLE ligneslivraisons
(reflivraison INTEGER NOT NULL,
refarticle INTEGER NOT NULL,
quantiteliv INTEGER NOT NULL CONSTRAINT QLV CHECK
(quantiteliv >=0) ,
refcommande INTEGER NOT NULL,
CONSTRAINT PKLV PRIMARY KEY (reflivraison, refarticle),
CONSTRAINT FKLVL FOREIGN KEY reflivraison REFERENCES
livraisons ON UPDATE CASCADE ON DELETE CASCADE,
CONSTRAINT FKLVA FOREIGN KEY refarticle REFERENCES articles
ON UPDATE CASCADE ON DELETE NO ACTION ,
CONSTRAINT FKLVLC FOREIGN KEY (refcommande, refarticle)
REFERENCES lignescommandes ON UPDATE CASCADE ON DELETE
CASCADE) ;
septembre 2013
79 / 143
Plan
1
2
3
4
septembre 2013
80 / 143
Architecture d’une BD dans un SGBDR
le serveur de bases de données
Sur ce serveur est implanté un SGBDR .
il faut se connecter au serveur en précisant un nom d’utilisateur et
une base de données avec une connexion sécurisée, la connexion peut
être transparente à l’utilisateur,
après connexion, on entre dans une session où il est possible de se
connecter à une autre base de données.
hiérarchie des objets
1
un serveur contient des bases de données et les informations sur les
utilisateurs
2
une base de données ou catalogue est constituée d’un ensemble de
schémas
3
un schéma contient des éléments : tables, contraintes, vues,
septembre 2013
81 / 143
Les utilisateurs dans un serveur de BDR
ils sont créés et définis au niveau du serveur, leur nom peut être
différent de leur nom système,
le mot de passe est, en général, différent du mot de passe système et
doit être suffisamment complexe
à ce niveau un utilisateur peut se voir attribuer les droits (voir
ci-après)
Instructions SQL
les instructions de gestion des utilisateurs sont : CREATE USER et
ALTER USER
les instructions de gestion des bases de données sont CREATE
DATABASE et ALTER DATABASE. Il faut alors créer tous les objets et
les renseigner. Le créateur d’une base possède tous les droits de
création puis d’usage de tous les objets de la base.
septembre 2013
82 / 143
les schémas dans une BDR
Intérêt des schémas et leur usage
pour organiser la base en sous-ensembles logiques pour une gestion
plus facile et pour éviter des interactions entre utilisateurs d’une
même base de données
les schémas sont contenus dans les bases de données (ou catalogues)
et contiennent les tables, vues, ...
par défaut, le schéma public existe et contient tous les objets créés,
le schéma pg catalog lui contient les tables systèmes.
Instructions SQL
On crée les schémas par l’instruction CREATE SCHEMA, puis les objets
dans chacun des schémas,
on attribue des droits au niveau des schémas, par exemple, de
création de tables dans le schéma.
septembre 2013
83 / 143
Les vues dans une BDR
Pourquoi les vues
les bases de données relationnelles contiennent des schémas, un grand
nombre de tables, des clés primaires et étrangères pour les jointures,
des informations “techniques”, des contraintes d’intégrité, ...
cette complexité n’est pas à la portée d’un utilisateur de base, et
même d’un utilisateur averti que vous êtes.
Objectifs des vues
elles permettent de donner à l’utilisateur une vue simplifiée de la base :
on restreint sa vision aux seules informations pertinentes au vu de sa
fonction
avec une une image globale dans son langage plus concrète et plus
claire,
on montre à l’utilisateur des relations sans qu’il ait conscience du
calcul effectué
septembre 2013
84 / 143
Implantation des vues dans une BDR
Principes des vues
une vue est dynamique,
une vue a une définition logique,
elle est recalculée lors de toute utilisation,
par conséquent toute modification sur les tables de base sera
répercutée sur la vue
Les vues en SQL
CREATE VIEW [(liste de colonnes)] AS
expression de table, où expression de table est une clause
SELECT. Par défaut, les noms de colonnes sont hérités des noms des
attributs des tables mais on peut renommer dans le langage métier,
on peut supprimer une vue, on peut définir des requêtes basées sur
des vues, on peut définir des vues basées sur des vues
septembre 2013
85 / 143
Vues modifiables et conclusion
Peut-on modifier avec une vue ?
Les vues définies à partir de SELECT permettent d’extraire facilement
de l’information par leur simple exécution,
La norme précise les règles pour qu’une vue soit modifiable sans
risque pour la cohérence de la BDR,
pour une vue modifiable, il faut préciser le comportement vis à vis des
ajout, mise à jour et suppression,
Les dialectes SQL acceptent ou pas les vues modifiables
Conclusion sur les vues
Le concept de vue permet de définir des schémas externes pour
l’utilisateur constitués d’un ensemble de vues au travers desquels il voit la
base de données. Les avantages principaux des vues sont : personnalisation
de la base de données, simplification, confidentialité des données,
indépendance entre applications et définition de la base.
septembre 2013
86 / 143
Les droits
Les différents droits et non droits
Dans un environnement multi-utilisateurs, vous avez des droits
au niveau système : poste de travail, le réseau, les applications, ...
au niveau du serveur de bases de données : authentification, droits de
connexion, de création, ...
au niveau des objets d’un schéma ou d’une base de données : tables,
vues, requêtes, mises à jour, ...
Principes généraux
le super-utilisateur (superuser) a tous les privilèges sur tous les
objets,
le créateur d’un objet possède tous les privilèges sur cet objet,
Un utilisateur ne peut effectuer une opération que s’il possède les
droits ou privilèges appropriés pour cette opération
le possesseur de la base (et le superutilisateur) doit attribuer des
privilèges aux autres utilisateurs,
qui eux-mêmes ... septembre 2013
87 / 143
La gestion des privilèges
au niveau utilisateur ou groupe d’utilisateurs
les utilisateurs peuvent être organisés en groupes, ces groupes
correspondent à des fonctions logiques dans l’entreprise,
avec les instructions CREATE GROUP et ALTER GROUP,
on peut alors attribuer des privilèges au groupe, le groupe PUBLIC
correspond à l’ensemble des utilisateurs.
Instructions d’attribution de privilèges en SQL
attribuer : GRANT privilege ON objet nom objet TO
liste utilisateurs [WITH GRANT OPTION],
enlever : REVOKE [GRANT OPTION FOR] privilege ON objet
nom objet TO liste utilisateurs,
les privilèges à attribuer dépendent de l’objet, la liste d’utilisateurs
peut contenir des groupes,
on peut combiner l’utilisation de ces deux instructions
septembre 2013
88 / 143
Quels privilèges ?
bases et schémas
dans une BD, le privilège CREATE permet de créer des schémas dans
la base de données,
dans un schéma, le privilège USAGE permet l’accès aux objets du
schéma, le privilège CREATE permet de créer des objets dans le schéma
tables et vues
le privilège SELECT donne accès à toutes les colonnes
le privilège INSERT pour insérer des lignes
le privilège DELETE pour supprimer des lignes
le privilège REFERENCES pour créer une contrainte de référence. Il faut
posséder ce privilège sur les deux tables
le privilège TRIGGER pour créer des “triggers”
La clause WITH GRANT OPTION permet de transférer les privilèges
attribués
septembre 2013
89 / 143
L’accès aux données dans un SGBDR
les schémas permettent de découper une base en sous-ensembles
logiques
les vues permettent de donner à chaque utilisateur un accès simplifié
sur les données utiles à ses fonctions
les privilèges permettent de gérer finement les droits d’accès aux
données
une utilisation conjointe des schémas, vues et privilèges permet
d’atteindre une grande souplesse pour l’accès facilité et sécurisé aux
données
les groupes sont également très utiles
septembre 2013
90 / 143
Un point d’étape
Nous venons de parcourir divers éléments proches de l’administration d’un
SGBDR à connaı̂tre pour un utilisateur avisé :
la notion de serveur de bases de données
les notions de schémas, vues, privilèges et groupes
les questions de performances
le dictionnaire des données contient toutes les informations sur les
utilisateurs et leurs privilèges, les schémas, les tables, clés, index,
contraintes, triggers, ...
Il nous reste à étudier les problèmes liés à la concurrence
septembre 2013
91 / 143
Plan
1
2
3
4
septembre 2013
92 / 143
SGBDR et concurrence
Composants d’un SGBDR
un moteur relationnel responsable de toutes les opérations sur les
données,
un dictionnaire des données contenant la description de toutes les
données,
un système de gestion des transactions permettant d’assurer que les
données restent intègres (cohérentes) quels que soient les événements.
Sysème de gestion des transactions
En effet, le modèle relationnel a été défini pour assurer l’intégrité des
données d’une base de données. Mais, il faut prendre en compte :
les pannes : défaillance technique, erreur de programmation, ... Un
SGBDR doit être tolérant aux pannes
la concurrence : la base est utilisée simultanément par plusieurs
utilisateurs. Un SGBDR doit gérer la concurrence
septembre 2013
93 / 143
Les transactions
Définition d’une transaction
Une application est constituée de groupes d’opérations.
Certains groupes d’opérations forment des unités logiques indivisibles
pour conserver l’intégrité des données relativement au respect de
règles de gestion du domaine et au respect de contraintes sur la base
de données,
une transaction est un groupe d’opérations tel que :
I
I
soit toutes les opérations sont effectuées
soit aucune ne l’est
Les transactions en SQL
Une transaction débute par l’instruction BEGIN, elle se termine
I
I
soit par COMMIT : toutes les opérations sont effectuées et enregistrées
soit par ROLLBACK : toutes les opérations sont annullées (défaites) et
on retrouve l’état initial.
Par défaut, toute instruction SQL est une transaction
septembre 2013
94 / 143
Les transactions pour récupérer les pannes
la base de données est sauvegardée régulièrement
le gestionnaire des transactions doit mémoriser l’état de toutes les
transactions
En cas de panne :
I
I
I
on récupère la dernière sauvegarde
on reconstruit toutes les transactions terminées
on annulle toutes les transactions qui étaient en cours
septembre 2013
95 / 143
Les transactions pour gérer la concurrence
Les transactions sont un élément important pour la gestion de la
concurrence
On pourrait penser à effectuer une transaction à la fois mais les
performances seraient catastrophiques !
Plusieurs (un grand nombre de) transactions doivent pouvoir
s’exécuter simultanément, il faut donc étudier le comportement de
transactions s’exécutant en parallèle
Les trois cas d’incohérence
la lecture inconsistante (dirty read) : lire des données non validées
la lecture non répétitive (nonrepeatable read) : deux lectures
successives donnent des résultats différents
la lecture fantôme (phantom read) : des données apparaissent et
disparaissent lors de lectures successives
septembre 2013
96 / 143
La lecture inconsistante
peut se produire lorsque deux transactions s’exécutent en parallèle selon le
schéma suivant :
transaction 1
select ligne 1
actions
transaction 2
Update ligne 1
ROLLBACK
on lit une valeur temporaire non validée. la lecture inconsistante est une
anomalie grave : faire croire qu’une propriété est vérifiée et engendrer des
actions menant à des incohérences
septembre 2013
97 / 143
La lecture non répétitive
schéma suivant :
transaction 1
select ligne 1
actions
select ligne 1
transaction 2
update ligne 1 ; COMMIT
On lit deux fois une même ligne avec des résultats différents dans la même
transaction.
septembre 2013
98 / 143
La lecture fantôme
schéma suivant :
transaction 1
select propriété
transaction 2
update ligne extraite
delete ligne extraite
select propriété
une transaction qui calcule deux fois un ensemble de lignes vérifiant une
condition ne trouvera pas les mêmes lignes
septembre 2013
99 / 143
Les solutions
Les niveaux d’isolation
On associe à toute transaction un niveau d’isolation :
READ UNCOMMITTED : pas d’isolation
READ COMMITTED : pas de lecture inconsistante
REPEATABLE READ : pas de lecture non répétitive
SERIALIZABLE : pas de lecture fantôme
Le choix est souvent entre READ COMMITTED et SERIALIZABLE. Si le
second est le plus sur, il peut y avoir dégradation des performances.
Les méthodes
une solution est l’utilisation de verrous. On verrouille un (bloc d’)
enregistrement, une table pendant le temps de la transaction,
attention au verrou mortel.
une autre solution est l’utilisation de versions. Chaque transaction
travaille sur une copie virtuelle de la base, copies à synchroniser.
septembre 2013
100 / 143
La concurrence
Une transaction est une suite d’instructions indissociables
Il existe différents niveaux d’isolation
Il faut un compromis entre isolation maximale et performances
Il existe des mécanismes pour éviter les verrous mortels
Le système de gestion des transactions est un élément essentiel d’un
SGBDR,
tout particulièrement les systèmes transactionnels comme la
réservation de billets de train, par exemple.
septembre 2013
101 / 143
Plan
1
2
3
4
septembre 2013
102 / 143
Critiques du modèle relationnel
Évolutivité
Quelle que soit la qualité de l’analyse, les besoins et donc les données
évoluent et les schémas doivent intégrer ces changements. Mais le
modèle relationnel est peu évolutif.
La question de l’intégration de données est un secteur d’activités à
part entière des entreprises.
Efficacité
La masse des données à analyser et à gérer est de plus en plus importante
et on voit apparaı̂tre : réseaux sociaux, Web, capteurs, ... d’où
informatique décisionnelle pour l’analyse de grands jeux de données et
le phénomène Big data pour la gestion et l’analyse de masses de
données.
septembre 2013
103 / 143
Évolutivité : cas agence de voyages
Des exemples d’évolution
On souhaite garder mémoire du mode d’inscription avec la forte
évolution du Web.
On souhaite offrir la possibilité aux clients de poser des options sur
des voyages.
On souhaite mémoriser les transports associés à un voyage.
On souhaite intégrer un nouveau voyagiste qui gère des voyages “à la
carte”, c’est-à-dire où le client choisit des prestations : avion,
transferts, hotels.
Implications de l’évolution d’un schéma
Une migration des données en accord avec le nouveau schéma
(intégration de données)
Une réécriture de toutes les applications (requêtes, programmes)
affectées par cette évolution.
septembre 2013
104 / 143
Efficacité et analyse : cas agence de voyages
Des exemples de requête décisionnelle
Donner le nombre voyages par destination sur tous les mois de 2013
Donner le CA par voyagiste sur les 5 dernières années
Comparer le nombre de voyages par région de client et mode
d’inscription au voyage.
Constatation liées à ces besoins
On peut répondre à ces requêtes mais
Ces requêtes peuvent être complexes à écrire et sont peu lisibles pour
un utilisateur
elles demandent du temps de calcul et peuvent nuire au bon
fonctionnement du système opérationnel
septembre 2013
105 / 143
Plan
1
2
3
4
septembre 2013
106 / 143
modèle relationnel et modèle en étoile
Modèle relationnel
Assurer l’intégrité des données dans un contexte multi-utilisateurs et
d’informatique opérationnelle : gérer les clients, les inscriptions, les
voyages et les circuits.
modèle basé sur tables (pour les entités) et jointures (pour les
associations) avec la notion de forme normale
Modèle en étoile
Permettre d’effectuer de façon efficace des analyses pour produire des
rapports en vue de la prise de décision
modèle basé sur la notion de faits et dimensions où un fait est toute
quantité qu’on souhaite analyser et une dimension est un axe
d’analyse
septembre 2013
107 / 143
Modèle en étoile : le cas voyage
Faits et dimensions
fait : une inscription à un voyage avec son prix
dimension : temporelle (toujours), géographique, client, vendeur, type
de voyage.
Exemple de modèle
FAITVOYAGE(refjour, reflieu, refclient, refvendeur, refvoyage,
prixvoyage)
JOURS(numjour, nomjour, débutWE ?, débutvacances ?, ...)
LIEUX(numlieu, nomlieu, typeclimat, pays, continent,
nomregiontouristique, ...)
CLIENTS(numclient, nom, prénom, adresse, codepostal, ...)
VENDEURS(numvendeur, nomvendeur, prénomvendeur, agence)
VOYAGES(numvoyage, intitulé, durée, numcatalogue, nomvoyagiste,
typevoyage, niveauconfort, gammeprix, ...)
septembre 2013
108 / 143
Modèle en étoile et informatique décisionnelle
Nécessite l’intégration des données du modèle relationnel (et
d’autres) avec des outils d’ETL (Extraction Treatment Loading)
vers des magasins de données (datamart) inclus dans des entrepôts de
données (datawarehouse)
avec des suites logicielles adaptées et
des outils pour la production de rapports : documents contenant des
analyses croisées souvent avec interactions possibles (drill-down et
drill-up) basés sur des requêtes en général écrites en SQL et
des outils de fouille de données (classification ou clustering,
classification supervisée).
septembre 2013
109 / 143
Plan
1
2
3
4
septembre 2013
110 / 143
Nouveaux besoins en gestion de données
Évolution des données
Apparition de très grandes plate-formes autour du Web : recherche
d’information, réseaux sociaux, bases de documents, twitter, ...
Volume considérable de données liées au Web, à la mémorisation de
documents (textes, rapports, images, vidéos, ...) et aux capteurs
(compteurs intelligents, télésurveillance, ...)
Données évolutives sans structure connue à l’avance
Évolution des besoins en gestion de données
Nécessité de répartir les données pour maintenir les performances
malgré la masse des données et
nécessité de gérer des données hétérogènes et évolutives.
septembre 2013
111 / 143
Nouvelles solutions
Le constat et les solutions
Les SGBDR ne sont pas adaptés en terme de performance,
d’évolutivité et de flexibilité pour le traitement de données évolutives
à grande échelle dans un contexte distribué.
D’où l’appartition de nouveaux paradigmes de gestion de données, en
particulier NoSQL “Not only SQL”, mais aussi NewSQL entre autres.
Plan du cours
1
parenthèse sur les collections (clé,valeur)
2
gestion de données distribuées (théorème CAP)
3
calculs sur des données distribuées (Map Reduce)
4
les modèles de données NoSQL
septembre 2013
112 / 143
Collection (clé,valeur)
Définition
est une collection constituée de paires (clé,valeur) telles que chaque
clé apparaı̂t au plus une fois dans la collection,
aussi nommée associative array, dictionary, collection, (key, value)
pairs, tableaux associatifs, dictionnaires, ...
exemples
clé = numéro du client, valeur = informations sur le client dans la
table des clients
clé = nom+prénom+email, valeur = informations sur un membre
d’un réseau social
clé = titre d’un morceau de musique, valeur = nombre d’écoutes et
descriptions des dernières écoutes
septembre 2013
113 / 143
Opérations et implantation
Opérations
lookup : trouver la valeur associée à une clé
add : ajouter une paire
remove : retirer une paire
reassign : modifier la valeur d’une paire
Implantation
Les opérations, en particulier le lookup, doivent être efficaces
une liste pour une petite collection, un tableau pour une collection
avec des clés entières en nombre raisonnable,
le plus souvent un tableau et une fonction de hachage,
mais aussi une répartition des valeurs sur des machines pour de très
grandes collections.
septembre 2013
114 / 143
Introduction aux tables de hachage
Hash table et hash function - définition idéale
Une table de hachage est constituée d’un tableau indexé par des entiers
contenant les valeurs et d’une fonction de hachage qui à chaque clé associe
l’indice entier où se trouve la valeur correspondante dans le tableau.
Exercice
Que peut être une fonction de hachage sur les noms et prénoms de
client ? Que peut-il se produire si on ajoute de nouveaux éléments ?
Pensez-vous pouvoir éviter les conflits ?
Quel est le temps d’accès (lookup) à une valeur ? Comparer à une
recherche linéaire et dichotomique.
septembre 2013
115 / 143
Tables de hachage
Hash table et hash function
Une table de hachage est constituée d’un tableau indexé par des
entiers contenant les valeurs et d’une fonction de hachage qui à
chaque clé associe l’entier où peut être trouvée rapidement la valeur
correspondante à la clé.
systèmes éprouvés et efficaces avec gestion des ajouts, suppressions et
conflits assurant un lookup en temps constant car les valeurs
correspondant à une même valeur d’index sont en nombre borné par
une constante.
Les techniques ont été étendues pour gérer la répartition des données
sur plusieurs machines dans des réseaux.
septembre 2013
116 / 143
Gestion de données distribuées
Système distribué
système logiciel qui permet de coordonner de nombreuses machines
souvent dans un même réseau local (LAN)
communiquant par l’échange de messages
avec des machines peu spécialisées pouvant être retirées (pannes) ou
ajoutées (besoins supplémentaires en capacité)
pour les données distribuées
système de gestion de données distribuées est un cas particulier de
système distribué
pour assurer des accès efficaces avec des volumes de données très
importants
tout en assurant l’accès même en cas d’indisponibilité de machines
septembre 2013
117 / 143
Exemple des data centers
Data center
est découpé en racks (machines avec liaison réseau rapide 1Go/sec),
eux-mêmes interconnectés par des routeurs (switches) avec liaison à
100 Mo/sec.
Les data centers peuvent être connectés (2-3 Mo/sec)
Exemple : 1 data center de Google : environ 125 racks, 1 rack = environ
40 machines, soit environ 5000 serveurs. On estime à environ 200 data
centers soit un million de serveurs pour Google.
septembre 2013
118 / 143
Deux stratégies de gestion de données distribuées
Distribution des traitements
Les programmes de traitement sont répartis sur les machines,
on envoie les données sur les machines qui réalisent les traitements
C’est un scénario de type workflow (chaı̂nes de traitement), par exemple
avec des Web services.
Distribution des données
Les données sont réparties sur les machines,
on envoie les programmes vers les machines pour traiter les données
C’est le scénario pour les masses de données réparties. En effet, il est plus
efficace d’échanger des programmes (plus courts) quand les données sont
très volumineuses. Pour NoSQL, ceci est réalisé avec le paradigme Map
Reduce présenté ci-après.
septembre 2013
119 / 143
Propriétés des systèmes de gestion de données distribuées
Consistency (cohérence) : tous les noeuds du système voient
exactement les mêmes données au même moment.
Availability (disponibilité) : la perte d’un noeud du système
n’empêche pas le système de fonctionner.
Partition Tolerance : le système continue de fonctionner en cas de
rupture de communication entre deux noeuds.
Exercice sur distribution simpliste
Discuter les 3 propriétés pour une base de users répartie comme suit
toute la base sur un seul noeud : A-Z,
la base répartie sur 2 noeuds : A-L ; M-Z,
la base dupliquée sur 2 noeuds : A-Z, A-Z.
septembre 2013
120 / 143
Théorème CAP
Dans un système de gestion de données distribuées, il est impossible
d’assurer les trois propriétés C(onsistency), A(vailability) et P(artition
Tolerance) en même temps
septembre 2013
121 / 143
Distribution pour les SGBDR et les bases NoSQL
Un SGBD distribué doit toujours assurer la “Partition Tolerance” donc on
a deux types principaux de SGBD distribué :
SGBDR
choisit d’assurer les propriétés C(onsistency) + (P)artition Tolerance
en vérifiant les propriétés ACID (Atomicité, Cohérence, Isolation et
Durabilité) en raison des besoins des BDs transactionnelles,
ceci au détriment de l’efficacité et avec des schémas peu évolutifs
Bases NoSQL
choisit d’assurer les propriétés A(vailability) + (P)artition Tolerance,
pour assurer des performances d’accès à des masses de données,
ceci au détriment de la cohérence des données (pas de gestion des
transactions) et avec des schémas absents ou évolutifs.
septembre 2013
122 / 143
Principes des bases NoSQL
Bases NoSQL
pas de schéma figé,
on privilégie lecture à écriture et pas de gestion des transactions,
pas de langage d’interrogation standard mais écrire des programmes
adaptés aux données.
Bases NoSQL et partitionnement
Assurer les propriétés A(vailability) + (P)artition Tolerance,
forte distribution des données avec des techniques de partitionnement
sophistiquées (sharding, consistent hashing, ...)
et un paradigme de calcul parallèle adapté aux masses de données
distribuées : Map reduce
septembre 2013
123 / 143
Map Reduce
est un
paradigme de calcul distribué pour traiter des masses de données,
par distribution des traitements sur les serveurs de données.
Il a été conçu par Google mais est basé sur des modèles bien étudiés
de programmation parallèle.
Caractéristiques
permet de répartir la charge sur de nombreux serveurs, augmenter le
nombre de serveurs augmente la rapidité de traitement,
abstrait l’infrastructure matérielle pour le programmeur en traitant le
cluster, la répartition de la charge, la distribution des données, la
tolérance aux pannes, ...,
est disponible dans de nombreux environnements de programmation.
septembre 2013
124 / 143
Map Reduce
Programmation
Le travail du programmeur pour un calcul (un programme complexe peut
nécessiter plusieurs calculs) se limite à l’écriture de deux fonctions
Map : fait des calculs élémentaires sur des paires (clé,valeur) et
retourne une liste de résultats intermédiaires,
Reduce : combine les listes de résultats intermédiaires en une liste de
résultats finaux.
exemple en recherche d’information
Le score du célèbre moteur de recherche d’information Google
contient une composante basée sur la fréquence d’apparition des mots
dans les documents
Il faut donc être capable, en particulier, de calculer le nombre
d’apparitions des mots dans l’ensemble des documents du Web ! ! !
septembre 2013
125 / 143
Map Reduce par l’exemple
Fonction Map de calcul du nombre d’occurences
entrée : identifiant d’un document, contenu d’un document
sortie : liste des mots avec leur nombre d’occurence
Que se passe-t-il sur un noeud Map ?
On produit une liste de la forme ((base : 2), ..., (réparti : 3), ..., (xml : 1))
pour chacun des documents du noeud.
et après ?
Ces listes reçues des différents noeuds sont regroupées et triées par mot
pour produire des listes : (base, 1, 2, 1, 2, ...), ..., (réparti, 1, 1, 3, ...), ...
et enfin la fonction Reduce
entrée : mot, liste des nombres d’occurences du mot dans les documents
sortie : liste des mots avec leur nombre d’occurence total
septembre 2013
126 / 143
Principes généraux de Map Reduce
Fonctionnement
la distribution des programmes Map et des données est géré par
l’environnement, les noeuds exécutent les Map,
l’environnement gère le groupement, le tri, la distribution des listes
résultats et des programmes Reduce, les noeuds exécutent les
programmes Reduce
l’environnement gère la collecte des résultats des Reduce.
Tout est géré avec des systèmes (clé,valeur) répartis
Applications du paradigme
les calculs de score en recherche d’information,
les calculs de règles d’association (panier de la ménagère) pour les
grands jeux de transactions
la détection de spam, les réseaux sociaux, la fouille du web, ...
septembre 2013
127 / 143
Plan
1
2
3
4
septembre 2013
128 / 143
Quatre modèles principaux
Dans l’ordre de la présentation dans ce cours :
bases clé-valeur
bases document
bases graphe
bases colonne
septembre 2013
129 / 143
Principes des bases clé-valeur
Définition
chaque objet de la base est identifié par une clé unique. C’est le seul
moyen d’accès à l’objet
la structure de l’objet est libre. Les traitements sur l’objet sont laissés
à la charge du programmeur
Les 4 opérations CRUD des bases NoSQL clé-valeur
Create : créer une paire, create(clé,valeur)
Read : lire une valeur à partir de la clé, read(clé)
Update : met à jour une valeur à partir de la clé, update(clé,valeur)
Delete : supprime une paire à partir de la clé, delete(clé)
septembre 2013
130 / 143
Les bases clé-valeur
Utilisations et implantations
masses de données avec des besoins de requêtage simple comme les
sessions Web et les fichiers de log, les profils utilisateurs, les données
de capteurs, ...
bases : Amazon Dynamo, Riak, Redis, Voldemort
Critiques
modèle simple, bonne mise à l’échelle, disponibilité, évolutivité des
valeurs (sous réserve d’adapter les programmes de traitement),
modèle trop simple, interrogation seulement sur la clé, la complexité
éventuelle des valeurs doit être gérée par des programmes et donc une
couche applicative complexe si les valeurs sont trop complexes.
septembre 2013
131 / 143
Principes des bases document
Définition
Elles sont basées sur les bases clé-valeur,
la valeur est un document semi-structuré hiérarchique de type JSON
ou XML, i.e. un document a une structure arborescente sans schéma
figé
Les opérations des bases documents
Les opérations CRUD du modèle clé-valeur,
augmentées de capacités de requêtage sur le contenu des documents
et de vues.
septembre 2013
132 / 143
Exemple de document semi-structuré XML
<?xml version="1.0" encoding="ISO-8859-1"?>
<BIBLIO SUBJECT="XML">
<BOOK ISBN="9782212090819" LANG="fr" SUBJECT="applications
<AUTHOR>
<FIRSTNAME>Jean-Christophe</FIRSTNAME>
<LASTNAME>Bernadac</LASTNAME> </AUTHOR>
<AUTHOR>
<FIRSTNAME>François</FIRSTNAME>
<LASTNAME>Knab</LASTNAME> </AUTHOR>
<TITLE>Construire une application XML</TITLE>
<PUBLISHER>
<NAME>Eyrolles</NAME>
<PLACE>Paris</PLACE> </PUBLISHER>
<DATEPUB>1999</DATEPUB> </BOOK>
<BOOK ISBN="9782212090529" LANG="fr" SUBJECT="général">
<AUTHOR>
septembre 2013
133 / 143
Exemple de document semi-structuré JSON
{
"data": [
{ "id": "X999_Y999",
"from": {"name": "Tom Brady", "id": "X12"},
"message": "Looking forward to 2010!",
"actions": [
{ "name": "Comment",
"link": "http://www.facebook.com/X999/posts/Y99
},
{ "name": "Like",
"link": "http://www.facebook.com/X999/posts/Y99
}
],
"type": "status",
"created_time": "2010-08-02T21:27:44+0000",
"updated_time": "2010-08-02T21:27:44+0000"
},
septembre 2013
134 / 143
Les bases document
les outils de gestion de contenu (CMS), catalogues de produits,
analyse du Web, ...
bases : CouchDB, RavenDB, MongoDB, Terrastore
Critiques
modèle simple augmenté de la richesse des documents
semi-structurés, bonne mise à l’échelle, expressivité des requêtes,
efficace pour les interrogations par clé mais peut être limité pour les
interrogations par le contenu des documents, limité aux données
hiérarchiques.
septembre 2013
135 / 143
Principes des bases graphe
Définition
Elles permettent de manipuler des données de triplets de la forme
(sujet, prédicat objet) représentables sous forme de graphes orientés,
on utilise du (clé,valeur) pour accéder rapidement d’un objet aux
couples (prédicat, sujet) qui le concerne (aux arcs sortant du noeud),
d’un prédicat aux couples (objet, sujet), d’un sujet aux couples (objet,
prédicat).
Les opérations des bases graphes
Le langage SPARQL est un langage avec une syntaxe inspirée de SQL
qui permet l’interrogation en utilisant des variables dans des
expressions de triplets ou de chemins
Exemple : SELECT ?vil ?pop WHERE ?vil rdf :type d :Settlement
. ?vil d :mayor ?o. ?vil d :country :France . ?vil d :populationTotal ?pop
. FILTER( ?pop > 100 000)
septembre 2013
136 / 143
Exemple de graphe de relations sociales
septembre 2013
137 / 143
vu comme des triplets (s,p,o)
<http://semprog.com/people/colin> foaf:name "Colin Evans".
<http://semprog.com/people/colin> rdf:type foaf:Person.
<http://semprog.com/people/colin> foaf:mbox <mailto:colin@semp
<http://kiwitobes.com/toby.rdf#ts> foaf:homepage <http://kiwit
<http://kiwitobes.com/toby.rdf#ts> foaf:nick "kiwitobes".
<http://kiwitobes.com/toby.rdf#ts> rdf:type foaf:Person.
<http://kiwitobes.com/toby.rdf#ts> foaf:knows <http://semprog.
<http://kiwitobes.com/toby.rdf#ts> foaf:knows _:x3.
<http://kiwitobes.com/toby.rdf#ts> foaf:interest <http://sempr
<http://kiwitobes.com/toby.rdf#ts> foaf:mbox <mailto:toby@sega
<http://kiwitobes.com/toby.rdf#ts> foaf:name "Toby Segaran".
<http://semprog.com> rdf:label "Semantic Programming".
<http://semprog.com> rdf:type foaf:Document.
_:x3 foaf:name "Jamie Taylor".
_:x3 rdf:type foaf:Person.
_:x3 foaf:mbox <mailto:[email protected]>.
septembre 2013
138 / 143
Les bases graphe
les réseaux sociaux, le Web sémantique (knowledge graph de Google),
les open data, les données cartographiques, ...
bases : Neo4J, OrientDB, ...
Critiques
modèle riche et évolutif (ajout de sujets, d’objets et de prédicats) bien
adapté aux situations oùil faut modéliser beaucoup de relations, un
langage d’interrogation généraliste (SPARQL) et des langages
spécialisés
répartition des données peut être problématique pour des masses de
triplets.
septembre 2013
139 / 143
Principes des bases colonne
Définition
Les données sont stockées en colonne,
une colonne est une entité de base représentant un champ de donnée,
chaque colonne est définie par un couple (clé,valeur),
les colonnes peuvent être groupées en supercolonnes et en famille de
colonnes, les colonnes sont regroupées par ligne
chaque ligne est identifiée par un identifiant unique et un nom unique
Les opérations des bases graphes
les requêtes doivent être prédéfinies en fonction de l’organisation en
colonnes (et supercolonnes et familles de colonnes) choisie.
septembre 2013
140 / 143
Exemple de base colonnes
septembre 2013
141 / 143
Les bases colonne
la journalisation d’événements, les analyses de clientèle et la
recommandation, ...
bases : HBase, Cassandra, SimpleDB, ...
Critiques
modèle efficace avec indexation sur les colonnes en particulier pour les
requêtes de calcul de type OLAP, supporte des données tabulaires à
schéma variable,
ne supporte pas les données structurées complexes, efficaces pour des
requêtes temps réel connues à l’avance, la modification de structures
en colonnes nécessite de la maintenance
septembre 2013
142 / 143
Conclusion sur les bases NoSQL
Leur intérêt
l’interrogation de masses de données à structure hétérogène et
évolutive,
trois modèles (clé,valeur), colonne et document avec des structures
de données simples, tabulaires et hiérarchiques,
un modèle graphe pour les données fortement interdépendantes.
Les principes sous-jacents
la répartition des données,
l’utilisation de collections (clé,valeur) réparties,
l’utilisation du paradigme Map reduce pour les calculs de requêtes.
septembre 2013
143 / 143

Bases de données avancées

Transcription

Documents pareils

Editer ce classement sous format PDF

portail miashs - Université Lyon 2

WEB Sémantique

pl cl fl bl gl

Chapitre V Les bases de données relationnelles en pratique : Mise

La population étudiante de Lille 3 en chiffres

Bon de Souscription - Association LA CLE

Fiche syst`eme d`assainissement 2014 St

mentionmiashs - Université Lyon 2

Peugeot 508 SW