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]

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.

[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?