Bases de données

Pr. Yahya Benkaouz

[email protected]
FSR, Université Mohammed V de Rabat
 Introduction aux bases de données
• Les bases de données se situent au coeur
de l’activité:
• des entreprises,
• des administrations,
• de la recherche
• etc.

2
http://www.objectifrente.com/actions/10-secteurs-activites-pour-diversifier-portefeuille-actions
 Introduction aux bases de données
• La croissance du World Wide Web a accru le développement du volume d’information, en
fournissant l’accès à des bases de données très diverses avec une interface commune.

3
www.freehali.com/service/je-vais-realiser-un-site-web-dynamique-base-de-donnee-bien-concue-qui-repond-exactement-aux-besoins-du-site
Introduction aux bases de données

4
Introduction aux bases de données

5
https://www.aivancity.ai/actualites/les-metiers-de-lintelligence-artificielle-et-de-la-data
Introduction aux bases de données
• Les bases de données reposent sur des théories solides et sont à l’origine d’une des plus
importantes disciplines de l’informatique : l’ingénierie des systèmes d’information.

• Les concepts théoriques liés à la gestion des bases de données incluent notamment :
• Les fondements des langages de requêtes
• La complexité, la puissance d'expression des requêtes
• Le contrôle de dépendance
• Les principes de contrôle de concurrence
• Les mécanismes de sauvegarde et restauration
• Les bases de données spécialisée: temporelles, déductives, spatiales, probabilistes, …
• Etc.

• Ces théories permettent de garantir l’efficacité, la cohérence et la fiabilité des systèmes de

gestion de bases de données. 6
Objectives du module
• Comprendre les principes fondamentaux des bases de données relationnelles.

• Apprendre à concevoir et à modéliser des bases de données à l'aide du modèle

Entité-Association (ER).

• Comprendre les principes de l'algèbre relationnelle pour manipuler efficacement

les données dans une base de données relationnelle.

• Apprendre à utiliser SQL pour interroger et manipuler des données dans une
base de données relationnelle.
7
Plan du cours
• Introduction aux bases de données

• Analyse du monde réel : Modèle Entité/Association (ER)

• Concepts fondamentaux : entités, relations, attributs, clés
• Étapes de la modélisation ER
• Normalisation de modèles ER

• Approche relationnelle
• Modèle relationnel
• Algèbre relationnelle

• Langage SQL
8
Introduction aux bases de données
• Qu’est ce qu’une base de données?
• Modèles de données
• Système de gestion de bases de données
• Etapes de la conception des bases de données

9
Introduction aux bases de données
• Qu’est ce qu’une base de données?
• Modèles de données
• Système de gestion de bases de données
• Etapes de la conception des bases de données

10
 Introduction aux bases de données
• Les bases de données sont au cœur de la gestion de
l’information dans tous les domaines.

• Les développeurs d’applications s’appuient sur des

bases de données externes pour gérer leurs données
alors qu’auparavant elles étaient intégrées dans le
programme.

11
https://web.maths.unsw.edu.au/~lafaye/CCM/bdd/bddintro.htm
Notion de bases de données
• On définit une base de données comme l’ensemble des
données stockées.
• Pour les manipuler, on utilise généralement un
logiciel spécialisé appelé SGBD (Système de Gestion
de Bases de Données).
• Il y a parfois confusion, par abus de langage, entre
base de données et SGBD.

• Plus formellement, on appelle Base de Données (BD):

Un ensemble de fichiers informatiques structurés ou non
structurés et organisés afin de stocker et de gérer de l’information

12
Utilisation d’une BD
• Une BD a un but précis: Elle doit permettre de retrouver de l’information par
son contenu en se basant sur des critères de recherche.

• Elle est conçue pour faciliter l’accès, la manipulation et la mise à jour des informations, tout en
garantissant leur cohérence, intégrité et sécurité.

• Caractéristiques principales d’une base de données :

• Stockage structuré : Les données sont organisées selon un modèle spécifique (relationnel, NoSQL,
graphe, etc.).
• Accès et manipulation facilités : Via un langage de requêtes comme SQL ou des API pour les bases
NoSQL.
• Partage et concurrence : Plusieurs utilisateurs peuvent interagir simultanément avec les données.
• Fiabilité et sécurité : Garanties par des mécanismes comme la gestion des transactions (ACID), les
contrôles d’accès et la sauvegarde.

13
Utilisation d’une BD
• Une BD a un but précis: Elle doit permettre de retrouver de l’information par
son contenu en se basant sur des critères de recherche.

• Par exemple:
• Retrouver les étudiants ayant validés tous les semestres.
• Retrouver tous les employés qui ont eu une augmentation l’année dernière.

• La grande différence avec un programme écrit dans un langage de programmation est:

• Une base de données doit pouvoir répondre à des questions pour lesquelles elle n’a pas
forcément été prévue à la conception.
• Les données sont susceptibles d’être utilisées par des applications différentes.

14
BD vs File
system

15
Introduction aux bases de données
• Qu’est ce qu’une base de données?
• Modèles de données
• Système de gestion de bases de données
• Etapes de la conception des bases de données

16
Modèles de données
• Un modèle de données est une représentation abstraite de la structure des
données dans une base de données.

• Il définit la manière dont les données sont organisées, stockées, manipulées et

interconnectées.

• Les modèles de données permettent de structurer les informations pour qu'elles

puissent être facilement exploitées par les applications et les utilisateurs.

• Ils jouent un rôle essentiel dans la conception des bases de données en

garantissant la cohérence, l'intégrité et l’efficacité des données

17
Modèles de données
• Objectifs des Modèles de Données:

• Structurer les données : Définir les entités et leurs relations.

• Faciliter l'accès et la manipulation : Permettre des opérations efficaces (lecture, écriture,

mise à jour).

• Assurer la cohérence et l'intégrité : Éviter les incohérences et assurer la validité des données.

• Indépendance des données : Séparer la structure des données des traitements effectués
dessus.

18
Evolution des Modèles de données
Années 1960- Modèles hiérarchique et réseau
1970

Années 1980- Domination du modèle relationnel avec SQL

1990

Années 2000- Apparition des bases NoSQL

2010 pour répondre aux besoins du Big Data et du web

Hybridation des modèles

Aujourd’hui
(Bases multi-modèles combinant SQL et NoSQL)

19
Modèles
• Il existe de nombreux types de modèles de bases de données. Parmi les plus classiques :

Modèle hiérarchique Modèle réseau

Modèle relationnel Modèle orientée objet

20
Modèle hiérarchique
• Origine:
• Le traitement de l’information était encore très lié à l’organisation des fichiers sur une
machine.

• Les modèles conceptuels de données étaient aussi très proches du système de fichiers
puisque l’on manipule des arbres.

• Les nœuds de ces structures constituent les informations et les arêtes représentent les liens
entre ces données.

Modèle hiérarchique propose une classification arborescente des données.

21
Modèle hiérarchique
• Aperçu:
• Le modèle hiérarchique organise les données dans une structure arborescente.
• Chaque enregistrement dispose d'un seul parent (racine).
• Les enregistrements frères et sœurs sont triés dans un ordre particulier.
• Cet ordre est suivi pour le stockage physique de la base de données.

Exemple : Bibliothèque
Une bibliothèque contient plusieurs sections │── Section (Ex: Informatique)
→ Chaque section contient plusieurs livres │ │── Livre (Ex: "SQL pour les nuls")
→ Chaque livre est écrit par un auteur. │ │ │── Auteur (Ex: John Doe)
│ │── Livre (Ex: "Big Data")
│ │── Auteur (Ex: Alice Smith)
Limitation : Un auteur ayant écrit plusieurs │── Section (Ex: Littérature)
livres est difficile à représenter. │── Livre (Ex: "Le Petit Prince")
│── Auteur (Ex: Antoine de Saint-Exupéry)
22
Modèle hiérarchique (Résumé)

Principe Origine Points forts Points faibles

• organise les • Années 1960, • Accès rapide • Difficulté à
données sous IBM IMS aux données modifier la
forme d'arbre, (Information traversant une structure.
avec des Management structure bien
relations System) définie. • Relations rigides
parent-enfant (un seul parent
strictes. • Utilisé dans les • Bonne intégrité par enfant).
systèmes des données.
mainframe.

23
Modèle Réseau
• Une extension du modèle hiérarchique:
• Le modèle reseau autorise des relations plusieurs-à-plusieurs entre des enregistrements liés,
ce qui implique plusieurs enregistrements parents.

• Basé sur la théorie mathématique des ensembles, ce modèle s'articule autour d'ensembles
d'enregistrements connexes.

• Chaque ensemble se compose d'un enregistrement propriétaire (ou enregistrement parent)

et d'un ou plusieurs enregistrements membres (ou enfants).

• Un enregistrement peut être un membre ou un enfant dans plusieurs ensembles, ce qui

permet à ce modèle de traduire des relations complexes.

24
 Modèle Réseau
• Dans les deux modèles, les enregistrements sont
reliés par des pointeurs.
• On stocke l’adresse de l’enregistrement auquel il
est lié.

• Des SGBD de type hiérarchique ou réseau sont

employés pour des raisons d’efficacité lorsque la
structure des données s’y prête.

• Son pic de popularité remonte aux années 70, après

qu'il a été officiellement défini par la conférence sur
les langages de systèmes de traitement de données
(Conference on Data Systems Languages, CODASYL).

25
https://www.geeksforgeeks.org/network-model-in-dbms/
Modèle Réseau (Résumé)

Principe Origine Points forts Points faibles

• Permet des • CODASYL • Meilleure • Complexité de
relations plus (Conference on flexibilité dans gestion des
flexibles que le Data Systems les relations liens.
modèle Languages) dans
hiérarchique, les années 1960 • Plus efficace • Langage de
avec des que le modèle requête difficile
connexions hiérarchique à manipuler
multiples entre pour certaines
les entités requêtes

26
Modèle Relationnel
• Proposé en 1970, par E. F. Codd dans l’article :
« A Relational Model of Data for Large Shared Data Banks »,
CACM 13, no 6, June1970.

• Il cherchait à créer un langage d’interrogation des bases de

données plus proche du langage naturel.

• Dans cette optique, il fonde sa recherche sur des concepts

mathématiques rigoureux, tels que la théorie des ensembles et
la logique du premier ordre.

• Le modèle relationnel permet de modéliser les informations

contenues dans les bases de données en utilisant des relations,
c’est-à-dire des ensembles d’attributs.
27
Modèle Relationnel
• De l’idée de départ à la réalisation d’un produit utilisable, le laps de
temps est souvent de l’ordre d’une décennie.

• La mise en oeuvre des idées de Codd s’est fait chez IBM dans le
cadre du projet de recherche System-R.

• Le premier produit commercial était non pas le fait d’IBM, mais

celui d’Honeywell en 1976.

• Il serait suivi d’un produit réellement abouti de chez

Relationnel Software en 1980 (Oracle), qui a connu le succès
que l’on sait.

• De son côté, IBM en tirera un produit qui deviendra DB2.

28
Modèle Relationnel
• Toujours dans le cadre du projet de recherche System-R:
• E. F. Codd a mis au point, en même temps que le modèle
relationnel,
• Un langage d’interrogation des données, SEQUEL
• SEQUEL deviendrait ensuite SQL (Structured Query Language).

• La normalisation du langage SQL dès 1986 par l’ANSI, puis par l’ISO,

• => a assuré pour une grande partie le succès du modèle

relationnel auprès des entreprises.

• La normalisation de ce langage a garanti sa pérennité, même si son

évolution s’en trouve ralentie.
29
Modèle Relationnel
• Fait rare dans le monde informatique, ce langage a été adopté
par la quasi-totalité des éditeurs commerciaux qui participent
activement à son évolution.

• SQL est devenu le standard, même si aucun éditeur ne respecte

à la lettre la norme.

• Les requêtes écrites pour un SGBD fonctionnent en général sans

trop de modifications avec un autre SGBD
• ce qui permet d’envisager des migrations moins complexes
et de conserver une partie de l’investissement initial.

30
Modèle Relationnel
• Aperçu:
• Le modèle relationnel et le modèle le plus courant.
• Les données sont tries dans des tables, que l'on
appelle aussi des relations, dont chacune se
compose de colonnes et de lignes.
• Chaque colonne contient un attribut de l'entité en
question, comme le prix, le code postal ou la date
de naissance.
• L'ensemble des attributs d'une relation est appelé
domaine.
• Chaque ligne, également appelée tuple, comprend
des données sur une instance spécifique de l'entité
en question, comme un employé en particulier.
• Le modèle tient également compte des types de
relations entre ces tables. e.g. un-à-un, un-à-
plusieurs,…
31
https://fr.wikipedia.org/wiki/Mod%C3%A8le_relationnel
Modèle Relationnel (Résumé)

Principe Origine Points forts Points faibles

• Stocke les • Introduit par • Simplicité et • Scalabilité
données sous Edgar F. Codd en normalisation des limitée sur les
forme de tables 1970 données grands volumes
avec des de données.
relations • SQL, un langage
standardisé et
puissant • Moins adapté
aux données
• Bonne intégrité et
semi-structures.
contrôle des
données

32
Modèle Objet
Encapsulation
• Dans le sillage du développement des langages
orientés objet (C++, Java…) dans les années 1980, le
concept objet a été adapté aux bases de données.

• Plusieurs raisons, en dehors des qualités reconnues

de l’approche objet, ont conduit à définir une
extension objet pour les bases de données.

• Le modèle relationnel, dans sa simplicité, ne

permet pas de modéliser facilement toutes les
réalités. Héritage

• Un objet permet de représenter directement un

élément du monde réel.
33
Modèle Objet
• Les structures d’éléments complexes se retrouvent souvent dispersées entre plusieurs tables dans
l’approche relationnelle classique.

• De plus, le concept objet est mieux adapté pour modéliser des volumes de texte importants ou
d’autres types de données multimédias (sons, images, vidéos…).

• Il est beaucoup plus commode de manipuler directement des objets lorsque l’on développe avec
un langage à objet (comme C++ ou Java).

• Les bases de données « orientées objet » apportent ainsi aux applications développées en
langage objet la persistance des objets manipulés :
• Ces derniers peuvent ainsi directement être réutilisés par l’application d’origine ou par d’autres sans
redéfinition.

34
Modèle Objet
• Aperçu:
• Ce modèle définit une base de données comme une
collection d'objets, ou d'éléments logiciels réutilisables,
associés à des caractéristiques et des méthodes.

• Il existe plusieurs types de bases de données orientées

objet :
• Une base de données multimédia réunit des médias, tels que
des images, qui ne peuvent pas être stockés dans une base de
données relationnelle.
• Une base de données hypertextuelle permet à n'importe quel
objet d'être relié à un autre. Elle est utile pour organiser de
nombreuses données disparates, mais peu adaptée à l'analyse
numérique.

35
Modèle Objet
• Les produits commerciaux adaptés à ces concepts n’ont pas connu une diffusion suffisamment
importante.

• Le monde des bases de données évolue assez lentement :

• La migration d’un système d’information vers l’objet représente pour une organisation
un investissement considérable qui n’est pas toujours justifié.

• La robustesse et la popularité de l’approche relationnelle, qui a mis presque vingt ans à

s’imposer, a également freiné le développement de l’approche objet pure dans les bases de
données.

• Les données modélisées sous forme d’objets sont aussi plus complexes à représenter du
point de vue du SGBD et l’on rencontre encore très souvent des problèmes de performance.

36
Modèle Objet (Résumé)

Principe Origine Points forts Points faibles

• Permet de • Développé dans • Manipulation • Moins adopté
stocker les années 1980 directe des que le
directement des en réponse aux objets relationnel.
objets limitations du
complexes. modèle • Compatible • Performance
relationnel. avec les parfois
• Prend en langages inférieure à
considération orientés objet d'autres
les principes des modèles
la POO.

37
Autres modèles de bases de données
• D'autres modèles (NoSQL) sont venus s'opposer au modèle relationnel :

Modèle clé-valeur Modèle document

Modèle graphe Modèle colonne-famille

38
Modèle Clé-Valeur “Key-Value Store”

Principe Origine Points forts Points faibles

• Stocke les • Popularisé par • Haute • Pas de support
données sous les bases NoSQL performance natif pour les
forme de paires comme Redis et pour les requêtes
clé-valeur, offrant DynamoDB lectures à faible complexes.
un accès très
latence
rapide.
• Pas de schema. • Difficile à
• Scalabilité modéliser pour
élevée certaines
applications.

39
 Modèle Clé-Valeur “Key-Value Store”

40
https://www.michalbialecki.com/wp-content/uploads/2018/03/cosmos-db-key-value-schema.png
Modèle Document

Principe Origine Points forts Points faibles

• Stocke les • Popularisé par • Adapté aux • Moins efficace
données sous MongoDB et données semi- pour les jointures
forme de CouchDB. structures. complexes.
documents JSON
ou BSON, offrant • Facile à faire
une structure évoluer.
flexible.

41
 Modèle
Document

https://stph.scenari-community.org/bdd/0/co/nos03.html 42
Modèle Graphe

Principe Origine Points forts Points faibles

• Utilise des nœuds • Popularisé par • Idéal pour les • Moins adapté aux
et des relations Neo4j, ArangoDB. réseaux sociaux, données
pour stocker des la détection de transactionnelles
données frauds. classiques.
fortement
connectées. • Requêtes très
performantes sur
les relations.

43
 Modèle Graphe

44
https://stph.scenari-community.org/bdd/0/co/nos03.html
Modèle Colonne-famille

Principe Origine Points forts Points faibles

• Stocke les • Utilisé par Apache • Optimisé pour le • Complexité de
données en Cassandra et stockage et gestion.
colonnes plutôt HBase. l’analyse de
qu’en lignes, grands volumes. • Moins adapté aux
optimisé pour les relations
analyses Big Data. • Haute scalabilité. complexes

45
 Modèle Colonne-famille

46
https://stph.scenari-community.org/bdd/0/co/nos03.html
Différents
Modèles

47
Choix du modèle
• Un modèle de données est essentiel pour structurer l’information et garantir l’efficacité des bases de
données.

• Le choix du modèle dépend des besoins spécifiques du système :

• SQL (relationnel) pour la rigueur et la structuration des données.

• NoSQL pour la flexibilité et la gestion des gros volumes de données.

• Modèles spécialisés (graphes, colonnes, objets) pour des cas d’usage spécifiques.

48
Introduction aux bases de données
• Qu’est ce qu’une base de données?
• Modèles de données
• Système de gestion de bases de données
• Etapes de la conception des bases de données

49
Niveaux d’abstraction

Ce modèle, qui date de 1975, s’inscrit dans les concepts

et théories de la première génération des bases de
données, dont l’objectif est d’avoir une indépendance
entre les données et les traitements.

Modèle élaboré par la commission SPARC de l’ANSI

50
Niveaux d’abstraction
• Niveau externe: (Schéma utilisateur / Vues)

• Ce niveau définit la manière dont les utilisateurs voient les données.

• Une Vue est une représentation filtrée ou organisée d’une base de

données, adaptée aux besoins spécifiques d’un utilisateur ou d’une
application.

• Pourquoi c'est important ?

• Permet d’offrir différentes perspectives des données selon le profil
utilisateur.
• Garantit la sécurité en masquant certaines informations sensibles.

51
Niveaux d’abstraction
• Niveau conceptuel: (Schéma logique global)

• C’est la vue globale et logique des données, indépendamment de leur stockage

physique.

• Il décrit les entités, leurs relations et les contraintes sous une forme standardisée
(ex. modèle relationnel avec des tables et des clés étrangères).

• Pourquoi c'est important ?

• Assure une indépendance entre les applications et le stockage physique.
• Définit une structure unique pour l’ensemble de la base de données.

52
Niveaux d’abstraction
• Niveau interne: (Schéma physique)

• Ce niveau décrit comment les données sont stockées sur le disque ou en

mémoire.

• Il concerne les fichiers, les index, les blocs de stockage, les accès disque, la
compression, etc.

• Pourquoi c'est important ?

• Optimise les performances des requêtes en choisissant des structures de
stockage adaptées.
• Permet une gestion efficace des accès concurrents et de la récupération
des données.
53
 Niveaux d’abstraction (Résumé)

Niveau d’Abstraction Rôle Exemple

Niveau Externe Vue utilisateur Un lecteur voit uniquement ses emprunts

Niveau Conceptuel Structure logique Modèle relationnel avec tables et relations

Fichiers, index, organisation des données

Niveau Interne Stockage physique
sur disque

Ce modèle garantit l’indépendance entre les données et leur stockage, ce qui facilite
l’évolution des bases de données sans impacter les utilisateurs ni les applications.
54
Niveaux d’abstraction et SGBD
• Un SGBD idéal doit posséder les principales caractéristiques qui découlent de ce modèle en
couches.

• Indépendance physique des données. Possibilité de modifier l'organisation physique

(Structures de stockage) sans modifier les programmes (façon dont les données sont définis).

• Indépendance logique des données. Un même ensemble de données peut être vu

différemment par des utilisateurs différents.

• Intégrité des données. Faire en sorte que l’information résultant des liens entre les données
soit cohérente.

55
SGBD
• Un Système de Gestion de Bases de Données (SGBD) est un logiciel qui permet de créer,
gérer, manipuler et sécuriser des bases de données.

• Il agit comme un intermédiaire entre les utilisateurs et les données en offrant un cadre
structuré pour le stockage et la récupération efficace des informations.

• Exemples de SGBD :
• SGBD relationnels (SQL) : MySQL, PostgreSQL, Oracle, SQL Server
• SGBD NoSQL : MongoDB, Cassandra, Redis
• SGBD orientés objet : Db4o, ObjectDB

56
Pourquoi utiliser un SGBD ?
• Les SGBD offrent plusieurs avantages par rapport au stockage manuel des données (ex.
fichiers texte, feuilles Excel) :

• Stockage structuré → Organisation des données en tables, documents ou objets.

• Accès rapide → Indexation et requêtes optimisées.
• Sécurité et permissions → Gestion des droits des utilisateurs.
• Intégrité des données → Contraintes (unicité, références) pour éviter les incohérences.
• Gestion de la concurrence → Plusieurs utilisateurs peuvent accéder aux données
simultanément.
• Sauvegarde et récupération → Protection contre les pertes accidentelles.

57
Architecture d’un SGBD
• Un SGBD repose sur plusieurs composants clés :

• Moteur de stockage → Gère le stockage physique des données sur disque.

• Moteur de requêtes → Interprète et exécute les requêtes SQL ou NoSQL.

• Gestion des transactions → Garantit l’atomicité, la cohérence, l’isolation et la durabilité

(ACID).

• Gestion des utilisateurs → Contrôle l’accès aux données via des permissions et rôles.

• Interfaces d’accès → Langages et API (SQL, REST, JDBC) pour interagir avec les données.

58
SGBD : Propriété ACID
• Gestion des transactions:
• En ce qui concerne les opérations de modification effectuées sur la base de données,
que l’on appelle des transactions, les propriétés suivantes doivent être assurées:

• Atomicité.
• La transaction est exécutée entièrement ou abandonnée.
• Cohérence.
• La transaction doit se faire d’un état cohérent de la base vers un autre état
cohérent.
• Isolation.
• Des transactions simultanées ne doivent pas interférer entre elles.
• Durabilité.
• La transaction a des effets permanents même en cas de panne.
59
SGBD : Propriété ACID
• Atomicité
• Une transaction se fait au complet ou pas du tout

• Si une partie d'une transaction ne peut être faite, il faut effacer toute trace de la
transaction et remettre les données dans l'état où elles étaient avant la transaction.

• L'atomicité doit être respectée dans toutes situations, comme une panne
d'électricité, une défaillance de l'ordinateur, ou une panne d'un disque magnétique.

Exemple:
- Un transfert de fonds d'un compte de banque à un autre, même s'il implique plusieurs
actions comme le débit d'un compte et le crédit d'un autre, est une seule transaction.
60
SGBD : Propriété ACID
• Cohérence

• Chaque transaction amènera le système d'un état valide à un autre état valide

• Tout changement à la base de données doit être valide selon toutes les règles
définies, incluant mais non limitées aux contraintes d'intégrité, aux rollbacks en
cascade, aux déclencheurs de base de données, et à toutes combinaisons
d'événements.

61
SGBD : Propriété ACID
• Cohérence
Exemple:
- Considérons la table suivante: CREATE TABLE acidtest (A INTEGER, B INTEGER, CHECK (A + B = 100));

- Supposons qu'une transaction tente de soustraire 10 de A sans modifier B.

- Étant donné que la cohérence est vérifiée après chaque transaction, on sait
que A + B = 100 avant le début de la transaction.
- Si la transaction supprime 10 de A avec succès, l'atomicité sera atteinte. Cependant, un
contrôle de validation montrera que A + B = 90, ce qui est incompatible avec les règles de
la base de données.
- L'intégralité de la transaction doit être annulée et les lignes concernées restaurées à leur
état antérieur à la transaction.

62
SGBD : Propriété ACID
• Isolation
• Toute transaction doit s'exécuter comme si elle était la seule sur le système.

• Aucune dépendance possible entre les transactions.

• La propriété d'isolation assure que l'exécution simultanée de transactions

produit le même état que celui qui serait obtenu par l'exécution en série des
transactions.

63
SGBD : Propriété ACID
• Isolation
Exemple:
- Considérons la table suivante: CREATE TABLE acidtest (A INTEGER, B INTEGER, CHECK (A + B = 100));
- Considérez deux transactions : T1 transfère 10 de A à B. T2 transfère 20 de B à A.
- Ensemble, il y a quatre actions :
- T1 soustrait 10 à A.
- T1 ajoute 10 à B.
- T2 soustrait 20 à B.
- T2 ajoute 20 à A.
- Si ces opérations sont effectuées dans l'ordre, l'isolation est maintenu, même si T2 doit
attendre
- Considérez ce qui se passe si T1 échoue à mi-chemin. La base de données élimine les effets
de T1 et T2 ne voit que les données valides. 64
SGBD : Propriété ACID
• Isolation
Exemple:
- Considérez deux transactions : T1 transfère 10 de A à B. T2 transfère 20 de B à A.
- Ensemble, il y a quatre actions :
- T1 soustrait 10 à A.
- T2 soustrait 20 à B.
- T2 ajoute 20 à A.
- T1 ajoute 10 à B.
- Si T1 échoue lors de la modification de B à l'étape 4.
- Au moment où T1 échoue, T2 a déjà modifié A ; On ne peut pas restauré à la valeur qu'il avait
avant T1 sans laisser une base de données invalide.

65
SGBD : Propriété ACID
• Durabilité
• assure que lorsqu'une transaction a été confirmée, elle demeure enregistrée même à
la suite d'une panne d'électricité, d'une panne de l'ordinateur ou d'un autre
problème.

• Exemple:
- Considérez une transaction qui transfère 10 de A à B.
- Tout d'abord, elle supprime 10 de A, puis elle ajoute 10 à B.
- À ce stade, l'utilisateur est informé que la transaction a réussi.
- Cependant, les modifications sont toujours mises en file d'attente dans la mémoire
tampon du disque en attendant d'être validées sur le disque.
- L'alimentation tombe en panne et les modifications sont perdues, mais l'utilisateur
pense que les modifications persistent. => Echec de la Durabilité 66
DB-Engines Ranking

https://db-engines.com/en/ranking

67
Notion : Metadonnée
• En utilisant une base de données, on assure une indépendance entre le traitement
et les données:

• Les données peuvent évoluer sans impacter directement les programmes qui
les utilisent.

• C’est pourquoi, il est nécessaire que l’application obtienne des informations sur la
structure des données (nom, type, taille, etc.).

68
Notion : Metadonnée
• => On associe à la base de données une description que l’on appelle :

• Métadonnées: sont des données sur les données.

• Catalogue: est un ensemble structuré de métadonnées qui décrit les objets

stockés dans la base.

• En plus de la structure et du type des données, on stocke également à cet endroit

les informations concernant les règles de cohérence des données.

69
 Notion : Metadonnée Chaîne de
caractères de
Nombre entier
< à l’année en
Chaîne de
caractères de
taille 50 cours taille 50

Idée Générale:
Titre Auteur Anne_Publication Genre ISBN
- Independence de l’application par
Introduction to the
rapport à la représentation interne Michael Sipser 1997
Informatique
978-1-133-18779-0
Theory of
des données. théorique
Computation
=> une abstraction des données Artificial
Stuart Russell, Intelligence
Intelligence: A 1995 978-0-13-461099-3
Peter Norvig artificielle
- C’est la raison pour laquelle on utilise Modern Approach
une description des données sous la Abraham
forme d’un modèle pour permettre la Database System Silberschatz, Bases de
1986 978-0-07-802215-9
Concepts Henry F. Korth, données
restitution la plus efficace possible de S. Sudarshan
l’information.
Table : Livres (Base de données d'une bibliothèque)

70
Notion : Catalogue
• Le catalogue d’une base de données contient des informations sur :

• Les tables (noms, colonnes, types de données…)

• Les index (clés primaires, index secondaires…)
• Les relations (contraintes, clés étrangères…)
• Les vues et procédures stockées
• Les utilisateurs et leurs permissions

71
Introduction aux bases de données
• Qu’est ce qu’une base de données?
• Modèles de données
• Système de gestion de bases de données
• Etapes de la conception des bases de données

72
Étapes de la conception des bases de
données
• On peut décomposer le processus de conception
d’une base de données en plusieurs étapes :
L’analyse du système du monde
réel à modéliser

La mise en forme du modèle

pour l’intégrer dans un SGBD

La création effective dans le

SGBD des structures et leur
remplissage
73
Étapes de la conception des bases de
données
• 1- Analyse du monde réel:
• Une étape qui se fonde en partie sur des entretiens avec les personnels concernés.
• Elle consiste en une analyse des entretiens et de l’organisation de l’entreprise.
• Lors de cette phase, on :
• détermine les objectifs du système d’information à concevoir.
• identifie tous les éléments (Champs) à prendre en compte dans le système.
• Un ensemble de champs peut constituer un objet du monde réel.
• Ex: les champs « nom », « prénom» et « adresse » constituent une « personne
».
• identifie les liens à modéliser entre les objets ainsi que les éléments
caractéristiques de ces liens.
• exprime les règles qui définissent le domaine de validité du contenu des champs.

74
Étapes de la conception des bases de
données
• 1- Analyse du monde réel:
• Cette modélisation du monde réel permet de proposer un schéma conceptuel qui servira à la
description générale du système d’information.

• La notion de sens des données et surtout des liens entre les entités ne sera réellement
exprimée que dans ce schéma qui est plus proche du monde réel.

• Ce schéma est souvent réalisé à l’aide de la symbolique du modèle « entité-association » ou

exprimé avec le langage UML (Unified Modeling Language).

75
Étapes de la conception des bases de
données
• 2- Passage au SGBD:
• La représentation précédente doit être transformée pour la rendre acceptable par le SGBD,
qu’il soit relationnel, objet ou relationnel-objet.

• Souvent, cette étape modifie considérablement les objets du monde réel ainsi que les liens
définis dans le schéma précédent.

• Lors de cette phase:

• On vérifie la qualité de la base de données en utilisant des critères pour éliminer par
exemple la redondance,….
• Le modèle relationnel procure à cette fin des outils capables de tester la cohérence du
système et de le modifier le cas échéant : ce sont les « formes normales ».
• On définit les « vues » du système d’information qui sont adaptées à chaque catégorie
d’utilisateurs.
76
Étapes de la conception des bases de
données
• 2- Passage au SGBD:

• Il est possible de constater des incohérences à ce niveau de l’analyse, ce qui implique de

modifier le modèle conceptuel de données développé à l’étape précédente.

• On obtient un schéma des données qui fournira aux utilisateurs les informations nécessaires
pour effectuer leurs requêtes, par exemple la description des noms de tables, de champs et
leurs types.

• Par contre, on perd à ce niveau l’information du « sens » des données et du lien entre elles.

77
Étapes de la conception des bases de
données
• 3- Création et utilisation de la BD

• Une fois le schéma précédent défini, on utilise le SGBD pour passer à la création des tables
qui constituent la base de données.

• Puis, on insère les valeurs dans les tables.

• Le cas échéant, on crée les vues définies à l’étape précédente et les utilisateurs concernés.

• Le système est alors opérationnel. Cette étape se fait forcément en utilisant le SGBD.

78
Qualité d’une BD
• L’un des objectifs de la création d’une base de données est de pouvoir retrouver les données par
leur contenu.
• Dans cette optique, il faut s’assurer que les données contenues dans la base sont de « bonne
qualité ».

• Les principaux critères de qualité d’une BD:

• La cohérence des données

• L’absence de redondance

79
Qualité d’une BD
• La cohérence des données:
• Elle est fondamentale
• Elle nécessite une réflexion préalable sur la normalisation du contenu des champs
• Problèmes à résoudre: Silence et Bruit

• Exemple (Silence):
• On suppose qu’un champ contient la qualité d’une personne (par exemple, Monsieur,
Madame, Mademoiselle).

• Si l’on trouve dans ce champ ‘Mr’ à la place de ‘Monsieur’, il est clair que les recherches
sur ce champ par le contenu ‘Monsieur’ risquent d’être erronées.

• => Silence: Certains résultats pertinents seront ignorés lors d’une interrogation

80
Qualité d’une BD
• La cohérence des données:
• Elle est fondamentale
• Elle nécessite une réflexion préalable sur la normalisation du contenu des champs
• Problèmes à résoudre: Silence et Bruit

• Exemple (Bruit):
• On suppose qu’un champ contient la qualité d’une personne (par exemple, Monsieur,
Madame, Mademoiselle).

• Si l’on saisit ‘Mme’ pour ‘Madame’ et ‘Melle’ pour ‘Mademoiselle’, et qu’il y ait eu par
erreur plusieurs saisies de ‘Mme’ alors qu’il s’agissait d’une demoiselle, la recherche par
le contenu ‘Mme’ donne cette fois plus de résultats qu’il n’y a réellement de dames

• => Bruit: Certains résultats non pertinents seront retrouvés lors d’une interrogation
81
 Qualité d’une BD
• La redondance:
• Elle est parfois plus déliquate á identifier

- Carnet d’adresse contient en même

temps le code postal et le nom de la
ville. (Redondance)

- Incohérence dans la saisie du nom de la

ville ‘Bordeaux’.

L’approche relationnelle procure des outils capables de détecter et d’améliorer

considérablement ce genre de problèmes de qualité des bases de données

82