Module 1 - Université Laval

Transcription

André Gamache professeur associé, Département d'informatique et de génie logiciel
Faculté des sciences et de génie, Université Laval. Québec, Qc, Canada, G1K 7P4
Introduction
Quelques lacunes de la technologie relationnelle
‐‐ Le modèle relationnel ouvre la voie au modèle objet ‐‐
et
Les nouvelles technologies pour la gestion des données sans égard à leur type (NoSQL) André Gamache, professeur associé
Département d'informatique et de génie logiciel
Faculté des sciences et de génie
Université Laval. Québec, Qc, Canada, G1K 7P4
Courriel: [email protected]
2016-09-03 ©
Lacunes du MR
Module 1 page 1
Rappel de quelques concepts généraux de l’architecture système et de la technologie relationnelle La technologie des BD concerne au premier chef le SGBD et la base de données.
Lacunes du MR
Module 1 page 2
Page 1
Module 1
Vue en tiers de l'exploitation des données avec un SGBD (architecture client‐serveur)
Architecture générale de l'implantation d'un système d’information avec
une technologie 2-tiers (client-serveur). Le lien peut être connecté ou
déconnecté (avec un parallélisme plus grand d’accès aux données)
niveau 2
niveau 1
Traitement : accès
aux données
Machine 2 : serveur
Machine 1
Traitement de la requête :
obtention des données de la
BD
Stockage des données et
préservation de la cohérence de la
base par les triggers et méthodes
Interface Utilisateur
Logique d’application : calculs sur les données et affichage sont faits sur le poste-client par
l'applicatif. Exemples: validation des saisies et calculs locaux (logique de métier).
Lacunes du MR
Module 1 page 3
Logique des traitements
(2‐tiers/niveaux)
niveau 1 (tiers 1- client)
• Niveau Interface(côté client): Gestion des fenêtres: Swing, AWT, browser ou Windows, …
capture et validation des données, traitement des données : calculs sur les données saisies
et affichage des données en provenance de la base.
niveau 2 (tiers 2) Client/Serveur (application « stateless ou stateful »)
Fonction traitement (côté serveur) : par le SGBD: Interprétation de la requête reçue,
recherche, calcul, et écriture dans la base (avec validation des contraintes) …
-- Le SGBD est un acteur majeur à ce niveau et TCP est un protocole très souvent mis à
contribution (d’autres ont été utilisés)
• Fonction stockage (côté serveur) : rangement rapide, persistant et cohérent des données
(validation).
Le SGBD et le système de gestion de fichiers ont des rôles significatifs et complémentaires.
La cohérence de la base est capitale! Éventuellement prise en charge par le « cloud ».
Lacunes du MR
Module 1 page 4
Page 2
Module 1
Couches versus tiers
-
Notion de couche réfère à du logiciel développé en
strates.
- Celle de tiers réfère à du hardware et des protocoles
de communication
Plusieurs couches de logiciel concentrées sur une seule
machine peut être une implantation selon 1-tiers.
L’application est sur une machine et le logiciel d’accès aux
données sur une autre, c’est une implantation 2-tiers.
Le Cloud computing sous-tend l’architecture en tiers et un
partage étendu des ressources informationnelles.
Lacunes du MR
Module 1 page 5
Architecture 3‐tiers • tiers 1: La gestion de la capture , de la vérification syntaxique et de l’affichage
effectuées localement du côté de l’application-utilisateur (applicatif faisant appel
à Windows, Swing, …). Une application « stateless » plus simple à développer
(i.e. sans « cookies » ou l’équivalent).
• tiers 2: La logique de validation et de calcul de l’applicatif (dite de métier) est
transférée sur un autre serveur dit d'applications.
• L'applicatif fait appel à des packages , méthodes et procédures de niveau 2.
Ex. Le calcul de la charge d’une structure architecturale complexe en un point donné.
• tiers 3: La logique de recherche et de stockage, validation globale (règles
d'entreprise),… sur le serveur de BD; SGBD mis à contribution.
Module à l’écoute pour
recevoir les paramètres
du tiers 1
client
Call procP1( ) ou
Transfert par http
Logique de
validation
des
applications
BD
Données + procédures
de calcul (méthodes)
SGBD
objet1.ajout( ) appel méthode ajoutajout( )
Tiers 1
Lacunes du MR
Tiers 3
Tiers 2
Module 1 page 6
Page 3
Module 1
Couche, niveau, tiers … (rappel)
Organiser un logiciel en couches n'oblige pas de limiter exclusivement la communication entre les couches adjacentes n et n+1! Un logiciel organisé en tiers sous‐tend la communication entre des serveurs différents (exclusion du tout placé sur une seule machine). Le « cloud » étant considéré comme un ou plusieurs Big Serveur (de données et d’applications) forcément distants, en clusters et transparents aux utilisateurs. Des protocoles de communication sont nécessaires pour échanger des informations entre tiers. La sécurité devient alors un facteur critique.
Différence entre couche et tiers tient au fait que placé sur une même machine un système en couches sous‐tend un mode de communication (par pipes, sockets, …) différent (sans l’exclure) celui pour la communication inter‐
machine (socket + protocole) (TCP/IP, http) pour le tiers. Lacunes du MR
Module 1 page 7
Architecture Web‐Serveur (3‐tiers)
Mise en service d’un serveur WEB à l’écoute sur un port • Tiers 1 : La gestion de la capture (validation locale plus rapide,…) et de l’affichage
effectuées localement avec un fureteur (browser). JavaScript, Ajax, applet, …
• Tiers 2: La logique de validation de l’applicatif est transférée sur un autre serveur qui
est à l’écoute des requêtes HTML traitées par la suite par des packages spécialisés
de Oracle. Ex. A partir d'un salaire brut et des charges pour une personne, en
déduire le montant maximum d'un prêt.
• Tiers 3: La recherche, validation globale (règles d'entreprise), cohérence du modèle,
couche implémentée entièrement sur le serveur de BD. La communication faite avec
JDBC, SQLJ, …
Serveur-Web
http:..
Browser
Page Web
Tiers 1
Réception des
requêtes HTML
et logique de
validation
des
applications
SGBD
Calcul de la
réponse
à chaque requête
ou DML avec
validation des
contraintes de la
base
appel méthode ajout( )
Tiers 2
bd
Données et
procédures
Toutes les données sont centralisées
sur un même serveur: Se prête mal à
une exploitation par cluster.
Tiers 3
Lacunes du MR
Module 1 page 8
Page 4
Module 1
Exploitation via le WEB favorise la répartition des données et
favorise le clustering : pas le relationnel
Données stockées en cluster: une BD pour
chaque grande fonction d’exploitation sur des
machines différentes.
Les données sont regroupées
comme un nœud d’intégration.
Exploitation en cluster difficile.
BD Ventes
Système Vente
Services WEB: un pour les ventes et un autre pour l’inventaire
Intégration par une BD centralisée
Système Inventaire
BD Inventaire
Le clustering des données facilite l’exploitation des
grands volumes de données.
Le modèle relationnel ne se prête pas facilement en raison de l’éclatement des données
imposée par la normalisation.
Lacunes du MR
Module 1 page 9
Web-server de Oracle avec le PL/SQL
Source: Oracle PL/SQL Web Application
Source: Oracle documentation
Une application WEB (1) fait appel à un ensemble de procédures PL/SQL stockées (2) qui
interagissent avec la base pour obtenir des données transmises au browser web via HTTP au
moyen des pages html générées par des procédures PL/SQL cataloguées. Ces pages
affichées sont celles qui de l’interface de l’utilisateur.
Le web Tool kit se charge des accès à la base de données avec le DML ou les méthodes prédéfinies via le module mod_plsql de Oracle.
Oracle® Database Advanced Application Developer's Guide 11g Release 1 (11.1) Doc. B28424-03
Lacunes du MR
Module 1 page 10
Page 5
Module 1
Gateway : mod_plsql
Affichage des résultats via un fureteur
Les données d’une réponse calculée peuvent être transmises à un client soit sous la
forme de pages web créées dynamiquement (et donc affichées par le fureteur
connaissant le nom du fichier correspondant à cette page web), soit sous la forme de
documents XML. Dans ce dernier cas, le fichier XML est transmis au fureteur qui en
interprète les balises XML et affiche correctement la page web.
Dans les deux cas, les procédures cataloguées (stockées) en PL/SQL sont utilisées
pour composer les pages réponses.
Lacunes du MR
Module 1 page 11
Interaction avec une application en langage de 3e génération
Une application peut prendre en charge la gestion de l’affichage des données et
d’interagir avec le serveur via JDBC.
Les données transférées peuvent avoir deux formes:
1- des données typées compatibles avec ceux du langage de l’application
2- des objets de la BD à la condition que les structures d’objets du
langage s’y prêtes.
Dans le cas de la réception d’objets de la BD, leur manipulation se fera avec les
méthodes définies pour l’objet dans le langage.
Par exemple:
Si les objets sont reçus dans des structures définies par le langages java, ces objets
seront manipulés par les méthodes définies dans l’application JAVA et non par les
méthodes propres à la BD objet.
Lacunes du MR
Module 1 page 12
Page 6
Module 1
L’environnement SGBD: agent critique de l’intégrité
Une exploitation WEB transfert entièrement le contrôle et
le maintien de l’intégrité de la base au SGBD.
L’application WEB prend à sa charge les validations
syntaxiques (et bientôt sémantiques?) et transfère le contrôle
entier au SGBD.
Donc:
•Il est critique d’implanter un modèle de données avec
toutes ses contraintes complexes et d’en garantir sans
faille la cohérence.
•Assurer que les accès aux données peu importe l’origine
soient faits exclusivement par des procédures certifiées
(et en objet par des méthodes).
Lacunes du MR
Module 1 page 13
L’informatique nuagique
Source web : Developpez.com 24 février 2016 par Guillaume Sigui
Lacunes du MR
Module 1 page 14
Page 7
Module 1
Différentes formules * de services en nuage
* Source web : Developpez.com 24 février 2016 par Guillaume Sigui
Responsabilité
de l’entreprise
Lacunes du MR
Module 1 page 15
Différentes Formules
Les possibilités offertes par chaque offre se récapitulent comme suit :
IAAS : Infrastructure As A Service: est l'offre de bas niveau (en nuage) qui consiste
à offrir la couche matérielle (caractéristiques serveurs : processeurs, mémoire,
stockage, réseau) sans le système d'exploitation, ni les applications ; (2 dernières
sous la responsabilité du fournisseur)
PASS: Platform As A Service: le système d'exploitation et des outils
d'administration. Elle se distingue des solutions des offres d'hébergement Web
classiques, par sa modularité et son élasticité à s'adapter aux besoins, avec une
possibilité de consommer à la carte ;
(7 dernières sous la responsabilité du fournisseur)
SAAS : Software As A Service: offre complète qui propose la couche applicative
prête à l'emploi. (toutes sous la responsabilité du fournisseur)
Lacunes du MR
Module 1 page 16
Page 8
Module 1
Contraintes spécifiques à chaque site (du cluster)
Dans un contexte de Cloud Computing, les sites exploitant la même base (en formule SAAS) doivent
pouvoir gérer leurs ensembles de contraintes, distinctes pour chaque site en sus de celles partagées par
tous les sites et les applications. Le traitement différentié des données s’impose tout comme leur
certification par une autorité centrale.
Contraintes indépendantes du site + contraintes spécifiques à chaque site
Site 1 avec en sus quelques contraintes particulières au site 1
Données et applications
Site 3
Site 2 avec en sus quelques contraintes particulières au site 2
Le site 3 peut recevoir les pièces que si les 2/3 commandées sont disponibles. Le site 1 peut se faire livrer partiellement des pièces même si elle est partielle
Le site 2 réceptionne les pièces que si toutes sont disponibles Contraintes c1
et c3
spécifique au
site 1
Contrainte c2
spécifique au
site 2
** Les triggers ne sont pas en mesure de gérer efficacement leur déclenchement pour certains sites et non pour
d’autres. Les méthodes de la BD rendus accessibles à des sites particuliers peuvent assurer cette gestion.
Lacunes du MR
Module 1 page 17
Communication entre les SGBD et les langages de programmation
Tous les SGBD fournissent des interfaces API pour permettre aux
applications dans différents langages de communiquer avec le SGBD via
l’insertion de clauses SQL:
1- SQL en Java avec JDBC (Java DataBase Connectivity)
2- SQL avec C avec l’API Pro*C de Oracle
3- ODBC pour les applications de MS Windows (+ ODBC)
Les interfaces de ODBC et JDBC sont connus comme des drivers :
type 1 à 4.
Un problème important dans cette communication est l’appariement et
l’intégration des types de données usagers : entre ceux de la base et ceux
implémentés dans les langages (natifs) de développement. Le mismatch
est parfois surprenant par son ampleur. Des outils de conversion
automatique existent et sont offerts par les éditeurs de SGBD!
Lacunes du MR
Module 1 page 18
Page 9
Module 1
SGBD et Modèles de données Divers SGBD :
Mono utilisateur, multi utilisateur, centralisé avec persistance des
données, transactions courtes et longues, bases et calculs en treillis
(répartition; grid), avec un capacité déductive, …
Diverses modèles de données :
1. Hiérarchique et réseau (IMS, IDS)
2. Relationnel (SQLServer*, Oracle*, ..)
3.
4.
56-
Mixe: Objet + relationnel (DB2, Oracle 10g +, ..)
Objet (Caché, Jasmine, O2, GemStone, Objectivity, …)
Déductif (Validity)
Base NoSQL
La convergence des technologies : BD, IA, WEB progresse lentement
en raison des coûts et de l’importance du legacy (systèmes existants)…
• La place relative dans le marché : Oracle, SQLServer, …
Lacunes du MR
Module 1 page 19
Lacunes de la technologie relationnelle pour l’implantation
stricte des modèles
Certaines de ces lacunes seront prises en charge par la technologie objet
Lacunes du MR
Module 1 page 20
Page 10
Module 1
Représentation complexe du réel avec le relationnel
Représentation conceptuelle distante du réel. La modélisation fournit de
nombreuses relations, en rupture avec le réel, qui est souvent plus simple.
Localisation:
noEq*
ville
Equipe
(noEq*, lesMembres : {nas,nom, position}, ville)
réel
Equipier:
nas*
Une seule Entité bien réelle
L’accès à une équipe sera réalisée par 2 accès à des
tables relationnelles
nom
position
noEq
2 relations ou tables comme
représentation informatique ??
Lacunes du MR
Module 1 page 21
Surcharge sémantique
•Les éléments du modèle relationnel (MR) sont souvent polysémiques:
une table peut représenter à la fois une classe UML ou/ et une Association!
Tout le conceptuel est modélisé en relationnel que par des relations (tables) :
EX.: 2 Entités + 1 Association (1..*) modélisées que par 2 relations (!)
=> Perte du nom de l’association
Departement
noDep* : int
Personne
1
Travaille
1..*
ville
nas* : string
nom : string
UML
Association Travaille
Personne:
Departement:
noDep*
ville
nas*
nom
noDep
MR
Lacunes du MR
Module 1 page 22
Page 11
Module 1
Double association entre deux classes:
renommage de certains attributs
La transformation du diagramme de classe en MR :
Employe
nasE*: int
nomE: varchar2
Projet
0..1
* <TravaillePerm
0..1
*
< TravailleTemp
noP*: int
siteP: varchar2
budgetP: number
Le passage au relationnel se fait en créant deux clés étrangères qui réfèrent au
noP de la classe Projet, mais qui sont absentes dans le diagramme de classe UML.
Ces deux clés étrangères doivent avoir un libellé différent, ce qui oblige à
renommer la clé principale afin d’avoir deux clés étrangères distinctes dans la
même table: noPP pour les projets des travailleurs permanents et noPT pour les
Rendu des 2 associations
travailleurs temporaires:
Employe (nasE* , nomE, noPP, noPT)
Projet (noP*, siteP, budgetP)
Le domaine de noPP peut être différent de celui de noPT
Lacunes du MR
Module 1 page 23
Accès à des tuples par les clauses SQL de l’application • Une table relationnelle correspond à une seule structure de données. L’accès aux
tuples est fait que par Select, Insert, Update, …. Aucun accès direct à une donnée
particulière correspondant à une colonne. Après avoir eu accès à un tuple, la
projection sur une colonne demandée par une application peut être faite pour avoir
obtenir la donnée recherchée.
Ex.: Après une fusion de la BD d’entreprises E1 et E2, il y a partage des mêmes
noDep. Il faut augmenter ceux de E2 par 1000 pour les distinguer. De nouveaux
employés doivent être associés au noDep de E1 et ceux de E2 à noDep +1000.
Par exemple, En l’absence de l’indexation, l’obtention de la ville d’un département où
travaille les employés « Sirois » sous-tend le transfert de tuples entiers de Personne
suivi d’une jointure avec Departement terminée par une projection sur ville.
Personne:
Departement:
noDep*
ville
nas*
nom
age
noDep
Solution : Obtenir les département où travaillent les Sirois sans faire de jointure et terminer par
la projection.
Lacunes du MR
Module 1 page 24
Page 12
Module 1
Contraintes d’intégrité : Entité et Référentielle des systèmes relationnels
• Contraintes d’Entité (découlant de la clé primaire) avec les contraintes
référentielles facultatives. Les deux peuvent être implémentées dans le schéma
relationnel de la BD.
• Si pas de CR définies => intégrité fragilisée !!!
==> Cohérences du parent et de l‘enfant en péril!
Create table Personne (
nas char(9) not null, nom varchar(45) not null,
age number(3) null check (age between 0 and 100), noDep int,
noDep number (3) check (noDep is not null),
Constraint cp_Personne Primary Key (nas),
Constraint fk_PersonneDepartement Foreign Key (noDep) References
Departement (noDep) On Delete CASCADE) ;
Si un département est supprimé, il entraîne la suppression des personnes associées.
Une personne ne pouvant pas être inscrite sans travailler dans un département.
Sans définition de FK, alors absence de la contrainte ! Et le travail de validation de
la cohérence est alors à faire dans l’application! (différent avec SET NULL).
*** L’approche objet implémentera avec certains systèmes les mêmes contraintes. ***
Lacunes du MR
Module 1 page 25
Contrainte sémantique élémentaire seulement • Contrainte sémantique du domaine absente ou difficile à définir dans le
schéma des systèmes relationnels : il faut donc les prévoir dans les
applications ou avec les triggers. Source d’erreurs!
Exemple : Inscription seulement des personnes non étudiantes
Create table Personne (
nas char(9) not null,
Clause très souvent interdite par les SGBD
nom varchar(45) not null Check (nom NOT IN
(Select nom From RegistreEtudiant Where statut = ‘l’)),
age number(3) null Check (age between 0 and 100),
noDep int,
Constraint cp_Personne Primary Key (nas),
Constraint fk_PersonneDepartement Foreign Key (noDep) References
Departement (noDep) On Delete CASCADE) ;
L’ajout de personnes non étudiantes est difficile à contrôler avec le relationnel! Le
Check est parfois oublié ou plus souvent la clause est interdite par le langage DDL.
Lacunes du MR
Module 1 page 26
Page 13
Module 1
Contrainte Globale d’entreprise : CG
•Absence dans le MR de triggers et de contraintes globales intégrées
(CG) => validation à faire par toutes les applications ( ==>source
d'erreurs)
Ex: 3 tables d’équipements dans la base :
EquipementRepris, (r)
EquipementConsigne, (p)
EquipementCommande (c)
Tous ces équipements sont stockés dans le même entrepôt dont la
capacité totale est de x pièces: r + p + c = ≤ x
Chaque application doit alors vérifier obligatoirement dans une transaction la
capacité de rangement disponible dans l’entrepôt pour chaque transaction
traitée.
CG : Toute transaction, peu importe l’application doit déclencher la vérification
d’une CG, soit : r + p + c = ≤ x
CG : le total des équipements après toute transaction <= capacité de l’entrepôt
Chaque application est responsable de cette vérification sinon incohérence potentielle.
Lacunes du MR
Module 1 page 27
Structure homogène et atomique du MR
Le MR assume l’homogénéité horizontale et verticale des tuples (lignes)
d’une même table :
• Horizontale : chaque tuple est composé d’une valeur atomique pour
chaque attribut. Donc absence de variabilité du nombre de valeurs pour
chaque attribut.
Ex.: attribut salaire représente qu’une seule valeur, impossible d’associer
l’historique des salaires d'un employé.
• Verticale : les valeurs d’une même colonne proviennent obligatoirement
d’un seul domaine atomique : syntaxique et/ou sémantique.
Ex.: une adresse peut être composée de plusieurs valeurs {no, rue, ville,
codePostal} du type struct mais une autre seulement d’une rue et d’un code
Postal.
Les deux adresses doivent pouvoir être utilisées malgré une structure différente
d’un tuple à l’autre.
Lacunes du MR
Module 1 page 28
Page 14
Module 1
Lecture de valeurs non nécessaires avec un tuple
Dans un SGBD relationnel, il faut lire le tuple en entier pour accéder à une
valeur de l’un de ses attributs.
Des recherches exigent donc la lecture de nombreuses données non
demandées créant ainsi une charge inutile en E/S.
Lacunes du MR
Module 1 page 29
Parcours de l’association conceptuelle par jointure (calcul)
• Le suivi (la traversée) d’une association UML est fait par calcul
d’une jointure de tables. => Calcul lourd en absence de cluster ou
d’index géré par le SGBD. (rôle important du cluster des index dans
l’optimisation du calcul de la réponse impliquant une jointure)
• Ce suivi est possible via les liens établis par les attributs
Dep:
noDep*
ville
Empl:
nas*
nom
noDep
- La jointure exige deux attributs partageant le même domaine sans
avoir nécessairement le même libellé;
- La contrainte référentielle CR (règle de cohérence) est non
obligatoire pour réaliser la jointure.
Lacunes du MR
Module 1 page 30
Page 15
Module 1
Jointure lourde à calculer
Avec 100 départements distincts et 10 000 employés de par le monde.
Le calcul d’une jointure sans index ni clusters exige 106 lectures sur un
ou plusieurs disques et autant de comparaisons.
Avec 100 tuples de même type par pages, 104 lectures de page avec
accès disque seront nécessaires, peu importe la taille de la cache.
Le calcul de la jointure avec au moins un index sur la table la plus
volumineuse sera plus rapide.
Le calcul sera encore plus rapide avec deux index et des clusters.
Ces derniers gèrent le placement des tuples au moment du stockage
ou d’une réorganisation de la base: les valeurs similaires d’attributs qui
définissent le cluster sont placées dans le voisinage et de préférence
sur une même page.
Lacunes du MR
Module 1 page 31
Opérations limitées de l’algèbre relationnelle (SQL)
Extensibilité limitée du langage
Certaines applications manipulent des types plus complexes et
exigent des opérateurs spécialisés appropriés.
Exemple : dans une BD spatiale, les opérateurs usuels à ce secteur sont
absents pour faire les opérateurs courantes de ce domaine :
• Distance entre deux points
•
Intersection entre deux aires
•
Inclusion totale/partielle d’une aire dans une autre. etc …
=> Opération qui doit être programmée dans chaque application ou fait
par des packages spécialisés et partagés.
Cercle:
x
y
r
x1
y1
r1
x2
y2
r2
r1
(x1,y1)
r2
(x2,y2)
Solution : redéfinir de nouveaux opérateurs ou mieux des méthodes pour
chaque type de données pour supprimer le risque d’erreur.
Lacunes du MR
Module 1 page 32
Page 16
Module 1
Exemple : Chevauchement de cercles (cc) : méthodes
Identification des cercles qui se superposent est possible dans les cas
simples avec une fonction sql :
Select ChevauchementCercle (x1, y1, x2, y2)
From Cercle
r1
ChevauchementCercle la plus simple étant développée
r2
(x1,y1)
autour la clause suivante :
(x2,y2)
Select x1, y1, x2, y2
From Cercle
Where (((x2 - x1)**2 + (y2 – y1) **2))**0.5) < (r1 + r2)
Pour des figures plus complexes, une expression SQL devient impossible à formuler via
le langage SQL.
Exemple: chevauchement des polygones ou des figures irrégulières.
L’appel à une méthode associée à chaque classe de figure est une solution plus
porteuse!
Lacunes du MR
Module 1 page 33
Récursivité/ déduction difficile / voire impossible avec MR+SQL
• Opération de déduction impossible dans le MR avec SQL
De quels gérants l’employé E4 peut-il recevoir des instructions?
(soit directement ou par la voie indirecte d'un supérieur-gérant)
Emp :
noEmp
noGerant
E5
E4
E4
E3
E3
E2
E2
E1
E1
null
Réponse attendue :
E3
E2
E1
Select noGerant from Emp
Where noEmp = ‘E4’;
E3 seulement ??
** La fermeture transitive est maintenant possible avec un opérateur non standard soit le Connect By de Oracle
Lacunes du MR
Module 1 page 34
Page 17
Module 1
Fermeture transitive non disponible dans le MR • Opération de fermeture transitive non disponible avec l’algèbre
relationnelle: De quels gérants, l’employé E4 peut-il recevoir des directives?
Solution : Utiliser la table calculée (non de base) correspondant à la fermeture
transitive de la relation Emp
Emp+ :
FTr
Select noGerant
From Emp+
La partie en vert est la fermeture transitive Emp:
E4 => E3 et E4=>E2 E4=> E1
noEmp
noGerant
E5
E4
E4
E3
E3
E2
E2
E1
E1
null
E5
E3
E5
E2
E5
E1
E4
E2
E4
E1
E3
E1
Lacunes du MR
Module 1 page 35
Fermeture transitive : métode FTr
La fermeture transitive de R(A: d1, B:d1) est R+, incluant tous les tuples
déduits par transitivité. Une méthode FTr est nécessaire pour calculer
Emp+ et ensuite une autre méthode pour faire la déduction.
Emp+ :
Si (a, b) et (b, c) sont des tuples de R,
+
alors le tuple (a,c) est un tuple de R .
*
Une méthode lesDonneursOrdres
exploitera la fermeture
Lacunes du MR
noGerant
E5
E4
E4
E3
E3
E2
E2
E1
E1
null
E5
E3
E5
E2
E5
E1
*
E4
E2
*
E4
E1
E3
E1
FTr(Emp) => Emp+
Select noGerant
From FTr(Emp)
noEmp
Module 1 page 36
Page 18
Module 1
Absence de BLOB dans le MR
• Plusieurs SGBD relationnels ne gèrent pas les LOB : BLOB et CBLOB:
procédures de manipulation absentes ou si peu!
Définition du BLOB
[Binary] Large Object : valeur en binaire représentant une image, un vidéo,
un son,..
•
Le SGBD ignore tout du contenu ou de la structure du BLOB
•
Aucun opérateur disponible sur un tel attribut (sauf par les utilitaires
spécialisés : plugin)
•
BLOB stocké dans :
1. un fichier interne à BD : optimisation possible, mais reste
encombrant (plusieurs Megs)
2.
un fichier externe : optimisation rendue difficile par le SGBD;
Lacunes du MR
Module 1 page 37
Implémentation du BLOB
•
Sortes de BLOB : CLOB BLOB (car., max. 4Go et +), et BFILE;
•
Implémentation du LOB par un pointeur sur un fichier interne ou
externe (file locator) ou insertion directe dans la table (lourd pour les
opérations sur la table). Les valeurs externes échappent aux
contraintes des BD : CR, contraintes sémantiques, …
•
Le BKP du SGBD ne les prend pas en compte.
Espace géré par le SGBD
D://photoAvion.blob
Fichier externe
Insertion directe
Fichier interne
Lacunes du MR
Module 1 page 38
Page 19
Module 1
Caractéristiques du LOB
•
Non structuré : aucune info sur le contenu. Pas d’opérateurs
particuliers disponibles dans SQL pour gérer le contenu du LOB.
•
Une cartouche ou des procédures spécialisées disponibles pour les
manipuler ou des plugins (plugiciels) appelés par l’applicatif.
•
Des procédures en L3G dédiées à manipuler les images et
graphiques vectorisés.
Exemples:
1.
2.
Affichez les images avec des forêts d’automne.
Trouvez les textes avec les occurrences des mots ‘production’ et ‘récession’
dans le même paragraphe ou dans la même phrase.
Certains SGBD utilisent des procédures spéciales – packages - pour traiter le
contenu : Ex. Les cartouches Oracle pour le texte (Context, VIR) les données
spatiales, la recherche des images basée sur le spectre des couleurs, …
Lacunes du MR
Module 1 page 39
Caractéristiques du BLOB (suite1)
• Un BLOB a un type opaque et ne peut pas contenir un autre BLOB
(autonome) pouvant être traité.
•Un blob comme un objet peut avoir des méthodes capables de faire des
manipulations de l’image comme celle de trouver une autre image
imbriquée i.e. exploiter le type opaque.
rapport
RNLO-34
mois
graphe
Attribut graphe de type BLOB ne peut
pas représenter un sous-objet BLOB
indépendant exploitable directement par
une application.
Janvier
Objet graphique
Une méthode pourrait le faire!
Objet graphique inclus dans un LOB dont les
méthodes pourraient permettre de manipuler cet
objet graphique
Lacunes du MR
Module 1 page 40
Page 20
Module 1
Requête difficile voire impossible avec un BLOB stocké dans le MR
Create table Film (noFilm: integer, producteur: varchar (45), video: BLOB ) ;
Select RechercheFrame (video, 350: debut, 6489 :fin)
From Film
Where noFilm = 2345;
RechercheFrame ne peut être qu'une procédure capable de fouiller un vidéo
et d’isoler une séquence de frames (images) entre les images 350 et 6489)
Idéalement, RechercheFrame devrait être un opérateur intégré au langage
de requête SQL. Plus difficile à réaliser car la grammaire de SQL devrait
être augmentée pour incorporer de nouveaux outils de traitement!
Solution: associer une méthode à l’objet pour tirer profit du type opaque.
Lacunes du MR
Module 1 page 41
Échange de données entre une application et le SGBD
Le « mismatch » des langages
Peu importe le nombre de tiers entre l'application et le serveur, le
calcul d'une requête, l'insertion ou la modification sous-tend en bout de
course un échange de données :
1.
Un flot de données typées mises en correspondance avec des variables
adéquates et typées du L3G sans exiger de transformation;
2.
Idéalement, cela sous-tend une mise en correspondance avec une variable
objet du L3G compatible.
Architecture 2 tiers
var1, var2, var3
Données typées: v1, v2, v3
bd
SGBD
Var objet obj1
Données et procédures
de calcul
Objet 1 typé par typeObj
Lacunes du MR
Module 1 page 42
Page 21
Module 1
Programmation en 2-tiers
* Une proc cataloguée est écrite en PL/SQL et stockée dans le DD Elle peut exécuter des
méthodes.
Dans une application Java: appel de la proc cataloguée du tiers qui exécutera la méthode:
…
// String call = "{call augVolProduction (?,?,?,?)}";
…
Affichage du résultat de la Proc catalogue reçu par l’application:
//lblResultat.setText("Le nouveau volume de production est " + stmt.getInt(3)); Lacunes du MR
Module 1 page 43
« Language impedance mismatch »
Structure de stockage fournie par le SGBD compatible avec les types du L3G
•
Toute valeur en provenance du SGBD doit avoir un type (sinon, devra être transformée) compatible avec un de ceux prédéfinis dans le L3G de l'application (type natif) ou construit de toute pièce dans le L3G. C’est une exigence rarement atteinte avec le relationnel.
•
Idem pour tout objet transféré à l'application: doit être stocké par une structure de données adéquate (classe) définie par une variable objet du L3G
dotée d’une structure objet, une classe avec son interface particulière. •
Lorsqu'il y a nécessité d'une telle transformation (mapping), pour s’accommoder, on dit qu'il y a impedance mismatch .
•
Cette transformation est plutôt complexe et des outils existent pour l’automatiser.
Lacunes du MR
Module 1 page 44
Page 22
Module 1
« Language impedance mismatch »
Types simples SQL du MR différents des langages de programmation:
Exemples:
•Date de SQL, absent dans C ou ayant une structure différente dans C++
ou
•Number ou varchar() de SQL absent dans C
Exemple : Select nom into v_nom From …
• Types Long et Long Raw (max 2Go). Var. PL/SQL (max. 32760 o.)
Conversion faite par l’application : inefficient et « proned to errors » !
Les vérifications des types de SQL et du L3G faites à des étapes
différentes :
1. À la compilation : pour les variables objets de l’application;
2.
À l’exécution pour les types des attributs de SQL
- La nature d’un type SQL peut varier jusqu’à l’exécution
Lacunes du MR
(ou par pré-compilateur)
Module 1 page 45
Un bémol: Mapping complexe des objets du BDOO vers un applicatif •
Le SGBD objet complique parfois les choses avec le mapping des objets vers des structures de données de l'applicatif. En effet, un type complexe ou une classe de la BDOO définie par un utilisateur ne correspond pas nécessairement à une structure primitive du langage de l'applicatif : C++, Java, C#, …
•
La définition manuelle de la structure ou de la classe du L3G pour chaque type définie dans la base est plutôt complexe et fastidieuse.
•
Cette structure ainsi définie permet l’usage de l’interface de l’objet par l’application hôte.
Automatisation du mapping avec Oracle:
• L'outil JPublisher de Oracle permet de générer les classes Java qui correspondent aux classes‐objets de la BD. Il suffira par la suite pour l'applicatif d'importer les classes générées à partir du schéma de la base. L'environnement .NET a aussi une telle solution.
Lacunes du MR
Module 1 page 46
Page 23
Module 1
Paradigme et incomplétude computationnelle
• Le paradigme de programmation est différent : SQL est
déclaratif, tandis que le L3G est procédural;
• Complétude computationnelle: Souvent le langage relationnel
est incomplet: absence de structures de contrôle au regard du
L3G. SQL3 est cependant plus complet que les précédents.
Exceptions : avec PL/SQL de Oracle, O2C de O2
Idéal
SQL intégré dans L3G, DML et types de données idem et le langage complet
sur le plan computationnel.
Lacunes du MR
Module 1 page 47
Absence d’attribut de structure ensembliste dans le MR =>redondance
Parent (nasP*: string, nomP: string, telE : string, nasE*: string)
Avec nasP pour identifier un parent et nasE pour celui d’un enfant
Comme clé composée.
Parent:
Cette relation n’est pas en FN2 car il y a
un attribut non primaire qui n’est pas en
DF totale sur une clé: nasE -> telE
nasP*
nomP
telE
nasE*
111
P. Dion
458-2345
544
nasP  nomP (1)
112
J. Bois
677-6789
567
nasP, nasE  nomP
112
J. Bois
345-6789
568
567
A. Bois
234-6534
159
544
L. Dion
458-2345
987
568
J. Bois
677-6789
456
987
L. Dion
458-2345
544
Les DF:
(+nasE)
nasE  telE (2) (+nasP)
mais
telE -/-> nasP, nasE (voir le tel en rouge)
Données redondantes => normalisation vers FN3 où tout attribut non primaire (nomP et telE)
ne dépend que d’une clé choisie ou candidate.
Quelle est la clé de la relation Parent?
( nasP, nasE) En forme normale ?
Lacunes du MR
Module 1 page 48
Page 24
Module 1
Multiplication des tables avec la normalisation EnfantDe :
Parent :
(1)
nasE*
telE
544
458-2345
567
677-6789
568
345-6789
159
159
234-6534
568
456
456
677-6789
987
544
327
565-6777
nasP*
nasE*
111
544
112
567
112
568
544
987
567
nasP*
nomP
111
P. Dion
TelEn:
(2)
112
J. Bois
567
A. Bois
Réduction des anomalies, mais alourdissement des
calculs via la jointure!
544
L. Dion
 multiplication des tables!
568
J. Bois
987
R. Dion
Lacunes du MR
Module 1 page 49
Normalisation : sous‐tend souvent une complexité accrue des requêtes relationnelles: avec jointure Quel est le téléphone des petits-enfants des parents nommés J. Bois?
(A) Avec une table non normalisée:
Parent (nasP*: string, nomP:string, telE :string, nasE *: string)
Select telE
From Parent
Where nomP = "J. Bois" ;
1 sélection dans 1 table
* réponse 3 téléphones
(B) Avec des tables normalisées (distinctes)
Parent(nasP*, nomP)
EnfantDe (nasP*, nasE*) TelEnf ( nasE*, telE)
Select t.telE
From Parent p, EnfantDe e, TelEnf te
Where p.nasP = e.nasP and e.nasE = te.nasE and p.nomP = "J. Bois"
2 jointures et 3 tables + 1 sélection
Lacunes du MR
Module 1 page 50
Page 25
Module 1
Est‐il possible d’éviter cette complexité ?
• Absence d’un attribut de type ensembliste ou structuré dans le modèle relationnel.
Avec un type d’ensemble:
Parent
(nasP*: string, nomP: string, enfants {nasE :string, telE :string})
où { } dénote un ensemble de tuples
=> Attribut complexe (d’ensemble) qui simplifie les requêtes !
Le téléphone des petits-enfants de J. Bois est alors fourni par cette simple
requête:
réponse:
Select p.telE
From Parent p
Where p.nomP = "J. Bois";
telE:string
677-6789
345-6789
Lacunes du MR
Module 1 page 51
Peu de contrôle sur les traitements
•
Les applications utilisent les clauses DML assez librement avec peu de contrôle (par le DBA) au regard de leur efficacité (formulation), de la cohérence et de l’intégrité des données. Les cas de figure les plus invraisemblable se voient dans la pratique!
•
L’encapsulation quasi absente : utilisation libre et directe des clauses DML est source d’erreurs fréquentes.
•
Les règles de gestion complexes difficilement implémentées par les triggers peuvent être contournées par les applications.
•
L’initialisation des tuples ou de certains attributs est mal contrôlée.
•
Les traitements complexes sont laissés aux applications : avec redondance inutile et source d’erreurs. Peu de partage des acquis en ce quia trait aux accès de données.
Lacunes du MR
Module 1 page 52
Page 26
Module 1
Conclusion
Constat des principales lacunes du relationnel :
•
•
•
•

Le maintien de la cohérence de la BD est laissé presque totalement aux applications.
Absence de structures de données complexes pour les applications dans les domaines multimédia; type opaque inutile.
Absence d’interface (méthodes) pour manipuler les données structurées assujetties à des contraintes spécifiques;
Jointure lourde à calculer notamment pour les grosses tables;
Les opinions divergent cependant quant à l'importance relative de ces lacunes (voir Fabian) dans la justification de l’objet.
Lacunes du MR
Module 1 page 53
Solution aux lacunes identifiées
Implanter l'encapsulation des données avec le passage du relationnel à l'objet (l'objet‐relationnel )
‐
Utiliser un langage complet au plan computationnel pour manipuler les données.
À terme, l’approche objet pur s’imposera comme une solution viable et supérieure pour renforcer l’intégrité du modèle de données et faciliter le développement des applications. Voir à l’adéquation optimale avec le choix approprié du SGBD en
considérant les logiciels NoSQL (Not only SQL ou no SQL) pour les données non structurées et réparties.
Lacunes du MR
Module 1 page 54
Page 27
Module 1
Les BD dites NoSQL
Certaines bases regroupent des données aux caractéristiques
particulières comme par exemple avoir une structure variable
pour les objets du même type voire même peu ou pas de
structure.
Les contraintes sur les données sont relaxées et la vitesse de
recherche est primordiale, même pour un volume considérable
de données.
Les bases relationnelles et objets calquées sur un modèle de
données complexe ne répondent plus aux exigences forte pour
une grande rapidité d’accès aux données.
Lacunes du MR
Module 1 page 55
Systèmes NoSQL et leurs structures pour gérer les données
From Hasan Mir de GuruSoft Group, 2014
NoSQL
Relationnel
OLAP
Tables
Cubes
Collections
Inapproprié
pour le Big Data
Inapproprié
pour le Big Data
Performance
Disponibilité
Et “scalability*”
* Auto-adaptif aux divers volumes de données
Lacunes du MR
Module 1 page 56
Page 28
Module 1
Systèmes NoSQL
Les nouveaux systèmes dits NoSQL* sont en mesure de franchir dans certains
environnements cette barrière de performance des modèles relationnels notamment
pour les données massives peu structurées.
Ces systèmes NoSQL stockent les données de façon très différente et abandonnent
la normalisation pour privilégier l’agrégation. La charge fonctionnelle associée à leur
exploitation doit être prise par les applicatifs (absence de methods intégrées).
Ces systèmes sont aussi plus adaptés au traitement parallèle (bd réparties ou en
cluster et le cloud).
Les BD NoSQL peuvent être regroupées en 4 classes:
1- Base à valeur de clé : la clé est associée à un type opaque
2- Base à structure de document: ensemble de paires (attribut type/valeur)
3- Base structurée colonne: les valeurs d’une même colonne sont regroupées.
4- Base hypergraphe: valeurs associées par un lien sémantique.
* Not only SQL
Lacunes du MR
Module 1 page 57
Différentes approches pour les NoSQL
Valeur de clé
Tabulaires
Orientés
document
Memcached
Coherence
Redis
BigTable
Hbase
Acumub
MongoDB
CouchDB
Cloudant
Performance
NoSql
Relationnel
Fonctionnalités
Lacunes du MR
Module 1 page 58
Page 29
Module 1
Une base NoSQL pour les bases de grande taille
Une base NoSQL permet d’accéder à une valeur ou à un ensemble plus ou
moins structuré de données agrégées et cela avec le minimum de calcul.
Une telle BD permet aussi de gérer les grands volumes de données peu
structurées incluant celles de type opaque.
Ces bases peuvent être réparties (clustering) sans obligation d’être contraintes
par les propriétés ACID. L’accent étant mis prioritairement sur la disponibilité
des données.
En résumé:
 Pas d’obligation d’avoir un schéma (type opaque)
 Pas de nécessité de répondre aux propriétés ACID.
 La cohérence est sacrifiée au profit de la disponibilité.
 Aucune implémentation de la jointure.
Lacunes du MR
Module 1 page 59
Sommaire du classement* des BD NoSQL
BD NoSQL
Key-Value
Stores
Document Stores
Columnar Databases
Graph Databases
* From NoSQL Databases Mohammad Hammoud de Carnegie Mellon University, April 2015
Lacunes du MR
Module 1 page 60
Page 30
Module 1
Caractéristiques d’une BD NoSQL *
•
Aucun schéma obligatoire (bien que possible).
•
Aucune obligation d’implémenter les transactions de type ACID.
•
Cohérence remplacée par une plus grande disponibilité des données.
•
Absence du langage SQL mais fournit un langage différent de SQL
•
Persistance non obligatoire: en cas de panne il peut y avoir perte des
données dans la cache.
•
Contrainte découlant du théorème de CAP : coherence, availability et
partitioned
* NoSQL Databases Mohammad Hammoud de Carnegie Mellon University, April 2015
Lacunes du MR
Module 1 page 61
Quand utiliser le NoSQL?
• Stockage de grands volumes de données.
• Les relations entre les données peu importantes
• Stockage d’un volume croissant de données
• Données non structurées : non typées
• Pour le développement d’un prototype
• Aucune contraintes à renforcer
• Journalisation par le SGBD
Lacunes du MR
Module 1 page 62
Page 31
Module 1
Théorème de CAP (Eric Brewer, Univ. Berkeley,
2010)
Dans un système réparti les paramètres critiques:
- Cohérence (C): après un update, tous les clients voient les mêmes données
- Disponibilité A): le système et les données accessibles et idem pour tous les clients
- Partitionnement des données(P): les données restent accessibles même si les
communications entre les serveurs du cluster ne sont pas fiables.
Avec le NoSQL:
Deux de ces paramètres seulement peuvent être pris en charge
simultanément (CAP).
https://people.eecs.berkeley.edu/~brewer
/cs262b-2004/PODC-keynote.pdf
Lacunes du MR
Module 1 page 63
BD clé/valeur
 Une clé donne accès à une valeur opaque complexe et non structurée.
 Les clés sont stockées dans une table fournissant un accès par Hashing.
 ** Aucune jointure et agrégation possibles. Une recherche complexe
est prise en charge par l’applicatif.
 Aucune contrainte au niveau du SGBD: chaque application doit
prendre la relève pour les renforcer.
** Voir le web pour plus de références
Lacunes du MR
Module 1 page 64
Page 32
Module 1
BD à valeur de clé
Systèmes Open Source: Redis, Riak, Memcached, Berkeley DB, Projet Voldemort, Amazon
Dynamo DB** (not open source)
Lacunes du MR
Module 1 page 65
Caractéristiques du système à valeur de clé
Un objet: simple ou complexe (ex. Une photo, …
Une clé donne accès à un objet complexe associé à
aucun schéma.
L’exploitation du contenu de l’objet est laissée à la
charge de l’applicatif.
Système facilement distribué et orienté WEB
Lacunes du MR
Module 1 page 66
Page 33
Module 1
BD de documents (Documents Store)
 Document (au sens non obligatoirement structuré) stocké dans un format standard ou encodé (e.g., XML, JSON, BSON, PDF or Office Documents)
Ils sont désignés comme des Binary Large Objects (BLOBs) de type opaque.
 Ces documents peuvent être indexés et comportés des éléments différents d’un objet à l’autre.
 Plus efficace que les systèmes de fichiers traditionnels
Exemples: les logiciels MongoDB and CouchDB
Lacunes du MR
Module 1 page 67
BD à base de documents (format JSON)
Type opaque
Lacunes du MR
Module 1 page 68
Page 34
Module 1
JSON (JavaScript Object Notation)
Format d’échange de données indépendant de tout langage.
JSON exploite deux structures:
• Une collection de couples nom/valeur chacune réifée par un
objet.
• Une liste de valeurs ordonnées rendue par un tableau :
{
string
:
valeur
}
,
valeur := string | number | object | …
Autres token définis en BNF ou par un graphe.
Lacunes du MR
Module 1 page 69
BD à base de colonnes
Chaque colonne est nommée et éventuellement dans un ordre différent d’un objet à l’autre
Lacunes du MR
Module 1 page 70
Page 35
Module 1
BD structurée en hypergraphe
De Martin Fowler GoTO Conference 2014 (Utube)
Quelle est la quantité de jouets inscrite sur la commande -0056 transmise
récemment par Bob?
Lacunes du MR
Module 1 page 71
BD NoSQL ≠ BD objets
Les objets de ces BD NoSQL sont traités non pas par des
méthodes mais par les applicatifs eux-mêmes.
En cela, ce ne sont pas des BD objets au sens strict.
Quelques systems NoSQL:
MongoDB and CouchDB
Redis, Riak, Memcached, Berkeley DB, Projet Voldemort,
Amazon Dynamo DB, Cassandra
Leur force: rapide pour trouver toute l’information qui n’est pas
éclatée dans différentes structures sans être assujetti fortement à
la cohérence des données de la base.
Lacunes du MR
Module 1 page 72
Page 36
Module 1
Prospective : maturité du marché SGBD pour l’objet ?
• La solution avec l’objet existe depuis quelques années;
• Le marché toujours hésitant : les coûts de conversion vers l’objet sont non
négligeables (lourdeur du legacy); déblocage en vue pour le NoSQL
• Disponibilité d’une solution intermédiaire l’objet-relationnel (OR) mise en
marché par les grands éditeurs; solution qui plaît au contrôleur du budget!
• Investissements éventuels des grands éditeurs de SGBD dans l'objet (DB2,
Oracle, UniSQL, CCA, Jasmine …) vont engendrer des pressions sur les
organisations pour faire évoluer leurs choix technologiques et entrainer des
investissements inévitables!
• Quelle sera l’influence du Cloud Computing dans ce processus? (infonuagique)
•Pour certaines exploitations (ex. OLTP et le Big Data), la solution passera plutôt par les
systèmes NoSQL qui sont pour la plupart encore des logiciels libres!
Lacunes du MR
Module 1 page 73
Outils de gestion (Éditeurs commerciaux de SGBD) •
Objet‐relationnel : Oracle 11g, DB2, …
•
Objet : O2 (?), Caché, Encore, GemStone, Jasmine, ObjectStore, Versant, …
•
Portail sur les bases objets: http://www.odbms.org/index.html
•
Cassandra, MongoDB et des dizaines d’autres SGBD NoSQL De nombreux SGBD NoSQL sont commercialisés. Le plus connu est le BigTable de Google.
•
Répertoire des logiciels NoSQL ( >225) de SGBD NoSQL Open Source: http://nosql‐database.org
Lacunes du MR
Module 1 page 74
Page 37
Module 1
Orthographe de la terminologie objet
Le vocabulaire des BD a encore une orthographe instable:
•
•
•
•
•
•
•
•
Base de données relationnelle (la base étant relationnelle)
Base de données objet‐relationnelle (la base est à la fois objet et relationnelle)
Base de données objet
Base de données objets Base de données à objets
Instance de classe Intantiation et instantier une classe (intance, Instantiation, instancier)
Base de données déductive (la base est déductive)
Les auteurs reconnus butinent encore quelque peu d’une graphie à l’autre! Lacunes du MR
Module 1 page 75
Technologie à l’horizon de la prochaine décennie …
Ce qu’en dit un pionnier :
•
Stonebraker (5), (Univ. Berkeley) architecte de deux SGBD : Ingres et Postgres, anticipe
un changement majeur dans la technologie relationnelle et des SGBD:
‐ “Changement radical: “Relational technology is obsolete and should be burried” in Computerworld sept 2007” … commentaire: déjà quelques années sont passées et la technologie relationnelle est encore très présente !!!!
‐ “He also argued that today's relational databases lag badly in performance behind a new wave of databases that flip database tables 90 degrees” : The Column Database. À l’horizon : les systèmes NoSQL:
• Des technologies du futur au regard de la nature et du volume considérable des données qui seront à gérer. Google est un pionnier de cette technologie avec le Google’s Big Table. C’est un outil de gestion de données pour des applications particulières!
Lacunes du MR
Module 1 page 76
Page 38
Module 1
Références 1‐ An Interview with Chris Date, Tony Williams July 2005,
http://www.oreillynet.com/pub/a/network/2005/07/29/cjdate.html?
2‐ Comparison of Relational and Object‐based Approaches in Modeling Financial Statements,
Lee Yao, S.H. Chan, M. Prokofieva, Research in progress,
http://www.sigasys.org/content/papers/YaoChanProkofieva2005.pdf
3‐ Test Your Foundation Knowledge, Pascal Fabian, Journal of Conceptual Modeling, May 2004,
http://www.inconcept.com/JCM/May2004/weakrm.htm
4‐ An Exploration of Object Oriented Database Managements Systems, Dare Obasanjo, 2001
http://25hoursaday.com ‐‐ Tableau comparatif et nombreux exemples de programmes pour
l’accès à la BD objet.
5‐ Relational database pioneer says technology is obsolete, Michael Stonebraker blogs not to praise RDBMS but to bury them By Eric Lai, Computerworld September 6, 2007.
6- Advancing Distributed Systems - Eric Brewer, 2012 RICON2012 https://vimeo.com/52446728
7‐ http://nosqlguide.com/nosql‐vs‐rdbms‐overview/
8‐ Le WEB: source importante d’informations pour les nouvelles technologies des BD non relationnelles, notamment le NoSQL
Lacunes du MR
Module 1 page 77
Page 39
Module 1

Module 1 - Université Laval

Transcription

Documents pareils

Institut Supérieur Aquitain du Bâtiment et des Travaux Publics

dut génie biologie - iut lyon 1

Le top 50 des programmes d`études professionnelles et techniques

INFORMATIQUE CYCLE PROBATOIRE GÉNIE LOGICIEL

dates de rentrée dut

de l`IUT de Vélizy - Université de V

BD JEUNESSE

Agrégés - SUD Education Vaucluse

Télécharger la lettre de motivation

Offre d`emploi