Algèbre relationnelle - Guide pratique de conception d'une base de données relationnelle normalisée

Algèbre relationnelle  Guide de conception d'une base de données

Michelle CLOUSE  

Résumé Ce livre sur l’algèbre relationnelle et la conception d’une base de données est un guide pratique qui décrit différentes étapes, pas à pas et avec de nombreux exemples, de l’expression des besoins des utilisateurs à la conception d’une base de données relationnelle normalisée qui répond à leur demande. C’est un ouvrage qui peut être lu, compris et mis en pratique par tout public : débutant, étudiant en informatique mais aussi professionnel de l’informatique ou enseignant. Tout au long des chapitres, la base de données sera positionnée dans le Système d’Information puis les sujets suivants seront décrits et mis en pratique : le dictionnaire des données de l’entreprise, la Matrice des Dépendances Fonctionnelles, les modèles et plus particulièrement les modèles de données de la méthode Merise (dont le modèle Conceptuel de Données), les règles de passage de la Matrice des Dépendances Fonctionnelles au schéma entités-associations puis à la Base de Données Relationnelle, les concepts fondamentaux de l’algèbre relationnelle, les opérateurs de l’algèbre relationnelle pour répondre aux requêtes des utilisateurs, la normalisation des relations... Après la lecture de ce livre, le lecteur sera capable de modéliser conceptuellement une base de données relationnelle et d’interroger les données de cette base en utilisant les opérateurs de l’algèbre relationnelle. Le processus développé dans le livre peut être mis en pratique facilement et avec succès dans la vie professionnelle. Des compléments à cet ouvrage (arbres algébriques de l’étude de cas, exercices sur les formes normales, exercices d’utilisation d’opérateurs algébriques...) sont en téléchargement sur cette page.

L'auteur Michelle Clouse est chef de projet informatique à la Banque de France, responsable d'applications d'intelligence artificielle. Elle enseigne l'informatique au Conservatoire National des Arts et Métiers de Poitou-Charentes (processus d'informatisation, méthodologie, Génie Logiciel, initiation à la conception de bases de données). A travers ce livre, elle fait bénéficier le lecteur de son expertise du monde des bases de données.

Ce livre numérique a été conçu et est diffusé dans le respect des droits d’auteur. Toutes les marques citées ont été déposées par leur éditeur respectif. La loi du 11 Mars 1957 n’autorisant aux termes des alinéas 2 et 3 de l’article 41, d’une part, que les “copies ou reproductions strictement réservées à l’usage privé du copiste et non destinées à une utilisation collective”, et, d’autre part, que les analyses et les courtes citations dans un but d’exemple et d’illustration, “toute représentation ou reproduction intégrale, ou partielle, faite sans le consentement de l’auteur ou de ses ayants droit ou ayant cause, est illicite” (alinéa 1er de l’article 40). Cette représentation ou reproduction, par quelque procédé que ce soit, constituerait donc une contrefaçon sanctionnée par les articles 425 et suivants du Code Pénal. Copyright Editions ENI

© ENI Editions - All rigths reserved

- 1-

Introduction  "Aucune  investigation  humaine  ne  peut  s’intituler  véritable  science,  si  elle  ne  passe  pas  par  une  démonstration  mathématique."  Léonard De Vinci 

© ENI Editions - All rigths reserved

- 1-

Objectifs  Aujourd’hui, la base de données est devenue le support incontournable du Système d’Information d’une entreprise.  Pourquoi ?  Parce que la base de données répond aux objectifs de qualité de l’information, de sécurité, de facilité de gestion… pour  les  informaticiens ;  et  aussi,  parce  qu’elle  répond  aux  besoins  de  convivialité,  de  facilité  d’utilisation…  pour  les  non­ informaticiens. Or, toutes ces qualités sont les garants de la pérennité et de l’évolutivité du système d’information de  l’entreprise et de l’entreprise elle­même.  Les évolutions technologiques ont permis, au fil des années, de rendre ces systèmes de plus en plus performants et de  plus  en  plus  intuitifs  à  l’usage.  Ainsi,  aujourd’hui,  tout  employé  d’une  entreprise  utilise  au  moins  une  application  informatique reposant sur une base de données.  Les types de bases de données ont aussi évolué pour répondre même aux besoins les plus pointus des utilisateurs :  bases de données objet, datawarehouse…  Mais ces bases de données sont toutes des évolutions d’un seul type originel : la base de données relationnelle.  Ainsi,  nous  pouvons  affirmer  qu’un  seul  homme  est  à  l’origine  de  toutes  ces  bases  de  données  complexes  et  sophistiquées :  E.  F.  Codd.  Ce  mathématicien  de  formation  utilisa  ses  connaissances  mathématiques  pour  analyser  l’ensemble  des  données  que  constitue  une  base  de  données.  Il  l’étudia  en  se  basant  tout  particulièrement  sur  la  théorie  des  ensembles.  Cela  lui  permit  d’édicter  les  règles  que  doit  suivre  toute  base  de  données  pour  éviter  les  redondances de données et les anomalies de mise à jour liées, de construire les opérateurs de l’algèbre relationnelle  permettant de manipuler les données…  Ces règles ont été mises en application par les constructeurs de base de données et cela a été rapidement un succès.  Les  bases  de  données  relationnelles  sont  aujourd’hui  tellement  répandues  dans  les  entreprises  que  tout  le  monde  connaît ou croit connaître ce concept.  C’est  vrai  qu’une  des  qualités  des  Systèmes  de  Gestion  de  Bases  de  Données  Relationnelles  est  de  faciliter  la  manipulation  des  données  aux  utilisateurs.  C’est  aussi  un  fait  que  le  SQL  (Script  Query  Langage),  qui  repose  sur  les  opérations  de  l’algèbre relationnelle, est facilement assimilable et utilisable, par les utilisateurs pour répondre à une  majeure partie de leurs questions et, ceci, d’une manière transparente par rapport à l’organisation physique de la base  de données.  Mais  cette  apparente  simplicité  d’utilisation  cache  des  fondations  complexes  sur  lesquelles  doit  se  construire  toute  base de données pour être viable et efficace.  De  plus,  l’exactitude  et  l’exhaustivité  de  l’extraction  des  informations  d’une  base  de  données  relationnelle  ne  sont  assurées que si la demande de l’utilisateur (formulée en SQL ou sous forme d’opérations  d’algèbre relationnelle) est  déjà, par elle­même, exacte. Elle doit donc être bâtie avec les tables et les conditions de recherche idoines.  L’objectif  de  cet  ouvrage  est  de  répondre  à  ces  deux  problématiques,  en  vous  initiant  aux  fondements  de  l’algèbre  relationnelle.  En effet, ces connaissances permettront aux non­informaticiens de cerner et de mieux exprimer leurs demandes en les  visualisant  sous  la  forme  d’opérations  sur  des  relations  et  aux  informaticiens  de  concevoir  une  base  de  données  résistante, évolutive et optimale. 

© ENI Editions - All rigths reserved

- 1-

Plan de l’ouvrage  Pour atteindre ces objectifs, nous allons suivre un cheminement logique.  Pour ce faire nous suivrons les étapes suivantes :  ●

D’abord,  bien  définir  le  positionnement  de  la  base  de  données  dans  les  systèmes  d’information  et  informatiques. 

●

Puis,  à  partir  de  l’expression  des  besoins  des  utilisateurs,  nous  créerons  le  dictionnaire  des  données  de  l’entreprise. 

●

Celui­ci nous permettra de créer la Matrice des Dépendances Fonctionnelles, à partir de laquelle nous pourrons  définir les entités et les associations (ou relations) de la future base de données. 

●

Pour ce faire, nous ferons l’approche des différents modèles de la méthode Merise et nous mettrons en œ uvre  les modèles de données. 

●

Puis, nous vous proposerons une introduction à l’algèbre relationnelle et nous verrons comment passer de la  Matrice des Dépendances Fonctionnelles aux relations de l’algèbre relationnelle. 

●

Ensuite,  nous  verrons  comment  utiliser  les  opérateurs  de  l’algèbre  relationnelle  pour  répondre  aux  requêtes  des utilisateurs. 

●

Et  nous  finirons  sur  un  concept  très  important :  celui  de  la  normalisation,  garant  d’une  base  de  données  relationnelle optimale et viable. 

Chaque chapitre finira par une synthèse des notions découvertes et l’application de celles­ci à des exercices.  Le dernier chapitre vous fournira l’occasion de mettre en pratique vos connaissances dans une étude de cas.  Un glossaire, reprenant les principales définitions des concepts ou termes nouveaux utilisés, complétera le livre.  À l’issue de ce livre, il sera possible de modéliser conceptuellement une base de données relationnelle et d’interroger  les données de cette base en utilisant les opérateurs de l’algèbre relationnelle.  L’étape suivante, qui n’est pas incluse dans ce livre, est la création de la base physique et la consultation des données  via les deux sous­domaines du langage SQL (le Langage de Description des Données et le Langage de Manipulation  des Données). 

© ENI Editions - All rigths reserved

- 1-

Introduction  Avant  de  savoir  concevoir  et  interroger  une  base  de  données,  il  faut  avoir  conscience  de  son  importance  dans  le  système d’information d’une entreprise. Ainsi, il sera plus aisé de comprendre tout l’intérêt à bien la concevoir pour en  tirer le maximum lors de ses interrogations et donc, de son utilisation.  Nous allons préciser le positionnement de la base de données dans le Système d’Information (SI) d’une entreprise ou  d’une organisation.  Mais d’abord, pourquoi parle­t­on de Système d’Information ?  ●

Pour  répondre  à  cette  question,  nous  allons  d’abord  étudier  le  concept  de  "système",  qui  repose  sur  des  critères bien précis. 

●

Puis  nous  verrons  que  l’activité  d’une  entreprise  repose  sur  des  flux  d’informations  en  entrée  (coordonnées  clients, prix de la matière première…), intermédiaires (coût horaire, volume des déchets, coût du stockage…), en  sortie  (prix  de  vente,  coût  de  transport…).  Ces  informations  peuvent  être  utilisées  à  l’état  brut  ou  après  traitement. 

Ceci nous permettra de discerner la différence entre la notion de donnée et la notion d’information.  Nous pourrons enfin définir un système d’information et la place occupée par la base de données dans ce système. 

© ENI Editions - All rigths reserved

- 1-

Notion de Système d’Information  1. Définition d’un système   Le terme "système" est couramment utilisé. Dans presque tous les domaines (mathématiques, physique, astronomie,  physiologie, informatique, économie et finances…), il existe des systèmes :  ●

système d’équations, 

●

système métrique, 

●

système solaire, 

●

système digestif, 

●

écosystème, 

●

système d’exploitation, 

●

système bancaire… 

La liste est loin d’être exhaustive.  Mais  un  "système"  doit  posséder  des  propriétés  bien  précises.  Nous  allons  les  présenter  et  les  illustrer  avec  le  système respiratoire.  D’après Jean­Louis  Le  Moigne,  professeur  d’université  et  spécialiste  français  de  la  systémique,  le  système  est  défini  comme :  ●

Un ensemble d’éléments identifiables avec leurs attributs, 

Exemple  Les poumons, qui appartiennent au système respiratoire, sont parfaitement identifiables : ils ont une structure, une forme,  etc. bien particulières.  Les bronches se trouvent à l’intérieur des poumons et comportent les alvéoles pulmonaires à leurs extrémités.  ●

Qui a une activité ou une fonction, 

Exemple  Le système respiratoire a deux fonctions :  ●

fournir à toutes les cellules du corps du dioxygène (O2) appelé communément oxygène, 

●

éliminer du corps le dioxyde de carbone (CO2) issu du fonctionnement des cellules. 

●

Qui est doté d’une structure, 

Exemple  Le système respiratoire se compose des voies nasales, de la trachée, d’une paire de poumons, etc. avec une architecture  type que l’on retrouve chez tous les êtres humains (sauf pathologies).  ●

Qui évolue dans le temps, 

Exemple  La taille des poumons évolue de la naissance à l’âge adulte, leur aspect peut changer du fait de maladies… 

© ENI Editions - All rigths reserved

- 1-

●

Qui est inséré dans un environnement et qui a une frontière ; les éléments des autres systèmes pouvant être  affectés par ce système ou l’affecter eux­mêmes, 

Exemple  Le système cardiaque ne fait pas partie du système respiratoire.  Par  contre,  les  alvéoles  pulmonaires  recueillent  l’oxygène  et  rejettent  dans  les  bronches  le  dioxyde  de  carbone,  via  les  vaisseaux sanguins qui les parcourent. Les frontières entre le système respiratoire et le réseau sanguin sont les parois des  vaisseaux.  Ensuite, le cœur va propulser ce sang riche en oxygène via les artères.  ●

Qui a une finalité (c’est­à­dire des objectifs), 

Exemple  La finalité du système respiratoire est de contribuer au bon fonctionnement du corps humain.  Il faut aussi ajouter (d’après La théorie générale des systèmes de Ludwig Von Bertalanffy 1954) :  ●

Le concept de totalité, 

Un système est composé de nombreux éléments mais il constitue un tout, et non la somme des parties.  Ce  n’est  pas  parce  vous  avez  réuni  tous  les  éléments  d’un  système  que  celui­ci  fonctionnera.  Il  faut  aussi  que  les  inter­relations existent, que le système puisse assurer ses fonctions...  Exemple  Un verre est un tout.  Si vous brisez ce verre et que vous ramassez tous les morceaux, vous ne tiendrez plus un verre dans la main : sa principale  fonction n’est plus assurée, vous ne pouvez plus boire avec.  ●

Un réseau d’informations et de communications, 

Il n’y a pas de système sans réseau de transport de matières, d’énergies, d’informations…  Exemple  Le système respiratoire ne serait d’aucune utilité s’il n’y avait pas le réseau des "voies aériennes" (trachée, bronches…) pour  transporter l’oxygène et le dioxyde de carbone.  ●

Des entrées (input) et des sorties (output).  

Exemple  Le système respiratoire a, entre autres :  ●

O2 en entrée, 

●

CO2 en sortie. 

De plus, un système peut être dit :  ●

Fermé, s’il a un nombre fini d’états et que les événements extérieurs n’ont aucun impact sur lui, 

●

Ouvert, s’il sait ou peut s’adapter aux influences externes et comporte donc, dans la théorie, un nombre infini  d’états. 

Exemple  Le système respiratoire est un système ouvert.  Il peut s’adapter aux événements extérieurs. Si au niveau de la séparation des voies respiratoires et des voies digestives,  un aliment fait une fausse route, le système respiratoire va essayer de le rejeter via la toux. 

- 2-

© ENI Editions - All rigths reserved

2. Précisions sur les concepts de donnée et d’information  Donnée et Information sont deux termes simples mais dont il faut bien connaître la signification et les différences.  ●

Une donnée est statique. Elle peut être temporaire ou permanente. Elle rentre dans un programme, subit des  traitements, participe à des traitements et est conservée ou détruite après traitement. 

Exemples :  Le nom d’un client : CLOUSE est une donnée.  Les N° de facture, N° de commande sont des données.  ●

Une  information  est dynamique. Elle peut être traitée mais aussi induire des actions. L’information  n’est pas  neutre, elle est porteuse de sens, elle sert à prendre des décisions. 

Exemple 1 :  Le nom du client, le N° de commande et le montant total représentent une information. Cette information est constituée de  deux données brutes (N° de commande et nom du client) et d’une donnée issue de traitement (somme des montants de  chacune  des  lignes  de  la  commande).  Cette  information  peut  induire  une  action :  par  exemple,  obtenir  de  la  part  du  fournisseur, un rabais proportionnel au montant de la commande.  Ceci est un exemple de décision opérationnelle : elle est à court terme, basée sur une ou des informations précises,  s’appuyant sur des règles ou procédures connues.  Exemple 2 :  Tous  les  mois,  le  constructeur  automobile  X  réalise  les  statistiques  des  ventes  de  voitures  neuves  de  tous  ses  concessionnaires et les compare d’un mois sur l’autre et d’une année sur l’autre. Ce traitement va être effectué à partir des  données  et  des  informations  fournies  par  chacun  de  ses  concessionnaires.  S’il  s’avère  qu’il  y  a  une  chute  continue  des  ventes, la direction va peut­être décider de faire une campagne de ventes promotionnelles pour relancer le marché.  Ceci  est  un  exemple  de  décision  stratégique :  elle  est  à  long  terme,  elle  repose  sur  le  traitement  d’un  volume  important  d’informations  et  sur  un  raisonnement  qui  ne  se  base  pas  toujours  sur  des  règles  ou  procédures  bien  précises et il y a un fort degré d’incertitude sur le résultat final de cette décision.  Une information est un ensemble de données (au minimum une), brutes et/ou résultantes de traitements.  L’information  circule  dans  l’entreprise.  Dans  le  premier  exemple  précédent,  la  saisie  de  la  commande  et  l’offre  de  rabais peuvent ne pas être réalisées par la même personne.  L’information va évoluer dans son environnement car elle doit aussi répondre à certains critères de qualité pour que  la décision, qui en est issue, repose sur des bases solides.  Ces critères peuvent être résumés dans la figure suivante : 

© ENI Editions - All rigths reserved

- 3-

  Examinons chaque terme :  PRÉCISION : la valeur de l’information ne doit pas être de l’à peu près. Elle doit être précise.  Exemple :  Le médecin va considérer différemment un malade qui a de la fièvre avec 38° et un malade qui a de la fièvre avec 40°.  PONCTUALITÉ : l’information doit arriver au moment où il faut. Si une information est attendue toutes les semaines, à  une heure précise, elle doit être disponible à cette heure­là. En effet, de cette information et des décisions prises peut  dépendre toute une chaîne d’activités.  Exemple :  Les prévisions météorologiques de la veille au soir indiquent aux marins s’ils peuvent faire une sortie de pêche ou si c’est  trop dangereux. Si cette information est manquante et qu’elle arrive après le départ en mer des pêcheurs, s’il y a risque de  tempête, c’est trop tard.  LISIBILITÉ : l’information doit être claire et compréhensible par la personne qui l’utilise.  Exemple :  Une  infirmière  ou  un  médecin  français  lira  et  comprendra  rapidement  une  température  d’un  malade  indiquée  en  degré  Celsius plutôt qu’en Fahrenheit.  ACCESSIBILITÉ : l’information doit être facile d’accès. 

- 4-

© ENI Editions - All rigths reserved

Exemple :  Les tableaux de bord des managers sont constitués d’informations générales mais primordiales pour la prise de décision. Ces  informations sont visibles rapidement, sans trop de manipulations du décideur et aussi souvent qu’il le veut.  FIABILITÉ : l’information servant à prendre une décision doit être fiable.  Exemple :  Le  chirurgien  opère  de  la  vésicule  biliaire  sur  la  base  de  résultats  sanguins  et  d’échographie.  Il  ne  met  pas  en  doute  les  résultats.  EXHAUSTIVITÉ  :  l’information  doit  être  exhaustive,  elle  doit  contenir  toutes  les  données  permettant  une  prise  de  décision.  Exemple :  Un  bilan  sanguin  ne  va  pas  suffire  à  un  médecin  pour  faire  un  diagnostic,  il  va  le  compléter  par  d’autres  examens  (radiographie, échographie…).  ACTUALITÉ : l’information doit être la plus récente possible.  Exemple :  Un médecin va vous donner un traitement d’après vos symptômes et votre fièvre d’aujourd’hui, il ne va pas tenir compte  des symptômes d’une autre maladie que vous auriez eue, il y a un mois. 

3. Le système d’information  L’activité  d’une  entreprise  ou  d’une  organisation  repose  sur  un  ensemble  de  données  qui  vont  être  mémorisées,  transformées quotidiennement pour constituer "un recueil d’informations" (documents, tableaux de bord, graphiques,  photos…).  Si nous examinons l’architecture et la gestion de ces "recueils d’informations", nous nous apercevons qu’ils présentent  les caractéristiques d’un système et qu’ils sont dotés de fonctionnalités ou qu’ils sont basés sur des technologies leur  permettant de fournir une information de qualité, d’où l’appellation plus appropriée de Système d’Information(SI).  En effet, généralement, les Systèmes d’Information sont constitués de ressources matérielles, logicielles ou humaines  permettant d’acquérir,  de  stocker,  de  traiter  ou  de  communiquer  les  données  qui  vont  représenter  des  informations  pour les utilisateurs.  Le périmètre du Système d’Information délimite les informations nécessaires à l’activité de l’entreprise. Ce périmètre  peut  être  localisé  à  l‘implantation  géographique  de  l’entreprise  ou  peut  être  plus  vaste  tout  en  étant  clos  (par  exemple : les réseaux extranet).  Exemple :  Dans une entreprise de fabrication de produits manufacturés, le SI englobera la nomenclature des articles, les schémas de  fabrication….  Dans une entreprise de Vente Par Correspondance, le SI englobera le fichier des clients, le catalogue des produits, les bons  de commande, les bordereaux de livraisons…  À  l’extérieur  de  l’entreprise, ces informations n’ont  pas  de  signification.  Par  contre,  à  l’intérieur  de  l’entreprise, sous  l’action de flux internes et externes, les différents éléments constitutifs du SI vont interagir et les informations vont  évoluer.  Exemple :  Flux  externes :  informations  provenant  de  la  veille  concurrentielle  ou  de  la  veille  économique,  prix  d’achat  des  matières  premières, quantités commandées par le client, quantités retournées par le client, modification du taux de TVA…  Flux internes : décisions stratégiques des dirigeants (offres promotionnelles...), modification de processus de fabrication…  Mais comment est assurée cette qualité de l’information ? 

© ENI Editions - All rigths reserved

- 5-

Positionnement de la base de données dans le Système d’Information  Avoir un Système d’Information pertinent, performant, évolutif et fiable passe obligatoirement par la réalisation d’un bon  Système Informatique. Le Système Informatique est le "squelette" technique du Système d’Information.  Le  Système  Informatique  est  constitué  de  deux  composants  principaux :  du  matériel  (serveurs,  stations  clientes,  réseau)  et  des  logiciels  (système  d’exploitation,  gestionnaires  de  fichiers  ou  de  bases  de  données,  applications  métiers). Nous ne détaillerons pas le concept de Système Informatique qui repose sur des éléments techniques qui ne  sont pas le sujet de ce livre. Aussi, dans la suite de ce livre, quand nous parlerons de SI, cela concernera toujours le  Système d’Information.  Nous noterons toutefois que  la  qualité  de  l’information du SI sera assurée par la mémorisation et le traitement des  données via une base de données et plus précisément par la mise en  œ uvre d’un Système  de  Gestion  de  Bases  de  Données Relationnelles (SGBDR) : Oracle, DB2 d’IBM…  En  effet,  le  SGBDR  est  constitué  principalement  de  la  base  de  données  mais  aussi  d’autres  éléments  logiques  et  physiques qui permettent :  ●

d’administrer et de maintenir la base de données dans un état cohérent 

●

d’assurer :  ●

l’indépendance  physique  (la  structure  physique  de  stockage  est  transparente  pour  les  utilisateurs  et  n’intervient pas sur la façon d’accéder aux données), 

●

l’indépendance logique (chaque application de l’entreprise ne sera en contact qu’avec les données de la  base dont elle a besoin), 

●

la  manipulation  aisée  des  données  par  des  non­informaticiens,  via  le  Langage  de  Manipulation  des  Données (LMD), 

●

l’efficacité  des  accès  aux  données  (le  Langage  de  Manipulation  des  Données  est  riche  et  permet  de  sélectionner d’une manière précise ce que l’on cherche), 

●

l’administration  centralisée  des  données  par  l’Administrateur  de  la  Base  de  Données  (DBA :  DataBase  Administrator) via des outils inclus dans l’architecture du SGBDR, 

●

la non­redondance  des  données  (la  base  de  données  centralise  physiquement  toutes  les  données  de  l’entreprise, il ne peut y avoir mémorisation d’une donnée déjà contenue dans la base, ailleurs), 

●

le partage des données (partage dans le temps mais aussi simultanément via le concept de verrouillage  logique des données), 

●

la  sécurité  des  données  (confidentialité  d’accès  aux  données,  récupération  des  données  en  cas  d’incident…). 

Nous constatons donc, que les SGBDR répondent aux exigences des utilisateurs du SI et que la base de données est la  clé de voûte d’un bon Système d’Information.  Mais malgré la puissance des outils du SGBDR et du langage SQL, les objectifs précédents ne seront atteints que si et  seulement si :  ●

la modélisation de la base de données est correcte 

●

et les relations, qui en sont issues, sont normalisées. 

De  plus,  la  connaissance  des  bases  de  l’algèbre  relationnelle  (à  l’origine  de  l’invention  des  bases  de  données  relationnelles) est le complément indispensable pour le créateur des requêtes de consultation de la base finale.  C’est ce que nous allons appréhender dans les chapitres suivants. 

© ENI Editions - All rigths reserved

- 1-

Synthèse  Ce  chapitre  a  permis  de  faire  la  distinction  entre  les  concepts  de  donnée  et  d’information  et  d’appréhender  la  complexité des systèmes sur lesquels repose l’activité de toute entreprise ou organisation : le Système d’Information  et le Système Informatique.  Le Système d’Information est fondamental car :  ●

Il traite des flux d’informations souvent volumineux entrants et sortants, 

●

Il stocke les informations, 

●

Il rend accessible les informations à tout moment et à tout le monde, 

●

Il est le garant de la qualité des informations, 

●

Et, de ce fait, il sera partie prenante des prises de décisions qu’elles soient stratégiques ou opérationnelles. 

Les qualités du Système d’Information reposeront en grande partie sur sa base de données et plus particulièrement  sur sa modélisation et l’architecture qui en sera issue (tables, index…).  La qualité de la modélisation d’une base de données reposera sur la connaissance et la mise en  œ uvre de l’algèbre  relationnelle. 

© ENI Editions - All rigths reserved

- 1-

Exercice  1. Énoncé  L’entreprise est­elle un système ? 

2. Solution  Nous pouvons dire que :  ●

Une  entreprise  est  parfaitement  identifiable  au  sein  de  l’ensemble  des  autres  systèmes  qui  l’entourent  (économie mondiale, système financier international…). 

●

Ses  éléments  constitutifs  sont  aussi  identifiables (le  service  commercial,  la  Direction  des  Ressources  Humaines, le service financier…). 

●

Elle  a  une  activité  ou  une  fonction  (industrie  de  processus,  commerce,  grande  distribution,  Vente  Par  Correspondance…). 

●

Elle est dotée d’une structure (organigramme : PDG, Directeurs...). 

●

L’entreprise  est  un  système  vivant, et  donc,  évolue  dans  le  temps.  Elle  naît,  se  développe  et  s’adapte  à  l’environnement économique (faillite, fusion, fermeture définitive, implantations internationales, élargissement  des activités...). 

●

La délimitation d’une entreprise dans son environnement est parfaitement identifiable. 

●

Les  frontières  de  l’entreprise  permettent  de  filtrer  ce  qui  constitue  des  événements  pertinents  pour  l’entreprise. 

●

L’entreprise a pour finalité première : celle de rentabiliser son action. 

Donc, l’entreprise est un système.  De plus, c’est un système ouvert car elle subit les lois du marché et s’y adapte pour poursuivre son développement. 

© ENI Editions - All rigths reserved

- 1-

Introduction  Pour  bien  concevoir  la  base  de  données  d’un  Système  d’Information,  il  faut  avoir  écouté  et  compris  les  besoins  des  futurs utilisateurs.  L’expression  claire,  nette  et  exhaustive  des  besoins  par  la  Maîtrise  d’OuvrAge  (MOA,  cf.  glossaire)  ainsi  que  leur  compréhension  et  leur  prise  en  compte  par  la  Maîtrise  d’OEuvre  (MOE,  cf.  glossaire)  sont  un  des  facteurs  clés  de  réussite d’un projet informatique.  En  effet,  la  bonne  compréhension  de  tous  les  besoins  des  utilisateurs  va  permettre  de  circonscrire  exactement  le  domaine et les informations qui seront gérées, mais aussi celles qui transiteront, dans le futur système d’information.  À partir de la connaissance de ces informations, il sera possible de recenser exhaustivement les données à gérer et de  les structurer.  La  phase  de  structuration  inclura la  recherche  des  liens existants  entre  ces  données.  Ces  liens  sont  appelés  des  Dépendances  Fonctionnelles  dont  la  recherche  sera  facilitée  par  l’utilisation  de  Matrice  des  Dépendances  Fonctionnelles.  Ce  chapitre  va  présenter  ces  différentes  étapes  dont  le  résultat  est  d’une  grande  importance  pour  la  qualité  de  la  future  base  de  données  et  tout  particulièrement  pour  répondre  au  critère  d’exhaustivité,  vu  dans  le  chapitre  précédent. 

© ENI Editions - All rigths reserved

- 1-

Analyse des besoins des utilisateurs  1. Généralités  L’expression  besoins  des  utilisateurs  représente  les  attentes  des  utilisateurs  en  termes  de  fonctionnalités,  traitements et informations gérés par le futur Système d’Information.  En  effet,  les  informations  gérées  seront  structurées  et  implantées  dans  une  base  de  données  et  les  traitements  seront appliqués via les applications informatiques qui existeront dans le futur SI.  L’étude des besoins portera sur les domaines fonctionnels, organisationnels, ergonomiques et aussi de sécurité.  Ces  attentes  sont  présentées  dans  un  document  que  l’on appelle  cahier  des  charges.  Elles  représentent  le  QUOI  (que doit­faire le futur SI).  À  ce  stade,  aucune  information  n’est  donnée  ou  connue  sur  le  COMMENT  du  futur  système  (technologie,  organisation…). 

Exemple  Les utilisateurs vous indiqueront qu’ils souhaitent saisir et enregistrer les commandes reçues par courrier, que l’opérateur  doit être immédiatement averti si un article est indisponible… : c’est le QUOI.  Mais, l’outil (le COMMENT) avec lequel ils travailleront n’est pas encore défini à ce stade.  Le cahier des charges précise :  ●

les volumes d’informations à traiter ; 

●

les services et résultats attendus ; 

●

les contraintes organisationnelles, matérielles, budgétaires, temporelles, juri­ diques dont il faut tenir compte ; 

●

les orientations privilégiées (solution logicielle ou progicielle). 

Il se base généralement sur une étude de l’existant qu’il soit informatisé ou non et décrit la solution cible, en tenant  compte des évolutions prévisibles des données à traiter (volume, structure…).  Le  cahier  des  charges  est  contractuel.  Cela  signifie  qu’à  partir  du  moment  où  la  MOE  interne  ou  externe  (sous­ traitance,  achat  de  progiciel…)  accepte  le  cahier  des  charges,  elle  s’engage  à  répondre  aux  besoins  exprimés.  En  particulier, dans le cas d’une sous­traitance, le cahier des charges est une annexe visée dans le contrat.  Dans le contexte de ce livre, nous étudierons les données plutôt que les traitements, car c’est ce qui nous intéresse le  plus pour construire la base de données. Mais, dans tout développement de Système d’Information, il faudra toujours  avoir à l’esprit que les données et les traitements sont étroitement liés et que toute modification de l’un peut avoir  un impact sur l’autre. Ce principe est d’ailleurs repris dans les méthodes de développement de projet qu’elles soient  Objet (Unified Modeling Language (UML)…) ou non (Merise…).  Comment va se faire le recensement des besoins des utilisateurs et en particulier des données ? 

2. Recensement des données utilisateurs  Cette  étape  repose  pour  une  large  part  sur  des  interviews,  des  audits  d’utilisateurs.  L’étude  se  fait  d’abord  sur  l’existant, pour acquérir la connaissance du sujet et recenser :  ●

les informations et leur circulation ; 

●

les acteurs ; 

●

les traitements actuels automatisés ou non, et leur chronologie… 

Puis,  l’étude  portera  sur  le  système  cible ;  cela  permettra  de  préciser  les  éléments  (informations,  fonctionnalités)  devenus inutiles et ceux à ajouter, dont aura besoin le futur système.  © ENI Editions - All rigths reserved

- 1-

Les  informations  retenues  seront  de  toute  nature  et  sur  tout  support  :  fichiers  informatiques,  mails,  fax,  fiches,  lettres…  L’informaticien  va  lister  et  définir  précisément  les  informations  entrantes,  sortantes  et  celles  que  l’on  peut  appeler  référentielles  (internes  et  dont  l’organisation  a  besoin  pour  fonctionner).  Il  modélisera  la  circulation  (avec  les  plus­ values recueillies) des informations dans l’organisation.  Exemple  Considérons une entreprise de Vente Par Correspondance :  ●

Informations  entrantes :  Bons  de  commande  avec  N°  de  client,  N°  article,  quantité  commandée,  règlements  (chèques, bons cadeau…), adresse de livraison… 

●

Plus­ value : le bon de commande va être traité et complété d’informations (articles en suspens, épuisé…)… 

●

Informations  sortantes :  Bons  de  livraison  avec  date  de  livraison,  nombre  de  colis,  poids  du  (ou  des)  colis…,  factures avec Numéro de client, TVA, montant total… 

●

Référentiel :  Les  clients  identifiés  par  leur  numéro,  nom,  prénom(s),  adresse…Les  articles  identifiés  par  leur  référence, coloris, poids, dimensions… 

Les informations sont des données structurées. L’informaticien va ainsi se constituer une liste de données exhaustive. 

- 2-

© ENI Editions - All rigths reserved

Dictionnaire des données  1. Analyse du recueil de données  L’informaticien va travailler la liste des données précédentes pour créer un recueil de données pertinentes, avec une  structure dédiée à leur usage futur.  Pour ce faire :  ●

Il éliminera les données redondantes directes ou indirectes. 

Ces  données,  qui  peuvent  ne  pas  avoir  la  même  dénomination  dans  la  vie  réelle,  ont  le  même  sens  dans  le  Système d’Information étudié, soit directement soit via un traitement.  Dans chacun des cas, il faudra définir la donnée la plus pertinente à conserver (la plus stable dans le temps, la plus  utilisée dans les traitements applicatifs…).  Exemple 1  Supposons que l’informaticien ait recensé deux données qui semblent différentes :  ●

Le  code  client :  intitulé  d’une  zone  que  l’on  retrouve  sur  certains  documents  internes :  listing  des  clients  à  relancer, listing des clients qui n’ont pas commandé depuis 6 mois… 

●

Le numéro de client qui identifie le client et qui est reporté systématiquement sur tous les mailings et bons de  commande qu’il reçoit. 

Il doit les examiner : ont­elles le même format ? Pour un même client, le code est­il identique au numéro de client ? Est­ce  que deux clients peuvent avoir le même code client mais en ayant des numéros de clients différents ?...  Les réponses à ces questions permettront d’affirmer ou non que ces deux données sont synonymes.  Si oui, il faudra donc en éliminer une.  Exemple 2  Considérons la gestion des employés d’une entreprise.  Nous connaissons la règle de gestion suivante : Tout nouvel embauché passe par une période d’essai de 6 mois. Donc, sa  date  de  titularisation  peut  être  calculée  à  partir  de  sa  date  d’embauche  en  y  ajoutant  6  mois  et  vice­versa  en  retranchant  6 mois  à  la  date  de  titularisation.  Ces  deux  dates  sont  en  redondance  indirecte,  connaissant  la  durée  de  la  période d’essai, il n’est pas nécessaire de conserver les deux dates puisque déductibles l’une de l’autre.  Entre les deux dates, ce sera celle susceptible d’être utilisée dans le plus grand nombre de traitements, qui sera conservée.  En effet, cela induira moins de calculs à faire.  ●

Il distinguera les données homonymes. 

Ces données ont le même libellé mais peuvent ne pas avoir le même sens dans le Système d’Information. Il faut en  renommer une (ou plusieurs) pour retrouver les 2 ou n données avec leur sémantique originelle.  Exemple  La donnée ville est indispensable dans toute adresse.  Mais, par exemple si vous faites une commande pour faire un cadeau, la ville de livraison (adresse de votre ami) a de fortes  chances d’être différente de la ville de facturation (votre adresse personnelle).  Aussi, dans le SI de cette gestion commerciale, cette donnée ville va générer deux données distinctes : ville de livraison  et ville de facturation.  ●

Il veillera à se constituer un recueil de données élémentaires et plus particulièrement atomiques. C’est­à­dire  que la donnée doit être décomposée le plus finement possible tout en gardant un sens. 

Exemple 1  Considérons le numéro de téléphone d’un client en France.  Il sera constitué de 10 chiffres. Mais, en France, ce numéro est plus généralement décliné en 5 nombres de 2 chiffres. 

© ENI Editions - All rigths reserved

- 1-

L’informaticien pourrait être tenté de faire le découpage en données suivantes : nombre 1, nombre 2, nombre 3, nombre 4  et  nombre  5  du  numéro  de  téléphone  client.  Le  nombre  1  indique  la  zone  géographique  téléphonique  mais  celle­ci  est  beaucoup moins précise que le code postal ou le lieu d’habitation. Elle ne peut donc être utilisée individuellement que si des  traitements utilisent la notion de zone téléphonique. Si non, elle n’est pas nécessaire en tant que telle.  Pour les autres séries de 2 chiffres (nombres 2, 3, 4 et 5), chacune de celles­ci en tant que telle ne veut rien dire et ne  pourra être utilisée isolée dans le futur SI.  Donc, généralement, le numéro de téléphone entier est conservé en tant que donnée élémentaire.  Exemple 2  Considérons l’adresse d’un client en France.  La  Poste  a  normalisé  l’adresse  en  France  et  l’a  structurée  en  6  lignes.  La  6ème  ligne  doit  contenir  le  code  postal  et  la  dénomination de la localité de destination.  Dans son recueil de données, l’informaticien ne doit pas considérer la ligne 6 comme une donnée atomique. En effet, le code  postal et la localité de destination n’ont pas le même poids. Le code postal permet de retrouver les localités de destination  possibles  (un  même  code  postal  peut  être  attribué  à  plusieurs  villages  différents)  mais  surtout  précise  un  élément  supplémentaire : le département.  Ces deux données sont complémentaires et peuvent avoir un usage différent dans le SI.  Il se peut que certains des futurs traitements du SI portent sur le département (par exemple, la connaissance d’un Chiffre  d’Affaires par département) ou sur la localité (par exemple, l’optimisation  quotidienne  d’un itinéraire de livraison dans une  grande ville).  ●

Il veillera à ce que toute information soit liée à un objet du monde réel (que l’on appellera entité) dont chaque  occurrence (chaque représentation concrète) puisse être déterminée d’une manière unique. 

Cela induit l’existence pour chaque objet, d’une propriété particulière qui aura ce rôle et que l’on appelle identifiant.  Cet identifiant prendra une valeur différente qui ne sera pas réutilisable pour chacune des occurrences.  Exemple  Les données suivantes : nom du client, prénom du client, adresse du client représentent les caractéristiques d’un client. Par  contre, elles ne sont pas suffisantes pour déterminer d’une manière unique un client.  En effet :  ●

Combien y­a­t­il de Durand en France ? 

●

Combien connaissez­vous de Michelle ? 

L’immeuble sis 13, Ter Rue Aristide Briand va abriter plusieurs familles, qui ne sont pas toutes clientes de notre entreprise.  Aussi,  la  donnée  supplémentaire  code  client  décrite  comme  identifiant  va  permettre  de  distinguer  Michelle  Durand  de  Marseille (code client 00234) de Jacques Durand de Lyon (00436).  ●

Il distinguera les entités qui seront susceptibles d’être fréquemment l’objet de recherches. Pour optimiser ces  futures  recherches,  il  pourra  créer  des  entités  paramètres supplémentaires  (mais  bien  entendu  logiques  et  pertinentes). 

Exemple  Considérons un catalogue d’une entreprise de Vente Par Correspondance.  Le catalogue est classé par grands chapitres : mobilier, électroménager, habillement… pour faciliter la recherche.  ●

●

Une entité paramètre ‘type de produit’ :  ●

Code type de produit (M, E, H…) 

●

Libellé type de produit (Mobilier, Electroménager, Habillement…). 

Une entité ‘produit’ :  ●

- 2-

Code produit (XXXXX....) 

© ENI Editions - All rigths reserved

●

Dénomination (Pull col roulé....) 

●

... 

●

Code type de produit (donnée faisant référence à la table paramètre)   

Nous constatons que le code identifiant de l’entité paramètre est ajouté aux données caractérisant l’objet.

Les  avantages  des  entités  paramètres  seront  perçus  lors  de  la  création  de  la  base  de  données  relationnelle,  mais  aussi lors de l’optimisation de l’accès aux données, quand la base de données sera implémentée physiquement. 

2. Dictionnaire de données  Le  recueil  de  données  finalisé  est  appelé  dictionnaire  de  données  du  Système  d’Information  cible.  Chaque  donnée  recensée reçoit un numéro, qui facilitera son utilisation ultérieure.  Ce dictionnaire de données va se présenter sous forme d’un tableau dont chaque ligne représentera une donnée et  chaque colonne, une caractéristique de la donnée.  Les caractéristiques utiles sont les suivantes :  ●

Numéro de la donnée, 

●

Nom interne de la donnée dans le SI (code mnémonique utilisé dans les développements informatiques), 

●

Libellé (explicatif), 

●

Type (alphanumérique, numérique, booléen…), 

●

Format (nombre maximum de caractères qui la composent), 

●

Catégorie (est­ce un identifiant (I) ou une simple propriété (S comme signalétique) ?). 

Exemple  Reprenons l’exemple du client du SI d’une entreprise. Nous le complétons avec les factures liées à ses achats.  Nous savons que chaque client a fait, au moins un achat.  De  plus,  les  données  recensées  sont  les  suivantes :  code  client  en  tant  qu’identifiant,  nom,  prénom,  une  adresse  de  facturation  composée  d’une  adresse­ligne1,  d’une  adresse­ligne2,  d’une  adresse­ligne3,  d’une  adresse­ligne4,  d’une  adresse­ligne5, du code postal et du code commune INSEE de la localité de destination (un code commune INSEE détermine  une et une seule commune), de la localité de destination, un numéro de facture en tant qu’identifiant de la facture (chaque  facture est identifiée par son numéro et toutes les factures ont des numéros différents), le montant HT de la facture, le  montant TTC et le taux de TVA à appliquer (19.6, 5.5...).  Ces  données  ne  seront  pas  les  seules  recensées  pour  le  futur  SI ;  aussi,  le  tableau  contiendra  des  points  de  suspension  représentant les autres données. 

© ENI Editions - All rigths reserved

- 3-

 

- 4-

© ENI Editions - All rigths reserved

Matrice des Dépendances Fonctionnelles  L’analyse  a  permis  de  construire  le  dictionnaire  des  données  exhaustives,  il  va  falloir  maintenant  rechercher  les  liens  éventuels entre ces données. Pour ce faire, l’analyste va s’aider de la matrice des dépendances fonctionnelles qu’il va  construire en suivant des étapes progressives. 

1. Dépendance fonctionnelle  Dans le dictionnaire des données, un certain nombre de données a été défini. Chaque donnée appartient à une entité  identifiable dans le monde réel.  De plus, il existe des liens particuliers entre données d’une même entité : la dépendance fonctionnelle (DF).  Deux données A et B sont en dépendance fonctionnelle, si la connaissance de la valeur de A permet d’identifier  une et une seule valeur de B.  Cet axiome doit être vrai pour toutes les valeurs de A.  La première donnée est dite donnée source.  La seconde donnée est dite donnée cible.  Leur modélisation est la suivante : Source → Cible.    Les propriétés identifiantes sont généralement source de Dépendance Fonctionnelle.

Exemple  Reprenons l’exemple du client de l’entreprise précédente et considérons les données 35 et 36.  Le  code  client  est  un  identifiant,  donc  la  connaissance  d’une  de  ses  valeurs  permet  de  déterminer  de  manière  unique un  client.  Donc  si  je  connais  une  valeur  de  COCLI,  par  exemple  05786,  il  lui  sera  associé un  seul  nom  client,  par  exemple :  Brigand.  Nous avons bien une dépendance fonctionnelle entre code client et nom client.  COCLI → NOMCLI.  Au contraire, si à un code client, nous avions pu associer plusieurs noms clients, c’est qu’il n’y aurait pas eu de dépendances  fonctionnelles entre COCLI et NOMCLI. 

2. Étape 1  L’analyste  va  étudier  chaque  donnée  et  chercher  les  dépendances  fonctionnelles  dont  elle  serait  source  ou  cible.  Toutes ces dépendances fonctionnelles vont être répertoriées dans une Matrice des Dépendances Fonctionnelles (MDF).  Dans cette matrice :  ●

Les en­têtes de colonne représentent les sources de Dépendance Fonctionnelle (DF) ; 

●

Les en­têtes de ligne représentent les cibles de DF. 

  Exemple 

© ENI Editions - All rigths reserved

- 1-

Reprenons l’exemple du client du SI d’une entreprise.  Le dictionnaire de données permet de construire le squelette de la Matrice des Dépendances Fonctionnelles suivante : 

  Pourquoi avons­nous toutes les données en tant que tête de colonne ?  Au stade de notre étude, toutes les données sont susceptibles d’être source de DF.  Le  premier  complément  à  apporter  à  cette  matrice  est  dû  au  fait  que  chaque  donnée  est  source  d’une dépendance  fonctionnelle vers elle­même.  Exemple  La connaissance d’un code postal détermine une et une seule valeur de code postal.  Cette notion de réflexivité de la dépendance fonctionnelle va être représentée par une  , neutralisant dans la matrice  l’intersection de la ligne et de la colonne de même numéro.  Exemple 

- 2-

© ENI Editions - All rigths reserved

 

3. Étape 2  Puis, il faut étudier chaque donnée source.  Il  faut  se  poser  la  question  suivante :  "pour  une  valeur  précise  de  la  donnée  source,  peut­on  identifier  une  et  une  seule valeur d’une ou de plusieurs données cibles ?".  Pour chaque donnée cible qui répond OUI à cette question, il faudra écrire ‘1’ dans la cellule intersection de la donnée  source et de cette donnée.  Exemple  Reprenons l’exemple du client du SI de notre entreprise.    La 1ère donnée source à étudier est la 35 : Code client qui est la donnée identifiant du client. Sa fonction d’identifiant permet de dire qu’une valeur du code client (COCLI) définit :  ●

Une et une seule valeur pour le nom du client 

●

Une et une seule valeur pour le premier prénom du client 

●

Une et une seule valeur pour la ligne 1 de l’adresse de facturation du client 

●

Une et une seule valeur pour la ligne 2 de l’adresse de facturation du client 

●

Une et une seule valeur pour la ligne 3 de l’adresse de facturation du client 

●

Une et une seule valeur pour la ligne 4 de l’adresse de facturation du client 

●

Une et une seule valeur pour la ligne 5 de l’adresse de facturation du client  © ENI Editions - All rigths reserved

- 3-

●

Une et une seule valeur pour le code postal de facturation 

●

Une et une seule valeur pour la ville de facturation. 

●

Une et une seule valeur pour le code commune INSEE. 

Par  contre,  la  connaissance  du  code  client  ne  permet  pas  de  définir  d’une  manière  unique  un  numéro  de  facture.  Un  client  (et  particulièrement  si  c’est  un  bon  client,  nous  l’espérons !)  va  recevoir  au  moins  une  facture,  voire  plusieurs. Ainsi, à un client pourront être associés n numéro(s) de facture (n ≥ 1).  Donc, le numéro de facture n’est pas en dépendance fonctionnelle avec le code client.  Pour les mêmes raisons, le montant hors taxes de la facture, le montant TTC et le taux de TVA à appliquer ne sont pas en  dépendance fonctionnelle du code client.  Nous allons donc compléter la matrice de la manière suivante : 

  La  2ème  donnée  source  à  étudier  est  la  36 :  Nom  du  client  (NOMCLI).  Du  fait  de  l’existence  d’homonymes  (Jean  Dupont,  Marc Dupont…), la connaissance du seul nom du client ne permet pas de définir d’une manière unique son code client, son  prénom,  son  adresse  de  facturation,  son  code  postal,  sa  ville  de  facturation,  son  code  commune  INSEE,  son  numéro  de  facture, les montants HT et TTC de cette facture et le taux de TVA appliqué dessus.  La 3ème donnée source à étudier est la 37 : le 1er prénom du client (PNOMCLI). Cette donnée n’est pas non plus source de  dépendance fonctionnelle !  La 4ème donnée source à étudier est la 38 : la ligne 1 de l’adresse de facturation du client (AD1CLIF). Cette donnée contient  entre autres le nom de la rue. La connaissance du nom de la rue n’induit pas la connaissance d’un et d’un seul habitant de  cette rue, d’un seul numéro de maison…  Les autres éléments de l’adresse (bâtiment, étage… c’est­à­dire les données 39, 40, 41 et 42) ne sont pas non plus sources  de dépendance fonctionnelle.  La 9ème donnée source à étudier est la 43 : code postal de facturation (CPCLIF). Une valeur de code postal de facturation ne  permet pas de définir un et un seul client.  Une  valeur  de  code  postal  de  facturation  ne  permet  pas  de  définir  une  et  une  seule  commune  de  France.  Il  existe  des 

- 4-

© ENI Editions - All rigths reserved

communes différentes mais voisines qui portent le même code postal.  Enfin,  une  valeur  de  code  postal  ne  permet  pas  de  déterminer  un  et  un  seul  Numéro  de  facture  et  les  informations  associées.  La 10ème donnée source est la 44 : ville de facturation (VILCLIF). En France, il existe des communes de même nom dans  différents  départements,  donc  la  connaissance  d’un  libellé  de  commune  ne  définit  pas  une  et  une  seule  valeur  de  code  postal,  ni  un  et  un  seul  code  commune  INSEE.  De  même,  la  connaissance  d’un  libellé  de  commune  ne  permet  pas  de  distinguer un et un seul client, ni un et un seul numéro de facture.    La 11ème donnée source à étudier est la 45 : code commune INSEE. La connaissance d’une valeur du code commune INSEE permet de définir une et une seule valeur de libellé de commune de  France.  Nous  avons  donc  une  dépendance  fonctionnelle  entre  la  donnée  code  commune  INSEE  et  le  libellé  du  code  commune  de  France.  Le tableau des dépendances fonctionnelles va être complété de la manière suivante : 

    La 12ème donnée source à étudier est la 46 : numéro de la facture (NOFACT). ●

Une et une seule valeur pour le montant HT de la facture, 

●

Une et une seule valeur pour le taux de TVA à appliquer, 

●

Une et une seule valeur pour le montant TTC de la facture, 

●

Une et une seule valeur pour le code client. 

Nous avons donc une dépendance fonctionnelle entre la donnée numéro de facture (source) et le montant HT, le taux de  TVA, le montant TTC de la facture et le code client (cibles).    La 13ème donnée source à étudier est la 47 : montant Hors Taxes de la facture (MNTHTF). La connaissance d’une  valeur  d’un montant Hors Taxes ne permet de déterminer une et une seule valeur d’aucune autre 

© ENI Editions - All rigths reserved

- 5-

donnée du dictionnaire. MNTHTF n’est pas une source de Dépendance Fonctionnelle.    La 14ème donnée source à étudier est la 48 : Taux de TVA à appliquer (TOTVA). La connaissance d’une valeur d’un taux de TVA à appliquer ne permet de déterminer une et une seule valeur d’aucune autre  donnée du dictionnaire. TOTVA n’est pas une source de Dépendance Fonctionnelle.    La 15ème donnée source à étudier est la 49 : montant Toutes Taxes Comprises de la facture (MNTTCF). La  connaissance  d’une  valeur  d’un  montant  Toutes  Taxes  Comprises  ne  permet  de  déterminer  une  et  une  seule  valeur  d’aucune autre donnée du dictionnaire. MNTHTF n’est pas une source de Dépendance Fonctionnelle.  Ces réflexions nous permettent de compléter une nouvelle fois la matrice des dépendances fonctionnelles : 

 

4. Étape 3  Quand  l’étude  de  toutes  les  données  susceptibles  d’être  source  est  terminée,  il  faut  simplifier  la  MDF.  Il  ne  faut  conserver que les colonnes dont l’en­tête est effectivement une donnée source.  Exemple  Dans notre exemple, on obtient donc : 

- 6-

© ENI Editions - All rigths reserved

  La matrice est devenue beaucoup plus lisible et plus simple à utiliser. Elle est, malgré tout, exhaustive car il y autant  de lignes que de données recensées dans le dictionnaire de données. 

5. Étape 4  Il faut maintenant valoriser la colonne Total en additionnant les ’1’ de chaque ligne.  Exemple  Dans notre exemple, nous obtenons après calculs : 

 

6. Étape 5  Dans une dernière étape, il faut s’intéresser à la colonne Total.  Deux cas particuliers sont à étudier : 

© ENI Editions - All rigths reserved

- 7-

Le Total est à zéro Cette valorisation nulle induit deux possibilités :  ●

La donnée est source de dépendance fonctionnelle, donc cela est normal. 

●

La donnée n’est pas source de dépendance fonctionnelle. Elle est isolée dans le Système d’Information. A­t­ elle réellement une utilité ?  ●

Si non, elle n’a pas lieu d’être et doit être éliminée. 

●

Si  oui,  elle  doit  être  obligatoirement  rattachée  à  une  donnée  source,  il  faut  approfondir  l’étude  des  données. En effet, elle peut être donnée cible d’une dépendance fonctionnelle dont la donnée source  est une composition de données source. 

Exemple 1  Dans notre exemple, le numéro de facture (NOFACT) est l’identifiant de l’entité Facture.  Sa colonne Total est égale à zéro.  Exemple 2  Considérons l’extraction des données d’un système de gestion de trains : nombre de voyageur, date, horaire, code train…  Les règles de gestion sont les suivantes :  ●

Un code train (COTRIN) détermine de manière unique l’horaire  de  départ  de  ce  train  (HDTRIN)  et  l’heure d’arrivée  (HATRIN), son type TGV, Corail… (TYTRIN). 

●

Par contre, un code train ne détermine pas d’une manière unique la date de circulation de ce train (DTRIN). Il peut  circuler tous les jours ou uniquement le week­end et/ou les jours fériés… 

●

La date de jour de circulation du train définit d’une manière unique le type de date (veille de fête ou pas) (TYDATE). 

●

Enfin, le code train ne détermine pas de manière unique le nombre de voyageurs (NBVOY) qui sont dans ce train. Ce  nombre peut être différent à chaque date de circulation. 

À ce stade, nous en déduisons la matrice de dépendances fonctionnelles suivantes : 

  Nous n’avons pas pu rattacher à une donnée source, via une dépendance fonctionnelle, les données NBVOY. C’est pour cela  que la colonne "Total" de cette ligne est à 0.  Par contre, pour un code train et une date définis, il est possible de déterminer précisément le nombre de voyageurs de ce  train.  Ainsi, la donnée DTRIN associée à COTRIN va définir une nouvelle donnée source d’une dépendance fonctionnelle dont la  donnée cible est NBVOY.  La matrice des dépendances fonctionnelles évolue et devient : 

- 8-

© ENI Editions - All rigths reserved

  Nous obtenons trois informations : client, train générique et train circulant.  Le Total est supérieur à 1 et la donnée n’est pas un identifiant La  donnée  est  en  dépendance  fonctionnelle  avec  plusieurs  sources.  La  propriété  de  transitivité  de  la  dépendance  fonctionnelle est mise en œ uvre et cela crée des dépendances fonctionnelles redondantes.  La propriété de transitivité signifie que si A → B et B → C, alors A → C.  Contrairement à la nature humaine, notre objectif étant d’éviter les redondances de données, il ne faut pas suivre le  plus court chemin. Il faut conserver les deux branches initiatrices de la transitivité et éliminer la branche déduite, car  c’est elle qui induit les redondances.  Exemple 1  Reprenons l’exemple de l’entreprise et de la gestion de ses clients et de leurs factures.  Examinons la donnée VILCLIF dont la colonne Total est 2, donc supérieur à 1.  Extrait du tableau précédent : 

  La donnée VILCLIF est une donnée cible de deux dépendances fonctionnelles :  ●

L’une dont la donnée source est Code Client (COCLI), 

●

L’autre dont la donnée source est le Code Commune INSEE (CINSEE). 

Mais  le  Code  Commune  INSEE  (CINSEE)  est  aussi  une  donnée  cible  de  la  dépendance  fonctionnelle  dont  le  code  client  (COCLI) est la donnée source.  Nous avons donc :  COCLI → CINSEE  CINSEE → VILCLIF  COCLI → VILCLIF  Les données CINSEE et VILCLIF, pour un code client donné, représente la même information. Il y a redondance.  Laquelle faut­il éliminer ?  Si l’on conserve VILCLIL, nous avons vu précédemment qu’il pouvait exister plusieurs communes de même nom, donc cette  information n’est pas suffisante en elle­même pour retrouver son code de commune.  Par  contre,  si  l’on  conserve  CINSEE,  la  connaissance  du  code  commune  INSEE  déterminera  une  et  une  seule  ville  de 

© ENI Editions - All rigths reserved

- 9-

livraison.  Donc, il faut conserver CINSEE dans l’entité client.  Pour assurer l’exhaustivité des informations, il faut conserver la dépendance fonctionnelle entre CINSEE et VILCLIF pour  retrouver la ville, mais dans une autre entité que celle de l’entité client.  Donc, le tableau résultant est le suivant : 

  Nous venons de créer une entité paramètre (cf. Dictionnaire des données ­ Analyse du recueil de données de ce chapitre).  L’attribut  code  commune  INSEE  (CINSEE)  de  l’entité  CLIENT  fait  référence  à  l’entité  paramètre  COMMUNE  (constituée  de  l’identifiant code commune (CINSEE) et de commune (VILCLIF).  Synthèse des exemples 1 et 2  Après  avoir  suivi  les  cinq  étapes  de  construction  d’une  matrice  des  dépendances  fonctionnelle,  nous  obtenons  le  résultat  suivant : 

  Si nous faisons la synthèse des données d’un client, nous constatons que :  ●

La donnée ville de facturation n’est plus en dépendance fonctionnelle du code client. 

●

Dans notre exemple, le code client (COCLI) est l’identifiant de l’entité CLIENT. 

●

Le N° de facture (NOFACT) est l’identifiant de l’entité FACTURE. 

●

Le code commune INSEE (CINSEE) est l’identifiant de l’entité paramètre COMMUNE.   

Cet exemple vous le confirme, l’intérêt des entités paramètres est d’éviter les redondances de données.

- 10 -

© ENI Editions - All rigths reserved

Synthèse  Ce  chapitre  a  permis  de  dévoiler  comment  se  réalise  la  transformation  des  attentes  des  utilisateurs  en  données  du  futur Système d’Information.  Cette  transformation  repose  sur  le  recueil  des  données  que  l’on  va  utiliser  jusqu’à  construire  la  matrice  des  dépendances fonctionnelles.  L’informaticien suivra le cheminement suivant :  ●

Recensement  et  analyse  des  données  pour  créer  le  dictionnaire  des  données  dans  lequel  chacune  des  données sera unique, identifiée (numéro, libellé) et caractérisée (type, format, catégorie). 

●

Étude de ces données pour regrouper les données liées par des dépendances fonctionnelles. Ce lien passe par  la description d’une donnée source (monôme ou association de données source) et de une à n données cible.  La relation entre ces données étant que pour une valeur de la donnée source, on ne peut associer qu’une et  une seule valeur de la donnée cible. 

●

Construction de la Matrice des Dépendances Fonctionnelles et affinage de celle­ci, reposant sur les 5 étapes  précédemment  détaillées,  pour  obtenir  une  matrice  résultante  dont  les  lignes  seront  les  données  cible,  les  colonnes les données source de DF et dont la dernière colonne Total ne devra être valorisée qu’à 1 ou 0. 

La  prise  en  main  de  ce  raisonnement  ne  se  fait  pas  en  une  seule  fois,  il  faut  pratiquer.  Mais  sa  mise  en œ uvre  est  l’assurance d’avoir un socle solide pour la modélisation conceptuelle des données, étape suivante dans la construction  d’une base de données.  Enfin,  répétons­le,  l’autre  pan  indispensable  de  la  construction  d’un  Système  d’Information  est  l’analyse  des  traitements, qui n’a pas été étudiée ici. 

© ENI Editions - All rigths reserved

- 1-

Exercice  1. Énoncé  Soit  un  service  de  prêts  dans  un  établissement  bancaire  dont  on  veut  automatiser  la  gestion  avec  une  application  informatique.  Les  données  suivantes  ont  été  recensées :  code  client,  montant  du  prêt,  type  de  prêt  (immobilier,  personnel,  complémentaire…),  durée  (en  mois),  adresse  du  client,  mail  client,  taux  annuel  (fixe),  assurance  facultative  (O/N),  nom, prénom, date du premier remboursement, date de signature du contrat, téléphone client, titulaire d’un compte­ espèce (O/N), libellé du prêt, montant mensuel de remboursement, courriel client, nombre de mensualités.  Répondez aux questions suivantes :  ●

Analyser  le  recueil  de  données  pour  obtenir  un  recueil  de  données  atomiques,  sans  redondance  directe  ou  indirecte, sans homonymes et en ayant déterminé les données susceptibles d’être identifiant d’entités. 

●

Construire le dictionnaire de données. 

●

Construire la matrice des dépendances fonctionnelles en distinguant les 5 étapes de sa construction. 

2. Solution  Analyse du recueil de données  ●

Y­a­t­il des données redondantes directes ? Oui. 

Les données  mail du client et  courriel du client ont un libellé différent mais ont le même sens. Nous conserverons la  donnée courriel du client qui est français.  Les  données durée  du  prêt  en  mois et  nombre  de  mensualités  ont  un  libellé  différent  mais  ont  le  même  sens.  Nous  conserverons la donnée durée du prêt en mois qui est le terme officiel que l’on retrouve sur le contrat signé par le  client.  ●

Y­a­t­il des données en redondance indirecte ? Oui. 

La donnée montant mensuel de remboursement peut être calculée connaissant le montant du prêt, la durée du prêt et  le taux annuel fixe appliqué à l’emprunt. Nous ne garderons pas cette donnée dans notre SI.  En théorie et dans le contexte analyse des données, ce choix est exact. Ensuite, il faut affiner cette décision  en  regardant  les  traitements.  Si  cette  donnée  est  souvent  utilisée  dans  l’application,  il  faut  se  poser  la  question suivante : que vaut­il mieux perdre : de la place mémoire ou du temps de calcul ? La réponse est à faire  au cas par cas, suivant le contexte. 

●

Y­a­t­il des données homonymes ? Non. 

●

Les données sont­elles toutes élémentaires ? 

L’adresse client telle qu’elle est définie actuellement n’est pas atomique.  Nous allons la décomposer en 5 lignes adresse complétées par le code postal et la commune.  ●

À quelle entité du monde réel, les données recensées sont­elles liées ? 

Les deux entités que nous percevons sont le client et le prêt. Nous avons deux données qui sont candidates à être  identifiant de ces entités et que nous retenons : le code client et le type de prêt.  Si ces données n’avaient pas existé, nous les aurions créées.  Nous avons filtré le recueil de données, nous pouvons passer à l’étape suivante. 

© ENI Editions - All rigths reserved

- 1-

Dictionnaire des données La  réalisation  du  dictionnaire  des  données  nous  oblige  à  étudier  d’un  peu  plus  près  chacune  des  données :  type,  format, catégorie…  Les réponses à certaines questions nous seront fournies par la Maîtrise d’Ouvrage.  Par  exemple,  si  l’utilisateur fait  des calculs sur une donnée, il ne faudra pas lui donner un type alphanumérique mais numérique.  Les montants seront d’un type numérique. Le format qui leur est assigné, devra pouvoir prendre en compte toutes  les possibilités offertes par le SI.  Après étude, vous avez obtenu le dictionnaire de données suivant : 

  Matrice des dépendances fonctionnelles Certaines données sources sont évidentes : celles que l’on a définies en I : Identifiant.  1) Réalisons le squelette de la MDF en partant de ces informations. 

- 2-

© ENI Editions - All rigths reserved

  2)  Nous  signalons  la  propriété  de  réflexivité  des  dépendances  fonctionnelles,  nous  ne  conservons  en  en­tête  de  colonne que les données actuellement définies comme identifiant et nous distinguons les DF : 

© ENI Editions - All rigths reserved

- 3-

  3) Valorisons la matrice : 

  4) Que pouvons­nous dire de cette matrice ?  ●

Il  existe  des  données,  non­identifiantes, pour lesquelles la colonne Total est valorisée à Zéro : montant du  prêt, durée (en mois), taux annuel, assurance facultative (O/N), date du 1er remboursement, date signature  du contrat. 

Il faut vérifier qu’elles sont utiles au Système d’Information :  Si NON, les éliminer,  Si OUI, les lier en tant que donnée source ou donnée cible à d’autres données du Système d’Information.  ●

Aucune donnée du SI n’est une donnée source de dépendance fonctionnelle de ces données. 

La connaissance du code client ne permet pas de définir une seule valeur de : 

- 4-

© ENI Editions - All rigths reserved

●

Montant  du  prêt,  durée,  taux  annuel,  assurance  facultative,  date  du  1e r  remboursement,  date  signature  contrat : en effet, il peut contracter plusieurs emprunts dans le même établissement financier. 

De  même,  la  connaissance  du  type  de  prêt  ne  permet  pas  de  définir  une  seule  valeur  pour  chacune  des  données  précédentes.  Quelles sont les données dont la connaissance d’une valeur permet de déterminer une et une seule valeur pour les  attributs  suivants :  les  valeurs  de  montant  du  prêt,  durée,  taux  annuel,  assurance  facultative,  date  du  1e r  remboursement, date signature contrat ?  Un client peut contracter plusieurs prêts dans une banque.  Il  peut  aussi  contracter  plusieurs  prêts  de  même  type  (immobiliers, ….)  dans  la  même  banque,  s’il  reste  client  plusieurs années. Ils se distingueront par la date de signature du contrat.  ●

Est­ce  que  la  connaissance  d’une  valeur  de  code  client,  de  type  de  prêt  et  date  de  signature  permet  de  connaître :  ●

Une valeur du montant du prêt ? Oui.  

●

Une valeur de durée du prêt ? Oui.  

●

Une valeur du taux annuel ? Oui. 

●

Une valeur d’adhésion à l’assurance facultative ? Oui.   

●

Une valeur pour la date de 1 e r remboursement ? Oui.

●

Une valeur pour la date de signature du contrat ? Oui. 

Il s’avère que la donnée source de dépendance fonctionnelle n’est pas une donnée mais un triplet de données (Code  client, type de prêt, Date signature) qui modélise un prêt précis pour un client bien déterminé.  (COCLI, TYPRET, DPRETS) → MNPRET  (COCLI, TYPRET, DPRETS) → DUPRET  (COCLI, TYPRET, DPRETS) → TXPRET  (COCLI, TYPRET, DPRETS) → DREMB1  (COCLI, TYPRET, DPRETS) → ADASSU  Nous  avons  donc  enrichi  le  dictionnaire  de  données  d’une  donnée.  Cette  donnée  est  un  identifiant  constitué  de  la  concaténation des trois données :  COCLI­TYPRET­DPRETS.  ●

La matrice de dépendance fonctionnelle résultante est la suivante : 

© ENI Editions - All rigths reserved

- 5-

  Toutes les données sont valorisées : ‘1’ (données cibles) ou ‘0’ (données sources).  La matrice des dépendances fonctionnelles est finalisée. 

- 6-

© ENI Editions - All rigths reserved

Introduction  Le  chapitre  précédent  nous  a  permis  de  lister  exhaustivement  les  données  du  futur  SI  et  de  définir  les  liens  les  unissant, par le biais des dépendances fonctionnelles.  L’étape suivante, à partir de la matrice des dépendances fonctionnelles entre données élémentaires, va consister à :  ●

rassembler les données élémentaires en regroupements cohérents que l’on appellera entités, 

●

déterminer les associations (appelées aussi relations) existantes entre ces entités. 

Pour ce faire, nous élaborerons un modèle conceptuel de données.  Comme nous l’avons déjà fait remarquer, précédemment, la conception d’un SI repose sur l’analyse des traitements et  des données et cette étude ne peut se faire sans méthode.  Dans ce chapitre, nous découvrirons la méthode Merise et ses différents niveaux. Cette méthode distingue et modélise  les traitements et les données du futur SI. Nous citerons les modèles de traitements pour mémoire et entrerons plus  en détail dans les modèles de données.  Le passage d’un niveau de modèles de données à un autre va nous permettre progressivement de créer notre base  de données. 

© ENI Editions - All rigths reserved

- 1-

Présentation générale de la méthode Merise  Dans ce paragraphe, nous présenterons les objectifs d’une méthode, en se basant sur la méthode Merise. 

1. Préambule  Tout  d’abord,  nous  pouvons  nous  demander  ce  qu’est  une  méthode  et  quels  sont  ses  apports  dans  la  conception  informatique.  Une méthode est "un ensemble ordonné de manière logique de principes, de règles, d’étapes permettant de parvenir  à un résultat" (Larousse).  L’utilisation d’une méthode va fournir au concepteur :  ●

une ligne de réflexion permettant de suivre une succession progressive d’étapes enrichissant l’analyse au fur  et à mesure ; 

●

la manière d‘aborder les problèmes. 

Exemple  C’est  dans  ce  sens  que  les  concepts  de  niveau  conceptuel,  organisationnel,  logique,  physique  sont  introduits  dans  la  méthode Merise.  ●

Des  représentations  de  la  réalité,  spécifiques  à  chaque  étape,  qui  permettront  d’assurer  la  communication  entre MOA et MOE. 

Exemple  Avec  Merise,  nous  parlerons  de  Modèle  Conceptuel  de  Données,  Modèle  Conceptuel  de  Traitement,  Modèle  Physique  de  Données, Modèle Physique de Traitement…  Avec UML, nous utiliserons des diagrammes de séquences, de classes…  C’est à partir de ces éléments que nous assurerons la qualité de l’analyse et de la conception d’un SI.  Dans  le  cas  d’un  SI  comportant  une  base  de  données  relationnelle,  la  méthode  Merise  et  ses  modèles  de  données  sont adéquats pour guider le concepteur à partir de la Matrice des Dépendances Fonctionnelles jusqu’à la déclaration  descriptive du schéma de la base de données. 

2. Historique de la méthode Merise  La méthode Merise est une méthode française et date des années 80.  En  1977,  après  l’explosion  et  le  grand  succès  des  traitements  automatisés,  le  Ministère  de  l’Industrie  a  souhaité  rationnaliser la conception des systèmes d’information. Ceci passait par la mise en place d’une méthode. Plusieurs SSII  (CGI  informatique,  etc.)  ont  participé  à  cette  étude  en  collaboration  avec  le  CETE  (Centre  d’Etudes  Techniques  de  l’Equipement)  du  Ministère  de  l’industrie,  et  avec  tout  particulièrement  un  de  leur  expert  en  bases  de  données :  Hubert Tardieu ainsi qu’avec Jean­Louis Le Moigne, spécialiste de la systémique.  C’est  ainsi  qu’est  née  la  méthode  Merise.  Merise  n’est  pas  une  méthode  brute,  c’est  un  ensemble  organisé  et  intelligent  de  concepts  et  de  règles  de  construction  qui  s’intègre  facilement  à  l’organisation  de  l’entreprise,  pour  générer des Systèmes d’Informations fiables et pérennes.  Cette  méthode,  bien  qu’âgée,  est  encore  d’actualité.  Les  fondateurs  ont  su  l’adapter  aux  diverses  innovations  informatiques : Merise 2 (pour l’architecture client serveur), MOO (Merise Orienté Objet), etc. C’est une des méthodes  les plus utilisées par les administrations françaises, les sociétés d’assurances... car elle est bien en adéquation avec  l’informatique de gestion.  C’est  une  méthode  systémique  qui  sépare  l’étude  des  traitements  et  des  données.  Cela  l’alourdit  certes,  mais  cela  permet de faciliter la maintenance de l’application : une évolution des traitements n’affectant pas obligatoirement les  données  et  vice  versa,  ceci  allégeant  la  mise  à  niveau  informatique.  Cette  séparation  n’élimine  pas,  dans  le  déroulement de la méthode, des étapes de vérification de cohérences entre traitements et données.  Exemple  Considérons une facture envoyée au client.  Jusqu’à maintenant, l’adresse de la facture était structurée de la manière suivante :  © ENI Editions - All rigths reserved

- 1-

Nom Prénom  Adresse  Code Postal Bureau distributeur  Le service de la facturation demande que l’adresse comporte dorénavant la civilité (M, Mme, Melle) avant le nom.  Nous savons, de plus, que la donnée civilité avait été recensée lors de l’élaboration du dictionnaire de données et conservée  dans la structure de l’entité client.  Donc, la nouvelle demande de la MOA d’ajout de civilité n’induit pas une modification de la structure de données du client.  Par contre, le traitement (les programmes) de l’impression de la facture en sera légèrement affecté : une zone de données  devra être ajoutée dans la maquette d’impression.  Après cet historique succinct, nous allons étudier les fondements de la méthode Merise. 

3. Les dimensions de la méthode Merise  En référence aux mathématiques et tout particulièrement à la géométrie, la méthode Merise peut être définie comme  un espace à trois dimensions.  En effet, le déroulement de la méthode repose sur trois axes :  ●

La démarche ou cycle de vie, 

●

Le raisonnement ou cycle d’abstraction, 

●

La maîtrise ou cycle de décision. 

 

a. La démarche ou cycle de vie  Un des objectifs d’une méthode est de guider l’informaticien dans son processus d’informatisation ; c’est ce que l’on  appelle la démarche ou le cycle de vie dans la méthode Merise.  Elle repose sur une succession de phases, enrichissant l’étude au fur et à mesure et comportant des activités bien  définies. Ces activités peuvent être spécifiques à une phase mais aussi continues tout au long de la démarche.  Exemple  L’activité de création du dictionnaire de données est réalisée en début de projet.  L’activité de documentation est continue tout le long du projet (analyse des besoins, commentaires dans les programmes,  maquettage…).  Le passage à la phase suivante dépend de la validation, généralement par la MOA, de la phase précédente.  Mais quelles sont ces phases ?  Le  nombre  de  phases  n’est  pas  constant,  il  dépend  de  l’entreprise,  de  l’ampleur  du  projet,  etc.  mais  celles­ci  recouvrent obligatoirement les travaux de : 

- 2-

© ENI Editions - All rigths reserved

●

Analyse des besoins, 

●

Conception, 

●

Développement, 

●

Tests unitaires, 

●

Tests fonctionnels (aussi appelés recette des utilisateurs), 

●

Mise en œ uvre, 

●

Maintenances. 

L’analyse des besoins permettra de mettre en exergue les objectifs, les fonctionnalités ou les contraintes du futur SI.  La  conception  permettra  d’affiner  et  de  définir  plus  précisément  les  niveaux  physique  (schéma  d’architecture  technique) et conceptuel (schéma d’architecture applicative) de la future solution.  Le développement permettra d’écrire les différents modules de l’application dans le langage de programmation, choisi  lors de la phase de conception technique.  Les  tests  unitaires  seront  effectués  par  les  analystes­programmeurs,  pour  contrôler  la  prise  en  compte  des  traitements demandés ainsi que la qualité de la programmation.  Les tests fonctionnels sont effectués par la MOA : ils servent à vérifier que les fonctionnalités, développées dans les  programmes, répondent totalement à l’expression des besoins.  La mise en œuvre inclut la préparation de l’intégration du futur SI dans l’environnement de production (réel).  Les maintenances consistent à la prise en compte de corrections de bugs, d’évolutions fonctionnelles ou techniques.  Les  modèles  Merise  couvrent  toutes  ces  phases  mais  les  modèles  les  plus  structurants  sont  ceux  qui  précèdent  l’étape de réalisation et tests unitaires. 

b. Le raisonnement ou cycle d’abstraction  Au  fur  et  à  mesure  de  l’avancée  de  la  conception  d’un  système  d’information,  différentes  problématiques  vont  se  poser. Nous pouvons citer, par exemple :  ●

la définition des règles de gestion du futur système ; 

●

la définition des informations gérées dans ce système ; 

●

la répartition des traitements entre l’homme et la machine ; 

●

le typage des futurs traitements : traitement en temps réel, en temps différé… 

●

la chronologie des traitements ; 

●

l’organisation physique du stockage des données ; 

●

le type de matériel choisi… 

La réponse à ces questions conduit à faire des choix de natures différentes, telles que :  ●

Gestion, 

●

Organisationnelle, 

●

Technique, 

© ENI Editions - All rigths reserved

- 3-

●

Matérielle… 

Et, de plus, ces questions suivent une progression, allant du plus général au plus précis. C’est ce que Merise définit  comme niveaux d’abstraction.  Ces niveaux sont au nombre de 4 :  ●

Le niveau conceptuel (le plus abstrait),  Réponses à la question de base : QUOI ? 

●

Le niveau organisationnel,  Réponses aux questions COMMENT ? OÙ ? QUI ? QUAND ? 

●

Le niveau logique,  Réponses à la question QUELS MOYENS ? 

●

Le niveau physique (le plus concret),  C’est l’étape de construction avec le matériel et les outils. 

Exemple  Par analogie à la réalité quotidienne : considérons l’arrivée d’un PC dans la maison :  ●

le  niveau  conceptuel  peut  être  comparé  à  la  réponse  au  besoin :  intégration  du  PC  dans  la  maison ?  Nous  souhaiterions le mettre sur un bureau spécial PC avec toutes les options éventuelles voulues (support inclus pour  l’imprimante, tour à CD…) 

●

le niveau organisationnel va permettre de préciser : qui va utiliser le PC (les parents et/ou les enfants), quand (la  journée ? le soir ? le week­end ?...), où (dans la salle à manger ? un bureau ? une chambre ? de quelle taille ? …),  … 

●

le  niveau  logique  va  préciser  avec  quels  moyens  on  va  répondre  à  ce  besoin :  la  construction  du  bureau  par  un  artisan ? l’achat d’un bureau déjà monté ? un kit à monter ? 

●

le niveau physique correspondra à prendre l’artisan Mr. X ou à sortir les éléments du kit (matériel, outils, plan) et  commencer à le monter… 

Précisons ces différents niveaux.  Le niveau conceptuel sert à exprimer les grandes activités, les processus inclus, les choix fondamentaux de gestion,  les  différents  éléments  structurels  du  futur  SI  mais  sans  tenir  compte  des  moyens  à  mettre  en  œ uvre,  de  leurs  contraintes, de leur organisation, etc.  Exemple  L’informatisation  du  domaine  Ressources  Humaines  d’une  entreprise  va  inclure  la  gestion,  la  formation,  la  grille  des  salaires, le calcul de la paye, etc. des employés. Au niveau conceptuel, les principales activités du métier seront recensées  mais sans préciser, par exemple, à quelles dates se fera le calcul de la paye, quelle sera la maquette de la future feuille de  paye, comment se fera l’édition des feuilles de paye et leur envoi, etc.  Ce  niveau,  et  plus  particulièrement  celui  concernant  les  données,  va  être  détaillé  dans  les  paragraphes  suivants. 

Le  niveau  organisationnel  sert  à  exprimer  les  choix  d’organisation  des  ressources  humaines  et  matérielles,  la  localisation des données, leur visibilité, leurs modalités de mise à jour, etc.  Exemple 1  Suivant  le  contexte,  il  peut  être  décidé  que  les  données  du  futur  SI  soient  centralisées  ou  réparties  avec  duplication  ou  pas, sur plusieurs sites.  Exemple 2 

- 4-

© ENI Editions - All rigths reserved

Certaines données du dossier médical d’un patient hospitalisé seront utiles au travail de l’infirmier et lui seront visibles ;  mais  d’autres  plus  techniques  ou  plus  confidentielles  lui  seront  occultées  et  seront  uniquement  visibles  par  le  médecin  traitant.  Exemple 3  C’est à ce niveau que l’on décidera si la mise à jour des stocks se fait :  ●

en temps réel à chaque sortie d’un article ; 

●

en différé ; par exemple, tous les soirs en fin de journée.   

La décision prise à ce niveau dépendra des choix de gestion effectués dans le niveau conceptuel.

Le  niveau  logique  sert  à  exprimer  les  choix  des  moyens  et  ressources  informatiques,  indépendamment  de  leurs  caractéristiques techniques.  Exemple  À ce niveau d’étude, le concepteur pourra décider, suivant les fonctionnalités attendues, d’opter pour une base de données  relationnelle, un datawarehouse, etc.  Le  niveau  physique  va  permettre  la  mise  en  œ uvre  des  solutions  informatiques  en  tenant  compte  des  caractéristiques techniques et de leurs spécificités et contraintes.  Dans  ce  niveau,  la  description  de  la  ou  des  bases  de  données  sera  faite  avec  le  vocabulaire,  la  syntaxe  du  futur  Système de Gestion de Bases de Données choisi et les outils proposés par celui­ci.  Exemple  Suivant  certaines  données  telles  que  le  volume  des  données,  les  traitements  qui  affecteront  la  base  de  données  ou  le  budget alloué pour le projet, le concepteur pourra opter pour une base de données gros système (par exemple, DB2 d’IBM)  permettant de gérer des millions de lignes et assurant via les utilitaires associés, une forte sécurité des données, ou une  base telle que Oracle ou Access qui sont plus limitées en volume de données mais plus souples à l’utilisation.   Chaque niveau générera deux modèles, l’un pour les données, l’autre pour les traitements.  Les différents niveaux d’abstraction de Merise sont synthétisés dans le tableau suivant : 

© ENI Editions - All rigths reserved

- 5-

  Merise est une méthode systémique. Donc, dans le niveau conceptuel, outre les modèles de données et de  traitements,  un  modèle  supplémentaire  est  intégré  pour  définir  le  SYSTEME  d’Information.  C’est  le  Modèle  Conceptuel de Communication (MCC) que nous découvrirons plus loin dans ce chapitre. 

c. La maîtrise du projet ou cycle de décision  Chaque  niveau  d’abstraction  représente  des  problématiques  qui  apparaissent  inévitablement  dans  la  conception  d’un  SI.  Cela  conduit  obligatoirement  à  trouver  des  réponses  et  à  faire  des  choix  (quelle(s)  solution(s),  quels  moyens…).  Ces choix, dans l’optique de la maîtrise du projet, induiront souvent des décisions d’arbitrage relatives aux coûts,  au délai, au niveau de la sécurité mise en place (la sécurité a un coût variable suivant le niveau de protection associé !),  au niveau de la qualité du produit final….  Or, ces différentes composantes sont antagonistes, si l’on en privilégie une, c’est souvent au détriment d’au moins  une  autre.  Particulièrement,  si  l’on  réduit  les  budgets,  la  qualité  finale  peut  en  être  affectée  (matériel  moins  performant…).  Ces décisions d’arbitrage sont donc stratégiques. Ce ne peut être ni les utilisateurs qui expriment leurs besoins, ni  les informaticiens qui proposent des réponses à ces besoins qui sont susceptibles de prendre de telles décisions.  Un troisième type d’acteurs apparaît : les décideurs (la direction).  Chacun des acteurs prendra, à un moment ou à un autre, une décision au cours du déroulement du projet. Chaque  décision  sera  prise  dans  l’intérêt  du  projet  et  pour  répondre  aux  critères  vus  précédemment  (coûts,  délais,  qualité…) mais leur criticité sera variable.  C’est pour cela que la démarche de maîtrise de projet consiste à définir : 

- 6-

© ENI Editions - All rigths reserved

●

Les rôles et les responsabilités de chacun des acteurs, 

●

Les groupes d’acteurs (comité de suivi, comité de pilotage…) ainsi que leur composition, 

●

Les décisions à prendre au cours du projet (solution privilégiée, plan de charge…), 

●

Les documents à livrer (livrables) tels que cahier des charges, dossier de choix de solution, étude sécurité… 

Pour  le  déroulement  optimum  d’un  projet,  les  trois  axes  de  Merise  doivent  être  développés  d’une  manière  harmonieuse. Il ne faudra pas accentuer un cycle, sinon cela se fera aux dépens des deux autres. 

© ENI Editions - All rigths reserved

- 7-

Les modèles Merise  Comme nous l’avons indiqué plus haut, un Système d’Information englobe des données et des traitements.  Les données sont constitutives des informations.  Les traitements affectent les données concurremment à l’évolution des informations. 

1. Modèle Conceptuel de Communication  Pourquoi ces informations évoluent­elles ? Tout simplement, sous l’influence d’événements, de flux d’informations issus  d’autres systèmes en relation avec lui.  Il faudra donc, dans un premier temps, définir les frontières du système d’information :  ●

Quels sont les domaines d’activités du SI (processus et acteurs internes) ? 

●

Quels sont les éléments externes au SI (acteurs externes) ? 

C’est pour cela que Merise a intégré un modèle supplémentaire, appelé Modèle Conceptuel de Communication. Celui­ci  permet de répondre aux questions précédentes.  Le Modèle Conceptuel de Communication est composé de deux diagrammes : le Modèle de Contexte et le Modèle de  Flux Conceptuel.  Le Modèle de Contexte va permettre de déterminer les frontières de notre SI, les acteurs externes et les flux existants  (émission et réception) entre le SI et les acteurs externes.  Le Modèle de Flux Conceptuel va entrer un peu plus en profondeur dans le système et va faire ressortir les grands  domaines d’activités du SI, les acteurs internes ainsi que les flux échangés entre ceux­ci. 

a. Modèle de Contexte  En premier lieu, il faut établir les frontières du SI.  Ceci sera induit par la compréhension des besoins des utilisateurs, qui permettra de définir précisément le domaine  d’étude.  Exemple  Supposons que dans le cahier des charges, il soit spécifié que le futur SI englobe la gestion d’une commande de Vente Par  Correspondance  (VPC)  de  la  saisie  à  la  préparation  de  la  commande  (incluse).  Cela  veut  dire  que  l’achat  des  objets  proposés dans le catalogue, la facturation ou le règlement de la commande ne font pas partie du domaine d’étude.  En second lieu, il sera possible de préciser les domaines d’activités que l’on veut inclure dans le SI :  ●

Activités commerciales, 

●

Activités de production, 

●

Activités de gestion des ressources humaines, 

●

Activités comptables, 

●

Activités de facturation… 

Qu’est­ce qu’une activité ?  Une activité appartenant à un domaine est constituée de 1 à n opérations élémentaires.  Une opération élémentaire est une suite chronologique de tâches qui s’exécutent sans interruption.  Une opération élémentaire forme un tout cohérent. Elle se déclenche à la réception d’un  événement  et  produit  un  résultat. 

© ENI Editions - All rigths reserved

- 1-

L’inclusion de la totalité des activités d’un domaine n’est pas obligatoire dans un SI, cela peut en être une  extraction. 

Exemple  Une entreprise de VPC doit :  ●

Acheter les articles à des fournisseurs, 

●

Stocker, 

●

Vendre les articles à des clients, 

●

Gérer le personnel… 

L’activité principale, qui est le cœur du métier de cette entreprise, est de vendre les articles à des clients.  Si on nous demande de concevoir le SI qui correspond au cahier des charges vu dans l’exemple précédent, le domaine à  étudier pour le futur SI est celui des activités commerciales. De plus, par rapport à ce qui est spécifié, le processus entier  ne doit pas être pris en compte : uniquement de la saisie de la commande à la préparation de la commande.  Enfin, il faudra déterminer les acteurs.  Dans  le  cas  où  le  SI  comporte  plusieurs  domaines  d’activités  échangeant  des  informations,  chacun  de  ceux­ci  représentera un acteur interne.  Les acteurs internes peuvent être un :  ●

Secrétariat, 

●

Magasin, 

●

Entrepôt, 

●

Atelier… 

En fait, les acteurs internes traduisent la répartition organisationnelle des activités au sein du domaine.  Les autres entités qui ne sont pas dans les frontières du SI sont les acteurs externes. Les acteurs externes ont une  importance capitale, ce sont eux qui sont à la base de l’activité du domaine.  Un  acteur,  qu’il  soit  interne  ou  externe,  est  actif.  À  la  réception  d’un  flux,  il  agira  (traitement(s),  émission  d’un  nouveau flux lié à la réception du précédent…).  Pourquoi les acteurs externes sont­ils importants ?   Tout simplement parce qu’ils émettent des flux qui déclenchent puis entretiennent les activités du domaine.  Qui peut être un acteur externe ?  Cela  peut  être  un  partenaire  extérieur  (client,  fournisseur…)  mais  aussi  un  autre  domaine  d’activités  de  l’entreprise  (comptabilité,  gestion  du  personnel…)  ou  une  unité  élémentaire  de  celle­ci  (service  de  la  formation  du  personnel,  service des litiges commerciaux…), mais extérieurau SI étudié.  Le SI et les différents acteurs externes vont donc, communiquer entre eux via des flux. Un flux est un échange entre  deux acteurs.  À l’intérieur du SI, la communication entre acteurs internes se fera aussi via des flux.  La connaissance de l’ensemble de ses flux permet de connaître le fonctionnement global du SI étudié.  Un flux est caractérisé par la connaissance : 

- 2-

●

Des acteurs qui l’émettent et le reçoivent. D’après ce que nous avons dit précédemment, un acteur peut être  externe (fournisseur, client…) ou interne (magasinier, secrétaire,…). 

●

La  catégorie  de  ce  flux  (matières,  finances,  informations…).  En  ce  qui  concerne,  l’informatique  de  gestion,  seuls les flux d’informations (qui englobent nos futures données) nous importent. 

© ENI Editions - All rigths reserved

Exemple :  Dans le SI d’une entreprise de construction automobile, le fournisseur de moteurs d’essuie­glace est un acteur externe.  L’atelier de montage des essuie­glaces est un acteur interne.  Dans l’étape de modèle de contexte, nous représenterons le SI, le ou les acteurs externe(s) et les flux qu’ils s’échangent.  Dans notre exemple, nous pouvons observer au moins 4 flux de base :  ●

Le SI va commander des moteurs d’essuie­glaces, 

●

Le fournisseur va lui faire livrer sa commande, 

●

Le SI peut lui retourner des modèles ayant un défaut, 

●

Le  fournisseur  lui  fera  un  échange  qui  se  concrétisera  par  une  nouvelle  livraison  (nous  distinguerons  cette  livraison de la précédente, car il y aura des éléments d’informations différents). 

Le modèle de contexte qui en est issu, sera le suivant : 

 

b. Modèle des Flux Contextuels  En premier lieu, nous allons regarder l’intérieur du SI et préciser les activités qui y sont incluses (acteurs internes).  En second lieu, comme dans le modèle de contexte, nous chercherons les flux échangés entre ces acteurs.  Cette étape peut distinguer plusieurs niveaux d’étude, d’où plusieurs modèles de plus en plus approfondis. En effet,  le but de ce(s) modèle(s) est de représenter les flux, échangés entre les activités, de plus en plus finement.  Le niveau de détail le plus fin est celui d’une opération élémentaire dans une activité.  Exemple :  Dans notre exemple précédent, le modèle de contexte nous indique que nous aurons au moins deux acteurs internes : le  service  achat  (commandes,  réceptions  et  retours)  et  l’atelier  de  montage  (montage  et  origine  des  retours  vers  le  fournisseur).  Le MFC de niveau 1 correspondant va être le suivant : 

© ENI Editions - All rigths reserved

- 3-

  Le montage des moteurs d’essuie­glaces sur une voiture va être constitué de plusieurs tâches :  ●

Déballage du moteur de son emballage d’origine, 

●

Vérification qu’il y ait tous les éléments, 

●

Pré­installation sur le véhicule, 

●

Montage et vissage,… sur le véhicule, 

●

Essai du moteur d’essuie­glaces. 

Combien y­a­t­il d’opérations élémentaires dans cette activité ?  Il faut distinguer :  ●

Les tâches qui ne peuvent pas être séparées dans le temps, sinon cela pourrait induire des anomalies, 

●

Certaines tâches ou groupes de tâches peuvent ou doivent être réalisées par des acteurs différents (compétences  différentes, par exemple). 

Dans  cet  exemple,  il  apparaît  que  nous  avons  deux  groupes  de  tâches  (deux  opérations  élémentaires)  qui  peuvent  être  réalisées à des moments différents sans interférer négativement l’une sur l’autre. De plus, elles peuvent être traitées par  des employés de compétence différente.  Ce sont les opérations élémentaires suivantes :  ●

L’Installation du moteur d’essuie­glaces sur l’automobile, 

●

Les essais du moteur (vérification du bon état de marche). 

D’où le MFC de niveau 2 : 

- 4-

© ENI Editions - All rigths reserved

  Et ainsi de suite jusqu’au niveau le plus fin.  Nous  voyons  donc  qu’en  analysant  chaque  activité,  il  est  possible  de  la  décomposer  plus  finement  en  opérations  élémentaires "ininterruptibles".  À  ce  stade,  les  grandes  fonctionnalités  et  tous  les  flux  d’informations  (n’oublions  pas,  porteurs  de  données)  sont  modélisés.  À partir de là, Merise propose donc de spécialiser notre analyse en distinguant données et traitements.  Comme indiqué précédemment, les traitements ne sont pas l’objet de notre livre, aussi, nous laisserons de côté cet  aspect. Mais nous vous conseillons d’en prendre connaissance dans un livre consacré à Merise pour bien comprendre  l’interaction de ces modèles et faire l’étude complète d’un SI.  Notre préoccupation principale est de savoir bâtir une base de données à partir des modèles de données de Merise.  Comment va­t­on le faire ? 

2. Modèle Conceptuel des Données  Le  Modèle  Conceptuel  des  Données  (MCD)  repose  sur  le  concept  du  schéma  entités­associations  (ou  appelé  aussi  schéma  entités­relations).  Les  entités,  les  associations  (relations),  les  cardinalités  et  les  contraintes  d’intégrité  multiples vont être conceptualisées à partir du dictionnaire de données et de la MDF, vus dans le chapitre précédent  ainsi que des règles de gestion des utilisateurs.  Faisons connaissance avec chacun de ces concepts. 

a. Entité  Une entité est un tout cohérent, pourvu d’une existence propre, appartenant au domaine à étudier et parfaitement  défini par ses propriétés et un identifiant. 

© ENI Editions - All rigths reserved

- 5-

Elle possède :  ●

Un nom, 

●

Une  ou  n  propriétés  qui  sont  des  caractéristiques  dont  la  valorisation  peut  être  différente  d’une  représentation de cette entité à une autre, 

●

Une propriété particulière appelée identifiant qui ne prendra jamais une valeur en double (ni nulle) et dont  chaque valeur permettra d’identifier d’une manière unique une et une seule occurrence de l’entité. 

Chaque représentation de l’entité (valorisation des propriétés) est appelée occurrence.  La représentation d’une entité est modélisée de la manière suivante : 

  Les noms des entités seront des noms communs : client, facture, assuré, contrat, compte…  L’identifiant est souligné pour le distinguer.  Exemple  Soit l’entité voiture définie de la manière suivante : 

  Deux occurrences de cette entité peuvent être les suivantes : 

 

b. Association  Une association est un lien, perçu dans le domaine à étudier, unissant 2 ou n entités.  Cette association n’a pas d’existence propre, elle n’existe que par l’existence des entités fondatrices.  Une association possède :  ●

- 6-

un nom (obligatoirement) ; 

© ENI Editions - All rigths reserved

●

zéro ou n propriétés. 

Les propriétés portées par l’association n’ont pas de sens en elles­mêmes. Leur sens et leur valorisation dépendent  complètement de la connaissance de chacune des occurrences qui jouent dans cette association.  Une association entre n entités est modélisée de la manière suivante : 

  Les noms des associations sont, généralement, des verbes car le lien qui relie plusieurs entités représente toujours  une action : appartenir, payer, signer, louer…  Le mode du verbe changera suivant le sens de la lecture de l’association.  Exemple :  Un client loue un appartement.  Un appartement a été loué par un client. 

 

c. Cardinalités  Un  couple  de  cardinalités  va  être  attribué  à  chacune  des  entités  appartenant  à  une  association.  Ces  cardinalités  vont préciser comment chacune des entités participe à l’association.  Ce couple de cardinalités est constitué d’une cardinalité minimum et d’une cardinalité maximum.  La valeur de ces cardinalités va dépendre des règles de gestion des utilisateurs.  La cardinalité minimale peut prendre la valeur 0 ou 1, elle représente le nombre de fois minimum qu’une entité peut  utiliser cette association.  La  cardinalité  maximale  peut  prendre  la  valeur  1  ou  n,  elle  représente  le  nombre  de  fois  maximum qu’une  entité  peut utiliser cette association.  D’où, ci­dessous, la modélisation complétée avec les cardinalités possibles : 

© ENI Editions - All rigths reserved

- 7-

 

●

Considérons les valeurs de la cardinalité minimum. 

La valeur 0 exprime le fait qu’il peut y avoir au moins une occurrence, parmi toutes celles existantes, qui n’a jamais  participé à l’association.  Exemple :  Supposons  que  dans  notre  SI,  nous  ayons  distingué  les  entités  client  et  contrat.  De  plus,  nous  avons  distingué  l’association signer un contrat.  Une des règles de gestion de ce système est la suivante : Un contrat peut être signé par plusieurs clients.  De plus, nous avons appris que dans nos clients, nous devons aussi intégrer le concept de prospect. Cela induit qu’il peut y  avoir des clients prospectés, mais qui n’ont pas signé de contrats.  Si  nous  considérons  l’association  signer  un  contrat,  la  cardinalité  minimum  est  égale  à  0.  En  effet,  il  existe  des  occurrences qui ne participent pas à l’association : les prospects.  Nous obtenons la modélisation suivante (la cardinalité maximum étant encore, à ce stade, d’étude à 1 ou n). 

  La valeur 1 exprime le fait que chaque occurrence de l’association participe à l’association.  Exemple :  Considérons  le  même  exemple  que  précédemment  mais  en  rajoutant  une  contrainte : à  savoir  que  les  clients  ont  tous  signé au moins 1 contrat. En d’autres termes, les prospects sont éliminés de notre ensemble de clients.  Dans ce cas la cardinalité minimum du côté client est égal à 1. En effet, toutes les occurrences ont participé à la relation  signer un contrat.  Nous obtenons la modélisation suivante (la cardinalité maximum étant encore, à ce stade, d’étude à 1 ou n). 

 

●

- 8-

Considérons les valeurs de la cardinalité maximum. 

© ENI Editions - All rigths reserved

La valeur 1 exprime le fait que chaque occurrence de la relation participe au plus 1 fois à la relation.  Exemple :  Supposons  que  dans  notre  SI,  nous  ayons  distingué  les  entités  client  et  contrat.  De  plus,  nous  avons  distingué  la  relation signer un contrat.  Dans nos clients, il est possible d’avoir des prospects.  Si la règle de gestion est que chaque client n’a le droit de signer qu’un seul contrat, la cardinalité maximum du côté client  pour la relation signer un contrat est égal à 1.  Nous obtenons la modélisation suivante : 

  Si  nous  n’avions  pas  eu  la  possibilité  d’avoir  des  prospects  dans  nos  clients,  la  cardinalité  minimum  aurait  été égale à 1, et nous aurions eu comme cardinalités finales : 1, 1 au lieu de 0,1. 

La valeur n exprime le fait que chaque occurrence de la relation peut participer plus d’une 1 fois à la relation.  Exemple :  Supposons  que  dans  notre  SI,  nous  ayons  distingué  les  entités  client  et  contrat.  De  plus,  nous  avons  distingué  la  relation signer un contrat.  Dans nos clients, il est possible d’avoir des prospects.  Si  la  règle  de  gestion  est  que  chaque  client  peut  signer  de  1  à  n  contrats  (assurance  auto,  assurance  habitation…),  la  cardinalité maximum du côté client pour la relation signer un contrat est égal à n.  Nous obtenons la modélisation suivante : 

  Si  nous  n’avions  pas  eu  la  possibilité  d’avoir  des  prospects  dans  nos  clients,  la  cardinalité  minimum  aurait  été égale à 1, et nous aurions eu comme cardinalités finales : 1, n au lieu de 0,n. 

Dans les exemples précédents, l’association n’est pas porteuse de données. Nous n’avons pas identifié de  données, propres à la relation, qui dépendent à la fois de client et de contrat. 

Dans une relation, au moins deux entités jouent. Nous n’avons analysé que les cardinalités de l’entité client.  Pour déterminer les cardinalités possibles de l’entité contrat, effectuez l’exercice suivant.  Exercice Énoncé  Supposons que dans notre SI, nous ayons distingué les entités client et contrat. 

© ENI Editions - All rigths reserved

- 9-

De plus, nous avons distingué la relation signer un contrat.  Un contrat peut être signé par plusieurs clients.  Quelles sont les cardinalités minimum, maximum possibles pour l’entité contrat ?  Solution  Pour les cardinalités de l’entité contrat, nous devrons nous poser les questions suivantes :  Une occurrence de contrat peut­elle exister sans avoir été signée par un client ? Non, un contrat en tant que tel doit  être signé par le contractant, donc il existe au moins 1 client associé à ce contrat.  Donc, la cardinalité minimum est égale à 1.  De  plus,  la  règle  de  gestion  « un  contrat  peut  être  signé  par  plusieurs  clients »  nous  indique  que  la  cardinalité  maximum n’est pas 1 mais n (n contractants pour la même occurrence de contrat).  D’où les modélisations possibles suivantes : 

  Si la règle de gestion avait été "un contrat ne peut être signé que par un et un seul client", la cardinalité  maximum de l’entité contrat aurait été égale à 1. 

d. Contrainte d’Intégrités Multiples  Les associations dont toutes les entités participantes ont des cardinalités maximum à n sont appelées Contraintes  d’Intégrité Multiples.  L’identifiant unique d’une CIM est la concaténation des identifiants des entités participant à celle­ci.  Ces associations sont généralement porteuses de données.  La modélisation d’une CIM est la suivante : 

- 10 -

© ENI Editions - All rigths reserved

 

e. De la Matrice des Dépendances Fonctionnelles aux Entités et Associations  Nous savons maintenant ce que sont les entités et les associations, mais comment allons­nous passer des règles de  gestion de la MOA et de la MDF terminée (colonne total valorisée à 0 ou 1) au schéma entités­associations ?  Cela va se faire en plusieurs étapes.  La MDF va induire toutes les entités et les CIM. Les règles de gestion nous aideront à compléter les associations du  schéma.  Règles de passage de la Matrice des Dépendances Fonctionnelles aux entités et associations Pour rappel, les lignes de la matrice recense d’une manière exhaustive les données du SI. De base, toute donnée en  ligne est une donnée cible de dépendance fonctionnelle.  Après étude, si cette donnée est une donnée source de DF, elle est aussi entrée en colonne.  Deux données A et B sont en dépendance fonctionnelle, si la connaissance de la valeur de A permet d’identifier une  et une seule valeur de B.  Leur modélisation est la suivante : Source → Cible.  1 ère étape : Il faut d’abord considérer les données source élémentaires. L’ensemble constitué  d’une donnée source  élémentaire et de ses données cible représente une entité.  La donnée source est l’identifiant de cette entité.  Les autres données cible constituent les propriétés de cette entité.  2 ème   étape :  Il  faut  ensuite  examiner  les  données  source  issues  de  rapprochement  de  données  source  élémentaires, nous les appellerons données  source  complexes. L’ensemble constitué d’une donnée source complexe  et de ses données cible représente une association, et plus particulièrement une CIM.  La donnée source complexe est l’identifiant de cette association.  Les autres données cible constituent les propriétés de cette association.  3 ème  étape : Il faut enfin reprendre les règles de gestion de la MOA pour compléter le schéma avec les associations  simples et toutes les cardinalités.  Exemple  Considérons une grande entreprise française, fondée il y a 10 ans et comportant des filiales françaises.  L’étude  de  la  gestion  du  personnel  a  permis  d’apprendre  qu’un  employé  pouvait,  durant  toute  sa  vie  professionnelle,  travailler dans la même filiale ou changer de filiale tous les 3 ans (et en particulier, les cadres y sont obligés) ; mais dans  tous les cas, il ne fera qu’une seule période dans chacune des filiales. Sa vie professionnelle est recensée dans le SI de 

© ENI Editions - All rigths reserved

- 11 -

l’entreprise avec les dates d’arrivée et de départ de chacune des filiales dans lesquelles il a travaillé.  Une filiale est constituée d’un directeur, d’un adjoint et d’au moins 10 employés (cadres et non­cadres).  Chaque employé est caractérisé par un numéro appelé code employé qui est unique pour chacun.  De même, chaque filiale est connue par un numéro unique.  Le dictionnaire de données correspondant est le suivant : 

  Ces informations nous ont permis de produire la matrice des dépendances fonctionnelles suivante : 

  Quelles sont les entités et associations qui en sont issues ?  Nous examinons d’abord les données source pour déterminer s’il y en a des complexes.  Les données source n° 35 et 38 sont élémentaires.  Donc, dans cet exemple, nous avons deux données source élémentaires qui génèreront donc des entités. 

- 12 -

●

Les  données  cible  du  code  employé  (n°35)  sont :  le  nom  de  l’employé  et  sa  date  de  naissance.  Nous  obtenons  l’entité  employé  constituée  de  l’identifiant  code  employé  et  des  propriétés  nom  employé  et  date  de  naissance  employé. 

●

La donnée cible du numéro filiale (n°38) est uniquement : la ville où se situe la filiale. Nous obtenons l’entité filiale  constituée de l’identifiant numéro de filiale et de la propriété ville filiale. 

© ENI Editions - All rigths reserved

●

La donnée source n° 42 (a travaillé) constituée de 2 données source élémentaires est donc, une donnée source  complexe. Elle va générer une Contrainte d’Intégrité Multiples : a travaillé. 

Les données cible de la relation a travaillé sont la date de début et la date de fin de travail dans la filiale.  Modélisons nos entités et notre association : 

  Notre association étant une CIM, la cardinalité maximum de chacune des entités est égale à n.  Mais les règles de gestion du SI nous le confirment aussi :  Il n’y  a  aucune  occurrence  d’employé qui n’ait jamais travaillé dans une filiale, sinon elle ne serait pas recensée dans le  fichier employé. Donc, la cardinalité minimum de l’entité employé est 1.  1 employé cadre doit changer de filiale tous les 3 ans. Ainsi, il y au moins 1 occurrence des employés qui a travaillé dans n  filiales. Donc, la cardinalité maximum de l’entité employé est n.  Dans une filiale, travaillent au moins 12 personnes. Donc, la cardinalité minimum de l’entité filiale est égale à 1.  Dans une filiale, travaillent au moins 12 personnes. Donc la cardinalité maximum de l’entité filiale est égale à n.  D’où, le MCD (schéma entités­associations) final suivant : 

 

3. Modèle Organisationnel des Données  Le  MCD,  que  l’on  vient  de  voir,  vise  à  représenter  la  signification  des  informations  utilisées  dans  le  Système  d’Information d’une entreprise.  Il ne tient pas compte des contraintes organisationnelles, économiques ou techniques. Les niveaux suivants vont donc  proposer de les étudier et de s’y adapter. 

© ENI Editions - All rigths reserved

- 13 -

En effet, l’architecture technique des SI a fortement évolué au fil des ans. D’une structure monolithique, nous sommes  passés à un développement très poussé de la technologie client­serveur, avec des bases de données relationnelles,  d’où une répartition des données et des traitements entre des clients et un ou plusieurs serveurs.  Il faut donc, très tôt, modéliser la répartition organisationnelle des données en tenant compte de leur volume, de leur  durée  de  vie,  de  leur  disponibilité  ou  de  la  manière  d’y  accéder  qui  peuvent  être  très  différents  suivant  l’unité  organisationnelle ou le profil de l’utilisateur…  Exemple :  Considérons  une  entreprise  comportant  des  filiales.  Un  exemple  de  répartition  organisationnelle  des  données  clients  peut  être la suivante :  La base de tous les clients est visible par toutes les filiales.  Les filiales n’ont le droit de mise à jour que sur leurs propres clients (extraction spécifique de la base clients). Ces mises à  jour  peuvent  être  prises  en  compte  en  temps  réel  ou  différé :  l’option  prise  dépendra  du  volume  de  données,  du  nombre  d’utilisateurs, etc. mais sera complètement indépendante de la localisation physique de la mémorisation.  Au niveau organisationnel, les contraintes physiques ne sont pas prises en compte.  Le MOD répond à ces questions.  Le MOD s’exprimera avec le même formalisme que le MCD (schéma entités­associations).  Il  est  possible,  à  ce  stade,  d’obtenir  plusieurs  schémas  entités­associations :  un  pour  chaque  division  organisationnelle  (siège  social,  annexes…)  suivant  la  totalité  ou  l’extraction  des  données  qui  leur  est  autorisée  en  mise  à  jour  et  /ou  en  consultation.  Ainsi  suivant  la  répartition  organisationnelle,  on  obtiendra 1  MOD  global  et 0  à  n  MOD locaux.  Ceux­ci  seront  complétés  d’un  texte  décrivant  les  règles  organisationnelles  à  prendre  en  compte  et  d’un  tableau  recensant les catégories d’utilisateurs et leurs restrictions d’accès sur les données.  Exemple :  Reprenons l’exemple précédent en le complétant de règles organisationnelles pour certaines entités.  Dans les filiales, tous les services peuvent consulter les clients et les contrats.  Seul le service clientèle peut créer et modifier la base client.  Seul le service juridique peut créer et modifier les contrats.  Nous obtiendrions le tableau de synthèse des droits d’accès suivants : 

 

4. Modèle Logique des Données  La  construction  du  MLD  repose  sur  les  MCD  et  MOD  en  tenant  compte  de  l’orientation  technique  choisie  pour  la  construction du SI.  Aujourd’hui, l’orientation technique la plus utilisée dans  l’informatique de gestion est l’orientation base de données  de type relationnel.  Il existe d’autres domaines de l’informatique, tels que l’informatique décisionnelle, où l’orientation prise sera  de  construire  des  entrepôts  de  données  (datawarehouse  dont  les  données  seront  issues  de  bases  de  données  relationnelles).  Sur  ces  datawarehouse,  les  utilisateurs  pourront  obtenir  des  vues  transversales,  historisées,  agrégées  ou  détaillées…  de  toutes  les  données  disponibles  de  l’entreprise,  suivant  différents  axes  d’analyse  et  adaptées  à  leurs  besoins.  Pour  ce  faire,  ils  utiliseront  des  outils  spécifiques :  datamining,  tableurs,  requêtes…  Mais  ce  n’est  pas  notre  propos,  aussi  resterons­nous  dans  le  cadre  des  bases  de  données  de  type  relationnel. 

Nous  avons  vu  que  le  MCD  reposait  sur  le  concept  de  schéma  entités­associations  avec  les  éléments  suivants :  entités, association, identifiant unique, cardinalités.  La  transformation  d’un  MCD  en  MLD  passe  par  la  transformation  de  ces  éléments.  Elle  sera  accompagnée  d’un  - 14 -

© ENI Editions - All rigths reserved

nouveau vocabulaire.  Vous  vous  posez  la  question  "Et  le  MOD,  dans  tout  cela ?".  N’oublions  que  le  MOD  est  constitué  de  MCD,  complété par des règles organisationnelles, de données volumétriques… Donc, ce qui nous importe dans cette  phase, c’est bien le passage du MCD au MLD.  Ainsi :  Chaque entité ou association du schéma entités­associations (MCD) correspond au plus à une table.  Chaque propriété de l’entité ou de la relation devient une colonne de la table.  Chaque occurrence de l’entité devient une ligne de la table.  L’identifiant  de  l’entité  (ou  de  l’association,  nous  verrons  un  peu  plus  loin  pourquoi)  constitue  la  clé  (primaire)  de  la  table.  Ces transformations reposent sur des règles bien précises, qui sont les suivantes :  Règle N° 1  Toute entité est traduite en une table relationnelle dont :  ●

Le nom de la table est le nom de l’entité, 

●

La clé de la table est l’identifiant de l’entité, 

●

Les autres attributs de l’entité forment les autres colonnes de la table. 

Règle N° 2  Toute relation binaire (ou n­aire), dont les cardinalités de chacune des entités participantes est de la forme (0,n) ou  (1,n), est traduite en une table relationnelle dont :  ●

Le nom de la table est le nom de la relation, 

●

La clé de la table est formée par la  concaténation  des  identifiants  de  chacune  des  entités  participant  à  la  relation, 

●

Les attributs de la relation forment les autres colonnes de la table. 

Règle N° 3  Toute relation binaire dont les cardinalités de l’une des entités sont de la forme (0,1) ou (1,1) et les cardinalités de  l’autre entité participante de la forme (0,n) ou (1,n) est généralement traduite par un report de clé :  ●

L’identifiant  de  l’entité  ayant  les  cardinalités  de  la  forme  (0,n)  ou(1,n)  est  ajouté  comme  colonne  supplémentaire à la table représentant l’autre entité. 

Cette nouvelle colonne est appelée clé étrangère.  Règle N°4  Toute relation binaire dont les cardinalités de l’une des entités sont de la forme (0,1) ou (1,1) et les cardinalités de  l’autre entité participante de la forme (0,1) ou (1,1) est généralement traduite par :  ●

La  fusion  des  tables,  des  entités  qu’elles  relient,  pour  n’en  faire  plus  qu’une,  contenant  les  attributs  d’une  manière exhaustive et sans redondance. 

La clé de la table résultante sera choisie parmi les 2 des tables participantes.  Les clés pourront être soulignées pour les distinguer des autres colonnes de la table et seront listées en premier.  Exemple 1  Reprenons l’exemple des employés qui travaillent dans des filiales.  Nous avions obtenu le MCD suivant : 

© ENI Editions - All rigths reserved

- 15 -

  La règle n°1 induit que nous allons créer deux tables : Employé et Filiale.  La clé de la table Employé est le Code employé (COEMP).  Les autres colonnes de cette table sont : Nom (NOEMP) et Date de naissance (de l’employé) (DNEMP).  La clé de la table Filiale est le Numéro filiale (NUFIL).  L’autre colonne de la table Filiale est la ville (de la filiale) (VILFIL).  La règle n° 2 induit que nous allons créer une table Contrat de travail (cette relation, étant transformée en table comme une  entité, prend un nom pour concrétiser ce qu’elle représente).  Cette table a pour clé : Code employé concaténé à numéro de filiale (COEMP­NUFIL).  Les colonnes de cette table sont : date début contrat (DADEB) et date de fin de contrat (DAFIN).  En synthèse, nous obtenons 3 tables que nous pouvons représenter littéralement (le plus usité) :  ●

Employé (Code employé, Nom, Date de naissance) 

●

Filiale (N° filiale, Ville) 

●

Contrat de travail (Code Employé, N°filiale, Date début contrat, Date fin contrat) 

Ou modéliser : 

  Exemple 2  Considérons le SI d’une entreprise de Vente Par Correspondance.  Cette entreprise propose des produits de différentes catégories : Habillement, Electroménager, Son, Vidéo…  Une catégorie est recensée dans le SI par son code (COCAT) et sa dénomination (DECAT).  Une catégorie particulière (une occurrence de catégorie) englobe au moins 1 produit et au plus n produits.  Un produit (caractérisé par son numéro NUPROD et son libellé LIBPROD) vendu par correspondance appartient à une et une  seule catégorie. 

- 16 -

© ENI Editions - All rigths reserved

Le schéma Entités­Associations correspondant est le suivant : 

  La règle n°1 induit que nous allons créer 2 tables : Catégorie et Produit.  La clé de la table Catégorie est le Code catégorie (COCAT).  L’autre colonne de cette table est la dénomination de la catégorie : LIBCAT.  La clé de la table Produit est le Numéro de produit (NUPROD).  L’autre colonne de la table Produit est le libellé produit (LIBPROD).  La règle n° 3 induit que nous allons ajouter une colonne supplémentaire dans la table Produit : la clé de la table Catégorie :  COCAT.  Un  produit  appartient  à  une  et  une  seule  catégorie.  Nous  avons  bien  une  dépendance  fonctionnelle  entre  le  code  produit  (source) et le code catégorie (cible).  Nous retrouvons dans la table produit : une clé primaire (NUPROD) et une clé étrangère (COCAT).  La clé étrangère sera soulignée en pointillé.  En synthèse, nous obtenons 2 tables que nous pouvons représenter littéralement :  ●

Catégorie (code catégorie, Dénomination catégorie) 

●

Produit (N° produit, libellé produit, code catégorie) 

Ou modéliser : 

  Exemple 3  Considérons le SI d’un comité d’entreprise qui propose un service de bibliothèque aux employés.  Les employés de l’entreprise sont recensés dans le SI en tant qu’adhérents de la bibliothèque.  Un employé est caractérisé par un numéro employé unique et son nom.  Un adhérent est caractérisé par un numéro adhérent unique et le nom de l’employé.  Les règles de gestion sont les suivantes :  ●

Un employé est ou n’est pas un adhérent de la bibliothèque. Un employé ne peut prendre qu’une seule adhésion. 

© ENI Editions - All rigths reserved

- 17 -

●

Un adhérent de la bibliothèque correspond à un et un seul employé. 

Le schéma entités­associations lié est le suivant : 

  La règle n°4 induit que nous allons créer une seule table : Adhérent ou Employé.  Nous privilégions Adhérent puisque c’est le SI de la bibliothèque du comité d’entreprise.  Quelle va être la clé de cette table ?  Nous avons le choix entre une clé qui existe déjà : le numéro de l’employé et une clé à créer : le numéro de l’adhérent.  Or, pour un numéro d’employé, il y a un et un seul numéro d’adhérent associé. Il vaut mieux conserver ce qui existe déjà et  qui représente une réalité : le numéro d’employé.  La clé de la table Adhérent sera : le Code employé (COEMP).  L’autre colonne de cette table sera le nom de l’employé (NOEMP).  En synthèse, nous obtenons une table que nous pouvons représenter littéralement :  ●

Adhérent (Numéro employé, Nom employé) 

Ou modéliser : 

  Attention,  le  passage  du  schéma  Entités­Associations  (MCD)  au  MLD  passe  aussi  nécessairement  par  la normalisation : traduction du MLD en tables normalisées. 

La  normalisation  a  pour  but  de  structurer  les  données,  de  telle  façon  qu’elles  soient  logiquement  organisées,  en  supprimant toute redondance d’informations.  Nous traiterons ce point plus en détail, dans le dernier chapitre.  Attention, la prise en compte des volumes de données, des types et des fréquences d’accès sur la base de  données… par l’Administrateur de la Base de Données (ou DBA : Data Base Administrator), peut entraîner une  légère dénormalisation de la base à cette étape. En effet, pour optimiser les traitements, il peut être nécessaire de  réintroduire une redondance de données dans une table pour accélérer les temps d’accès. Pour en savoir plus, je  vous invite à consulter des traités sur l’optimisation d’une base de données relationnelle. Bonne lecture ! 

5. Modèle Physique des Données  Enfin, quand le MLD est stabilisé, il faut passer à l’étape du Modèle Physique de Données, en implémentant la base de 

- 18 -

© ENI Editions - All rigths reserved

données avec le SGBD choisi (Oracle, DB2 d’IBM…).  Rappelons qu’à cette étape, la description de la base de données sera faite avec le vocabulaire, la syntaxe du futur  Système de Gestion de bases de Données choisi et les outils proposés par celui­ci.  Exemple 1  Reprenons la description de la table Employé vue précédemment.  Le MLD de cette table est le suivant : 

  Rappelons­nous le dictionnaire des données correspondant : 

  Un exemple de description de la table Employé dans une base Oracle se fera de la manière suivante, via un script .sql et avec  utilisation d’un Langage de Description des Données :  Create table EMPLOYE ( COEMP number(5) not null, NOEMP Char(30) not null, DNEMP date ); Add constraint PK_EMPLOYE primary key (COEMP) using index tablespace TEST_INDEX; Exemple 2  La  description  de  la  même  table  Employé  dans  une  base  Access  peut  se  faire  de  trois  manières,  en  utilisant  l’Interface  Homme­Machine (IHM) : 

 

© ENI Editions - All rigths reserved

- 19 -

Via  cette  IHM,  la  table  Employé  précédente  pourra  être  créée  sans  connaître  la  syntaxe  d’un  Langage  de  Description  des  Données particulier. La création de la table sera plus simple que dans l’environnement Oracle.  Nous vous laissons le soin d’expérimenter les trois manières de créer une table sous Access. 

- 20 -

© ENI Editions - All rigths reserved

Synthèse  Ce chapitre nous a fait percevoir que la création d’un SI de qualité suit un cheminement bien précis, qui doit être dicté  par une méthode.  En  informatique  de  gestion,  les  bases  de  données  seront  structurées  sous  forme  relationnelle.  La  méthode  Merise,  bien que datant des années 80, est encore d’actualité dans ce cadre.  Pour ce faire, de l’expression des besoins utilisateurs à l’implémentation de la Base de Données, l’informaticien suivra  les étapes suivantes :  ●

Expression des besoins ; 

●

Dictionnaire des données ; 

●

Matrice des Dépendances Fonctionnelles ; 

●

Schéma  entités­associations  et  valorisation  des  cardinalités  minimum  et  maximum,  dont  sera  issu  le  Modèle  Conceptuel des Données ; 

●

Étude organisationnelle dont découleront les Modèles Organisationnels de Données ; 

●

Traduction du MCD en tables de la future base de données (Modèle Logique de Données) ; 

●

Enfin, via le Modèle Physique des Données : description des tables en langage du SGBDR choisi et génération  de la Base de Données. 

Dans les chapitres suivants, nous reviendrons sur le schéma entités­associations et plus particulièrement sur l’algèbre  relationnelle.  Nous  allons  découvrir  comment  normaliser  un  schéma,  quels  sont  les  opérateurs  de  l’algèbre  relationnelle  qui  permettront d’extraire des informations pertinentes à partir des données de la base de données relationnelle. 

© ENI Editions - All rigths reserved

- 1-

Exercice  1. Énoncé  Reprenons  la  MDF  de  l’extraction  des  données  d’un  système  de  gestion  de  trains :  nombre  de  voyageurs,  date,  horaire, code train…  Les règles de gestion sont les suivantes :  ●

Un  code  train  (COTRIN)  détermine  de  manière  unique  l’horaire  de  départ  de  ce  train  (HDTRIN)  et  l’heure  d’arrivée (HATRIN), sa catégorie : TGV, Corail… (TYTRIN). 

●

Par contre, un code train ne détermine pas d’une manière unique la date de circulation de ce train (DTRIN). Un  train peut circuler tous les jours ou uniquement le week­end et/ou les jours fériés… 

●

La  date  de  jour  de  circulation  du  train  définit  d’une  manière  unique  le  type  de  date  (veille  de  fête  ou  pas)  (TYDATE). 

●

Mais  une  date  de  jour  de  circulation  définit  au  moins  un  train  en  circulation  (sinon  cette  date  ne  serait  pas  recensée) mais pas obligatoirement un et un seul train. Dans une journée, il y a n occurrences de train qui  circulent. 

●

Enfin, le code train ne détermine pas de manière unique le nombre de voyageurs (NBVOY) qui sont dans ce  train. Ce nombre peut être différent à chaque date de circulation. 

Nous en avions déduit la matrice des dépendances fonctionnelles suivante : 

  1. 

Quelles sont les entités et associations qui en sont issues ? 

2. 

Modéliser le schéma entités­associations 

3. 

Réaliser le Modèle Logique de Données. 

2. Solution  1. 

Nous examinons d’abord les données source pour déterminer s’il y en a des complexes.  Nous avons deux données source élémentaires : code train (n° 37) et date train (n° 41).  La donnée source n° 44 est constituée d’une concaténation de deux données source,  donc elle est une donnée source complexe. En effet, elle est constituée de la donnée  source élémentaire COTRIN et de la donnée source élémentaire DTRIN.  Donc, dans cet exemple, nous avons deux données source élémentaires qui génèreront  des entités et une donnée source complexe qui génèrera une association porteuse de  données.  Les données cible du code train (n° 37) sont : l’heure de départ, l’heure d’arrivée et sa  catégorie.  Nous obtenons l’entité train générique constituée de l’identifiant code train et des  propriétés heure de départ train, heure d’arrivée train et catégorie de train. 

© ENI Editions - All rigths reserved

- 1-

La donnée cible de date train (n° 41) est le type de jour (TYDATE). Nous obtenons l’entité  date générique constituée de l’identifiant code date et de la propriété type de jour.  Nous obtenons une relation CIM représentative du train circulant à telle date avec pour  identifiant le code train et la date de circulation et pour propriétés : le nombre de  voyageur.  2.  Nous en déduisons le début de MCD suivant : 

  Complétons­le avec les cardinalités liées au règles de gestion.  Un train peut circuler tous les jours ou uniquement le week­end et/ou les jours fériés…  Donc, il peut exister une occurrence de train qui ne circule pas à une date donnée →  cardinalité minimum à 0.  Et une occurrence de train n’est pas mise en circulation qu’à une seule date → cardinalité  maximum à n.  De plus, une date de jour de circulation définit au moins un train en circulation →  cardinalité minimum à 1.  Et dans une journée, il y a n occurrences de train qui circulent → cardinalité maximum à n.  Nous complétons le MCD : 

 

3. 

- 2-

La règle n°1 induit que nous allons créer deux tables : Train et Date de circulation.  La clé de la table Train est le Code train. Les autres colonnes de cette table sont : Heure  de départ, Heure d’arrivée et catégorie (du train).  La clé de la table Date de circulation est le date du jour (jour, mois, année). L’autre  colonne de la table Date de circulation est le type de jour. 

© ENI Editions - All rigths reserved

La règle n° 2 induit que nous allons créer une table Train circulant (cette association étant  transformée en table comme une entité, prend un nom pour concrétiser ce qu’elle  représente).  Cette table a pour clé : Code train concaténé à Date de circulation.  Les colonnes de cette table sont : Nombre voyageurs.  En synthèse, nous obtenons trois tables que nous pouvons représenter ainsi : 

  Ou littéralement :  ●

Train (Code train, Heure départ, Heure d’arrivée, catégorie) 

●

Date de circulation (Date du jour, Type de jour) 

●

Train circulant (Code train, Date du jour, Nombre de voyageurs) 

© ENI Editions - All rigths reserved

- 3-

Introduction  C’est un informaticien britannique Edgar Frank Codd (décédé en avril 2003) qui est l’inventeur du modèle relationnel,  basé sur l’algèbre relationnelle.  Dans les années 70, les bases de données non relationnelles (modèle hiérarchique…) suffisaient pour gérer les volumes  de  données  de  l’époque ;  mais  elles  avaient  des  limites  pour  les  très  gros  volumes,  telles  que  la  redondance  de  données,  la  non  garantie  de  l’intégrité  des  données,  etc.  Mathématicien  (et  chimiste)  de  formation,  E.  F.  Codd,  qui  travaillait  chez  IBM,  utilisa  ses  connaissances  mathématiques  (et  en  particulier,  la  théorie  des  ensembles)  pour  concevoir son modèle relationnel qui devait faire disparaître ces inconvénients. Ce modèle qu’il présenta dans l’article "A  relational Model of Data for Large Shared Data Banks" (Un modèle relationnel de données pour les banques de données à  grande consultation) de juin 70 ne fut pas exploité tout de suite par IBM mais par d’autres entreprises, telles qu’Oracle,  et avec bonheur.  Dans cet article, E. F. Codd décrivait les 12 règles que, d’après lui, devait obligatoirement suivre un système de gestion  de  bases  de  données  pour  être  relationnel.  Ce  modèle  relationnel,  bien  que  datant  de  plusieurs  décennies,  sert  toujours de fondement aux bases de données relationnelles.  Nous avons vu, dans les chapitres précédents, comment en partant de l’expression des besoins des utilisateurs, nous  arrivions  à  décrire  les  tables  qui  porteront  les  données  de  la  future  base  de  données,  via  le  Modèle  Logique  des  Données  (MLD) ;  mais  si  nous  voulons  que  ce  MLD  génère  une  base  de  données  réellement  relationnelle,  il  faut  que  celui­ci repose sur les concepts de l’algèbre relationnelle inventée par E. F. Codd.  Or,  l’algèbre  relationnelle  introduit  le  fait  que  ces  tables,  par  lesquelles  les  utilisateurs  voient  et  manipulent  les  données, doivent être perçues comme des relations, au sens mathématique du terme.  En  effet,  l’algèbre  est  une  "partie  autonome  de  la  mathématique  attachée  à  l’étude  d’ensembles  constitués  d’autres  éléments  (objets  géométriques,  probabilités,  espaces  topologiques…  )  et  qui  emploie,  à  la  place  des  opérations  courantes, les lois de composition (interne ou externe) dont la combinaison détermine les structures algébriques" (cf Le  Robert).  Dans le cas de l’algèbre relationnelle, nous appliquerons des opérations (union, intersection, projection, sélection…) sur  des relations (tables) pour obtenir une nouvelle relation (table).  Ce  chapitre  va  nous  permettre  de  découvrir  les  concepts  fondamentaux  de  l’algèbre  relationnelle  tels  que :  domaine,  attribut, relation, tuple, schéma de relation, clé de relation et base de données relationnelles.  Pour  mieux  les  assimiler,  nous  découvrirons  comment  les  construire  à  partir  de  nos  bases  de  travail  provenant  des  chapitres précédents. 

© ENI Editions - All rigths reserved

- 1-

Concepts  Nous allons les découvrir d’une manière progressive ; chaque concept participant à la construction ou à la qualification  d’un concept supérieur. 

1. Domaine  Le  concept  de  base  de  l’algèbre  est  l’ensemble,  c’est  une  collection  d’éléments  cohérents  liés  par  une  condition  permettant de définir leur appartenance à ce groupe. Dans l’algèbre relationnelle, on parlera de domaine.  Un domaine est un ensemble de valeurs. On le représentera de la manière suivante : D = {v1,v2,…vn}.  Un domaine peut être un sous­ ensemble d’un autre domaine.  Exemples :  Le domaine des booléens : Db = {0,1}.  Le domaine des couleurs primaires : Dcp = {jaune, rouge, bleu}.  Le domaine des couleurs spectrales, issues de la décomposition de la lumière solaire par un prisme : Ds = {violet, indigo,  vert, bleu, jaune, rouge, orangé}.  Nous  remarquons  que  dans  l’exemple  précédent,  les  couleurs  rouge,  jaune  et  bleu  appartiennent  à  deux  domaines différents issus du domaine Couleurs, plus général. En effet, c’est la définition du domaine (ou son  rôle, c’est­à­dire ce qu’il représente) qui permet de relier les différents éléments et de les faire appartenir à tel ou  tel domaine qui peut être un sous­ensemble d’un domaine ayant un rôle plus générique. 

2. Produit cartésien  Le  produit  cartésien  de  n  domaines  D1,  D2,…  Dn  est  l’ensemble  des  n_uplets    tel  que  vDi  appartienne à Di.  Ce produit cartésien est noté D1xD2x…Dn.  Exemple :  Le  produit  cartésien  du  domaine  des  booléens  avec  le  domaine  des  couleurs  primaires,  soit  DbxDcp,  va  être  constitué  de  2_uplets (paires) dont la première valeur appartiendra à Db et la deuxième à Dcp.  DbxDcp = {(0, rouge),(0, jaune), (0, bleu), (1, rouge), (1, jaune), (1, bleu)}. 

3. Tuple  Un tuple est une liste de valeurs provenant de domaines.  Donc, un n­uplet issu d’un produit cartésien de n domaines est un tuple.  Exemple 1 :  Si  nous  considérons  le  produit  cartésien  DbxDcp  de  l’exemple  précédent,  nous  avons  6  tuples :<0,  rouge>,  <0,  jaune>,  <0,bleu>, <1, rouge>, <1, jaune>, <1,bleu>.  Exemple 2 :  Si nous considérons le tuple suivant : < 101, BRANY, POITIERS, 28/10/1990>  Ce tuple contient des valeurs issues des domaines, N° élève, Nom, Ville, Date, suivants : 

© ENI Editions - All rigths reserved

- 1-

  Ce tuple est issu du produit cartésien Numéro élève x Nom x Ville x Date.  Ce tuple exprime le fait que l’élève qui est identifiée par le numéro élève 101, s’appelle Brany, réside à Poitiers, est née le  28/10/1990. 

4. Relation  Nous arrivons enfin au concept le plus important de l’algèbre relationnelle. 

a. Définition et caractéristiques d’une relation  Une relation est un sous­ensemble du produit cartésien de n domaines (n>0).  Une relation est un ensemble de tuples. Une relation a de 0 à n tuple(s).  Pourquoi parle­t­on de sous­ensemble de produit cartésien ?  Parce  que  la  relation  n’est  pas  obligatoirement  l’ensemble  exhaustif  de  tous  les  n_uplets  créés  par  le  produit  cartésien.  Exemple :  Considérons le tuple issu du produit cartésien Numéro élève x Nom x Ville x Date de naissance.  D’après le format utilisé, le domaine Date comprend les dates de 01/01/0001 à 31/12/9999.  L’ensemble  des  tuples,  issus  du  produit  cartésien,  est  exhaustif  mais  les  tuples  avec  une  date  de  naissance  égale  à  31/12/9999 ne peuvent pas appartenir à la relation ELEVE. En effet, cette valeur n’appartient pas au domaine des valeurs  réellement possibles pour une date de naissance d’un élève.  Donc notre relation ELEVE est bien un sous­ensemble du produit cartésien Numéro élève x Nom x Ville x Date.  Toute relation est déterminée par son nom.  Chaque domaine participant au produit cartésien est appelé attribut de la relation.  Une relation a de 1 à n attribut(s).  Un attribut contiendra des valeurs appartenant au même domaine.  En  pratique,  le  domaine  d’appartenance  permet  de  typer  les  valeurs  prises  par  l’attribut :  numérique,  alphanumérique, booléen… Cela ne vous rappelle pas une colonne du dictionnaire de données ? 

L’ordre de déclaration des attributs d’une relation n’a pas d’importance.  Lorsque plusieurs attributs prennent leurs valeurs dans le même domaine, le rôle des attributs doit être précisé et  leurs noms doivent être différents. À l’intérieur d’une relation, chaque attribut a un nom unique.  Exemple :  Considérons le tuple suivant : <101, BRANY, LAVAL, POITIERS, 28/10/1990, 25/06/2006>  Ce tuple contient des valeurs issues des domaines, N° élève, Nom, Ville, Date, suivants : 

- 2-

© ENI Editions - All rigths reserved

  Ce tuple est issu du produit cartésien Numéro élève x Nom x Ville x Ville x Date x Date.  Il y a deux attributs ville qui prennent leurs valeurs dans le domaine Ville. Il faut donc définir plus précisément le rôle de  chacun : ville de naissance et ville de résidence.  De même, il y a deux attributs date qui prennent leurs valeurs dans le domaine Date. Il faut donc définir plus précisément  le rôle de chacun : date de naissance et date d’inscription.  Ainsi, ce tuple exprime le fait que l’élève qui a le numéro élève 101, s’appelle Brany, est née à Laval le 28/10/1990, réside  à Poitiers et est inscrite au lycée depuis le 25/06/2006.  La relation peut être exprimée sous deux formats : en intention ou en extension. 

b. Relation en intention : schéma de Relation  Les caractéristiques précédentes vont être reprises dans le schéma de la relation.  Un schéma de relation est le nom de la relation suivi de ses attributs et de leurs domaines d’appartenance.  Exemple :  La relation ELEVE est un sous­ensemble du produit cartésien Numéro élève x Nom x Ville de naissance x Ville de résidence  x Date de naissance x Date d’inscription et a pour relation :  ELEVE(Numéro élève : Nombre, Nom : Nom, Ville de naissance : Ville, Ville de résidence : Ville, Date de naissance : Date,  Date d’inscription : Date).    Pour alléger l’écriture, le schéma de relation se limite souvent au nom de la relation suivi de ses attributs. En effet, n’oublions pas que les attributs que nous manipulons sont des éléments du dictionnaire de données dans  lequel le format et le type sont précisés. Il sera facile de les typer, en se référant au dictionnaire.  Exemple :  La  relation  ELEVE(Numéro  élève :  Nombre,  Nom :  Nom,  Ville  de  naissance :  Ville,  Ville  de  résidence :  Ville,  Date  de  naissance : Date, Date d’inscription : Date) peut être allégée :  ELEVE(Numéro élève, Nom ,Ville de naissance, Ville de résidence, Date de naissance, Date d’inscription )  où :  ●

Numéro élève fait bien référence à du numérique. 

●

Nom, Ville de résidence, Ville de naissance font référence à de l’alphanumérique. 

●

Date de naissance, Date de d’inscription font référence au format Date. 

c. Relation en extension : Relation sous forme tabulaire  Quand la relation est exprimée en intention, ses tuples ne sont pas visibles. Par contre, la présentation de la relation  en extension permet de les lister.  La relation en extension est représentée sous forme de tableau. Les lignes de la table sont les tuples.  Chaque colonne de la table contient les valeurs d’un et un seul domaine. 

© ENI Editions - All rigths reserved

- 3-

  Exemple :  La représentation en extension de la relation ELEVE est la suivante : 

  Vous  remarquez  que  cette  forme,  bien  que  semblant  plus  complète  que  la  relation  en  intention,  n’est pas  lisible facilement et ne sera pas exploitable si votre relation contient des millions de tuples. 

Entre  les  deux  possibilités  de  présentation  d’une  relation,  le  schéma  de  relation  est  le  plus  pratique  et  le  plus  complet.  Vous  remarquerez  que  les  relations  en  intention  et  en  extension  correspondent  aux  deux  manières  de  modélisation des tables du MLD, vues dans le chapitre Modélisation des données. 

d. Clé de relation  Nous  terminerons  la  présentation  du  concept  de  relation  par  un  de  ses  éléments  le  plus  important :  la  clé  de  relation.  Une clé de relation est un attribut ou une composition minimale d’attributs dont chacune des valeurs permet de  déterminer, d’une manière unique, un tuple de la relation.  Ainsi,  la  valeur  d’une  clé  (mono­attribut  ou  combinaison  minimale  d’attributs)  de  relation  ne  peut  exister  qu’une  seule fois dans la relation en extension.  Que veut dire combinaison minimale ?  Cela veut dire qu’aucun attribut ne peut être ôté de cette combinaison, sinon elle perdrait sa nature d’identifiant.  La clé de relation, qu’elle soit décrite en intention ou extension, sera soulignée.  Clés candidates et clé primaire Dans une relation, il peut y avoir plusieurs attributs ou compositions d’attributs qui permettent de déterminer, d’une  manière unique, un tuple de la relation ; mais il n’y a qu’une seule clé de relation.  Ces attributs ou ces compositions d’attributs sont donc susceptibles de devenir clé de relation. Ils sont appelés clés  candidates.    Les clés candidates n’ont pas obligatoirement toutes le même nombre d’attributs.

Il n’y a qu’une seule clé par relation. Il faut donc faire un choix parmi les clés candidates. Ce choix se fera non pas  par rapport aux attributs entre eux mais au SI entier : à son métier, ses traitements, à ses fonctionnalités…  La clé de la relation choisie, elle sera appelée la clé primaire de la relation. 

- 4-

© ENI Editions - All rigths reserved

Exemple 1 :  Considérons le SI d’un établissement d’enseignement et la relation ELEVE suivante :  ELEVE(Numéro élève, Nom élève ,Ville de naissance, Ville de résidence, Date de naissance, Date d’inscription ).  Il n’existe pas dans la relation ELEVE deux tuples ayant la même valeur pour l’attribut Numéro élève.  En extension, elle se présente de la manière suivante : 

  Quelles sont les clés candidates ?  La première clé candidate qui nous vient à l’esprit est le numéro d’élève qui a toutes les propriétés d’un identifiant.  Est­ce qu’un autre attribut isolé peut être susceptible de devenir la clé de la relation ?  Il peut exister des homonymes.  Il peut exister, dans l’établissement, des enfants ayant la même ville de naissance et la même ville de résidence.  Il peut exister, dans l‘établissement, des enfants dont la date de naissance et/ou la date d’inscription soient identiques.  Aucun des autres attributs de la relation, pris isolément, ne peut être considéré comme une clé candidate.  Bien sûr, toute composition d’attributs avec numéro d’élève permettrait d’identifier un élève d’une manière unique ; mais  nous n’aurions plus une combinaison minimale d’attributs puisqu’en enlevant l’attribut supplémentaire, le numéro d’élève  conserverait sa propriété d’identifiant.  La combinaison nom­ville de naissance n’est pas une clé : il peut exister des jumeaux de même nom et de même ville de  naissance.  Le  même  raisonnement  peut  être  appliqué  à  la  combinaison  nom­ville  de  naissance­ville  de  résidence,  donc  celle­ci  non  plus, n’est pas une clé candidate.  Le même raisonnement peut être appliqué à la combinaison nom­ville de naissance­ville de résidence­date de naissance,  donc celle­ci non plus n’est pas une clé candidate.  Nous constatons que quelle que soit la combinaison d’attributs choisis, nous n’avons pas la garantie de ne pas avoir des  valeurs en double, pour cette clé, dans la relation.  Quelle pourrait être la clé primaire ?  Donc, la seule clé primaire que nous pouvons choisir et que nous choisissons est : numéro élève.  La  relation  ELEVE  s’écrira :  ELEVE(Numéro élève,  Nom  élève,  Ville  de  naissance,  Ville  de  résidence,  Date  de  naissance,  Date d’inscription).  Exemple 2 :  Considérons la gestion du parc informatique d’une entreprise.  Les employés sont identifiés d’une manière unique par leur numéro.  Tous les employés ont un seul poste de travail attitré et chaque poste de travail n’appartient qu’à un et un seul employé.  Ce poste de travail peut être un ordinateur de bureau (disque dur + écran) ou un portable. Pour la maintenance du parc, ce  poste de travail est aussi numéroté, chaque numéro est unique.  Nous avons créé la relation TRAVAILLEUR(Numéro employé, Numéro poste de travail, Désignation poste de travail).  En extension, elle se présente ainsi : 

© ENI Editions - All rigths reserved

- 5-

  Quelles sont les clés candidates ? Quelle pourrait être la clé primaire ?  Chaque numéro d’employé est unique donc pour une valeur de numéro employé, il n’y aura qu’une seule occurrence dans  la relation TRAVAILLEUR.  L’attribut numéro employé est clé candidate de cette relation.  Mais chaque numéro de poste est églament unique et n’appartient qu’à un seul employé, donc pour une valeur de numéro  poste de travail, il n’y aura qu’une seule occurrence dans la relation TRAVAILLEUR.  Donc, l’attribut numéro de poste de travail est clé candidate de cette relation.  Il faut choisir une seule clé primaire.  Il faut choisir celle qui sera le plus sollicitée dans les traitements.  Si la manipulation des occurrences de cette relation se base sur la connaissance du numéro d’employé, pour l’optimisation  des accès physiques à la future base de données, il faut alors prendre le numéro employé comme clé primaire.  Si  cette  relation  est  beaucoup  plus  utilisée  pour  la  gestion  (suppression,  création…)  des  postes  de  travail,  il  faut  alors  privilégier l’attribut numéro poste de travail comme clé primaire.  Le choix de la clé primaire dépend de la manière dont sera utilisée la relation (future table) dans la future  base de données. 

5. Base de données relationnelle  Une base de données relationnelle est un ensemble exhaustif et cohérent de schémas de relations.  Pourquoi  cohérent ?  Cet  ensemble  de  tables  doit  répondre  à  la  problématique  du  Système  d’Information  qu’il  représente et ne pas contenir des schémas de relation qui lui sont étrangers.  Exemple :  La  base  de  données  relationnelle  des  produits  d’une  entreprise  industrielle  pourra  comporter  les  schémas  de  relation  suivants :  ●

PRODUIT(N°Produit, Libellé, Date de fabrication, Prix) avec N° produit comme clé primaire. 

●

ARTICLE(N°Article, Libellé, QuantitéenStock) avec N° article comme clé primaire. 

●

NOMENCLATURE(N°Produit,  N°Article,  Quantité)  avec  N°  produit­N°article  (composition  d’attributs)  comme  clé  primaire. 

Mais  le  schéma  de  relation  ELEVE(Numéro  élève,  Nom ,Ville  de  naissance,Ville  de  résidence,  Date  de  naissance,  Date  d’inscription) n’y figurera pas ! Cette relation n’appartient pas à ce domaine d’études. 

- 6-

© ENI Editions - All rigths reserved

Création d’une base de données relationnelle  1. Les étapes de construction  L’assimilation des concepts précédents passe par leur apprentissage.  Dans les chapitres précédents, nous avons préparé nos fondations, maintenant nous allons construire notre base de  données relationnelle dessus. 

a. Étude du dictionnaire de données  La première étape de l’étude d’un système d’information est la réalisation du dictionnaire de données.  Ce dictionnaire des données contient toutes les données pertinentes du SI. Elles sont toutes caractérisées par un  type et un format. Ces données peuvent prendre des valeurs.  Donc, le dictionnaire des données est aussi l’inventaire des domaines de valeurs utiles au SI. 

b. Étude de la Matrice des Dépendances Fonctionnelles  Dans une deuxième étape, nous réalisons la MDF à partir de l’analyse des données du dictionnaire des données et  des règles de gestion du SI.  Cette matrice est constituée :  ●

de lignes qui sont les données, 

●

de  colonnes  regroupant  des  données  (mais  qui  sont  aussi  des domaines  de  valeurs)  liées  entre  elles  par  une relation de dépendance fonctionnelle, avec une donnée source et des données cible. 

Les tables issues de la MDF et du schéma entités­associations Dans  le  chapitre  Modélisation  des  données,  nous  avons  extrait  de  cette  matrice  et  plus  particulièrement  de  ses  colonnes,  des  entités  (provenant  des  données  source  élémentaires  et  leur(s)  cible(s))  et  des  CIM  (provenant  des  données source complexes et leur(s) cible(s)).  Les entités et les CIM sont les éléments constitutifs du schéma entités­associations, base du MCD de Merise. Que ce  soit  une  entité  ou  une  CIM,  nous  avions  démontré  que  chacune  portait  un  identifiant  (donnée(s)  source)  et  des  propriétés (donnée(s) cible).  Ensuite, le passage du Modèle Conceptuel au Modèle Logique va permettre de définir des tables, à partir des entités  et des CIM. Chaque entité ou CIM du schéma entités­relations (MCD) va donner lieu à une table.  Chaque propriété (donnée de la MDF) de l’entité ou de la CIM devient une colonne de la table.  Chaque occurrence de l’entité devient une ligne de la table.  L’identifiant de l’entité ou de la CIM constitue la clé primaire de la table.  L’ensemble de toutes les tables constituera la base de données relationnelle du Système d’Information étudié.  Les relations issues directement de la MDF et de l’algèbre relationnelle À  partir  de  nos  nouvelles  connaissances  en  algèbre  relationnelle,  nous  pouvons  étudier,  sous  un  nouvel  angle,  la  MDF.  Chacune  de  ses  colonnes  représente  un  ensemble  constitué  d’une  donnée  qui  est  source  de  dépendance  fonctionnelle et de toutes les autres données qui sont cible de cette dépendance fonctionnelle.  Or, une donnée est un ensemble de valeurs.  Exemple :  Le nom de chaque client d’une entreprise n’est pas toujours identique. Il y aura des Dupont, des Riviere … Nous pouvons  considérer que les noms de tous les clients d’une entreprise constituent un ensemble de valeurs : nom {Dupont, Riviere,  Martin, Clouse…}.  Nous avons vu dans un paragraphe précédent que chacun de ces ensembles de valeurs est un domaine. 

© ENI Editions - All rigths reserved

- 1-

Donc, chaque colonne représente un produit cartésien de domaines.  Donc, chaque colonne est une relation dont chaque donnée constitutive (ou domaine) est, suivant la définition, un  attribut.  De plus, nous savons qu’une clé de relation est un attribut ou une composition minimale d’attributs dont chacune des  valeurs permet de déterminer d’une manière unique un tuple de la relation.  Donc, une clé de relation de chaque relation est le domaine source de dépendance fonctionnelle :  ●

Si c’est un domaine source élémentaire, il n’y aura qu’un seul attribut, 

●

Si c’est un domaine source complexe, il y aura de 1 à n attribut(s). 

Nous affinons cette assertion car nous savons qu’il peut exister 1 ou n clés candidates et que la clé primaire est une  des clés candidates choisies.  La MDF nous permet de déterminer la clé candidate qui correspond le mieux aux règles de gestion du SI.  Donc,  la  clé  primaire  de  chaque  relation  est  le  domaine  source  de  dépendance  fonctionnelle  (mono­attribut  ou  multi­attribut).  L’ensemble  de  toutes  les  relations  issues  de  la  MDF,  constituera  la  base  de  données  relationnelle  du  Système  d’Information étudié.  Conclusion Faisons un parallèle des concepts utilisés dans la modélisation de tables et dans la modélisation de relations. 

  Remarquez  l’importance  de  la  MDF !  L’exactitude  de  votre  Matrice  des  Dépendances  Fonctionnelles  est  la  pierre angulaire de la qualité de votre futur SI et de sa base de données. 

- 2-

© ENI Editions - All rigths reserved

En conclusion, nous pouvons dire qu’une table issue du schéma entité­associations est l’équivalent d’une relation  au sens de l’algèbre relationnelle.  Nous pourrons, ainsi, appliquer sur les tables ou relations, les opérations de l’algèbre relationnelle pour obtenir de  nouvelles relations ou tables répondant à un besoin précis de l’utilisateur. 

2. Mise en œuvre  Mettons en pratique nos nouvelles connaissances.  Nous  allons  reprendre  l’exemple  développé  dans  le  chapitre  Modélisation  des  données.  La  problématique  est  la  suivante :  Nous considérons une grande entreprise française, fondée il y a 10 ans et comportant des filiales françaises.  L’étude de la gestion du personnel a permis d’apprendre qu’un employé pouvait, durant toute sa vie professionnelle,  travailler dans la même filiale ou changer de filiales tous les 3 ans (et en particulier, les cadres y sont obligés). Mais  dans tous les cas, il ne fera qu’une seule période dans chacune des filiales. Sa vie professionnelle est recensée dans  le SI de l’entreprise avec les dates d’arrivée et de départ de chacune des filiales dans lesquelles il a travaillé.  Une filiale est constituée d’un directeur, d’un adjoint et d’au moins 10 employés (cadres et non cadres).  Chaque employé est caractérisé par un numéro appelé code employé qui est unique pour chacun.  De même, chaque filiale est connue par un numéro unique.  Un extrait du dictionnaire de données est le suivant : 

  Quels sont les éléments fournis par le dictionnaire des données qui nous intéressent pour notre étude ?  Nous avons des données qui ont un type et un format. Ces données peuvent prendre des valeurs.  Nous sommes donc, en présence de domaines de valeurs.  Exemple :  COEMP : Code employé a un format de 5 caractères, il est numérique. S’il n’est pas indiqué dans les règles de gestion que le  code  employé  est  différent  de  zéro,  les  valeurs  prises  par  code  employé  appartiennent  à  l’ensemble  suivant :  {00000,00001,..,99999}, qui est considéré en algèbre relationnelle comme un domaine. C’est le domaine des nombres à 5  chiffres : format 5 caractères, type numérique. Le Numéro de filiale appartient au même domaine.  NOMEMP : Nom employé a un format de 30 caractères et est de type alphanumérique. Les valeurs prises par Nom employé  appartiennent à l’ensemble suivant {AA…A (A répété 30 fois), AA…B (A répété 29 fois et B 1 fois), AA… C (A répété 29 fois et  C 1fois),… ZZ…Z (Z répété 30 fois)}. C’est le domaine des noms à 30 lettres ou chiffres ou symboles ou blanc : format 30  caractères, type alphanumérique..  VILFIL : Ville filiale a un format de 50 caractères et est de type alphanumérique. De base, les valeurs prises par Ville filiale  appartiennent à l’ensemble suivant {AA…A (A répété 50 fois), AA…B (A répété 49 fois et B 1 fois), AA… C (A répété 49 fois et  C 1fois),… ZZ…Z (Z répété 50 fois)}. C’est le domaine des noms à 50 lettres ou chiffres ou symboles : format 50 caractères,  type alphanumérique. 

© ENI Editions - All rigths reserved

- 3-

On peut affiner ce domaine en domaine des villes de France en ne conservant que les valeurs correspondant  à un libellé d’une ville de France. 

DNEMP : Date de naissance employé a un format date. Les valeurs prises par Date de naissance employé appartiennent au  domaine  Date  {01/01/0001,  02/01/0001,  …,  31/12/9999}.  Nous  pouvons  appliquer  le  même  raisonnement  à  Date  d’arrivée et Date de départ.  La 2ème étape de l’étude est la réalisation de la Matrice des Dépendances Fonctionnelles.  Un extrait de la MDF est le suivant : 

  Nous allons étudier la MDF avec les deux méthodes précédentes pour confirmer notre assertion table = relation.  MDF et schéma entités­relations La MDF nous indique qu’il y a deux données source élémentaires (35 et 38) et une donnée source complexe (42).  Nous obtenons donc, deux entités et une CIM, respectivement :  ●

Employé, 

●

Filiale, 

●

A travaillé. 

Les données source de la MDF nous permettent de définir les identifiants de chacune :  ●

COEMP (Code Employé) pour Employé 

●

NUFIL (N° Filiale) pour Filiale 

●

COEMP_NUFIL (Code Employé­N° Filiale) pour A travaillé. 

Les données cible nous permettent de compléter les entités et la CIM :  ●

- 4-

NOMEMP (Nom Employé) et DNEMP (Date de naissance) pour Employé, 

© ENI Editions - All rigths reserved

●

VILFIL (Ville) pour Filiale, 

●

DADEB (Date début) et DAFIN (Date fin) pour A travaillé. 

Les règles de gestion nous permettent de définir les cardinalités minimum et maximum :  ●

Un employé travaille dans au moins 1 filiale. 

●

Un employé travaille dans au plus n filiales (par exemple, les cadres vont changer de filiale tous les 3 ans). 

Donc les cardinalités liées à l’entité EMPLOYE sont : 1,n.  ●

Une filiale contient au moins 1 employé (elle en contient minimum 12) et au plus n. 

Donc les cardinalités liées à l’entité EMPLOYE sont : 1,n.  Le schéma entités­associations provenant de cette analyse est le suivant : 

  En  utilisant  les  règles  de  passage  du  MCD  au  MLD,  nous  en  déduisons  3  (c’est  un  extrait,  puisque  nous  travaillons  dans  cet  exemple  avec  des  extraits  de  dictionnaire  de  données,  de  MDF)  des  futures  tables  de  notre  base  de  données :  ●

Employé (Code Employé, Nom, Date de naissance) 

●

Filiale (N° Filiale, Ville) 

●

Contrat de travail (Code Employé, N°Filiale, Date début contrat, Date fin contrat) 

Pour  rappel :  la  CIM,  étant  transformée  en  table  comme  une  entité,  prend  un  nom  pour  concrétiser  ce  qu’elle  représente.  MDF et algèbre relationnelle Chaque colonne représente un produit cartésien de domaines. Donc, chaque colonne est une relation.  La clé de relation étant, pour chaque relation, le domaine source de dépendance fonctionnelle.  Dans cette MDF, nous distinguons 3 colonnes qui vont constituer 3 relations :  La relation Employé . COEMP, NOMEMP, DNEMP sont des domaines (ensemble de valeurs)  et  représentent  chacun  un  attribut  de  la  relation.  L’attribut  source  de  dépendance  fonctionnelle  (dans  notre  cas,  COEMP) est la clé de relation ; d’où la relation Employé complètement définie : .  Un employé est caractérisé par son code, son nom et sa date de naissance.  La relation Filiale . NUFIL, VILFIL sont des domaines (ensemble de valeurs) et représentent chacun un 

© ENI Editions - All rigths reserved

- 5-

attribut  de  la  relation.  L’attribut  source  de  dépendance  fonctionnelle  (dans  notre  cas,  NUFIL)  est  la  clé  de  relation ;  d’où la relation Filiale complètement définie : .  Une filiale est caractérisée par son numéro et sa localisation.  La  relation  Contrat  de  travail  .  NUFIL,  COEMP,  DADEB,  DAFIN  sont  des  domaines  (ensemble de valeurs) et représentent chacun un attribut de la relation. L’attribut source de dépendance fonctionnelle  (dans notre cas, c’est une composition d’attributs : NUFIL et COEMP) est la clé de relation ; d’où la relation Contrat de  travail complètement définie : .  Le contrat de travail d’un employé dans une filiale est caractérisé par le numéro de l’employé, le numéro de filiale et  ses dates de début et de fin de contrat.  Un extrait de la base de données relationnelle qui représentera notre Système d’Information est le suivant :  ●

Employé . 

●

Filiale . 

●

Contrat de travail . 

Nous constatons que les tables trouvées dans l’étape du MLD correspondent aux relations issues de la MDF  et reposant sur l’algèbre relationnelle. 

- 6-

© ENI Editions - All rigths reserved

Synthèse  Ce chapitre nous a permis d’appréhender le monde relationnel et son vocabulaire.  Les  concepts  à  retenir  pour  la  construction  d’une  base  de  données  relationnelle  sont  peu  nombreux  mais  très  importants :  ●

le domaine : ensemble de valeurs, 

●

le produit cartésien de n domaines : ensemble de n­uplets ou tuples, 

●

la relation : sous­ensemble du produit cartésien de n domaines (n>0), 

●

le schéma de relation : le nom de la relation suivi de ses attributs, 

●

la clé de relation : composition minimale de n attributs (n>= 1) dont chacune des valeurs permet de déterminer,  d’une manière unique, un tuple de la relation, 

●

la base de données relationnelle : ensemble cohérent de schémas de relations. 

La  méthode  que  nous  suivons  dans  l’étude  d’un  Système  d’Information  nous  fournit  des  éléments  (dictionnaire  des  données, Matrice des Dépendances Fonctionnelles…) essentiels à la construction des relations, clés de relation…  Les  domaines  et  les  produits  cartésiens  seront  déterminés  à  l’aide  du  dictionnaire  de  données  et  de  la  Matrice  des  Dépendances Fonctionnelles.  Les relations et leurs clés peuvent être déterminées par l’étude de la MDF ou à partir du schéma entités­associations.  À  ce  stade  de  l’étude,  nous  avons  construit  notre  base  de  données  relationnelle.  Bien  sûr,  elle  sera  physiquement  créée par une création de database dans un SGBDR (cf Modèle Physique de Données de Merise).  Dans les chapitres suivants, nous allons apprendre à manipuler ces relations avec les fonctions proposées par l’algèbre  relationnelle, pour extraire les tuples répondant aux demandes des utilisateurs de la base de données et pour finir,  nous apprendrons à vérifier la structure des relations (via la normalisation). 

© ENI Editions - All rigths reserved

- 1-

Exercices  1. Exercice 1  a. Énoncé  Prenons  un  extrait  des  données  d’un  système  de  gestion  de  trains :  nombre  de  voyageurs,  date,  horaires,  code  train…  Un extrait du dictionnaire de données est le suivant : 

  Les règles de gestion sont les suivantes :  ●

Un  code  train  (COTRIN)  détermine  de  manière  unique  l’horaire  de  départ  de  ce  train  (HDTRIN)  et  l’heure  d’arrivée (HATRIN), sa catégorie TGV, TER ou Corail (TYTRIN). 

●

Par contre, un code train ne détermine pas d’une manière unique la date de circulation de ce train (DTRIN).  Il peut circuler tous les jours ou uniquement le week­end et/ou les jours fériés… 

●

La date de jour de circulation du train définit d’une manière unique le type de date (veille de fête ou pas)  (TYDATE). 

●

Enfin, le code train ne détermine pas de manière unique le nombre de voyageurs (NBVOY) qui sont dans ce  train. Ce nombre peut être différent à chaque date de circulation. 

Nous en déduisons la MDF suivante : 

  1. 

Quels sont les domaines de ce SI ? 

2. 

Quelles sont les relations avec leurs attributs et clé de relation ? 

© ENI Editions - All rigths reserved

- 1-

3. 

Quels sont les schémas en intention de ces relations ? 

4. 

Peut­on donner les schémas en extension de ces relations ? Pourquoi ? 

5. 

Quel serait un extrait de la base de données relationnelle résultante ? 

b. Solution  1) Le dictionnaire des données recense pour chaque donnée, un type et un format. De plus, ces données peuvent  prendre des valeurs.  Nous sommes donc, en présence de domaines de valeurs.  Dans notre exercice, les domaines sont les suivants :  ●

COTRIN :  Code  train  a  un  format  de  5  caractères,  il  est  numérique.  Les  valeurs  prises  par  code  train  appartiennent  à  l’ensemble  suivant :  {00000,00001,..,99999},  qui  est  considéré  en  algèbre  relationnelle  comme un domaine. C’est le domaine des nombres à 5 chiffres : format 5 caractères, type numérique. 

●

NBVOY : Nombre de voyageurs a un format de 4 caractères, il est numérique. Les valeurs prises par nombre  de  voyageurs  appartiennent  à  l’ensemble  suivant :  {0000,  0001,..,9999},  qui  est  considéré  en  algèbre  relationnelle  comme  un  domaine.  C’est  le  domaine  des  nombres  à  4  chiffres :  format  4  caractères,  type  numérique. 

●

HDTRIN  :  Heure  départ  train  a  un  format  Heure  constitué,  dans  notre  cas,  de  l’heure  et  des  minutes.  Les  valeurs  prises  par  heure  départ  train  appartiennent  à  l’ensemble  suivant :  {00H00,..,23H59},  qui  est  considéré en algèbre relationnelle comme un domaine. 

●

HATRIN  :  Heure  arrivée  train  a  un  format  Heure  constitué,  dans  notre  cas,  de  l’heure et des minutes. Les  valeurs  prises  par  heure  arrivée  train  appartiennent  à  l’ensemble  suivant :  {00H00,..,23H59},  qui  est  considéré en algèbre relationnelle comme un domaine. 

●

DTRIN : Date de circulation a un format Date constitué, dans notre cas, du jour, du mois et de l’année. Les  valeurs prises par date de circulation appartiennent à l’ensemble suivant : {01/01/0001, ..., 31/12/9999},  qui est considéré en algèbre relationnelle comme un domaine. 

●

TYDATE :  Type  de  date  a  un  format  d’un  caractère,  alphanumérique.  Les  valeurs  prises  par  type  de  date  appartiennent à l’ensemble suivant : {0, 1(veille de fête)}, qui est considéré en algèbre relationnelle comme  un domaine. 

●

TYTRIN :  Catégorie  de  train  a  un  format  de  6  caractères,  alphanumérique.  Les  valeurs  prises  par  type  de  train  appartiennent  à  l’ensemble  suivant :  {Corail,  TER,  TGV},  qui  est  considéré  en  algèbre  relationnelle  comme un domaine. 

2) Il faut maintenant étudier la MDF.  Nous  savons  que  chaque  colonne  est  une  relation ;  la  clé  de  relation  étant,  pour  chaque  relation,  le  domaine  source de dépendance fonctionnelle.  Nous avons donc, dans notre cas, 3 relations :  ●

Trains  susceptibles  de  circuler  (colonne  37)  avec  comme  clé  de  relation :  COTRIN  (code  train)  et  comme  attributs HDTRIN, HATRIN et TYTRIN. 

●

Calendrier (colonne 41) avec comme clé de relation : DTRIN et comme attribut TYDATE. 

●

Trains  circulants  (colonne  44)  avec  comme  clé  de  relation :  la  composition  de  COTRIN  et  DTRIN  et  comme  attributs : NBVOY. 

3) Le schéma en intention de chacune de ces relations est le suivant :  Trains susceptibles de circuler  Calendrier  Train circulant 

- 2-

© ENI Editions - All rigths reserved

4)  Le  schéma  en  extension  d’une  relation  est  sous  forme  de  tableau  contenant  les  tuples  explicites.  Dans  cet  exercice, nous ne connaissons aucune des valeurs réellement prises dans le SI par chacune des données.  Donc,  il  n’est  pas  possible  de  donner  les  schémas  en  extension  des  relations  trains  susceptibles  de  circuler,  calendrier et trains circulants.  5) L’ensemble de toutes les relations, issues de la matrice, constitue la base de données relationnelle du Système  d’Information étudié.  Dans cet exercice, un extrait de la base de données relationnelle est constituée d’au moins :  ●

Trains susceptibles de circuler 

●

Calendrier 

●

Trains circulants. 

2. Exercice 2  a. Énoncé  Considérons une entreprise de gestion de location de véhicules. Cette entreprise a un parc automobile de véhicules  qui  peuvent  être  loués  par  des  clients  et  qui  sont  révisés  tous  les  7500  km  par  les  deux  garagistes  attitrés  de  l’entreprise.  Les informations concernant les deux garagistes sont les suivantes : 

  Le dictionnaire des données est le suivant : 

© ENI Editions - All rigths reserved

- 3-

  Les règles de gestion sont les suivantes : 

- 4-

●

Les clients sont répertoriés avec les mêmes informations que les garagistes sans les N° SIREN mais avec un  numéro de client. 

●

Un client peut louer, à chacune de ses locations, n’importe quel véhicule de n’importe quelle catégorie. 

●

Les clients, recensés dans la base, sont des clients ayant fait au moins une location de véhicule. 

●

Un véhicule est identifié par son numéro, possède une couleur (gris, blanc, noir), une cylindrée (3, 4, 5 ou 6  © ENI Editions - All rigths reserved

chevaux), une catégorie (Berline, Break) et un kilométrage (de 0 à 100 000 maximum ; au delà, la voiture  est changée).  ●

Un véhicule neuf est révisé avant toute location. 

●

La location est déterminée par une date de début, une date de fin et un kilométrage effectué. 

La MDF issue de la connaissance du dictionnaire de données et des règles de gestion est la suivante : 

  © ENI Editions - All rigths reserved

- 5-

1. 

Quelles sont les relations avec leurs attributs et clé de relation ? 

2. 

Quels sont les schémas en intention de ces relations ? 

3. 

Peut­on donner les schémas en extension de ces relations ? Pourquoi ? 

4. 

Quelle est la base de données relationnelle résultante ? 

5. 

Reprendre la MDF. Est­ce que les tables (et leurs clés) construites en passant par l’étape  du schéma entités­associations sont équivalentes aux relations (et leurs clés) de la  question 1 ? 

b. Solution  1)  Le  dictionnaire  de  données  nous  permet  de  déterminer  les  différents  domaines  de  valeurs  (numérique,  alphanumérique,  date,  heure...)  avec  leur  type  (numérique,  alphanumérique  et  date  dans  cet  exercice)  et  leur  format.  La Matrice des Dépendances Fonctionnelles permet de déterminer les relations.  Chaque colonne de la matrice est une relation ; la clé de relation, étant pour chaque relation, le domaine source de  dépendance fonctionnelle.  Nous avons donc, dans notre cas, 5 relations :  ●

Client  (colonne  01)  avec  comme  clé  de  relation :  NUCLI  (N°  de  client)  et  comme  attributs NOCLI,  PNOCLI,  LIGAD1, LIGAD2, PAYSCLI, TELCLI. 

●

Garagiste (colonne 08) avec comme clé de relation : NUGAR (N° SIREN) et comme attributs DENOM, NOGAR,  PNOGAR, LIGAD1G, LIGAD2G, PAYSGAR, TELGAR, FAXGAR, EMGAR. 

●

Voiture  (colonne  17)  avec  comme  clé  de  relation :  COVOIT  (Code  voiture)  et  comme  attributs LIBVOIT,  COLVOIT, CYL, KMCOMPT. 

●

Révision  (colonne  28)  avec  comme  clé  de  relation :  composition  de  COVOIT  (Code  voiture)  et  NUGAR  (N°  SIREN) et comme attributs KMREVI et DREV. 

●

Location (colonne 29) avec comme clé de relation : composition de COVOIT (Code voiture) et NUCLI (N° de  client) et comme attributs DBLOC, DFLOC et KMEFF. 

2) Les schémas en intention de ces relations sont les suivants :  Client .  Garagiste .  Voiture .  Révision .  Location .  3) Le seul schéma en extension que nous pouvons donner est celui de la relation Garagiste , puisque nous avons  les informations exhaustives concernant les deux garagistes attitrés. 

  4) La base de données relationnelle est la liste exhaustive des schémas de relation.  Donc, la base de données relationnelle résultante est : 

- 6-

© ENI Editions - All rigths reserved

Client .  Garagiste .  Voiture .  Révision .  Location .  5) Étudions la Matrice des Dépendances Fonctionnelles.  La MDF nous indique qu’il y a trois données source élémentaires (01, 08 et 17) et deux données source complexe  (28 et 29).  Nous obtenons donc, 3 entités et 2 CIM, respectivement :  ●

Client, 

●

Garagiste, 

●

Voiture, 

●

Est révisée, 

●

A loué. 

Les données source de la MDF nous permettent de définir les identifiants de chacune :  ●

NUCLI (N° Client) pour Client, 

●

NUGAR (N° SIREN) pour Garagiste 

●

COVOIT (Code Voiture) pour Voiture, 

●

COVOIT_NUGAR (Code Voiture­N° SIREN) pour Est révisée, 

●

COVOIT_NUCLI ( Code Voiture­N°Client) pour A loué. 

Les données cible nous permettent de compléter les entités et les CIM :  ●

NOCLI (Nom Client), PNOCLI (Prénom Client), LIGAD1 (Ligne adresse 1), LIGAD2 (Ligne adresse 2), PAYSCLI  (Pays Client), TELCLI (Téléphone Client) pour Client, 

●

NOGAR (Nom Garagiste), PNOGAR (Prénom Garagiste), LIGAD1 (Ligne adresse 1), LIGAD2 (Ligne adresse 2),  PAYSGAR (Pays Garagiste), TELGAR (Téléphone Garagiste), FAXGAR (Fax Garagiste), EMGAR (Email Garagiste)  pour Garagiste, 

●

LIBVOIT  (Libellé  Voiture),  COLVOIT  (Couleur),  KMCOMPT  (Kilométrage  compteur),  CYL  (Cylindrée)  pour  Voiture, 

●

KMREVI (Kilométrage de révision) et DREV (Date de révision) pour Est révisé, 

●

KMEFF (Kilométrage effectué), DBLOC (Date début de location), DFLOC (Date fin de location) pour A loué. 

Les règles de gestion nous permettent de déterminer les cardinalités liées à chaque entité.  ●

Toutes les occurrences de client ont loué au moins 1 véhicule. 

●

Une occurrence de client peut louer n véhicules. 

●

Une occurrence de véhicule a été louée au minimum par 0 clients (voiture neuve). 

© ENI Editions - All rigths reserved

- 7-

●

Une occurrence de véhicule a été louée au maximum par n client. 

●

Une  occurrence  de  véhicule  a  été  révisée  au  minimum  par  1  garagiste  (une  voiture  neuve  est  obligatoirement révisée avant location). 

●

Une occurrence de véhicule a été révisée au maximum par 2 garagistes (donc n, puisque 2 > 1). 

●

Toutes les occurrences de garagiste ont révisé au moins 1 véhicule. 

●

Une occurrence de garagiste a révisé au maximum n véhicules. 

Le schéma entités­associations correspondant est le suivant : 

  En  utilisant  les  règles  de  passage  du  MCD  au  MLD,  nous  en  déduisons  les  5  futures  tables  de  notre  base  de  données :  Client (NUCLI, NOCLI, PNOCLI, LIGAD1, LIGAD2, PAYSCLI, TELCLI).  Garagiste (NUGAR, DENOM, NOGAR, PNOGAR, LIGAD1G, LIGAD2G, PAYSGAR, TELGAR, FAXGAR, EMGAR).  Voiture (COVOIT, LIBVOIT, COLVOIT, CYL, KMCOMPT).  Révision (COVOIT, NUGAR, KMREVI, DREV).  Location (COVOIT, NUCLI, DBLOC, DFLOC , KMEFF). 

- 8-

© ENI Editions - All rigths reserved

Nous constatons que les tables trouvées dans l’étape du MLD correspondent aux relations construites à partir de la  MDF et reposent sur les concepts de l’algèbre relationnelle. 

© ENI Editions - All rigths reserved

- 9-

Introduction  Le  chapitre  précédent  nous  a  permis  d’appréhender  le  monde  de  l’algèbre  relationnelle  et  tout  particulièrement  l’élément de base : la relation.  Construire la base de données relationnelle est une étape fondamentale dans la vie d’un SI.  Mais  comment  feriez­vous  si  vous  aviez  une  voiture  mais  pas  le  permis  de  conduire ?  Même  si  vous  aviez  choisi  une  belle voiture puissante et respectueuse de l’environnement, avec toutes les dernières nouveautés technologiques, elle  vous serait inutile ! La même problématique se pose avec la base de données.  Aussi,  comme  le  terme  algèbre  renvoie  aux  mathématiques,  E.  F.  Codd,  outre  les  relations,  a  aussi  inventé  un  ensemble d’opérations qui peuvent être appliquées aux relations pour obtenir de nouvelles relations résultantes. Ces  opérations  pourront  être  composées  entre  elles  pour  en  créer  de  nouvelles.  Ces  opérations  appliquées  sur  les  relations permettront de répondre à des besoins précis des utilisateurs. Le terme précis indique que les utilisateurs,  parmi toutes les données du SI, voudront en faire une extraction cohérente d’une ou plusieurs relations pour obtenir  des  informations.  Cette  demande  correspond  à  une  recherche  de  données  répondant  ou  non  à  des  conditions  particulières.  C’est  ainsi  que  la  ou  les  opération(s)  de  l’algèbre  relationnelle,  répondant  à  ce  besoin,  sera(ont)  transformée(s)  en  requête  (Query)  par  le  SQL  (Structured  Query  Langage),  pour  être  exécutée(s)  dans  la  base  de  données relationnelle implémentée physiquement.  Nous allons découvrir les opérations de l’algèbre relationnelle, dans ce chapitre, d’une manière progressive : des plus  élémentaires (unaires) aux plus complexes (ensemblistes).  La  compréhension  des  rouages  de  l’algèbre  relationnelle  est  importante,  car  elle  est  le  fondement  du  langage  SQL.  Tout utilisateur de base de données connaît le SQL, mais s’il n’a pas acquis ce qu’est une sélection, une projection, une  jointure…, il n’utilisera pas le SQL dans toute sa puissance.  L’objectif  de  ce  livre  n’est  pas  de  vous  apprendre  le  SQL,  aussi  nous  vous  donnerons  simplement  un  aperçu  très  synthétique du lien entre l’algèbre relationnelle et le SQL, et nous vous laisserons le soin d’aller encore plus loin. 

© ENI Editions - All rigths reserved

- 1-

Les opérations unaires  Rappelons­nous que les relations sont des ensembles de tuples. Toute relation est déterminée par son nom.  Chaque tuple de la relation est un produit cartésien de domaines. Chaque domaine participant au produit cartésien est  appelé attribut de la relation.  Les  opérations  unaires  vont  permettre  d’éliminer  des  tuples  ou  des  attributs  d’une  relation  pour  en  construire  une  nouvelle.  Vous  remarquerez,  dans  les  exemples  fournis,  que  ces  opérations  unaires  répondent  à  des  besoins  de  consultation ou d’extractions d’informations usuels. 

1. La projection  La  projection  d’une  relation  R  consiste  à  créer  une  nouvelle  relation,  à  partir  de  R  mais  en  ne  conservant  que  les  attributs cités en opérande.  Si nous nous plaçons du côté utilisateurs, cela veut dire que parmi les attributs constituants les tuples, les valeurs de  certains ne nous intéressent pas temporairement pour l’objectif à atteindre. 

a. Définition  La projection (proj ou Π) est l’opération qui consiste à :  ●

Supprimer, d’une relation, les attributs non mentionnés en opérande, 

●

ET à éliminer les tuples, en doublon, qui risquent d’apparaître dans la nouvelle table. 

Notation Soit un schéma de relation R (A1, A2… An), avec ∀i ∈ E (entiers), Ai étant un attribut dont les valeurs appartiennent à  un domaine Di.  La projection R’ de R sur A1,A2 s’écrira :  R’ = proj (R,A1,A2) = Π A1,A2 (R)  La modélisation graphique suivante est aussi possible : 

  Pourquoi faut­il éliminer les tuples en doublon qui risquent d’apparaître ?  Si  la  clé  primaire  (constituée  d’une  composition  minimale  d’attribut(s))  n’apparaît  pas  dans  les  opérandes  de  la  projection, la relation résultante n’aura pas de clé primaire définie, d’où risque de tuples en double.  De ce fait, une clé primaire est définie arbitrairement dans le cas de la projection. Ce sera la composition de tous les  attributs restants dans cette relation : ce qui permet d’éliminer tout doublon dans les tuples. 

b. Exemples 

© ENI Editions - All rigths reserved

- 1-

Exemple1 :  Considérons la relation CLIENT.  La clé primaire de cette relation est le numéro de client (NUCLI). Les autres attributs représentent les caractéristiques du  client : nom (NOCLI), Prénom (PNCLI) et date de naissance (DNCLI).  Cette relation en extension se présente ainsi : 

  Nous ne voudrions connaître que les noms et prénoms des clients qui intéressent l’utilisateur X.  Traduisons cette demande : extraire de la relation client, les attributs nom et prénom.   Pour  répondre  à  cette  demande,  il  faut  appliquer  une  projection  sur  la  relation  CLIENT  pour  créer  une  nouvelle  relation  PCLIENT1.  Pour conserver le nom et le prénom de chaque client, il faut mettre ces attributs en tant qu’opérandes de la projection.  D’où PCLIENT1 = proj (CLIENT, NOCLI, PNCLI) = Π NOCLI, PNCLI (CLIENT).  La représentation graphique de PCLIENT1 est la suivante : 

  Pour  obtenir  la  relation  PCLIENT1,  nous  allons  supprimer  les  attributs  qui  ne  sont  pas  les  opérandes  de  la  projection,  soient : NUCLI, DNCLI.  La relation PCLIENT1 en intention s’écrira : PCLIENT1 (NOCLI, PNCLI).  La relation PCLIENT1 en extension est de la forme suivante : 

 

- 2-

© ENI Editions - All rigths reserved

De  plus,  pour  finaliser  la  projection,  il  faut  supprimer  les  tuples  en  doublons  qui  apparaîtraient  après  suppression  des  attributs.  Nous constatons que dans cet exemple particulier, nous n’avons pas de doublons dans les tuples.  En  conclusion,  par  la  projection  de  la  relation  client  proj  (CLIENT,  NOCLI,  PNCLI) =   Π  NOCLI,  PNCLI  (CLIENT),  nous  obtenons une relation ne contenant que les informations demandées : nom et prénom du client. Les autres données de  la relation client sont « occultées » car inutiles pour cette requête.  Exemple 2 :  Considérons la relation CLIENT.  La clé primaire de cette relation est le numéro de client (NUCLI). Les autres attributs représentent les caractéristiques du  client : nom (NOCLI), Prénom (PNCLI) et date de naissance (DNCLI).  Cette relation en extension se présente ainsi : 

  Nous  constatons  qu’il existe des homonymes qui ont les mêmes nom et prénom dans la relation CLIENT mais qui sont  distingués par leur numéro de client différent.  L’utilisateur X fait la même demande que dans l’exemple précédent : ne voir que les noms et prénoms des  clients.  Traduisons cette demande : extraire de la relation client, les attributs nom et prénom.   Pour  répondre  à  cette  demande,  il  faut  appliquer  une  projection  sur  la  relation  CLIENT  pour  créer  une  nouvelle  relation  PCLIENT2.  Pour conserver le nom et le prénom de chaque client, il faut mettre ces attributs en tant qu’opérandes de la projection.  D’où PCLIENT2 = proj (CLIENT, NOCLI, PNCLI) = Π NOCLI, PNCLI (CLIENT).  La représentation graphique de PCLIENT2 est la suivante (la même que dans l’exemple 1) : 

  Pour  obtenir  la  relation  PCLIENT2,  nous  allons  supprimer  les  attributs  qui  ne  sont  pas  les  opérandes  de  la  projection,  soient : NUCLI, DNCLI.  La relation PCLIENT2 en intention s’écrira : PCLIENT2 (NOCLI, PNCLI).  La relation PCLIENT2 en extension, après élimination de NUCLI et DNCLI, est de la forme suivante : 

© ENI Editions - All rigths reserved

- 3-

  La suppression de la clé primaire (NUCLI) a fait apparaître des doublons dans la relation résultante. Il faut les supprimer du  fait de la nouvelle clé primaire NOCLI­PNCLI. 

  D’où, la relation finalisée PCLIENT2 : 

  En conclusion, par rapport au besoin des utilisateurs, la relation résultante est correcte et exhaustive : elle contient tous  les noms et prénoms des clients et uniquement ces données.  En effet, les homonymes se distinguaient par un numéro de client et leur date de naissance : ce qui ne constitue pas la  demande d’informations des utilisateurs.  Exemple 3 :  Considérons la relation CLIENT.  La clé primaire de cette relation est le numéro de client (NUCLI). Les autres attributs représentent les caractéristiques du  client : nom (NOCLI), Prénom (PNCLI) et date de naissance (DNCLI).  Cette relation en extension se présente ainsi : 

- 4-

© ENI Editions - All rigths reserved

  Les utilisateurs ne veulent voir que les numéros de clients, leur nom et leur prénom.  Traduisons cette demande : extraire de la relation client, les attributs numéro de client, nom et prénom.   Pour  répondre  à  cette  demande,  il  faut  appliquer  une  projection  sur  la  relation  CLIENT  pour  créer  une  nouvelle  relation  PCLIENT3.  Pour conserver le numéro, le nom et le prénom de chaque client, il faut mettre ces attributs en tant qu’opérandes de la  projection.  D’où PCLIENT3 = proj (CLIENT, NUCLI, NOCLI, PNCLI) = Π NUCLI, NOCLI, PNCLI (CLIENT).  La représentation graphique de PCLIENT3 est la suivante : 

  Pour  obtenir  la  relation  PCLIENT3,  nous  allons  supprimer  l’attribut  qui  n’est  pas  mentionné  dans  les  opérandes  de  la  projection, soit : DNCLI.  La relation PCLIENT3 en intention s’écrira : PCLIENT3 (NUCLI,NOCLI, DNCLI).  La  clé  primaire  de  la  relation  initiale  étant  conservée  dans  les  opérandes,  elle  constitue  toujours  la  clé  primaire de la relation résultant de la projection.  La relation PCLIENT3 en extension est de la forme suivante : 

  Il n’y a pas de tuples en doublons à supprimer ; ce qui est normal, la clé primaire ayant été conservée. 

© ENI Editions - All rigths reserved

- 5-

À partir d’une relation R, il est possible de faire plusieurs projections (autant que de compositions possibles,  des attributs de cette relation) pour créer plusieurs nouvelles relations. 

2. La sélection (ou restriction)  La sélection consiste à créer une relation à partir d’une autre, en ne gardant que les tuples pour lesquels un attribut  vérifie une certaine propriété.  Dans  ce  cas,  tous  les  attributs  de  chaque  tuple  nous  intéressent  mais  par  contre,  certains  tuples,  eux,  ne  nous  intéressent pas. 

a. Définition  La sélection (ou restriction) (select ou σ) est l’opération qui consiste, à partir d’une relation R (A1, A2,…An), à  créer une nouvelle relation R’(A1, A2…An) dont tous les tuples vérifient une propriété d’un attribut Ai.  On notera : R’ = σAi   (R) ∀i ∈ E (entiers)  Ou R’ = Restrict (R, Ai  )  Ou R’ = R[Ai  ]  L’opérateur appartient à l’ensemble {=, < , ≤ , >, ≥ , ≠ }.  La valeur appartient au domaine de l’attribut Ai.  La modélisation graphique suivante est aussi possible : 

  Cette opération construit une nouvelle relation R’ à partir de R qui contient moins de tuples, mais pour laquelle la clé  primaire est conservée. 

b. Exemples  Exemple 1 :  Considérons la relation CLIENT.  La clé primaire de cette relation est le numéro de client (NUCLI). Les autres attributs représentent les caractéristiques du  client : nom (NOCLI), Prénom (PNCLI) et date de naissance (DNCLI).  Cette relation en extension se présente ainsi : 

- 6-

© ENI Editions - All rigths reserved

  Les utilisateurs n’ont besoin, pour leurs traitements, de ne conserver que les clients qui ont 35 ans ou plus  au 1er janvier 2008.  Analysons cette demande :  ●

●

Il n’y a aucun attribut à éliminer (toutes les données des clients sont demandées),  Quel  est  l’attribut  qui  va  nous  permettre  de  savoir  si  un  client  à  35  ans  ou  plus  au  1er  janvier  2008 ?  C’est  l’attribut date de naissance DNCLI, il y a donc une condition à apporter à DNCLI. 

La  condition  littéraire  doit  être  traduite  mathématiquement :  DNCLI  ≤‘ 01/01/1973’,  il  faut  que  tous  les  tuples  conservés vérifient cette condition et il faut conserver toutes les informations (attributs) concernant un client.  Donc, c’est une sélection que l’on doit appliquer à la relation CLIENT pour créer une nouvelle relation SCLIENT1.  SCLIENT1  =   σ  DNCLI  ≤  ‘01/01/1973’  (CLIENT)  =   CLIENT  [DNCLI  ≤  ‘01/01/1973’]  =  Restrict  (CLIENT,  DNCLI  ≤  ‘01/01/1973’ )  La représentation graphique de SCLIENT1 est la suivante : 

  Pour obtenir la relation SCLIENT1, nous allons supprimer tous les tuples dont l’attribut date de naissance DNCLI ne vérifie  pas la condition.  La  relation  SCLIENT1  en  intention  s’écrira :  SCLIENT1  .  Le  schéma  de  Relation  résultante reste identique à celui de la relation originelle : même clé primaire, même(s) attribut(s).  Par contre, certains tuples vont être éliminés et nous obtenons la relation SCLIENT1 en extension suivante : 

  Exemple 2 :  Considérons la relation CLIENT. 

© ENI Editions - All rigths reserved

- 7-

La clé primaire de cette relation est le numéro de client (NUCLI). Les autres attributs représentent les caractéristiques du  client : nom (NOCLI), Prénom (PNCLI) et date de naissance (DNCLI).  Cette relation en extension se présente ainsi : 

  Nous remarquons dans la relation en extension, des homonymes qui ont les mêmes nom et prénom.  Les utilisateurs n’ont besoin pour leurs traitements de conserver que les informations des clients qui ont 35  ans ou plus au 1er janvier 2008.  La même condition que dans l’exemple précédent est à apporter à l’attribut date de naissance DNCLI.  La  condition  littéraire  doit  être  traduite  mathématiquement :  DNCLI  ≤  ‘01/01/1973’,  il  faut  que  tous  les  tuples  conservés vérifient cette condition et il faut conserver toutes les informations (attributs) concernant un client.  Donc, c’est une sélection que l’on doit appliquer à la relation CLIENT pour créer une nouvelle relation SCLIENT2.  SCLIENT2  =   σ  DNCLI  ≤  ‘01/01/1973’  (CLIENT)  =   CLIENT  [DNCLI  ≤  ‘01/01/1973’]  =   Restrict  (CLIENT,  DNCLI  ≤  ‘01/01/1973’ )  La représentation graphique de SCLIENT2 est la suivante : 

  Pour obtenir la relation SCLIENT2, nous allons supprimer tous les tuples dont l’attribut date de naissance DNCLI ne vérifie  pas la condition.  La  relation  SCLIENT2  en  intention  s’écrira :  SCLIENT2  .  Le  schéma  de  la  relation  résultante reste identique à celui de la relation originelle.  Nous obtenons la relation SCLIENT2 en extension suivante : 

  Nous constatons que la relation résultante n’est pas erronée, malgré le fait qu’il y ait des doublons sur certains attributs  (autres que la clé) ; ce qui est vrai dans tous les cas, car la sélection n’élimine aucun attribut et donc, le ou les attribut(s)  discriminant(s) de la clé primaire perdure(nt) dans la relation.  Exemple 3 : 

- 8-

© ENI Editions - All rigths reserved

Considérons la relation CLIENT.  La clé primaire de cette relation est le numéro de client (NUCLI). Les autres attributs représentent les caractéristiques du  client : nom (NOCLI), Prénom (PNCLI) et date de naissance (DNCLI).  Cette relation en extension se présente ainsi : 

  Nous ne voulons conserver que les informations des clients qui s’appellent DUCLOS.  Nous voulons toutes les informations, donc nous voulons conserver tous les attributs.  De plus, nous ne voulons que les tuples dont l’attribut nom est égal à ‘DUCLOS’.  Cette  demande  présente  les  caractéristiques  d’une  sélection  appliquée  sur  la  relation  CLIENT  qui  donnera  une  nouvelle  relation SCLIENT3.  SCLIENT3 = σ NOCLI = ‘DUCLOS’ (CLIENT) = CLIENT[NOCLI = ‘DUCLOS’] = Restrict (CLIENT, NOCLI= ‘DUCLOS’ )  La représentation graphique de SCLIENT3 est la suivante : 

  Pour obtenir la relation SCLIENT3, nous allons éliminer, de notre extraction de tuples, tous les tuples dont l’attribut nom  client NOCLI ne vérifie pas la condition.  La  relation  SCLIENT3  en  intention  s’écrira :  SCLIENT3  .  Le  schéma  de  la  relation  résultante reste identique à celui de la relation originelle.  Nous obtenons la relation SCLIENT3 en extension suivante : 

 

c. Exercice  Énoncé Considérons la relation CLIENT.  La  clé  primaire  de  cette  relation  est  le  numéro  de  client  (NUCLI).  Les  autres  attributs  représentent  les  caractéristiques du client : nom (NOCLI), Prénom (PNCLI) et date de naissance (DNCLI). 

© ENI Editions - All rigths reserved

- 9-

Cette relation en extension se présente ainsi : 

  Quelle est la relation résultante de la sélection : ne conserver que les clients dont le nom est DUMAS ?  Réponse La nouvelle relation CLIENTDUMAS s’obtient par une sélection sur la relation CLIENT.  σ NOCLI = ‘DUMAS’ (CLIENT) = CLIENT[NOCLI = ‘DUMAS’] = Restrict (CLIENT, NOCLI= ‘DUMAS’ ) = ∅.  CLIENTDUMAS = ∅.  C’est un ensemble vide, aucun tuple ne comporte l’attribut nom avec une valeur égale à ‘DUMAS’. 

- 10 -

© ENI Editions - All rigths reserved

Les opérations ensemblistes  Les opérations ensemblistes vont permettre, à partir de  deux relations, d’en construire une troisième. La totalité des  attributs  de  chacune  des  relations  est  conservée.  Nous  retrouvons  les  opérations  ensemblistes  traditionnelles  de  l’algèbre.  Dans le contexte d’un SI, ces opérations vont permettre à l’utilisateur de regrouper les informations provenant de deux  relations dans une seule avec ou non des conditions de recherche. 

1. L’intersection  a. Définition  L’intersection de deux relations R1 et R2 est une nouvelle relation R dont les tuples appartiennent à R1 ET R2.  Les trois relations R1, R2 et R ont le même schéma.  On notera : R = R1 ∩ R2  Un seul exemplaire de chaque tuple commun est conservé.  La modélisation graphique de l’intersection est la suivante : 

    Attention ! L’intersection ne peut être appliquée que sur deux relations ayant absolument le même schéma.

b. Exemples  Exemple 1 :  Supposons que deux bibliothèques B1 et B2 fusionnent et décident de rechercher les livres qu’elles ont en commun  pour n’en garder qu’un exemplaire. Chacune des bibliothèques possède une relation LIVREB1 et LIVREB2, recensant  les caractéristiques des livres.  La relation LIVREB1 a pour schéma , où :  ●

NULIV : Numéro de livre, clé primaire. 

●

TITLIV : Titre du livre. 

●

NOAUT : Nom de l’auteur. 

La relation LIVREB2 a pour schéma , où :  ●

NULIV : Numéro de livre, clé primaire. 

●

TITLIV : Titre du livre. 

© ENI Editions - All rigths reserved

- 1-

●

NOAUT : Nom de l’auteur. 

●

PNAUT : Prénom de l’auteur. 

La demande rechercher les livres communs à B1 et B2 consiste à faire une intersection sur deux ensembles de livres.  Oui, mais en algèbre relationnelle, les deux ensembles doivent avoir le même schéma descriptif.  Dans LIVREB1, le prénom de l’auteur n’existe pas en tant qu’attribut donc, on ne pourra pas réaliser une intersection sur  LIVREB1 et LIVREB2. LIVREB1 et LIVREB2 n’ont pas le même schéma.  Exemple 2 :  Supposons que deux bibliothèques B1 et B2 fusionnent et décident de rechercher les livres qu’elles ont en commun  pour n’en garder qu’un exemplaire. Chacune des bibliothèques possède une relation LIVREB1 et LIVREB2, recensant  les caractéristiques des livres.  La relation LIVREB1 a pour schéma , où :  ●

NULIV : Numéro de livre, clé primaire. 

●

TITLIV : Titre du livre. 

●

NOAUT : Nom de l’auteur. 

La relation LIVREB2 a pour schéma , où :  ●

NULIV : Numéro de livre, clé primaire. 

●

TITLIV : Titre du livre. 

●

NOAUT : Nom de l’auteur. 

Les  relations  LIVREB1  et  LIVREB2  ont  le  même  schéma,  donc  il  est  possible  de  répondre  à  la  question  par  LIVREB1  ∩  LIVREB2.  La relation résultante INTERLIVRE aura pour schéma  et ne conservera que les tuples communs à  LIVREB1 et LIVREB2. 

  Considérons LIVREB1 et LIVREB2 en extension : 

- 2-

© ENI Editions - All rigths reserved

  Qu’appelle­t­on un tuple commun ?  C’est  un  tuple  qui  aura  les  mêmes  valeurs  pour  chacun  de  ces  attributs  dans  LIVREB1  et  LIVREB2.  Dans  notre  exemple, nous en avons donc 2.  Nous obtenons : 

 

c. Exercice  Énoncé En repartant des données des relations précédentes LIVRE1 et LIVRE2, construire la relation LIVRE2 ∩ LIVRE1.  Solution Nous obtenons : 

    R1 ∩ R2 = R2 ∩ R1

2. L’union  a. Définition  L’union  de  deux  relations  R1  et  R2  est  une  nouvelle  relation  R  dont  les  tuples  appartiennent  à  R1  OU  appartiennent à R2 OU appartiennent à R1 et R2.  Les trois relations R1, R2 et R ont le même schéma. 

© ENI Editions - All rigths reserved

- 3-

On notera : R = R1 ∪ R2  Comme dans le cas de l’intersection, s’il existe des tuples communs à R1 et à R2, un seul exemplaire de chaque est  conservé.  La modélisation graphique de l’union est la suivante : 

    Attention ! l’union ne peut être appliquée que sur deux relations ayant absolument le même schéma.

b. Exemples  Exemple 1 :  Supposons  que  deux  bibliothèques  B1  et  B2  fusionnent  et  décident  de  regrouper  tous  leurs  livres.  Chacune  des  bibliothèques possède une relation LIVREB1 et LIVREB2, recensant les caractéristiques des livres.  La relation LIVREB1 a pour schéma .  La relation LIVREB2 a pour schéma .  Nous ne pouvons pas répondre à cette demande par une union des deux relations. LIVREB1 et LIVREB2 n’ont pas le  même schéma.  Exemple 2 :  Supposons  que  deux  bibliothèques  B1  et  B2  fusionnent  et  décident  de  regrouper  tous  leurs  livres.  Chacune  des  bibliothèques possède une relation LIVREB1 et LIVREB2 recensant les caractéristiques des livres.  Les relations LIVREB1 et LIVREB2 ont pour schéma .  ●

NULIV : Numéro de livre, clé primaire. 

●

TITLIV : Titre du livre. 

●

NOAUT : Nom auteur. 

Pour répondre à la demande des bibliothécaires, il faut faire une réunion de leurs livres et donc, en algèbre relationnelle,  une union de leurs relations.  Les  relations  LIVREB1  et  LIVREB2  ont  le  même  schéma,  donc  il  est  possible  de  répondre  à  la  question  par  LIVREB1  ∪  LIVREB2.  La relation résultante UNIONLIVRE aura pour schéma  et regroupera tous les tuples appartenant  à LIVREB1 ou à LIVREB2 ou à LIVREB1 et LIVREB2.  Vous constatez que la relation résultante n’a pas de clé primaire définie. En effet, l’union regroupe tous les  tuples quelque soit la valeur de chacun de leurs attributs. 

- 4-

© ENI Editions - All rigths reserved

  Considérons LIVREB1 et LIVREB2 en extension : 

  Nous allons visualiser cette union par étapes :  1) La relation résultante UNIONLIVRE aura pour schéma .  2) Puis, elle regroupera tous les tuples appartenant à LIVREB1 et LIVREB2.  Cette condition est la même que celle utilisée pour l’intersection.  Il n’y a qu’un tuple qui vérifie cette condition. 

  3) Mais elle contiendra aussi tous les tuples appartenant à LIVREB1.  Nous enrichissons UNIONLIVRE : 

  4) Elle contiendra aussi tous les tuples appartenant à LIVREB2.  Nous enrichissons UNIONLIVRE : 

© ENI Editions - All rigths reserved

- 5-

  5) Enfin, nous éliminons les tuples éventuels en doublons : 

  6) Analysons notre résultat :  ●

LIVREB1 contenait 4 tuples. 

●

LIVREB2 contenait 3 tuples. 

●

UNIONLIVRE contient 6 tuples puisque les deux relations avait un tuple en commun dont nous avons éliminé un  exemplaire. 

Nous  avons  deux  tuples  qui  ont  le  même  numéro  de  livre.  Cela  est  normal  car  la  relation  résultante  ne  reprend  pas  les  clés  primaires  des  relations  originelles ;  mais,  ce  ne  sont  pas  des  doublons  car  ces  deux  tuples ont au moins un même attribut qui a des valeurs différentes. 

c. Exercice  Énoncé En repartant des données des relations précédentes LIVRE1 et LIVRE2, construire la relation LIVRE2 ∪ LIVRE1.  Solution Nous obtenons : 

- 6-

© ENI Editions - All rigths reserved

    R1 ∪ R2 = R2 ∪ R1

3. La différence  a. Définition  La différence R1 ­ R2 de deux relations R1 et R2 est une nouvelle relation R dont les tuples appartiennent à R1  ET n’appartiennent PAS à R2.  Les trois relations R1, R2 et R ont le même schéma.  On notera : R = R1 ­ R2  Aucun exemplaire des tuples communs n’est conservé.  La modélisation graphique de la différence est la suivante : 

 

b. Exemple  Supposons qu’une grande librairie B1 rachète une petite librairie B2 et décide de ne conserver en vente que les livres  de B1 ; mais, de plus, s’il  y  a  un  livre  de  B1  qui  est  référencé  chez  B2,  il  est  retiré  de  la  vente. Chacune des  librairies possède une relation LIVREB1 et LIVREB2 recensant les caractéristiques des livres.  Les relations LIVREB1 et LIVREB2 ont pour schéma , où :  ●

NULIV : Numéro de livre, clé primaire. 

●

TITLIV : Titre du livre. 

●

NOAUT : Nom de l’auteur. 

La demande de la librairie B1 correspond un tri particulier des livres de B1 et B2 qui s’appelle, en algèbre relationnelle, une 

© ENI Editions - All rigths reserved

- 7-

différence de leurs relations : LIVREB1 ­  LIVREB2.  Les relations LIVREB1 et LIVREB2 ont le même schéma, donc il est effectivement possible de répondre à la question par  LIVREB1 ­ LIVREB2.  Nous faisons la différence LIVREB1 ­  LIVREB2  et non  LIVREB2 ­ LIVREB1. En effet, du fait de la demande  des  bibliothécaires,  nous  conservons  de  base  tous  les  tuples  de  B1  sur  lesquels  nous  appliquerons  un  contrôle éliminatoire (ne pas appartenir à B2). 

La relation résultante DIFLIVRE aura pour schéma  et regroupera tous les tuples appartenant à  LIVREB1 et n’appartenant pas à LIVREB2. 

  Considérons LIVREB1 et LIVREB2 en extension : 

  Nous allons visualiser cette différence par étapes :  1) La relation résultante DIFLIVRE aura pour schéma .  2) Elle contiendra tous les tuples appartenant à LIVREB1.  Nous obtenons : 

 

- 8-

© ENI Editions - All rigths reserved

3) Puis, il faut ensuite éliminer de cet ensemble de tuples, les tuples qui appartiendraient aussi à B2.  Dans notre exemple, il n’y en a qu’un : <102, Le soir des fourmiz,Bertrand>.  Nous obtenons : 

 

c. Exercice  Énoncé Supposons qu’une grande librairie B1 rachète une petite librairie B2 et décide de ne conserver en vente que les livres de  B2 ; mais, de plus, s’il y a un livre de B2 qui est référencé chez B1, il est retiré de la vente.  Quelle est la relation B2B1LIV qui répond à cette demande ?  Solution B2B1LIV = LIVREB2 ­ LIVREB1.  La  relation  B2B1LIV  aura  le  même  schéma  relationnel  que  LIVREB1  et  LIVREB2  et  contiendra  tous  les  tuples  appartenant à LIVREB2 mais n’appartenant pas à LIVREB1.  Nous obtenons : 

    Attention ! R2 ­ R1 ≠ R1 ­ R2.

4. Le produit cartésien  a. Définition  Le produit cartésien de deux relations R1 et R2 est la relation R, dont :  ●

le schéma relationnel est constitué de la concaténation des attributs du schéma de R1 et du schéma de  R2, 

●

les tuples sont issus de toutes les combinaisons des tuples de R1 avec les tuples de R2. 

Les deux tables participant au produit cartésien n’ont pas forcément le même schéma.  On notera : R = R1 X R2 = R1 * R2  L’opération de produit cartésien des relations est la même opération que celle du produit cartésien des domaines (cf.  chapitre Introduction à l’algèbre relationnelle ­ Concepts ­ Produit cartésien).  La  relation  résultante  du  produit  cartésien  aura  une  clé  primaire  différente  de  chacune  de  celles  des  relations  participant au produit cartésien.  La modélisation graphique du produit cartésien est la suivante : 

© ENI Editions - All rigths reserved

- 9-

 

b. Exemples  Exemple 1 :  Supposons que le SI d’une grande bibliothèque possède, entre autres, deux relations :  LIVRE ayant pour schéma  qui recense les livres de la bibliothèque, où :  ●

NULIV : Numéro de livre, clé primaire. 

●

TITLIV : Titre du livre. 

●

NBPAGE : Nombre de pages. 

La relation LIVRE en extension se présente ainsi : 

  ANNEX ayant pour schéma , qui recense les annexes de la bibliothèque, où :  ●

NUAN : Numéro de l’annexe, clé primaire. 

●

VILAN : Nom de la commune de l’annexe. 

La relation ANNEX en extension se présente ainsi : 

  Si nous faisons le produit cartésien de ces 2 relations, nous allons obtenir une nouvelle relation contenant 1 tuple par ville  possible et par livre possible.  Appelons VILLIB la nouvelle relation :  VILLIB = LIVRE * ANNEX.  Son schéma est la concaténation des schémas de LIVRE et d’ANNEX. 

- 10 -

© ENI Editions - All rigths reserved

Donc, VILLIB a pour schéma < NULIV, TITLIV, NBPAGE, NUAN, VILAN>. Cette relation aura une clé primaire différente de  celle  de  la  relation  LIVRE  et  de  celle  de  la  relation  ANNEX,  car  aucune  d’elle  prise  individuellement  ne  pourra  assurer  l’unicité de chaque tuple de VILLIB. Dans notre exemple, une clé candidate pourrait être, par exemple, la composition des  attributs NULIV­NUAN. 

  L’ensemble de ces tuples est le produit cartésien des tuples de LIVRE et d’ANNEX.  Nous obtenons : 

  Exemple2 :  Supposons que le SI d’une grande bibliothèque possède une autre relation en plus des deux précédentes.  Soit la relation LECTEUR ayant pour schéma  recensant les lecteurs de la bibliothèque, où :  ●

NULEC : Numéro de lecteur, clé primaire. 

●

NOLEC : Nom du lecteur. 

●

NUANL : Numéro annexe. 

Cette relation en extension se présente ainsi : 

  Soit VILLEC, le produit cartésien de LECTEUR et d’ANNEX.  VILLEC = LECTEUR * ANNEX. 

© ENI Editions - All rigths reserved

- 11 -

Le schéma relationnel de VILLEC est le suivant : .  La relation VILLEC en extension, va se présenter ainsi : 

  Vous  remarquez  que  le  produit  cartésien  de  2  ou  n  relations  construit  l’ensemble  exhaustif  de  toutes  les  possibilités  permises. La relation représentant la réalité sera généralement un sous­ ensemble du produit cartésien de ces  relations.  En  effet,  dans  l’exemple  précédent,  certains  tuples,  répondant  correctement  à  l’opération  du  produit  cartésien,  ne  représentent pas la réalité. Pour connaître le nom réel de l’annexe à laquelle est inscrit un lecteur, il faut une égalité  entre les attributs NUANL et NUAN. 

  Donc,  la  représentation  de  la  réalité  (annexe  à  laquelle  est  inscrite  un  lecteur)  est  un  sous­ensemble  du  produit  cartésien de la relation LECTEUR et de la relation ANNEX (de la bibliothèque).  Comment allons­nous faire pour obtenir les informations exhaustives de la réalité, sans informations parasites (donc  sans tuples inutiles), à partir d’informations provenant de plusieurs relations ? 

- 12 -

© ENI Editions - All rigths reserved

Les jointures  Cette question trouve sa réponse avec l’opération de jointure, et plus particulièrement, avec la jointure naturelle.  L’opération  de  jointure  est  une  opération  essentielle  en  algèbre  relationnelle  et  pour  les  utilisateurs  d’une  base  de  données.  En effet, nous avons structuré, dans les chapitres précédents, nos données pour qu’elles constituent des informations  cohérentes et nous les avons organisées, entre elles, de telle manière que cela soit le miroir de la réalité, via le schéma  entités­ associations. En particulier, les associations de ce dernier représentent les liens entre les entités.  Ainsi,  quand  les  utilisateurs  voudront  retrouver  des  informations  de  synthèse  (liste  des  factures  de  tel  ou  tel  client,  nomenclature d’un produit…)…, il faudra qu’ils rapprochent ces informations, disséminées sur plusieurs relations, avec un  ou plusieurs critères de rapprochement pour isoler les bonnes données et obtenir des résultats exacts.  La jointure est un dérivé du produit cartésien avec, en plus, une condition permettant de comparer la valeur d’attributs.  Il y aura une étape de concaténation d’attributs provenant de deux relations puis élimination des tuples ne vérifiant pas  la condition de rapprochement.  Comme  pour  l’opération  de  produit  cartésien,  les  deux  tables  participant  à  la  jointure  n’ont  pas  forcément  le  même  schéma.  Suivant la condition restrictive, la jointure prendra différents noms. 

1. Les jointures internes  a. La Θ­jointure  Définition La  jointure  thêta  (ou  join)  est  l’opération  qui  consiste,  à  partir  du  produit  cartésien  de  deux  relations  R1 (A’1,A’2…A’n) et R2(A’’1,A’’2 …A’’n) et à une condition de rapprochement C de ces deux relations, à créer une  nouvelle relation R conservant les tuples satisfaisant au prédicat.  On notera :  R = j o i n ( R 1 , R 2 , A ’ i < o p é r a t e u r > A ’ ’ j ) ∀i , j ∈ E ( e n t i e r s ) Ou R = R1

⊲⊳

R2

A’i A’’j L’opérateur appartient à l’ensemble {=, < , ≤ , >, ≧ , ≠ }.    Les attributs A’i et A’’j doivent appartenir à des domaines de valeurs comparables.

La modélisation graphique de la Θ­jointure est la suivante : 

  Le principe est donc, à partir de deux relations R1 et R2 et avec une condition de rapprochement (Θ), de construire  une nouvelle relation R3. 

© ENI Editions - All rigths reserved

- 1-

La  condition  de  rapprochement  impliquera  un  attribut  de  R1  et  un  attribut  de  R2  sur  lesquels  sera  appliqué  un  opérateur algébrique (égalité, inférieur, inférieur ou égal, etc.).  La relation R3 contiendra l’ensemble des tuples obtenus en concaténant les tuples (ensemble d’attributs) de R1 et  de R2, vérifiant la condition de rapprochement.  Exemple  Reprenons l’exemple précédent de la bibliothèque dont le SI possède, entre autres, deux relations : LIVRE  et ANNEX.  La relation LIVRE en extension se présente ainsi : 

  La relation ANNEX en extension se présente ainsi : 

  Nous ne voulons conserver que les livres dont le nombre de pages NBPAGE est supérieur au numéro d’annexe  NUAN d’ANNEX.  Il  faut  construire  la  relation  LIVRETANNEX  issue  de  la  théta­jointure  sur  LIVRE  et  ANNEX,  reposant  sur  la  condition  NBPAGE de LIVRE > NUAN d’ANNEX.  La représentation graphique est la suivante : 

  La  relation  LIVRETANNEX  =   join  (LIVRE,  ANNEX,  NBPAGE  >  NUAN)  contiendra  tous  les  tuples  provenant  de  la  concaténation des attributs des tuples de LIVRE, avec les attributs des tuples d’ANNEX pour lesquels l’attribut  NBPAGE de LIVRE est strictement supérieur à l’attribut NUAN d’ANNEX.  La relation LIVRETANNEX en intention se présente ainsi : LIVRETANNEX< NULIV, TITLIV, NBPAGE, NUAN, VILAN>  Le contenu de cette relation va se constituer en deux étapes :  1) D’abord un produit cartésien : 

- 2-

© ENI Editions - All rigths reserved

  2) Puis élimination des tuples qui ne vérifient pas la condition (NBPAGE > NUAN) : 

  En définitive, la relation LIVRETANNEX = join (LIVRE, ANNEX, NBPAGE > NUAN) en extension est la suivante : 

  Les tuples de la relation répondent bien à la condition de la theta­jointure demandée.  Nous remarquons qu’une jointureest un produit cartésien suivi d’une restriction pour laquelle la condition  porte sur deux attributs de la même relation. 

Rappelons­nous la définition d’une restriction :  © ENI Editions - All rigths reserved

- 3-

La sélection (ou restriction ) (select ou σ) est l’opération qui consiste, à partir d’une relation R (A1, A2,…An), à créer une  nouvelle relation R’(A1, A2…An) dont tous les tuples vérifient une propriété d’un attribut Ai que l’on note :   R’ = σAi  (R) ∀i ∈ E (entiers)  L’opérateur appartient à l’ensemble {=, < , ≤ , >, ≥ , ≠ }.  La valeur appartient au domaine de l’attribut Ai.  En effet, si nous considérons la jointure J de deux relations R(A1, A2, …An) et R’(A’1,A’2,…A’n), nous construisons d’abord  le produit cartésien :  R X R’= (A1, A2,…An,A’1,A’2,…A’n)  Puis la sélection : σAi   (RXR’).   représente les valeurs prises par l’attribut A’j appartenant à RXR’ comme l’attribut Ai.  Cette remarque sera vraie pour tous les types de jointure. 

b. L’équi­jointure  Définition L’équi­jointure est une jointure thêta où l’opérateur de rapprochement est une égalité (=).  On notera :  R = j o i n ( R 1 , R 2 , A ’ i = A ’ ’ j ) ∀i , j ∈ E ( e n t i e r s ) Ou

R

= R1

⊲⊳ R2 A’i = A’’j

La modélisation graphique de l’équi­jointure est la suivante : 

  Exemples Exemple 1 :  Reprenons l’exemple précédent de la bibliothèque dont le SI possède, entre autres, deux relations : LIVRE  et ANNEX.  La relation LIVRE en extension se présente ainsi : 

  La relation ANNEX en extension se présente ainsi : 

- 4-

© ENI Editions - All rigths reserved

  Nous ne voulons conserver que les livres dont le nombre de pages NBPAGE est égal au numéro d’annexe NUAN  d’ANNEX.  Il  faut  construire  la  relation  EQUILA,  issue  de  l’équi­jointure  sur  LIVRE  et  ANNEX,  reposant  sur  la  condition  NBPAGE  de  LIVRE = NUAN d’ANNEX.  La représentation graphique est la suivante : 

  La  relation  EQUILA  =   join  (LIVRE,  ANNEX,  NBPAGE  =   NUAN)  contiendra  tous  les  tuples  provenant  de  la  concaténation des attributs des tuples de LIVRE, avec les attributs des tuples d’ANNEX pour lesquels l’attribut  NBPAGE de LIVRE est égal à l’attribut NUAN d’ANNEX.  La relation EQUILA en intention se présente ainsi : EQUILA  Le contenu de cette relation va se constituer en deux étapes :  1) D’abord, un produit cartésien : 

  2) Puis, élimination des tuples qui ne vérifient pas la condition (NBPAGE = NUAN) : 

© ENI Editions - All rigths reserved

- 5-

  En définitive, la relation EQUILA = join (LIVRE, ANNEX, NBPAGE = NUAN) en extension est la suivante : 

  Exemple 2 :  Reprenons l’exemple de la bibliothèque précédente avec deux nouvelles relations : LIVRE   et ANNEX .  L’attribut NUANL représente le Numéro d’annexe auquel appartient le livre.  La relation LIVRE en extension se présente ainsi : 

  La relation ANNEX en extension se présente ainsi : 

  Nous ne voulons conserver que les livres dont le numéro d’annexe NUANL existe dans la relation ANNEX. Cela se  traduit  en  la  recherche  des  livres  dont  le  numéro  d’annexe  NUANL  est  égal  à  un  numéro  d’annexe  NUANA  d’ANNEX.  Il  faut  construire  la  relation  RECENS,  issue  de  l’équi­jointure  sur  LIVRE  et  ANNEX,  reposant  sur  la  condition  NUANL  de  LIVRE = NUANA d’ANNEX.  La représentation graphique est la suivante : 

- 6-

© ENI Editions - All rigths reserved

  La  relation  RECENS  =   join  (LIVRE,  ANNEX,  NUANL  =   NUANA)  contiendra  tous  les  tuples  provenant  de  la  concaténation des attributs des tuples de LIVRE, avec les attributs des tuples d’ANNEX pour lesquels l’attribut  NUANL de LIVRE est égal à l’attribut NUANA d’ANNEX.  La relation RECENS en intention se présente ainsi : RECENS   Le contenu de cette relation va se constituer en deux étapes :  1) D’abord le produit cartésien des deux relations : 

  2) Puis, élimination des tuples qui ne vérifient pas la relation d’équi­jointure (NUANL= NUANA) : 

  En définitive, la relation RECENS = join (LIVRE, ANNEX, NUANL = NUANA) en extension est la suivante : 

© ENI Editions - All rigths reserved

- 7-

  Les tuples de la relation répondent bien à la condition de l’équi­jointure demandée.  Comme  précédemment,  par  l’opération  d’équi­jointure,  les  deux  attributs  égaux  sont  conservés  dans  les  tuples de la relation résultante.Donc, pour chacun des tuples, il y a deux valeurs identiques et représentant  la  même  information :  il  y  a  donc,  redondance  d’informations.  Pour  éliminer  celles­ci,  une  équi­jointure  plus  élaborée a été inventée : la jointure naturelle. 

c. La jointure naturelle  Définition La jointure naturelle R de R1 et R2 est une équi­jointure dont la condition de rapprochement concerne tous les  attributs, A’i de R1 et A’’i de R2, de même nom et dont une occurrence de chaque attribut commun est éliminée.  On la notera R = R1 ⊳ ⊳⊲ R2.  Autrement dit, la jointure naturelle est une équi­jointure entre attributs de même nom suivie d’une projection sur un des  deux attributs commun.  Les attributs de même nom appartiennent aussi au même domaine.  La jointure naturelle porte sur des attributs de même nom, même domaine mais appartenant à des relations  distinctes. Aussi, en pratique, nous ferons le plus souvent des jointures naturelles qui porteront sur une clé  primaire et une clé étrangère (cf. chapitre Modélisation des données ­ Les modèles Merise ­ Règle N°3). 

La modélisation graphique de la jointure naturelle est la suivante : 

  La condition de rapprochement est obligatoirement une égalité et obligatoirement entre attributs de même nom.  Exemples Exemple 1 :  Reprenons  l’exemple  de  la  bibliothèque  précédente  avec  les  deux  relations :  LIVRE   et  ANNEX .  L’équi­jointure  effectuée  dans  le  paragraphe  précédent  n’était  pas  une  jointure  naturelle  puisque  les  deux  attributs  concernés par la jointure ne portaient pas le même nom, on ne pouvait donc pas supprimer une de leurs occurrences dans  la relation résultante.  Exemple 2 :  Prenons  le  SI  d’une  bibliothèque  avec  les  deux  relations  suivantes :  LIVRE   et  ANNEX  .  La relation LIVRE en extension se présente ainsi : 

- 8-

© ENI Editions - All rigths reserved

  La relation ANNEX en extension se présente ainsi : 

  Nous ne voulons conserver que les livres dont le numéro d’annexe existe dans la relation ANNEX. Cela se traduit  en la recherche des livres de la relation LIVRE dont le numéro d’annexe NUAN est égal à un numéro d’annexe  NUAN d’ANNEX.  Pour répondre à cette demande, nous devons faire une jointure (conservation des attributs mais élimination des tuples ne  répondant pas à la condition).  C’est une jointure avec l’opérateur =, entre deux attributs de même nom, et plus précisément une jointure naturelle.  La représentation graphique est la suivante : 

  Nous allons passer par plusieurs étapes pour obtenir la relation résultante :  1) D’abord, le produit cartésien des deux relations : 

 

© ENI Editions - All rigths reserved

- 9-

2) Puis, élimination des tuples qui ne vérifient pas la relation de jointure (NUAN= NUAN) : 

  3) Nous obtenons : 

  4) Nous supprimons l’attribut en double pour obtenir la relation finale : 

  Nous avons le numéro du livre, son titre, son auteur qui est dans une annexe recensée dans le SI et nous avons aussi le  nom de cette annexe.  Nous remarquons que la jointure naturelle a porté sur NUAN qui est clé primaire d’ANNEX et clé étrangère de  LIVRE. 

Les  relations  résultantes  des  différentes  jointures  que  nous  avons  vues  (theta­jointure,  équi­jointure,  jointure  naturelle)  ne  conservent  que  les  tuples  qui  vérifient  la  condition  de  jointure.  Donc,  les  tuples  éliminés  (d’au moins  une relation) sont occultés dans le résultat.  Or  ceux­ci  peuvent,  dans  certains  cas,  apporter  une  information  complémentaire  à  l’utilisateur.  N’oublions  pas  que  nos exemples traitent des relations avec une dizaine de tuples faciles à retrouver, mais dans la réalité, elles peuvent  contenir des milliers, voire des millions de lignes.  Un nouveau type de jointure a été créé qui permet de préserver l’intégralité des données, tout en différenciant celles  qui répondent au critère de jointure et celles qui n’y répondent pas.  Ce sont les jointures externes. 

2. La jointure externe  Dans le cas d’une jointure externe, les tuples ne vérifiant pas la condition de rapprochement seront conservés avec un  signe distinctif dans la relation résultante.  Quel sera le signe distinctif utilisé ? La valeur Nulle.  Suivant  l’appartenance  des  tuples  conservés  avec  un  signe  distinctif,  à  telle  ou  telle  relation,  nous  parlerons  de  jointure externe entière, gauche, droite. 

a. La jointure externe entière 

- 10 -

© ENI Editions - All rigths reserved

Définition La jointure externe entière est l’opération qui consiste, à partir d’une jointure entre deux relations R1(A’1,A’2… A’n)  et  R2(A’’1,A’’2 …A’’n),  à  créer  une  nouvelle  relation  R  incluant  tous  les  tuples  des  deux  relations  satisfaisant ou non au prédicat, mais avec des valeurs nulles sur les attributs des tuples n’y satisfaisant pas.  On notera :  R = e x t - j o i n ( R 1 , R 2 , A ’ i < o p é r a t e u r > A ’ ’ j ) ∀i , j ∈ E ( e n t i e r s ) ⊳⊲ R2 . A’i A’’j

Ou R = R1

L’opérateur appartient à l’ensemble {=, < , ≤ , >, ≥ , ≠ }.  Dans la pratique, bien qu’il soit possible de faire des conditions de recherche complexes, l’opérateur le plus  souvent utilisé sera l’opérateur ‘égal’ et le plus souvent entre une clé primaire et une clé étrangère de même  nom (jointure naturelle). Nous baserons nos exemples sur ce prédicat. 

La représentation graphique est la suivante : 

  Exemple  Reprenons le SI d’une bibliothèque avec les deux relations suivantes : LIVRE  et ANNEX  .  La relation LIVRE en extension se présente ainsi : 

  La relation ANNEX en extension se présente ainsi : 

  Nous  voulons  faire  ressortir  les  livres  dont  le  numéro  d’annexe  existe  dans  la  relation  ANNEX,  tout  en  conservant les livres appartenant à une annexe inexistante et les annexes n’ayant pas de livres. 

© ENI Editions - All rigths reserved

- 11 -

Pour répondre à cette demande, nous devons faire une jointure externe entière avec une condition d’égalité entre NUAN de  LIVRE et NUAN d’ANNEX.  Nous allons obtenir la relation résultante LIVREJE  La représentation graphique est la suivante : 

  Nous allons passer par plusieurs étapes pour obtenir la relation résultante.  1) D’abord, le produit cartésien des deux relations : 

  2) Puis, nous recherchons les livres qui n’appartiennent pas à une annexe existante : 

  - 12 -

© ENI Editions - All rigths reserved

3) Pour chacun de ces tuples, la condition d’égalité n’est pas vérifiée.  Nous allons marquer les attributs d’ANNEX, qui lui ont été liés par le produit cartésien, par le signe distinctif "valeur nulle". 

  4) Puis, nous recherchons les annexes n’ayant pas de livres : 

  5) Pour chacun de ces tuples, la condition d’égalité n’est pas vérifiée.  Nous allons marquer les attributs de LIVRE, qui lui ont été liés par le produit cartésien, par le signe distinctif "valeur nulle". 

© ENI Editions - All rigths reserved

- 13 -

  5) Nous supprimons les tuples en doublons : 

  Nous obtenons : 

  6) Enfin, comme nous sommes dans le cadre d’une jointure naturelle, il faut supprimer une des occurrences de l’attribut  en double : 

- 14 -

© ENI Editions - All rigths reserved

  En regardant cette relation, nous obtenons les informations suivantes :  ●

Le seul livre qui appartient à une annexe existante, 

●

Les livres qui n’appartiennent à aucune annexe existante, 

●

Les annexes n’ayant aucun livre. 

Il  sera  possible  d’affiner  cette  jointure  externe  en  ne  conservant  les  tuples  ne  participant  à  la  correspondance que d’une seule des deux relations. 

b. La jointure externe gauche  Définition La jointure exerne gauche est l’opération qui consiste, à partir d’une jointure entre 2 relations R1(A’1,A’2…A’n)  et R2(A’’1,A’’2 …A’’n), à créer une nouvelle relation R incluant tous les tuples des deux relations satisfaisant au  prédicat  et  ceux  de  R1  n’y  satisfaisant  pas,  mais  avec  des  valeurs  nulles  sur  les  attributs  des  tuples  n’y  satisfaisant pas.  On notera :  R = L e x t - j o i n ( R 1 , R 2 , A ’ i < o p é r a t e u r > A ’ ’ j ) ∀i , j ∈ E ( e n t i e r s ) ⊳⊲ R2 . A’i A’’j

Ou R = R1

L’opérateur appartient à l’ensemble {=, < , ≤ , >, ≥ , ≠ }.  Dans la pratique, bien qu’il soit possible de faire des conditions de recherche complexes, l’opérateur le plus  souvent utilisé sera l’opérateur = et le plus souvent entre une clé primaire et une clé secondaire (jointure  naturelle). 

La représentation graphique est la suivante : 

© ENI Editions - All rigths reserved

- 15 -

  Exemple  Reprenons le SI d’une bibliothèque avec les deux relations suivantes : LIVRE  et ANNEX  .  La relation LIVRE en extension se présente ainsi : 

  La relation ANNEX en extension se présente ainsi : 

  Nous  voulons  faire  ressortir  les  livres  dont  le  numéro  d’annexe  existe  dans  la  relation  ANNEX,  tout  en  conservant les livres appartenant à une annexe inexistante.  Pour répondre à cette demande, nous devons faire une jointure externe gauche avec une condition d’égalité entre NUAN de  LIVRE et NUAN d’ANNEX.  Nous allons obtenir la relation résultante LIVREJEG  La représentation graphique est la suivante : 

  Nous allons passer par plusieurs étapes pour obtenir la relation résultante :  1) D’abord, le produit cartésien des deux relations : 

- 16 -

© ENI Editions - All rigths reserved

  2) Puis, nous recherchons les livres qui n’appartiennent pas à une annexe existante : 

  3) Pour chacun de ces tuples, la condition d’égalité n’est pas vérifiée.  Nous allons marquer les attributs d’ANNEX, qui lui ont été liés par le produit cartésien, par le signe distinctif "valeur nulle". 

© ENI Editions - All rigths reserved

- 17 -

  4) Puis, nous recherchons les annexes n’ayant pas de livres : 

  5) Pour chacun de ces tuples, la condition d’égalité n’est pas vérifiée.  Nous les supprimons et nous obtenons : 

  6) Nous supprimons les tuples en doublons : 

- 18 -

© ENI Editions - All rigths reserved

  Et nous obtenons : 

  7) Enfin, comme nous sommes dans le cadre d’une jointure naturelle, il faut supprimer une des occurrences de l’attribut  en double : 

  En regardant cette relation, nous obtenons les informations suivantes :  ●

Le seul livre qui appartient à une annexe existante, 

●

Les livres qui n’appartiennent à aucune annexe existante. 

c. La jointure externe droite  Définition La jointure exerne droite est l’opération  qui  consiste,  à  partir  d’une jointure entre deux relations R1(A’1,A’2… A’n) et R2(A’’1,A’’2 …A’’n), à créer une nouvelle relation R incluant tous les tuples des 2 relations satisfaisant  au  prédicat  et  ceux  de  R2  n’y  satisfaisant  pas,  mais  avec  des  valeurs  nulles  sur  les  attributs  des  tuples  n’y  satisfaisant pas.  On notera :  R = R2

Rext-join

(R1,

R2,

A’i



A ’ ’ j ) ∀i , j

∈ E

(entiers)Ou

R

=

R1

⊳⊲

. A’i A’’j L’opérateur appartient à l’ensemble {=, < , ≤ , >, ≥ , ≠ }.  Dans la pratique, bien qu’il soit possible de faire des conditions de recherche complexes, l’opérateur le plus  souvent utilisé sera l’opérateur = et le plus souvent entre une clé primaire et une clé secondaire (jointure  naturelle).  © ENI Editions - All rigths reserved

- 19 -

La représentation graphique est la suivante : 

  Exemple  Reprenons le SI d’une bibliothèque avec les deux relations suivantes : LIVRE  et ANNEX  .  La relation LIVRE en extension se présente ainsi : 

  La relation ANNEX en extension se présente ainsi : 

  Nous  voulons  faire  ressortir  les  livres  dont  le  numéro  d’annexe  existe  dans  la  relation  ANNEX,  tout  en  conservant les annexes n’ayant aucun livre.  Pour répondre à cette demande, nous devons faire une jointure externe droite avec une condition d’égalité entre NUAN de  LIVRE et NUAN d’ANNEX.  Nous allons obtenir la relation résultante LIVREJED  La représentation graphique est la suivante : 

 

- 20 -

© ENI Editions - All rigths reserved

Nous allons passer par plusieurs étapes pour obtenir la relation résultante :  1) D’abord, le produit cartésien des deux relations : 

  2) Puis, nous recherchons les livres qui n’appartiennent pas à une annexe existante : 

  3) Pour chacun de ces tuples, la condition d’égalité n’est pas vérifiée.  Nous les éliminons et nous obtenons : 

  4) Puis, nous recherchons les annexes n’ayant pas de livres : 

© ENI Editions - All rigths reserved

- 21 -

  5) Pour chacun de ces tuples, la condition d’égalité n’est pas vérifiée.  Nous allons marquer les attributs de LIVRE, qui lui ont été liés par le produit cartésien, par le signe distinctif "valeur nulle". 

  6) Nous supprimons les tuples en doublons éventuels. Il n’y en a pas.  Nous obtenons, donc : 

  7) Enfin, comme nous sommes dans le cadre d’une jointure naturelle, il faut supprimer une des occurrences de l’attribut  en double : 

  En regardant cette relation, nous obtenons les informations suivantes :  ●

Le seul livre qui appartient à une annexe existante, 

●

Les annexes n’ayant aucun livre. 

Tous les opérateurs d’algèbre relationnelle que nous venons de découvrir, peuvent être composés.  En  effet,  la  réponse  à  une  question  d’un  utilisateur  peut  ne  pas  être  issue  d’une  seule  opération  mais  d’un  ensemble  d’opérations  appliquées  sur  des  relations  originelles,  puis  sur  les  opérations  résultantes  intermédiaires, pour obtenir une relation résultat.  Nous pourrons représenter cette suite d’opérations par un arbre algébrique. 

- 22 -

© ENI Editions - All rigths reserved

L’arbre algébrique  L’arbre algébrique repose sur deux composants :  ●

Les nœuds : opérations de l’algèbre relationnelle. 

●

Les  arcs :  données  sur  lesquelles  seront  appliquées  les  opérations,  relations  originelles,  puis  toutes  les  relations intermédiaires et temporaires, qui sont des relations résultantes d’opérations  antérieures,  jusqu’à la  production de la relation résultat finale. 

Ce n’est pas si compliqué que cela, il suffit de suivre un cheminement logique.  Exemples Exemple 1 :  Reprenons  le  SI  d’une  bibliothèque  avec  les  deux  relations  suivantes :  LIVRE   et  ANNEX  .  La relation LIVRE en extension se présente ainsi : 

  La relation ANNEX en extension se présente ainsi : 

  Nous ne voulons conserver que les titres des livres appartenant à une annexe et le nom de celle­ci.  Analysons cette demande :  ●

Il  faut  ne  conserver  que  les  livres  appartenant  à  une  annexe  donc  nous  devons  faire  une  jointure,  entre  ces  deux  relations,  sur  la  condition  d’égalité  entre  NUAN  de  LIVRE  et  NUAN  d’ANNEX  (conservation  des  attributs  mais  élimination des tuples ne répondant pas à la condition).Ce sera une jointure naturelle. 

●

Mais de plus, les attributs qui doivent être conservés sont le titre du livre (TITLIV) qui appartient à la relation LIVRE et  le  nom  de  l’annexe  (VILAN)  qui  appartient  à  la  relation  ANNEX.  Donc,  il  faudra  appliquer  une  projection  pour  ne  conserver que les attributs pertinents. 

Mais dans quel ordre procéder ?  Faut­il faire la projection d’abord et ne conserver que TITLIV et VILAN puis faire la jointure naturelle ensuite ? Ou le contraire ?  Si nous ne conservons que TITLIV et VILAN, nous n’aurons plus les attributs NUAN de LIVRE et NUAN d’ANNEX pour réaliser  la condition de rapprochement.  Donc, il faut d’abord faire la jointure naturelle puis la projection.  Si nous appelons la relation résultante EXTRACT1, alors :  EXTRACT1 = ∏ TITLIV,VILAN (LIVRE ⊳⊲ ANNEX )  Il y a deux opérations à réaliser, nous pouvons faire un arbre algébrique pour représenter cette demande. 

© ENI Editions - All rigths reserved

- 1-

  Suivons l’évolution des relations jusqu’à la relation résultat EXTRACT1.  Nous partons des relations LIVRE et ANNEX.  Nous leur appliquons une jointure naturelle sur l’attribut NUAN, nous obtenons LIVRE⊳⊲ ANNEX en extension : 

  Puis,  nous  appliquons,  sur  cette  relation  intermédiaire  et  temporaire,  une  projection  sur  les  attributs  TITLIV  et  VILAN  pour  obtenir EXTRACT1.  La relation EXTRACT1 en extension se présente de la manière suivante : 

  Exemple 2 :  Supposons que deux bibliothèques B1 et B2 fusionnent et décident de rechercher les numéros et les titres des livres  qu’elles ont en commun, dont le numéro de livre est inférieur à 200.  Chacune des bibliothèques possède une relation LIVREB1 et LIVREB2 recensant les caractéristiques des livres.  La relation LIVREB1 a pour schéma .  Elle se présente en extension, ainsi : 

- 2-

© ENI Editions - All rigths reserved

  La relation LIVREB2 a pour schéma .  Elle se présente ainsi en extension : 

  Nous remarquons que LIVREB1 et LIVREB2 ont le même schéma.  Analysons la demande des utilisateurs.  Nous recherchons les livres en commun de B1 et B2, donc il va falloir faire une intersection de LIVREB1 et LIVREB2.  Mais  nous  n’avons  besoin  que  des  numéros  et  des  titres  des  livres,  donc  l’attribut  NOAUT  sera  éliminé  de  la  relation  résultante : il faudra faire une projection sur cette relation.  Il faudra aussi éliminer les tuples dont le numéro de livre est inférieur à 200, donc il faudra aussi faire une sélection sur les  tuples.  Dans quel ordre doivent se faire ces opérations ?  Avant de faire toutes les opérations unitaires, il faut d’abord faire les opérations ensemblistes pour s’assurer d’avoir regrouper  l’exhaustivité des tuples répartis sur plusieurs relations.  Donc, nous devons d’abord réaliser l’intersection.  La projection conserve le numéro de livre utilisé dans la sélection, donc nous pouvons faire indifféremment la projection avant  la sélection ou la sélection avant la projection.  Nous  avons  donc,  deux  possibilités  d’arbre  algébrique.  Appelons  la  relation  de  l’arbre  1  EXTRACT2  et  celle  de  l’arbre  2  EXTRACT3.  Arbre 1 

© ENI Editions - All rigths reserved

- 3-

  Suivons l’évolution des relations jusqu’à la relation résultat EXTRACT2 :  1) Nous partons des relations LIVRE et ANNEX. Nous leur appliquons une intersection, nous obtenons LIVRE ∩ ANNEX en  extension : 

  2) Puis, nous appliquons, sur cette relation intermédiaire et temporaire, une projection sur les attributs NULIV et TITLIV pour  obtenir une nouvelle relation intermédiaire.  Celle­ci se présente en extension : 

- 4-

© ENI Editions - All rigths reserved

  3) Enfin, nous appliquons une sélection sur cette relation, pour éliminer les tuples dont le numéro de livre est > = à 200, pour  obtenir la relation résultat EXTRACT2.  La relation EXTRACT2 en extension se présente de la manière suivante : 

  Arbre 2 

© ENI Editions - All rigths reserved

- 5-

  Suivons l’évolution des relations jusqu’à la relation résultat EXTRACT3 :  1) Nous partons des relations LIVRE et ANNEX. Nous leur appliquons une intersection, nous obtenons LIVRE ∩ ANNEX en  extension : 

  2) Puis, nous appliquons une sélection sur cette relation, pour éliminer les tuples dont le numéro de livre est > = à 200, pour  obtenir une nouvelle relation intermédiaire. 

- 6-

© ENI Editions - All rigths reserved

  3) Enfin, nous appliquons sur cette relation intermédiaire et temporaire, une projection sur les attributs NULIV et TITLIV pour  obtenir la relation résultat EXTRACT3.  La relation EXTRACT3 en extension se présente de la manière suivante : 

    Nous constatons que les relations EXTRACT2 et EXTRACT3 sont identiques.

© ENI Editions - All rigths reserved

- 7-

Fonctions et agrégats  Tous  les  opérateurs  précédents  nous  ont  permis  d’extraire  les  données  brutes  des  tuples ;  mais  dans  la  gestion  quotidienne  d’un  SI,  ces  informations  seront  insuffisantes  pour  répondre  aux  besoins  des  utilisateurs.  En  effet,  nous  n’avons pas traité les demandes d‘informations de synthèse, telles que le calcul d’un chiffre d’affaires par département,  le  cumul  du  montant  des  achats  d’un client, etc. Toutes les interrogations liées à des calculs sur les données restent  pour l’instant sans réponse.  C’est pour cela qu’il a fallu introduire les fonctions de calcul et d’agrégation dans l’algèbre relationnelle. 

1. Fonctions de calcul  Comment les fonctions de calcul ont­elles été introduites ?  Il  est  possible  de  remplacer,  dans  les  conditions  des  opérations,  un  attribut  utilisé  en  tant  qu’argument  par  une  composition de fonctions appliquées sur des attributs de la relation ou des constantes.  Généralement, ce sont des fonctions arithmétiques qui seront utilisées.  Ainsi, il est possible d’additionner des attributs, d’ajouter une constante à un attribut, etc.  Les domaines de valeurs des attributs auxquels sont appliquées les fonctions doivent être compatibles avec  celles­ci. Il ne sera pas possible d’additionner un attribut ville (valeurs composées de lettres alphabétiques) à  une constante numérique. 

Exemple  Considérons la relation CLIENT.  La clé primaire de cette relation est le numéro de client (NUCLI). Les autres attributs représentent les caractéristiques du  client : nom (NOCLI), Prénom (PNCLI) et total des achats effectués (TOTACH).  Cette relation en extension se présente ainsi : 

  Les  utilisateurs  veulent  connaître  les  numéro  et  nom  des  clients  à  qui  il  suffirait  de  faire  un  achat  de  100 € pour égaler ou dépasser un total d’achat de 1000 €.  Analysons cette demande :  Il  faut  extraire  les  tuples  dont  le  total  d’achats  effectués  +  100€ est  supérieur  à  1000€.  Arithmétiquement,  cela  s’écrira  (l’attribut TOTACH étant numérique) : TOTACH + 100 ≥ 1000.  Puis, de ces tuples extraits, il ne faudra conserver que deux attributs : numéro client et nom client.  Représentons l’arbre algébrique correspondant : 

© ENI Editions - All rigths reserved

- 1-

  La relation CLIENT [TOTACH + 100 ≥ 1000] en extension se présentera ainsi : 

  La relation finale BONCLIENT en extension se présentera ainsi : 

 

2. Fonctions d’agrégat  Les fonctions d’agrégat vont permettre de calculer une valeur simple à partir d’un ensemble de valeurs provenant d’un  même attribut mais de plusieurs tuples d’une relation.  Ces fonctions pourront s’appliquer à tous les tuples ou à une sélection de tuples d’une relation.  Les fonctions d’agrégat courantes, que l’on retrouvera en SQL, sont les suivantes : 

- 2-

© ENI Editions - All rigths reserved

●

COMPTE : compter les valeurs d’un attribut d’une relation, 

●

SOMME : additionner les valeurs d’un attribut d’une relation, 

●

MOYENNE : effectuer la moyenne des valeurs d’un attribut d’une relation, 

●

MAXIMUM : chercher la valeur maximale d’un attribut d’une relation, 

●

MINIMUM : chercher la valeur minimale d’un attribut d’une relation. 

Exemple :  Considérons la relation CLIENT.  La clé primaire de cette relation est le numéro de client (NUCLI). Les autres attributs représentent les caractéristiques du  client : nom (NOCLI), Prénom (PNCLI) et total des achats effectués (TOTACH).  Cette relation en extension se présente ainsi : 

  Les utilisateurs veulent connaître le total des achats effectués par tous les clients.  Analysons cette demande :  Il faut calculer le total des achats effectués par tous les clients : il faut donc effectuer la somme de toutes les valeurs de  l’attribut TOTACH.  Mais seul le résultat de cette fonction nous suffit, les autres attributs doivent être éliminés du résultat.  Représentons l’arbre algébrique correspondant : 

 

© ENI Editions - All rigths reserved

- 3-

La relation TOTACHAT= ∏ Somme(TOTACH)(CLIENT) en extension se présentera ainsi : 

 

- 4-

© ENI Editions - All rigths reserved

Des opérateurs au SQL  Nous  vous  présentons  quelques  exemples  de  traduction,  mais  nous  vous  laissons  le  soin  de  compléter  vos  connaissances par un livre spécialisé en SQL. 

 

© ENI Editions - All rigths reserved

- 1-

Synthèse  Grâce  aux  opérateurs  de  l’algèbre  relationnelle,  E.F.  Codd  a  inventé  un  véritable  langage  algébrique  qui  permet  de  répondre à la plupart des interrogations des utilisateurs d’une base de données d’un SI.  Nous  avons  vu  que  ces  opérateurs  permettaient  de  manipuler  une  relation  pour  extraire  des  informations  bien  précises, tels les opérateurs unaires de sélection et de projection.  Ils permettent aussi d’extraire des informations provenant de plusieurs relations de la base de données relationnelle.  En effet, les opérations ensemblistes, telles que le produit cartésien ou les jointures internes et externes, mettent en  jeu  initialement  deux  relations ;  mais  grâce  à  la  propriété  de  composition  de  ces  opérations,  nous  pouvons  en  relier  beaucoup plus.  Les fonctions de calcul et d’agrégat apportent un complément puissant car elles permettent de donner des réponses à  des demandes d’informations synthétiques ; mais il faudra toujours analyser la demande des utilisateurs et la traduire  sous forme mathématique pour répondre correctement à leurs besoins.  Puis, le cheminement des relations originelles à la relation répondant à la requête des utilisateurs pourra être modélisé  par  un  arbre  algébrique.  Celui­ci  mettra  en  lumière  les  différentes  relations  intermédiaires  utilisées  et  les  enchaînements des opérations effectuées, et parfois éventuellement les possibilités de parallélisme de celles­ci.  Les  concepts  que  nous  venons  d’étudier  constituent  la  base  du  langage  SQL,  langage  effectivement  utilisé  sur  les  tables (issues des relations, cf passage du modèle conceptuel de données au modèle logique de données de Merise)  des bases de données. 

© ENI Editions - All rigths reserved

- 1-

Exercices  1. Exercice 1  a. Énoncé  Soit  la  relation  ANIMAUX  (NOTATO,  Nom,  Race,  Age,  Ordre)  recensant  les  animaux  soignés  par  une  clinique  vétérinaire où NOTATO est le numéro de tatouage.  Cette relation en extension contient : 

  1) Traduire en français les opérations suivantes puis donner les schémas en extension des relations résultantes :  ●

a) σ AGE = 7 (ANIMAUX) 

●

b) ∏ Age (ANIMAUX) 

●

c) ∏ Age (σ NOM = ‘ZIP’ (ANIMAUX)). Donner l’arbre algébrique de cette composition d’opérations. 

2) Exprimer les demandes suivantes en opérations de l’algèbre relationnelle puis donner les schémas en extension  des relations résultantes :  ●

a) Nous voulons conserver les animaux qui sont des chiens. 

●

b) Nous voulons conserver toutes les données des animaux qui sont âgés de moins de 8 ans. 

●

c) Nous voulons conserver l’âge et la race des animaux qui sont des bovins. Donner l’arbre algébrique des  opérations qui permettront de trouver ce résultat. 

b. Solution  1) Traduction en français et schéma en extension des relations résultantes :  ●

a) σ AGE = 7 (ANIMAUX) : nous voulons les données des animaux âgés de 7 ans.  C’est une restriction (sélection) qui conservera tous les attributs des tuples dont l’attribut AGE = 7.  σ AGE = 7 (ANIMAUX) en extension se présente ainsi : 

 

●

b) ∏ Age (ANIMAUX) : nous voulons voir l’âge de tous les animaux recensés dans la relation, sans doublons.  C’est une projection sur l’attribut Age de la relation ANIMAUX, qui éliminera les doublons éventuels. 

© ENI Editions - All rigths reserved

- 1-

∏ Age (ANIMAUX) en extension se présente ainsi : 

 

●

c) ∏ Age (s NOM = ‘ZIP’ (ANIMAUX)) : nous voulons visualiser uniquement l’âge des animaux qui se nomment  ‘ZIP’.  Il faudra faire une sélection puis une projection, l’arbre algébrique correspondant est le suivant : 

  La relation ∏ Age (σ NOM = ‘ZIP’ (ANIMAUX)) en extension se présente ainsi : 

  2)  Traduction  en  opérations  de  l’algèbre  relationnelle,  arbre  algébrique  et  schéma  en  extension  des  relations  résultantes. 

- 2-

© ENI Editions - All rigths reserved

●

a) Nous voulons conserver les animaux qui sont des chiens. 

Il n’y a pas de précision sur les données, donc tous les attributs sont à conserver.  Un  ‘chien’  est  un  ‘canidé’  qui  correspond  à  une  valeur  de  l’attribut  ordre.  Il  va  falloir  effectuer  une  sélection  (conservation  des  attributs)  avec  une  condition  sur  l’attribut  ORDRE  (pour  élimination  des  tuples  n’y  satisfaisant  pas).  Donc, pour répondre à la question, il faut faire l’opération suivante σ ORDRE = ‘Canidés’ (ANIMAUX).  La relation résultante en extension se présente ainsi : 

 

●

b) Nous voulons conserver toutes les données des animaux qui sont âgés de moins de 8 ans. 

C’est une sélection avec une condition sur l’attribut AGE strictement inférieur à 8 ans.  Pour répondre à cette question, il faut faire l’opération suivante σ AGE <8 (ANIMAUX).  La relation résultante en extension se présente ainsi : 

 

●

c) Nous voulons conserver l’âge et la race des animaux qui sont des bovins et donner l’arbre algébrique des  opérations qui permettront de trouver ce résultat. 

Les informations demandées sont l’âge et la race (projection pour éliminer des attributs), donc il faudra effectuer la  sélection sur l’ordre avant la projection.  La représentation algébrique de ces opérations est la suivante : 

© ENI Editions - All rigths reserved

- 3-

  La relation résultat en extension est la suivante : 

 

2. Exercice 2  a. Énoncé  La  base  de  données  relationnelle  du  SI  de  la  clinique  vétérinaire  BOCHIEN  contient,  outre  la  relation  précédente  ANIMAUX, la relation PROPRIETAIRE, où :  ●

CODEP est la clé primaire (code propriétaire), 

●

NOMP est le nom du propriétaire, 

●

PRENOM est le prénom du propriétaire, 

●

ACTIVITE est l’activité professionnelle du propriétaire. 

La  table  ANIMAUX  recensant  les  animaux  dese  propriétaires.  La  clé  primaire  CODEP  de  PROPRIETAIRE  lui  a  été  rajoutée en tant que clé étrangère.  Ces deux relations en extension se présentent ainsi : 

- 4-

© ENI Editions - All rigths reserved

 

  1) Donner le résultat de la relation suivante :  R = ∏ NOMP, NOM(ANIMAUX ⊳⊲ PROPRIETAIRE)  2) Nous voulons afficher les noms des animaux, les noms de leur propriétaire et leur code dont le code propriétaire  existe dans la relation PROPRIETAIRE, tout en conservant les propriétaires n’ayant pas d’animaux. 

b. Solution  1) Nous voulons le nom des propriétaires et de leurs animaux.  Pour ce faire, nous faisons une équijointure sur CODEP (code propriétaire) entre ANIMAUX et PROPRIETAIRE. Puis  nous appliquons une projection sur le résultat pour ne conserver que les attributs NOMP (Nom propriétaire) et NOM  (Nom animal). La relation résultante est la suivante : 

  2) Pour répondre à cette demande, nous devons effectuer une jointure externe droite avec une condition d’égalité  entre CODEP d’ANIMAUX et CODEP de PROPRIETAIRE.  Nous allons obtenir la relation résultante ANIMAUXJED.   La représentation graphique est la suivante : 

© ENI Editions - All rigths reserved

- 5-

  Nous obtenons le résultat suivant : 

 

3. Exercice 3  a. Énoncé  Considérons le SI suivant :  Nous gérons des clients qui achètent des produits vendus par des commerciaux. Si le client a besoin d’un produit et  qu’il est démarché par un commercial qui propose ce produit, il lui achète ce produit.  Chaque commercial ne vend pas tous les produits proposés par l’entreprise.  L’informaticien, qui a analysé ces règles de gestion, a construit la relation Achat suivante :  Achat  L’extension de cette relation est la suivante : 

- 6-

© ENI Editions - All rigths reserved

  1) Construire R’1 = ∏ NUCLI,NUCOM (ACHAT) ⊳⊲ ∏ NUCLI,NUPROD (ACHAT)  2) Construire R’2 = R’1 ⊳⊲ ∏ NUCOM,NUPROD (ACHAT)  3) R’2 = Achat ? 

b. Solution  1) a) Il faut d’abord construire ∏ NUCLI,NUCOM (ACHAT)  En extension, nous obtenons : 

  b) Puis, il faut construire ∏ NUCLI, NUPROD (ACHAT)  En extension, nous obtenons : 

© ENI Editions - All rigths reserved

- 7-

  c) Il faut maintenant construire  R’ = ∏ NUCLI,NUCOM (ACHAT) ⊳⊲ ∏ NUCLI,NUPROD (ACHAT)  La jointure se fera sur l’attribut commun NUCLI, avec élimination d’un des 2 attributs NUCLI en doublon.  R’1 en extension : 

  2) Il faut d’abord construire ∏ NUCOM,NUPROD (ACHAT)  En extension, nous obtenons : 

- 8-

© ENI Editions - All rigths reserved

  b) Puis, il faut construire :  R’2 = R’1 ⊳⊲ ∏ NUCOM,NUPROD (ACHAT)  C’est une jointure naturelle qui portera sur les 2 attributs communs aux deux relations : NUCOM et NUPROD. Les  tuples à conserver des 2 relations sont donc les tuples qui auront des couples de valeurs (valeur de NUCOM, valeur  de NUPROD) égaux.  Donc, certains tuples de R’1 ne sont pas à conserver : 

  Donc nous obtenons R’2 en extension : 

© ENI Editions - All rigths reserved

- 9-

  3) Nous obtenons bien R’2 = Achat. 

- 10 -

© ENI Editions - All rigths reserved

Introduction  Dans  les  chapitres  précédents,  nous  avons  vu  qu’il  était  possible  de  modéliser  le  monde  réel  et,  en  particulier  les  informations gérées dans un SI, par des relations.  L’ensemble  exhaustif  et  cohérent  des  relations  d’un  Système  d’Information  sert  à  construire  une  base  de  données  relationnelle.  L’objectif de ce livre étant de vous apprendre à faire des bases de données relationnelles de qualité, nous avons suivi  une méthode que nous considérons comme la plus optimum pour le faire.  Mais  cette  méthode  n’est  pas  le  passage  obligatoire ;  et  un  même  dictionnaire  de  données  et  les  mêmes  règles  de  gestion peuvent générer des schémas de relation différents, suivant l’interprétation  et  l’analyse de l’informaticien. Là  où le bât blesse, c’est que la qualité résultante sera aussi de niveau différent.  Aussi, le modèle relationnel est complété par "la théorie de la normalisation". Le but de la normalisation est de créer  les relations exhaustives au besoin du SI et ayant le nombre minimum d’attributs nécessaires. Les attributs de chacune  des relations doivent aussi avoir une redondance minimale et nécessaire.  Dans  ce  chapitre,  nous  détaillerons  les  critères  qui  permettent  de  dire  qu’une  base  est  de  meilleure  qualité  qu’une  autre et pourquoi une normalisation s’impose.  Puis,  nous  découvrirons  sur  quoi  repose  la  théorie  de  la  normalisation  (vous  comprendrez  enfin  l’importance  de  la  Matrice des Dépendances Fonctionnelles !) et l’ensemble des formes normales, définies par E. F. Codd, qui permettent  de vérifier un schéma de relation ou de l’affiner progressivement pour le normaliser, suivant l’approche utilisée. 

© ENI Editions - All rigths reserved

- 1-

La théorie de la normalisation  1. La relation universelle  L’expression  des  besoins  des  utilisateurs,  recensant  les  données  à  gérer  dans  leur  Système  d’Information  et  les  règles  de  gestion  à  y  appliquer,  est  à  l’origine  des  schémas  de  relation  et  de  la  base  de  données  relationnelle  résultante.  Généralement, en partant du dictionnaire des données, il est facile de regrouper les données d’une entité car elle a  toujours une existence visible dans la réalité.  Par  contre,  il  n’est  pas  toujours  évident  de  positionner  les  données  qui  semblent  dépendre  de  plusieurs  autres  données source.  Faut­il les regrouper :  ●

sous une donnée source aux dépens des autres données source (et donc si l’on se réfère au schéma entités­ associations, sous une entité) ? 

●

sous  une  composition  de  données  source  (et  donc,  sous  une  association  unissant  plusieurs  entités) ?  La  composition de ces données source est­elle exacte (toutes les données source nécessaires y sont­elles ? N’y  a­t­il pas une ou n donnée(s) source inutile(s) ?) ? 

Ces questions ne sont pas anodines, de leur réponse dépendra la qualité des schémas de relation.  Exemple  Reprenons l’exemple d’une grande entreprise française, fondée il y a 10 ans et comportant des filiales françaises.  L’étude  de  la  gestion  du  personnel  a  permis  d’apprendre  qu’un  employé  pouvait,  durant  toute  sa  vie  professionnelle,  travailler dans la même filiale ou changer de filiale tous les 3 ans (et en particulier, les cadres y sont obligés). Mais, dans  tous  les  cas,  il  ne  fera  qu’une  seule  période  dans  chacune  des  filiales.  Sa  vie  professionnelle  est  recensée,  dans  le  SI  de  l’entreprise, avec les dates d’arrivée et de départ dans chacune des filiales dans lesquelles il a travaillé.  Une filiale est constituée d’un directeur, d’un adjoint et d’au moins 10 employés (cadres et non­cadres).  Chaque employé est caractérisé par un numéro appelé code employé, qui est unique pour chacun.  De même, chaque filiale est connue par un numéro unique.  Un extrait du dictionnaire de données est le suivant : 

  Même  si  les  données  concernant  l’employé  (code  et  nom)  avaient  été  dispersées  dans  le  dictionnaire,  nous  aurions  pu  facilement les regrouper sachant que chacune concernait l’employé.  Le même raisonnement est valable pour le regroupement des données de la Filiale (numéro et ville).  Par contre, le positionnement des dates d’arrivée et de départ est plus difficile. 

© ENI Editions - All rigths reserved

- 1-

C’est l’employé qui arrive à telle date et qui part à telle date. Pourquoi ne pas regrouper ces deux données avec toutes les  données concernant l’Employé ?  ●

Oui, mais on ne sait pas quelle filiale est concernée par ces dates. 

●

Par  contre,  ce  n’est  pas  la  Filiale  qui  arrive  à  telle  date  et  qui  part  à  telle  date.  Donc,  cela  paraît  beaucoup  plus  naturel et logique de ne pas regrouper ces données avec celle de Filiale. Mais est­ce correct ? 

Le passage par la Matrice des Dépendances Fonctionnelles nous a permis de regrouper ces dates sous ce que nous avons  appelé des données source complexes et nous avons créé une nouvelle relation. Est­ce le bon choix ?  N’aurait­il pas fallu mettre dans la relation Employé, le N° de filiale, sa date d’arrivée et sa date de départ ?  ●

Dans ce cas, nous avions toutes les informations complètes concernant chaque employé. 

●

Mais dans ce cas, si nous avons le N° de filiale dans Employé, pourquoi ne pas y mettre aussi la localisation de la  filiale, correspondant au N° de filiale ? 

En apparence, nous n’avons que des avantages :  ●

Nous n’avons plus qu’une relation (table) à gérer, 

●

Nous avons, par le biais de ses attributs, toutes les données exhaustives du SI dans un tuple. 

Cette relation est appelée relation universelle. La base de données relationnelle est, alors, constituée d’un  seul schéma de relation. 

Si nous options pour ce dernier choix, nous obtiendrions la relation universelle en intention suivante :  Employé .  Les règles de gestion nous permettent de préciser les dépendances des attributs, les uns par rapport aux autres. Ainsi, dans  cet exemple, elles précisent qu’un employé n’a qu’un et un seul code employé.  Donc, le code de l’employé détermine d’une manière unique le nom de l’employé.  Regardons un extrait de celle­ci en extension, la gestion du personnel nous ayant donné des exemples de cadres et de non­ cadres : 

  Nous  constatons  qu’il  y  a  des  données  redondantes :  les  employés  DAVID  et  DUPONT  apparaissent  au  moins  deux  fois  dans la table Employé.  La localisation de la filiale 033 y apparaît 3 fois.  Ces redondances entraîneront des contraintes dans l’utilisation habituelle de la base de données. 

2. Les problèmes liés à la non­normalisation 

- 2-

© ENI Editions - All rigths reserved

En premier lieu, cette redondance des données induit un volume des tables plus important qu’il ne faudrait, et donc,  un coût de stockage plus important.  De plus, la mise à jour d’une donnée ne s’effectuera pas en un minimum d’opérations si celle­ci est redondante dans  une relation (= table).  Exemple :  Considérons la relation universelle Employé précédente.  Pour  corriger  une  erreur  de  saisie  dans  la  date  de  naissance  de  l’employé  DUPONT,  il  faudra  modifier  tous  les  tuples  concernant Dupont dans la table Employé. Dans cet exemple, il n’y a que 2 tuples, mais si Dupont avait été un cadre qui  change de filiale tous les 3 ans, il y aurait beaucoup plus de tuples à mettre à jour.  Or, chacune des opérations a une durée d’exécution, donc plus il y a d’opérations, plus le temps de mise à jour sera  important.  De plus, plus il y a de manipulations, plus il y a des risques d’erreur et donc, au final, des risques d’incohérences des  données.  En  effet,  sachant  que  nous  partons  toujours  d’une  base  de  données  où  toutes  les  données  sont  cohérentes  entre  elles,  nous  devons,  après  avoir  terminé  toutes  les  manipulations  de  données,  revenir  dans  un  état  tout  aussi  cohérent.  Or,  si parmi les  n  opérations  de  la  mise  à  jour,  il  apparaît  un  problème  quelconque  (technique…) qui  n’en  permet pas la bonne fin, nous nous retrouverons avec une base de données dans un état incohérent :  ●

Certaines opérations ayant réussi : mise à jour OK de la donnée X de certains tuples de la table. 

●

Certaines opérations étant en échec : la donnée X n’a pas été mise à jour dans certains tuples de la table. 

●

Ainsi, la même donnée X peut prendre plusieurs valeurs dans la même table. 

Enfin,  ces  redondances  de  données  peuvent  aussi  entraîner  des  anomalies  de  mise  à  jour.  Ces  anomalies  vont  concerner l’insertion, la suppression et la modification de données. 

a. Les anomalies d’insertion  En créant une nouvelle valeur d’une donnée, concernée par plusieurs tuples, il faudra veiller à ce que la saisie soit  correcte dans tous ces tuples.  En  effet,  dans  le  cas  contraire,  cela  peut  entraîner  une  anomalie  d’insertion  qui  aura  des  répercussions  dans  les  recherches ultérieures.  Exemple :  Considérons  que  l’entreprise ouvre une nouvelle filiale à Nantes. Il y aura plusieurs employés qui seront embauchés ou  mutés.  Pour  chacun  des  tuples  concernant  ces  employés,  la  saisie  de  VILFIL  devra  contenir  exactement  les  mêmes  caractères.  Sinon, pour la même filiale, la table en extension pourrait donner le résultat suivant : 

  Si le directeur général recherche les noms des employés de la filiale de Nantes, il ne trouvera que M. BOLO.  Par contre, si le directeur général recherche les noms des employés de la filiale de NANTES, il obtiendra les noms de M.  MIRO et de M. ONYX.  Le résultat de la recherche n’est pas, donc, pas fiable. 

© ENI Editions - All rigths reserved

- 3-

b. Les anomalies de suppression  En  supprimant  une  valeur  d’une  donnée  concernée  par  plusieurs  tuples,  il  faudra  veiller  à  ne  pas  générer  des  incohérences dans les données de la base de données.  Exemple :  Reprenons, la relation en extension initiale : 

  La Direction Générale a décidé de fermer la succursale d’Albi et donc de supprimer la filiale N° 051 dans la relation. 

  Nous constatons que le calcul de l’ancienneté de l’employé Dupont sera erroné puisque le temps passé à Albi a disparu de  la relation.  Nous  obtenons  une  incohérence  dans  les  données  de  la  relation.  Cette  incohérence  induit  la  non­ fiabilité  des  informations du SI. 

c. Les anomalies de modification  Comme dans les cas précédents, modifier une valeur d’une donnée concernée par plusieurs tuples, peut induire des  incohérences dans les données de la base de données. 

- 4-

© ENI Editions - All rigths reserved

Exemple :  Reprenons la relation en extension initiale : 

  Pour  corriger  une  erreur  de  saisie  dans  la  date  de  naissance  de  l’employé  DUPONT,  il  faut  modifier  tous  les  tuples  concernant Dupont dans la table Employé.  Il peut y avoir une erreur de saisie durant la manipulation et le résultat peut être le suivant : 

  En finalité, quel est l’âge exact de l’employé Dupont ?  Nous constatons que le calcul pour les droits à la retraite de l’employé Dupont sera erroné.  Nous  obtenons  une  incohérence  dans  les  données  de  la  relation.  Cette  incohérence  induit  la  non­fiabilité  des  informations du SI. 

3. La normalisation  a. Les objectifs  Nous  venons  de  voir  que  les  conséquences  des  problèmes,  liés  à  la  non­normalisation  des  relations  d’un  SI,  sont  importantes. À un certain degré, elles peuvent même être une atteinte à la pérennité de l’entreprise qui repose sur  ce SI.  Pour éviter ces inconvénients, la solution passe par la normalisation de la base de données relationnelle.  Quel est le but de la normalisation ?  Les objectifs de la normalisation sont les suivants :  ●

Regrouper  tous  les  attributs  strictement  nécessaires  dans  une  relation.  Ces  attributs  seront  liés  par  une  condition très forte (appelée dépendance fonctionnelle ou DF) permettant de définir leur appartenance à ce  groupe, dans une relation. 

●

Éliminer  le  maximum  de  redondances  et  n’en  garder  que  les  strictement  nécessaires  (que  l’on  identifiera 

© ENI Editions - All rigths reserved

- 5-

comme clé de relation étrangère).  Ces principes mis en œ uvre permettront de construire une base de données :  ●

nécessitant moins d’espace physique pour son stockage, 

●

dont la manipulation sera plus facile, 

●

et dont les traitements qui lui seront appliqués, donneront des résultats fiables. 

b. Les fondements de la normalisation  Dépendance fonctionnelle Nous  constatons  que  le  fondement  principal  de  la  normalisation  est  un  concept  déjà  connu :  celui  de  la DF  entre  attributs.  Dans le chapitre Étude de l’expression des besoins des utilisateurs, nous avions donné la définition suivante pour la  DF :  Deux données A et B sont en dépendance fonctionnelle, si la connaissance de la valeur de A permet d’identifier une  et une seule valeur de B.  Cet axiome doit être vrai pour toutes les valeurs de A. La première donnée est dite donnée source.  La seconde donnée est dite donnée cible.  Leur modélisation est la suivante : Source → Cible.  Nos connaissances en algèbre relationnelle nous permettent d’affiner cette définition de la manière suivante :  Soit un schéma de relation décrit par la relation universelle U (A1, A2… An), avec ∀i ∊ E (entiers), Ai étant un  attribut dont les valeurs appartiennent à un domaine Di.  On dira que :  ∀p, q ∈ E, Aq est fonctionnellement dépendant de Ap si et seulement si pour chaque valeur de Ap correspond une  valeur unique de Aq.  On écrira : Ap → Aq.    Dans cette définition, les attributs Ap et Aq peuvent chacun être remplacés par un ensemble d’attributs.

La DF, en normalisation, est une propriété des attributs dans une relation.  La  dépendance  fonctionnelle  entre  attributs  doit  être  vraie  dans  tous  les  cas.  Aussi,  la  dépendance  fonctionnelle  entre  attributs  d’une  relation  doit  être  vérifiée  pour  la  relation  en  intention  et  non  en  extension (qui est une image à un instant t du schéma de la relation). 

La Matrice des Dépendances Fonctionnelles, vue dans le chapitre Étude de l’expression des besoins des utilisateurs,  pourra être mise en œ uvre pour identifier d’une manière exhaustive les DF d’une relation.  Les axiomes d’Amstrong La théorie de la DF repose sur des concepts mathématiques et vérifie des propriétés dites axiomes d’Amstrong.  Nous les rappellerons et nous les imagerons par un exemple, mais nous ne les démontrerons pas, car ce n’est pas  l’objet de ce livre.  Réflexivité Soit une base de données décrite par une relation universelle U (A1, A2… An), avec ∀i ∊ E (entiers), Ai étant un  attribut dont les valeurs appartiennent à un domaine Di.  ∀i ∊ E, Ai → Ai.  Exemple :  Considérons la relation universelle Employé  

- 6-

© ENI Editions - All rigths reserved

La connaissance d’une valeur du code de l’employé (COEMP) ne détermine qu’une et une seule valeur. L’employé n’a qu’un  seul code d’employé dans l’entreprise.  La connaissance d’une date de naissance ne détermine qu’une et une seule date.  Même raisonnement pour les attributs.  Augmentation Soit une base de données décrite par une relation universelle U (A1, A2… An), avec ∀i ∊ E (entiers), Ai étant un  attribut dont les valeurs appartiennent à un domaine Di.  ∀p,q,r ∊ E, si Ap → Aq alors Ap,Ar → Aq,Ar.  Exemple :  Considérons la relation universelle Employé .  Les  règles  de  gestion  nous  permettent  de  préciser  les  dépendances  des  attributs  les  uns  par  rapport  aux  autres.  Ainsi,  dans cet exemple, elles précisent qu’un employé n’a qu’un et un seul code employé. Donc, le code de l’employé détermine  d’une manière unique le nom de l’employé.  Par rapport à la relation en extension qui lui correspond à un instant t : 

  Nous pouvons donner les exemples suivants de cette DF : 

  Rajoutons l’information concernant la date de naissance au code employé et au nom de l’employé.  La connaissance du code et de la date de naissance d’un employé détermine toujours, d’une manière unique, son nom et  sa date de naissance. En effet, pour un code employé ne correspond qu’un seul nom d’employé et un employé n’a qu’une  et une seule date de naissance.  Exemple (par rapport à quelques tuples de la relation en extension) : 

© ENI Editions - All rigths reserved

- 7-

  Transitivité Soit une base de données décrite par une relation universelle U (A1, A2… An), avec ∀i ∊ E (entiers), Ai étant un  attribut dont les valeurs appartiennent à un domaine Di.  ∀p,q,r ∊ E, si Ap → Aq et Aq→ Ar alors Ap→ Ar.  Exemple :  Considérons la relation universelle Employé .  Les  règles  de  gestion  nous  permettent  de  préciser  les  dépendances  des  attributs  les  uns  par  rapport  aux  autres.  Ainsi,  dans cet exemple, elles précisent qu’un employé n’a qu’un et un seul code employé. Donc, le code de l’employé détermine  d’une manière unique la date de naissance de l’employé.  Un nouvel attribut AGEEMP a été rajouté dans cette relation. AGEEMP est l’âge de l’employé, calculé par rapport à sa date  de naissance et à l’année en cours. Chaque année, à la date anniversaire de l’employé, cette information est mise à jour  (annulation et remplacement de l’ancienne valeur par la nouvelle).  Un extrait de la relation en extension pourrait être le suivant en 2008 : 

  Dans cette relation, nous avons les dépendances fonctionnelles suivantes : 

- 8-

●

COEMP → DNEMP 

●

Et DNEMP → AGEEMP 

© ENI Editions - All rigths reserved

Suivant le théorème d’Amstrong, nous aurons COEMP → AGEEMP.  L’âge  de  l’employé  est  calculé  à  partir  de  la  date  de  naissance  de  celui­ci.  Il  est  aussi  en  DF  par  rapport  à  la  date  de  naissance et la date naissance est en DF par rapport au code employé.  Donc, pour un code employé nous obtenons une seule date de naissance.  L’âge  de  l’employé = année en cours  ­ année de naissance de l’employé. Ce calcul donnera pendant toute une année le  même résultat et dès l’année suivante, à la date anniversaire, il sera remplacé. Donc, un code employé ne déterminera, à  tout moment, qu’un seul âge de l’employé.  Donc, COEMP → AGEEMP.  Par rapport aux éléments de la table en extension, nous avons bien en 2008 : 

  La décomposition sans perte Définition La décomposition d’une relation R en n relations R1, R2… Rn est dite sans perte si et seulement si R = R1 ⊳⊲ R2 ⊳⊲ …  Rn.  Autrement  dit,  une  relation  R  est  décomposée  sans  perte  d’informations si la jointure (naturelle) de toutes de ces  relations  issues  (R1,  R2 …  Rn)  reconstitue  une  relation  de  même  schéma  et  régénère  exactement  les  mêmes  tuples sans tuple supplémentaire et /ou faux.    Nous verrons plus loin des exemples de relation de décomposition.

© ENI Editions - All rigths reserved

- 9-

Processus de normalisation  1. Introduction  La  normalisation  d’une base de données relationnelle concerne l’ensemble de toutes ses relations. Donc, toutes les  relations doivent être normalisées.  Pour ce faire, il faudra vérifier individuellement chaque relation. Ceci se fera par un certain nombre d’étapes. Chaque  étape correspondant à une graduation du niveau de normalisation. Cette graduation est appelée degré de la forme  normale.  E. F. Codd a présenté initialement trois formes normales (1ère , 2è m e  et 3 è m e ). Il les a complétées dans les années 80  par trois autres formes : la forme de Boyce_Codd (créée en collaboration avec R. Boyce) puis la 4è m e  et la 5 è m e  forme  normale.  Le processus de normalisation part du niveau le plus bas (1ère forme normale).  À chaque étape, il faut vérifier que la relation suit les conditions nécessaires et suffisantes exigées par le niveau de  normalisation.  Si  et  seulement  si  cela  est  le  cas,  il  est  possible  de  passer  au  niveau  immédiatement  supérieur  de  vérification.  Si  la  relation  que  nous  étudions  ne  répond  pas  aux  conditions  du  degré  de  forme  normale  vérifié,  il  faudra  décomposer  la  relation  en  2  ou  n  relations  plus  simples  qui  devront  répondre  chacune  aux  exigences  de  la  normalisation. Cette décomposition devra s’effectuer sans perte.  Chacune  des  relations  trouvées  devra,  à  son  tour,  être  vérifiée  et  il  faudra  repartir  du  niveau  le  plus  bas  de  la  normalisation (première forme normale).  Il existe deux approches dans la mise en œ uvre de la normalisation d’une base de données.  La  première  approche  consiste,  à  partir  de  la  relation  universelle  (composition  de  tous  les  attributs  strictement  nécessaires à la viabilité du SI) pour la décomposer en relations normalisées. C’est une approche de construction de  base de données relationnelle.  La  deuxième  approche  est  une  approche  de  validation  de  base  de  données  relationnelle.  Dans  ce  contexte,  les  relations ont été créées via les phases du dictionnaire de données, matrice des dépendances fonctionnelles, passage  de cette matrice aux relations…  Nous  allons  d’abord  définir  les  différentes  formes  normales  puis  nous  étudierons,  par  l’exemple,  chacune  de  ces  approches. 

2. Les formes normales indispensables à un schéma relationnel normalisé  Chaque degré de forme normale repose sur le concept de DF.  Chaque  degré  acquis  implique  que  les  exigences  du  ou  des  degré(s)  inférieur(s)  soient  remplies  ainsi  que  celles  exigées à son niveau. 

a. La première forme normale (1FN)  Définition 1 Une  relation  est  en  première  forme  normale  si,  pour  chaque  tuple  de  la  relation,  chaque  attribut  contient  une  valeur atomique.  Autrement  dit,  si  l’on  considère  une  relation  en  extension,  cette  relation  est  dite  en  première  forme  normale  si  et  seulement à l’intersection d’une colonne (attribut) et d’une ligne (tuple), on ne peut trouver qu’un seul élément.  Exemple 1 :  Considérons la relation Livre  On  dira  qu’il y a une valeur atomique pour chaque attribut, si chaque tuple est de la forme (avec possibilité bien sûr de  valeurs différentes) :  « 2 », « livre de poche », « 17 », « € 12.50 »  Si pour un N° de livre, il existe, par exemple, plusieurs Formats (livre de poche, édition de luxe,…) , la relation n’est pas en  1FN. 

© ENI Editions - All rigths reserved

- 1-

  Si  pour tout  tuple  de  la  relation,  il  y  a  une  valeur  unique  pour  les  attributs  N° Livre,  Type,  Format  et  Prix,  alors la  relation est en 1FN. 

  Exemple 2 :  Considérons la relation Employé  Si nous avons au moins un tuple de la forme suivante :  ●

Attribut zone Adresse contenant la valeur «5, av. Camille Pagé, 86000 Poitiers», 

●

Attribut zone Etat­civil contenant la valeur «Oiseau, Bel, ornithologiste». 

Alors, nous sommes en présence de valeurs non­atomiques. Elles sont dans cet exemple : composées.  En effet, dans le seul attribut adresse, nous avons plusieurs informations : la rue mais aussi le code postal et la ville.  De même, dans l’attribut Etat­civil, nous avons aussi plusieurs informations : le nom, le prénom et la profession. 

- 2-

© ENI Editions - All rigths reserved

  Donc, il faut décomposer ces attributs en attributs simples dont l’ensemble reconstituera l’information initiale.  L’adresse  comportant  la  rue,  le  code  postal  et  la  commune,  nous  allons  créer 3  nouveaux  attributs  qui  remplaceront  l’attribut adresse : rue, code postal, ville.  En suivant le même raisonnement, nous allons remplacer l’attribut Etat­Civil par les nouveaux attributs : nom, prénom,  profession. 

  Nous obtenons une relation dont les attributs ne sont pas composés.  Par  contre,  il  faut  maintenant  vérifier  que,  pour  tout  tuple,  il  y  a  bien  une  seule  valeur  pour  chacun  des  attributs pour confirmer que cette relation est en 1FN.  Attention,  la  distinction  entre  atomique  et  non­atomique  n’est  pas  que  syntaxique,  il  faut  aussi  se  situer  dans  le  contexte  de  l’étude.  Ainsi,  les  dates,  bien  que  composées,  sont  souvent  considérées  comme  atomiques car c’est le tout de la composition qui fournit l’information. 

Exemple :  Considérons la date d’embauche de l’ornithologiste Oiseau  : 01 janvier 2007.  C’est  un  attribut  composé  mais  chaque  élément  pris  séparément  (01  ou  janvier  ou  2007)  ne  veut  rien  dire  dans  le  contexte.  Affinons la définition avec nos connaissances en algèbre relationnelle et plus particulièrement, celui du concept de clé  de relation.  Définition 2 (en référence au concept de DF) Une relation R (ID, A1,A2…An) est en 1FN si et seulement si tous les attributs non­clés dépendent fonctionnellement  de la clé de relation. 

© ENI Editions - All rigths reserved

- 3-

Définition 3 (en référence au concept de DF) Une  relation  R’  (ID1,ID2,  A’1,A’2…A’n)  est  en  1FN  si  et  seulement  si  tous  les  attributs  non­clés  dépendent  fonctionnellement de la clé composée de relation (de la clé entière ou d’une partie seulement).  Ces  deux  définitions  sont  formulées  différemment  mais  sont  identiques  à  la  première,  les  propriétés  de  la  DF  assurant la valeur atomique de chaque attribut cible de DF.  Exemple :  Soit le schéma de relation Employé : Employé   Un  employé  n’a  qu’un  et  un  seul  code  employé,  c’est  pour  cette  raison  que  le  code  employé  est  défini  comme  clé  de  relation.  Dans ce schéma, le nom de l’employé et la date de naissance dépendent fonctionnellement de la clé de la relation. En effet,  une valeur d’un code employé ne pourra déterminer qu’un seul nom d’employé et qu’une seule date de naissance, celle de  l’employé.  Il n’y aura qu’une seule valeur atomique dans les colonnes NOEMP et DNEMP pour chaque tuple de la table.  Autrement dit, nous aurons :  COEMP → NOEMP et COEMP → DNEMP  D‘après les définitions, cette relation est en 1FN.  Nous obtiendrons, par exemple, la table en extension suivante : 

  Une relation en 1FN n’est pas complètement normalisée, il faut maintenant vérifier qu’elle est en 2FN. 

b. La deuxième forme normale (2FN)  La  deuxième  forme  normale  va  permettre  d’éliminer  certaines  redondances  qui  subsisteraient  encore  et  d’assurer  qu’aucun attribut n’est déterminé que par une partie seulement de la clé.  Définition 1 Une relation R (ID1,ID2, A1, A2…An) est en 2FN si et seulement si :  ●

Elle est en 1FN, 

●

Tout attribut n’appartenant pas à une clé ne dépend pas que d’une partie de cette clé. 

La deuxième forme normale est à vérifier sur les relations dont la clé est une composition d’attributs. Une  relation en 1FN dont la clé de relation est mono­attribut est, par définition, en 2FN. 

Exemple :  Soit la relation Client, où : 

- 4-

●

NUCLI est l’attribut Numéro du client. 

●

NUACHAT est l’attribut numéro achat du client. Un client peut faire plusieurs achats mais un seul achat par jour.  Un numéro d’achat est unique pour un client ; mais, un même numéro d’achat peut être attribué à deux clients  différents. 

●

DATACHAT est la date de l’achat. 

© ENI Editions - All rigths reserved

●

NOCLI est l’attribut nom du client. Il n’existe pas d’homonymes dans la base client. 

●

MTACHAT est l’attribut Montant TTC de l’achat. 

●

NBPOINT est le nombre de points de fidélité acquis. L’acquisition des points suit la règle suivante :  5 points acquis pour un montant d’achat compris entre 20€ et 40 € :  NBPOINT = 5 ⇔ 20 ≤ MTACHAT < 40  10 points acquis pour un montant d’achat compris entre 40€ et 80 € :  NBPOINT = 10 ⇔ 40 ≤ MTACHAT < 80  15 points acquis pour un montant d’achat compris entre 80€ et 150 € :  NBPOINT = 15 ⇔ 80 ≤ MTACHAT < 150  20 points acquis pour un montant d’achat compris entre 150€ et 300 € :  NBPOINT = 20 ⇔ 150 ≤ MTACHAT < 300  30 points acquis pour un montant d’achat supérieur ou égal à 300 € :  NBPOINT = 30 ⇔ 300 ≤ MTACHAT 

La  clé  de  relation  a  été  définie  comme  composée  des  attributs  Numero  client  et  Numéro  Achat  qui  définissent  d’une  manière unique un achat Y d’un montant X à une date D pour un client C.  Cette relation est­elle en 2FN ?  D’abord, il faut vérifier qu’elle est en 1FN.  Nous sommes en présence d’une relation avec une clé composée, donc nous devons vérifier l’assertion suivante :  Une  relation  R’  (ID1,ID2, A’1,A’2…A’n)  est  en  1FN  si  et  seulement  si  tous  les  attributs  non­ clés dépendent  fonctionnellement de la clé composée de relation (de la clé entière ou d’une partie seulement).  NUCLI, NUACHAT →  NOCLI ?  Les règles de gestion nous confirment que le numéro du client définit, par lui­même et d’une manière unique, le nom du  client. Donc, l’ajout du numéro d’achat du client à son numéro détermine un et un seul nom de client.  NUCLI, NUACHAT →  MTACHAT ?  Pour un numéro de client et un numéro d’achat, il n’existe bien qu’un et un seul montant TTC de l’achat.  NUCLI, NUACHAT →  DATACHAT ?  Pour un numéro de client et un numéro d’achat, il ne peut exister qu’une et une seule date d’achat puisqu’un client ne  peut faire qu’un achat par jour.  NUCLI, NUACHAT →  NBPOINT ?  Pour  un  numéro  de  client  et  un  numéro  d’achat,  il  n’existe  qu’un  et  un  seul  montant  TTC  de  l’achat,  donc  il  n’existe  qu’un et un seul NBPOINT acquis par achat et par client.  Cette relation est en 1FN.  Comme la clé de cette relation est multivaluée, il faut maintenant vérifier que tout attribut n’appartenant pas à la clé,  ne dépend pas que d’une partie de cette clé, pour démontrer que cette relation est en 2FN.  Les questions à se poser sont les suivantes :  ●

NUCLI →  NOCLI ? 

●

NUACHAT →  NOCLI ? 

© ENI Editions - All rigths reserved

- 5-

●

NUCLI →  MTACHAT ? 

●

NUACHAT →  MTACHAT ? 

●

NUCLI →  DATACHAT ? 

●

NUACHAT →  DATACHAT ? 

●

NUCLI →  NBPOINT ? 

●

NUACHAT →  NBPOINT ? 

Il suffit qu’il y ait une seule réponse OUI à une de ces questions pour démontrer que cette relation n’est pas en 2FN.  La connaissance du N° client permet de déterminer un et un seul nom de client.  Donc, NUCLI →  NOCLI.  Il existe un attribut qui dépend que d’une partie de la clé.  Cela suffit pour pouvoir affirmer que cette relation n’est pas en 2FN.   Il faut la décomposer.  À titre de pratique, examinons complètement, malgré tout, cette relation :    ●

NUACHAT 

NUCLI : car deux clients peuvent avoir le même numéro d’achat.  

●

NUACHAT 

NOCLI : pour la même raison.

●

NUCLI  MTACHAT : la connaissance d’un numéro de client ne détermine pas une seule valeur  d’un montant  d’achat. Un client peut faire des achats de montants différents. 

●

NUACHAT  MTACHAT :  à  un  numéro  d’achat  peut  correspondre  plusieurs  achats  effectués  par  des  clients  différents et donc, plusieurs montant TTC différents. 

●

NUCLI  DATACHAT :  la  connaissance  d’un  numéro  de  client  ne  détermine  pas  une  seule  valeur  d’une  date  d’achat. Un client peut faire des achats à des dates différentes. 

●

NUACHAT  DATACHAT :  à  un  numéro  d’achat  peut  correspondre  plusieurs  achats  effectués  par  des  clients  différents à des dates différentes. 

●

NUCLI  NBPOINT : la connaissance d’un numéro de client ne détermine pas une seule valeur  du nombre de  points acquis. Un client peut faire des achats de montants différents et acquérir des nombres de points différents. 

●

NUACHAT  NBPOINT :  à  un  numéro  d’achat  peut  correspondre  plusieurs  achats  effectués  par  des  clients  différents, pour des montants différents, d’où un nombre de points de fidélité différents. 

En résumé, nous avons, pour cette relation, les DF suivantes :  ●

NUCLI, NUACHAT → NOCLI 

●

NUCLI, NUACHAT → MTACHAT 

●

NUCLI, NUACHAT → DATACHAT 

●

NUCLI, NUACHAT → NBPOINT   

●

NUACHAT 

DATACHAT  

●

NUACHAT 

NOCLI  

- 6-

© ENI Editions - All rigths reserved

  ●

NUACHAT 

MTACHAT  

●

NUACHAT 

NBPOINT  

●

NUCLI 

DATACHAT  

●

NUCLI 

MTACHAT  

●

NUCLI 

NBPOINT

●

NUCLI →  NOCLI. 

Il existe un attribut qui ne dépend que d’une partie de la clé.  La relation client actuelle n’est pas en 2FN, il faut la décomposer.  Il suffit qu’il n’y ait qu’un seul attribut non­clé qui dépende d’une partie de la clé pour affirmer que la relation n’est  pas en 2FN. Une relation en 1FN qui n’est pas en 2FN doit être décomposée.  La décomposition d’une table, qui n’est pas au degré de normalisation demandé, va se baser uniquement sur les DF  existantes dans la relation.  Dans cette étape, on ne tient plus compte des DF liées à la clé de relation composée puisque notre objectif  est justement de la décomposer. 

Nous allons regrouper toutes les DF cible d’une DF source dans une relation.  En suivant cette règle et en partant d’une relation qui n’est pas en 2FN, nous allons obtenir au moins une relation de  plus.  Exemple :  Les DF de la relation client précédente sont les suivantes :  ●

●

NUCLI,  NUACHAT  →   NOCLI  mais  la  DF  NUCLI  →   NOCLI  existe  aussi.  Il  ne  faut  conserver  que  la  DF  source  comportant le nombre minimal d’attribut.  D’où, NUCLI →  NOCLI 

Nous avons aussi :  ●

NUCLI, NUACHAT →  MTACHAT 

●

NUCLI, NUACHAT →  DATACHAT 

●

NUCLI, NUACHAT →  NBPOINT 

Nous regroupons les données cibles de DF avec leur(s) donnée(s) source et nous obtenons deux relations :  ●

Client (NUCLI, NOCLI) 

●

Achat (NUCLI, NUACHAT, DATACHAT, MTACHAT, NBPOINT) 

La clé de chacune des relations est la (ou les) donnée(s) source de la DF correspondant à la relation.  En définitive, nous avons les deux relations suivantes :  ●

Client (NUCLI, NOCLI) 

●

Achat (NUCLI, NUACHAT, DATACHAT, MTACHAT, NBPOINT) 

© ENI Editions - All rigths reserved

- 7-

La  décomposition  de  la  relation,  qui  n’était  pas  en  2FN,  est  effectuée.  Il  faut  maintenant  vérifier  que  les relations  obtenues sont normalisées en repartant du degré 1FN.  Exemple :  Client (NUCLI, NOCLI) est­elle en 1FN ?  ●

Oui, car NOCLI dépend fonctionnellement de la clé de la relation. 

●

Elle est de fait en 2FN car la clé de la relation n’est pas composée. 

●

Achat (NUCLI, NUACHAT, DATACHAT, MTACHAT, NBPOINT) est­elle en 1FN ? 

●

Oui, car DATACHAT, MTACHAT et NBPOINT dépendent fonctionnellement de la clé de la relation. 

●

  DATACHAT  

●

NUACHAT 

●

NUACHAT 

MTACHAT  

●

NUACHAT 

NBPOINT  

●

NUCLI 

DATACHAT  

●

NUCLI 

MTACHAT  

●

NUCLI 

NBPOINT.

Nous avons construit deux relations en 2FN en partant d’une relation non normalisée.  Une décomposition d’une relation 1FN en 2FN en se basant sur les DF existantes dans la relation s’effectue  sans perte. 

En effet, tous les attributs sont conservés et sont regroupés par DF. Si l’on réalise la jointure des relations issues de  la  décomposition,  nous  retrouvons  la  relation  initiale  avec  tous  ses  tuples,  sans  tuple(s)  supplémentaire(s)  et/ou  faux.  Exemple :  Considérons la relation Client en extension : 

  En se basant sur les DF, nous avons décomposé cette relation en deux autres relations :  ●

- 8-

Clientbis (NUCLI, NOCLI) dont l’extension est la suivante : 

© ENI Editions - All rigths reserved

 

●

Achat (NUCLI, NUACHAT, DATACHAT, MTACHAT, NBPOINT) dont l’extension est la suivante : 

  ACHAT ⊳⊲  CLIENTBIS (jointure naturelle entre CLIENTBIS et ACHAT sur l’attribut  commun  NUCLI)  est  l’équi­jointure  dont la condition de rapprochement concerne les attributs NUCLI de ACHAT et NUCLI de CLIENTBIS, sur laquelle une  occurrence de l’attribut NUCLI est éliminée.  Nous retrouvons bien la relation CLIENT : 

  ACHAT ⊳⊲ CLIENTBIS = CLIENT, donc nous avons une décomposition sans perte.  Une relation en 2FN n’est pas complètement normalisée, il faut maintenant vérifier qu’elle est en 3FN. 

c. La troisième forme normale (3FN)  La troisième forme normale va permettre d’éliminer les redondances dues aux dépendances transitives par rapport à  la clé primaire.  Définition 1 Une relation R (ID, A1,A2…An) est en 3FN si et seulement si :  ●

Elle est en 2FN, 

●

Et tout attribut n’appartenant pas à la clé ne dépend pas d’un attribut non­clé. 

Définition 2 Une relation R’ (ID1,ID2, A’1,A’2…A’n) est en 3FN si et seulement si :  ●

Elle est en 2FN, 

●

Et tout attribut n’appartenant pas à la clé ne dépend pas d’un attribut non clé. 

© ENI Editions - All rigths reserved

- 9-

La troisième forme normale est à vérifier sur les relations pour lesquelles il existe au moins deux attributs  n’appartenant à la clé. Une relation en 2FN comprenant un seul attribut non­clé est, de fait, en 3FN. 

Exemple :  Reprenons notre exemple précédent avec les deux relations en 2FN que nous avons trouvées :  ●

Clientbis (NUCLI, NOCLI) 

●

Achat (NUCLI, NUACHAT, DATACHAT, MTACHAT,NBPOINT) 

La relation Client n’ayant qu’un attribut non clé est de fait en 3FN.  Analysons la relation Achat et les DF entre les attributs n’appartenant pas à la clé : DATACHAT, MTACHAT, NBPOINT.  Les questions à se poser sont les suivantes :  ●

DATACHAT →  MTACHAT ? 

●

DATACHAT →  NBPOINT ? 

●

NBPOINT →  DATACHAT ? 

●

NBPOINT →  MTACHAT ? 

●

MTACHAT →  DATACHAT ? 

●

MTACHAT →  NBPOINT ? 

Une  valeur  de  date  d’achat  détermine­t­elle  une  valeur  unique  d’un  montant  d’achat  ?  Non  (heureusement  pour  l’entreprise) car plusieurs achats de montants différents peuvent être effectués dans une même journée.    Donc DATACHAT  MTACHAT.  Une  valeur  de  date  d’achat  détermine­t­elle  une  valeur  unique  d’un  nombre  de  points  acquis  ?  Non,  car  plusieurs  achats ayant des nombres de points acquis différents peuvent être effectués dans une même journée.    Donc DATACHAT  NBPOINT.  Une valeur du nombre de points acquis détermine­t­elle une valeur unique d’une date d’achat ? Non, car plusieurs  achats effectués à des dates d’achats différentes peuvent induire le même nombre de points.    Donc NBPOINT  DATACHAT.  Une valeur du nombre de points acquis détermine­t­elle une valeur unique d’un montant d’achat ? Non, car la valeur  du nombre de points acquis dépend du montant d’achat  qui  n’est pas fixe mais inclus dans un certain intervalle de  valeurs.    Donc NBPOINT  MTACHAT.  Une valeur d’un montant d’achat détermine­t­elle une valeur unique d’une date d’achat ? Non, car plusieurs achats  de mêmes montants peuvent être effectués dans une des journées différentes.    Donc MTACHAT  DATACHAT.  Une valeur d’un montant d’achat détermine­t­elle une valeur unique d’un nombre de points acquis ? Oui, car, d’après  les règles de gestion, c’est bien le montant de l’achat qui détermine la valeur du nombre de points acquis.  Donc MTACHAT →  NBPOINT.   Cette DF avait été masquée par les autres DF que nous avions définies précédemment :  ●

- 10 -

NUACHAT →  MTACHAT  

© ENI Editions - All rigths reserved

●

NUACHAT →  NBPOINT 

Mais, en réalité, la DF NUACHAT  →  NBPOINT était issue de la propriété de transitivité des DF. Elle doit être éliminée car  recalculable.  C’est pour cela que la troisième forme normale permet d’éliminer les redondances dues aux dépendances transitives  par rapport à la clé primaire.  En effet, comme il existe un attribut n’appartenant pas à la clé qui dépend d’un attribut non­ clé, nous pouvons  affirmer que cette relation n’est pas en 3FN.  Il faut la décomposer.  La décomposition d’une table, qui n’est pas au degré de normalisation demandé, va se baser uniquement sur les DF  existantes dans la relation.  Nous allons regrouper toutes les DF cible d’une DF source dans une relation.  En suivant cette règle et en partant d’une relation qui n’est pas en 3FN, nous allons obtenir au moins une relation de  plus.  Exemple :  La DF de la relation Achat (NUCLI, NUACHAT,  DATACHAT,  MTACHAT,NBPOINT)  prouvant  qu’elle n’est pas en 3FN , est la  suivante :  MTACHAT → NBPOINT  Nous regroupons les données cible de DF avec leur(s) donnée(s) source et nous obtenons deux relations :  ●

Achat (NUCLI, NUACHAT, DATACHAT, MTACHAT) 

●

Fidélité (MTACHAT, NBPOINT) 

La clé de chacune des relations est la (ou les) donnée(s) source de la DF correspondant à la relation.  En définitive, nous avons les deux relations suivantes :  ●

Achat (NUCLI,NUACHAT, DATACHAT, MTACHAT) 

●

Fidélité (MTACHAT, NBPOINT). 

La  décomposition  de  la  relation,  qui  n’était  pas  en  3FN,  réalisée,  il  faut  vérifier  que  les  relations  obtenues  sont  normalisées en repartant du degré 1FN.  Exemple :  Achat (NUCLI,NUACHAT, DATACHAT, MTACHAT) est­elle en 1FN ?  Oui, car DATACHAT et MTACHAT dépendent fonctionnellement de la clé de la relation.  Nous avons démontré précédemment que :    ●

NUCLI 

DATACHAT  

●

NUCLI 

MTACHAT  

●

NUACHAT 

DATACHAT  

●

NUACHAT 

MTACHAT

Donc, elle est aussi en 2FN.  Les questions suivantes à se poser pour vérifier la 3FN, sont les suivantes :  ●

DATACHAT →  MTACHAT ? 

●

MTACHAT →  DATACHAT ? 

© ENI Editions - All rigths reserved

- 11 -

Une  valeur  de  date  d’achat  détermine­t­elle  une  valeur  unique  d’un  montant  d’achat  ?  Non,  car  plusieurs  achats  de  montants différents peuvent être effectués dans une même journée.    Donc DATACHAT  MTACHAT. Une  valeur  d’un  montant  d’achat  détermine­t­elle  une  valeur  unique  d’une  date  d’achat.  Non,  car  plusieurs  achats  de  mêmes montants peuvent être effectués dans des journées différentes.    Donc MTACHAT  DATACHAT. Cette relation est en 3FN.  Fidélité (MTACHAT, NBPOINT) est­elle en 1FN ?  ●

Oui, car NBPOINT dépend fonctionnellement de la clé de la relation. 

●

Elle est de fait en 2FN car la clé de la relation n’est pas composée. 

●

Elle est de fait en 3FN car il n’existe qu’un seul attribut non clé. 

Nous avons construit deux relations en 3FN en partant d’une relation non normalisée.  En  synthèse,  en  partant  de  la  relation  universelle  de  notre  exemple,  Client, qui est non­normalisée, nous avons construit, en la décomposant, trois relations en 3FN :  ●

Clientbis (NUCLI, NOCLI) 

●

Achat (NUCLI,NUACHAT, DATACHAT, MTACHAT) 

●

Fidélité (MTACHAT, NBPOINT). 

Si  à  chaque  étape  de  vérification  d’un  des  niveaux  des  trois  premières  formes  normales,  nous  décomposons,  si  besoin,  la  relation  originelle  en  se  basant  sur  les  DF  de  chacun  des  attributs,  nous  ferons  toujours  une  décomposition sans perte.  Exemple :  La décomposition en trois relations de la relation universelle Client de notre exemple a été systématiquement effectuée en  tenant compte des DF existantes (liées, ne l’oublions pas, aux règles de gestion du système d’information).  Nous avions vérifié qu’au niveau de la deuxième forme normale, la décomposition s’était réalisée sans perte.  En est­il arrivé de même au niveau de la 3FN ?  La question à se poser est la suivante  :  Client = Clientbis ⊳⊲ Achat ⊳⊲ Fidélité ?  Reprenons la relation en extension Client : 

  En se basant sur les DF, nous avons décomposé cette relation en trois autres relations :  ●

- 12 -

Clientbis (NUCLI, NOCLI) dont l’extension est la suivante : 

© ENI Editions - All rigths reserved

 

●

Achat (NUCLI, NUACHAT, DATACHAT, MTACHAT) dont l’extension est la suivante : 

 

●

Fidélité( MTACHAT, NBPOINT) dont l’extension est la suivante : 

  Les jointures se font par deux relations.  Commençons par Achat ⊳⊲ Fidélité. La jointure se fera sur l’attribut commun MTACHAT et nous obtenons : 

  Puis  nous  effectuons  la  jointure  Clientbis  ⊳⊲  (Achat  ⊳⊲  Fidélité)  qui  utilisera,  comme  prédicat  de  jointure,  l’égalité  sur  l’attribut NUCLI. Nous obtenons : 

© ENI Editions - All rigths reserved

- 13 -

  Donc, Clientbis ⊳⊲ (Achat ⊳⊲ Fidélité) = Client et nous retrouvons tous les attributs minimum et nécessaires à la gestion  de notre SI. 

d. Clé étrangère  La décomposition en relations 3FN, issues d’une relation en 2FN, mais dont certains attributs n’appartenant pas à la  clé dépendent d’un attribut non­clé, fait surgir un concept que nous avons déjà vu : celui de la clé étrangère.  Nous pouvons lui donner une définition plus formelle.  Définition Un  attribut  (ou  une  composition  d’attribut)  qui  n’est  pas  une  clé  d’une  relation  est  une  clé  étrangère  de  cette  relation si le même attribut (ou la même composition d’attributs) apparaît comme clé d’une autre relation.  La clé de la relation est aussi appelée clé primaire.  La clé étrangère d’une relation R n’a pas les caractéristiques pour être la clé (primaire) de cette relation. Elle n’est  qu’un attribut parmi les autres de R mais avec deux spécificités :  ●

Elle est la clé (primaire) d’une autre relation R’, 

●

Les  valeurs  prises  par  la  clé  étrangère  de  R  doivent  se  retrouver  en  tant  que  valeurs  de  sa  clé  primaire  correspondante dans R’. L’unique valeur qui lui est permise, dans certains cas, est la valeur Nulle (Null). 

En  synthèse,  nous  avons  déterminé  trois  types  de  clés :  les  clés  candidates  d’une  relation,  la  clé  primaire  d’une relation qui a été choisie parmi la ou les clé(s) candidate(s) et la clé étrangère qui constitue un lien  entre deux relations puisqu’elle est clé primaire dans l’une et attribut dans l’autre. 

Exemple :  En partant de la relation universelle de notre exemple, Client,  nous avons construit, en la décomposant, trois relations en 3FN :  ●

Clientbis (NUCLI, NOCLI) 

●

Achat (NUCLI,NUACHAT, DATACHAT, MTACHAT) 

●

Fidélité (MTACHAT, NBPOINT). 

Après analyse des DF, la clé candidate de Clientbis est NUCLI. Donc, le choix a été limité et la clé primaire de Clientbis est  NUCLI.  De même, la relation Fidélité n’a qu’une seule clé candidate qui devient la clé primaire : MTACHAT.  De même, la clé candidate d’Achat est le regroupement des deux attributs NUCLI­NUACHAT. La clé primaire est donc, ce  même regroupement. De plus, cette relation contient l’attribut MTACHAT qui permettra de déterminer le nombre de points  de cet achat grâce à la relation Fidélité. Cet attribut est une clé étrangère dans la relation Achat puisqu’elle est clé primaire  dans la relation Fidélité.  Les valeurs prises par l’attribut MTACHAT de la relation Achat dépendent des valeurs existantes de l’attribut  MTACHAT de Fidélité, et non le contraire. 

- 14 -

© ENI Editions - All rigths reserved

Exemple :  Si pour le N° d’achat 309 du 13/07/2007, le montant TTC est de 456  €, alors obligatoirement ce montant TTC de 456€ existe et est lié à une valeur de nombre de points acquis dans la table Fidélité.  Par contre, il peut exister un montant de 372€ avec une valeur 30 pour le nombre de points acquis dans la relation Fidélité,  alors qu’il n’existe aucun tuple dans la relation Achat dont la valeur du montant TTC soit égal à 372€.  L’attribut NUCLI ne peut pas être considéré comme une clé étrangère de la relation Achat car elle fait partie  de la clé primaire. 

e. Forme normale de Boyce­Codd  Dans la pratique, un schéma relationnel dont toutes les tables sont en 3FN est dit normalisé.  Mais dans certains cas, R. Boyce et E. F. Codd ont repéré des faiblesses dans la 3FN.  En  effet,  la  3FN  élimine  les  redondances  liées  à  la  transitivité  des  DF  par  rapport  à  la  clé  primaire ;  mais  il  peut  subsister des dépendances transitives par rapport à un élément de la clé de la relation si celle­ci est multiattribut. Ils  ont donc défini une 3FN, plus restrictive, appelée la Forme Normale de Boyce­Codd (FNBC).  Définition Une relation est en FNBC si et seulement si :  ●

Elle est en 3FN, 

●

Aucun attribut faisant partie de la clé ne dépend d’un attribut ne faisant pas partie de la clé primaire. 

Pour passer de la 3FN à la FNBC, il faut diviser chaque relation ne satisfaisant pas aux critères de la FNBC en deux  relations.  Une nouvelle relation sera créée, celle qui répond à la DF nouvelle. Ainsi, cette nouvelle relation aura en tant que :  ●

Clé : l’attribut dont provient la dépendance, 

●

Attribut(s) : la partie de la clé qui en dépend. 

Dans la relation de base, il faudra remplacer la partie de la clé concernée par l’attribut dont provient la dépendance  (qui est devenu la clé de l’autre relation).  La décomposition se fera ainsi, sans pertes, puisque par jointure, nous retrouverons l’intégralité des tuples.  Par contre, la décomposition en FNBC, bien que normalisée, fait disparaître certaines DF.  Exemple :  Considérons le schéma relationnel constitué des relations suivantes :  ●

Produit, où : NUPROD est l’attribut Numéro de produit, clé de relation, LIBPROD est l’attribut  libellé du produit. Ces deux attributs sont liés par la DF suivante : NUPROD →  LIBPROD. 

●

Fournisseur,  où :  NUFOU  est  l’attribut  Numéro  de  fournisseur,  clé  de  relation,  DENFOU  est  l’attribut dénomination du fournisseur. Ces deux attributs sont liés par la DF suivante : NUFOU →  DENFOU. 

●

Type produit,  où  :  TYPROD  est  l’attribut Type de produits, clé de relation, LIBTYP est l’attribut  libellé du type de produits. Ces deux attributs sont liés par la DF suivante : TYPROD →  LIBTYP. 

De plus, ce Système d’Information doit suivre les règles de gestion suivantes :  ●

Un type de produits englobe plusieurs produits. Un produit peut être de types différents. 

●

Un fournisseur propose plusieurs types de produits mais un produit par type. De plus, un type de produits n’est 

© ENI Editions - All rigths reserved

- 15 -

fourni que par un et un seul fournisseur.  En répondant à ces règles de gestion, nous avons construit la relation Fourniture   Ce schéma est­il en FNBC ?  Les trois premières relations sont en 1FN du fait de leur DF.  Elles sont aussi de 2FN, de 3FN et de FNBC de fait puisqu’elles ont une clé mono­attribut et n’ont qu’un seul attribut non­ clé.  Donc, il faut maintenant analyser la relation Fourniture.  Cette relation est­elle en 1FN ?  La connaissance d’une valeur d’un numéro de produit et d’un numéro de fournisseur détermine une et une seule valeur de  type de produits puisqu’un fournisseur ne propose qu’un produit par type.  NUPROD, NUFOU →  TYPROD.  Cette relation est en 1FN.  Est­elle en 2FN ?  Les questions suivantes sont à se poser :  ●

NUPROD →  TYPROD ? 

●

NUFOU →  TYPROD ? 

Un produit peut être de types différents donc, une valeur de numéro de produit ne détermine pas une et une seule valeur  de type de produits.    Donc NUPROD  TYPROD. De même, un fournisseur propose plusieurs types de produits, donc une valeur de numéro de fournisseur ne détermine  pas une et une seule valeur de types de produit.    Donc NUFOU  TYPROD. Cette relation est en 2FN.  Elle est en 3FN de fait puisqu’elle ne possède qu’un seul attribut non­clé.  Mais est­elle en FNBC ?  Du fait des règles de gestion, nous avons la DF supplémentaire suivante :TYPROD →  NUFOU  Une valeur de TYPROD détermine une et une seule valeur de numéro de fournisseur.  Nous  constatons  qu’un  attribut  faisant  partie  de  la  clé  (NUFOU)  dépend  d’un  attribut  ne  faisant  pas  partie  de  la  clé  (TYPROD). Donc, la relation Fourniture n’est pas en FNBC.  Il faut la décomposer.  Une nouvelle relation sera créée, celle qui répond à la DF nouvelle. Ainsi, cette nouvelle relation Type par Fournisseur aura  en tant que :  ●

Clé : l’attribut dont provient la dépendance TYPROD, 

●

Attribut(s) : la partie de la clé qui en dépend : NUFOU. 

Nous obtenons Type par Fournisseur< TYPROD,NUFOU>  Dans la relation de base, il faudra remplacer la partie de la clé concernée par l’attribut dont provient la dépendance (qui est  devenu la clé de l’autre relation).  Nous obtenons Fourniturebis (NUPROD, TYPROD).  Illustrons cet exemple avec la relation Fourniture vue en extension. 

- 16 -

© ENI Editions - All rigths reserved

  La décomposition de cette relation en FNBC crée les deux relations suivantes :  Type par fournisseur en extension : 

  Fourniturebis en extension : 

  Attention !  Nous  constatons  que  la  décomposition  en  FNBC  élimine  les  redondances  qui  subsisteraient  encore dans la relation mais fait également disparaître certaines DF existantes. 

Exemple :  Dans notre exemple précédent, la DF NUPROD, NUFOU →  TYPROD a disparu.  Or, elle était représentative d’une règle de gestion du futur SI.  Dans la pratique, il faudra donc faire le choix le plus judicieux et le plus pertinent pour le SI (déjà normalisé en 3FN) :  ●

conserver les DF (cœ ur de notre SI) grévées de redondances de données qui entraîneront une manipulation  des données un peu plus complexe pour conserver leur cohérence, 

●

ou  construire  une  base  de  données  parfaite,  sans  risque  d’anomalies  produites  par  la  manipulation  des  données mais ne reflétant pas toutes les DF du Système. 

f. Synthèse 

© ENI Editions - All rigths reserved

- 17 -

 

3. Les quatrième et cinquième formes normales  Les  formes  normales  étudiées  précédemment  qui,  répétons­le,  suffisent  généralement  pour  répondre  aux  besoins  d’un Système d’Information, nous ont aidés à éliminer toutes les anomalies liées aux dépendances fonctionnelles.  Mais  E.  F.  Codd  a  poussé  plus  loin  ses  réflexions  et  a  identifié  un  autre  type  de  dépendances  qui  peuvent  aussi  provoquer des redondances de données : les dépendances multivaluées.  Nous  allons  définir  ces  nouvelles  dépendances  puis  aborder  les  quatrième  et  cinquièmes  formes  normales  qui  reposent sur celles­ci. 

a. Les dépendances multivaluées (DM)  Définition 1 Soit un schéma de relation décrit par une relation universelle U (A1, A2… An), avec ∀i ∈ E (entiers), Ai étant un  attribut dont les valeurs appartiennent à un domaine Di.  Soit X et Y des sous­ensembles de A1, A2,… An.  On dira que :  X multi­détermine Y (ou il existe une dépendance multivaluée (DM) de Y sur X) si :  ●

étant donné des valeurs de X, il y a un ensemble de valeurs de Y associées 

●

et cet ensemble est indépendant des autres attributs Z= U­X­Y de la relation U. 

On écrira :  X → → Y  Définition 2 (simplifiée) Soit une relation R(X,Y,Z), 

- 18 -

© ENI Editions - All rigths reserved

X→ → Y (X multi­détermine Y) < = = > ∀ la valeur prise par X,  ∃ un ensemble de valeurs de Y : Ey  et  ∃ un ensemble de valeurs de Z : Ez  et  Ey ∩ Ez = ∅ (ensemble vide)  Il existe une troisième définition encore plus simple mais qui n’est viable que si et seulement si vous avez une vue  exhaustive de la relation en extension.  Définition 3 (encore plus simple !) Soit une relation R(X,Y,Z),  X→ → Y (X multi­détermine Y) < = = > ∀ la valeur prise par X,  ∃ 2 tuples (x, y, z) et (x, y’, z’) dans R alors obligatoirement ∃ 2 tuples (x, y’, z) et (x, y, z’) dans R  La manière la plus simple de comprendre ce nouveau concept est de l’illustrer avec un exemple.  Exemple :  Soit un SI qui gère des produits appartenant à un certain type. De plus, le SI gère les employés de l’entreprise.  Chaque type de produits englobe de 1 à n produits.  Les employés manipulent au moins un ou tous les types de produits existant dans l’entreprise.  L’informaticien a modélisé ce SI avec la relation Produit_employé suivante : Pro_emp, où :  ●

TYPROD est l’attribut type de produit. 

●

NUPROD est l’attribut numéro de produit. 

●

CODEMP est l’attribut code employé. 

La clé de relation choisie est TYPROD­NUPROD­CODEMP.  Un extrait de la table en extension est le suivant : 

  Dans cet exemple, les produits appartiennent à un type de produits.  Les employés manipulent tel ou tel type de produits.  De plus, il n’y a aucun lien de défini, dans les règles de gestion, entre employés et produits. 

© ENI Editions - All rigths reserved

- 19 -

Attention ! C’est ce postulat de complète indépendance entre deux attributs, qui sont malgré tout liés par  une DF à un même 3ème attribut, qui permet de déterminer une DM. 

La  connaissance  d’une  valeur  d’un  type  de  produits  détermine  un  ensemble  de  valeurs  de  numéro  de  produit  et  un  ensemble de valeurs de code employé.  Mais, l’ensemble des valeurs de produit et l’ensemble des valeurs d’employé sont indépendants, malgré la connaissance de  la valeur du type de produits. Leur intersection est égale à ∅ (ensemble vide).  Nous avons donc deux dépendances multivaluées.  TYPROD →  →  NUPROD  Et  TYPROD →  →  CODEMP.  La relation Prod_emp de l’exemple précédent est bien FNBC, mais elle est mal structurée.  Pourquoi ?  Parce  qu’il  existe  deux  sortes  de  DM,  et  suivant  la  DM  mise  en  œ uvre  dans  la  relation,  celle­ci  pourra  souffrir  des  mêmes anomalies de mise à jour qu’une relation non normalisée.  Dépendance Multivaluée Triviale (DMT) La DM X → → Y de la relation R est une DM Triviale si et seulement  ●

Si X est un sous­ensemble de Y 

●

Si X ∪ Y = R. 

OU 

Dépendance Multivaluée Non­Triviale (DMNT) La DM X → → Y de la relation R est une DM Non­Triviale si et seulement  ●

Si X n’est pas un sous­ensemble de Y 

●

Si X ∪ Y ≠ R. 

ET 

Exemple :  Quelle est la DM mise en œuvre dans la relation Prod­emp ?  Analysons chacune des DM.  TYPROD ∪ NUPROD ≠ Prod_emp.  Et de plus, TYPROD n’est pas un sous­ensemble de NUPROD.  Donc TYPROD →  →  NUPROD est une DM Non­ Triviale.  TYPROD ∪ CODEMP ≠ Prod_emp.  Et de plus, TYPROD n’est pas un sous­ensemble de CODEMP.  Donc TYPROD →  →  CODEMP est une DM Non­ Triviale.  Malgré  le  fait  qu’une  relation  soit  en  FNBC,  si  elle  possède  au  moins  une  DM  Non­  Triviale,  sa  structure  sera  responsable d’anomalies de mise à jour.  Exemple :  En  effet,  dans  notre  relation  Prod_emp,  si  nous  embauchons  un  employé  qui  devra  manipuler  un  type  de  produits,  il  faudra créer autant de tuples que de produits appartenant à ce type de produits.  Par exemple, soit le nouvel employé de code 031 qui vient d’être embauché et qui doit manipuler les produits de type A.  Dans  notre  relation,  nous  avons  trois  tuples  produit  concernant  le  type  de  produit  A,  il  faudra  donc,  créer  trois  tuples  supplémentaires pour intégrer l’employé de code 031 dans la gestion de notre SI. 

- 20 -

© ENI Editions - All rigths reserved

Illustrons cette création d’employé 031 : 

  Pour  prévenir  ces  risques,  il  a  fallu  qu’E.  F.  Codd  définisse  une  forme  normale  supplémentaire,  appelée  quatrième  forme normale. 

b. La quatrième forme normale (4FN)  Définition Une relation est en 4FN si et seulement si :  ●

Elle est en FNBC, 

●

Elle ne contient aucune DM Non Triviale. 

Pour  passer  de  la  FNBC  à  la  4FN,  il  faudra  supprimer  toutes  les  DM  Non­Triviales.  Cela  se  réalisera  en  créant  une  nouvelle relation comportant le(s) attribut(s) concerné(s) par la DM et le(s) déterminant(s) de la DM.  Le(s) déterminant(s) restent dans la relation originelle, les attributs y sont retirés.  La décomposition se réalise sans perte.  Exemple :  La relation précédente Prod_Emp n’est pas en 4FN puisqu’elle a deux DM Non­Triviales.  Elle a deux DMNT, cela implique qu’il va falloir construire deux nouvelles relations.  Commençons à étudier la DM TYPROD →  →  NUPROD.  Nous créons la nouvelle relation Typ_prod qui va comporter les attributs :  ●

TYPROD (déterminant de la DM) 

●

NUPROD (déterminé). 

D’où la relation Typ_prod (TYPROD, NUPROD).  Cette relation est en 4FN de fait car elle ne comporte que deux attributs. 

© ENI Editions - All rigths reserved

- 21 -

Étudions la DM TYPROD →  →  CODEMP.  Nous créons la nouvelle relation Typ_emp qui va comporter les attributs :  ●

TYPROD (déterminant de la DM) 

●

CODEMP (déterminé). 

D’où la relation Typ_emp (TYPROD, CODEMP).  Cette relation est en 4FN de fait car elle ne comporte que deux attributs.  Les  attributs  liés  à  une  DMNT  ont  été  retirés  de  la  relation  originelle.  Dans  cette  relation,  il  ne  resterait  plus  que  le  déterminant TYPROD qui existe déjà dans les deux autres relations, donc elle n’est pas conservée.  Donc,  de  la  relation  Prod_Emp  qui  n’était  pas  en  4FN,  nous  obtenons  deux  nouvelles  relations en 4FN :  ●

Typ_prod (TYPROD, NUPROD). 

●

Typ_emp (TYPROD, CODEMP). 

Visualisons ces nouvelles relations à partir de la table originelle en extension.  Relation Typ_prod en extension : 

  Relation Typ_emp en extension : 

  Rappelez­vous de l’exemple précédent : pour gérer le nouvel employé de code 031 qui doit manipuler les produits de type A,  nous avions créé 3 tuples. Au contraire, maintenant que nos relations sont en 4FN, il suffit de créer un seul tuple (A, 031)  dans la relation TYP_EMP.  Les décompositions se sont réalisées sans pertes d’informations (de données et d’attributs).  En effet, Typ_Prod ⊳⊲ Typ_emp avec égalité sur l’attribut commun TYPROD donne en extension : 

- 22 -

© ENI Editions - All rigths reserved

  Prod_Emp = Typ_Prod ⊳⊲ Typ_emp  Nous sommes presque arrivés à l’excellence, mais les relations en 4FN peuvent encore comporter des insuffisances.  En effet, dans tous les cas que nous avons vu jusqu’à maintenant, nous avons décomposé les relations originelles  non conformes au degré de forme normale demandé, en deux relations.  Cela s’est toujours effectué sans pertes, nous pouvions toujours recomposer la relation première à partir des deux  relations nouvelles.  Mais cela n’est pas toujours le cas. En effet, si l’on décompose une relation en plus de 2 relations (donc, à partir de  3), il est possible de perdre des informations.  Exemple :  Considérons le SI suivant :  Nous gérons des clients qui achètent des produits vendus par des commerciaux. Si le client a besoin d’un produit et qu’il  est démarché par un commercial qui propose ce produit, il lui achète ce produit.  Chaque commercial ne vend pas tous les produits proposés par l’entreprise.  L’informaticien qui a analysé ces règles de gestion, a construit la relation Achat suivante :  Achat  L’extension de cette relation est la suivante : 

  Nous constatons que le client 103 qui avait besoin du produit 4 et qui a été démarché par les commerciaux 009 et 023, a  acheté ce produit à chaque commercial.  Idem pour les clients 317.  Cette relation est­elle en 4FN ?  © ENI Editions - All rigths reserved

- 23 -

Possède­t­elle des DM ?  Pour rappel : Soit une relation R(X,Y,Z),  X→ → Y (X multi­détermine Y) < = = > ∀ la valeur prise par X,  ∃ un ensemble de valeurs de Y : Eyet  ∃ un ensemble de valeurs de Z : Ez  et  Ey ∩ Ez = ∅ (ensemble vide)  Est­ce que NUCLI →  →  NUPROD ?  Non, car quelle que soit la valeur prise par NUCLI, l’ensemble des valeurs prises par NUPROD correspondant dépend  aussi des valeurs prises de NUCOM, puisque c’est le commercial qui vend le produit et tous les commerciaux ne  vendent pas tous les mêmes produits.  Donc, quelle que soit la valeur prise par NUCLI, nous ne pourrons pas trouver des ensembles de valeurs pour NUPROD et  NUCOM indépendants. Donc, NUCLI  NUPROD.  Est­ce que NUCLI →  →  NUCOM ?  Non, car quelle que soit la valeur prise par NUCLI, l’ensemble des valeurs prises par NUCOM correspondant dépend aussi  des  valeurs  prises  de  NUPROD,  puisque  le  produit  acheté  par  le  client  est  obligatoirement  vendu  par  un  commercial.  Donc, quelle que soit la valeur prise par NUCLI, nous ne pourrons pas trouver des ensembles de valeurs pour NUPROD et  NUCOM indépendants. Donc, NUCLI  NUCOM.  Est­ce que NUPROD →  →  NUCLI ?  Non, car quelle que soit la valeur prise par NUPROD, l’ensemble des valeurs prises par NUCLI correspondant dépend aussi  des valeurs prises de NUCOM, puisque le produit est acheté par le client, par l’intermédiaire d’un commercial.  Donc, quelle que soit la valeur prise par NUPROD, nous ne pourrons pas trouver des ensembles de valeurs pour NUCLI et  NUCOM indépendants. Donc, NUPROD  NUCLI.  Est­ce que NUPROD →  →  NUCOM ?  Non,  car  quelle  que  soit  la  valeur  prise  par  NUPROD,  l’ensemble  des  valeurs  prises  par  NUCOM  correspondant  dépend  aussi des valeurs prises de NUCLI, puisque le produit, pour être vendu par le commercial, doit être acheté par le  client.  Donc, quelle que soit la valeur prise par NUPROD, nous ne pourrons pas trouver des ensembles de valeurs pour NUCOM et  NUCLI indépendants. Donc, NUPROD  NUCOM.  Est­ce que NUCOM →  →  NUCLI ?  Non, car quelle que soit la valeur prise par NUCOM, l’ensemble des valeurs prises par NUCLI correspondant dépend aussi  des valeurs prises de NUPROD, puisque pour qu’il y ait une relation entre le commercial et le client, il faut qu’il y  ait une vente de produits.  Donc, quelle que soit la valeur prise par NUCOM, nous ne pourrons pas trouver des ensembles de valeurs pour NUCLI et  NUPROD indépendants. Donc, NUCOM  NUCLI.  Est­ce que NUCOM →  →  NUPROD?  Non,  car  quelle  que  soit  la  valeur  prise  par  NUCOM,  l’ensemble  des  valeurs  prises  par  NUPROD  correspondant  dépend  aussi  des  valeurs  prises  de  NUCLI,  puisque  pour  que  le  commercial  vende  un  produit,  il  faut  qu’un  client  l’achète.  Donc, quelle que soit la valeur prise par NUCOM, nous ne pourrons pas trouver des ensembles de valeurs pour NUPROD et  NUCLI indépendants. Donc, NUCOM  NUPROD.  Puisque cette relation ne possède pas de DM, elle est en 4FN. Mais malgré tout, elle possède encore des redondances (cf.  l’extrait de la table en extension).  En  tant  qu’exercice,  utilisez  la  définition  3  pour  confirmer  que  cette  relation  n’a  pas  de  DM.  En  particulier,  regardez de près les tuples avec le numéro d’article égal à 7 ! 

- 24 -

© ENI Editions - All rigths reserved

c. Les Dépendances de Jointure (DJ)  Pourquoi une table en 4FN peut­elle contenir des redondances et n’être pas encore normalisée ?  Parce que les DM nous aident à décomposer sans perte les relations en 2 autres relations normalisées ; mais s’il n’y  a pas de DM pour structurer la décomposition, il est difficile de faire une décomposition sans perte d’une relation en  2+n (0
R = ∏

( R ) ⊳⊲ X1

∏

( R ) ⊳⊲ ... ∏

X2

(R)

Xn

Exemple :  Considérons  la  relation  Achat  précédente  qui  est  en  4FN  et  qui  comporte  pourtant  des  redondances. Elle n’a pas de DM qui nous serait utile pour la décomposer en deux relations. En effet, d’après les règles de  gestion, tout client, qui a besoin d’un produit et étant démarché par un commercial qui vend ce produit, a aussi acheté ce  produit à ce commercial.  Donc, nous avons trois liens ni DF, ni DM :  client ­ produit : un client a besoin de produits  commercial ­ produit : un commercial vend des produits  client ­ commercial : un client achète à des commerciaux  Créons les trois relations associées :  ●

CLIPRO 

●

COMPRO 

●

CLICOM 

En extension, nous obtenons pour chacune des relations : 

 

© ENI Editions - All rigths reserved

- 25 -

 

  Existe­t­il  une  dépendance  de  jointure  *(,  , de ACHAT donne une nouvelle relation ne comportant pas l’attribut NUCOM  et dont les tuples en doublon sont supprimés.  Nous obtenons la relation en extension : 

    Nous constatons que cette projection est la relation CLIPRO.

La projection par rapport à  de ACHAT donne une nouvelle relation ne comportant pas l’attribut NUCLI  et dont les doublons sont supprimés.  Nous obtenons la relation en extension : 

- 26 -

© ENI Editions - All rigths reserved

    Nous constatons que cette projection est la relation COMPRO.

La projection par rapport à  de ACHAT donne une nouvelle relation ne comportant pas l’attribut NUPROD  et dont les doublons sont supprimés.  Nous obtenons la relation en extension : 

  Nous constatons que cette projection est la relation CLICOM.  Soit R1 = ∏ NUCLI,NUPROD (ACHAT) ⊳⊲ ∏ NUCOM,NUPROD (ACHAT)  La jointure se fera sur l’attribut commun NUPROD.  La relation R1 en extension est la suivante : 

© ENI Editions - All rigths reserved

- 27 -

  Nous constatons qu’à ce stade de jointure (recomposition d’ACHAT à partir de deux relations), nous avons  trois tuples faux. 

Construisons maintenant R2 = R1 ⊳⊲ P NUCLI,NUCOM (ACHAT)  La jointure naturelle de ces deux relations se fera sur les deux attributs communs NUCLI et NUCOM.  La relation R2 en extension est la suivante : 

    Nous constatons que les tuples faux ont été éliminés et R2 = Achat.

Il existe une dépendance de jointure *(, ,2) relations en s’appuyant sur le concept de  la dépendance de jointure.  Le concept de dépendance de jointure étant assimilé, nous pouvons aborder la cinquième forme normale. 

d. La cinquième forme normale (5FN)  Nous avons vu dans l’exemple précédent que même une relation en 4FN et sans DM peut contenir des redondances 

- 28 -

© ENI Editions - All rigths reserved

de données ; mais nous avons vu aussi que cette relation en 4FN pouvait se décomposer sans perte en n relations  normalisées (sans aucune redondance), selon le principe de la dépendance de jointure.  C’est sur cet état de fait qu’est basée la définition de la 5FN.  Définition 1 Une relation R est en 5FN si elle ne possède aucune dépendance de jointure.  Ou Définition 2 Une relation R est en 5FN si pour toute dépendance de jointure *(X1,X2… Xn) dans R,  Alors ∀i ∈ E (entiers), Xi possède une clé candidate de R.  Une relation en 5FN, n’a pas de redondance de données, est au plus haut niveau de normalisation (jusqu’à ce que  des  points  de  faiblesse  apparaissent  et  qu’il  devienne  indispensable  d’inventer  des  formes  normales  encore  plus  élaborées !) et ne pourra être décomposée sans risque de perte d’informations.  Exemple :  La relation Achat est en 4FN.  Elle possède malgré tout des redondances, nous l’avons confirmé en regardant sa relation en extension.  Elle  ne  possède  pas  d’autres  clés  candidates  que  la  clé  primaire  actuelle  puisque  par  définition,  la  clé  primaire  est  la  composition minimale d’attributs permettant de définir des tuples uniques.  Nous  avons  vu  précédemment  qu’elle  possède  une  dépendance  de  jointure  et  en  l’occurrence  *(CLICOM,  CLIPRO,  COMPRO).  CLICOM   CLIPRO   Et COMPRO .  Donc, il existe une dépendance de jointure d’Achat pour laquelle aucune des relations issues ne possède une clé candidate  d’Achat.  Donc Achat n’est pas en 4FN.  Nous la décomposons suivant sa dépendance de jointure.  Ces  trois  relations  sont  en  5FN,  ne  comportent  plus  de  redondances  et  la  décomposition  s’est  réalisée  sans  perte d’informations.  Nous sommes enfin arrivés au bout du processus de normalisation ! 

© ENI Editions - All rigths reserved

- 29 -

Les deux approches de normalisation  Il convient maintenant d’appliquer !  La normalisation est une technique que l’on peut mettre en œ uvre à n’importe quel stade de la modélisation du futur  SI.  En effet, elle est complètement indépendante de la méthode utilisée pour concevoir le SI. De ce fait, deux approches  peuvent être suivies :  La première approche consiste à avoir une approche ascendante :  ●

nous partons de toutes les données du SI pour en faire une relation universelle, 

●

nous  gravissons  tous  les  degrés  des  FN  pour  décomposer  cette  relation  universelle  en  n  relations  sans  redondance d’informations et aboutir à un schéma relationnel normalisé. 

La deuxième approche est une approche descendante  ●

Les relations ont été construites par une méthode classique via un schéma entités­associations, 

●

Et nous les validons par conformité des exigences des différentes formes normales. 

Nous allons entrer dans le détail de chacune. 

1. Présentation du cas servant aux démonstrations  Nous allons étudier le SI de l’entreprise BOGATO de fabrication de biscuits et viennoiseries. Le périmètre de l’étude  est constitué par la fabrication des produits alimentaires par les employés, les autres services (comptabilité, achats…)  ne font pas partie de notre étude.  Les informations que nous avons recueillies (cahier des charges, audits auprès des utilisateurs…) sont les suivantes :  ●

Chaque  employé  est  identifié  par  son  matricule  unique,  son  nom  (il  peut  exister  des  homonymes  ou  des  jumeaux,  ces  derniers  auront  la  même  date  de  naissance  et  le  même  nom  mais  seront  distingués  par  leur  matricule différent) et sa date de naissance, 

●

Au  niveau  géographique,  dans  l’entreprise,  la  fabrication  des  produits  est  divisée  dans  plusieurs  unités  appelées département, qui porte chacun un numéro unique et un nom, 

●

Un employé travaille dans un département de fabrication, 

●

Un  employé  fabrique  plusieurs  produits,  il  n’est  pas  spécialisé  dans  la  fabrication  d’un  pain  viennois,  de  financiers, etc. Il est polyvalent, 

●

Chaque  biscuit  ou  viennoiserie  fabriqué  porte  un  numéro  de  produit  unique  et  un  nom  (financier,  cookie,  brioche aux fruits, brioche aux pépites de chocolat, etc.), 

●

La production d’un produit exige un temps donné par produit et par employé. En effet, un débutant ira moins  vite qu‘un employé ayant une expérience de 10 ans, 

●

Il est possible, si c’est un produit élaboré (par exemple, brioche suisse comprenant une pâte à brioche et de  la crème pâtissière), que sa fabrication requiert la participation de plusieurs employés. 

Les données exhaustives recensées sont les suivantes :  ●

NUEMP : Matricule de l’employé, 

●

NOEMP : Nom de l’employé, 

© ENI Editions - All rigths reserved

- 1-

●

DNEMP : Date de naissance de l’employé 

●

NUDEP : Numéro du département, 

●

NODEP : Nom du département, 

●

NUPROD : Numéro du produit, 

●

NOPROD : Nom du produit, 

●

TFABR : Temps de fabrication. 

2. Approche de construction de la base de données relationnelle  a. Relation universelle  Dans  cette  approche,  nous  regroupons  toutes  les  informations  de  base  dans  une  seule  relation :  la  relation  universelle.  Nous créons la relation BOGATO suivante :  BOGATO   Chaque attribut correspond à une donnée élémentaire recensée précédemment.  Consultons la relation BOGATO en extension : 

  Nous apprenons ainsi que l’employé de numéro 101 qui se nomme BELAME, est né le 14/03/1959, travaille dans le  domaine 1, Viennoiserie. Il fabrique la brioche en 2h.  Ce même employé, avec les mêmes caractéristiques, fabrique du pain au chocolat en 1h30.  La même lecture des informations est à effectuer pour les autres employés de l’entreprise.  Peut­on garder cette seule relation pour le schéma relationnel du SI de l’entreprise BOGATO ? Autrement dit, cette  relation est­elle normalisée ?  Oui, s’il n’y a pas de redondance de données. Or, dans la relation actuelle, il y a de nombreuses redondances (nom  d’employé, nom de département, nom de produit…). Donc, cette relation n’est pas normalisée.  Nous allons suivre le processus de normalisation en suivant les degrés de forme normale pas à pas.  Sachant  que  le  matricule  de  chaque  employé  est  unique,  nous  identifions  comme  clé  de  relation  le  numéro  d’employé : NUEMP.  La relation s’écrit : BOGATO   Nous obtenons la relation BOGATO en extension suivante : 

- 2-

© ENI Editions - All rigths reserved

 

b. 1FN  Cette relation est­elle en 1FN ?  Nous  remarquons  à  l’intersection  de  certaines  lignes  et  colonnes,  des  valeurs  non  atomiques.  Particulièrement,  à  l’intersection des lignes avec les attributs NOPROD et TFABR.  La relation BOGATO n’est pas en 1FN.  Nous allons utiliser la définition de la 1FN reposant sur les DF pour améliorer la relation BOGATO.  Pour  rappel :  Une  relation  R  (ID,  A1,A2…An)  est  en  1FN  si  et  seulement  si  tous  les  attributs  non­clés  dépendent  fonctionnellement de la clé de relation.  Nous devons chercher les dépendances fonctionnelles de chacun des attributs par rapport à la clé NUEMP.  D’après les règles de gestion :  NUEMP → NOEMP et NUEMP → DNEMP (il n’existe qu’une seule date de naissance par employé).  Maintenant, nous devons vérifier que :  ●

NUEMP → NUDEP ? 

●

NUEMP → NODEP ? 

●

NUEMP → NUPROD ? 

●

NUEMP → NOPROD ? 

●

NUEMP → TFABR ? 

NUEMP → NUDEP : une valeur du numéro d’employé détermine une et une seule valeur de numéro de département  puisqu’un employé ne travaille que dans un seul département.  NUEMP  →  NODEP :  une  valeur  du  numéro  d’employé  détermine  une  et  une  seule  valeur  de  nom  de  département puisqu’il travaille dans un et un seul département.  NUEMP  NUPROD :  une  valeur  du  numéro  d’employé ne détermine pas une et une seule valeur de numéro de  produit puisqu’un employé peut participer à la fabrication de plusieurs produits, étant polyvalent.  NUEMP  NOPROD :  une  valeur  du  numéro  d’employé  ne  détermine  pas  une  et  une  seule  valeur  de  nom  de  produit puisqu’un employé peut participer à la fabrication de plusieurs produits.  NUEMP  TFABR :  une  valeur  du  numéro  d’employé  ne  détermine  pas  une  et  une  seule  valeur  de  temps  de  fabrication puisqu’un employé peut participer à la fabrication de plusieurs produits.  Il faut donc que nous affinions notre clé de relation.  D’après les règles de gestion, nous savons que :  ●

NUPROD → NOPROD 

●

NUEMP, NUPROD → TFABR ? 

© ENI Editions - All rigths reserved

- 3-

Une valeur de numéro d’employé et de numéro de produit déterminent­elles une et une seule valeur de temps de  fabrication ? Oui, car le temps de fabrication conservée en information est le temps de fabrication d’un employé qui  appartient à un seul département et pour un produit bien déterminé.  Donc, NUEMP, NUPROD → TFABR.  Donc, nous allons enrichir notre clé de relation avec l’attribut NUPROD.  La relation s’écrit : BOGATO .  Cette nouvelle relation BOGATO se présente en extension sous la forme : 

  Est­elle en 1FN ?  NUEMP, NUPROD → NOEMP ? Oui par la DF NUEMP → NOEMP.  NUEMP, NUPROD → NUDEP ? Oui, par la DF NUEMP → NUDEP.  NUEMP, NUPROD → NODEP ? Oui par la DF NUDEP → NODEP (issue de la transitivité des DF).  NUEMP, NUPROD → DNEMP ? Oui par la DF NUEMP → DNEMP  NUEMP, NUPROD → NOPROD ? Oui par la DF NUPROD → NOPROD.  Donc, la relation BOGATO  est en 1FN. 

c. 2FN  Cette relation est­elle en 2FN ?  Cette relation a une clé qui n’est pas mono­attribut donc il faut vérifier qu’elle soit en 2FN.  Pour rappel : une relation R (ID1,ID2, A1, A2…An) est en 2FN si et seulement si :  ●

Elle est en 1FN. 

●

Tout attribut n’appartenant pas à une clé ne dépend pas que d’une partie de cette clé. 

La relation BOGATO  est en 1FN.  Il suffit de vérifier que NUDEP, NOEMP, DNEMP, NODEP, NOPROD, TFABR ne dépendent pas que d’une partie de la  clé. Si un au moins de ces attributs ne dépend que d’une partie de la clé, la relation n’est pas en 2FN.  Or, nous avons la DF suivante : NUEMP → NOEMP.  Donc  la  relation  actuelle  BOGATO  n’est  pas  en  2FN.  Pour  confirmer  cette  assertion,  nous  avons  aussi  les  DF  suivantes : 

- 4-

●

NUEMP → DNEMP. 

●

NUEMP → NUDEP. 

●

NUEMP → NODEP. 

© ENI Editions - All rigths reserved

●

NUPROD → NOPROD. 

Par contre, TFABR ne dépend pas que d’une partie de la clé pour la raison citée dans le paragraphe précédent.  NUEMP, NUPROD → TFABR.  Notre relation n’étant pas en 2FN, il faut la décomposer sans perte d’informations.  Au niveau de la 2FN, la décomposition en relations se réalisant via les DF, nous sommes assurés qu’il n’y aura pas  de perte d’informations si nous recréons la relation originelle.  Les DF existantes nous permettent de créer les relations suivantes :  ●

EMPLOYE 

●

PRODUIT 

●

FABRICATION 

La DF source étant la clé de la relation, nous finalisons les relations.  ●

EMPLOYE en extension : 

 

●

PRODUIT en extension : 

 

●

FABRICATION en extension : 

© ENI Editions - All rigths reserved

- 5-

  Nous avons décomposé BOGATO en trois nouvelles relations.  Il faut obligatoirement vérifier chacune d’elles en partant du niveau le plus bas de normalisation.  ●

EMPLOYE est­elle en 1FN ? Oui, la clé de relation est la DF source  de tous ses attributs. Elle est en 2FN de fait puisque sa clé de relation est mono­attribut. 

●

PRODUIT  est­elle  en  1FN ?  Oui,  la  clé  de  relation  est  la  DF  source  de  son  unique  attribut NOPROD. Elle est en 2FN de fait puisque sa clé de relation est mono­attribut. 

●

FABRICATION  est­elle  en  1FN ?  Oui,  la  clé  de  relation  est la  DF  source  de  son  unique attribut TFABR. Cette assertion implique aussi qu’elle soit en 2FN. 

d. 3FN  Ces trois nouvelles relations sont­elles en 3FN ?  Pour rappel : une relation R (ID, A1,A2…An) est en 3FN si et seulement si :  ●

Elle est en 2FN. 

●

Et tout attribut n’appartenant pas à la clé ne dépend pas d’un attribut non clé. 

Ou si la clé est multi­attribut  Une relation R’ (ID1,ID2, A’1,A’2…A’n) est en 3FN si et seulement si :  ●

Elle est en 2FN. 

●

Et tout attribut n’appartenant pas à la clé ne dépend pas d’un attribut non clé. 

La relation EMPLOYE est­elle en 3FN ?  Les questions à se poser sont les suivantes : 

- 6-

●

NOEMP → DNEMP ? 

●

NOEMP → NUDEP ? 

© ENI Editions - All rigths reserved

●

NOEMP → NODEP ? 

●

DNEMP → NOEMP ? 

●

DNEMP → NUDEP ? 

●

DNEMP → NODEP ? 

●

NODEP → NUDEP ? 

●

NODEP → NOEMP ? 

●

NODEP → DNEMP ? 

●

NUDEP → NODEP ? 

●

NUDEP → NOEMP ? 

●

NUDEP → DNEMP ? 

Il suffit qu’il y ait une réponse affirmative à l’une de ces deux questions pour que la relation ne soit pas en 3FN.  NOEMP  DNEMP car comme il y a des homonymes parmi les employés (cette assertion fait partie des règles de  gestion du SI), une valeur de nom employé ne détermine pas une et une seule valeur d’une date de naissance.  NOEMP  NUDEP car comme il y a des homonymes parmi les employés (cette assertion fait partie des règles de  gestion du SI), une valeur de nom employé ne détermine pas une et une seule valeur d’un numéro de département.  NOEMP  NODEP car comme il y a des homonymes parmi les employés (cette assertion fait partie des règles de  gestion du SI), une valeur de nom employé ne détermine pas une et une seule valeur d’un nom de département.    DNEMP  NOEMP car, à une même date de naissance peut correspondre plusieurs valeurs de nom employé. DNEMP  NUDEP car, à une même date de naissance peut correspondre plusieurs valeurs de nom employé qui ne  travaillent pas tous dans le même département, d’où plusieurs valeurs pour le numéro de département.  DNEMP  NODEP car, à une même date de naissance peut correspondre plusieurs valeurs de nom employé qui ne  travaillent pas tous dans le même département, d’où plusieurs valeurs pour le nom du département.    NODEP  NOEMP car dans un même nom de département peuvent travailler plusieurs employés. NODEP  DNEMP  car  dans  un  même  nom  de  département  peuvent  travailler  plusieurs  employés  qui  sont  nés  à  des dates différentes.  NODEP  NUEMP  car  les  règles  de  gestion  ne  précisent  pas  qu’obligatoirement  tous  les  départements  ont  des  noms différents.  Mais NUDEP  → NODEP. En effet, une valeur d’un numéro de département détermine une et une seule valeur de  nom de département.  Donc, il existe un attribut non­clé qui est dépendant d’un autre attribut non­clé.  Donc, la relation EMPLOYE n’est pas en 3FN.  Finissons d’examiner les DF.    NUDEP 

NOEMP car dans un même nom de département peuvent travailler plusieurs employés.

NUDEP  DNEMP  car  dans  un  même  nom  de  département  peuvent  travailler  plusieurs  employés  qui  sont  nés  à  des dates différentes.  La relation EMPLOYE n’étant pas en 3FN, il faut la décomposer.  Pour  rappel !  La  décomposition  d’une  table,  qui  n’est  pas  au  degré  de  normalisation  demandé,  va  se  baser  uniquement sur les DF existantes dans la relation. 

© ENI Editions - All rigths reserved

- 7-

Nous allons regrouper toutes les DF cible d’une DF source dans une relation.  En suivant cette règle et en partant d’une relation qui n’est pas en 3FN, nous allons obtenir au moins une relation  de plus.  Recensons nos DF :  ●

NUEMP → NOEMP 

●

NUEMP → DNEMP 

●

NUEMP → NUDEP 

●

NUDEP → NODEP 

Nous obtenons deux relations :  ●

EMPLOYE 

●

DEPARTEMENT 

Les clés de chacune de ces relations sont la ou les DF source.  Donc nous obtenons :  ●

EMPLOYE 

●

DEPARTEMENT 

DEPARTEMENT est une entité paramètre. Sa clé primaire NUDEP est la clé étrangère de la relation EMPLOYE.  Ces deux relations en extension : 

  Les  relations PRODUIT,  DEPARTEMENT  et  FABRICATION ne comportant qu’un seul attribut non­clé sont, de fait, en 3FN.  La  base  de  données  relationnelle  du  SI  de  l’entreprise  BOGATO  est  en  3FN  et  nous  voyons  qu’il  n’y  a  aucune  redondance d’informations dans aucune relation. Elle est donc normalisée.  Malgré tout, continuons à explorer les FN supérieures. 

e. FNBC 

- 8-

© ENI Editions - All rigths reserved

Les quatre relations du schéma relationnel de BOGATO sont­elles en FNBC ?  Pour rappel : Une relation est en FNBC si et seulement si :  ●

Elle est en 3FN. 

●

Aucun attribut faisant partie de la clé ne dépend d’un attribut ne faisant pas partie de la clé primaire. 

Considérons la relation EMPLOYE  Les questions à se poser sont les suivantes :  ●

NOEMP → NUEMP ? 

●

DNEMP → NUEMP ? 

●

NUDEP → NUEMP ? 

NOEMP  NUEMP : le système admet des homonymes pour les noms d’employés donc une valeur de nom employé  ne détermine pas une et une seule valeur de matricule employé.  DNEMP  NUEMP :  une  valeur  de  date  de  naissance  ne  détermine  pas  une  et  une  seule  valeur  de  matricule  d’employé.  NUDEP  NUEMP : une valeur de numéro de département ne détermine pas une et une seule valeur de matricule  d’employé.    NOEMP  NUEMP et DNEMP  NUEMP et NUDEP  NUEMP, donc la relation EMPLOYE est en FNBC. Considérons la relation PRODUIT.  La question à se poser est NOPROD → NUPROD ?  Les règles de gestion nous précisent que le numéro de produit est unique mais pas le nom. Donc, une valeur de  nom de produit n’est pas susceptible de déterminer obligatoirement une et une seule valeur de numéro de produit.    Donc, NOPROD  NUPROD. La relation PRODUIT est en FNBC.  Considérons la relation DEPARTEMENT.  La question à se poser est NODEP → NUDEP ?  Les règles de gestion nous précisent que le numéro de département est unique mais pas le nom. Donc, une valeur  de nom de département n’est pas susceptible de déterminer obligatoirement une et une seule valeur de numéro  de département.    Donc, NODEP  NUDEP. La relation DEPARTEMENT est en FNBC.  Considérons la relation FABRICATION.  Les questions à se poser :  ●

TFABR → NUEMP ? 

●

TFABR → NUPROD ? 

Un  employé  peut  participer  à  la  fabrication  de  plusieurs  produits,  qui  peuvent  avoir  des  temps  de  fabrication  différents. De même, plusieurs employés peuvent mettre le même temps de fabrication pour les mêmes produits ou  des produits différents. Donc, une valeur de temps de fabrication ne détermine pas une et seule valeur de matricule  d’employé.    Donc, TFABR  NUEMP. Un  produit  peut  avoir  des  temps  de  fabrication  différents  suivant  l’employé  qui  s’en  occupe.  Donc,  une  valeur  de  temps de fabrication ne détermine pas une et seule valeur de numéro de produit.    © ENI Editions - All rigths reserved

- 9-

Donc, TFABR 

NUPROD.

La relation FABRICATION est en FNBC.  La relation EMPLOYE est FNBC.  La relation PRODUIT est en FNBC.  La relation DEPARTEMENT est en FNBC.  Donc, la base de données relationnelle du SI de BOGATO est en FNBC. 

f. 4FN  Est­il en 4FN ?  Pour rappel : Une relation est en 4FN si et seulement si :  ●

Elle est en FNBC. 

●

Elle ne contient aucune DM Non­Triviale. 

Dépendance Multivaluée Non­Triviale (DMNT) La DM X → → Y de la relation R est une DM Non Triviale si et seulement  ●

Si X n’est pas un sous­ensemble de Y 

●

Si X ∪ Y ≠ R. 

ET 

La relation EMPLOYE  est­elle en 4FN ?  La première question à se poser est de savoir si elle contient des DM et si oui, si elles sont triviales ou non.  Rappelez­vous la remarque que nous avions faite :  Attention ! C’est ce postulat de complète indépendance entre deux attributs, qui sont malgré tout liés par  une DF à un même troisième attribut, qui permet de déterminer une DM. 

Or  pour  chaque  employé :  son  nom,  sa  date  de  naissance,  son  numéro  de  département  font  partie  de  ses  caractéristiques propres. La connaissance de celles­ci fait partie de la connaissance de l’individu. Ces 3 propriétés  ne sont pas indépendantes, elles font partie du même tout : l’employé ; contrairement aux propriétés de l’exemple  vu  dans  le  paragraphe  concernant  les  DM  (cf.  ce  chapitre  Processus  de  normalisation ­ Les  dépendances  multivaluées).  Donc, la relation EMPLOYE n’ayant pas de DM, n’a pas de DMNT. Elle est aussi en FNBC donc elle est en 4FN.  Considérons maintenant la relation FABRICATION.  Il n’existe pas de DM, il n’y a que la DF NUPROD, NUEMP → TFABR. Les valeurs de ces 3 attributs sont dépendantes  entre elles.  Donc,  la  relation  FABRICATION  n’ayant  pas  de  DM,  n’a  pas  de  DMNT.  Elle  est  aussi  en  FNBC donc elle est en 4FN.  Les  relations  PRODUIT  et  DEPARTEMENT  ne  comportant  que  2  attributs  (un  attribut clé et un attribut non clé) sont de fait en 4FN.  La relation EMPLOYE  est en 4FN.  Donc, la base de données relationnelle actuelle du SI de BOGATO est en 4FN. 

g. 5FN  Le schéma relationnel de BOGATO est­il en 5FN ? 

- 10 -

© ENI Editions - All rigths reserved

Pour rappel :  Définitions 5FN Une relation R est en 5FN si elle ne possède aucune dépendance de jointure.  Ou  Une  relation  R  est  en  5FN  si  pour  toute  dépendance  de  jointure  *(X1,X2…  Xn)  dans  R,  alors  ∀i  ∈  E  (entiers),  Xi  possède une clé candidate de R.  Dépendance de jointure Soit une relation R (A1, A2… An), et X1, X2…Xn des sous­ensembles de (A1, A2… An) avec ∀i ∈ E (entiers), Ai étant  un attribut dont les valeurs appartiennent à un domaine Di.  On dira qu’il existe une dépendance de jointure *(X1,X2…Xn) si R est la jointure de ses projections sur X1, X2, … Xn.  C’est­à­dire, ∃ *(X1,X2… Xn) < = = > R = ∏ X1 (R) ⊳⊲ P X2 (R) ⊳⊲ … ∏ Xn (R)  La relation EMPLOYE possède­t­elle d’autres clés candidates que NUEMP ?  Le travail effectué pour les vérifications des FN inférieures nous permettent de dire que NON. NUEMP est la seule clé  candidate  et  primaire.  Ainsi,  il  n’est  pas  possible  de  trouver  une  dépendance  de  jointure  où  toutes  les  relations  comporteraient une clé candidate d’EMPLOYE.  Donc, la relation EMPLOYE est en 5FN.  Les  relations  PRODUIT  et  DEPARTEMENT  ne  comportant  que  deux  attributs  (un attribut clé et un attribut non clé) n’ont pas de dépendance de jointure, donc elles sont en 5FN.  Considérons la relation FABRICATION.  A­t­elle des clés candidates autres que NUEMP, NUPROD ?  NUPROD, TFABR est­elle une clé candidate ? Cela veut dire que la connaissance d’une valeur d’un n° de produit et  d’un  temps  de  fabrication  permet  de  déterminer  une  valeur  d’un  seul  employé.  Non,  un  employé  peut  fabriquer  plusieurs  produits  et  avec  des  temps  identiques  ou  différents.  Un  produit  peut  être  fabriqué  par  des  employés  différents avec un temps identique ou différent. Il est donc possible d’avoir des doublons avec cette éventuelle clé,  donc ce n’est pas une clé candidate.  Pour confirmer notre propos, considérons la relation FABRICATION avec cette clé candidate : 

  NUEMP,  TFABR  est­elle  une  clé  candidate ?  Cela  veut  dire  que  la  connaissance  d’une  valeur  d’un  n°  d’employé  et  d’un  temps  de  fabrication  permet  de  déterminer  une  valeur  d’un  seul  produit.  Non,  un  employé  peut  fabriquer 

© ENI Editions - All rigths reserved

- 11 -

plusieurs produits avec des temps identiques. Il est donc possible d’avoir des doublons avec cette éventuelle clé,  donc ce n’est pas une clé candidate.  Pour confirmer notre propos, considérons la relation FABRICATION avec cette clé candidate : 

  Du fait de doublons déjà existants pour les clés candidates multi­attributs de la relation FABRICATION, il n’existe pas  de clés candidates mono­attribut pour cette relation.  Donc, la clé primaire de FABRICATION est la seule clé candidate.  De  ce  fait,  on  ne  pourra  pas  décomposer  la  relation  Fabrication  en  dépendance  de  jointure  dont  chacune  des  relations composantes auraient une clé candidate.  La relation FABRICATION est donc en 5FN.  La relation EMPLOYE est en 5FN.  Les relations PRODUIT et DEPARTEMENT sont en 5FN.  Donc, la base de données relationnelle que l’on vient de constituer pour le SI de l’entreprise BOGATO est 5FN.  Elle est complètement normalisée. 

3. Approche de validation de la base de données relationnelle  Dans  cette  approche,  à  partir  de  l’expression  des  besoins  des  utilisateurs,  nous  construisons  le  schéma  entités­ associations  des  données  du  futur  SI  par  une  méthode  d’analyse  classique.  Puis,  nous  en  déduisons  les  tables  (relations) de la future base de données relationnelle ; et c’est à ce stade, que nous appliquons toutes les règles de  E. F. Codd pour valider la normalisation de la base de données.  Pour appliquer cette approche, nous allons repartir des informations de l’entreprise BOGATO et construire la base de  données via les étapes vues dans les premiers chapitres (dictionnaire de données…) puis la valider.  Rappelons­nous les étapes à suivre : 

- 12 -

●

Élaborer le dictionnaire de données exhaustif et épuré (sans homonymes et sans synonymes), 

●

Réaliser la Matrice des Dépendances Fonctionnelles entre ces données, 

●

En déduire le schéma Entités­Associations 

© ENI Editions - All rigths reserved

Traduire  ce  schéma,  suivant  les  règles  de  transformation  en  MPD  de  Merise,  pour  obtenir  les  relations  exhaustives de notre future base de données relationnelle. 

●

a. Dictionnaire des données  Notre étude des informations fournies par l’entreprise BOGATO, nous a permis de dresser une liste exhaustive des  données :  ●

NUEMP : Matricule de l’employé, 

●

NOEMP : Nom de l’employé, 

●

DNEMP : Date de naissance de l’employé 

●

NUDEP : Numéro du département de fabrication, 

●

NODEP : Nom du département de fabrication, 

●

NUPROD : Numéro du produit, 

●

NOPROD : Nom du produit, 

●

TFABR : Temps de fabrication du produit par un employé. 

Vous remarquerez que l’analyse des besoins des utilisateurs et des informations qu’ils ont fournies, conduit  à la même liste exhaustive de données que dans la première approche. C’est normal et c’est obligatoire ! 

Il n’y a pas de synonymes, ni d’homonymes dans les données.  Cela nous conduit à déterminer trois objets du monde réel (trois entités) : l’employé, le produit et le département  Il faut trouver la donnée qui soit l’identifiant de chacune des entités.  Sachant que le matricule de l’employé est unique, le numéro de département de fabrication est unique et le numéro  de produit est unique, nous en déduisons que :  ●

NUEMP sera l’identifiant de l’entité EMPLOYE, 

●

NUDEP sera l’identifiant de l’entité DEPARTEMENT, 

●

NUPROD sera l’identifiant de l’entité PRODUIT. 

Nous en déduisons le dictionnaire de données suivant : 

 

b. Matrice des Dépendances Fonctionnelles  Recherche des dépendances fonctionnelles Pour rappel : deux données A et B sont en dépendance fonctionnelle, si la connaissance de la valeur de A permet  © ENI Editions - All rigths reserved

- 13 -

d’identifier une et une seule valeur de B.  Cet axiome doit être vrai pour toutes les valeurs de A.  À ce stade du livre, nous sommes aguerris dans la recherche des DF.  Nous déduisons facilement les DF suivantes :  ●

NUEMP → NOEMP 

●

NUEMP → DNEMP 

●

NUEMP → NUDEP 

●

NUEMP → NODEP 

●

NUDEP → NODEP 

●

NUPROD → NOPROD 

Par contre, nous noterons principalement que :    ●

NUEMP 

NUPROD

●

NUDEP 

●

NUDEP 

NOPROD   NUEMP

 

Nous avons trois données source de DF (NUEMP, NOPROD et NUDEP) qui sont, d’ailleurs les identifiants que nous  avions déterminés pour les entités du monde réel : Employé, Produit et Département.  À part TFABR, les autres attributs sont des données cible.  TFABR n’est pas une source de DF.  Par contre, à ce stade, nous ne savons pas encore à quelle DF elle appartient.  Matrice des Dépendances Fonctionnelles Nous allons la construire par étapes : 

  Nous venons d’indiquer la propriété de réflexivité des DF sur chacun des attributs.  Nous y rajoutons les informations concernant les DF.  Nous éliminons les colonnes ne concernant que des données cible et effectuons un premier Total : 

- 14 -

© ENI Editions - All rigths reserved

  Analysons la colonne Total.  Le total égal à 0 pour les données source de DF, NUEMP et NUPROD est normal.  Le total égal à 1 pour les données cible de DF, NOEMP, DNEMP, NOPROD est normal.  Le total égal à 1 pour la donnée source d’une DF NUDEP est normal.  Le total égal à 2 pour la donnée cible de DF NODEP est anormal.  Le total égal à 0 pour la donnée TFABR qui doit être cible d’une DF est anormal.  Le total égal à 2 pour NODEP induit que celle­ci est en DF avec plusieurs sources. La propriété de transitivité de la  dépendance fonctionnelle est mise en œ uvre et cela crée des dépendances fonctionnelles redondantes.  C’est exact, nous avons :  ●

NUEMP → NODEP 

●

Et NUDEP → NODEP 

De plus, nous avons NUEMP → NUDEP.  Or, la propriété de transitivité signifie que si NUEMP → NUDEP et que NUDEP → NODEP, alors NUEMP → NODEP en  est déduit.  Il  faut  conserver  les  deux  branches  initiatrices  de  la  transitivité  et  éliminer  la  branche  déduite,  car  c’est  elle  qui  induit les redondances. Il ne faut donc pas conserver NODEP dans l’entité EMPLOYE.  D’où la nouvelle MDF : 

  Le total égal à 0 pour la donnée TFABR qui doit être cible d’une DF est anormal.  La donnée n’est pas source de dépendance fonctionnelle. Elle est isolée dans le Système d’Information. 

© ENI Editions - All rigths reserved

- 15 -

Mais  nous  savons  que  la  connaissance  d’une  valeur  de  temps  de  fabrication  est  dépendante  de  la  connaissance  d’une valeur d’un matricule employé et d’un numéro de produit.  En effet :  ●

Un  employé  fabrique  plusieurs  produits,  il  n’est  pas  spécialisé  dans  la  fabrication  d’un  pain  viennois,  de  financiers, etc. Il est polyvalent. 

●

La  production  d’un  produit  exige  un  temps  donné  par  produit  et  par  employé.  En  effet,  un  débutant  ira  moins vite qu‘un employé ayant une expérience de 10 ans. 

●

Il est possible, si c’est un produit élaboré (par exemple, brioche suisse comprenant une pâte à brioche et de  la crème pâtissière), que la fabrication d’un produit requiert la participation de plusieurs employés. 

Donc le temps de fabrication (TFABR) est cible d’une composition des données source NUEMP et NUPROD.  Nous allons construire un nouvel identifiant et l’intégrer dans la MDF. 

 

c. Création de la base de données relationnelle  Rappelons­nous  la  synthèse  de  la  conversion  de  la  MDF  en  schéma  de  relation  d’une  base  de  données  relationnelle : 

  À  partir  de  la  MDF  suivante,  nous  pouvons  construire  une  base  de  données  relationnelle  pour  le  SI  de  BOGATO,  constituée des relations suivantes : 

- 16 -

●

La relation EMPLOYE . 

●

La relation PRODUIT. 

© ENI Editions - All rigths reserved

●

La relation DEPARTEMENT. 

●

La relation FABRICATION. 

Cette base de données ne vous rappelle­t­elle pas quelque chose ?  C’est en effet la base de données relationnelle que nous avons trouvé à l’issue de notre première approche, celle  de  construction  d’une  base  de  données  à  partir  de  la  relation  universelle,  après  décomposition  de  la  relation  universelle en relations en 3FN. 

d. Validation de la base de données relationnelle 

Attention !  Nous  avons  utilisé  la  MDF  pour  réaliser  la  base  de  données  relationnelle ;  donc  les  liens  existants entre les attributs d’une des relations celles­ci, sont tous basés sur les DF. Ce qui nous permet  d’affirmer que cette base de données relationnelle est au moins, en 3FN. 

Par  contre,  les  DM  et  les  DJ  ne  sont  pas  étudiées  dans  la  MDF,  donc  on  ne  peut  pas  affirmer  que  cette  base  de  données relationnelle est de fait en 5FN.  Nous allons malgré tout, en tant qu’étude pour la pratique, vérifier que toutes les relations suivent les exigences de  toutes les formes normales.  EMPLOYE  est­elle  en  1FN ?  Oui,  la  clé  de  relation  est  la  DF  source  de  tous  ses  attributs. Elle est en 2FN de fait puisque sa clé de relation est mono­attribut.  PRODUIT  est­elle  en  1FN ?  Oui,  la  clé  de  relation  est  la  DF  source  de  son  unique  attribut  NOPROD. Elle est en 2FN de fait puisque sa clé de relation est mono­attribut.  DEPARTEMENT  est­elle  en  1FN ?  Oui,  la  clé  de  relation  est  la  DF  source  de  son  unique  attribut  NODEP. Elle est en 2FN de fait puisque sa clé de relation est mono­attribut.  FABRICATION est­elle en 1FN ? Oui, la clé de relation est la DF source complexe de son  unique attribut TFABR. Cette assertion implique aussi qu’elle soit en 2FN.  La  MDF  nous  confirme  que  la  relation  EMPLOYE  est  en  3FN  ,  car  aucun  des  attributs non­clés de la relation ne dépend d’un attribut n’appartenant pas à la clé.  Les  relations PRODUIT,  DEPARTEMENT  et  FABRICATION ne comportant qu’un seul attribut non­clés sont, de fait en 3FN.  Pour les vérifications des formes normales suivantes FNBC, 4FN, 5FN, reportez­vous aux paragraphes précédents,  c’est exactement le même raisonnement. Nous démontrerons ainsi que cette base de données relationnelle est en  5FN.  En conclusion, notre approche méthodique, basée sur les DF, nous assure de construire une base de données au  minimum en 3FN et très souvent, au­delà. 

e. Exercice additionnel  Énoncé Construire le schéma entités­associations du SI de l’entreprise BOGATO.  Solution À partir de la MDF, nous allons d’abord identifier les entités.  L’ensemble  constitué  d’une  donnée  source  élémentaire  et  de  ses  données  cible  représente  une  entité.  La  donnée  source est l’identifiant de cette entité. Les autres données cible constituent les propriétés de cette entité.  Nous obtenons trois entités : Employé, Produit et Département.  Nous recherchons ensuite s’il y a des associations.  L’ensemble constitué d’une donnée source complexe et de ses données cible représente une association particulière :  une CIM. La donnée source complexe est l’identifiant de cette association. Les autres données cible constituent les  propriétés de cette association.  Nous avons une CIM : fabrique en (temps). L’identifiant de cette association est la composition NUEMP­NUPROD (1  employé, 1 produit) et l’attribut TFABR (temps de fabrication). 

© ENI Editions - All rigths reserved

- 17 -

Il faut enfin reprendre les règles de gestion de la MOA pour compléter le schéma avec les associations simples.  Il  n’y  a  qu’une  seule  association  simple  à  rajouter,  à  savoir  qu’un  employé  appartient  à  un  département  de  fabrication.  Nous avons recensé toutes les entités et toutes les associations qui représentent le SI de l’entreprise BOGATO.  Nous obtenons le schéma Entités­Associations incomplet suivant : 

  Il  ne  nous  reste  plus  qu’à  rajouter  les  cardinalités,  toujours  en  se  basant  sur  les  informations  fournies  par  l’entreprise BOGATO.  Les  cardinalités  de  l’entité  Département  et  de  l’entité  Employé,  pour  l’association  ∈,  sont  calculées  à  partir  des  assertions :  ●

Les employés appartiennent à un et un seul département de fabrication. 

●

Un département de fabrication englobe de 1 à n employés. 

●

Les  cardinalités  de  l’entité  Produit  et  de  l’entité  Employé,  pour  l’association  Fabrique  en,  sont  calculées  à  partir des assertions : 

●

Un employé fabrique de 1 à n produit(s). 

●

Un produit peut être fabriqué par 1 à n employés. 

Nous obtenons le schéma Entités­Associations complet suivant : 

- 18 -

© ENI Editions - All rigths reserved

 

© ENI Editions - All rigths reserved

- 19 -

Synthèse  Nous avons découvert tout au long de ce chapitre qu’un même dictionnaire de données et que les mêmes règles de  gestion  peuvent  générer  des  schémas  de  relation  différents  suivant  l’interprétation  et  le  degré  d’analyse  de  l’informaticien.  Mais, malheureusement, une mauvaise perception du réel entraînera des difformités dans la structure du futur schéma  relationnel. Celles­ci seront responsables de la présence de données redondantes, d’incohérences potentielles entre  les informations gérées par le SI, d’un surcoût de gestion et de stockage de la BD.  La réponse à cette problématique est de normaliser le schéma relationnel de la future base de données.  Il existe deux approches de normalisation : l’approche de construction du schéma relationnel en partant de la relation  universelle et l’approche de validation du schéma relationnel après construction de celui­ci avec méthode (dictionnaire  des données, Matrice des Dépendances Fonctionnelles…). En tant que praticienne, le conseil que je vous donnerai est  de préférer la deuxième approche, beaucoup moins empirique, qui a l’avantage de border la démarche et de fournir une  base de données relationnelle au minimum en 3FN, avantage indéniable pour les débutants.  De toute manière, quel que soit l’approche privilégiée, le processus de normalisation suivra une démarche par étape.  Chaque étape consistera à vérifier un degré de forme normale. Chaque étape suivante ne pourra être abordée que si  l’étape précédente est vérifiée.  E. F. Codd a inventé plusieurs niveaux de forme normale.  ●

La première forme normale oblige à avoir des attributs atomiques au sein d’une relation. 

●

Les deux formes normales suivantes reposent sur le concept de dépendance fonctionnelle entre attributs d’une  relation. 

Généralement et dans le contexte de l’approche de validation du schéma relationnel, la vérification de ces trois formes  normales  sur  toutes  les  relations  d’un  schéma  relationnel  élimine  toute  forme  de  redondances  dans  celui­ci.  Elle  implique  donc  l’assurance  d’avoir  éradiquer  tout  risque  de  problème  pouvant  entraîner  une  incohérence  du  schéma  relationnel. Et dans la plupart des cas, si un schéma relationnel a toutes ses relations en 3FN, il est normalisé.  Nous  confirmons  donc,  que  les  connaissances  acquises  dans  les  chapitres  précédents  (dictionnaire  de  données,…  et  surtout MDF) nous suffiront pour créer un schéma relationnel normalisé en pratique courante.  Mais si vous avez un SI très élaboré à construire, avec des règles de gestion très complexes, alors des anomalies, liées  à  une  faiblesse  de  normalisation,  peuvent  subsister.  C’est  à  cet  effet  qu’E.  F.  Codd  a  introduit  les  définitions  de  la  forme normale de Boyce­Codd, puis de la quatrième et de la cinquième forme normale plus tard, pour répondre à ces  besoins exceptionnels et rares.  Ces formes normales reposent non plus sur les dépendances fonctionnelles mais sur des dépendances plus complexes  (multivaluées et de jointure). 

© ENI Editions - All rigths reserved

- 1-

Exercice  1. Énoncé  Soit la relation Tarif, où :  ●

NOLIV est l’attribut Titre du livre. 

●

TYPEEDIT est l’attribut format d’édition (poche, avec CD,…). 

●

PVENTE est l’attribut prix de vente. 

Un même livre peut avoir plusieurs formats d’édition, mais différents les uns des autres, qui détermineront son prix de  vente.  Il y a un prix de vente par format d’édition. Par contre, le même prix de vente peut être attribué à plusieurs formats  d’édition.  1) Cette relation est­elle normalisée ?  2) Si non, que faut­il faire pour normaliser cette relation ? 

2. Solution  1)  Une  relation  est  en  première  forme  normale.  Si  pour  chaque  tuple  de  la  relation,  chaque  attribut  contient  une  valeur atomique.  Autrement  dit,  si  l’on  considère  une  relation  en  extension,  cette  relation  est  dite  en  première  forme  normale  si  et  seulement à l’intersection d’une colonne (attribut) et d’une ligne (tuple) , on ne peut trouver qu’un seul élément.  Or, l’énoncé nous dit que pour un Titre de Livre, il existe plusieurs TYPEDIT (livre de poche, édition de luxe,…) , donc la  relation n’est pas en 1FN .  2) Il faut d’abord vérifier les DF existantes entre les attributs et modifier si besoin la clé primaire de la relation.  Quelles sont les DF existantes ?  Pour un même Titre de Livre, il peut exister plusieurs formats d’édition. Donc, NOLIV 

  TYPEDIT.  

De même, un même format d’édition peut concerner plusieurs titres de livre, donc TYPEDIT  Le même prix de vente peut être attribué à plusieurs formats d’édition, donc PVENTE 

NOLIV.   TYPEDIT.  

Le même prix de vente peut être attribué à plusieurs titres de livre différents, donc PVENTE 

NOLIV.

Le format d’édition détermine le prix de vente. Donc, pour une valeur de format d’édition, il existe une et une seule  valeur pour le prix de vente, donc TYPEDIT → PVENTE  Donc, si nous associons à une valeur de titre de livre, une valeur de son format d’édition, nous déterminons alors une  et une seule valeur pour le prix de vente.  NOLIV­TYPEDIT  est une  composition  minimale  d’attributs  dont  chacune  des  valeurs  permet  de  déterminer  d’une  manière unique un tuple de la relation.  Il n’y a pas d’autres attributs ou composition minimale d’attributs permettant de déterminer une et une seule valeur  de  tuples.  En  effet,  les  autres  compositions  minimales  d’attribut  TYPEDIT­PVENTE  et  NOLIV­PVENTE  ne  sont  source  d’aucune DF (TIPEDIT  NOVLIV, PVENTE  NOLIV et NOLIV  TYPEDIT, PVENTE  TYPEDIT).  Nous obtenons la relation Tarif en 1FN.  Cette relation est­elle en 2FN ?  Nous venons de prouver que tout attribut non­clé (en l’occurrence PVENTE) ne dépend pas que d’une partie de la clé.  Cette relation est­elle en 3FN ?  Cette relation ne comporte qu’un seul attribut non­clé, elle est de fait en 3FN.  Cette relation est­elle en FNBC ?  © ENI Editions - All rigths reserved

- 1-

  L’étude des DF nous a indiqué que : PVENTE 

TYPEDIT et PVENTE 

NOLIV.

Ainsi,  aucun  attribut  faisant  partie  de  la  clé  ne  dépend  d’un  attribut  ne  faisant  pas  partie  de  la  clé  primaire.  Donc,  cette relation est en FNBC.  Cette relation est­elle en 4 FN ?  Il  n’existe  pas  de  DM,  il  n’y  a  que  la  DF  NOLIV,  TYPEDIT  →  PVENTE.  Les  valeurs  de  ces  trois  attributs  sont  dépendantes entre elles.  Donc, la relation Tarif  n’ayant pas de DM, n’a pas de DMNT. Elle est aussi en FNBC donc  elle est en 4FN.  Cette relation est­elle en 5FN ?  Nous avons vérifié en analysant les DF qu’il n’y avait pas d’autres clés candidates que la clé primaire NOLIV­TYPEDIT,  donc s’il existait des dépendances de jointure pour cette relation, il ne serait pas possible que toutes les relations de  la dépendance de jointure possède une clé candidate.  Donc la relation Tarif est en 5FN. 

- 2-

© ENI Editions - All rigths reserved

Énoncé  Le centre multimédia d’une grande ville souhaite rénover l’informatisation de la gestion des prêts de livres, CD et DVD.  Son patrimoine est constitué de 10 000 livres, 5 000 CD et 3 200 DVD.  Tout habitant de la ville peut s’inscrire (avec un justificatif de domicile) au centre multimédia.  Suivant le type de son adhésion, il aura accès à divers services et un montant de cotisation annuel différent :  ●

adhésion LIGHT de 10 euros (enfant < 15 ans : 8 euros) : emprunt de livres ou CD ou DVD, 

●

adhésion MEDIUM de 16 euros (enfant < 15 ans : 14 euros) : emprunt de livres et CD, 

●

adhésion XTRA de 20 euros (enfant < 15 ans : 17 euros) : emprunts de livres, de CD et de DVD. 

L’adhérent  reçoit  une  carte  d’adhésion  valable  un  an  où  figurent  l’année,  son  numéro  d’adhérent,  son  numéro  d’inscription  (unique  pour  chaque  adhérent),  son  nom,  son  prénom,  sa  date  d’adhésion,  la  date  de  règlement  de  l’adhésion et sa date de naissance et où il doit apposer sa photo d’identité.  La  carte  d’adhésion  est  valable  du  1  janvier  au  31  décembre  de  l’année  en  cours.  Si  l’adhérent  renouvelle  son  adhésion l’année suivante, il reçoit un nouveau numéro d’inscription.  Chaque adhésion est individuelle : chaque membre d’une même famille peut avoir sa carte d’adhérent.  L’emprunt  maximal  est  de  3  livres  et/ou  2  CD  et/ou  1DVD  pour  15  jours.  Le  retour  d’un  emprunt  peut  s’effectuer en  plusieurs fois.  Chaque  livre  est  repéré  par  son  numéro  ISBN  unique  et  peut  avoir  été  acheté  par  le  centre  multimédia  en  1  à  5  exemplaires.  Il  sera  classé  dans  les  rayons  de  la  bibliothèque  par  catégorie.  Un  code  unique  détermine  chaque  catégorie (SF : Science Fiction, P : Policier,….).  Chaque CD ou DVD (acheté en 1 ou 3 exemplaires) est repéré par son numéro unique, son titre et sa catégorie. Un  code unique détermine chaque catégorie (R : Rap, CM : Comédies musicales,….).  Chaque exemplaire de livre, CD ou DVD est distingué par un numéro unique. À tout instant, la bibliothécaire sait s’il est  disponible ou non (déjà emprunté).  Les  livres,  CD  et  DVD  sont  achetés  à  un  seul  fournisseur :  MEdia­One.  Leur  règlement  ne  sont  pas  effectués  par  la  bibliothèque.  À la réception d’un  nouveau  livre,  CD  ou  DVD,  la  bibliothécaire  lui  affecte  une  fiche  sur  laquelle  elle  notera  les  dates  d’emprunts et de retour de cet article.  À  chaque  emprunt,  la  bibliothécaire  vérifie  que  l’adhérent  a  son  adhésion  valide  et  note  le  numéro  de  l’emprunt  (unique, ce numéro est constitué du quantième du jour + un numéro incrémental qui recommence à 1 tous les jours), la  date d’emprunt, les éléments empruntés, le numéro de l’adhérent emprunteur, la date prévue de retour. Elle enlève les  fiches des éléments empruntés, les met à jour et les range dans un bac à fiches.  Il vous a été demandé de concevoir la base de données du futur SI de gestion de cette bibliothèque (stockage des  livres, CD et DVD, gestion des adhérents et des emprunts).  1) Représenter le Modèle de Contexte.  2) Constituer le dictionnaire épuré du SI.  3) Réaliser la MDF.  4) Réaliser le schéma entités­associations.  5) Décrire les relations de la base de données relationnelle du futur SI.  6) En utilisant des opérateurs d’algèbre relationnelle, répondre aux interrogations suivantes :  ●

a) Quelles sont les catégories possibles pour les média (libellé) ? 

●

b) Quels sont les livres (N° et titre) qui n’ont aucun exemplaire de disponible ? 

●

c) Quels sont les media (Numéro et code type) proposés par la bibliothèque pour "Le Comte de Monte­Cristo". 

●

d) Quels sont les media (Numéro et libellé type) proposés par la bibliothèque pour "Le Comte de Monte­Cristo". 

© ENI Editions - All rigths reserved

- 1-

- 2-

●

e)  Quels  sont  les  titres  des  livres  dont  le  prix  d’achat  d’un  de  ses  exemplaires  est  supérieur  à  25  € ?  Nous  savons que le TYPMED (Type de média) des livres est égal à ‘1’. Donner l’arbre algébrique associé. 

●

f) Quels sont les adhérents qui n’ont pas encore fait d’emprunt au 14/12/2008 ? 

●

g) Quels sont les adhésions qui ont été réglées le jour même de l’adhésion ? 

© ENI Editions - All rigths reserved

Solution  1) Modèle de Contexte  Le Modèle de Contexte est un des deux diagrammes du Modèle Conceptuel de Communication.  Le Modèle de Contexte va permettre de déterminer :  ●

les frontières de notre SI, 

●

les acteurs externes, 

●

les flux existants (émission et réception) entre le SI et les acteurs externes. 

Le SI devra inclure le stockage des livres, CD et DVD, la gestion des adhérents et des emprunts ; mais il n’inclura pas la  relance des emprunts puisque cela n’a pas été demandé.  Les seuls acteurs externes sont l’adhérent et le fournisseur MEdia­One.  Les flux en réception du SI (en provenance de l’adhérent) :  ●

Demande d’adhésion + justificatif, 

●

Cotisation, 

●

Retour emprunt. 

Les flux en réception du SI (en provenance du fournisseur) :  ●

Médias (livres, CD et DVD) 

●

Les flux en émission du SI (vers l’adhérent) : 

●

Carte d’adhérent, 

●

Emprunt (livres et/ou CD et/ou DVD). 

Il n’y a pas d’émission vers Media­One car le paiement des médias n’est pas effectué par la bibliothèque elle­même.  Nous pouvons représenter le MC du SI : 

© ENI Editions - All rigths reserved

- 1-

  2) Dictionnaire des Données  Les informations recensées sont les suivantes :  ●

L’adhérent possède un numéro d’adhérent, nom, prénom et une date naissance. 

●

L’adhérent prend une adhésion pour une année à une date d’adhésion  et  règle  son  adhésion  à  une  date  de  règlement. 

●

Un type d’adhésion possède un code, un libellé, un nombre de livres autorisés, un nombre de CD autorisés, un  nombre de DVD autorisés, un tarif adulte et un tarif enfant. 

●

Chaque exemplaire de livre, CD ou DVD possède un numéro d’exemplaire, une date d’achat, un état disponible  ou non, un prix d’achat, un état général (bon, dégradé…). 

●

Un média possède un numéro (N° ISBN pour les livres) et un titre. 

●

Un média appartient à un type (CD, Livre, DVD). 

●

Un média appartient à une catégorie possédant un code et un libellé (Science Fiction, Rap…). 

●

Un  emprunt  effectué  par  un  adhérent  possède  une  date  d’emprunt,  une  date  de  retour  prévue,  la  date  de  retour effective de chaque article et est constitué de 1 ou plusieurs médias (nombre de CD, nombre de livres et  nombre de DVD). 

Quelles sont les données immédiatement identifiables comme identifiant ?  Elles nous ont été indiquées par le texte : le numéro adhérent, le code type adhésion, le numéro exemplaire, le numéro  de média, le code catégorie de média, le numéro de l’emprunt et le code type de média.  Les autres données sont, à ce stade, signalétiques. 

- 2-

© ENI Editions - All rigths reserved

  3) La Matrice des Dépendances Fonctionnelles  Nous conservons en colonne, les données de catégorie Identifiant. 

© ENI Editions - All rigths reserved

- 3-

  Quelles sont les dépendances fonctionnelles ?  Les données identifiant sont des données source de DF.  Nous allons chercher pour chacune, les données cible de DF.  Une valeur de numéro adhérent (NUADH) détermine une et une seule valeur de :  ●

Nom de l’adhérent (NOADH), 

●

Prénom de l’adhérent (PNADH), 

●

Date de naissance (DNADH). 

Une valeur de type adhésion (TYADH) détermine une et une seule valeur de :  ●

Libellé de l’adhésion (LIBADH), 

●

Nombre de livres autorisés (NBLIV), 

●

Nombre de CD autorisés (NBCD), 

●

Nombre de DVD autorisés (NBDVD), 

●

Tarif de l’adhésion adulte (TADHA), 

●

Tarif de l’adhésion enfant (TADHE). 

Une valeur de numéro exemplaire (NUEXE) détermine une et une seule valeur de :  ●

- 4-

État de l’exemplaire (ETEXE), 

© ENI Editions - All rigths reserved

●

Disponibilité de l’exemplaire (DIEXE) 

●

Date d’achat de l‘exemplaire (DATACH) 

●

Prix d’achat (PEXE), 

●

Code du média (COMED) (un exemplaire concerne un et un seul media). 

Une valeur de catégorie média (CAMED) détermine une et une seule valeur de :  ●

Libellé de la catégorie du média (LIBCAM) (SF, Comédie…). 

Une valeur de type média (TYPMED) détermine une et une seule valeur de :  ●

Libellé du type du média (LIBTM) (CD, DVD, Livre). 

Une valeur de code média (COMED) détermine une et une seule valeur de :  ●

Titre (TITMED) 

●

Catégorie du media (CAMED) (un média est soit de type Rap, Comédie…). 

●

Type du media (TYPMED) (un média est soit un livre OU un Cd OU un DVD). 

Une valeur de numéro emprunt (NUEMP) détermine une et une seule valeur de :  ●

Date de l’emprunt (DATEMP), 

●

Date de retour prévue (DRPEMP), 

●

Nombre de livres empruntés (NBLIVE), 

●

Nombre de CD empruntés (NBCDE), 

●

Nombre de DVD empruntés (NBDVDE) 

●

Numéro adhérent (NUADH) (un emprunt concerne un et un seul adhérent). 

Nous enrichissons la MDF avec ces informations : 

© ENI Editions - All rigths reserved

- 5-

  Nous constatons que certaines données non­identifiantes ont une valorisation à 0 :  ●

Année de l’adhésion (ANADH), 

●

Date d’adhésion (DATADH), 

●

Date de règlement de l’adhésion (DATREG), 

●

Date du retour effectif de l’exemplaire (DREEMP). 

La date d’adhésion d’un adhérent est déterminée d’une manière unique par le numéro adhérent et le type d’adhésion  et son année d’adhésion.  La date de règlement de l’adhésion d’un adhérent est déterminée d’une manière unique par le numéro adhérent et le  type d’adhésion et son année d’adhésion.  La  date  de  retour  effectif  d’un  exemplaire  est  déterminée  par  la  connaissance  du  numéro  de  l’emprunt  auquel  il  appartenait et le numéro de l’exemplaire.  Nous enrichissons une nouvelle fois la MDF : 

- 6-

© ENI Editions - All rigths reserved

  La donnée ANADH est valorisée à zéro car elle fait uniquement partie d’une donnée source complexe de DF.  La nouvelle donnée 33 est représentative du numéro d’inscription qui sera reportée sur la carte d’adhésion.  En effet, les règles de gestion nous ont indiqué qu’à chaque adhésion annuelle, l’adhérent reçoit un nouveau numéro  d’inscription.  3) Le schéma Entités­Associations  Les règles du passage de la MDF au schéma entités­associations sont les suivantes :  ●

●

●

1 ère  étape :  Il  faut  d’abord  considérer  les  données  source  élémentaires.  L’ensemble  constitué  d’une  donnée  source  élémentaire et  de  ses  données  cible  représente  une entité.  La  donnée  source  est  l’identifiant  de  cette  entité. Les autres données cible constituent les propriétés de cette entité.  2 ème   étape :  Il  faut  ensuite  examiner  les  données  source  issues  de  rapprochement  de  données  source  élémentaires,  nous  les  appellerons  données  source  complexes.  L’ensemble  constitué  d’une  donnée  source  complexe  et  de  ses  données  cible  représente  une  association,  et  plus  particulièrement  une  CIM.  La  donnée  source complexe est l’identifiant de cette association. Les autres données cible constituent les propriétés de  cette association.  3 ème   étape :  Il  faut  enfin  reprendre  les  règles  de  gestion  de  la  MOA  pour  compléter  le  schéma  avec  les  associations simples et toutes les cardinalités. 

Nous avons 6 données source élémentaires, nous obtenons 6 entités avec leur identifiant souligné :  ●

ADHERENT (NUADH, NOADH, PNADH, DNADH) 

●

TYPE ADHESION (TYADH, LIBADH, NBLIV, NBCD, NBDVD, TADHA, TADHE) 

●

MEDIA (COMED, TITMED, CAMED, TYPMED) 

●

EXEMPLAIRE(NUEXE, ETEXE, DIEXE, DATACH, PEXE, COMED) 

© ENI Editions - All rigths reserved

- 7-

●

CATEGORIE MEDIA (CAMED, LIBCAM) 

●

TYPE MEDIA (TYPMED, LIBTM) 

●

EMPRUNT(NUEMP, DRPEMP, DATEMP, NUADH) 

Nous avons 2 données source complexes, nous obtenons 2 CIM avec leur identifiant souligné :  ●

MEDIA EMPRUNTE (NUEMP, NUEXE, DREEMP) 

●

ADHESION (NUADH, TYADH, ANADH, DATADH, DATREG) 

Nous pouvons représenter le schéma entités­associations sans les cardinalités : 

  Les règles de gestion de ce SI vont nous permettre de déterminer les cardinalités de chacune des entités par rapport à  la ou les association(s) à laquelle ou auxquelles, elle participe.  Une occurrence d’adhérent peut posséder au moins une adhésion et au plus n, s’il en prend chaque année.  Un type d’adhésion peut concerner 1 adhésion au minimum et n adhésions au maximum.  Un emprunt concerne un et un seul client.  Un client est concerné par 0 ou plusieurs emprunts.  Un emprunt concerne 1 à n exemplaires.  Un exemplaire est concerné par aucun ou plusieurs emprunts.  Un média est défini par une et une seule catégorie (SF, Rap, Comédie…).  Une catégorie concerne de 1 à n média.  Un média est soit un livre, soit un CD ou soit un DVD.  Un type de média concerne de 1 à n articles. 

- 8-

© ENI Editions - All rigths reserved

Un média comporte de 1 à n exemplaires.  Un exemplaire d’un média concerne un et un seul média.  Le schéma entités­associations définitif est le suivant : 

  Les clés étrangères en italique sont liées à la traduction des cardinalités sur le schéma entités­associations (cf. chapitre  Modélisation ­ Les modèles Merise ­ Modèle Logique de Données).  5) Décrire les relations de la base de données relationnelles du futur SI  Nous reprenons le tableau vu dans le chapitre Introduction à l’algèbre relationnelle : 

  En repartant de la MDF, nous pouvons décrire les 8 relations de la base de données relationnelle :  ●

ADHERENT  

●

TYPE ADHESION  

© ENI Editions - All rigths reserved

- 9-

●

MEDIA  

●

EXEMPLAIRE  

●

CATEGORIE MEDIA  

●

TYPE MEDIA  

●

EMPRUNT  

●

MEDIA EMPRUNTE  

●

ADHESION  

6) En utilisant des opérateurs d’algèbre relationnelle, répondre aux interrogations suivantes :  a) Quels sont les libellés possibles pour les médias?  La relation résultant CATPOS sera issue d’une projection sur l’attribut LIBCAM de la relation catégorie.  CATPOS = proj (CATEGORIE, LIBCAM) = ∏ LIBCAM (CATEGORIE).  b) Quels sont les livres (N° et titre) qui n’ont aucun exemplaire de disponible ?  Nous appellerons la relation résultante NONDISPO.  Nous recherchons un média qui soit un livre et qui a tous les exemplaires dans un état emprunté.  Nous devons extraire d’abord les média qui sont des livres : jointure naturelle entre média et type de média sur LIBTM =  ‘Livre’ ; d’où R1 = MEDIA ⊳⊲ ( σ LIBTM = ‘Livre’ (TYPE ))  Puis  nous  devons  extraire  tous  les  exemplaires  qui  sont  liés  à  ces  livres  (jointure  naturelle  sur  COMED) ;  d’où  R2  =   EXEMPLAIRE ⊳⊲ R1  Puis  nous  devons  extraire  les  tuples  exemplaires  pour  lesquels  l’attribut  état  est  ‘disponible’  ;  d’où  R3  =   σ  ETEXE  =   ‘Disponible’ (R2)  Puis, nous n’en extrayons que les N° media correspondants ; d’où R4 = ∏ COMED (R3)  En parallèle, nous faisons une projection sur N° media des exemplaires qui sont liés aux livres ; d’où R5 = ∏ COMED (R1)  Puis, nous faisons la différence R5 (tous les N° de media qui sont des livres ) ­ R4 (Tous les N° de media qui sont des  livres dont au moins un des exemplaires est ‘disponible’) pour conserver les N° des livres qui ont tous les exemplaires à  l’état ‘emprunté’.  NONDISPO = R5 ­ R4.  c) Quels sont les media (Numéro et code type) proposés par la bibliothèque pour "Le Comte de Monte­Christo" ?  Nous recherchons d’abord les médias qui ont un titre TITMED = ‘Le Comte de Monte­Christo’. (sélection)  Puis, sur cette relation intermédiaire, nous allons faire une projection sur le numéro de média (COMED) et le code type  (TYPMED) ; d’où R = ∏ COMED, TYPMED[σ TITMED = ‘Le Comte de Monte­Christo’ (MEDIA)]  d) Quels sont les media (Numéro et libellé du type de média) proposés par la bibliothèque pour « Le Comte de Monte­ Christo ».  Nous recherchons d’abord les médias qui ont un titre TITMED = ‘Le Comte de Monte­Christo’. (sélection)  Puis, nous allons faire, sur cette relation intermédiaire, une jointure naturelle avec TYPE MEDIA pour récupérer le libellé  du type de média.  Puis, sur cette dernière relation intermédiaire, nous allons faire une projection sur le numéro de média (COMED) et le  libellé type media (LIBTM).  D’où R = ∏ COMED, LIBTM[(TYPE MEDIA ⊳⊲ ( σ TITMED = ‘Le Comte de Monte­Christo’ (MEDIA))]  e) Quels sont les titres des livres dont le prix d’achat d’un de ses exemplaires est supérieur à 25 € ? Nous savons que le  TYPMED des livres est égal à ‘1’.  Il faut d’abord sélectionner les COMED des livres qui ont le TYPMED = ‘1’.  Puis, sur cette relation intermédiaire, il faudra effectuer une jointure naturelle avec EXEMPLAIRE sur le numéro de media  (COMED).  Puis, sur cette relation intermédiaire, il faudra effectuer une sélection sur les tuples pour lesquels le prix d’achat PEXE >  - 10 -

© ENI Editions - All rigths reserved

25.  Enfin, sur cette relation intermédiaire, il faudra faire une projection sur l’attribut titre TITMED.  D’où R = ∏ TITMED(σ PEXE > 25 (EXEMPLAIRE ⊳⊲ ( σ TYPMED = ‘1’ (MEDIA)))).  L’arbre algébrique correspondant est le suivant : 

  f) Quels sont les adhérents qui n’ont pas encore effectué d’emprunt au 14/12/2008 ?  Nous sélectionnons, dans la relation EMPRUNT, tous les emprunts dont DATEMP < 14/12/2008.  Puis,  nous  faisons  une  projection  sur  la  relation  résultante  sur  l’attribut  N°adhérent.  Nous  avons  donc,  tous  les  adhérents ayant fait des emprunts au 14/12/2008, dans la nouvelle relation résultante.  Nous allons en faire la différence de la projection sur NUADH d’ADHERENT, pour ne conserver que les adhérents n’ayant  pas fait d’emprunt au 14/12/2008.  R = ∏ NUADH( ADHERENT) ­ (∏ NUADH( σ DATEMP < ‘14/12/2008’(EMPRUNT))).  g) Quelles sont les adhésions qui ont été réglées le jour même de l’adhésion ?  Nous  sélectionnons  les  tuples  de  la  relation  ADHESION  pour  lesquels  DATREG  (date  de  règlement)  =   DATADH  (date  adhésion).  R = ( σ DATADH = DATREG (ADHESION)). 

© ENI Editions - All rigths reserved

- 11 -

Glossaire  Acteur externe   Entité externe au SI qui échange des flux avec celui­ci (et, au travers de celui­ci, aux acteurs internes).  Acteur interne   Entité interne au SI qui échange des flux avec d’autres acteurs externes ou internes.  Activités   Une activité appartenant à un domaine est constituée de 1 à n opérations élémentaires.  Association   C’est  un  lien  unissant  2  ou  n  entités  dans  le  schéma  entités­associations.  Une  association  peut  être  porteuse  de  données. Elle est aussi appelée relation (nous parlerons alors d’un schéma entités­relations).  Base de données relationnelle   Ensemble exhaustif et cohérent de schémas de relation.  Besoin des utilisateurs   Attentes  des  utilisateurs  en  termes  de  fonctionnalités,  traitements  et  informations  gérés  par  le  futur  Système  d’Information.  Cahier des charges   Ce  document  décrit  les  besoins  des  futurs  utilisateurs  du  Système  d’Information,  sur  les  domaines  fonctionnels,  organisationnels, ergonomiques et aussi de la sécurité.  Cardinalités (minimum, maximum)   Nombre de fois minimum et maximum qu’une occurrence d’une entité peut participer à une association.  Clé de relation   Une  clé  de  relation  est  un  attribut  ou  une  composition  minimale  d’attributs  dont  chacune  des  valeurs  permet  de  déterminer, d’une manière unique, un tuple de la relation.  DatawareHouse   "Un Datawarehouse est une collection de données orientées sujet, intégrées, non volatiles, organisées pour la prise  de décision." Bill Inmon  DF   Deux données A et B sont en Dépendance Fonctionnelle (DF), si la connaissance de la valeur de A permet d’identifier  une et une seule valeur de B.  DM   Dépendance Multivaluée dont la définition est :  Soit une relation R(X,Y,Z),  Xà  à  Y (X multi­détermine Y) < = = > ∀ la valeur prise par X,   ∃ un ensemble de valeurs de Y : Ey 

© ENI Editions - All rigths reserved

- 1-

et  ∃ un ensemble de valeurs de Z : Ez  et  Ey ∩ Ez = ∅ (ensemble vide)  DMNT   Dépendance Multivaluée Non­triviale dont la définition est :  La DM X à  à  Y de la relation R est une DM Non­Triviale si et seulement   ­ Si X n’est pas un sous­ensemble de Y  ET  ­ Si X ∪ Y ≠ R.  DMT   Dépendance Multivaluée Triviale dont la définition est :  La DM X à  à  Y de la relation R est une DM Triviale si et seulement   ­ Si X est un sous­ensemble de Y  OU  ­ Si X ∪ Y = R.  Dictionnaire de Données   Les données du SI sont présentées sous forme d’un tableau dont chaque ligne représentera une  donnée et chaque  colonne, une caractéristique de la donnée.  Domaine  Ensemble de valeurs.  Entité   Représentation d’un objet du monde réel.  Flux   Flux  d’informations  en  entrée  (coordonnées  clients,…),  intermédiaires  (volume  des  déchets…),  en  sortie  (prix  de  vente…) d’un Système d’Information.  Identifiant   Propriété particulière d’une entité qui permet d’identitifier chaque occurrence d’une manière unique.  LDD   Langage de Description des Données d’une Base de Données relationnelle (create, grant…)  LMD   Langage de Manipulation des Données d’une Base de Données relationnelle (select, update…).  Matrice des Dépendances Fonctionnelles   Les  en­têtes  de  colonne  représentent  les  sources  de  Dépendance  Fonctionnelle  (DF),  les  en­têtes  de  ligne  représentent les cibles de DF.  MOA   - 2-

© ENI Editions - All rigths reserved

Maîtrise d’OuvrAge.  Les  (futurs)  utilisateurs  du  Système  d’Information sont appelés MOA, car ils sont commanditaires  des travaux informatiques. Leur demande de travaux s’effectue via le cahier des charges.  MOE   Maîtrise d’Œuvre. La MOE, à partir du moment où elle accepte le contenu du cahier des charges de la MOA, va exécuter  les travaux (développement informatique). Le cahier des charges est considéré comme un contrat qui lie la MOA et la  MOE.  Modèle   Un  modèle  est  une  représentation  schématique  de  la  réalité  qui  facilite  son  appréhension,  que  ce  soit  par  des  personnes initiées ou non.  MCD   Dans Merise, Modèle Conceptuel des Données.  MCT   Dans Merise, Modèle Conceptuel desTraitements.  MDF   Matrice  des  Dépendances  Fonctionnelles  d’un  SI.  Matrice  recensant  toutes  les  données  d’un SI et leurs relations via  des dépendances fonctionnelles. Cette matrice permet de déterminer les données source de DF et les données cible de  DF.  MLD   Dans Merise, Modèle Logique des Données.  MLT   Dans Merise, Modèle Logique des Traitements.  MOD  Dans Merise, Modèle Organisationnel des Données.  MOT  Dans Merise, Modèle Organisationnel des Traitements.  MPD  Dans Merise, Modèle Physique des Données.  MPT  Dans Merise, Modèle Physique des Traitements.  Occurrence (d’une entité)    Une représentation concrète (valorisée) d’une entité.  Opération Elémentaire   C’est une suite chronologique de tâches qui s’exécutent sans interruption.  Produit cartésien   Le produit cartésien de n domaines D1, D2,… Dn est l’ensemble des n_uplets  tel que vDi appartienne  © ENI Editions - All rigths reserved

- 3-

à Di. Ce produit cartésien est noté D1xD2x…Dn.  Relation   Une relation est un sous­ensemble du produit cartésien de n domaines (n>0). Une relation est un ensemble de tuples.  SAA ­ Schéma d’Architecture Applicative   Représentation graphique des grandes fonctionnalités englobées dans le SI.  SAT ­ Schéma d’Architecture Technique   Représentation graphique des éléments matériels et briques logicielles du SI.  SGBDR   Système de Gestion de Bases de Données Relationnelles : Oracle, DB2 d’IBM…  SI   Système d’Information.  Traitement en Temps Différé   Aussi  appelé  Batch,  traitement  informatique  qui  est  planifié  (par  exemple,  sauvegarde  et  duplication  d’une  base  de  données la nuit).  Traitement en Temps Réel   Aussi  appelé  TP  (Transactionnel  Process),  traitement  informatique  qui  met  à  jour  le  Système  d’Information  immédiatement.  Tuple   Un n­uplet issu d’un produit cartésien de n domaines est un tuple. 

- 4-

© ENI Editions - All rigths reserved