erd
This commit is contained in:
370
banque.erd.md
Normal file
370
banque.erd.md
Normal file
@@ -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
|
||||
```
|
||||
373
banque.md
373
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
|
||||
|
||||
|
||||
@@ -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
|
||||
|
||||
Reference in New Issue
Block a user