Interpréter le mini shema

**dancom5** · 27/10/2016, 04h00

Bonjour.

Me suis fait un mini shema avec jMerise et j'ai converti en Mysql après.
Le terme avatar est une image dans mon raisonnement ci-bas.

Mon shema:

Avatar 1,n ---- détenir ----- 1,1 Membres

Pour définir, je me suis pour arriver à 1,n et 1,1 les phrases suivantes:

pour 1,n: Un membre peut déternir 1 ou plusieurs avatar(s) ou photos.
pour 1,1: Un avatar peut être détenu par un seul membre

Mon objectif est d'attribuer entre 1 et plusieurs images par membres.
Mais qu'un seul membre puisse avoir les images.

C'est en vu de créer une image avec des sous-images si on veut une
catégories avec ses images.

Et surtout de voir si mon raisonnement est applicable ou bon.

Je me demande si c'est correcte.

Converti avec jMerise au résulat SQL :

Code :

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
#------------------------------------------------------------
# Table: avatars
#------------------------------------------------------------

CREATE TABLE avatars(
        id  Int NOT NULL ,
        url Varchar (100) NOT NULL ,
        PRIMARY KEY (id )
)ENGINE=InnoDB;


#------------------------------------------------------------
# Table: members
#------------------------------------------------------------

CREATE TABLE members(
        id         Int NOT NULL ,
        fname      Varchar (100) NOT NULL ,
        lname      Varchar (100) NOT NULL ,
        age        Int NOT NULL ,
        id_avatars Int NOT NULL ,
        PRIMARY KEY (id )
)ENGINE=InnoDB;

ALTER TABLE members ADD CONSTRAINT FK_members_id_avatars FOREIGN KEY (id_avatars) REFERENCES avatars(id);

Et ma requête SQL :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
            SELECT
            m.id,
            m.fname,
            m.lname,
            m.age,
            m.id_avatars,
            a.id,
            a.url
            FROM
            members AS m
            INNER JOIN avatars AS a ON a.id = m.id_avatars

D'après cela, un membre possède le même avatar ou image.

**escartefigue** · 27/10/2016, 09h36

Bonjour,

Attention, quand dans une règle de gestion, vous écrivez "peut", la cardinalité mini qui en découle est zéro et non un

De ce fait :
Un membre peut détenir 1 ou plusieurs avatar(s) ou photos. ==> 0,n
Un membre détient 1 à plusieurs avatars ou photos ==> 1,n
Il faut donc soit corriger vos règles, soit vos cardinalités

Votre DDL ne correspond pas a votre besoin car vous avez mis la FK avatar dans la table membre, ce qui implique qu'un membre possède un et un seul avatar
C'est la table avatar qui doit hériter en FK de l'identifiant du membre, et non l'inverse

**dancom5** · 27/10/2016, 10h09

Envoyé par escartefigue

Bonjour,
Un membre peut détenir 1 ou plusieurs avatar(s) ou photos. ==> 0,n
Un membre détient 1 à plusieurs avatars ou photos ==> 1,n
Il faut donc soit corriger vos règles, soit vos cardinalités

Merci escartefigue, je crois comprendre.

Je me reprends:

La manière que je dois interpréter ceci: Avatar 1,n ---- détenir ----- 1,1 Membres

Du côté gauche de détenir, je dois dire 1 membre détient (pour le 1 qui représente le membre) plusieurs avatars?
Et du côté droite de détenir, je dois dire 1 avatar est détenu par 1 seul membre?

Comme pour lire en chassé-croisé?

**escartefigue** · 27/10/2016, 10h30

Pas tout à fait, car la règle "1 avatar est détenu par 1 seul membre", ne dit pas clairement qu'un avatar doit obligatoirement appartenir à un membre

Du coup la formulation exhaustive est par exemple
R01 : un avatar appartient à un et un seul membre (si un avatar n'appartenant à personne est interdit)
ou
R01 : un avatar appartient au plus à un membre (dans le cas contraire)

De même
R02 : un membre détient un ou plusieurs avatars (si tout membre doit avoir au moins un avatar)
ou
R02 : un membre peut détenir plusieurs avatars (si certains membres peuvent ne pas en avoir, par exemple les nouveaux inscrits)

Une règle de gestion ne doit laisser aucune place à l'équivoque, tout ce qui n'est pas dit peut être interprété librement et donc différemment par les uns et les autres
Vu que le MCD est le socle de l'édifice Base de données, les règles de gestion se doivent d'être irréprochables.

**dancom5** · 27/10/2016, 11h52

Merci, c'est plus clair pour moi vos explications.

**dancom5** · 28/10/2016, 13h48

Bonjour.

Dans la suite de ce topic pour terminer, j'ai générer un MCD et MLD puis
je voudrais qu'on me dise si ça du bon sens les cardinalités en fonction
de la règle suivante:

Tout produit doit être représenté par une image qui doit être située
dans un seul album lui-même dans une seule catégorie.

Voici le shema dans cette image générée par jMerise:

Nom : MCD.jpg
Affichages : 369
Taille : 246,1 Ko

Nom : MCD.jpg
Affichages : 369
Taille : 246,1 Ko

En même temps, jMerise a généré le MLD suivant:

Nom : MLD.jpg
Affichages : 361
Taille : 268,5 Ko

Que signifie les petites flêches entourées en rouge?

**escartefigue** · 28/10/2016, 14h15

Bonjour,

La règle de gestion que vous mentionnez ne donne les cardinalités que de produit vers album, mais pas dans l'autre sens, du coup on ne peut valider qu'une partie des cardinalités du MCD :
Du coté produit, vos cardinalités sont OK

La flèche en rouge indique qu'il y a une contrainte de type référence par exemple entre la FK de la table produit et la PK de la table image
Je ne connais pas JMERISE, mais il y a probablement une fonctionnalité qui vous permet de visualiser le DDL généré.
Si c'est le cas, vous verrez dans le script, quelque chose qui doit ressembler à :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
CONSTRAINT nom_de_contrainte 
FOREIGN KEY (id_albums)
REFERENCES albums(id)
   ON UPDATE(option)
   ON DELETE(option)

Ce que j'ai mis en italique est la partie variable du script.

**dancom5** · 28/10/2016, 14h56

Pour commencer, merci pour votre intervention

Il n y a pas la notion DDL dans jMerise. Je peux générer le SQL, XML, MCD et MLD

Assez mélangeant parfois de déterminer les cardinalités.

A)
Pour y arriver, je vais à l'entité PRODUITS et pour déterminer la cardinalité à gauche, et je me suis dit ceci:
Un produit s'il est représentée par une image, il est forcément dans un album et un seul album. Alors, j'ai mis (1,1)

B)
Pour déterminer la cardinalité de ALBUMS, je me suis à droite vers PRODUIT, je me suis dit ceci:
Je me suis dis, il peut y avoir plusieurs PRODUITS comme il peut ne pas en avoir. Alors, j'ai mis (0,n)

C)
Pour déterminer la cardinalité à gauche de ALBUMS vers CATEGORIES pour obtenir (1,1), je me suis dit:
Un ALBUM se trouve forcément dans une catégories et seulement dans cette catégorie.

D)
Pour la cardinalité de CATEGORIES vers ALBUMS, une catégorie contient soit aucun ALBUM ou PLUSIEURS (0,1).
Mais, j'ai mis 1,n parce que je me suis dis pour qu'une catégorie puisse exister, il faut qu'il y ait un album ==> 1,n

Ce que je comprends, c'est seulement la partie A) qui serait bon?
Si, c'est le cas, c'est quoi qui ne va pas dans mes trois autres?

Envoyé par escartefigue

Bonjour,

La règle de gestion que vous mentionnez ne donne les cardinalités que de produit vers album, mais pas dans l'autre sens, du coup on ne peut valider qu'une partie des cardinalités du MCD :
Du coté produit, vos cardinalités sont OK

**escartefigue** · 28/10/2016, 16h28

Envoyé par dancom5

Pour commencer, merci pour votre intervention

Il n y a pas la notion DDL dans jMerise. Je peux générer le SQL, XML, MCD et MLD

Ce serait étonnant, si voyez des instructions comme DROP ou CREATE ou ALTER, alors il y a bien du DDL (Data Definition Language)
SQL inclut le DDL et le DML (Data Manipulation Language)

Envoyé par dancom5

B)
Pour déterminer la cardinalité de ALBUMS, je me suis à droite vers PRODUIT, je me suis dit ceci:
Je me suis dis, il peut y avoir plusieurs PRODUITS comme il peut ne pas en avoir. Alors, j'ai mis (0,n)

Alors c'est parfait, mais cette règle n'avait pas été écrite, d'où le doute.

**dancom5** · 28/10/2016, 16h58

Dans le logiciel, il n y a pas d'option DDL après l'avoir exploré.
Je vais plus explorer sur le sujet MERISE.

J'ai aussi compris qu'il fallait faire mes requêtes avec des jointures.

J'utilise PDO et MYSQL pour faire mes choses.

Je suis content que mon raisonnement soit correcte avec mes
règles versus les cardinalités. Je vais approfondir plus la dessus.

Merci pour vos explications escartefigue et j'ajoute 1+ aux interventions
bien appréciées et pertinentes.

**JPhi33** · 28/10/2016, 19h14

Bonjour dancom5 et escartefigue,

Je me permets de revenir sur le début de ce fil car dancom5 ne semble pas à l'aise avec les cardinalités Merise. Vous avez échangé sur les cardinalités de l'association "détenir" sans vous rendre compte l'un et l'autre que le schéma de dancom5 a toujours été à l'inverse des règles énoncées.

Envoyé par dancom5

La manière que je dois interpréter ceci: Avatar 1,n ---- détenir ----- 1,1 Membres

En effet, le schéma ci-dessus signifie :

Un avatar est détenu par 1 à n membres
Un membre détient 1 et 1 seul avatar

Et non pas :

Envoyé par dancom5

pour 1,n: Un membre peut déternir 1 ou plusieurs avatar(s) ou photos.
pour 1,1: Un avatar peut être détenu par un seul membre

Ni (extrait) :

Envoyé par escartefigue

R01 : un avatar appartient à un et un seul membre
R02 : un membre détient un ou plusieurs avatars

**dancom5** · 28/10/2016, 23h02

Comme je disais, c'est mélangeant ce sujet.

Envoyé par JPhi33

Bonjour dancom5 et escartefigue, ...Vous avez échangé sur les cardinalités de l'association "détenir" sans vous rendre compte l'un et l'autre que le schéma de dancom5 a toujours été à l'inverse des règles énoncées.

En effet, le schéma ci-dessus signifie :

Un avatar est détenu par 1 à n membres
Un membre détient 1 et 1 seul avatar

Ni (extrait) :

Très logique et rationnel comme phrase. Je prends!

Le 1er: un avatar est détenu par 1 à n membres, si c'est une image d'une personne en particulier, c'est un problème. Si c'est une image générique, non.
Le 2e : un membre détient un avatar qui soit la sienne son image ou une image quelconque, la règle est plus logique.

Donc, il faut voir ce qu'est un avatar. Si j'avais remplacer avatar par une photo, la question ne se poserait pas, je crois.

Le fait d'avoir indiquer : avatar ou photo, ça peut avoir laissé des sous-attendus.

Dans l'hypothèse que l'avatar est une photo personnelle, la règle aurait été plus:

Avatar 1,1 ---- détenir ----- 1,1 Membres

Un avatar est détenu par 1 et 1 seule membre.
Un membre détient 1 et un seul avatar.

Une table se créée et la migration d'une clé étrangère dans cette table de avatar et membres.

Mais, si mon avatar est générique, ça devient comme choisir une image quelconque comme choix.

C'est une idée.

**escartefigue** · 29/10/2016, 00h04

Envoyé par JPhi33

Bonjour dancom5 et escartefigue,
Je me permets de revenir sur le début de ce fil car dancom5 ne semble pas à l'aise avec les cardinalités Merise. Vous avez échangé sur les cardinalités de l'association "détenir" sans vous rendre compte l'un et l'autre que le schéma de dancom5 a toujours été à l'inverse des règles énoncées.

En effet, j'ai précisé la sémantinque mais sans relever l'inversion du prédicat, merci de l'avoir signalé

Je profite de ce post pour revenir sur la notion de DDL :

Dans le langage SQL, on distingue
- le DDL qui permet de définir les structures : databases, tables, tablespaces, index, et autres objets de la base de données
- le DML qui permet d'interroger et mettre à jour les données
Donc si Jmerise génère le SQL ce qui est tout à fait probable, il génère très certainement aussi les ordres DDL de création des tables et index, la plupart (tous ?) des outils de modélisation font ce travail.

**dancom5** · 29/10/2016, 00h36

Concernant jMerise, les détails:
http://www.jfreesoft.com/JMerise/

Pour mon raisonnement précédent, que l'avatar soit personnel ou générique (une image quelconque), la règle change.

Si l'avatar est générique [avatar]---1,n---(détient)---1,1---[membres] :
Un avatar est détenu par 1 à n membres (plusieurs personne peut avoir le même avatar)
Un membre détient 1 et 1 seul avatar (mais, un membre en détient qu'un).

Si l'avatar est personnel [avatar]---1,1---(détient)---1,1---[membres] ::
Un avatar est détenu par 1 et 1 seul membre (une personne parce que l'image est personnel)
Un membre détient toujours un seul avatar.

J'aurais dû écrire ça de même au message précédent. Me dire si ça du bon sens cela.

Interpréter le mini shema [MCD]

Schéma

Partager

Partager