Discussion :

[sousou88]

bonjours, je suis débutante en merise
j'ai établie 2 relations et je ne c'est pas quelle est la plus correct ...merci de donnez vos avis sa m'aiderais beaucoup.

[fsmrel]

Bonjour,


Selon votre représentation, un étudiant peut avoir plusieurs pères er plusieurs mères. Le MCD devrait plutôt ressembler à quelque chose comme ceci :



La patte connectant l’entité-type Parent et l’association-type Pere est porteuse d’une cardinalité maximale N (même chose concernant la patte connectant l’entité-type Parent et l’association-type Mere). En effet :
Supposons que les étudiants Emile et Lucie puissent avoir le même papa Albert, mais des mamans différentes, Claire et Jeanne, alors l’entité-type Etudiant fera l’objet de deux couples distincts faisant référence aux paires {Albert, Claire} et {Albert, Jeanne} :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
Parent {ParentId  PsnNom  ...} 
           p1     Albert  ...
           p2     Claire  ...
           p3     Jeanne  ...
          ...     ...     ...

Etudiant {EtudId  PsnPereId  PsnMereId  EtudNom  ...}
            e1       p1         p2       Emile   ...
            e2       p1         p3       Lucie   ...

La patte connectant l’entité-type Etudiant et l’association-type Pere est porteuse d’une cardinalité minimale 0 (même chose concernant la patte connectant l’entité-type Etudiant et l’association-type Mere). En effet, l’étudiant René n’a peut-être pas de père. Si dans votre système un étudiant à nécessairement un père et une mère, les cardinalités 0,1 doivent être remplacées par des cardinalités 1,1.

[B.AF]

Ce qui est surtout surprenant c'est pourquoi faire des informations redondantes :

Parent ou étudiant sont des personnes, donc la définition est commune;

Sachant que tout à chacun peut avoir plusieurs parents, et que chaque parent peut avoir plusieurs enfants.

[fsmrel]

Parent ou étudiant sont des personnes, donc la définition est commune;

A ceci près que vous imposez la date de naissance des parents ainsi que leur adresse, ce qui est en contradiction avec le MCD initial. Et que faites-vous de leurs revenus ?

Ce qui est surtout surprenant c'est pourquoi faire des informations redondantes

Que les attributs Nom et Prénom entrent dans la composition de l’en-tête de l’entité-type Parent et dans l’en-tête de l’entité-type Etudiant, ça n’est absolument pas un problème. Il y a redondance d’information quand il y a redondance de valeurs, ce qui ne sera pas le cas dans la base données issue du MCD que j’ai proposé.

Sachant que tout à chacun peut avoir plusieurs parents

Plus de deux ? Justifez. En se limitant à deux, le MCD que j'ai proposé convient.

[B.AF]

En france, un enfant peut avoir plusieurs parents :
Les parents biologiques,
Les responsables légaux,
Les tuteurs,

Un enfant aujourd'hui dans le cadre de ses études qui peut faire financer ses études par son beau pére sans pour autant ne plus être sous la responsabilité de son pére, ce qui sera pris en compte dans la calcul de la bourse par exemple. Ce que l'on cherche finalement à identifier dans ce modéle sont les responsables légaux de l'enfant qui ne sont pas nécessairement les paretns par définition.

Un pére ou une mére peuvent reconnaitre plusieurs enfants différents. Mais c'était déjà levé.

Quant à la définition d'une personne, ce sont des informations triviales, ce qui est important c'est de pouvoir spécialiser la données, il pourrait effectivement avoir une entité permettant d'identifier le genre et les adultes pour avoir une intégrité plus forte sur la notion pére/mére qui est sexuée, ce qui n'empêcherait pas d'avoir une mutualisation des propriétés.

Ce modéle de données est plus approprié à un modéle objet qu'un modéle relationnel.

Globalement, le shéma est effectivement trop "trivial", parce qu'il ne s'agit pas finalement d'identifier les parents mais si je comprends bien les responsables légaux de l'enfant et leurs revenus (ce qui ressemble effectivement à de l'enseignement privé ou a des calculs d'affectation de bourses). Donc même parent n'est qu'un rôle qui peut exister dans l'association d'une personne adulte à la responsabilité d'un enfant.

[fsmrel]

En france, un enfant peut avoir plusieurs parents

En France si ça ne vous ennuie pas.

il pourrait effectivement avoir une entité permettant d'identifier le genre et les adultes pour avoir une intégrité plus forte sur la notion pére/mére

Les associations-types Père et Mère du MCD que j’ai proposées suffisent. La spécialisation ne s’impose pas. Utere sed non abutere.

Ce modéle de données est plus approprié à un modéle objet qu'un modéle relationnel.

Un MCD Merise est tout à fait approprié. Quant au Modèle Relationnel de Données, pourquoi ne conviendrait-il pas ?

Ce que l'on cherche finalement à identifier dans ce modéle sont les responsables légaux de l'enfant qui ne sont pas nécessairement les paretns par définition.

sousou88 emploie le terme « Parent » qui est sémantiquement fort, qui sous-entend la participation d’un père et/ou d’une mère. A sousou88 de se prononcer, sinon la discussion ne peut que tourner en rond.

[B.AF]

Ok d'ou si ambiguité, l'inutilité de recourir à des éléments fortement typés et redondants.

Abusus non tollit usum

La base d'une bonne modélisation, c'est bien de résoudre toutes les ambiguités.

Sur le principe je n'ai rien contre le MCD, mais je ne vois pas l'utilié pratique d'avoir des entités qui représentent des éléments identiques.

Non seulement le modéle n'est pas évolutif, mais je crois que c'est surtout l'habitude de travailler sur des modéles de plusieurs milliers d'entité où la question de la factorisation et de la généricité est vitale pour permettre des schémas maintenable.

Je concéde avoir un peu complexifié, mais finalement, le principe de modélisation doit inclure aussi dans le raisonnement une analyse des entités pour définir.

Comme je le dis à un client, une client, un fournisseur, une banque, restent des personnes, certaines sont physiques et d'autres morales, ce qui défini des informations de base. Donc, quelle utilité d'avoir une table client, une table fournisseur, une table banque ...? Elle est nulle, c'est une conception naïve où l'on considére que le terme est suffisamment descriptif.

M'enfin, en france, vous n'aimez pas l'abstraction, c'est l'héritage latin probablement.

[fsmrel]

Abusus non tollit usum

C’est bien pour cela que si je suis évidemment partisan de la généralisation/spécialisation, je n’en fais pas pour autant un usage inconsidéré.

La base d'une bonne modélisation, c'est bien de résoudre toutes les ambiguités.

Après trente années de modélisation — surtout d’audit, validation, assistance aux concepteurs, etc. — dans tous les secteurs (banque, assurance, industrie, distribution, administration, j’en passe et des meilleures), j’ai constaté que certaines ambiguïtés ne peuvent pas être levées, quelle que soit la volonté avec laquelle on s’y essaie, ne serait-ce que parce qu’il est des situations dans lesquelles les utilisateurs ne savent pas bien ce qu’ils veulent, ou parce qu’ils n’arrivent pas à se mettre d’accord entre eux et campent sur leurs positions, jusqu’à ce que la Maîtrise d’ouvrage tranche.

Sur le principe je n'ai rien contre le MCD, mais je ne vois pas l'utilié pratique d'avoir des entités qui représentent des éléments identiques.

Soyez précis quant à la terminologie. Je suppose que les éléments auxquels vous faites allusion sont les attributs ParentNom, ParentPrenom (entité-type Parent) et EtudNom, EtudPrenom (entité-type Etudiant), lesquels ne jouent pas de rôle déterminant au niveau des opérations, à moins que sousou88 ne dise le contraire.

Quand vous parlez d’utilité pratique, cela veut dire que vous passez du niveau conceptuel au niveau logique, puis physique, et cette fois-ci le discours change, on descend des nuages pour aller transpirer dans la soute et mettre du charbon. Regrouper dans un seul espace physique S l’ensemble des noms et prénoms fait que volumétrie V de S correspondra à la somme des volumétries Vp et Ve des espaces physiques Sp et Se hébergeant les tables Parent et Etudiant, avec en gros Vp =2V/3 et Ve = V/3. Quand l’ordre de grandeur est la centaine de millions de lignes, on y regarde à deus fois avant de tout regrouper. Les productions informatiques préfèrent que les espaces physiques soient moins volumineux (encombrement, durée des opérations de service telles que les sauvegardes). Les DBA préfèrent aussi, car — entre autres choses — la hauteur des index pourra en prendre un coup (donc les performances s’en ressentiront) ; s’il faut habiliter seulement certains utilisateurs à consulter ou mettre à jour les noms et prénoms soit des parents, soit des étudiants, cela devient plus difficile quand on a tout mis sans le pot commun. J’en passe et des meilleures.

quelle utilité d'avoir une table client, une table fournisseur, une table banque ...?

Si vous définissez une entité-type générique Personne, vous serez amené à définir des entités-types spécialisées : Client, Fournisseur, Banque, car certains attributs et certaines associations-types valent seulement pour telle entité-type en particulier (par exemple, les clients ont des conditions tarifaires, tandis qu’avec les fournisseurs on a des taux de remise, toutes choses sans objet concernant les banques) : en ce qui concerne la base de données, les tables Client, Fournisseur, Banque seront bien présentes, outre la table Personne.

Non seulement le modéle n'est pas évolutif, mais je crois que c'est surtout l'habitude de travailler sur des modéles de plusieurs milliers d'entité où la question de la factorisation et de la généricité est vitale pour permettre des schémas maintenable.

Le MCD est évolutif, car si le besoin s’en faisait sentir, rien n’empêcherait de définir une entité-type générique Personne, tandis que les entités-types existantes, Parent et Etudiant donneraient lieu à des entités-types spécialisées.

Par ailleurs, quand on travaille sur des modèles comportant des milliers d’entités-types, on commence par urbaniser l’univers du discours, en le découpant en sous-univers correspondant aux différents référentiels (Par exemple : Personnes, Contrats, Cotisations, Catalogue produits, Prospection, etc.), sinon une chatte n’y retrouverait pas ses chatons. Ça n’est qu’ensuite, au sein de chaque référentiel, que l’on procède à la généralisation/spécialisation (sans oublier la composition et l’agrégation, bref la routine).

Et veuillez ne pas massacrer l’orthographe, s’il vous plaît, on a du mal à vous lire. Une erreur de temps en temps, d’accord, ça nous arrive à tous, mais il y a des limites.

M'enfin, en france, vous n'aimez pas l'abstraction, c'est l'héritage latin probablement.

La courtoisie n’est manifestement pas votre qualité première et vous préférez provoquer, afficher une condescendance de mauvais aloi. Je ne sais pas qui vous êtes pour vous permettre de porter des jugements définitifs du niveau café du commerce, mais en France nous aimons l’abstraction (par exemple notre pays s’honore quand même de neuf médaillés Fields), par contre nous n’apprécions guère les logorrhées absconses du genre « le principe de modélisation doit inclure aussi dans le raisonnement une analyse des entités pour définir ». Le français est la langue de la précision, profitez-en. Et méditez l’avertissement de Edgser Dijkstra :

« A programmer that talks sloppily is just a disaster. Excellent mastery of his native tongue is my first selection criterion for a prospective programmer. »

Je me demande pourquoi vous cherchez à froisser les gens, mais on ne saurait s’étonner si les modérateurs venaient à vous sanctionner, comme c’est déjà arrivé, suite à des argumenta ad odium tout à fait déplacés.

[B.AF]

Justement au cas où tu n'avais pas compris, le Français n'est pas ma langue maternelle.
Et comme tous, je fais encore des erreurs, mais je progresse.

Ce n'est pas une question de courtoisie, c'est une question de culture.

Vous avez une culture qui à l'origine est latine, basée sur la discussion, la proximité et l'abondance, qui n'est pas la mienne. Donc là où vous voyez la circonlocution comme une preuve de courtoisie et où vous considérez que pour être correct il faut écrire sans fautes quelle que soit son origine, ma culture est là encore différente.

Mais comme vous semblez toujours plus vous lire que lire les autres, je doute que vous puissiez comprendre.

Vous me reprochez mon ton sans courtoisie, quand je vous lis, j'ai l'impression que vous voyez surtout la paille dans mon oeil.

Bref, une fois de plus sur la forme on s'égare, et ça ne m'intéresse pas plus que ça.

Bonne journée à vous.

[fsmrel]

Décidément, ce B.AF restera ad infinitum sur ses a priori...

[B.AF]

Oui Papa.