Ce document académique, élaboré dans le cadre du module "Système d’information et Bases de données" pour l'année universitaire 2019/2020 à l'École Nationale des Sciences Appliquées de l'Université Sidi Mohamed Ibn Abdellah, est destiné aux étudiants.
Il introduit les méthodes d'analyse et de conception des systèmes d'information, en se concentrant sur la méthode MERISE (2ème Génération). Le contenu détaille les modèles conceptuels, tels que le Modèle Conceptuel de Données (MCD) avec les notions d'entités, d'associations et de dépendances fonctionnelles, ainsi que les principes du Modèle Logique de Données Relationnel (MLDR), y compris les attributs et les clés.
Modélisation Merise : Cours Système d’information et Bases de données
Télécharger PDFSystèmes d'Information et Bases de Données
Ce module présente les méthodes d'analyse et de conception des systèmes d'information, avec un focus particulier sur la méthode MERISE et les concepts fondamentaux des bases de données relationnelles.
Les Méthodes d'Analyse et de Conception des Systèmes d'Information
But d'une méthode
- Analyser la réalité du système d'information (SI) en vue de son informatisation.
- Formaliser son activité à l'aide de modèles.
Les techniques de modélisation constituent un domaine en pleine évolution.
Quelques méthodes de modélisation
Approche relationnelle :
- MERISE (première génération 1979 ; deuxième génération 1988 et 1994) de H. Tardieu et A. Rochfeld.
- SSADM (Structured System Analysis And Design Method) du Royaume-Uni (1987).
- AXIAL.
Approche orientée objet :
- OOD (Object Oriented Design) de G. Booch (1986).
- OOA (Object Oriented Analysis) de P. Coad et E. Yourdon (1991).
- OOM (Orientations Objet dans MERISE) de A. Rochfeld (1992).
- OMT (Object Modeling Technique) de J. Rumbaugh (1991).
- UML (Unified Modeling Language) de l’OMG (Object Management Group, 1995).
La Méthode MERISE (Deuxième Génération)
MERISE propose une approche par niveaux, chacun avec des modèles spécifiques pour une description progressive et détaillée du système d'information.
Modèles par Niveau
La méthode MERISE structure la conception en plusieurs niveaux d'abstraction :
- Niveau Conceptuel : Description des processus et données sans contraintes techniques (Quoi). Modèles : Modèle Conceptuel de Communication (MCC), Modèle Conceptuel de Données (MCD), Modèle Conceptuel de Traitements (MCTA).
- Niveau Organisationnel : Intégration des choix humains et organisationnels (Qui, Où, Quand). Modèles : Modèle Organisationnel de Données (MOD), Modèle Organisationnel de Traitements (MOTA).
- Niveau Logique : Spécification des solutions informatiques sans tenir compte de la technologie (Comment de l'informaticien, abstrait). Modèles : Modèle Logique de Données (MLD), Modèle Logique de Traitements (MLT).
- Niveau Physique : Implémentation technique et concrète (Comment de l'informaticien, concret). Modèles : Modèle Physique de Données (MPD), Modèle Physique de Traitements (MPT).
Le Système d'Information vu selon la méthode MERISE
Niveau Conceptuel (SIC)
Modèles utilisés : MCC, MCD, MCTA.
Description : Représente les fonctions majeures du système d'information en réponse aux stimuli de l'environnement extérieur (acteurs externes), sans référence aux ressources nécessaires à sa mise en œuvre. La concentration est faite sur le "Quoi" : quelles sont les données et les processus essentiels, indépendamment de leur réalisation.
Niveau Organisationnel (SIO)
Modèles utilisés : MOD, MOTA.
Description : Décrit les ressources nécessaires à la mise en œuvre des activités du SIC du point de vue du gestionnaire (moyens techniques et humains, espace, temps, données) et le choix d'une organisation pour ces ressources. La concentration est faite sur le "Comment" du gestionnaire : qui fait quoi, quand et avec quels moyens.
Niveau Logique (SII)
Modèles utilisés : MLD, MLT.
Description : Décrit une solution informatique permettant d'assurer le fonctionnement du SIO. Cela inclut :
- Les choix techniques concernant les outils de gestion de données (Système de Gestion de Bases de Données – SGBD) et les outils de développement informatiques.
- La représentation de la structure logique des données (base de données) et des traitements (interaction homme-machine au niveau des postes de travail).
- La description de l'architecture informatique (répartition des traitements et des données).
La concentration est faite sur le "Comment" de l'informaticien, mais de manière abstraite et indépendante de la technologie finale.
Niveau Physique (SIOp)
Modèles utilisés : MPD, MPT.
Description : Représente la mise en œuvre opérationnelle d'une solution informatique. Cela implique :
- La description de la base de données dans la syntaxe du SGBD choisi.
- Le codage des procédures logiques de traitement en langage informatique évolué (programmation).
- La mise en place d'une architecture de fonctionnement en réseau (architecture centralisée, distribuée ou répartie).
Ce niveau se concentre sur l'implémentation concrète de la solution.
Le Modèle Conceptuel de Données (MCD)
Le formalisme du MCD est le Modèle Entité-Association, développé par Peter Chen aux États-Unis (1976) puis par H. Tardieu en France (1979).
Ce modèle permet de représenter la structure statique des données d'un système d'information en identifiant les entités, leurs propriétés et les associations qui les relient.
Notion d'Entité
Une Entité est la représentation d'un objet concret ou abstrait du système d'information, caractérisé par :
- Des propriétés (attributs) : P1, P2, P3, ..., Pn.
- Un identifiant : une propriété (P1) dont les valeurs sont discriminantes, c'est-à-dire uniques pour chaque occurrence de l'entité.
- Des occurrences (instances) multiples (au moins deux).
Exemple :
L'entité "Étudiant" peut avoir les propriétés "N° Inscription" (identifiant), "Nom", "Prénom", "Nationalité".
Une occurrence d'entité est un jeu de valeurs prises par les propriétés de l'entité. Par exemple :
- Étudiant (N° Inscription: 918, Nom: DAOUDI, Prénom: MOUNIR, Nationalité: MAROCAINE)
- Étudiant (N° Inscription: 125, Nom: ALAMI, Prénom: DRISS, Nationalité: MAROCAINE)
- Étudiant (N° Inscription: 235, Nom: SEBASTIEN, Prénom: ALBERT, Nationalité: FRANÇAISE)
Notion d'Association
Une Association traduit les liens sémantiques existant entre deux ou plusieurs entités du système d'information et de son environnement. Elle est caractérisée par :
- L'absence d'existence intrinsèque : elle ne peut exister sans les entités qu'elle relie.
- Des occurrences (au moins une).
- Des propriétés portées (nombre M), où M peut être 0, 1, 2, 3, etc. Ces propriétés sont spécifiques au lien.
- Une dimension N (N = nombre d'entités rattachées).
- Un identifiant obtenu par concaténation des identifiants des entités rattachées.
Exemples :
- Association binaire non porteuse d'identifiant : "Loué par" entre "Client" (N° Client, Nom, Adresse) et "Véhicule" (N° Immatriculation, Date mise en service, Kilométrage). L'identifiant de l'association serait (N° Immatriculation, N° Client).
- Association binaire porteuse d'une propriété : "Affecté à" entre "Salarié" (Matricule, Nom) et "Service" (N° Service, Désignation), avec la propriété "Date affectation". L'identifiant de l'association serait (Matricule, N° Service).
Occurrences d'Association
Les occurrences d'association représentent des faits concrets. Par exemple, pour l'association "Affecté à" entre "Salarié" et "Service" :
- Un salarié A01 est affecté au service 125 (Comptabilité) le 18/05/92.
- Un salarié A12 est affecté au service 125 (Comptabilité) le 11/10/91.
- Un salarié A05 est affecté au service 106 (Magasin) le 04/03/93.
Ces triplets (salarié, service, date) sont des instances de l'association. Les instances comme A09 (salarié DAOUDI) et 124 (service Commercial) ne participent pas à cette association si aucune date d'affectation n'est enregistrée pour elles dans ce contexte.
Cardinalités d'une Association (Interprétations)
Les cardinalités sont un couple de valeurs (minimale et maximale) représentant la fréquence de participation d'une occurrence d'entité à une association.
Cardinalités minimales :
- 0 : Certaines occurrences de l'entité peuvent ne pas participer à l'association (la participation est facultative).
- 1 : Toute occurrence de l'entité participe obligatoirement à l'association (la participation est obligatoire).
Cardinalités maximales :
- 1 : Toute occurrence de l'entité participe au plus une fois à l'association.
- N : Toute occurrence de l'entité peut participer plusieurs fois à l'association (N étant un nombre quelconque ou infini).
Conclusion :
- La cardinalité minimale traduit la capacité d'une occurrence à exister indépendamment ou non des occurrences de l'association.
- La cardinalité maximale traduit la capacité associative de l'association pour l'entité considérée.
Cardinalités d'une Association
Les cardinalités sont un couple de valeurs représentant la fréquence (minimale et maximale) de participation d'une occurrence d'entité à une association. Elles sont notées (i, j) où 'i' est la cardinalité minimale et 'j' est la cardinalité maximale.
Exemple : Association "Affecté à" entre "Salarié" et "Service" avec la propriété "Date affectation".
Règles de gestion :
- Un salarié est affecté à un et/ou plusieurs services le long de sa carrière.
- À un service, on peut affecter un à plusieurs salariés (maximum 8).
Pour la patte "Salarié" vers "Affecté à" : (1, N) car un salarié doit être affecté à au moins un service (1) et peut être affecté à plusieurs (N). Pour la patte "Service" vers "Affecté à" : (1, 8) car un service doit avoir au moins un salarié (1) et au maximum 8.
Identifiant d'une Association
L'identifiant d'une association est obtenu par concaténation des identifiants des entités reliées par cette association.
Exemple : Association "Visiter" entre "Employé" (N° Employé, Nom Employé, Prénom Employé) et "Médecin" (N° Médecin, Nom Médecin, Spécialité, Téléphone), avec la propriété "Date Visite" portée par l'association.
Si l'identifiant de l'association est (N° Employé, N° Médecin), cela signifie qu'un employé ne peut visiter un même médecin qu'une seule fois. Si l'employé 42 visite le médecin 4 le 22/08/01, il ne pourra pas le visiter à nouveau le 05/09/01 car l'identifiant (42, 4) est déjà pris, violant la règle d'unicité de l'identifiant.
Question : Un employé peut-il effectuer plusieurs visites chez le même médecin à des dates différentes ?
Réponse : Ce modèle, avec l'identifiant (N° Employé, N° Médecin), ne le permet pas, même si la propriété "Date Visite" est portée par l'association "Visiter".
Identifiant d'une Association (Suite)
Solution du Problème : Association ternaire.
Pour permettre à un employé de visiter le même médecin plusieurs fois à des dates différentes, l'identifiant de l'association doit inclure la date de visite. On peut modéliser une association ternaire "Visiter" entre "Employé" (N° Employé), "Médecin" (N° Médecin) et "Calendrier" (Date).
L'identifiant de l'association "Visiter" devient alors (N° Employé, N° Médecin, Date).
Avec cet identifiant, les triplets (42, 4, 22/08/01) et (42, 4, 05/09/01) sont maintenant des occurrences possibles de l'association "Visiter", car ils représentent des valeurs distinctes de son identifiant. Ce modèle permet de représenter le fait qu'un employé peut visiter le même médecin plusieurs fois à des dates différentes.
Généralisation : Une association N-aire (de dimension N) possède un identifiant sous forme de N-uplet dont les valeurs sont distinctes.
Comment doit-on interpréter les cardinalités d'une association ternaire ?
L'interprétation des cardinalités d'une association ternaire (ou N-aire) se fait en fixant les occurrences des autres entités. Par exemple, pour l'association ternaire "Visiter" (Employé, Médecin, Date) :
- Pour un employé E fixé, le couple de cardinalités (i1, j1) traduit le nombre minimal et maximal d'occurrences du couple d'entités (Médecin, Calendrier) qui sont associées à cet employé. Cela indique combien de couples (médecin, date de visite) un employé peut avoir.
- Pour un médecin M fixé, le couple de cardinalités (i2, j2) traduit le nombre minimal et maximal d'occurrences du couple d'entités (Employé, Calendrier) qui sont associées à ce médecin. Cela indique combien de couples (employé, date de visite) un médecin peut avoir.
- De même, pour une date D fixée, (i3, j3) traduit le nombre minimal et maximal d'occurrences du couple d'entités (Employé, Médecin) qui sont associées à cette date. Cela indique combien de couples (employé, médecin) peuvent avoir une visite à cette date.
Rôles dans une Association
Un Rôle est une notion précisant la fonction particulière jouée par un ensemble d'occurrences relatives à une entité dans une association. Les rôles sont portés sur le schéma Entité-Association.
Exemple :
- Association "Livrer" entre "Client" et "Dépôt" : Le client peut jouer le rôle de "destinataire" et le dépôt le rôle de "source", même si non explicité par un nom de rôle sur le diagramme, c'est l'interprétation.
- Association réflexive "A pour chef" sur l'entité "Salarié" : Un salarié peut jouer le rôle de "Chef" et un autre le rôle de "Subalterne". Un même salarié peut potentiellement être chef pour certains et subalterne pour d'autres.
Notion d'entité faible et d'identification relative
Une entité faible (ou entité dépendante) possède un identifiant relatif qui se rapporte toujours à celui d'une entité forte (ou classique) dont elle dépend. L'identifiant absolu de l'entité faible est obtenu en concaténant les identifiants des deux entités (l'entité forte et l'entité faible elle-même).
Formalisme MERISE 2 :
- HOTEL : - Code Hôtel (Identifiant absolu)
- ÉTAGE : - N° Étage (Identifiant relatif), Code Hôtel + N° Étage (Identifiant absolu)
- CHAMBRE : - N° Chambre (Identifiant relatif), Code Hôtel + N° Étage + N° Chambre (Identifiant absolu)
Exemple :
Une chambre est identifiée par son numéro, mais uniquement dans le contexte d'un étage donné. Cet étage est lui-même identifié par son numéro dans le contexte d'un hôtel spécifique. Ainsi, le numéro de chambre n'est pas suffisant pour identifier une chambre de manière unique sans connaître l'hôtel et l'étage.
Notion de Dépendance Fonctionnelle
Définition : Deux propriétés A et B sont en dépendance fonctionnelle (DF) si la connaissance d'une valeur de A détermine une et une seule valeur de B. On dit que A détermine fonctionnellement B.
Formalisme :
A → B: Une source, un but (A détermine B).(X, Y, ...) → B: Plusieurs sources, un but (X et Y ensemble déterminent B).A → (X, Y, ...): Une source, plusieurs buts (A détermine X et A détermine Y).
Exemples :
N° Client → Nom Client(Le numéro de client détermine son nom).(Réf. produit, N° Commande) → Quantité produit commandée(La référence du produit et le numéro de commande déterminent la quantité commandée de ce produit).Réf. produit → (Libellé produit, Prix unitaire produit)(La référence du produit détermine son libellé et son prix unitaire).Nom Client → N° Client(Pas de DF, plusieurs clients peuvent avoir le même nom si non géré).N° Client → Prénom Client(Pas de DF si un client peut avoir plusieurs prénoms ou un prénom n'est pas unique à un N° Client).
Axiomes et Propriétés des Dépendances Fonctionnelles
Axiomes (d'Armstrong) :
- Réflexivité :
X → X(Un ensemble d'attributs se détermine fonctionnellement lui-même). - Augmentation : Si
X → Y, alors(X, Z) → Y(Si X détermine Y, alors X et Z ensemble déterminent toujours Y). - Additivité : Si
X → YetX → Z, alorsX → (Y, Z)(Si X détermine Y et X détermine Z, alors X détermine l'ensemble (Y, Z)). - Projectivité : Si
X → (Y, Z), alorsX → YetX → Z(Si X détermine un ensemble d'attributs, alors X détermine chaque attribut de cet ensemble individuellement). - Transitivité : Si
X → YetY → Z, alorsX → Z(Si X détermine Y, et Y détermine Z, alors X détermine Z). - Pseudo-transitivité : Si
X → Yet(Y, Z) → W, alors(X, Z) → W.
Propriétés :
- DF élémentaire :
X → Yest élémentaire si il existe Z inclus dans X tel queZ → Y. - DF directe :
X → Yest directe si il existe Z tel queX → ZetZ → Y.
Dépendances Fonctionnelles : Cas d'Usage
Dans la modélisation des données, l'identification des dépendances fonctionnelles est cruciale pour la normalisation et la structuration logique des informations.
1 - Cas d'une Entité :
Toutes les propriétés d'une entité sont en dépendance fonctionnelle directe avec la propriété identifiante de cette entité.
Exemple : Pour l'entité CLIENT avec l'identifiant "Code Client", nous avons : Code Client → (Nom, Prénom, Adresse, Téléphone).
2 - Cas d'une Association hiérarchique (monovaluée) :
Une Association Hiérarchique est une association binaire (dimension = 2) dont l'une des pattes possède une cardinalité maximale égale à 1. Ce type d'association est toujours orienté suivant le sens de la dépendance fonctionnelle qui relie les identifiants de ses entités.
Exemple : Association "PASSER" entre "CLIENT" (Code Client, Nom, Adresse) et "COMMANDE" (N° Commande, Date Commande, Montant).
Si la cardinalité maximale de "COMMANDE" vers "PASSER" est 1, cela signifie qu'une commande est passée par un seul client. Alors : N° Commande → Code Client et N° Commande → (Date Commande, Montant).
Remarque : La dépendance fonctionnelle Code Client → N° Commande n'existe pas, car un client peut passer plusieurs commandes (exemple du Client N°4 qui a passé plusieurs commandes).
3 - Cas d'une Association N-aire multivaluée non porteuse de propriétés :
Une Association multivaluée est une association dont toutes les pattes possèdent une cardinalité maximale égale à N (N >= 2). Pour ce type d'association, la DF représentant l'association n'a pas de but explicite (car elle ne porte pas de propriétés).
Exemple 1 : Association binaire "JOUER" entre "ACTEUR" (N° Acteur, Nom, Prénom) et "FILM" (N° Film, Titre, Date Production).
DF représentant l'association (sans but) : (N° Acteur, N° Film) → -
Exemple 2 : Association ternaire "VISITER" entre "EMPLOYÉ" (N° Employé, Nom, Prénom), "MÉDECIN" (N° Médecin, Nom Médecin, Spécialité) et "CALENDRIER" (Date).
DF représentant l'association (sans but) : (N° Employé, N° Médecin, Date) → -
4 - Cas d'une Association N-aire multivaluée porteuse de propriétés :
Lorsque l'association porte des propriétés, l'identifiant concaténé des entités détermine ces propriétés.
Exemple 1 : Association binaire "COMPORTER" entre "FACTURE" (N° Facture, Date Facture, Montant) et "PRODUIT" (Réf. Produit, Désignation, Prix Unitaire), avec la propriété "Quantité Produit" portée par l'association.
DF représentant l'association : (N° Facture, Réf. Produit) → Quantité Produit
Exemple 2 : Association ternaire "TRAJET" entre "VILLE" (N° Ville, Nom Ville, Nombre Habitants) pour "Ville départ" et "Ville arrivée", et "ROUTE" (N° Route, Type Route, État Route), avec la propriété "Distance" portée par l'association.
DF représentant l'association : (N° Ville Départ, N° Ville Arrivée, N° Route) → Distance
5 - Cas d'une Association Hiérarchique Réflexive :
Une association réflexive hiérarchique relie une entité à elle-même avec une cardinalité maximale de 1 d'un côté.
Exemple : Association "A pour Chef" sur l'entité "EMPLOYÉ" (N° Employé, Nom, Prénom, Date Embauche). Un employé a un seul chef, mais un chef peut avoir plusieurs subalternes.
DF représentant l'association : N° Employé (subalterne) → N° Employé (chef)
6 - Cas d'une Association Multivaluée Réflexive :
Une association réflexive multivaluée relie une entité à elle-même avec des cardinalités maximales de N des deux côtés.
Exemple : Association "PARENTE" sur l'entité "PERSONNE" (N° CIN, Nom, Prénom). Pour représenter des liens de parenté généraux (enfant, parent, frère, sœur...).
DF représentant l'association : (N° CIN Parent, N° CIN Enfant) → - (sans but, car la nature du lien est implicite par l'association elle-même ou d'autres propriétés).
7 - Cas d'une Association de Cardinalités Maximales Égales à 1 :
Ce type d'association est orienté dans les deux sens pour indiquer l'existence de deux dépendances fonctionnelles entre les identifiants des entités de l'association.
Exemple : Association "PAYER" entre "FACTURE" (N° Facture, Date Facture, Montant Facture) et "RÈGLEMENT" (N° Règlement, Date Règlement, Montant Règlement).
Règles de gestion :
- Une facture fait l'objet d'un seul règlement.
- Un règlement compense toujours une seule facture.
- À un instant donné, certaines factures peuvent être impayées.
Ceci implique : N° Facture → N° Règlement et N° Règlement → N° Facture.
8 - Cas des entités faibles :
Dans le cas des entités faibles, l'identifiant absolu est une composition des identifiants des entités fortes parentes. Les dépendances fonctionnelles reflètent cette hiérarchie.
Exemple : Dans la structure Hôtel - Étage - Chambre, l'identifiant de "Chambre" est (Code Hôtel, N° Étage, N° Chambre). Une réservation peut être effectuée sur une ou plusieurs chambres.
Code Hôtel → (Nom Hôtel, Adresse Hôtel)
(Code Hôtel, N° Étage) → Nombre de toilettes (si cette propriété est au niveau de l'étage)
(Code Hôtel, N° Étage, N° Chambre) → Surface (si la surface est propre à la chambre)
Pour une réservation : N° Réservation → (Date Réservation, Avance en Dirhams (DH))
Et l'association entre Réservation et Chambre : (N° Réservation, Code Hôtel, N° Étage, N° Chambre) → Durée (durée de la réservation pour cette chambre spécifique).
Graphe de Dépendances Fonctionnelles (GDF)
Le GDF est une représentation graphique de l'ensemble des dépendances fonctionnelles unissant les propriétés dans un domaine d'activité du système d'information. Ces propriétés sont obtenues à partir du dictionnaire de données du domaine. Le GDF est un outil essentiel pour analyser et valider la structure des données avant de passer à la modélisation logique.
Exemple : GDF du domaine de la « Gestion commerciale » dans une entreprise.
Le Modèle Logique des Données (MLD)
But du MLD
Le MLD a pour objectif de représenter la structure logique des données du système d'information sous une forme adaptée à l'utilisation d'un Système de Gestion de Bases de Données (SGBD) ou d'un Système de Gestion de Fichiers (SGF). Il transforme le MCD conceptuel en une structure implémentable.
Différents types de modèles logiques
Plusieurs types de modèles logiques, dits "machinables", ont été exploités sur le marché des SGF et SGBD au fil du temps :
Le Modèle Hiérarchique (années 60)
Il permet de gérer des données dans un ensemble de fichiers sous forme d'un ensemble d'arbres ou de hiérarchies. Seuls les liens de un à plusieurs (1-N) entre enregistrements sont permis (liens père-fils). Les liens multivalués (N-N) doivent être transformés sous forme de liens 1-N indirects.
La recherche d'enregistrements se fait en parcourant l'arbre général par une gestion de pointeurs : du parent vers le premier enfant, puis de celui-ci vers le suivant ou du parent vers le grand-parent, etc.
Les utilisateurs ne peuvent accéder aux données que par l'intermédiaire de programmes de gestion de fichiers (SGF) écrits spécifiquement pour eux, ce qui offre un niveau de réutilisation faible.
Exemples de SGF : IMS (IBM).
Le Modèle Réseau ou CODASYL (1971)
Son but est de lever certaines des contraintes du modèle hiérarchique. Il fonctionne selon le même principe navigationnel, c'est-à-dire par pointeurs. Il permet de représenter les liens N-N entre enregistrements par liaison d'un enregistrement à un ou plusieurs parents et/ou à un ou plusieurs enfants.
Il est basé sur les notions de RECORD (enregistrement) et de SET (lien entre deux enregistrements).
Les premiers SGF et SGBD supportant ce modèle sont apparus en 1978.
Exemples : IDS2 (Bull), DBMS (DEC), IDMS (Culliname), ADABAS (Software AG), etc.
Le Modèle Logique des Données (Suite)
Le Modèle Relationnel (Codd - 1970)
C'est le modèle le plus répandu actuellement sur le marché des SGBD (environ 85 % en 1995 et toujours dominant aujourd'hui). Il lève toutes les contraintes des modèles précédents (hiérarchiques et réseau). Créé par des mathématiciens, il permet de gérer les données sous forme de tables d'enregistrements (appelées "relations"). En reliant ces tables à l'aide d'un système de clés, il est possible de rechercher des données dans une table ou de collecter des données à partir de plusieurs tables (requêtes) satisfaisant un critère fixé.
Exemples de SGBDR (Systèmes de Gestion de Bases de Données Relationnels) :
- INGRES et INFORMIX (sur UNIX et DEC/VMS)
- ORACLE (sur tous les systèmes)
- DB400 (sur IBM/AS400)
- DB2 et SQL/DS (sur gros systèmes IBM)
- MS-SQL Server (sur Windows NT/Server)
- Microsoft Access et Borland Paradox (sur MS-DOS et Windows)
Le Modèle Objet (Années 1990)
C'est le successeur potentiel du modèle relationnel. Il repose sur la théorie des objets. Dans cette théorie, le système d'information peut être représenté comme un ensemble d'objets possédant des propriétés et des méthodes, et communiquant entre eux par échange de messages.
Il s'appuie en amont sur des méthodes de conception de SI orientées objet comme OMT (Object Modeling Technique) ou UML (Unified Modeling Language) ou OOM (Orientations Objet dans MERISE), etc. Ce modèle était encore peu utilisé sur le marché commercial mais est appelé à remplacer le modèle relationnel pour sa puissance et sa sémantique intuitive.
Exemples de SGBDO (Systèmes de Gestion de Bases de Données Objet) : O2 (IBM).
Le Modèle Logique de Données Relationnel (MLDR)
Ce modèle permet de constituer une base de données au sens logique au moyen de tables désignées aussi sous le terme de relations.
Les Concepts du MLDR
1) L'attribut : C'est le plus petit élément d'information enregistré dans une base de données. Il possède un nom et prend des valeurs dans un domaine de valeurs bien déterminé.
Exemples :
- Attribut : N° Client, Domaine de valeurs : Entier naturel
- Attribut : Adresse Client, Domaine de valeurs : Alphanumérique
- Attribut : Mode de paiement, Domaine de valeurs : Liste alphabétique (Espèces, Chèque, Traite)
2) La Relation : Une relation (appelée aussi table) est un ensemble d'attributs significativement associés, dont l'association a un sens au niveau du système d'information.
Représentation d'une relation :
- Représentation en intention (ou Schéma de la relation) :
R (A1, A2, A3, ..., An), où R est le nom de la relation et A1, A2, ..., An sont les attributs de la relation. - Représentation en extension (montrant les tuples de la relation) : Il s'agit d'une table avec des colonnes pour les attributs et des lignes pour les tuples (enregistrements). Chaque ligne représente une occurrence de la relation, avec des valeurs spécifiques pour chaque attribut.
Le Modèle Logique de Données Relationnel (Suite 1)
Une relation est un sous-ensemble du produit cartésien des domaines de valeurs associés à ses attributs. Cela signifie que chaque combinaison possible de valeurs d'attributs, si elle est significative, peut potentiellement exister dans la relation.
Exemple : Soient 2 attributs dont les domaines de valeurs sont :
- D1 (pour Nom) = (Ahmed, Brahim, Ali)
- D2 (pour Statut) = (Mineur, Majeur)
Le produit cartésien D1 x D2 représente toutes les combinaisons possibles. Une relation R pour (Nom, Statut) sera un sous-ensemble de ce produit, par exemple :
R (Nom, Statut)
- (Ahmed, Mineur)
- (Brahim, Majeur)
- (Ali, Mineur)
Cette relation R est un exemple de relation incluse dans D1 x D2. Toutes les relations qu'il est possible de créer à partir des attributs 'Nom' et 'Statut' sont incluses dans D1 x D2.
3) Les clés d'une relation :
Considérons 3 relations comportant certains attributs communs :
R1 (A1#, A2, A3, ..., An)R2 (B1#, B2, B3, ..., Bn, A1#)R3 (A1#, B1#, C1, C2, C3, ..., Cn)
Les attributs suivants jouent un rôle particulier :
- A1# dans R1 et B1# dans R2 sont appelés clés primaires : Chacun de ces attributs est choisi pour identifier de manière unique les enregistrements (tuples) de sa relation. Une clé primaire garantit l'unicité de chaque ligne de la table.
Le Modèle Logique de Données Relationnel (Suite 2)
- A2 est une clé candidate pour R1 : à condition que A2 soit un attribut discriminant (unique) pour les enregistrements (tuples) de R1, comme c'est le cas de A1#. Une clé candidate est un attribut ou un groupe d'attributs qui aurait pu servir de clé primaire mais qui n'a pas été retenu comme telle.
- A1# dans R2 est une clé étrangère : C'est un attribut (ou groupe d'attributs) d'une relation (R2) qui fait référence à une clé primaire (A1#) d'une autre relation (R1), établissant ainsi un lien entre elles. Elle assure la cohérence des données entre les tables.
- (A1#, B1#) dans R3 représente une clé primaire composée : C'est un groupe d'attributs définis chacun sur un domaine primaire. Les occurrences de ce groupe (couples de valeurs de A1# et B1#) sont utilisées pour identifier de manière unique les enregistrements (tuples) de la relation R3.
Remarques :
- Une clé primaire (simple ou composée) est toujours soulignée dans une relation dans la notation textuelle.
- Une clé étrangère est généralement indiquée par une notation spécifique (par exemple, suffixée par `*` ou un lien visuel dans un diagramme).
FAQ
Qu'est-ce que la méthode MERISE et à quoi sert-elle ?
R: MERISE est une méthode de conception de systèmes d'information qui vise à modéliser le fonctionnement d'une organisation en plusieurs étapes (conceptuelle, organisationnelle, logique, physique). Son objectif est de faciliter la conception et la réalisation d'applications informatiques en garantissant que le système développé corresponde aux besoins métiers et soit techniquement réalisable.
Quelle est la différence entre une entité et une association dans un MCD ?
R: Une entité représente un objet concret ou abstrait du monde réel (ex: un client, un produit) avec ses propres propriétés et un identifiant unique. Une association, quant à elle, représente un lien sémantique ou une interaction entre deux ou plusieurs entités (ex: un client passe une commande, un salarié travaille dans un service). L'association n'a pas d'existence indépendante des entités qu'elle relie.
Pourquoi les dépendances fonctionnelles sont-elles importantes dans la conception des bases de données ?
R: Les dépendances fonctionnelles sont fondamentales car elles décrivent les relations de détermination entre les attributs d'une relation. Leur analyse permet de décomposer les tables de manière appropriée (normalisation), d'éliminer la redondance des données, d'améliorer la cohérence et l'intégrité de la base de données, et d'optimiser les performances en évitant les anomalies de mise à jour, d'insertion ou de suppression.