MCD d'un outil de positionnement des entreprises..

Bonjour et bonnes fêtes en avance...

Je suis confronté à un problème de modélisation d'une base de données.
Je cherche à développer une BDD (Mysql) qui permettrait de positionner des "organisations" (entreprises, laboratoire, etc.) dans des filières industrielles, etc.

Voici les règles de gestions :

Une organisation appartient à 1 ou plusieurs filières industrielles

Une filière industrielle se divise en 1 ou plusieurs chaîne de valeur
Une chaîne de valeur appartient à 1 et 1 seule filière industrielle

Une chaîne de valeur se divise en 1 ou plusieurs segments
Un segment appartient à 1 et 1 seule filière

Un segment possède 1 à n besoins clés
Un besoin clé appartient à un segment

Une organisation se positionne sur un ou plusieurs chaîne de valeur
Une organisation se positionne sur un ou plusieurs segments (à partir des chaînes de valeur sélectionnées au préalable)

Je me pose des questions sur les relations de ma base de données ...
Je vois surtout qu'il y a une séquence hiérarchique entre les différentes entités...

Est ce que je dois utiliser une relation ternaire ? organisation - segment - chaîne de valeur
Est ce que je dois créer une entité qui regrouperait ces entités ?
par exemple avec une table "entités" avec les champs : filières, chaîne de valeur, segments, besoins clés ... Mais cela alourdirait un peu la base non ?

Merci d'avance pour votre réponse

Citation:

---

Envoyé par dreamweaver

Je cherche à développer une BDD (Mysql) qui permettrait de positionner des "organisations" (entreprises, laboratoire, etc.) dans des filières industrielles, etc.

Voici les règles de gestions :

---

Bonjour,

Vous avez énuméré vos règles de gestion, c'est une base nécessaire pas toujours suffisante, mais c'est déjà très positif, car c'est malheureusement rarement le cas :)
Vous auriez pu les numéroter, ça facilite les échanges ;)

Citation:

---

Envoyé par dreamweaver

Un segment appartient à 1 et 1 seule filière

---

Cette règle est redondante car on l'obtient par transitivité avec les règles précédentes : vous avez décrit les dépendances fonctionnelles suivantes
DF1 : chaine de valeur -> Filière
DF2 : segment -> chaine de valeur
On en déduit donc par transitivité
DF3 : segment -> Filière

Citation:

---

Envoyé par dreamweaver

Un segment possède 1 à n besoins clés
Un besoin clé appartient à un segment

---

A compléter : un et un seul ?

Citation:

---

Envoyé par dreamweaver

Une organisation se positionne sur un ou plusieurs chaîne de valeur
Une organisation se positionne sur un ou plusieurs segments (à partir des chaînes de valeur sélectionnées au préalable)

---

Il y a deux chemins pour aller de "Organisation" vers "Chaine de valeur" : en passant par "Filière" ou directement
En l'état, rien ne vous interdit d'aller de "Organisation" vers une "Chaine de valeur" qui ne correspond à aucune "Filière" en lien avec l'Organisation
Est-ce souhaité ou faut il au contraire le contrôler ?
Même chose pour aller de "Organisation" vers "Segment"

Citation:

---

Envoyé par dreamweaver

par exemple avec une table "entités" avec les champs : filières, chaîne de valeur, segments, besoins clés ... Mais cela alourdirait un peu la base non ?

---

Il est prématuré de se préoccuper des tables, il faut d'abord établir le MCD et pour ça, stabiliser les règles de gestion dans leur exhaustivité ;)

Il faudrait que vous commenciez à modéliser un MCD (sous forme graphique), avec les identifiants et les attributs.
C'est plus facile à lire que du texte :)
Si vous n'avez pas de logiciel pour ça, vous pouvez en télécharger des gratuits

Comme a dit escartefigue, écrire les règles e gestion des données, c'est bien et les vôtres sont assez bien formulées dans l'ensemble.

Passez maintenant au dessin du MCD ; ça vous aidera à y voir plus clair.
Revenez nous voir avec votre schéma et posez-nous des questions précises sur les difficultés de modélisation que vous rencontrez.

Bonjour et bonnes fêtes en avance...

Merci pour vos réponses et pour répondre à vos remarques je vous apporte les éléments complémentaires.

Citation:

---

Envoyé par escartefigue

Bonjour,
A compléter : un et un seul ?

---

En effet oui... C'est bien un et un seul ...

Citation:

---

Envoyé par escartefigue

Il y a deux chemins pour aller de "Organisation" vers "Chaine de valeur" : en passant par "Filière" ou directement
En l'état, rien ne vous interdit d'aller de "Organisation" vers une "Chaine de valeur" qui ne correspond à aucune "Filière" en lien avec l'Organisation
Est-ce souhaité ou faut il au contraire le contrôler ?
Même chose pour aller de "Organisation" vers "Segment"

---

je souhaite mettre un contrôle fort ... Une chaîne de valeur appartient impérativement à une filière ... On ne peut pas avoir de chaîne de valeur "indépendantes" ... On créera une nouvelle filière si on souhaite créer une CDV qui ne rentre pas dans les filières existantes...
C'est pareil pour un segment ... Un segment appartient impérativement à une chaîne de valeur.
Pour faire simple, tous les besoins clés sont inclus dans des segments qui sont inclus dans des chaînes de valeurs qui sont inclues dans des filières ...

Citation:

---

Envoyé par escartefigue

Il faudrait que vous commenciez à modéliser un MCD (sous forme graphique), avec les identifiants et les attributs.
C'est plus facile à lire que du texte :)
Si vous n'avez pas de logiciel pour ça, vous pouvez en télécharger des gratuits

---

Voici un MCD fait assez rapidement avec JMerise ...
Je n'entre pas trop dans le détail des entités ...
j'ai ajouté le fait que ce serait en multilingue mais cela n'a pas trop d'importance du moins a ce niveau ... ...
Je pense avoir créé beaucoup trop de relations dans cet embryon de BDD ...

Les users sont positionnés sur les segments avec une intensité de relation .. dans le lien "ETRE POSITIONNE" on doit retrouver un Numérique (longueur 1)

Pièce jointe 336795



Bien cordialement

Citation:

---

Une organisation appartient à 1 ou plusieurs filières industrielles

---

Je ne vois pas cette règle modélisée dans votre MCD.

Citation:

---

Une organisation se positionne sur un ou plusieurs chaîne de valeur
Une organisation se positionne sur un ou plusieurs segments (à partir des chaînes de valeur sélectionnées au préalable)

---

Il semble que vous ayez transformé les organisations en users ?
Si je remplace organisation par user, dans votre MCD, un user peut se positionner sur un segment qui n'est pas possédé par une chaîne de valeur sur laquelle il s'est positionné.
À vous de voir si le positionnement se fait :
- sur la chaîne de valeur, ce qui entraîne implicitement le positionnement sur tous les segments de cette chaîne ;
- sur le segment, ce qui entraine implicitement le positionnement sur la chaîne de valeur qui possède ce segment.

Idem avec les filières.

En fait, du fait de l'enchaînement hiérarchique que vous avez entre les filières, les chaînes de valeur, les segments et les besoins clés, vous pourriez utiliser l'identification relative :
keyneeds -(1,1)----posseder----1,n- segment -(1,1)----posseder----1,n- valuechain -(1,1)----posseder----1,n- filiere

Notez au passage que je nomme les entités types au singulier, ce que je vous conseille de faire parce que le pluriel peut introduire des ambiguïtés sémantiques. Une règle de gestion s'exprime pour chaque entité type au singulier, comme vous l'avez d'ailleurs fait : Une organisation se positionne sur une ou plusieurs chaîne de valeur... règle à compléter par la contraposée... et une chaîne de valeur est positionnée par une seule organisation.

L'inconvénient de l'identification relative en chaîne est, en bout de chaîne, la complexité de la clé primaire. En effet, mon morceau de MCD ci-dessus va donner les tables suivantes :
filiere (fil_id, ...)
valuechain (vch_id_filiere, vch_numero, ...)
segment (seg_id_filiere, seg_numero_filiere, seg_numero, ...)
keyneed (knd_id_filiere, knd_numero_filiere, knd_numero_segment, knd_numero, ...)

L'avantage est qu'on est sûr qu'un positionnement sur une chaîne de valeur sera bien un positionnement aussi sur la filière de cette chaine de valeur.
L'autre avantage est qu'on n'est pas obligé de faire des jointures en cascade pour trouver la filière d'un keyneed : une seule jointure suffit puisque keyneed contient l'identifiant de la filière.

Autant pour moi ... dans la BDD :

RG1 - Users appartiennent à 1 et 1 organizations
RG2 - Organizations avoir 1 à n users

(autre règles à venir non encore édictées dans le MCD)
RG3 - Organization possèder des Organizations
RG4 - Organization etre filiale 1 et 1 seule Organizations

Citation:

---

Envoyé par CinePhil

Je ne vois pas cette règle modélisée dans votre MCD.
Il semble que vous ayez transformé les organisations en users ?
Si je remplace organisation par user, dans votre MCD, un user peut se positionner sur un segment qui n'est pas possédé par une chaîne de valeur sur laquelle il s'est positionné.
À vous de voir si le positionnement se fait :
- sur la chaîne de valeur, ce qui entraîne implicitement le positionnement sur tous les segments de cette chaîne ;
- sur le segment, ce qui entraine implicitement le positionnement sur la chaîne de valeur qui possède ce segment.

Idem avec les filières.

En fait, du fait de l'enchaînement hiérarchique que vous avez entre les filières, les chaînes de valeur, les segments et les besoins clés, vous pourriez utiliser l'identification relative :
keyneeds -(1,1)----posseder----1,n- segment -(1,1)----posseder----1,n- valuechain -(1,1)----posseder----1,n- filiere

---

Un users se positionne sur 1 à n filières,
Users doivent se positionner sur des CDV qui sont dans les filières

Citation:

---

Envoyé par CinePhil

Notez au passage que je nomme les entités types au singulier, ce que je vous conseille de faire parce que le pluriel peut introduire des ambiguïtés sémantiques. Une règle de gestion s'exprime pour chaque entité type au singulier, comme vous l'avez d'ailleurs fait : Une organisation se positionne sur une ou plusieurs chaîne de valeur...

---

J'ai aussi un préférence pour le singulier mais ...Le choix du pluriel n'est pas un choix personnel mais dépend des conventions de l'ORM que je vais utiliser... Je compte développer l'appli sous Laravel ... y compris les relations : la relation users et filieres s'écrira filieres_users (table pivot) dans l'ordre alphabétique, ce qui en termes de lecture et de compréhension n'est pas très agréable... Je pense que mon soucis de conception vient essentiellement du fait que je conçois les relations entre les entités du point de vue du cheminement que devra suivre l'utilisateur pour s'inscrire ...

- choisir les filières qui le concerne
- choisir les chaînes de valeurs des filières
- choisir les segments qui sont dans les chaînes de valeurs sélectionnées ...

On ne peut pas choisir son positionnement sans avoir défini au préalable sa filière (étape 1) et ses chaînes de valeur (étape 2)

il est possible que je prenne le problème à l'envers ... je vais réfléchir un peu à tout ça ...

Citation:

---

Envoyé par CinePhil

L'avantage est qu'on est sûr qu'un positionnement sur une chaîne de valeur sera bien un positionnement aussi sur la filière de cette chaine de valeur.
L'autre avantage est qu'on n'est pas obligé de faire des jointures en cascade pour trouver la filière d'un keyneed : une seule jointure suffit puisque keyneed contient l'identifiant de la filière.

---

je vais regarder tout ça à tête reposée et reviendrai avec un MCD plus abouti et surtout plus clair ...

Merci encore pour vos pistes

Citation:

---

RG1 - Users appartiennent à 1 et 1 organizations

---

Vous voyez l'ambiguïté syntaxique du pluriel ?
=> Écrivez vos règles de gestion en considérant UNE entité au singulier puis l'autre (user, organization). Ensuite, nommez vos entités types au singulier dans votre MCD, puis vos tables dans la BDD.

Citation:

---

Le choix du pluriel n'est pas un choix personnel mais dépend des conventions de l'ORM que je vais utiliser

---

Euh... ça m'étonnerait que l'Outil Réellement Merdique :mrgreen: que vous allez utiliser vous impose un nom au pluriel ! Pour lui, 'xyz', 'user' ou 'te_utilisateur_uti' sont, je pense, des noms valables. Ou alors il est encore plus pourri que les quelques uns auxquels je me suis confronté. :aie:

Citation:

---

la relation users et filieres s'écrira filieres_users (table pivot) dans l'ordre alphabétique, ce qui en termes de lecture et de compréhension n'est pas très agréable... Je pense que mon soucis de conception vient essentiellement du fait que je conçois les relations entre les entités du point de vue du cheminement que devra suivre l'utilisateur pour s'inscrire ...

- choisir les filières qui le concerne
- choisir les chaînes de valeurs des filières
- choisir les segments qui sont dans les chaînes de valeurs sélectionnées ...

On ne peut pas choisir son positionnement sans avoir défini au préalable sa filière (étape 1) et ses chaînes de valeur (étape 2)

il est possible que je prenne le problème à l'envers ... je vais réfléchir un peu à tout ça ...

---

Ne pas confondre modélisation des données en vue de l'architecture de la base de données et modélisation des classes métier de l'application. À plus forte raison, ne pas confondre avec les processus métier.

Votre enchaînement de choix par l'utilisateur va entraîner le développement de listes de choix liées dans le formulaire présenté à l'utilisateur. Ce n'est pas incompatible avec la modélisation des données qui se fait aussi de manière hiérarchique en partant de la filière pour aboutir aux besoins clés.

La notion d'organisation a disparu de votre MCD, or c'était la raison d'être de ma remarque

Citation:

---

Envoyé par escartefigue

Il y a deux chemins pour aller de "Organisation" vers "Chaine de valeur" : en passant par "Filière" ou directement
En l'état, rien ne vous interdit d'aller de "Organisation" vers une "Chaine de valeur" qui ne correspond à aucune "Filière" en lien avec l'Organisation
Est-ce souhaité ou faut il au contraire le contrôler ?
Même chose pour aller de "Organisation" vers "Segment"

---

Qu'en est il ? Est-ce un oubli ?

Les entités-type suffixées "_Trad" sont elles là pour mentionner qu'il existe une traduction dans une langue pour chaque entité-type de même nom sans le suffixe ?
Ce ne sont pas les types d'entité qui sont traduits mais les contenus, sauf si l'un et l'autre sont des acteurs différents de votre modèle conceptuel
exemple : la facture n° 100 est une instance de l'entité-type facture, cette facture n°100 peut être libellée en français, en allemand, en serbe ou tout autre langue
Les attributs de la facture sont indifférenciés quelque soit la langue (montant, date, n° de facture...) ce ne sont que les textes associés à l'imprimé "facture" qui eux varieront en fonction de la langue

Tout comme Cinéphil, je ne vois pas en quoi une nomenclature au pluriel pourrait vous être imposée, ce n'est pas conforme à l'usage et dénoué de tout fondement

EDIT : à propos des langues, je vois que vous mêlez joyeusement des termes français comme "filière" et anglais comme "organization" ou "user".
Il vaut mieux choisir son camp, pour éviter de tomber sur des homonymes ou de faux amis.
Si vous intervenez sur un projet franco-français, privilégiez les termes français, si au contraire vous intervenez à l'international, alors le plus souvent l'anglais s'impose (voire la langue locale, si toutefois vous la maitrisez) ;)

Citation:

---

Envoyé par escartefigue

La notion d'organisation a disparu de votre MCD, or c'était la raison d'être de ma remarque
Qu'en est il ? Est-ce un oubli ?

---

C'est un oubli de ma part en fait ... que ce soit un "utilisateur" ou une "organisation" (je vais faire l'effort de tout écrire en français... ca simplifiera un peu). Je crois avoir posté ma première question vers minuit une heure (donc pas très frais) et avoir répondu en pleine préparation de valise ...

Citation:

---

Envoyé par escartefigue

Les entités-type suffixées "_Trad" sont elles là pour mentionner qu'il existe une traduction dans une langue pour chaque entité-type de même nom sans le suffixe ?
Ce ne sont pas les types d'entité qui sont traduits mais les contenus, sauf si l'un et l'autre sont des acteurs différents de votre modèle conceptuel
exemple : la facture n° 100 est une instance de l'entité-type facture, cette facture n°100 peut être libellée en français, en allemand, en serbe ou tout autre langue
Les attributs de la facture sont indifférenciés quelque soit la langue (montant, date, n° de facture...) ce ne sont que les textes associés à l'imprimé "facture" qui eux varieront en fonction de la langue

---

Oui ... par exemple "filiere" est caractérisée que par un ID... et "filiere_trad" comprendra l'intitulé / nom de la filière ... Ca me semble plus pertinent que d'utiliser une entité "filiere" et d'ajouter dans "filiere" les champs "nom_fr", "nom_en", nom_es", etc. A chaque ajout de langue je vais me retrouver à modifier chaque entité et par la suite chaque table de la BDD ...
Si la filière à un ID 1, les entrées dans filiere_trad comprendra l'ID filiere et la traduction associée ... J'imagine qu'il doit bien y avoir d'autres méthodes pour y arriver, si vous avez une proposition plus efficace, je suis preneur ... J'aurais pu créer une relation entre l'entité "filiere" et "filiere" avec une relation "ETRE LA TRADUCTION DE...".

Citation:

---

Envoyé par escartefigue

Tout comme Cinéphil, je ne vois pas en quoi une nomenclature au pluriel pourrait vous être imposée, ce n'est pas conforme à l'usage et dénoué de tout fondement

---

Bizzarement, c'est la nomenclature de l'ORM Eloquent ... J'avoue que ca pique un peu les yeux au début...
Donc je suis allé revérifier histoire de voir si j'avais pas tout compris de travers et apparemment j'ai relativement bien compris ... Cependant on peut faire ce qu'on veut mais ca fout tout un bordel dans les modèles où il faut rajouter en dur les noms des tables & des clés primaires, etc.

• https://laravel.com/docs/5.5/eloquent
• http://www.laravelbestpractices.com/...se_conventions
• http://www.rappasoft.com/articles/la...vention-guide/

Citation:

---

Envoyé par escartefigue

EDIT : à propos des langues, je vois que vous mêlez joyeusement des termes français comme "filière" et anglais comme "organization" ou "user".
Il vaut mieux choisir son camp, pour éviter de tomber sur des homonymes ou de faux amis.
Si vous intervenez sur un projet franco-français, privilégiez les termes français, si au contraire vous intervenez à l'international, alors le plus souvent l'anglais s'impose (voire la langue locale, si toutefois vous la maitrisez) ;)

---

Je suis porteur du projet en fait ... le contexte du dév sera sans aucun doute européen... donc le choix de la langue sera sans aucun doute l'anglais.
Le MCD a été fait en un quart d'heure avant d'attraper mon train donc du coup j'ai fait un peu ça sans trop faire attention à la langue. Je vais retravailler ça (en anglais & au singulier) pour voir si certains points peuvent être améliorés... je ferais la traduction version Eloquent ultérieurement. L'essentiel c'est que le MCD soit cohérent et que le MPD ensuite ne soit pas foireux...

Merci en tout cas pour le coup de pouce et les commentaires qui me permettent d'enrichir ma réflexion ... je pense que j'aurais un "beau" MCD un peu après les fêtes ... Je vais quand même pas vous harceler pendant la trêve des confiseurs

Bonnes fêtes en tout cas...

Pour gérer les différentes langues il faut créer une association entre l'entité-type concernée et la langue.

Par exemple pour les filières vous modélisez

FILIERE 0,n --- traduire --- 0,n LANGUE

Dans le MLD, l'association "traduire" deviendra une table dont la PK sera id_filière + id_langue et dont les autres attributs seront les différents libellés (libellé court, libellé long, abrégé, sigle...)

Citation:

---

Envoyé par escartefigue

Pour gérer les différentes langues il faut créer une association entre l'entité-type concernée et la langue.

Par exemple pour les filières vous modélisez

FILIERE 0,n --- traduire --- 0,n LANGUE

Dans le MLD, l'association "traduire" deviendra une table dont la PK sera id_filière + id_langue et dont les autres attributs seront les différents libellés (libellé court, libellé long, abrégé, sigle...)

---

Je me rends compte que je mettais dans mon MCD les tables pivots ... Ca simplifie nettement mon schéma maintenant ...
J'ai modifié mon MCD et les rèles de gestion ... Ce coup ci c'est en anglais et au singulier ...


RG001-1 organization AVOIR 1 à n user
RG001-2 user APPARTENIR 1 et 1 seul organization
RG002-1 organization SE POSITIONNER 0 à n segment
RG002-2 segment INCLURE 0 à n organization
RG003-1 keyneed APPARTENIR 1 et 1 seul segment
RG003-2 segment REPERTORIER 0 à n keyneed
RG004-1 segment APPARTENIR 1 et 1 seul valuechain
RG004-2 valuechain POSSEDER 0 à n segment
RG005-1 valuechain APPARTENIR 1 et 1 seul sector
RG005-2 sector COMPORTER 0 à n valuechain
RG006-1 keyneed ETRE TRADUIT 1 à n lang
RG006-2 lang TRADUIRE 1 à n keyneed
RG007-1 segment ETRE TRADUIT 1 à n lang
RG007-2 lang TRADUIRE 1 à n segment
RG008-1 valuechain ETRE TRADUIT 1 à n lang
RG008-2 lang TRADUIRE 1 à n valuechain
RG009-1 sector ETRE TRADUIT 1 à n lang
RG009-2 lang TRADUIRE 1 à n sector
RG010-1 segment ETRE RELIE 1 à n segment Matrice segment / Segment
RG010-2 segment ETRE EN RELATION 1 à n segment


Pièce jointe 337646

Merci pour le coup de main ... En vous souhaitant de joyeuses fêtes de fin d'année à tous!
Bien cordialement !!

Bonjour,

Vous avez numéroté vos règles de gestion, bravo, ça facilite les échanges, et justement à ce propos, j'ai quelques remarques ;)

Les cardinalités exprimées dans les règles RG001 et RG006 à RG010 sont divergentes avec ce qui est mentionné sur le MCD
Pour ce qui concerne les traductions :
- il faut prévoir une cardinalité mini de zéro coté langue car vous pouvez avoir référencé des langues qui ne sont pour l'instant pas utilisées pour une traduction
- il faut a priori prévoir une cardinalité mini de un coté segment, valuechain etc... car on peut penser qu'à minima il existe une traduction pour chacune de ces ET (entités-type)

Concernant les ET "user" et "organization", il ne faut pas modéliser les n° de téléphone et autres média comme dans un tableur, mais utiliser une relation entre l'ET une nouvelle ET "média"
Ca vous évitera d'avoir des colonnes inutiles topées nulles pour les user n'ayant pas de fax, pas de portable ou autre, et de manquer de colonnes pour ceux qui ont plusieurs portables (pro, privé, d'astreinte...) ou d'autres média que vous n'avez pas prévu (minitel :aie: ;))
La bonne modélisation est donc la suivante
USER (id, nom, prénom, etc...) 0,n --- posséder --- (1,1) MEDIA (id, numéro, code_favori) (1,1) --- typer --- 0,n TYPE_MEDIA(id, code_type, libellé_type)
Notez les parenthèses autour des cardinalités de l'ET média, ce qui permet d'identifier le média relativement au USER et au TYPE_MEDIA.
Ce n'est pas obligatoire, mais bien pratique pour retrouver tous les média (téléphones, fax, adresse courriel, etc...) d'un user ou tous les média d'un certain type (téléphones par exemple) pour un user ;)
L'attribut "code_favori" permet d'identifier le(s) média(s) préféré(s) d'un user (celui sur lequel il préfère être contacté)
Faites de même avec l'ET "organization"

D'une façon générale, si l'attribut "deleted_at" est la date de suppression logique, vous pourriez supprimer cet attribut, redondant avec "updated_at" à condition d'ajouter un attribut (un caractère suffit) mentionnant le type de mise à jour (exemple "M" pour modification "S" pour suppression logique)

Bonjour,
et pour commencer bonne année, bonne santé et que 2018 soit une année remplie de MCD, MLD et MPD ...

Citation:

---

Envoyé par escartefigue

Bonjour,

Vous avez numéroté vos règles de gestion, bravo, ça facilite les échanges, et justement à ce propos, j'ai quelques remarques ;)

Les cardinalités exprimées dans les règles RG001 et RG006 à RG010 sont divergentes avec ce qui est mentionné sur le MCD
Pour ce qui concerne les traductions :
- il faut prévoir une cardinalité mini de zéro coté langue car vous pouvez avoir référencé des langues qui ne sont pour l'instant pas utilisées pour une traduction
- il faut a priori prévoir une cardinalité mini de un coté segment, valuechain etc... car on peut penser qu'à minima il existe une traduction pour chacune de ces ET (entités-type)

---

Je fais trop attention aux max dans mes relations mais rarement aux mins...

Citation:

---

Envoyé par escartefigue

Concernant les ET "user" et "organization", il ne faut pas modéliser les n° de téléphone et autres média comme dans un tableur, mais utiliser une relation entre l'ET une nouvelle ET "média"
Ca vous évitera d'avoir des colonnes inutiles topées nulles pour les user n'ayant pas de fax, pas de portable ou autre, et de manquer de colonnes pour ceux qui ont plusieurs portables (pro, privé, d'astreinte...) ou d'autres média que vous n'avez pas prévu (minitel :aie: ;))
La bonne modélisation est donc la suivante
USER (id, nom, prénom, etc...) 0,n --- posséder --- (1,1) MEDIA (id, numéro, code_favori) (1,1) --- typer --- 0,n TYPE_MEDIA(id, code_type, libellé_type)
Notez les parenthèses autour des cardinalités de l'ET média, ce qui permet d'identifier le média relativement au USER et au TYPE_MEDIA.
Ce n'est pas obligatoire, mais bien pratique pour retrouver tous les média (téléphones, fax, adresse courriel, etc...) d'un user ou tous les média d'un certain type (téléphones par exemple) pour un user ;)
L'attribut "code_favori" permet d'identifier le(s) média(s) préféré(s) d'un user (celui sur lequel il préfère être contacté)
Faites de même avec l'ET "organization"

---

OK ...si je comprends bien il faut que je normalise encore plus mes entités ... Je vais aussi faire la même chose avec les URL (linkedin, viadeo, website, twitter....). Le principe est le même à priori... Au niveau de ma représentation, l'entité "media" va générer une table pivot... Ne serait t'il pas plus pertinent de créer une relation 1,n et 1,n entre "user" et "type_media" de la même manière que nous avons pu le faire pour les langues...
PS : je ne compte pas mettre le minitel ... ca existe encore d'ailleurs ?

Citation:

---

Envoyé par escartefigue

D'une façon générale, si l'attribut "deleted_at" est la date de suppression logique, vous pourriez supprimer cet attribut, redondant avec "updated_at" à condition d'ajouter un attribut (un caractère suffit) mentionnant le type de mise à jour (exemple "M" pour modification "S" pour suppression logique)

---

Comme vous le faites remarquer, je pourrais utiliser un attribut avec un caractère S ou M voire un booléen ... Ceci dit l'ORM que je compte utiliser utilise une date comme attribut d'une suppression logique...

Voici donc mes règles de gestion

RG001-1 organization AVOIR 1 à n user
RG001-2 user APPARTENIR 1 et 1 seul organization
RG002-1 organization SE POSITIONNER 0 à n segment
RG002-2 segment INCLURE 0 à n organization
RG003-1 keyneed APPARTENIR 1 et 1 seul segment
RG003-2 segment REPERTORIER 0 à n keyneed
RG004-1 segment APPARTENIR 1 et 1 seul valuechain
RG004-2 valuechain POSSEDER 0 à n segment
RG005-1 valuechain APPARTENIR 1 et 1 seul sector
RG005-2 sector COMPORTER 0 à n valuechain
RG006-1 keyneed ETRE TRADUIT 1 à n lang
RG006-2 lang TRADUIRE 0 à n keyneed
RG007-1 segment ETRE TRADUIT 0 à n lang
RG007-2 lang TRADUIRE 1 à n segment
RG008-1 valuechain ETRE TRADUIT 1 à n lang
RG008-2 lang TRADUIRE 0 à n valuechain
RG009-1 sector ETRE TRADUIT 1 à n lang
RG009-2 lang TRADUIRE 0 à n sector
RG010-1 segment ETRE RELIE 1 à n segment Matrice segment / Segment
RG010-2 segment ETRE EN RELATION 1 à n segment
RG011-1 keyneed ETRE RELIE 1 à n keyneed Matrice keyneed / keyneed
RG011-2 keyneed ETRE EN RELATION 1 à n keyneed
RG012-1 organization AVOIR 1 et 1 seul typology (PME, PMI,ETI...)
RG012-2 typology S'APPLIQUER 1 à n organization
RG013-1 organization AVOIR 0 à n url
RG013-2 url APPARTENIR 1 et 1 seul organization
RG014-1 organization AVOIR 0 à n communication (téléphone, fax)
RG014-2 communication APPARTENIR 1 et 1 seul organization
RG015-1 user DIRIGER 0 à n user (hierarchy)
RG015-2 user ETRE DIRIGE 1 et 1 seul user
RG016-1 user AVOIR 0 à n user et AVOIR 1 à n contact_type (contacts)
RG016-2 user ETRE DANS LES CONTACTS 0 à n user
RG017-1 admin CRÉER 1 à n valuechain
RG017-2 valuechain EDITER 1 à n admin
RG018-1 user ENVOYER 1 à n message
RG018-2 message ETRE ENVOYE 1 à n user
RG019-1 user RECEVOIR 1 à n message
RG019-2 message ETRE RECU 1 à n user
RG020-1 domain ETRE TRADUIT 1 à n lang
RG020-2 lang TRADUIRE 0 à n domain
RG021-1 user AVOIR 1 à n role
RG021-2 role ETRE ATTRIBUE 0 à n user
RG022-1 role AVOIR 1 à n permission
RG022-2 permission ETRE ATTRIBUE 0 à n role

Et mon MCD "final" ...

Pièce jointe 338728

PS : je remarque que les premiers échanges ne comprenaient que trois quatre tables et qu'au fur et à mesure elles augmentent en quantité :) Je précise que ca augmente aussi en qualité grace à vous... au final on risque de finaliser tout le boulot conceptuel avec 230 entités.. Faudrait peut etre que j'envoie une bouteille de champagne ?

Je pense que je vais marquer ce sujet comme résolu ...
Merci encore

Votre modèle de toute façon est faux. Langue devrait être une entité.

A +

Bonjour et bonne année pour commencer.

Je suis preneur de toute remarque dès lors qu'elle me permet d'avancer et de mieux appréhender les choses...
Je prends note que "lang" devrait être une entité. Ce qui semble évident à priori.

Sauf erreur de ma part, il me semble que c'est déjà une entité sur le dernier MCD ...
Ou alors quelque chose m'a vraiment échappé dans la définition d'entité.

Sur les cardinalités, sur mes relations ou encore sur mes règles de gestion, je ne doute pas une seconde qu'il y ait une collection d'erreurs qui méritent de rentrer dans un best of de ce qu'il ne faut pas faire.
Comme vous vous en apercevez, je me lance avec persévérance et sans peur du ridicule dans la conception de BDD.

Merci pour votre réponse. Je prends note de vos remarques pour enrichir mon expérience...
Bien cordialement