Quel choix de modélisation pour une table ADDRESS ?

Bonjour,

ma question est assez basique et concerne le modèle de base de données.
Mais je n'arrive pas vmt à trouver de réponse.

Pour faire simple, j'ai une base de données avec différentes tables dont les tables :
SOCIETY
INT society_id
VARVHAR society_name
....

USER
INT user_id
VARVHAR user_name
....

ADMINISTRATION
INT administration_id
VARVHAR administration_name
....

Or toutes ces "entités" possèdent une ou plusieurs adresses.
L'administration possède une seule adresse.
L'utilisateur plusieurs (pays d'origine, en france, etc..)
Et la société plusieurs (adresse de facturation, adresse physique, adresse livraison, etc..)

Ma question est quel est le meilleur choix pour la table ADDRESS.

En gros je vois 2 solutions :
Une table ADDRESS unique avec
INT address_id
VARCHAR address_name
VARCHAR address_zipcode
...
avec des tables de jonctions

Ou une table USER_ADDRESS et une table SOCIETY_ADDRESS + les champs adresses directement dans la table ADMINISTRATION.
???
Je sais que c'est plus une question de choix et de cardinalités mais j'aimerais avoir des avis pour que cela facilite la récupération et la mise à jour des données dans mon application.

Merci

Puisque une société ou un utilisateur peuvent avoir plusieurs adresses, il faut considérer l'adresse comme une entité type séparée.

Reste à savoir si tu considères qu'une adresse n'appartient qu'à une seule personne, à une seule société, à une seule administration, ou si plusieurs administrations, sociétés, personnes peuvent avoir la même adresse.

La solution la plus élégante à mon avis est de généraliser personne, société et administration grâce à un héritage de données :

personne_physique -(1,1)----être----0,1- personne
societe -(1,1)----être----0,1--------------------------|
administration -(1,1)----être----0,1--------------|

On pourrait même considérer que administration et société sont toutes deux des personnes_morales et faire un niveau d'héritage supplémentaire mais restons-en à ce schéma pour le moment.

Il est alors facile d'associer une adresse à une personne :
personne_physique -(1,1)----être----0,1- personne -0,n----avoir----1,n- adresse
societe -(1,1)----être----0,1--------------------------|
administration -(1,1)----être----0,1--------------|

1,n si on considère que toute adresse n'est créée qu'en rapport avec au moins une personne.
1,1 si on considère qu'une adresse n'appartient qu'à une seule personne.

Les tables issues de ce modèle :
personne (prs_id, prs_nom, [colonnes communes à toutes les personnes])
personne_physique (pph_id_personne, pph_prenom, [autres colonnes spécifiques aux personnes physiques])
societe (sct_id_personne, sct_siret, [autres colonnes spécifiques aux sociétés])
administration (adm_id_personne, [colonnes spécifiques aux administrations])
adresse (adr_id, adr_id_ville, adr_rue, adr_code_postal...)
prs_avoir_adr (paa_id_personne, paa_id_adresse...)

Merci bcp pour cette réponse, elle m'éclaire déjà bcp.

En fait j'ai bien compris que le fait d'utiliser l'héritage est une bonne chose, évitant ainsi d'avoir des champs dupliqués dans les tables.

Mais je me demandais ensuite au sein de l'application, le requêtage n'est-til pas bcp plus compliqué? Entraînant bcp de jointures etc.

Je ne sais pas s'il y a un compromis ou quelque chose comme ca...

Merci encore

Pour reconstituer une personne complète, tu crées des vues dans le SGBD et ton application interroge ces vues. C'est le SGBD qui se débrouille avec les jointures.

Merci bcp pour ces conseils je vais étudier tout cela de plus près ^^