TD 1 MODELE ENTITES ASSOCIATIONS - Modélisation Merise

Ce document constitue le premier travail dirigé (TD 1) de la série, conçu pour les étudiants universitaires souhaitant maîtriser les concepts fondamentaux du Modèle Entités-Associations (E/A). Il sert à la fois de rappel de cours et d'introduction pratique à la conception de bases de données.

À travers une série d'exercices, vous explorerez les notions suivantes :

• La compréhension des cardinalités d'associations et de l'héritage.
• La conception et l'adaptation de schémas E/A.
• La conversion entre les modèles E/A et relationnel.

Ce TD vise à développer votre expérience dans la modélisation de données.

Modélisation Merise : TD 1 MODELE ENTITES ASSOCIATIONS

Télécharger PDF

Modèle Entités-Associations : Exercices Pratiques

Ce tutoriel propose une série d'exercices conçus pour approfondir la compréhension des concepts fondamentaux des modèles Entité-Association (E/A) et leur transformation en schémas relationnels. Les premiers exercices se concentrent sur la lecture et l'interprétation des cardinalités d'associations, l'héritage et les liens avec le modèle relationnel, des points cruciaux qui requièrent une attention particulière et une pratique régulière. La conception de schémas de bases de données, en particulier la gestion des aspects temporels et historiques, représente un défi qui s'affine avec l'expérience.

1. Modélisation d'une Équipe de Rugby

Pour cet exercice, nous allons considérer un schéma Entité-Association hypothétique représentant des équipes de rugby et leurs composants.

Analyse du Schéma Entité-Association

Voici quelques questions clés pour analyser la structure d'un tel schéma E/A :

• Combien d'entités composent ce modèle ? Quel attribut sert d'identifiant unique pour une équipe ?
• Est-il possible que deux stades partagent le même nom, par exemple « Stade municipal » ? Cela soulève la question de l'unicité des identifiants et des contraintes d'intégrité.
• Combien d'associations possèdent au moins un attribut propre, décrivant une caractéristique spécifique de la relation elle-même ?
• Pourquoi l'entité Équipe ne devrait-elle pas inclure un attribut tel que « stade préféré » avec le nom du stade comme valeur ? Cette question aborde la normalisation et la déduplication des données. Il est préférable d'utiliser des associations pour représenter de telles relations.
• Un Sponsor peut-il ne financer aucun Joueur ? Cela explore les cardinalités minimales des associations.
• Un Joueur peut-il n’avoir aucun Sponsor ? De même, cela interroge les cardinalités minimales.
• À combien d’équipes (minimum et maximum) un Joueur peut-il appartenir ? Ceci concerne les cardinalités maximales et minimales d'une association entre Joueur et Équipe.
• Plusieurs équipes peuvent-elles préférer le même stade ? Cela impacte la cardinalité de l'association entre Équipe et Stade.
• Un stade est-il toujours préféré par au moins une équipe ? Ceci vérifie la cardinalité minimale côté Stade dans l'association de préférence.

Adaptations et Extensions du Schéma E/A

Considérons les modifications suivantes pour enrichir le schéma de l'équipe de rugby :

• **Durée du financement :** Il est nécessaire d'enregistrer la durée (en nombre d'années) pendant laquelle un sponsor finance un joueur. Cet attribut devrait être placé sur l'association entre Sponsor et Joueur.
• **Unicité des noms d'équipe et villes :** Pour gérer des cas comme « Racing » à Pau et à Aix, il faut s'assurer que l'identifiant de l'équipe inclut non seulement son nom, mais potentiellement un lien vers une entité Ville.
• **Informations sur la ville :** La population de la ville doit être enregistrée. L'entité Ville devrait avoir un attribut population.
• **Stade d'entraînement :** Une équipe peut avoir un stade d’entraînement distinct de son stade préféré, et certaines équipes n'en ont pas. Cela implique une nouvelle association optionnelle (cardinalité minimale 0) entre Équipe et Stade, distincte de l'association pour le stade préféré.

2. Modélisation d'un Match de Football

Analysons un schéma Entité-Association lié à des matchs de football.

Analyse d'un Schéma E/A de Match de Foot

• **Associations réflexives :** Combien d'associations relient une entité à elle-même ? Ces associations sont souvent utilisées pour modéliser des relations entre entités de même type, comme des matchs successifs ou des relations hiérarchiques.
• **Arête maximale :** Quelle association présente l'arité la plus élevée (c'est-à-dire le plus grand nombre d'entités participantes) et quelle est cette arité ? Les associations d'arité supérieure à 2 sont dites n-aires et sont utilisées pour modéliser des relations complexes.
• **Labels sur les arcs :** Pourquoi l'association « distance » pourrait-elle ne pas avoir de labels sur ses arcs ? L'absence de labels sur les arcs peut indiquer une relation symétrique ou une convention de modélisation simplifiée où le rôle de chaque participant est implicite.

Adaptations et Enrichissements du Schéma

Pour affiner le modèle, voici des points à considérer :

• **Rôles des équipes dans un match :** Pour chaque match, il faut distinguer l'équipe « invitante » et l'équipe « invitée ». Ceci peut être représenté par des rôles spécifiques sur l'association entre Match et Équipe.
• **Entraîneurs :** Chaque équipe possède un entraîneur. Nous devons enregistrer le nom et l’âge de l'entraîneur (mais pas sa taille). Un entraîneur peut gérer plusieurs équipes. Cela suggère une entité Entraîneur avec des attributs nom et âge, et une association de type (1,N) entre Entraîneur et Équipe (un entraîneur peut entraîner plusieurs équipes, une équipe a un seul entraîneur).
• **Identification des joueurs :** Pour les joueurs, il est important de stocker leur numéro d’adhérent national, surtout si plusieurs joueurs peuvent avoir le même nom. Le numéro d'adhérent national devient un identifiant clé ou un attribut unique. L'entité Joueur aurait numéro_adhérent_national (identifiant) et nom.

3. Conception d'un Schéma E/A pour un Musée

Décrivons les entités, associations, attributs et cardinalités pour modéliser les informations suivantes :

• **Villes :** Une entité Ville avec comme identifiant nom_ville et un attribut pays.
• **Musées :** Une entité Musée avec comme identifiant nom_musée et un attribut description.
• **Relation Ville-Musée :** Une Ville peut avoir plusieurs Musées (1,N), et un Musée est situé dans une seule Ville (1,1). Association "Situé_dans".
• **Œuvres :** Une entité Œuvre avec comme identifiant titre_œuvre et un attribut siècle.
• **Relation Œuvre-Artiste :** Une entité Artiste avec nom_artiste et prénom_artiste comme identifiant composé ou un identifiant générique (ex: id_artiste). Un Artiste réalise de nombreuses Œuvres (1,N), et chaque Œuvre est réalisée par un seul Artiste (1,1). Association "Réalise".
• **Exposition d'œuvres :** Une Œuvre est exposée dans un Musée pendant une période donnée (date_début, date_fin). Une œuvre peut ne pas être exposée (0,N) et être exposée dans différents musées à différentes périodes. L'association "Exposée_dans" entre Œuvre et Musée doit être ternaire avec les attributs date_début et date_fin. Les cardinalités seraient (0,N) pour Œuvre et (0,N) pour Musée, car une œuvre peut être dans plusieurs musées ou aucun, et un musée peut exposer plusieurs œuvres ou aucune. L'identifiant de cette association serait composé de l'identifiant de l'Œuvre, de l'identifiant du Musée et de la date_début pour distinguer les périodes d'exposition.

4. Modélisation d'un Album de Musique

La création d'un schéma Entité-Association pour gérer des albums de musique implique plusieurs entités et relations complexes.

a) Établissement du Schéma E/A

• **Albums :** Entité Album avec code_album (identifiant) et date_sortie.
• **Plages :** Entité Plage avec numéro_plage (identifiant relatif à l'album) et durée.
• **Œuvres :** Entité Œuvre avec code_œuvre (identifiant) et titre_œuvre.
• **Interprètes :** Entité Interprète avec id_interprète (identifiant) et nom_interprète.

Associations :

• **Composition d'album :** Un Album est composé d'une ou plusieurs Plages (1,N). Une Plage appartient à un seul Album (1,1). L'identifiant d'une Plage serait (code_album, numéro_plage).
• **Plage-Œuvre :** Chaque Plage est l'enregistrement d'une seule Œuvre (1,1). Une Œuvre peut s'étendre sur plusieurs Plages (1,N) ou n'être pas enregistrée du tout (0,N). L'association "Enregistre" entre Plage et Œuvre aura les cardinalités (1,1) côté Plage et (0,N) côté Œuvre.
• **Interprétation d'œuvre sur une plage :** On connaît les interprètes de l’œuvre pour une plage donnée. Une Œuvre peut être jouée par plusieurs Interprètes (0,N). Un Interprète peut jouer de nombreuses Œuvres (0,N). Cette relation est contextuelle à une Plage. La modélisation la plus simple est une association entre Interprète et Plage, où les cardinalités seraient (0,N) des deux côtés. L'identifiant de l'association "Interprète_sur_Plage" serait (id_interprète, code_album, numéro_plage).

b) Placement de l'attribut "Instrument"

Si chaque interprète utilise exactement un instrument sur une plage donnée, l'attribut « instrument » ne peut pas être placé directement sur l'entité Interprète (car un interprète pourrait jouer de plusieurs instruments sur différentes plages) ni sur l'entité Plage (car plusieurs interprètes pourraient jouer sur la même plage avec des instruments différents). Il doit être placé sur l'association entre Interprète et Plage (ou sur l'association ternaire "Interprète_sur"). Cela indique quel instrument est joué par quel interprète sur une plage spécifique.

5. Modélisation d'une Course Nautique

Pour gérer les informations d'une course nautique, plusieurs entités et associations sont nécessaires afin de répondre aux besoins spécifiques de suivi.

1) Proposition de Modèle Entité-Association (E/A)

• **Course :** Entité Course (id_course (identifiant), nom_course).
• **Épreuve :** Entité Épreuve (id_épreuve (identifiant), date, heure_départ, heure_fin). Une Course contient plusieurs Épreuves (1,N). Une Épreuve appartient à une seule Course (1,1). L'identifiant d'une épreuve pourrait être (id_course, numéro_ordre_épreuve) ou simplement id_épreuve si unique globalement.
• **Port :** Entité Port (id_port (identifiant), nom_port, localisation). Une Épreuve a un port de départ et un port d'arrivée. Deux associations entre Épreuve et Port : "Départ_de" et "Arrivée_à", avec des cardinalités (1,1) côté Port pour chaque épreuve.
• **Bateau :** Entité Bateau (id_bateau (identifiant), nom_bateau, longueur).
• **Sponsor :** Entité Sponsor (id_sponsor (identifiant), nom_sponsor, adresse).
• **Relation Bateau-Sponsor :** Un Bateau est financé par un ou plusieurs Sponsors (1,N). Un Sponsor peut financer plusieurs Bateaux (0,N). L'association "Finance" entre Bateau et Sponsor aura un attribut montant_subvention pour répondre à la question spécifique.
• **Personne :** Entité Personne (id_personne (identifiant), nom, prénom, date_naissance, type_personne (skipper, équipier, médecin, etc.)).
• **Rôle de Skipper :** Un Bateau a un seul Skipper (1,1). Un Skipper est une Personne. Le Skipper ne change pas pour la durée de la course. Association "Est_skipper_de" entre Personne (rôle Skipper) et Bateau (1,1) pour Bateau, (0,1) pour Personne.
• **Rôle d'Équipier :** Un Bateau est armé d'un équipage composé d'équipiers. La composition des équipiers peut changer par épreuve. L'association "Participe_à_épreuve" entre Personne (rôle Équipier), Bateau et Épreuve. Cette association ternaire pourrait avoir les cardinalités (0,N) pour Personne (un équipier peut participer à plusieurs épreuves ou aucune, sur différents bateaux), (0,N) pour Bateau (un bateau a plusieurs équipiers sur une épreuve), et (0,N) pour Épreuve (une épreuve implique plusieurs équipiers et bateaux). Attributs comme classement pourraient être sur l'association d'engagement ou sur une association de résultat.
• **Classement :** L'association "Classement" entre Bateau et Épreuve, avec un attribut position. Cardinalités (0,N) pour Bateau (il peut participer à plusieurs épreuves), (0,N) pour Épreuve (plusieurs bateaux par épreuve).

Les questions posées par le cahier des charges guident la conception des attributs et des associations, en particulier pour le montant de la subvention, les dates d'engagement et les rôles spécifiques des équipiers.

2) Déduction du Schéma Relationnel

La déduction du schéma relationnel à partir du modèle E/A suit des règles précises :

• Chaque entité forte devient une table. Ses attributs deviennent des colonnes, et son identifiant devient la clé primaire.
• Les associations (1,1) ou (1,N) peuvent être représentées en ajoutant la clé primaire de l'entité côté "1" comme clé étrangère dans la table de l'entité côté "N".
• Les associations (N,N) deviennent des tables à part entière, avec les clés primaires des entités participantes comme clés étrangères composant souvent la clé primaire de cette nouvelle table d'association.
• Les associations ternaires deviennent également des tables, avec les clés des trois entités comme clés étrangères.
• Les attributs des associations sont ajoutés à la table de l'association correspondante.
• L'héritage (si présent) peut être géré par différentes stratégies (table par super-type, table par sous-type, ou une table unique).

Par exemple, pour l'association "Finance" (Bateau N-N Sponsor) avec l'attribut montant_subvention, on créerait une table FINANCE (id_bateau*, id_sponsor*, montant_subvention) où id_bateau et id_sponsor seraient des clés étrangères et conjointement la clé primaire.

6. Analyse d'un Schéma E/A de Consultation Médicale

Bien que le schéma E/A ne soit pas fourni, nous pouvons discuter des concepts et des questions qu'il soulève concernant les visites médicales.

1. Identification des Composantes d'un Schéma E/A

Un schéma Entité-Association est composé de :

• **Entités :** Les objets principaux du système (ex: Patient, Médecin, Consultation, Médicament).
• **Attributs :** Les propriétés des entités (ex: nom, prénom, date_naissance pour Patient ; spécialité pour Médecin). Certains attributs sont des identifiants (clés primaires).
• **Associations :** Les liens entre les entités (ex: un Médecin consulte un Patient, un Patient se voit prescrire un Médicament).
• **Cardinalités :** Les règles qui définissent le nombre minimal et maximal d'occurrences d'une entité participant à une association (ex: un Patient peut avoir (0,N) consultations, une Consultation implique (1,1) Médecin).

2. Questions d'Analyse des Caractéristiques du Schéma

Sans le schéma visuel, l'analyse se base sur les cardinalités et la structure implicite d'un tel modèle :

• **Prescription multiple de médicaments :** La capacité à prescrire plusieurs médicaments lors d'une même consultation dépend de la cardinalité de l'association entre Consultation et Médicament. Si elle est (1,N) ou (0,N) côté Médicament, alors oui.
• **Plusieurs patients par consultation :** Un médecin peut-il recevoir plusieurs patients dans la même consultation ? Généralement, une Consultation est liée à un seul Patient (cardinalité (1,1) côté Patient).
• **Consultations multiples pour un patient :** Un patient peut-il être consulté plusieurs fois ? Oui, la cardinalité de l'association entre Patient et Consultation devrait être (0,N) ou (1,N) côté Consultation.
• **Prescription multiple du même médicament pour un patient :** Un médicament peut-il être prescrit plusieurs fois pour un même patient ? Cela dépend si l'association de prescription inclut une date ou un identifiant unique par prescription. Si l'association est entre Patient, Médicament et Consultation, la clé de l'association pourrait permettre des prescriptions multiples à différentes occasions.
• **Consultations multiples le même jour :** Un patient peut-il être consulté plusieurs fois le même jour ? Si l'identifiant de Consultation inclut seulement la date, cela pourrait être restrictif. Si un identifiant unique ou un créneau horaire est utilisé, c'est possible.
• **Consultations multiples le même jour par le même médecin :** Un patient peut-il être consulté plusieurs fois le même jour par le même médecin ? Similaire à la question précédente, si la Consultation est identifiée par (Médecin, Patient, Date, Heure), c'est possible pour des heures différentes.

3. Déduction du Schéma Relationnel

La transformation d'un schéma E/A de consultation médicale en schéma relationnel suivrait les principes évoqués précédemment. Par exemple :

• Table PATIENT (id_patient, nom, prénom, date_naissance, ...)
• Table MEDECIN (id_médecin, nom, prénom, spécialité, ...)
• Table CONSULTATION (id_consultation, date, heure, id_patient*, id_médecin*)
• Table MEDICAMENT (id_médicament, nom, description, ...)
• Table PRESCRIPTION (id_consultation*, id_médicament*, quantité, posologie, ...)

4. Exemple de Base de Données

Un exemple concret illustrerait comment les données sont stockées et comment les questions précédentes sont gérées :

PATIENT : (1, 'Dupont', 'Jean', '1980-01-15')

MEDECIN : (10, 'Martin', 'Sophie', 'Généraliste')

CONSULTATION :

• (100, '2023-10-26', '10:00', 1, 10) // M. Dupont consulte Dr Martin
• (101, '2023-10-26', '11:00', 1, 10) // M. Dupont consulte à nouveau Dr Martin le même jour (si le schéma le permet par heure)

MEDICAMENT : (200, 'Paracétamol'), (201, 'Ibuprofène')

PRESCRIPTION :

• (100, 200, '2', '1 cp matin, 1 cp soir') // Pour la consultation 100, Paracétamol est prescrit
• (100, 201, '1', '1 cp midi') // Pour la consultation 100, Ibuprofène est aussi prescrit (réponse à 2.a)
• (101, 200, '1', '1 cp soir') // Pour la consultation 101, Paracétamol est prescrit à nouveau pour le même patient (réponse à 2.d et 2.e/f)

7. Modélisation d'une Base de Données Cinéma

La conception d'une base de données pour le cinéma implique de gérer les informations sur les films, les acteurs et les réalisateurs, ainsi que leurs interactions.

1. Proposition d'un Schéma Entité-Association (E/A)

Hypothèses :

• Un film est identifié par son titre. Pour assurer l'unicité (ex: différents films avec le même titre), on peut ajouter une année de sortie ou un identifiant générique (id_film). Ici, nous nous en tiendrons à l'hypothèse que le titre est unique.
• Un acteur est identifié par son nom et prénom. Similaire au titre de film, un identifiant générique (id_personne) est souvent préférable pour éviter les homonymes.
• Un réalisateur est une personne, et peut aussi être un acteur. Cela suggère une hiérarchie ou des rôles distincts pour une entité Personne.

Entités :

• **Film :** (titre_film (identifiant), nombre_entrées).
• **Personne :** (id_personne (identifiant), nom, prénom, âge, adresse). Cette entité représente à la fois les acteurs et les réalisateurs pour éviter la duplication et faciliter la gestion des rôles multiples.

Associations :

• **Réalisation :** Un Film est réalisé par un Réalisateur (qui est une Personne). Initialement, un film a un seul réalisateur (1,1). Un réalisateur peut réaliser plusieurs films (0,N). Association "Réalisé_par" entre Film et Personne (avec rôle "Réalisateur"). Cardinalités : Film (1,1) vers Personne, Personne (0,N) vers Film.
• **Jeu d'acteur :** Une Personne (en tant qu'acteur) joue dans un Film. Un Acteur peut jouer dans plusieurs Films (0,N), et un Film peut avoir plusieurs Acteurs (0,N). L'association "Joue_dans" entre Film et Personne (avec rôle "Acteur") doit avoir un attribut cachet.

2. Déduction du Schéma Relationnel

• **Table FILM :** (titre_film PK, nombre_entrées, id_réalisateur FK vers PERSONNE)
• **Table PERSONNE :** (id_personne PK, nom, prénom, âge, adresse)
• **Table JOUE_DANS (association N-N avec attribut) :** (id_personne PK FK vers PERSONNE, titre_film PK FK vers FILM, cachet)

Les clés primaires sont soulignées. Les clés étrangères sont indiquées avec (FK) et référencent la table d'origine.

3. Exemple de Base de Données

Voici un exemple pour illustrer le schéma :

PERSONNE :

• (1, 'Durand', 'Pierre', 45, '123 Rue A') // Acteur et Réalisateur
• (2, 'Lefevre', 'Marie', 30, '456 Av B') // Actrice
• (3, 'Dupont', 'Jean', 55, '789 Bd C') // Réalisateur seulement

FILM :

• ('Le Grand Voyage', 1000000, 1) // Réalisé par Pierre Durand (id=1)
• ('L'Aventure Solitaire', 500000, 3) // Réalisé par Jean Dupont (id=3)
• ('Mystère Ancien', 50000, NULL) // Film sans réalisateur connu et sans acteur
• ('La Symphonie', 800000, 1) // Réalisé par Pierre Durand (id=1)

JOUE_DANS :

• (2, 'Le Grand Voyage', 50000) // Marie Lefevre (id=2) joue dans 'Le Grand Voyage' (réalisé par Pierre Durand (id=1)) -> Acteur joue sans réaliser le film.
• (1, 'La Symphonie', 100000) // Pierre Durand (id=1) joue dans 'La Symphonie' (réalisé par lui-même) -> Acteur joue et réalise.
• (2, 'La Symphonie', 75000) // Marie Lefevre (id=2) joue dans 'La Symphonie'.

Illustrations :

• Un acteur (Marie Lefevre) a joué dans un film ('Le Grand Voyage') sans le réaliser.
• Un réalisateur (Jean Dupont) a réalisé un film ('L'Aventure Solitaire') sans y jouer (il n'est pas dans la table JOUE_DANS pour ce film).
• Un acteur (Pierre Durand) a réalisé un film ('La Symphonie') et y a joué.
• Un film ('Mystère Ancien') n'a pas d'acteur (pas dans JOUE_DANS) et son réalisateur n'est pas spécifié.

4. Gestion de Réalisateurs Multiples pour un Film

Si un film peut avoir plusieurs réalisateurs, le modèle E/A et le schéma relationnel doivent être adaptés :

• **Modèle E/A :** L'association "Réalisé_par" entre Film et Personne (avec rôle "Réalisateur") devient une association de type (N,N). Un Film peut être réalisé par plusieurs Personnes (1,N), et une Personne peut réaliser plusieurs Films (0,N).
• **Schéma Relationnel :** L'attribut id_réalisateur dans la table FILM doit être supprimé. Une nouvelle table d'association est créée pour gérer la relation N-N.

**Nouvelle table d'association pour les réalisateurs :**

REALISE_PAR (id_personne PK FK vers PERSONNE, titre_film PK FK vers FILM)

Exemple de données pour REALISE_PAR :

• (4, 'Kung Fu Panda') // Supposons id_personne 4 pour Mark Osborne
• (5, 'Kung Fu Panda') // Supposons id_personne 5 pour John Stevenson

Les identifiants 4 et 5 correspondraient à Mark Osborne et John Stevenson dans la table PERSONNE.

8. Modélisation d'une Bibliothèque

Cet exercice explore la déduction d'un schéma relationnel et son adaptation à partir d'un modèle E/A pour une bibliothèque.

1. Déduction du Schéma Relationnel (Livres et Revues seulement)

En supposant un modèle E/A où une entité Ouvrage est une super-entité avec deux sous-entités Livre et Revue (relation d'héritage), et que seuls les livres et revues sont présents :

• **Stratégie :** On peut utiliser la stratégie "une table par sous-type avec identifiant partagé" ou "une table par super-type avec des attributs optionnels".
• **Exemple de schéma relationnel (Table par sous-type) :**
• LIVRE (id_ouvrage PK, titre, auteur, isbn, ...)
• REVUE (id_ouvrage PK, titre, éditeur, issn, numéro, ...)
• Une table OUVRAGE (id_ouvrage PK, type_ouvrage) peut exister pour gérer les identifiants uniques et le type, avec les clés id_ouvrage des tables LIVRE et REVUE étant également clés étrangères vers OUVRAGE.

2. Adaptation pour d'autres types d'Ouvrages

Si la bibliothèque peut prêter des ouvrages qui ne sont ni des revues ni des livres (ex: CD, DVD, thèses) :

• **Modèle E/A :** La super-entité Ouvrage deviendrait encore plus générique, et de nouvelles sous-entités (CD, DVD, etc.) seraient ajoutées avec leurs attributs spécifiques.
• **Schéma Relationnel :** La meilleure approche serait probablement une table OUVRAGE générique contenant les attributs communs (id_ouvrage PK, titre, date_acquisition, type_ouvrage) et des tables spécifiques pour chaque type d'ouvrage (LIVRE, REVUE, CD, DVD), où l'identifiant de ces tables serait également une clé étrangère vers la table OUVRAGE. La stratégie "table par super-type et sous-types" est la plus flexible.

9. Conception d'une Base de Données pour une Fédération de Cyclisme

La création d'une base de données pour une fédération de cyclisme est un projet complexe nécessitant de modéliser coureurs, équipes, courses, résultats et suivi médical.

a) Schéma Entité-Association (E/A) Proposé

• **Coureur :** (id_coureur (identifiant), nom, prénom, taille, date_naissance).
• **Équipe :** (id_équipe (identifiant), nom_équipe, budget).
• **Directeur Sportif :** (id_directeur (identifiant), nom, prénom, date_naissance). Une Équipe est dirigée par un Directeur_Sportif (1,1). Un Directeur_Sportif dirige une seule Équipe à la fois (0,1).
• **Sponsor :** (id_sponsor (identifiant), nom_sponsor, adresse, domaine_activité). Une Équipe est financée par plusieurs Sponsors (1,N). Un Sponsor peut financer plusieurs Équipes (0,N). Association "Finance_équipe".
• **Course :** (id_course (identifiant), nom_course, distance_totale).
• **Étape :** (id_étape (identifiant relatif à la course), numéro_ordre, date_étape, type_étape, ville_départ, ville_arrivée). Une Course a une ou plusieurs Étapes (1,N). Une Étape appartient à une seule Course (1,1). Identifiant de l'étape : (id_course, numéro_ordre).
• **Participation Coureur-Étape :** Un Coureur participe à une Étape. Association "Participe_à_étape" entre Coureur et Étape avec l'attribut classement_étape. Cardinalités : Coureur (0,N), Étape (0,N).
• **Vainqueur Course :** Une Course a un Vainqueur_Final (un Coureur) (1,1). Un Coureur peut être vainqueur de plusieurs Courses (0,N). Association "Est_vainqueur_de".
• **Soigneur :** (id_soigneur (identifiant), nom, prénom, date_naissance, nationalité). Une Équipe emploie plusieurs Soigneurs par course (1,N). Un Soigneur est employé par une seule Équipe pour une course donnée (1,1). L'association "Emploie_pour_course" entre Équipe, Soigneur et Course.
• **Produit Médical :** (id_produit (identifiant), nom_produit, indication, contre_indication, posologie).
• **Administration Produit :** Un Soigneur administre un Produit à un Coureur lors d'une Étape. Association quaternaire "Administre" entre Soigneur, Produit, Coureur et Étape, avec l'attribut dose. Cardinalités (1,N) pour Soigneur, (1,N) pour Produit, (1,N) pour Coureur, (1,N) pour Étape.
• **Appartenance Coureur-Équipe :** Un Coureur appartient à une seule Équipe (1,1) à un moment donné. Une Équipe a plusieurs Coureurs (1,N). Association "Appartient_à_équipe".

Ces éléments constituent les bases pour un schéma E/A complet, avec une attention particulière aux cardinalités pour refléter les règles de gestion.

b) Déduction du Schéma Relationnel

Suivant les règles de dérivation E/A vers relationnel :

• **COUREUR :** (id_coureur, nom, prénom, taille, date_naissance, id_équipe FK)
• **EQUIPE :** (id_équipe, nom_équipe, budget, id_directeur FK)
• **DIRECTEUR_SPORTIF :** (id_directeur, nom, prénom, date_naissance)
• **SPONSOR :** (id_sponsor, nom_sponsor, adresse, domaine_activité)
• **FINANCE_EQUIPE :** (id_équipe FK, id_sponsor FK)
• **COURSE :** (id_course, nom_course, distance_totale, id_vainqueur_final FK vers COUREUR)
• **ETAPE :** (id_course FK, numéro_ordre, date_étape, type_étape, ville_départ, ville_arrivée)
• **PARTICIPATION_ETAPE :** (id_coureur FK, id_course FK, numéro_ordre_étape FK, classement_étape)
• **SOIGNEUR :** (id_soigneur, nom, prénom, date_naissance, nationalité)
• **EMPLOIE_POUR_COURSE :** (id_équipe FK, id_soigneur FK, id_course FK)
• **PRODUIT_MEDICAL :** (id_produit, nom_produit, indication, contre_indication, posologie)
• **ADMINISTRATION_PRODUIT :** (id_soigneur FK, id_produit FK, id_coureur FK, id_course FK, numéro_ordre_étape FK, dose)

Les attributs soulignés représentent les clés primaires (composées ou simples). Les 'FK' indiquent les clés étrangères.

c) Aspect Temporel et Historique

Pour stocker l'historique des informations qui évoluent annuellement (composition des équipes, directeur, budget, sponsors, etc.), plusieurs stratégies sont possibles :

• **Ajout d'une date de validité :** Modifier les tables concernées en ajoutant des attributs date_début_validité et date_fin_validité à chaque enregistrement. Cela permet de conserver toutes les versions historiques. Par exemple, pour l'équipe : EQUIPE_HISTO (id_équipe, date_début_validité, nom_équipe, budget, id_directeur, date_fin_validité).
• **Création de tables historiques :** Pour chaque table dont les données évoluent, créer une table "historique" qui stocke les versions précédentes, déclenchée par des mises à jour.
• **Versionnage par édition de course :** Intégrer l'année ou l'identifiant de l'édition de la course dans les clés primaires des tables liées aux éléments qui changent (ex: EQUIPE_ANNEE (id_équipe, année, nom_équipe, budget, id_directeur), FINANCE_EQUIPE_ANNEE (id_équipe, année, id_sponsor)). Cela permet de lier explicitement les données à une édition spécifique. C'est souvent la solution la plus adaptée pour des événements sportifs annuels.

La troisième option semble la plus pertinente ici, car les changements sont explicitement liés aux "éditions" de la course.

10. Gestion des Personnels Universitaires et de leurs Emplois du Temps

La modélisation des personnels universitaires (enseignants, chercheurs, enseignants-chercheurs) et de leurs emplois du temps est un exemple classique d'utilisation de l'héritage dans les modèles E/A.

Schéma Entité-Association (E/A)

• **Super-entité Personnel :** (id_personnel (identifiant), nom, prénom, bureau).
• **Sous-entités :** Enseignant, Chercheur, Enseignant_Chercheur.
• Enseignant_Chercheur hérite de Enseignant et Chercheur (héritage multiple ou modélisation avec des rôles). L'énoncé indique "sont à la fois enseignants et chercheurs", ce qui suggère un chevauchement/généralisation. Une approche est de faire de Personnel la super-entité, et Enseignant, Chercheur, Enseignant_Chercheur des sous-entités avec des attributs spécifiques. Enseignant_Chercheur peut avoir un attribut pourcentage_enseignement.
• **Réunion :** (id_réunion (identifiant), date_réunion, heure_début, heure_fin, salle_réunion).
• **Participation à la Réunion :** Une Personne (n'importe quel Personnel) participe à une Réunion. Association "Participe" entre Personnel et Réunion. Cardinalités : Personnel (0,N), Réunion (1,N).
• **Cours :** (id_matière (identifiant), nom_matière, salle_cours, période_début, période_fin, jour_semaine, heure_début_cours, heure_fin_cours).
• **Dispense Cours :** Un Enseignant dispense un Cours. Un Enseignant peut enseigner plusieurs matières (0,N), et plusieurs fois la même matière à des périodes différentes. Un Cours peut être dispensé par plusieurs Enseignants (0,N) (si le même cours, à la même matière, est enseigné par plusieurs profs). Ici, "plusieurs enseignants peuvent enseigner la même matière dans l'année, à des jours et créneaux horaires différents". Donc l'association est entre Enseignant et une "occurrence de cours" ou Cours. Une association "Dispense" entre Enseignant et Cours. Cardinalités : Enseignant (0,N), Cours (1,N). La clé du Cours doit inclure la période, jour, créneau.
• **Mission :** (id_mission (identifiant), date_début_mission, date_fin_mission, lieu_mission).
• **Effectue Mission :** Un Chercheur effectue une Mission. Association "Effectue" entre Chercheur et Mission. Cardinalités : Chercheur (0,N), Mission (1,1).
• **Laboratoire :** (id_laboratoire (identifiant), nom_laboratoire, secrétariat_urgence).
• **Appartient à Laboratoire :** Un Chercheur appartient à un Laboratoire (1,1). Un Laboratoire a plusieurs Chercheurs (0,N). Association "Appartient_à_Labo".

Déduction du Schéma Relationnel

Pour l'héritage, nous pouvons utiliser la stratégie "une table par super-type et une table par sous-type".

• **PERSONNEL :** (id_personnel, nom, prénom, bureau, type_personnel (ex: 'E', 'C', 'EC'))
• **ENSEIGNANT :** (id_personnel FK vers PERSONNEL)
• **CHERCHEUR :** (id_personnel FK vers PERSONNEL)
• **ENSEIGNANT_CHERCHEUR :** (id_personnel FK vers PERSONNEL, pourcentage_enseignement)
• **REUNION :** (id_réunion, date_réunion, heure_début, heure_fin, salle_réunion)
• **PARTICIPE_REUNION :** (id_personnel FK, id_réunion FK)
• **MATIERE :** (id_matière, nom_matière, salle_cours)
• **COURS_DISPENSE :** (id_cours_dispense, id_matière FK, période_début, période_fin, jour_semaine, heure_début_cours, heure_fin_cours, id_enseignant FK vers ENSEIGNANT) // Chaque occurrence de cours est liée à un enseignant.
• **MISSION :** (id_mission, date_début_mission, date_fin_mission, lieu_mission, id_chercheur FK vers CHERCHEUR)
• **LABORATOIRE :** (id_laboratoire, nom_laboratoire, secrétariat_urgence)
• **APPARTIENT_LABO :** (id_chercheur FK vers CHERCHEUR, id_laboratoire FK) // Si un chercheur ne peut appartenir qu'à un labo, la FK id_laboratoire pourrait être dans CHERCHEUR directement. Ici c'est N-N pour flexibilité.

11. Tennis : Reconstruction du Modèle E/A à partir du Schéma Relationnel

Reconstruire un modèle Entité-Association à partir d'un schéma relationnel existant permet de comprendre les relations sous-jacentes et les contraintes de conception. Voici le schéma relationnel donné :

• TOURNOI (lieu, année)
• JOUEUR (nujoueur, nom, prénom, annaiss, nationalité)
• RENCONTRE (nugagnant*, nuperdant*, lieu*, année*, score)
• GAIN (nujoueur*, lieu*, année*, sponsor*, prime)
• SPONSOR (nom_sponsor, chiffre_d_affaires, adresse)

Interprétation et Modèle E/A :

• **Entités :**
• Tournoi (Identifiant : lieu, année)
• Joueur (Identifiant : nujoueur, Attributs : nom, prénom, annaiss, nationalité)
• Sponsor (Identifiant : nom_sponsor, Attributs : chiffre_d_affaires, adresse)
• **Associations :**
• **RENCONTRE :** Cette table représente une association entre Joueur et Tournoi. Les attributs nugagnant et nuperdant suggèrent des rôles spécifiques pour les joueurs. L'association serait "Participe_à_Rencontre" entre deux rôles de Joueur (Gagnant, Perdant) et Tournoi, avec l'attribut score. Les clés étrangères (lieu*, année*) montrent que la rencontre est spécifique à un tournoi. Les cardinalités seraient : un Tournoi contient plusieurs Rencontres (1,N). Une Rencontre implique deux Joueurs spécifiques (1,1) pour Gagnant et (1,1) pour Perdant, et appartient à un (1,1) Tournoi.
• **GAIN :** Cette table représente une association ternaire entre Joueur, Tournoi et Sponsor. Les clés étrangères (nujoueur*, lieu*, année*, sponsor*) indiquent que le gain est spécifique à un joueur, un tournoi et un sponsor donné, avec l'attribut prime. Les cardinalités seraient N-N-N : un Joueur peut avoir des gains de différents Sponsors dans différents Tournois. Un Sponsor peut donner des gains à différents Joueurs dans différents Tournois. Un Tournoi peut générer des gains pour plusieurs Joueurs avec plusieurs Sponsors.

12. Jeux Olympiques : Reconstruction du Modèle E/A à partir du Schéma Relationnel

À partir du schéma relationnel des Jeux Olympiques, nous pouvons déduire le modèle Entité-Association sous-jacent.

• Pays (code, nom)
• Sport (sid, nom)
• Epreuve (epId, sid*, nom, categorie, dateDebut, dateFin)
• Athlete (aid, nom, prenom, dateNaissance, pays*)
• Equipe (eqId, pays*)
• AthletesEquipe (eqId*, aid*)
• RangIndividuel (epId*, aid*, rang)
• RangEquipe (epId*, eqId*, rang)

Interprétation et Modèle E/A :

• **Entités :**
• Pays (Identifiant : code, Attribut : nom)
• Sport (Identifiant : sid, Attribut : nom)
• Épreuve (Identifiant : epId, Attributs : nom, categorie, dateDebut, dateFin)
• Athlète (Identifiant : aid, Attributs : nom, prénom, dateNaissance)
• Équipe (Identifiant : eqId)
• **Associations et Cardinalités :**
• **Épreuve-Sport :** Une Épreuve est associée à un Sport (clé étrangère sid dans Epreuve). Un Sport peut avoir plusieurs Épreuves (1,N). Une Épreuve appartient à un seul Sport (1,1).
• **Athlète-Pays :** Un Athlète représente un Pays (clé étrangère pays dans Athlete). Un Pays peut avoir plusieurs Athlètes (0,N). Un Athlète représente un seul Pays (1,1).
• **Équipe-Pays :** Une Équipe représente un Pays (clé étrangère pays dans Equipe). Un Pays peut avoir plusieurs Équipes (0,N). Une Équipe représente un seul Pays (1,1).
• **AthlètesEquipe :** Cette table est une association N-N entre Athlète et Équipe. Un Athlète peut faire partie de plusieurs Équipes (si le contexte le permet, ex: différentes disciplines, ou historique). Une Équipe est composée de plusieurs Athlètes (1,N). Cardinalités (0,N) pour Athlète, (1,N) pour Équipe.
• **RangIndividuel :** Cette table représente l'association "Obtient_rang" entre Épreuve et Athlète, avec l'attribut rang. C'est une N-N puisque un athlète participe à plusieurs épreuves et une épreuve a plusieurs athlètes. Cardinalités (0,N) pour Athlète, (0,N) pour Épreuve.
• **RangEquipe :** Similaire à RangIndividuel, c'est l'association "Obtient_rang" entre Épreuve et Équipe, avec l'attribut rang. Cardinalités (0,N) pour Équipe, (0,N) pour Épreuve.

Foire Aux Questions (FAQ) sur les Modèles E/A et Relationnels

Qu'est-ce qu'un modèle Entité-Association (E/A) ?

Un modèle Entité-Association est une représentation conceptuelle des données utilisée dans la conception de bases de données. Il décrit les entités (objets réels ou abstraits), leurs attributs (propriétés des entités), et les associations (relations) entre ces entités, incluant les cardinalités qui définissent le nombre minimal et maximal d'occurrences impliquées dans chaque relation.

Quelle est la différence entre un modèle E/A et un schéma relationnel ?

Le modèle E/A est un modèle conceptuel, indépendant de la technologie, qui se concentre sur la signification des données et les relations entre elles de manière abstraite. Le schéma relationnel, en revanche, est un modèle logique, directement translatable en tables de base de données (comme SQL). Il définit les tables, les colonnes, les clés primaires et les clés étrangères, et est une étape concrète vers l'implémentation physique de la base de données.

Pourquoi les cardinalités sont-elles cruciales dans un modèle E/A ?

Les cardinalités sont essentielles car elles définissent les règles métier et les contraintes d'intégrité de la base de données. Elles indiquent, pour chaque extrémité d'une association, le nombre minimum et maximum d'occurrences d'une entité qui peuvent être liées à une occurrence de l'autre entité. Une modélisation précise des cardinalités garantit que la base de données reflète fidèlement la réalité des données et aide à prévenir les erreurs de données.

Cela peut vous intéresser :

Rattrapage Avril2018 Solution - Modélisation Merise

Ce document pédagogique est spécifiquement conçu pour les étudiants universitaires, notamment ceux inscrits en Parcours Gestion. Il présente un examen...

Devoir 1 sujet - Modélisation Merise

Ce document est un devoir universitaire destiné aux étudiants en BTS CGO, axé sur l'organisation des systèmes d'information. Il présente une étude de ...

Sujet 1 mcd Gestion d'un pressing - Modélisation Merise

Ce document est destiné aux étudiants universitaires en informatique, spécifiquement ceux abordant la conception de bases de données. Il contient deux...

Examen en Informatique de gestion - Modélisation Merise

Ce document est un examen d'informatique de gestion conçu pour les étudiants universitaires du parcours Gestion (niveau S5). Il a pour objectif d'éval...

Devoir n°1 Merise 2 et SQL corrigé - Modélisation Merise

Ce document universitaire présente la correction détaillée du Devoir n°1, axé sur la conception de bases de données. Il est destiné aux étudiants univ...

Solution de l’examen 1 en informatique de gestion - Modélisa

Ce document propose la solution complète de l'examen en informatique de gestion, spécifiquement conçu pour les étudiants du Parcours Gestion en semest...

Correction examen conception - Modélisation Merise

Ce document pédagogique est destiné aux étudiants universitaires des filières d'informatique de gestion et des domaines connexes. Il a pour objectif d...

Solution Examen 2 en informatique de gestion - Modélisation

Ce document présente la solution détaillée d'un examen en informatique de gestion, spécifiquement conçu pour les étudiants universitaires. Il s'adress...

Voir tous →