Modélisation d'une application web

Bonjour à tous,

Dans le cadre d'un projet d'étude, nous devons réaliser un MCD d'une application web d'investissement immobilier fractionné tel que Fragments ou Bricks.
L’immobilier fractionné est une forme d’investissement où plusieurs investisseurs s’unissent pour acquérir ensemble un actif immobilier. Chaque investisseur détient ainsi une fraction de propriété, ce qui lui donne droit à une partie des bénéfices (loyers, plus-value de cession…) générés par cet actif. L’investissement dans l’immobilier est de ce fait beaucoup plus accessible.
Novice sur les MCD, je vous avoue qu'on a un peu de mal à s'auto-corriger sur ce que nous avons fait et nous avons besoin d'aide extérieure..
Nous vous serions très reconnaissants pour votre assistance et le partage de vos connaissances.

L'application :
La plateforme "Slice" sera une plateforme d'investissement crowdfunding immobilier qui sélectionne des biens dans lesquels les utilisateurs pourront investir à partir de 20€ et percevoir des revenus tous les mois.
1 "Slice" = 20€

- Un utilisateur peut avoir un des 3 rôles : connecté / validé / admin
Connecté : Un utilisateur seulement connecté pourra consulter la liste des biens. Il pourra vérifier son compte pour + d'actions.
- Validé : Un utilisateur validé aura accès à son portefeuille Slice avec lequel il pourra investir et percevoir des revenus.
- Admin : Un utilisateur admin pourra CRUD (Create, Read, Update, Delete) des biens, générer des Slice, valider les virements et autres demandes.
- Un utilisateur "lambda" pourra se connecter sur l'application avec son adresse mail et un mot de passe. S'il veut pouvoir investir dans des biens, il faudra qu'il complète son profil et valide son compte.
- Un utilisateur validé aura un code de parrainage à partager.
- Un utilisateur aura, une fois validé, un wallet sur lequel il pourra déposer de l'argent pour acheter des Slices, ainsi que recevoir les revenus de ses investissements.
- Si un utilisateur veut mettre de l'argent sur son wallet, il fait une transaction, par carte bleue ou par virement. Si c'est par virement, la transaction générera une demande qu'un utilisateur admin devra valider.
- Un bien équivaut à une somme d'argent donc à un nombre donné de Slice. Un bien possède une liste de documents que seul les utilisateurs validés peuvent consulter.
- Si un utilisateur veut investir dans un bien, il va donc acheter un ou des Slices lié à ce bien. Il va faire une transaction = débiter du wallet la somme pour acheter et posséder des Slices.
- Un Slice possède un id unique, en prévention d'une potentielle marketplace interne pour pouvoir revendre ses Slices d'un bien. Il devra aussi posséder une sorte de token aléatoire.
- L'achat de Slice d'un bien générera un contrat que l'utilisateur devra signer.
- Un bien sur lequel un utilisateur a investi des Slice va lui générer un revenu donc une transaction de crédit/ débit du wallet.
- Un utilisateur pourra avoir accès à un historique de ses transactions.
- Un utilisateur pourra retirer de son wallet de l'argent via une transaction, ce qui générera une demande qu'un utilisateur admin devra valider.

Avec ses informations je distingue 9 entités : Utilisateur [User] / [Wallet] / [Transaction] / [Slice] / [Contrat] / Demande [Request] / Bien [Property] / [Document] / [Revenue]

Je distingue également ces associations :

- Un utilisateur peut avoir 0 ou 1 wallet, mais un wallet n'est détenu que par un unique utilisateur = [User] 0,1 --- 1,1 [Wallet]
- Un utilisateur peut faire 0 ou n transaction, une transaction peut être générée par un utilisateur = [User] 0,n --- 0,1 [Transaction]
- Une transaction peut générer 0 ou n demande, une demande n'est générée que par une transaction = [Transaction] 0,n --- 1,1 [Request]
- Une demande doit être validée par un utilisateur, un utilisateur peut valider 0 ou n demande = [Request] 1,1 --- 0,n [User]
- Une transaction peut créditer ou débiter de l'argent sur le wallet, le wallet peut avoir 0 ou n transaction = [Transaction] 0,1 --- 0,n [Wallet]
- Une transaction peut générer l'achat de Slice, un Slice peut etre lié à plusieurs transaction (en prévision d'une marketplace) = [Transaction] 0,n --- 1,n [Slice]
- Un Slice génère un contrat, un contrat est lié à un slice = [Slice] 1,1 --- 1,1 [Contrat]
- Un utilisateur peut avoir/signer 0 ou plusieurs contrat, un contrat n'est detenu que par un utilisateur = [User] 0,n --- 1,1 [Contrat]
- Un bien génère 1 ou plusieurs Slice, un Slice n'appartient qu'à un bien = [Property] 1,n --- 1,1 [Slice]
- Un bien peut posséder des documents, un document peut etre lié à plusieurs biens = [Property] 0,n --- 1,n [Document]
- Un bien génère 0 ou n revenu, un revenu est lié à un bien = [Property] 0,n --- 1,1 [Revenue]
- Un revenu génère 1 ou n transaction, une transaction est liée à un revenu = [Revenue] 1,n --- 1,1 [Transaction]
- Un utilisateur peut voir les documents, un document peut etre vu par un utilisateur = [User] 0,n --- 0,1 [Document]

Nous avons donc réalisé ce MDC :

Pièce jointe 652482

Bonsoir,

C'est un très bon début !
Avant d'aller plus loin dans l'analyse de votre modèle, juste 3 questions ?

• l'association "generate" met en œuvre des cardinalité 1,1 des deux côtés... Etes-vous sûr de ces cardinalités ? Si oui, il faut envisager de regrouper les 2 classes d'entités.
• les cardinalités n'apparaissent pas pour l'association "have"... est-ce juste un problème d'affichage au niveau de votre logiciel ? (d'ailleurs, quel est ce logiciel ?)
• Comment sont représentées les associations avec cardinalités multiples de part et d'autre, et pouvant donc porter des rubriques ?

D'autres questions arriveront probablement de la part de mes collègues experts sur ce forum ;).

Bonsoir,

Citation:

---

Envoyé par Paprick

D'autres questions arriveront probablement de la part de mes collègues experts sur ce forum ;).

---

T'en fait pas, Paprick, on va s'y employer :P

Bonsoir,

Lors du passage à SQL, le catastrophique bonhomme NULL va envahir les tables. On va essayer de lui barrer la route du mieux possible.

Pour commencer, vu leurs attributions et possibilités propres, spécialisons les utilisateurs en Admin, utilisateur validé et utilisateur connecté. Je prends note que seul un admin pourra créer des objets (biens, slices). Disons qu’il se situe à un niveau méta.
 

https://www.fsmwarden.com/developpez...isation(1).png

Questions

(1) Qu’est-ce qu’un utilisateur lambda ? Est-ce simplement un utilisateur connecté ? Précisez.
 
(2) « S'il veut pouvoir investir dans des biens, il faudra qu'il complète son profil et valide son compte. »
Quels sont les attributs, dans quelle table (ou association) sont utilisés à ce effet ?
 
(3) Un utilisateur validé u1 aura un code de parrainage à partager avec autre utilisateur u2. Je suppose que l’association affiliate est là pour associer u1 et u2. Dans ce contexte, u2 peut-il être un utilisateur validé ? Merci de clarifier cette partie.
 
(4) Qu’est-ce qu’un code de parrainage ?
 
(5) Bien que francophone pur jus, ça ne me dérange pas d’utiliser une terminologie qui ne m’est pas familière (wallet, slice...) Cela dit quelle est la différence entre les attributs Name et LastName ?
 
(6) Un utilisateur validé aura accès à son portefeuille Slice. Je suppose qu’un admin peut aussi se comporter en utilisateur validé, auquel cas la spécialisation des utilisateurs peut être affinée :
 

https://www.fsmwarden.com/developpez...isation(2).png

 
Mais si l’admin reste au niveau méta, on peut supposer qu’il se créera par exemple un compte en tant qu’utilisateur validé, auquel cas la première vue relative à la spécialisation est préférable à celle-ci. Votre position ?
 
(7) Un wallet n'est détenu que par un unique utilisateur : [User] 0,1 --- 1,1 [Wallet]
Dans la première vue relative à la spécialisation, on passe à [UtilisateurValide] 1,1 --- 1,1 [Wallet]
Même chose avec la seconde vue, on passe à [UtilisateurAwallet] 1,1 --- 1,1 [Wallet]
 
Comme vous l’a signalé Paprick, les associations 1,1 --- 1,1 sont particulièrement pénalisantes, et j’ajouterai particulièrement au stade SQL. Autrement dit, l’entité-type Wallet doit être phagocytée par sa partenaire et disparaître du MCD (tant pis pour le côté bande dessinée...)
 
Pour le bien de la base de données, le défi est de faire disparaître les cardinalités 0,1, au bénéfice des cardinalités 1,1.
 
Ainsi, cela vaut la peine de spécialiser l’entité-type Transaction en TransactionCB et TransactionVirement puisqu’une transaction par carte bleue n’a pas à faire l’objet d’une demande à valider par un admin.
 

https://www.fsmwarden.com/developpez...isation(3).png

 

Notez l’utilisation de l’identification relative pour l’entité-type Demande : ontologiquement parlant une demande n’existe que par la transaction dont elle est l’objet. On reparlera de ce type très important d’identification.
 
(8)    « Un Slice possède un id unique, en prévention d'une potentielle marketplace interne pour pouvoir revendre ses Slices d'un bien. Il devra aussi posséder une sorte de token aléatoire ».
Dans l’absolu, ce jeton aléatoire doit-il être unique ? si oui, il devra faire l’objet d’une clé alternative (alternate key), c’est-à-dire d’une contrainte d’unicité.
 
(9)     « Un Slice génère un contrat, un contrat est lié à un slice = [Slice] 1,1 --- 1,1 [Contrat] »
Là encore, une des deux entités-types doit phagocyter l’autre.

Je reviendrai à la charge...

Quant à l’AGL pour la modélisation des données, je vous engage à utiliser Looping (Merci Paprick !) aucun de ceux à qui on l’a recommandé n’a hésité.

Bonjour,

Quelques remarques et questions :
 
Des entités-types telles que User, Contrat, Revenue, Transaction, Request sont dotées d’attributs CreatedAt, UpdatedAt. Je suppose qu’en français, le suffixe « at » est à interpréter comme « à ». Est-ce cela ? Quel est le type de ces attributs ? DATE, HEURE, DATE-HEURE ?
 
Entité-type User :
 
  Role_User : s’agit-il des trois rôles (spécialisés) Admin, Utilisateur validé, Utilisateur connecté ?
  AffiliateCode_User : dans mon message précédent, j’ai évoqué le parrainage (questions 3 et 4). Qu’en est-il ?
 
Entité-type Wallet :
 
  Balance_Wallet : de quoi s’agit-il ? Cette donnée est-elle inférable ?
  
Entité-type Contrat :
 
  TypeOf_Contrat : sans doute à faire l’objet d’une entité-type ad-hoc, à laquelle devrait faire référence l’entité-type Contrat.
  Slice_Contrat : de quoi s’agit-il exactement ?
 
Entité-type Property :
 
  Slice_Property de quoi s’agit-il exactement ?
 
Entité-type Transaction :
 
  TypeOf_Transaction : carte bleue, virement, autre possibilité ? (achat, vente...)
  CreatedAt_Transaction est présent deux fois.
  Status_Transaction : sans doute à faire l’objet d’une entité-type ad-hoc, à laquelle devrait faire référence l’entité-type Transaction.
 
Entité-type Request :
 
  TypeOf_Request : sans doute à faire l’objet d’une entité-type ad-hoc, à laquelle devrait faire référence l’entité-type Request.
  Status_Request : sans doute à faire l’objet d’une entité-type ad-hoc, à laquelle devrait faire référence l’entité-type Request.

Bonjour à tous

Citation:

---

Envoyé par fsmrel

(5) Bien que francophone pur jus, ça ne me dérange pas d’utiliser une terminologie qui ne m’est pas familière (wallet, slice...) Cela dit quelle est la différence entre les attributs Name et LastName ?
 

---

Je suis d'accord sur ce point, mais sous réserve que le contexte le justifie : il est inutile de s'encombrer d'une langue étrangère si le contexte est franco-français.
Outre la complexité supplémentaire liée à la maitrise plus ou moins bonne de la langue, le risque de percussion des noms d'objets (tables, colonnes...) avec des mots réservés SQL est plus important en anglais qu'en français.
Cas d'espèce "USER" est un mot réservé SQL alors que "UTILISATEUR" ne l'est pas. Il faudra donc ajouter des doubles quotes pour encadrer le nom de la table issue de cette entité-type dans les requêtes... Pénible à l'usage.

EDIT : par ailleurs, si l'anglais se justifie, alors il faut l'utiliser partout. Or "contrat" se dit "contract" ou "deal" ou "agreement" selon le contexte.

Enfin, et c'est un point de confort, s'il est judicieux de suffixer les attributs par le nom de l'entité-type dont ils sont issus, je leur préfère des préfixes, la recherche en est facilitée : like prefixe% est toujours plus performant que like %suffixe, non indexable ;)

PS : n'hésitez pas à voter :plusser: pour les réponses de Fsmrel qui j'en suis sûr vous ont été utiles ;)

EDIT (2) comme il est question de transactions financières et que la langue est l'anglais, on est en droit de s'interroger sur les devises considérées pour ces transactions. Si celles-ci peuvent dépendre de la transaction, alors le code devise est requis.
Vous pouvez vous référer à la norme ISO 4217 pour ce besoin.

Bonjour à tous,

Tout d'abord, merci de vos réponses et de votre temps !

Je vais tenter de répondre aux points que vous avez soulevés dans l'ordre :

Paprick :

1. En effet, c'est une erreur ! Nous avons corrigé les cardinalités ainsi que notre vision de l'association Slice - Contrat
2. Encore une erreur ! Nous avions utilisé draw.io pour cette version, mais nous avons écouté vos conseils et sommes parti sur Looping !
3. Nous n'avons pas compris.. :oops:

fsmrel :

1. Un Utilisateur "lambda" est un utilisateur qui n'est pas connecté et qui n'a accès à rien, si ce n'est la page pour s'inscrire. Nous n'avons pas jugé utile de l'inclure dans le MCD, devons nous le faire ?
2 / 3 / 4. Vos questions et la notion d'héritage nous ont permis de mettre à jour notre version du MCD. Un utilisateur pourra ajouter le code de son parrain lors de son passage à un utilisateur connecté. Seul un utilisateur validé peut avoir un code de parrainage à partager. Cette notion de parrainage, nous l'avons trouvé sur Bricks par exemple, voici ce qu'ils disent à ce sujet :

Pièce jointe 652759

5. Nous avons fait la nouvelle version sur Looping en français pour être sûr que tout soit compréhensible, vous devriez apprécié la dernière version ! Au moins à la lecture !
6. Nous avons dissocié Admin d'un Utilisateur.
7. Nous avons modifié le MCD en prenant en compte vos conseils sur ces points.
8. Nous n'avons pas compris ce point..
9. Nous avons mis à jour l'association Slice - Contrat
10. Nous ne sommes pas sûr d'avoir bien compris ni de comment bien représenter "objet d’une entité-type ad-hoc" alors nous avons fait une table extérieur avec une simple flèche.

escartefigue

Vous avez raison, nous avons conclu de passer à un MCD en français pour faciliter notre compréhension, éviter les erreurs de traductions et les mots réservés..
Je note votre point de confort ! Nous avions déjà commencé notre nouvel MCD en %suffixe pour les attributs ! Mais nous allons revoir ça à la nouvelle version


Encore merci beaucoup pour vos précieux conseils et retours. Nous espérons vraiment que notre MCD_v2 saura mettre en valeur ce que vous nous avez évoqués.

Pièce jointe 652758

Bonsoir,

Avec Looping, on y voit plus clair :P

J’avais noté ceci :
 

Citation:

---

Envoyé par fsmrel

Je suppose qu’un admin peut aussi se comporter en utilisateur validé [...] Mais si l’admin reste au niveau méta, on peut supposer qu’il se créera par exemple un compte en tant qu’utilisateur validé, auquel cas la première vue relative à la spécialisation est préférable à celle-ci. Votre position ?

---

 
Votre réponse :
 

Citation:

---

Envoyé par Worldask

6. Nous avons dissocié Admin d'un Utilisateur.

---

 
D’accord.
 

Citation:

---

Envoyé par Worldask

8. Nous n'avons pas compris ce point.
Il s’agissait pour moi de traiter de ce point :
 

Citation:

---

Envoyé par Worldask

Un utilisateur aura, une fois validé, un wallet

---

---

Le wallet est désormais un portefeuille. D’accord. Cela dit puisque l’utilisateur doit avoir été validé pour détenir un portefeuille, l’attribut Portefeuille_Utilisateur doit migrer vers l’entité-type UtilisateurValide.
 
 

Citation:

---

Envoyé par Worldask

Un Utilisateur "lambda" est un utilisateur qui n'est pas connecté et qui n'a accès à rien, si ce n'est la page pour s'inscrire. Nous n'avons pas jugé utile de l'inclure dans le MCD, devons nous le faire ?

---

Je dirais que si la page d’inscription figurait dans le modèle, alors je dirais oui. Sinon je ne vois pas de raison objective de le prendre en compte dans le MCD. Qu’en pensent mes collègues :question:
 
 

Citation:

---

Envoyé par Worldask

9. Nous avons mis à jour l'association Slice – Contrat

---

 
Selon votre MCD, un slice permet la création de plusieurs contrats. A son tour un contrat fait référence à un seul slice et il est signé par un seul utilisateur : un contrat est donc (à voir dans notre tête comme) une association entre un slice et un utilisateur (validé). Cela dit, un slice s1 peut faire l’objet d’un contrat c1 avec l’utilisateur u1 et d’un contrat c2 avec l’utilisateur u2. Est-ce bien ainsi qu’il faut voir les choses ?
 
 

Citation:

---

Envoyé par Worldask

10. Nous ne sommes pas sûr d'avoir bien compris ni de comment bien représenter "objet d’une entité-type ad-hoc" alors nous avons fait une table extérieure avec une simple flèche.

---

 
Prenons l’exemple des revenus : si chaque revenu est d’un type donné, alors la modélisation est la suivante :
 

[RevenuType]---0,n---(Être du type)---1,1---[Revenu]

 
Dans votre MCD initial l’attribut TypeOf_Revenue peut prendre n’importe quelle valeur, alors que grâce à l’entité-type RevenuType, cette valeur est contrôlée.
 
 
A propos du parrainage. Vous avez créé un attribut Codeparrain_Utilisateur. Cet attribut peut prendre n’importe quelle valeur : l’intégrité des données est prise en défaut. Il doit être supprimé et à la place il faut définir une association Parrainer. Si un utilisateur validé peut parrainer plusieurs autres utilisateurs validés et si un utilisateur validé peut être parrainé par au plus un autre utilisateur validé alors le MCD ressemblera à ceci :
 

https://www.fsmwarden.com/developpez...arrainage).png

 
L’association est dite réflexive. Au stade SQL, le bonhomme Null pourra se manifester, mais on verra alors comment s’en débarrasser...

En attendant, si vous avez une heure etez un oeil à la discussion où je traite de la réflexivité (récursivité) : Représentation d'arbres entremêlés. Voyez le post #9.
 
Affaire à suivre !

Bonjour,
Il y a des liens dans votre modèle que je ne comprends pas et qui dérogent au formalisme entité-association...
Il s'agit des liens directs sans association entre certaines classes d'entités :

• EtatBien -> Bien
• ContratEtat -> Contrat
• RevenuType -> Revenu
• Etc...

Connaissant un petit peu Looping, j'imagine que vous avez créé ces liens avec l'outil "Flèche" ; or, cet outil fait partie des illustrations et n'a aucun effet syntaxique...
Le MLD correspondant ne le prendra donc pas du tout en compte et, surtout, cette une notation qui n'existe pas dans le formalisme.
En résumé, pour associer des classes d'entités, vous ne pouvez utiliser que les outils "Lien" (qui créera automatiquement une association entre les 2) ou "Héritage".
Ensuite, si vous voulez simplifier la représentation graphique de votre modèle, cliquez plusieurs fois sur le bouton "E/A" en haut à gauche : les associations avec cardinalités 1,1 seront alors réduites à une simple DF.

Bonne continuation !

Bonjour,

Citation:

---

Envoyé par Paprick

Il y a des liens dans votre modèle que je ne comprends pas et qui dérogent au formalisme entité-association...

---

 
J’ai déjà répondu à notre ami comment s’y prendre :
 

Citation:

---

Envoyé par fsmrel

Prenons l’exemple des revenus : si chaque revenu est d’un type donné, alors la modélisation est la suivante :
[RevenuType]---0,n---(Être du type)---1,1---[Revenu]

---

 
A propos des transactions
 
(1) Selon votre MCD, un utilisateur validé peut effectuer des transactions externes : très bien. Mais une telle transaction, appelons-la t1, est facultativement le fait d’un utilisateur validé (la cardinalité portée par la patte connectant l’entité-type TransactionExterne et l’association (faire) est en effet 0,1). Dans ces conditions qui d’autre qu’un utilisateur validé peut aussi être la source de la transaction t1 ? Il y aurait comme de la génération spontanée ?
 
(2) selon l’association (solder), non seulement un utilisateur validé peut être concerné, mais il en va de même avec l’utilisateur connecté : j’ai des doutes. Veuillez nous éclairer.
De même, explicitez le terme "solder", quel est son objet, qu’est-ce qui est soldé dans cette affaire ?

Revenons sur l’association réflexive Parrainer :
 

https://www.fsmwarden.com/developpez...arrainage).png

 
Et supposons qu’il faille prendre en compte la date de parrainage et autres données liées au parrainage : on est coincés car la cardinalité 0,1 portée par la patte connectant l’association Parrainer interdit que celle-ci soit porteuse de propriétés...
Même pas grave, on peut modéliser ainsi :
 

https://www.fsmwarden.com/developpez...rainage)v2.png

 
La date de parrainage est présente dan l’entité-type Filleul (attribut FilleulDepuis).

Bonjour,

Je remets à plat l’histoire du parrainage. Après relecture, je constate que ma proposition d’aménagement du MCD (cf. post #11) ne tient pas.

Citation:

---

Envoyé par Worldask

Un utilisateur validé aura un code de parrainage à partager.

---

 
(1) Si je comprends bien, à un utilisateur validé est affecté d’office un code parrainage, et ce code de parrainage pourra ensuite être partagé par plusieurs utilisateurs ; si l’on fait référence à ce que dit Bricks, ces derniers sont seulement des utilisateur connectés. Votre dernier MCD va dans ce sens, mais les associations sont absentes.

Je propose ceci :
 

https://www.fsmwarden.com/developpez...rainage)v3.png

 
En notant que les attributs dont le nom est en gras et n’est pas souligné sont des identifiants alternatifs (contrainte d’unicité, deux utilisateurs validés ne peuvent pas avoir le même code de parrainage).
 
 

Citation:

---

Envoyé par Worldask

Seul un utilisateur validé peut avoir un code de parrainage à partager.

---

 
(2) Ce qui confirme le point (1).
 
 
(3) Ce que dit Bricks :
 
« Valable pour toutes les nouvelles inscriptions faites durant l’année 2024 via votre code de parrainage »
 
Cela veut-il dire qu’un utilisateur connecté a nécessairement un parrain ? C’est ce que j’ai modélisé, mais si un utilisateur peut être connecté sans avoir de parrain, la cardinalité 1,1 est à transformer en 0,1.
 
 

Citation:

---

Envoyé par Worldask

Un utilisateur pourra ajouter le code de son parrain lors de son passage à un utilisateur connecté.

---

 
(4) Je ne suis pas sûr d’avoir bien compris. Je pense que vous confirmez qu’un utilisateur connecté n’a pas forcément de parrain. C’est ça ?

Parrainage, variation sur le thème...
 
Supposons que :
 
(1) Un utilisateur validé n’a pas nécessairement de filleul ;
 
(2) Un utilisateur connecté n’a pas nécessairement de parrain ;
 
(3) Alors le MCD suivant prend en compte ces deux possibilités.
 

https://www.fsmwarden.com/developpez...rainage)v4.png

 
S’il fallait modéliser la date de parrainage, dans la mesure où elle pourrait être différente de la date à laquelle un utilisateur s’est connecté (attribut ConnecteDate) alors l’entité-type relative Filleul serait à doter à cet effet d’un attribut ParrainageDate.

Bonsoir,

Citation:

---

Envoyé par Worldask

Si un utilisateur veut investir dans un bien, il va donc acheter un ou des Slices lié à ce bien.
Il va faire une transaction = débiter du wallet la somme pour acheter et posséder des Slices.

---

Citation:

---

Envoyé par fsmrel

Le wallet est désormais un portefeuille. D’accord. Cela dit puisque l’utilisateur doit avoir été validé pour détenir un portefeuille, l’attribut Portefeuille_Utilisateur doit migrer vers l’entité-type UtilisateurValide.

---

A ceci près, reprenons votre dernier MCD (post #7)
 

https://www.fsmwarden.com/developpez...ilisateur).png

Je n’ai pas tout capté, aussi voici comment je comprends naïvement les choses.

Supposons qu’à la date du 01/02/2024 l’utilisateur validé Raoul a acheté 100 slices du bien b1. Cet achat fait l’objet du contrat c1.
 
Question : pourquoi un contrat pour chacun des 100 slices de 20 euros ? Cela donne lieu à 100 contrats, ça paraît étrange. :koi:

Quoi qu’il en soit, Raoul est le propriétaire des 100 slices pour la période [01/02/2024:31/12/9999], l’infini étant symboliquement représenté par la date "31/12/9999".

Supposons encore que Raoul revende 20 slices à la date du 02/04/2024. Pour la période [01/02/2024:31/12/9999] il possède encore 80 slices, mais il possède aussi 20 slices pour la période [02/04/2024:31/12/9999].

A son tour, l’utilisateur Fernand achète des slices, dont 10 des 20 slices revendus par Raoul.

Pour simplifier la recherche de l’état de chaque slice, l’entité-type Slice est dotée d’un attribut SliceEtat de type booléen : si sa valeur est 0, le slice n’est possédé par aucun acheteur, si sa valeur est 1, le slice est possédé par un acheteur.

Pendant une période donnée, un slice n’est possédé que par un seul utilisateur (CIF fléchée "à la escartefigue" figurant sur le lien connectant l’association Détenir et l’entité-type UtilisateurValide).

Contrainte impérative à assurer : pour un slice donné, deux périodes doivent être strictement distinctes (pas de recouvrement).

Voici le MCD traduisant ma vision des choses (j’ai fait abstraction des contrats pour ne pas compliquer cette affaire).
 

https://www.fsmwarden.com/developpez...lisateur)3.png

 
Merci de commenter, dire ce qui ne va pas. Au besoin je peux joindre le code SQL.

Votre SGBD ?

Bonjour,

Simplifions les choses.

Examinez le MCD suivant :
 

https://www.fsmwarden.com/developpez...8207;tuel).png

 

On l’interprète par exemple ainsi :
 
Supposons que le montant du bien b1 soit de 20000 euros, soit 1000 slices de 20 euros chaque. A la date du 01/02/2024, le tout premier utilisateur validé a investir sur ce bien est Raoul, qui en a mis pour 2000 euros (c’est-à-dire 100 slices).
Pour le bien b1, reste 18000 euros à investir.
Si Raoul revend 30 slices à la date du 02/04/2024, son montant investi est ramené à 1400 euros et il reste 18600 euros à investir ans le bien b1.

A son tour, l’utilisateur Fernand achète 200 slices, ce qui représente un montant de 4000 euros. Restent 14600 euros à investir dans le bien b1.

Etc.

En fait, dans le MCD le concept de slice est absent, concrètement les slices sont dématérialisés ! Pour connaître le nombre de slices investis il suffit de diviser le montant investi par 20.

Que les utilisateurs parlent des slices, c’est normal, mais modéliser dans la base de données le slice pour lui-même conduit à une complexification inutile.

On a appliqué ici le principe d’essentialité défini par Ted Codd en 1974 et qui a tué le modèle réseau qui régnait alors en maître. Cf. le post (#7) A propos de "Parlez-vous Merise".

Merci de commenter.

Bonjour,

Encore une fois merci beaucoup pour tous vos retours.

Nous avons rendu notre MCD.

Nous avons bien pris en considération tous vos conseils pour le mettre à jour.

Ce que nous avons modifié depuis notre dernier post :

- Le principe de parrainage (post #13),
- Mise à jour de toutes les associations, retrait des simples flèches,
- Retrait de l'association Utilisateur --(solder)-- Transaction,
- Nous avons décidé de garder l'entité Slice, la gestion de la marketplace n'étant pas la priorité. Cependant nous gardons en tête le principe d'essentialité.
- Ajout d'une association Administrateur --(déclarer)-- Revenu,
- Mise à jour des champs.

Pièce jointe 653127

Nous tenons une nouvelle fois à vous remercier car la V1 de notre MCD n'a rien à voir avec celle que nous avons rendue, et ce, grâce à vous.

Bonjour Worldask,

Voilà un travail sérieux, je vous félicite. :ccool:

Préparez la riposte si on vous fait observer que tel slice acheté par Raoul ne pourra pas être revendu par celui-ci et racheté par Fernand, à moins de monter une usine à gaz en ce sens.

Bonne route, et tenez-moi au courant. ;)

François

Bonjour,

C'est effectivement un beau travail.
Au delà du fond, je trouve que la forme du modèle est très propre et lisible malgré sa complexité : un bon exemple également de l'utilisation de Looping :zoubi: !
Bonne continuation !

Bonjour vaillant Worldask,

Si vos travaux d’Hercule chez DVP sont achevés, marquez la discussion comme résolue.

Encore bravo et bon courage pour la suite, ;)

François