Salut,
Pour les entités TIRAGE et REPARTITION_TIRAGE ==> n'est-ce pas mieux de passer numeroTirage, numeroRepartition en Counter ?
Ce qui donnera ceci :
Salut,
Pour les entités TIRAGE et REPARTITION_TIRAGE ==> n'est-ce pas mieux de passer numeroTirage, numeroRepartition en Counter ?
Ce qui donnera ceci :
Bonsoir,
Attention, avec COUNTER le numéro attribué sera unique pour toute la table et pas pour un emprunt donné.
Par conséquent, numeroTirage et numeroRepartition seront uniques et n'ont pas besoin de l'identifiant relatif pour assurer cette unicité.
Se pose alors la question du non respect de l'irréductibilité (clé minimale)... On obtient une surclé, et c'est à éviter pour une clé primaire.
De plus, il me semble que le numéro de tirage fait partie du SI et doit donc être contrôlé par l'application ; or, le type COUNTER génère automatiquement des clés que l'on ne contrôle pas toujours très bien en cas de modification, de suppression d'enregistrements, ...
Bonsoir Paprick,
Merci pour ce retour, donc je retour au type initial, en les mettant comme entier. Voici la version corrigée :
Bonsoir Malick
Je continue de penser que le type d'entité [REPARTITION TIRAGE] n'a pas d'intérêt et doit être absorbé dans [TIRAGE]
Exemple :
- emprunt de 100 000 € attribué en 3 tirages
- 1er tirage de 40 000 € octroyés à 40% par le Crédit Agricole et 60% par LCL
- 2e tirage de 25 000 € octroyés à 20% par le Crédit Agricole et 80% par la BNP
- 3e et dernier tirage de 35 000 € octroyé à 100 % par la BNP
Au niveau des instances d'entité-type on aura
- 1 seule occurrence d'[EMPRUNT] avec sa date, son montant de 100 000 €, son taux et sa durée
- 3 occurrences de [TIRAGE], la 1re occurrence pour un montant de 40 000 avec sa date, la deuxième pour un montant de 25 000 avec sa date et la troisième pour le solde de 35 000 avec également sa date
Au niveau des instances d'association on aura
- 5 occurrences d'(octroyer), association qui sera donc liée à [PRETEUR] d'un côté et [TIRAGE] de l'autre :
1re occurrence en lien avec le 1er [TIRAGE] avec un montant (attribut à ajouter dans l'association) de 16 000 € et un % de 40% pour ce qui concerne le Crédit Agricole2e occurrence en lien avec le 1er [TIRAGE] avec un montant de 24 000 € et un % de 60% pour ce qui concerne LCL3e occurrence en lien avec le 2e [TIRAGE]avec un montant de 5 000 € et un % de 20% pour ce qui concerne le Crédit Agricole4e occurrence en lien avec le 2e [TIRAGE]avec un montant de 20 000 € et un % de 80% pour ce qui concerne la BNP5e occurrence en lien avec le 3e [TIRAGE]avec un montant de 35 000 € et un % de 100% pour ce qui concerne la BNP
Bonsoir escartefigue,
Merci pour cette remarque. Cela donnera donc ceci :
Bonjour Malick
La règle de gestion
et le MCD sont cohérents, mais... tout projet fait il l'objet d'au moins un emprunt ?R1 : un projet est concerné par un ou plusieurs emprunts
N'y a -t- il jamais de projet autofinancé ?
Auquel cas, la règle serait
et la cardinalité deviendrait 0,nR1 : un projet peut être concerné parun ouplusieurs emprunts
Entité-type EMPRUNT
Si la durée d'un emprunt est toujours exprimée selon la même unité de mesure, par exemple en mois, alors c'est OK, sinon, il faut créer une nouvelle entité-type [UNITE_DUREE] et établir l'association
[EMPRUNT] 1,1 --- mesurer --- 0,n [UNITE_DUREE]
Tous les emprunts sont ils exprimés en € ?, sinon il faut également créer une nouvelle entité-type [DEVISE] et établir l'association
[EMPRUNT] 1,1 --- exprimer --- 0,n [DEVISE]
La durée d'emprunt utilisant un type de données "double" est adapté si tu souhaites souscrire des emprunts sur plusieurs millions d'années , sinon un type decimal(3,0) par exemple devrait suffire
Association COMPREND
La cardinalité mini 1 côté emprunt signifie qu'un emprunt ne pourra être connu dans la base de données qu'à partir du moment où il aura fait l'objet d'au moins un tirage. Est-ce bien ce qui est souhaité ?
Bonsoir escartefigue,
Effectivement il est plus prudent d'intégrer cette possibilité. Je modifie donc la cardinalité suivant ta proposition
La durée d'un emprunt sera toujours exprimée en année. Je peux donc ne pas créer l'entité-type [UNITE_DUREE]
Bien vu On peut avoir des emprunts en Dollar ou en Euros ==> donc ok pour créer l'entité-type [DEVISE]
Lol, j'ai corrigé.
Non ce n'est pas le souhait Un emprunt peut exister sans qu'un tirage ne soit encore effectué. J'ai corrigé pour mettre 0 comme mini.
Voici le MCD corrigé suivant les remarques. Qu'en pensez-vous ? Merci d'avance
Sauf que sur le MCD, la card mini est restée à 1, donc toujours pas de projet auto-financé
Par ailleurs, la cardinalité maxi n de [EMPRUNT] vers (exprimer) autorise des emprunts multi-devises, est-ce bien ce qui est autorisé ?
Dans les tables de typologie (devises, pays, ou autres) on a en général un code en plus du libellé et éventuellement une date de début et de fin de validité (utile par exemple lors du passage du Franc Français à l'Euro )
Pour les codes, il est recommandé d'utiliser les codes ISO (par exemple EUR pour l'euro. Cf. norme ISO 4217)
Le montant tirage n'a d'intérêt que s'il peut être différent de la somme des montants octroyés pour le tirage. Si par exemple tu demandes un premier tirage de 40 000 € mais que les préteurs versent des montants correspondants à leur % respectifs qui ne font pas exactement 40 000 (peut être à cause des arrondis ou de frais retirés du montant octroyé ou que sais-je encore). Si la somme des montant octroyés est toujours égale au montant du tirage, alors un seul des deux attributs suffit.
Pour le reste, ça me semble ok
Salut,
Merci escartefigue encore , j'ai appliqué les corrections conformément aux remarques très justes et pertinentes.
Est-ce que l'attribut datePaiement de l'association Octroyer ne devrait pas également être intégré à l'entité-type [Tirage] ?
Voici le nouveau modèle sous réserve de ma question ci-dessus :
Si c'est un nombre entier d'années, le type entier est alors préférable.La durée d'un emprunt sera toujours exprimée en année.
Ca dépend : si le "tirage" est la demande faite par l'entreprise aux banques pour que ces dernières versent la somme demandée, alors, il est en théorie possible que la date du tirage ne soit pas la même que celle de l'octroi, et en ce cas, les deux dates sont requises.
C'est le même raisonnement que pour le montant du tirage et la somme des montants octroyés : on ne conserve que les attributs non redondants.
Pour le code devise, il est inutile de prévoir du char(50).
Comme mentionné plus haut, il est préférable d'appliquer la codification ISO (en l'occurrence l'ISO 4217 pour les devises) et le type associé (en l'occurrence char(3).
Pour le prêteur, il est sans doute intéressant de connaître le code BIC ou SWIFT, le RIB émetteur, le code IBAN...
Salut,
Merci CinePhil, je viens d'appliquer la remarque
J'ai gardé la date pour l'envoi de la demande de tirage et la date de paiement. Pour le montant, pas besoin donc puisque c'est exactement la demande qui est payée.
J'ai corrigé cela.
Je ne pense pas, cette information je n'en ai pas besoin pour mon suivi.
Voici le modèle corrigé :
Qu'en pensez-vous ?
et bonne nuit
Ca me paraît bien
D'où vient la référence du tirage ? Est-ce une information communiquée par le prêteur ?
Salut,
Merci escartefigue
Je l'ai passé en Texte avec option "Volumeux".
Avec Looping, j'ai ceci pour le choix des typess :
Le modèle corrigé :
bonsoir Malick
Ce qu'il faut savoir c'est quelle est la longueur effective des éléments transmis par le préteur, si cette longueur est toujours la même ou pas et enfin, si pour une même ligne dans la table, elle est susceptible de varier.
En fonction des réponses à ces questions, il sera judicieux d'utiliser du variable ou du fixe ou - mais c'est très peu probable - du volumineux
Il s'agit juste des références de la demande, exemple : Tirage 004/2020/BanqueA
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Partager