Design conceptuel

Le design conceptuel commence par une analyse du domaine du client ou du problème.

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.

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 :

Schéma E-R sans verbe

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 :

Schéma E-R avec un verbe

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.

Cardinalité one-to-one

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

Cardinalité one-to-one

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.

Cardinalité one-to-one

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 :

Cardinalité one-to-one

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 !

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 !