Salut à tous,
Avez-vous déjà eu à mettre en place une relation de type 0,1 - 1,1 ?
En gros j'ai une table "dossier" et une table "grille".
Avec dans dossier, un champ grille_id et dans grille un champ dossier_id.
Une grille n'est définit que pour un dossier et un dossier n'a qu'une grille, le problème c'est que ça me génère (via Symfony2) une "relation croisée" et il m'est ensuite impossible de supprimer l'une de ces tables puisque lié par la seconde.
Ca me parait bizarre...
la communauté d'entraide francophone dédiée au PHP
Modélisation relation 0,1 - 1,1
Il faut créer une table relationnelle entre les deux et virer les clés étrangère de tes tables grille et dossier : pour la suppression dans ce cas, tu fais d'abord sauter la ligne dans la table relationnelle sans soucis et la ligne d'une des deux autres tables si nécessaire.
Edit :
quoique... en principe pour une relation 0:1 - 1:1, tu ne devrais pas avoir besoin de plus qu'une clé étrangère facultative dans la table du coté du 0:1
Edit :
quoique... en principe pour une relation 0:1 - 1:1, tu ne devrais pas avoir besoin de plus qu'une clé étrangère facultative dans la table du coté du 0:1
Codez en pensant que celui qui maintiendra votre code est un psychopathe qui connait votre adresse 
Tu as un bout de mcd qui va avec ça ?
Parce que bon tu affaire devrais seulement faire un fk dans la table grille (semble être un sous ensemble de dossier tel que tu le décris). Soit un soucis dans la génération des tables soit le modèle est bancale
@+
Parce que bon tu affaire devrais seulement faire un fk dans la table grille (semble être un sous ensemble de dossier tel que tu le décris). Soit un soucis dans la génération des tables soit le modèle est bancale
@+
Il en faut peu pour être heureux ......
En gros ce que je cherche à faire:Tu as un bout de mcd qui va avec ça ?
Parce que bon tu affaire devrais seulement faire un fk dans la table grille (semble être un sous ensemble de dossier tel que tu le décris). Soit un soucis dans la génération des tables soit le modèle est bancale
@+
- j'ai une bibliothèque de rubriques pour un dossier
- une rubrique est de type élément ou évènement
- un collaborateur construit une grille pour un dossier à partir de ces rubriques + définir sa configuration
- un collaborateur ouvre une saisie à partir d'une grille
- un client saisies les rubriques définit par la grille en fonction des options définit
Et effectivement, une grille est un sous ensemble de dossier puisque l'un sans l'autre ne doit pas exister.
Je vais simplement supprimer ma table grille :p et faire mes liaisons sur la table dossier.
J'ai pas ce qu'il faut sous la main pour un beau dessin, mais si grille est un ensemble cohérent ce n'est pas un problème
Ici la grille c'est la relation 1 dossier n rubrique ce qui me faire que tu a une relation 1,n - 0,n entre dossiers et rubrique et que cette relation s'appelle grille. Au final cette relation sera une table.
Après la gestion de l'unicité je vois pas la (pas assez d'info et encore dans le gaz ).
Au pire si c'est immuable une procédure avec transaction pour insertion dans grille de toute les rubriques au début tu test si le numéro de dossier est déjà présent si oui rollback si non tu insère les rubriques.
edit :
ça pourrait ressembler à sa ton mcd (grosso modo) au final ?
@+
Ici la grille c'est la relation 1 dossier n rubrique ce qui me faire que tu a une relation 1,n - 0,n entre dossiers et rubrique et que cette relation s'appelle grille. Au final cette relation sera une table.
Après la gestion de l'unicité je vois pas la (pas assez d'info et encore dans le gaz
). Au pire si c'est immuable une procédure avec transaction pour insertion dans grille de toute les rubriques au début tu test si le numéro de dossier est déjà présent si oui rollback si non tu insère les rubriques.
edit :
ça pourrait ressembler à sa ton mcd (grosso modo) au final ?
@+
Modifié en dernier par moogli le 22 nov. 2011, 09:56, modifié 2 fois.
Il en faut peu pour être heureux ......
Après quelques modifications, voilà mon MCD
http://imageshack.us/photo/my-images/507/mcdyosh.gif/
Mon seul soucis est de savoir comment je vais gérer mes rubriques, il me faut un référentiel de toutes les rubriques d'un dossier + une table stockant les rubriques sélectionner pour la construction de la grille (est-ce que c'est clair?).
En gros il me faut deux tables rubriques, le référentiel et la sélection.
La relation ternaire vous semble correcte ?
Les tables saisie_salarie et saisie_rubrique stockent respectivement les salariés et les rubriques de la saisies.
Et donc une saisie contient n couple(s) de salarie / rubrique + une valeur.
EDIT:
http://imageshack.us/photo/my-images/269/mcdyosh.gif/
MCD avec le référentiel des rubriques
EDIT 2:
Pour la relation ternaire, en toute logique cela devrait donner ça ?
http://imageshack.us/photo/my-images/196/mcdyosh.gif/
http://imageshack.us/photo/my-images/507/mcdyosh.gif/
Mon seul soucis est de savoir comment je vais gérer mes rubriques, il me faut un référentiel de toutes les rubriques d'un dossier + une table stockant les rubriques sélectionner pour la construction de la grille (est-ce que c'est clair?).
En gros il me faut deux tables rubriques, le référentiel et la sélection.
La relation ternaire vous semble correcte ?
Les tables saisie_salarie et saisie_rubrique stockent respectivement les salariés et les rubriques de la saisies.
Et donc une saisie contient n couple(s) de salarie / rubrique + une valeur.
EDIT:
http://imageshack.us/photo/my-images/269/mcdyosh.gif/
MCD avec le référentiel des rubriques
EDIT 2:
Pour la relation ternaire, en toute logique cela devrait donner ça ?
http://imageshack.us/photo/my-images/196/mcdyosh.gif/
fiou c'est un brin la :/
coté rubrique, la boucle entre referentiel, dossier et rubrique dossier y a un lien de trop je pense, d'ailleurs je ne vois pas l'intérêt de rubrique_dossier c'est de la redondance d'information
collaborateur == salarie ?
les infos de saisie peuvent tres bien être dans dossier (puisse qu'a priori il s'agit de l'année et du mois de saisie du dossier ?)
dossier_salarie, c'est étonnant l'id du salarie devrait être dans dossier, a moins qu'un dossier ne concerne plusieurs salarie bien entendu.
Je ne comprend trop la partie saisie au final tu balade des clef primaire / étrangère qui sont incompréhensible parce que l'outil les nomment automatiquement et qu'au final on ne sais plus a quoi elles servent
je vois ton truc plus ainsi
en imaginant que saisie sert a "logguer" les saisies utilisateurs, dans ce cas je pourrais comprendre la date dans saisies (que je n'ai pas mis dans le modèle)
Ici appartenir est une relation, je suis partis du principe qu'un salarié n'a qu'un seul dossier, si un salarié peux avoir plusieurs ou si un dossier concernent plusieurs salarié (voir les deux) dans ce cas les cardinalités change (0,n) et appartenir sera une table.
saisies contiendra des clefs étrangère sur salries, dossiers, referentiels et type saisie. j'imagine des type saisis comme création, modification etc
le modèle est bancale, car cela voudrais dire que l'on aurais une seule des trois case renseignées.
le mieux serait un truc moins normalisé, qui prend un champ "clef", un type et un lien table (un table qui liste les tables sur lesquelles on log les saisies.
ça ferais deux bloques séparés c'est moyen.
bon ceci dit je m'égare surement de ce que toi tu veux faire
mais sur le principe c'est ça il faut virer les relations circulaires et surement repenser ton modèle
@+
coté rubrique, la boucle entre referentiel, dossier et rubrique dossier y a un lien de trop je pense, d'ailleurs je ne vois pas l'intérêt de rubrique_dossier c'est de la redondance d'information
collaborateur == salarie ?
les infos de saisie peuvent tres bien être dans dossier (puisse qu'a priori il s'agit de l'année et du mois de saisie du dossier ?)
dossier_salarie, c'est étonnant l'id du salarie devrait être dans dossier, a moins qu'un dossier ne concerne plusieurs salarie bien entendu.
Je ne comprend trop la partie saisie au final tu balade des clef primaire / étrangère qui sont incompréhensible parce que l'outil les nomment automatiquement et qu'au final on ne sais plus a quoi elles servent
je vois ton truc plus ainsi
en imaginant que saisie sert a "logguer" les saisies utilisateurs, dans ce cas je pourrais comprendre la date dans saisies (que je n'ai pas mis dans le modèle)
Ici appartenir est une relation, je suis partis du principe qu'un salarié n'a qu'un seul dossier, si un salarié peux avoir plusieurs ou si un dossier concernent plusieurs salarié (voir les deux) dans ce cas les cardinalités change (0,n) et appartenir sera une table.
saisies contiendra des clefs étrangère sur salries, dossiers, referentiels et type saisie. j'imagine des type saisis comme création, modification etc
le modèle est bancale, car cela voudrais dire que l'on aurais une seule des trois case renseignées.
le mieux serait un truc moins normalisé, qui prend un champ "clef", un type et un lien table (un table qui liste les tables sur lesquelles on log les saisies.
ça ferais deux bloques séparés c'est moyen.
bon ceci dit je m'égare surement de ce que toi tu veux faire
mais sur le principe c'est ça il faut virer les relations circulaires et surement repenser ton modèle
@+
Il en faut peu pour être heureux ......
C'est pas évident sans cahier des charges...fiou c'est un brin la :/
Je mouline un peu mais je préfère passer plus de temps sur mon MCD pour qu'il soit flexible...
Je vais modifier deux trois trucs et je repasse plus tard.
Sinon dans ton modèle, liés les rubriques au dossier ne suffit pas...il me faut une table stockant les rubriques sélectionné dans le référentiel, c'est pour ça que j'avais la table rubrique_dossier (une table référentiel pour les 90000 rubriques et une table rubrique_dossier qui stocke les quelques rubriques à saisir par le client, et lorsque qu'un collaborateur va ouvrir une saisie je déporte les rubriques de la table rubrique_dossier dans la table saisie_rubrique - en gros -).
De plus de mon point de vue, une saisie doit être historisé (d’où l'année et le mois) et les valeurs saisies dépendent du couple saisie-rubrique-salarié
Bon, je m'arrache la tête, voila un peu plus d'infos.
Le but de l'application est le suivant.
On a deux types de personnes, les collaborateurs et les clients.
=> table collab + table client
Toutes les nuits un cron va alimenter les dossiers, le référentiel de rubriques et les salariés.
=> table dossier + table référentiel (renommer en rubrique) + table salarie
Un collaborateur défini quels sont les rubriques à renseigner (en les recherchant dans le référentiel) ainsi que leur configuration (d'où ma table dossier_rubriques puisque celle-ci va contenir les champs de configuration, tel que indice, type_calcul, etc...).
=> table dossier_rubrique
Une fois par mois, le collaborateur va ouvrir une nouvelle saisie pour un dossier en renseignant l'année et le mois de la saisie, cette saisie doit référencer les rubriques selectionnées ( = les colonnes ) et les salariés du dossier ( = les lignes ).
=> table saisie + table saisie_rubrique (clone des données de dossier_rubrique avec la config) + table saisie_salarie (alimenter avec les salariés courant du dossier)
Une fois la saisie ouverte le client va saisir les données des rubriques pour chaque salariés.
=> table donnee
La saisie est fermé par le client lorsqu'il a fini.
Le collaborateur télécharge un fichier .txt contenant toutes les données (avec un formatage spécial mais là n'est pas le problème).
En fonction du type de rubrique les valeurs à saisir ne sont pas les mêmes.
Le système doit pouvoir historiser les saisies et être capable de rendre en affichage une saisie passées.
Le système doit pouvoir logués toutes les modifications apportés sur les valeurs saisies.
je n'ai pas encore intégrer le système de logs, les collab et les clients mais j'en suis au MCD suivant et pour moi tout est ok sauf la table saisie_rubrique_salarie (qui est une relation de type n,m sur des relations de type n,m :$, du coup j'ai ajouter un id autoincrement en guise de PK)
EDIT: tu peux déplacer ce post dans la partie Méthodologie, modélisation, sécurité, merci.
EDIT2: maj du MCD
Le but de l'application est le suivant.
On a deux types de personnes, les collaborateurs et les clients.
=> table collab + table client
Toutes les nuits un cron va alimenter les dossiers, le référentiel de rubriques et les salariés.
=> table dossier + table référentiel (renommer en rubrique) + table salarie
Un collaborateur défini quels sont les rubriques à renseigner (en les recherchant dans le référentiel) ainsi que leur configuration (d'où ma table dossier_rubriques puisque celle-ci va contenir les champs de configuration, tel que indice, type_calcul, etc...).
=> table dossier_rubrique
Une fois par mois, le collaborateur va ouvrir une nouvelle saisie pour un dossier en renseignant l'année et le mois de la saisie, cette saisie doit référencer les rubriques selectionnées ( = les colonnes ) et les salariés du dossier ( = les lignes ).
=> table saisie + table saisie_rubrique (clone des données de dossier_rubrique avec la config) + table saisie_salarie (alimenter avec les salariés courant du dossier)
Une fois la saisie ouverte le client va saisir les données des rubriques pour chaque salariés.
=> table donnee
La saisie est fermé par le client lorsqu'il a fini.
Le collaborateur télécharge un fichier .txt contenant toutes les données (avec un formatage spécial mais là n'est pas le problème).
En fonction du type de rubrique les valeurs à saisir ne sont pas les mêmes.
Le système doit pouvoir historiser les saisies et être capable de rendre en affichage une saisie passées.
Le système doit pouvoir logués toutes les modifications apportés sur les valeurs saisies.
je n'ai pas encore intégrer le système de logs, les collab et les clients mais j'en suis au MCD suivant et pour moi tout est ok sauf la table saisie_rubrique_salarie (qui est une relation de type n,m sur des relations de type n,m :$, du coup j'ai ajouter un id autoincrement en guise de PK)
EDIT: tu peux déplacer ce post dans la partie Méthodologie, modélisation, sécurité, merci.
EDIT2: maj du MCD