1 LacunesMR

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: andre.gamache@ift.ulaval.ca
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.
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 :

Stockage des données et
obtention des données de la
préservation de la cohérence de la
BD
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).
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 ».
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.
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 Logique de BD Données + procédures
Transfert par http validation de calcul (méthodes)
des SGBD
applications
objet1.ajout( ) appel méthode ajoutajout( )
Tiers 3
Tiers 1 Tiers 2
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.
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 SGBD
http:.. Réception des
Calcul de la
réponse
bd Données et
requêtes HTML à chaque requête
Browser procédures
et logique de ou DML avec
validation validation des
contraintes de la
des
base
Page Web
applications Toutes les données sont centralisées
appel méthode ajout( ) sur un même serveur: Se prête mal à
une exploitation par cluster.
Tiers 2
Tiers 1 Tiers 3
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
Les données sont regroupées machines différentes.
comme un nœud d’intégration.
Exploitation en cluster difficile.
Système BD Ventes
Vente
Services WEB: un pour les
ventes et un autre pour
l’inventaire
Intégration
par une BD
centralisée
BD
Inventaire
Système
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.
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
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.
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.
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).
L’informatique nuagique
Source web : Developpez.com 24 février 2016 par Guillaume Sigui
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
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)
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 Le site 1 peut
spécifiques à chaque site se faire livrer
partiellement
Site 1 avec en sus quelques des pièces Contraintes c1
contraintes particulières au même si elle et c3
est partielle spécifique au
Données et
site 1 site 1
applications
Site 2 avec en sus
quelques contraintes Contrainte c2
Le site 2
Site 3 particulières au site 2 spécifique au
réceptionne les
site 2
pièces que si
Le site 3 peut toutes sont
recevoir les pièces disponibles
que si les 2/3
commandées sont
disponibles.
** 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.
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!
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. Mixe: Objet + relationnel (DB2, Oracle 10g +, ..)

4. Objet (Caché, Jasmine, O2, GemStone, Objectivity, …)
5- Déductif (Validity)
6- 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 de la technologie relationnelle pour l’implantation

stricte des modèles
Certaines de ces lacunes seront prises en charge par la technologie
objet
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* nom position noEq
Une seule Entité bien réelle 2 relations ou tables comme

L’accès à une équipe sera réalisée par 2 accès à des représentation informatique ??
tables relationnelles
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 Personne
noDep* : int 1 Travaille 1..* nas* : string
ville nom : string UML
Association Travaille
Departement: Personne:
noDep* ville nas* nom noDep
MR
Page 11 Module 1
Double association entre deux classes:
renommage de certains attributs
La transformation du diagramme de classe en MR :
Employe 0..1 Projet

* <TravaillePerm
nasE*: int noP*: int
0..1
nomE: varchar2 * siteP: varchar2
< TravailleTemp 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
travailleurs temporaires: Rendu des 2 associations
Employe (nasE* , nomE, noPP, noPT)
Projet (noP*, siteP, budgetP)
Le domaine de noPP peut être différent de celui de noPT
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.
Departement: Personne:
noDep* ville nas* nom age noDep
Solution : Obtenir les département où travaillent les Sirois sans faire de jointure et terminer par
la projection.
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. ***
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.
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.

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.
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.
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.
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.
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.
r1
(x1,y1)
Cercle: x y r r2
x1 y1 r1 (x2,y2)
x2 y2 r2
Solution : redéfinir de nouveaux opérateurs ou mieux des méthodes pour
chaque type de données pour supprimer le risque d’erreur.
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) r1

From Cercle
(x1,y1) r2
ChevauchementCercle la plus simple étant développée
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!
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

Réponse attendue :
E5 E4
E3
E4 E3
E2
E3 E2
E2 E1 E1
E1 null
Select noGerant from Emp E3 seulement ??

Where noEmp = ‘E4’;
** La fermeture transitive est maintenant possible avec un opérateur non standard soit le Connect By de Oracle
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+ : noEmp noGerant
FTr E5 E4
E4 E3
E3 E2
E2 E1
Select noGerant
E1 null
From Emp+
Where noEmp = ‘E4’; E5 E3
E5 E2
E5 E1
La partie en vert est la fermeture transitive Emp:
E4 E2
E4 E1
E4 => E3 et E4=>E2 E4=> E1
E3 E1
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+ : noEmp noGerant
Si (a, b) et (b, c) sont des tuples de R, E5 E4

+
alors le tuple (a,c) est un tuple de R . * E4 E3
E3 E2
E2 E1
FTr(Emp) => Emp+ E1 null

E5 E3
E5 E2
Select noGerant E5 E1
From FTr(Emp)
* E4 E2
Where noEmp = ‘E4’;
* E4 E1
E3 E1
Une méthode lesDonneursOrdres
exploitera la fermeture
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;
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.
D://photoAvion.blob
Espace géré par le SGBD
Fichier externe
Insertion directe
Fichier interne
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. Affichez les images avec des forêts d’automne.

2. 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, …
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 mois graphe
RNLO-34 Janvier Attribut graphe de type BLOB ne peut

pas représenter un sous-objet BLOB
indépendant exploitable directement par
une application.
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
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.
É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
Données et procédures
SGBD de calcul
Var objet obj1 Objet 1 typé par typeObj
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));
« 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.
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 (ou par pré-compilateur)
- La nature d’un type SQL peut varier jusqu’à l’exécution
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.
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.
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 Cette relation n’est pas en FN2 car il y a
Comme clé composée. un attribut non primaire qui n’est pas en
DF totale sur une clé: nasE -> telE
Parent:
nasP* nomP telE nasE* Les DF:
111 P. Dion 458-2345 544 nasP  nomP (1) (+nasE)
112 J. Bois 677-6789 567 nasP, nasE  nomP
nasE  telE (2) (+nasP)
112 J. Bois 345-6789 568
mais
567 A. Bois 234-6534 159
telE -/-> nasP, nasE (voir le tel en rouge)
544 L. Dion 458-2345 987
568 J. Bois 677-6789 456
987 L. Dion 458-2345 544
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 ?
Page 24 Module 1
Multiplication des tables avec la normalisation
EnfantDe : nasP* nasE* nasE* telE

TelEn:
111 544 544 458-2345
(2)
112 567
567 677-6789
112 568
568 345-6789
544 987
567 159 159 234-6534
568 456 456 677-6789

Parent : 987 544 327 565-6777
(1) nasP* nomP
111 P. Dion
112 J. Bois Réduction des anomalies, mais alourdissement des
567 A. Bois calculs via la jointure!
544 L. Dion  multiplication des tables!
568 J. Bois
987 R. Dion
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)

1 sélection dans 1 table
Select telE
From Parent
Where nomP = "J. Bois" ; * 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
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:
telE:string
Select p.telE 677-6789
From Parent p
345-6789
Where p.nomP = "J. Bois";
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.
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.
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.
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.
Systèmes NoSQL et leurs structures pour gérer les données
From Hasan Mir de GuruSoft Group, 2014
Relationnel OLAP NoSQL
Tables Cubes Collections
Performance
Inapproprié Inapproprié
Disponibilité
pour le Big pour le Big
Et
Data Data
“scalability*”
* Auto-adaptif aux divers volumes de données

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
Différentes approches pour les NoSQL
Orientés
Valeur de clé Tabulaires
document
Memcached BigTable MongoDB

Coherence Hbase CouchDB
Redis Acumub Cloudant
NoSql
Performance
Relationnel
Fonctionnalités
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.
Sommaire du classement* des BD NoSQL
BD NoSQL
Key-Value Document Columnar

Stores Graph Databases
Stores Databases
* From NoSQL Databases Mohammad Hammoud de Carnegie Mellon University, April 2015
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
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
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
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
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)
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
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
BD à base de documents (format JSON)
Type opaque
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.

BD à base de colonnes
Chaque colonne est nommée et éventuellement dans un ordre différent d’un objet à l’autre
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?
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.
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!
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
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!
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!
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
Page 39 Module 1

1 LacunesMR

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

1 LacunesMR

Transféré par

Droits d'auteur :

Formats disponibles

André Gamache professeur associé, Département d'informatique et de génie logiciel

André Gamache, professeur associé

Lacunes du MR Module 1 page 1

Lacunes du MR Module 1 page 2

Architecture générale de l'implantation d'un système d’information avec

Machine 1 Traitement de la requête :

Lacunes du MR Module 1 page 3

niveau 1 (tiers 1- client)

niveau 2 (tiers 2) Client/Serveur (application « stateless ou stateful »)

Le SGBD et le système de gestion de fichiers ont des rôles significatifs et complémentaires.

Lacunes du MR Module 1 page 4

- Notion de couche réfère à du logiciel développé en

- Celle de tiers réfère à du hardware et des protocoles

Plusieurs couches de logiciel concentrées sur une seule

L’application est sur une machine et le logiciel d’accès aux

Le Cloud computing sous-tend l’architecture en tiers et un

Lacunes du MR Module 1 page 5

• tiers 2: La logique de validation et de calcul de l’applicatif (dite de métier) est

• tiers 3: La logique de recherche et de stockage, validation globale (règles

Lacunes du MR Module 1 page 7

• Tiers 3: La recherche, validation globale (règles d'entreprise), cohérence du modèle,

Lacunes du MR Module 1 page 8

Exploitation via le WEB favorise la répartition des données et

Web-server de Oracle avec le PL/SQL

Source: Oracle documentation

Lacunes du MR Module 1 page 10

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

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

Lacunes du MR Module 1 page 12

Une exploitation WEB transfert entièrement le contrôle et

L’application WEB prend à sa charge les validations

•Assurer que les accès aux données peu importe l’origine

Lacunes du MR Module 1 page 13

Source web : Developpez.com 24 février 2016 par Guillaume Sigui

Lacunes du MR Module 1 page 14

Différentes formules * de services en nuage

* Source web : Developpez.com 24 février 2016 par Guillaume Sigui

Lacunes du MR Module 1 page 15

Les possibilités offertes par chaque offre se récapitulent comme suit :

PASS: Platform As A Service: le système d'exploitation et des outils

SAAS : Software As A Service: offre complète qui propose la couche applicative

Lacunes du MR Module 1 page 16

Contraintes spécifiques à chaque site (du cluster)

Lacunes du MR Module 1 page 17

Un problème important dans cette communication est l’appariement et

Lacunes du MR Module 1 page 18

Diverses modèles de données :

3. Mixe: Objet + relationnel (DB2, Oracle 10g +, ..)

La convergence des technologies : BD, IA, WEB progresse lentement

• La place relative dans le marché : Oracle, SQLServer, …

Lacunes de la technologie relationnelle pour l’implantation

Lacunes du MR Module 1 page 20

Représentation conceptuelle distante du réel. La modélisation fournit de

Une seule Entité bien réelle 2 relations ou tables comme

•Les éléments du modèle relationnel (MR) sont souvent polysémiques:

=> Perte du nom de l’association

noDep* ville nas* nom noDep

Lacunes du MR Module 1 page 22

La transformation du diagramme de classe en MR :