Discussion :

[beninsky]

Bonjour à tous,

J'ai une question qui est peut-être bête =) Qu'est ce qui permet de décider de placer des données dans des autres tables plutôt que de les laisser ensemble ?

Par exemple j'ai une table client contenant des informations sur les clients dont les champs sont : CLI_ID | CLI_NOM | CLI_TEL | CLI_EMAIL

Imaginons qu'il n'est pas obligatoire de renseigner les champs 'CLI_TEL' et 'CLI_EMAIL' et que ces champs se retrouvent donc souvent vides.

Est-il préferable dans ce cas la de créer une table 't_telephone' ou l'on renseignerais le téléphone et le numéro CLI_ID seulement quand un client rentre cette information ?

Ou bien le fait d'avoir beaucoup de champs vides dans une table n'a aucune importance et on peut garder la première solution ?

Merci pour votre aide !

[seabs]

Bonjour,

J'ai une question qui est peut-être bête =) Qu'est ce qui permet de décider de placer des données dans des autres tables plutôt que de les laisser ensemble ?

Par exemple j'ai une table client contenant des informations sur les clients dont les champs sont : CLI_ID | CLI_NOM | CLI_TEL | CLI_EMAIL

Lorsqu'une propriété peut comporter plusieurs valeurs, elle doit être incluse dans une autre entité (Table pour ton cas). Sinon, comment feras-tu si tes clients ont plus d'un numéro de téléphone et plus d'une adresse email ?
Tes deux entités seront :

Client(Cli_Id, Cli_Nom)
TelMail(PkCle, Cli_Id, ZoneTelEmail)

A ta toi de voir pour l'organisation de la zone où tu dois saisir le n° de téléphone et l'email.

Bon courage

[beninsky]

Merci beaucoup pour ta réponse seabs.

En fait mon exemple est mal choisi J'ai un champ dans ma table dont je suis sure qu'il sera unique. Cependant ce champs ne sera pas souvent complété dont souvent laissé avec la valeur 'NULL'; est-ce utile dans ce cas la d'exporter ce champs dans une autre table pour ne pas avoir plein de valeur 'NULL' à chaque lignes?

Encore merci pour votre aide !

[seabs]

Bonjour,

Dans ton nouvel exemple, il s'agit d'un choix personnel sans conséquence sur le fonctionnement de ta base de données.

Le seul avantage serait de réduire l'espace occupé sur le disque. Sinon, ton entité étant correcte, il est possible de maintenir cette propriété dans ta table même si elle souvent sans aucune information. Il est peut être possible ou intéressant d'inclure une valeur par défaut, car plus facile à gérer dans les requêtes que des propriétés NULL

Dans une telle situation, je mets une autre table uniquement dans le cas de la saisie d'un commentaire long. Mais, après différentes lectures sur les forums, je ne suis pas certain que cette approche soit plus performante.

En conclusion, tu peux mettre ton champ dans ta table sans créer une table complémentaire.

Bien entendu, il s'agit que d'un avis.

Bon courage

[CinePhil]

Si cette colonne qui sera souvent NULL est une clé étrangère, il vaut mieux créer une table associative. Cela correspond au MCD suivant :
A -(0,1)----Associer----0,n- B

Les tables doivent alors être les suivantes :
A (id_a, ...)
B (id_b, ...)
A_B (id_a, id_b)

Il n'est en effet pas souhaitable d'avoir des clés étrangères nulles.

[seabs]

Bonjour,

J'ai lu avec intérêt la remarque de "Cinephil"

Si cette colonne qui sera souvent NULL est une clé étrangère, il vaut mieux créer une table associative

Je ne vois pas la nécessité de créer une table associative. En effet, mon MCD et mon MPD se présente ainsi :



Si je n'ai aucun moyen de communication, aucune saisie dans la table "Communication", sinon liaison avec clé étrangère. Dans cette approche, il n'y a jamais de NULL.

Le code pour créer les tables démontre d'ailleurs qu'il est impossible d'inclure un NULL.

Code :

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

1
2
3
4
5
create table CLIENT (
CLIENTID             INTEGER                        not null,
CLIENTNOM            CHAR(30),
constraint PK_CLIENT primary key (CLIENTID)
);

Code :

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

1
2
3
4
5
6
7
8
9
10
11
create table COMMUNICATION (
COMMUNICATIONID      INTEGER                        not null,
CLIENTID             INTEGER                        not null,
COMMUNICATIONTELEPHONE CHAR(14),
COMMUNICATIONEMAIL   VARCHAR(50),
constraint PK_COMMUNICATION primary key (COMMUNICATIONID)
);

alter table COMMUNICATION
   add constraint FK_COMMUNIC_ASSOCIATI_CLIENT foreign key (CLIENTID)
      references CLIENT (CLIENTID);

Il s'agit de mon avis, mais peut être que je commets une erreur de raisonnement.
A+

[CinePhil]

Tes cardinalités empêchent effectivement qu'il y ait NULL dans la clé étrangère !
Comme tu le dis toi même : Pas de communication => pas de ligne dans la table contenant la clé étrangère. Communication => Clé étrangère non nulle.

Quelle colonne alors risque d'être à NULL si souvent ?
CommunicationTelephone ?
CommunicationEmail ?

Au passage, si les deux sont à NULL, alors la ligne insérée dans la table Communication ne contient pas d'information utile !

Moi je ferais deux tables : Une pour les téléphones et une autre pour les adrels. Ainsi plus de colonne risquant d'être à NULL souvent ! Et sémantiquement, les numéros de téléphone et les adresses électroniques sont bien deux choses différentes et doivent faire l'objet de deux entités séparées.

[beninsky]

Merci pour toutes vos réponse TRES complètes c'est le moins qu'on puisse dire ^^ Je vais me pencher sur vos exemples car je suis totalement débutant en SGBD :S

Merci de partager (un peu) de votre savoir