Base de données

Concevoir Créer et manipuler une BD

Définitions
SGBD: Système de gestion de base de données (Oracle, Mysql, Sybase…)

BD: Base de données. Ensemble de données (Tables) représentant un domaine fonctionnel. Ex: Système de Facturation.

Table: Ensemble de lignes (Tuple). Un table représente un concept général

Tuple: Représente un concept particulier

Attribut: Représente un aspect d’un concept. C’est une colonne

Définitions
Table :

Tuple:

Attribut:
Clefs primaires et clés étrangères
PK (clef primaire): Ensemble d’attributs identifiant de façon unique un tuple.

 Une PK peut être composée d’un attribut. Ex: Table personne PK(no_secu) ou id_personne
 Une PK peut être composée de plusieurs attributs. Ex: Table commune PK(code_postal, nom)

FK (clef étrangère): Ensemble d’attributs référençant de façon unique le tuple d’une autre table
Contraintes d’integrité
S’expriment par :
 Appartenance des valeurs d’attibuts à des domaines définition de clés
 Normalisation des relations ensemble d’assertations
 Conditions associées aux opérations de mise à jour

Valeur nulle :
 absence ou non-pertinence d’information : nul (ou NUL)

Contrainte d’intégrité d’entité : toute relation possède une clé primaire et les valeurs d’attribut de cette clé doivent être
non nulles.

Contrainte d’intégrité référentielle : chaque valeur d’une clé étrangère Y :

 Soit existe comme valeur de la clé primaire d’un n-uplet de la relation que Y réfère
 Soit nulle
Définitions
BD
Modèles EA & DC Nom des classes :

 Au singulier
 Avec des lettres non accentuées
Conventions de nommage  Commençant par une majuscule
 Camel case
Nom des tables et des attributs
Ex: PierrePrecieuse
 Au singulier
 Avec des lettres non accentuées Attributs
 En minuscules
 Les mots étant séparés par des underscores  au singulier
 avec des lettres non accentuées
Ex:  commençant par une minuscule
 Camel Case
 attribut: couleur_reflet
 table : pierre_precieuse Ex: couleurReflet
 Normalisation

Définition d’un schéma relationnel afin

• D’éviter la redondance des données
• les incohérrences lors des mises à jour
• les anomalies lors des suppressions et/ou des
insertions

La normalisation repose sur l’analyse des

• Dépendance entre attributs
• Decomposition des relations sujettes aux redondance
 Normalisation

exemple (cours F. Trichet (Univ. Nantes))

Une entreprise de vente de bateaux qui souhaite constituer un
système d’information relatif à son activité
achats ID client(NOM CLIENT, PRENOM CLIENT,
ADRESSE CLIENT, IDENTIFICATION BATEAU,
MODELE BATEAU, LONGUEUR BATEAU DATE
ACHAT, MONTANT ACHAT)
problemes potentiels :
Redondance des données
incohérence suite à une mise à jour
anomalies lors d’insertion /
suppression
 Normalisation
exemple
Une entreprise de vente de bateaux qui souhaite constituer un système
d’information relatif à son activité
achats ID client(NOM CLIENT, PRENOM CLIENT, ADRESSE CLIENT,
IDENTIFICATION BATEAU, MODELE BATEAU, LONGUEUR BATEAU
DATE ACHAT, MONTANT ACHAT)
Problèmes potentiels :
redondance des données : achat de plusieurs bateaux
incohérence suite à une mise à jour : changement d’adresse
anomalies lors d’insertion / suppression : client potentiel ne peut pas être
enregistré dans la BD s’il n’a pas encore achète un bateau, lorsqu’un client vend
son bateau il est supprimé du syst`eme d’information
 Normalisation
Autre exemple : BD alpinisme (cours J. Le Maitre (USTV))
r
NOM SOMMET FACE ALTITUDE ANNEé
Everest S 8848 1953
Manaslu S 8125 1972
Hidden-Peak NO 8068 1975
Everest SO 8848 1975

Problèmes potentiels :
insertion : insertion d’un sommet seulement si une première a eu lieu sur celui-ci
modification : si l’altitude de l’Everest est modifiée il faut la modifier dans toutes
les premières de ce sommet
suppression : si l’unique première sur un sommet est supprimée, l’information sur
son altitude est perdue
 Dépendance fonctionnelle

r : relation, X et Y : deux sous-ensembles d’attributs Y depend

fonctionnellement de X ou X determine fonctionnellement Y :
X→Y

si pour toute extension de r , ext(r ), et tout tuples t1 et t2 de

ext(r ) on a

si πX (t1) = πX (t2) alors πY (t1) = πY (t2)

Une dépendance fonctionnelle X → Y est dite élémentaire ou

triviale si Y = ∅ ou Y ⊆ X
 Dépendance fonctionnelle

Exemple de dépendances fonctionnelles

voiture
NUMERO MARQUE TYPE PUISSANCE COULEUR
872RH75 Peugeot P206A 7 BLEUE
975AB80 Peugeot P206A 7 ROUGE

Dépendances fonctionnelles

NUMERO → COULEUR TYPE

→ MARQUE TYPE →
PUISSANCE
(TYPE, MARQUE) →
PUISSANCE
Dépendances fonctionnelles

Exemple de dépendances fonctionnelles

R
NOM SOMMET FACE ALTITUDE Année
Everest S 8848 1953
Manaslu S 8125 1972
Hidden-Peak NO 8068 1975
Everest SO 8848 1975

Dépendances fonctionnelles :

NOM SOMMET → ALTITUDE

(NOM SOMMET, FACE) → ANNEé
Dépendances fonctionnelles

Propriétés de base (Armstrong)

réflexivité : si Y ⊆ X alors X → Y

augmentation : si X → Y alors X ∪ Z → Y ∪ Z

transitivité : si X → Y et Y → Z alors X → Z
Propriétés deduites
union : si X → Y et X → Z alors X → Y ∪ Z

pseudo-transitivité : si X → Y et W ∪ Y → Z alors
W∪X→Z

décomposition : si X → Y ∪ Z alors X → Y et X → Z
 Dépendances fonctionnelles

fermeture d’un ensemble de dépendances fonctionnelles F :

F + ensemble de toutes les dépendances fonctionnelles déduites obtenues par
l’application répétées des propriétés de base.

F et G deux ensembles de dependances fonctionnelles

F et G sont équivalents ssi F + = G +

fermeture transitive d’un ensemble de dep´ endances fonctionnelles F :

ensemble de toutes les dépendances fonctionnelles déduites obtenues par
transitivité
 Dépendances fonctionnelles

un ensemble de dépendances fonctionnelles F est irréductible si :

le membre droit de chaque dépendance fonctionnelle contient un seul attribut

chaque dépendance fonctionnelle de F est élémentaire

aucune dépendance fonctionnelle de F ne peut ˆetre supprimée sans changer la fermeture

de F

tout ensemble de dependances fonctionnelles irreductible et

équivalent à F est appelé couverture minimale de F
Normalisation de bases de données
 Normalisation
Les formes normales sont des niveaux de qualité d'un modèle relationnel.
Elles permettent de vérifier la robustesse de la conception du modèle en
évitant:
 La redondance des données
 Les problèmes de mise à jour
 La cohérence.
Il existe 6 niveaux de de formes normales nous allons nous occuper des
3 premiers uniquement.
 1NF
 2NF
 3NF
 BCNF

Données
non-normalisation 1 NF 2 NF 3 NF BCNF

5 NF 4 NF
 Pourquoi normalisation ?
-Réduire l’espace de stockage
-Eviter la redondance de données
-Eviter le coding (trigger,procédure stocké,…)
-Bien structurer des données
-Optimisation de performance:
.temps d’exécution(‘’thin table’’)
.Maximiser ‘’Clustered indexes’’ (trier,rercherche)
.Nombre d’index par table
 1NF
 Une relation est dite normalisée ou en première forme normale si :
 aucun attribut qui la compose n'est lui-même une relation, c'est-à-dire si tout attribut
est atomique (non décomposable).
 Cette forme n'utilise que les structures de base d'une relation, elle ne résout pas le
problème de la redondance.
Exemple :
Cette table ne respecte pas 1NF il y a plusieurs mails dans la meme colonne

La solution est de créer un table email pour y stocker les emails

 2NF
 Une relation est dite en deuxième forme normale si et seulement si :
 Elle est en première forme normale ;
 Chaque attribut est totalement dépendant de la clé primaire.

 Avec cette forme, les problèmes de redondance ne sont pas entièrement résolus.
 Mais ne pas respecter la 2FN entraîne des redondances. Cela gaspille de l'espace de stockage, et pose
aussi le problème de la mise à jour des données.
 Exemple: 2NF
 Dans la table suivante la difficulté de la figure ne dépend que de
la figure et non de la clef primaire entière (skater, figure). 2NF
n’est pas respecté
 Exemple: 2NF
 La solution est de décomposer la table en deux qui affichent les
deux dépendances:
 Nom  difficulté
 (Skater,Figure)note
 3NF

 Une relation est en troisième forme normale si et seulement si :

 Elle est en 2NF;
 Et chaque attribut non-clé primaire dépend directement de la clé primaire.
 La 3NF est adéquate pour la majorité des designs de BD mais elle n'élimine pas toutes les redondances
et incohérences. Pour cela, Codd a pensé à BCNF qui est une forme plus stricte de 3NF.
 Exemple: 3NF
 Dans la table suivante le sexe peut être déduit de l’attribut non
clef civilité. 3NF n’est pas respecté
 Exemple: 3NF
 La solution est de créer une table civilité qui contient le sexe
d’une personne en fonction de sa civilité
Cas de dénormalisation 3NF

 Dans table suivante le total peut être calculé. Nous pourrions

donc supprimer cette colonne.
 Cas de dénormalisation 3NF
 Mais dans certains cas, même s'il est possible de recalculer les
montants totaux hors taxes et TTC à partir des lignes de commandes
de l'expédition associée à une facture,
 Il peut être judicieux d'ajouter les colonnes total_ht et total_ttc dans
notre table facture. Cela permettrait de:
 Faire des recherches par montant total plus facilement
 Purger les tables expedition, ligne_commande et commande à intervalles
réguliers sans perdre l'information des montants totaux dans les factures.
Boyce-Codd Normal Form (BCNF)

 Une relation est en BCNF si :

 Elle est en 3NF
 Les seules DFE existantes sont celles dans lesquelles une clé détermine un attribut.
 4NF

 Permet autant que possible de minimiser l'occurence d'attributs

indépendants à valeur mutiple.
 Une relation est de la 4NF si :
 elle satisfait la 3NF
 les données composant chaque attribut ne comportent aucune
répétition inutile -> dans une même colonne, il faut minimiser les
répétitions.
 Une base qui est 4NF est des plus optimales quoiqu'il soit possible de
généraliser cette dernière afin d'obtenir la 5NF.
4NF Exemple

 Dans la table suivante :

 Conférencier et Livre sont deux entités indépendantes
 Les conférenciers peuvent enseigner n’importe quelle matière
 Pour une matière donnée les étudiants peuvent utiliser plusieurs livres

 Il y a une dépendance multivaluée sur Matière

 La table cours ne respecte pas 4NF
4NF Exemple
 Si nous faisons un « SELECT c.LECTURER, c.BOOKS FROM
COURSE c WHERE SUBJECT = 'Mathematics’; »

 Nous obtenons
 Alors qu’il n’y a pas de dépendance entre conférencier et livre
 La solution pour supprimer la dépendance est de créer deux
tables Conférencier et Livre
Associations
1-1 (one to one) :

1-n (one to many):

n-n (many to many) :

Associations (PK et FK)
Modèle Entité association-> Modèle physique de données

1. Modèle entité-association
a. Définir concept entité et principaux attribut. (Juste ce qui est nécessaire)
b. Echange et affinage des règles
c. Définir les clefs primaires
d. Mettre en oeuvre les relations (heritage, composition, agrégation)
2. Diagramme de classes
a. SQL Power Architect->Génération du script de la base
b. Libre Office draw/Papyrus->Diagramme de classe
i. Une table = une classe
ii. Mise en oeuvre des relations (heritage, composition, agrégation)
Agrégation
Exemples

 Classe - Élève : dans l'association Classe/Elève, la classe joue un rôle de regroupement d'élèves.
 Équipe - Joueur : une équipe est un ensemble de joueurs.

Contre exemple:

Elève/email car une élève ne joue pas le rôle de regroupement d’élèves.

Composition
Aggregation plus forte si l’entité composée disparaît les composants n’existent plus.

Exemples:

 Répertoire - Fichier : un répertoire est composé de fichiers. Un fichier ne peut pas être dans plusieurs répertoires.
Si on supprime le répertoire, les fichiers sont supprimés.
 Immeuble - Appartement : un immeuble est composé d'un ensemble d'appartements. Un appartement ne se situe
que dans un seul immeuble et si on détruit l'immeuble, les appartements sont détruits aussi !
Heritage
Association Réflexive
Installation PostGres
 summary.installation.directory: C:\Program Files\PostgreSQL\11
 summary.server.installation.directory: C:\Program Files\PostgreSQL\11
 summary.data.directory: C:\Program Files\PostgreSQL\11\data
 summary.database.port: 5432
 summary.database.superuser: postgres
 summary.serviceaccount: NT AUTHORITY\NetworkService
 summary.databaseservice: postgresql-x64-11
 summary.clt.installation.directory: C:\Program Files\PostgreSQL\11
 summary.pgadmin.installation.directory: C:\Program Files\PostgreSQL\11\pgAdmin 4
 summary.sbp.installation.directory: C:\Program Files\PostgreSQL\11
Création du modèle physique de données
1. je crée une table par classe
2. je crée les colonnes dans les tables
3. je définie les clés primaires
4. je crée les relations entre les tables

Lancez SQL Power Architect

Génération du script SQL
Cliquez
Importer le script
Dans pgAdmin

1. Connectez-vous au serveur PostgreSQL en utilisant l'utilisateur propriétaire de la base de données.

2. Cliquez sur l'icône SQL.
3. Une fenêtre s'ouvre vous permettant de saisir des requêtes SQL.
4. Ouvrez le fichier create_db.sql que vous avez enregistré depuis SQL Power Architect.
5. Exécutez le script SQL en cliquant sur l'icône