Petite Question Modélisation [Résolu]

[TiEuM]

Bonjour,
j'ai tjrs été tracassé par ce problème alors je vous demande votre avis

Regardez cet exemple simple de SI :

Un employé fait partie de 0 ou 1 société. Une société a 1 à n employés.

Merise nous donne le modèle physique suivant :


Mais dans le cas où un employé n'a PAS de société, vous mettez une valeur null dans le champ id_societe de la table employe ?
Dans ce cas il n'y a plus d'intégrité référentielle, si ?
Et puis c'est un peu chiant à gérer, non ?
Ne vaudrait-il pas mieux faire une table de liaison ?

Merci bcp pour vos réponses !

[pinocchio]

Que ce soit chiant est une chose mais ca doit passer après.
Pour l'intégrité référentiel, y'a pas de souci.
Pour les liasons, ce sera un left join ou right join (ce qui alourdit un peu le temps d'éxcution).
Avec une table de liaison tu casses complétement ton schéma. Un employé peut avoir plusieurs sociétés (c'est pas forcément faux d'ailleurs) ce que tu ne désires pas. Ca te fait donc rajouter des contrôles.
NULL est une valeur à part entière.
Bon courage

[TiEuM]

Ok merci beaucoup Pinocchio ...
Je voulais surtout cette confirmation que c'est bien la méthode répandue d'utiliser null dans ce cas
Parce que c'est jamais précisé dans les tutos merise par exemple

[al1_24]

Dans la pratique, on utilise souvent un identifiant "poubelle" (non défini, 9999, ...) dans la table de référence.
L'avantage est qu'on évite les jointures externes, et donc on diminue la charge système.
En plus, on évite de "perdre" des enregistrements si, par inadvertance, on utilise un INNER JOIN à la place du OUTER JOIN (outils de consultation mis à la disposition des utilisateurs...)

[izioto]

Envoyé par TiEuM

Un employé fait partie de 0 ou 1 société. Une société a 1 à n employés.

Juste une remarque, même si ce n'est pas le vrai problème :
On ne peut pas être employé d'aucune société ... car sinon on a aucune raison d'être dans la table EMPLOYE.

Dans le cas contraire (si on supose que l'on peut être employé d'aucune société), une société devrait alors pouvoir aussi avoir 0 employé !!

je dis des bêtises ?

izioto

[TiEuM]

peu importe c'était juste pour avoir un exemple de cardinalité 0:n

al1_24 merci mais d'un point de vue logique je préfère la valeur null à l'identifiant poubelle

[zigwen]

Salut,

le souci du NULL c'est que tu vas devoir faire des jointures externes à chaque requetes ce qui est tres penible. Il vaut vraiment mieux avoir un code à la noix (XXX) avec un libellé associé (Non défini) comme le dit al1_24 !

En plus :
- si ton volume augmente, les jointures externes seront tres penalisantes.
- si qq un d'autre que toi fait une requete, il n'y pensera pas forcément et "ratera" des enregistrements.

@+.

[pinocchio]

Je ne suis pas d'accord du tout.
La valeur NULL est une valeur qui exprime le cas souhaité.
La valeur xxx est une valeur poubelle et elle porte bien son nom!!!

[SQLpro]

A Al1_24 :
Au sujet de l'évitement des NULL :

Dans la pratique, on utilise souvent un identifiant "poubelle" (non défini, 9999, ...) dans la table de référence.

C'est une imbécilité gravissime...

Un petit exemple de cette stupidité debile :

dans le schéma précédent, calculer le nbre d'employés qui ne relève pas d'une société définie...

Code :

1
2
3
SELECT COUNT(*)
FROM   EMPLOYE
WHERE  ID_SOCIETE = monCodeALaCon

Dans les 9/10° des cac, celui qui va faire la requête obliera le WHERE ou le code à la con. Alors que c'est si simple de faire intelligemment avec les marqueurs NULL :

Code :

1
2
SELECT COUNT(ID_SOCIETE)
FROM   EMPLOYE

Et plus performant !


A Pinocchio :

NULL est une valeur à part entière.

Non, c'est justement l'absence de valeur.
A lire sur les erreurs SQL et notamment sur le NULL : http://sqlpro.developpez.com/cours/sqlaz/erreurs/#L3
Il est navrant de trouver dans les forums des réponses aussi nulles !!!

Au sujet des marqueurs NUL :
http://sqlpro.developpez.com/cours/null/

A +