Discussion :

[Wilhem31]

Bonjour,

Actuellement en formation, je dois réaliser un site internet pour une association d'aide à la personne comme projet de fin d'année.
Etant encore débutant, je leur permettrait simplement d'acceder à un espace personnel avec une messagerie et un emploi du temps.
Je souhaiterai avoir des avis sur le debut de ma démarche et pourquoi pas des pistes d'améliorations!

Voici le shema de depart que j'ai réaliser :

[escartefigue]

Bonjour,

Tout d'abord, il faut planter un peu mieux le décor, les lecteurs ne connaissent pas votre sujet, définissez le rôle des différents acteurs

Ensuite vous devez communiquer la liste exhaustive des règles de gestion, de préférence identifiées par un n°.
Exemple :
- R001 : un admin peut affecter zéro à plusieurs prestations
- R002 : toute prestation est affectée par un à plusieurs admin
- R003 etc...
Il faut aussi préciser les Contraintes d'Intégrité Fonctionnelle (CIF) : un salarié peut il être également admin, un admin peut il être aussi un client etc...
Ces règles écrites permettront notamment de vérifier vos cardinalités, il semble que vous ayez inversé certaines d'entre elles (exemple : tous les 1,1 coté AGENCE sont très suspects)

Après, chassez les redondances. Un client, un salarié un admin, sont tous 3 des personnes, il faut donc mutualiser ce qui est commun à ces personnes dans une entité-type personne, puis procéder par sous-type et héritage pour ce qui est spécifique.

Enfin, attention à respecter les formes normales, tout attribut d'une entité-type doit être en dépendance fonctionnelle de l'identifiant. Or, l'adresse d'une personne (client, admin ou salarié) ne dépend pas de l'identifiant de la personne, mais de l'identifiant de la personne, du type d'adresse et de la date.
Il faut donc modéliser ainsi (je simplifie aux cas de personnes physiques seulement) :
PERSONNE (id, nom, prénom, date de naissance...) 0,n --- Posseder (date début, date fin) --- 1,n ADRESSE (id, ligne1, ligne2, ...) 1,1 --- Typer --- 0,n TYPE ADRESSE (id, code, libellé...)

Utilisez vous un logiciel de modélisation ?
Dans la négative, il en existe des gratuits

[Wilhem31]

Ha oui d'accord c'est un cran au dessus de ce que j'ai appris en fait..
J'utilise Jmerise pour les schema ou StarUML.

Je vais travailler la dessus alors mais avant pourriez vous m'éclairer sur certaine choses :
- Dans le cas de la classe Personne , ou la placer dans le schema ? Je comprends son interet mais au final ce sera toujours Client,Salarié et Admin qui seront utilisé pour les relations.
- En ce qui concerne la dépendance fonctionelle de l'identifiant j'avoue etre un peu perdu aussi , quel est l'interet de la Personne->possede-->adresse-->de type-->Type_adresse ?

Merci de l'aide déjà apporter en tout cas,

Cordialement,

[escartefigue]

- Dans le cas de la classe Personne , ou la placer dans le schema ? Je comprends son interet mais au final ce sera toujours Client,Salarié et Admin qui seront utilisé pour les relations.

Vous créez une ET (entité-type) personne avec ce qui est commun à toutes les personnes, puis les sous types tels que vous les aviez créés (client, salarié et admin) vos relations ne changent pas elles concernent les sous-type
L'avantage est que si une personne est à la fois admin et client par exemple, vous n'avez pas à répéter les informations qui concernent cette personne

- En ce qui concerne la dépendance fonctionelle de l'identifiant j'avoue etre un peu perdu aussi , quel est l'interet de la Personne->possede-->adresse-->de type-->Type_adresse ?

Prenez l'exemple de 3 personnes
- pour la première, vous ne connaissez aucune adresse
- pour la deuxième vous n'en connaissez que 1, celle de son habitation principale
- pour la troisième, qui est une personne morale, vous connaissez une adresse du siège, une adresse de facturation et une adresse de livraison
Si vous modélisez comme vous l'aviez fait, soit vous prévoyez 3 adresses dans l'entité-type personne, et du coup, dans la table qui en résulte, vous avez plein de colonnes inutilisées pour les clients 1 et 2, soit vous perdez des adresses pour les clients qui en ont le plus. Et si un jour un nouveau client possède 4 adresses, il faut modifier votre table pour ajouter encore de nouvelles colonnes.
Si au contraire vous modélisez comme je le suggère, votre modèle de données n'est pas impacté par le nombre d'adresses des personnes, il suffit de créer autant d'occurrences d'adresses que la personne possède.

C'est bien ainsi qu'il faut modéliser, il ne faut jamais répéter un groupe d'attributs dans une entité-type, quand un groupe d'attributs est répété, c'est qu'il doit appartenir à une autre entité-type
Le type d'adresse permet de savoir s'il s'agit d'une adresse de résidence principale, secondaire, temporaire, de livraison, de facturation etc...

[escartefigue]

Voici un exemple de modélisation possible, qui utilise l'héritage, et dans lequel je n'ai repris qu'une partie de votre sujet

Au niveau conceptuel

Pièce jointe 295614

Une personne peut être une personne physique ou une personne morale
Un salarié est forcément une personne physique
Si vous avez des clients PP et PM alors c'est un sous-type non exclusif à créer directement sous PERSONNE sinon c'est un sous-type des PP ou des PM

L'entité-type adresse est en relation directement avec les PERSONNES ainsi tous les sous-types en bénéficient : vous géréz aussi bien l'adresse de vos clients, que de vos salariés etc... la cardinalité notée entre parenthèses met en évidence l'identification relative : lors de la dérivation du MLD l'identifiant de l'adresse sera composé de l'id_personne + id_adresse (cette solution est facultative, mais elle présente des avantages en termes de performances)

Par contre la relation d'utilisation d'un véhicule est en lien avec les salariés conformément à votre modèle.
Vous noterez à ce sujet que j'ai ajouté la notion de date via une nouvelle entité-type "CALENDRIER" : un véhicule est affecté à un salarié pour une période, mais il peut ensuite être affecté à un autre salarié

Et voici le MLD correspondant

Pièce jointe 295619

Notez que la table issue de la relation "attribuer" a pour clef unique Personne + Véhicule + Date
Il faudra donc modifier le DDL lors de la génération du MPD pour que l'id Personne ne contribue pas à cette PK : en effet, il faut bien qu'à une date, un véhicule ne soit attribué qu'à une seule personne. C'est donc le couple id_vehicule + date qui doit être unique (sauf si un véhicule peut être attribué à plusieurs personnes au même moment bien sur)

Voilà vous pouvez vous baser sur ces principes pour enrichir votre modèle

EDIT :

• j'ai modifié les schémas au niveau héritage, j'avais oublié de modifier certains paramètres dans Power AMC
• une remarque concernant la génération de la table adresse dans le MLD : Power AMC a positionné l'id adresse avant l'id personne, avant de générer le MPD, il sera judicieux d'inverser ces deux colonnes pour faciliter la recherche de toutes les adresses d'une personne. Je ne sais pas pourquoi Power AMC choisit parfois cet ordre, parfois l'ordre inverse, il semble que ce soit aléatoire

[Wilhem31]

Whaou ..!!

Ca c'est du boulot, merci de l'aide mais je me demande même si j'arriverai à utiliser un MCD aussi complexe !

[escartefigue]

Qu'Est-ce qui est complexe ? n'hésitez pas à poser des questions si besoin