Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

  1. #1
    Membre à l'essai
    Homme Profil pro
    Étudiant
    Inscrit en
    avril 2019
    Messages
    16
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Côte d'Ivoire

    Informations professionnelles :
    Activité : Étudiant
    Secteur : Enseignement

    Informations forums :
    Inscription : avril 2019
    Messages : 16
    Points : 16
    Points
    16

    Par défaut MCD - Gestion de la location d'appartements

    Bonjour, je suis débutant en modélisation
    Je souhaite faire un MCD pour la gestion des appartements d’une entreprise selon les données suivantes :

    1- Tous les appartements sont attribués à travers un contrat de bail
    2- Un appartement peut être une maison basse ou être situé sur un étage. Dans le dernier cas, il faudra gérer le niveau où l’appartement est situé ;
    3- La localisation géographique retenue est le quartier et la ville ;
    4- Tous les locataires doivent produire un papier d’identité (Carte nationale d’identité, Permis de conduire, Passeport, …..) ;
    5- Tous les loyers sont mensuels et font l’objet d’une facturation mensuelle,
    6- Possibilité de payer une facture en plusieurs tranches
    J’aimerais avoir votre avis sur le MCD que je propose
    Nom : MCD_Kalix01_01.png
Affichages : 169
Taille : 120,9 Ko

    Par ailleurs ; je suis un peu confus pour la relation entre appartement-immeuble. Dans le cas où l’appartement n’est pas sur un immeuble, les informations liées à cet objet sont caduques. Comment puis-je gerer cette situation ?

    Merci d’avance pour votre attention

  2. #2
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    septembre 2006
    Messages
    6 732
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Spécialiste en bases de données
    Secteur : Conseil

    Informations forums :
    Inscription : septembre 2006
    Messages : 6 732
    Points : 24 450
    Points
    24 450
    Billets dans le blog
    16

    Par défaut

    Citation Envoyé par kalix01
    je suis un peu confus pour la relation entre appartement-immeuble. Dans le cas où l’appartement n’est pas sur un immeuble, les informations liées à cet objet sont caduques. Comment puis-je gérer cette situation ?
    Transformez l’association « situe_dans » en entité-type. Soit ETAGE cette entité-type :


    Un étage fait référence à un immeuble, mais surtout ETAGE est ce qu’on appelle une entité-type « faible » : elle n’est pas autonome, elle n’a pas d’existence propre, elle est en fait une propriété externalisée de l’entité-type APPARTEMENT. Elle n’a pas d’identifiant en propre, elle hérite de celui de APPARTEMENT. Ces particularités sont symbolisées par la cardinalité (1,1) portée par la patte d’association entre ETAGE et ETAGE_APP. Pour parvenir à cela, cliquer sur cette patte d’association et cocher la case « Identifiant » :

    Le MLD correspondant (MPD dans le jargon AMC) :

    Les tables APPARTEMENT et ETAGE ont la même clé primaire, appart_id.
    Faites simple, mais pas plus simple ! (A. Einstein)
    E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)

    Je ne réponds pas aux questions techniques par MP. Les forums sont là pout ça.
    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench

  3. #3
    Membre à l'essai
    Homme Profil pro
    Étudiant
    Inscrit en
    avril 2019
    Messages
    16
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Côte d'Ivoire

    Informations professionnelles :
    Activité : Étudiant
    Secteur : Enseignement

    Informations forums :
    Inscription : avril 2019
    Messages : 16
    Points : 16
    Points
    16

    Par défaut

    Bonjour fsmrel et merci beaucoup pour ton coup de main.
    j'ai pris en compte tes observations et voici le MCD

    Nom : MCD_Kalix01_03.png
Affichages : 137
Taille : 122,4 Ko

    Et le MPD correspondant

    Nom : MPD_Kalix01_03.png
Affichages : 138
Taille : 142,5 Ko

    Mais dans le MPD, je constate l'apparition d'un champ eta_appart_id dans la table appartement. A quoi cela est-il du ?

    Au delà de ca, le reste de mon MCD est-il acceptable notamment la facturation, les règlements, et la notion d historisation que je viens d'ajouter ?

  4. #4
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    septembre 2006
    Messages
    6 732
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Spécialiste en bases de données
    Secteur : Conseil

    Informations forums :
    Inscription : septembre 2006
    Messages : 6 732
    Points : 24 450
    Points
    24 450
    Billets dans le blog
    16

    Par défaut

    Tout d’abord, pour éviter que l’on confonde le délimiteur de pages et les associations entre objets :

    Outils > Préférences d’affichage et décocher la case « Afficher le délimiteur de page ».

    Identification relative : A son tour, QUARTIER est une entité-type faible : à elle seule elle ne pèse pas bien lourd. Elle n’est pas autonome, elle n’a pas d’existence propre, elle est en fait une propriété externalisée (multivaluée) de l’entité-type VILLE. Dans votre MCD elle est identifiée de manière absolue : {quartier_id}. Si donc on veut savoir le nom de la ville dans laquelle se situe l’immeuble I1, au stade SQL, on aura une double jointure mettant en jeu les tables IMMEUBLE, QUARTIER, VILLE. Les choses seraient simplifiées et ça serait plus efficace si on court-circuitait la table QUARTIER, on peut donc mettre à profit l’identification relative, cf. par exemple Ingénierie des systèmes d'information : Merise deuxième génération (4e édition, 2001), page 131.

    On procède donc comme dans le cas des appartements et des étages, à ceci près qu’une ville peut avoir plusieurs quartiers alors qu’un appartement ne se situe qu’à un seul étage. Pour mettre en oeuvre l’identification relative avec AMC :



    =>



    Vous me direz qu’à ce jeu-là, l’entité-type IMMEUBLE pourrait être identifiée relativement à l’entité-type QUARTIER : ç’est évidemment possible, mais ça n’a pas trop de sens puisque sémantiquement parlant, IMMEUBLE est une entité-type « forte ». Bref, à vous de voir.

    MLD :



    Vous remarquerez que l’attribut ville_id a été propagé et appartient à la table IMMEUBLE, d’où simplification des requêtes SQL pour lesquelles on n’a pas besoin du quartier.


    Je note que l’entité-type IMMEUBLE est dotée d’un attribut im_nb_etages : d’accord si l’ information est essentielle, c’est-à-dire si on ne sait pas l’inférer par simple comptage des étages.

    Entités-types CONTRAT_BAIL et HISTORIQUE_BAIL :

    Je suppose que la date d’effet bail_date_effet est la plus récente, et que la date d’effet d’un ancien contrat-bail correspond à la date de fin d’effet de son prédécesseur. C’est ça ? C’est plus subtil ? (cas par exemple des « trous », périodes sans).

    Entité-type FACTURE :

    Il n’y a aucune contrainte entre la paire d’attributs {facture_annee, facture_mois} et la date d’émission {facture_date_emission} ? le mois et l’année de la facture ne sont pas inférables de la date d’émission ?

    Entité-type LOCATAIRE :

    L’âge des personnes change au fil des ans, à remplacer donc par la date de naissance (complète ou limitée à l’année...), date qui ne change pas.

    Association IDENTIFIER :

    Pour deux paires {LOCATAIRE, TYPE_PIECE}, on peut effectivement avoir plus d’une valeur pour l’attribut piece_numero ?

    Dans votre MLD (qui n’est pas ce qu’il est convenu d’appeler un MPD, lequel permet de mettre en oeuvre des objets physiques tels que des index, des partitionnements d’espace, etc.), vous êtes victime de l’incurie de PowerAMC : celui-ci a créé un lien dans le sens APPARTEMENT > ETAGE, ce qui est stupide, puisqu’un appartement ne dépend pas d’un étage... Faites comme moi, après génération du MLD (MPD AMC...), virez manuellement ce lien (comme je l’ai fait de mon côté) : vous le sélectionnez par clic puis vous utilisez la touche SUPPR de votre clavier...

    Pour un débutant en modélisation, vous méritez la mention « Très bien » :-)

    En passant, il n’est pas interdit de liker quand les réponses rendent service...
    Faites simple, mais pas plus simple ! (A. Einstein)
    E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)

    Je ne réponds pas aux questions techniques par MP. Les forums sont là pout ça.
    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench

  5. #5
    Membre à l'essai
    Homme Profil pro
    Étudiant
    Inscrit en
    avril 2019
    Messages
    16
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Côte d'Ivoire

    Informations professionnelles :
    Activité : Étudiant
    Secteur : Enseignement

    Informations forums :
    Inscription : avril 2019
    Messages : 16
    Points : 16
    Points
    16

    Par défaut

    Merci pour cette reponse vraiment detaillée. Et j'ai pris en compte les remarques que tu as formu
    Identification relative : A son tour, QUARTIER est une entité-type faible : à elle seule elle ne pèse pas bien lourd. Elle n’est pas autonome, elle n’a pas d’existence propre, elle est en fait une propriété externalisée (multivaluée) de l’entité-type VILLE. Dans votre MCD elle est identifiée de manière absolue : {quartier_id}. Si donc on veut savoir le nom de la ville dans laquelle se situe l’immeuble I1, au stade SQL, on aura une double jointure mettant en jeu les tables IMMEUBLE, QUARTIER, VILLE.
    Le problème c'est que chez nous ici, il peut arriver que deux quartiers aient le même nom dans deux villes différentes. L'identification relative ne pose-t-il pas problème dans ce cas ?

    Je suppose que la date d’effet bail_date_effet est la plus récente, et que la date d’effet d’un ancien contrat-bail correspond à la date de fin d’effet de son prédécesseur. C’est ça ? C’est plus subtil ? (cas par exemple des « trous », périodes sans).
    Ce n'est pas forcement le cas. Donc dois-je dupliquer la date d'effet dans l'entité-type HISTORIQUE_BAIL ?

    L’âge des personnes change au fil des ans, à remplacer donc par la date de naissance (complète ou limitée à l’année...), date qui ne change pas.
    Je vais changer le nom de l'attribut loc_age pour mettre peut etre loc_date_naissance car en effet il s'agit bien de la date de naissance

    Pour deux paires {LOCATAIRE, TYPE_PIECE}, on peut effectivement avoir plus d’une valeur pour l’attribut piece_numero ?
    Oui c'est possible

  6. #6
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    septembre 2006
    Messages
    6 732
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Spécialiste en bases de données
    Secteur : Conseil

    Informations forums :
    Inscription : septembre 2006
    Messages : 6 732
    Points : 24 450
    Points
    24 450
    Billets dans le blog
    16

    Par défaut

    Citation Envoyé par kalix01
    Le problème c'est que chez nous ici, il peut arriver que deux quartiers aient le même nom dans deux villes différentes. L'identification relative ne pose-t-il pas problème dans ce cas ?
    Plutôt que de faire un exposé théorique, je préfère passer directement au niveau tabulaire concret et prendre un exemple. Ainsi, créons les tables VILLE et QUARTIER.

    Code SQL (par exemple SQL Server, histoire de fixer les idées, où « séquentiel » et à remplacer par « IDENTITY ») :

    CREATE TABLE VILLE
    (
            ville_id       INT   IDENTITY        NOT NULL
          , ville_nom      VARCHAR(30)           NOT NULL
        , CONSTRAINT VILLE_PK PRIMARY KEY (ville_id)
    ) ;
    
    Créons quelques villes :

    INSERT INTO VILLE (ville_nom)
        VALUES ('Londres'), ('Athènes'), ('Madrid')
    
    Au résultat, où l’on voit qu’à ma demande (clause IDENTITY oblige) le SGBD s’est chargé d’affecter les valeurs pour la colonne ville_id :

    VILLE {ville_id, ville_nom}
           --------  ---------
           1         Londres
           2         Athènes
           3         Madrid
    
    Créons la table QUARTIER :

    CREATE TABLE QUARTIER
    (
            ville_id       INT                   NOT NULL
          , quartier_id    INT   IDENTITY        NOT NULL
          , quartier_nom   VARCHAR(30)           NOT NULL
        , CONSTRAINT QUARTIER_PK PRIMARY KEY (ville_id, quartier_id)
        , CONSTRAINT QUARTIER_AK UNIQUE (ville_id, quartier_nom)
        , CONSTRAINT QUARTIER_VILLE_FK FOREIGN KEY (ville_id)
              REFERENCES VILLE (ville_id) 
    ) ;
    
    Créons quelques quartiers :

    INSERT INTO QUARTIER (ville_id, quartier_nom)
      SELECT (SELECT ville_id FROM VILLE WHERE  ville_nom = 'Londres'), 'City'
    ;
    INSERT INTO QUARTIER (ville_id, quartier_nom)
      SELECT (SELECT ville_id FROM VILLE WHERE  ville_nom = 'Londres'), 'Whitechapel'
    ;
    INSERT INTO QUARTIER (ville_id, quartier_nom)
      SELECT (SELECT ville_id FROM VILLE WHERE  ville_nom = 'Londres'), 'Quartier Sud'
    ;
    INSERT INTO QUARTIER (ville_id, quartier_nom)
      SELECT (SELECT ville_id FROM VILLE WHERE  ville_nom = 'Athènes'), 'Le Pirée'
    ;
    INSERT INTO QUARTIER (ville_id, quartier_nom)
      SELECT (SELECT ville_id FROM VILLE WHERE  ville_nom = 'Athènes'), 'Acropole'
    ;
    INSERT INTO QUARTIER (ville_id, quartier_nom)
      SELECT (SELECT ville_id FROM VILLE WHERE  ville_nom = 'Athènes'), 'Agora'
    ;
    INSERT INTO QUARTIER (ville_id, quartier_nom)
      SELECT (SELECT ville_id FROM VILLE WHERE  ville_nom = 'Madrid'), 'Amande centrale'
    ;
    INSERT INTO QUARTIER (ville_id, quartier_nom)
      SELECT (SELECT ville_id FROM VILLE WHERE  ville_nom = 'Madrid'), 'Quartier Sud'
    ;
    
    Au résultat, où l’on voit qu’à nouveau (clause IDENTITY oblige) le SGBD s’est chargé d’affecter les valeurs pour la colonne quartier_id :

     
    QUARTIER {Ville_id, quartier_id, quartier_nom}
              -------   -----------  ------------
              1         1            City
              1         2            Whitechapel
              1         3            Quartier Sud
              2         4            Le Pirée
              2         5            Acropole
              3         6            Agora
              3         7            Amande centrale
              3         8            Quartier Sud
    
    La colonne quartier_id prend les valeurs successives 1, 2, 3, ..., 8, mais on va dire que c’est un hasard.

    Moralité : Les villes de Londres et Madrid ont toutes deux un quartier 'Quartier Sud'. Clairement l'identification relative n’a posé aucun problème. Les valeurs prises par les colonnes IDENTITY ont été fournies par le SGBD sans que j’ai à m’en occuper. Ainsi, les colonnes ville_id et quartier_id correspondent à des données artificielles et leurs valeurs m’indiffèrent totalement, je sous-traite leur affectation au SGBD, et qui plus est, je ne mentionne jamais les valeurs affectées à ces colonnes dans les requêtes. Seules les colonnes correspondant à des données naturelles m’intéressent (le nom d’une personne, sa date de naissance, le nom d’une ville, celui d’un quartier, etc.), ce sont les seules colonnes dont je ferai mention des valeurs dans les requêtes.

    Par ailleurs, une ville ne peut pas avoir deux quartiers ayant le même nom, d’où la clé alternative QUARTIER_AK (ville_id, quartier_nom) à ajouter à la main dans le MLD. Cette contrainte d’unicité n’est malheureusement pas déclarable au stade MCD.

    Concernant l’invariance des clés primaires (donc des identifiants), voir le billet De l’invariance des clés primaires.


    dois-je dupliquer la date d'effet dans l'entité-type HISTORIQUE_BAIL ?
    Oui, chaque occurrence de cette entité-type doit avoir une date de début et une date de fin, puisque de la date de fin de l’occurrence Oi on ne peut pas systématiquement inférer la date de début de l’occurrence Oi+1.
    Faites simple, mais pas plus simple ! (A. Einstein)
    E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)

    Je ne réponds pas aux questions techniques par MP. Les forums sont là pout ça.
    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench

  7. #7
    Membre à l'essai
    Homme Profil pro
    Étudiant
    Inscrit en
    avril 2019
    Messages
    16
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Côte d'Ivoire

    Informations professionnelles :
    Activité : Étudiant
    Secteur : Enseignement

    Informations forums :
    Inscription : avril 2019
    Messages : 16
    Points : 16
    Points
    16

    Par défaut

    Merci bien pour ta riche contribution. Je vais prendre en compte cette dernière observation et finaliser mon travail.

    Bonne journée

  8. #8
    Membre à l'essai
    Homme Profil pro
    Étudiant
    Inscrit en
    avril 2019
    Messages
    16
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Côte d'Ivoire

    Informations professionnelles :
    Activité : Étudiant
    Secteur : Enseignement

    Informations forums :
    Inscription : avril 2019
    Messages : 16
    Points : 16
    Points
    16

    Par défaut

    Bonjour et toutes mes excuses de revenir à la charge.
    En fait il y a un élément nouveau que je doit prendre en compte.
    IL y a en réalité plusieurs sites et je dois en tenir compte.
    Pour cela j'ai modifier le MCD, au lieu de relier un immeuble au quartier, je relie l'immeuble à un site qui lui est relié au quartier.

    Nom : MCD_Kalix01_04.png
Affichages : 113
Taille : 72,9 Ko

    Comme je l'ai signalé au début du post, un appartement peut ne pas être sur un immeuble, dans ce cas,
    comment je fais la liaison entre l'appartement avec le site où il est situé
    .

    Merci beaucoup

  9. #9
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    septembre 2006
    Messages
    6 732
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Spécialiste en bases de données
    Secteur : Conseil

    Informations forums :
    Inscription : septembre 2006
    Messages : 6 732
    Points : 24 450
    Points
    24 450
    Billets dans le blog
    16

    Par défaut

    Il s’agit donc d’associer à un site soit des immeubles, soit des appartements. Le mieux est d’utiliser la généralisation/spécialisation des entités-types, donc l’héritage.

    On définit une nouvelle entité-type, nommons-la par exemple LIEU (ou HABITATION ou tout autre nom à votre convenance), qui généralise les concepts d’IMMEUBLE et d’APPARTEMENT : un lieu est soit un immeuble, soit un appartement ; un lieu appartient à un et un seul site, tandis qu’un site contient plusieurs lieux.

    IMMEUBLE et APPARTEMENT sont des spécialisations de LIEU.

    LIEU a un identifiant, nommons-le par exemple lieu_id. IMMEUBLE et APPARTEMENT n’ont pas d’identifiant en propre, car héritant par définition de celui de LIEU. Cela ne les empêche pas d’avoir des identifiants alternatifs, tel appart_code, dans la mesure où dans votre système deux appartements ne pourraient pas avoir le même code.

    MCD :


    Nom : kalix01_mcd_v2.png
Affichages : 106
Taille : 19,8 Ko

    MLD :

    Héritage oblige, L’AGL a généré de lui-même les clés des tables IMMEUBLE et APPARTEMENT.

    Nom : kalix01_mld_v2.png
Affichages : 107
Taille : 16,5 Ko

    Je vous conseille de lire l’ouvrage de référence de D. Nanci (RIP) et B. Espinasse :

    Ingénierie des systèmes d'information : Merise deuxième génération (4e édition, 2001), pages 106 et suivantes.

    N.B. Avec AMC, pour le lien d’héritage (cliquer sur la lunule), retenir l’option « n’hériter que des attributs primaires ».
    Faites simple, mais pas plus simple ! (A. Einstein)
    E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)

    Je ne réponds pas aux questions techniques par MP. Les forums sont là pout ça.
    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench

  10. #10
    Membre à l'essai
    Homme Profil pro
    Étudiant
    Inscrit en
    avril 2019
    Messages
    16
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Côte d'Ivoire

    Informations professionnelles :
    Activité : Étudiant
    Secteur : Enseignement

    Informations forums :
    Inscription : avril 2019
    Messages : 16
    Points : 16
    Points
    16

    Par défaut

    OK merci bien je me mets à l’œuvre.
    Un petit détail, dans cette configuration, je rattachache l'entité contrat_bail à "appartement" ou à la nouvelle entité "lieu" ?

    Bonne soirée

  11. #11
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    septembre 2006
    Messages
    6 732
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Spécialiste en bases de données
    Secteur : Conseil

    Informations forums :
    Inscription : septembre 2006
    Messages : 6 732
    Points : 24 450
    Points
    24 450
    Billets dans le blog
    16

    Par défaut

    Rattacher à LIEU voudrait dire qu’un contrat-bail pourrait concerner tout type de lieu, auquel cas un immeuble pourrait en faire l’objet. Au contraire, si un contrat-bail ne peut concerner qu’un appartement, la relation reste donc entre CONTRAT-BAIL et APPARTEMENT.
    Faites simple, mais pas plus simple ! (A. Einstein)
    E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)

    Je ne réponds pas aux questions techniques par MP. Les forums sont là pout ça.
    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench

  12. #12
    Membre à l'essai
    Homme Profil pro
    Étudiant
    Inscrit en
    avril 2019
    Messages
    16
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Côte d'Ivoire

    Informations professionnelles :
    Activité : Étudiant
    Secteur : Enseignement

    Informations forums :
    Inscription : avril 2019
    Messages : 16
    Points : 16
    Points
    16

    Par défaut

    OK j'ai tenu compte de tes recommandations et voici le MCD

    Nom : MCD_Kalix01_05.png
Affichages : 99
Taille : 124,0 Ko

    Et le MPD (pour power AMC) qui va avec:

    Nom : MPD_Kalix01_05.png
Affichages : 103
Taille : 160,7 Ko

    1. Dans le MPD, des champs supplémentaires (soulignés en rouge sur le MPD) apparaissent dans les tables etage et appartement. Comme tu l'as dis dans les précédents post je dois les enlever manuellement ? Car je remarque que dans ton avant-dernier post c’était le cas dans la table etage

    2. Avec la réplication de l'identifiant habitation_id dans les tables appartement, immeuble et etage, je veux comprendre le fonctionnement. Pour cela un petit exemple:
    En supposant que j'ai déjà créer un site avec site_id=3, je veut créer mon premier immeuble:
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    INSERT INTO habitation (habitation_id, site_id) VALUES (1,3) ;
    INSERT INTO immeuble (habitation_id,im_nb_etage,im_nom , im_annee_construction) VALUES (1,7,"Tour Eifel",2015) ;
    Ensuite je crée un appartement mais qui n'est pas situé sur un immeuble
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    INSERT INTO habitation (habitation_id, site_id) VALUES (2,3) ;
    INSERT INTO appartement (habitation_id,appart_code,appart_nb_piece,appart_superficie) VALUES (2,"AK 200",4,185) ;
    Et maintenant j'ajoute un deuxième appartement, qui est au 6e étage de l'immeuble.

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    INSERT INTO habitation (habitation_id, site_id) VALUES (3,3) ;
    INSERT INTO appartement (habitation_id,appart_code,appart_nb_piece,appart_superficie) VALUES (3,"GT 31",3,137) ;
    Et maintenant je dois intégrer l'information dans la table etage (l'id de l'immeuble=1 et l'id de l'appartement=3).
    Dois-je écrire
    INSERT INTO etage (habitation_id, etage_numero) VALUES (1,6) ;
    dans ce cas on ne sais pas de quel appartement il s'agit

    ou bien
    INSERT INTO etage (habitation_id, etage_numero) VALUES (3,6) ;
    On ne sait pas de quel immeuble il s'agit.

    Merci

  13. #13
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    septembre 2006
    Messages
    6 732
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Spécialiste en bases de données
    Secteur : Conseil

    Informations forums :
    Inscription : septembre 2006
    Messages : 6 732
    Points : 24 450
    Points
    24 450
    Billets dans le blog
    16

    Par défaut

    Dans le MPD, des champs supplémentaires (soulignés en rouge sur le MPD) apparaissent dans les tables etage et appartement.
    Comme disent volontiers CinePhil, escartefigue et SQLpro, les champs c’est à la campagne et dans un MLD on parle plutôt d’attributs (ou de colonnes dans le cas de SQL). Cela dit, dans la table APPARTEMENT, manuellement ce n’est pas l’attribut eta_habitation_id qu’il faut supprimer, mais la référence (lien) FK_ETAGE_APPART2.

    Quant à l’attribut imm_habitation_id il doit être conservé, car il permet de faire référence à l’immeuble où il se situe.

    Les noms des attributs des clés de IMMEUBLE et APPARTEMENT sont générés automatiquement par AMC, mais ces noms sont trompeurs car AMC a pris le parti en toute légalité de reprendre le nom de l’attribut de la clé de HABITATION (on imagine mal ce qu’il pourrait faire d’autre).

    Quoi qu’il en soit, une fois le ménage effectué (suppression de la référence FK_ETAGE_APPART2 et c’est tout !) il n’est pas mauvais de renommer les attributs identifiants comme ci-dessous :

    Nom : kalix01_mld_v3.png
Affichages : 102
Taille : 13,2 Ko

    Mais pour rendre justice à la sémantique, il est préférable de modéliser ainsi :

    MCD

    Nom : kalix01_mcd_by_moi_v4.png
Affichages : 101
Taille : 11,3 Ko

    Où l’entité-type faible ETAGE s’est transformée en entité-type spécialisée (sous-type chez les merisiens) APPARTEMENT_D_IMMEUBLE (sous-entendu il y a aussi des appartements qui ne sont pas à étage, mais faute d’attributs discriminants les caractérisant, il est inutile de mettre en oeuvre une entité-type spécialisée APPARTEMENT_PAS_D_IMMEUBLE). :-)

    MLD

    Nom : kalix01_mld_by_moi_v4.png
Affichages : 104
Taille : 14,4 Ko

    AMC se dispense cette fois-ci de générer la référence erronée FK_ETAGE_APPART2. Pour faire causer le MLD, j’ai fourni à AMC les noms des rôles « enfants » (Être) et « parents » (Avoir).


    Citation Envoyé par kalix01
    Et maintenant je dois intégrer l'information dans la table etage (l'id de l'immeuble=1 et l'id de l'appartement=3).
    Le problème est que vous avez supprimé un peu trop vite l’attribut imm_habitation_id. En effet c’est lui qui permet de référencer l’immeuble auquel appartient l’appartement.

    Avec le MLD ci-dessus (ou celui qu’il remplace) :

    HABITATION {habitation_id ...}
                -------------    
                1                
                2
                3
    
    APPARTEMENT {appart_id ...}           IMMEUBLE {im_id ...}
                 ---------                          -----
                 2                                  1
    
    APPARTEMENT_D_IMMEUBLE  {appart_id   im_id ...}
                             ---------   -----
                             3           1
    
    Cette fois-ci, l’appartement 3 appartient bien à l’immeuble 1.


    En passant :

    Le type BIGINT utilisé pour habitation_id permet de gérer près de dix milliards de milliards d’habitations : le type INT permet d’en gérer « seulement » deux milliards et SMALLINT 16000... Evitons BIGINT :-)
    Faites simple, mais pas plus simple ! (A. Einstein)
    E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)

    Je ne réponds pas aux questions techniques par MP. Les forums sont là pout ça.
    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench

  14. #14
    Membre à l'essai
    Homme Profil pro
    Étudiant
    Inscrit en
    avril 2019
    Messages
    16
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Côte d'Ivoire

    Informations professionnelles :
    Activité : Étudiant
    Secteur : Enseignement

    Informations forums :
    Inscription : avril 2019
    Messages : 16
    Points : 16
    Points
    16

    Par défaut

    Merci je vais prendre en compte tes recommandations.

    Et merci pour tous le temps consacré à mon post. Ta contribution m'a vraiment sauvé

  15. #15
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    septembre 2006
    Messages
    6 732
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Spécialiste en bases de données
    Secteur : Conseil

    Informations forums :
    Inscription : septembre 2006
    Messages : 6 732
    Points : 24 450
    Points
    24 450
    Billets dans le blog
    16

    Par défaut

    Citation Envoyé par kalix01
    Ta contribution m'a vraiment sauvé
    Alors une médaille de sauvetage est de mise, c’est ici ;-)
    Faites simple, mais pas plus simple ! (A. Einstein)
    E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)

    Je ne réponds pas aux questions techniques par MP. Les forums sont là pout ça.
    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench

  16. #16
    Membre à l'essai
    Homme Profil pro
    Étudiant
    Inscrit en
    avril 2019
    Messages
    16
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Côte d'Ivoire

    Informations professionnelles :
    Activité : Étudiant
    Secteur : Enseignement

    Informations forums :
    Inscription : avril 2019
    Messages : 16
    Points : 16
    Points
    16

    Par défaut

    Alors une médaille de sauvetage est de mise, c’est ici ;-)
    J'ai visité la page, mais concrètement que dois-je faire ? je ne vois pas de bouton like, ou autre ....

    Bon week end

  17. #17
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    septembre 2006
    Messages
    6 732
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Spécialiste en bases de données
    Secteur : Conseil

    Informations forums :
    Inscription : septembre 2006
    Messages : 6 732
    Points : 24 450
    Points
    24 450
    Billets dans le blog
    16

    Par défaut

    Citation Envoyé par kalix01
    je ne vois pas de bouton like, ou autre ....
    En descendant, on aperçoit des médailles du genre :

    Nom : medailles.png
Affichages : 97
Taille : 15,5 Ko

    Il suffit de cliquer sur celles qui conviennent...

    Bon week-end aussi !
    Faites simple, mais pas plus simple ! (A. Einstein)
    E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)

    Je ne réponds pas aux questions techniques par MP. Les forums sont là pout ça.
    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench

  18. #18
    Membre à l'essai
    Homme Profil pro
    Étudiant
    Inscrit en
    avril 2019
    Messages
    16
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Côte d'Ivoire

    Informations professionnelles :
    Activité : Étudiant
    Secteur : Enseignement

    Informations forums :
    Inscription : avril 2019
    Messages : 16
    Points : 16
    Points
    16

    Par défaut

    Bonjour et bon début de semaine.
    Une dernière question concernant l'historisation de l’occupation des appartements.
    Lorsqu'un contrat bail est résilié, dois-je le supprimer de la table contrail_bail (pour ne garder que les bails en cours) et stocker toutes les infos concernant le bail dans historique_bail
    Ou bien ne pas le supprimer auquel cas je ne met dans la table historique_bail que l'id du bail et la date de résiliation ?

    Merci à tous

  19. #19
    Expert éminent sénior

    Homme Profil pro
    bourreau
    Inscrit en
    mars 2010
    Messages
    4 577
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loir et Cher (Centre)

    Informations professionnelles :
    Activité : bourreau
    Secteur : Finance

    Informations forums :
    Inscription : mars 2010
    Messages : 4 577
    Points : 11 558
    Points
    11 558
    Billets dans le blog
    1

    Par défaut

    Concernant ce dernier point, en quoi un bail peut il avoir un historique ?
    Il me semble qu'un bail concerne un seul locataire ou groupe de locataires et que si ce locataire change, on crée un nouveau bail, non ?
    Auquel cas, il n'y a pas de table historique à créer, un simple attribut date de fin de bail avec éventuellement un code motif de fin ajouté dans la table des baux (plutôt que des bails ) doit suffire.
    Par défaut, la date de fin de bail sera valorisée à "9999-12-31" par le SGBD

  20. #20
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    septembre 2006
    Messages
    6 732
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Spécialiste en bases de données
    Secteur : Conseil

    Informations forums :
    Inscription : septembre 2006
    Messages : 6 732
    Points : 24 450
    Points
    24 450
    Billets dans le blog
    16

    Par défaut

    Citation Envoyé par escartefigue
    Auquel cas, il n'y a pas de table historique à créer, un simple attribut date de fin de bail avec éventuellement un code motif de fin ajouté dans la table des baux (plutôt que des bails ) doit suffire.
    Par défaut, la date de fin de bail sera valorisée à "9999-12-31" par le SGBD
    C’est effectivement une possibilité, "9999-12-31" étant alors synonyme de « en cours ».


    Citation Envoyé par kalix01
    Ou bien ne pas le supprimer auquel cas je ne met dans la table historique_bail que l’id du bail et la date de résiliation ?
    C’est une 2e possibilité, qui vaut par sa conformité aux recommandations de Date et Darwen (les meilleurs théoriciens du relationnel).

    Le MCD correspondant est alors le suivant :

    Nom : kalix01_mcd_v5_baux.png
Affichages : 78
Taille : 9,0 Ko

    MLD

    Nom : kalix01_mld_v5_baux.png
Affichages : 79
Taille : 9,1 Ko
    Faites simple, mais pas plus simple ! (A. Einstein)
    E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)

    Je ne réponds pas aux questions techniques par MP. Les forums sont là pout ça.
    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench

+ Répondre à la discussion
Cette discussion est résolue.
Page 1 sur 2 12 DernièreDernière

Discussions similaires

  1. [MCD] MCD pour la location d 'appartements
    Par beegees dans le forum Schéma
    Réponses: 2
    Dernier message: 22/02/2012, 19h41
  2. [MCD] Gestion d'acces a des applications
    Par Tibler dans le forum Schéma
    Réponses: 12
    Dernier message: 25/04/2006, 18h10
  3. [BEST_PRACTICE][Merise] MCD & gestion de date
    Par Seb7 dans le forum Schéma
    Réponses: 5
    Dernier message: 10/01/2006, 05h49
  4. [MCD] [MCD] Gestion des dates
    Par brionne dans le forum Schéma
    Réponses: 3
    Dernier message: 30/05/2003, 13h01

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo