Algèbre relationnelle Guide de conception d'une base de données
Michelle CLOUSE
Résumé Ce livre sur l’algèbre relat...
46 downloads
559 Views
7MB Size
Report
This content was uploaded by our users and we assume good faith they have the permission to share this book. If you own the copyright to this book and it is wrongfully on our website, we offer a simple DMCA procedure to remove your content from our site. Start by pressing the button below!
Report copyright / DMCA form
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 ellemê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 ellemê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 noninformaticiens 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.
●
Celuici 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 cellesci à 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 sousdomaines 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 parleton 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 JeanLouis 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 euxmê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 celuici fonctionnera. Il faut aussi que les interrelations 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 heurelà. 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 noninformaticiens, 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 nonredondance 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 estelle 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 doitfaire 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 soustraitance, 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 : ontelles le même format ? Pour un même client, le code estil identique au numéro de client ? Estce 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 viceversa 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 celleci 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 cellesci 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 yatil de Durand en France ?
●
Combien connaissezvous 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 (estce 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 adresseligne1, d’une adresseligne2, d’une adresseligne3, d’une adresseligne4, d’une adresseligne5, 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 entêtes de colonne représentent les sources de Dépendance Fonctionnelle (DF) ;
●
Les entê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 avonsnous 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 ellemê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, peuton 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’entê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. At 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 weekend 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 fautil é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 ellemê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 celleci, 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étonsle, 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 ●
Yatil 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. ●
Yatil 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 vautil mieux perdre : de la place mémoire ou du temps de calcul ? La réponse est à faire au cas par cas, suivant le contexte.
●
Yatil des données homonymes ? Non.
●
Les données sontelles 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 sontelles 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 entê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 pouvonsnous dire de cette matrice ? ●
Il existe des données, nonidentifiantes, 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. ●
Estce 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 : COCLITYPRETDPRETS. ●
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 JeanLouis 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 cellesci 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 analystesprogrammeurs, 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 weekend ?...), 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 celuici. 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 évoluentelles ? 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. Celuici 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 ceuxci.
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’estce 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 ceuxci 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 sontils 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 celleci (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’essuieglace est un acteur externe. L’atelier de montage des essuieglaces 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’essuieglaces,
●
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’essuieglaces 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’essuieglaces.
Combien yatil 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’essuieglaces 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 vaton 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ésassociations (ou appelé aussi schéma entitésrelations). 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 ellesmê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ù, cidessous, 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 peutelle 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 à celleci. 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 allonsnous 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ésassociations ? 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 noncadres). 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ésassociations) 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 clientserveur, 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ésassociations). Il est possible, à ce stade, d’obtenir plusieurs schémas entitésassociations : 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. Ceuxci 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 resteronsnous 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ésassociations 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ésassociations (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 naire), 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 (COEMPNUFIL). 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ésAssociations 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ésassociations 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ésAssociations (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 celuici. Exemple 1 Reprenons la description de la table Employé vue précédemment. Le MLD de cette table est le suivant :
Rappelonsnous 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 HommeMachine (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ésassociations 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ésassociations 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 weekend 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ésassociations
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étonsle avec les cardinalités liées au règles de gestion. Un train peut circuler tous les jours ou uniquement le weekend 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 celuici 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 sousensemble 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 nuplet 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 :, , , , , . Exemple 2 : Si nous considérons le tuple suivant : 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 sousensemble 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 parleton de sousensemble 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 sousensemble 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 : 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 sousensemble 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é (monoattribut 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. Estce 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 nomville 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 nomville de naissanceville de résidence, donc celleci non plus, n’est pas une clé candidate. Le même raisonnement peut être appliqué à la combinaison nomville de naissanceville de résidencedate de naissance, donc celleci 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° produitN°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ésassociations 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ésassociations, 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ésrelations (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 (monoattribut ou multiattribut). 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ésrelations 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ésassociations 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 nuplets ou tuples,
●
la relation : sousensemble 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ésassociations. À 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 weekend 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.
Peuton 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.
Peuton 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. Estce que les tables (et leurs clés) construites en passant par l’étape du schéma entitésassociations 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 VoitureN° SIREN) pour Est révisée,
●
COVOIT_NUCLI ( Code VoitureN°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ésassociations 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 feriezvous 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 Rappelonsnous 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 fautil é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 NOCLIPNCLI.
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’appelleton 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 : . 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 . 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 NULIVNUAN.
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 sousensemble du produit cartésien de la relation LECTEUR et de la relation ANNEX (de la bibliothèque). Comment allonsnous 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étajointure 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 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 thetajointure 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.
Rappelonsnous 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’équijointure Définition L’équijointure 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’équijointure 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’équijointure 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’équijointure 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’équijointure (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’équijointure demandée. Comme précédemment, par l’opération d’équijointure, 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 cellesci, une équijointure 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 équijointure 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 équijointure 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’équijointure 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 (thetajointure, équijointure, 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 ceuxci 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 celleci. 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 ? Fautil 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. Celleci 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 ontelles é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 cellesci. 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. Celuici 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 cellesci. 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