Chapitre 1 UN MODELE CONCEPTUEL: LE MODELE ENTITE- ASSOCIATION

Save this PDF as:
 WORD  PNG  TXT  JPG

Dimension: px
Commencer à balayer dès la page:

Download "Chapitre 1 UN MODELE CONCEPTUEL: LE MODELE ENTITE- ASSOCIATION"

Transcription

1 Chapitre 1 UN MODELE CONCEPTUEL: LE MODELE ENTITE- ASSOCIATION 1. Concepts de base et diagrammes EA Le modèle entité-association (EA, appelé aussi entité-relation ou ER) est un modèle de données de type conceptuel. Comme tel, il est actuellement utilisé par plusieurs méthodes et outils d'aide à la conception des bases de données (MERISE, IDA, Yourdon,...). Ce modèle est actuellement limité à la description statique: son but est de permettre la description conceptuelle des structures de données d'une application. L'idée fondamentale du modèle EA est de retenir comme concepts de base pour la représentation les mêmes concepts génériques que ceux qui guident le processus d'abstraction conduisant de l'observation d'une réalité à sa description. On suppose que la perception d'une situation observée se fait naturellement sur la base d'une identification des objets présents (qu'ils soient réels, une personne, ou abstraits, une foule), de liens entre ces objets (une personne conduit une voiture) et de propriétés observables (la taille d'une personne, la couleur d'une voiture,...). Le modèle EA propose une description sur la base de ces mêmes trois concepts, renommés de façon à distinguer facilement le discours sur la réalité (fait en termes d'objets, liens et propriétés) du discours sur la représentation de la réalité (fait en utilisant les termes du modèle). La correspondance entre les trois concepts génériques et la terminologie du modèle EA est la suivante: objet entité lien association propriété attribut Entité représentation d'un objet du monde réel (concret ou abstrait), perçu par le concepteur comme ayant une existence propre, et à propos duquel on veut enregistrer des informations. Une entité existe indépendamment du fait qu'elle puisse être liée à d'autres entités de la base de données. Exemples: Mme Dupont, Mr. Durand, la cafetière X32, l'atelier de fabrication A22, le service Comptabilité, sont des objets susceptibles d'être représentés par des entités. Type d'entité (TE) représentation d'un ensemble d'entités perçues comme similaires et ayant les mêmes caractéristiques. Exemples: Employé (représentation de l'ensemble des employés),, Atelier de fabrication, Service,... Association Bases de données avancées

2 représentation d'un lien entre plusieurs entités, lien où chaque entité liée joue un rôle déterminé. Si l'association lie deux (ou plus) entités du même type, elle est dite "cyclique" et, dans ce cas, la spécification du rôle de chaque entité est indispensable pour supprimer les ambiguïtés possibles. Exemples: le lien de fabrication entre l'atelier A22 (rôle: producteur) et la cafetière X32 (rôle: objet produit); le lien de travail entre l'employé Durand et le service Comptabilité; le lien de mariage entre Mr. Durand (rôle: époux) et Mme Dupont (rôle: épouse),... peuvent être représentés par des associations entre les entités correspondantes. Type d'association (TA) représentation d'un ensemble d'associations ayant la même sémantique et décrites par les mêmes caractéristiques (liant des entités de même type avec les mêmes rôles, et possédant les mêmes propriétés). Exemples: le TA fabrique lie le TE Atelier de fabrication au TE, chaque association de ce TA exprimant le fait qu'un atelier de fabrication donné fabrique un article donné; travaille lie le TE Employé au TE Service pour exprimer que tel employé travaille dans tel service; est marié avec lie le TE Personne avec lui-même pour exprimer que telle personne, l'époux, est mariée à telle autre personne, l'épouse. Attribut représentation d'une propriété associée à un TE, ou à un TA, ou participant à la composition d'un autre attribut. L'ensemble des attributs d'un TE (TA) représente l'ensemble des informations inhérentes que l'on souhaite conserver sur les entités (associations) du TE (TA). Exemples: nom, prénoms, salaire sont des attributs du TE Employé; quantité-en-fabrication est un attribut du TA fabrique; date-de-mariage est un attribut du TA est-marié-avec; jour, mois, année sont des attributs composant un attribut date,... On appelle occurrence d'un TE (TA) toute entité (association) appartenant à l'ensemble décrit par le TE (TA). On appelle population d'un TE (TA) l'ensemble des occurrences du TE (TA). La base de données décrite par un schéma EA est donc l'ensemble des populations des TE et TA apparaissant dans le schéma. Une occurrence de TE est vue par l'utilisateur comme un ensemble de valeurs: une valeur pour chaque attribut du TE (NB: il est possible que la valeur d'un attribut soit en fait une absence de valeur ou un ensemble de valeurs). Une occurrence de TA est vue par l'utilisateur comme un ensemble de valeurs (éventuellement vide) et un ensemble d'occurrences de TE : une valeur pour chaque attribut du TA (s'il en existe), et, pour chaque rôle associé au TA, une occurrence du TE qui joue ce rôle. Il faut remarquer que les termes type, population, occurrence sont génériques (ne sont pas propres au modèle EA, ni aux modèles conceptuels). Le modèle EA permet une représentation graphique assez lisible du schéma d'une base de données. Dans cette représentation, appelée diagramme EA, les types d'entités sont représentés par des rectangles; les types d'associations sont représentés par des hexagones ou autre symbole similaire (ovale, losange...). Les attributs sont soit rattachés au TE (TA) par des traits (convention utilisée ici), soit listés à l'intérieur du rectangle TE (hexagone TA), au dessous du nom du TE (TA) et séparés de celui-ci par une barre (voir les diagrammes MERISE, par exemple). Bases de données avancées

3 Par exemple, le diagramme EA suivant illustre le schéma d'une base de données pour la gestion d'un hypermarché. Dans ce diagramme, sont représentés quatre types d'entité: - Employé, d'attributs nom et salaire; - Rayon, d'attributs nomr et étage; -, d'attributs noma et type; - Fournisseur, d'attributs nomf et adresse. Ces types d'entité sont reliés par les types d'association suivants: - Livraison, d'attribut quantité, liant Fournisseur, et Rayon; - Vente, d'attribut quantité, liant Rayon et ; - Emploi, liant Employé et Rayon; - Chef, cyclique, liant Employé (avec le rôle Inf) et Employé (avec le rôle Sup). La signification des différents types de traits (pleins, pointillés,...) est précisée dans le paragraphe 3. Sup Employé Chef Fournisseur Inf nom salaire nomf adresse Emploi Livraison quantité Rayon Vente nomr étage quantité noma type Un premier diagramme pour la base de données Hypermarché 2. Représentations multiples: la généralisation/spécialisation Un type d entité représente une classe d'objets du monde réel perçus comme similaires et ayant les mêmes caractéristiques. Or, il arrive parfois qu'un même ensemble d'objets soit perçu d'un certain point de vue comme une seule classe, mais en même temps perçu d'un autre point de vue comme plusieurs classes, différentes malgré l'existence de caractéristiques communes. Exemple: dans le diagramme EA décrivant un hypermarché, le TE regroupe tous les articles vendus, quels qu'ils soient; certains traitements doivent pouvoir accéder de façon uniforme à tous les articles: inventaire, recherche des caractéristiques d'un article dont on ne connaît que le code,... Pour d'autres usages, on peut néanmoins vouloir séparer les articles en plusieurs classes (alimentation, habillement, Hi-Fi, hygiène,...). Par exemple, la gestion des ventes promotionnelles n'aura pas les mêmes critères suivant la catégorie, les articles d'alimentation doivent être retirés des Bases de données avancées

4 rayons lorsque la date limite de vente est dépassée. Chaque classe peut avoir des caractéristiques qui lui sont propres, par exemple: date limite de vente (alimentation), taille et couleur (habillement),... On sera donc amené à décrire, en plus du TE générique, des TE plus spécialisés, représentant les sous-classes "intéressantes" (celles sur lesquelles on a effectivement quelque chose de particulier à faire). Par exemple, un TE " alimentaire", un TE " d'habillement" et un TE " Hi-Fi". Ceci, toutefois, introduit une situation atypique: celle où les mêmes objets sont représentés par deux TE (le TE générique et l'un des TE spécialisés), alors que normalement les populations de deux TE représentent des classes d'objets disjointes. Pour décrire une telle situation atypique, les modèles de données récents incluent le concept de généralisation/spécialisation: un lien, orienté, d'un TE spécialisé (ou spécifique) vers un TE générique. La sémantique de ce lien est qu'à toute occurrence du TE spécifique correspond une occurrence du TE générique qui décrit le même objet du monde réel. Inversement, à toute occurrence du TE générique correspond zéro ou une occurrence par TE spécifique. Graphiquement, ce lien est représenté par une flèche orientée du TE spécifique vers le TE générique. Pour l'exemple de l'hypermarché, le diagramme suivant affine la représentation des articles: alimentaire habillement Hi-Fi Les liens de généralisation/spécialisation sont souvent appelés liens "est-un" (IS A); on dit que " alimentaire est-un ". On dit également que le TE spécifique est un sous-type du TE générique qui, lui, est sur-type du TE spécifique. En effet, par convention, les attributs communs au TE générique et aux TE spécifiques ne sont décrits, dans le schéma, que comme attributs du TE générique. Néanmoins, ils sont implicitement inclus dans les attributs des TE spécifiques: on dit que ces derniers "héritent" des attributs du TE générique. En plus des attributs hérités, les TE spécifiques peuvent avoir des attributs propres. Ce qui a été dit pour la description et l'héritage des attributs s'applique également à l'héritage des rôles d'association. Par exemple, le TE " Hi-Fi", comme les autres TE spécifiques, est implicitement lié par les TA Vente et Livraison, hérités du TE. Il pourrait, en plus, être lié par un TA Réparation à un TE Service après-vente (tel type d'articles de Hi-Fi est réparé par tel Service après-vente). Ce dernier TA n'est défini alors que pour les articles du TE Hi-Fi. Un diagramme plus précis (mais partiel) pour la base de données exemple Hypermarché est donc: Bases de données avancées

5 Vente alimentaire Livraison habillement marque noma type n code quantité en stock Hi-Fi date limite de vente tailles couleurs puissance Réparation Service après-vente Il n'est pas nécessaire que les TE spécifiques représentent, dans leur ensemble, tous les objets représentés par le TE générique. Ainsi, dans l'exemple, les articles d'hygiène, de bricolage,... ne constituent pas d'autres classes spécifiques et sont donc uniquement représentés par le TE. De même, les TE spécifiques d'un même TE générique ne représentent pas nécessairement des populations disjointes, comme le montre le diagramme qui suit, décrivant des personnes travaillant ou étudiant dans un campus universitaire. Cet exemple illustre également le fait qu'un TE générique peut à son tour être sous-type d'un autre TE: on dit alors que l'on a une hiérarchie de généralisations. On parle de généralisation multiple lorsqu'un TE est sous-type de plusieurs autres TE. C'est le cas dans l'exemple du campus universitaire pour le TE Assistant-doctorant, qui regroupe la population des personnes qui sont à la fois Assistant et Doctorant. La généralisation multiple pose des problèmes liés à l'héritage: éviter d'hériter deux fois d'un ancêtre commun (dans l'exemple, Assistant-doctorant doit hériter une seule fois de Personne, soit via Doctorant-Etudiant, soit via Assistant-Enseignant-Employé), éviter d'avoir des conflits d'héritage (par exemple, lorsque deux attributs portant le même nom se trouvent dans deux TE génériques différents dont on hérite). Pour résoudre ces conflits d'héritage, soit le concepteur spécifie explicitement une préférence d'héritage, soit le système applique une règle implicite déterministe. Bases de données avancées

6 Personne no matricule nom prénom Etudiant section Employé classe de traitement sujet Doctorant Enseignant Technicien Administratif Assistant Professeur Assistant-doctorant laboratoire dirigé 3. Description d'un schéma EA Un TE est décrit par les spécifications suivantes: - le nom du type d'entité; - le nom du (ou des) type(s) d'entité sur-type de ce type d'entité, s'il en existe; - une définition libre (commentaire) précisant la population exacte du type d'entité; - la description des attributs du TE; - la composition des identifiants du TE, s'il en existe (voir 4). Exemple: description du TE "Employé" de la base de données hypermarché: - nom : Employé; - sur-types: / ; - définition: "toute personne salariée par l'entreprise en ce moment"; - attributs: nom, salaire (avec leur description); - identifiant: nom. Remarques: - deux TE différents ne peuvent avoir le même nom; - la définition libre est une partie très importante de la description d'un TE. C'est elle qui permet de définir exactement, de façon non ambiguë, la population du TE. Elle inclut notamment la spécification temporelle (soulignée dans l'exemple), qui permet de savoir si le contexte modélisé couvre uniquement la situation actuelle ou aussi l'historique (les situations antérieures) et/ou la prospective (situations à venir). Un TA est décrit par les spécifications suivantes: - le nom du type d'association; - une définition libre (commentaire) précisant la population exacte du type d'association; Bases de données avancées

7 - les noms des TE participant au TA, avec le nom du rôle les associant au TA. En pratique, le nom de rôle n'est obligatoire que pour les associations cycliques; - pour chaque rôle, ses cardinalités: c'est une information supplémentaire exprimant la règle de participation des entités dans les associations (au niveau des occurrences). Les cardinalités consistent en deux nombres, min et max, spécifiant le nombre minimal et le nombre maximal d'occurrences du TA qui peuvent, à un instant donné, lier par ce rôle une occurrence quelconque du TE en question; min et max sont deux entiers tels que max=min, min=0, max=1. Dans le cas d'une cardinalité maximale supérieure à 1, on précise si les rôles liant une entité constituent une liste ou un ensemble (valeur par défaut). - la description des attributs du TA, s'il en existe; - la composition des identifiants du TA, s'il en existe (voir 4). Exemple: description du TA "Emploi" de la base de données hypermarché: - nom: Emploi - définition: "lie un employé au rayon dans lequel cet employé travaille aujourd'hui" - TE participants: Employé, Rayon - cardinalités: Employé: min=0, max=1 Rayon: min=0, max=n - attributs: / - identifiant: ( Employé nom + Rayon nomr 1 ) Les cardinalités possibles pour un rôle (ici, Employé de Emploi) et leur signification sont les suivantes: min=0 : un employé peut ne travailler dans aucun rayon min=1 : un employé doit travailler dans au moins un rayon max=1 : un employé ne peut travailler dans plus d'un rayon max=n : un employé peut travailler dans plusieurs rayons La représentation graphique des rôles et des attributs varie en fonction des cardinalités associées au rôle ou à l'attribut, selon le tableau ci-dessous: minimum maximum n 1 n m n Certains auteurs utilisent une convention graphique différente, consistant à indiquer explicitement les cardinalités par deux chiffres (min,max ou min:max) au voisinage du trait continu représentant le rôle correspondant: Parent 0:n 2:2 est parent de Enfant La signification des cardinalités dans ce diagramme est: un parent peut avoir de 0 à n enfants; un enfant a toujours (dans cette base de données) deux parents. 1 la notation pointée Employé nom désigne l'attribut nom du TE Employé. Plus généralement, X a désigne le composant a de l'objet X. Bases de données avancées

8 Les TA cycliques suivent les mêmes conventions. Rappelons qu'un TA est dit cyclique s'il lie plusieurs fois, avec des rôles différents, le même type d'entité. Dans ce cas, les noms de rôle sont essentiels pour éviter des ambiguïtés. Ils sont donc explicitement notés sur le diagramme. Par exemple, un TA cyclique modélisant le lien de composition associant à un produit composé les produits le composant sera illustré comme suit: Produit nomp est composé de est composant de Composition quantité Si l'on représente dans la base de données d'un constructeur automobile la composition d'une voiture, on pourra obtenir les occurrences suivantes: TE Produit : occurrence nomp p1 voiture p2 carrosserie p3 roue p4 moteur p5 porte... TA Composition : occurrence est composé de est composant de quantité c1 p1 p2 1 c2 p1 p3 5 c3 p1 p4 1 c4 p2 p Un attribut est décrit par les spécifications suivantes: - nom de l'attribut; - définition libre (libellé en clair); - cardinalités: min et max, spécifiant combien de valeurs de cet attribut sont autorisées (au minimum, au maximum) dans: une occurrence du TE (TA), si l'attribut est directement rattaché au TE (TA), une valeur de l'attribut dont il est composant, sinon (voir ci-dessous). Dans le cas d'une cardinalité maximale supérieure à 1, on précise si les valeurs de l'attribut constituent une liste, un ensemble ou un multi-ensemble (valeur par défaut); - si l'attribut n'est pas composé d'autres attributs: domaine de valeurs associé, spécifiant quel est l'ensemble des valeurs autorisées pour l'attribut; - si l'attribut est composé d'autres attributs: description des attributs composants. Exemple: description de l'attribut "nom" du TE Employé de la base de données hypermarché: - nom: nom - définition: "nom de l'employé, nom de jeune fille pour une femme" - cardinalités: min=1, max=1 (tout employé a un nom et un seul) - domaine de valeurs: l'ensemble des chaînes de caractères de longueur inférieure à 15. Bases de données avancées

9 Exemple: description d'un attribut "date de naissance" d'un TE Personne - nom: date de naissance - définition: "date de naissance de la personne" - cardinalités: min=1, max=1 (tout personne a une date de naissance connue) - composition: - nom: jour - définition: "jour de naissance de la personne" - cardinalités: min=1, max=1 - domaine de valeurs: les entiers dans l'intervalle [1,31] - nom: mois - définition: "mois de naissance de la personne" - cardinalités: min=1, max=1 - domaine de valeurs: les entiers dans l'intervalle [1,12] - nom: année - définition: "année de naissance de la personne" - cardinalités: min=1, max=1 - domaine de valeurs: les entiers dans l'intervalle [1870,1993] Terminologie: on appelle: attribut simple: attribut complexe: attribut monovalué: attribut multivalué: attribut obligatoire: attribut facultatif: Le diagramme suivant: un attribut qui n'est pas décomposé en d'autres attributs: ses valeurs sont atomiques. Un domaine lui est associé. Exemple: salaire, téléphones un attribut qui est décomposé en d'autres attributs: ses valeurs sont des valeurs composées. Exemple: adresse, composé de: rue, ville, code postal un attribut qui ne peut prendre qu'une seule valeur par occurrence (cardinalité max=1). Exemple: nom, date de naissance un attribut qui peut prendre plusieurs valeurs par occurrence (cardinalité max>1). Exemple: prénoms, téléphones un attribut qui doit prendre une valeur au moins par occurrence (cardinalité min=1). Exemple: nom, prénoms un attribut qui peut ne pas prendre de valeur dans une occurrence (cardinalité min=0). Exemple: salaire, téléphones Bases de données avancées

10 Employé liste liste liste n E nom prénoms CV postes diplôme année intitulé salaires date-début date-fin montant date année mois illustre un TE Employé, qui a deux attributs simples, monovalués et obligatoires (n E et nom), un attribut simple, multivalué et obligatoire (prénoms) et deux attributs complexes et multivalués (CV et postes), dont le premier est facultatif et le deuxième est obligatoire. Il convient de souligner que la définition d'un attribut (ou d'un rôle) comme étant obligatoire induit une contrainte sur la création des occurrences correspondantes. En effet, la création d'une occurrence ne peut être acceptée que si tous les attributs (rôles) obligatoires reçoivent une valeur dès sa création. 4. Identifiants des TE et TA Définition: un identifiant d'un TE (ou TA) est un ensemble minimum d'attributs tel qu'il n'existe pas deux occurrences du TE (ou TA) qui ont la même valeur pour ces attributs. Un TE, comme un TA, peut avoir plusieurs identifiants; il peut n'en avoir aucun. Dans ce cas, des occurrences de même valeur sont autorisées. Exemple: n employé et (nom+prénoms) sont deux identifiants du TE Employé, si dans cette entreprise il n'y a jamais deux employés ayant les mêmes nom et prénoms, ou le même numéro. Les identifiants des TE peuvent être représentés sur le diagramme en les soulignant (attention à distinguer l'existence de deux identifiants de celle d'un identifiant composé de deux attributs). Par contre, pour ne pas surcharger le diagramme, les identifiants des TA sont en général précisés textuellement en commentaire du diagramme Identifiant d'un TA Exemple: soit le TA Mariage suivant, représentant les mariages actuels: AVS Personne nom sexe état-civil époux épouse Mariage Une occurrence du TA Mariage est un triplet: < <un époux>, <une épouse>, date > Comme l'attribut AVS est l'identifiant de Personne, Mariage possède deux identifiants: époux AVS et épouse AVS Cette définition n'est valable que si la population du TA Mariage ne contient que les mariages en cours (on ne garde pas l'historique). Si le TA Mariage conservait l'historique (les mariages passés), les cardinalités des deux rôles seraient 0,n et les identifiants du TA seraient: date Bases de données avancées

11 ( époux AVS + date ) et ( épouse AVS + date ) Un TA dont tous les rôles ont une cardinalité maximum supérieure à 1, a souvent (mais pas toujours) un identifiant qui est constitué de l'ensemble des identifiants des TE liés. Exemple: soit un TA Contrôle, avec une occurrence (donc une moyenne, et un ensemble de notes) par étudiant par matière suivie. Ce TA représente les résultats acquis, à ce jour, par un étudiant dans une matière. Etudiant Contrôle Matière N Carte notes moyenne coef NumMat En supposant que les identifiants des TE soient ceux indiqués sur le diagramme, l'identifiant du TA Contrôle est: ( Etudiant N Carte + Matière NumMat ) Néanmoins, il n'est pas toujours vrai que l'identifiant d'un TA est constitué de l'ensemble des identifiants des TE liés. Si l'un des rôles du TA a une cardinalité maximum égale à 1, l'identifiant du TE associé à ce rôle est un identifiant du TA (ce qui était le cas de Mariage, dans la première version). Par exemple, soit le TA suivant: noma Cie Assurance nomp Personne Assure Voiture numv L'identifiant du TA Assure n'est pas ( Personne nomp + Cie Assurance noma + Voiture numv ) car ce triplet ne constitue pas un ensemble minimal. En effet, l'attribut numv de Voiture suffit, à lui seul, pour identifier une occurrence d'assure. Ceci est dû à la cardinalité 1,1 du rôle de Voiture dans le TA, qui garantit que pour une valeur de numv il n'y aura qu'une seule occurrence d'assure avec cette valeur de numv. D'où la règle suivante. Règle: si le TA a une cardinalité maximum égale à 1 pour un des TE liés, alors tout identifiant de ce TE est identifiant du TA. Une autre règle peut être établie pour les cas où plusieurs occurrences du TA lient les mêmes occurrences des TE. Dans l'exemple ci-dessous, plusieurs commandes peuvent être passées par un même client pour un même produit à des dates différentes. Dans ce cas l'identifiant du TA contient au moins un attribut du TA. Produit Commande Client N Produit N Commande date quantité N Client Le TA Commande a ici deux identifiants: ( N Produit + N Client + date ) et N Commande 4.2. Identifiant d'un TE faible Bases de données avancées

12 Un TE est dit faible si aucun sous-ensemble de ses attributs ne constitue un identifiant (il n'a pas d'identifiant qui lui soit interne), et qu'un identifiant peut être défini en intégrant un identifiant d'un autre TE' qui lui est lié par un TA binaire de cardinalité (1,1) pour TE. On dit dans ce cas que TE dépend de TE'. Dans l'exemple ci-dessous, Exemplaire (qui représente un exemplaire d'un livre) est un TE faible (N ex n'est pas un identifiant) dépendant du TE Livre. On dit que Exemplaire dépend de Livre car, du fait des cardinalités, il n'est pas possible de créer une occurrence de Exemplaire sans la rattacher à une occurrence existante de Livre. Ce type de dépendance est appelé dépendance d'existence. Livre Correspond Exemplaire ISBN titre N ex état L'identifiant d'un TE faible (qui est le même que celui du TA) est constitué de l'identifiant du TE dont il dépend et d'un (ou plusieurs) attribut du TE faible. L'identifiant de Exemplaire (et du TA "Correspond") est: ( Livre ISBN + N ex 2 ) 4.3. Identifiant d'un TE sous-type Soit E un TE sous-type du TE E', alors tout identifiant de E' est aussi identifiant de E. E n'a pas nécessairement d'identifiant qui lui soit propre. Dans l'exemple de l'hypermarché, alimentaire, habillement et Hi-Fi ont tous les trois pour identifiant celui de (n code). 5. Contraintes d'intégrité Les concepts d'entité, d'association, d'attribut et de sous-type ne suffisent pas à décrire tout ce qui caractérise les données d'un schéma EA. Par exemple, pour le TA Mariage du 4.1, une règle connue mais non exprimée par ce diagramme est: si une occurrence de Personne participe à l'association Mariage, alors la valeur de son attribut état civil doit être "marié". Un formalisme possible, inspiré de la logique du premier ordre, pour cette règle est: x,y Personne, <x,y> Mariage x état-civil = "marié" y état-civil = "marié" (soient x et y deux occurrences quelconques de Personne, alors, le fait que la paire <x,y> forme une occurrence de mariage implique que l'attribut état-civil dans les occurrences x et y a la valeur "marié") D'autres règles possibles s'appliquant à cet exemple sont: - seuls les hommes peuvent participer à l'association mariage dans le rôle "époux" x,y Personne, <époux:x, épouse:y> Mariage x sexe = "M" - seules les femmes peuvent participer à l'association mariage dans le rôle "épouse" x,y Personne, <époux:x, épouse:y> Mariage y sexe = "F" 2 ISBN signifie "international standard book number". C'est un numéro qui identifie tout nouveau livre édité. Bases de données avancées

13 - si l'état-civil d'une personne est "marié", celui-ci ne peut être changé en "célibataire" x Personne, t1,t2 Temps, t2>t1 x(t1) état-civil="marié" x(t2) état-civil? "célibataire" De telles règles, définissant les états (ou transitions d'état) possibles de la base de données et qui ne peuvent pas être décrites avec les concepts du modèle, sont appelées contraintes d'intégrité. Si les valeurs de la base de données ne satisfont pas ces contraintes, il y a une "erreur" dans la base de données; on dit que la base de données est incohérente. Lors du passage au schéma logique (celui implanté sur le SGBD), les contraintes d'intégrité peuvent être implémentées par des prédicats de contraintes (par exemple les CHECK de SQL), par des procédures déclenchées automatiquement (par exemple les TRIGGERS de SQL) ou par des procédures associées au schéma (par exemple les "stored procedures" de SQL). Contraintes d'intégrité sur les attributs Les contraintes d'intégrité les plus fréquentes limitent les valeurs possibles d'un attribut à certaines valeurs du domaine sous-jacent. Dans le cas le plus simple, elles sont du type: age [0,130]. Il s'agit ici d'une limitation définissant de façon fixe une même fourchette pour toutes les valeurs de l'attribut. Ces contraintes simples disparaissent si le modèle permet une définition précise des domaines de valeurs, au lieu des définitions ne faisant appel qu'à des domaines généraux prédéfinis (entier, réel, chaîne de caractères, booléen,...). Les limites peuvent être définies en fonction du contexte (valeur d'un autre attribut, participation à une association,...). Exemples: - si mois {4, 6, 9, 11} alors jour [1:30], sinon si mois=2 alors jour [1:29] sinon jour [1:31] ; - si une Personne participe à l'association Mariage, alors son état civil doit être "marié"; - une française mariée avant 1986 a pour premier nom, le nom de son mari; une française mariée après 1986 a pour premier nom son nom de jeune fille. Contraintes d'intégrité sur les cardinalités D'autres types de contraintes d'intégrité limitent les cardinalités des TE, des TA, ou des valeurs des attributs. Exemple: On suppose, dans le diagramme Parent-Enfant du paragraphe 3, que les attributs du type d'entité Parent sont les suivants: nom, prénoms, adresse, nombre-enfants. Il existe alors la contrainte d'intégrité: nombre-enfants = nombre d'occurrences du TA "est parent de" qui lient ce Parent. Contraintes d'intégrité sur les généralisations/spécialisations Dans une hiérarchie de généralisation/spécialisation, il est fréquent de trouver des contraintes d'intégrité décrivant le partage de population entre les sous-types d'un même sur-type: - contrainte de couverture, pour spécifier que l'union des populations de certains TE spécifiques d'un même TE générique est égale à la population du TE générique; - contrainte de disjonction, pour spécifier que les populations de certains TE spécifiques d'un même TE générique n'ont aucune occurrence en commun; Bases de données avancées

14 - contrainte de partition, pour spécifier que la population d'un TE générique se distribue complètement et sans intersection entre certains de ses TE spécifiques (partition = couverture + disjonction sur les mêmes TE spécifiques). Par exemple, dans la base de l'hypermarché, les trois sous-types de sont disjoints: un article alimentaire n'est jamais un article d'habillement et vice-versa. Un autre type de contrainte peut être défini sur les groupes de sous-types issus d'un même sur-type s'ils sont statiques. A priori un objet du monde réel peut se transformer et changer de classification. Par exemple, dans la base de données du campus universitaire vue à la fin du paragraphe 2, un étudiant ayant fini sa licence peut devenir assistant doctorant, puis ayant fini sa thèse il peut devenir assistant, puis plus tard devenir professeur. La même occurrence change donc de sous-type au cours de sa vie. Le groupe de sous-types est alors dit "dynamique". Au contraire certains groupes de soustypes ne permettent aucun changement de classification. Par exemple pour l'hypermarché, le groupe de sous-types d' est statique: un article d'habillement ne peut pas se transformer en article alimentaire, etc. De tels groupes de sous-types sont dits statiques. C'est une contrainte d'intégrité. disjoint statique alimentaire habillement Hi-Fi En conclusion: Un schéma conceptuel entité association est un ensemble de descriptions de types d'entité et de types d'association (avec leurs attributs et les liens de généralisation entre types d'entité), et des contraintes d'intégrité associées. Bases de données avancées

Modèle conceptuel : diagramme entité-association

Modèle conceptuel : diagramme entité-association Modèle conceptuel : diagramme entité-association Raison d'être de ce cours «La conception et l'utilisation de bases de données relationnelles sur micro-ordinateurs n'est pas un domaine réservé aux informaticiens.»

Plus en détail

Modélisation Conceptuelle. Partie 2: Le modèle Entité-Association

Modélisation Conceptuelle. Partie 2: Le modèle Entité-Association Modélisation Conceptuelle Partie 2: Le modèle Entité-Association Modèle de type conceptuel But: permettre la description conceptuelle des structures de données d'une application Les concepts de base (correspondent

Plus en détail

Chapitre 2 : Conception de base de données relationnelle

Chapitre 2 : Conception de base de données relationnelle Chapitre 2 : Conception de base de données relationnelle Le modèle entité-association 1. Les concepts de base 1.1 Introduction Avant que la base de données ne prenne une forme utilisable par le SGBD il

Plus en détail

Bases de données Cours 2 : Modélisation d une base de données

Bases de données Cours 2 : Modélisation d une base de données Cours 2 : Modélisation d une base de données POLYTECH Université d Aix-Marseille odile.papini@univ-amu.fr http://odile.papini.perso.esil.univmed.fr/sources/bd.html Plan du cours 1 Modélisation d une base

Plus en détail

Introduction aux bases de données Cours 2 : Modélisation d une base de données

Introduction aux bases de données Cours 2 : Modélisation d une base de données Cours 2 : Modélisation d une base de données ESIL Université de la méditerranée Odile.Papini@esil.univmed.fr http://odile.papini.perso.esil.univmed.fr/sources/bdmat.html Plan du cours 1 Modélisation d

Plus en détail

II. Modèle conceptuel le modèle entité-association

II. Modèle conceptuel le modèle entité-association II. Modèle conceptuel le modèle entité-association Personne Voiture Schéma conceptuel Monde réel υ Concepteur υ Personne conduit Voiture ϖ ϖ Schéma logique utilisateurs ω LMD BD Personne Dupont Durant

Plus en détail

Les principaux domaines de l informatique

Les principaux domaines de l informatique Les principaux domaines de l informatique... abordés dans le cadre de ce cours: La Programmation Les Systèmes d Exploitation Les Systèmes d Information La Conception d Interfaces Le Calcul Scientifique

Plus en détail

Chapitre 5 LE MODELE ENTITE - ASSOCIATION

Chapitre 5 LE MODELE ENTITE - ASSOCIATION Chapitre 5 LE MODELE ENTITE - ASSOCIATION 1 Introduction Conception d une base de données Domaine d application complexe : description abstraite des concepts indépendamment de leur implémentation sous

Plus en détail

Modélisation Conceptuelle. Partie 3: Validation et transformations

Modélisation Conceptuelle. Partie 3: Validation et transformations Modélisation Conceptuelle Partie 3: Validation et transformations Méthode de modélisation 1. Etude des besoins de l'entreprise interviews analyse des documents existants 2. Construction du diagramme EA

Plus en détail

Modèle e-a étendu: MCD (Modèle conceptuel des données) de Merise

Modèle e-a étendu: MCD (Modèle conceptuel des données) de Merise 58 Modèle e-a étendu: MCD (Modèle conceptuel des données) de Merise Héritage Contrainte d intégrité Fonctionnelle (CIF) 59 Héritage S impose dans 2 cas : Spécialisation : permet de modéliser dans l'ensemble

Plus en détail

A. Définition et formalisme

A. Définition et formalisme Les cardinalités et les différents types d'associations I. Les cardinalités A. Définition et formalisme Les cardinalités sont des couples de valeur que l'on trouve entre chaque entité et ses associations

Plus en détail

IFT3030 Base de données. Chapitre 7 Conception de bases de données. Plan du cours

IFT3030 Base de données. Chapitre 7 Conception de bases de données. Plan du cours IFT3030 Base de données Chapitre 7 Conception de bases de données Plan du cours Introduction Architecture Modèles de données Modèle relationnel Algèbre relationnelle SQL Conception Fonctions avancées avancés

Plus en détail

Conception d une base de données - Modèle E/A -

Conception d une base de données - Modèle E/A - Conception d une base de données - Modèle E/A - Démarche 3 niveaux d'analyse: Niveau conceptuel : (On utilise le modèle E/A) Quelles sont les entités et les associations dans l'entreprise? Quelles informations

Plus en détail

Chapitre 2 CONCEPTION D'UN SCHEMA ENTITE- ASSOCIATION

Chapitre 2 CONCEPTION D'UN SCHEMA ENTITE- ASSOCIATION Chapitre 2 CONCEPTION D'UN SCHEMA ENTITE- ASSOCIATION Dans ce chapitre, nous proposons quelques règles pour guider le concepteur lors de la définition du schéma conceptuel entité association d'une (nouvelle)

Plus en détail

1. Objectifs de la Modélisation. Dériver le schéma de la BD. Élaborer un modèle conceptuel. Modélisation E/R des Données

1. Objectifs de la Modélisation. Dériver le schéma de la BD. Élaborer un modèle conceptuel. Modélisation E/R des Données . Objectifs et principes Modélisation E/R des Données 2. Le modèle Entité-Association (E/R) 3. Passage au relationnel 4. Conclusion. Objectifs de la Modélisation Permettre une meilleure compréhension Le

Plus en détail

Chapitre 4 Modélisation et Conception de BD

Chapitre 4 Modélisation et Conception de BD Pourquoi une modélisation préalable? Chapitre 4 Modélisation et Conception de BD Il est difficile de modéliser un domaine sous une forme directement utilisable par un SGBD. Stockage physique Cohérence/intégrité

Plus en détail

Chapitre 2 Modélisation de bases de données

Chapitre 2 Modélisation de bases de données Pourquoi une modélisation préalable? Chapitre 2 Modélisation de bases de données 1. Première étape : le modèle conceptuel Eemple : le modèle Entités-Associations (E/A) 2. Deuième étape : le modèle Traduction

Plus en détail

Le modèle conceptuel des données

Le modèle conceptuel des données Le modèle conceptuel des données 1 Objectif du MCD Décrire les données du SI, indépendamment de tout choix d'implantation physique. 1. Le dictionnaire des données Inventaire exhaustif des données du domaine

Plus en détail

Modélisation des données

Modélisation des données Modélisation des données Le modèle Entité/Association Le MCD ou modèle Entité/Association est un modèle chargé de représenter sous forme graphique les informations manipulées par le système (l entreprise)

Plus en détail

Modélisation conceptuelle des données Responsable: Dominique Schneuwly, Regis Caloz

Modélisation conceptuelle des données Responsable: Dominique Schneuwly, Regis Caloz Geographic Information Technology Training Alliance (GITTA) presents: Modélisation conceptuelle des données Responsable: Dominique Schneuwly, Regis Caloz Table des matières 1. Modélisation conceptuelle

Plus en détail

Modélisation des données

Modélisation des données 1 2 Démarche classique d un projet informatique Analyse de la situation existante et des besoins ; Création d une série de modèles, qui permettent de représenter tous les aspects importants ; A partir

Plus en détail

CONCEPTION Support de cours n 3 DE BASES DE DONNEES

CONCEPTION Support de cours n 3 DE BASES DE DONNEES CONCEPTION Support de cours n 3 DE BASES DE DONNEES Auteur: Raymonde RICHARD PRCE UBO PARTIE III. - LA DESCRIPTION LOGIQUE ET PHYSIQUE DES DONNEES... 2 A. Les concepts du modèle relationnel de données...

Plus en détail

Bases de données (organisation générale)

Bases de données (organisation générale) Bases de données (organisation générale) Répétition 1 Le modèle entité-relation Samuel Hiard S.Hiard@ulg.ac.be I/112 (B28) sur rendez-vous Page du cours : http://www.montefiore.ulg.ac.be/~pw/cours/bd.html

Plus en détail

Modèle Entité/Association. Marc Plantevit. marc.plantevit@liris.cnrs.fr

Modèle Entité/Association. Marc Plantevit. marc.plantevit@liris.cnrs.fr Modèle Entité/Association Marc Plantevit marc.plantevit@liris.cnrs.fr Objectifs Savoir lire un schéma E/R. Savoir traduire un schéma E/R en Modèle Relationnel.... 2 Le modèle Entité-Association (E/A) E/R

Plus en détail

Série 1 : Corrigé indicatif (modélisation entité association)

Série 1 : Corrigé indicatif (modélisation entité association) Série 1 : Corrigé indicatif (modélisation entité association) Ce corrigé présente pour chaque exercice une, voire deux solutions, mais aucunement toutes les bonnes solutions possibles. Pour pouvoir choisir

Plus en détail

Du monde réel à SQL la modélisation des données

Du monde réel à SQL la modélisation des données ANF «Comment concevoir une base de données en archéométrie» Réseau CAI-RN & rbdd - 05/06/2014 au 06/06/2014 Du monde réel à SQL la modélisation des données Marie-Claude Quidoz (CEFE/CNRS) Ce document est

Plus en détail

Chap. 3: Le modèle de données entité-association (E.A.)

Chap. 3: Le modèle de données entité-association (E.A.) Chap. 3: Le modèle de données entité-association (E.A.) En anglais: Entity-Relationship (ER) Origines: C.Bachman (1969), P.Chen (1976). Modèle de données > décrire la réalité perçue à travers les données

Plus en détail

Chapitre 2 Modèle Conceptuel de données

Chapitre 2 Modèle Conceptuel de données Chapitre 2 Modèle Conceptuel de données I. Introduction Le modèle conceptuel de données MCD (ou modèle entité-association MEA, ou Entity-RelationShip Model en anglais) a été introduit dans les années 70

Plus en détail

Conception des bases de données : Modèle Entité-Association

Conception des bases de données : Modèle Entité-Association Conception des bases de données : Modèle Entité-Association La modélisation d un problème, c est-à-dire le passage du monde réel à sa représentation informatique, se définit en plusieurs étapes pour parvenir

Plus en détail

Rappel sur les bases de données

Rappel sur les bases de données Rappel sur les bases de données 1) Généralités 1.1 Base de données et système de gestion de base de donnés: définitions Une base de données est un ensemble de données stockées de manière structurée permettant

Plus en détail

Bases de Données et SGBD. Le Modèle Entité/Association

Bases de Données et SGBD. Le Modèle Entité/Association Bases de Données et SGBD Le Modèle Entité/Association 1 Modèle Entité/Association Représentation explicite de 3 concepts principaux: entité, association, attribut. 1. Entité = classe générique d'individus

Plus en détail

CHAPITRE 2. Modèle Entités-Relations (E-R)

CHAPITRE 2. Modèle Entités-Relations (E-R) CHAPITRE 2 Modèle Entités-Relations (E-R) Contenu du chapitre 2 Après la collecte et l analyse des besoins de usagers, il faut créer le schéma conceptuel de haut niveau Nous utiliserons le modèle E-R Entités,

Plus en détail

UML Diagramme de classes (class diagram) pour le recueil et l analyse des besoins. Emmanuel Pichon 2013 V1.1

UML Diagramme de classes (class diagram) pour le recueil et l analyse des besoins. Emmanuel Pichon 2013 V1.1 UML Diagramme de classes (class diagram) pour le recueil et l analyse des besoins 2013 V1.1 Objectif Diagramme de classes (class diagram) pour le recueil des besoins et l analyse Présenter un ensemble

Plus en détail

Conception de bases de données relationnelles

Conception de bases de données relationnelles Conception de bases de données relationnelles Niveau conceptuel : modélisation de BD relationnelles Marie Szafranski 2015-2016 ensiie 1 2015-2016 ensiie 1 Modélisation d une BD Modélisation d une BD Étape

Plus en détail

Conventions communes aux profils UML

Conventions communes aux profils UML Conventions communes aux profils UML Auteur : Projet ACCORD (Assemblage de composants par contrats en environnement ouvert et réparti)* Référence : Livrable 2.1 Date : Juin 2002 * : Les partenaires du

Plus en détail

CHAPITRE II CONCEPTION D'UN SCHEMA RELATIONNEL. [GARD01] Chapitre XVII

CHAPITRE II CONCEPTION D'UN SCHEMA RELATIONNEL. [GARD01] Chapitre XVII CHAPITRE II CONCEPTION D'UN SCHEMA RELATIONNEL [GARD01] Chapitre XVII 27 CONCEPTION D'UN SCHEMA RELATIONNEL - Introduction 1. INTRODUCTION 1.1. Lien entre la base de données et le système d'information

Plus en détail

Chapitre 3 LE MODELE RELATIONNEL

Chapitre 3 LE MODELE RELATIONNEL Chapitre 3 LE MODELE RELATIONNEL Le modèle relationnel a été inventé en 1960 et a fait l'objet de très nombreuses recherches qui ont débouché sur la réalisation et commercialisation de SGBDs relationnels.

Plus en détail

Introduction à la POO : «has a», comprend un, composition. Segment. Mais on peut aussi dire qu'un segment est décrit pas deux points :

Introduction à la POO : «has a», comprend un, composition. Segment. Mais on peut aussi dire qu'un segment est décrit pas deux points : Introduction à la POO : «has a», comprend un, composition I. Préambule : On peut décrire un segment par 4 coordonnées. S e g m e n t -x1 : flo a t -y1 : flo a t -x2 : flo a t -y2 : flo a t +S e g m e(e

Plus en détail

L approche Bases de données

L approche Bases de données L approche Bases de données Cours: BD. Avancées Année: 2005/2006 Par: Dr B. Belattar (Univ. Batna Algérie) I- : Mise à niveau 1 Cours: BDD. Année: 2013/2014 Ens. S. MEDILEH (Univ. El-Oued) L approche Base

Plus en détail

Bases de Données Relationnelles. Le Modèle Relationnel

Bases de Données Relationnelles. Le Modèle Relationnel Bases de Données Relationnelles Le Modèle Relationnel Le modèle relationnel modèle de niveau logique modèle simple : deux concepts relation (table) attribut (colonne) défini par Ted Codd en 1970 ; prix

Plus en détail

Université de Bangui. Modélisons en UML

Université de Bangui. Modélisons en UML Université de Bangui CRM Modélisons en UML Ce cours a été possible grâce à l initiative d Apollinaire MOLAYE qui m a contacté pour vous faire bénéficier de mes connaissances en nouvelles technologies et

Plus en détail

Modélisation de bases de données : Le modèle relationnel

Modélisation de bases de données : Le modèle relationnel Modélisation de bases de données : Le modèle relationnel Rappel chapitre 1 C est quoi un modèle? Type de modèle : Modèle hiérarchique Modèle réseau Modèle objet Modèle relationnel Cours BD Dr REZEG K 1

Plus en détail

Modélisation des données (2)

Modélisation des données (2) Modélisation des données (2) Types et sous-types : spécialisation/généralisation Spécialisation simple Permet de modéliser, dans l ensemble des occurrences d une entité, des sous-ensembles d occurrences

Plus en détail

Modélisation Entité Association

Modélisation Entité Association Modélisation Entité Association 1 Modèle entité association Concepts de base Entités Associations Propriétés Identifiant Cardinalités des rôles Exemple Démarche de conception Passage du modèle Entité/Association

Plus en détail

Introduction. 1. Une base de données : 2. Un SGBD :

Introduction. 1. Une base de données : 2. Un SGBD : Le modèle Entité-Association Introduction Les bases de données ont pris une place importante en informatique, et particulièrement dans le domaine de la gestion. L étude des bases de données a conduit au

Plus en détail

Programmation orientée objet et événementielle en JavaScript. Département SRC Pôle Universitaire de Vichy Bruno Bachelet

Programmation orientée objet et événementielle en JavaScript. Département SRC Pôle Universitaire de Vichy Bruno Bachelet Programmation orientée objet et événementielle en JavaScript Département SRC Pôle Universitaire de Vichy Bruno Bachelet «PARTIE IV Introduction au paradigme objet Programmation objet et événementielle

Plus en détail

alg - Relations entre classes [kr]

alg - Relations entre classes [kr] alg - Relations entre classes [kr] Karine Zampieri, Stéphane Rivière, Béatrice Amerein-Soltner Unisciel algoprog Version 21 avril 2015 Table des matières 1 L association 2 1.1 Définitions...................................

Plus en détail

Le modèle relationnel Page 1 / 8

Le modèle relationnel Page 1 / 8 Le modèle relationnel Page 1 / 8 Sommaire 1 Introduction... 1 2 Les Règles de passage... 2 2.1 Le traitement des entités... 2 2.2 Les associations binaires... 3 2.2.1 Association binaire 1,1-1,n... 3 2.2.2

Plus en détail

Chapitre 4 NORMALISATION D'UNE RELATION

Chapitre 4 NORMALISATION D'UNE RELATION Chapitre 4 NORMALISATION D'UNE RELATION 1 Introduction Les modèles conceptuels (comme le modèle entité association) et les modèles logiques des SGBD (comme les modèles relationnel, orienté-objets ou relationnel-objet)

Plus en détail

GOL502 Industries de services

GOL502 Industries de services GOL502 Industries de services Conception d un service Partie IIb Version 2013 Introduction Conception d un service partie IIb Nous verrons dans ce chapitre Modélisation d un service; Langage de modélisation

Plus en détail

Bases de données. Chapitre 1. Introduction

Bases de données. Chapitre 1. Introduction Références : Bases de données Pierre Wolper Email : pw@montefiore.ulg.ac.be URL : http : //www.montefiore.ulg.ac.be/~pw/ http : //www.montefiore.ulg.ac.be/ ~pw/cours/bd.html Henry F. Korth, Abraham Silberschatz,

Plus en détail

Annexe du cours Conception des sites web marchands et mobiles

Annexe du cours Conception des sites web marchands et mobiles Conception des sites web marchands et mobiles Nassim BAHRI {contact@nassimbahri.ovh} 1 Novembre 2015 1 Diagramme de séquence système Les cas d'utilisation décrivent les interactions des acteurs avec le

Plus en détail

Le modèle de données relationnel

Le modèle de données relationnel Le modèle de données relationnel 1. Le modèle relationnel 1.1. Présentation Le modèle relationnel représente la base de données comme un ensemble de tables, sans préjuger de la façon dont les informations

Plus en détail

Conception de Bases de Données Avec UML

Conception de Bases de Données Avec UML 1 1 Bases de Données Avancées Module B IUT Lumière, License CE-STAT 2006-2007 Pierre Parrend Plan du Cours Table of Contents Conception de Bases de Données Avec UML UML et la conception de Bases de Données...2

Plus en détail

Modèle relationnel, domaine, relation, attribut, schéma relationnel, clé primaire, clé étrangère, dépendance fonctionnelle, contrainte d'intégrité

Modèle relationnel, domaine, relation, attribut, schéma relationnel, clé primaire, clé étrangère, dépendance fonctionnelle, contrainte d'intégrité Propriétés Titre Type de ressource Niveau Matière Public Description Thème Objectifs Pré-requis B2i - Niveau B2i - Objectifs Le modèle relationnel Description Document de synthèse et base de données exemple

Plus en détail

Diagramme de classes

Diagramme de classes Diagramme de classes Un diagramme de classes décrit les classes et leurs relations (associations, généralisation/spécialisation, ). classe association méthodes attributs héritage Diagramme de classes :

Plus en détail

Modèle objet/classe. Sommaire

Modèle objet/classe. Sommaire Modèle objet/classe Sommaire Pourquoi un tel modèle ; Sa place dans le processus de développement ; Les premiers concepts ; Comment construire un diagramme de classes. Sa place dans le processus de développement

Plus en détail

Diagramme de Classe UML et Base de Données Relationnelle-objet

Diagramme de Classe UML et Base de Données Relationnelle-objet Ecole des Hautes Etudes Commerciales HEC Alger Diagramme de Classe UML et Base de Données Relationnelle-objet par Amina GACEM Module Informatique 1ière Année Master Sciences Commerciales Plan Introduction

Plus en détail

Schéma conceptuel de données. Access

Schéma conceptuel de données. Access Schéma conceptuel de données Access 29/08/2014 Schéma conceptuel de données... 2 L'analyse préalable... 2 La conception de la solution... 2 Le développement du projet... 2 La mise en œuvre... 2 Les différents

Plus en détail

Chapitre 1 Généralités sur les bases de données

Chapitre 1 Généralités sur les bases de données Chapitre 1 Généralités sur les bases de données I. Définition d un SGBD Une base de données, généralement appelée BD est un ensemble structuré et organisé permettant le stockage de grandes quantités d'informations

Plus en détail

Informatique commercial : La base de données 1/14

Informatique commercial : La base de données 1/14 Informatique commercial : La base de données 1/14 Table des matières 1.Les données du modèle relationnel...3 a)l'importance de l'organisation...3 Donnée et base de données...3 b)l'organisation des données...3

Plus en détail

UML. Diagrammes de classes. Delphine Longuet. Polytech Paris-Sud Formation initiale 3 e année Spécialité Informatique Année 2015-2016

UML. Diagrammes de classes. Delphine Longuet. Polytech Paris-Sud Formation initiale 3 e année Spécialité Informatique Année 2015-2016 Polytech Paris-Sud Formation initiale 3 e année Spécialité Informatique Année 2015-2016 UML Diagrammes de classes Delphine Longuet delphine.longuet@lri.fr Objets et classes Conception orientée objet :

Plus en détail

LES CONCEPTS OBJETS. On regroupe les objets ayant les mêmes types de propriétés et de comportements en une classe.

LES CONCEPTS OBJETS. On regroupe les objets ayant les mêmes types de propriétés et de comportements en une classe. LES CONCEPTS OBJETS I Objet et Classe Un objet est une entité du monde réel qui a très souvent un identifiant des propriétés des comportements (actions qu il peut effectuer). La voiture de Clément a pour

Plus en détail

La comptabilisation dans la ligne Crésus Le module de comptabilisation

La comptabilisation dans la ligne Crésus Le module de comptabilisation Note La comptabilisation dans la ligne Crésus Le module de comptabilisation Ce document présente le fonctionnement du module de comptabilisation qui prend la relève entre les programmes de facturation

Plus en détail

UML (Diagramme de classes) Unified Modeling Language

UML (Diagramme de classes) Unified Modeling Language UML (Diagramme de classes) Unified Modeling Language Sommaire Introduction Objectifs Diagramme de classes Classe (Nom, attribut, opération) Visibilité et portée des constituants d une classe Association

Plus en détail

La gestion des doublons

La gestion des doublons fims.informatique@skynet.be 01.10 10.02 N 3 La gestion des doublons Dans la plupart des bases de données, les doublons sont souvent inévitables. Il est parfois complexe de les gérer car les informations

Plus en détail

INTRODUCTION AUX TECHNOLOGIES D INGENIERIE DES DONNEES DIRIGEE PAR LES MODELES

INTRODUCTION AUX TECHNOLOGIES D INGENIERIE DES DONNEES DIRIGEE PAR LES MODELES INTRODUCTION AUX TECHNOLOGIES D INGENIERIE DES DONNEES DIRIGEE PAR LES MODELES Les contenus de ce document sont la propriété exclusive de la société REVER. Ils ne sont transmis qu à titre d information

Plus en détail

PRINCIPES DIRECTEURS PERMETTANT DE DÉTERMINER L ENDROIT OÙ DOIVENT ÊTRE CLASSÉS LES DOCUMENTS DE BREVET DANS LA CIB

PRINCIPES DIRECTEURS PERMETTANT DE DÉTERMINER L ENDROIT OÙ DOIVENT ÊTRE CLASSÉS LES DOCUMENTS DE BREVET DANS LA CIB PRINCIPES DIRECTEURS PERMETTANT DE DÉTERMINER L ENDROIT OÙ DOIVENT ÊTRE CLASSÉS LES DOCUMENTS DE BREVET DANS LA CIB adoptés par le Comité d experts de l Union de l IPC à sa quarante-deuxième session et

Plus en détail

Spécialisation / généralisation évolutive

Spécialisation / généralisation évolutive Spécialisation / généralisation évolutive Comparaison de complexité avec une solution statique conventionnelle Créé: Juin 2005 Rédigé : Léonard Sandoz Modifié: Dirigé : Pierre-André Sunier Laboratoire

Plus en détail

BASES DE DONNÉES. CNAM Centre associé de Clermont-Ferrand Cycle A Année 1997-98. J. Darmont I. INTRODUCTION II. LES SYSTÈMES HIÉRARCHIQUES

BASES DE DONNÉES. CNAM Centre associé de Clermont-Ferrand Cycle A Année 1997-98. J. Darmont I. INTRODUCTION II. LES SYSTÈMES HIÉRARCHIQUES BASES DE DONNÉES CNAM Centre associé de Clermont-Ferrand Cycle A Année 1997-98 J. Darmont I. INTRODUCTION II. LES SYSTÈMES HIÉRARCHIQUES III. LES SYSTÈMES RÉSEAU IV. LES SYSTÈMES RELATIONNELS V. LE LANGAGE

Plus en détail

Modèle relationnel Algèbre relationnelle

Modèle relationnel Algèbre relationnelle Modèle relationnel Algèbre relationnelle Modèle relationnel (Codd 1970) On considère D i où i = 1,2..n des ensembles, dits domaines Un domaine = ensemble de valeurs (ex. D1 : entiers sur 10 positions,

Plus en détail

Synthèse sur la conception de bases de données

Synthèse sur la conception de bases de données Synthèse sur la conception de bases de données Pour fonctionner une entreprise doit traiter et organiser ses informations le plus efficacement possible. C est pourquoi il est important de concevoir des

Plus en détail

DESCRIPTION DU SI PAR NIVEAUX. Le niveau organisationnel ou logique. Le niveau opérationnel ou physique

DESCRIPTION DU SI PAR NIVEAUX. Le niveau organisationnel ou logique. Le niveau opérationnel ou physique DESCRIPTION DU SI PAR NIVEAUX Le niveau conceptuel "Quoi?" MCD MCT Le niveau organisationnel ou logique "Qui fait quoi, où et quand?" MLD MOT Le niveau opérationnel ou physique "Comment faire" MPD MPT

Plus en détail

Bases de données et langage SQL

Bases de données et langage SQL Bases de données et langage SQL Introduction, modèle entité / association Philippe.Dosch@loria.fr IUT SRC DE VERDUN 10/09/2003 Exemples introductifs Gestion de CD Artiste Album Les têtes raides Les oiseaux

Plus en détail

ESTINATION FORMATION Un aller simple vers le savoir-faire INITIATION A L ANALYSE ET A LA CONCEPTION DE BASE DE DONNEES

ESTINATION FORMATION Un aller simple vers le savoir-faire INITIATION A L ANALYSE ET A LA CONCEPTION DE BASE DE DONNEES ESTINATION FORMATION INITIATION A L ANALYSE ET A LA CONCEPTION DE BASE DE DONNEES AVANT PROPOS Ce support de cours est un outil personnel, il ne constitue pas un guide de référence. C'est un outil pédagogique

Plus en détail

Travaux dirigées Bases de Données

Travaux dirigées Bases de Données Travaux dirigées Bases de Données Série I Exercice I.1. Corrigés Rappel énoncé: On a les données suivantes sur des élèves avec le DFs: Matricule, Nom, Age, Club,Salle Matricule Nom, AGE Matricule Club

Plus en détail

Modélisation et stockage des données géographiques. Christelle Pierkot

Modélisation et stockage des données géographiques. Christelle Pierkot Modélisation et stockage des données géographiques Christelle Pierkot Rappels : L information géographique Information relative àun objet ou àun phénomène du monde réel On ne peut appréhender totalement

Plus en détail

Nous allons détailler dans cette documentation les fonctionnalités pour créer un objet colonne.

Nous allons détailler dans cette documentation les fonctionnalités pour créer un objet colonne. Généralités Dans le générateur d états des logiciels Ciel pour Macintosh vous avez la possibilité de créer différents types d éléments (texte, rubrique, liste, graphiques, tableau, etc). Nous allons détailler

Plus en détail

Diagrammes de classes et d objets

Diagrammes de classes et d objets Diagrammes de classes et d objets Exercice 1 : rédaction d un diagramme de classe Dessiner un diagramme de classe pour décrire les objets suivants: enregistreurs Exercice 1: solution possible Exercice

Plus en détail

Java Licence professionnelle CISI 2009-2010

Java Licence professionnelle CISI 2009-2010 Java Licence professionnelle CISI 2009-2010 Cours 10 : Type générique (c) http://manu.e3b.org/java/tutoriels/avance/generique.pdf 1 Introduction La programmation générique - nouveauté la plus significative

Plus en détail

Modélisation Conceptuelle de Base de Données

Modélisation Conceptuelle de Base de Données odélisation Conceptuelle de Base de Données Akoka-Wattiau 1 SOAIRE 1. La conception de base de données 2. Pourquoi la modélisation conceptuelle? 3. Le modèle ER 4. Comment modéliser? 5. Le modèle ER étendu

Plus en détail

11. Les associations sous la loupe

11. Les associations sous la loupe . Les associations sous la loupe Après avoir, dans les deux chapitres précédents, présenté la méthode que nous préconisons pour analyser les données et concevoir un modèle de la base, nous allons ici étudier

Plus en détail

Cas d'étude : Puissance 4 Analyse des besoins

Cas d'étude : Puissance 4 Analyse des besoins 1 Génie Logiciel Cas d'étude : Puissance 4 Analyse des besoins Renaud Marlet LaBRI / INRIA http://www.labri.fr/~marlet màj 18/04/2007 2 Exercice Vous êtes employé(e) dans une société qui édite des jeux

Plus en détail

Observation de la réalité, Collecte d informations Réflexion et modélisation Définitions des tables d une BD relationnelle Obtenir une représentation

Observation de la réalité, Collecte d informations Réflexion et modélisation Définitions des tables d une BD relationnelle Obtenir une représentation Bases de données Modèle relationnel BD relationnelle Observation de la réalité, Collecte d informations Réflexion et modélisation Définitions des tables d une BD relationnelle Obtenir une représentation

Plus en détail

Du modèle Entité Relation Étendu (EER) au modèle relationnel

Du modèle Entité Relation Étendu (EER) au modèle relationnel Du modèle Entité Relation Étendu (EER) au modèle relationnel Akoka-Wattiau 1 SOMMAIRE 1 - Traduction des entités 2 - Traduction des associations M-N 3 - Traduction des associations 1-N 4 - Traduction des

Plus en détail

Identifier les entités présentes

Identifier les entités présentes Merise Analyser un Système d Information déroute parfois le non-initié, car traduire un environnement de travail en symboles cabalistiques n est pas très habituel pour qui ne connaît pas. Pourtant, avec

Plus en détail

I. Bases de données. Exemples classiques d'applications BD. Besoins de description

I. Bases de données. Exemples classiques d'applications BD. Besoins de description I. Bases de données Exemples classiques d'applications BD Les besoins Qu est ce qu un SGBD, une BD Architecture d un SGBD Cycle de vie Plan du cours Gestion des personnels, étudiants, cours, inscriptions,...

Plus en détail

Fonctions de plusieurs variables

Fonctions de plusieurs variables Module : Analyse 03 Chapitre 00 : Fonctions de plusieurs variables Généralités et Rappels des notions topologiques dans : Qu est- ce que?: Mathématiquement, n étant un entier non nul, on définit comme

Plus en détail

Gestion multi-stocks

Gestion multi-stocks Gestion multi-stocks Dans l architecture initiale du logiciel IDH-STOCK, 11 champs obligatoires sont constitués. Ces champs ne peuvent être supprimés. Ils constituent l ossature de base de la base de données

Plus en détail

Méthode MERISE : Outils conceptuels et organisationnels

Méthode MERISE : Outils conceptuels et organisationnels CNAM A4 Année 2000-2001 Méthode MERISE : Outils conceptuels et organisationnels 1 Introduction : La méthode MERISE met à disposition de l'analyste des outils pour modéliser un système d'informations. C'est

Plus en détail

Sytèmes de gestion de base de données

Sytèmes de gestion de base de données Soors Aurore (2302) Année académique 2009-2010 Sytèmes de gestion de base de données Notes de cours Chapitre 1 La normalisation 1.1 Procédé de design 1. Analyse et définition des règles de gestion 2. Validation

Plus en détail

LE MODELE CONCEPTUEL DE DONNEES

LE MODELE CONCEPTUEL DE DONNEES LE MODELE CONCEPTUEL DE DONNEES Principe : A partir d'un cahier des charges, concevoir de manière visuelle les différents liens qui existent entre les différentes données. Les différentes étapes de réalisation.

Plus en détail

2A-SI 4 - Bases de Données 4.3 - Conception d une BdD relationnelle par le modèle entités-associations

2A-SI 4 - Bases de Données 4.3 - Conception d une BdD relationnelle par le modèle entités-associations 2A-SI 4 - Bases de Données 4.3 - par le modèle entités-associations Stéphane Vialle Stephane.Vialle@supelec.fr http://www.metz.supelec.fr/~vialle Avec l aide du cours de Y. Bourda Modèle entités-associations

Plus en détail

Chapitre 07 Le modèle relationnel des données

Chapitre 07 Le modèle relationnel des données Chapitre 07 Le modèle relationnel des données Introduction Ce chapitre est un prolongement de l'étude du modèle relationnel vu en classe de première. L'idée principale est de faire comprendre aux élèves

Plus en détail

1. Introduction. 2. Diagramme des exigences

1. Introduction. 2. Diagramme des exigences 1. Introduction La complexité des systèmes techniques est telle que, sans outils de représentations abstraites et progressivement enrichies, les intervenants d un projet auraient de nombreuses difficultés

Plus en détail

Bases de Données Cours de SRC 1. Mathieu MANGEOT mathieu.mangeot@univ-savoie.fr

Bases de Données Cours de SRC 1. Mathieu MANGEOT mathieu.mangeot@univ-savoie.fr Bases de Données Cours de SRC 1 Mathieu MANGEOT mathieu.mangeot@univ-savoie.fr Objectifs du cours Analyser les besoins et modéliser les données d un système d information Mettre en œuvre des bases de données

Plus en détail

A. ANALYSE DU SCHEMA DES DONNEES EXISTANT (7 POINTS)

A. ANALYSE DU SCHEMA DES DONNEES EXISTANT (7 POINTS) B T S C G O 2 C O R R I G É D U D E V O I R DOSSIER 2 - ORGANISATION DU SYSTÈME D INFORMATION (P10) A. ANALYSE DU SCHEMA DES DONNEES EXISTANT (7 POINTS) a) Commandes non livrées (2 points) Dans le schéma

Plus en détail

Chapitre 6 Héritage en Java

Chapitre 6 Héritage en Java Chapitre 6: Héritage 1/12 Chapitre 6 Héritage en Java Chapitre 6: Héritage 2/12 1. Généralités L'héritage est le troisième des paradigmes de la programmation orientée objet (le 1 er étant l'encapsulation,

Plus en détail

Machine de Turing. Informatique II Algorithmique 1

Machine de Turing. Informatique II Algorithmique 1 Machine de Turing Nous avons vu qu un programme peut être considéré comme la décomposition de la tâche à réaliser en une séquence d instructions élémentaires (manipulant des données élémentaires) compréhensibles

Plus en détail

RÈGLES DE TRANSFORMATION DU MCD AU MLD (MRD)

RÈGLES DE TRANSFORMATION DU MCD AU MLD (MRD) 1 RÈGLES DE TRANSFORMATION DU AU MLD () Nous allons définir les règles de transformation pour le passage du au MLD, en respectant les différents cas qui se posent. Transformation des entités Toute entité

Plus en détail