Problème de relations et on delete

Bonjour,
Admettons le schéma suivant :
http://www.icam.ch/upload/dncnet/schema.jpg
Entre Table1 et Table2 la relation indique "on delete cascade"
Entre Table1 et Table3 la relation indique "on delete cascade"
Entre Table3 et Table2 la relation indique "on delete set NULL"

En ben ça, mssql ne le tolère pas. Apparemment il considère que si on supprime un item de Table1, les ligne correspondantes à Table3 dans Table2 ne pourront plus être mises à jour (NULL sur IDTable3) par la suppression des items dans Table3 via la contrainte entre Table1 et Table3.

J'ai réalisé exactement le même schéma sur MySql et là, c'est OK.
Il me semblerais qu'une contrainte delete cascade soit prioritaire sur une contrainte delete set null.
D'autre part, si l'on supprime un item de Table1, tant les items correspondants dans Table3 que ceux dans Table2 disparaitront. Donc la contrainte delete set null devient caduque dans ce cas...

Qu'est-ce que vous en pensez ???

Ou alors, c'est tellement gros que je n'y vois plus rien...

Bonne journée

Bonjour,

Je me suis simplement arrêté sur le schéma (physique au passage) avant de lire la suite : ne pensez-vous pas qu'il y a un problème ?

Citation:

---

En ben ça, mssql ne le tolère pas. Apparemment il considère que si on supprime un item de Table1, les ligne correspondantes à Table3 dans Table2 ne pourront plus être mises à jour (NULL sur IDTable3) par la suppression des items dans Table3 via la contrainte entre Table1 et Table3.

---

Normal. Cela s'appelle l'intégrité référentielle. C'est ce que vous avez demandé.

Citation:

---

J'ai réalisé exactement le même schéma sur MySql et là, c'est OK.

---

Ben c'est du propre :D

Citation:

---

Il me semblerais qu'une contrainte delete cascade soit prioritaire sur une contrainte delete set null.

---

Les contraintes n'ont pas de priorité.
ça sort de MySQL ça aussi ?

Citation:

---

D'autre part, si l'on supprime un item de Table1, tant les items correspondants dans Table3 que ceux dans Table2 disparaitront. Donc la contrainte delete set null devient caduque dans ce cas...

---

Normal aussi.

Citation:

---

Qu'est-ce que vous en pensez ???

---

Que votre modèle est faux, et que cela ne me donne pas envie de bosser avec MySQL :D

@++ ;)

Citation:

---

Citation:
D'autre part, si l'on supprime un item de Table1, tant les items correspondants dans Table3 que ceux dans Table2 disparaitront. Donc la contrainte delete set null devient caduque dans ce cas...

Normal aussi.

---

Alors justement, la contrainte entre Table3 et Table2 doit être possible...

Citation:

---

Que votre modèle est faux,

---

Ça je veux bien mais ça ne fait pas avancer mon schmilblick...

Donc je m'explique quant au schéma...

Table1 = des entreprises
Table2 = des collaborateurs
Table3 = des bureaux
Les collaborateurs peuvent avoir ou ne pas avoir de bureau.
Si je supprime un bureau, tous les collaborateurs de se bureau n'en ont plus. Ils bossent à la maison par exemple. Donc collaborateur.bureau = null
Si je supprime une entreprise, tous les collaborateurs disparaissent. Tous les bureaux également.

Alors, comment puis-je représenter cela autrement que par le schéma ci-dessus ?

Re bonjour elsuket,
Est-ce que ma vision des choses est complètement fausse ?

Non, elle me semble correcte.
Par contre votre modèle n'implémente pas cela.
Il ne devrait pas y avoir autant de relations.

Donc :

- soit vous considérez que les bureaux appartiennent à l'entreprise, et qu'un collaborateur est affecté à un bureau
- soit vous considérez qu'un bureau est affecté à un employé, et qu'un employé est employé par l'entreprise.

Quelle est l'assertion qui répond exactement à votre besoin ?

@++ ;)

Dans mon cas ce serait :
les bureaux appartiennent à l'entreprise, et un collaborateur est affecté à un bureau

Mais un collaborateur peut très bien n'être affecté à aucun bureau donc :
collaborateur.bureau = null

Je peux très bien ajouter un bureau, y affecter des collaborateurs.
Je peux aussi supprimer un bureau. Dans ce cas tous les collaborateurs affectés à ce bureau n'ont plus de bureau mais, par contre, ils font toujours partie de l'entreprise...

Ca, c'est l'exemple simplifié de mon problème.

En réalité, j'ai un affichage d'une entreprise. Soit :
- une entreprise qui possède des ateliers
- des ateliers qui possèdent des machines
Ce schéma là est la représentation physique de la réalité. Donc une machine ne peut pas exister si elle ne fait pas partie d'un atelier. Jusque ici, pas de problème.

Maintenant, sur l'interface de l'application, l'utilisateur peut créer sa propre structure d'entreprise pour ranger ces machines par groupes et ce de manière totalement libre.

Donc :
- une machine peut appartenir à un groupe ou non. -> machine.groupe = groupe ou NULL
- un groupe fait par contre forcément partie d'une entreprise

Alors :
- si je supprime l'entreprise, je supprime par contrainte les atelier et les machines d'un côté, les groupes de l'autre.
- si je supprime un groupe, je dois forcément mettre les références à ce groupe dans les machine à NULL...

Bon, ben tant pis.
Je me mets sur mysql.... Là au moins ça fonctionne

ça fonctionne mais c'est conceptuellement faux.
Désolé je n'ai pas eu le temps de me mettre dessus.

@++ ;)

Bonjour,

Citation:

---

Envoyé par ppphil

Dans mon cas ce serait :
les bureaux appartiennent à l'entreprise, et un collaborateur est affecté à un bureau

Mais un collaborateur peut très bien n'être affecté à aucun bureau donc :
collaborateur.bureau = null

---

Lorsque l'on utilise un SGBDR, on évite NULL.

D'après ce que j'ai compris si on remonte au niveau du MCD Merisien, vous avez quelque chose qui ressemble à ceci:

Entreprise -0,N------(situer)-------1,1- Bureau
Collaborateur -0,1---(affecter)----0,N- Bureau

La cardinalité 0,1 du collaborateur, entraine la création du table "de jointure" au niveau du MLD.

La structure des tables (clés primaires soulignées, clés étrangères en italique):

Entreprise(ent_id, ent_nom)
Bureau(bur_id, bur_nom, ent_id)
Collaborateur(col_id, col_nom)
Affecter(col_id, bur_id)

Lorsqu'un Collaborateur est affecté à un Bureau, il y a une ligne dans la table Affecter. Là, vous pouvez faire tout ce que vous voulez.

Si vous aviez utilisé un outil de conception de schéma de bases de données relationnelle comme Power AMC par exemple il vous aurait immédiatement trouvé une erreur dite de cycle dans le modèle conceptuel !
Vous n'auriez pas pu monter un tel modèle au niveau conceptuel car il est faux.

Le fait que MySQL permettent de telles imbécilités est la preuve que l'on est pas un face d'un SGBDR un tant soit peu sérieux... les défauts de MySQL sont si nombreux, qu'il est difficile de parler de SGBDR, mais plutôt de gestionnaire de fichier à la sauce SQL !

Commencez par apprendre la modélisation de données avec la notation de votre choix : Merise, UML2, E/R, IDEF1X...

A +

Merci beaucoup Oishiiii !
J'avais le nez trop près du guidon...
Bonne fin de journée !!

Lorsque l'on utilise un SGBDR, on évite NULL.

D'après ce que j'ai compris si on remonte au niveau du MCD Merisien, vous avez quelque chose qui ressemble à ceci:

Entreprise -0,N------(situer)-------1,1- Bureau
Collaborateur -0,1---(affecter)----0,N- Bureau

La cardinalité 0,1 du collaborateur, entraine la création du table "de jointure" au niveau du MLD.

La structure des tables (clés primaires soulignées, clés étrangères en italique):

Entreprise(ent_id, ent_nom)
Bureau(bur_id, bur_nom, ent_id)
Collaborateur(col_id, col_nom)
Affecter(col_id, bur_id)

Lorsqu'un Collaborateur est affecté à un Bureau, il y a une ligne dans la table Affecter. Là, vous pouvez faire tout ce que vous voulez.[/QUOTE]



Ce qui implique que toute clé étrangère "nullable" nécessite une table de liens...

En dehors de la lisibilité des modèles, forcément amoindrie, et des requêtes SQL, artificiellement complexifiées, quels sont les autres avantages de cette table Affecter : performances, ... ?

En outre, comment lister tous les employés, qu'ils aient un bureau ou non ?

Finalement, serais-je trop laxiste en termes de dénormalisation ?

Citation:

---

Envoyé par lespaul

Ce qui implique que toute clé étrangère "nullable" nécessite une table de liens...

---

Oui, c'est ce qui se passe lorsqu'on applique c'est méthode de décomposition pour éviter NULL.

Citation:

---

Envoyé par lespaul

En dehors de la lisibilité des modèles, forcément amoindrie, et des requêtes SQL, artificiellement complexifiées, quels sont les autres avantages de cette table Affecter : performances, ... ?

---

Qu'appelez-vous la "lisibilité des modèles" ?
Je ne vois pas en quoi les requêtes SQL seraient "complexifiées" (lesquelles et par rapport à quoi?).
Si une requête SELECT vous semble trop "complexe" vous pouvez toujours en faire une vue.
Quant aux performances, je ne pourrais rien affirmer car je n'ai pas le temps de prouver quoi que ce soit mais j'imagine bien que les optimiseurs de nos SGBDs se passeraient bien volontier de ces NULL…
Evitons les affirmations ou les sous-entendus basés uniquement sur des a priori.

Citation:

---

Envoyé par lespaul

En outre, comment lister tous les employés, qu'ils aient un bureau ou non ?

---

Les employés, ou collaborateurs ici sont à leur place dans la table Collaborateur, qu'ils aient un bureau ou non. Un simple SELECT devrait suffire:

Code:

---

SELECT col_id, col_nom FROM Collaborateur;

---

Citation:

---

Envoyé par lespaul

Finalement, serais-je trop laxiste en termes de dénormalisation ?

---

Je ne pense pas qu'il soit possible d'être laxiste en dénormalisation puisqu'en effet celle-ci ne suit aucune règle contrairement au processus de normalisation.

Dans le monde réel, il est tout a fait possible de réaliser une BDD ne comportant aucun NULL et cela ne pose aucun soucis, sauf psychologiques pour certains face à un nombre de table relativement important, mais les vues sont la pour simplifier la vie des utilisateurs.

Le langage SQL permet de faire tout et n'importe quoi, à chacun d'en faire ce qu'il veux.
J'essaye de respecter la théorie relationnelle et donc j'évite NULL qui bien sûr n'en fait pas parti.

Les problèmes des NULLs et de la 3VL ainsi que la gestion de l'information manquante ont largement étaient étudiés.
Voyez par exemple le dernier ouvrage de Date et Darwen à ce sujet: Database Explorations