Discussion :

[Fabinout]

Bonjour à vous! J'ai une question en Base de Donnée assez précise, et je n'arrive pas à mettre le doigt sur une réponse sur Internet (j'ai aussi un livre, Modern Database Management, mais sans le mot que je recherche, je tourne en rond)
Je vais donc vous expliquer mon problème.
Disons que je veux modéliser le personnel d'un aéroport.
Il y a d'abord le personnel (qui a un nom, un num_sécu, une adresse)
et le personnel navigant (qui a la même chose, avec en sus un Int nombre_d'heure_de_vol)

Et je vois deux manières de modéliser mon personnel navigant
soit:
PERSONNEL NAVIGANT:
Employé ; Nombre_d'heure

Soit
PERSONNEL NAVIGANT:
Num_secu ; Nombre_d'heure
(num sécu est la clé étrangère)

En gros, employé est soit un attribut direct du personnel navigant, soit on utilise le num_secu du personnel navigant pour se référer à ses caractéristiques. La première me parait plus "jolie" programmatiquement parlant, mais je ne sais pas peser le pour et contre de ce système.

Et donc pour finir, pourriez vous juste m'indiquer vers quoi pointer mes recherches afin d'enfin savoir les tenants et aboutissants de cette méthode!

D'avance merci
Amicalement,
Fabien

[skuatamad]

Moi je ferais :
personel (id_personel,num_secu,nom,adresse)
avec id_personel en PK(primary key) et num_secu en UK (unique key, aka contrainte d'unicité)

personnel_navigant(id_personel,nb_heure)
avec id_personel PK ET FK (foreign key, aka clé d'intégrité référentielle vers la table personnel)

Mais oui num_secu est une clé candidate (donc au minimum une clé unique) mais il n'est pas obligatoire d'en faire une primary key, la question majeure pour toi en tant que développeur est : est ce que num_secu est ET sera toujours unique et jamais réattribué ?

La logique veut que oui, donc num_secu peut être une PK et une FK mais si jamais ça n'est pas vrai...il faudra faire de grosses mises à jours.
Recherche sur le forum et tu verras que le num_siret des entreprises est aussi sensé ne jamais changer....mais au bout du compte.....il peut être réaffecté.

Concernant le num_secu je ne sais pas s'il est amené à être réaffecté, normalment non, donc il pourait être une PK/FK.

En tout cas il ne faut pas dupliquer les colonnes comme nom et adresse.

[Waldar]

Je pense que le mot que vous cherchez est héritage.

Si votre modèle est aussi simple que vous le décrivez (une seule information différente entre le personnel et le personnel navigant), vous pouvez envisager une seule table PERSONNEL.

Ceux dont la colonne nombre_d'heure_de_vol est non nulle forment le personnel navigant.

skuatamad, le numéro de sécu n'est pas une bonne idée, c'est pile le contre-exemple choisi par SQLPro sur la notion de clef naturelle :
http://sqlpro.developpez.com/cours/clefs/#L2

[iberserk]

Mais oui num_secu est une clé candidate (donc au minimum une clé unique)

De toute façon le numéro de sécurité sociale n'est pas unique (eh oui...).

C'était jusqu'à très peu encore le problème de l'identito-vigilance dans le domaine de la santé qui ne disposait pas d'un identifiant unique pour un patient.

[skuatamad]

Effectivement, j'avais utilisé le conditionnel pour la PK, mais en fait le num_secu n'est même pas vraiment une clé candidate...
Merci pour l'info.