Licence MPCI

Base de Données

Rémi Eyraud
Remi.Eyraud@lis-lab.fr
https://pageperso.lis-lab.fr/~remi.eyraud/WP/?page_id=129

1
 Organisation de l'UE
●
Premier cours : lundi 14 janvier, 16h-18h
●
Mercredi 16/01 : Cours (13h45 – 15h45)
●
Vendredi 18/01 : TD (8h – 10h)
●
Lundi 21/01 : Cours-TD (16h – 18h)
●
Mercredi 23/01 : DS (10h15 – 12h15)
●
Vendredi 25/01 : Cours (8h – 10h)
●
Lundi 28/01 : TP (16h – 18h)
●
Mercredi 30/01 : Cours (16h – 18h)
●
Lundi 4/02 : TD (16h – 18h)
●
Vendredi 8/02 : ?? (8h – 10h)
●
Mercredi 13/02 : TP noté (10h15 – 16h)
●
Vendredi 15/02 : Cours (8h – 10h)
●
Lundi 25/02 : TD (16h – 18h)
●
Mercredi 27/02 : TP (16h – 18h)
●
Vendredi 1/03 : ?? (14h30 – 16h30)
●
Mercredi 6/03 : ?? (16h – 18h)
●
Mercredi 20/03 : Examen final (13h45 – 15h45) 2
Plan du cours de Base de Données
●
Vaste introduction
●
Le modèle relationnel
●
Le langage SQL
●
Conception de BD
●
Bd & python

3
 Introduction

Dans quel(s) domaine(s) trouve-t-on

des bases de données ?

4
 Introduction

Qu'est-ce qu'une base de données ?

7
 Introduction

Exemples et contre-exemples
●
Toute source de donnée
●
Un fichier texte
●
Un ensemble de fichiers textes
●
Un site internet quelconque
●
Le web dans son ensemble
●
Un répertoire de téléphone portable
●
L'ensemble des information utilisées par la SNCF
pour l'achat d'un billet de train.
9
 Introduction

Usagers des BD
●
Il existe 3 catégories d'usagers des bases de
données :
– les usagers interactifs
– les programmeurs d'applications
– les administrateurs

11
 Usagers des Bases de Données

Les usagers interactifs

●
Une personne quelconque (ne sachant même pas
qu'il utilise une BD).
– Ex.: quelqu'un consultant des horaires de trains sur le
site de la SNCF
●
Une personne visualisant le contenu d'une base à
l'aide d'une interface graphique conviviale.

12
 Introduction

Les programmeurs d'applications

●
Construisent les interfaces destinées aux usagers
interactifs.
●
Sont spécialistes d'un langage de définition et
d'interrogation de données (ex: SQL).
●
Exemple : développeur web.

13
 Introduction

Les administrateurs
●
Définissent (parfois) et maintiennent la base de
données.
●
Possèdent plus de droits sur la base.
●
2 types :
– concepteur
– administrateur
●
Exemple : vous, à la fin de ce cours ☺

14
 Introduction

Types de Base de Données

●
3 types :
– BD personnelles (10 à 100 Ko)
– BD professionnelles (100 Ko à 1 To)
– Très grande BD (de 1 To à 1 Po)
– Très très très grande (plus de 1 Po)
●
Exemples :
– Répertoire téléphonique
– Données clients d'une PME
– SNCF (10 To en 2016)
– Facebook ( > 100 Po, + 500 To par jour) 15
 Introduction

SGBD
Système de Gestion de Base de Données :
●
But : simplifier la tache des usagers (tout les types).
●
Rôle : aide au développement et à l'exploitation des BD
●
Caractéristiques :
– définition et programmation de BD
– contrôle et sécurité de BD
– optimisation des accès à la base
●
fourni : le(s) langage(s) nécessaire(s) (déclaratifs ou
procéduraux) à la manipulation des données (lecture &
écriture).
16
 Introduction

SGBD (suite)
●
Gestion des couches physiques ET logiques
●
Certains SGBD intègrent des outils connexes:
– générateurs (de rapport, d'applications, d'interface, etc.)
– utilitaires (calcul de statistiques, ...)
– interface web
– outils de fouille de données
●
Un administrateur doit parfaitement connaître le
SGBD de sa base.

17
 Historique

Bref historique
●
3 grandes phases :
– La préhistoire (1950-1970)
– La révolution (1970)
– L'ère post-révolutionnaire

18
 Historique

Historique : la pré-préhistoire
●
basée sur les fichiers
●
Chaque application définit et gère ses propres
fichiers, reliés par des pointeurs
●
Positif : premières idées
●
Négatif :
– structure du stockage visible dans le code (struct en C)
– dépendance donnée/programme (portabilité nulle)
– redondance des données (taille, maintenance, ...)
– Pas de vrai SGBD
19
 Historique

Historique : la préhistoire (1965-1970)

●
Approche navigationelle
●
Systèmes hiérarchiques et réseaux
●
A base de fichiers gérés par arborescence de
pointeurs
●
Positif : fin de la redondance, premier vrai SGBD
●
Négatif : mélange logique/physique, accès
procéduraux (programmation lourde), “one-
record-at-a-time”
●
Toujours utilisés (SGBD : IDS2, IMS2, PHOLAS)
20
 Historique

Historique : la révolution
●
Approche relationnelle
●
Premier SGBD relationnel en 1980
●
idée majeure : indépendance des données (séparation
application/implémentation)
●
Positif :
– simplicité des concepts de base

– existence d'un cadre théorique simple

– modèle de données (respect de l'intégrité)
– approche déclarative de haut niveau (SQL)
– SGBD performants (accès concurrents, optimisation,
pannes)
– portabilité des bases et des applications
21
 Historique

Historique : la révolution (suite)

●
Négatif :
– types de données prédéfinis (inadaptés aux données complexes)
– modélisation conceptuelle pauvre
– trop grande séparation données/opération (les procédures ne
font pas parties du modèle)
– théorie relationnelle pas entièrement exploité (ex: contraintes
d'intégrité)
– grand écart entre SQL et langages de programmation
– pas adapté à la fouille
●
La plupart des bases actuelles sont relationnelles (SGBDR :
Oracle, PosgreSQL, SQLite, DB2, Informix, ...) 22
 Historique

Historique : la nouvelle génération

●
Approche post-relationnelle (Not Only SQL - NoSQL)
●
Pour des applications de + en + complexes
●
Plein de catégories :
– approche orientée objet
– approche par documents semi-structurés (XML)
– Données hétérogènes complexes (vidéos, images, sons, etc.)
●
Permet une intégration des idées de l'intelligence
artificielle (base de donnée déductives, Business
Intelligence, data science)
●
Pas autant utilisée que les SGBDR mais en progression
constante. 23
 Modélisation des données

Plan de ce cours
●
Introduction
●
Modélisation des données
– principes
– différents niveaux
– modèle entité-relation
●
SGBD
– objectifs
– fonctionnalités
– architectures
24
 Modélisation des données

Modélisation des données

●
Principe premier : séparer description des
données et manipulation par des programmes.
●
description : spécification des structures des
données et de leurs types.
●
manipulation : opération d'interrogation,
d'insertion, mise à jour, suppression.
●
Réalisation : norme ANSI-SPARC.

25
 Modélisation des données

Décrire les données : définitions

●
Données = ensembles reliés par des associations
(= ensembles de liens).
Exemple : base de données cinématographique
– Ensemble des films
– Ensemble des acteurs
– Association entre les films et les acteurs (ensemble de
liens film ↔ acteurs)
décrire les données c'est définir ces ensembles via
leurs propriétés / leurs caractéristiques
26
 Modélisation des données

Décrire les données : définitions

●
4 grandes notions :
– Type de donnée : construction informatique spécifiant un
ensemble de données via leurs caractéristiques et les
opérations applicables.
– Instance : une donnée particulière appartenant à un type
spécifié + identifiant. Créées par insertion dans la base
– Modèle de description : spécification d'un ensemble de
types, parfois graphique.
– Schéma : mise en oeuvre du modèle de description à l'aide
d'une Langage de Description de Données (LDD).
●
LDD : souvent algébrique (SQL) ne nécessite pas d'exécution.
27
 Modélisation des données

Décrire les données : exemples

●
Le type Entier muni des opérations standards de
l'arithmétique est un type de donnée (élémentaire). 12 est une
instance de ce type.
●
Le type Film avec ses propriétés : titre, réalisateur, langues,
acteurs, durée, année, etc. muni d'opérations internes comme
traduire est un type composé.
●
Le film (“Usual suspects”, “Bryan Singer”, [anglais,
français], [“Byrne”, “Spacey”, “Del Toro”], 108, 1994) est
une instance du type Film dont l'identifiant pourrait être le
produit cartésien des valeurs de chaque propriété nommée.
● Le type générique Entité avec les propriétés p1, p2...pn et les
opérations Créer, Afficher, Modifier, Supprimer.
28
 Modélisation des données

Les niveaux d'abstraction

●
Selon l'ANSI-X3-SPARC, 3 niveaux spécifiant
clairement le passage de la vision de chaque
utilisateur à la représentation en machine.
●
facilite la construction, la maintenance,
l'évolution des BD
●
Les SGBD actuels ont tendance à n'utiliser que 2
niveaux MAIS il est important de comprendre ces
3 niveaux lors de la phase de conception.

29
 Modélisation des données

Le niveau conceptuel
(chapitre 2)
●
Niveau le plus important, détaillé avant même la
réalisation de la base.
●
Il conditionne :
– la qualité de la base
– les développements au sein du SGBD
– la perception que les utilisateurs auront de la BD
●
il correspond à l'explication et la description sémantique
des concepts et des relations du domaine modélisé.
●
Indépendant d'un SGBD, il reflète une réalité cohérente
du domaine ET des acteurs du domaine.
30
 Modélisation des données

Le niveau conceptuel (suite)

Le schéma conceptuel d'une BD couvre (mini) :
– La référence aux concepts élémentaires. Ex.: la durée
d'un film est un entier positif correspondant au nombre
de minutes.
– La définition des types composés : regroupement des
propriétés nommées d'un ensemble d'objets. Cet
ensemble est soit un concept du monde modélisé, soit
une association entre concepts. Ex.: à suivre
– Les règles que doivent respectées les données au cours
de leur vie. Ex.: un Film doit obligatoirement avoir un
titre, un acteur doit avoir joué dans au moins un Film,
etc. 31
 Modélisation des données

Le niveau conceptuel (fin)

Ex. de définition de types composés et d'associations
Types d'objets :
FILM(titre, année, durée, nbPrix, réalisateur)
ACTEUR(nom, prénom, dateNaissance, photo)
Type d'association :
CASTING(FILM, ACTEUR, personnage)

Note : toutes les relations ne sont pas explicités. Par exemple, deux
acteurs peuvent être en relation parce qu'ils ont joué dans le même film.

32
 Modélisation des données

Le niveau interne
(Cours de Master 1 Info)
●
Niveau le plus proche de l'implémentation
●
Concerne la façon dont les données sont stockées.
●
La définition du schéma interne est donc
fortement lié au choix du SGBD.
●
Contenu :
– les fichiers contenant les données
– les articles de ces fichiers (leur longueur, mode de
placement, etc.)
– le mode d'accès à ces articles (pointeur/index, etc.)
●
Dérive du schéma conceptuel. 33
 Modélisation des données

Le niveau externe
(fin du cours, peut-être)
●
Le niveau externe spécifie des vues différentes
associée aux différents groupes d'utilisateurs.
●
Eloigné du niveau interne, dépendant du niveau
conceptuel.
●
On définit donc 1 ou plusieurs schémas externes.
Chaque schéma définit la manière dont un
utilisateur perçoit la base dans ses applications.
●
Il spécifie les droits d'accès.

34
 Modélisation des données

Le niveau externe
Exemples de schémas externes possibles pour le
schéma conceptuel de filmographie

35
 Modélisation des données

Les trois niveaux (fin)

●
Les schémas externes dépendent fortement du
schéma conceptuel : impossibilité de définir certaines
vues → le gros du travail (et des difficultés) est au
niveau conceptuel.
●
Figure générale de l'ANSI-SPARC :

36
 Modélisation des données

Le modèle entité-association

●
But : réaliser un schéma conceptuel
●
Permet : description visuelle des entités (=types
d'objets) et de liens entre elles (= relations)
●
Notion principale : agrégation (= la construction
d'un objet complexe/composé à l'aide d'objets
plus élémentaires).
●
monde = distinction entre agrégations de
données élémentaires (entités) et des liaisons
entre ces entités (=relations)
●
Entité = agrégation d'attributs (nommés et typés)
37
 Modélisation des données

Modèle entité-association : exemple

Spécifier un schéma conceptuel revient (presque) à fournir

un modèle entité-relation et à le préciser par diverses
informations.
38
 SGBD

Objectif des SGBDs

●
Nous avons vu le rôle des SGBD, nous verrons leurs
principes permettant de mettre en oeuvre leurs
objectifs.
●
Ces principes dépendent fortement des trois niveaux
d'abstraction : l'objectif principal est la gestion des
données en respectant l'indépendance des
programmes aux données, tant aux niveaux logiques
que physique.
●
Langages de haut niveau : quoi VS comment.
S'adressent au niveau logique, stocké dans le
dictionnaire des données.
39
 SGBD

Indépendance physique
●
Si modification du schéma interne alors les
programmes d'applications ne sont pas modifiés.
●
Modifier les propriétés de stockage ne doit pas
modifier le schéma conceptuel.
●
Ex.: ajouter un index dans un fichier, fusionner
deux fichiers, changer le codage des données, ...
●
L'inverse n'est pas vrai.

40
 SGBD

Indépendance logique
●
Le schéma conceptuel résulte d'une synthèse de la vision
d'un ensemble (de groupes) d'usagers : les entités et leurs
relations sont un consensus.
●
Or, un groupe d'usagers doit pouvoir modifier son schéma
externe sans modifier le schéma conceptuel.
●
Avantages :
– chaque groupe voit les données comme il veut
– un groupe peut faire évoluer sa visions sans en faire
pâtir les autres (pas toujours possible)
●
l'inverse (ajout d'attributs, d'entités, d'associations au
schéma conceptuel) doit aussi être (partiellement) possible.
41
 SGBD

Manipuler avec des langages non-

procéduraux
●
Un usagers voit les données indépendamment de leur
implémentation machine.
●
Manipulation des données (au moins consultations)
affranchie du schéma interne.
●
Le moyen d'accéder et de mettre à jour les données est
le problème du SGBD.
●
Langages de (très) haut niveau utilisés :
– s'adresser à la base via entités, relations et propriétés.
– Basés sur la logique du premier ordre et de l'algèbre.
– plusieurs classes (suivant usagers).
42
 SGBD

Administration des données

●
Vie d'une BD :
1 description (3 niveaux)
2 création
3 évolution
● Des outils d'administration des données doivent
être disponibles.
● Ex: un administrateur doit pouvoir régulièrement
contrôler les données, la résolution de conflit
entre vues, etc.
43
 SGBD

Efficacité des accès

●
Mesures :
– débit (nombre de transactions types par seconde)
– temps de réponse (temps moyen pour une requête type)
●
Objectif des SGBD : être bons ☺
●
Les petites requêtes ne doivent pas attendre la fin
des grandes (cf cours de système d'exploitation).
●
Problème majeur : accès disque (10 ms).
Ex. de solution : tampons en mémoire vive.
●
Autre problème : les langages de haut niveau (cf
processus de compilation).
44
 SGBD

Cohérence des données

●
Respect des propriétés élémentaires.
Ex.: la durée d'un film est positive.
●
La modification (ou sa suppression) d'une donnée
mène à reconsidérer d'autres données.
Ex: enlever un acteur de la base implique enlever les
données de type Casting associées.
●
Un SGBD doit veiller à cette cohérence, mise en
oeuvre à l'aide de contraintes d'intégrité (et de
triggers si ils existent).

45
 SGBD

Partage et sécurité
●
Les données sont accessibles simultanément par
plusieurs usagers, de manière transparente (cf SE)
●
Transaction : programme consultant ou modifiant une
base dont l'exécution est indivisible.
Ex.: réservation d'un billet de train
– 2 transactions concurrentes ne doivent pas être
emmêlées (cohérence, mais pas toujours
possible).
– Sécurité :
●
restauration à l'identique après une panne (une
transaction est soit pas exécutée, soit exécutée).
●
gestion des droits d'accès.
46
 Fonctionnalités des SGBD

Fonctionnalités des SGBD

●
Pour atteindre les objectifs précédents, les SGBD
intègrent de nombreuses fonctionnalités.
●
Ce qui suit ne représente que des exemples
simples (liste non-exhaustive).

47
 Fonctionnalités des SGBD

Description des données

(chapitre 4)
●
Réservée aux administrateurs
●
Le SGBD a un langage pour décrire les données aux 3 niveaux
(de + en + souvent graphique).
●
Les 3 niveaux peuvent être partiellement référencés dans le
dictionnaire des données, avec le mode de passage d'un niveau
à l'autre.
●
Exemple en SQL :
CREATE TABLE Film (titre TEXT, annee DATE, duree
INTEGER, nbPrix INTEGER, realisateur VARCHAR);
●
A chaque instructions est associée des contrôles d'intégrité.
Ex.: il ne doit pas déjà exister de table nommée Film.

48
 Fonctionnalités des SGBD

Interrogation de données
(dès le premier TP, chapitre 3)
●
fonctionnalité majeure
●
langage assertionnelle (dans SGBD) pour retrouver
des données par leur contenu, en fonction du schéma
conceptuel, à condition d'être disponibles dans le
schéma externe en question.
●
SQL se base sur la notion de qualification (= une
expression logique de critères simples, cf cours de
logique). Les données sont alors comparables (entre
elles, avec une valeur donnée, ...)
●
Une autre fonctionnalité : la navigation dans les
descriptions (parcours d'association)
49
 Fonctionnalités des SGBD

Interrogation de données : exemples

Sélection des titres de films ayant été tournés après 2007:
SELECT titre
FROM Film
WHERE annee > DATE('2007');
Sélection du nombre de prix de chaque film, indiqué par
son titre, dont ce titre contient le mot “Hunger”:
SELECT titre, nbPrix
FROM Film
WHERE titre LIKE '%Hunger%';

50
 Fonctionnalités des SGBD

Ajout et mise à jour

●
Un SGBD doit permettre l'ajout, la modification
et la suppression de données en maintenant la
cohérence.
●
La modification est souvent précédée d'une
interrogation de la base.
●
Lors d'une suppression, des conséquences en
cascade peuvent intervenir : le SGBD doit
permettre de spécifier le comportement du
modèle dans de tel cas.

51
 Fonctionnalités des SGBD

Ajout et mise à jour : exemples

Modification de la description d'une entité
ALTER TABLE Acteur ADD (initiales VARCHAR);
Ajout d'un Film
INSERT INTO Film ('The big short', '2015', 131, 0, 'McKay');
Ajout des initiales pour chaque acteur (modification de données)
UPDATE TABLE Acteur
SET initiales=FIRST(nom) + '.' + FIRST(prenom) + '.';
Suppression de données
DELETE FROM Casting WHERE personnage='Popeye';

52
 Fonctionnalités des SGBD

Gestion de l'intégrité
●
Un SGBD maintient la cohérence de la base à
condition que les règles de cohérence soient
explicitées :
1 chaque instance d'entité est muni d'un identifiant
unique (contrainte de clé primaire)
2 Une relation associe deux entités (contrainte
référentielle)
3 les valeurs des attributs d'entités doivent appartenir à
un type donné (contrainte de domaine).
●
D'autres contraintes existent.
55
 Architectures principales

Architectures principales
●
Pour atteindre ces objectifs, plusieurs existent.
●
Celle de l'ANSI-SPARC est une architecture
idéale.
●
Actuellement les SGBD ont presque tous une
architecture client/serveur (exception : SQLite)

56
 Quelques repères bibliographiques
●
La “bible” francophone : Bases de données, Georges
Gardarin, éditions Eyrolles.
●
Le site web de l'auteur :
http://georges.gardarin.free.fr/Cours_Total/IndexTotal.html
●
Anglophone : “RDB: A Comprehensive Guide”, Ken
England, Lilian Hobbs, Ian Smith.
●
Plein de sites web “tutoriels”. Exemple :
https://youtu.be/jReDVnyCNdQ?list=PLB9AbbTDeBzT9J
N8-Ow669spvEN8DKAwp
57