Discussion :

[escartefigue]

Bonjour BlueBeery

Attention :

• dans le MCD on a bien le verbe "occupe(r)" mais dans les règles de gestion, on trouve à nouveau "possède(r)", ce faisant la correspondance entre les deux n'est pas claire et surtout, on retrouve les travers sur la notion de "possession" que j'avais expliqués dans mes réponses précédentes.
  J'avais compris que seule la localisation vous intéressait, pas la possession, auquel cas, les règles doivent être reformulées.
• il faut éviter les caractères spéciaux dans les noms d'objets car ça complexifie inutilement les requêtes.
  Supprimez le slash dans "groupe/societe" à remplacer par un underscore et les différents accents comme dans "pièce" ou "bâtiment" par exemple
  (pas de blanc ni de tiret non plus, pas d'accents ni cédille ni ligature, pas de combinaison majuscules/minuscules)

[BlueBeery]

Bonjour BlueBeery

Attention :

• dans le MCD on a bien le verbe "occupe(r)" mais dans les règles de gestion, on trouve à nouveau "possède(r)", ce faisant la correspondance entre les deux n'est pas claire et surtout, on retrouve les travers sur la notion de "possession" que j'avais expliqués dans mes réponses précédentes.
  J'avais compris que seule la localisation vous intéressait, pas la possession, auquel cas, les règles doivent être reformulées.
• il faut éviter les caractères spéciaux dans les noms d'objets car ça complexifie inutilement les requêtes.
  Supprimez le slash dans "groupe/societe" à remplacer par un underscore et les différents accents comme dans "pièce" ou "bâtiment" par exemple
  (pas de blanc ni de tiret non plus, pas d'accents ni cédille ni ligature, pas de combinaison majuscules/minuscules)

J'utilise la distinction sous looping du nom et nom logique afin de gagner en lisibilité, peut être cela n'est il pas une bonne pratique ?
Surtout que dans mon MLD textuel et mon code SQL, j'ai bien fait attention de ne pas inclure de caractère spéciaux.
Je vais corriger mes règles de gestion afin de coller au MCD.

[laurentSc]

Etant abonné à cette discussion, j'ai lu ton post ; même n'étant que débutant en MCD, plusieurs remarques ou questions :

- RG_BAT_001 : Un site peut appartenir de 1 à n société ; ça serait pas plutôt : un site appartient à une (et une seule) société ?

- RG_BAT_002 : Une société possède de 0 à n Pièce ; une pièce appartient à un bâtiment, OK, mais à une société ? Bizarre...

- contrainte_site , contrainte_bâtiment, contrainte_pièce : c'est quoi ces contraintes ?

- RG_BAT_005 : Un site possède de 0 à n type_site ; pour moi, un bâtiment possède un type et un seul...C'est quoi type_site ?

- RG_BAT_006 : Un site contient de 0 à n bâtiment ; un site qui contient 0 bâtiment, faut expliquer...

- RG_BAT_009 : Un bâtiment possède de 0 à n étage ; un bâtiment a au moins un étage (le rez de chaussée)

- RG_BAT_012 : Un étage possède de 0 à n piéce ; même remarque que pour RG_BAT_006

- RG_BAT_014 : Une pièce possède de 1 à n type_pièce : même remarque que pour RG_BAT_005

- les noms d'association : tu utilises parfois des noms (contrainte, bâtiment du site, pour contrainte, etc) ; je me souviens d'une remarque de escartefigue : plutôt toujours employer des verbes.

- type de l'attribut liste type : varchar(50). Pour une liste, j'aurais plutôt mis ENUM...

[escartefigue]

J'utilise la distinction sous looping du nom et nom logique afin de gagner en lisibilité, peut être cela n'est il pas une bonne pratique ?
Surtout que dans mon MLD textuel et mon code SQL, j'ai bien fait attention de ne pas inclure de caractère spéciaux.

C'est une très bonne pratique au contraire, c'est donc parfait

Je vais corriger mes règles de gestion afin de coller au MCD.

Alors à bientôt

les noms d'association : tu utilises parfois des noms (contrainte, bâtiment du site, pour contrainte, etc) ; je me souviens d'une remarque de escartefigue : plutôt toujours employer des verbes.

Ce n'est pas une obligation, mais l'avantage d'un verbe est qu'il permet de lire l'association dans les deux sens, par exemple
[CLIENT] 1,n --- (passer) --- 1,1[COMMANDE] correspond aux règles
RG001a : un client passe au moins une commande
RG001b : une commande est passée par un et un seul client

type de l'attribut liste type : varchar(50). Pour une liste, j'aurais plutôt mis ENUM...

Effectivement, s'il s'agit d'une typologie des sites, il faut renommer l'attribut (par exemple code_site en char(4)) et lui associer une contrainte CHECK (plutôt qu'une ENUM très pauvre en fonctionnalités)

[laurentSc]

RG001a : une commande passe au moins une commande

Moi, j'aurais dit : la commande est super intelligente

Effectivement, s'il s'agit d'une typologie des sites, il faut renommer l'attribut (par exemple code_site en char(4)) et lui associer une contrainte CHECK (plutôt qu'une ENUM très pauvre en fonctionnalités)

J'ai lu quelque part que ENUM était déconseillé mais n'avais pas pris le temps de lire pourquoi. Votre proposition (code_site en char(4) avec une contrainte CHECK) est TOP

[escartefigue]

J'ai corrigé :
RG001a : un client passe au moins une commande

Merci

Les ENUM étaient une sorte de CHECK service minimum (liste de valeurs possibles seulement) mais c'est tout ce que proposait MySQL avant la V8.
Comme la V8 a enfin implémenté les contraintes CHECK, ce serait dommage de s'en priver.

[laurentSc]

Votre proposition (code_site en char(4) avec une contrainte CHECK) est TOP

Je viens de réaliser que vous me l'aviez déjà conseillée !

Code sql :

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

1
2
3
4
5
COU_region CHAR(5) NOT NULL,
 
ALTER TABLE COU_country
ADD constraint COU_CHK_001
CHECK(COU_region IN ('ISMA','EMEA','NAM','other','china','APAC','India'))

[BlueBeery]

Bonjour,

- RG_BAT_001 : Un site peut appartenir de 1 à n société ; ça serait pas plutôt : un site appartient à une (et une seule) société ?

- RG_BAT_006 : Un site contient de 0 à n bâtiment ; un site qui contient 0 bâtiment, faut expliquer...

La notion de site est la suivante : Chaque société possède au moins 1 site ayant une adresse, sur 1 site il peut y avoir plusieurs Bâtiment, or dans un bâtiment on peut retrouver de multiple société => 1 site peut donc contenir de multiple société. La notion de site est volontairement vague, si je veux par exemple inclure dans ma base de données un constructeur sans pour autant trop détailler, je peux simplement dire que celui-ci possède un site de production en France dans la ville de d'Anger.

- RG_BAT_002 : Une société possède de 0 à n Pièce ; une pièce appartient à un bâtiment, OK, mais à une société ? Bizarre...

J'ai ici repris une suggestion du Forum, en effet la pièce est le plus petit élément de la partie, ainsi en mettant la notion d'occupation d'une pièce par une société, l'appartenance des étages et des bâtiments en découle.

- contrainte_site , contrainte_bâtiment, contrainte_pièce : c'est quoi ces contraintes ?

Y a-t-il un parking ? est-ce un site de l'armée ? etc ....

- RG_BAT_009 : Un bâtiment possède de 0 à n étage ; un bâtiment a au moins un étage (le rez de chaussée)

Cela peut en effet paraître bizarre, c'est pour permettre lors de la saisie par un utilisateur dans la future base de données, si celui-ci veut juste enregistrer un bâtiment pour une futur client sans plus de détail.

- type de l'attribut liste type : varchar(50). Pour une liste, j'aurais plutôt mis ENUM...

Je travaille en ce moment à la mise en forme des types

[laurentSc]

OK,

quand j'ai lu constructeur, mon premier réflexe a été de penser à celui de la POO...

Tu ne réponds pas aux questions que je pose sur RG_BAT_05 et RG_BAT_014.

Le mot contrainte ne me semble pas explicite ; j'aurais plutôt utilisé propriété.

Pour les points sur lesquels j'ai posé des questions, pour faciliter la lecture de ton MCD, moi, j'aurais ajouter des commentaires sur le graphique (icône texte)

[BlueBeery]

Bonjour, je reviens vers vous, car je rencontre un petit problème de mise en forme. J'ai une table "matériel" et une table qui regroupe une liste d'état possible pour celui-ci (neuf,bon, etc ...)
Ainsi les règles sont :

- Un matériel possède au plus un état.

- Un état réfère de 0 à n matériel.



Mais j'aimerais avoir la possibilité d'avoir des détails sur le "couple" état et matériel, par exemple : j'ai un écran un état moyen, détail : "plusieurs pixels noirs". (les détails sont facultatifs)
Aussi une fois que le matériel change d'état, les détails doivent être ressaisis.

J'ai utilisé une CIF mais je ne suis pas sur de moi :

[escartefigue]

Bonjour,

L'état du matériel ne doit-il pas être historisé ?

Par ailleurs, le nom de l'attribut "liste_etat" est inquiétant, une instance d'attribut ne doit jamais contenir une liste de valeurs, qu'avez vous prévu de stocker comme information ici  ?

[BlueBeery]

Bonjour,

L'état du matériel ne doit-il pas être historisé ?

Par ailleurs, le nom de l'attribut "liste_etat" est inquiétant, une instance d'attribut ne doit jamais contenir une liste de valeurs, qu'avez vous prévu de stocker comme information ici  ?

Pour le moment je reste simple, l'état n'a pas besoin d'être historisé.
Pour la liste_etat, elle contient la "liste" des états disponible. Je ne vois pas comment faire autrement... surtout que cette liste doit être modifiable par l'utilisateur final.

Edit :
Je suis un peu stupide parfois ...

voici une nouvelle "version" (avec les statuts mais on est dans le même cas que pour les états ), qui normalement garde même un historique !

[escartefigue]

Deux approches possibles :

La plus simple : rapatrier l'information dans l'entité-type matériel en lui associant une contrainte check pour restreindre les valeurs possibles.
Avec cette solution, pas d'historique possible.

La plus riche : faire une entité-type distincte comme vous l'avez modélisée, ce qui permet de gérer non seulement un code, mais aussi un libellé long, un libellé court, une date de début de validité, une date de fin de validité etc. Cette solution permet non seulement d'historiser les statuts, mais aussi d'établir une association entre ce statut et d'autres entité-type si besoin.

Dans les deux cas, l'attribut devrait s'appeler "statut" ou quelque chose d'équivalent, mais pas "liste_statut"

Question : que représente l'attribut "détail statut" dans l'association de votre modèle ?

[BlueBeery]

Re Bonjour après quelque temps,

Je fais face à un problème "simple" mais quelque peu frustrant!

J'ai 2 entités : Utilisateur et Métier

Et les règles suivantes :

Un utilisateur à un unique métier.
Un métier est effectué par de 1 à n utilisateurs.

Un utilisateur est chef de 0 à 1 métier.
Un métier à un unique Chef.

Je n'arrive pas à modéliser cette relation sans me retrouver avec une référence circulaire :




Comment me sortir de cette situation ?

[Paprick]

Bonjour,

Effectivement, dans votre modèle, un utilisateur doit obligatoirement faire référence à un métier, et un métier doit obligatoirement faire référence à un utilisateur, ce qui pose problème au moment de la création des tables, et de l'utilisation de l'application : tant qu'il n'y a pas d'utlisateur, on ne pourra pas créer de métier, et tant qu'il n'y pas de métier, on ne pourra pas créer d'utilisateur...

Avec Looping, on peut néanmoins contourner ce problème.
Pour éviter la référence circulaire, commencez par remplacer le 1,1 côté "Métier" par 1,n : le problème est alors de s'assurer qu'un métier n'ait qu'un seul chef .
Pour cela, il faut déclarer UNIQUE la clé étrangère de "Métier" présente dans "Utilisateur", ce qui n'est pas très simple :

1. Dans les propriétés de Looping, mettre à "Oui" l'option "Proposer index composé".
2. Ouvrir la fenêtre du lien 1,n de "A pour Chef", cocher la case "Clé étrangère dans index" et donner un nom à cet index ("Chef" par exemple).
3. Pour éviter toute ambiguïté au niveau des libellés des clés étrangères dans "Utilisateur", préciser un rôle sur cette même patte ("Chef" par exemple en suffixe).

De cette manière, un utilisateur ne pourra être chef que d'un seul métier et un métier ne pourra avoir qu'un seul chef.
Il restera néanmoins un problème : un métier peut se retrouver sans chef, mais ça c'est le prix à payer pour éviter une référence circulaire.
Ca peut se régler éventuellement avec une règle accompagnée du TRIGGER qui va bien dans Looping, ou directement dans l'application.

Autre petite remarque : "Nom métier" est un très mauvais identifiant ! Il est souhaitable de rajouter un "Id_métier".

Bonne continuation !