Utiliser le Modèle Physique de Donnée :
Une fois le système d'information analysé et modélisé en Modèle Conceptuel
de Donnée (MCD), et après être passé par le Modèle Logique de Donnée
Relationnel (MLDR), nous arrivons au Modèle Physique de Donnée (MPD).
Il s'agit maintenant de créer la base correspondante à l'étude entamée.
C'est à ce stade seulement que la base de donnée choisie intervient.
Le SQL (Structured Query Language), ou Langage d'Interrogation Structuré,
a été reconnu en tant que norme officielle de langage de requête relationnelle
par l'institut ANSI (American National Standards Institute) et par
l'organisme ISO (International Standards Organization). Malgré cela,
les syntaxes d'extractions des données et de créations des tables varient
quelques peux d'une base à l'autre. En particulier, si la base de donnée
utilisée pour le développement n'est pas véritablement relationnelle
(cas de MySql dans sa version actuelle), il appartiendra au développeur
de prendre lui-même en charge les limitations rencontrées, afin de
s'assurer que sa base ne puisse JAMAIS être corrompue, c'est à dire
contenir des données aberrantes.
APPLICATION SUR UN MODELE PHYSIQUE CONCRET :
Prenons l'exemple du schéma de base (MPD) suivant :
- La table MOTIVATIONS est très simple à créer : elle comporte
deux champs, ID_MOTIVATIONS et INTITULE. ID_MOTIVATIONS
est la Clé Primaire.
- ABONNES comporte les 12 champs du schéma. ID_ABONNES
est la clé primaire. ID_MOTIVATIONS est une clé étrang7re provenant
de MOTIVATIONS, c'est à dire que sa valeur doit être toujours
égale à une valeur de ID_MOTIVATIONS de MOTIVATIONS.
L'intérêt majeur des clés étrangères est surtout d'éviter les redondances,
sources d'erreurs.
- Pour les bases non totalement relationnelles : Il appartiendra
au développeur de vérifier lors de chaque insertion dans ABONNES
que l'ID_MOTIVATIONS fournis fais partie des valeurs existantes
de ID_MOTIVATIONS de MOTIVATIONS. De même, lors de
chaque suppression d'un enregistrement de MOTIVATIONS, il
faudra vérifier qu'aucun enregistrement d'ABONNES n'utilise
la valeur d'ID_MOTIVATION correspondante.
- S_INSCRIT comporte deux champs, ID_ABONNES et ID_RUBRIQUE.
ID_ABONNES et ID_RUBRIQUE sont clé primaire de S_INSCRIT
: S_INSCRIT a comme clé primaire la concaténation de ces deux
champs. C'est à dire que tout couple (ID_ABONNES,ID_RUBRIQUE)
de S_INSCRIT est unique. ID_ABONNES est aussi clé étrangère
de ABONNES dans S_INSCRIT, et ID_RUBRIQUE est
clé étrangère de RUBRIQUE dans S_INSCRIT.
Une telle table est communément appelée "Table de Lien". L'intérêt
d'une telle table est que pour chaque ID_ABONNES donné, il
est aisé de retrouver tous les ID_RUBRIQUE associés, et vice
et versa.
- Pour les bases non totalement relationnelles : Il faudra
vérifier lors de chaque insertion dans S_INSCRIT que le couple
(ID_ABONNES,ID_RUBRIQUE) n'existe pas déjà dans la
table S_INSCRIT, que ID_ABONNES existe dans ABONNES
et que ID_RUBRIQUE existe dans RUBRIQUE. De même,
pour chaque suppression d'un abonné, il faudra supprimer tous les
couples (ID_ABONNES,ID_RUBRIQUE) ayant l'ID_ABONNE
correspondant. Pareil pour toute suppression de RUBRIQUE.
- RUBRIQUE est elle aussi très simple à créer : elle comporte
deux champs, ID_RUBRIQUE et NOM_RUBRIQUE. ID_RUBRIQUE
est la Clé Primaire.
- NEWSLETTERS comprend les 5 champs du schéma. ID_NEWSLETTER
est la clé primaire. ID_RUBRIQUE est une clé étrangère provenant
de RUBRIQUE.
- Pour les bases non totalement relationnelles : Il faudra
vérifier lors de chaque insertion dans NEWSLETTER que ID_RUBRIQUE
existe dans RUBRIQUE. De plus, pour chaque suppression d'une
rubrique, il faudra s'interroger sur le sort réservé à chaque newsletter
de cette rubrique : les détruire ou les archiver.
APPLICATIONS AUX BASES RELATIONNELLES :
Les vérifications détaillées précédemment n'ont lieu que pour assurer
la cohérence de la base. Il est donc logique, si celle ci le permet,
de déléguer et d'automatiser ces taches au niveau ce celle-ci. Généralement,
les vérifications afférentes à une clé étrangère sont confiées à un
Trigger (un Trigger est un ensemble d'instruction SQL s'effectuant
avant ou après un événement donné, par exemple une insertion ou une
suppression). Ainsi, lors de chaque commande d'insertion sur la table
désignée au Trigger préalablement correctement programmé, celui ci
va vérifier AVANT l'insertion que la clé étrangère est valable. Dans
le cas ou elle ne le serait pas, le Trigger renvoie un message d'erreur
et l'insertion ne s'effectue pas, évitant ainsi de corrompre la base.
De même, certains traitements automatisés pourront être réalisés directement
à l'aide de procédures stockées. Exemple : un devis validé qui entraîne
la création de la facture correspondante. Et surtout, les Trigger et
Procédures Stockées étant compilées directement par la Base de Donnée,
leur exécution est beaucoup plus rapide qu'une série d'instruction
SQL envoyées par le programme attaquant la base.
Une base de donnée correctement pensée est à envisager comme un contenant
d'information "vivant", forcement cohérent, aux réactions automatisées.
Une telle base se suffirait presque à elle-même pour gérer un Système
d'Information. Le développement ne consisterait alors plus qu'à afficher
son contenu en temps réel, et à fournir les outils d'insertion appropriés.
Le rêve...
SECOND EXEMPLE : MODELISER UN DOCUMENT
Il est courant, lors du développement d'un site Web ou de l'informatisation
d'un système d'information, de démarrer son analyse par un document.
Captures d'écrans, photocopies, sont parfois les principales pièces
jointes à la demande de devis, accompagnés du commentaire suivant :
"Je veux faire ça !!!". Bien. Alors, faisons ça...
Système d'Information :
L'entreprise "WebCash" de vente par correspondance désire ajouter
à son site un système de consultation de factures visible en ligne
pour ses clients. Chaque client, après authentification, pourra accéder
à toutes les factures le concernant, qu'elles soient anciennes ou en
cours de traitement indifféremment. Pour être sur de bien se faire
comprendre, "WebCash" fournis une copie d'une facture type en disant
:
"C'est ça qu'on veut sur l'écran !"
Voici une copie de cette facture :
WebCash S.A.R.L
24, Avenue des Rêves roses
75008 PARIS |
FACTURE N° 12345 |
Paris, le 15/10/2000 |
| Nom : |
BIDOCH |
| Prénom : |
Robert |
| Adresse : |
12, rue du centre |
| Code Postal : |
70000 |
| Ville : |
Gray |
|
| N° Article |
Libellé |
Prix Unitaire |
Quantité |
Prix |
| 234 |
Stylo Plume |
12.5 F |
1 |
12.50 F |
| 568 |
Couteau Suisse |
75.00 F |
2 |
150 F |
| 132 |
Serviette |
30.00 F |
1 |
30.00 F |
TOTAL TTC : |
192.50 F |
| Dont TVA 19.6% :
|
37.73 F |
| A PAYER :
|
192.50 F |
|
Avec nos plus cordiaux remerciements |
Voilà, tous les éléments sont réunis. Il ne reste plus qu'à concevoir
la Base de Donnée se cachant derrière cette innocente petite facture.
Cet exemple est très conforme à la réalité. Il sera très intéressant
à étudier, car il permettra d'expliquer un certain nombre de points,
et de mettre en évidence certaines erreurs à ne pas commettre. N'hésitez
pas à prendre le stylo et à vous entraîner, je vous fournirais une
solution commentée la prochaine fois.
A bientôt...
Stéphane
Lambert
http://www.vediovis.fr/
Spécialisé dans le développement Web, Stéphane LAMBERT
a fondé VEDIOVIS PRODUCTIONS en Mai 2000.
Son expérience couvre essentiellement les sites à fortes audiences,
institutionnels ou audiovisuels.
Tous droits réservés - Reproduction même partielle interdite
sans autorisation préalable
| |
Webmaster