P.-A. Sunier 15 septembre Modélisation des données

Transcription

1 P.-A. Sunier 15 septembre Modélisation des données

2 Propos liminaires Table des matières 1 Propos liminaires Introduction Entreprise ou organisme Le SI Le SII Données et informations Données et valeurs de données La nécessité de structure Non redondance et qualité des données La démarche Méthode Modélisation UML Gestion et informatique Informatique de gestion Règle de gestion Modèle conceptuel de données (MCD) Historique Bases Entité Concept Représentation Attribut Type de données Domaine Valeur par défaut Identifiant Identifiant naturel Identifiant technique Attribut artificiel ou identifiant naturel Modification de valeur des attributs Contrainte d'unicité Attribut ou entité

3 Chapitre Problématique Divergences de saisie, redondance et bruit Jour et Date Entité de référence Discussion Association Concept Représentation Cardinalité Concept Cardinalités minimales Contraintes implicites Notation UML Notation Merise Notation graphique de Bachman Notation graphique de Barker (Oracle CASE tools) Double cardinalité 1..1 ou exactement Degré d'association Produit cartésien Association identifiante Association identifiante naturelle Association identifiante de composition Différences entre association identifiante naturelle et de composition Contrainte implicite Entité référencée au lieu d'attribut Note ou commentaire Entité indépendante Identifiant Identifiant technique Entité dépendante Identifiant Identifiant technique Entité associative Pseudo entité associative Entité dépendante n:n Généralisation & spécialisation Concepts de base

4 Propos liminaires Représentation conceptuelle Contraintes d intégrité Ensemble et sous-ensembles Partitionnement d ensemble Imbrication de généralisation - spécialisation Discussion Association réflexive Concepts de base Cardinalités Cardinalité minimale Cardinalité maximale Graphe Arcs Graphe non orienté Graphe orienté Arbre Cardinalités Ordonnancement des arcs Propriété des arcs Liste Cardinalités Propriété des arcs Couple Discussion Liste ou arbre Pas de bouclage Identifiants d entités et associations identifiantes Considérations générales Association identifiante naturelle Association n-aire Association n-aire au formalisme UML Simulation d'une association n-aire avec le stéréotype «CP» Simulation d'une association n-aire avec une entité dépendante Attribut multivalué Attribut dérivé Historisation Quel est le problème?

5 Chapitre Datation Concept de date er exemple ème exemple Traçabilité Prise en compte de l'historisation Contraintes formelles Contraintes implicites et contraintes formelles (ou explicites) Contraintes au format UML Contrainte de non modification {frozen} Contrainte d'ordonnancement {ordered} Contrainte de suppression en cascade {deletecascade} Contraintes {oriented} et {nonoriented} Contraintes logiques entre deux associations Bases Contrainte commutative "ou" {or} Contrainte commutative "ou exclusif" {xor} Contrainte commutative "non et" {nand} Contrainte commutative "et" {and} Contrainte commutative "équivalence" {<=>} ou {eqv} ou {not xor} Contrainte commutative "non ou" {nor} ou {not or} Contrainte non commutative "implication" {=>} ou {imp} Contrainte non commutative "inhibition" {inh} Synthèse des contraintes Contraintes ensemblistes entre deux associations Bases Contrainte commutative de disjonction {disjoint} Contrainte non commutative d'inclusion {subset} Contraintes sous forme d invariant OCL Bases Contrainte de boucle Contrainte de boucle incluse Contrainte de convergence Contraintes sous forme d opérations UML Bases Contrainte commutative d'égalité de taille de deux ensembles de données {sizesetequality}

6 Propos liminaires Cumul de contraintes Création de domaines personnalisés Discussions - Cas particuliers Pseudo entité associative Association n:n et/ou entité dépendante Contrainte implicite Attribut de l'entité associative Règles de nommage Noms prédéfinis Synthèse des éléments du profil UML Synthèse des stéréotypes Synthèse des contraintes Portée des modèles Problématique Exemple Modèle existant Modèle idéal Modèle réel (futur système) Maquettes Objectif Portée Le langage de contraintes OCL Positionnement d'ocl Exemple de diagramme de classe Invariant Valeur initiale d'attribut Attribut dérivé Contexte Adressage explicite - self Navigation Navigation d'une entité vers un attribut Navigation d'une entité vers une extrémité opposée d'association Navigation d'une entité vers une entité associative Navigation d'une entité vers une entité associative par une association réflexive Navigation d'une association vers une extrémité Navigation et cardinalités maximales

7 Chapitre Collections Concept Opérations de collections select() et reject() collect() forall() exists() closure() iterate() Autres opérations Eléments complémentaires Remarques let - Variable locale def - Variable globale Structure de test allinstance() Modèle logique relationnel de données (MLD-R) Historique Bases Table Concept Représentation Colonne Type de données Clé primaire Clé étrangère Clé secondaire Identifiant naturel Contrainte Valeur non nulle Unicité Clé primaire Clé étrangère Représentation graphique de la contrainte de clé étrangère Cardinalité Degré de relation Table indépendante

8 Propos liminaires 7.11 Relation identifiante Table dépendante Table associative Relation réflexive Traçabilité Colonnes d'audit Journalisation Stratégie de traçabilité Règles de nommage Noms prédéfinis Normalisation et formes normales Quel est le problème? Bases ère forme normale (1NF) NF - Colonne formée d une relation NF - Colonne contenant un groupe répétitif ème forme normale (2NF) Dépendance fonctionnelle Dépendance fonctionnelle élémentaire pleine NF ème forme normale (3NF) Dépendance fonctionnelle directe Clé secondaire unique et non nulle «UID-i» Problématique Table indépendante Tables dépendantes En résumé NF - Colonne dépendant d'une autre colonne NF - Colonne dépendant d'une clé étrangère Autres formes normales Forme normale de Boyce-Codd (BCNF) Règle de normalisation Illustration Exemple ème forme normale (4NF) et 5 ème forme normale (5NF) Dépendance multivaluée Exemple

9 Chapitre Redondances "horizontales" Définition Règle de normalisation Exemple Critères de détermination de redondance Colonnes redondantes Définition Règle de normalisation Exemple Bilan Dénormalisation Quel est le problème? Principe général Exemple Evénements d'états Evénements temporels Stratégies de calcul des éléments dénormalisés Régime normal En cas de panne Tables propres aux éléments dénormalisés Modalités de mise en place Les vues pour éviter des calculs fastidieux Modalités de mise en place Transformation conceptuel -> logique relationnel MLD : Contraintes structurelles ou contraintes déclaratives MCD : Idéal ou réel Transformation avec contraintes structurelles Concept Règles de base Première règle Deuxième règle Troisième règle Index de performance Règles de structures particulières Entité associative Entité dépendante Pseudo entité associative

10 Propos liminaires Généralisation - spécialisation Associations réflexives Entité dépendante n:n Stéréotype «CP» de simulation d'une dimension du produit cartésien Attribut multivalué Processus de transformation itératif Principe Initialisation Traitement itératif des dépendances Finalisation Transformation avec contraintes déclaratives Concept ème règle de base Association de degré n:n Entité associative Entité dépendante Pseudo entité associative Généralisation spécialisation Associations réflexives Graphes Arbres & listes Entité dépendante n:n Attribut multivalué Index Bibliographie

11 Chapitre 1 1 Propos liminaires Le cours a trait à la modélisation des données relevant du système d'information informatisé des entreprises ou organismes dans un sens plus large. Les illustrations sont réalisées avec l'atelier de génie logiciel Visual Paradigm i, VP en abrégé. Les modèles conceptuels de données, MCD en abrégé, sont réalisés à partir du méta modèle de classes d'uml. Les spécificités du MCD sont décrites par un profil; elles sont réalisées à l'aide des mécanismes d'extension d'uml: - Stéréotypes - Valeurs marquées Pour certains éléments, nous expliciterons d'autres notations, plus ou moins couramment utilisées, comme celle issue de la méthode Merise. Les modèles logiques relationnels de données, MLD ou MLD-R en abrégé, sont réalisés de deux manières: - à partir du méta modèle de classes UMLet en utilisant les mécanismes d'extension décrits plus haut; - à partir du méta modèle Entity Relationship de VP. 11

12 Introduction 2 Introduction La modélisation des données des systèmes d'information (SI) des entreprises ou organisation nécessite de comprendre ou se mettre d'accord sur ce qu'est une entreprise, un système d'information, une donnée et un modèle; cette introduction va fixer notre vision de ces différents éléments. 2.1 Entreprise ou organisme Une entreprise est un système social qui a comme finalité de produire des biens ou des services à but commercial. Comme tout système social, chaque entreprise doit s'organiser pour réaliser sa finalité et atteindre son but; il s'agit, essentiellement, de coordonner les activités humaines, matérielles ou autres nécessaires à produire les biens ou services dans des conditions économiques viables. Figure 1 - Entreprise [Plus de détails en PAS-2] 2.2 Le SI Le concept de système d'information (SI) de l'entreprise trouve son origine dans l'approche systémique de l'étude des systèmes sociaux et autres. L approche systémique nous propose de considérer l entreprise, en tant que système social, formé de trois sous-systèmes essentiels. le sous-système opérant (SO) qui active les processus métier pour créer la valeur ajoutée. le sous-système de pilotage (SP) qui coordonne l ensemble de l activité en fonction de la mission. le sous-système d'information qui capte, mémorise, traite et restitue les informations utiles aux sous-systèmes opérant et de pilotage ainsi qu'à l'environnement. Figure 2 - Entreprise système [Plus de détails en PAS-2] 12

13 Chapitre Le SII Technologie Le SII ou système d'information informatisé est la partie du SI de l'entreprise qui est automatisée grâce aux technologies de l'information. IT SII SI Le SII doit permettre des gains de productivité et/ou d'efficience en optimisant l'organisation de l'entreprise grâce à la circulation des informations. Organisation Figure 3 - Système d'information informatisé Le SII doit permettre de capter, de mémoriser, de traiter et de restituer les informations ou données utiles à l'entreprise de manière transparente 1 pour les utilisateurs. [Plus de détails en PAS-2] 1 S'agissant des aspects techniques 13

14 Introduction La partie informatisée du système d'information de l'entreprise, son organisation et son rôle peuvent être représentés par le diagramme symbolique ci-dessous. SP SO 3 Figure 4 - Représentation symbolique du SII Entreprise Système de pilotage (SP) Système opérant (SO) Système d'information (SI) Système d'information informatisé (SII) Partie dynamique du SII Partie statique du SII Acquisition/restitution de données/informations Stockage (pérennisation) des données Traitement des données 14

15 Chapitre Données et informations Une information est le résultat d'un traitement appliqué à des données. Une information est une production sociale qui présente une ou des données selon un point de vue. La ou les données représentent l'aspect statique, les traitements représentent l'aspect dynamique du processus de production d'information Figure 5 - Données et informations [Plus de détails en PAS-3] 15

16 Introduction 2.5 Données et valeurs de données Dans l'optique des systèmes d'information de l'entreprise, lorsque nous parlons de données, il s'agit de conteneurs; chaque donnée ou plus précisément chaque conteneur peut contenir de multiples occurrences de même nature. Par exemple, pour une école nous avons des salles; chaque salle peut avoir un nom, se situer sur un étage d'un bâtiment, contenir un certain nombre de places. Salle Pascal, 1 er étage Einstein, 1 er étage, 30 places Descartes, 3 ème étage, 50 places l Galilée, 2 ème étage, 30 places Figure 6 - Ensemble des salles d'une école La salle Einstein de 30 places située au 1 er étage est une occurrence de l'ensemble des salles. Lorsque la littérature parle de la dimension statique du système d'information (SI) à propos des données, l'aspect statique a trait aux conteneurs, les données, et non aux occurrences qui peuvent être ajoutées, modifiées ou supprimées. La donnée Salle d'une école est statique, nous aurons toujours besoin de salles identifiées par un nom, dotées de places et situées sur un étage spécifique; par contre, au fil du temps, des salles peuvent être ajoutées, modifiées ou supprimées. Figure 7 - Voiture ou image d'une voiture? Dans le langage courant, nous ne faisons pas de différence entre donnée (un élève) et valeur de donnée (l'élève Rouge Marc) ou entre nature de donnée (les élèves) et donnée (l'élève Rouge Marc); en général, nous parlons de données et selon le contexte nous en déduisons sa portée. Il en est de même dans une multitude d'autres situations; en regardant un catalogue de voiture, nous parlons de voiture mais, en fait c'est une image et non le véhicule physique ou réel avec lequel nous pouvons nous déplacer. 16

17 Chapitre La nécessité de structure Pour toute entreprise, ses données sont un patrimoine essentiel; une entreprise commerciale ne saurait perdre les données de ses clients ou encore de ses débiteurs; une école ne saurait perdre ses élèves ou les résultats de ceux-ci acquis lors de session d'examens. Pour ne pas perdre quelque chose ou le retrouver aisément, dans notre vie de tous les jours nous nous organisons en conséquence. C'est ce que nous faisons lorsque nous organisons le rangement de notre logement. Chaque pièce est dotée d un ou plusieurs emplacements pour y mettre les éléments appropriés : les produits laitiers au frigo, les surgelés au congélateur, les fruits dans le bahut du balcon, les pulls dans l armoire de la chambre, les pantalons dans la penderie, etc. Figure 8 Dans le même ordre d'idée et avant l'informatisation, les entreprises ont organisé leurs données; celles-ci sont regroupées au sein d'armoires, de classeurs ou encore de dossiers. Pour que tout collaborateur puisse trouver les données recherchées, les divers conteneurs sont dédiés à une nature de données, par exemple les dossiers de notes des élèves; les conteneurs de données sont étiquetés pour faciliter l'accès à tout en chacun. Figure 9 Les armoires, classeurs, dossiers ou autres éléments de rangement des données de l'entreprise représentent l'aspect statique du traitement de l'information. Le collaborateur qui recherche, classe, modifie, ajoute ou encore supprime du contenu représente l'aspect dynamique du traitement de l'information. Les armoires ou tiroirs de notre logement d'un côté ou les armoires, classeurs ou dossiers d'une entreprise d'un autre côté sont des éléments physiques qu'il est aisé d'identifier et de visualiser; il n'en est malheureusement pas de même pour les données d'un système d'information informatisé (SII) car les conteneurs sont immatériels. Pour résoudre ce problème d'immatérialité des systèmes d'information informatisés, il est recommandé de faire des modèles de données qui représentent la structure des données. 17

18 Introduction Pour définir une structure des données, nous devons préalablement recenser les données 2 qui devront être stockées ou enregistrées et les grouper par données de même nature; pour l aménagement de notre logement, nous devrons prévoir une armoire pour les chaussures, une pharmacie pour les médicaments, une commode pour les sous-vêtements et les chaussettes 3, etc. En fait, nous allons appliquer l adage «Une place pour chaque chose et chaque chose à sa place». Pour l aménagement de notre logement, une place sera le troisième tiroir de la commode dans lequel nous rangerons nos chaussettes et une chose sera la paire de chaussettes bleues avec un dessin de soleil sur le côté ; naturellement, dans ce tiroir (place) nous mettrons encore d autres chaussettes (choses de même nature). Pour l aménagement d une structure de données nous procéderons de la même manière, nous recenserons les différentes données qui devront être stockées et les organiserons en données de même nature que nous nommons : donnée; chaque donnée est un conteneur de stockage. 2.7 Non redondance et qualité des données La redondance est le fait de multiplier une ressource pour éviter une défaillance en cas de panne. Au niveau des composants matériels et logiciels de tout ou partie d'un système d'information informatisé, de nombreuses ressources, on parle plutôt de composants, sont redondantes pour éviter une défaillance et/ou pour répartir une charge de travail. Au niveau des données, ou plus précisément au niveau de la structure de données d'un système d'information d'entreprise, la redondance est une source de confusion. Si une donnée est redondante, tout se passe correctement tant que les différentes valeurs sont identiques; par contre, si les valeurs divergent, l'utilisation de deux valeurs différentes va produire 4 des résultats contradictoires. Concepteurs Pas de redondance Pas de bruit Figure 10 - Qualité des données Utilisateurs Fiabilité du SII Lorsque nous parlons de qualité des données, nous nous plaçons dans la perspective des utilisateurs mais aussi dans celle des concepteurs 5 de systèmes d'information; les utilisateurs doivent pouvoir produire et utiliser de l'information fiable. Pour que l'information produite par les systèmes d'information soit fiable il est impératif que les concepteurs puissent s'appuyer sur des données exemptes de redondances qui sont sources de contradictions. 2 Pour être plus précis, il s'agit de recenser des instances de données et parmi ces instances, nous pouvons en identifier comme étant de même nature. 3 Chacun peut décider en fonction de ses contraintes, souhaits ou autres goûts quels tiroirs accueilleront quels habits. Il en est de même pour la modélisation des données, il y a autant de structures différentes qu'il y a de clients et de besoins différents. 4 Comme nous l'avons vu [2.4], les données sont la matière première de production de l'information et si la matière première n'est pas de qualité, l'information déduite ne sera pas fiable. 5 Concepteurs au sens large, c'est-à-dire tous les acteurs de la maîtrise d'œuvre. 18

19 Chapitre La démarche Méthode La modélisation des données doit s'inscrire dans une démarche méthodologique permettant d'offrir aux utilisateurs 6 les services attendus en garantissant la fiabilité des traitements et la pérennité des données. De nombreuses méthodes ont été proposées au fil du temps pour atteindre cet objectif de qualité que sont: - la fiabilité des traitements; - la pérennité des données. S'agissant de la pérennité des données qui est concernée par ce cours et comme nous l'avons écrit précédemment, il est indispensable de recenser les données et de les représenter aux travers de modèles de données. Pour ce faire, nous nous appuierons, de manière complémentaire, sur deux éléments méthodologiques reconnus: - les modèles de cas d'utilisation d'up ii pour affiner la réflexion de détermination des cardinalités minimales des associations [Chapitre ]. - les maquettes d'interface utilisateurs; les maquettes sont utilisées pour valider un modèle de données auprès des utilisateurs en mettant l'accent non pas sur les aspects techniques du modèle mais, sur ce que le modèle représente en terme d'opportunités et de contraintes de traitement 7 des données Modélisation La modélisation va nous permettre de mettre en forme le recensement des données et de pallier à l'immatérialité des systèmes d'information informatisés en fournissant une représentation de la structure des données sous forme de modèles. Figure 11 Les modèles sont des représentations d'une réalité exprimée selon un point de vue. Les modèles de données représentent plus ou moins abstraitement la réalité. Au niveau le plus abstrait, nous avons un modèle que nous nommons conceptuel (MCD); comme son nom l'indique, il s'attache aux concepts. En reprenant notre exemple de rangement de logement, ce serait de dire qu'il nous faut un espace de rangement pour les chaussettes et un autre pour les pulls. Ensuite, nous trouvons un modèle que nous nommons logique (MLD); il définit une architecture ou une technologie d'enregistrement des données: en reprenant notre exemple, ce 6 Utilisateurs des fonctionnalités du système d'information informatisé. 7 Traitement au sens large incluant, l'acquisition, le stockage, la restitution en plus du traitement de calcul. 19

20 Introduction serait un tiroir de commode pour les chaussettes et un espace d'armoire pour les pulls. Actuellement, en informatique de gestion, l'architecture usuelle est celle des bases de données relationnelles (MLD-R) mais, il en existe d'autres comme les bases de données orientées objet, les bases de données XML ou le recours à de simples fichiers. Et enfin, nous trouvons un modèle que nous nommons physique (MPD); il s'attache aux contingences de réalisation liées souvent à un constructeur particulier; en reprenant notre exemple, ce serait les détails de fabrication (dimensions, matériaux, couleurs ) de notre commode ou de notre armoire UML UML est un langage de modélisation. C'est actuellement, le seul langage de modélisation qui n'est pas propre à une technologie ou à un constructeur/éditeur. Figure 12 UML permet de représenter: - Les besoins des utilisateurs. - Les aspects dynamiques d'un système d'information. - L'aspect statique d'un système d'information. UML est extensible grâces aux mécanismes suivants: - Les stéréotypes. - Les valeurs marquées. - Les contraintes. Une utilisation particulière d'uml peut être guidée et contrôlée grâce au mécanisme de profil. Remarque: Depuis UML 2, les stéréotypes et valeurs marquées ne sont disponibles qu'au travers d'un profil. 20

21 Chapitre Gestion et informatique Gestion d'une part et informatique d'autre part peuvent être associés à la représentation systémique de l'entreprise. La gestion recouvre essentiellement les activités qui ont trait au sous-système de pilotage. L'informatique est une technologie permettant d'automatiser certaines parties du système d'information. Figure 13 - Entreprise système Informatique de gestion Nous proposons, ci-après, une définition de l'informatique de gestion extraite d'un article que nous avons publié en [PAS-4] L informatique de gestion recouvre les connaissances et compétences qui se trouvent à l intersection des disciplines de l informatique et de la gestion. Mais quelle est la signification ou la portée des termes que sont l informatique d une part et la gestion d autre part. Selon [1] Le terme «informatique» est un néologisme construit à partir des mots «information» et «automatique» par P. Dreyfus en Il s'agit donc d'une discipline qui concerne le traitement automatique de l'information. La définition acceptée par l'académie Française est la suivante : "science du traitement rationnel, notamment par machines automatiques, de l'information considérée comme le support des connaissances humaines et des communications dans les domaines techniques, économiques et sociaux". Selon [2], le terme de «gestion» signifie : Action d administrer, d assurer la rentabilité (d une entreprise) ; [3] le définit comme : Action de gérer (les affaires d un autre, et par extension ses propres affaires) et «gérer» est défini comme : Administrer (les intérêts, les affaires d un autre). 21

22 Introduction A partir des éléments ci-dessus, nous proposons la définition suivante de l informatique de gestion : L informatique de gestion est la discipline du traitement de l information utile et nécessaire à automatiser tout ou partie de l administration des intérêts ou des affaires des entreprises 8. La définition ci-dessus implique que l informatique est au service de la gestion et non l inverse ; pour reprendre une phrase de notre ancien directeur, J.-P. Gindroz : «L informatique doit couler dans le sillon 9 de la gestion et non l inverse» Règle de gestion Une règle de gestion est une contrainte qui s'applique à une action, à une activité ou encore à un processus de l'entreprise. Une règle de gestion peut provenir de l'environnement ou être énoncée par l'entreprise. Une règle de gestion peut s'appliquer aux sous-systèmes opérant, de pilotage ou d'information. Si une règle de gestion s'applique à un élément du système d'information informatisé (SII), elle doit être transformée en une contrainte 10 concrète exprimée au sein dudit SII. Une règle de gestion est aussi nommée règle métier; la règle métier a une connotation plus orientée sous-système opérant 11 mais, de prime abord, nous pouvons considérer les deux termes comme identiques. 8 La notion d entreprise peut être étendue aux individus et aux organismes au sens large 9 Toute la difficulté de l activité de direction est de maintenir le cap du sillon afin que gestionnaires et informaticiens convergent vers un but identique. 10 Contrainte au sens très large qui peut être simplement le type et la taille d'un attribut. 11 Une règle impactant le sous-système opérant directement ou par l'intermédiaire de l'un ou l'autre des deux sous-systèmes de pilotage ou d'information. 22

23 Chapitre 3 3 Modèle conceptuel de données (MCD) 3.1 Historique Dans le monde francophone, le Modèle Conceptuel de Données (MCD) a été proposé par H. Tardieu et consorts au milieu des années 1970 en tant qu'élément de la méthode Merise issue du courant systémique. Un modèle équivalent a été proposé à la même époque dans le monde anglo-saxon; il s'agit du modèle Entity-Relationship de Chen et autres. Le modèle conceptuel de données (MCD) tel que nous le présentons ici s'attache à la structure statique du système d'information et est implanté par un système de gestion de base de données 12. Dans l'approche de développement de l'aspect dynamique du SII basée sur la technologie orientée objet, il est préconisé 13 de réaliser un modèle des objets métier dit modèle du domaine; le modèle du domaine est proche du MCD mais il est une image au sein de l'aspect dynamique (Point 6 de la Figure 4) des données statiques (Point 7 de la Figure 4). 3.2 Bases Un modèle conceptuel de données est conçu à partir des éléments suivants: - 1 Les entités qui représentent des conteneurs de données. - 2 Les associations qui représentent des conteneurs de liens entre données. - 3 Les cardinalités qui fixent les modalités de réalisation des liens entre données. - 4 Les attributs d'entités ou d'associations qui représentent des conteneurs de données élémentaires Figure 14 - Bases du MCD Remarque: Les entités sont des conteneurs de données agrégées; les attributs en sont les différentes parties ou éléments. Lorsque l'on parle de données, il y a toujours besoin de référer au contexte pour savoir s'il s'agit d'entité ou d'attribut. 12 Ou, exceptionnellement, en recourant à de simples fichiers. 13 Entre autres, par la méthode UP de Booch, Rumbaugh et Jacobson 23

24 Modèle conceptuel de données (MCD) 3.3 Entité Concept Une entité est un ensemble d'éléments de même nature; les différentes salles d'une école pour notre exemple de la Figure 15. Une entité porte un nom qui différentie les entités entre elles; pour notre école, nous aurions aussi l'ensemble des étudiants, des cours, des matières Salle Pascal, 1 er étage Einstein, 1 er étage, 30 places Descartes, 3 ème étage, 50 places l Galilée, 2 ème étage, 30 places Figure 15 - Ensemble des salles d'une école Représentation Une entité est représentée très couramment par un rectangle séparé en 2 parties: - La partie du haut contient le nom de l'entité. Le stéréotype «MCD» indique que le rectangle 14 UML est considéré comme une entité. - La partie du bas contient les attributs de l'entité. Figure 16 - Entité Salle représentant l'ensemble des salles d'une école 14 Il s'agit d'une classe en UML. 24

25 Chapitre Attribut Un attribut représente une propriété de l'entité; l'attribut etage représente l'étage où se trouve une salle dans le bâtiment de notre école de l'exemple de la Figure Un attribut porte un nom qui le différencie des autres propriétés de l'entité. - Un attribut est une donnée élémentaire caractérisée par un type ou un domaine de validité. Selon le type de données, chaîne de caractères ou numérique, une taille maximale peut être définie; pour les valeurs numériques avec fraction, la taille maximale de la partie décimale peut aussi être définie. - Un attribut peut être obligatoire, stéréotype «M» pour Mandatory, ou optionnel (sans le stéréotype «M») Type de données Les données élémentaires que sont les attributs sont caractérisées par un type de données. Un type de donnée définit, plus ou moins universellement, une nature de donnée. Pour ce cours, nous nous appuyons sur les types de données définis par le W3C et que nous avons complétés. Les modèles représentant les types de données sont des méta modèles (des modèles qui spécifient d'autres modèles). Les modèles de type de données sont des modèles de classes usuels formalisés par UML. 1 Dans les définitions des types de données qui suivent, le type Type 1 est abstrait seul les types spécialisés 2 sont utilisables. 2 3 La relation 3 entre Type et boolean est une spécialisation; cela signifie que boolean est une sorte de Type. Figure Valeur logique Figure 18 - Type boolean Une valeur logique ou booléenne est utilisée pour un attribut qui ne contient que des valeurs vraies ou fausses. 25

26 Modèle conceptuel de données (MCD) Valeur textuelle Figure 19 - Type texte La pratique courante est d'utiliser le type string; toutefois, lorsqu'un attribut ne permet pas d'espace, le type word est plus approprié. Si un espace ou des espaces 15 peuvent exister, le type token est plus approprié. Par habitude, nous avons certainement l'un ou l'autre attribut dans nos exemples qui sont de type string alors qu'ils devraient être spécialisés en token ou word. 15 Mais, sans répétition. 26

27 Chapitre 3 Le type sequenceanystring est défini comme type memo ou text par certains auteurs ou éditeurs. Il est utilisé lorsqu'un attribut doit être formaté comme par exemple une adresse. Figure 20 - Utilisation de types d'attributs Le tableau ci-dessous donne un exemple de valeurs pour différents attributs d'un membre d'une société. Attribut mnemo nom prenom Valeur CRC de Carré Rouge adresse Rue de Neuchâtel 2b 2025 Chez le Bart datenaissance - cotisant Tableau 1 - Attribut adresse de type sequenceanystring oui decarre.rouge@gareferroviaire.ch Le type sequenceanystring est à utiliser avec prudence. Une donnée de type sequenceanystring peut contenir plusieurs données élémentaires, en relation entre elles ou pas, et être source de redondances. Pour notre exemple, il y aurait des problèmes si nous devions rechercher tous les membres habitant une localité précise. Le premier problème est de nature technique, il est nécessaire de faire un traitement de chaîne qui peut s'avérer compliqué et aléatoire pour retrouver au sein de celle-ci une localité. Le deuxième est de nature sémantique, si nous recherchons dans l'attribut adresse de notre exemple ci-dessus, les membres habitant Neuchâtel, nous allons retrouver De Carré Rouge qui habite à Chez le Bart mais rue de Neuchâtel. Dans ce cas, la rue de Neuchâtel induit du bruit et fausse les résultats de recherche tout comme vous le connaissez avec les moteurs de recherche sur Internet. 27

28 Modèle conceptuel de données (MCD) Une première ébauche de solution consiste à séparer l'attribut adresse en deux attributs rueno d'une part et localite d'autre part comme illustré ci-après. Attribut Valeur mnemo CRC nom de Carré prenom Rouge rueno Rue de Neuchâtel 2b localite 2025 Chez le Bart datenaissance - cotisant oui decarre.rouge@gareferroviaire.ch Tableau 2 - adresse éclatée en deux attributs Notre exemple incite à ne choisir que la solution du Tableau 2; toutefois, le choix de conserver ou pas un attribut de type sequenceanystring dépend de la seule question de savoir si cet attribut doit être considéré comme atomique 16 ou pas. En finalité: Si, l'attribut adresse du Tableau 1 n'est créé que pour effectuer des envois postaux et uniquement pour cela, le type sequenceanystring est approprié. Si, un besoin de recherche de localité ou autre au sein de l'attribut adresse du Tableau 1 est envisageable, le type sequenceanystring n'est pas approprié; cet attribut doit être affiné et une première ébauche d'affinage consiste à le séparer en rueno et localite (Tableau 2). 16 Est atomique, un élément que l'on ne veut ou que l'on ne peut plus décomposer. 28

29 Chapitre Valeur numérique Figure 21 - Type décimal Un type numérique ne doit être utilisé que pour des attributs sur lesquels des opérations arithmétiques peuvent s'appliquer; un attribut peut être représenté par des caractères numériques sans pour autant représenter une valeur numérique. 29

30 Modèle conceptuel de données (MCD) Un code postal est un bon exemple de représentation numérique sans signification arithmétique; en effet, un code postal est un élément qui permet de trier du courrier ou des colis et une opération comme l'addition de deux codes postaux n'a aucun sens. En ce qui nous concerne, nous évitons d'utiliser le terme de numéro lorsqu'il s'agit d'un attribut composé de caractères numériques sans signification arithmétique et privilégions le terme de code. A propos du code postal utilisé en Suisse et repris de [WP-01]: En 1964, La Poste suisse a introduit le numéro postal d'acheminement (NPA) après la poste allemande Deutsche Bundespost et américaine United States Postal Service. En Suisse, les numéros se composent de quatre chiffres. Comme dans le système allemand, une commune peut avoir plusieurs NPA. Qu'une localité possède son propre NPA ne veut pas dire qu'il s'agit d'une commune politiquement autonome. Le même NPA peut être aussi utilisé par différentes communes (exemples : 1227 comprend un quartier de Genève - Les Acacias - et la commune de Carouge ; 3048 Worblaufen, comprend des parties de Berne et d'ittigen). Même si nous privilégions le terme de code (Figure 22) à celui de numéro lorsqu'il s'agit d'un attribut composé de caractères numériques sans signification arithmétique, le poids de l'habitude, des coutumes ou des traditions nous amène en certaines situations à utiliser le terme de numéro (Figure 23) pour faciliter le dialogue avec les utilisateurs. Figure 22 - Code postal Figure 23 - Numéro postal d'acheminement (NPA) 30

31 Chapitre Valeur temporelle Figure 24 - Type temporel 31

32 Modèle conceptuel de données (MCD) Tailles maximales Lors de l'attribution d'un type à un attribut, nous avons vu que pour certains types il y a lieu de définir une taille maximale. La définition de la taille maximale d'un type de données étant essentiellement un problème de choix de modélisation, nous y reviendrons plus en détail lors de la mise en œuvre avec Visual Paradigm Données non structurées La modélisation des données s'est longtemps attachées aux seules données dites structurées. Pour faire simple, les données structurées sont celles qui sont définies par les types présentés ci-avant hormis sequenceanystring qui est un type de données non structuré. En plus de sequenceanystring, nous pouvons citer les types non structurés potentiels suivants: - image ; une image. - video ; un enregistrement vidéo. - sound ; un enregistrement sonore. Nous affinerons ce chapitre dans une prochaine version Donnée atomique Tout attribut doit être une donnée atomique dans la perspective du système d'information considéré. Comme nous l'avons vu au chapitre , l'atomicité n'est pas quelque chose d'absolu; l'atomicité des attributs est déterminée par l'usage qu'il en sera fait. En reprenant notre exemple d'adresse précédent, nous avons un attribut rueno qui contient la rue et le numéro de rue. Attribut mnemo nom prenom rueno Valeur CRC de Carré Rouge Rue de Neuchâtel 2b localite 2025 Chez le Bart datenaissance - cotisant Tableau 3 - Rue & no de rue dans le même attribut oui decarre.rouge@gareferroviaire.ch Cet attribut RueNo peut être considéré comme atomique tant que nous ne devons pas traiter séparément la rue et le numéro, que ce soit pour une recherche ou autre. 32

33 Chapitre 3 Si nous devons devoir traiter précisément une rue d'une part et les entrées d'immeuble 17 de cette rue d'autre part, il faut séparer, atomiser, cet attribut en deux attributs plus précis comme illustré ci-dessous. Attribut mnemo nom prenom rue norue localite Valeur CRC de Carré Rouge Rue de Neuchâtel 2b 2025 Chez le Bart datenaissance - cotisant oui decarre.rouge@gareferroviaire.ch Tableau 4 - Rue & no de rue séparés Domaine Un domaine est une spécialisation de type de données Domaines prédéfinis Pour ce cours, nous avons prédéfini les 3 domaines suivants : , httpurl et xml Figure 25 - Domaines prédéfinis Le modélisateur peut créer ses propres domaines [Chapitre 3.20]. 17 Dans la plupart des cas, les numéros de rue correspondent à des entrées d'immeubles qui sont les objets réels que nous modélisons. 18 Types de données et domaines sont des concepts qui peuvent être identiques ou pas selon les auteurs; dans le cadre de ce cours, nous réservons la notion de type de domaine pour la classification de base (repris du W3C) et la notion de domaine pour une spécialisation de ces types de bases. 33

34 Modèle conceptuel de données (MCD) Valeur par défaut Une valeur par défaut peut être assignée à un attribut; naturellement, la valeur par défaut doit être conforme au type ou au domaine de l'attribut. Figure 26 - Valeur par défaut d'un attribut Une valeur par défaut peut aussi être assignée en recourant à une expression; nous nous appuierons sur le langage OCL iii pour spécifier des expressions logiques, numériques, temporelles ou textuelles [Chapitre 6]. 34

35 Chapitre Identifiant Un identifiant est formé d'un ou plusieurs attributs qui permettent de distinguer une et une seule occurrence d'entité parmi l'ensemble des occurrences. Les attributs constitutifs d'un identifiant ne doivent pas être stéréotypés «M» car ils le sont implicitement par leur stéréotype identifiant «UID-x» ou «PK» expliqué par la suite. Important: Un identifiant est obligatoirement discriminant, il permet de distinguer sans ambigüité une et une seule occurrence d'entité parmi l'ensemble des occurrences. Lorsqu un identifiant naturel est formé de plusieurs attributs, il y a toujours au moins un attribut qui est renseigné pour une occurrence d entité mais cet attribut peut varier au gré des enregistrements. Si un ou plusieurs attribut constitutif Identifiant naturel Un identifiant est qualifié de naturel lorsque les attributs qui le constituent proviennent des propriétés de l'ensemble que nous voulons représenter. [Voir au chapitre , la définition d'attribut artificiel ou technique]. Figure 27 - Entité Salle dotée d'un identifiant naturel La ou les colonnes constitutives d'un ou de plusieurs identifiants naturels sont stéréotypés «UID-x»; x est une valeur allant de 1 à n; x vaudra 1 pour le 1 er identifiant, 2 pour un éventuel deuxième et ainsi de suite jusqu'à n. Pour notre exemple, les salles sont identifiées par l'attribut nom; le nom de chaque salle est repris du nom d'un savant illustre [Figure 6]. Par défaut, les attributs constitutifs d un identifiant naturel sont obligatoires; toutefois, l un ou l autre attribut, peut être optionnel, stéréotype «O» en plus de «UID-x», pour autant qu il y en ait au moins un obligatoire. Remarque : Nous n avons pas d exemple de stéréotype «O», car, à priori, si le modèle est correctement réalisé, le besoin d attribut identifiant optionnel ne se présente pas Interface utilisateur Par opposition à l'attribut artificiel qui sert d'identifiant technique, le ou les attributs qui servent d'identifiants naturels sont éditables en ajout, modification et autres opérations car: - en général, les utilisateurs en détiennent la valeur; - le sens qu'ils véhiculent peut changer et nécessiter une mise à jour; - une erreur de saisie doit pouvoir être corrigée. 35

36 Modèle conceptuel de données (MCD) Identifiant naturel Figure 28 - Maquette de modification d'une salle Identifiant technique En certaines situations, il peut être impossible ou difficile de disposer d'attributs susceptibles de discriminer sans ambigüité chaque élément d'un ensemble; c'est le cas des étudiants pour l'école de notre exemple. En effet, s'il est souvent possible d'identifier un étudiant avec son nom, son prénom ou les deux, il n'est pas possible de garantir l'unicité de cette identification 19 ; il peut très bien y avoir deux étudiants de même nom et prénom dans une école. Il est possible de rajouter la date de naissance à l'identification; nous repoussons le risque de doublon mais ne pouvons, toujours pas, garantir la suppression du risque; nous pourrions imaginer d'autres attributs qui repoussent encore le risque de doublon mais, sans jamais permettre de le supprimer. Dans cette situation, il y a lieu de créer un attribut artificiel qui aura une valeur unique pour chaque élément de l'ensemble; pour chaque étudiant parmi l'ensemble des étudiants de l'école de notre exemple. Cet attribut artificiel peut être géré automatiquement par un système de gestion de base de données relationnelle si cette technologie est utilisée pour la gestion des données. Dans cette perspective, il est usuel d'ajouter dans le modèle conceptuel, cet attribut artificiel ou technique qui servira ensuite de clé primaire pour le modèle logique relationnel [Voir le chapitre 7.5]. 1 L'attribut artificiel ou technique qui sert de clé primaire 1 est: - nommé num; - marqué du stéréotype «PK» iv ; - de type positiveinteger 20. Figure 29 - Entité Etudiant dotée d'une clé primaire Remarque: Souvent, nous ne typons pas l'attribut artificiel servant de clé primaire car le type positiveinteger est implicite. 19 Surtout si l'on prend en compte la nécessité de garder la trace des étudiants au fil du temps. 20 Le type positiveinteger est un choix élégant, au niveau conceptuel, permettant de ne prendre en compte que des valeurs positives entières mais, au niveau du stockage interne des données, nous recourons au type ancêtre integer. 36

37 Chapitre Interface utilisateur L'attribut artificiel qui sert d'identifiant technique doit être traité de manière différente selon qu'il s'agit de l'ajout d'une occurrence d'entité ou des autres opérations que sont la consultation, la modification ou la suppression Ajout d'une occurrence Lors de l'ajout, aucun champ de saisie de l'identifiant technique ne doit être présenté à l'utilisateur car: - à ce stade, l'utilisateur n'a pas de connaissance d'une valeur à saisir; - c'est le SGBD qui doit se charger de créer une valeur. Figure 30 - Maquette d'ajout d'un étudiant Après l'ajout, le système doit renvoyer à l'utilisateur la quittance de l'ajout avec indication de la valeur d'identifiant technique créée pour le nouvel étudiant. Identifiant technique Figure 31 - Maquette de quittance d'ajout d'un étudiant avec indication de la valeur de clé primaire Cet identifiant technique ou référence interne sera utile pour différencier avec exactitude toutes les occurrences d'étudiant et en rechercher un précis. 37

38 Modèle conceptuel de données (MCD) Recherche d'occurrence(s) Identifiant technique Figure 32 - Maquette de filtre de recherche d'étudiant(s) Après l'ajout, la valeur de l'identifiant technique étant connue des utilisateurs, il est donc possible de faire une recherche directement sur cet attribut comme illustré ci-contre. C'est souvent ce mécanisme qui est derrière les mentions Votre référence ou Notre Référence des échanges de courriers commerciaux Modification d'une occurrence Identifiant technique Figure 33 - Maquette de modification d'un étudiant Les utilisateurs ne pourront en aucun cas modifier l'identifiant technique. Par contre, son affichage est très souvent utile pour garantir la sélection correcte de l'occurrence en cours de traitement; c'est particulièrement vrai pour notre exemple, si l'utilisateur modifie le nom et/ou le prénom. 38

39 Chapitre Attribut artificiel ou identifiant naturel Deux positions doctrinaires s'affrontent lorsqu'il s'agit de définir le ou les identifiants d'une entité: - L'approche francophone, très conceptuelle, qui ne retient que le concept d'identifiant naturel. Si le modèle logique est réalisé sous forme relationnelle, une clé primaire est créée lors de la transformation du modèle conceptuel en modèle logique. - L'approche anglo-saxonne, très pragmatique, qui impose un identifiant technique en plus du ou des éventuels identifiants naturels. Cette position se justifie par le fait que, implicitement, la transformation du modèle conceptuel se fera sous forme d'un modèle logique relationnel. De notre côté, nous ferons un mixte, à savoir: - Lorsqu'une entité est dotée d'un identifiant naturel, nous ne créons pas d'identifiant technique. Figure 34 - Identifiant naturel - Lorsqu'une entité indépendante [Chapitre 3.8] ne possède pas d'attribut permettant de créer un identifiant naturel, nous créons un attribut artificiel qui servira de base à un identifiant technique. Il en est de même pour une entité dépendante qui ne représente pas de multiples valeurs d'un attribut [Chapitre 3.9]. Figure 35 - Identifiant technique d'une entité indépendante Modification de valeur des attributs Le ou les attributs constitutifs d'un identifiant naturel peuvent changer de valeur. Les noms de salles de notre exemple illustré en Figure 15 et Figure 16 sont basés sur des noms de savants illustres; toutefois l'école pourrait vouloir changer cette règle et baser les noms sur des noms de pays ou de villes. 39