erd

2025-11-15 13:49:09 +01:00
parent b9429d1c80
commit 26e370819c
3 changed files with 372 additions and 373 deletions
--- a/banque.erd.md
+++ 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
+```