Discussion :

[Syntcpip]

Bonjour, je suis actuellement en train de travailler sur un projet de gestion des archives (j'suis debutant en developpement en general). j'ai pu avec l'aide des tutos et amis et concevoir un diagramme de classe et j'arrive pas a creer une BD. aidez-moi s'il vous plait

[fsmrel]

Bonsoir Syntcpip,

Vous n’avez pas précisé le nom de l’AGL que vous utilisez. S’il s’agit de PowerAMC, alors pour générer la base de données, vous commencez par générer un MPD (Modèle physique des données), en réalité un MLD (modèle logique des données) :

Le diagramme de classes étant affiché, dans la barre de menus : OUTILS > Générer un modèle physique de données.

Une fois ce MLD généré, dans la fenêtre correspondante : dans la barre de menus : SGBD > Générer la base de données.

Au besoin, vous pouvez préciser votre SGBD : dans la barre de menus : SGBD > Editer le SGBD courant.

Bon courage

[Syntcpip]

Oui en fait je voulais comprendre comment ca se passe je veux pas creer moi meme la base de donnée. merci

[fsmrel]

Bonsoir Syntcpip,

Traitons donc des règles classiques du Passage à SQL.

(1) Traduction d’une classe en table :

La classe fait l’objet d’une table.

Les attributs de la classe deviennent les colonnes de la table.

Le type des attributs est parfois à renommer. Ainsi, si le type entier (INT) est le même, le type String est en général à renommer en TEXT, CHAR, VARCHAR, etc., en fonction de votre SGBD (le type le plus souvent utilisé est en l’occurrence VARCHAR).

Les opérations sont ignorées.

Un identifiant de classe devient une contrainte, plus précisément une clé primaire SQL (primary key) (symbolisée ci-dessous par le mickey <pk>, voyez par exemple l’attribut ServiceId). A noter qu’une clé primaire est une spécialisation de ce qu’on appelle clé candidate (dont la fonction première est de garantir la non redondance des lignes d’une table), le pendant de la clé primaire est dite clé alternative. Par exemple, si la classe SERVICE était dotée d’un attribut (naturel) ServiceCode, tel qu’il n’existe pas deux services ayant la même valeur pour cet attribut, alors la table SERVICE serait à doter d’une clé alternative {ServiceCode}.

Exemple :

SQL ne propose aucun graphique pour représenter les tables, seuls les AGL le font. SQL ne propose que des instructions.

Pour les tables ci-dessus :

CREATE TABLE SERVICE
(
        ServiceId               INT            NOT NULL
      , ServiceNom              VARCHAR(48)    NOT NULL 
    , CONSTRAINT SERVICE_PK PRIMARY KEY (ServiceId) 
) ;
CREATE TABLE ARCHIVE
(
        ArchiveId               INT            NOT NULL
      , ArchiveNom              VARCHAR(64)    NOT NULL
      , ArchiveDate             DATE           NOT NULL
      , ArchiveTaille           INT            NOT NULL
    , CONSTRAINT ARCHIVE_PK PRIMARY KEY (ArchiveId) 
) ;

(2) Traduction d’une association de N à 1.

Si les AGL proposent de visualiser les liens N à 1 entre tables au moyen de ficelles plus ou moins parlantes, pour sa part SQL impose que la référence d’une table (par exemple ARCHIVE) à une autre (par exemple SERVICE) mette en jeu une contrainte dite référentielle, plus connue sous le nom (assez étrange il faut le dire) de clé étrangère (mickey <fk> ci-dessous), système qui impose d’ajouter — dans l’en-tête (liste des attributs) de la table référençante — les attributs composant la clé primaire (ou autre clé candidate) de la table référencée.

CREATE TABLE SERVICE
(
        ServiceId               INT            NOT NULL
      , ServiceNom              VARCHAR(48)    NOT NULL 
    , CONSTRAINT SERVICE_PK PRIMARY KEY (ServiceId) 
) ;
CREATE TABLE ARCHIVE
(
        ArchiveId               INT            NOT NULL
      , ServiceId               INT            NOT NULL
      , ArchiveNom              VARCHAR(64)    NOT NULL
      , ArchiveDate             DATE           NOT NULL
      , ArchiveTaille           INT            NOT NULL
    , CONSTRAINT ARCHIVE_PK PRIMARY KEY (ArchiveId) 
    , CONSTRAINT ARCHIVE_SERVICE_FK FOREIGN KEY (ServiceId) REFERENCES SERVICE (ServiceId)
) ;

Notez la présence la clause « NOT NULL » : NULL est une pustule (qu’il faut éviter), plus formellement un marqueur d’attribut. Si un attribut est marqué NULL, alors il ne contient aucune valeur conforme à son type. En revanche on ne fonctionne plus alors selon le mode de la logique classique, binaire (vrai, faux), mais selon le mode de la logique ternaire (vrai, faux, n’iimporte quoi).

Voilà pour l’instant. Il reste pas mal de cas de figures à examiner : associations N-N, classes-associations, héritage, compositions et j’en oublie, mais voyons déjà si ce qui précède vous convient. Et si cela a pu vous apporter quelque chose, n’hésitez pas à voter

[Syntcpip]

Merci beaucoup ca m'a beaucoup aidé. et pour les cardinalités 0 a N et 1 a 1 aussi c'est la meme logique qu'il faut utiliser ?

[fsmrel]

Bonjour Syntcpip,

Poursuivons notre histoire de traduction du diagramme de classes en SQL.

Pour les multiplicités 0..N, le film est le même que le précédent, à ceci près qu’une multiplicité 1..N impose la mise en oeuvre d’une contrainte SQL pour faire respecter la règle selon laquelle un service gère au moins une archive, contrainte absente dan le cas de la multiplicité 0..N.

Vous avez aussi évoqué les multiplicités 1-1, alors allons-y...


(3) Traduction d’une association de 1 à 1.

Prenons le cas des agences qui ont un et un seul directeur, tandis qu’une personne ne peut diriger qu’une et une seule agence :

Il y a manifestement une bijection entre les deux classes, mais ceci sera source de pièges avec SQL (présence d’un cycle). La symétrie parfaite dans le diagramme ci-dessous (automatiquement généré par PowerAMC) est flagrante : la clé primaire (<pk>) d’une table est forcément l’objet d’une contrainte référentielle — clé étrangère — (<fk>) pour l’autre, intégrité des données oblige. Mais selon le diagramme, il est seulement exigé que chaque valeur de l’attribut AgenceId de la table DIRECTEUR soit une valeur de l’attribut AgenceId de la table AGENCE, et que chaque valeur de l’attribut DirecteurId de la table AGENCE soit une valeur de l’attribut DirecteurId de la table DIRECTEUR :

Mais, pour la table DIRECTEUR, on ne garantit en rien qu’une agence n’a qu’un directeur : en effet, on pourrait avoir la situation suivante où chaque directeur dirige une seule agence, mais où une agence pourrait avoir plusieurs directeurs :

DIRECTEUR {DirecteurId    AgenceId    DirecteurNom}
           d1             a1          Fernand
           d2             a2          Paul
           d3             a1          Raoul

Ainsi, l’agence a1 est dirigée à la fois par Fernand et Raoul...

De même, pour la table AGENCE, on ne garantit pas qu’un directeur ne dirige qu’une agence :

AGENCE {AgenceId    DirecteurId    AgenceNom}
        a1          d1             Yaoundé
        a2          d2             Lyon
        a3          d1             Rome

Ainsi, le directeur d1 dirige à la fois les agences de Yaoundé et Rome...

L’intégrité référentielle est respectée, mais pas les règles de gestion des données.

Pour pallier les lacunes de l’AGL, on complète en faisant de {AgenceId} une clé alternative (<ak>) de DIRECTEUR et de {DirecteurId} une clé alternative de AGENCE :

Dans ces conditions, l’agence a1 est dirigée soit par Fernand soit par Raoul, mais pas par les deux. De même, le directeur d1 dirige soit l’agence de Yaoundé soit celle de Rome, mais pas les deux.

Et pourtant ! On voit dans le tableau ci-dessous que l’intégrité référentielle et les règles de gestion des données sont respectées au sein de chaque table, mais ces règles sont violées au niveau de la base de données : par exemple, selon la table DIRECTEUR, le directeur a1 ne dirige que l’agence d1, mais d’après la table AGENCE, ce directeur ne dirige que l’agence d2 !

DIRECTEUR                              AGENCE
+-------------+----------+             +----------+-------------+
| DirecteurId | AgenceId |             | AgenceId | DirecteurId |
|-------------+----------|             |----------+-------------|
|          a1 |       d1 |             |       d1 |          a2 |
|          a2 |       d2 |             |       d2 |          a1 |
+-------------+----------+             +----------+-------------+ 

Ce problème a évidemment une solution, mais à ce sujet je vous renvoie au billet que j’ai consacré au problème que posent les associations 1-1 (Merise : cardinalités 1,1 ---- 1,1 => intégrité référentielle = cautère sur jambe de bois).


Prochain épisode : les associations M..N.