algèbre relationnelle - guide pratique de conception d'une base de données relationnelle...

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.

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

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

Michelle CLOUSE

Résumé

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.

- 1 -© ENI Editions - All rigths reserved

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


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 noninformaticiens. 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.


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).


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.


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…


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 :


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.


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 ?


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.


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.


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.


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.


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 (soustraitance, 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.


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 plusvalues 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…

Plusvalue : 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.


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.


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’ :

Code produit (XXXXX....)


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.


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


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


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 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


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


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 :


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 :


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. Atelle 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 :

Le Total est à zéro


Nous obtenons trois informations : client, train générique et train circulant.

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

Le Total est supérieur à 1 et la donnée n’est pas un identifiant


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.


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.


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 compteespè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.


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 :

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.

Dictionnaire des données

Matrice des dépendances fonctionnelles


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 :


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 :


Montant du prêt, durée, taux annuel, assurance facultative, date du 1er 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 1er 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 1er 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 :


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.


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.


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 :


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 :


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,


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


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 :


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 :


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.


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.


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 :

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.


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 :


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 :


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.


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 :

un nom (obligatoirement) ;


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 :


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).

Considérons les valeurs de la cardinalité maximum.


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.

Énoncé

Supposons que dans notre SI, nous ayons distingué les entités client et contrat.

Exercice


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 :


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.

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.



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

Règles de passage de la Matrice des Dépendances Fonctionnelles aux entités et associations


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.

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.


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.


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


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 :


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.


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é.


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


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


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) :


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.


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.


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…


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…


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.


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

2. Solution

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.

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.


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. 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.


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)

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 :


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.


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 sousensemble 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 <vD1, vD2,…vDn> 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 :<0, rouge>, <0, jaune>, <0,bleu>, <1, rouge>, <1, jaune>, <1,bleu>.

Exemple 2 :

Si nous considérons le tuple suivant : < 101, BRANY, POITIERS, 28/10/1990>

Ce tuple contient des valeurs issues des domaines, N° élève, Nom, Ville, Date, suivants :


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 : <101, BRANY, LAVAL, POITIERS, 28/10/1990, 25/06/2006>

Ce tuple contient des valeurs issues des domaines, N° élève, Nom, Ville, Date, suivants :


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.


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.

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.

Clés candidates et clé primaire


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 :


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.


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.

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é.

À 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.

Les tables issues de la MDF et du schéma entitésassociations

Les relations issues directement de la MDF et de l’algèbre relationnelle


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é.

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.

Conclusion


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.


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.


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.

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 :

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

MDF et schéma entitésrelations


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.

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>. 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 : <COEMP, NOMEMP, DNEMP>.

Un employé est caractérisé par son code, son nom et sa date de naissance.

La relation Filiale <NUFIL, VILFIL>. NUFIL, VILFIL sont des domaines (ensemble de valeurs) et représentent chacun un

MDF et algèbre relationnelle


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 : <NUFIL, VILFIL>.

Une filiale est caractérisée par son numéro et sa localisation.

La relation Contrat de travail <NUFIL, COEMP, DADEB, DAFIN>. 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 : <NUFIL, COEMP, DADEB, DAFIN>.

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é <COEMP, NOMEMP, DNEMP>.

Filiale <NUFIL, VILFIL>.

Contrat de travail <NUFIL, COEMP, DADEB, DAFIN>.

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.


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).


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 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…



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 ?


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<COTRIN, HDTRIN, HATRIN, TYTRIN>

Calendrier<DTRIN, TYDATE>

Train circulant<COTRIN,DTRIN,NBVOY>

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 ?


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<COTRIN, HDTRIN, HATRIN, TYTRIN>

Calendrier<DTRIN, TYDATE>

Trains circulants<COTRIN,DTRIN,NBVOY>.

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 :



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


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 :


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 <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 et KMEFF>.

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 :

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 ?


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>.

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).


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).


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.


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.


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.

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

Notation


Exemple1 :

Considérons la relation CLIENT<NUCLI, NOCLI, PNCLI, DNCLI>.

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 :


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 :




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 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 :


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 :





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 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.


À 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 <opérateur> <valeur> (R) ∀i ∈ E (entiers)

Ou R’ = Restrict (R, Ai <opérateur> <valeur>)

Ou R’ = R[Ai <opérateur> <valeur>]

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 :





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 <NUCLI, NOCLI, PNCLI, DNCLI>. 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 :





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’ )


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 <NUCLI, NOCLI, PNCLI, DNCLI>. 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 :





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’ )


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 <NUCLI, NOCLI, PNCLI, DNCLI>. 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é



Quelle est la relation résultante de la sélection : ne conserver que les clients dont le nom est DUMAS ?

La nouvelle relation CLIENTDUMAS<NUCLI, NOCLI, PNCLI, DNCLI> 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’.

Réponse


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 <NULIV, TITLIV, NOAUT>, où :

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

TITLIV : Titre du livre.

NOAUT : Nom de l’auteur.

La relation LIVREB2 a pour schéma <NULIV, TITLIV, NOAUT, PNAUT>, où :





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.









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 <NULIV, TITLIV,NOAUT> et ne conservera que les tuples communs à LIVREB1 et LIVREB2.

Considérons LIVREB1 et LIVREB2 en extension :


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

En repartant des données des relations précédentes LIVRE1 et LIVRE2, construire la relation LIVRE2 ∩ LIVRE1.

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.


Énoncé

Solution


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 <NULIV, TITLIV, NOAUT>.

La relation LIVREB2 a pour schéma <NULIV, TITLIV, NOAUT, PNAUT>.

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, TITLIV, NOAUT>.



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 <NULIV, TITLIV,NOAUT> 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.



Nous allons visualiser cette union par étapes :

1) La relation résultante UNIONLIVRE aura pour schéma <NULIV, TITLIV, NOAUT>.

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 :


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

En repartant des données des relations précédentes LIVRE1 et LIVRE2, construire la relation LIVRE2 ∪ LIVRE1.

Nous obtenons :

Énoncé

Solution


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.


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 <NULIV, TITLIV, NOAUT>, où :




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


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 <NULIV, TITLIV,NOAUT> et regroupera tous les tuples appartenant à LIVREB1 et n’appartenant pas à LIVREB2.


Nous allons visualiser cette différence par étapes :

1) La relation résultante DIFLIVRE aura pour schéma <NULIV, TITLIV, NOAUT>.

2) Elle contiendra tous les tuples appartenant à LIVREB1.

Nous obtenons :


3) Puis, il faut ensuite éliminer de cet ensemble de tuples, les tuples qui appartiendraient aussi à B2.

Dans notre exemple, il n’y en a qu’un : <102, Le soir des fourmiz,Bertrand>.

Nous obtenons :

c. Exercice

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 ?

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 :

Énoncé

Solution


b. Exemples

Exemple 1 :

Supposons que le SI d’une grande bibliothèque possède, entre autres, deux relations :

LIVRE ayant pour schéma <NULIV, TITLIV, NBPAGE> qui recense les livres de la bibliothèque, où :



NBPAGE : Nombre de pages.

La relation LIVRE en extension se présente ainsi :

ANNEX ayant pour schéma <NUAN, VILAN>, 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.


Donc, VILLIB a pour schéma < NULIV, TITLIV, NBPAGE, NUAN, VILAN>. Cette relation aura une clé primaire différente de celle de la relation LIVRE et de celle de la relation ANNEX, car aucune d’elle prise individuellement ne pourra assurer l’unicité de chaque tuple de VILLIB. Dans notre exemple, une clé candidate pourrait être, par exemple, la composition des attributs 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 <NULEC, NOLEC, NUANL> recensant les lecteurs de la bibliothèque, où :

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

NOLEC : Nom du lecteur.

NUANL : Numéro annexe.


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

VILLEC = LECTEUR * ANNEX.


Le schéma relationnel de VILLEC est le suivant : <NULEC, NOLEC, NUANL, NUAN, VILAN>.

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 sousensemble 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 ?


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

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 = join (R1, R2, A’i <opérateur> A’’j) ∀i,j ∈ E (entiers)

Ou R = R1 ⊲⊲⊲⊲⊳⊳⊳⊳ R2 A’i <opérateur> 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.

Définition


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 <NULIV, TITLIV, NBPAGE> et ANNEX<NUAN, VILAN>.



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< NULIV, TITLIV, NBPAGE, NUAN, VILAN>

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) :

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 :


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<opérateur> <valeur> (R) ∀i ∈ E (entiers)


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 <opérateur> <A’j> (RXR’).

<A’j> 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

L’équijointure est une jointure thêta où l’opérateur de rapprochement est une égalité (=).

On notera :

R = join(R1, R2, A’i =A’’j) ∀i,j ∈ E (entiers)

Ou R = R1 ⊲⊲⊲⊲⊳⊳⊳⊳ R2 A’i = A’’j

La modélisation graphique de l’équijointure est la suivante :

Exemple 1 :

Reprenons l’exemple précédent de la bibliothèque dont le SI possède, entre autres, deux relations : LIVRE <NULIV, TITLIV, NBPAGE> et ANNEX<NUAN, VILAN>.



Définition

Exemples


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 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<NULIV, TITLIV, NBPAGE, NUAN, VILAN>


1) D’abord, un produit cartésien :

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


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 <NULIV, TITLIV, NOAUT, NUANL> et ANNEX <NUANA, VILAN>.

L’attribut NUANL représente le Numéro d’annexe auquel appartient le livre.



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 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 <NULIV, TITLIV, NOAUT, NUANL, NUANA, VILAN>


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 :


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

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.

Exemple 1 :

Reprenons l’exemple de la bibliothèque précédente avec les deux relations : LIVRE <NULIV, TITLIV, NOAUT, NUANL> et ANNEX <NUANA, VILAN>.

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 <NULIV, TITLIV, NOAUT, NUAN> et ANNEX <NUAN, VILAN>.


Définition

Exemples



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.


Nous allons passer par plusieurs étapes pour obtenir la relation résultante :

1) D’abord, le produit cartésien des deux relations :


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


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 = ext-join (R1, R2, A’i <opérateur> A’’j) ∀i,j ∈ E (entiers)

Ou R = R1 ⊳⊲ R2 . A’i <opérateur> A’’j


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.


Exemple

Reprenons le SI d’une bibliothèque avec les deux relations suivantes : LIVRE <NULIV, TITLIV, NOAUT, NUAN> et ANNEX <NUAN, VILAN>.



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.

Définition


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<NULIV, TITLIV, NOAUT, NUAN, VILAN>


Nous allons passer par plusieurs étapes pour obtenir la relation résultante.


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".

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


Nous allons marquer les attributs de LIVRE, qui lui ont été liés par le produit cartésien, par le signe distinctif "valeur nulle".


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 :


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

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 = Lext-join (R1, R2, A’i <opérateur> A’’j) ∀i,j ∈ E (entiers)

Ou R = R1 ⊳⊳⊳⊳⊲⊲⊲⊲ R2 . A’i <opérateur> A’’j


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).


Définition


Exemple




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<NULIV, TITLIV, NOAUT, NUAN, VILAN>







Nous allons marquer les attributs d’ANNEX, qui lui ont été liés par le produit cartésien, par le signe distinctif "valeur nulle".




Nous les supprimons et nous obtenons :

6) Nous supprimons les tuples en doublons :


Et nous obtenons :




Les livres qui n’appartiennent à aucune annexe existante.

c. La jointure externe droite

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 = Rext-join (R1, R2, A’i <opérateur> A’’j)∀i,j ∈ E (entiers)Ou R = R1 ⊳⊳⊳⊳⊲⊲⊲⊲ R2 . A’i <opérateur> A’’j


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).

Définition



Exemple




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<NULIV, TITLIV, NOAUT, NUAN, VILAN>







Nous les éliminons et nous obtenons :




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 :




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.


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.

Exemple 1 :




Nous ne voulons conserver que les titres des livres appartenant à une annexe et le nom de celleci.


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.

Exemples


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.


Elle se présente en extension, ainsi :



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


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 :


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.


Arbre 2


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.


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.


Nous constatons que les relations EXTRACT2 et EXTRACT3 sont identiques.


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<NUCLI, NOCLI, PNCLI, TOTACH>.

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).


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 €.


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 :


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 :


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<NUCLI, NOCLI, PNCLI, TOTACH>.

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).


Les utilisateurs veulent connaître le total des achats effectués par tous les clients.


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 :


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


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.


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.


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.


∏ 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.


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

Il n’y a pas de précision sur les données, donc tous les attributs sont à conserver.

Un ‘chien’ est un ‘canidé’ qui correspond à une valeur de l’attribut ordre. Il va falloir effectuer une sélection (conservation des attributs) avec une condition sur l’attribut ORDRE (pour élimination des tuples n’y satisfaisant pas).

Donc, pour répondre à la question, il faut faire l’opération suivante σ ORDRE = ‘Canidés’ (ANIMAUX).

La relation résultante en extension se présente ainsi :

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

C’est une sélection avec une condition sur l’attribut AGE strictement inférieur à 8 ans.

Pour répondre à cette question, il faut faire l’opération suivante σ AGE <8 (ANIMAUX).

La relation résultante en extension se présente ainsi :

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

Les informations demandées sont l’âge et la race (projection pour éliminer des attributs), donc il faudra effectuer la sélection sur l’ordre avant la projection.

La représentation algébrique de ces opérations est la suivante :


La relation résultat en extension est la suivante :

2. Exercice 2

a. Énoncé

La base de données relationnelle du SI de la clinique vétérinaire BOCHIEN contient, outre la relation précédente ANIMAUX, la relation PROPRIETAIRE, où :

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

NOMP est le nom du propriétaire,

PRENOM est le prénom du propriétaire,

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

La table ANIMAUX recensant les animaux dese propriétaires. La clé primaire CODEP de PROPRIETAIRE lui a été rajoutée en tant que clé étrangère.

Ces deux relations en extension se présentent ainsi :


1) Donner le résultat de la relation suivante :

R = ∏ NOMP, NOM(ANIMAUX ⊳⊲ PROPRIETAIRE)

2) Nous voulons afficher les noms des animaux, les noms de leur propriétaire et leur code dont le code propriétaire existe dans la relation PROPRIETAIRE, tout en conservant les propriétaires n’ayant pas d’animaux.

b. Solution

1) Nous voulons le nom des propriétaires et de leurs animaux.

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

2) Pour répondre à cette demande, nous devons effectuer une jointure externe droite avec une condition d’égalité entre CODEP d’ANIMAUX et CODEP de PROPRIETAIRE.

Nous allons obtenir la relation résultante ANIMAUXJED.



Nous obtenons le résultat suivant :

3. Exercice 3

a. Énoncé

Considérons le SI suivant :

Nous gérons des clients qui achètent des produits vendus par des commerciaux. Si le client a besoin d’un produit et qu’il est démarché par un commercial qui propose ce produit, il lui achète ce produit.

Chaque commercial ne vend pas tous les produits proposés par l’entreprise.

L’informaticien, qui a analysé ces règles de gestion, a construit la relation Achat suivante :

Achat<NUCLI, NUPROD, NUCOM>

L’extension de cette relation est la suivante :


1) Construire R’1 = ∏ NUCLI,NUCOM (ACHAT) ⊳⊲ ∏ NUCLI,NUPROD (ACHAT)

2) Construire R’2 = R’1 ⊳⊲ ∏ NUCOM,NUPROD (ACHAT)

3) R’2 = Achat ?

b. Solution

1) a) Il faut d’abord construire ∏ NUCLI,NUCOM (ACHAT)

En extension, nous obtenons :

b) Puis, il faut construire ∏ NUCLI, NUPROD (ACHAT)



c) Il faut maintenant construire

R’ = ∏ NUCLI,NUCOM (ACHAT) ⊳⊲ ∏ NUCLI,NUPROD (ACHAT)

La jointure se fera sur l’attribut commun NUCLI, avec élimination d’un des 2 attributs NUCLI en doublon.

R’1 en extension :

2) Il faut d’abord construire ∏ NUCOM,NUPROD (ACHAT)



b) Puis, il faut construire :

R’2 = R’1 ⊳⊲ ∏ NUCOM,NUPROD (ACHAT)

C’est une jointure naturelle qui portera sur les 2 attributs communs aux deux relations : NUCOM et NUPROD. Les tuples à conserver des 2 relations sont donc les tuples qui auront des couples de valeurs (valeur de NUCOM, valeur de NUPROD) égaux.

Donc, certains tuples de R’1 ne sont pas à conserver :

Donc nous obtenons R’2 en extension :


3) Nous obtenons bien R’2 = Achat.


Introduction

Dans les chapitres précédents, nous avons vu qu’il était possible de modéliser le monde réel et, en particulier les informations gérées dans un SI, par des relations.

L’ensemble exhaustif et cohérent des relations d’un Système d’Information sert à construire une base de données relationnelle.

L’objectif de ce livre étant de vous apprendre à faire des bases de données relationnelles de qualité, nous avons suivi une méthode que nous considérons comme la plus optimum pour le faire.

Mais cette méthode n’est pas le passage obligatoire ; et un même dictionnaire de données et les mêmes règles de gestion peuvent générer des schémas de relation différents, suivant l’interprétation et l’analyse de l’informaticien. Là où le bât blesse, c’est que la qualité résultante sera aussi de niveau différent.

Aussi, le modèle relationnel est complété par "la théorie de la normalisation". Le but de la normalisation est de créer les relations exhaustives au besoin du SI et ayant le nombre minimum d’attributs nécessaires. Les attributs de chacune des relations doivent aussi avoir une redondance minimale et nécessaire.

Dans ce chapitre, nous détaillerons les critères qui permettent de dire qu’une base est de meilleure qualité qu’une autre et pourquoi une normalisation s’impose.

Puis, nous découvrirons sur quoi repose la théorie de la normalisation (vous comprendrez enfin l’importance de la Matrice des Dépendances Fonctionnelles !) et l’ensemble des formes normales, définies par E. F. Codd, qui permettent de vérifier un schéma de relation ou de l’affiner progressivement pour le normaliser, suivant l’approche utilisée.


La théorie de la normalisation

1. La relation universelle

L’expression des besoins des utilisateurs, recensant les données à gérer dans leur Système d’Information et les règles de gestion à y appliquer, est à l’origine des schémas de relation et de la base de données relationnelle résultante.

Généralement, en partant du dictionnaire des données, il est facile de regrouper les données d’une entité car elle a toujours une existence visible dans la réalité.

Par contre, il n’est pas toujours évident de positionner les données qui semblent dépendre de plusieurs autres données source.

Fautil les regrouper :

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

sous une composition de données source (et donc, sous une association unissant plusieurs entités) ? La composition de ces données source estelle exacte (toutes les données source nécessaires y sontelles ? N’y atil pas une ou n donnée(s) source inutile(s) ?) ?

Ces questions ne sont pas anodines, de leur réponse dépendra la qualité des schémas de relation.

Exemple

Reprenons l’exemple d’une grande entreprise française, fondée il y a 10 ans et comportant des filiales françaises.

L’étude de la gestion du personnel a permis d’apprendre qu’un employé pouvait, durant toute sa vie professionnelle, travailler dans la même filiale ou changer de filiale tous les 3 ans (et en particulier, les cadres y sont obligés). Mais, dans tous les cas, il ne fera qu’une seule période dans chacune des filiales. Sa vie professionnelle est recensée, dans le SI de l’entreprise, avec les dates d’arrivée et de départ dans chacune des filiales dans lesquelles il a travaillé.

Une filiale est constituée d’un directeur, d’un adjoint et d’au moins 10 employés (cadres et noncadres).

Chaque employé est caractérisé par un numéro appelé code employé, qui est unique pour chacun.



Même si les données concernant l’employé (code et nom) avaient été dispersées dans le dictionnaire, nous aurions pu facilement les regrouper sachant que chacune concernait l’employé.

Le même raisonnement est valable pour le regroupement des données de la Filiale (numéro et ville).

Par contre, le positionnement des dates d’arrivée et de départ est plus difficile.


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

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

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

Le passage par la Matrice des Dépendances Fonctionnelles nous a permis de regrouper ces dates sous ce que nous avons appelé des données source complexes et nous avons créé une nouvelle relation. Estce le bon choix ?

N’auraitil pas fallu mettre dans la relation Employé, le N° de filiale, sa date d’arrivée et sa date de départ ?

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

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

En apparence, nous n’avons que des avantages :

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

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

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

Si nous options pour ce dernier choix, nous obtiendrions la relation universelle en intention suivante :

Employé <COEMP, NOEMP, DNEMP, DADEB, DAFIN, NUFIL, VILFIL>.

Les règles de gestion nous permettent de préciser les dépendances des attributs, les uns par rapport aux autres. Ainsi, dans cet exemple, elles précisent qu’un employé n’a qu’un et un seul code employé.

Donc, le code de l’employé détermine d’une manière unique le nom de l’employé.

Regardons un extrait de celleci en extension, la gestion du personnel nous ayant donné des exemples de cadres et de noncadres :

Nous constatons qu’il y a des données redondantes : les employés DAVID et DUPONT apparaissent au moins deux fois dans la table Employé.

La localisation de la filiale 033 y apparaît 3 fois.

Ces redondances entraîneront des contraintes dans l’utilisation habituelle de la base de données.

2. Les problèmes liés à la nonnormalisation


En premier lieu, cette redondance des données induit un volume des tables plus important qu’il ne faudrait, et donc, un coût de stockage plus important.

De plus, la mise à jour d’une donnée ne s’effectuera pas en un minimum d’opérations si celleci est redondante dans une relation (= table).

Exemple :

Considérons la relation universelle Employé précédente.

Pour corriger une erreur de saisie dans la date de naissance de l’employé DUPONT, il faudra modifier tous les tuples concernant Dupont dans la table Employé. Dans cet exemple, il n’y a que 2 tuples, mais si Dupont avait été un cadre qui change de filiale tous les 3 ans, il y aurait beaucoup plus de tuples à mettre à jour.

Or, chacune des opérations a une durée d’exécution, donc plus il y a d’opérations, plus le temps de mise à jour sera important.

De plus, plus il y a de manipulations, plus il y a des risques d’erreur et donc, au final, des risques d’incohérences des données.

En effet, sachant que nous partons toujours d’une base de données où toutes les données sont cohérentes entre elles, nous devons, après avoir terminé toutes les manipulations de données, revenir dans un état tout aussi cohérent. Or, si parmi les n opérations de la mise à jour, il apparaît un problème quelconque (technique…) qui n’en permet pas la bonne fin, nous nous retrouverons avec une base de données dans un état incohérent :

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

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

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

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

a. Les anomalies d’insertion

En créant une nouvelle valeur d’une donnée, concernée par plusieurs tuples, il faudra veiller à ce que la saisie soit correcte dans tous ces tuples.

En effet, dans le cas contraire, cela peut entraîner une anomalie d’insertion qui aura des répercussions dans les recherches ultérieures.

Exemple :

Considérons que l’entreprise ouvre une nouvelle filiale à Nantes. Il y aura plusieurs employés qui seront embauchés ou mutés. Pour chacun des tuples concernant ces employés, la saisie de VILFIL devra contenir exactement les mêmes caractères.

Sinon, pour la même filiale, la table en extension pourrait donner le résultat suivant :

Si le directeur général recherche les noms des employés de la filiale de Nantes, il ne trouvera que M. BOLO.

Par contre, si le directeur général recherche les noms des employés de la filiale de NANTES, il obtiendra les noms de M. MIRO et de M. ONYX.

Le résultat de la recherche n’est pas, donc, pas fiable.


b. Les anomalies de suppression

En supprimant une valeur d’une donnée concernée par plusieurs tuples, il faudra veiller à ne pas générer des incohérences dans les données de la base de données.

Exemple :

Reprenons, la relation en extension initiale :

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

Nous constatons que le calcul de l’ancienneté de l’employé Dupont sera erroné puisque le temps passé à Albi a disparu de la relation.

Nous obtenons une incohérence dans les données de la relation. Cette incohérence induit la nonfiabilité des informations du SI.

c. Les anomalies de modification

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


Exemple :

Reprenons la relation en extension initiale :

Pour corriger une erreur de saisie dans la date de naissance de l’employé DUPONT, il faut modifier tous les tuples concernant Dupont dans la table Employé.

Il peut y avoir une erreur de saisie durant la manipulation et le résultat peut être le suivant :

En finalité, quel est l’âge exact de l’employé Dupont ?

Nous constatons que le calcul pour les droits à la retraite de l’employé Dupont sera erroné.

Nous obtenons une incohérence dans les données de la relation. Cette incohérence induit la nonfiabilité des informations du SI.

3. La normalisation

a. Les objectifs

Nous venons de voir que les conséquences des problèmes, liés à la nonnormalisation des relations d’un SI, sont importantes. À un certain degré, elles peuvent même être une atteinte à la pérennité de l’entreprise qui repose sur ce SI.

Pour éviter ces inconvénients, la solution passe par la normalisation de la base de données relationnelle.

Quel est le but de la normalisation ?

Les objectifs de la normalisation sont les suivants :

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

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


comme clé de relation étrangère).

Ces principes mis en œuvre permettront de construire une base de données :

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

dont la manipulation sera plus facile,

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

b. Les fondements de la normalisation

Nous constatons que le fondement principal de la normalisation est un concept déjà connu : celui de la DF entre attributs.

Dans le chapitre Étude de l’expression des besoins des utilisateurs, nous avions donné la définition suivante pour la DF :


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.


Nos connaissances en algèbre relationnelle nous permettent d’affiner cette définition de la manière suivante :

Soit un schéma de relation décrit par la relation universelle U (A1, A2… An), avec ∀i ∊ E (entiers), Ai étant un attribut dont les valeurs appartiennent à un domaine Di.

On dira que :

∀p, q ∈ E, Aq est fonctionnellement dépendant de Ap si et seulement si pour chaque valeur de Ap correspond une valeur unique de Aq.

On écrira : Ap → Aq.

Dans cette définition, les attributs Ap et Aq peuvent chacun être remplacés par un ensemble d’attributs.

La DF, en normalisation, est une propriété des attributs dans une relation.

La dépendance fonctionnelle entre attributs doit être vraie dans tous les cas. Aussi, la dépendance fonctionnelle entre attributs d’une relation doit être vérifiée pour la relation en intention et non en

extension (qui est une image à un instant t du schéma de la relation).

La Matrice des Dépendances Fonctionnelles, vue dans le chapitre Étude de l’expression des besoins des utilisateurs, pourra être mise en œuvre pour identifier d’une manière exhaustive les DF d’une relation.

La théorie de la DF repose sur des concepts mathématiques et vérifie des propriétés dites axiomes d’Amstrong.

Nous les rappellerons et nous les imagerons par un exemple, mais nous ne les démontrerons pas, car ce n’est pas l’objet de ce livre.

Réflexivité

Soit une base de données décrite par une relation universelle U (A1, A2… An), avec ∀i ∊ E (entiers), Ai étant un attribut dont les valeurs appartiennent à un domaine Di.

∀i ∊ E, Ai → Ai.

Exemple :

Considérons la relation universelle Employé <COEMP, NOEMP, DNEMP DADEB, DAFIN, NUFIL, VILFIL>

Dépendance fonctionnelle

Les axiomes d’Amstrong


La connaissance d’une valeur du code de l’employé (COEMP) ne détermine qu’une et une seule valeur. L’employé n’a qu’un seul code d’employé dans l’entreprise.

La connaissance d’une date de naissance ne détermine qu’une et une seule date.

Même raisonnement pour les attributs.

Augmentation


∀p,q,r ∊ E, si Ap → Aq alors Ap,Ar → Aq,Ar.

Exemple :

Considérons la relation universelle Employé <COEMP, NOEMP, DNEMP, DADEB, DAFIN, NUFIL, VILFIL>.

Les règles de gestion nous permettent de préciser les dépendances des attributs les uns par rapport aux autres. Ainsi, dans cet exemple, elles précisent qu’un employé n’a qu’un et un seul code employé. Donc, le code de l’employé détermine d’une manière unique le nom de l’employé.

Par rapport à la relation en extension qui lui correspond à un instant t :

Nous pouvons donner les exemples suivants de cette DF :

Rajoutons l’information concernant la date de naissance au code employé et au nom de l’employé.

La connaissance du code et de la date de naissance d’un employé détermine toujours, d’une manière unique, son nom et sa date de naissance. En effet, pour un code employé ne correspond qu’un seul nom d’employé et un employé n’a qu’une et une seule date de naissance.

Exemple (par rapport à quelques tuples de la relation en extension) :


Transitivité


∀p,q,r ∊ E, si Ap → Aq et Aq→ Ar alors Ap→ Ar.

Exemple :

Considérons la relation universelle Employé <COEMP, NOEMP, DNEMP, DADEB, DAFIN, NUFI, VILFIL, AGEEMP>.

Les règles de gestion nous permettent de préciser les dépendances des attributs les uns par rapport aux autres. Ainsi, dans cet exemple, elles précisent qu’un employé n’a qu’un et un seul code employé. Donc, le code de l’employé détermine d’une manière unique la date de naissance de l’employé.

Un nouvel attribut AGEEMP a été rajouté dans cette relation. AGEEMP est l’âge de l’employé, calculé par rapport à sa date de naissance et à l’année en cours. Chaque année, à la date anniversaire de l’employé, cette information est mise à jour (annulation et remplacement de l’ancienne valeur par la nouvelle).

Un extrait de la relation en extension pourrait être le suivant en 2008 :

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

COEMP → DNEMP

Et DNEMP → AGEEMP


Suivant le théorème d’Amstrong, nous aurons COEMP → AGEEMP.

L’âge de l’employé est calculé à partir de la date de naissance de celuici. Il est aussi en DF par rapport à la date de naissance et la date naissance est en DF par rapport au code employé.

Donc, pour un code employé nous obtenons une seule date de naissance.

L’âge de l’employé = année en cours année de naissance de l’employé. Ce calcul donnera pendant toute une année le même résultat et dès l’année suivante, à la date anniversaire, il sera remplacé. Donc, un code employé ne déterminera, à tout moment, qu’un seul âge de l’employé.

Donc, COEMP → AGEEMP.

Par rapport aux éléments de la table en extension, nous avons bien en 2008 :

Définition

La décomposition d’une relation R en n relations R1, R2… Rn est dite sans perte si et seulement si R = R1 ⊳⊲ R2 ⊳⊲ … Rn.

Autrement dit, une relation R est décomposée sans perte d’informations si la jointure (naturelle) de toutes de ces relations issues (R1, R2 … Rn) reconstitue une relation de même schéma et régénère exactement les mêmes tuples sans tuple supplémentaire et /ou faux.

Nous verrons plus loin des exemples de relation de décomposition.

La décomposition sans perte


Processus de normalisation

1. Introduction

La normalisation d’une base de données relationnelle concerne l’ensemble de toutes ses relations. Donc, toutes les relations doivent être normalisées.

Pour ce faire, il faudra vérifier individuellement chaque relation. Ceci se fera par un certain nombre d’étapes. Chaque étape correspondant à une graduation du niveau de normalisation. Cette graduation est appelée degré de la forme normale.

E. F. Codd a présenté initialement trois formes normales (1ère, 2ème et 3ème). Il les a complétées dans les années 80 par trois autres formes : la forme de Boyce_Codd (créée en collaboration avec R. Boyce) puis la 4ème et la 5ème forme normale.

Le processus de normalisation part du niveau le plus bas (1ère forme normale).

À chaque étape, il faut vérifier que la relation suit les conditions nécessaires et suffisantes exigées par le niveau de normalisation. Si et seulement si cela est le cas, il est possible de passer au niveau immédiatement supérieur de vérification.

Si la relation que nous étudions ne répond pas aux conditions du degré de forme normale vérifié, il faudra décomposer la relation en 2 ou n relations plus simples qui devront répondre chacune aux exigences de la normalisation. Cette décomposition devra s’effectuer sans perte.

Chacune des relations trouvées devra, à son tour, être vérifiée et il faudra repartir du niveau le plus bas de la normalisation (première forme normale).

Il existe deux approches dans la mise en œuvre de la normalisation d’une base de données.

La première approche consiste, à partir de la relation universelle (composition de tous les attributs strictement nécessaires à la viabilité du SI) pour la décomposer en relations normalisées. C’est une approche de construction de base de données relationnelle.

La deuxième approche est une approche de validation de base de données relationnelle. Dans ce contexte, les relations ont été créées via les phases du dictionnaire de données, matrice des dépendances fonctionnelles, passage de cette matrice aux relations…

Nous allons d’abord définir les différentes formes normales puis nous étudierons, par l’exemple, chacune de ces approches.

2. Les formes normales indispensables à un schéma relationnel normalisé

Chaque degré de forme normale repose sur le concept de DF.

Chaque degré acquis implique que les exigences du ou des degré(s) inférieur(s) soient remplies ainsi que celles exigées à son niveau.

a. La première forme normale (1FN)

Une relation est en première forme normale si, pour chaque tuple de la relation, chaque attribut contient une valeur atomique.

Autrement dit, si l’on considère une relation en extension, cette relation est dite en première forme normale si et seulement à l’intersection d’une colonne (attribut) et d’une ligne (tuple), on ne peut trouver qu’un seul élément.

Exemple 1 :

Considérons la relation Livre<N°livre,Type, Format, Prix>

On dira qu’il y a une valeur atomique pour chaque attribut, si chaque tuple est de la forme (avec possibilité bien sûr de valeurs différentes) :

« 2 », « livre de poche », « 17 », « € 12.50 »

Si pour un N° de livre, il existe, par exemple, plusieurs Formats (livre de poche, édition de luxe,…) , la relation n’est pas en 1FN.

Définition 1


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

Exemple 2 :

Considérons la relation Employé<N°emp, adresse,étatcivil,date entrée>

Si nous avons au moins un tuple de la forme suivante :

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

Attribut zone Etatcivil contenant la valeur «Oiseau, Bel, ornithologiste».

Alors, nous sommes en présence de valeurs nonatomiques. Elles sont dans cet exemple : composées.

En effet, dans le seul attribut adresse, nous avons plusieurs informations : la rue mais aussi le code postal et la ville.

De même, dans l’attribut Etatcivil, nous avons aussi plusieurs informations : le nom, le prénom et la profession.


Donc, il faut décomposer ces attributs en attributs simples dont l’ensemble reconstituera l’information initiale.

L’adresse comportant la rue, le code postal et la commune, nous allons créer 3 nouveaux attributs qui remplaceront l’attribut adresse : rue, code postal, ville.

En suivant le même raisonnement, nous allons remplacer l’attribut EtatCivil par les nouveaux attributs : nom, prénom, profession.

Nous obtenons une relation dont les attributs ne sont pas composés.

Par contre, il faut maintenant vérifier que, pour tout tuple, il y a bien une seule valeur pour chacun des attributs pour confirmer que cette relation est en 1FN.

Attention, la distinction entre atomique et nonatomique n’est pas que syntaxique, il faut aussi se situer dans le contexte de l’étude. Ainsi, les dates, bien que composées, sont souvent considérées comme

atomiques car c’est le tout de la composition qui fournit l’information.

Exemple :

Considérons la date d’embauche de l’ornithologiste Oiseau : 01 janvier 2007.

C’est un attribut composé mais chaque élément pris séparément (01 ou janvier ou 2007) ne veut rien dire dans le contexte.

Affinons la définition avec nos connaissances en algèbre relationnelle et plus particulièrement, celui du concept de clé de relation.

Une relation R (ID, A1,A2…An) est en 1FN si et seulement si tous les attributs nonclés dépendent fonctionnellement de la clé de relation.

Définition 2 (en référence au concept de DF)


Une relation R’ (ID1,ID2, A’1,A’2…A’n) est en 1FN si et seulement si tous les attributs nonclés dépendent fonctionnellement de la clé composée de relation (de la clé entière ou d’une partie seulement).

Ces deux définitions sont formulées différemment mais sont identiques à la première, les propriétés de la DF assurant la valeur atomique de chaque attribut cible de DF.

Exemple :

Soit le schéma de relation Employé : Employé <COEMP, NOEMP, DNEMP>

Un employé n’a qu’un et un seul code employé, c’est pour cette raison que le code employé est défini comme clé de relation.

Dans ce schéma, le nom de l’employé et la date de naissance dépendent fonctionnellement de la clé de la relation. En effet, une valeur d’un code employé ne pourra déterminer qu’un seul nom d’employé et qu’une seule date de naissance, celle de l’employé.

Il n’y aura qu’une seule valeur atomique dans les colonnes NOEMP et DNEMP pour chaque tuple de la table.

Autrement dit, nous aurons :

COEMP → NOEMP et COEMP → DNEMP

D‘après les définitions, cette relation est en 1FN.

Nous obtiendrons, par exemple, la table en extension suivante :

Une relation en 1FN n’est pas complètement normalisée, il faut maintenant vérifier qu’elle est en 2FN.

b. La deuxième forme normale (2FN)

La deuxième forme normale va permettre d’éliminer certaines redondances qui subsisteraient encore et d’assurer qu’aucun attribut n’est déterminé que par une partie seulement de la clé.

Une relation R (ID1,ID2, A1, A2…An) est en 2FN si et seulement si :

Elle est en 1FN,

Tout attribut n’appartenant pas à une clé ne dépend pas que d’une partie de cette clé.

La deuxième forme normale est à vérifier sur les relations dont la clé est une composition d’attributs. Une relation en 1FN dont la clé de relation est monoattribut est, par définition, en 2FN.

Exemple :

Soit la relation Client<NUCLI, NUACHAT, DATACHAT, NOCLI, MTACHAT, NBPOINT>, où :

NUCLI est l’attribut Numéro du client.

NUACHAT est l’attribut numéro achat du client. Un client peut faire plusieurs achats mais un seul achat par jour. Un numéro d’achat est unique pour un client ; mais, un même numéro d’achat peut être attribué à deux clients différents.

DATACHAT est la date de l’achat.

Définition 3 (en référence au concept de DF)

Définition 1


NOCLI est l’attribut nom du client. Il n’existe pas d’homonymes dans la base client.

MTACHAT est l’attribut Montant TTC de l’achat.

NBPOINT est le nombre de points de fidélité acquis. L’acquisition des points suit la règle suivante :

5 points acquis pour un montant d’achat compris entre 20€ et 40 € :

NBPOINT = 5 ⇔ 20 ≤ MTACHAT < 40







30 points acquis pour un montant d’achat supérieur ou égal à 300 € :

NBPOINT = 30 ⇔ 300 ≤ MTACHAT

La clé de relation a été définie comme composée des attributs Numero client et Numéro Achat qui définissent d’une manière unique un achat Y d’un montant X à une date D pour un client C.

Cette relation estelle en 2FN ?

D’abord, il faut vérifier qu’elle est en 1FN.

Nous sommes en présence d’une relation avec une clé composée, donc nous devons vérifier l’assertion suivante :

Une relation R’ (ID1,ID2, A’1,A’2…A’n) est en 1FN si et seulement si tous les attributs nonclés dépendent fonctionnellement de la clé composée de relation (de la clé entière ou d’une partie seulement).

NUCLI, NUACHAT → NOCLI ?

Les règles de gestion nous confirment que le numéro du client définit, par luimême et d’une manière unique, le nom du client. Donc, l’ajout du numéro d’achat du client à son numéro détermine un et un seul nom de client.

NUCLI, NUACHAT → MTACHAT ?

Pour un numéro de client et un numéro d’achat, il n’existe bien qu’un et un seul montant TTC de l’achat.

NUCLI, NUACHAT → DATACHAT ?

Pour un numéro de client et un numéro d’achat, il ne peut exister qu’une et une seule date d’achat puisqu’un client ne peut faire qu’un achat par jour.

NUCLI, NUACHAT → NBPOINT ?

Pour un numéro de client et un numéro d’achat, il n’existe qu’un et un seul montant TTC de l’achat, donc il n’existe qu’un et un seul NBPOINT acquis par achat et par client.

Cette relation est en 1FN.

Comme la clé de cette relation est multivaluée, il faut maintenant vérifier que tout attribut n’appartenant pas à la clé, ne dépend pas que d’une partie de cette clé, pour démontrer que cette relation est en 2FN.

Les questions à se poser sont les suivantes :

NUCLI → NOCLI ?

NUACHAT → NOCLI ?


NUCLI → MTACHAT ?

NUACHAT → MTACHAT ?

NUCLI → DATACHAT ?

NUACHAT → DATACHAT ?

NUCLI → NBPOINT ?

NUACHAT → NBPOINT ?

Il suffit qu’il y ait une seule réponse OUI à une de ces questions pour démontrer que cette relation n’est pas en 2FN.

La connaissance du N° client permet de déterminer un et un seul nom de client.

Donc, NUCLI → NOCLI.

Il existe un attribut qui dépend que d’une partie de la clé.

Cela suffit pour pouvoir affirmer que cette relation n’est pas en 2FN.

Il faut la décomposer.

À titre de pratique, examinons complètement, malgré tout, cette relation :

NUACHAT NUCLI : car deux clients peuvent avoir le même numéro d’achat.

NUACHAT NOCLI : pour la même raison.

NUCLI MTACHAT : la connaissance d’un numéro de client ne détermine pas une seule valeur d’un montant d’achat. Un client peut faire des achats de montants différents.

NUACHAT MTACHAT : à un numéro d’achat peut correspondre plusieurs achats effectués par des clients différents et donc, plusieurs montant TTC différents.

NUCLI DATACHAT : la connaissance d’un numéro de client ne détermine pas une seule valeur d’une date d’achat. Un client peut faire des achats à des dates différentes.

NUACHAT DATACHAT : à un numéro d’achat peut correspondre plusieurs achats effectués par des clients différents à des dates différentes.

NUCLI NBPOINT : la connaissance d’un numéro de client ne détermine pas une seule valeur du nombre de points acquis. Un client peut faire des achats de montants différents et acquérir des nombres de points différents.

NUACHAT NBPOINT : à un numéro d’achat peut correspondre plusieurs achats effectués par des clients différents, pour des montants différents, d’où un nombre de points de fidélité différents.

En résumé, nous avons, pour cette relation, les DF suivantes :

NUCLI, NUACHAT → NOCLI

NUCLI, NUACHAT → MTACHAT

NUCLI, NUACHAT → DATACHAT

NUCLI, NUACHAT → NBPOINT

NUACHAT DATACHAT

NUACHAT NOCLI


NUACHAT MTACHAT

NUACHAT NBPOINT

NUCLI DATACHAT

NUCLI MTACHAT

NUCLI NBPOINT

NUCLI → NOCLI.

Il existe un attribut qui ne dépend que d’une partie de la clé.

La relation client actuelle n’est pas en 2FN, il faut la décomposer.

Il suffit qu’il n’y ait qu’un seul attribut nonclé qui dépende d’une partie de la clé pour affirmer que la relation n’est pas en 2FN. Une relation en 1FN qui n’est pas en 2FN doit être décomposée.

La décomposition d’une table, qui n’est pas au degré de normalisation demandé, va se baser uniquement sur les DF existantes dans la relation.

Dans cette étape, on ne tient plus compte des DF liées à la clé de relation composée puisque notre objectif est justement de la décomposer.

Nous allons regrouper toutes les DF cible d’une DF source dans une relation.

En suivant cette règle et en partant d’une relation qui n’est pas en 2FN, nous allons obtenir au moins une relation de plus.

Exemple :

Les DF de la relation client précédente sont les suivantes :

NUCLI, NUACHAT → NOCLI mais la DF NUCLI → NOCLI existe aussi. Il ne faut conserver que la DF source comportant le nombre minimal d’attribut.

D’où, NUCLI → NOCLI

Nous avons aussi :

NUCLI, NUACHAT → MTACHAT

NUCLI, NUACHAT → DATACHAT

NUCLI, NUACHAT → NBPOINT

Nous regroupons les données cibles de DF avec leur(s) donnée(s) source et nous obtenons deux relations :

Client (NUCLI, NOCLI)

Achat (NUCLI, NUACHAT, DATACHAT, MTACHAT, NBPOINT)

La clé de chacune des relations est la (ou les) donnée(s) source de la DF correspondant à la relation.

En définitive, nous avons les deux relations suivantes :

Client (NUCLI, NOCLI)

Achat (NUCLI, NUACHAT, DATACHAT, MTACHAT, NBPOINT)


La décomposition de la relation, qui n’était pas en 2FN, est effectuée. Il faut maintenant vérifier que les relations obtenues sont normalisées en repartant du degré 1FN.

Exemple :

Client (NUCLI, NOCLI) estelle en 1FN ?

Oui, car NOCLI dépend fonctionnellement de la clé de la relation.

Elle est de fait en 2FN car la clé de la relation n’est pas composée.

Achat (NUCLI, NUACHAT, DATACHAT, MTACHAT, NBPOINT) estelle en 1FN ?

Oui, car DATACHAT, MTACHAT et NBPOINT dépendent fonctionnellement de la clé de la relation.

NUACHAT DATACHAT

NUACHAT MTACHAT

NUACHAT NBPOINT

NUCLI DATACHAT

NUCLI MTACHAT

NUCLI NBPOINT.

Nous avons construit deux relations en 2FN en partant d’une relation non normalisée.

Une décomposition d’une relation 1FN en 2FN en se basant sur les DF existantes dans la relation s’effectue sans perte.

En effet, tous les attributs sont conservés et sont regroupés par DF. Si l’on réalise la jointure des relations issues de la décomposition, nous retrouvons la relation initiale avec tous ses tuples, sans tuple(s) supplémentaire(s) et/ou faux.

Exemple :

Considérons la relation Client<NUCLI, NUACHAT, DATACHAT, NOCLI, MTACHAT, NBPOINT> en extension :

En se basant sur les DF, nous avons décomposé cette relation en deux autres relations :

Clientbis (NUCLI, NOCLI) dont l’extension est la suivante :


Achat (NUCLI, NUACHAT, DATACHAT, MTACHAT, NBPOINT) dont l’extension est la suivante :

ACHAT ⊳⊲ CLIENTBIS (jointure naturelle entre CLIENTBIS et ACHAT sur l’attribut commun NUCLI) est l’équijointure dont la condition de rapprochement concerne les attributs NUCLI de ACHAT et NUCLI de CLIENTBIS, sur laquelle une occurrence de l’attribut NUCLI est éliminée.

Nous retrouvons bien la relation CLIENT :

ACHAT ⊳⊲ CLIENTBIS = CLIENT, donc nous avons une décomposition sans perte.

Une relation en 2FN n’est pas complètement normalisée, il faut maintenant vérifier qu’elle est en 3FN.

c. La troisième forme normale (3FN)

La troisième forme normale va permettre d’éliminer les redondances dues aux dépendances transitives par rapport à la clé primaire.

Une relation R (ID, A1,A2…An) est en 3FN si et seulement si :

Elle est en 2FN,

Et tout attribut n’appartenant pas à la clé ne dépend pas d’un attribut nonclé.

Une relation R’ (ID1,ID2, A’1,A’2…A’n) est en 3FN si et seulement si :

Elle est en 2FN,

Et tout attribut n’appartenant pas à la clé ne dépend pas d’un attribut non clé.

Définition 1

Définition 2


La troisième forme normale est à vérifier sur les relations pour lesquelles il existe au moins deux attributs n’appartenant à la clé. Une relation en 2FN comprenant un seul attribut nonclé est, de fait, en 3FN.

Exemple :

Reprenons notre exemple précédent avec les deux relations en 2FN que nous avons trouvées :

Clientbis (NUCLI, NOCLI)

Achat (NUCLI, NUACHAT, DATACHAT, MTACHAT,NBPOINT)

La relation Client n’ayant qu’un attribut non clé est de fait en 3FN.

Analysons la relation Achat et les DF entre les attributs n’appartenant pas à la clé : DATACHAT, MTACHAT, NBPOINT.


DATACHAT → MTACHAT ?

DATACHAT → NBPOINT ?

NBPOINT → DATACHAT ?

NBPOINT → MTACHAT ?

MTACHAT → DATACHAT ?

MTACHAT → NBPOINT ?

Une valeur de date d’achat déterminetelle une valeur unique d’un montant d’achat ? Non (heureusement pour l’entreprise) car plusieurs achats de montants différents peuvent être effectués dans une même journée.

Donc DATACHAT MTACHAT.

Une valeur de date d’achat déterminetelle une valeur unique d’un nombre de points acquis ? Non, car plusieurs achats ayant des nombres de points acquis différents peuvent être effectués dans une même journée.

Donc DATACHAT NBPOINT.

Une valeur du nombre de points acquis déterminetelle une valeur unique d’une date d’achat ? Non, car plusieurs achats effectués à des dates d’achats différentes peuvent induire le même nombre de points.

Donc NBPOINT DATACHAT.

Une valeur du nombre de points acquis déterminetelle une valeur unique d’un montant d’achat ? Non, car la valeur du nombre de points acquis dépend du montant d’achat qui n’est pas fixe mais inclus dans un certain intervalle de valeurs.

Donc NBPOINT MTACHAT.

Une valeur d’un montant d’achat déterminetelle une valeur unique d’une date d’achat ? Non, car plusieurs achats de mêmes montants peuvent être effectués dans une des journées différentes.

Donc MTACHAT DATACHAT.

Une valeur d’un montant d’achat déterminetelle une valeur unique d’un nombre de points acquis ? Oui, car, d’après les règles de gestion, c’est bien le montant de l’achat qui détermine la valeur du nombre de points acquis.

Donc MTACHAT → NBPOINT.

Cette DF avait été masquée par les autres DF que nous avions définies précédemment :

NUACHAT → MTACHAT


NUACHAT → NBPOINT

Mais, en réalité, la DF NUACHAT → NBPOINT était issue de la propriété de transitivité des DF. Elle doit être éliminée car recalculable.

C’est pour cela que la troisième forme normale permet d’éliminer les redondances dues aux dépendances transitives par rapport à la clé primaire.

En effet, comme il existe un attribut n’appartenant pas à la clé qui dépend d’un attribut nonclé, nous pouvons affirmer que cette relation n’est pas en 3FN.


La décomposition d’une table, qui n’est pas au degré de normalisation demandé, va se baser uniquement sur les DF existantes dans la relation.



Exemple :

La DF de la relation Achat (NUCLI, NUACHAT, DATACHAT, MTACHAT,NBPOINT) prouvant qu’elle n’est pas en 3FN , est la suivante :

MTACHAT → NBPOINT

Nous regroupons les données cible de DF avec leur(s) donnée(s) source et nous obtenons deux relations :

Achat (NUCLI, NUACHAT, DATACHAT, MTACHAT)

Fidélité (MTACHAT, NBPOINT)

La clé de chacune des relations est la (ou les) donnée(s) source de la DF correspondant à la relation.

En définitive, nous avons les deux relations suivantes :

Achat (NUCLI,NUACHAT, DATACHAT, MTACHAT)

Fidélité (MTACHAT, NBPOINT).

La décomposition de la relation, qui n’était pas en 3FN, réalisée, il faut vérifier que les relations obtenues sont normalisées en repartant du degré 1FN.

Exemple :

Achat (NUCLI,NUACHAT, DATACHAT, MTACHAT) estelle en 1FN ?

Oui, car DATACHAT et MTACHAT dépendent fonctionnellement de la clé de la relation.

Nous avons démontré précédemment que :

NUCLI DATACHAT

NUCLI MTACHAT

NUACHAT DATACHAT

NUACHAT MTACHAT

Donc, elle est aussi en 2FN.

Les questions suivantes à se poser pour vérifier la 3FN, sont les suivantes :

DATACHAT → MTACHAT ?

MTACHAT → DATACHAT ?


Une valeur de date d’achat déterminetelle une valeur unique d’un montant d’achat ? Non, car plusieurs achats de montants différents peuvent être effectués dans une même journée.

Donc DATACHAT MTACHAT.

Une valeur d’un montant d’achat déterminetelle une valeur unique d’une date d’achat. Non, car plusieurs achats de mêmes montants peuvent être effectués dans des journées différentes.

Donc MTACHAT DATACHAT.


Fidélité (MTACHAT, NBPOINT) estelle en 1FN ?

Oui, car NBPOINT dépend fonctionnellement de la clé de la relation.

Elle est de fait en 2FN car la clé de la relation n’est pas composée.

Elle est de fait en 3FN car il n’existe qu’un seul attribut non clé.

Nous avons construit deux relations en 3FN en partant d’une relation non normalisée.

En synthèse, en partant de la relation universelle de notre exemple, Client<NUCLI, NUACHAT, DATACHAT, NOCLI, MTACHAT, NBPOINT>, qui est nonnormalisée, nous avons construit, en la décomposant, trois relations en 3FN :




Si à chaque étape de vérification d’un des niveaux des trois premières formes normales, nous décomposons, si besoin, la relation originelle en se basant sur les DF de chacun des attributs, nous ferons toujours une décomposition sans perte.

Exemple :

La décomposition en trois relations de la relation universelle Client de notre exemple a été systématiquement effectuée en tenant compte des DF existantes (liées, ne l’oublions pas, aux règles de gestion du système d’information).

Nous avions vérifié qu’au niveau de la deuxième forme normale, la décomposition s’était réalisée sans perte.

En estil arrivé de même au niveau de la 3FN ?

La question à se poser est la suivante :

Client = Clientbis ⊳⊲ Achat ⊳⊲ Fidélité ?

Reprenons la relation en extension Client :

En se basant sur les DF, nous avons décomposé cette relation en trois autres relations :

Clientbis (NUCLI, NOCLI) dont l’extension est la suivante :


Achat (NUCLI, NUACHAT, DATACHAT, MTACHAT) dont l’extension est la suivante :

Fidélité( MTACHAT, NBPOINT) dont l’extension est la suivante :

Les jointures se font par deux relations.

Commençons par Achat ⊳⊲ Fidélité. La jointure se fera sur l’attribut commun MTACHAT et nous obtenons :

Puis nous effectuons la jointure Clientbis ⊳⊲ (Achat ⊳⊲ Fidélité) qui utilisera, comme prédicat de jointure, l’égalité sur l’attribut NUCLI. Nous obtenons :


Donc, Clientbis ⊳⊲ (Achat ⊳⊲ Fidélité) = Client et nous retrouvons tous les attributs minimum et nécessaires à la gestion de notre SI.

d. Clé étrangère

La décomposition en relations 3FN, issues d’une relation en 2FN, mais dont certains attributs n’appartenant pas à la clé dépendent d’un attribut nonclé, fait surgir un concept que nous avons déjà vu : celui de la clé étrangère.

Nous pouvons lui donner une définition plus formelle.

Un attribut (ou une composition d’attribut) qui n’est pas une clé d’une relation est une clé étrangère de cette relation si le même attribut (ou la même composition d’attributs) apparaît comme clé d’une autre relation.

La clé de la relation est aussi appelée clé primaire.

La clé étrangère d’une relation R n’a pas les caractéristiques pour être la clé (primaire) de cette relation. Elle n’est qu’un attribut parmi les autres de R mais avec deux spécificités :

Elle est la clé (primaire) d’une autre relation R’,

Les valeurs prises par la clé étrangère de R doivent se retrouver en tant que valeurs de sa clé primaire correspondante dans R’. L’unique valeur qui lui est permise, dans certains cas, est la valeur Nulle (Null).

En synthèse, nous avons déterminé trois types de clés : les clés candidates d’une relation, la clé primaire d’une relation qui a été choisie parmi la ou les clé(s) candidate(s) et la clé étrangère qui constitue un lien

entre deux relations puisqu’elle est clé primaire dans l’une et attribut dans l’autre.

Exemple :

En partant de la relation universelle de notre exemple, Client<NUCLI, NUACHAT, DATACHAT, NOCLI, MTACHAT, NBPOINT>, nous avons construit, en la décomposant, trois relations en 3FN :




Après analyse des DF, la clé candidate de Clientbis est NUCLI. Donc, le choix a été limité et la clé primaire de Clientbis est NUCLI.

De même, la relation Fidélité n’a qu’une seule clé candidate qui devient la clé primaire : MTACHAT.

De même, la clé candidate d’Achat est le regroupement des deux attributs NUCLINUACHAT. La clé primaire est donc, ce même regroupement. De plus, cette relation contient l’attribut MTACHAT qui permettra de déterminer le nombre de points de cet achat grâce à la relation Fidélité. Cet attribut est une clé étrangère dans la relation Achat puisqu’elle est clé primaire dans la relation Fidélité.

Les valeurs prises par l’attribut MTACHAT de la relation Achat dépendent des valeurs existantes de l’attribut MTACHAT de Fidélité, et non le contraire.

Définition


Exemple :

Si pour le N° d’achat 309 du 13/07/2007, le montant TTC est de 456 €, alors obligatoirement ce montant TTC de 456€ existe et est lié à une valeur de nombre de points acquis dans la table Fidélité.

Par contre, il peut exister un montant de 372€ avec une valeur 30 pour le nombre de points acquis dans la relation Fidélité, alors qu’il n’existe aucun tuple dans la relation Achat dont la valeur du montant TTC soit égal à 372€.

L’attribut NUCLI ne peut pas être considéré comme une clé étrangère de la relation Achat car elle fait partie de la clé primaire.

e. Forme normale de BoyceCodd

Dans la pratique, un schéma relationnel dont toutes les tables sont en 3FN est dit normalisé.

Mais dans certains cas, R. Boyce et E. F. Codd ont repéré des faiblesses dans la 3FN.

En effet, la 3FN élimine les redondances liées à la transitivité des DF par rapport à la clé primaire ; mais il peut subsister des dépendances transitives par rapport à un élément de la clé de la relation si celleci est multiattribut. Ils ont donc défini une 3FN, plus restrictive, appelée la Forme Normale de BoyceCodd (FNBC).

Une relation est en FNBC si et seulement si :

Elle est en 3FN,

Aucun attribut faisant partie de la clé ne dépend d’un attribut ne faisant pas partie de la clé primaire.

Pour passer de la 3FN à la FNBC, il faut diviser chaque relation ne satisfaisant pas aux critères de la FNBC en deux relations.

Une nouvelle relation sera créée, celle qui répond à la DF nouvelle. Ainsi, cette nouvelle relation aura en tant que :

Clé : l’attribut dont provient la dépendance,

Attribut(s) : la partie de la clé qui en dépend.

Dans la relation de base, il faudra remplacer la partie de la clé concernée par l’attribut dont provient la dépendance (qui est devenu la clé de l’autre relation).

La décomposition se fera ainsi, sans pertes, puisque par jointure, nous retrouverons l’intégralité des tuples.

Par contre, la décomposition en FNBC, bien que normalisée, fait disparaître certaines DF.

Exemple :

Considérons le schéma relationnel constitué des relations suivantes :

Produit<NUPROD, LIBPROD>, où : NUPROD est l’attribut Numéro de produit, clé de relation, LIBPROD est l’attribut libellé du produit. Ces deux attributs sont liés par la DF suivante : NUPROD → LIBPROD.

Fournisseur<NUFOU, DENFOU>, où : NUFOU est l’attribut Numéro de fournisseur, clé de relation, DENFOU est l’attribut dénomination du fournisseur. Ces deux attributs sont liés par la DF suivante : NUFOU → DENFOU.

Type produit<TYPROD, LIBTYP>, où : TYPROD est l’attribut Type de produits, clé de relation, LIBTYP est l’attribut libellé du type de produits. Ces deux attributs sont liés par la DF suivante : TYPROD → LIBTYP.

De plus, ce Système d’Information doit suivre les règles de gestion suivantes :

Un type de produits englobe plusieurs produits. Un produit peut être de types différents.

Un fournisseur propose plusieurs types de produits mais un produit par type. De plus, un type de produits n’est

Définition


fourni que par un et un seul fournisseur.

En répondant à ces règles de gestion, nous avons construit la relation Fourniture <NUPROD, NUFOU,TYPROD>

Ce schéma estil en FNBC ?

Les trois premières relations sont en 1FN du fait de leur DF.

Elles sont aussi de 2FN, de 3FN et de FNBC de fait puisqu’elles ont une clé monoattribut et n’ont qu’un seul attribut nonclé.

Donc, il faut maintenant analyser la relation Fourniture.


La connaissance d’une valeur d’un numéro de produit et d’un numéro de fournisseur détermine une et une seule valeur de type de produits puisqu’un fournisseur ne propose qu’un produit par type.

NUPROD, NUFOU → TYPROD.


Estelle en 2FN ?

Les questions suivantes sont à se poser :

NUPROD → TYPROD ?

NUFOU → TYPROD ?

Un produit peut être de types différents donc, une valeur de numéro de produit ne détermine pas une et une seule valeur de type de produits.

Donc NUPROD TYPROD.

De même, un fournisseur propose plusieurs types de produits, donc une valeur de numéro de fournisseur ne détermine pas une et une seule valeur de types de produit.

Donc NUFOU TYPROD.


Elle est en 3FN de fait puisqu’elle ne possède qu’un seul attribut nonclé.

Mais estelle en FNBC ?

Du fait des règles de gestion, nous avons la DF supplémentaire suivante :TYPROD → NUFOU

Une valeur de TYPROD détermine une et une seule valeur de numéro de fournisseur.

Nous constatons qu’un attribut faisant partie de la clé (NUFOU) dépend d’un attribut ne faisant pas partie de la clé (TYPROD). Donc, la relation Fourniture n’est pas en FNBC.


Une nouvelle relation sera créée, celle qui répond à la DF nouvelle. Ainsi, cette nouvelle relation Type par Fournisseur aura en tant que :

Clé : l’attribut dont provient la dépendance TYPROD,

Attribut(s) : la partie de la clé qui en dépend : NUFOU.

Nous obtenons Type par Fournisseur< TYPROD,NUFOU>

Dans la relation de base, il faudra remplacer la partie de la clé concernée par l’attribut dont provient la dépendance (qui est devenu la clé de l’autre relation).

Nous obtenons Fourniturebis (NUPROD, TYPROD).

Illustrons cet exemple avec la relation Fourniture vue en extension.


La décomposition de cette relation en FNBC crée les deux relations suivantes :

Type par fournisseur en extension :

Fourniturebis en extension :

Attention ! Nous constatons que la décomposition en FNBC élimine les redondances qui subsisteraient encore dans la relation mais fait également disparaître certaines DF existantes.

Exemple :

Dans notre exemple précédent, la DF NUPROD, NUFOU → TYPROD a disparu.

Or, elle était représentative d’une règle de gestion du futur SI.

Dans la pratique, il faudra donc faire le choix le plus judicieux et le plus pertinent pour le SI (déjà normalisé en 3FN) :

conserver les DF (cœur de notre SI) grévées de redondances de données qui entraîneront une manipulation des données un peu plus complexe pour conserver leur cohérence,

ou construire une base de données parfaite, sans risque d’anomalies produites par la manipulation des données mais ne reflétant pas toutes les DF du Système.

f. Synthèse


3. Les quatrième et cinquième formes normales

Les formes normales étudiées précédemment qui, répétonsle, suffisent généralement pour répondre aux besoins d’un Système d’Information, nous ont aidés à éliminer toutes les anomalies liées aux dépendances fonctionnelles.

Mais E. F. Codd a poussé plus loin ses réflexions et a identifié un autre type de dépendances qui peuvent aussi provoquer des redondances de données : les dépendances multivaluées.

Nous allons définir ces nouvelles dépendances puis aborder les quatrième et cinquièmes formes normales qui reposent sur cellesci.

a. Les dépendances multivaluées (DM)

Soit un schéma de relation décrit par une relation universelle U (A1, A2… An), avec ∀i ∈ E (entiers), Ai étant un attribut dont les valeurs appartiennent à un domaine Di.

Soit X et Y des sousensembles de A1, A2,… An.

On dira que :

X multidétermine Y (ou il existe une dépendance multivaluée (DM) de Y sur X) si :

étant donné des valeurs de X, il y a un ensemble de valeurs de Y associées

et cet ensemble est indépendant des autres attributs Z= UXY de la relation U.

On écrira :

X → → Y

Soit une relation R(X,Y,Z),

Définition 1

Définition 2 (simplifiée)


X→ → Y (X multidétermine Y) < = = > ∀ la valeur prise par X,

∃ un ensemble de valeurs de Y : Ey

et

∃ un ensemble de valeurs de Z : Ez

et

Ey ∩ Ez = ∅ (ensemble vide)

Il existe une troisième définition encore plus simple mais qui n’est viable que si et seulement si vous avez une vue exhaustive de la relation en extension.



∃ 2 tuples (x, y, z) et (x, y’, z’) dans R alors obligatoirement ∃ 2 tuples (x, y’, z) et (x, y, z’) dans R

La manière la plus simple de comprendre ce nouveau concept est de l’illustrer avec un exemple.

Exemple :

Soit un SI qui gère des produits appartenant à un certain type. De plus, le SI gère les employés de l’entreprise.

Chaque type de produits englobe de 1 à n produits.

Les employés manipulent au moins un ou tous les types de produits existant dans l’entreprise.

L’informaticien a modélisé ce SI avec la relation Produit_employé suivante : Pro_emp<TYPROD, NUPROD, CODEMP>, où :

TYPROD est l’attribut type de produit.

NUPROD est l’attribut numéro de produit.

CODEMP est l’attribut code employé.

La clé de relation choisie est TYPRODNUPRODCODEMP.

Un extrait de la table en extension est le suivant :

Dans cet exemple, les produits appartiennent à un type de produits.

Les employés manipulent tel ou tel type de produits.

De plus, il n’y a aucun lien de défini, dans les règles de gestion, entre employés et produits.

Définition 3 (encore plus simple !)


Attention ! C’est ce postulat de complète indépendance entre deux attributs, qui sont malgré tout liés par une DF à un même 3ème attribut, qui permet de déterminer une DM.

La connaissance d’une valeur d’un type de produits détermine un ensemble de valeurs de numéro de produit et un ensemble de valeurs de code employé.

Mais, l’ensemble des valeurs de produit et l’ensemble des valeurs d’employé sont indépendants, malgré la connaissance de la valeur du type de produits. Leur intersection est égale à ∅ (ensemble vide).

Nous avons donc deux dépendances multivaluées.

TYPROD → → NUPROD

Et

TYPROD → → CODEMP.

La relation Prod_emp de l’exemple précédent est bien FNBC, mais elle est mal structurée.

Pourquoi ?

Parce qu’il existe deux sortes de DM, et suivant la DM mise en œuvre dans la relation, celleci pourra souffrir des mêmes anomalies de mise à jour qu’une relation non normalisée.

La DM X → → Y de la relation R est une DM Triviale si et seulement

Si X est un sousensemble de Y

OU

Si X ∪ Y = R.

La DM X → → Y de la relation R est une DM NonTriviale si et seulement

Si X n’est pas un sousensemble de Y

ET

Si X ∪ Y ≠ R.

Exemple :

Quelle est la DM mise en œuvre dans la relation Prodemp ?

Analysons chacune des DM.

TYPROD ∪ NUPROD ≠ Prod_emp.

Et de plus, TYPROD n’est pas un sousensemble de NUPROD.

Donc TYPROD → → NUPROD est une DM NonTriviale.

TYPROD ∪ CODEMP ≠ Prod_emp.

Et de plus, TYPROD n’est pas un sousensemble de CODEMP.

Donc TYPROD → → CODEMP est une DM NonTriviale.

Malgré le fait qu’une relation soit en FNBC, si elle possède au moins une DM Non Triviale, sa structure sera responsable d’anomalies de mise à jour.

Exemple :

En effet, dans notre relation Prod_emp, si nous embauchons un employé qui devra manipuler un type de produits, il faudra créer autant de tuples que de produits appartenant à ce type de produits.

Par exemple, soit le nouvel employé de code 031 qui vient d’être embauché et qui doit manipuler les produits de type A. Dans notre relation, nous avons trois tuples produit concernant le type de produit A, il faudra donc, créer trois tuples supplémentaires pour intégrer l’employé de code 031 dans la gestion de notre SI.

Dépendance Multivaluée Triviale (DMT)

Dépendance Multivaluée NonTriviale (DMNT)


Illustrons cette création d’employé 031 :

Pour prévenir ces risques, il a fallu qu’E. F. Codd définisse une forme normale supplémentaire, appelée quatrième forme normale.

b. La quatrième forme normale (4FN)

Une relation est en 4FN si et seulement si :

Elle est en FNBC,

Elle ne contient aucune DM Non Triviale.

Pour passer de la FNBC à la 4FN, il faudra supprimer toutes les DM NonTriviales. Cela se réalisera en créant une nouvelle relation comportant le(s) attribut(s) concerné(s) par la DM et le(s) déterminant(s) de la DM.

Le(s) déterminant(s) restent dans la relation originelle, les attributs y sont retirés.

La décomposition se réalise sans perte.

Exemple :

La relation précédente Prod_Emp<TYPROD, NUPROD, CODEMP> n’est pas en 4FN puisqu’elle a deux DM NonTriviales.

Elle a deux DMNT, cela implique qu’il va falloir construire deux nouvelles relations.

Commençons à étudier la DM TYPROD → → NUPROD.

Nous créons la nouvelle relation Typ_prod qui va comporter les attributs :

TYPROD (déterminant de la DM)

NUPROD (déterminé).

D’où la relation Typ_prod (TYPROD, NUPROD).

Cette relation est en 4FN de fait car elle ne comporte que deux attributs.

Définition


Étudions la DM TYPROD → → CODEMP.

Nous créons la nouvelle relation Typ_emp qui va comporter les attributs :

TYPROD (déterminant de la DM)

CODEMP (déterminé).

D’où la relation Typ_emp (TYPROD, CODEMP).

Cette relation est en 4FN de fait car elle ne comporte que deux attributs.

Les attributs liés à une DMNT ont été retirés de la relation originelle. Dans cette relation, il ne resterait plus que le déterminant TYPROD qui existe déjà dans les deux autres relations, donc elle n’est pas conservée.

Donc, de la relation Prod_Emp<TYPROD, NUPROD, CODEMP> qui n’était pas en 4FN, nous obtenons deux nouvelles relations en 4FN :

Typ_prod (TYPROD, NUPROD).

Typ_emp (TYPROD, CODEMP).

Visualisons ces nouvelles relations à partir de la table originelle en extension.

Relation Typ_prod en extension :

Relation Typ_emp en extension :

Rappelezvous de l’exemple précédent : pour gérer le nouvel employé de code 031 qui doit manipuler les produits de type A, nous avions créé 3 tuples. Au contraire, maintenant que nos relations sont en 4FN, il suffit de créer un seul tuple (A, 031) dans la relation TYP_EMP.

Les décompositions se sont réalisées sans pertes d’informations (de données et d’attributs).

En effet, Typ_Prod ⊳⊲ Typ_emp avec égalité sur l’attribut commun TYPROD donne en extension :


Prod_Emp = Typ_Prod ⊳⊲ Typ_emp

Nous sommes presque arrivés à l’excellence, mais les relations en 4FN peuvent encore comporter des insuffisances.

En effet, dans tous les cas que nous avons vu jusqu’à maintenant, nous avons décomposé les relations originelles non conformes au degré de forme normale demandé, en deux relations.

Cela s’est toujours effectué sans pertes, nous pouvions toujours recomposer la relation première à partir des deux relations nouvelles.

Mais cela n’est pas toujours le cas. En effet, si l’on décompose une relation en plus de 2 relations (donc, à partir de 3), il est possible de perdre des informations.

Exemple :

Considérons le SI suivant :

Nous gérons des clients qui achètent des produits vendus par des commerciaux. Si le client a besoin d’un produit et qu’il est démarché par un commercial qui propose ce produit, il lui achète ce produit.

Chaque commercial ne vend pas tous les produits proposés par l’entreprise.

L’informaticien qui a analysé ces règles de gestion, a construit la relation Achat suivante :

Achat<NUCLI, NUPROD, NUCOM>

L’extension de cette relation est la suivante :

Nous constatons que le client 103 qui avait besoin du produit 4 et qui a été démarché par les commerciaux 009 et 023, a acheté ce produit à chaque commercial.

Idem pour les clients 317.



Possèdetelle des DM ?

Pour rappel : Soit une relation R(X,Y,Z),


∃ un ensemble de valeurs de Y : Eyet


et


Estce que NUCLI → → NUPROD ?

Non, car quelle que soit la valeur prise par NUCLI, l’ensemble des valeurs prises par NUPROD correspondant dépend aussi des valeurs prises de NUCOM, puisque c’est le commercial qui vend le produit et tous les commerciaux ne vendent pas tous les mêmes produits.

Donc, quelle que soit la valeur prise par NUCLI, nous ne pourrons pas trouver des ensembles de valeurs pour NUPROD et NUCOM indépendants. Donc, NUCLI NUPROD.

Estce que NUCLI → → NUCOM ?

Non, car quelle que soit la valeur prise par NUCLI, l’ensemble des valeurs prises par NUCOM correspondant dépend aussi des valeurs prises de NUPROD, puisque le produit acheté par le client est obligatoirement vendu par un commercial.

Donc, quelle que soit la valeur prise par NUCLI, nous ne pourrons pas trouver des ensembles de valeurs pour NUPROD et NUCOM indépendants. Donc, NUCLI NUCOM.

Estce que NUPROD → → NUCLI ?

Non, car quelle que soit la valeur prise par NUPROD, l’ensemble des valeurs prises par NUCLI correspondant dépend aussi des valeurs prises de NUCOM, puisque le produit est acheté par le client, par l’intermédiaire d’un commercial.

Donc, quelle que soit la valeur prise par NUPROD, nous ne pourrons pas trouver des ensembles de valeurs pour NUCLI et NUCOM indépendants. Donc, NUPROD NUCLI.

Estce que NUPROD → → NUCOM ?

Non, car quelle que soit la valeur prise par NUPROD, l’ensemble des valeurs prises par NUCOM correspondant dépend aussi des valeurs prises de NUCLI, puisque le produit, pour être vendu par le commercial, doit être acheté par le client.

Donc, quelle que soit la valeur prise par NUPROD, nous ne pourrons pas trouver des ensembles de valeurs pour NUCOM et NUCLI indépendants. Donc, NUPROD NUCOM.

Estce que NUCOM → → NUCLI ?

Non, car quelle que soit la valeur prise par NUCOM, l’ensemble des valeurs prises par NUCLI correspondant dépend aussi des valeurs prises de NUPROD, puisque pour qu’il y ait une relation entre le commercial et le client, il faut qu’il y ait une vente de produits.

Donc, quelle que soit la valeur prise par NUCOM, nous ne pourrons pas trouver des ensembles de valeurs pour NUCLI et NUPROD indépendants. Donc, NUCOM NUCLI.

Estce que NUCOM → → NUPROD?

Non, car quelle que soit la valeur prise par NUCOM, l’ensemble des valeurs prises par NUPROD correspondant dépend aussi des valeurs prises de NUCLI, puisque pour que le commercial vende un produit, il faut qu’un client l’achète.

Donc, quelle que soit la valeur prise par NUCOM, nous ne pourrons pas trouver des ensembles de valeurs pour NUPROD et NUCLI indépendants. Donc, NUCOM NUPROD.

Puisque cette relation ne possède pas de DM, elle est en 4FN. Mais malgré tout, elle possède encore des redondances (cf. l’extrait de la table en extension).

En tant qu’exercice, utilisez la définition 3 pour confirmer que cette relation n’a pas de DM. En particulier, regardez de près les tuples avec le numéro d’article égal à 7 !


c. Les Dépendances de Jointure (DJ)

Pourquoi une table en 4FN peutelle contenir des redondances et n’être pas encore normalisée ?

Parce que les DM nous aident à décomposer sans perte les relations en 2 autres relations normalisées ; mais s’il n’y a pas de DM pour structurer la décomposition, il est difficile de faire une décomposition sans perte d’une relation en 2+n (0<n) relations normalisées, sauf si l’on s’appuie sur le concept de dépendance de jointure sans perte.

Soit une relation R (A1, A2… An), et X1, X2…Xn des sousensembles de (A1, A2… An) avec ∀i ∈ E(entiers), Ai étant un attribut dont les valeurs appartiennent à un domaine Di.

On dira qu’il existe une dépendance de jointure *(X1,X2…Xn) si R est la jointure de ses projections sur X1, X2, … Xn.

C’estàdire :

∃ *(X1,X2... Xn) ⇔ R = ∏ (R) ⊳⊲ ∏ (R) ⊳⊲ ... ∏ (R)

X1 X2 Xn

Exemple :

Considérons la relation Achat<NUCLI, NUPROD, NUCOM> précédente qui est en 4FN et qui comporte pourtant des redondances. Elle n’a pas de DM qui nous serait utile pour la décomposer en deux relations. En effet, d’après les règles de gestion, tout client, qui a besoin d’un produit et étant démarché par un commercial qui vend ce produit, a aussi acheté ce produit à ce commercial.

Donc, nous avons trois liens ni DF, ni DM :

client produit : un client a besoin de produits

commercial produit : un commercial vend des produits

client commercial : un client achète à des commerciaux

Créons les trois relations associées :

CLIPRO<NUCLI, NUPROD>

COMPRO<NUCOM, NUPROD>

CLICOM<NUCLI, NUCOM>

En extension, nous obtenons pour chacune des relations :

Définition


Existetil une dépendance de jointure *(<NUCLI, NUPROD>, <NUCOM, NUPROD>,<NUCLI, NUCOM<) = *(CLIPRO, COMPRO, CLICOM)) ?

La projection par rapport à <NUCLI, NUPROD> de ACHAT donne une nouvelle relation ne comportant pas l’attribut NUCOM et dont les tuples en doublon sont supprimés.

Nous obtenons la relation en extension :

Nous constatons que cette projection est la relation CLIPRO.

La projection par rapport à <NUCOM, NUPROD> de ACHAT donne une nouvelle relation ne comportant pas l’attribut NUCLI et dont les doublons sont supprimés.



Nous constatons que cette projection est la relation COMPRO.

La projection par rapport à <NUCLI, NUCOM> de ACHAT donne une nouvelle relation ne comportant pas l’attribut NUPROD et dont les doublons sont supprimés.


Nous constatons que cette projection est la relation CLICOM.

Soit R1 = ∏ NUCLI,NUPROD (ACHAT) ⊳⊲ ∏ NUCOM,NUPROD (ACHAT)

La jointure se fera sur l’attribut commun NUPROD.

La relation R1 en extension est la suivante :


Nous constatons qu’à ce stade de jointure (recomposition d’ACHAT à partir de deux relations), nous avons trois tuples faux.

Construisons maintenant R2 = R1 ⊳⊲ P NUCLI,NUCOM (ACHAT)

La jointure naturelle de ces deux relations se fera sur les deux attributs communs NUCLI et NUCOM.

La relation R2 en extension est la suivante :

Nous constatons que les tuples faux ont été éliminés et R2 = Achat.

Il existe une dépendance de jointure *(<NUCLI, NUPROD>, <NUCOM, NUPROD>,<NUCLI, NUCOM<) = *(CLIPRO, COMPRO, CLICOM).

Ainsi, il sera possible de décomposer, sans perte, une relation en n (n>2) relations en s’appuyant sur le concept de la dépendance de jointure.

Le concept de dépendance de jointure étant assimilé, nous pouvons aborder la cinquième forme normale.

d. La cinquième forme normale (5FN)

Nous avons vu dans l’exemple précédent que même une relation en 4FN et sans DM peut contenir des redondances


de données ; mais nous avons vu aussi que cette relation en 4FN pouvait se décomposer sans perte en n relations normalisées (sans aucune redondance), selon le principe de la dépendance de jointure.

C’est sur cet état de fait qu’est basée la définition de la 5FN.

Une relation R est en 5FN si elle ne possède aucune dépendance de jointure.

Une relation R est en 5FN si pour toute dépendance de jointure *(X1,X2… Xn) dans R,

Alors ∀i ∈ E (entiers), Xi possède une clé candidate de R.

Une relation en 5FN, n’a pas de redondance de données, est au plus haut niveau de normalisation (jusqu’à ce que des points de faiblesse apparaissent et qu’il devienne indispensable d’inventer des formes normales encore plus élaborées !) et ne pourra être décomposée sans risque de perte d’informations.

Exemple :

La relation Achat<NUCLI, NUPROD, NUCOM> est en 4FN.

Elle possède malgré tout des redondances, nous l’avons confirmé en regardant sa relation en extension.

Elle ne possède pas d’autres clés candidates que la clé primaire actuelle puisque par définition, la clé primaire est la composition minimale d’attributs permettant de définir des tuples uniques.

Nous avons vu précédemment qu’elle possède une dépendance de jointure et en l’occurrence *(CLICOM, CLIPRO, COMPRO).

CLICOM <NUCLI, NUCOM>

CLIPRO <NUCLI, NUPROD>

Et COMPRO <NUPROD, NUCOM>.

Donc, il existe une dépendance de jointure d’Achat pour laquelle aucune des relations issues ne possède une clé candidate d’Achat.

Donc Achat n’est pas en 4FN.

Nous la décomposons suivant sa dépendance de jointure.

Ces trois relations sont en 5FN, ne comportent plus de redondances et la décomposition s’est réalisée sans perte d’informations.

Nous sommes enfin arrivés au bout du processus de normalisation !

Définition 1

Ou Définition 2


Les deux approches de normalisation

Il convient maintenant d’appliquer !

La normalisation est une technique que l’on peut mettre en œuvre à n’importe quel stade de la modélisation du futur SI.

En effet, elle est complètement indépendante de la méthode utilisée pour concevoir le SI. De ce fait, deux approches peuvent être suivies :

La première approche consiste à avoir une approche ascendante :

nous partons de toutes les données du SI pour en faire une relation universelle,

nous gravissons tous les degrés des FN pour décomposer cette relation universelle en n relations sans redondance d’informations et aboutir à un schéma relationnel normalisé.

La deuxième approche est une approche descendante

Les relations ont été construites par une méthode classique via un schéma entitésassociations,

Et nous les validons par conformité des exigences des différentes formes normales.

Nous allons entrer dans le détail de chacune.

1. Présentation du cas servant aux démonstrations

Nous allons étudier le SI de l’entreprise BOGATO de fabrication de biscuits et viennoiseries. Le périmètre de l’étude est constitué par la fabrication des produits alimentaires par les employés, les autres services (comptabilité, achats…) ne font pas partie de notre étude.

Les informations que nous avons recueillies (cahier des charges, audits auprès des utilisateurs…) sont les suivantes :

Chaque employé est identifié par son matricule unique, son nom (il peut exister des homonymes ou des jumeaux, ces derniers auront la même date de naissance et le même nom mais seront distingués par leur matricule différent) et sa date de naissance,

Au niveau géographique, dans l’entreprise, la fabrication des produits est divisée dans plusieurs unités appelées département, qui porte chacun un numéro unique et un nom,

Un employé travaille dans un département de fabrication,

Un employé fabrique plusieurs produits, il n’est pas spécialisé dans la fabrication d’un pain viennois, de financiers, etc. Il est polyvalent,

Chaque biscuit ou viennoiserie fabriqué porte un numéro de produit unique et un nom (financier, cookie, brioche aux fruits, brioche aux pépites de chocolat, etc.),

La production d’un produit exige un temps donné par produit et par employé. En effet, un débutant ira moins vite qu‘un employé ayant une expérience de 10 ans,

Il est possible, si c’est un produit élaboré (par exemple, brioche suisse comprenant une pâte à brioche et de la crème pâtissière), que sa fabrication requiert la participation de plusieurs employés.

Les données exhaustives recensées sont les suivantes :

NUEMP : Matricule de l’employé,

NOEMP : Nom de l’employé,


DNEMP : Date de naissance de l’employé

NUDEP : Numéro du département,

NODEP : Nom du département,

NUPROD : Numéro du produit,

NOPROD : Nom du produit,

TFABR : Temps de fabrication.

2. Approche de construction de la base de données relationnelle

a. Relation universelle

Dans cette approche, nous regroupons toutes les informations de base dans une seule relation : la relation universelle.

Nous créons la relation BOGATO suivante :

BOGATO <NUEMP, NOEMP, DNEMP, NUDEP, NODEP, NUPROD, NOPROD, TFABR>

Chaque attribut correspond à une donnée élémentaire recensée précédemment.

Consultons la relation BOGATO en extension :

Nous apprenons ainsi que l’employé de numéro 101 qui se nomme BELAME, est né le 14/03/1959, travaille dans le domaine 1, Viennoiserie. Il fabrique la brioche en 2h.

Ce même employé, avec les mêmes caractéristiques, fabrique du pain au chocolat en 1h30.

La même lecture des informations est à effectuer pour les autres employés de l’entreprise.

Peuton garder cette seule relation pour le schéma relationnel du SI de l’entreprise BOGATO ? Autrement dit, cette relation estelle normalisée ?

Oui, s’il n’y a pas de redondance de données. Or, dans la relation actuelle, il y a de nombreuses redondances (nom d’employé, nom de département, nom de produit…). Donc, cette relation n’est pas normalisée.

Nous allons suivre le processus de normalisation en suivant les degrés de forme normale pas à pas.

Sachant que le matricule de chaque employé est unique, nous identifions comme clé de relation le numéro d’employé : NUEMP.

La relation s’écrit : BOGATO <NUEMP, NOEMP, DNEMP, NUDEP, NODEP, NUPROD, NOPROD, TFABR>

Nous obtenons la relation BOGATO en extension suivante :


b. 1FN


Nous remarquons à l’intersection de certaines lignes et colonnes, des valeurs non atomiques. Particulièrement, à l’intersection des lignes avec les attributs NOPROD et TFABR.

La relation BOGATO n’est pas en 1FN.

Nous allons utiliser la définition de la 1FN reposant sur les DF pour améliorer la relation BOGATO.

Pour rappel : Une relation R (ID, A1,A2…An) est en 1FN si et seulement si tous les attributs nonclés dépendent fonctionnellement de la clé de relation.

Nous devons chercher les dépendances fonctionnelles de chacun des attributs par rapport à la clé NUEMP.

D’après les règles de gestion :

NUEMP → NOEMP et NUEMP → DNEMP (il n’existe qu’une seule date de naissance par employé).

Maintenant, nous devons vérifier que :

NUEMP → NUDEP ?

NUEMP → NODEP ?

NUEMP → NUPROD ?

NUEMP → NOPROD ?

NUEMP → TFABR ?

NUEMP → NUDEP : une valeur du numéro d’employé détermine une et une seule valeur de numéro de département puisqu’un employé ne travaille que dans un seul département.

NUEMP → NODEP : une valeur du numéro d’employé détermine une et une seule valeur de nom de département puisqu’il travaille dans un et un seul département.

NUEMP NUPROD : une valeur du numéro d’employé ne détermine pas une et une seule valeur de numéro de produit puisqu’un employé peut participer à la fabrication de plusieurs produits, étant polyvalent.

NUEMP NOPROD : une valeur du numéro d’employé ne détermine pas une et une seule valeur de nom de produit puisqu’un employé peut participer à la fabrication de plusieurs produits.

NUEMP TFABR : une valeur du numéro d’employé ne détermine pas une et une seule valeur de temps de fabrication puisqu’un employé peut participer à la fabrication de plusieurs produits.

Il faut donc que nous affinions notre clé de relation.

D’après les règles de gestion, nous savons que :

NUPROD → NOPROD

NUEMP, NUPROD → TFABR ?


Une valeur de numéro d’employé et de numéro de produit déterminentelles une et une seule valeur de temps de fabrication ? Oui, car le temps de fabrication conservée en information est le temps de fabrication d’un employé qui appartient à un seul département et pour un produit bien déterminé.

Donc, NUEMP, NUPROD → TFABR.

Donc, nous allons enrichir notre clé de relation avec l’attribut NUPROD.

La relation s’écrit : BOGATO <NUEMP, NUPROD, NUDEP, NOEMP, DNEMP, NODEP, NOPROD, TFABR>.

Cette nouvelle relation BOGATO se présente en extension sous la forme :

Estelle en 1FN ?

NUEMP, NUPROD → NOEMP ? Oui par la DF NUEMP → NOEMP.

NUEMP, NUPROD → NUDEP ? Oui, par la DF NUEMP → NUDEP.

NUEMP, NUPROD → NODEP ? Oui par la DF NUDEP → NODEP (issue de la transitivité des DF).

NUEMP, NUPROD → DNEMP ? Oui par la DF NUEMP → DNEMP

NUEMP, NUPROD → NOPROD ? Oui par la DF NUPROD → NOPROD.

Donc, la relation BOGATO <NUEMP, NUPROD, NUDEP, NOEMP, DNEMP, NODEP, NOPROD, TFABR> est en 1FN.

c. 2FN


Cette relation a une clé qui n’est pas monoattribut donc il faut vérifier qu’elle soit en 2FN.

Pour rappel : une relation R (ID1,ID2, A1, A2…An) est en 2FN si et seulement si :

Elle est en 1FN.

Tout attribut n’appartenant pas à une clé ne dépend pas que d’une partie de cette clé.

La relation BOGATO <NUEMP, NUPROD, NUDEP, NOEMP, DNEMP, NODEP, NOPROD, TFABR> est en 1FN.

Il suffit de vérifier que NUDEP, NOEMP, DNEMP, NODEP, NOPROD, TFABR ne dépendent pas que d’une partie de la clé. Si un au moins de ces attributs ne dépend que d’une partie de la clé, la relation n’est pas en 2FN.

Or, nous avons la DF suivante : NUEMP → NOEMP.

Donc la relation actuelle BOGATO n’est pas en 2FN. Pour confirmer cette assertion, nous avons aussi les DF suivantes :

NUEMP → DNEMP.

NUEMP → NUDEP.

NUEMP → NODEP.


NUPROD → NOPROD.

Par contre, TFABR ne dépend pas que d’une partie de la clé pour la raison citée dans le paragraphe précédent.

NUEMP, NUPROD → TFABR.

Notre relation n’étant pas en 2FN, il faut la décomposer sans perte d’informations.

Au niveau de la 2FN, la décomposition en relations se réalisant via les DF, nous sommes assurés qu’il n’y aura pas de perte d’informations si nous recréons la relation originelle.

Les DF existantes nous permettent de créer les relations suivantes :

EMPLOYE<NUEMP, NOEMP, DNEMP, NUDEP, NODEP>

PRODUIT<NUPROD, NOPROD>

FABRICATION<NUEMP, NOPROD, TFABR>

La DF source étant la clé de la relation, nous finalisons les relations.

EMPLOYE<NUEMP, NOEMP, DNEMP,NUDEP,NODEP> en extension :

PRODUIT<NUPROD, NOPROD> en extension :

FABRICATION<NUEMP, NOPROD, TFABR> en extension :


Nous avons décomposé BOGATO en trois nouvelles relations.

Il faut obligatoirement vérifier chacune d’elles en partant du niveau le plus bas de normalisation.

EMPLOYE<NUEMP, NOEMP, DNEMP, NUDEP, NODEP> estelle en 1FN ? Oui, la clé de relation est la DF source de tous ses attributs. Elle est en 2FN de fait puisque sa clé de relation est monoattribut.

PRODUIT<NUPROD, NOPROD> estelle en 1FN ? Oui, la clé de relation est la DF source de son unique attribut NOPROD. Elle est en 2FN de fait puisque sa clé de relation est monoattribut.

FABRICATION<NUEMP, NOPROD, TFABR> estelle en 1FN ? Oui, la clé de relation est la DF source de son unique attribut TFABR. Cette assertion implique aussi qu’elle soit en 2FN.

d. 3FN

Ces trois nouvelles relations sontelles en 3FN ?

Pour rappel : une relation R (ID, A1,A2…An) est en 3FN si et seulement si :

Elle est en 2FN.


Ou si la clé est multiattribut

Une relation R’ (ID1,ID2, A’1,A’2…A’n) est en 3FN si et seulement si :

Elle est en 2FN.


La relation EMPLOYE<NUEMP, NOEMP, DNEMP, NUDEP, NODEP> estelle en 3FN ?


NOEMP → DNEMP ?

NOEMP → NUDEP ?


NOEMP → NODEP ?

DNEMP → NOEMP ?

DNEMP → NUDEP ?

DNEMP → NODEP ?

NODEP → NUDEP ?

NODEP → NOEMP ?

NODEP → DNEMP ?

NUDEP → NODEP ?

NUDEP → NOEMP ?

NUDEP → DNEMP ?

Il suffit qu’il y ait une réponse affirmative à l’une de ces deux questions pour que la relation ne soit pas en 3FN.

NOEMP DNEMP car comme il y a des homonymes parmi les employés (cette assertion fait partie des règles de gestion du SI), une valeur de nom employé ne détermine pas une et une seule valeur d’une date de naissance.

NOEMP NUDEP car comme il y a des homonymes parmi les employés (cette assertion fait partie des règles de gestion du SI), une valeur de nom employé ne détermine pas une et une seule valeur d’un numéro de département.

NOEMP NODEP car comme il y a des homonymes parmi les employés (cette assertion fait partie des règles de gestion du SI), une valeur de nom employé ne détermine pas une et une seule valeur d’un nom de département.

DNEMP NOEMP car, à une même date de naissance peut correspondre plusieurs valeurs de nom employé.

DNEMP NUDEP car, à une même date de naissance peut correspondre plusieurs valeurs de nom employé qui ne travaillent pas tous dans le même département, d’où plusieurs valeurs pour le numéro de département.

DNEMP NODEP car, à une même date de naissance peut correspondre plusieurs valeurs de nom employé qui ne travaillent pas tous dans le même département, d’où plusieurs valeurs pour le nom du département.

NODEP NOEMP car dans un même nom de département peuvent travailler plusieurs employés.

NODEP DNEMP car dans un même nom de département peuvent travailler plusieurs employés qui sont nés à des dates différentes.

NODEP NUEMP car les règles de gestion ne précisent pas qu’obligatoirement tous les départements ont des noms différents.

Mais NUDEP → NODEP. En effet, une valeur d’un numéro de département détermine une et une seule valeur de nom de département.

Donc, il existe un attribut nonclé qui est dépendant d’un autre attribut nonclé.

Donc, la relation EMPLOYE n’est pas en 3FN.

Finissons d’examiner les DF.

NUDEP NOEMP car dans un même nom de département peuvent travailler plusieurs employés.

NUDEP DNEMP car dans un même nom de département peuvent travailler plusieurs employés qui sont nés à des dates différentes.

La relation EMPLOYE n’étant pas en 3FN, il faut la décomposer.

Pour rappel ! La décomposition d’une table, qui n’est pas au degré de normalisation demandé, va se baser uniquement sur les DF existantes dans la relation.




Recensons nos DF :

NUEMP → NOEMP

NUEMP → DNEMP

NUEMP → NUDEP

NUDEP → NODEP

Nous obtenons deux relations :

EMPLOYE<NUEMP, NOEMP,DNEMP, NUDEP>

DEPARTEMENT<NUDEP, NODEP>

Les clés de chacune de ces relations sont la ou les DF source.

Donc nous obtenons :

EMPLOYE<NUEMP, NOEMP,DNEMP, NUDEP>

DEPARTEMENT<NUDEP, NODEP>

DEPARTEMENT est une entité paramètre. Sa clé primaire NUDEP est la clé étrangère de la relation EMPLOYE.

Ces deux relations en extension :

Les relations PRODUIT<NUPROD, NOPROD>, DEPARTEMENT<NUDEP, NODEP> et FABRICATION<NUEMP, NOPROD, TFABR> ne comportant qu’un seul attribut nonclé sont, de fait, en 3FN.

La base de données relationnelle du SI de l’entreprise BOGATO est en 3FN et nous voyons qu’il n’y a aucune redondance d’informations dans aucune relation. Elle est donc normalisée.

Malgré tout, continuons à explorer les FN supérieures.

e. FNBC


Les quatre relations du schéma relationnel de BOGATO sontelles en FNBC ?

Pour rappel : Une relation est en FNBC si et seulement si :

Elle est en 3FN.

Aucun attribut faisant partie de la clé ne dépend d’un attribut ne faisant pas partie de la clé primaire.

Considérons la relation EMPLOYE<NUEMP, NOEMP, DNEMP, NUDEP>


NOEMP → NUEMP ?

DNEMP → NUEMP ?

NUDEP → NUEMP ?

NOEMP NUEMP : le système admet des homonymes pour les noms d’employés donc une valeur de nom employé ne détermine pas une et une seule valeur de matricule employé.

DNEMP NUEMP : une valeur de date de naissance ne détermine pas une et une seule valeur de matricule d’employé.

NUDEP NUEMP : une valeur de numéro de département ne détermine pas une et une seule valeur de matricule d’employé.

NOEMP NUEMP et DNEMP NUEMP et NUDEP NUEMP, donc la relation EMPLOYE est en FNBC.

Considérons la relation PRODUIT<NUPROD, NOPROD>.

La question à se poser est NOPROD → NUPROD ?

Les règles de gestion nous précisent que le numéro de produit est unique mais pas le nom. Donc, une valeur de nom de produit n’est pas susceptible de déterminer obligatoirement une et une seule valeur de numéro de produit.

Donc, NOPROD NUPROD.

La relation PRODUIT est en FNBC.

Considérons la relation DEPARTEMENT<NUDEP, NODEP>.

La question à se poser est NODEP → NUDEP ?

Les règles de gestion nous précisent que le numéro de département est unique mais pas le nom. Donc, une valeur de nom de département n’est pas susceptible de déterminer obligatoirement une et une seule valeur de numéro de département.

Donc, NODEP NUDEP.

La relation DEPARTEMENT est en FNBC.

Considérons la relation FABRICATION<NUEMP, NUPROD, TFABR>.

Les questions à se poser :

TFABR → NUEMP ?

TFABR → NUPROD ?

Un employé peut participer à la fabrication de plusieurs produits, qui peuvent avoir des temps de fabrication différents. De même, plusieurs employés peuvent mettre le même temps de fabrication pour les mêmes produits ou des produits différents. Donc, une valeur de temps de fabrication ne détermine pas une et seule valeur de matricule d’employé.

Donc, TFABR NUEMP.

Un produit peut avoir des temps de fabrication différents suivant l’employé qui s’en occupe. Donc, une valeur de temps de fabrication ne détermine pas une et seule valeur de numéro de produit.


Donc, TFABR NUPROD.

La relation FABRICATION<NUEMP, NUPROD, TFABR> est en FNBC.

La relation EMPLOYE<NUEMP, NOEMP, DNEMP, NUDEP> est FNBC.

La relation PRODUIT<NUPROD, NOPROD> est en FNBC.

La relation DEPARTEMENT<NUDEP, NODEP> est en FNBC.

Donc, la base de données relationnelle du SI de BOGATO est en FNBC.

f. 4FN

Estil en 4FN ?

Pour rappel : Une relation est en 4FN si et seulement si :

Elle est en FNBC.

Elle ne contient aucune DM NonTriviale.

La DM X → → Y de la relation R est une DM Non Triviale si et seulement


ET

Si X ∪ Y ≠ R.

La relation EMPLOYE <NUEMP, NOEMP, DNEMP, NUDEP> estelle en 4FN ?

La première question à se poser est de savoir si elle contient des DM et si oui, si elles sont triviales ou non.

Rappelezvous la remarque que nous avions faite :

Attention ! C’est ce postulat de complète indépendance entre deux attributs, qui sont malgré tout liés par une DF à un même troisième attribut, qui permet de déterminer une DM.

Or pour chaque employé : son nom, sa date de naissance, son numéro de département font partie de ses caractéristiques propres. La connaissance de cellesci fait partie de la connaissance de l’individu. Ces 3 propriétés ne sont pas indépendantes, elles font partie du même tout : l’employé ; contrairement aux propriétés de l’exemple vu dans le paragraphe concernant les DM (cf. ce chapitre Processus de normalisation Les dépendances multivaluées).

Donc, la relation EMPLOYE n’ayant pas de DM, n’a pas de DMNT. Elle est aussi en FNBC donc elle est en 4FN.

Considérons maintenant la relation FABRICATION<NUEMP, NUPROD, TFABR>.

Il n’existe pas de DM, il n’y a que la DF NUPROD, NUEMP → TFABR. Les valeurs de ces 3 attributs sont dépendantes entre elles.

Donc, la relation FABRICATION<NUEMP, NUPROD, TFABR> n’ayant pas de DM, n’a pas de DMNT. Elle est aussi en FNBC donc elle est en 4FN.

Les relations PRODUIT<NUPROD, NOPROD> et DEPARTEMENT<NUDEP, NODEP> ne comportant que 2 attributs (un attribut clé et un attribut non clé) sont de fait en 4FN.

La relation EMPLOYE <NUEMP, NOEMP, DNEMP, NUDEP> est en 4FN.

Donc, la base de données relationnelle actuelle du SI de BOGATO est en 4FN.

g. 5FN

Le schéma relationnel de BOGATO estil en 5FN ?

Dépendance Multivaluée NonTriviale (DMNT)


Pour rappel :

Une relation R est en 5FN si elle ne possède aucune dépendance de jointure.

Ou

Une relation R est en 5FN si pour toute dépendance de jointure *(X1,X2… Xn) dans R, alors ∀i ∈ E (entiers), Xi possède une clé candidate de R.

Soit une relation R (A1, A2… An), et X1, X2…Xn des sousensembles de (A1, A2… An) avec ∀i ∈ E (entiers), Ai étant un attribut dont les valeurs appartiennent à un domaine Di.

On dira qu’il existe une dépendance de jointure *(X1,X2…Xn) si R est la jointure de ses projections sur X1, X2, … Xn.

C’estàdire, ∃ *(X1,X2… Xn) < = = > R = ∏ X1 (R) ⊳⊲ P X2 (R) ⊳⊲ … ∏ Xn (R)

La relation EMPLOYE<NUEMP, NOEMP, DNEMP, NUDEP> possèdetelle d’autres clés candidates que NUEMP ?

Le travail effectué pour les vérifications des FN inférieures nous permettent de dire que NON. NUEMP est la seule clé candidate et primaire. Ainsi, il n’est pas possible de trouver une dépendance de jointure où toutes les relations comporteraient une clé candidate d’EMPLOYE.

Donc, la relation EMPLOYE<NUEMP, NOEMP, DNEMP, NUDEP> est en 5FN.

Les relations PRODUIT<NUPROD, NOPROD> et DEPARTEMENT<NUDEP, NODEP> ne comportant que deux attributs (un attribut clé et un attribut non clé) n’ont pas de dépendance de jointure, donc elles sont en 5FN.

Considérons la relation FABRICATION<NUEMP, NUPROD, TFABR>.

Atelle des clés candidates autres que NUEMP, NUPROD ?

NUPROD, TFABR estelle une clé candidate ? Cela veut dire que la connaissance d’une valeur d’un n° de produit et d’un temps de fabrication permet de déterminer une valeur d’un seul employé. Non, un employé peut fabriquer plusieurs produits et avec des temps identiques ou différents. Un produit peut être fabriqué par des employés différents avec un temps identique ou différent. Il est donc possible d’avoir des doublons avec cette éventuelle clé, donc ce n’est pas une clé candidate.

Pour confirmer notre propos, considérons la relation FABRICATION avec cette clé candidate :

NUEMP, TFABR estelle une clé candidate ? Cela veut dire que la connaissance d’une valeur d’un n° d’employé et d’un temps de fabrication permet de déterminer une valeur d’un seul produit. Non, un employé peut fabriquer

Définitions 5FN

Dépendance de jointure


plusieurs produits avec des temps identiques. Il est donc possible d’avoir des doublons avec cette éventuelle clé, donc ce n’est pas une clé candidate.

Pour confirmer notre propos, considérons la relation FABRICATION avec cette clé candidate :

Du fait de doublons déjà existants pour les clés candidates multiattributs de la relation FABRICATION, il n’existe pas de clés candidates monoattribut pour cette relation.

Donc, la clé primaire de FABRICATION<NUEMP, NUPROD, TFABR> est la seule clé candidate.

De ce fait, on ne pourra pas décomposer la relation Fabrication en dépendance de jointure dont chacune des relations composantes auraient une clé candidate.

La relation FABRICATION<NUEMP, NUPROD, TFABR> est donc en 5FN.

La relation EMPLOYE<NUEMP, NOEMP, DNEMP, NUDEP> est en 5FN.

Les relations PRODUIT<NUPROD, NOPROD> et DEPARTEMENT<NUDEP, NODEP> sont en 5FN.

Donc, la base de données relationnelle que l’on vient de constituer pour le SI de l’entreprise BOGATO est 5FN.

Elle est complètement normalisée.

3. Approche de validation de la base de données relationnelle

Dans cette approche, à partir de l’expression des besoins des utilisateurs, nous construisons le schéma entitésassociations des données du futur SI par une méthode d’analyse classique. Puis, nous en déduisons les tables (relations) de la future base de données relationnelle ; et c’est à ce stade, que nous appliquons toutes les règles de E. F. Codd pour valider la normalisation de la base de données.

Pour appliquer cette approche, nous allons repartir des informations de l’entreprise BOGATO et construire la base de données via les étapes vues dans les premiers chapitres (dictionnaire de données…) puis la valider.

Rappelonsnous les étapes à suivre :

Élaborer le dictionnaire de données exhaustif et épuré (sans homonymes et sans synonymes),

Réaliser la Matrice des Dépendances Fonctionnelles entre ces données,

En déduire le schéma EntitésAssociations


Traduire ce schéma, suivant les règles de transformation en MPD de Merise, pour obtenir les relations exhaustives de notre future base de données relationnelle.

a. Dictionnaire des données

Notre étude des informations fournies par l’entreprise BOGATO, nous a permis de dresser une liste exhaustive des données :

NUEMP : Matricule de l’employé,

NOEMP : Nom de l’employé,

DNEMP : Date de naissance de l’employé

NUDEP : Numéro du département de fabrication,

NODEP : Nom du département de fabrication,

NUPROD : Numéro du produit,

NOPROD : Nom du produit,

TFABR : Temps de fabrication du produit par un employé.

Vous remarquerez que l’analyse des besoins des utilisateurs et des informations qu’ils ont fournies, conduit à la même liste exhaustive de données que dans la première approche. C’est normal et c’est obligatoire !

Il n’y a pas de synonymes, ni d’homonymes dans les données.

Cela nous conduit à déterminer trois objets du monde réel (trois entités) : l’employé, le produit et le département

Il faut trouver la donnée qui soit l’identifiant de chacune des entités.

Sachant que le matricule de l’employé est unique, le numéro de département de fabrication est unique et le numéro de produit est unique, nous en déduisons que :

NUEMP sera l’identifiant de l’entité EMPLOYE,

NUDEP sera l’identifiant de l’entité DEPARTEMENT,

NUPROD sera l’identifiant de l’entité PRODUIT.

Nous en déduisons le dictionnaire de données suivant :

b. Matrice des Dépendances Fonctionnelles

Pour rappel : deux données A et B sont en dépendance fonctionnelle, si la connaissance de la valeur de A permet

Recherche des dépendances fonctionnelles


d’identifier une et une seule valeur de B.

Cet axiome doit être vrai pour toutes les valeurs de A.

À ce stade du livre, nous sommes aguerris dans la recherche des DF.

Nous déduisons facilement les DF suivantes :

NUEMP → NOEMP

NUEMP → DNEMP

NUEMP → NUDEP

NUEMP → NODEP

NUDEP → NODEP

NUPROD → NOPROD

Par contre, nous noterons principalement que :

NUEMP NUPROD

NUDEP NOPROD

NUDEP NUEMP

Nous avons trois données source de DF (NUEMP, NOPROD et NUDEP) qui sont, d’ailleurs les identifiants que nous avions déterminés pour les entités du monde réel : Employé, Produit et Département.

À part TFABR, les autres attributs sont des données cible.

TFABR n’est pas une source de DF.

Par contre, à ce stade, nous ne savons pas encore à quelle DF elle appartient.

Nous allons la construire par étapes :

Nous venons d’indiquer la propriété de réflexivité des DF sur chacun des attributs.

Nous y rajoutons les informations concernant les DF.

Nous éliminons les colonnes ne concernant que des données cible et effectuons un premier Total :



Analysons la colonne Total.

Le total égal à 0 pour les données source de DF, NUEMP et NUPROD est normal.

Le total égal à 1 pour les données cible de DF, NOEMP, DNEMP, NOPROD est normal.

Le total égal à 1 pour la donnée source d’une DF NUDEP est normal.

Le total égal à 2 pour la donnée cible de DF NODEP est anormal.

Le total égal à 0 pour la donnée TFABR qui doit être cible d’une DF est anormal.

Le total égal à 2 pour NODEP induit que celleci est en DF avec plusieurs sources. La propriété de transitivité de la dépendance fonctionnelle est mise en œuvre et cela crée des dépendances fonctionnelles redondantes.

C’est exact, nous avons :

NUEMP → NODEP

Et NUDEP → NODEP

De plus, nous avons NUEMP → NUDEP.

Or, la propriété de transitivité signifie que si NUEMP → NUDEP et que NUDEP → NODEP, alors NUEMP → NODEP en est déduit.

Il faut conserver les deux branches initiatrices de la transitivité et éliminer la branche déduite, car c’est elle qui induit les redondances. Il ne faut donc pas conserver NODEP dans l’entité EMPLOYE.

D’où la nouvelle MDF :

Le total égal à 0 pour la donnée TFABR qui doit être cible d’une DF est anormal.

La donnée n’est pas source de dépendance fonctionnelle. Elle est isolée dans le Système d’Information.


Mais nous savons que la connaissance d’une valeur de temps de fabrication est dépendante de la connaissance d’une valeur d’un matricule employé et d’un numéro de produit.

En effet :

Un employé fabrique plusieurs produits, il n’est pas spécialisé dans la fabrication d’un pain viennois, de financiers, etc. Il est polyvalent.

La production d’un produit exige un temps donné par produit et par employé. En effet, un débutant ira moins vite qu‘un employé ayant une expérience de 10 ans.

Il est possible, si c’est un produit élaboré (par exemple, brioche suisse comprenant une pâte à brioche et de la crème pâtissière), que la fabrication d’un produit requiert la participation de plusieurs employés.

Donc le temps de fabrication (TFABR) est cible d’une composition des données source NUEMP et NUPROD.

Nous allons construire un nouvel identifiant et l’intégrer dans la MDF.

c. Création de la base de données relationnelle

Rappelonsnous la synthèse de la conversion de la MDF en schéma de relation d’une base de données relationnelle :

À partir de la MDF suivante, nous pouvons construire une base de données relationnelle pour le SI de BOGATO, constituée des relations suivantes :

La relation EMPLOYE<NUEMP, NOEMP, DNEMP, NUDEP> .

La relation PRODUIT<NUPROD, NOPROD>.


La relation DEPARTEMENT<NUDEP, NODEP>.

La relation FABRICATION<NUEMP, NUPROD, TFABR>.

Cette base de données ne vous rappelletelle pas quelque chose ?

C’est en effet la base de données relationnelle que nous avons trouvé à l’issue de notre première approche, celle de construction d’une base de données à partir de la relation universelle, après décomposition de la relation universelle en relations en 3FN.

d. Validation de la base de données relationnelle

Attention ! Nous avons utilisé la MDF pour réaliser la base de données relationnelle ; donc les liens existants entre les attributs d’une des relations cellesci, sont tous basés sur les DF. Ce qui nous permet

d’affirmer que cette base de données relationnelle est au moins, en 3FN.

Par contre, les DM et les DJ ne sont pas étudiées dans la MDF, donc on ne peut pas affirmer que cette base de données relationnelle est de fait en 5FN.

Nous allons malgré tout, en tant qu’étude pour la pratique, vérifier que toutes les relations suivent les exigences de toutes les formes normales.

EMPLOYE<NUEMP, NOEMP, DNEMP, NUDEP> estelle en 1FN ? Oui, la clé de relation est la DF source de tous ses attributs. Elle est en 2FN de fait puisque sa clé de relation est monoattribut.

PRODUIT<NUPROD, NOPROD> estelle en 1FN ? Oui, la clé de relation est la DF source de son unique attribut NOPROD. Elle est en 2FN de fait puisque sa clé de relation est monoattribut.

DEPARTEMENT<NUDEP, NODEP> estelle en 1FN ? Oui, la clé de relation est la DF source de son unique attribut NODEP. Elle est en 2FN de fait puisque sa clé de relation est monoattribut.

FABRICATION<NUEMP, NOPROD, TFABR> estelle en 1FN ? Oui, la clé de relation est la DF source complexe de son unique attribut TFABR. Cette assertion implique aussi qu’elle soit en 2FN.

La MDF nous confirme que la relation EMPLOYE<NUEMP, NOEMP, DNEMP,NUDEP> est en 3FN , car aucun des attributs nonclés de la relation ne dépend d’un attribut n’appartenant pas à la clé.

Les relations PRODUIT<NUPROD, NOPROD>, DEPARTEMENT<NUDEP, NODEP> et FABRICATION<NUEMP, NOPROD, TFABR> ne comportant qu’un seul attribut nonclés sont, de fait en 3FN.

Pour les vérifications des formes normales suivantes FNBC, 4FN, 5FN, reportezvous aux paragraphes précédents, c’est exactement le même raisonnement. Nous démontrerons ainsi que cette base de données relationnelle est en 5FN.

En conclusion, notre approche méthodique, basée sur les DF, nous assure de construire une base de données au minimum en 3FN et très souvent, audelà.

e. Exercice additionnel

Construire le schéma entitésassociations du SI de l’entreprise BOGATO.

À partir de la MDF, nous allons d’abord identifier les entités.

L’ensemble constitué d’une donnée source élémentaire et de ses données cible représente une entité. La donnée source est l’identifiant de cette entité. Les autres données cible constituent les propriétés de cette entité.

Nous obtenons trois entités : Employé, Produit et Département.

Nous recherchons ensuite s’il y a des associations.

L’ensemble constitué d’une donnée source complexe et de ses données cible représente une association particulière : une CIM. La donnée source complexe est l’identifiant de cette association. Les autres données cible constituent les propriétés de cette association.

Nous avons une CIM : fabrique en (temps). L’identifiant de cette association est la composition NUEMPNUPROD (1 employé, 1 produit) et l’attribut TFABR (temps de fabrication).

Énoncé

Solution


Il faut enfin reprendre les règles de gestion de la MOA pour compléter le schéma avec les associations simples.

Il n’y a qu’une seule association simple à rajouter, à savoir qu’un employé appartient à un département de fabrication.

Nous avons recensé toutes les entités et toutes les associations qui représentent le SI de l’entreprise BOGATO.

Nous obtenons le schéma EntitésAssociations incomplet suivant :

Il ne nous reste plus qu’à rajouter les cardinalités, toujours en se basant sur les informations fournies par l’entreprise BOGATO.

Les cardinalités de l’entité Département et de l’entité Employé, pour l’association ∈, sont calculées à partir des assertions :

Les employés appartiennent à un et un seul département de fabrication.

Un département de fabrication englobe de 1 à n employés.

Les cardinalités de l’entité Produit et de l’entité Employé, pour l’association Fabrique en, sont calculées à partir des assertions :

Un employé fabrique de 1 à n produit(s).

Un produit peut être fabriqué par 1 à n employés.

Nous obtenons le schéma EntitésAssociations complet suivant :


Synthèse

Nous avons découvert tout au long de ce chapitre qu’un même dictionnaire de données et que les mêmes règles de gestion peuvent générer des schémas de relation différents suivant l’interprétation et le degré d’analyse de l’informaticien.

Mais, malheureusement, une mauvaise perception du réel entraînera des difformités dans la structure du futur schéma relationnel. Cellesci seront responsables de la présence de données redondantes, d’incohérences potentielles entre les informations gérées par le SI, d’un surcoût de gestion et de stockage de la BD.

La réponse à cette problématique est de normaliser le schéma relationnel de la future base de données.

Il existe deux approches de normalisation : l’approche de construction du schéma relationnel en partant de la relation universelle et l’approche de validation du schéma relationnel après construction de celuici avec méthode (dictionnaire des données, Matrice des Dépendances Fonctionnelles…). En tant que praticienne, le conseil que je vous donnerai est de préférer la deuxième approche, beaucoup moins empirique, qui a l’avantage de border la démarche et de fournir une base de données relationnelle au minimum en 3FN, avantage indéniable pour les débutants.

De toute manière, quel que soit l’approche privilégiée, le processus de normalisation suivra une démarche par étape. Chaque étape consistera à vérifier un degré de forme normale. Chaque étape suivante ne pourra être abordée que si l’étape précédente est vérifiée.

E. F. Codd a inventé plusieurs niveaux de forme normale.

La première forme normale oblige à avoir des attributs atomiques au sein d’une relation.

Les deux formes normales suivantes reposent sur le concept de dépendance fonctionnelle entre attributs d’une relation.

Généralement et dans le contexte de l’approche de validation du schéma relationnel, la vérification de ces trois formes normales sur toutes les relations d’un schéma relationnel élimine toute forme de redondances dans celuici. Elle implique donc l’assurance d’avoir éradiquer tout risque de problème pouvant entraîner une incohérence du schéma relationnel. Et dans la plupart des cas, si un schéma relationnel a toutes ses relations en 3FN, il est normalisé.

Nous confirmons donc, que les connaissances acquises dans les chapitres précédents (dictionnaire de données,… et surtout MDF) nous suffiront pour créer un schéma relationnel normalisé en pratique courante.

Mais si vous avez un SI très élaboré à construire, avec des règles de gestion très complexes, alors des anomalies, liées à une faiblesse de normalisation, peuvent subsister. C’est à cet effet qu’E. F. Codd a introduit les définitions de la forme normale de BoyceCodd, puis de la quatrième et de la cinquième forme normale plus tard, pour répondre à ces besoins exceptionnels et rares.

Ces formes normales reposent non plus sur les dépendances fonctionnelles mais sur des dépendances plus complexes (multivaluées et de jointure).


Exercice

1. Énoncé

Soit la relation Tarif<NOLIV, TYPEDIT, PVENTE>, où :

NOLIV est l’attribut Titre du livre.

TYPEEDIT est l’attribut format d’édition (poche, avec CD,…).

PVENTE est l’attribut prix de vente.

Un même livre peut avoir plusieurs formats d’édition, mais différents les uns des autres, qui détermineront son prix de vente.

Il y a un prix de vente par format d’édition. Par contre, le même prix de vente peut être attribué à plusieurs formats d’édition.

1) Cette relation estelle normalisée ?

2) Si non, que fautil faire pour normaliser cette relation ?

2. Solution

1) Une relation est en première forme normale. Si pour chaque tuple de la relation, chaque attribut contient une valeur atomique.

Autrement dit, si l’on considère une relation en extension, cette relation est dite en première forme normale si et seulement à l’intersection d’une colonne (attribut) et d’une ligne (tuple) , on ne peut trouver qu’un seul élément.

Or, l’énoncé nous dit que pour un Titre de Livre, il existe plusieurs TYPEDIT (livre de poche, édition de luxe,…) , donc la relation n’est pas en 1FN .

2) Il faut d’abord vérifier les DF existantes entre les attributs et modifier si besoin la clé primaire de la relation.

Quelles sont les DF existantes ?

Pour un même Titre de Livre, il peut exister plusieurs formats d’édition. Donc, NOLIV TYPEDIT.

De même, un même format d’édition peut concerner plusieurs titres de livre, donc TYPEDIT NOLIV.

Le même prix de vente peut être attribué à plusieurs formats d’édition, donc PVENTE TYPEDIT.

Le même prix de vente peut être attribué à plusieurs titres de livre différents, donc PVENTE NOLIV.

Le format d’édition détermine le prix de vente. Donc, pour une valeur de format d’édition, il existe une et une seule valeur pour le prix de vente, donc TYPEDIT → PVENTE

Donc, si nous associons à une valeur de titre de livre, une valeur de son format d’édition, nous déterminons alors une et une seule valeur pour le prix de vente.

NOLIVTYPEDIT est une composition minimale d’attributs dont chacune des valeurs permet de déterminer d’une manière unique un tuple de la relation.

Il n’y a pas d’autres attributs ou composition minimale d’attributs permettant de déterminer une et une seule valeur de tuples. En effet, les autres compositions minimales d’attribut TYPEDITPVENTE et NOLIVPVENTE ne sont source d’aucune DF (TIPEDIT NOVLIV, PVENTE NOLIV et NOLIV TYPEDIT, PVENTE TYPEDIT).

Nous obtenons la relation Tarif<NOLIV, TYPEDIT, PVENTE> en 1FN.


Nous venons de prouver que tout attribut nonclé (en l’occurrence PVENTE) ne dépend pas que d’une partie de la clé.


Cette relation ne comporte qu’un seul attribut nonclé, elle est de fait en 3FN.

Cette relation estelle en FNBC ?


L’étude des DF nous a indiqué que : PVENTE TYPEDIT et PVENTE NOLIV.

Ainsi, aucun attribut faisant partie de la clé ne dépend d’un attribut ne faisant pas partie de la clé primaire. Donc, cette relation est en FNBC.

Cette relation estelle en 4 FN ?

Il n’existe pas de DM, il n’y a que la DF NOLIV, TYPEDIT → PVENTE. Les valeurs de ces trois attributs sont dépendantes entre elles.

Donc, la relation Tarif<NOLIV, TYPEDIT, PVENTE> n’ayant pas de DM, n’a pas de DMNT. Elle est aussi en FNBC donc elle est en 4FN.


Nous avons vérifié en analysant les DF qu’il n’y avait pas d’autres clés candidates que la clé primaire NOLIVTYPEDIT, donc s’il existait des dépendances de jointure pour cette relation, il ne serait pas possible que toutes les relations de la dépendance de jointure possède une clé candidate.

Donc la relation Tarif<NOLIV, TYPEDIT, PVENTE> est en 5FN.


Énoncé

Le centre multimédia d’une grande ville souhaite rénover l’informatisation de la gestion des prêts de livres, CD et DVD.

Son patrimoine est constitué de 10 000 livres, 5 000 CD et 3 200 DVD.

Tout habitant de la ville peut s’inscrire (avec un justificatif de domicile) au centre multimédia.

Suivant le type de son adhésion, il aura accès à divers services et un montant de cotisation annuel différent :

adhésion LIGHT de 10 euros (enfant < 15 ans : 8 euros) : emprunt de livres ou CD ou DVD,

adhésion MEDIUM de 16 euros (enfant < 15 ans : 14 euros) : emprunt de livres et CD,

adhésion XTRA de 20 euros (enfant < 15 ans : 17 euros) : emprunts de livres, de CD et de DVD.

L’adhérent reçoit une carte d’adhésion valable un an où figurent l’année, son numéro d’adhérent, son numéro d’inscription (unique pour chaque adhérent), son nom, son prénom, sa date d’adhésion, la date de règlement de l’adhésion et sa date de naissance et où il doit apposer sa photo d’identité.

La carte d’adhésion est valable du 1 janvier au 31 décembre de l’année en cours. Si l’adhérent renouvelle son adhésion l’année suivante, il reçoit un nouveau numéro d’inscription.

Chaque adhésion est individuelle : chaque membre d’une même famille peut avoir sa carte d’adhérent.

L’emprunt maximal est de 3 livres et/ou 2 CD et/ou 1DVD pour 15 jours. Le retour d’un emprunt peut s’effectuer en plusieurs fois.

Chaque livre est repéré par son numéro ISBN unique et peut avoir été acheté par le centre multimédia en 1 à 5 exemplaires. Il sera classé dans les rayons de la bibliothèque par catégorie. Un code unique détermine chaque catégorie (SF : Science Fiction, P : Policier,….).

Chaque CD ou DVD (acheté en 1 ou 3 exemplaires) est repéré par son numéro unique, son titre et sa catégorie. Un code unique détermine chaque catégorie (R : Rap, CM : Comédies musicales,….).

Chaque exemplaire de livre, CD ou DVD est distingué par un numéro unique. À tout instant, la bibliothécaire sait s’il est disponible ou non (déjà emprunté).

Les livres, CD et DVD sont achetés à un seul fournisseur : MEdiaOne. Leur règlement ne sont pas effectués par la bibliothèque.

À la réception d’un nouveau livre, CD ou DVD, la bibliothécaire lui affecte une fiche sur laquelle elle notera les dates d’emprunts et de retour de cet article.

À chaque emprunt, la bibliothécaire vérifie que l’adhérent a son adhésion valide et note le numéro de l’emprunt (unique, ce numéro est constitué du quantième du jour + un numéro incrémental qui recommence à 1 tous les jours), la date d’emprunt, les éléments empruntés, le numéro de l’adhérent emprunteur, la date prévue de retour. Elle enlève les fiches des éléments empruntés, les met à jour et les range dans un bac à fiches.

Il vous a été demandé de concevoir la base de données du futur SI de gestion de cette bibliothèque (stockage des livres, CD et DVD, gestion des adhérents et des emprunts).

1) Représenter le Modèle de Contexte.

2) Constituer le dictionnaire épuré du SI.

3) Réaliser la MDF.

4) Réaliser le schéma entitésassociations.

5) Décrire les relations de la base de données relationnelle du futur SI.

6) En utilisant des opérateurs d’algèbre relationnelle, répondre aux interrogations suivantes :

a) Quelles sont les catégories possibles pour les média (libellé) ?

b) Quels sont les livres (N° et titre) qui n’ont aucun exemplaire de disponible ?

c) Quels sont les media (Numéro et code type) proposés par la bibliothèque pour "Le Comte de MonteCristo".

d) Quels sont les media (Numéro et libellé type) proposés par la bibliothèque pour "Le Comte de MonteCristo".


e) Quels sont les titres des livres dont le prix d’achat d’un de ses exemplaires est supérieur à 25 € ? Nous savons que le TYPMED (Type de média) des livres est égal à ‘1’. Donner l’arbre algébrique associé.

f) Quels sont les adhérents qui n’ont pas encore fait d’emprunt au 14/12/2008 ?

g) Quels sont les adhésions qui ont été réglées le jour même de l’adhésion ?


Solution

1) Modèle de Contexte

Le Modèle de Contexte est un des deux diagrammes du Modèle Conceptuel de Communication.

Le Modèle de Contexte va permettre de déterminer :

les frontières de notre SI,

les acteurs externes,

les flux existants (émission et réception) entre le SI et les acteurs externes.

Le SI devra inclure le stockage des livres, CD et DVD, la gestion des adhérents et des emprunts ; mais il n’inclura pas la relance des emprunts puisque cela n’a pas été demandé.

Les seuls acteurs externes sont l’adhérent et le fournisseur MEdiaOne.

Les flux en réception du SI (en provenance de l’adhérent) :

Demande d’adhésion + justificatif,

Cotisation,

Retour emprunt.

Les flux en réception du SI (en provenance du fournisseur) :

Médias (livres, CD et DVD)

Les flux en émission du SI (vers l’adhérent) :

Carte d’adhérent,

Emprunt (livres et/ou CD et/ou DVD).

Il n’y a pas d’émission vers MediaOne car le paiement des médias n’est pas effectué par la bibliothèque ellemême.

Nous pouvons représenter le MC du SI :


2) Dictionnaire des Données

Les informations recensées sont les suivantes :

L’adhérent possède un numéro d’adhérent, nom, prénom et une date naissance.

L’adhérent prend une adhésion pour une année à une date d’adhésion et règle son adhésion à une date de règlement.

Un type d’adhésion possède un code, un libellé, un nombre de livres autorisés, un nombre de CD autorisés, un nombre de DVD autorisés, un tarif adulte et un tarif enfant.

Chaque exemplaire de livre, CD ou DVD possède un numéro d’exemplaire, une date d’achat, un état disponible ou non, un prix d’achat, un état général (bon, dégradé…).

Un média possède un numéro (N° ISBN pour les livres) et un titre.

Un média appartient à un type (CD, Livre, DVD).

Un média appartient à une catégorie possédant un code et un libellé (Science Fiction, Rap…).

Un emprunt effectué par un adhérent possède une date d’emprunt, une date de retour prévue, la date de retour effective de chaque article et est constitué de 1 ou plusieurs médias (nombre de CD, nombre de livres et nombre de DVD).

Quelles sont les données immédiatement identifiables comme identifiant ?

Elles nous ont été indiquées par le texte : le numéro adhérent, le code type adhésion, le numéro exemplaire, le numéro de média, le code catégorie de média, le numéro de l’emprunt et le code type de média.

Les autres données sont, à ce stade, signalétiques.


3) La Matrice des Dépendances Fonctionnelles

Nous conservons en colonne, les données de catégorie Identifiant.


Quelles sont les dépendances fonctionnelles ?

Les données identifiant sont des données source de DF.

Nous allons chercher pour chacune, les données cible de DF.

Une valeur de numéro adhérent (NUADH) détermine une et une seule valeur de :

Nom de l’adhérent (NOADH),

Prénom de l’adhérent (PNADH),

Date de naissance (DNADH).

Une valeur de type adhésion (TYADH) détermine une et une seule valeur de :

Libellé de l’adhésion (LIBADH),

Nombre de livres autorisés (NBLIV),

Nombre de CD autorisés (NBCD),

Nombre de DVD autorisés (NBDVD),

Tarif de l’adhésion adulte (TADHA),

Tarif de l’adhésion enfant (TADHE).

Une valeur de numéro exemplaire (NUEXE) détermine une et une seule valeur de :

État de l’exemplaire (ETEXE),


Disponibilité de l’exemplaire (DIEXE)

Date d’achat de l‘exemplaire (DATACH)

Prix d’achat (PEXE),

Code du média (COMED) (un exemplaire concerne un et un seul media).

Une valeur de catégorie média (CAMED) détermine une et une seule valeur de :

Libellé de la catégorie du média (LIBCAM) (SF, Comédie…).

Une valeur de type média (TYPMED) détermine une et une seule valeur de :

Libellé du type du média (LIBTM) (CD, DVD, Livre).

Une valeur de code média (COMED) détermine une et une seule valeur de :

Titre (TITMED)

Catégorie du media (CAMED) (un média est soit de type Rap, Comédie…).

Type du media (TYPMED) (un média est soit un livre OU un Cd OU un DVD).

Une valeur de numéro emprunt (NUEMP) détermine une et une seule valeur de :

Date de l’emprunt (DATEMP),

Date de retour prévue (DRPEMP),

Nombre de livres empruntés (NBLIVE),

Nombre de CD empruntés (NBCDE),

Nombre de DVD empruntés (NBDVDE)

Numéro adhérent (NUADH) (un emprunt concerne un et un seul adhérent).

Nous enrichissons la MDF avec ces informations :


Nous constatons que certaines données nonidentifiantes ont une valorisation à 0 :

Année de l’adhésion (ANADH),

Date d’adhésion (DATADH),

Date de règlement de l’adhésion (DATREG),

Date du retour effectif de l’exemplaire (DREEMP).

La date d’adhésion d’un adhérent est déterminée d’une manière unique par le numéro adhérent et le type d’adhésion et son année d’adhésion.

La date de règlement de l’adhésion d’un adhérent est déterminée d’une manière unique par le numéro adhérent et le type d’adhésion et son année d’adhésion.

La date de retour effectif d’un exemplaire est déterminée par la connaissance du numéro de l’emprunt auquel il appartenait et le numéro de l’exemplaire.

Nous enrichissons une nouvelle fois la MDF :


La donnée ANADH est valorisée à zéro car elle fait uniquement partie d’une donnée source complexe de DF.

La nouvelle donnée 33 est représentative du numéro d’inscription qui sera reportée sur la carte d’adhésion.

En effet, les règles de gestion nous ont indiqué qu’à chaque adhésion annuelle, l’adhérent reçoit un nouveau numéro d’inscription.

3) Le schéma EntitésAssociations

Les règles du passage de la MDF au schéma entitésassociations sont les suivantes :

1ère étape : Il faut d’abord considérer les données source élémentaires. L’ensemble constitué d’une donnée source élémentaire et de ses données cible représente une entité. La donnée source est l’identifiant de cette entité. Les autres données cible constituent les propriétés de cette entité.

2ème étape : Il faut ensuite examiner les données source issues de rapprochement de données source élémentaires, nous les appellerons données source complexes. L’ensemble constitué d’une donnée source complexe et de ses données cible représente une association, et plus particulièrement une CIM. La donnée source complexe est l’identifiant de cette association. Les autres données cible constituent les propriétés de cette association.

3ème étape : Il faut enfin reprendre les règles de gestion de la MOA pour compléter le schéma avec les associations simples et toutes les cardinalités.

Nous avons 6 données source élémentaires, nous obtenons 6 entités avec leur identifiant souligné :

ADHERENT (NUADH, NOADH, PNADH, DNADH)

TYPE ADHESION (TYADH, LIBADH, NBLIV, NBCD, NBDVD, TADHA, TADHE)

MEDIA (COMED, TITMED, CAMED, TYPMED)

EXEMPLAIRE(NUEXE, ETEXE, DIEXE, DATACH, PEXE, COMED)


CATEGORIE MEDIA (CAMED, LIBCAM)

TYPE MEDIA (TYPMED, LIBTM)

EMPRUNT(NUEMP, DRPEMP, DATEMP, NUADH)

Nous avons 2 données source complexes, nous obtenons 2 CIM avec leur identifiant souligné :

MEDIA EMPRUNTE (NUEMP, NUEXE, DREEMP)

ADHESION (NUADH, TYADH, ANADH, DATADH, DATREG)

Nous pouvons représenter le schéma entitésassociations sans les cardinalités :

Les règles de gestion de ce SI vont nous permettre de déterminer les cardinalités de chacune des entités par rapport à la ou les association(s) à laquelle ou auxquelles, elle participe.

Une occurrence d’adhérent peut posséder au moins une adhésion et au plus n, s’il en prend chaque année.

Un type d’adhésion peut concerner 1 adhésion au minimum et n adhésions au maximum.

Un emprunt concerne un et un seul client.

Un client est concerné par 0 ou plusieurs emprunts.

Un emprunt concerne 1 à n exemplaires.

Un exemplaire est concerné par aucun ou plusieurs emprunts.

Un média est défini par une et une seule catégorie (SF, Rap, Comédie…).

Une catégorie concerne de 1 à n média.

Un média est soit un livre, soit un CD ou soit un DVD.

Un type de média concerne de 1 à n articles.


Un média comporte de 1 à n exemplaires.

Un exemplaire d’un média concerne un et un seul média.

Le schéma entitésassociations définitif est le suivant :

Les clés étrangères en italique sont liées à la traduction des cardinalités sur le schéma entitésassociations (cf. chapitre Modélisation Les modèles Merise Modèle Logique de Données).

5) Décrire les relations de la base de données relationnelles du futur SI

Nous reprenons le tableau vu dans le chapitre Introduction à l’algèbre relationnelle :

En repartant de la MDF, nous pouvons décrire les 8 relations de la base de données relationnelle :

ADHERENT <NUADH, NOADH, PNADH, DNADH>

TYPE ADHESION <TYADH, LIBADH, NBLIV, NBCD, NBDVD, TADHA, TADHE>


MEDIA <COMED, TITMED, CAMED, TYPMED>

EXEMPLAIRE <NUEXE, ETEXE, DIEXE, DATACH, PEXE, COMED>

CATEGORIE MEDIA <CAMED, LIBCAM>

TYPE MEDIA <TYPMED, LIBTM>

EMPRUNT <NUEMP, DRPEMP, DATEMP, NUADH>

MEDIA EMPRUNTE <NUEMP, NUEXE, DREEMP>

ADHESION <NUADH, TYADH, ANADH, DATADH, DATREG>

6) En utilisant des opérateurs d’algèbre relationnelle, répondre aux interrogations suivantes :

a) Quels sont les libellés possibles pour les médias?

La relation résultant CATPOS sera issue d’une projection sur l’attribut LIBCAM de la relation catégorie.

CATPOS = proj (CATEGORIE, LIBCAM) = ∏ LIBCAM (CATEGORIE).

b) Quels sont les livres (N° et titre) qui n’ont aucun exemplaire de disponible ?

Nous appellerons la relation résultante NONDISPO.

Nous recherchons un média qui soit un livre et qui a tous les exemplaires dans un état emprunté.

Nous devons extraire d’abord les média qui sont des livres : jointure naturelle entre média et type de média sur LIBTM = ‘Livre’ ; d’où R1 = MEDIA ⊳⊲ ( σ LIBTM = ‘Livre’ (TYPE ))

Puis nous devons extraire tous les exemplaires qui sont liés à ces livres (jointure naturelle sur COMED) ; d’où R2 = EXEMPLAIRE ⊳⊲ R1

Puis nous devons extraire les tuples exemplaires pour lesquels l’attribut état est ‘disponible’ ; d’où R3 = σ ETEXE = ‘Disponible’ (R2)

Puis, nous n’en extrayons que les N° media correspondants ; d’où R4 = ∏ COMED (R3)

En parallèle, nous faisons une projection sur N° media des exemplaires qui sont liés aux livres ; d’où R5 = ∏ COMED (R1)

Puis, nous faisons la différence R5 (tous les N° de media qui sont des livres ) R4 (Tous les N° de media qui sont des livres dont au moins un des exemplaires est ‘disponible’) pour conserver les N° des livres qui ont tous les exemplaires à l’état ‘emprunté’.

NONDISPO = R5 R4.

c) Quels sont les media (Numéro et code type) proposés par la bibliothèque pour "Le Comte de MonteChristo" ?

Nous recherchons d’abord les médias qui ont un titre TITMED = ‘Le Comte de MonteChristo’. (sélection)

Puis, sur cette relation intermédiaire, nous allons faire une projection sur le numéro de média (COMED) et le code type (TYPMED) ; d’où R = ∏ COMED, TYPMED[σ TITMED = ‘Le Comte de MonteChristo’ (MEDIA)]

d) Quels sont les media (Numéro et libellé du type de média) proposés par la bibliothèque pour « Le Comte de MonteChristo ».

Nous recherchons d’abord les médias qui ont un titre TITMED = ‘Le Comte de MonteChristo’. (sélection)

Puis, nous allons faire, sur cette relation intermédiaire, une jointure naturelle avec TYPE MEDIA pour récupérer le libellé du type de média.

Puis, sur cette dernière relation intermédiaire, nous allons faire une projection sur le numéro de média (COMED) et le libellé type media (LIBTM).

D’où R = ∏ COMED, LIBTM[(TYPE MEDIA ⊳⊲ ( σ TITMED = ‘Le Comte de MonteChristo’ (MEDIA))]

e) Quels sont les titres des livres dont le prix d’achat d’un de ses exemplaires est supérieur à 25 € ? Nous savons que le TYPMED des livres est égal à ‘1’.

Il faut d’abord sélectionner les COMED des livres qui ont le TYPMED = ‘1’.

Puis, sur cette relation intermédiaire, il faudra effectuer une jointure naturelle avec EXEMPLAIRE sur le numéro de media (COMED).

Puis, sur cette relation intermédiaire, il faudra effectuer une sélection sur les tuples pour lesquels le prix d’achat PEXE >


25.

Enfin, sur cette relation intermédiaire, il faudra faire une projection sur l’attribut titre TITMED.

D’où R = ∏ TITMED(σ PEXE > 25 (EXEMPLAIRE ⊳⊲ ( σ TYPMED = ‘1’ (MEDIA)))).

L’arbre algébrique correspondant est le suivant :

f) Quels sont les adhérents qui n’ont pas encore effectué d’emprunt au 14/12/2008 ?

Nous sélectionnons, dans la relation EMPRUNT, tous les emprunts dont DATEMP < 14/12/2008.

Puis, nous faisons une projection sur la relation résultante sur l’attribut N°adhérent. Nous avons donc, tous les adhérents ayant fait des emprunts au 14/12/2008, dans la nouvelle relation résultante.

Nous allons en faire la différence de la projection sur NUADH d’ADHERENT, pour ne conserver que les adhérents n’ayant pas fait d’emprunt au 14/12/2008.

R = ∏ NUADH( ADHERENT) (∏ NUADH( σ DATEMP < ‘14/12/2008’(EMPRUNT))).

g) Quelles sont les adhésions qui ont été réglées le jour même de l’adhésion ?

Nous sélectionnons les tuples de la relation ADHESION pour lesquels DATREG (date de règlement) = DATADH (date adhésion).

R = ( σ DATADH = DATREG (ADHESION)).


Glossaire

Acteur externe

Entité externe au SI qui échange des flux avec celuici (et, au travers de celuici, aux acteurs internes).

Acteur interne

Entité interne au SI qui échange des flux avec d’autres acteurs externes ou internes.

Activités

Une activité appartenant à un domaine est constituée de 1 à n opérations élémentaires.

Association

C’est un lien unissant 2 ou n entités dans le schéma entitésassociations. Une association peut être porteuse de données. Elle est aussi appelée relation (nous parlerons alors d’un schéma entitésrelations).

Base de données relationnelle

Ensemble exhaustif et cohérent de schémas de relation.

Besoin des utilisateurs

Attentes des utilisateurs en termes de fonctionnalités, traitements et informations gérés par le futur Système d’Information.

Cahier des charges

Ce document décrit les besoins des futurs utilisateurs du Système d’Information, sur les domaines fonctionnels, organisationnels, ergonomiques et aussi de la sécurité.

Cardinalités (minimum, maximum)

Nombre de fois minimum et maximum qu’une occurrence d’une entité peut participer à une association.

Clé de relation

Une clé de relation est un attribut ou une composition minimale d’attributs dont chacune des valeurs permet de déterminer, d’une manière unique, un tuple de la relation.

DatawareHouse

"Un Datawarehouse est une collection de données orientées sujet, intégrées, non volatiles, organisées pour la prise de décision." Bill Inmon

DF

Deux données A et B sont en Dépendance Fonctionnelle (DF), si la connaissance de la valeur de A permet d’identifier une et une seule valeur de B.

DM

Dépendance Multivaluée dont la définition est :


Xà à Y (X multidétermine Y) < = = > ∀ la valeur prise par X,

∃ un ensemble de valeurs de Y : Ey


et


et


DMNT

Dépendance Multivaluée Nontriviale dont la définition est :

La DM X à à Y de la relation R est une DM NonTriviale si et seulement


ET

Si X ∪ Y ≠ R.

DMT

Dépendance Multivaluée Triviale dont la définition est :

La DM X à à Y de la relation R est une DM Triviale si et seulement

Si X est un sousensemble de Y

OU

Si X ∪ Y = R.

Dictionnaire de Données

Les données du SI sont présentées sous forme d’un tableau dont chaque ligne représentera une donnée et chaque colonne, une caractéristique de la donnée.

Domaine

Ensemble de valeurs.

Entité

Représentation d’un objet du monde réel.

Flux

Flux d’informations en entrée (coordonnées clients,…), intermédiaires (volume des déchets…), en sortie (prix de vente…) d’un Système d’Information.

Identifiant

Propriété particulière d’une entité qui permet d’identitifier chaque occurrence d’une manière unique.

LDD

Langage de Description des Données d’une Base de Données relationnelle (create, grant…)

LMD

Langage de Manipulation des Données d’une Base de Données relationnelle (select, update…).


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.

MOA


Maîtrise d’OuvrAge. Les (futurs) utilisateurs du Système d’Information sont appelés MOA, car ils sont commanditaires des travaux informatiques. Leur demande de travaux s’effectue via le cahier des charges.

MOE

Maîtrise d’Œuvre. La MOE, à partir du moment où elle accepte le contenu du cahier des charges de la MOA, va exécuter les travaux (développement informatique). Le cahier des charges est considéré comme un contrat qui lie la MOA et la MOE.

Modèle

Un modèle est une représentation schématique de la réalité qui facilite son appréhension, que ce soit par des personnes initiées ou non.

MCD

Dans Merise, Modèle Conceptuel des Données.

MCT

Dans Merise, Modèle Conceptuel desTraitements.

MDF

Matrice des Dépendances Fonctionnelles d’un SI. Matrice recensant toutes les données d’un SI et leurs relations via des dépendances fonctionnelles. Cette matrice permet de déterminer les données source de DF et les données cible de DF.

MLD

Dans Merise, Modèle Logique des Données.

MLT

Dans Merise, Modèle Logique des Traitements.

MOD

Dans Merise, Modèle Organisationnel des Données.

MOT

Dans Merise, Modèle Organisationnel des Traitements.

MPD

Dans Merise, Modèle Physique des Données.

MPT

Dans Merise, Modèle Physique des Traitements.

Occurrence (d’une entité)

Une représentation concrète (valorisée) d’une entité.

Opération Elémentaire

C’est une suite chronologique de tâches qui s’exécutent sans interruption.

Produit cartésien

Le produit cartésien de n domaines D1, D2,… Dn est l’ensemble des n_uplets <vD1, vD2,…vDn> tel que vDi appartienne


à Di. Ce produit cartésien est noté D1xD2x…Dn.

Relation

Une relation est un sousensemble du produit cartésien de n domaines (n>0). Une relation est un ensemble de tuples.

SAA Schéma d’Architecture Applicative

Représentation graphique des grandes fonctionnalités englobées dans le SI.

SAT Schéma d’Architecture Technique

Représentation graphique des éléments matériels et briques logicielles du SI.

SGBDR

Système de Gestion de Bases de Données Relationnelles : Oracle, DB2 d’IBM…

SI

Système d’Information.

Traitement en Temps Différé

Aussi appelé Batch, traitement informatique qui est planifié (par exemple, sauvegarde et duplication d’une base de données la nuit).

Traitement en Temps Réel

Aussi appelé TP (Transactionnel Process), traitement informatique qui met à jour le Système d’Information immédiatement.

Tuple

Un nuplet issu d’un produit cartésien de n domaines est un tuple.


algèbre relationnelle - guide pratique de conception d'une base de données relationnelle...

Documents