Discussion :

[sarah_insat]

Dans un modèle ou existe par exemple 4 entités dans lesquelles il y'a l'attribut nom, prenom, adresse, et tel (redondances).
Est ce qu'il est obligatoire de créer une entité qui contient ces données et puis la relié avec les 4 entités par une relation d'héritage. ou bien si on décompose l'adresse (code postal,ville,rue...) est il nécessaire de creér une entité adresse et la relié avec une association aux autres entités.
qu'elle est la solution optimale.
Est ce que c'est "moche" de garder les 4 entités avec les redondances sans créer d'autres entités.

[tavarlindar]

Je trouve ta question très intéressante. D'autant plus que cette notion d'héritage fait couler beaucoup d'encre semble-t-il et qu'en plus je suis en plein dedans !

Ce n'est pas moi qui vais t'apporter une réponse d'évangile,cela dit, j'ai envie de te répondre :
tout dépend de ta volumétrie. Si tu gères 100, 10000, 1.000.000 ou plus de contacts, cela doit avoir une incidence.
A l'heure où les serveurs sont plus performants et où l'espace disque ne coûte plus des millions comme il y a ... 20 ans .... je pense qu'optimiser pour optimiser cela se traduit par plus d'ennuis qu'autres choses.
Le principal c'est à mon sens de restituer les choses dans leur contexte dans une approche multi critère.
Combien d'utilisateurs dans ta base, combien de fois une table est utilisée par jour, quel type de base de données, etc ...
Qui doit maintenir, qui saisie, etc ....

En un mot, ta question est peut être trop générale pour le moment pour qu'un Gourou d'ici t'apporte une réponse pertinente.
Non ? Qu'en penses-tu ? quelles sont-tes inquiétudes en posant cette question ?

[Soutou]

Dans un modèle ou existe par exemple 4 entités dans lesquelles il y'a l'attribut nom, prenom, adresse, et tel (redondances).

Je ne vois qu'une entité (Personne) qui contient des attributs qui ne sont pas redondant. Aucun héritage n'est utile ici. Que veux tu dire par redondance?

[tavarlindar]

Dans un modèle ou existe par exemple 4 entités dans lesquelles il y'a l'attribut nom, prenom, adresse, et tel

4 entités qui partagent des attributs en commun .. non ?

[fsmrel]

Dans un modèle ou existe par exemple 4 entités dans lesquelles il y'a l'attribut nom, prenom, adresse, et tel (redondances).
Est ce qu'il est obligatoire de créer une entité qui contient ces données et puis la relié avec les 4 entités par une relation d'héritage. Ou bien si on décompose l'adresse (code postal, ville, rue...) est il nécessaire de créer une entité adresse et la relié avec une association aux autres entités.
Est ce que c'est "moche" de garder les 4 entités avec les redondances sans créer d'autres entités.

Au niveau d’un modèle conceptuel, disons Merise, il est d’usage de ne pas multiplier les noms des propriétés :

"Une propriété ne peut qualifier qu’un seul objet ou une seule relation."

[Ministère de l'Industrie, Mission à l'Informatique, Centre Technique Informatique, Méthode de Définition d'un Système d'Informations, Fascicule 4. Juin 1979]

En conséquence de quoi, Nom, Prénom, Adresse et Tel ne devraient figurer qu’une seule fois dans le modèle. En revanche, si vous avez quatre attributs qui sont des variations sur le thème du type Nom : Nom du client, Nom du fournisseur, Nom du développeur, Nom du service de l'entreprise, tels que chacun de ces attributs figure dans une entité-type appropriée (respectivement Client, Fournisseur, Développeur, Service), du point de vue de la forme il n’y a rien à dire, il n’y a pas redondance et ça n’est pas "moche".

Cela dit, il y a manifestement une alternative, dès que l’on précise le sens des attributs.

Vous aurez observé en passant que l’exposé de votre problème est vague, car vous n'en prenez pas en compte la dimension sémantique : A quoi correspond chaque entité-type ? Client, fournisseur, salarié de l’entreprise, service, chamouflard, etc.? A défaut, on ne peut pas dire si votre modèle est "moche" du point de vue non plus de la forme, mais du fond.

Appelons Client, Fournisseur, Développeur, Service, les entités-types initiales. Supposons que les attributs dont vous avez fourni la liste soient en fait sémantiquement comparables : vous pouvez alors les regrouper en une seule entité-type Personne et ne laisser dans Client, Fournisseur, Développeur, Service que les attributs spécifiques, non sémantiquement comparables (le salaire d’un employé de l’entreprise n’a pas de sens pour les clients, de même que le numéro de Siren d’une entreprise n’a pas de sens pour l’employé). Le procédé de regroupement des attributs qui le méritent, s’appelle Généralisation. L'entité-type Personne correspond à ce que l’on appelle un surtype et Client, Fournisseur, Développeur et Service correspondent aux sous-types de Personne. La relation entre surtype et sous-types est de type EST UN (IS A).

Concernant l’adresse, vous ne mettez en œuvre une entité-type Adresse que si pour une valeur de Personne — donc pour une personne — vous pouvez avoir plus d’une adresse. Adresse entretient alors une relation R avec Personne :

Personne --- 0,N ---R --- 1,1 --- Adresse

Quant à décomposer l’adresse en code postal etc., vous ne le faites que si c’est utile pour les applications utilisant la base de données. En l’occurrence, c’est donc à vous, en relation avec les utilisateurs de définir le niveau atomique de l’adresse. Et si vous devez décomposer, alors appuyez-vous tant qu’à faire sur les normes de La Poste, de l’AFNOR, de votre entreprise ou que sais-je, mais ne réinventez pas l'eau tiède.

qu'elle est la solution optimale.

Il n’y a jamais de solution optimale, mais plutôt une solution que l’on estime a priori meilleure que d’autres, sur la base par exemple de son aptitude à permettre une évolution sans douleur de la base de données. En effet, un système d’information n’est pas figé et les coups peuvent venir de partout. Souvenez-vous du passage à l’euro ou à l’an 2000. Plus modestement, imaginez la charge de travail à venir, voire la panique, le jour où le système d’immatriculation des voitures en France changera...
Et puis, le niveau conceptuel est une chose, mais le niveau logique (relationnel) en est une autre, et là bien des choses peuvent être remises en question, car on ne joue plus sur le nom des attributs (propriétés) et d'autres paramètres interviennent. Quoi qu’il en soit, le niveau conceptuel reste quand même déterminant pour la suite et il ne faut pas rater son coup.

Pour la petite histoire, c'est quand même généralement au stade de la modélisation logique et physique que les choses finissent par se dénouer : conservation ou éclatement de la table Personne en 2, 3 ou 4 tables, même chose pour les adresses, sans oublier que par le mécanisme des vues d'union et de jointure, on sait recomposer l'équivalent des entités conceptuelles. Le SGBD n'est pas neutre dans cette affaire et vous ne procèderez pas de la même façon si vous avez un SGBD classique ou bien une machine base de données du genre Teradata, avec des processeurs en parallèle à foison, machine avec laquelle l'éclatement est inutile, car celui-ci se passe sous le capot...

[mayloshi]

Avant de prendre en compte une information élémentaire (nom, adresse...), il faut s'assurer qu'il n'est pas polysème (un mot qui a plusieurs sens) ou qu'il n'a pas de synonymes( deux mots qui ont le même sens) dans tout le MCD.

Si l'info est polysème (Ex: entité Employé avec propriété nom, entité département avec propriété nom), il faut la nommer de manière très précise (nom_employé et nom_departement).

Si l'info a un synonyme, il y a redondance, dans ce cas là, il faut soit fusionner avec son synonyme, soit deplacer l'info dans la relation entre les entités qui la prennent en compte.