# 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
```