Discussion :

[nouras]

Bonjour,
je suis entrain de développer une application de gestion d'une association de loisir et d'animation .
En fait , il y a deux catégories de clubs :
-des clubs pour les enfants
-des clubs pour les femmes
A l’inscription des enfants , on doit enregistré les informations de leurs parents
L'application inclut également la gestion des animateurs .

J'ai essayé de modéliser mes données avec merise (le mcd ci-joint )
Est-ce que cette modélisation est correcte?
Comment le modifier pour avoir une seule relation "Insciption"
et est-il plus correcte de faire deux entités pour différencier entre la mére et le pére ?

[fsmrel]

Bonjour nouras,

Je n’ai pas le temps pour le moment de commenter. En attendant, voici une version arborescente et dépliée : à vous de voir ce qui convient ou pas.

[nouras]

merci beaucoup pour cette réponse
elle très clair

J'ai une question :
le nom du père et de l'enfant sont les même dans la plupart des cas
On peut avoir une redondance avec cette modélisation

une autre remarque , les parents de l'enfant peuvent ne pas être des adhérent dans notre association

[fsmrel]

Bonjour nouras,

les parents de l'enfant peuvent ne pas être des adhérent dans notre association.

C’est une question de terminologie. Je remplace donc le terme ADHERENT par exemple par celui plus neutre d’EXTERNE. Si ça ne vous paraît pas pertinent, il y a ceux de CLIENT, de COTISANT, ou tout autre terme qui aura votre préférence.

le nom du père et de l'enfant sont les même dans la plupart des cas
On peut avoir une redondance avec cette modélisation.

Avant de nous embarquer pour la redondance zéro...

Limitons-nous au cas de la France. Prenons l'exemple de l’enfant Jean Martin qui a ses deux parents.

Avant l’apparition du Code Napoléon, la situation ne pouvait guère être que la suivante :

Cas 1 : On infère que les parents de Jeannot se nomment Martin.

Je suppose qu'aujourd’hui on peut avoir les cas suivants :

Cas 2 : Un des deux parents de Jeannot ne se nomme pas Martin mais Dupont.

Je ne suis pas grand clerc ès matière, mais il peut sans doute y avoir des cas du genre :

Cas 3 : A la différence de Jeannot, ses parents se nomment tous les deux Dupont.

Voire le cas qui me dépasse (que j’appellerai donc le cas « asile de fous ») :

Cas 4 : Un des parents de Jeannot se nomme Dupont et l’autre Durand.

Quels cas peuvent concerner votre association ?

[lunatix]

pour les noms de famille ça peut etre compliqué
un enfant peut porter le nom du pere, de la mere, ou même la concaténation des deux séparés par un espace ou un tiret.

duplique l'info

[nouras]

Je suis tunisienne donc dans notre pays +95% des cas l'enfant porte le nom de son père .

[fsmrel]

Parmi les 4 cas que j'ai énumérés, lesquels sont pertinents ? (l'incidence sur le MCD n'est neutre).

[nouras]

peut être la 2 éme cas est la plus proche et la première cas peut exister rarement

voici la situation normale dans notre pays :
nom de l'enfant =nom du père
nom du mère =! nom du père mais peut être dans des cas nom du mère=nom du père
de toute façon il y a pas une relation entre le nom de l'enfant et le nom du mère dans 95% des cas

[fsmrel]

Bonsoir nouras,


Dans la version ci-dessous, le nom ne figure plus dans l’entité-type PERSONNE, mais il est ventilé dans les entités-types ANIMATEUR, INSCRIT, ENFANT(où il est sous-entendu qu’il s’agit normalement du nom du père) et PORTEUR_NOM. PORTEUR_NOM, est une spécialisation de PARENT permettant de traiter au besoin du cas où un parent a un nom différent de celui de l’enfant (donc de celui du père). L’attribut TypeParent (entité-type PARENT) permet de connaître la nature du lien de parenté avec l’enfant : père, mère, autre (si par exemple l'enfant est orphelin).



Si ce scénario ne vous convient pas, on essaiera d'en trouver d'autres...

[nouras]

Bonsoir fsmrel ,

J'ai pas bien compris le rôle de la spécialisation PORTEUR_NOM et quand je dois l'utiliser
En fait, la possibilité que la mère et le père aient un nom de famille commun est rare .
donc comment avec cette modélisation peut-je stocker les info de la mère ?

[fsmrel]

Bonsoir nouras,


Dans cette 2e version du MCD, on cherche la zéro-redondance du nom. Comme le père a le même nom que l’enfant, on connaîtra le nom du père à partir de celui de l’enfant. Même chose pour la mère si elle a aussi le même nom que l’enfant. En revanche, si la mère et l’enfant n’ont pas le même nom, celui de la mère figurera dans PORTEUR_NOM.


Maintenant, si les parents peuvent avoir plusieurs enfants inscrits, on aura intérêt à utiliser le MCD suivant, dans lequel on a ôté le nom de l’enfant de l’entité-type ENFANT pour l’expédier dans l’entité-type PARENT puis finalement dans l’entité-type ADULTE (ce qui permet de le dégager de l’entité-type INSCRIT).




Si la redondance est peu fréquente, vous pouvez aussi utiliser le tout 1er modèle que j’ai proposé.

[nouras]

Merci beaucoup

[fsmrel]

Bonjour nouras,


Si c'est tout bon, n'oubliez pas de voter et de marquer la discussion comme résolue. Si vous avez encore des questions, n'hésitez pas.


Bonne route, et longue vie aux clubs.

[nouras]

Bonjour ,

Mon système doit aussi gérer les salaires ainsi que les absences des animateurs .

-L'animateur peut être absent plus qu'un jour .
-chaque mois on recalcule son montant en tenant compte des absences ainsi que les avances sur salaires .

J'ai choisi de travaillez avec la premier version que vous avez suggéré.

Est-ce que c'est bon comme ça?

[fsmrel]

Bonsoir nouras,


Dans votre MCD, la patte connectant l’entité-type ENFANT et l’association AVOIR est porteuse d’une cardinalité 1,N : pour des raisons sémantiques vous pouvez la remplacer par 1,2, même si ça n’aura pas d’influence sur le MLD.

Toujours dans le cadre de la relation enfant-parent, avez-vous besoin de savoir le type de parenté des parents (père/mère) ? Sinon votre MCD ne le permet pas. S’il le faut, il faut un attribut permettant de connaître le rôle du parent.

Concernant les absences des animateurs, il faut isoler les absences en cours des absences terminées (vous noterez l’utilisation de l’identification relative) :





Le MLD pourrait ressembler à quelque chose comme ceci :

[nouras]

Bonjour fsmrel,

Je travaille avec une version d'essaye de PowerDesigner qui ne permet pas de préciser une cardinalité égale à 1,2

Concernant les absences j'ai pas bien saisir pourquoi on doit séparer les absences en cours des absences passées?

Vous trouvez ci joint un essai pour la gestion des salaires des animateurs.
Est-ce que vous pouvez me le corriger ?

Une autre question SVP quelle est l'atelier que vous utilisez ?

Merci

[fsmrel]

Bonsoir nouras,

quelle est l'atelier que vous utilisez ?

Le jumeau de PowerDesigner, à savoir PowerAMC (une vieille version).

Je travaille avec une version d'essaye de PowerDesigner qui ne permet pas de préciser une cardinalité égale à 1,2

Vous devriez pouvoir faire comme je fais avec ma vieille version de PowerAMC :

Concernant les absences j'ai pas bien saisir pourquoi on doit séparer les absences en cours des absences passées?

Il y a plusieurs façons de justifier cette façon de faire. Utilisons par exemple des prédicats.

Pour la table ABSENCE_EN_COURS, le prédicat est :

L’animateur P est absent depuis la date D.

Pour la table ABSENCE_PERIODE :

L’animateur P a été absent pendant la période P.

Si l’on utilise une seule table, le prédicat devient :

L’animateur P est (ou a été) absent à partir de la date D1 et peut-être jusqu’à la date D2.

C'est-à-dire qu’on s’embarque pour le n’importe quoi, ce que les concepteurs de bases de données SQL essaient de gérer avec le marqueur Null (que j’appelle le bonhomme Null, lequel doit être mis hors la loi car il ne peut être traité qu’avec une logique trivalente pleine de pièges dont n’a pas conscience celui n’est pas averti).

Les données temporelles ont été traitées au plan théorique par Lorentzos, Date et Darwen dans Temporal Data and the Relational Model, mais attention, il faut bien connaître la théorie relationnelle pour comprendre le sujet en profondeur. Éventuellement, voyez ici.


Concernant les parents, vous pouvez réfléchir à la structure suivante, selon laquelle un enfant a au moins un parent (attribut ParentId de la table ENFANT) et facultativement un 2e parent (table AVOIR_PARENT_2) :




Salaire des animateurs :

Je ne suis pas spécialiste du salaire, je resterai donc muet sur les attributs composant l’entité-type SALAIRE et qui sont spécifiques des salaires des personnes.

Du point de vue de la modélisation, vous avez établi une bijection entre ANIMATEUR et SALAIRE, ce qui revient à dire que les attributs de l’entité-type SALAIRE peuvent intégrer l’entité-type ANIMATEUR. Si donc au mois M, l’animateur P a eu le saleur Sm, lorsqu’on passera au mois M+1 il faudra remplacer la valeur M de l’attribut Mois par la valeur M+1 ainsi probablement que les valeurs des attributs Salaire_de_base et Avance_salaire. Est-ce ainsi que vous voyez les choses ? Sinon, si vous voulez garder l’historique des salaires, il y a une cardinalité 1,1 à remplacer par 1,N. D’autre part, je suppose qu’il faudra tenir compte du changement d’année : passage par exemple de décembre 2013 à janvier 2014. Il y a aussi le problème de l’identification de SALAIRE : l’entité-type ANIMATEUR hérite de l’identifiant de l’entité-type PERSONNE, mais dans votre modèle, rien n’existe pour SALAIRE et si vous demandez à PowerDesigner de vérifier votre MCD, il signalera une erreur.

[nouras]

Bonsoir ,
L’attribut salaire_de_base normalement est spécifique à l'animateur ou a une catégorie d'animateurs ; elle ne change pas d'un mois à un autre donc il faudra mieux que je la déplacer dans l'entité animateur .
L'attribut avance_salaire est spécifique pour chaque mois .En fait , le système doit calculer le salaire mensuelle pour chaque animateur en tenant compte de l'avance salaire (qui peut être nulle pour un mois donné) ainsi que le nombre des jours d'absences pendant cet mois .

Vous trouvez ci-joint le mcd final mais le MPD généré contient beaucoup de problème

[fsmrel]

Bonsoir nouras,


Votre message était au fond de la pile...

Vous avez défini une bijection entre ANIMATEUR et SALAIRE, ce qui revient à dire que chaque animateur a toujours une avance sur salaire, alors que vous aviez précisé que c’était facultatif : selon votre MCD, si un animateur n’a pas eu d’avance sur salaire, alors il faudra que l’attribut avance_salaire ait la valeur 0.

Je pense par ailleurs que vous avez intérêt à conserver l’historique des avances, ne serait-ce que pour des raisons comptables et pouvoir répondre aux questions relatives aux avances des mois précédents, même si vous avez une trace sur papier. Même chose pour les salaires.

MCD correspondant aux animateurs :




MLD

Le MPD généré contient beaucoup de problèmes.

Sur la partie de MCD que vous présentez, il y a des entités-types qui ne sont pas identifiées : ABSENCE_EN_COURS, ABSENCE_PERIODE, SALAIRE. Elles doivent être identifiées relativement à l’entité-type ANIMATEUR, comme je l’ai précisé dans le message #15. Cette identification relative est symbolisée par la mise entre parenthèses des cardinalités 1,1 (en rouge dans mes MCD). Pour identifier de cette façon :



N’oubliez pas que l’attribut DateDebut participe à l’identifiant de l’entité-type ABSENCE_PERIODE.


Et n’oubliez pas de voter pour les réponses qui ont pu vous aider...

[nouras]

Merci beaucoup
une autre question SVP : Comment faire pour ajouter deux entités ayant le même clef primaire ; poweramc m'afficher un message d'erreur