3. représenter de façon structurée les données
décrit la sémantique c’est à dire le sens attaché à ces données et à leurs rapports et non à l’utilisation qui
peut en être fait
Le MCD ne peut pas être implanté dans une base de données sans modification. Il est obligatoire de
transformer ce modèle. On dit qu’on effectue un passage du modèle conceptuel de données vers le modèle
logique de données.
Le modèle conceptuel des données (MCD)
4. permet de modéliser la structure selon laquelle les données seront stockées dans la future base de
données
est adapté à une famille de SGBD : ici les SGBD relationnels (MLD Relationnels ou MLD-R)
permet d'implémenter la base de données dans un SGBD donné
Modèle Logique de Données (MLD) :
5. Quelques notions essentielles
·Domaine : Le domaine est l’ensemble des valeurs que peut prendre une donnée
une table est un sous-ensemble du produit des domaines, une table est donc un ensemble d’enregistrements
une table porte un nom et est composée d’attributs prenant leurs valeurs dans les domaines correspondant
Attribut : c'est une colonne d'une relation, caractérisé par un nom.
une clé est constituée de 1 ou plusieurs attributs telle que une valeur de la clé détermine exactement
l’enregistrement,
toute table possède une clé primaire et, éventuellement, des clés candidates.
7. Une classe devient une table
Son identifiant devient la clé primaire de la table
les autres propriétés deviennent les attributs de la table
CLIENT
numClient
nom
prénom
CLIENT (numClient , nom , prénom)
Exemple
Règle numéro 1
15. Chaque classe possède des caractéristiques (attributs et méthodes) qui lui sont propres. Lorsqu'une
classe fille hérite d'une classe mère, elle peut alors utiliser ses caractéristiques.
Propriétés de la notion d'héritage
Transitivité : si B hérite de A et si C hérite de B alors C hérite de A ;
Non réflexif : une classe ne peut hériter d’elle-même ;
Non symétrique : si A hérite de B, B n’hérite pas de A ;
Sans cycle : Il n'est pas possible que B hérite de A, C hérite de B et que A hérite de C.
Modélisation par héritage
21. Élaboration du MLD et passage au SQL
La conception d’un système qui va recourir à un Système de Gestion de Base de Données (SGBD) et donc
qui devra utiliser le langage SQL nécessite parfois l’utilisation de logiciels pour concevoir un tel système
grâce à des méthodes telles que UML ou Merise.
• Avec ces différentes règles de conversion, il nous est déjà possible de convertir notre MCD au complet :
Pays (id_p, nom_p)
Auteur (id_a, nom_a, prenom_a, date_naissance_a, id_p#)
TypeLivre (id_t, libelle_t)
Livre (id_l, titre_l, annee_l, resume_l, id_t#)
Rediger (id_a#, id_l#)
Edition (id_ed, nom_ed)
Exemplaire (ref_e, id_ed#, id_l#)
Inscrit (id_i, nom_i, prenom_i, date_naissance_i, rue_i, ville_i, cp_i, email_i, tel_i, tel_portable_i)
Emprunt (id_em, date_em, delais_em, id_i#, ref_e#) Légende :
x : relation
x : clef primaire
x# : clef étrangère
22. Les règles de passage au SQL sont assez simples :
• chaque relation devient une table
• chaque attribut de la relation devient une colonne de la table correspondante
• chaque clef primaire devient une PRIMARY KEY
• chaque clef étrangère devient une FOREIGN KEY
23. CREATE TABLE Pays ( id_p INT NOT NULL, nom_p VARCHAR(50), PRIMARY KEY (id_p) );
CREATE TABLE Auteur ( id_a INT NOT NULL, nom_a VARCHAR (30), prenom_a VARCHAR (30),
date_naissance_a DATE, id_p INT NOT NULL, FOREIGN KEY (id_p) REFERENCES Pays(id_p),
PRIMARY KEY (id_a) );
CREATE TABLE TypeLivre ( id_t INT NOT NULL, libelle_t VARCHAR (30), PRIMARY KEY (id_t)
);
CREATE TABLE Livre ( id_l INT NOT NULL, titre_l VARCHAR (254), annee_l VARCHAR (4),
resume_l TEXT, id_t INT NOT NULL, FOREIGN KEY (id_t) REFERENCES TypeLivre(id_t), PRIMARY
KEY (id_l) );
CREATE TABLE Rediger ( id_a INT NOT NULL, id_l INT NOT NULL, FOREIGN KEY (id_a) REFERENCES
Auteur(id_a), FOREIGN KEY (id_l) REFERENCES Livre (id_l), PRIMARY KEY (id_a, id_l) );
CREATE TABLE Edition ( id_ed INT NOT NULL, nom_ed VARCHAR (254), PRIMARY KEY (id_ed) );
24. CREATE TABLE Exemplaire ( ref_e VARCHAR(254) NOT NULL, id_ed INT NOT NULL, id_l INT NOT NULL,
FOREIGN KEY (id_ed) REFERENCES Edition (id_ed), FOREIGN KEY (id_l) REFERENCES Livre(id_l),
PRIMARY KEY (ref_e) );
CREATE TABLE Inscrit ( id_i INT NOT NULL, nom_i VARCHAR (30), prenom_i VARCHAR (30),
date_naissance_i DATE, rue_i VARCHAR(50), ville_i VARCHAR(50), cp_i VARCHAR (5), tel_i
VARCHAR(15), tel_portable_i VARCHAR(15) , email_i VARCHAR(100), PRIMARY KEY (id_i) );
CREATE TABLE Emprunt ( id_em INT NOT NULL, date_em DATE, delais_em INT DEFAULT 0, id_i INT NOT
NULL, ref_e VARCHAR (254) NOT NULL, FOREIGN KEY (id_i) REFERENCES Inscrit(id_i), FOREIGN KEY
(ref_e) REFERENCES Exemplaire(ref_e), PRIMARY KEY (id_em) );
Le modèle conceptuel des données (MCD)
a pour but de représenter de façon structurée les données qui seront utilisées par le système d'information.
Le modèle conceptuel des données décrit la sémantique c’est à dire le sens attaché à ces données et à leurs rapports et non à l’utilisation qui peut en être faite. On établit le MCD après avoir recensé et donné un nom à l’ensemble des données du domaine étudié. Ensuite on étudie les relations existantes entre ces
Les valeurs de la clé primaire sont donc uniques
Les valrurs se la clé primaire sont obligatoirement non nulles
Transformation des classes : chaque classe du diagramme UML devient une relation, il faut choisir un attribut de la classe pouvant jouer le rôle de clé
Une association de type 1:N (c’est à dire qui a les cardinalités maximales positionnées à « 1 » d’une côté de l’association et à « n » de l’autre côté) se traduit par la création d’une clé étrangère dans la relation correspondante à l’entité côté « 1 ». Cette clé étrangère référence la clé primaire de la relation correspondant à l’autre entité.
Association 1.. : il faut ajouter un attribut de type clé étrangère dans la relation fils de l'association. L'attribut porte le nom de la clé primaire de la relation père de l'association. [C.S02]
Une commande est passée par un seul client. un client peut avoir passé 0 ou n commandes. Il est donc nécessaire de dupliquer dans la table COMMANDE l'identifiant de l'entité CLIENT.
Une association de type N :N (c’est à dire qui a les cardinalités maximales positionnées à « N » des 2 côtés de l’association) se traduit par la création d’une relation dont la clé primaire est composée des clés étrangères référençant les relations correspondant aux entités liées par l’association. Les éventuelles propriétés de l’association deviennent des attributs de la relation.
Association *..* et n-aire et classes-association : la classe-association devient une relation. La clé primaire de cette relation est la concatenation des identifiants des classes connectées à l'association. [C.S02]
Cas particuliers : associations 1,1 : On entend par association 1,1 une association dont les cardinalités maximales sont à 1 de chaque côté Exemple 1 : Dans le cadre d’une course à la voile en solitaire, représentez le schéma relationnel après avoir fait le schéma Entité-Relations pour les informations suivantes : numero du marin, nom du marin, numéro du voilier, nom du voilier.
Association 1.. 1 : il faut ajouter un attribut de type clé étrangère dans la relation dérivée de la classe ayant la multiplicité minimale égale à un. L'attribut porte le nom de la clé primaire de la relation dérivée de la classe connectée à l'association. Si les deux multiplicités minimales sont à un, il est préférable de fusionner les deux classes en une seule. [C.S02]
Une association de type N :N (c’est à dire qui a les cardinalités maximales positionnées à « N » des 2 côtés de l’association) se traduit par la création d’une relation dont la clé primaire est composée des clés étrangères référençant les relations correspondant aux entités liées par l’association. Les éventuelles propriétés de l’association deviennent des attributs de la relation.
Nous voyons désormais que les entités PROSPECT, EMPLOYE et CLIENT n'ont plus de clef. C'est normal ces entités vont hériter des données de la table PERSONNE contenant une clef.
A ce stade il existe deux possibilités :
chacune des tables filles (PROSPECT, EMPLOYE, CLIENT) hérite de tous les attributs de PERSONNE lors du passage au modèle physique
les tables filles n'héritent que de la clef de la table PERSONNE et il faut faire une jointure entre table fille et mèere pour retrouver toutes les données
Nous voyons désormais que les entités PROSPECT, EMPLOYE et CLIENT n'ont plus de clef. C'est normal ces entités vont hériter des données de la table PERSONNE contenant une clef.
A ce stade il existe deux possibilités :
chacune des tables filles (PROSPECT, EMPLOYE, CLIENT) hérite de tous les attributs de PERSONNE lors du passage au modèle physique
les tables filles n'héritent que de la clef de la table PERSONNE et il faut faire une jointure entre table fille et mèere pour retrouver toutes les données
On note que les entités PROSPECT, EMPLOYE et CLIENT héritent de la colonne clef de la table mère PERSONNE.
NOT NULL : on n’accepte pas que l’attribut puisse avoir une valeur nulle (valeur inconnue) PRIMARY KEY (cli_num): l’attribut cli_num est clé primaire de la table Client. Remarque : un attribut déclaré clé primaire doit être défini avec l'option NOT NULL