feat: Add DictionnaryTable component and TermsTable data

app/pages/docs/merise/dictionnaire-de-donnees/+Page.mdx

@@ -0,0 +1,101 @@
+---
+title: Dictionnaire de Données Merise
+description: Explorez le dictionnaire de données dans Merise, essentiel pour structurer et documenter les informations de votre système.
+tags: [Backend, Merise, BDD, MCD, MLD, MPD, SQL]
+---
+
+import DictionnaryTable from "./DictionnaryTable";
+import Callout from "@/components/Callout";
+
+Le **dictionnaire de données** est un document qui contient toutes les informations sur les données qui vont être stockées dans la future base de données.
+
+Ici, on ne va pas parler de tables, de colonnes ou de relations, mais uniquement de **données**. Ces informations nous sont données par le client, et il est important que le dictionnaire reste compréhensible par le client.
+
+En gros : Le dictionnaire de données se veut **non technique** et **compréhensible par le client**.
+
+Pour cet article et les suivants, on va se reposer sur une mise en situation fictive pour un contexte d'organisation d'un groupe de musique. _(Rassure-toi, pas besoin d'être musicien pour comprendre !)_
+
+## Brief avec le client
+
+Le client est un groupe qui doit faciliter l'organisation interne pour la gestion de ses différentes activités (répétitions, concerts, etc.).  
+Il souhaite donc créer une application pour gérer les informations suivantes :
+
+- **Musicien** : Nom, prénom, instruments, adresse e-mail, mot de passe
+- **Concert** : Date et heure, lieu, tarif
+- **Répétition** : Date et heure, lieu
+
+Le client a aussi précisé que le mot de passe doit faire plus de 12 caractères, et que l'adresse e-mail doit être unique.
+
+En ce qui concerne les répétitions et les concerts, il nous a indiqué que tous les musiciens ne sont pas forcément présents à chaque répétition ou concert.  
+Il faut donc prévoir un moyen pour savoir qui est présent à chaque répétition et concert.
+
+Pour le moment, on ne va pas se soucier de la technique, mais juste de lister les données que l'on doit stocker dans la base de données.
+On va donc créer un tableau qui va nous permettre de lister toutes les données que l'on doit stocker dans notre base de données.
+
+## Informations du dictionnaire de données
+
+Avant de créer notre dictionnaire de données, regardons un peu ce qu'on peut y mettre :
+
+- **Nom** : Nom de la donnée que l'on va stocker dans la base de données
+- **Format** : Format de la donnée que l'on va stocker dans la base de données _(on y revient juste après !)_
+- **Longueur** : Longueur de la donnée que l'on va stocker dans la base de données
+- **Contraintes** : Contraintes sur la donnée que l'on va stocker dans la base de données
+- **Document** : Document qui contient la donnée que l'on va stocker dans la base de données, un "groupe de données"
+
+### Les différents formats
+
+Rappelons-nous que le dictionnaire de données doit rester compréhensible par le client. Du moins, dans un premier temps.  
+Rien ne nous empêche de le rendre technique par la suite, cependant comme nous sommes en phase de conception : on doit rester simple.
+
+Voici les différents formats que l'on peut utiliser dans le dictionnaire de données :
+
+- **Alphabétique** _(Chaîne de caractères, uniquement A-Z)_
+- **Alphanumérique** _(Chaîne de caractères, A-Z et 0-9)_
+- **Numérique** _(Entier/flottant etc)_
+- **Date**
+- **Logique** _(Vrai/Faux)_
+
+Et c'est tout ! On ne parle surtout pas de types de données techniques comme `VARCHAR`, `INT`, `FLOAT`, etc.  
+Le client n'a pas besoin de savoir ce que c'est, et on ne va pas lui en parler _(et s'il est vraiment curieux, il pourra consulter le futur **MPD**)_.
+
+### Contraintes
+
+Pour les contraintes, on reprendra les informations que l'on a récupérées dans le brief avec le client.  
+Si le client nous dit qu'une certaine donnée est obligatoire, on peut l'indiquer dans le dictionnaire de données. De même pour les valeurs par défaut, les valeurs uniques, etc.
+
+Cependant, on n'ira pas plus loin sur ce terrain pour maintenir une compréhension simple par le client ! Que je ne te surprenne pas à lui dire :
+
+> Alors là j'ai mis des ID en AUTO_INCREMENT, des clés primaires et étrangères, et j'ai mis des contraintes d'unicité sur les colonnes !
+
+Tu risques de retrouver ton client en train de convulser sur le sol : **pas glop**.
+
+## Notre dictionnaire de données
+
+Voici donc le dictionnaire de données que l'on va créer pour notre application :
+
+<DictionnaryTable />
+
+Voilà, on a notre dictionnaire de données !
+
+Faisons quand même un petit point sur les données que l'on a récupérées et la façon dont on les a représentées.
+
+<Callout type="note" title="Retour rapide sur le dictionnaire de données">
+  Dans certains cas, on a précisé des longueurs de données. On l'a fait uniquement pour des données textuelles _(Alphabétiques et Alphanumériques)_.
+
+  Au niveau des contraintes, on a majoritairement _(sauf pour le tarif d'un concert)_ mis des contraintes d'obligation sur les données.
+  On a aussi mis une contrainte d'unicité sur l'adresse e-mail, car il ne peut pas y avoir deux membres avec la même adresse e-mail.
+
+  Dans certains cas, on a mis des contraintes de longueur sur les données. On a fait ça pour éviter de stocker des données trop longues dans la base de données.  
+  Bien entendu, une date ne peut pas avoir de longueur, on a donc mis un tiret pour indiquer que ce n'est pas applicable.
+
+  Pour le mot de passe, on a mis une contrainte de longueur supérieure à 12 caractères.  
+  Évidemment on ne viendra pas stocker le mot de passe en clair dans la base de données, on va utiliser la donnée réelle _(non transformée)_ pour éviter de perdre le client entre la longueur réelle du mot de passe et la longueur de son hash.
+</Callout>
+
+## Conclusion
+
+Voilà, on a créé notre dictionnaire de données pour notre application de gestion de groupe de musique.
+
+Pour le moment ça ne nous permet pas de créer notre base de données, mais au moins on a une bonne idée de ce que l'on doit stocker dans la base de données !
+
+Pour la suite, on va se pencher sur le **MCD** _(Modèle Conceptuel de Données)_ qui va nous permettre de modéliser les données que l'on vient de récupérer et formaliser.

app/pages/docs/merise/dictionnaire-de-donnees/DictionnaryTable.tsx

@@ -0,0 +1,87 @@
+export default function DictionnaryTable() {
+	return (
+		<table class="block max-w-full overflow-x-auto border-collapse text-sm">
+			<thead>
+				<tr>
+					<th scope="col">Nom de la donnée</th>
+					<th scope="col">Format</th>
+					<th scope="col">Longueur</th>
+					<th scope="col">Contraintes</th>
+					<th scope="col">Document</th>
+				</tr>
+			</thead>
+			<tbody>
+				<tr>
+					<td>Nom</td>
+					<td>Alphabétique</td>
+					<td>30</td>
+					<td>Obligatoire</td>
+					<td>Musicien</td>
+				</tr>
+				<tr>
+					<td>Prénom</td>
+					<td>Alphabétique</td>
+					<td>30</td>
+					<td>Obligatoire</td>
+					<td>Musicien</td>
+				</tr>
+				<tr>
+					<td>Instruments</td>
+					<td>Alphabétique</td>
+					<td>30</td>
+					<td>Obligatoire</td>
+					<td>Musicien</td>
+				</tr>
+				<tr>
+					<td>Adresse e-mail</td>
+					<td>Alphanumérique</td>
+					<td>50</td>
+					<td>Obligatoire, unique</td>
+					<td>Musicien</td>
+				</tr>
+				<tr>
+					<td>Mot de passe</td>
+					<td>Alphanumérique</td>
+					<td>&gt; 12</td>
+					<td>Obligatoire</td>
+					<td>Musicien</td>
+				</tr>
+				<tr>
+					<td>Date et heure de concert</td>
+					<td>Date</td>
+					<td>-</td>
+					<td>Obligatoire</td>
+					<td>Concert</td>
+				</tr>
+				<tr>
+					<td>Lieu de concert</td>
+					<td>Alphabétique</td>
+					<td>50</td>
+					<td>Obligatoire</td>
+					<td>Concert</td>
+				</tr>
+				<tr>
+					<td>Tarif</td>
+					<td>Numérique</td>
+					<td>-</td>
+					<td>-</td>
+					<td>Concert</td>
+				</tr>
+				<tr>
+					<td>Date et heure de répétition</td>
+					<td>Date</td>
+					<td>-</td>
+					<td>Obligatoire</td>
+					<td>Répétition</td>
+				</tr>
+				<tr>
+					<td>Lieu de répétition</td>
+					<td>Alphabétique</td>
+					<td>50</td>
+					<td>Obligatoire</td>
+					<td>Répétition</td>
+				</tr>
+			</tbody>
+		</table>
+	);
+}

app/pages/docs/merise/mcd/+Page.mdx

@@ -0,0 +1,194 @@
+---
+title: Modèle Conceptuel de Données (MCD) Merise
+description: Comprenez le MCD dans Merise, une étape clé pour représenter les données de manière abstraite et cohérente.
+tags: [Backend, Merise, BDD, MCD, MLD, MPD, SQL]
+---
+
+import DictionnaryTable from "../dictionnaire-de-donnees/DictionnaryTable";
+import Callout from "@/components/Callout";
+import TermsTable from "./TermsTable";
+
+On va enfin pouvoir commencer à réaliser notre premier schéma : le **MCD** _(Modèle Conceptuel de Données)_ !
+
+Mais déjà... qu'est-ce que c'est que ce MCD ?
+
+## Qu'est-ce que le MCD ?
+
+Le **MCD** est un schéma qui va nous permettre de représenter les données que l'on a récupérées dans le dictionnaire de données.
+
+Il va nous permettre de représenter les différentes données que l'on a, regroupée dans un rectangle nommé **entité**, ainsi que les relations entre elles.  
+On devra également indiquer les **cardinalités** de chaque relation entre les **entités**.
+
+Tout comme le dictionnaire de données, ce schéma doit rester compréhensible par le client.  
+Il doit donc être le plus simple possible, et ne pas contenir de détails techniques.
+
+Pour ce schéma _(ainsi que les suivants)_, on va utiliser le logiciel **Looping**.
+
+## Définitions
+
+Tu l'auras remarqué, ici on ne parle pas de "table" ou de "colonne".  
+On va exploiter d'autres termes comme **entité**, **attribut** ou **relation**.
+
+Voici un petit lexique pour t'aider à comprendre :
+
+<TermsTable />
+
+C'est tout un lexique à apprendre, mais pas de panique tu vas vite t'y habituer !
+
+## Exemple de MCD
+
+Forcément, les définitions sans donner un exemple ça n'aide pas beaucoup à comprendre...  
+Voici un petit exemple tout simple de MCD pour illustrer tout ça :
+
+![Exemple de MCD](/images/merise/mcd-basic.webp)
+
+On a ici un MCD qui représente trois **entités** :
+
+- **Entité 1**
+- **Entité 2**
+- **Entité 3**
+
+Chacune de ces entités a plusieurs **attributs** qui lui sont propres :
+
+- **Entité 1** : code identité 1, attribut 2, attribut 3
+- **Entité 2** : code identité 2, attribut 2, attribut 3
+- **Entité 3** : code identité 3, attribut 2, attribut 3
+
+<Callout type="question" title="Pourquoi le premier attribut est en gras et souligné ?">
+  Dans le MCD, un attribut en gras est un attribut **unique**.  
+  S'il est souligné en plus d'être en gras, c'est qu'il s'agit d'un **discriminant** _(ou déterminant/identifiant)_.
+
+  Il permet d'identifier de manière unique une entité.  
+  Comme le MCD n'est **pas technique**, on n'utilisera pas le terme de **clé primaire** ou **ID**.
+</Callout>
+
+Et pour terminer, on remarque aussi que certaines de nos entités sont reliées entre elles par des **relations**.  
+Les relations se caractèrisent par :
+
+- Une bulle ovale ou arrondie contenant un verbe à l'infinitif _(par exemple : "posséder")_
+- Des **cardinalités** qui vont indiquer le nombre d'occurrences d'une entité par rapport à une autre.
+
+Ici, on a :
+
+- **Entité 1** 0,N - Contenir - 0,N **Entité 2**
+- **Entité 1** 1,1 - Posséder - 0,N **Entité 3**
+
+Mais qu'est-ce que ça veut dire tout ça ?
+
+## Les cardinalités
+
+Les cardinalités sont un élément essentiel du MCD.
+Elles vont nous permettre de définir le nombre d'occurrences d'une entité par rapport à une autre.
+
+Une cardinalité est définie par deux valeurs :
+
+1. Le **minimum** d'occurrences
+2. Le **maximum** d'occurrences
+
+On va donc avoir des cardinalités de la forme : **X,Y**.
+
+Toujours dans l'exemple précédent, on comprend donc que :
+
+- **Entité 1** peut contenir entre 0 et N **Entité 2**
+- **Entité 2** peut être contenue entre 0 et N **Entité 1**
+- **Entité 1** doit posséder 1 et 1 seule **Entité 3**
+- **Entité 3** peut être possédée entre 0 et N **Entité 1**
+
+<Callout type="note" title="Les différentes valeurs">
+  La plupart du temps, nous allons retrouver les valeurs suivantes :
+
+  - **0**
+  - **1**
+  - **N**
+
+  **N** signifie "N'importe quel nombre" _(0, 1, 2, 3, ...)_.  
+  Mais dès que l'on connait le nombre exact, on peut le mettre à la place de **N**.
+
+  Par exemple : **1,5** signifie "1 à 5" et **0,3** signifie "0 à 3".
+
+  Si la valeur n'est pas connue à l'avance ou qu'aucune limite n'est nécessaire, on utilisera alors **N**.
+</Callout>
+
+## Retour sur notre dictionnaire de données
+
+Maintenant que l'on sait comment fonctionne un MCD, on va pouvoir retourner sur notre dictionnaire de données pour le formaliser en MCD.
+
+Pour rappel, voici notre dictionnaire de données :
+
+<DictionnaryTable />
+
+### Les entités
+
+On va donc créer trois entités :
+
+- **Musicien**
+- **Concert**
+- **Répétition**
+
+Ces entités vont contenir les attributs que l'on a récupérés dans le dictionnaire de données.
+
+On se retrouve pour le moment avec un MCD qui ressemble à ça :
+![MCD avec uniquement les entités](/images/merise/mcd-1.webp)
+
+On est déjà pas trop mal, il nous reste plus qu'à ajouter les relations entre les entités et les cardinalités !
+
+### Les relations
+
+On va donc ajouter les relations entre les entités.
+
+Sachant qu'un musicien peut participer à plusieurs concerts, et qu'un concert peut avoir plusieurs musiciens, on va créer une relation entre les deux entités.
+On va donc créer une relation **"Participer"** entre les entités **Musicien** et **Concert**.
+
+On en fera une relation **0,N** - **1,N**.
+
+Pour la répétition, on va faire la même chose !
+On va créer une relation **"Répéter"** entre les entités **Musicien** et **Répétition**.
+
+À la fin, on se retrouve avec un MCD qui ressemble à ça :
+![MCD avec les relations](/images/merise/mcd-2.webp)
+
+Et c'est tout ! Notre MCD est terminé... enfin presque !
+
+### Aller plus loin
+
+Si on souhaite aller plus loin, on peut ajouter de l'héritage.
+
+<Callout type="note" title="Rapide point sur l'héritage">
+  L'héritage _(ou aussi appelé **spécialisation** ou **généralisation**)_ est un concept qui va nous permettre de factoriser les propriétés identiques dans une entité commune. Cette entitée est appelée **entité générique** _(ou **sur-type**)_.
+
+  Les entités qui héritent de l'entité générique sont appelées **entités spécialisées** _(ou **sous-types**)_.
+</Callout>
+
+En regardant bien notre MCD, on se rend compte que les entités **Concert** et **Répétition** ont des attributs communs :
+
+- Date et heure
+- Lieu
+
+La seule différence est que le concert a un tarif, contrairement à la répétition.  
+On va donc pouvoir créer une entité **générique** que l'on appelera **Événement**.
+
+Cette entité générique va contenir les attributs communs aux deux entités, et on va faire hériter les entités **Concert** et **Répétition** de cette entité.  
+On se retrouve donc avec ces trois entités _(**Événement**, **Concert** et **Répétition**)_ :
+![MCD avec héritage](/images/merise/mcd-3.webp)
+
+<Callout type="question" title="Pourquoi ne pas stocker le type d'événement ?">
+  Effectivement, on aurait pu stocker le type d'événement dans l'entité **Événement** !  
+  Il s'agit d'une autre approche qui est tout à fait valable.
+
+  Cependant, il est plus simple de créer une entité générique qui va nous permettre de factoriser les attributs communs et éviter de devoir rendre plusieurs attributs nullables en fonction du type d'événement.
+
+  On renforce ainsi l'intégrité de la base de données.
+</Callout>
+
+Le MCD final ressemble donc à ça :
+![MCD final](/images/merise/mcd-4.webp)
+
+Si tu souhaites télécharger le MCD que l'on vient de créer, tu peux le faire ici : [MCD Merise pour Looping](/downloads/merise/band-manager.loo).
+
+## Conclusion
+
+En conclusion, le MCD dans Merise est un outil indispensable pour structurer et visualiser les données de manière claire et cohérente.
+
+Grâce à des entités, des attributs, des relations et des cardinalités, le MCD permet de représenter les informations de façon abstraite, tout en restant compréhensible pour le client.
+
+Prochaine étape : le **MLD** _(Modèle Logique de Données)_ et le **MRD** _(Modèle Relationnel de Données)_ !

app/pages/docs/merise/mcd/TermsTable.tsx

@@ -0,0 +1,60 @@
+export default function TermsTable() {
+	return (
+		<table class="block max-w-full overflow-x-auto border-collapse text-sm">
+			<thead>
+				<tr>
+					<th scope="col">Terme</th>
+					<th scope="col">Définition</th>
+				</tr>
+			</thead>
+			<tbody>
+				<tr>
+					<td>
+						<strong class="font-semibold text-slate-800">Entité</strong>
+					</td>
+					<td>
+						Représentation d'un regroupement de données <em>(rectangle)</em>
+					</td>
+				</tr>
+				<tr>
+					<td>
+						<strong class="font-semibold text-slate-800">Attribut</strong>
+					</td>
+					<td>Donnée précise d'une entité</td>
+				</tr>
+				<tr>
+					<td>
+						<strong class="font-semibold text-slate-800">Relation</strong>
+					</td>
+					<td>
+						Lien entre deux entités <em>(bulle ovale/arrondie)</em>, accompagné
+						d'un verbe à l'infinitif
+					</td>
+				</tr>
+				<tr>
+					<td>
+						<strong class="font-semibold text-slate-800">Cardinalité</strong>
+					</td>
+					<td>
+						Nombre d'occurrences <em>(minimum et maximum)</em> d'une entité par
+						rapport à une autre
+					</td>
+				</tr>
+				<tr>
+					<td>
+						<strong class="font-semibold text-slate-800">Discriminant</strong>{" "}
+						<em>
+							(ou{" "}
+							<strong class="font-semibold text-slate-800">déterminant</strong>/
+							<strong class="font-semibold text-slate-800">identifiant</strong>)
+						</em>
+					</td>
+					<td>
+						Attribut qui permet d'identifier une entité de manière unique{" "}
+						<em>(ex: matricule)</em>
+					</td>
+				</tr>
+			</tbody>
+		</table>
+	);
+}

app/pages/docs/merise/mld/+Page.mdx

@@ -0,0 +1,7 @@
+---
+title: Modèle Logique/Relationnel de Données (MLD/MRD) Merise
+description: Plongez dans le MLD et MRD de Merise pour transformer votre modèle conceptuel en une structure relationnelle optimisée.
+tags: [Backend, Merise, BDD, MCD, MLD, MPD, SQL]
+---
+
+En cours de rédaction...

app/pages/docs/merise/mpd/+Page.mdx

@@ -0,0 +1,7 @@
+---
+title: Modèle Physique de Données (MPD) Merise
+description: Apprenez à créer le MPD dans Merise, la dernière étape pour concrétiser votre base de données sur un SGBD.
+tags: [Backend, Merise, BDD, MCD, MLD, MPD, SQL]
+---
+
+En cours de rédaction...