IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
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

Diagrammes de Classes Discussion :

Diagramme de Classes et conception Base de Donnees


Sujet :

Diagrammes de Classes

  1. #1
    Candidat au Club
    Homme Profil pro
    Administrateur systèmes et réseaux
    Inscrit en
    Avril 2021
    Messages
    23
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Administrateur systèmes et réseaux

    Informations forums :
    Inscription : Avril 2021
    Messages : 23
    Points : 4
    Points
    4
    Par défaut Diagramme de Classes et conception Base de Donnees
    Bonjour a tous,
    Pour un projet universitaire,
    Je suis en train de travailler sur le projet qui consiste a mettre en place un site web/application mobile permettant aux particuliers après inscription d'échanger des places de parkings ou la location en temps réel d'une place de parkings. le site devra permettre l'affichage des parkings disponibles sur une carte Google Map.
    J'ai fais les cas d'utilisations :

    Nom : CasUtilisationMembre.PNG
Affichages : 2166
Taille : 41,0 KoNom : CasUtilisationVisiteur.PNG
Affichages : 2487
Taille : 55,3 Ko


    Je dois faire le diagramme des classes et la modélisation base de donnes. j'ai commence la conception de la bdd, est-ce le bon déroulement ? . J'ai du mal a comprendre la différence entre Diagramme de Classes et conception Base de Données.

    Apres réflexion, je pense qu'il faut commencer par le diagramme des classes. Je l'ai fait. Pouvez-vous me donner votre avis ?

    Nom : DiagrammeDesClasses.PNG
Affichages : 2791
Taille : 42,2 Ko
    Merci bien.

  2. #2
    Modérateur
    Avatar de escartefigue
    Homme Profil pro
    bourreau
    Inscrit en
    Mars 2010
    Messages
    10 133
    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 : 10 133
    Points : 38 555
    Points
    38 555
    Billets dans le blog
    9
    Par défaut
    Bonjour NarumiN et bienvenue sur ce forum

    Sur la partie traitements, je ne m'attarderai pas, ce n'est pas mon domaine de compétences.
    Je note toutefois que le mélange de termes anglais et français n'est pas une bonne idée (même si j'imagine que ce formalise vous est imposé).
    Soit on s'adresse à des francophones et on n'utilise que du français, soit le public est international et l'usage de l'anglais s'impose.

    Concrètement, je ne vois pas ce que "membre extend connexion" signifie (les traductions possibles de "extend" étant étendre, prolonger, augmenter, agrandir...)

    Sur la partie données, avant de commencer la modélisation, il faut identifier les acteurs ou objets de gestion, c'est ce que vous avez fait avec les "membres", "parking", "réservation" etc., mais aussi les règles de gestion qui décrivent les relations entre ces acteurs.
    Attribuez à chaque règle de gestion un identifiant sous la forme (exemple)
    R001a : chaque membre peut effectuer plusieurs réservations
    R001b : une réservation est effectuée par un et un seul membre
    R002a : un membre peut publier plusieurs annonces
    R002b : une annonce est publiée par un seul membre
    etc.

    Quand ce sera fait, il faudra établir un modèle conceptuel des données avec un logiciel Adhoc.
    Il existe des logiciels gratuits parmi lesquels Looping que je vous recommande (simple d'utilisation et très complet)

    Attention au typage des données : un identifiant primaire de type chaine et un code postal ou un téléphone de type entier ne sont pas appropriés, mais nous pourrons y revenir plus tard.
    La première étape c'est les règles de gestion

  3. #3
    Candidat au Club
    Homme Profil pro
    Administrateur systèmes et réseaux
    Inscrit en
    Avril 2021
    Messages
    23
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Administrateur systèmes et réseaux

    Informations forums :
    Inscription : Avril 2021
    Messages : 23
    Points : 4
    Points
    4
    Par défaut
    Bonjour escartefigue, merci pour l'accueil et ton aide.

    Quand vous dites traitements , vous parlez de quelle partie ?

    sur les 2 cas d'utilisations, connexion extend avec les actions possible c'était pour indiquer que toutes les actions nécessite la connexion pour être réalisé et qu'elle ne sont pas forcément obligatoire mais optionnelle. ce n'est pas la bonne façon de faire ? il faut le faire dans l'autre sens avec par exemple :
    - ajout/modifier/supprimer un parkings ------- include -----> se connecter (s'authentifier)

    c'est mieux de cette manière ?

    je vais travailler sur les règles de gestion.

    Merci à toi

  4. #4
    Modérateur
    Avatar de escartefigue
    Homme Profil pro
    bourreau
    Inscrit en
    Mars 2010
    Messages
    10 133
    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 : 10 133
    Points : 38 555
    Points
    38 555
    Billets dans le blog
    9
    Par défaut
    Citation Envoyé par NarumiN Voir le message
    Quand vous dites traitements , vous parlez de quelle partie ?
    Je parlais du premier diagramme, celui avec les ovales bleus, pour lequel je n'ai pas les compétences requises

  5. #5
    Candidat au Club
    Homme Profil pro
    Administrateur systèmes et réseaux
    Inscrit en
    Avril 2021
    Messages
    23
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Administrateur systèmes et réseaux

    Informations forums :
    Inscription : Avril 2021
    Messages : 23
    Points : 4
    Points
    4
    Par défaut
    J'ai fait mes règles de gestion. Je ne sais pas s'il manque quelque chose

    MP0001 : Chaque membre peut avoir un ou plusieurs parkings
    PM0001 : Chaque parking appartient à un seul membre

    AM0002 : Chaque annonce peut être publiée par un seul membre
    MA0002 : Chaque membre peut publiée plusieurs annonces

    RP0003 : Chaque parking peut être présent dans une seule annonce
    PR0003 : chaque annonce peut contenir une seul parking

    MR0003 : Chaque membre peut effectué plusieurs reservations
    RM0004 : Chaque reservation est effectué par un seul membre unique

    SA0005 : Chaque personne du Staff peut modérer une ou plusieurs annonces
    AS0005 : Chaque annonce peut être modéré par une personne du Staff




    les premières lettres correspondent au initiale de l'action ou l'objet ( premier ligne M > Membre et P > Parking)

    J'ai modifié un peu les tables :

    Nom : DiagrammeDesClasses.PNG
Affichages : 1977
Taille : 43,1 Ko

  6. #6
    Modérateur
    Avatar de escartefigue
    Homme Profil pro
    bourreau
    Inscrit en
    Mars 2010
    Messages
    10 133
    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 : 10 133
    Points : 38 555
    Points
    38 555
    Billets dans le blog
    9
    Par défaut
    Bonjour,

    Membres et équipiers du staff sont des personnes avec des attributs communs.
    Vous pouvez donc utiliser l'héritage pour mutualiser ce qui est commun et la spécialisation pour ce qui est particulier.
    Il faudra préciser si un membre peut également faire partie du staff ou pas ?

    Y a -t-il un intérêt à connaître les parkings pour lesquels il n'y a pas d'annonce ?
    Dans la négative, on peut fusionner les classes d'entité parking et annonce

    à l'inverse, s'il faut conserver les deux classes d'entité, il manque probablement une règle de gestion pour stipuler qu'une annonce ne peut être publiée que par le membre qui possède le parking

  7. #7
    Candidat au Club
    Homme Profil pro
    Administrateur systèmes et réseaux
    Inscrit en
    Avril 2021
    Messages
    23
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Administrateur systèmes et réseaux

    Informations forums :
    Inscription : Avril 2021
    Messages : 23
    Points : 4
    Points
    4
    Par défaut
    Citation Envoyé par escartefigue Voir le message
    Bonjour,

    Membres et équipiers du staff sont des personnes avec des attributs communs.
    Vous pouvez donc utiliser l'héritage pour mutualiser ce qui est commun et la spécialisation pour ce qui est particulier.
    Il faudra préciser si un membre peut également faire partie du staff ou pas ?

    Y a -t-il un intérêt à connaître les parkings pour lesquels il n'y a pas d'annonce ?
    Dans la négative, on peut fusionner les classes d'entité parking et annonce

    à l'inverse, s'il faut conserver les deux classes d'entité, il manque probablement une règle de gestion pour stipuler qu'une annonce ne peut être publiée que par le membre qui possède le parking
    Bonjour,
    Merci pour votre aide.
    J'ai pris en compte vos suggestions.
    J'ai donc améliorer les classes avec membres qui contient à la fois les consumers et le staff et une fusion des annonces et parkings avec activation d'une annonce grâce a un nouvea champ dans la classe "Enable_Advertisement"

    Nom : DiagrammeDesClasses.PNG
Affichages : 1904
Taille : 38,4 Ko

    J'ai aussi rajouté une onzième et deuxième règle de gestion pour les membres faisant potentiellement partie du staff :

    MP0001 : Chaque membre peut avoir un ou plusieurs parkings
    PM0001 : Chaque parking appartient à un seul membre

    AM0002 : Chaque annonce peut être publiée par un seul membre
    MA0002 : Chaque membre peut publiée plusieurs annonces

    RP0003 : Chaque parking peut être présent dans une seule annonce
    PR0003 : chaque annonce peut contenir une seul parking

    MR0003 : Chaque membre peut effectué plusieurs reservations
    RM0004 : Chaque reservation est effectué par un seul membre unique

    SA0005 : Chaque personne du Staff peut modérer une ou plusieurs annonces
    AS0005 : Chaque annonce peut être modéré par une personne du Staff

    MS0006 : Chaque membre peut faire partie du staff
    SM0006 : Chaque personne du staff doit être un membre de la plateforme

  8. #8
    Modérateur
    Avatar de escartefigue
    Homme Profil pro
    bourreau
    Inscrit en
    Mars 2010
    Messages
    10 133
    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 : 10 133
    Points : 38 555
    Points
    38 555
    Billets dans le blog
    9
    Par défaut
    Vous n'avez pas répondu à cette question, qu'en est il ?

    Citation Envoyé par escartefigue Voir le message
    Y a -t-il un intérêt à connaître les parkings pour lesquels il n'y a pas d'annonce ?
    Dans la négative, on peut fusionner les classes d'entité parking et annonce

    à l'inverse, s'il faut conserver les deux classes d'entité, il manque probablement une règle de gestion pour stipuler qu'une annonce ne peut être publiée que par le membre qui possède le parking
    Voici une proposition de MCD réalisé avec Looping et dans lequel j'ai considéré que seuls les parkings pour lesquels il y a une annonce nous intéressent :

    Pièce jointe 596267

    Notez l'ajout de quelques attributs tels que les dimensions du parking (ça me semble important, le besoin pour une moto, une berline ou un camping car n'est pas le même ansi que son adresse (la géolocalisation c'est bien, mais l'adresse c'est indispensable . Je n'ai mais que deux lignes adresses, mais la norme postale c'est 6 lignes de 38 caractères pour une adresse française)
    Notez également la présence du type d'entité fictif "CALENDRIER", son nom entre parenthèses indique que cette entité-type ne deviendra pas une table.
    Elle n'est la que pour participer à l'identification de l'association "réserver"
    Enfin, la flèche de "réserver" vers "membre" matérialise le fait que pour une annonce et une date, il ne peut y avoir qu'un seul membre (contrainte d'intégrité fonctionnelle)

    Le diagramme de classe généré par Looping est donc le suivant :
    Pièce jointe 596268

  9. #9
    Candidat au Club
    Homme Profil pro
    Administrateur systèmes et réseaux
    Inscrit en
    Avril 2021
    Messages
    23
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Administrateur systèmes et réseaux

    Informations forums :
    Inscription : Avril 2021
    Messages : 23
    Points : 4
    Points
    4
    Par défaut
    oui il y a un intérêt de connaitre les parkings où il n'y pas d'annonce pour que les utilisateurs puissent activer une annonce pour leur parkings plus tard par exemple.
    Merci pour vos schémas je vais regarde ça je comprend pas tout ^^ . Par contre j'avais mis dans ma table parking le champ adresse par conte je ne l'avais mis sur deux lignes ^^

    A quoi correspond l'attribut de la table Réserver ? Pourquoi avez-vous séparé l'attribut ville de la table parking ? A quoi correspond matricule dans la table membre ?
    Si je comprend bien, vous ne souhaitez pas créer une table réservation classique mais une entité-type. Pour quelle raison , est-ce plus pertinent d'avoir une entité-type fictive qu'une table Réservation avec un ID_réservation et d'autres attributs tels que "ID_Parking_reservé" , "ID email propriétaire" et "ID email client" qui permet d'avoir un historique des réservations ?


    Concernant les associations entre les différents classes , j'aimerais savoir si ça semble correct ce que j'ai fais :

    MP0001 : Chaque membre peut avoir un ou plusieurs parkings

    Membre 1 ----------------> 0 .. N Parkings


    PM0001 : Chaque parking appartient à un seul membre


    Parking 1 ---------------- > 1 Membre





    AM0002 : Chaque annonce peut être publiée par un seul membre

    Annonce 1 ----------------------> 1 Membre


    MA0002 : Chaque membre peut publiée plusieurs annonces


    Membre 1 ----------------------> 0 .. N Annonces








    RP0003 : Chaque parking peut être présent dans une seule annonce

    Parking 1 --------------------------> 1 Annonce




    PR0003 : chaque annonce peut contenir une seul parking


    Annonce 1 ---------------------> 1 Parking







    MR0003 : Chaque membre peut effectué plusieurs reservations

    Membre 1 -----------------------------> 0 .. N Réservation





    RM0004 : Chaque reservation est effectuée par un seul membre unique


    Réservation 1 -------------------------> 1 Membre








    SA0005 : Chaque personne du Staff peut modérer une ou plusieurs annonces

    Staff 1 -----------------> 0 .. N Annonce





    AS0005 : Chaque annonce peut être modéré plusieurs membres du Staff

    Annonce 1 -----------------> 1.. N Staff


    MS0006 : Chaque membre peut faire partie du staff

    Membre 1 ------------------> 0 .. 1 Staff



    SM0006 : Chaque personne du staff doit être un membre de la plateforme

    Staff 1 -------------------> 1 Membre


    Merci bien

  10. #10
    Modérateur
    Avatar de escartefigue
    Homme Profil pro
    bourreau
    Inscrit en
    Mars 2010
    Messages
    10 133
    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 : 10 133
    Points : 38 555
    Points
    38 555
    Billets dans le blog
    9
    Par défaut
    Bonsoir NarumiN

    Citation Envoyé par NarumiN Voir le message
    oui il y a un intérêt de connaitre les parkings où il n'y pas d'annonce pour que les utilisateurs puissent activer une annonce pour leur parkings plus tard par exemple.
    Ok du coup mon schéma qui précède est à corriger, j'y reviendrai plus tard


    Citation Envoyé par NarumiN Voir le message
    A quoi correspond l'attribut de la table Réserver ?
    C'est la date de fin de réservation, la date de début de réservation est héritée de l'entité-type CA_calendrier dont elle est la PK


    Citation Envoyé par NarumiN Voir le message
    Pourquoi avez-vous séparé l'attribut ville de la table parking ?
    Parce que plusieurs adresses peuvent être dans la même ville, or, si la ville était dans l'adresse, quand une ville change de nom (ça arrive tous les ans lors de fusion de communes), il faudrait modifier toutes les adresses.
    De même, avec la ville dans l'adresse, vous risquez d'avoir des orthographes différentes pour la même ville dans chaque adresse.


    Citation Envoyé par NarumiN Voir le message
    A quoi correspond matricule dans la table membre ?
    C'est un attribut à titre d'exemple, pour montrer qu'on peut avoir des attributs spécifiques à un sous-type (ici j'ai supposé que les membres avaient un numéro de membre et pas les non membres)


    Citation Envoyé par NarumiN Voir le message
    Si je comprend bien, vous ne souhaitez pas créer une table réservation classique mais une entité-type. Pour quelle raison , est-ce plus pertinent d'avoir une entité-type fictive qu'une table Réservation avec un ID_réservation et d'autres attributs tels que "ID_Parking_reservé" , "ID email propriétaire" et "ID email client" qui permet d'avoir un historique des réservations ?
    Attention à ne pas mélanger les concepts, les types d'entité sont des objets du modèle conceptuel, de ces types d'entités découlent des tables dans le modèle logique et physique.

    Par ailleurs, je ne souhaite pas créer telle ou telle entité-type, je modélise un MCD qui correspond aux règles de gestion, c'est tout.
    Ensuite, quand on génère le MLD découlant de ce MCD on obtient des tables. Les tables ne sont pas un but en soi, mais le résultat d'une modélisation fidèle aux règles de gestion, nuance

    Si on comprend que la réservation c'est la mise en relation d'un membre et d'un parking à une certaine période, alors on comprend que la table résultante est, comme toute table issue d'une association, identifiée par chaque identifiant des classes d'entité (ou types d'entité ou encore entité-type) entrant en jeu dans l'association. Pas besoin de créer un identifiant supplémentaire, il n'apporterait rien.

    J'en reste là pour ce soir, le diner va refroidir

  11. #11
    Candidat au Club
    Homme Profil pro
    Administrateur systèmes et réseaux
    Inscrit en
    Avril 2021
    Messages
    23
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Administrateur systèmes et réseaux

    Informations forums :
    Inscription : Avril 2021
    Messages : 23
    Points : 4
    Points
    4
    Par défaut
    Bonjour,

    Merci pour ces explications. Je comprend mieux le fonctionnement du MCD et MLD .

    Par contre pour la partie réservation , je suis d'accord qu'il est inutile de créer un nouvel identifiant supplémentaire. Si nous appliquons votre exemple, on pourra avoir un historique des réservations dans le MLD (modèle logique avec les tables) ?
    Les règles de gestions et leur associations que j'ai citées dans mon précédent message au-dessus vous paraissent correct ?

    Pouvez-vous me transmettre les fichiers correspondant au MCD que vous avez réalisés , s'il vous plaît ?
    Merci bien

  12. #12
    Modérateur
    Avatar de escartefigue
    Homme Profil pro
    bourreau
    Inscrit en
    Mars 2010
    Messages
    10 133
    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 : 10 133
    Points : 38 555
    Points
    38 555
    Billets dans le blog
    9
    Par défaut Historique des réservations
    Au niveau conceptuel, l'association réserver du MCD est en lien avec les types d'entité "MB_membre", "AP_annonce_parking" et "CA_calendrier"
    Comme toute association n-aire, elle devient une table au niveau MLD, table dont l'identifiant primaire est l'ensemble des PK issus des types d'entités associés.
    Soit a priori MB_ident, CA_date, AP_ident
    Mais, comme une contrainte d'intégrité fonctionnelle (CIF matérialisée par une flèche vers membre) stipule que pour une date et un parking, il une peut y avoir qu'un membre, alors MB_ident est évacué de la PK de la table associative RS_reserver, il devient un simple attribut de cette table.
    Ce faisant, la PK de la table RS_reserver devient AP_ident, CA_date
    Il n'y a donc aucune difficulté à conserver tout l'historique des réservations d'un parking : on aura dans la table RS_reserver autant de fois le même identifiant de parking AP_ident avec à chaque fois une date CA_date différente

    Une remarque :
    • si vous répondez au dernier message, utilisez le bouton "répondre", plutôt que "répondre avec citation" ;
    • si vous répondez à un message plus ancien, alors utilisez "répondre avec citation" mais ne conservez que la partie intéressante de la citation sur laquelle vous souhaitez réagir.

  13. #13
    Candidat au Club
    Homme Profil pro
    Administrateur systèmes et réseaux
    Inscrit en
    Avril 2021
    Messages
    23
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Administrateur systèmes et réseaux

    Informations forums :
    Inscription : Avril 2021
    Messages : 23
    Points : 4
    Points
    4
    Par défaut
    Merci encore.
    Je commence à bien comprendre l'optimisation que vous avez fais ^^ .
    A quoi correspond PK ? primary key ?
    Pourquoi avez-vous mis 0 , n entre rs_réserver et MB_membre ? je n'ai pas trop compris par exemple 1,1 entre moderer et annonce que vous avez mis en place .

    Si je résume , pour identifier une reservation dans l'historique des réservations on va se servir du couple des identifiants AP_Ident et CA_date comme clé primaire qui sera unique et il n'est pas nécessaire d'indiquer l'ID utilisateur (ici MB_Ident) car vous avez mis une contrainte spécifiant que pour une date et un parking , il peut y avoir uniquement un utilisateur . c'est bien ça ?

  14. #14
    Modérateur
    Avatar de escartefigue
    Homme Profil pro
    bourreau
    Inscrit en
    Mars 2010
    Messages
    10 133
    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 : 10 133
    Points : 38 555
    Points
    38 555
    Billets dans le blog
    9
    Par défaut
    Ci dessous, j'ai utilisé "répondre avec citation" pour répondre point par point et j'ai recopié plusieurs fois les balises de début et de fin de citation pour encadrer chaque question, ainsi les réponses sont plus claires


    Citation Envoyé par NarumiN Voir le message
    A quoi correspond PK ? primary key ?
    oui


    Citation Envoyé par NarumiN Voir le message
    Pourquoi avez-vous mis 0 , n entre rs_réserver et MB_membre ?
    Parce qu'un membre peut réserver un parking ou n'en réserver aucun (


    Citation Envoyé par NarumiN Voir le message
    je n'ai pas trop compris par exemple 1,1 entre moderer et annonce que vous avez mis en place .
    Je me suis trompé : c'est 0,n conformément à votre règle de gestion AS0005


    Citation Envoyé par NarumiN Voir le message
    Si je résume , pour identifier une reservation dans l'historique des réservations on va se servir du couple des identifiants AP_Ident et CA_date comme clé primaire qui sera unique et il n'est pas nécessaire d'indiquer l'ID utilisateur (ici MB_Ident) car vous avez mis une contrainte spécifiant que pour une date et un parking , il peut y avoir uniquement un utilisateur . c'est bien ça ?
    Tout à fait

  15. #15
    Modérateur
    Avatar de escartefigue
    Homme Profil pro
    bourreau
    Inscrit en
    Mars 2010
    Messages
    10 133
    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 : 10 133
    Points : 38 555
    Points
    38 555
    Billets dans le blog
    9
    Par défaut
    Voici une nouvelle proposition de MCD.
    J'ai ajouté l'identifiant de l'entité-type "membre" (je l'avais oublié dans la version précédente )
    J'ai corrigé les cardinalités de l'association "modérer", du coup c'est une association n-aire qui deviendra une table.
    J'ai pris en compte le fait que les parking sans annonces doivent être gérés et supposé que seul le membre propriétaire du parking peut publier des annonces relatives à ce parking. C'est le rôle de la contrainte d'inclusion (cercle I).
    Notez la cardinalité 1,1(R) de AN_annonce vers PA_parking. Cette symbolique matérialise l'identification relative : l'identifiant du parking contribuera à identifier l'annonce dans la table issue de l'entité-type AN_annonce. Cette méthode d'identification est utilisée pour les entité-types dites "faibles", c'est le cas de l'annonce qui ne saurait exister sans son parking.

    Pièce jointe 596361

    voici le diagramme UML correspondant :
    Pièce jointe 596362

    et enfin le DDL associé généré par Looping (ici j'ai choisi arbitrairement SQL server) :
    Code SQL : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    42
    43
    44
    45
    46
    47
    48
    49
    50
    51
    52
    53
    54
    55
    56
    57
    58
    59
    60
    61
    62
    63
    64
    65
    66
    67
    68
    69
    70
    71
    72
    73
    74
    75
    76
    77
    78
    79
    80
    81
    82
    83
    84
    CREATE TABLE PE_personne(
       PE_ident INT IDENTITY,
       PE_nom VARCHAR(50) NOT NULL,
       PE_prenom VARCHAR(50) NOT NULL,
       PE_ddn DATE NOT NULL,
       PRIMARY KEY(PE_ident)
    );
     
    CREATE TABLE MB_membre(
       MB_ident INT IDENTITY,
       MB_matricule CHAR(6) NOT NULL,
       PE_ident INT NOT NULL,
       PRIMARY KEY(MB_ident),
       UNIQUE(PE_ident),
       UNIQUE(MB_matricule),
       FOREIGN KEY(PE_ident) REFERENCES PE_personne(PE_ident)
    );
     
    CREATE TABLE RP_responsable(
       PE_ident INT,
       PRIMARY KEY(PE_ident),
       FOREIGN KEY(PE_ident) REFERENCES PE_personne(PE_ident)
    );
     
    CREATE TABLE VI_ville(
       VI_ident INT IDENTITY,
       VI_insee CHAR(5) NOT NULL,
       VI_nom VARCHAR(50) NOT NULL,
       PRIMARY KEY(VI_ident),
       UNIQUE(VI_insee)
    );
     
    CREATE TABLE PA_parking(
       PA_ident INT IDENTITY,
       PA_long DECIMAL(5,2) NOT NULL,
       PA_larg DECIMAL(5,2) NOT NULL,
       PA_haut DECIMAL(5,2) NOT NULL,
       PA_geo GEOGRAPHY NOT NULL,
       PA_adr1 VARCHAR(38) NOT NULL,
       PA_adr2 VARCHAR(38),
       VI_ident INT NOT NULL,
       MB_ident INT NOT NULL,
       PRIMARY KEY(PA_ident),
       FOREIGN KEY(VI_ident) REFERENCES VI_ville(VI_ident),
       FOREIGN KEY(MB_ident) REFERENCES MB_membre(MB_ident)
    );
     
    CREATE TABLE AN_annonce(
       PA_ident INT,
       AN_ident SMALLINT,
       AN_date DATE NOT NULL,
       AN_tarif DECIMAL(7,2) NOT NULL,
       MB_ident INT NOT NULL,
       PRIMARY KEY(PA_ident, AN_ident),
       FOREIGN KEY(PA_ident) REFERENCES PA_parking(PA_ident),
       FOREIGN KEY(MB_ident) REFERENCES MB_membre(MB_ident)
    );
     
    CREATE TABLE RS_reserver(
       PA_ident INT,
       CA_date DATE,
       RS_dtfin DATE NOT NULL,
       MB_ident INT NOT NULL,
       PRIMARY KEY(PA_ident, CA_date),
       FOREIGN KEY(PA_ident) REFERENCES PA_parking(PA_ident),
       FOREIGN KEY(MB_ident) REFERENCES MB_membre(MB_ident)
    );
     
    CREATE TABLE MO_moderer(
       PE_ident INT,
       PA_ident INT,
       AN_ident SMALLINT,
       MO_dateheure DATETIME2 NOT NULL,
       MO_motif VARCHAR(128),
       PRIMARY KEY(PE_ident, PA_ident, AN_ident),
       FOREIGN KEY(PE_ident) REFERENCES RP_responsable(PE_ident),
       FOREIGN KEY(PA_ident, AN_ident) REFERENCES AN_annonce(PA_ident, AN_ident)
    );
     
    ALTER TABLE AN_annonce
    ADD CONSTRAINT FK_publier_posseder
       FOREIGN KEY (MB_ident, PA_ident) 
       REFERENCES PA_parking(MB_ident, PA_ident) 
    ;

  16. #16
    Modérateur
    Avatar de escartefigue
    Homme Profil pro
    bourreau
    Inscrit en
    Mars 2010
    Messages
    10 133
    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 : 10 133
    Points : 38 555
    Points
    38 555
    Billets dans le blog
    9
    Par défaut
    Par ailleurs je pense que cette règle est erronée

    Citation Envoyé par NarumiN Voir le message
    RP0003 : Chaque parking peut être présent dans une seule annonce
    En effet, je suppose que l'annonce relative au parking P1 émise en janvier 2019 pour un tarif de 150€ par mois, peut être remplacée par une nouvelle annonce pour ce même parking P1 mais avec un nouveau tarif de 155€ mensuels.
    C'est en tout cas dans ce sens que va ma proposition de MCD qui précède.

  17. #17
    Candidat au Club
    Homme Profil pro
    Administrateur systèmes et réseaux
    Inscrit en
    Avril 2021
    Messages
    23
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Administrateur systèmes et réseaux

    Informations forums :
    Inscription : Avril 2021
    Messages : 23
    Points : 4
    Points
    4
    Par défaut
    y-a-t-il une utilité à avoir MB_Ident et MB_Matricule dans la table MB_membre?

    Pouvez-vous m'expliquer le fonctionnement entre PR_Responsable et PA_Annonce avec 0,n et 0,n et modérer entre les deux ?


    Est-il possible d'avoir accès au fichier pour que je suis puisse rajouter des champs et vous montrer si ça vous semble correct avec tous les champs indiqués ?


    Merci beaucoup.

  18. #18
    Candidat au Club
    Homme Profil pro
    Administrateur systèmes et réseaux
    Inscrit en
    Avril 2021
    Messages
    23
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Administrateur systèmes et réseaux

    Informations forums :
    Inscription : Avril 2021
    Messages : 23
    Points : 4
    Points
    4
    Par défaut
    Citation Envoyé par escartefigue Voir le message
    Par ailleurs je pense que cette règle est erronée



    En effet, je suppose que l'annonce relative au parking P1 émise en janvier 2019 pour un tarif de 150€ par mois, peut être remplacée par une nouvelle annonce pour ce même parking P1 mais avec un nouveau tarif de 155€ mensuels.
    C'est en tout cas dans ce sens que va ma proposition de MCD qui précède.
    Votre suggestion de remplacer l'annonce actuelle par une nouvelle annonce avec un nouveau tarif ne respecte pas ma regle de gestion qui stipule "RP0003 : Chaque parking peut être présent dans une seule annonce" donc pour créer une nouvelle annonce, il est obligatoire de supprimer l'ancienne annonce ?

  19. #19
    Modérateur
    Avatar de escartefigue
    Homme Profil pro
    bourreau
    Inscrit en
    Mars 2010
    Messages
    10 133
    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 : 10 133
    Points : 38 555
    Points
    38 555
    Billets dans le blog
    9
    Par défaut
    Pour créer une nouvelle annonce, il n'est pas nécessaire de supprimer l'ancienne, on en crée simplement une nouvelle avec un nouvel identifiant et une date de création plus récente.
    L'application recherchera la date de l'annonce la plus récente pour le parking et c'est celle là qui sera valide.
    J'explique dans mon blog comment le faire

    L'intérêt est de conserver l'historique des annonces pour un même parking

  20. #20
    Modérateur
    Avatar de escartefigue
    Homme Profil pro
    bourreau
    Inscrit en
    Mars 2010
    Messages
    10 133
    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 : 10 133
    Points : 38 555
    Points
    38 555
    Billets dans le blog
    9
    Par défaut
    Citation Envoyé par NarumiN Voir le message
    y-a-t-il une utilité à avoir MB_Ident et MB_Matricule dans la table MB_membre?
    MB_ident c'est une boulette, j'ai modifié trop vite en oubliant que MB_membre était un sous-type de PE_personne... désolé.
    Concernant MB_matricule, je l'ai déjà expliqué plus haut, c'est un exemple d'attribut du sous-type, vous pouvez le supprimer bien sûr



    Citation Envoyé par NarumiN Voir le message
    Pouvez-vous m'expliquer le fonctionnement entre PR_Responsable et PA_Annonce avec 0,n et 0,n et modérer entre les deux ?
    J'ai compris qu'un responsable (staff) pouvait modérer plusieurs annonces et qu'une annonce pouvait être modérée par plusieurs responsables, d'où cette modélisation.
    à modifier si ce n'est pas le cas



    Citation Envoyé par NarumiN Voir le message
    Est-il possible d'avoir accès au fichier pour que je suis puisse rajouter des champs et vous montrer si ça vous semble correct avec tous les champs indiqués ?
    oui c'est possible mais il vous faut télécharger looping, sans quoi vous ne pourrez rien en faire et il faut que je zipe le fichier pour pouvoir le déposer, voici le fichier zipé




    Citation Envoyé par NarumiN Voir le message
    Merci beaucoup.
    N'hésitez pas à voter pour les réponses qui vous ont aidées en cliquant sur le pouce vert prévu à cet effet

Discussions similaires

  1. Passage d'un diagramme de classe a une base de donnée relationnelle
    Par Midoov dans le forum Diagrammes de Classes
    Réponses: 1
    Dernier message: 07/06/2010, 11h47
  2. diagramme de classe pour un base de donnée
    Par gentelmand dans le forum Diagrammes de Classes
    Réponses: 5
    Dernier message: 23/05/2009, 00h30
  3. conception base de donnees
    Par jean clode dans le forum Modélisation
    Réponses: 9
    Dernier message: 19/07/2007, 11h46
  4. Du diagramme de classe à la conception du code
    Par BRAUKRIS dans le forum Diagrammes de Classes
    Réponses: 8
    Dernier message: 08/05/2005, 18h57

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