SV_LVH a écrit :
Non vraiment ce que je veux savoir c'est : Est-ce qu'on peut avoir des clés étrangères vides dans une table ?
|
Citation :
Contrainte d’intégrité référentielle : toute valeur d’une clé étrangère est égale à la valeur nulle ou à la valeur de la clé primaire à laquelle la clé étrangère se réfère
|
Oui. C'est de la logique, et ça dépend du modèle que tu choisis.
Exemple :
J'ai une table PAYS, et une table USERS. Un USER réside dans un pays, donc clé étrangère.
Dans le cadre de mon application, il n'est pas indispensable de connaître le pays des utilisateurs. Du coup, je décide que les utilisateurs n'ont pas besoin de renseigner ce champ (NULL). Mais s'ils le renseignent, le pays doit correspondre à un des pays de la table PAYS...
=> Clé étrangère (relation 1,n) avec possibilité de NULL (pour matérialiser la relation 0,n).
SV_LVH a écrit :
'IDENTITES' 0,1 | 1,1 'USER_WEB'
'IDENTITES' 0,1 | 1,1 'CLIENTS'
Je ne peux pas changer les cardinalités si c'est ce que tu veux dire. J'ai bien sur pensé à les modifier pour virer les FK de ma table, mais cela revient a donner de faux paramètres. Cela risque de poser d'autres problèmes pour plus tard. Et puis je ne cherche pas un moyen de bricoler pour que ma table fonctionne mais plutôt à apprendre des trucs qui me serviront après et que je saurais être juste.
|
Dans ce cas, revoie les relations...
Sauf cas particulier (dénormalisation), il n'y a aucune raison de faire plusieurs tables quand la cardinalité est 1.
Exemple caricatural :
Un utilisateur a un unique mail. Un mail doit correspondre à un seul utilisateur.
Tu vas faire quoi ?
Code :
- USERS (id_user<PK>, nom, id_mail<FK> ) et MAILS(id_mail<PK>, adresse_mail)
|
ou
Code :
- USERS(id_user, nom, mail)
|
Dans ton cas c'est pareil :
Une identité peut correspondre à un et un seul user_web, et un user_web doit correspondre à une et une seule identité.
=> Une seule table qui regroupe les trois, et les champs actuellement dans USER_WEB ou CLIENTS peuvent être NULL.