Cycle de vie d’une B.D
? Déroulement de l’étude préalable :
1. Analyse des besoins et de l’existant (problèmes à résoudre)
L'expression des besoins est une étape consistant à définir ce que l'on attend du système d'information automatisé, il faut pour cela :
• faire l'inventaire des éléments nécessaires au système d'information
• délimiter le système en s'informant auprès des futurs utilisateurs
Les concepteurs doivent effectuer une enquête précise au niveau des demandeurs de l’application (les clients), et des utilisateurs (souvent le personnel des clients).
2. Communication (interview) avec les utilisateurs, clients et experts
3. Dégager et étudier des alternatives
4. Estimer les coûts et planifier le développement globalement
5. Rédiger le cahier de charges (C.C)
6. Rédiger le contrat
7. Lancer le développement ? La spécification a pour buts :
• La description du modèle fonctionnel du système d’information (quels sont les modules constitutifs? comment l’ensemble fonctionne ?)
• l’estimation des ressources (humaines, et matérielles)
• Obtention du cahier des charges détaillé (fonctionnalités, ressources, contraintes, planning).
? La conception générale
Elle consiste en une description de l’architecture du logiciel, c’est à dire obtenir à la fois : une décomposition du système d’information en un ensemble de modules et de structures de données et une description du rôle de chaque module individuellement, et en interaction avec les autres.
Remarque : Il est important de retenir que les travaux de cette étape doivent rester indépendants d’une quelconque implémentation (langage de programmation ou SGBD).
Schéma des phases de réalisation d’un logiciel
Les concepteurs vont devoir utiliser des méthodes, des outils de conception.
? La conception d'un système d'information n'est pas évidente car il faut réfléchir à l'ensemble de l'organisation que l'on doit mettre en place. La phase de conception nécessite des méthodes permettant de mettre en place un modèle sur lequel on va s'appuyer lors du développement.
? La modélisation consiste à créer une représentation virtuelle d'une réalité de telle façon à faire ressortir les points auxquels on s'intéresse. Ce type de méthode est appelé analyse. Il existe plusieurs méthodes d'analyse, la méthode la plus utilisée étant la méthode MERISE.
Merise : Définition
MERISE (Méthode d'Étude et de Réalisation Informatique par les Sous-Ensembles ou pour les Systèmes d'Entreprises) est une méthode de conception de projets informatiques. Son but est d'arriver à concevoir un système d'information en se basant sur la séparation des données et des traitements à effectuer en plusieurs modèles conceptuels et physiques. La séparation des données et des traitements assure une longévité au modèle. En effet, l'agencement des données n'a pas à être souvent remanié, tandis que les traitements le sont plus fréquemment. I- Modèle Conceptuel de Données (MCD):
On cherche à trouver un modèle représentatif des données que nous fournit un univers d'information, pour lequel on mettra en place ultérieurement des traitements automatiques.
Le MCD permet le passage d'un concret inaccessible (l'univers réel) à un abstrait manipulable. Le schéma conceptuel peut donc être considéré comme la description du contenu de la base : c'est le résultat d'un travail d'analyse et de conception d'un système d'information automatisé.
Merise : Etapes de la démarche
? L’approche Merise se base sur les étapes suivantes :
1-Délimitation du domaine d’étude :
Bien définir les limites du projet : division du cas que‘on traite en sous ensembles cohérents exemple : domaine financier et comptable, domaine commercial, domaine gestion du personnel…
2-Repérage des entités :
Définition : Une entité peut être définie comme une personne, un objet, un lieu, un événement qui ont une existence dans le monde réel. C'est un objet concret ou abstrait, possédant un certain nombre de caractéristiques spécifiques (exemple : le produit x coûte y dirhams).
Définie par : Un nom qui permet de l’identifier
Un ensemble de propriétés/attributs qu’elle possède.
La désignation d’un identifiant: propriété ou ensemble de propriétés permettant de repérer de façon unique une occurrence de cette entité parmi d’autres occurrences
• Exemple: Enseignant possède : un nom, un prénom, un âge, un nombre d’enfants, une situation familiale,…
• Une entité a un seul identifiant
• Une entité a au moins une propriété
• Une entité participe a au moins une association
• A chaque occurrence de l’entité, il ne peut y avoir au plus qu’une valeur de la propriété:
– Si une personne possède plusieurs numéros de téléphone, il faudra éclater ces numéros sous plusieurs titres
• Une information ne peut être que dans une seule entité. Pour être dans cette entité, elle doit dépendre de l’identifiant (notion de dépendance fonctionnelle) 3-Repérage des relations / Associations :
Définition: Une relation contient toujours une clé primaire. Chaque ligne est unique et est accessible de façon univoque par une valeur de la clé primaire. Elle peut représenter le lien entre deux à plusieurs entités.
L’association n’existe qu’à travers les entités qu’elle relie
On désigne en général les associations par des noms de verbe:
• verbe statique à l’infinitif:appartenir,concerner,
• la forme active ou passive permet d’orienter la lecture de l’association
Remarque: Une association n’a pas d’identifiant propre mais ses occurrences sont identifiées par la concaténation des identifiants des entités qu’elle relie
Une association peut être porteuse de données comme il ne peut pas l’être On distingue différents types d’association:
Les associations binaires: qui associent 2 entités
Les associations n-aires: qui associe plus de 2 entités (ex: associations ternaires, quarnaires) Les associations réflexives qui associent les occurrences d’une même entité 4-Identification des entités :
Affecter un identifiant à chaque entité de telle façon à ce qu’un enregistrement soit identifié de façon unique.
5-Précision des cardinalités :
Les cardinalités d'un objet dans une association désignent le nombre minimum (0 ou 1) et le nombre maximum (1 ou n) de liens qu'il existe entre une occurrence de l'objet et une occurrence de l'association.
La cardinalité caractérise la participation d’une entité à une association
Elle représente le nombre d’occurrences de l’association pour chaque occurrence de l’entité On distingue:
La cardinalité minimale: donne le nombre minimum de participation de chacune des occurrences de l’entité à l’association
La cardinalité maximale: donne le maximum de chacune des occurrences de l’entité à l’association
Les cardinalités permettent de caractériser le lien qui existe entre une entité et la relation à laquelle elle est reliée. La cardinalité d'une relation est composée d'un couple comportant une borne maximale et une borne minimale, intervalle dans lequel la cardinalité d'une entité peut prendre sa valeur:
• la borne minimale (généralement 0 ou 1) décrit le nombre minimum de fois qu'une entité peut participer à une relation
• la borne maximale (généralement 1 ou n) décrit le nombre maximum de fois qu'une entité peut participer à une relation
Une cardinalité 1.n signifie que chaque entité appartenant à une classe d'entité participe au moins une fois à la relation. Une cardinalité 0.n signifie que chaque entité appartenant à une classe d'entité ne participe pas forcément à la relation.
(0,1): Une occurrence de l’objet ne participe jamais plus d’une fois à la relation;
(1,1): Une occurrence de l’objet participe une et une seule fois à la relation;
(0,N): Chacune des occurrences de l’objet est reliée à un nombre quelconque d’occurrences de la relation;
(1,N): Une occurrence de l’objet participe toujours au moins une fois à la relation 6-Constitution du Dictionnaire de Donnée (Dico) :
Définition : Le DICO est une mise en forme cohérente de l’ensemble des données de l’organisation dans le ou les domaines de gestion étudiés. C’est la liste précise de chacune des données manipulées (attributs), représentée par un identificateur et une définition précise de la donnée reconnue au sein de l’organisation. Le principe d’attribution d’identificateur est établi autant pour faciliter l’ensemble de la démarche d’analyse que pour des raisons purement informatiques, à savoir la limitation du nombre des caractères des noms de variables dans un programme ou une base de données.
L’explication liée à la donnée ne sert pas uniquement à définir la donnée, mais aussi à préciser le cadre de validité de cette donnée, entre autre les caractéristiques de l’ensemble des valeurs qu’elle peut prendre dans le domaine de gestion étudié. Exemple : le dico de la B.D monarchie se présente comme suit :
| Attribut | Type | Désignation |
| Nom_roi dynastie | Caractère (10) Caractère (20) | Le nom du roi La dynastie |
Exemple d’application 1:
Un client désigné par son numéro, sa raison sociale et son adresse peut commander plusieurs produits. Chaque produit est reconnu par son numéro, sa désignation et son prix unitaire. Dans chaque commande émise, on commande certaines quantités de plusieurs produits. Un même produit peut figurer dans plusieurs factures.
Appliquer sur ce domaine d’étude les étapes de l’approche Merise :
CLIENT(N°Client,RSClient,Adresse)
FACTURE(N°Facture,N°Client*)
PRODUIT(N°Produit,Design,PrixUnit)
LIGNE_FACTURE(N°Facture*,N°Produit*,Quantité)
Exemple d’application 2 :
Un acteur caractérisé par son nom, son prénom, sa nationalité et son age peut jouer un rôle dans au maximum 2 films. Chaque film est identifié par un titre, une date de sortie et une durée. Etablir le schéma conceptuel complet, sachant qu’un producteur finance plusieurs films et qu'un film peut être financé par plusieurs producteurs. Pour chaque film on connaît le montant de financement d'un producteur qui y participe.
Exemple d’application 3 :
Intégrité des données dans une base.
• Assurer l'intégrité des données, c’est préserver la cohérence et l'exactitude des données stockées dans une base de données en validant le contenu des différents champs, en vérifiant la valeur des champs l'un par rapport à l'autre, en validant les données dans une table par rapport à une autre, et en vérifiant que la mise à jour d'une base de données est efficacement et correctement effectuée pour chaque transaction.
• 3 types de contraintes d’intégrité :
ð Intégrité d’entité : unicité de la clé primaire (PRIMARY KEY) ou d’autres clés (UNIQUE)
ð Intégrité de domaine : plage des valeurs possibles pour une colonne. On peut restreindre cette plage en attribuant à la colonne un type défini par l’utilisateur, ou par une contrainte CHECK avec une règle.
ð L'intégrité référentielle garantit la relation entre une clé primaire unique dans une table et les clés étrangères qui y font référence dans les autres tables. Exemple : avant de supprimer une ligne dans la table Examen, il faut supprimer toutes les lignes de la table épreuve qui font référence à cet examen. Il faut détruire les tables dans l’ordre inverse de leur création.
• Pour assurer l’intégrité référentielle, SQL Server interdit de :
- ajouter des enregistrements à une table liée lorsqu'il n'y a aucun enregistrement associé dans la table primaire ;
- changer des valeurs ou effacer des enregistrements dans une table primaire qui engendrerait des enregistrements «orphelins» dans une table liée; Quelques définitions :
Intégrité d'entité (ou de relation) (Integrity) : Règle obligatoire dans une base de données relationnelle, spécifiant que les valeurs d'une clé primaire doivent être uniques et non NULL. Intégrité de référence (ou référentielle) (Referential Integrity) : Règle de cohérence hautement souhaitée dans une base de données relationnelle, obligeant à vérifier la correspondance entre la valeur d'une clé étrangère et celle de la clé primaire associée. Cette règle doit être vérifiée à chaque mise à jour de la base
Une relation est toujours représentée au niveau conceptuel, donc en SQL, comme une table à deux dimensions, composées de lignes constituées d'attributs. Pour être manipulable par SQL, une relation doit être en "première forme normale" (ou "normalisée"), c'est à dire que chaque attribut doit avoir une valeur atomique.
Règle de gestion : Une règle de gestion est une loi qui à l’échelle de l’entreprise va s’appliquer systématiquement dans les cas qu’elle doit régir. Par exemple une règle de gestion définira l’application d’une remise de 20% aux clients dont le chiffre d’affaire de l’année précédente a dépassé 200 000 euros ; une autre imposera que les commandes aux fournisseurs qui dépassent 10 000 euros soient visées par le chef du service achats La difficulté principale liée aux règles de gestion tient au fait qu’elles ne sont pas toujours formalisées et qu’il est souvent difficile de les faire exprimer par ceux qui les appliquent régulièrement.
Occurrence
L'occurrence d'une propriété est l'une des valeurs que peut prendre cette propriété. L'occurrence d'un objet est l'un des ensembles d'occurrences de ses propriétés. L'occurrence d'une association est l'une des liaisons entre occurrences d'objets participant à l'association.
Contrainte d’intégrité :
Une contrainte d’intégrité (C.I.) est une règle à observer pour que chacune des valeurs que revêt une donnée soit correcte. Autrement dit, les CI associées à une donnée définissent les règles d’appartenance à son domaine. Par exemple, la date de naissance d’un titulaire du permis de conduire sera considérée comme correcte - indépendamment de toute erreur de saisie - si elle est antérieur d’au moins 18 ans à la date du jour.
Il existe différents types de C.I. : les C.I. «mono-attribut»,les C.I. «inter attribut, mono-table» et les C.I «inter-tables». A ce stade de l’analyse, l’indépendance qu’on accorde aux données par rapports à leurs supports d’origine repousse l’étude des deux derniers types de C.I. à l’étape du : « Développement ».
Les C.I «mono-attribut» sont des règles concernant les valeurs d’une donnée et elle seule. On trouve dans cette catégorie tous les types de C.I suivants :
- obligation de présence : la donnée doit être non vide
- les valeurs de la donnée doivent appartenir à un ensemble restreint de valeur exemple : état - civil dans ( Mr, Mme, Melle)
- les valeurs doivent appartenir à une fourchette de valeur
- exemple 10 ? quantité < 1000
Dépendance fonctionnelle :
Définition :
Une propriété ou un ensemble de propriétés P2 dépend fonctionnellement d'une propriété ou d'un ensemble de propriétés P1, si la connaissance de la valeur de P1 détermine une et une seule valeur de P2. Cette dépendance est notée P1P2 et se lit « P2 dépend fonctionnellement de P1 » ou « P1 détermine P2 par DF ». Un identifiant détermine par DF toutes les autres propriétés de l'objet ou de l'association.
Exemple 1 : La gestion des commandes clients obéit à une règle tout à fait générale qui est : une commande n'est passée que par un seul client. Une deuxième règle de gestion est : chaque commande est identifiée par un numéro. Il résulte de ces deux règles que la connaissance d'un numéro de commande permet la connaissance du client qui a passé cette commande. L'inverse n'est pas possible bien sûr. La relation "une commande est passée par un client" sera donc représentée par une association hiérarchique.
Exemple 2 : Dans les établissement scolaires on trouve ces deux règles de gestion : un élève appartient obligatoirement à une classe ; un élève n'appartient qu'à une seule classe. L'identification de l'élève entraînera l'identification de sa classe. L'inverse n'est pas possible. La relation "un élève fait partie d'une classe" sera donc représentée par une association hiérarchique. Une DF est nommée aussi "Relation père-fils" car, vous l'avez constaté dans les deux exemples ci-dessus, la relation d'identification ne fonctionne que dans un sens. Un fils n'a qu'un père ; un père a plusieurs fils. Un élève n'appartient qu'à une classe ; une classe comporte plusieurs élèves.
Les DF sont régies par la règle mathématique de transitivité : si P1 P2 et P2 P3 alors P1
P3. Une DF P1 P2 est dite directe s'il n'y a pas de transitivité P1 P3 et P3 P2. Une DF n'est jamais porteuse de données.
Type de DF :
Certains auteurs distinguent la DF forte et faible. La DF forte est caractérisée par une cardinalité 1/1-0/N , 1/1-1/N ou 1/1-m/n et la DF faible se caractérise par une cardinalité de 0/1-0/N , 0/1-1/N ou 0/1-m/n et elle est dite faible si la connaissance d'une valeur de X implique la connaissance d’au plus une valeur de Y (zéro ou une).
Cette distinction est à utiliser avec précaution. Les lois de composition interne, notamment la transitivité, ne s’appliquent qu’aux DF "fortes". La pérennité de la DF
Une DF peut être stable dans le temps ou non. La stabilité d’une DF s’explique comme suit : Une CIF est un cas particulier de la DF forte. .De plus la dépendance doit être stable , c’ est à une fois le lien DF établi entre deux occurrences, il ne peut être modifié dans le temps (lien stable dans le temps) . Une telle dépendance, forte et stable à la fois, est dite totale.
Par exemple entre un individu "facture" et "client" il existe une CIF, alors qu'entre un individu "Agent" et "contrat" il existe une DF (l'agent qui gère le contrat peut changer dans le temps). Exemples :
D’un point de vue sémantique on sait qu’une commande ne peut exister si elle n’a pas été passée par un client, et que cette commande dépendra toujours de ce client et uniquement de celui ci.
• Le client peut signer de 0 à N contrat;
• Le contrat est signé par un seul et un seul client.
| Emplacement |
| Numéro d'emplacement Surface Nombre personne max |
| Type d'Emplacement |
| Type d'emplacement Tarif de location |
1,1 0,n
Dans un camping un emplacement est d’un type particuliers (tente, caravane, camping car, ), toutefois rien n’empêche son propriétaire de modifier ce type en fonction de ses besoins. Ce qui fait que le type d’un emplacement peut varier au cours du temps.
Un cheval appartient bien à un propriétaire, mais il pourra appartenir à un autre propriétaire si le premier vient à le vendre. Le lien hiérarchique liant le premier propriétaire au cheval est donc bien temporaire.
Un ouvrage est édité par un et un seul éditeur
Graphe des dépendances fonctionnelles :
C'est une représentation graphique permettant de visualiser aisément toutes les dépendances fonctionnelles qui se trouvent dans un MCD.
Exemples d’applications : Définir le GDF pour les MCD déjà établis Bien concevoir une base de donnée :
De nombreux travaux ont permis de mettre au point une théorie de conception d'une base de données relationnelle : la théorie de la normalisation Théorie de normalisation:
Objectifs:
La mise sous une forme "normale" des relations, ou normalisation, permet de construire un schéma conceptuel correct à partir des relations issues des données recueillies auprès des clients. Cette représentation du monde réel minimise la redondance et les risques d'anomalies lors des mises à jour et assure l’intégrité des données.
La 0eme Forme Normale : Une relation est dite en 0 ème forme normale si et seulement si chaque table est identifiée par une clé primaire et que tous les autres attributs soient en dépendance fonctionnelle avec la clé primaire.
Première Forme Normale (1FN) :
Une relation est dite en première forme normale si elle est en 0 ème forme normale et si les propriétés d’un individu ou d’une relation sont atomiques : A un instant donné dans une entité, un attribut ne peut prendre qu’une seule valeur et non pas plusieurs. Si un attribut prend plusieurs valeurs, alors ces valeurs doivent faire l’objet d’une entité supplémentaire, en association avec la première.
Exemples :
I-Livres (num_livre,titre,nom_auteur,nombre_page,année_edition) : il peut y avoir plusieurs auteurs pour un livre donné En première forme normale :
| Livre Num_livre Titre Nombre_page Année |
1,n
II-formateur (num_f,nom_f,prenom_f,num_etab,nom_etab,ville_etab) : Un formateur peut travailler dans plusieurs établissements, de ce fait l’attribut nom_etab n’est pas atomique. En première forme normale :
III-
|
groupe
répétitif
En première forme normale :
| COMMANDE | ARTICLE COMMANDE | |
| n° commande date n° client nom | n° commande n° article désignation qté commandée |
Deuxième Forme Normale (2FN) :
Une relation est dite en deuxième forme normale si et seulement si elle est en première forme normale, et si tout attribut n'appartenant pas à la clé primaire ne dépend pas fonctionnellement que d'une partie de cette clé.
Exemples :
I- Soit la relation
OPERATION(N°Compte*,CodeOpe*,DateOpe*,Nom,Prenom,LibelOpe,Somme)
On note que :
Nom et Prénom dépendent fonctionnellement de N°Compte, Libellé d'opération dépend fonctionnellement de Code opérationEn deuxième forme normale :
On va obtenir une relation ternaire avec les tables suivantes :
COMPTE(N°Compte,Nom,Prénom)
LIBELLE(CodeOpe,LibelOpe) problème de cardinalité a résoudre : la cardinalité de la patte compte (0-1 ou 0-n)
OPERATION(N°Compte*,DateOpe*,CodeOpe*,somme)
II-
| ARTICLE COMMANDE |
| n° commande n° article désignation qté commandée |
En deuxième forme normale :
|
|
Troisième Forme Normale (3FN)
Une relation est en troisième forme normale (3FN) si elle est en deuxième forme normale et si tout attribut non clé ne dépend pas fonctionnellement d'un autre attribut non clé.
Exemples :
I-ADHERENT(CodeAdh,NomAdh,AdressAdh,TypAdh,CotisTyp)
On impose que la cotisation de l'adhérent dépend fonctionnellement du type de l'adhérent.En troisième forme normale : TYPE(TypAdh,CotisAdh)
ADHERENT(CodeAdh,NomAdh,AdressAdh,DatPaiCot)
II-
| COMMANDE |
| n° commande date n° client nom |
En troisième forme normale :
|
|
III-MATERIEL(code matériel, libellé matériel, code marque, libellé marque)
"libellé marque" est en dépendance fonctionnelle directe avec le "code marque". La relation doit être éclatée en deux, pour être exprimée en troisième forme normale : En troisième forme normale :
R-MATERIEL(code matériel, libellé matériel, code marque)
R-MARQUE(code marque, libellé marque)
II- Le Modèle Logique des Données (MLD)
Afin de rendre le MCD exploitable par le logiciel de base de données prévu, on transforme le MCD selon un formalisme machinal, c’est à dire compréhensible par la machine, en un modèle logique de données noté MLD, ce modèle consiste à décrire la structure de données utilisée sans faire référence à un langage de programmation. A l’issue de cette étape on disposera d’un schéma logique qu’il restera à traduire ensuite dans le langage d’implantation physique d’une base de données. Le langage généralement utilisé pour ce type d'opération est le SQL, et plus spécialement le langage de définition de données du SQL (DDL).
Le modèle relationnel
Traduction d'une classe d'entité
Chaque classe d'entité du modèle conceptuel devient une table dans le modèle logique. Les identifiants de la classe d'entité sont appelé clés de la table, tandis que les attributs standard deviennent des attributs de la table, c'est-à-dire des colonnes.
Traduction d'une classe de relation
Le passage du modèle conceptuel au modèle logique au niveau des classes de relation se fait selon les cardinalités des classes d'entité participant à la relation:
• si l’une des classes d'entités possède une cardinalité faible: la table aura comme attributs, les attributs de la classe ayant une cardinalité faible, puis le (ou les) attribut(s) de relation et enfin les attributs de la seconde classe précédé du nom de la classe
• si les deux classes d'entités possèdent une cardinalité forte: la table aura comme attributs, les attributs des deux classes de relation précédés des noms des classes respectives, puis le (ou les) attribut(s) de relation
Le modèle physique
Cette étape consiste à implémenter le modèle dans le SGBD, c'est-à-dire le traduire dans un
Le langage généralement utilisé pour ce type d'opération est le SQL, et plus spécialement le langage de définition de données du SQL.
Les règles de passage du MEA au MR.
Les règles générales
De façon générale, les règles de passage d’un MCD en un MLD se résument dans ce qui suit :
Règle 1 : Les entités qui ne sont pas porteuses d’autres données que leur identifiant peuvent disparaître du modèle logique.
Règle 2 : Les autres entités deviennent des tables dont la clé primaire est l’identifiant de l’entité.
Règle 3 : Les associations, de type Contrainte d’Intégrité Fonctionnel (C.I.F.) ou Dépendance Fonctionnelle simple (D.F.). Soit de cardinalités (1/1 (ou 0/1) - 0 ou 1/N) disparaissent du modèle logique. L’identifiant de l’entité but (cardinalité 0 ou 1/N) devient clé étrangère dans la table représentant l’entité source (cardinalité 1/1).
Exemple : (CIF dépendance fonctionnelle forte)
COMMANDE (Numéro commande, date commande, Numéro client#)
CLIENT (Numéro client, Nom client, Adresse client)
Autres notations
COMMANDE (Numéro commande, date commande, Numéro client*)
Exemple : (DF dépendance fonctionnelle faible)
| Emplacement |
| Numéro d'emplacement Surface Nombre personne max |
| Type d'Emplacement |
| Type d'emplacement Tarif de location |
1,1 0,n
EMPLACEMENT (Numéro d’emplacement, Surface, Nombre personne max, Type d’emplacement#)
TYPE D’EMPLACEMENT (Type d’emplacement, Tarif de location)
Autres notations
EMPLACEMENT (Numéro d’emplacement, Surface, Nombre personne max, Type d’emplacement*)
Règle 4 : Les associations porteuses ou non de données deviennent des tables dont la clé primaire est la concaténation des identifiants des entités reliées par l’association.
EMPLOIE (Numéro projet#, Numéro employé#)
PROJET (Numéro projet, Nom projet, Budget projet)
EMPLOYE (Numéro employé, Nom Employé, prénom employé)
EMPLOIE (Numéro projet#, Numéro employé#, Nb heure travail) PROJET (Numéro projet, Nom projet, Budget projet)
EMPLOYE (Numéro employé, Nom Employé, prénom employé)
Exemple : règles 1, 2, et 4 sur une association reliant trois entités (ternaire)
DATE (Date d’ouverture)
SERVEUR (Numéro serveur, Nom serveur, Prénom serveur)
TABLE (Numéro table, capacité)
EST_AFFECTE (Numéro serveur#, Numéro table#, Date d’ouverture)
Règle 5 : Cas des associations de cardinalités particulières.
Les associations réflexives.
est la suite de
Solution 1 : On considère être en présence d’une association de type (0/N,0/N), on applique de ce fait la règle 4 en prenant soin de renommer les parties composant la clé primaire de telle façon à ce que la sémantique du modèle conceptuel soit conservée.
LIVRE (Code livre, titre, date d’édition)
PRECEDE(Code livre#, Code livre Suivant#)
Solution 2 : On considère être en présence d’une association de type (1/1,0/N), on applique de ce fait la règle 3 en prenant soin de renommer la clé étrangère de telle façon à ce que la sémantique du modèle conceptuel soit conservée.
LIVRE (Code livre, titre, date d’édition, Code livre Suivant#)
Remarque : Le choix de la solution à retenir va dépendre du contexte.
Si l’on considère qu’en règle générale peu de livre ont des suites on choisira la solution 1, dans le cas où l’on rencontre un livre qui est la suite d’un autre on crée une occurrence dans PRECEDE, ce qui évite une multitude de Code livre Suivant (table LIVRE) à vide si l’on avait choisi la solution 2.
PERSONNE (Code_personne, Nom, Prenom, Date_naissance,Code_père#,Code_mère#)
Cardinalités spécifiques :
ENTREPRISE(référence entreprise, raison sociale, adresse, code tuteur#)
TUTEUR(code tuteur, nom, prénom, téléphone, référence entreprise#)
Solution 1 : On considère être en présence d’une association de type (1/N,0/N), on applique de ce fait la règle 4.
DEPARTEMENT(Numéro département, Budget département)
EMPLOYE(Numéro employé, nom employé, prénom employé)
DIRIGE(Numéro département#, Numéro employé#)
Solution 2 : On considère être en présence d’une association de type (1/1,0/N), on applique de ce fait la règle 3 on prendra soin de renommer la clé étrangère pour conserver la sémantique du problème
DEPARTEMENT(Numéro département, Budget département, Numéro employé directeur#) EMPLOYE(Numéro employé, nom employé, prénom employé)
Solution 3 : On considère être en présence d’une association non hiérarchique (1/1,1/1).
DEPARTEMENT(Numéro département, Budget département, Numéro employé directeur#) EMPLOYE(Numéro employé, nom employé, prénom employé, Numéro département
dirigé#)
Solution 1 : (absolument logique) On considère être en présence d’une association hiérarchique (1/1,0/N), on applique de ce fait la règle 3 on prendra soin de renommer la clé étrangère pour conserver la sémantique du problème
STAGE(Numéro stage, Libellé stage, Date stage, Durée stage, Numéro formateur responsable#)
FORMATEUR(Numéro formateur, Nom formateur, Prénom formateur)
Solution 2 : On considère être en présence d’une association non hiérarchique (1/N,0/N), on applique de ce fait la règle 4.
STAGE(Numéro stage, Libellé stage, Date stage, Durée stage)
FORMATEUR(Numéro formateur, Nom formateur, Prénom formateur) RESPONSABLE(Numéro stage#, Numéro formateur#)
Ä adaptation à une possible modification de contexte de la responsabilité du stage.
Remarque : Cette modélisation peut être discutable (cas d’illustration).
Solution 1 : On considère être en présence d’une association hiérarchique (1/1,0/N), on applique de ce fait la règle 3 on prendra soin de renommer la clé étrangère pour conserver la sémantique du problème, sans oublier la donnée portée.
STAGE(Numéro stage, Libellé stage, Date stage, Durée stage, Numéro formateur responsable#,
Prime)
FORMATEUR(Numéro formateur, Nom formateur, Prénom formateur)
Solution 2 : On considère être en présence d’une association non hiérarchique (1/N,0/N) porteuse de données, on applique de ce fait la règle 4.
STAGE(Numéro stage, Libellé stage, Date stage, Durée stage)
FORMATEUR(Numéro formateur, Nom formateur, Prénom formateur)
RESPONSABLE(Numéro stage#, Numéro formateur#, Prime)
La sémantique du modèle nous indique qu’un étudiant peut ou ne pas être délégué de classe, et qu’une classe peut avoir de 0 à 2 délégués.
En appliquant la règle 4
ETUDIANT(Code élève, nom, prénom)
CLASSE(Code classe, effectif)
DELEGUE(Code classe#, Code élève#)
On peut aussi imaginer la solution suivante en appliquant la règle 3 (présence d’une DF) ETUDIANT(Code élève, nom, prénom)
CLASSE(Code classe, effectif, Code délégué1#, Code délégué2#)
CLASSE(Code classe, Libellé classe, Effectif)
MATIERE(Code matière, Libellé matière)
PROFESSEUR(Numéro professeur, Nom professeur, Prénom professeur)
ASSURE_les_COURS(Code classe#, Code matière#, Numéro professeur#)
Exemples :
I-
MCD MLD
| Professeur | |
| Num_prof | |
| (1,1) | |
Le 20/04/2006
Installation du Power AMC Designor : Création des entités avec leurs attributs (type) et identifiants. Création aussi des associations. Génération à partir du MCD une fois crée le MPD et par la suite le script sql. Création d’une base de données vierge dans SQL Server et création de sa structure en se basant sur le .sql ainsi obtenu.
Comment transformer l'héritage, les sous-types du MCD dans le MLD
Soit le MCD suivant :
La théorie nous indique qu'il existe 4 possibilités de transformation
? Ne dupliquer dans les tables sous-type que l'identifiant o Cette solution ne pose aucun problème de redondance. Elle est celle qui minimise la place. On peut "reconstituer" les héritages par des vues SQL. o Le MLD suivant est UNE solution possible :
Cycle de vie d’une B.D
? Déroulement de l’étude préalable :
1. Analyse des besoins et de l’existant (problèmes à résoudre)
L'expression des besoins est une étape consistant à définir ce que l'on attend du système d'information automatisé, il faut pour cela :
• faire l'inventaire des éléments nécessaires au système d'information
• délimiter le système en s'informant auprès des futurs utilisateurs
Les concepteurs doivent effectuer une enquête précise au niveau des demandeurs de l’application (les clients), et des utilisateurs (souvent le personnel des clients).
2. Communication (interview) avec les utilisateurs, clients et experts
3. Dégager et étudier des alternatives
4. Estimer les coûts et planifier le développement globalement
5. Rédiger le cahier de charges (C.C)
6. Rédiger le contrat
7. Lancer le développement ? La spécification a pour buts :
• La description du modèle fonctionnel du système d’information (quels sont les modules constitutifs? comment l’ensemble fonctionne ?)
• l’estimation des ressources (humaines, et matérielles)
• Obtention du cahier des charges détaillé (fonctionnalités, ressources, contraintes, planning).
? La conception générale
Elle consiste en une description de l’architecture du logiciel, c’est à dire obtenir à la fois : une décomposition du système d’information en un ensemble de modules et de structures de données et une description du rôle de chaque module individuellement, et en interaction avec les autres.
Remarque : Il est important de retenir que les travaux de cette étape doivent rester indépendants d’une quelconque implémentation (langage de programmation ou SGBD).
Schéma des phases de réalisation d’un logiciel
Les concepteurs vont devoir utiliser des méthodes, des outils de conception.
? La conception d'un système d'information n'est pas évidente car il faut réfléchir à l'ensemble de l'organisation que l'on doit mettre en place. La phase de conception nécessite des méthodes permettant de mettre en place un modèle sur lequel on va s'appuyer lors du développement.
? La modélisation consiste à créer une représentation virtuelle d'une réalité de telle façon à faire ressortir les points auxquels on s'intéresse. Ce type de méthode est appelé analyse. Il existe plusieurs méthodes d'analyse, la méthode la plus utilisée étant la méthode MERISE.
Merise : Définition
MERISE (Méthode d'Étude et de Réalisation Informatique par les Sous-Ensembles ou pour les Systèmes d'Entreprises) est une méthode de conception de projets informatiques. Son but est d'arriver à concevoir un système d'information en se basant sur la séparation des données et des traitements à effectuer en plusieurs modèles conceptuels et physiques. La séparation des données et des traitements assure une longévité au modèle. En effet, l'agencement des données n'a pas à être souvent remanié, tandis que les traitements le sont plus fréquemment. I- Modèle Conceptuel de Données (MCD):
On cherche à trouver un modèle représentatif des données que nous fournit un univers d'information, pour lequel on mettra en place ultérieurement des traitements automatiques.
Le MCD permet le passage d'un concret inaccessible (l'univers réel) à un abstrait manipulable. Le schéma conceptuel peut donc être considéré comme la description du contenu de la base : c'est le résultat d'un travail d'analyse et de conception d'un système d'information automatisé.
Merise : Etapes de la démarche
? L’approche Merise se base sur les étapes suivantes :
1-Délimitation du domaine d’étude :
Bien définir les limites du projet : division du cas que‘on traite en sous ensembles cohérents exemple : domaine financier et comptable, domaine commercial, domaine gestion du personnel…
2-Repérage des entités :
Définition : Une entité peut être définie comme une personne, un objet, un lieu, un événement qui ont une existence dans le monde réel. C'est un objet concret ou abstrait, possédant un certain nombre de caractéristiques spécifiques (exemple : le produit x coûte y dirhams).
Définie par : Un nom qui permet de l’identifier
Un ensemble de propriétés/attributs qu’elle possède.
La désignation d’un identifiant: propriété ou ensemble de propriétés permettant de repérer de façon unique une occurrence de cette entité parmi d’autres occurrences
• Exemple: Enseignant possède : un nom, un prénom, un âge, un nombre d’enfants, une situation familiale,…
• Une entité a un seul identifiant
• Une entité a au moins une propriété
• Une entité participe a au moins une association
• A chaque occurrence de l’entité, il ne peut y avoir au plus qu’une valeur de la propriété:
– Si une personne possède plusieurs numéros de téléphone, il faudra éclater ces numéros sous plusieurs titres
• Une information ne peut être que dans une seule entité. Pour être dans cette entité, elle doit dépendre de l’identifiant (notion de dépendance fonctionnelle) 3-Repérage des relations / Associations :
Définition: Une relation contient toujours une clé primaire. Chaque ligne est unique et est accessible de façon univoque par une valeur de la clé primaire. Elle peut représenter le lien entre deux à plusieurs entités.
L’association n’existe qu’à travers les entités qu’elle relie
On désigne en général les associations par des noms de verbe:
• verbe statique à l’infinitif:appartenir,concerner,
• la forme active ou passive permet d’orienter la lecture de l’association
Remarque: Une association n’a pas d’identifiant propre mais ses occurrences sont identifiées par la concaténation des identifiants des entités qu’elle relie
Une association peut être porteuse de données comme il ne peut pas l’être On distingue différents types d’association:
Les associations binaires: qui associent 2 entités
Affecter un identifiant à chaque entité de telle façon à ce qu’un enregistrement soit identifié de façon unique.
5-Précision des cardinalités :
Les cardinalités d'un objet dans une association désignent le nombre minimum (0 ou 1) et le nombre maximum (1 ou n) de liens qu'il existe entre une occurrence de l'objet et une occurrence de l'association.
La cardinalité caractérise la participation d’une entité à une association
Elle représente le nombre d’occurrences de l’association pour chaque occurrence de l’entité On distingue:
La cardinalité minimale: donne le nombre minimum de participation de chacune des occurrences de l’entité à l’association
La cardinalité maximale: donne le maximum de chacune des occurrences de l’entité à l’association
Les cardinalités permettent de caractériser le lien qui existe entre une entité et la relation à laquelle elle est reliée. La cardinalité d'une relation est composée d'un couple comportant une borne maximale et une borne minimale, intervalle dans lequel la cardinalité d'une entité peut prendre sa valeur:
• la borne minimale (généralement 0 ou 1) décrit le nombre minimum de fois qu'une entité peut participer à une relation
• la borne maximale (généralement 1 ou n) décrit le nombre maximum de fois qu'une entité peut participer à une relation
Une cardinalité 1.n signifie que chaque entité appartenant à une classe d'entité participe au moins une fois à la relation. Une cardinalité 0.n signifie que chaque entité appartenant à une classe d'entité ne participe pas forcément à la relation.
(0,1): Une occurrence de l’objet ne participe jamais plus d’une fois à la relation;
(1,1): Une occurrence de l’objet participe une et une seule fois à la relation;
(0,N): Chacune des occurrences de l’objet est reliée à un nombre quelconque d’occurrences de la relation;
Définition : Le DICO est une mise en forme cohérente de l’ensemble des données de l’organisation dans le ou les domaines de gestion étudiés. C’est la liste précise de chacune des données manipulées (attributs), représentée par un identificateur et une définition précise de la donnée reconnue au sein de l’organisation. Le principe d’attribution d’identificateur est établi autant pour faciliter l’ensemble de la démarche d’analyse que pour des raisons purement informatiques, à savoir la limitation du nombre des caractères des noms de variables dans un programme ou une base de données.
L’explication liée à la donnée ne sert pas uniquement à définir la donnée, mais aussi à préciser le cadre de validité de cette donnée, entre autre les caractéristiques de l’ensemble des valeurs qu’elle peut prendre dans le domaine de gestion étudié. Exemple : le dico de la B.D monarchie se présente comme suit :
| Attribut | Type | Désignation |
| Nom_roi dynastie | Caractère (10) Caractère (20) | Le nom du roi La dynastie |
Exemple d’application 1:
Un client désigné par son numéro, sa raison sociale et son adresse peut commander plusieurs produits. Chaque produit est reconnu par son numéro, sa désignation et son prix unitaire. Dans chaque commande émise, on commande certaines quantités de plusieurs produits. Un même produit peut figurer dans plusieurs factures.
Appliquer sur ce domaine d’étude les étapes de l’approche Merise :
CLIENT(N°Client,RSClient,Adresse)
FACTURE(N°Facture,N°Client*)
PRODUIT(N°Produit,Design,PrixUnit)
LIGNE_FACTURE(N°Facture*,N°Produit*,Quantité)
Exemple d’application 2 :
Exemple d’application 3 :
Intégrité des données dans une base.
• Assurer l'intégrité des données, c’est préserver la cohérence et l'exactitude des données stockées dans une base de données en validant le contenu des différents champs, en vérifiant la valeur des champs l'un par rapport à l'autre, en validant les données dans une table par rapport à une autre, et en vérifiant que la mise à jour d'une base de données est efficacement et correctement effectuée pour chaque transaction.
• 3 types de contraintes d’intégrité :
ð Intégrité d’entité : unicité de la clé primaire (PRIMARY KEY) ou d’autres clés (UNIQUE)
ð Intégrité de domaine : plage des valeurs possibles pour une colonne. On peut restreindre cette plage en attribuant à la colonne un type défini par l’utilisateur, ou par une contrainte CHECK avec une règle.
ð L'intégrité référentielle garantit la relation entre une clé primaire unique dans une table et les clés étrangères qui y font référence dans les autres tables. Exemple : avant de supprimer une ligne dans la table Examen, il faut supprimer toutes les lignes de la table épreuve qui font référence à cet examen. Il faut détruire les tables dans l’ordre inverse de leur création.
• Pour assurer l’intégrité référentielle, SQL Server interdit de :
- ajouter des enregistrements à une table liée lorsqu'il n'y a aucun enregistrement associé dans la table primaire ;
- changer des valeurs ou effacer des enregistrements dans une table primaire qui engendrerait des enregistrements «orphelins» dans une table liée; Quelques définitions :
Une relation est toujours représentée au niveau conceptuel, donc en SQL, comme une table à deux dimensions, composées de lignes constituées d'attributs. Pour être manipulable par SQL, une relation doit être en "première forme normale" (ou "normalisée"), c'est à dire que chaque attribut doit avoir une valeur atomique.
Règle de gestion : Une règle de gestion est une loi qui à l’échelle de l’entreprise va s’appliquer systématiquement dans les cas qu’elle doit régir. Par exemple une règle de gestion définira l’application d’une remise de 20% aux clients dont le chiffre d’affaire de l’année précédente a dépassé 200 000 euros ; une autre imposera que les commandes aux fournisseurs qui dépassent 10 000 euros soient visées par le chef du service achats La difficulté principale liée aux règles de gestion tient au fait qu’elles ne sont pas toujours formalisées et qu’il est souvent difficile de les faire exprimer par ceux qui les appliquent régulièrement.
Occurrence
L'occurrence d'une propriété est l'une des valeurs que peut prendre cette propriété. L'occurrence d'un objet est l'un des ensembles d'occurrences de ses propriétés. L'occurrence d'une association est l'une des liaisons entre occurrences d'objets participant à l'association.
Contrainte d’intégrité :
Une contrainte d’intégrité (C.I.) est une règle à observer pour que chacune des valeurs que revêt une donnée soit correcte. Autrement dit, les CI associées à une donnée définissent les règles d’appartenance à son domaine. Par exemple, la date de naissance d’un titulaire du permis de conduire sera considérée comme correcte - indépendamment de toute erreur de saisie - si elle est antérieur d’au moins 18 ans à la date du jour.
Les C.I «mono-attribut» sont des règles concernant les valeurs d’une donnée et elle seule. On trouve dans cette catégorie tous les types de C.I suivants :
- obligation de présence : la donnée doit être non vide
- les valeurs de la donnée doivent appartenir à un ensemble restreint de valeur exemple : état - civil dans ( Mr, Mme, Melle)
- les valeurs doivent appartenir à une fourchette de valeur
- exemple 10 ? quantité < 1000
Dépendance fonctionnelle :
Définition :
Une propriété ou un ensemble de propriétés P2 dépend fonctionnellement d'une propriété ou d'un ensemble de propriétés P1, si la connaissance de la valeur de P1 détermine une et une seule valeur de P2. Cette dépendance est notée P1P2 et se lit « P2 dépend fonctionnellement de P1 » ou « P1 détermine P2 par DF ». Un identifiant détermine par DF toutes les autres propriétés de l'objet ou de l'association.
Exemple 1 : La gestion des commandes clients obéit à une règle tout à fait générale qui est : une commande n'est passée que par un seul client. Une deuxième règle de gestion est : chaque commande est identifiée par un numéro. Il résulte de ces deux règles que la connaissance d'un numéro de commande permet la connaissance du client qui a passé cette commande. L'inverse n'est pas possible bien sûr. La relation "une commande est passée par un client" sera donc représentée par une association hiérarchique.
Les DF sont régies par la règle mathématique de transitivité : si P1 P2 et P2 P3 alors P1
P3. Une DF P1 P2 est dite directe s'il n'y a pas de transitivité P1 P3 et P3 P2. Une DF n'est jamais porteuse de données.
Type de DF :
Certains auteurs distinguent la DF forte et faible. La DF forte est caractérisée par une cardinalité 1/1-0/N , 1/1-1/N ou 1/1-m/n et la DF faible se caractérise par une cardinalité de 0/1-0/N , 0/1-1/N ou 0/1-m/n et elle est dite faible si la connaissance d'une valeur de X implique la connaissance d’au plus une valeur de Y (zéro ou une).
Cette distinction est à utiliser avec précaution. Les lois de composition interne, notamment la transitivité, ne s’appliquent qu’aux DF "fortes". La pérennité de la DF
Une DF peut être stable dans le temps ou non. La stabilité d’une DF s’explique comme suit : Une CIF est un cas particulier de la DF forte. .De plus la dépendance doit être stable , c’ est à une fois le lien DF établi entre deux occurrences, il ne peut être modifié dans le temps (lien stable dans le temps) . Une telle dépendance, forte et stable à la fois, est dite totale.
Par exemple entre un individu "facture" et "client" il existe une CIF, alors qu'entre un individu "Agent" et "contrat" il existe une DF (l'agent qui gère le contrat peut changer dans le temps). Exemples :
D’un point de vue sémantique on sait qu’une commande ne peut exister si elle n’a pas été passée par un client, et que cette commande dépendra toujours de ce client et uniquement de celui ci.
• Le client peut signer de 0 à N contrat;
• Le contrat est signé par un seul et un seul client.
| Emplacement |
| Numéro d'emplacement Surface Nombre personne max |
| Type d'Emplacement |
| Type d'emplacement Tarif de location |
1,1 0,n
Un cheval appartient bien à un propriétaire, mais il pourra appartenir à un autre propriétaire si le premier vient à le vendre. Le lien hiérarchique liant le premier propriétaire au cheval est donc bien temporaire.
Un ouvrage est édité par un et un seul éditeur
Graphe des dépendances fonctionnelles :
C'est une représentation graphique permettant de visualiser aisément toutes les dépendances fonctionnelles qui se trouvent dans un MCD.
Exemples d’applications : Définir le GDF pour les MCD déjà établis Bien concevoir une base de donnée :
De nombreux travaux ont permis de mettre au point une théorie de conception d'une base de données relationnelle : la théorie de la normalisation Théorie de normalisation:
Objectifs:
La mise sous une forme "normale" des relations, ou normalisation, permet de construire un schéma conceptuel correct à partir des relations issues des données recueillies auprès des clients. Cette représentation du monde réel minimise la redondance et les risques d'anomalies lors des mises à jour et assure l’intégrité des données.
La 0eme Forme Normale : Une relation est dite en 0 ème forme normale si et seulement si chaque table est identifiée par une clé primaire et que tous les autres attributs soient en dépendance fonctionnelle avec la clé primaire.
Première Forme Normale (1FN) :
Une relation est dite en première forme normale si elle est en 0 ème forme normale et si les propriétés d’un individu ou d’une relation sont atomiques : A un instant donné dans une entité, un attribut ne peut prendre qu’une seule valeur et non pas plusieurs. Si un attribut prend plusieurs valeurs, alors ces valeurs doivent faire l’objet d’une entité supplémentaire, en association avec la première.
Exemples :
I-Livres (num_livre,titre,nom_auteur,nombre_page,année_edition) : il peut y avoir plusieurs auteurs pour un livre donné En première forme normale :
| Livre Num_livre Titre Année |
1,n
II-formateur (num_f,nom_f,prenom_f,num_etab,nom_etab,ville_etab) : Un formateur peut travailler dans plusieurs établissements, de ce fait l’attribut nom_etab n’est pas atomique. En première forme normale :
III-
|
groupe
répétitif
En première forme normale :
| COMMANDE | ARTICLE COMMANDE | |
| n° commande date n° client nom | n° commande n° article désignation qté commandée |
Deuxième Forme Normale (2FN) :
Une relation est dite en deuxième forme normale si et seulement si elle est en première forme normale, et si tout attribut n'appartenant pas à la clé primaire ne dépend pas fonctionnellement que d'une partie de cette clé.
Exemples :
I- Soit la relation
OPERATION(N°Compte*,CodeOpe*,DateOpe*,Nom,Prenom,LibelOpe,Somme)
On note que :
Nom et Prénom dépendent fonctionnellement de N°Compte, Libellé d'opération dépend fonctionnellement de Code opérationEn deuxième forme normale :
On va obtenir une relation ternaire avec les tables suivantes :
COMPTE(N°Compte,Nom,Prénom)
LIBELLE(CodeOpe,LibelOpe) problème de cardinalité a résoudre : la cardinalité de la patte compte (0-1 ou 0-n)
OPERATION(N°Compte*,DateOpe*,CodeOpe*,somme)
II-
| ARTICLE COMMANDE |
| n° commande n° article désignation qté commandée |
En deuxième forme normale :
|
|
Troisième Forme Normale (3FN)
Une relation est en troisième forme normale (3FN) si elle est en deuxième forme normale et si tout attribut non clé ne dépend pas fonctionnellement d'un autre attribut non clé.
Exemples :
I-ADHERENT(CodeAdh,NomAdh,AdressAdh,TypAdh,CotisTyp)
ADHERENT(CodeAdh,NomAdh,AdressAdh,DatPaiCot)
II-
| COMMANDE |
| n° commande date n° client nom |
En troisième forme normale :
|
|
III-MATERIEL(code matériel, libellé matériel, code marque, libellé marque)
"libellé marque" est en dépendance fonctionnelle directe avec le "code marque". La relation doit être éclatée en deux, pour être exprimée en troisième forme normale : En troisième forme normale :
R-MATERIEL(code matériel, libellé matériel, code marque)
R-MARQUE(code marque, libellé marque)
II- Le Modèle Logique des Données (MLD)
Afin de rendre le MCD exploitable par le logiciel de base de données prévu, on transforme le MCD selon un formalisme machinal, c’est à dire compréhensible par la machine, en un modèle logique de données noté MLD, ce modèle consiste à décrire la structure de données utilisée sans faire référence à un langage de programmation. A l’issue de cette étape on disposera d’un schéma logique qu’il restera à traduire ensuite dans le langage d’implantation physique d’une base de données. Le langage généralement utilisé pour ce type d'opération est le SQL, et plus spécialement le langage de définition de données du SQL (DDL).
Le modèle relationnel
Traduction d'une classe d'entité
Chaque classe d'entité du modèle conceptuel devient une table dans le modèle logique. Les identifiants de la classe d'entité sont appelé clés de la table, tandis que les attributs standard deviennent des attributs de la table, c'est-à-dire des colonnes.
Traduction d'une classe de relation
Le passage du modèle conceptuel au modèle logique au niveau des classes de relation se fait selon les cardinalités des classes d'entité participant à la relation:
• si les deux classes d'entités possèdent une cardinalité forte: la table aura comme attributs, les attributs des deux classes de relation précédés des noms des classes respectives, puis le (ou les) attribut(s) de relation
Le modèle physique
Cette étape consiste à implémenter le modèle dans le SGBD, c'est-à-dire le traduire dans un
Le langage généralement utilisé pour ce type d'opération est le SQL, et plus spécialement le langage de définition de données du SQL.
Les règles de passage du MEA au MR.
Les règles générales
De façon générale, les règles de passage d’un MCD en un MLD se résument dans ce qui suit :
Règle 1 : Les entités qui ne sont pas porteuses d’autres données que leur identifiant peuvent disparaître du modèle logique.
Règle 2 : Les autres entités deviennent des tables dont la clé primaire est l’identifiant de l’entité.
Règle 3 : Les associations, de type Contrainte d’Intégrité Fonctionnel (C.I.F.) ou Dépendance Fonctionnelle simple (D.F.). Soit de cardinalités (1/1 (ou 0/1) - 0 ou 1/N) disparaissent du modèle logique. L’identifiant de l’entité but (cardinalité 0 ou 1/N) devient clé étrangère dans la table représentant l’entité source (cardinalité 1/1).
Exemple : (CIF dépendance fonctionnelle forte)
COMMANDE (Numéro commande, date commande, Numéro client#)
CLIENT (Numéro client, Nom client, Adresse client)
Autres notations
COMMANDE (Numéro commande, date commande, Numéro client*)
Exemple : (DF dépendance fonctionnelle faible)
| Emplacement |
| Numéro d'emplacement Surface Nombre personne max |
| Type d'Emplacement |
| Type d'emplacement Tarif de location |
1,1 0,n
TYPE D’EMPLACEMENT (Type d’emplacement, Tarif de location)
Autres notations
EMPLACEMENT (Numéro d’emplacement, Surface, Nombre personne max, Type d’emplacement*)
Règle 4 : Les associations porteuses ou non de données deviennent des tables dont la clé primaire est la concaténation des identifiants des entités reliées par l’association.
EMPLOIE (Numéro projet#, Numéro employé#)
PROJET (Numéro projet, Nom projet, Budget projet)
EMPLOYE (Numéro employé, Nom Employé, prénom employé)
EMPLOIE (Numéro projet#, Numéro employé#, Nb heure travail) PROJET (Numéro projet, Nom projet, Budget projet)
EMPLOYE (Numéro employé, Nom Employé, prénom employé)
Exemple : règles 1, 2, et 4 sur une association reliant trois entités (ternaire)
DATE (Date d’ouverture)
SERVEUR (Numéro serveur, Nom serveur, Prénom serveur)
TABLE (Numéro table, capacité)
EST_AFFECTE (Numéro serveur#, Numéro table#, Date d’ouverture)
Règle 5 : Cas des associations de cardinalités particulières.
Les associations réflexives.
est la suite de
Solution 1 : On considère être en présence d’une association de type (0/N,0/N), on applique de ce fait la règle 4 en prenant soin de renommer les parties composant la clé primaire de telle façon à ce que la sémantique du modèle conceptuel soit conservée.
LIVRE (Code livre, titre, date d’édition)
PRECEDE(Code livre#, Code livre Suivant#)
Solution 2 : On considère être en présence d’une association de type (1/1,0/N), on applique de ce fait la règle 3 en prenant soin de renommer la clé étrangère de telle façon à ce que la sémantique du modèle conceptuel soit conservée.
LIVRE (Code livre, titre, date d’édition, Code livre Suivant#)
Si l’on considère qu’en règle générale peu de livre ont des suites on choisira la solution 1, dans le cas où l’on rencontre un livre qui est la suite d’un autre on crée une occurrence dans PRECEDE, ce qui évite une multitude de Code livre Suivant (table LIVRE) à vide si l’on avait choisi la solution 2.
PERSONNE (Code_personne, Nom, Prenom, Date_naissance,Code_père#,Code_mère#)
Cardinalités spécifiques :
ENTREPRISE(référence entreprise, raison sociale, adresse, code tuteur#)
TUTEUR(code tuteur, nom, prénom, téléphone, référence entreprise#)
Solution 1 : On considère être en présence d’une association de type (1/N,0/N), on applique de ce fait la règle 4.
DEPARTEMENT(Numéro département, Budget département)
EMPLOYE(Numéro employé, nom employé, prénom employé)
DIRIGE(Numéro département#, Numéro employé#)
Solution 2 : On considère être en présence d’une association de type (1/1,0/N), on applique de ce fait la règle 3 on prendra soin de renommer la clé étrangère pour conserver la sémantique du problème
DEPARTEMENT(Numéro département, Budget département, Numéro employé directeur#) EMPLOYE(Numéro employé, nom employé, prénom employé)
Solution 3 : On considère être en présence d’une association non hiérarchique (1/1,1/1).
DEPARTEMENT(Numéro département, Budget département, Numéro employé directeur#) EMPLOYE(Numéro employé, nom employé, prénom employé, Numéro département
dirigé#)
Solution 1 : (absolument logique) On considère être en présence d’une association hiérarchique (1/1,0/N), on applique de ce fait la règle 3 on prendra soin de renommer la clé étrangère pour conserver la sémantique du problème
STAGE(Numéro stage, Libellé stage, Date stage, Durée stage, Numéro formateur responsable#)
FORMATEUR(Numéro formateur, Nom formateur, Prénom formateur)
STAGE(Numéro stage, Libellé stage, Date stage, Durée stage)
FORMATEUR(Numéro formateur, Nom formateur, Prénom formateur) RESPONSABLE(Numéro stage#, Numéro formateur#)
Ä adaptation à une possible modification de contexte de la responsabilité du stage.
Remarque : Cette modélisation peut être discutable (cas d’illustration).
Solution 1 : On considère être en présence d’une association hiérarchique (1/1,0/N), on applique de ce fait la règle 3 on prendra soin de renommer la clé étrangère pour conserver la sémantique du problème, sans oublier la donnée portée.
STAGE(Numéro stage, Libellé stage, Date stage, Durée stage, Numéro formateur responsable#,
Prime)
FORMATEUR(Numéro formateur, Nom formateur, Prénom formateur)
Solution 2 : On considère être en présence d’une association non hiérarchique (1/N,0/N) porteuse de données, on applique de ce fait la règle 4.
STAGE(Numéro stage, Libellé stage, Date stage, Durée stage)
FORMATEUR(Numéro formateur, Nom formateur, Prénom formateur)
RESPONSABLE(Numéro stage#, Numéro formateur#, Prime)
La sémantique du modèle nous indique qu’un étudiant peut ou ne pas être délégué de classe, et qu’une classe peut avoir de 0 à 2 délégués.
En appliquant la règle 4
ETUDIANT(Code élève, nom, prénom)
CLASSE(Code classe, effectif)
DELEGUE(Code classe#, Code élève#)
On peut aussi imaginer la solution suivante en appliquant la règle 3 (présence d’une DF) ETUDIANT(Code élève, nom, prénom)
CLASSE(Code classe, effectif, Code délégué1#, Code délégué2#)
CLASSE(Code classe, Libellé classe, Effectif)
MATIERE(Code matière, Libellé matière)
PROFESSEUR(Numéro professeur, Nom professeur, Prénom professeur)
Exemples :
I-
MCD MLD
| Professeur | |
| Num_prof | |
| (1,1) | |
Le 20/04/2006
Installation du Power AMC Designor : Création des entités avec leurs attributs (type) et identifiants. Création aussi des associations. Génération à partir du MCD une fois crée le MPD et par la suite le script sql. Création d’une base de données vierge dans SQL Server et création de sa structure en se basant sur le .sql ainsi obtenu.
Comment transformer l'héritage, les sous-types du MCD dans le MLD
Soit le MCD suivant :
La théorie nous indique qu'il existe 4 possibilités de transformation
? Ne dupliquer dans les tables sous-type que l'identifiant o Cette solution ne pose aucun problème de redondance. Elle est celle qui minimise la place. On peut "reconstituer" les héritages par des vues SQL. o Le MLD suivant est UNE solution possible :
