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

Schéma Discussion :

Problème de relations


Sujet :

Schéma

  1. #1
    Membre expérimenté
    Profil pro
    Inscrit en
    Juillet 2006
    Messages
    899
    Détails du profil
    Informations personnelles :
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : Juillet 2006
    Messages : 899
    Points : 1 390
    Points
    1 390
    Par défaut Problème de relations
    Bonjour,

    Je me fait une base de données afin de suivre ma progression sur Final Fantasy 6.

    Pour vous expliquer simplement le contexte:
    Le joueur rencontre des monstres formations de monstre.
    Une formation regroupe entre 1 et 6 monstres.
    Chaque monstre à, outre ses caractéristiques, une compétence particulière appelée Frénésie.
    Le joueur peut acquérir ces frénésies, à condition qu'elle soit issue d'un monstre déjà rencontré (ou plutôt un monstre présent dans une formation déjà rencontrée).

    J'ai donc fait la modélisation suivante:
    Nom : Capture d'écran 2024-01-28 193440.png
Affichages : 198
Taille : 29,9 Ko
    Mais je n'en suit pas très satisfait. En effet, ce modèle autorise l'acquisition de n'importe quelle frénésie, qu'elle soit issue d'un monstre déjà rencontré ou non.

    J'ai très envie de mettre un lien entre les relations Acquiert et Rencontre, mais Merise ne l'autorise pas.
    Quelle solution est envisageable ?

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

    Un MCD n'est valide que s'il est conforme aux règles de gestion métier, or, vous n'avez communiqué aucune règle de gestion.
    Voyez dans ce fil de discussion, réponse n°8, comment les rédiger

    D'après ce que je comprends, un utilisateur ne peut acquérir une "frénésie" (terme à expliquer) que s'il a fait une rencontre d'un monstre possédant cette "frénésie".
    Pour ce genre de besoins, il faut mettre en oeuvre une contrainte d'inclusion. Dans Looping, l'outil est présent dans la barre d'icones, de mémoire c'est un cercle jaune (je n'ai pas Looping sur ce poste pour le vérifier).

    Mais chaque chose en son temps, tout d'abord, précisez bien vos règles de gestion

  3. #3
    Membre expérimenté
    Profil pro
    Inscrit en
    Juillet 2006
    Messages
    899
    Détails du profil
    Informations personnelles :
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : Juillet 2006
    Messages : 899
    Points : 1 390
    Points
    1 390
    Par défaut
    Heu ..., je trouves que tu chipottes,
    le MCD que j'ai posté est plutôt explicite, j'ai exprimé mon besoin, et apporté les explications adéquat.
    Pour rappel: Un monstre a des compétences (que je n'ai pas modélisé car je n'en ai pas besoin), dont une particulière appelée Frénésie. On se contentera de connaitre son nom.

    Règles de gestion métier, étant plutôt programmeur, je ne doit pas avoir la même définition que toi.
    De mon point de vue, ce sont les règles qui permettent de transformer les données d'un état d'entrée vers un état de sortie, ainsi que les restrictions applicables.

    C'est le point suivant qui me pose problème:
    Le joueur peut acquérir ces frénésies, à condition qu'elle soit issue d'un monstre déjà rencontré (ou plutôt un monstre présent dans une formation déjà rencontrée).
    D'une part, je ne sais pas comment le modéliser.
    D'autre part, je ne sais pas comment l'implémenter.

  4. #4
    Modérateur
    Avatar de escartefigue
    Homme Profil pro
    bourreau
    Inscrit en
    Mars 2010
    Messages
    10 022
    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 022
    Points : 38 165
    Points
    38 165
    Billets dans le blog
    8
    Par défaut
    Au stade du MCD les règles de gestion concernent évidemment les données et non pas les traitements, donc les changements d'état et les entrées et sorties sont hors sujet à ce stade.
    Comme dit précédemment, pour vérifier qu'un joueur ne peut acquérir une "frénésie" que s'il a rencontré le monstre possédant cette "frénésie", il faut inverser les liens d'association comme dans le MCD ci-dessous, mais ceci n'est possible que si les règles de gestion (au sens de la modélisation des données) le permet.
    A partir de là, mettre en oeuvre une contrainte d'inclusion devient très simple.

    Ce qui donnerait le MCD suivant :

    Nom : Sans titre.png
Affichages : 148
Taille : 24,4 Ko

    D'après ce MCD, le joueur rencontre non pas une formation, mais un monstre, monstre qui fait partie ou pas d'une formation.
    A vous de voir si ça correspond ou pas aux règles de gestion.

  5. #5
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    Septembre 2006
    Messages
    7 911
    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 : 7 911
    Points : 30 657
    Points
    30 657
    Billets dans le blog
    16
    Par défaut Ockham
    Bonjour,

    Capitaine, ton MCD répond de façon élégante à l’attente de deedolith, à moins qu’une règle de gestion à venir de sa part précise que la connaissance de la formation "rencontrée" par l’utilisateur soit indispensable.
     
    deedolith, deux points :

    a) Le MCD proposé par Escartefigue trouve-t-il grâce à vos yeux ?

    b) Avez-vous besoin du code SQL produit par Looping ?
     

    Une remarque concernant l’identification relative

    L’association Posseder pourrait être identifiée relativement à l’entité-type Monstre. A défaut, l’entité-type Frenesie possède deux identifiants : {Id} et {MonstreId}, ce dernier étant hérité du fait des cardinalités dont est dotée cette association. {Id} n’apporte rien et peut passer au rasoir d’Ockham.


     
    (a) Faites simple, mais pas plus simple ! (A. Einstein)
    (b) Certes, 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 »)

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

  6. #6
    Membre expérimenté
    Profil pro
    Inscrit en
    Juillet 2006
    Messages
    899
    Détails du profil
    Informations personnelles :
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : Juillet 2006
    Messages : 899
    Points : 1 390
    Points
    1 390
    Par défaut
    Citation Envoyé par fsmrel Voir le message
    a) Le MCD proposé par Escartefigue trouve-t-il grâce à vos yeux ?
    Bonjour,

    Plusieurs choses me font tiquer.
    je ne vais pas invoquer de nouvelles règles, mais réitérer celles que j'ai déjà cité et apporter des précisions qui m'on parues évidentes:
    Un utilisateur peut rencontrer des formations de monstres.
    Une formation comprend 1 à 6 monstres.
    Une formation peut être rencontrée par des joueurs.
    Un monstre fait partie d'au moins 1 formation (je ne voit d'ailleurs pas pourquoi les cardinalités ont été changées autour de la relation "Aggrege".

    J'insiste sur le fait que c'est la formation qui est rencontrée, ce qui implique que les monstres composant cette dernière sont rencontrés en même temps.
    Si l'utilisateur pouvais rencontrer un monstre, cela n'impliquerait pas que la ou les formation(s) parentes sont rencontrées.

    Citation Envoyé par fsmrel Voir le message
    b) Avez-vous besoin du code SQL produit par Looping ?
    Je ne pense pas en avoir besoin.
    Par contre, je souhaiterais savoir comment va se traduire ces contraintes au niveau de la base de données, des triggers ?

    Est ce que je peux également demander des précisions sur ces contraintes ?
    Mes cours de Merise commencent à dater, ce sont des notions qui me sont inconnues.

  7. #7
    Modérateur
    Avatar de escartefigue
    Homme Profil pro
    bourreau
    Inscrit en
    Mars 2010
    Messages
    10 022
    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 022
    Points : 38 165
    Points
    38 165
    Billets dans le blog
    8
    Par défaut
    Citation Envoyé par deedolith Voir le message
    Un utilisateur peut rencontrer des formations de monstres.
    Une formation comprend 1 à 6 monstres.
    Une formation peut être rencontrée par des joueurs.
    Un monstre fait partie d'au moins 1 formation (je ne voit d'ailleurs pas pourquoi les cardinalités ont été changées autour de la relation "Aggrege".
    Vu qu'une formation peut être composée d'un seul monstre, ma proposition de modèle communiquée hier à 9h12 est valide, il suffit de modifier les cardinalités de [MONSTRE] vers (agreger) pour remplacer 0,n par 1,n
    Vous pouvez en profiter pour identifier la frénésie relativement au monstre comme l'a judicieusement proposé Fsmrel plus haut.

    Concernant le code SQL, la contrainte d'inclusion se traduit par une contrainte de type REFERENCE, elle ressemblera à ceci

    Code SQL : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    alter table AQ_acquerir
    add constraint FK_AQ_AC
    foreign key (UT_ident, MO_ident)
    references RE_rencontrer (UT_ident, MO_ident)
    ;

    Notez "agréger" avec un seul "g" contrairement à l'anglais "aggregate"

    Dans votre premier modèle, le type d'entité [MONSTRE] possède un attribut nommé gameid qui est probablement l'identifiant d'un autre type d'entité.
    Si c'est bien le cas, il doit être supprimé : les clefs étrangères n'ont pas lieu d'être au stade conceptuel, elle sont la conséquence de la dérivation du MCD en modèle tabulaire et n'apparaissent donc que dans les MLD et MPD

  8. #8
    Membre expérimenté
    Profil pro
    Inscrit en
    Juillet 2006
    Messages
    899
    Détails du profil
    Informations personnelles :
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : Juillet 2006
    Messages : 899
    Points : 1 390
    Points
    1 390
    Par défaut
    Ok,

    Mais si je comprend bien, la contrainte doit plutôt s'appliquer sur les relations "Acquiert" et "Rencontre" ?

  9. #9
    Modérateur
    Avatar de escartefigue
    Homme Profil pro
    bourreau
    Inscrit en
    Mars 2010
    Messages
    10 022
    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 022
    Points : 38 165
    Points
    38 165
    Billets dans le blog
    8
    Par défaut
    Oui et c'est le cas : au niveau tabulaire, j'ai nommé les tables issues de ces associations selon une norme que j'applique souvent (préfixe unique par table, qu'on retrouve dans chaque attribut de cette table).

  10. #10
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    Septembre 2006
    Messages
    7 911
    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 : 7 911
    Points : 30 657
    Points
    30 657
    Billets dans le blog
    16
    Par défaut
    Bonjour,

    Citation Envoyé par escartefigue Voir le message
    Concernant le code SQL, la contrainte d'inclusion se traduit par une contrainte de type REFERENCE, elle ressemblera à ceci

    Code SQL : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
     
    alter table AQ_acquerir
    add constraint FK_AQ_AC
    foreign key (UT_ident, MO_ident)
    references RE_rencontrer (UT_ident, MO_ident);
    Mais ceci permet à un utilisateur d’acquérir une frénésie appartenant à un monstre ne faisant pas partie des formations qu’il rencontre...
    (a) Faites simple, mais pas plus simple ! (A. Einstein)
    (b) Certes, 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 »)

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

  11. #11
    Modérateur
    Avatar de escartefigue
    Homme Profil pro
    bourreau
    Inscrit en
    Mars 2010
    Messages
    10 022
    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 022
    Points : 38 165
    Points
    38 165
    Billets dans le blog
    8
    Par défaut
    Que nenni : la contrainte fait référence au duo (identifiant utilisateur, identifiant monstre), on répond donc bien au besoin

  12. #12
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    Septembre 2006
    Messages
    7 911
    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 : 7 911
    Points : 30 657
    Points
    30 657
    Billets dans le blog
    16
    Par défaut
    Citation Envoyé par escartefigue Voir le message
    Que nenni : la contrainte fait référence au duo (identifiant utilisateur, identifiant monstre), on répond donc bien au besoin
    Négatif ! Je répète que ceci permet à un utilisateur d’acquérir une frénésie appartenant à un monstre ne faisant pas partie des formations que cet utilisateur rencontre...

    Je rappelle en effet le point sur lequel deedolith insiste :
     
    Citation Envoyé par deedolith Voir le message
    J'insiste sur le fait que c'est la formation qui est rencontrée, ce qui implique que les monstres composant cette dernière sont rencontrés en même temps.
    Si l'utilisateur pouvais rencontrer un monstre, cela n'impliquerait pas que la ou les formation(s) parentes sont rencontrées.
    Il faut donc appeler un chat, un chat.

    Pour s’assurer que chaque utilisateur ne puisse acquérir que des frénésies possédées par des monstres faisant partie des formations qu’il rencontre, il faut mettre en oeuvre une association, appelons-la UFM, entre les associations Rencontre, Acquiert et Agrege.
     
    Comme Merise ne le permet pas, il faut transformer ces associations en entités-types. Pour cela, on utilise l’icône en bas à droite de la boîte Association :

     
     
    MCD que je propose :
     
     
    Bien entendu, Looping produit pour la table UFM une structure où les attributs UtilisateurId , FormationId et MonstreId redondent :
     
    Code SQL : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    CREATE TABLE UFM
    (
       UtilisateurId INT,
       FormationId INT,
       FormationId_1 INT,
       MonstreId INT,
       UtilisateurId_1 INT,
       MonstreId_1 INT,
       PRIMARY KEY(UtilisateurId, FormationId, FormationId_1, MonstreId, UtilisateurId_1, MonstreId_1),
       FOREIGN KEY(UtilisateurId, FormationId) REFERENCES Rencontrer(UtilisateurId, FormationId),
       FOREIGN KEY(FormationId_1, MonstreId) REFERENCES Agreger(FormationId, MonstreId),
       FOREIGN KEY(UtilisateurId_1, MonstreId_1) REFERENCES Acquerir(UtilisateurId, MonstreId)
    );

    Je ne sache pas que nos AGL permettent de produire une table non redondante, à savoir :

    Code SQL : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    CREATE TABLE UFM
    (
       UtilisateurId INT,
       FormationId INT,
       MonstreId INT,
       PRIMARY KEY(UtilisateurId, FormationId, MonstreId),
       FOREIGN KEY(UtilisateurId, FormationId) REFERENCES Rencontrer(UtilisateurId, FormationId),
       FOREIGN KEY(FormationId, MonstreId) REFERENCES Agreger(FormationId, MonstreId),
       FOREIGN KEY(UtilisateurId, MonstreId) REFERENCES Acquerir(UtilisateurId, MonstreId)
    );

    On supprimera donc les redondances à la main.

    Exemple avec SQL Server, création des tables :

    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
    create table Formation
    (
       FormationId INT,
       FormationNumero INT NOT NULL,
       PRIMARY KEY(FormationId),
       UNIQUE(FormationNumero)
    );
    create table Monstre
    (
       MonstreId INT,
       MonstreNom VARCHAR(24) NOT NULL,
       PRIMARY KEY(MonstreId),
       UNIQUE(MonstreNom)
    );
     
    create table Agreger
    (
       FormationId INT,
       MonstreId INT,
       PRIMARY KEY(FormationId, MonstreId),
       FOREIGN KEY(FormationId) REFERENCES Formation(FormationId),
       FOREIGN KEY(MonstreId) REFERENCES Monstre(MonstreId)
    );
    create table Frenesie(
       MonstreId INT,
       FrenesieNom VARCHAR(24) NOT NULL,
       PRIMARY KEY(MonstreId),
       FOREIGN KEY(MonstreId) REFERENCES Monstre(MonstreId)
    );
     
    create table Utilisateur
    (
       UtilisateurId INT,
       UtilisateurNom VARCHAR(24) NOT NULL,
       PRIMARY KEY(UtilisateurId)
    );
    create table Rencontrer
    (
       UtilisateurId INT,
       FormationId INT,
       PRIMARY KEY(UtilisateurId, FormationId),
       FOREIGN KEY(FormationId) REFERENCES Formation(FormationId),
       FOREIGN KEY(UtilisateurId) REFERENCES Utilisateur(UtilisateurId)
    );
     
    create table Acquerir
    (
       UtilisateurId INT,
       MonstreId INT,
       PRIMARY KEY(UtilisateurId, MonstreId),
       FOREIGN KEY(UtilisateurId) REFERENCES Utilisateur(UtilisateurId),
       FOREIGN KEY(MonstreId) REFERENCES Frenesie(MonstreId)
    );
     
    create table UFM
    (
       UtilisateurId INT
    ,  FormationId INT
    ,  MonstreId INT
       PRIMARY KEY(UtilisateurId, FormationId, MonstreId)
    ,  FOREIGN KEY(UtilisateurId, FormationId) REFERENCES Rencontrer(UtilisateurId, FormationId)
    ,  FOREIGN KEY(FormationId, MonstreId) REFERENCES Agreger(FormationId, MonstreId)
    ,  FOREIGN KEY(UtilisateurId, MonstreId) REFERENCES Acquerir(UtilisateurId, MonstreId)
    );

    Jeu d’essai :

    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
    insert into Formation values
      (1,1)
    , (2,2)
    , (3,3)
    ;
    select '' as Formation, * from Formation ;
     
    insert into Monstre values
      (1,'m1')
    , (2,'m2')
    , (3,'m3')
    , (4,'m4')
    , (5,'m5')
    ;
    select '' as Monstre,* from Monstre ;
     
    insert into Agreger values
      (1,1)
    , (1,2)
    , (1,3)
    , (2,1)
    , (2,3)
    , (2,4)
    , (3,2)
    , (3,5)
    ;
    select '' as Agreger,* from Agreger ;
     
    insert into Frenesie values
      (1,'f1')
    , (2,'f2')
    , (3,'f3')
    , (4,'f4')
    , (5,'f5')
    ;
    select '' as Frenesie, * from Frenesie ;
     
    insert into Utilisateur values
      (1,'u1')
    , (2,'u2')
    , (3,'u3')
    ;
    select '' as Utilisateur, * from Utilisateur ;
     
    insert into Rencontrer values
      (1,1)
    , (1,2)
    , (2,1)
    , (2,2)
    , (2,3)
    ;
    select '' as Rencontrer, * from Rencontrer ;
     
    insert into Acquerir values
      (1,1)
    , (1,3)
    , (2,1)
    , (2,4)
    , (3,2)
    , (1,5) – UFM ne sera pas d’accord
    ;
    select '' as Acquerir, * from Acquerir ;
     
    insert into UFM values
      (1,1,1)
    , (1,1,3)
    ;
    select '' as UFM, * from UFM ;  -- ok
     
    insert into UFM values
      (1,3,5) -- délinquant : l’utilisateur 1 n’a pas rencontré la formation 3
    ;
    select '' as UFM, * from UFM ; -- ko

    Le SGBD valide les deux premiers inserts UFM, tandis que 3e le fait tousser :

    « L'instruction INSERT est en conflit avec la contrainte FOREIGN KEY "UFM_Rencontrer_fk".
    Le conflit s'est produit dans la base de données "deedolith", table "dbo.Rencontrer". »

    Quod erat demonstrandum. 
    (a) Faites simple, mais pas plus simple ! (A. Einstein)
    (b) Certes, 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 »)

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

  13. #13
    Modérateur
    Avatar de escartefigue
    Homme Profil pro
    bourreau
    Inscrit en
    Mars 2010
    Messages
    10 022
    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 022
    Points : 38 165
    Points
    38 165
    Billets dans le blog
    8
    Par défaut
    Sauf que, tout monstre fait partie d'une formation, ce faisant, par transitivité, tout utilisateur qui rencontre un monstre rencontre aussi la formation de ce monstre, du coup, la contrainte est suffisante

  14. #14
    Membre expérimenté
    Profil pro
    Inscrit en
    Juillet 2006
    Messages
    899
    Détails du profil
    Informations personnelles :
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : Juillet 2006
    Messages : 899
    Points : 1 390
    Points
    1 390
    Par défaut
    @escartefigue:
    Sauf qu'un monstre peut apparaitre dans plusieurs formations, ce qu'introduit la relation Agrege: 1-n, 1-n.

  15. #15
    Membre expérimenté
    Profil pro
    Inscrit en
    Juillet 2006
    Messages
    899
    Détails du profil
    Informations personnelles :
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : Juillet 2006
    Messages : 899
    Points : 1 390
    Points
    1 390
    Par défaut
    Merci pour tout.

    Je n'ai plus qu'a faire ingurgiter tout cela à Ms Access (je sent que ca va jazzer).

    Dernier point:
    Quel est la philosophie derrière les combinaisons de lettre (UA, FC, MF ect ...) ?
    Obtenir un nom unique ?

  16. #16
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    Septembre 2006
    Messages
    7 911
    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 : 7 911
    Points : 30 657
    Points
    30 657
    Billets dans le blog
    16
    Par défaut
    Citation Envoyé par escartefigue Voir le message
    Sauf que, tout monstre fait partie d'une formation, ce faisant, par transitivité, tout utilisateur qui rencontre un monstre rencontre aussi la formation de ce monstre, du coup, la contrainte est suffisante
    Pour l’anecdote, l’utilisateur qui rencontre un monstre rencontre toutes les formations de ce monstre. Mais ceci n’est-il vraiment qu’un détail ?

    Désormais la règle de gestion initiale :

    « Un utilisateur peut acquérir une frénésie, à condition qu'elle soit celle d'un monstre présent dans une formation déjà rencontrée. »

    Est remplacée par celle-ci, qui n’est pas équivalente :

    « Un utilisateur qui acquiert une frénésie doit rencontrer toutes les formations dont fait partie le monstre possesseur de cette frénésie. »

    A deedolith de trancher

    La philosophie derrière les combinaisons de lettre (UA, FC, MF etc.) ?
    Aucune ! Il s’agissait de gagner de la place dans le schéma...

    Bon courage avec Access !
    (a) Faites simple, mais pas plus simple ! (A. Einstein)
    (b) Certes, 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 »)

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

  17. #17
    Membre expérimenté
    Profil pro
    Inscrit en
    Juillet 2006
    Messages
    899
    Détails du profil
    Informations personnelles :
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : Juillet 2006
    Messages : 899
    Points : 1 390
    Points
    1 390
    Par défaut
    Je confirme: une, et non toutes.
    Par exemple, soit 2 formations:
    1) Truite des sables, Raie des sables, Raie des sables.
    2) Truite des sables, Truite des sables, Truite des sables, Truite des sables, Scorpion, Scorpion.
    Si l'utilisateur n'a rencontré que la seconde, cela n'implique pas qu'il a rencontré la première, pourtant la Truite des sables est présente dans les 2.
    La frénésie de la Raie des sables doit rester inaccessible.

    Citation Envoyé par fsmrel Voir le message
    La philosophie derrière les combinaisons de lettre (UA, FC, MF etc.) ?
    Ha ouais ?
    Mais du coup, tu m'as perdu loin ... très loin (il y a longtemps dans une galaxie ...)

  18. #18
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    Septembre 2006
    Messages
    7 911
    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 : 7 911
    Points : 30 657
    Points
    30 657
    Billets dans le blog
    16
    Par défaut
    Citation Envoyé par deedolith Voir le message
    La frénésie de la Raie des sables doit rester inaccessible.
    Ce qui implique que la table Rencontrer doit faire référence à la table Formation et non pas à la table Monstre :
     
    Code SQL : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    create table Rencontrer
    (
       UtilisateurId INT,
       FormationId INT,
       PRIMARY KEY(UtilisateurId, FormationId),
       FOREIGN KEY(FormationId) REFERENCES Formation(FormationId),
       FOREIGN KEY(UtilisateurId) REFERENCES Utilisateur(UtilisateurId)
    );
     
    Et que la table UFM doit faire référence à la table Agreger :
     
    Code SQL : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    create table UFM
    (
       UtilisateurId INT
    ,  FormationId INT
    ,  MonstreId INT
       PRIMARY KEY(UtilisateurId, FormationId, MonstreId)
    ,  FOREIGN KEY(UtilisateurId, FormationId) REFERENCES Rencontrer(UtilisateurId, FormationId)
    ,  FOREIGN KEY(FormationId, MonstreId) REFERENCES Agreger(FormationId, MonstreId)
    ,  FOREIGN KEY(UtilisateurId, MonstreId) REFERENCES Acquerir(UtilisateurId, MonstreId)
    );

    Cf. en cela les CREATE TABLE dans le post #12.

    Do you agree, Tovaritch ?
     
     
    Citation Envoyé par deedolith Voir le message
    tu m'as perdu loin ... très loin
    J’en suis navré...
    (a) Faites simple, mais pas plus simple ! (A. Einstein)
    (b) Certes, 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 »)

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

  19. #19
    Membre expérimenté
    Profil pro
    Inscrit en
    Juillet 2006
    Messages
    899
    Détails du profil
    Informations personnelles :
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : Juillet 2006
    Messages : 899
    Points : 1 390
    Points
    1 390
    Par défaut
    Yep, on est d'accord.

    Citation Envoyé par fsmrel Voir le message
    J’en suis navré...
    Maintenant, je me retrouve avec des relations dont le nom ne me dit rien, ce qui ne facilite pas la compréhension.

    D'apres ton MCD:
    "MF" peut devenir "Posseder" (ce que j'ai dans mon 1er message).
    "UFM" peut devenir "Inclure".
    Le reste, pour l'instant, je sèche.

  20. #20
    Modérateur
    Avatar de escartefigue
    Homme Profil pro
    bourreau
    Inscrit en
    Mars 2010
    Messages
    10 022
    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 022
    Points : 38 165
    Points
    38 165
    Billets dans le blog
    8
    Par défaut
    Une démonstration vaut mieux qu'un discours.

    J'ai enrichi un peu mon MCD pour ajouter des attributs en plus des simples identifiants et ajouté l'identification de la frénésie relativement au monstre comme indiqué plus haut.

    Ce qui donne le MCD suivant

    Nom : Sans titre.png
Affichages : 103
Taille : 14,8 Ko

    Le script correspondant décliné pour SQL server est celui-ci, notez la contrainte en fin de script.

    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
    CREATE TABLE UT_utilisateur(
       UT_ident INT IDENTITY,
       UT_nom VARCHAR(50) NOT NULL,
       PRIMARY KEY(UT_ident)
    );
     
    CREATE TABLE MO_monstre(
       MO_ident INT IDENTITY,
       MO_nom VARCHAR(50) NOT NULL,
       PRIMARY KEY(MO_ident)
    );
     
    CREATE TABLE FO_formation(
       FO_ident INT IDENTITY,
       FO_nom VARCHAR(50) NOT NULL,
       PRIMARY KEY(FO_ident)
    );
     
    CREATE TABLE FR_frenesie(
       MO_ident INT,
       FR_seq SMALLINT,
       FR_nom VARCHAR(50) NOT NULL,
       PRIMARY KEY(MO_ident, FR_seq),
       FOREIGN KEY(MO_ident) REFERENCES MO_monstre(MO_ident)
    );
     
    CREATE TABLE AQ_acquerir(
       MO_ident INT,
       FR_seq SMALLINT,
       UT_ident INT,
       PRIMARY KEY(MO_ident, FR_seq, UT_ident),
       FOREIGN KEY(MO_ident, FR_seq) REFERENCES FR_frenesie(MO_ident, FR_seq),
       FOREIGN KEY(UT_ident) REFERENCES UT_utilisateur(UT_ident)
    );
     
    CREATE TABLE RE_rencontrer(
       UT_ident INT,
       MO_ident INT,
       PRIMARY KEY(UT_ident, MO_ident),
       FOREIGN KEY(UT_ident) REFERENCES UT_utilisateur(UT_ident),
       FOREIGN KEY(MO_ident) REFERENCES MO_monstre(MO_ident)
    );
     
    CREATE TABLE AG_agreger(
       MO_ident INT,
       FO_ident INT,
       PRIMARY KEY(MO_ident, FO_ident),
       FOREIGN KEY(MO_ident) REFERENCES MO_monstre(MO_ident),
       FOREIGN KEY(FO_ident) REFERENCES FO_formation(FO_ident)
    );
     
    alter table AQ_acquerir
    add constraint FK_AQ_AC
    foreign key (UT_ident, MO_ident)
    references RE_rencontrer (UT_ident, MO_ident);

    J'insère ensuite un jeu d'essai de quelques lignes :

    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
    insert into UT_utilisateur (UT_nom)
    values ('dupont'), ('martin'), ('abadie')
    ;
    insert into MO_monstre (MO_nom)
    values ('raie des sables'), ('truite des sables'), ('scorpion')
    ;
    insert into FO_formation (FO_nom)
    values ('FO1'), ('FO2'), ('FO3')
    ;
    insert into FR_frenesie (MO_ident, FR_seq, FR_nom)
    values (1, 1, 'FR1'), (2, 1, 'FR2'), (3, 1, 'FR31'), (3, 2, 'FR32')
    ;
    -- création des agrégations
    insert into AG_agreger (MO_ident, FO_ident)
    values (1, 1), (1, 2), (2, 1), (3, 1), (3, 3)
    ;
    -- création des rencontres
    insert into RE_rencontrer (UT_ident, MO_ident)
    values (1, 1), (1, 2), (2, 2), (3, 3)
    ;
    -- qui a rencontré quoi
    select UTI.UT_nom as joueur
         , MON.MO_nom as monstre
    from        UT_utilisateur as UTI
    inner join  RE_rencontrer  as REN
       on REN.UT_ident = UTI.UT_ident
    inner join  MO_monstre     as MON
       on MON.MO_ident = REN.MO_ident

    Puis je réalise des acquisitions de frénésies valides, pas de souci, c'est accepté par SQL server :

    Code SQL : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    -- acquisition de frénésies
    insert into AQ_acquerir (MO_ident, FR_seq, UT_ident)
    values (1, 1, 1), (2, 1, 1)
    ;

    Et enfin, j'essaye d'acquérir une frénésie pour un joueur qui n'a pas rencontré le monstre concerné, là, ça couine

    Code SQL : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    -- acquisition invalide : le joueur n'a pas rencontré le monstre qui possède la frénésie
    insert into AQ_acquerir (MO_ident, FR_seq, UT_ident)
    values (2, 1, 3)
    ;

    Réponse du SGBD :
    Msg 547 Level 16 State 0 Line 93
    The INSERT statement conflicted with the FOREIGN KEY constraint "FK_AQ_AC". The conflict occurred in database "fiddle_e828546660ab484da435b49044fd19a9", table "dbo.RE_rencontrer".
    Vous retrouverez tout le script DB_fiddle ICI


    Il n'est donc absolument pas nécessaire que l'utilisateur rencontre toutes les formations d'un monstre ! On répond bel et bien au cahier des charges sans se faire des noeuds au cerveau

    EDIT : j'ai oublié de modifier la cardinalité minimale de MO_monstre vers AG_agreger, il faut remplacer le 0 par un 1, mais ça ne change évidemment rien au résultat

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

Discussions similaires

  1. Mettre en relation les contrôles DBLookUpComboBox et DBGrid
    Par Gendarmette dans le forum Bases de données
    Réponses: 7
    Dernier message: 19/01/2004, 14h16
  2. [Relations] afficher les relations entre 2 tables
    Par dzincou dans le forum PostgreSQL
    Réponses: 5
    Dernier message: 14/01/2004, 18h07
  3. [EJB2.1 Entity] [CMR] Relation One to Many
    Par hamed dans le forum Java EE
    Réponses: 2
    Dernier message: 31/12/2003, 15h26
  4. Réponses: 2
    Dernier message: 26/09/2003, 16h54
  5. Problème avec mes tables de relation...
    Par mmike dans le forum PostgreSQL
    Réponses: 4
    Dernier message: 02/06/2003, 16h16

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