From 26e370819c0274b1160b0d1de29a2f4d0614f66b Mon Sep 17 00:00:00 2001 From: medina5 Date: Sat, 15 Nov 2025 13:49:09 +0100 Subject: [PATCH] erd --- banque.erd.md | 370 ++++++++++++++++++++++++++++++++++++ banque.md | 373 +------------------------------------ banque/banque.1.tables.sql | 2 +- 3 files changed, 372 insertions(+), 373 deletions(-) create mode 100644 banque.erd.md diff --git a/banque.erd.md b/banque.erd.md new file mode 100644 index 0000000..79db6ef --- /dev/null +++ b/banque.erd.md @@ -0,0 +1,370 @@ +# Le Diagramme Entités Relations (ERD) + +## 1. Les titulaires + +Un client de la banque est appelé un titulaire. Il peut être une **personne physique** ou une **entreprise**. + +- Quelles informations faut-il conserver pour tous les titulaires ? +- Quelles informations sont spécifiques à chaque type de titulaire ? +- Comment représenter cette distinction en base relationnelle ? + +> [!TIP] +> Indice : on peut utiliser une table abstraite `holder`, puis des tables `person` et `company` qui héritent logiquement de celle-ci. + +#### Pourquoi séparer `person` et `company` ? + +Parce que leurs attributs diffèrent (nom/prénom vs raison sociale). +Cela évite les **colonnes inutiles** et permet des **contraintes spécifiques** à chaque type. + +#### Quelle contrainte empêche d’insérer une person sans holder ? + +La clé étrangère `references holder(id)` dans `person`. + +```mermaid +erDiagram + person { + bigint id PK + text firstname + text lastname + date birthdate + } + + company { + bigint id PK + text name + text registration_number + date creation_date + } + + holder { + bigint id PK + timestamp creation_date + text type + } + + %% Relations + + person |o--|| holder : is + company |o--|| holder : is +``` + +## 2. Les comptes + +- Chaque titulaire peut détenir **un** ou **plusieurs comptes**. +- Un compte bancaire doit pouvoir appartenir à **un** ou **plusieurs titulaires** (compte individuel / compte joint). +- Chaque compte dispose d’un numéro de compte unique, d’un solde et d'une date d'ouverture. +- Dans le cas d'un compte joint, les parts de propriété d'un compte doivent pouvoir être précisées. + +```mermaid +erDiagram + person { + bigint id PK + text firstname + text lastname + date birthdate + } + + company { + bigint id PK + text name + text registration_number + date creation_date + } + + holder { + bigint id PK + timestamp creation_date + text type + } + + account { + bigint id PK + timestamp creation_date + decimal balance + } + + account_holder { + bigint account_id FK + bigint holder_id FK + decimal share + } + + %% Relations + + person |o--|| holder : is + company |o--|| holder : is + holder }|--|{ account_holder : a + account_holder ||--|{ account : hold +``` + +## 3. Les opérations + +```mermaid +erDiagram + person { + bigint id PK + text firstname + text lastname + date birthdate + } + + company { + bigint id PK + text name + text registration_number + date creation_date + } + + bank { + bigint id PK + text name + } + + holder { + bigint id PK + timestamp creation_date + text type + } + + account { + bigint id PK + timestamp creation_date + decimal balance + text currency_code FK + } + + account_holder { + bigint account_id FK + bigint holder_id FK + decimal share + } + + operation { + bigint id PK + bigint transaction_id FK + bigint account_id FK + decimal amount + text direction + } + + %% Relations + + person |o--|| holder : is + company |o--|| holder : is + bank |o--|| holder : is + holder }|--|{ account_holder : a + account_holder ||--|{ account : hold + operation }o--|| account : concerne +``` + +## 4. Les transactions + +#### La double écriture comptable + +Jusqu’à présent, les dépôts et retraits modifiaient directement le solde d’un compte. +Mais dans un vrai système bancaire ou comptable, chaque opération financière doit être enregistrée en double : + +- Un débit sur un compte (celui qui reçoit) +- Un crédit sur un autre (celui qui cède) + +La somme des débits doit toujours être égale à la somme des crédits. + +Chaque opération comporte au moins : + +* un **compte concerné** ; +* une **date** ; +* un **montant** ; +* un **sens** (débit ou crédit). + + +#### Méthode 1 : montant relatif (positif/négatif) + +On stocke un seul champ `montant`. + +* **Crédit** → montant positif +* **Débit** → montant négatif + +##### Exemple + +| id | compte | date | montant | +| -- | ------ | ---------- | ------- | +| 1 | 123 | 2025-11-06 | +200.00 | +| 2 | 123 | 2025-11-07 | -50.00 | + + +##### Avantages + +* **Simple à manipuler** pour les calculs (sommes, soldes, agrégations). +* Pas besoin de colonne supplémentaire pour le sens. +* Représente naturellement le comportement du solde d’un compte. + +##### Inconvénients + +* Le **signe a une signification métier** implicite → risque d’erreur d’interprétation. +* **Moins lisible** pour les utilisateurs finaux ou pour des exports comptables. +* Pas toujours compatible avec les règles de la **comptabilité en partie double** (où débit et crédit doivent être visibles séparément). + +#### Méthode 2 : deux colonnes (débit / crédit) + +Deux colonnes numériques, l’une pour le débit, l’autre pour le crédit. +Une seule des deux contient une valeur non nulle. + +##### Exemple + +| id | compte | date | debit | credit | +| -- | ------ | ---------- | ----- | ------ | +| 1 | 123 | 2025-11-06 | 0.00 | 200.00 | +| 2 | 123 | 2025-11-07 | 50.00 | 0.00 | + +##### Avantages + +* Très **clair visuellement** et **conforme aux usages comptables**. +* Facilite les **exports vers des logiciels comptables**. +* On peut facilement filtrer les débits et crédits séparément. + +##### Inconvénients + +* **Redondance potentielle** (une des deux colonnes sera toujours à zéro). +* Les calculs de soldes nécessitent des **expressions plus complexes** : + `SUM(credit) - SUM(debit)` +* Risque d’incohérence si les deux colonnes contiennent des valeurs remplies par erreur. + +#### Méthode 3 : montant absolu + colonne sens ('D' / 'C') + +Le montant est toujours positif. +Le sens est indiqué par une lettre (`D` ou `C`). + +##### Exemple + +| id | compte | date | montant | sens | +| -- | ------ | ---------- | ------- | ---- | +| 1 | 123 | 2025-11-06 | 200.00 | C | +| 2 | 123 | 2025-11-07 | 50.00 | D | + + +##### Avantages + +* **Lisible** et **intuitif** : correspond au vocabulaire métier. +* Facilite la lecture humaine et les exports comptables. +* Pas d’ambiguïté sur le signe numérique. + +##### Inconvénients + +* Nécessite une **jointure logique** du sens pour les calculs : + `SUM(CASE WHEN sens='C' THEN montant ELSE -montant END)` +* Moins direct pour les traitements purement mathématiques. +* L’usage de lettres rend le **stockage un peu moins compact** (mais négligeable en pratique). + + +#### Méthode 4 : montant absolu + colonne sens numérique (1 / -1) + +Le montant est toujours positif, et une colonne numérique `sens` vaut `1` (crédit) ou `-1` (débit). + +##### Exemple + +| id | compte | date | montant | sens | +| -- | ------ | ---------- | ------- | ---- | +| 1 | 123 | 2025-11-06 | 200.00 | 1 | +| 2 | 123 | 2025-11-07 | 50.00 | -1 | + +##### Avantages + +* **Compact et performant** pour les calculs : + `SUM(montant * sens)` donne directement le solde. +* Moins d’ambiguïté qu’un signe caché dans le montant. +* Combine la **rigueur du modèle mathématique** avec la **clarté du stockage absolu**. + +##### Inconvénients + +* **Moins lisible** pour un utilisateur non technique. +* Moins standard pour la comptabilité classique (on préfère `D` / `C`). +* Nécessite une convention claire sur la signification de `1` et `-1`. + +#### Synthèse comparative + +| Méthode | Structure | Lisibilité | Facilité calculs | Conformité comptable | Risque d'erreur | +| ------- | ---------------------- | ------------| ---------------- | -------------------- | --------------- | +| 1 | montant relatif (+/-) | ★☆☆ | ★★★ | ★☆☆ | Moyen | +| 2 | débit / crédit séparés | ★★★ | ★☆☆ | ★★★ | Faible | +| 3 | valeur + sens 'D'/'C' | ★★★ | ★★☆ | ★★★ | Faible | +| 4 | valeur + sens 1/-1 | ★★☆ | ★★★ | ★★☆ | Moyen | + + +## 5. Les devises + +```mermaid +erDiagram + person { + bigint id PK + text firstname + text lastname + date birthdate + } + + company { + bigint id PK + text name + text registration_number + date creation_date + } + + bank { + bigint id PK + text name + } + + holder { + bigint id PK + timestamp creation_date + text type + } + + account { + bigint id PK + timestamp creation_date + decimal balance + text currency_code FK + } + + account_holder { + bigint account_id PK,FK + bigint holder_id PK,FK + decimal share + } + + currency { + text code PK + } + + exchange_rate { + date date PK + text currency_code PK,FK + decimal rate + } + + transaction { + bigint id PK + timestamp transaction_date + decimal amount + } + + operation { + bigint id PK + bigint transaction_id FK + bigint account_id FK + decimal amount + text direction + } + + %% Relations + + person |o--|| holder : is + company |o--|| holder : is + bank |o--|| holder : is + holder }|--|{ account_holder : a + account_holder ||--|{ account : hold + currency ||--|{ account : tenu + exchange_rate }o--|| currency : a + transaction ||--|{ operation : a + operation }o--|| account : a +``` diff --git a/banque.md b/banque.md index 3283454..6994ae1 100644 --- a/banque.md +++ b/banque.md @@ -22,378 +22,7 @@ La diffusion de cette application est internationale, vous vous efforcerez d'uti Pour les entités vous utiliserez le singuler et écrirez le tout en minuscule. -## Séance 1 : Le Diagramme Entités Relations (ERD) - -### 1. Les titulaires - -Un client de la banque est appelé un titulaire. Il peut être une **personne physique** ou une **entreprise**. - -- Quelles informations faut-il conserver pour tous les titulaires ? -- Quelles informations sont spécifiques à chaque type de titulaire ? -- Comment représenter cette distinction en base relationnelle ? - -> [!TIP] -> Indice : on peut utiliser une table abstraite `holder`, puis des tables `person` et `company` qui héritent logiquement de celle-ci. - -#### Pourquoi séparer `person` et `company` ? - -Parce que leurs attributs diffèrent (nom/prénom vs raison sociale). -Cela évite les **colonnes inutiles** et permet des **contraintes spécifiques** à chaque type. - -#### Quelle contrainte empêche d’insérer une person sans holder ? - -La clé étrangère `references holder(id)` dans `person`. - -```mermaid -erDiagram - person { - bigint id PK - text firstname - text lastname - date birthdate - } - - company { - bigint id PK - text name - text registration_number - date creation_date - } - - holder { - bigint id PK - timestamp creation_date - text type - } - - %% Relations - - person |o--|| holder : is - company |o--|| holder : is -``` - -### 2. Les comptes - -- Chaque titulaire peut détenir **un** ou **plusieurs comptes**. -- Un compte bancaire doit pouvoir appartenir à **un** ou **plusieurs titulaires** (compte individuel / compte joint). -- Chaque compte dispose d’un numéro de compte unique, d’un solde et d'une date d'ouverture. -- Dans le cas d'un compte joint, les parts de propriété d'un compte doivent pouvoir être précisées. - -```mermaid -erDiagram - person { - bigint id PK - text firstname - text lastname - date birthdate - } - - company { - bigint id PK - text name - text registration_number - date creation_date - } - - holder { - bigint id PK - timestamp creation_date - text type - } - - account { - bigint id PK - timestamp creation_date - decimal balance - } - - account_holder { - bigint account_id FK - bigint holder_id FK - decimal share - } - - %% Relations - - person |o--|| holder : is - company |o--|| holder : is - holder }|--|{ account_holder : a - account_holder ||--|{ account : hold -``` - -### 3. Les opérations - -```mermaid -erDiagram - person { - bigint id PK - text firstname - text lastname - date birthdate - } - - company { - bigint id PK - text name - text registration_number - date creation_date - } - - bank { - bigint id PK - text name - } - - holder { - bigint id PK - timestamp creation_date - text type - } - - account { - bigint id PK - timestamp creation_date - decimal balance - text currency_code FK - } - - account_holder { - bigint account_id FK - bigint holder_id FK - decimal share - } - - operation { - bigint id PK - bigint transaction_id FK - bigint account_id FK - decimal amount - text direction - } - - %% Relations - - person |o--|| holder : is - company |o--|| holder : is - bank |o--|| holder : is - holder }|--|{ account_holder : a - account_holder ||--|{ account : hold - operation }o--|| account : concerne -``` - -### 4. Les transactions - -#### La double écriture comptable - -Jusqu’à présent, les dépôts et retraits modifiaient directement le solde d’un compte. -Mais dans un vrai système bancaire ou comptable, chaque opération financière doit être enregistrée en double : - -- Un débit sur un compte (celui qui reçoit) -- Un crédit sur un autre (celui qui cède) - -La somme des débits doit toujours être égale à la somme des crédits. - -Chaque opération comporte au moins : - -* un **compte concerné** ; -* une **date** ; -* un **montant** ; -* un **sens** (débit ou crédit). - - -#### Méthode 1 : montant relatif (positif/négatif) - -On stocke un seul champ `montant`. - -* **Crédit** → montant positif -* **Débit** → montant négatif - -##### Exemple - -| id | compte | date | montant | -| -- | ------ | ---------- | ------- | -| 1 | 123 | 2025-11-06 | +200.00 | -| 2 | 123 | 2025-11-07 | -50.00 | - - -##### Avantages - -* **Simple à manipuler** pour les calculs (sommes, soldes, agrégations). -* Pas besoin de colonne supplémentaire pour le sens. -* Représente naturellement le comportement du solde d’un compte. - -##### Inconvénients - -* Le **signe a une signification métier** implicite → risque d’erreur d’interprétation. -* **Moins lisible** pour les utilisateurs finaux ou pour des exports comptables. -* Pas toujours compatible avec les règles de la **comptabilité en partie double** (où débit et crédit doivent être visibles séparément). - -#### Méthode 2 : deux colonnes (débit / crédit) - -Deux colonnes numériques, l’une pour le débit, l’autre pour le crédit. -Une seule des deux contient une valeur non nulle. - -##### Exemple - -| id | compte | date | debit | credit | -| -- | ------ | ---------- | ----- | ------ | -| 1 | 123 | 2025-11-06 | 0.00 | 200.00 | -| 2 | 123 | 2025-11-07 | 50.00 | 0.00 | - -##### Avantages - -* Très **clair visuellement** et **conforme aux usages comptables**. -* Facilite les **exports vers des logiciels comptables**. -* On peut facilement filtrer les débits et crédits séparément. - -##### Inconvénients - -* **Redondance potentielle** (une des deux colonnes sera toujours à zéro). -* Les calculs de soldes nécessitent des **expressions plus complexes** : - `SUM(credit) - SUM(debit)` -* Risque d’incohérence si les deux colonnes contiennent des valeurs remplies par erreur. - -#### Méthode 3 : montant absolu + colonne sens ('D' / 'C') - -Le montant est toujours positif. -Le sens est indiqué par une lettre (`D` ou `C`). - -##### Exemple - -| id | compte | date | montant | sens | -| -- | ------ | ---------- | ------- | ---- | -| 1 | 123 | 2025-11-06 | 200.00 | C | -| 2 | 123 | 2025-11-07 | 50.00 | D | - - -##### Avantages - -* **Lisible** et **intuitif** : correspond au vocabulaire métier. -* Facilite la lecture humaine et les exports comptables. -* Pas d’ambiguïté sur le signe numérique. - -##### Inconvénients - -* Nécessite une **jointure logique** du sens pour les calculs : - `SUM(CASE WHEN sens='C' THEN montant ELSE -montant END)` -* Moins direct pour les traitements purement mathématiques. -* L’usage de lettres rend le **stockage un peu moins compact** (mais négligeable en pratique). - - -#### Méthode 4 : montant absolu + colonne sens numérique (1 / -1) - -Le montant est toujours positif, et une colonne numérique `sens` vaut `1` (crédit) ou `-1` (débit). - -##### Exemple - -| id | compte | date | montant | sens | -| -- | ------ | ---------- | ------- | ---- | -| 1 | 123 | 2025-11-06 | 200.00 | 1 | -| 2 | 123 | 2025-11-07 | 50.00 | -1 | - -##### Avantages - -* **Compact et performant** pour les calculs : - `SUM(montant * sens)` donne directement le solde. -* Moins d’ambiguïté qu’un signe caché dans le montant. -* Combine la **rigueur du modèle mathématique** avec la **clarté du stockage absolu**. - -##### Inconvénients - -* **Moins lisible** pour un utilisateur non technique. -* Moins standard pour la comptabilité classique (on préfère `D` / `C`). -* Nécessite une convention claire sur la signification de `1` et `-1`. - -#### Synthèse comparative - -| Méthode | Structure | Lisibilité | Facilité calculs | Conformité comptable | Risque d'erreur | -| ------- | ---------------------- | ------------| ---------------- | -------------------- | --------------- | -| 1 | montant relatif (+/-) | ★☆☆ | ★★★ | ★☆☆ | Moyen | -| 2 | débit / crédit séparés | ★★★ | ★☆☆ | ★★★ | Faible | -| 3 | valeur + sens 'D'/'C' | ★★★ | ★★☆ | ★★★ | Faible | -| 4 | valeur + sens 1/-1 | ★★☆ | ★★★ | ★★☆ | Moyen | - - -### 5. Les devises - -```mermaid -erDiagram - person { - bigint id PK - text firstname - text lastname - date birthdate - } - - company { - bigint id PK - text name - text registration_number - date creation_date - } - - bank { - bigint id PK - text name - } - - holder { - bigint id PK - timestamp creation_date - text type - } - - account { - bigint id PK - timestamp creation_date - decimal balance - text currency_code FK - } - - account_holder { - bigint account_id PK,FK - bigint holder_id PK,FK - decimal share - } - - currency { - text code PK - } - - exchange_rate { - date date PK - text currency_code PK,FK - decimal rate - } - - transaction { - bigint id PK - timestamp transaction_date - decimal amount - } - - operation { - bigint id PK - bigint transaction_id FK - bigint account_id FK - decimal amount - text direction - } - - %% Relations - - person |o--|| holder : is - company |o--|| holder : is - bank |o--|| holder : is - holder }|--|{ account_holder : a - account_holder ||--|{ account : hold - currency ||--|{ account : tenu - exchange_rate }o--|| currency : a - transaction ||--|{ operation : a - operation }o--|| account : a -``` - ---- +- Séance 1 : [Le schéma Entités-Relations](banque.erd.md) # Séance 2 : Implémentation du modèle diff --git a/banque/banque.1.tables.sql b/banque/banque.1.tables.sql index a88448a..4e16341 100644 --- a/banque/banque.1.tables.sql +++ b/banque/banque.1.tables.sql @@ -300,7 +300,7 @@ from holder h create or replace view account_detail as select a.balance, a.balance * ah.share as balance_currency, - a.balance * ah.share / latest_exchange_rate(a.currency_code), + a.balance * ah.share / latest_exchange_rate(a.currency_code, current_date), a.currency_code, hd.nom from account a