> For the complete documentation index, see [llms.txt](https://docs.glassworks.tech/sgbdr/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.glassworks.tech/sgbdr/data-modeling/010-design-conceptuel.md). # Design conceptuel Le design conceptuel commence par une analyse du domaine du client ou du problème. {% hint style="success" %} Le design conceptuel commence **sur le terrain** ! Il faut aller parler aux clients, aux utilisateurs potentiels, ou aux managers qui veulent extraire des synthèses. Dans les grandes entreprises, il y aura des analystes qui vont créer de questionnaires, d'ateliers, ou des études, et synthétiser des informations pour vous. Dans les petites entreprises, c'est votre commercial, ou peut-être vous-même, qui va aller chercher des informations. {% endhint %} Les livrables de la phase d'analyse peuvent se trouver en plusieurs formes : * des \**use-cases* (cas d'utilisation) : souvent, exprimé en format *storytelling* qui raconte les procédures de quelqu'un dans l'entreprise, d'un client ou autre partie prenant * des comptes-rendus des interviews avec des personnes de votre audience cible * des cahiers des charges * des notes en bullet prises des rendez-vous ou discussions * ... C'est à nous de maintenant prendre toutes ces informations et extraire une logique, et notamment un modèle de données qui représente la réalité — surtout avec l'objectif de résoudre un problème exprimé (n'oubliez jamais ce dernier point !). ## Entités En lisant toutes les analyses, la première activité est d'extraire la liste d'acteurs, la liste d'objets…, en bref, la liste de *trucs* qui sont manipulés dans le domaine. Nous utilisons le mot **entité**. En général, tout ce qui a un **nom** dans votre entreprise est une entité. Cela peut être des interlocuteurs, des produits, des services, etc. Une entité peut être *concrète* (un livre) ou *abstraite* (un cours). Chaque entité est représentée par un set **d’attributs**. ### Exercice Je suis votre client. Je vous envoie un email vous demandant de me créer un système d'information pour mon magasin de location de films. Quelles seront les entités et les attributs ? Sur un papier brouillon (et sans regarder le schéma se SAKILA), essayez d’identifier les entités. ## E-R diagram Il y a plusieurs façons de représenter nos entités. D'abord, on peut lister simplement en texte nos entités et leurs attributs : ``` film(title, duration) actor(familyName, givenName, age) ``` Ceci est bien pour une première passe, mais ce n'est pas très parlant quand la liste devient longue. Il y a donc des représentations graphiques qui ont été développés :

Deux façons différentes de dessiner une entité film et ses attributs

En plus, on aimerait aussi modéliser les liens entre les entités ! Par exemple, un acteur joue dans un film. D'abord, si on ne comprend pas trop la nature de la relation, mais on sait qu'il y en a une, on tire juste un trait entre les deux :

Ensuite, on creuse plus le domaine, afin de savoir plus de cette relation. On découvre, qu'en effet, plusieurs acteurs **jouent** dans un film. On exprime ce lien, souvent via un *verbe* en forme losange sur le trait :

## Cardinalité Vous avez peut-être remarqué qu'en analysant le domaine des films, notamment, le lien entre des acteurs et des films, nous avons découvert que *plusieurs* acteurs peuvent jouer dans un film. Mais, vous vous êtes rendu compte qu'en plus, un acteur peut jouer dans *plusieurs* films. Le lien entre les deux entités n'est donc pas si simple ! Cette notion du *nombre maxi de liens* potentiels entre deux entités s'appelle la **cardinalité**. ### One-to-one Seulement, et au maximum, une entité de chaque côté du lien. Ce cas est assez rare. Quelle est la différence entre 2 entités avec un lien *one-to-one* et une entité avec tous les attributs ? La réponse est peut être dans le niveau d’accès aux certains attributs, ou peut être le lien entre en sous-set des attributs avec d'autres entités dans le domaine.

Dans l'image, on sépare le RIB des détails d'un acteur, parce qu'on aura des niveaux d'accès différent. Seulement les chargées de la paye auront accès aux RIBs des acteurs. Parfois, ce n'est pas si simple de décider : > Dans notre domaine, un acteur a une adresse principal. On a le choix de dire, d'accord, on stocke toutes les informations de l'adresse avec l'entité **actor**. > > En revanche, on découvre qu'en fait la même adresse peut-être utilisé comme lieu d'un tournage. On peut aussi stocker l'adresse avec l'entité **shoot**, sauf que maintenant on a de la redondance dans notre base (la même adresse est stocké plusieurs fois dans la base). > > A ce moment là, il serait prudent d'extraire l'adresse et le stocker en entité à part, même s'il y a des liens type *one-to-one*. Noter que le processus de *normalisation* va nous aider à identifier les cas comme décrit dessus. ### One-to-many Une entité de l’un côté peut être liée à plusieurs entités de l’autre côté du lien. En revanche, l’inverse n’est pas vrai. Exemple : une ville se trouve dans le maximum un pays, mais un pays a plusieurs villes

Notez qu'avec cette notation, la flèche est cotée **one**. Il y a d'autres types de notation qui seront peut-être plus intuitives. ### Many-to-many Plusieurs entités sont liées à plusieurs entités à l’autre côté du lien. Exemple : un film a plusieurs acteurs, et un acteur peut jouer dans plusieurs films.

## Entités faibles Parfois, il y a des entités qui existent uniquement parce qu'une autre entité existe. Prenons l'exemple d'une fiche de paye. Une fiche de paye ne peut pas exister sans un salarié. Dans cet exemple : * L'entité `salarié` est une entité **forte**, parce qu'elle peut exister sans l'existence d'autres entités * L'entité `fiche_de_paie` est une entité **faible**, parce que son existence dépend de l'existence d'un salarié. Dans un schéma E-R, on utilise des doubles traits pour représenter des entités et liens faibles :

Notez bien que la notion d'entité faible joue en parallèle de la notion de cardinalité. Dans l'exemple, la cardinalité du lien est *one-to-many* : une fiche de paye doit avoir maximum 1 salarié. En revanche, un salarié peut avoir plusieurs fiches de paye. ## Modalité A l'opposé de *cardinalité* (le nombre **maximum** de liens) est la *modalité* : le nombre **minimum** de liens. Un film peut exister sans forcément d'acteur (par exemple un documentaire sur la nature). Un acteur peut exister sans avoir joué dans un film. On dit donc que la modalité du lien entre l'entité *film* et l'entité *actor* est 0. En revanche, une ville doit obligatoirement avoir un pays. Une ville ne peut pas exister sans son pays. La modalité est donc 1. Dans l'exemple de salarié / fiche de paye, la modalité dépend du sens de la relation : * salarié vers fiche-de-paye : modalité est 0, car un salarié peut avoir 0 fiches de paie (pendant son premier mois d'emploi par exemple) * fiche-de-paye ver salarié : modalité est 1 comme une fiche de paye doit avoir minimum 1 salariés ## Différentes notations On essaye de créer des schémas qui expriment l'ensemble des informations de nos entités et leurs liens. Cela représente beaucoup d'information à communiquer, et donc ce n'est pas si simple ! L'image dessous indique trois sortes de notation : **chen**, **crow's foot** et **UML**

Différentes sortes de notation d'un schéma E-R

Nous n'allons pas plonger dans les détails de chaque notation pendant ce cours. Selon l'outil que vous utilisez, ou bien l'équipe dans laquelle vous travaillez, vous allez devoir chercher et apprendre la forme de notation utilisée. L'importance est de comprendre les notions exprimées (cardinalité, modalité, entités faibles, etc.), et le reste est juste syntaxe ! {% hint style="success" %} On peut passer beaucoup de temps à créer le schéma parfaitement détaillé en suivant toutes les règles possibles. Cela peut avoir des avantages et désavantages. Avantages : * Un schéma parfait et bien détaillé peut souvent être lu et transformé en DDL par un client SGBDR * Plus résistant aux failles dans le long terme Désavantages : * Si notre équipe ne sait pas lire le schéma, c'est une perte de temps ! * Si on ne maîtrise pas le domaine, un schéma très détaillé ne sert à rien. Autant avoir un schéma moins détaillé, mais qui permette d'évoluer ou itérer plus facilement ! {% endhint %}