Discussion :

[kaibaa]

salut tout le monde,

j'ai crée 3 table:
la table personnePhysique,
la table personneMorale,
et la table contrat
voici le code:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
CREATE TABLE PERSONNEPHISYQUE (
 CODE NUMBER(38) NOT NULL,
 NOM VARCHAR2(20),
 PRENOM VARCHAR2(20),
 NUMTEL NUMBER(14),
 ADRESSE VARCHAR2(50),
 PRIMARY KEY (CODE));

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
CREATE TABLE PERSONNEMORALE (
CODEFISCAL NUMBER(38) NOT NULL,
 RAISONSOC VARCHAR2(50),
 PRIMARY KEY (CODEFISCAL));

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
CREATE TABLE CONTRAT (
NUMCONTRAT NUMBER(38),
NUMVEHICULE NUMBER(38), 
ETATNEUF NUMBER(38),
CODECLIENT NUMBER(38));

mon problème est que je veut vérifier que le CODECLIENT de la table CONTRAT est soit un CODEFISCAL(d'une société par exemple) dans PERSONNEMORALE soit un CODE(d'une personne) dans PERSONNEPHYSIQUE,
comment je peu faire ?

[pachot]

Bonjour,

Pour ce besoin j'aurait fait une seule table 'CLIENT' avec le code (code fiscal si personne morale), un discrimnant (persone physique ou morale), et tous les champs de personne morale et de personne physique (selon le discriminant, la moitié seront null)

L'autre solution s'il est plus logique d'avoir 2 tables (si elles n'ont vraiement rien en commun), c'est d'avoir dans contrat les 2 colonnes (code personne physique et code fiscal), chacun sa foreign key, et l'un des 2 sera toujours null.
Mais dans ton cas, elles ont en commun le fait d'avoir des contrats. Il y a vraiement un seul concept métier "client". suivant son type (discriminant) il a différentes informations.

Il n'y a pas d'héritage en relationnel. Par contre il n'y a pas de probblème a avoir des colonnes null.

Cordialement,
Franck.

[mnitu]

Je suis en contradiction sur ce point avec Pachot, donc je vous propose d'organiser vos tables autrement:

Table Personne
Code Primary key
RaisonSociale (ou nom)
...

Table PersonePhysique
Code Primary key, Foreign Key fk_personnePh_personne References Personne (code)
Prenom
Tel
Adresse
...
Table Contract
NumContract primary key
…

de cette façon l'entité personne physique est un sous type de l'entité personne et votre problème disparaît ainsi le besoin de s'assurer que si un code est saisie l'autre est nul, etc.

[kaibaa]

Bonjour,

Pour ce besoin j'aurait fait une seule table 'CLIENT' avec le code (code fiscal si personne morale), un discrimnant (persone physique ou morale), et tous les champs de personne morale et de personne physique (selon le discriminant, la moitié seront null)

L'autre solution s'il est plus logique d'avoir 2 tables (si elles n'ont vraiement rien en commun), c'est d'avoir dans contrat les 2 colonnes (code personne physique et code fiscal), chacun sa foreign key, et l'un des 2 sera toujours null.
Mais dans ton cas, elles ont en commun le fait d'avoir des contrats. Il y a vraiement un seul concept métier "client". suivant son type (discriminant) il a différentes informations.

Il n'y a pas d'héritage en relationnel. Par contre il n'y a pas de probblème a avoir des colonnes null.

Cordialement,
Franck.

merci à vous Mr.pachot pour la réponse d'abord,
l'idée du discriminant me parait très logique et comme j'ai compris on insère des NULL où c'est nécessaire, mais avant d'adopter cette vision j'ai pensé à un trigger qui fait la vérification avec un trigger comme suit:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
 
create or replace trigger codeCltTR
before insert on contrat
begin
check(codeclient in(
select codefiscal from personnemorale) or 
codeclient in(
select code from personnphysique))
end codeCltTR;

que pensez vous s'il vous plait?

[kaibaa]

Je suis en contradiction sur ce point avec Pachot, donc je vous propose d'organiser vos tables autrement:

de cette façon l'entité personne physique est un sous type de l'entité personne et votre problème disparaît ainsi le besoin de s'assurer que si un code est saisie l'autre est nul, etc.

comme ca, je pense toute personnePhysique(qui signifie client normal) aura surement l'attribut RAISONSOC dans la table PERSONNE que tu a proposé mnitu, alors que je veux seulement societé (PERSONNEMORALE) dispose de l'attribut RAISONSOC

[Waldar]

Je préfère aussi la modélisation de mnitu.

Vos deux tables personnephysique et personnemorale ont deux attributs en commun, un code et un nom.

Les regrouper dans une même table personne est une bonne pratique.
Les attributs restants de personnephysique vont dans cette table-ci.

[pachot]

kaibaa,
Un trigger pour vérifier une contrainte d'intégrité, c'est jamais une bonne idée.
Il faudrait aussi vérifier qu'on ne peut pas supprimer de personnemorale ou de personnphysique s'il y a des contracts.
Il faudrait aussi poser les verrous sur les tables pour être sur qu'il n'y a pas un insert en cours...


mnitu/Waldar

J'ai proposé la solution qui me paraît la plus conforme à ton besoin:
une seule table pour tous les clients, car je pense que le concept métier principal c'est le client, et que les différents types de clients ont simplement différent types d'information (nom/prenom vs raison sociale)

Ce n'est pas forcément la meilleure modélisation. Il y a plusieurs solutions qui dépendent en premier des spécifications, puis ensuite de soucis de performances.

Mettre à part les attributs de personnes physique ne m'a pas paru adapté ici parce que une personne physique pourrait quand même avoir une adresse, un numéro de téléphone...

Par contre, kaiba, si dans le reste de ton appli la différenciation personne physique/morale est structurante (par exemple si tu as des tables importantes qui ont une foreign key sur l'un ou sur l'autre seulement) il se peut qu'il faille avoir une table pour chaque type de personne.

Et ensuite, en terme de performance, je préfère avoir quelques colonnes nulles que faire des jointures systématiques.

En vérité il y a 3 choix possibles:

- une table pour l'entité générale ( donc 1 table 'personne' )
- une table pour chaque entité spécialisée ( donc 2 tables 'personne morale' et 'personne physique' )
- une table pour chaque entité ( donc 3 tables 'personne' , 'personne morale' et 'personne physique' )

Cordialement,
Franck.

[mnitu]

Pachot,

...
Ce n'est pas forcément la meilleure modélisation.
...

La gestion des sous types dans une seule table est une solution dégradée.

...

Et ensuite, en terme de performance, je préfère avoir quelques colonnes nulles que faire des jointures systématiques.
...

C'est l'argument préféré pour justifier les solutions dégradées.

Mais, bon les applications tournent, derrière c’est vrai. Mais avec des règles de gestion plus complexes que nécessaire, voir des triggers comme celui proposé, etc.

[orafrance]

Je suis d'accord, j'ajouterai que pour simplifier les dévs une vue fera très bien l'affaire sans sacrifier la normalisation

[pachot]

Bonjour,

La règle me parait très simple, pas besoin de trigger:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
check (
-- seule une personne morale a une raison sociale
(CLIENT_TYPE<>'M' and RAISONSOC is null)
or
-- seule une personne physique a un nom,prenom,adresse et telephone
(CLIENT_TYPE<>'P' and NOM is null and PRENOM is null NUMTEL is null and ADRESSE is null)
)

C'est directement une règle métier qui est implémentée en relationnel.
Je ne vois pas en quoi c'est une solution dégradée.

Ensuite, rien n'empêche d'avoir une vue logique de tout ça avec des vues
- vue PERSONNE avec uniquement les colonnes communes
- vue PERSONNE_MORALE
- vue PERSONNE_PHYSIQUE

ce qui permet éventuellement de ne faire des grants que pour un type particulier.

Mais comme je le disais, ce n'est qu'une solution parmi d'autres. Il n'y a rien de systématique:

• Je n'irai pas mettre toute ma base de donnée dans une seule table sous le prétexte que ce sont toutes des types différents de données .
• Mais je n'irai pas non plus faire une table PERSONNE_PHYSIQUE_HOMME et PERSONNE_PHYSIQUE_HOMME sous pretexte que le nom de jeune fille sera null pour les hommes

En fait, je vais surtout regarder les association avec les autres concepts métier principaux.

Cordialement,
Franck.

[orafrance]

si fonctionnellement on différencie personne morale et physique alors il n'y a pas de raison de les rassembler techniquement... selon moi

[pachot]

Bonjour,

si fonctionnellement on différencie personne morale et physique alors il n'y a pas de raison de les rassembler techniquement... selon moi

Mais justement ici, elles sont rassemblées fonctionellement: elle ne portent pas nécessairement les mêmes informations, mais elles ont le même comportement vis à vis de contrat.

En fait, je ne ragarde pas vraiement les attributs portés par chaque entité. Des vues permettent d'avoir la vue logique dans tous les cas.

Par contre, ce sont les associations qui sont importantes car on ne peut pas avoir une foreign key vers une vue.
Donc, vu qu'on a une foreign key vers une personne, quelle que soit sont type, je trouve logique d'avoir une seule table en face.

Bref, pour moi, la question métier à se poser est:
personnes physique et morale ont elle un comportement identique dans le systeme ou non ?

Je pense que les points de vu différents viennent du fait qu'on ne connait pas le reste de l'appli. Il faudrait voir s'il y a d'autres table qui auraient une foreign key sur personne_physique seulement ou sur personne_morale seulement. Genre, comme le contrat parle de véhicule, s'il y avait la notion de conducteur (obligatoirement une personne physique).

Cordialement,
Franck.

[orafrance]

en effet, c'est pour ça que je précise bien "si fonctionnellement on différencie" Ceci étant, j'vois mal la volumétrie, les régles de gestion et le reporting être le même selon le cas

[mnitu]

Bonjour,

La règle me parait très simple, pas besoin de trigger:
...
C'est directement une règle métier qui est implémentée en relationnel.
Je ne vois pas en quoi c'est une solution dégradée.
...

Bonjour Franck,

Les modèles de genre si type est ceci alors ces colonnes sont vides et si le type et cela ces autres colonnes sont vides etc. ne sont pas une solution correcte :

To Be or Not to Be, Or to Be Null…
In any case, a sure sign that a database design is flawed is when columns of some prominent tables mostly contain null values, and especially when two columns cannot possibly contain a value at the same time ; if one is defined, the other must be null, and vice versa. This condition would undoubtedly indicate a violation of eitre 2NF or 3NF.
…

The Art Of SQL Feuilletez le premier chapitre "Laying plans" page 11.

Cordialement,
Marius

[Matzke.claudio]

petite remarque en passant

si fonctionnellement on différencie personne morale et physique alors il n'y a pas de raison de les rassembler techniquement... selon moi

je suis sur la fond d'accord, mais d'expérience sur les bases du progiciel Siebel, c'est très souvent le cas.

On distingue souvent un objet métier d'un autre (approchant mais bien distinct) en flaggant l'enregistrement avec une colonne.

Exemple: société, établissement, consortium sont modélisés dans la même table.

Idem pour des offres marketing de haut niveau qui sont dans la même table que des services commerciaux de base.

[mnitu]

Oui, dans la pratique il n'est pas interdite d'utiliser un tournevis comme un marteau. Et parfois ça marche.

[pachot]

Marius,

L'utilisation des NULL en relationnel, on peut la discuter. Mais i'implementation actuelle faite par les SGBD relationnels actuels est peut-être différente de la théorie.
Ici je parle d'une solution efficace sur Oracle à un conept métier précis.

Je n'ai pas lu 'The Art of SQL'. Il y a peut-être une explication qui est donnée à ce que tu cites. Moi j'ai proposé une solution à un problème précis, et j'en ai donné l'explication.
Quel est le problème à avoir des colonnes nulles ? Y a-t-il un problème de maintenabilité ? de performance ? de cohérence ? Moi je n'en vois pas dans ce cas.
Il y en a peut-être et ce serait utile de les donner à l'auter de ce post.

Si tu as le livre, je serais interessé de connaitre les raisons de:

In any case, a sure sign that a database design is flawed is when columns of some prominent tables mostly contain null values, and especially when two columns cannot possibly contain a value at the same time

et surtout l'explication de:

if one is defined, the other must be null, and vice versa. This condition would undoubtedly indicate a violation of eitre 2NF or 3NF.

Parce que les règles 2NF et 3NF sont très claires, en quoi la solution proposée - une table client - viole ces règles ?
Y a-t-il une colonne dont les valeurs peuvent être toujours déterminées par une partie de la clé seulement ? Je n'en vois pas -> en est en 2NF
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

Et ces règles servent à éviter des inconsistences dans dans les données. Quelles inconsistences peut venir de cette solution ?

J'aime bien être concret, sut un contexte précis, plutôt que des règles un peut trop générales du genre 'il faut faire comme ceci et pas comme celà'

Cordialement,
Franck.

[Oishiiii]

Bonjour,

Les niveaux de normalisation s'imbriquent. (1)
Pour être en 2NF une relvar doit préalablement être en 1NF. Pour être entre 3NF elle doit préalablement être en 2NF.

Une relvar est en 1NF si chaque n-uplet contient exactement une valeur pour chaque attribut.
NULL n'existe pas. Il est interdit de séjour au pays des Relations me semble t'il.

Donc il me semble normal, sans avoir besoin de rentrer dans le détail que la présence de NULL viole la 3NF (et 2NF), par transitivité en quelque sorte, puisqu'il y a viole de la 1NF.

Une base de donnée est une collection de propositions vraies.
C'est une manière de définir ce qu'est une Relation et indirectement une table. (2)
C'est très simple, et logique.

On peut donc lire tout naturellement les propositions vrais que sont les lignes. Pour une table Client: Client {CODE, NOM, PRENOM)

Le Client identifié par le code C048 s'appelle Jean DUPONT.

Mais pour l'éventuelle table Client avec présence de NULL : Client {CODE, NOM, PRENOM, RAISONSOC}

Le Client identifié par le code C083 s'appelle ??? et a pour raison sociale "Aux deux amis".

Ça a du mal à passer, pour moi en tout cas.

Il est toujours possible de réaliser une base de données dont les tables ne contiennent aucun NULL. Le nombre de table sera certainement plus élevé mais on retrouve ses petits grâce aux vues.



Pour en revenir au problème de kaibaa, à moins que quelque chose m'ait échappé; la difficulté est qu'un contrat concerne soit une personne physique, soit une personne morale.

Au niveau du MCD Merisien cela ressemblerai à ceci:
PersonnePhysique -0,N-------(Concerner)----------0,1- Contrat
PersonneMorale -0,N----------(Concerner)---------0,1- Contrat

Ce que je traduirait au niveau du MLD par les tables suivantes (clé primaires soulignées, clé étrangères en italiques):
PersonnePhysique(Code, nom, prénom, etc..)
PersonneMorale(Code, RaisonSociale, etc..)
Contrat(num, Date, etc..)
Contrat_PersPhysique(numContrat, CodePersPhys)
Contrat_PersMorale(numContrat, CodePersMoral)

Il n'y aura aucun NULL dans les tables. Simplement l'information.
Rien n'empêche d'utiliser des vues par dessus pour représenter les données différemment.



Concernant la gestion des personnes physiques et morales, c'est une simple notion d'héritage; la proposition mnitu/Waldar.
Voyez par exemple ce topic où fsmrel traite le sujet: Modélisation gestion commerciale



Une partie du chapitre auquel fait référence mnitu est visible ici.
(1) Bases de données relationnelles et normalisation - Partie 1.5
(2) Date on database: writtings 2000-2006 - Chapitre 10

[pachot]

Oui, je suis d'accord sur le principe (la théorie)
On peut faire un modèle que n'a pas besoin de null.
Et je suis d'accord avec le MLD que tu propose, à condition de rajouter une contraint XOR entre les 2 associations.
Mais je ne vois aucun inconvénient non plus à parler d'héritage dans le modèle logique, sans présumer d'une implémentation quelconque.

Par contre, dans le MPD je me vois mal avoir des tables différentes pour tous les types, et tous les états des données.
Sur les SGBD relationnels tels qu'ils sont implémentés aujourd'hui, null ne pose pase de problème. Par contre multiplier le nombre de table sur lesquelles faire des jointures, ou implémenter la contrainte XOR, là on a de nomnreux problèmes lorsqu'on voit celà en prod.

Si l'on implémente un modèle sans null, avec plein de tables,
- quel est le coût (performance) de vérification de la contrainte: un contrat ne peut pas avoir à la fois une personne physique et une personne morale
- le coût (performance) de la jointure lorsqu'on lit plusieurs contrats et qu'on veut les informations de personne physique ou morale
- le coût (maintenabilité) lorqu'il faudra avoir une deuxième ligne d'adresse, et que cette deuxième ligne sera facultative
- le cout pour rajouter le nom de jeune fille lorque la personne physique est une femme mariée
- et lorqu'on aura des cients à l'étranger où l'identification d'une société sera chaque fois différente. Le code fiscal, ce n'est pas universel.
- et si l'on veut permettre de ne pas rensigner le numéro de téléphone
...

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
-...

Pourquoi pas sur un beau diagramme. Masi je ne connais aucun SGBD qui est efficace sur un modèle physique de la sorte.

Si l'inconvénient des null c'est une violation des formes normales, ou une fidélité à la théorie relationelle, celà ne me pose pas de problème. Lorsque je modélise, cette théorie est à mon service, pas l'inverse, la théorie m'aide dans ma modélisation.

Si c'est un manque de lisibilité, un risque d'inconsistence, une faible evolutivité, ou de médiocres performances, alors là ce serait des arguments importants.

Cordialement,
Franck.

[Oishiiii]

[...]
Sur les SGBD relationnels tels qu'ils sont implémentés aujourd'hui, null ne pose pase de problème. Par contre multiplier le nombre de table sur lesquelles faire des jointures, ou implémenter la contrainte XOR, là on a de nomnreux problèmes lorsqu'on voit celà en prod.
[...]

D'après ce que je peut lire ici ou là (1) sur les forums de developpez.com; les "mauvaises performance" ou "problèmes" causés par les jointures ou l'utilisation de triggers pour garantir la qualité, l'intégrité des données semblent relever principalement de l'émotionnel et de l' a priori.

[...]
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
-...

L'héritage ne s'applique pas systématiquement comme ceci...
Par exemple l'adresse doit faire l'objet d'une table, dont la ligne d'adresse est une propriété multi-valuée à la manière des commandes et lignes de commande, il n'y a aucunement besoin de créer des tables ou d'avoir autant de colonnes que de lignes d'adresse.

Si vous devez représenter le fait qu'une personne puisse avoir un nom de famille, modélisez en conséquence, la notion d'héritage n'intervient pas ici...

Concernant les problèmes posés par les NULL voyez par exemple ce qu'écris Chris Date dans son dernier livre visible ici.
Le problème des NULL a était souvent traité sur le forum, et il me semble bien que certains Praticiens (DBA) n'y ont pas recours et leur base de données se portent très bien au niveau des performances. Voyez:
http://www.developpez.net/forums/m4495199-6/
entre la theorie et la pratique!

Concernant la "maintenabilité"; avec ces nombreuses tables, utiliser des vues pour accéder aux données offre une grande possibilité d'évolution de manière totalement transparente pour l'utilisateur. Je ne voit pas de problème ici.


Je conseillerai à kaibaa de se baser sur la Théorie Relationnelle ainsi qu'une méthode éprouvée comme Merise pour réaliser sa base de donnée et ne pas utiliser des pratiques qui a priori vont résoudre des problèmes de performances.
D'ailleurs, il ne nous a pas parlé de son environnement, de volumétrie, etc..

A moins de mettre en place les deux solutions et d'effectuer les tests ad hoc, il est difficile d'affirmer objectivement qu'une solution normalisée (au moins sans NULL) serait moins performante qu'une autre.

(1) A ce sujet (entre autre):
- Jointure, jointure, vous avez dit jointure ?
- Dénormalisation de table. Quand ?
- SI & SGBD : comment/où gérer les règles métier ?