Le modèle conceptuel de données¶

Pourquoi le modèle entité-association ?

Il permet le passage du monde réel à sa représentation informatique.

Dictionnaires de données¶

Le dictionnaire des données contient toutes les données nécessaires, relevées dans l’analyse de l’organisation. Il est organisé sous forme d’un tableau de cinq colonnes:

donnée

Code donnée

Description

Type et longueur

observations

Le graphe de dépendances fonctionnelles¶

Ce graphe fait apparaître les dépendances fonctionnelles entre les données. Une dépendance fonctionnelle relie deux données lorsque la connaissance de l’une détermine l’autre.

Attention

Une dépendance fonctionnelle n’est pas réversible.

\[ \begin{align}\begin{aligned}\begin{split}id\_{}jeu\_{}plateau \longrightarrow nom\_{}jeu\_{}plateau\\\end{split}\\id\_{}categorie \longrightarrow nom\_{}categorie\end{aligned}\end{align} \]

Les règles de passage des DF au MCD:

Règle 0: Toute donnée du graphe de DF devient une propriété.
Règle 1: Toute donnée source de dépendance fonctionnelle devient identifiant d’une entité.
Règle 2: Toute donnée cible d’une dépendance fonctionnelle et non source (d’une autre DF) devient une propriété de l’entité dont la donnée source de la DF est identifiant.
Règle 3: Une dépendance fonctionnelle entre deux données sources de DF révèle une association hiérarchique toujours non porteuse de propriété(s).
Règle 4: La présence d’une donnée concaténée (association de plusieurs données élementaires) source de DF révèle une association non hiérarchique porteuse de propriété(s).
Règle 5: Attention il peut exister des associations qui sont des dépendances non fonctionnelles et qui n’apparaissent pas dans le graphe des DF.

Éléments fondamentaux du MCD¶

Le modèle E/A est un formalisme graphique pour la modélisation de données dont l’origine se trouvent dans les travaux de Tardieu (France) et Chen (USA) en 1974/1975.

Ce modèle repose sur des concepts simples:

choses (objets) \(\rightarrow\) entités
liens entre les choses \(\rightarrow\) associations

Entités¶

Une entité est un objet, événement, lieu, personne, chose, etc. identifiable sans ambiguïté.

@startuml entity

scale 2.5
allow_mixing
skinparam backgroundcolor transparent
skinparam defaultFontName Hack
skinparam monochrome true

object "Étudiant" as etudiant {
}

@enduml — Exemple d’une entité¶

Associations¶

Une association est un lien entre 2 ou plusieurs entités.

@startuml association2

scale 2.5
allow_mixing
skinparam backgroundcolor transparent
skinparam defaultFontName Hack
skinparam monochrome true

left to right direction

usecase Enseigne as "Enseigne
--
"

object Enseignant
object Cours

Enseignant -- Enseigne
Enseigne -- Cours

@enduml

Différents cas de figure élémentaires¶

@startuml association_types

scale 2.5
allow_mixing
skinparam backgroundcolor transparent
skinparam defaultFontName Hack
skinparam monochrome true
left to right direction

object " " as A {
{field}
{field}
{field}
}

object " " as B {
{field}
{field}
{field}
}

object " " as C {
{field}
{field}
{field}
}

object " " as D {
{field}
{field}
{field}
}

usecase binaire as "
"

usecase ternary as "
"

usecase reflex as "
"

A -- binaire
binaire -- B

B -- ternary
ternary -- C
ternary -- D

D -- reflex
reflex -- D

note right of reflex : Réflexive \n(auto-association)

note bottom of ternary: Ternaire

note bottom of binaire: Binaire

@enduml — Les différents types d’associations¶

Propriétés = Attributs¶

Il s’agit d’une donnée élémentaire que l’on perçoit sur une entité ou une association

@startuml entity2

scale 2.5
allow_mixing
skinparam backgroundcolor transparent
skinparam defaultFontName Hack
skinparam monochrome true

object "Étudiant" as etudiant {
nom
prénom
date de de naissance
numéro étudiant
}

usecase Enseigne as "Enseigne
--
cycle
"

@enduml

Identifiant¶

Propriété ou groupe de propriétés dont la valeur identifie sans ambiguïté une entité (identifiant = clé primaire).

Chaque occurrence doit pouvoir être repérée de manière unique et sans ambiguïté, pour être distinguée de toutes les autres, c’est l’objectif des identifiants.

@startuml association3

scale 2.5
allow_mixing
skinparam backgroundcolor transparent
skinparam defaultFontName Hack
skinparam monochrome true

left to right direction

usecase Enseigne as "Enseigne
--
<u>num prof</u>
<u>num_cours</u>
cycle
"

object Enseignant{
<u>num prof</u>
nom
prénom
statut
num compte
}
object Cours{
<u>num cours</u>
intitulé
}

Enseignant -- Enseigne
Enseigne -- Cours

@enduml

Typologies des associations: Cardinalités¶

Une association permet de relier une ou plusieurs entités. Le rôle de l’association détermine la façon dont les entités sont reliées.

Le rôle d’une association est défini par deux nombres (min, max) représentant le nombre de fois minimum et maximum qu’une entité participe à une association. Les valeurs possibles sont \(0,1\), \(1,1\), \(0,N\) et \(1,N\).

@startuml cardinality5

scale 2.5
allow_mixing
skinparam backgroundcolor transparent
skinparam defaultFontName Hack
skinparam monochrome true
left to right direction

object A
object B

usecase C as "
"

A -- C: "min,max"
C -- B: "min,max"

@enduml

Min: combien de fois au moins une entité de \(A\) est relié à une entité de \(B\).
Max! combien de fois au plus une entité de \(A\) est relié à une entité de \(B\).

Attention

Il faut se poser ces questions dans les deux sens, sens de \(A\) vers \(B\) puis de \(B\) vers \(A\).

Association de type 0,1¶

Une entité de \(A\) peut être reliée à aucune ou à une seule entité de \(B\).

@startuml cardinality

scale 2.5
allow_mixing
skinparam backgroundcolor transparent
skinparam defaultFontName Hack
skinparam monochrome true
left to right direction

object A
object B

usecase C as "
"

A -- C: "0,1"
C -- B

@enduml

Association de type 1,1¶

Une entité de \(A\) est reliée à une seule entité de \(B\).

@startuml cardinality2

scale 2.5
allow_mixing
skinparam backgroundcolor transparent
skinparam defaultFontName Hack
skinparam monochrome true
left to right direction

object A
object B

usecase C as "
"

A -- C: "1,1"
C -- B

@enduml

Association de type 0,N¶

Une entité de \(A\) peut être reliée à aucune ou à plusieurs entités de \(B\).

@startuml cardinality3

scale 2.5
allow_mixing
skinparam backgroundcolor transparent
skinparam defaultFontName Hack
skinparam monochrome true
left to right direction

object A
object B

usecase C as "
"

A -- C: "0,N"
C -- B

@enduml

Association de type 1,N¶

@startuml cardinality4

scale 2.5
allow_mixing
skinparam backgroundcolor transparent
skinparam defaultFontName Hack
skinparam monochrome true
left to right direction

object A
object B

usecase C as "
"

A -- C: "1,N"
C -- B

@enduml

Règles de complétude¶

Une entité doit à minima contenir (forme minimun pour le modèle EA):

un nom,
une liste d’attributs
et un identifiant.

Une Association doit à minima contenir (forme minimun pour le modèle EA):

un nom,
la liste des entités qui participent à l’association
ainsi que les rôles et leur cardinalité
et éventuellement la liste des attributs.

Démarche de conception¶

La conception d’un MCD passe par les étapes suivantes:

l’identification des entités les plus naturelles;
l’identification des associations entre ces entités;
l’identification des attributs et des identifiants de ces entités et associations;
l’expression des cardinalités;
l’expression des Contraintes d’Intégrités.

Contrainte d’Intégrité Fonctionnelle¶

Une Contrainte d’Intégrité Fonctionnelle (en abrégé : CIF) se définit par le fait que l’une des entités participant à l’association est complètement déterminée par la connaissance d’une ou plusieurs autres entités participant dans cette même association.

Normalisation des entités/association¶

Normaliser un schéma conceptuel c’est le transformer en schéma normalisé équivalent, c.a.d contenant les même informations, sans perte de données et de dépendances. On parle aussi de forme normal (NF)

Première forme normale (1NF)

Une entité ou une association est en première forme normale si elle ne possède aucun attribut multivalué c.a.d décomposable.

Deuxième forme normale (2NF)

Une entité ou une association est en deuxième forme normale si:

elle est en première forme normale,
tout attribut n’appartenant pas à la clé ne dépend pas que d’une partie de cette clé.

Troisième forme normale (3NF)

Une entité ou une association est en troisième forme normale si:

elle est en deuxième forme normale,
tout attribut n’appartenant pas à la clé ne peut dépendre que d’une clé.

Entité de type faible¶

Certaines entités dites « faibles » n’existent qu’en référence à d’autres entités dites « identifiantes », on parle aussi d’entités « fortes ». L’entité identifiante est appelé « identifiant étranger » et l’association qui les unit « association identifiantes ».

Une entité de type faible, également appelée entité non identifiée, possède une clé locale (appelée identifiant relatif) qui permet d’identifier une de ses occurrences parmi l’ensemble des occurrences associées à une occurrence de l’entité identifiante. La clé complète d’une entité faible est la concaténation de la clé de l’entité identifiante et de sa clé locale.

@startuml weak_entity

scale 2.5
allow_mixing
skinparam backgroundcolor transparent
skinparam defaultFontName Hack
skinparam monochrome true
left to right direction

object Projet {
<u>id projet</u>
designation article
}

object Tâche {
<u>id tâche</u>
nom fournisseur
adresse fournisseur
}

usecase Contenir as "Contenir
--
"

Projet -- Contenir: "0,N"
Contenir -- Tâche: "1,1"

@enduml

L’entité Tâche est complètement dépendante de l’entité Projet et sa clé locale (idTache) n’est pas suffisante à l’identifier de façon absolue.

Le repérage des entités de type faible est très important dans le processus de modélisation, il permet de réfléchir à la meilleure façon d’identifier de façon unique les entités et donc de trouver les meilleures clés. Notons de plus que le repérage d’entités faibles aura une influence importante sur le modèle relationnel résultant.

UML¶

Unified Modeling Language

(UML) est un langage de représentation destiné en particulier à la modélisation objet, devenue une norme OMG (Object Management Group) en 1997.

Le modèle dominant en conception de bases de données a longtemps été le modèle E-A toutefois le modèle UML se généralise de plus en plus. Nous ne donnons ici (parmi l’ensemble des outils d’UML) qu’un aperçu du diagramme de classes, qui plus est limité aux aspects particulièrement utilisés en modélisation de bases de données.

Classe UML¶

Type abstrait caractérisé par des propriétés (attributs et méthodes) communes à un ensemble d’objets. Permet de créer des instances de ces objets ayant ces propriétés.

@startuml voiture
scale 2.5
skinparam backgroundcolor transparent
skinparam defaultFontName Hack

class Voiture {
{field} Immatriculation: string
{field} Vin: string
{field} Marque: string
{field} Type: string
{field} NbPortes: integer
{field} Puissance: integer
{field} Kilométrage: integer
{method} Rouler()
}

hide methods

@enduml — Exemple de classe UML¶

Attribut¶

Information élémentaire qui caractérise une classe et dont la valeur dépend de l’objet instancié.

Un attribut est:

typé, domaine des valeurs est fixé a priori;
(peut être) multivalué, prendre plusieurs valeurs distinctes dans son domaine ;
dérivé, sa valeur est une fonction sur d’autres attributs.

@startuml voiture2
scale 2.5
skinparam backgroundcolor transparent
skinparam defaultFontName Hack

class Voiture {
{field} Immatriculation: string
{field} Vin: string
{field} Marque: string
{field} Type: string
{field} NbPortes: integer
{field} Puissance: integer
{field} Kilométrage: integer
{field} Age: integer
{field} Date1erMEC: date
{method} Rouler()
}

note right of Voiture::Age
Age = maintenant - Date1erMEC
endnote

hide methods

@enduml

Association¶

Relation logique entre deux classes (association binaire) ou plus (association n-aire). Une association est:

est nommée, généralement par un verbe. - peut avoir des propriétés. - définit le nombre minimum et maximum d’instances autorisée dans la relation (cardinalité).

@startuml association
scale 2.5
skinparam backgroundcolor transparent
skinparam defaultFontName Hack

class ClasseA {
}

class ClasseB {
}

ClasseA -- ClasseB: Verbe

hide methods

@enduml

Association porteuse de valeurs¶

@startuml classes_association

scale 2.5
skinparam backgroundcolor transparent
skinparam defaultFontName Hack
left to right direction

class A {
}

class B {
}

class C {
field
}

A "0..*" - "1..*" B
(A, B) .. C

hide methods

@enduml

@startuml classes_association_exemple

scale 2.5
skinparam backgroundcolor transparent
skinparam defaultFontName Hack
left to right direction

class Étudiant {
nom
prénom
}

class Cours {
intitulé
}

class Inscrit {
notes
}

Étudiant "0..*" - "1..*" Cours
(Étudiant, Cours) .. Inscrit

hide methods

@enduml

Cardinalités¶

Elle permet de représenter le nombre minimum et maximum d’instances qui sont autorisées à participer à la relation. La cardinalité est définie pour les deux sens de la relation et la notation en UML est opposée à celle adopté en E/A.

@startuml voiture3
scale 2.5
skinparam backgroundcolor transparent
skinparam defaultFontName Hack

left to right direction

class Personne {
{field} Nom: string
{field} Prénom: string
{field} NuméroPermis: string
}

class Voiture {
{field} Immatriculation: string
{field} Vin: string
{field} Marque: string
{field} Type: string
{field} NbPortes: integer
{field} Puissance: integer
{field} Kilométrage: integer
{field} Age: integer
{field} Date1erMEC: date
{method} Rouler()
}

Personne "1" -- "N" Voiture: Possède

hide methods

@enduml

Héritage UML¶

Relation entre deux classes permettant d’exprimer que l’une est plus générale que l’autre. Implique une transmission automatique des propriétés (attributs et méthodes) d’une classe \(A\) à une classe \(A'\). Dire que \(A'\) hérite de \(A\) équivaut à dire que \(A'\) est une sous-classe de \(A\).

@startuml heritage
scale 2.5
skinparam backgroundcolor transparent
skinparam defaultFontName Hack

left to right direction

class ClasseA {
}

class SousClasse {
}

ClasseA <|-- SousClasse

hide methods

@enduml

Permet de représenter la relation « est-un » et représente une relation courante dans le monde réel. L’avantage est bien évidemment la factorisation de définition de propriétés identiques pour des classes proches.

Des voitures et des conducteurs¶

@startuml voiture4
scale 2.5
skinparam backgroundcolor transparent
skinparam defaultFontName Hack

left to right direction

class Personne {
{field} Nom: string
{field} Prénom: string
{field} DateNaissance: date
{field} Age: integer
}

class Conducteur {
{field} NuméroPermis: string
{field} DatePermis: date
}

class Voiture {
{field} Immatriculation: string
{field} Vin: string
{field} Marque: string
{field} Type: string
{field} NbPortes: integer
{field} Puissance: integer
{field} Kilométrage: integer
{field} Age: integer
{field} Date1erMEC: date
{method} Rouler()
}

Personne <|-- Conducteur
Personne "1" -- "N" Voiture: Possède
Conducteur "*" -- "*" Voiture: Conduit

hide methods

@enduml

On en déduit que les conducteurs sont des personnes qui ont un permis, toute voiture est possédée par une unique personne (qui peut en posséder plusieurs), les voitures peuvent être conduites par des conducteurs et que les conducteurs peuvent conduire plusieurs voitures.

Avertissement

Le but d’une modélisation UML n’est pas de représenter la réalité dans l’absolu, mais plutôt de proposer une vision d’une situation réduite aux éléments nécessaires pour répondre au problème posé.

Donc une modélisation s’inscrit toujours dans un contexte, et en cela l’exemple précédent reste limité car son contexte d’application est indéfini.