Cardinalité entre les objets

Bonjour,
J’ai les objets « Société » et « Compte bancaire »qui ont comme cardinalité : Compte bancaire 0,1 ↔ 1,n société.( Un compte bancaire peut être associé à maximum une société et une société doit avoir au moins un compte bancaire).

Je voudrais que lorsqu’ on crée une société, qu’on lui associe obligatoirement un compte bancaire (existant ou un nouveau)

Or, à la création d’une société, je n’ai pas de champs qui font référence à l’objet « Compte bancaire » et l’onglet des « Compte bancaire » n’apparaît que lorsque la création est terminée.



En gros, comment puis-je rendre obligatoire l’association d’un compte bancaire à une société depuis l’écran Société.
Dans l’écran “Compte bancaire”, l’association d’une société à un compte bancaire se passe bien.

Merci d’avance pour votre aide.
Abed.

Pour d’évidentes raisons d’intégrité transactionnelle il n’y a pas moyen de forcer la création d’un objet fils sans avoir préalablement créé avec succès son objet père.

Mais il y a des approches possibles pour répondre à cet type de besoin.

Première approche, configurer un workflow d’activités avec plusieurs étapes : 1) je saisis les données minimales du père 2) je saisis les données minimales du 1er fils 3) je créé les 2 dans la même transaction

Une autre approche est d’utiliser un diagramme d’état pour obliger la création d’un objet fils avant de rendre un record père “utilisable”. Disons qu’on a 2 état “draft” et “validé” au niveau du père. Lorsqu’on créé un record père il est en état “draft” puis la transition à l’état “validé” est, elle, conditionnée par la présence d’au moins 1 objet fils (à tester dans le hook isStateTransitionEnable du père), vous devez alors mettre des règles de filtrage qui rendent les objets père non utilisables par ailleurs tant qu’ils sont en état “draft”

Dans certains cas il est possible de créer le 1er record fils avec des valeurs par défaut et/ou à partir de données (persistantes ou non) saisies au niveau du père. Dans ce cas vous devez implémenter la création du fils dans le postCreate du père (afin de ne le faire qu’une fois que le père est créé avec succès)

Etc.

Autres possibilités :

Si le lien CB est 1,n, on peut aussi mettre la CB principale dans l’objet père directement.
Et laisser le lien pour les CB secondaires en lien 0,n.

Ou mettre des champs “CB principale” non persistant (sans nom phyisique juste pour véhiculer des données entre la page et le back) et uniquement visible en création sur le père (par contrainte obj.isNew() ou dans les initCreate/initUpdate), puis peupler une ligne dans la relation 0,n lors du postCreate qui garantit que le create est bien passé pour utiliser le row_id du père créé comme clé étrangère.

Perso je ne suis pas très fan des approches où on “duplique” les champs du fils en champs (persistants ou non) dans le père car, quelque part, on “abîme” le modèle relationnel logique juste pour une question d’UX…

dire qu’un compte est obligatoire à la création c’est du métier, et tout mettre dans un seul écran est la bonne solution en terme d’UX.

Car faire un workflow draft/validé ou un screenflow est encore plus lourd en terme d’UX juste pour ça, ce serait aussi “dupliquer” en plus complexe, alors que des champs temporaires à la création c’est beaucoup plus intuitif pour l’utilisateur.

En tout cas quelle que soit l’approche retenue pour la création il faut bien mettre 1,n dans la cardinalité de la relation afin de ne pas pouvoir redescendre à mois d’un objet lié

Merci pour les propositions de solution.
Si j’opte pour les champs “non persistants”, est-ce que l’utilisateur aura la possibilité quand-même de sélectionner un CB existant (depuis l’écran de création d’une société), ou bien, il sera obligé de saisir tous les champs obligatoire à la création d’un CB et qui seront insérées comme un nouveau CB dans le postCreate ?

Je ne comprends pas votre modèle.
S’i faut pouvoir rechercher un compte c’est alors une N,N entre société et compte.
et non une 1,N

Toutes mes réponses sont alors inadaptées.

Clarifier votre besoin et revenez à un usage standard des objets. Quand votre modèle sera plus stable, on verra pour améliorer l’UX.