Initiation aux bases de

données relationnelles
Cours VBA Access

Mahdi Zargayouna
zargayou@lamasade.dauphine.fr
 Objectifs
Concevoir et bâtir des systèmes d’information informatisés

Stocker ses données et les mettre à jour

Pouvoir les retrouver quand on en a besoin

Les organiser à des fins précises (statistiques, publipostage etc.)

Comment ?
Il faut :
Avoir une méthode qui, à partir d’un problème de gestion nous permet de modéliser
une base de données correspondantes (modèle entités –associations)
Connaître un langage qui permet de gérer la base de données (SQL)

Connaître un logiciel qui permet de créer, manipuler et

gérer la base de données
 Exemple : gérer les commandes de ses clients

Tableau bidimensionnel (ici Excel)

Nous avons :
les informations relatives à chaque client
les informations sur ses commandes de ce client
Les informations sur les produits commandés
 Saisie des informations

Très bien.
Sauf que Zorba n’a pas commandé qu’un seul produit !
Nous devons dupliquer toutes les informations relatives au client dans la ligne qui suit
Si on ne saisit que les informations relatives à la commande, le lien entre la commande
et le client sera perdu (si on fait un tri, par exemple)
 Ce qui donne ..

Les informations du client seront recopiées pour chaque commande

Les informations du client et de la commande seront recopiées pour chaque produit
Gaspillage d’espace

Combien de commande pour le client X ?

On ne peut pas simplement compter les lignes …
Traitements plus complexes
Qu’est ce qui se passe si l’adresse du client change ?
Il nous faut chercher le client dans chacun des tableaux où il se trouve, et changer son adresse

Gaspillage de temps & surtout risque d'erreur => incohérence

 Limites des tableaux bidimensionnels

Redondance de données
Gaspillage d’espace et source d’erreurs

Le mélange des divers ensembles de données (Client / Commande / Produit / …) dans

un seul et même tableau ne facilite pas les traitement et/ou analyses statistiques.
Mise à jour difficile et source d’erreurs aussi

Avant de passer au stockage des données, il nous faut un effort de ‘conception’ :

Une manière d’organiser nos données de manière à avoir un stockage minimal et un
traitement le plus simple possible

C’est pour ces différentes raisons que nous avons besoin des bases de données
relationnelles et des systèmes qui permettent de les créer et de les gérer : le Systèmes de
Gestion de Bases de Données Relationnelles (SGBDR)
Le logiciel Microsoft ACCESS et un SGBDR
 Conception d’une base de données
étape 1
La conception est l’établissement du « plan » de la base de données

Identification des ‘entités’

Une entité représente tous les sujets qui sont décrits de la même manière

Par exemple, tous les clients sont décrits par un nom, une adresse etc.

Un client est donc une entité

Une commande est aussi une entité (décrite par réfProduit, PrixHT etc.)

De même pour un produit

Cette étape pourrait être vue comme la réalisation de fiches types des différents composants de
notre système

Pour le moment, on ne se soucie pas de savoir lien entre les clients et les commandes
(Quel client a passé quelle commande)
 Étape 1 : suite - Schéma
Nous avons identifié trois entités : dessinons-les

Clients Commandes Produits

N°Client N°Commande RefProduit

Nom Description
Date Commande
Adresse PrixHT
Date Livraison
Code Postal TVA
Frais de port
… …
…

Principe 1: chaque entité DOIT avoir un ‘identifiant’ UNIQUE

Un identifiant est une valeur avec laquelle nous sommes sûrs qu’il s’agit de CE client (par exemple) et pas d’un
autre (on le souligne dans le schéma)
Dans notre exemple, nous disposant de nos trois identifiants :
Le numéro du Client, le numéro de la commande et la référence du produit (code barre par exemple)

On peut désormais rajouter dans chaque entité, les informations qui la décrivent (attributs)

Principes :
Chaque attribut doit être ‘atomique’ : ne pas être un champ composé.
Exemple type: adresse : il faut décomposer en rue, ville code postal etc.(important lors de la mise à jour notamment)
Aucun attribut ne doit ‘dépendre’ d’un autre champ, autre que l’identifiant
Exemple : le département et le code département
 Entités … et ?
Nous avons organisé nos entités en fiches types, si nous les remplissons, nous devenons
capables de connaître l’étendue de notre carnet d’adresse, la taille de notre fichier de
commandes, ajouter des clients, des produits…

Nous pouvons les retrouver grâce à leurs identifiants uniques

Nous ne gaspillons pas d’espace puisque chaque client est stocké une seule fois, idem pour chaque
commande, produit etc.

Cependant

Dans le tableau initial, nous savions que telle commande était passée par tel client car ils
étaient sur la même ligne

En isolant les entités, nous avons perdu cette relation !

D’où l’étape 2
 Conception d’une base de données
étape 2
Identification des ‘associations’
Une association sert à définir l’action qu’exercent les entités entre elles
Dans le schéma, une association est un lien entre deux entités, avec un verbe qui décrit l’action

Que fait le client à la commande ? Un client ‘passe’ une commande

Que fait la commande au produit ? Une commande ‘contient’ un produit

On pourrait aussi dire qu’un client achète ou commande un produit, mais cette relation est déduite des
deux autres

Clients Commandes Produits

N°Client N°Commande RefProduit

Nom Passer Contenir Description

Date Commande
Adresse PrixHT
Date Livraison
Code Postal TVA
Frais de port
… …
…
 Étape 2 : suite
Identification des ‘cardinalités’
On prend une association, on se place du côté {entité}, on regarde l’{autre entité} et on se pose une question :

« Combien de {autre entité} un(e) {entité} peut-il(elle) {action} ? » (sens de la flèche)

« (Par-Dans..) Combien de {autre entité} un(e) {entité} peut-il(elle) être {action} ? » (sens contraire)

Exemple

Combien de commandes un client peut-il passer ? Une ou plusieurs (1..N)

Par combien de clients une commande peut-elle être passée ? Un seul (1)

Combien de produits une commande peut-elle contenir ? Un ou plusieurs (1..N)

Dans Combien de commandes un produit peut-il être contenu ? Une ou plusieurs (1..N)

Clients Commandes Produits

N°Client N°Commande RefProduit

1 Passer 1..N Contenir 1..N Description
Nom Date Commande 1..N
Adresse Date Livraison PrixHT

Code Postal TVA

Frais de port
… … …
 Effets des cardinalités sur la structure des entités
(1/2)
Clients Commandes

N°Client N°Commande
Passer
Nom 1 1..N Date Commande
Adresse Date Livraison
Code Postal Frais de port
… N°Client

Association un à plusieurs

reproduire l'identifiant de l’entité qui est du côté un dans l’entité côté plusieurs

Ce qui est assez intuitif :

On est en train de lire la fiche d’une commande, on tombe sur le numéro du client, si on veut en
savoir plus (son adresse par exemple), on accède à l’entité Clients, et comme il n’y en a qu’un seul
avec ce N° …
 Effets des cardinalités sur la structure des entités
(2/2)
Commandes Produits

N°Commande RefProduit
1..N Contenir 1..N Description
Date Commande
PrixHT
Date Livraison
TVA
Frais de port
…
N°Client

Association plusieurs à plusieurs

Ce cas est interdit !

Il s’agit en réalité à deux associations un à plusieurs

Créer une entité intermédiaire avec deux associations un à plusieurs

 Association plusieurs à plusieurs : suite
Commandes_
Commandes Produits Produits

N°Commande N°Commande RefProduit

RefProduit Description
Date Commande 1..N 1
1 1..N
Quantité demandée PrixHT
Date Livraison
TVA
Frais de port Remise
…
N°Client

reproduire les identifiants des entités dans la nouvelle entité

Réfléchir !
- Est-ce qu’il y a des informations qui ne dépendent ni du produit seul, ni de la commande seule, mais
des deux en même temps ?
+ Ici, oui ! La quantité demandée de ce produit, dans cette commande.
+ Aussi, s’il y a une remise pour ce produit, dans cette commande seulement
Etc.

Chaque entité doit avoir un identifiant UNIQUE, quel est l’identifiant de l’entité Commandes_Produits ?

Si on convient qu’un produit ne figure pas deux fois dans la même commande, l’identifiant est l’union
des deux identifiants (cas le plus fréquent)

Sinon, on en rajoute un nouveau (ref_Commandes_Produits par exemple)

 Récapitulatif

Nous avons un problème donné

Avant de commencer à remplir nos tableaux, on en prépare le plan :

I. Nous identifions les entités

Nous leur associons des identifiants uniques
Nous leur ajoutons les informations qui les décrivent

II. Nous identifions les actions mutuelles qu’exercent les entités entre elles
Nous découvrons les cardinalités
Nous appliquons les règles des effets des cardinalités

Le schéma de notre base de données est prêt !

Il suffit de la remplir
 Vocabulaire (1/2)

Maintenant que notre schéma de base de données est prêt, et

que nous l’avons remplie :
On ne parle plus d’entité, mais de table (on préfixe le nom avec « tab »)

tabCommandes

N°Commande Clé primaire

Date Commande
Date Livraison Attributs
Frais de port

N°Client Clé étrangère

Du schéma de la base aux tables

N°Commande Date Commande Date Livraison Frais de port N°Client

tabCommandes

N°Commande

Date Commande
Date Livraison
Frais de port

N°Client
 Vocabulaire (2/2)

Les colonnes s’appellent des champs

Chaque champ a un « type de données» (texte, numérique..)
Toutes les données d’un même champs ont le même type

Les lignes s’appellent des enregistrements

Sous Access, notre schéma
 …et la base

Avec notre client Zorba, sa seule commande et ses trois produits..