Discussion :

[hyperion13]

Bonjour
Je suis étonné que personne ne vous ait orienté vers la Théorie des ensembles pour comprendre Fonction, Application, Injection, Surjection et Bijection, pour ensuite assimiler, si ce n'était pas déjà la cas, les Formes normales (FN) avec un aperçu ici et là et comprendre l'Héritage (contraintes de spécialisations) avec un aperçu ici et là.

[Lio_Nel]

Bonjour, je vois que la discussion est marquée comme résolue. Mais rien n'empêche d'ajouter une brique pour l'intérêt du sujet et l'exercice

Après lecture de ce post et analyse des différents échanges, mon avis est qu'une adaptation sur la modélisation est à prévoir afin de gérer tous les aspects proprement, sans faire porter de notions multiples à certains champs.

J'ai relevé plusieurs besoins qui doivent être gérés par une modélisation adaptée :

• Identifier une personne de manière unique.
• Identifier individuellement un client.
• Identifier les couples, avec les variations possibles dans le temps.
• Identifier les accompagnants individuellement.
• Gestion de mailing avec adressage approprié de la personne, ou d'un couple.
• Connaitre l'effectif de location.
• Gestion des ressources à louer avec leurs caractéristiques. Ici on parle de maisons, appartements, chambres, lits, mais ça reste une gestion des ressources avec des caractéristiques particulières.
• Gérer les rattachements d'assurance à la location, mais aussi à chaque ressource
• Gérer les contrats de location adossés aux factures
• Gérer l'historique des coordonnées d'un client, ou d'un accompagnant, ou d'un membre de sa famille, soit finalement l'historique d'une personne.
• Suivre l'activité d'un client, en effet un client est d'abord un contact, puis un client, puis un occupant et son statut à chacun de ces stades peut varier comme par exemple : Réservation en cours, Réservation confirmée, Acompte réglé, Facture en suspend etc …
• Suivis du statut de réservation ou de disponibilité d'une ressource dans un planning
• Connaître la fidélité des personnes. Combien de fois est venue chaque personne, chaque client et sa famille etc …

Pour résoudre ces besoins, je propose ce modèle, non pas que ce soit le seul modèle possible, mais à priori, il résiste à l'usage de chacun de ces besoins.
Il s'agit d'un modèle simplifié qui ne traite en détail que les champs importants servant de clé primaire, clé externe, ou encore de données fondamentales. C'est donc vraiment plus une proposition "POC" qu'un modèle aboutis




Explication du modèle

Table	Explication
[T_Personnes]	Permet l'enregistrement de chaque personne identifiée tout au long des différentes phase de de location. Chaque personne est identifiée, avec sa civilité, son {Identite} (nom,prénom), ses {Coordonnees}, son {Email} à un instant donné {DateCreation}. Chaque personne peut évoluer dans le temps, changer de nom, ou déménager. Le champ {AutreIdPersonne} permet de rattacher une personne qui a déjà été identifiée à son profil précédent, ou encore de rattacher tous ses précédents profils à son profil actuel. Question de choix de règle de gestion. Une personne identifiée plusieurs fois vois ses précédents profils désactivés grâce au champ {Desactive} une fois rattachés au profils principal, probablement le plus récent. La pertinence de ces profils pourra être interchangeable en fonction de la situation de la personne : occupant enfant, puis célibataire, puis marié, puis divorcé ou remarié avec des identités et coordonnées changeantes. Il s'agira de programmer un peu pour gérer le rattachement via le champ {AutreIdPersonne} et l'activation ou pas d'un profil en tant que profil principal.
[T_Civilites]	Permet la dénomination d'une personne en tenant compte de sa civilité "Mr", "Mme", "Mlle". La table peut aussi contenir des Civilités destinées à la rédaction dynamique de mail en fonction des algorithme qui déduiront si Monsieur est accompagné de Madame ou l'inverse. La prise en charge de ce point est expliqué plus loin.
[T_Activités]	Permet de lister un ensemble d'activités liées au cycle de vie d'une location par un client. Une activité par rapport à une personne pourra prendre les valeurs suivantes, et même être étendues selon les besoins de suivis : Contact Client - Devis en cours Client - Réservation en cours Client - Location réservée Client - Facture en cours Client - Facture réglée Occupant etc … La gestion de ces statuts d'activité répond à des règles de gestion à fixer avant tout. Il doivent servir à quelque chose, sinon, ils n'ont pas lieu d'être.
[T_SuivisActivites]	Permet d'historiser dans le temps tous les statuts d'activités par personne. Il faut voir cette table un peu comme une table de log. Elle sera alimentée sur évènement dans les formulaires probablement.
[T_Clients]	Permet de considérer séparément les clients des personnes accompagnantes. Les clients ont des caractéristiques qui leurs sont propres, ces caractéristiques sont à identifier en fonction du besoin. Ce modèle considère qu'un client correspond à une personne et une seule. La conséquence est qu'en cas d'évolution d'une personne sous un autre {IdPersonne}, il faut soit modifier à la volée le champ {IdPersonne] de la table [T_Client], soit créer un nouvel {IdClient} avec de nouvelles caractéristiques et rattachable à l'ancien {IdClient} par le champ {AncienIdClient}. Cette fonctionnalité est à approfondir en fonction des règles de gestion à appliquer selon les besoins. Attention, il faudra prendre en compte qu'il faut conserver les caractéristiques d'un client, donc ses coordonnées de personne au niveau des facture set devis qui une fois établies sont fixes. Soit on conserve l'historique dans [T_Personne] que l'on rattache de manière permanente aux factures via la table [T_Clients], soit on stock les valeurs dans la table [T_Facture] de manière statique. Encore un choix de règle de gestion lié au besoin.
[T_Ressources]	Permet de gérer un pool de ressources à louer. Les caractéristiques d'{Assurance} propre à la ressource sont à raccrocher à ce niveau. Les caractéristiques propres aux ressources sont à rajouter évidemment, mais pour ce modèle, elles ne sont pas essentielles. Elles le deviennent lorsqu'on doit évaluer l'adéquation d'une ressource avec le besoin du client. Ces caractéristiques sont à définir en fonction des besoins.
[T_Locations]	Permet de suivre les locations et leur statut dans le temps Une location est affectée à un client {idClient}. Une Ressource se voit affectée à la location pour une période donnée {IdRessource}, {DateDebut}, {DateFin}. Une location est en attente de confirmation, ou confirmée {Confirmation}. Il est donc possible de savoir si une ressource est disponible, potentiellement disponible, ou réservée. Les caractéristiques de {Contrat} et d'{Assurance} pour la location sont ici à raccrocher à la Location.
[T_Occupants]	Permet de savoir qui occupe la location {IdLocation} Le couple {IdLocation}, {IdPersonne} permet de peupler la location {IdLocation}. Le fait de tagguer un occupant comme {OccupantPrincipal] permet d'identifier les couples, parents, par rapport aux enfants. Il permet également de déterminer une hiérarchie de civilités. Ex: Si Monsieur est le client, et viens en couple avec 2 enfants, Monsieur et Madame seront taggués {OccupantPrincipal}, Ensuite, pour savoir comment s'adresser au couple dans un mailing par exemple, on pourra déterminer dynamiquement les Civilités de couple comme Monsieur et Madame, Messieurs, Mesdames etc… Règle Si {IdPersonne} est {OccupantPrincipal} et est le Client, il passe en premier dans la civilité, si il n'est qu'{OccupantPrincipal}, il passe en second dans la civilité. La règle de gestion est à approfondir en fonction du besoin, mais la base est là.
[T_Factures]	Permet de suivre les Devis et Factures par clients en fonction des locations prises. Une Facture est affectée à une Location {idLocation} et une seule, mais une location pourrait faire l'objet de plusieurs factures. Une Facture est affectée à un client {IdClient}, mais un client peut avoir plusieurs factures le long de de son parcours client. Une facture reste en mode {Brouillon} le temps de son établissement avant son envoi. Un Facture est d'abord un {Devis} avant d'en devenir une. La vie d'une facture s'accompagne de traces temporelles {DateCreation}, {DatePaiement}, {DateAnnulation}. Ces marqueurs de vie sont à étendre en fonction des besoins.

Passons maintenant au criblage des besoins relevés :

• Identifier une personne de manière unique.

La table [T_Personnes] permet de le faire.

• Identifier individuellement un client.

Les tables [T_Clients] et {T_Personnes] permettent de le faire.

• Identifier les couples, avec les variations possibles dans le temps.

La table [T_Occupants] permet d'identifier les occupants principaux d'une location via le champ {OccupantPrincipal} et de cibler dans le temps les couples grâce aux périodes définies dans la table [T_Locations].

• Identifier les accompagnants individuellement.

La table [T_Occupants] permet de le faire.

• Gestion de mailing avec adressage approprié de la personne, ou d'un couple.

Une requête et un peu de programmation basés sur les tables [T_Personnes], [T_Clients], [T_Occupants] permet d'arriver à nos fins.

• Connaitre l'effectif de location.

La table [T_Occupants] permet de compter le nombre d'occupants pour une locations donnée.

• Gestion des ressources à louer avec leurs caractéristiques. Ici on parle de maisons, appartements, chambres, lits, mais ça reste une gestion des ressources avec des caractéristiques particulières.

La table [T_Ressources] devra être designée pour cela.

• Gérer les rattachements d'assurance à la location, mais aussi à chaque ressource.

Faisable au niveau des tables [T_Ressources] et [T_Locations] en améliorant le design du modèle relationnel.

• Gérer les contrats de location adossés aux factures.

La table [T_Locations] permet de le faire, en améliorant si besoin le design du modèle relationnel.

• Gérer l'historique des coordonnées d'un client, ou d'un accompagnant, ou d'un membre de sa famille, soit finalement l'historique d'une personne.

Les tables [T_Personnes], [T_Locations] et [T_Occupants] associées entre elles permettent de définir cet historique.

• Suivre l'activité d'un client, en effet un client est d'abord un contact, puis un client, puis un occupant et son statut à chacun de ces stades peut varier comme par exemple : Réservation en cours, Réservation confirmée, Acompte réglé, Facture en suspend etc …

La table [T_SuivisActivites] permet de mettre en place ce suivis.

• Suivis du statut de réservation ou de disponibilité d'une ressource dans un planning.

L'usage du champ {Confirmation} de la table {T_Locations], et éventuellement une requête sur le Suivis d'activité du client dans [T_SuivisActivites] permettent d'obtenir toutes les informations nécessaires.

• Connaître la fidélité des personnes. Combien de fois est venue chaque personne, chaque client et sa famille etc …

Des jeux de requêtes en fonction des besoins sur les tables [T_Personnes], [T_Locations] et [T_Occupants] permettent de sortir ces rapports sans trop forcer.

Comme je l'ai mentionné au début de mon post, c'est une modélisation possible, sûrement pas la seul, et qui a l'air de répondre aux besoins exprimés dans le fil de la discussion, mais la résolution de tous les cas se fait forcément au prix d'une modification du modèle de données original. Il y a donc un impact sur la récupération des données historiques et sur le travail déjà engagé au niveau du développement des formulaires.

Du coup, on part ici sur une petite refonte de la base Access initiale.
Reste à évaluer si le gain potentiel en vaut la chandelle, en effet, le travail est loin d'être terminé au niveau modélisation car il faut descendre dans le détail, puis développer les formulaires et rapports adaptés.

Pour l'exercice, je fournis la base remodélisée ici : POC Location saisonnière