problème avec des tables

Salut !

Pachot, mon argument contre les NULL ici, c'est que ça tue les statistiques.

Le CBO prend pour hypothèse que les colonnes sont indépendantes : puisqu'il multiplie les sélectivités des prédicats en conjonctions sans termes correctif.

On est d'accord ?

Si oui, le fait qu'un certain nombre de colonnes soient NULL en fonction d'une autre colonne risque vraiment de poser problème.
Bien sûr, l'hypothèse d'indépendance peut être fausse même lorsque le modèle est totalement relationnel normé... mais ici, on force l'erreur !

Salut Franck,

Il n'y rien de spécial sur le sujet dans le livre de Stéphane Faroult, j'avais cherché un lien qui devrait (te) permettre de consulter on-line le sujet. De plus je pense que tu connais ces arguments:

• non respecte de la normalisation: la valeur (y compris le manque de valeur qui est le nul) de la zone téléphone dépende en plus de la clé de la zone type entité: client_type dans ta proposition
• la table qui résulte à plus des colonnes que nécessaires; en pratique souvent on rencontre plus de deux sous types et chaque sous type a ses propres colonnes et ses propre règles de gestion: il en résulte des tables à trous comme l'emmenthal.
• certains requêtes sont obliger de lire plus de enregistrement que nécessaire seulement pour les éliminer. Exemple: trouver tous les numéros de téléphone des personnes morales
• ce type de règles finit souvent par se retrouver dans le code en compliquant le développement et la maintenance: «*à, mince, parce que c'est une personne physique le numéro de téléphone est nul si non peut être que c'est fourni*» à la place d'une erreur de compilation quand on essaie de chercher un attribut qui n'existe pas pour l'entité.
• En fin de compte il ne s'agit pas d'éliminer le nul mais simplement de ne le pas introduire là où il n'est pas forcement nécessaire.

Il ne s'agit pas d'une dogme, des exceptions peuvent bien exister. Si la théorie est la pour te servir commence par la suivre et ensuite prends tes libertés quand c'est profitable. Mais ce n'est pas «parce que ça se fait y compris chez le grands» qu'il faut aller toujours sur ce chemin.

Cordialement,
Marius

Citation:

---

Envoyé par pachot

Y a-t-il des colonnes dont les valeurs sont déterminées par des attributs non clés ? Je n'en vois pas -> 3NF

---

Si la nullité d'une colonne donne une signification particulière à l'enregistrement (si SIRET NULL alors c'est un particulier) alors tu violes bien la 3NF ;)

Citation:

---

Envoyé par pachot

Est-ce qu'on aura
- personne_physique_adresse_simple_homme _ou_jeune_fille
- personne_physique_adresse_2lignes_homme _ou_jeune_fille
- personne_physique_adresse_simple_femme mariée
- personne_physique_adresse_2lignes_femme mariée
- personne_morale_fisc_francais
- personne_morale_fisc_italien
-...

---

En réalité tu ferais surtout une table adresse qui pour chaque personne contiendra 1 ou n lignes d'adresse ;)