Compare commits

..

No commits in common. "54f6bf8a7293be7d81a221bf93e98424b3d67274" and "90c2773de171d4140518f9d989fbb55503984908" have entirely different histories.

9 changed files with 25 additions and 175 deletions

View File

@ -12,11 +12,6 @@ const styles = {
title: "text-amber-900 dark:text-amber-500", title: "text-amber-900 dark:text-amber-500",
body: "text-slate-800 [--tw-prose-underline:var(--color-slate-400)] [--tw-prose-background:var(--color-slate-50)] prose-a:text-slate-900 prose-code:text-slate-900 dark:text-slate-300 dark:[--tw-prose-underline:var(--color-slate-700)] dark:prose-code:text-slate-300", body: "text-slate-800 [--tw-prose-underline:var(--color-slate-400)] [--tw-prose-background:var(--color-slate-50)] prose-a:text-slate-900 prose-code:text-slate-900 dark:text-slate-300 dark:[--tw-prose-underline:var(--color-slate-700)] dark:prose-code:text-slate-300",
}, },
question: {
container: "bg-amber-50 dark:bg-amber-800/60 dark:ring-1 dark:ring-amber-300/10",
title: "text-amber-900 dark:text-amber-500",
body: "text-slate-800 [--tw-prose-underline:var(--color-slate-400)] [--tw-prose-background:var(--color-slate-50)] prose-a:text-slate-900 prose-code:text-slate-900 dark:text-slate-300 dark:[--tw-prose-underline:var(--color-slate-700)] dark:prose-code:text-slate-300",
},
}; };
const icons = { const icons = {

View File

@ -1,6 +1,5 @@
import { InstallationIcon } from "@syntax/icons/InstallationIcon"; import { InstallationIcon } from "@syntax/icons/InstallationIcon";
import { LightbulbIcon } from "@syntax/icons/LightbulbIcon"; import { LightbulbIcon } from "@syntax/icons/LightbulbIcon";
import { QuestionIcon } from "@syntax/icons/QuestionIcon";
import { PluginsIcon } from "@syntax/icons/PluginsIcon"; import { PluginsIcon } from "@syntax/icons/PluginsIcon";
import { PresetsIcon } from "@syntax/icons/PresetsIcon"; import { PresetsIcon } from "@syntax/icons/PresetsIcon";
import { ThemingIcon } from "@syntax/icons/ThemingIcon"; import { ThemingIcon } from "@syntax/icons/ThemingIcon";
@ -15,7 +14,7 @@ const icons = {
theming: ThemingIcon, theming: ThemingIcon,
lightbulb: LightbulbIcon, lightbulb: LightbulbIcon,
warning: WarningIcon, warning: WarningIcon,
question: QuestionIcon, question: WarningIcon,
}; };
const iconStyles = { const iconStyles = {

View File

@ -1,47 +0,0 @@
import { DarkMode, Gradient, LightMode } from "@syntax/Icon";
export function QuestionIcon({ id, color }: { id: string; color?: React.ComponentProps<typeof Gradient>["color"] }) {
return (
<>
<defs>
<Gradient id={`${id}-gradient`} color={color} gradientTransform="rotate(65.924 1.519 20.92) scale(25.7391)" />
<Gradient id={`${id}-gradient-dark`} color={color} gradientTransform="matrix(0 24.5 -24.5 0 16 5.5)" />
</defs>
<LightMode>
<circle cx={20} cy={20} r={12} fill={`url(#${id}-gradient)`} />
<path
d="M3 16c0 7.18 5.82 13 13 13s13-5.82 13-13S23.18 3 16 3 3 8.82 3 16Z"
fillOpacity={0.5}
className="fill-[var(--icon-background)] stroke-[color:var(--icon-foreground)]"
strokeWidth={2}
strokeLinecap="round"
strokeLinejoin="round"
/>
<path
d="m 16.39 14.617 l 1.179 -3.999 C 17.38 9.304 16.133 9.127 15.469 10.645 C 15.306 11.269 14.71 11.12 14.71 10.537 a 1.66 1.66 5 1 1 3.808 0.217 l -1.5182 5.4314 a 0.602 0.602 5 0 1 -1.1795 -0.1032 Z"
className="fill-[var(--icon-foreground)] stroke-[color:var(--icon-foreground)]"
strokeWidth={2}
strokeLinecap="round"
strokeLinejoin="round"
/>
<path
d="M16 23a1 1 0 1 0 0-2 1 1 0 0 0 0 2Z"
fillOpacity={0.5}
stroke="currentColor"
className="fill-[var(--icon-background)] stroke-[color:var(--icon-foreground)]"
strokeWidth={2}
strokeLinecap="round"
strokeLinejoin="round"
/>
</LightMode>
<DarkMode>
<path
fillRule="evenodd"
clipRule="evenodd"
d="M2 16C2 8.268 8.268 2 16 2s14 6.268 14 14-6.268 14-14 14S2 23.732 2 16Zm11.386-4.85a2.66 2.66 0 1 1 5.228 0l-1.039 5.543a1.602 1.602 0 0 1-3.15 0l-1.04-5.543ZM16 20a2 2 0 1 0 0 4 2 2 0 0 0 0-4Z"
fill={`url(#${id}-gradient-dark)`}
/>
</DarkMode>
</>
);
}

View File

@ -50,17 +50,17 @@ Ce sont ces informations que l'on va devoir stocker dans notre base de données.
En reprenant les informations que l'on a, on va pouvoir créer notre dictionnaire de données. En reprenant les informations que l'on a, on va pouvoir créer notre dictionnaire de données.
| Groupe de la donnée | Nom de la donnée | Type de donnée | Description | | Groupe de la donnée | Nom de la donnée | Type de donnée | Description |
| ------------------- | -------------------------- | -------------- | ---------------------------------------------- | | ------------------- | ---------------- | -------------- | ------------------------------------------- |
| Pommes de terre | variété | Texte | Nom de la variété de la pomme de terre | | Pommes de terre | variété | Texte | Nom de la variété de la pomme de terre |
| Pommes de terre | stock | Nombre | Quantité de pommes de terre en stock | | Pommes de terre | stock | Nombre | Quantité de pommes de terre en stock |
| Salarié | matricule | Texte | Numéro d'immatriculation du salarié, unique | | Salarié | matricule | Texte | Numéro d'immatriculation du salarié, unique |
| Salarié | nom | Texte | Nom du salarié | | Salarié | nom | Texte | Nom du salarié |
| Salarié | prénom | Texte | Prénom du salarié | | Salarié | prénom | Texte | Prénom du salarié |
| Vente | date | Date | Date de la vente | | Vente | date | Date | Date de la vente |
| Vente | quantité vendue | Nombre | Quantité de pommes de terre vendues | | Vente | quantité | Nombre | Quantité de pommes de terre vendues |
| Vente | prix total | Nombre | Prix de vente unitaire | | Vente | prix | Nombre | Prix de vente unitaire |
| Vente | Salarié (individuel) | Non applicable | Salarié en charge de la vente | | Vente | vendeur | Texte | Nom du salarié qui a vendu |
| Vente | Pomme de terre (multiples) | Non applicable | Pommes de terre vendues lors d'une transaction | | Vente | variété | Texte | Nom de la variété de la pomme de terre |
Comme tu peux le voir, nous utilisons des termes simples et compréhensibles par le client. Comme tu peux le voir, nous utilisons des termes simples et compréhensibles par le client.
Il ne faut **surtout pas** perdre le client avec des termes techniques comme `VARCHAR` par exemple. Il ne faut **surtout pas** perdre le client avec des termes techniques comme `VARCHAR` par exemple.
@ -90,17 +90,17 @@ Selon les questions posées et les réponses obtenues par le client, on va pouvo
On va donc ajouter des précisions sur les données, comme la taille attendue, le type de données et si la taille est fixe ou pas. On va donc ajouter des précisions sur les données, comme la taille attendue, le type de données et si la taille est fixe ou pas.
| Groupe de la donnée | Nom de la donnée | Type de donnée | Taille attendue | Taille fixe ? | Description | | Groupe de la donnée | Nom de la donnée | Type de donnée | Taille attendue | Taille fixe ? | Description |
| ------------------- | -------------------------- | -------------- | --------------- | -------------- | ---------------------------------------------- | | ------------------- | ---------------- | -------------- | --------------- | -------------- | ------------------------------------------- |
| Pomme de terre | variété | Texte | 50 caractères | Non | Nom de la variété de la pomme de terre | | Pommes de terre | variété | Texte | 50 caractères | Non | Nom de la variété de la pomme de terre |
| Pomme de terre | stock | Nombre | 8 chiffres | Non applicable | Quantité de pommes de terre en stock | | Pommes de terre | stock | Nombre | 8 chiffres | Non applicable | Quantité de pommes de terre en stock |
| Salarié | matricule | Texte | 10 caractères | Oui | Numéro d'immatriculation du salarié, unique | | Salarié | matricule | Texte | 10 caractères | Oui | Numéro d'immatriculation du salarié, unique |
| Salarié | nom | Texte | 50 caractères | Non | Nom du salarié | | Salarié | nom | Texte | 50 caractères | Non | Nom du salarié |
| Salarié | prénom | Texte | 50 caractères | Non | Prénom du salarié | | Salarié | prénom | Texte | 50 caractères | Non | Prénom du salarié |
| Vente | date | Date | Non applicable | Non | Date de la vente | | Vente | date | Date | Non applicable | Non | Date de la vente |
| Vente | quantité vendue | Nombre | 8 chiffres | Non applicable | Quantité de pommes de terre vendues | | Vente | quantité | Nombre | 8 chiffres | Non applicable | Quantité de pommes de terre vendues |
| Vente | prix total | Nombre | 8 chiffres | Non applicable | Prix de vente unitaire | | Vente | prix | Nombre | 8 chiffres | Non applicable | Prix de vente unitaire |
| Vente | Salarié (individuel) | Non applicable | Non applicable | Non | Salarié en charge de la vente | | Vente | vendeur | Texte | 50 caractères | Non | Nom du salarié qui a vendu |
| Vente | Pomme de terre (multiples) | Non applicable | Non applicable | Non applicable | Pommes de terre vendues lors d'une transaction | | Vente | variété | Texte | 50 caractères | Non | Nom de la variété de la pomme de terre |
Dans cet exemple, on a ajouté la **taille** des données, mais ce n'est pas toujours le cas. Dans cet exemple, on a ajouté la **taille** des données, mais ce n'est pas toujours le cas.
Lorsque ce n'est pas pertinent, on peut indiquer `Non applicable` _(ou un autre terme équivoque)_ pour la taille attendue. Lorsque ce n'est pas pertinent, on peut indiquer `Non applicable` _(ou un autre terme équivoque)_ pour la taille attendue.

View File

@ -109,101 +109,6 @@ Le client n'ayant pas besoin de savoir ce qu'est un identifiant technique, on va
{% /callout %} {% /callout %}
## Données uniques et discriminants
Je fais un rapide point entre les données uniques et discriminants !
Les deux attributs sont **uniques**, mais n'ont pas la même signification.
Dans l'exemple donné plus tôt avec l'attribut **Matricule**, il s'agit d'un **discriminant naturel**. Dans ce cas précis, il s'agit d'une **donnée réelle** _(métier)_ qui permet d'identifier un salarié de manière unique.
Maintenant, prenons l'exemple d'un compte utilisateur sur un site web avec :
- **Email** : Adresse email de l'utilisateur
- **Mot de passe** : Mot de passe de l'utilisateur
On serait tenté de se dire que l'adresse email est un discriminant du fait que cette donnée se doit d'être unique.
Pourtant, ce n'est pas le cas.
La raison est simple : l'adresse email peut être **modifiée par l'utilisateur**.
Un discriminant se veut **unique**, **fixe** et **non modifiable**.
En gros, les mêmes contraintes que pour une **clé primaire** _(même si on ne doit pas utiliser ce terme dans un MCD)_.
Maintenant, à quoi ça ressemble dans un MCD ?
### Représentation graphique entre discriminant et unique
Une donnée unique se représente par une écriture **épaisse** sur le nom de l'attribut d'une entité.
On sait qu'il s'agit d'une donnée unique, mais pas forcément d'un discriminant.
Le discriminant reprend cette même écriture, mais ajoute un **soulignement** sur le nom de l'attribut.
![MCD - Discriminant et unique](/merise/mcd-3.webp)
## Relations entre entités
Oui, on passe déjà aux relations entre entités !
Et si jamais tu te poses la question : "Et **Vente** alors ?"... et bien on en parle juste maintenant !
Dans notre situation, une vente relie les entités **Pomme de terre** et **Salarié**.
On va donc créer une nouvelle entité : **Vente**.
Dans notre cas, on sait qu'une vente est réalisée par un salarié et concerne une ou plusieurs pommes de terre.
C'est donc maintenant que l'on peut parler de **cardinalité** !
### Écriture et lecture des cardinalités
La cardinalité est un élément essentiel dans la modélisation de données. Elle permet de définir le nombre d'occurrences d'une entité par rapport à une autre.
Une cardinalité se compose de deux valeurs :
- **Minimum** : Nombre minimum d'occurrences _(0, 1, ...)_
- **Maximum** : Nombre maximum d'occurrences _(1, 2, N, ...)_
{% callout type="question" title="C'est quoi ce `N` ?" %}
`N` représente une valeur **illimitée**.
Dans le cas d'une vente, on ne limite pas le nombre maximale de variétés de pommes de terre vendues lors d'une transaction.
On peut donc dire que le nombre de variétés de pommes de terre vendues est **illimité**.
{% /callout %}
## Définition de nos cardinalités
Il est temps d'en finir avec notre MCD et ces histoires de cardinalités !
Voici comment on va définir nos cardinalités :
- **Pomme de terre** et **Vente** :
- Une pomme de terre peut être vendue plusieurs fois, mais pas forcément _(0,N)_
- Une vente concerne au moins une pomme de terre, jusqu'à une infinité de pommes de terre _(1,N)_
- **Salarié** et **Vente** :
- Un salarié peut réaliser plusieurs ventes, mais pas forcément _(0,N)_
- Une vente est réalisée par un et un seul salarié _(1,1)_
En ajoutant des verbes **à l'infinitif** pour expliquer la relation entre les entités, on obtient :
![MCD - Relations entre entités](/merise/mcd-4.webp)
Et là, on est presque bon !
Il nous manque juste un petit détail : la **quantité** vendue d'une variété de pomme de terre au cours d'une vente.
## Relations N-N
Si on regarde de plus prêt notre relation **INCLURE** entre **Pomme de terre** et **Vente**, on se rend compte qu'il s'agit d'une relation **N-N** _(N-N)_.
Ce type de relation permet l'ajout d'attributs à la relation elle-même.
Lors de l'étape suivante _(MLD)_, on verra comment gérer ce type de relation.
Ici, on va pouvoir ajouter un nouvel attribut à notre relation : **Quantité**.
![MCD - Relations N-N](/merise/mcd-5.webp)
---
Gros morceau, n'est-ce pas ? 😅
## Ressources supplémentaires ## Ressources supplémentaires
- [La vérité sur les id - Jean Prulière](https://jeanpruliere.medium.com/la-v%C3%A9rit%C3%A9-sur-les-id-507134adda12) - [La vérité sur les id - Jean Prulière](https://jeanpruliere.medium.com/la-v%C3%A9rit%C3%A9-sur-les-id-507134adda12)

View File

@ -9,8 +9,6 @@ export default {
// https://vike.dev/Layout // https://vike.dev/Layout
Layout, Layout,
lang: "fr",
// https://vike.dev/head-tags // https://vike.dev/head-tags
title: "Memento Dev", title: "Memento Dev",
description: "Demo showcasing Vike", description: "Demo showcasing Vike",

Binary file not shown.

Before

Width:  |  Height:  |  Size: 5.8 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 22 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 22 KiB