Discussion :

[Raiden1234]

Bonjour,

Alors voila on est plusieurs a pas etre d'accord sur une relation entre deux entites :

Supposons que nous avons une entite "Personne" avec comme attribut nom, prenom et addresse.

Cette personne peut avoir deux status a savoir : Staff ou Etudiant represente par l'entite "PersonneStatus" qui est liee avec "Personne".

Maintenant, dans le cas ou cette personne est un etudiant, elle doit fournir un numero d'etudiant. Donc nous avons gere ceci en creant une entite "EtudiantNumber" et nous l'avons egalement liee avec "Personne".

Il conviendrait alors de pour l'association entre "Personne" et "EtudiantNumber" de mettre comme cardinalites 0,1 du cote de "Personne" et 1,1 du cote de "EtudiantNumber".
Car, pour une occurence de Personne, il peut y avoir 0 ou 1 numero d'etudiant.
Et inversement, un numero d'etudiant correspond obligatoirement a une et une seule personne.

Mais voila, certains disent que c'est inutile d'avoir une telle association et qu'il suffirait de mettre un champ numeroEtudiant dans "Personne" et de le renseigner seulement en cas de besoin. Est-ce juste de raisonner comme ceci ?

A-t-on le droit de mettre un champs non renseigne dans une entite ? Et l'association 0,1 -- 1,1 est-elle correcte ?

Merci de nous eclaircir a ce niveau la

[ylarvor]

Dans un premier temps, essayez de modéliser des objets concrets, c'est plus facile, par la suite, vous modéliserez des paniers dans un site de ecommerce ou des comptes dans une application de gestion!

A la place de statutpersonne, vous avez plusieurs classes : professeurs, etudiants, ... et l'étudiant à une propriété numéro étudiant toujours renseignée, toutes ces classes dependent d'une super classe personne qui rassemble les élèments commun comme nom et prenom ( un professeur a un nom, un etudiant aussi ).

référence : http://sqlpro.developpez.com/cours/m...n/heritage/#L2

[fsmrel]

Bonsoir,


Si vous souhaitez prendre l'habitude de modéliser proprement, étudiez les techniques de spécialisation/généralisation et d'héritage (Cf. la FAQ Merise) et étudiez le cas présenté par Chtouk, car le vôtre est proche du sien.

Vous devriez donc mettre en oeuvre une entité-type Etudiant, spécialisation de Personne. D'autant plus que le numéro d'étudiant sera peut être un jour accompagné d'autres attributs spécifiques des étudiants. De la même façon, en pensant à l'avenir, vous serez peut-être amené à mettre en oeuvre d'autres spécialisations pour l'entité-type Personne, et ne pas vouloir polluer cette dernière.

[Raiden1234]

En fait, nous avons bel et bien une entite qui contient les proprietes communes et l'entite EtudiantNumber correspond a un etudiant (il contient son numero etudiant et pourra par la suite contenir d'autres parametres propre a un etudiant).

En fait, ce que nous nous demandons est :

A-t-on le droit d'avoir des champs dans une entite que nous ne voulons pas specifier ?

Actuellement nous utilisons cette modelisation propre ou nous affectons une entite Etudiant a part. Et nous sommes entierement d'accord sur le fait que c'est plus propre. Nous voulions juste savoir si on a le droit ou pas aux proprietes non renseignees (affectees a NULL par exemple)

Merci de vos reponses et pour la FAQ qui va etre surement servir

[fsmrel]

Bonsoir,

A-t-on le droit d'avoir des champs dans une entite que nous ne voulons pas specifier ?

Dans l’absolu, on ne peut pas l’interdire, puisqu'avec SQL il suffit d'autoriser NULL lors de la définition des colonnes des tables. Mais je vous ai fourni des éléments de réflexion qui devraient vous inciter à bien peser le pour et le contre dans le cadre de la modélisation. Et côté pragmatique, plus d’une fois j’ai eu à auditer puis "casser" des tables comportant de l’ordre de 400 millions de lignes, dont la moitié des colonnes n’étaient pas valorisées, parce que ne correspondant qu’à des cas très particuliers (entre 10 et 10000 lignes moins enneigées que les autres). Et cette fois-ci, ça n’était plus la théorie qui était concernée, mais bien la durée des traitements (je ne parle même pas de la pertinence des résultats...)

[Raiden1234]

Ok merci beaucoup pour vos explications, je part maintenant entierement satisfait car c'est egalement ce que je pensais

[fsmrel]

Bonjour Raiden1234,

C'est toujours agréable d'avoir affaire à quelqu'un qui part satisfait et qui remercie ses interlocuteurs. A mon tour je vous remercie et vous souhaite bonne route.