Please enable JavaScript.
Coggle requires JavaScript to display documents.
Modèles de données - Coggle Diagram
Modèles de données
MCD : Modèle Conceptuel de données
objectifs
mémorise les données du SI
partie la plus stable du SI
éléments
entités
formalisme graphique (variant)
définition
décrit une classe d'objet concret ou abstrait
formalisme textuel
nom
sémantique : description
liste des attributs
associations
définition : décrit des classes de liens entre entités n'ayant pas d'existence propre (si les entités n'existent pas, l'association n'existe pas).
formalisme graphique (insuffisant)
textuel
nom
sémantique : description du lien
entités liées
éventuels attributs
rôle
définition
chaque lien qui relie une association à une entité
attributs
définition
prend sa valeur dans un domaine simple (INT, CHAR, String, etc.)
propriétés qui décrivent une entité ou une association
graphiquement : dans les entités
textuel
nom
sémantique : description de la propriété
domaine, càd type
contraintes éventuelles (syntaxe, valeurs admissibles, etc.)
occurrence
définition
l'occurrence d'une entité est un exemplaire de cette entité (par ex: association)
est décrite par les valeurs de ses attributs
attributs identifiants
définition
est identifiant si une valeur de la propriété ne correspond qu'une seule occurrence de l'entité
construction
à partir des autres modèles Merises
à partir des documents internes
spécialisation / généralisation
relation particulière entre entités
G généralise S (si S est hérité de G)
S spécialise G (si S hérite de G)
contraintes
exclusion mutuelle des sous-ensembles
X indique l'exclusion
totalité des sous-ensembles (il n'en manque pas)
T indique la totalité
(parfois c'est une double barre ou une flèche double)
composition
définition
relation particulière entre entités
une entité "principale" peut être composée d'autres entités
(si l'entité "principale" est détruite les autres entités sont détruite)
exemple : une entité hôtel composée d'entités chambres
représentation graphique
en MERISE
en UML
qualité
définition
la dépendance fonctionnelle d'un attribut (Q) est vrai si sa valeur dépend de celle d'un autre attribut (P) de l'entité
notation
cf. ci-dessus : P -> Q
forme
élémentaire
si la seule combinaison de plusieurs attributs donne la valeur du (ou des) attribut en dépendance fonctionnelle.
directe
si il n'y a pas d'intermédiaires
(exemple, P -> I est de forme directe
mais si I -> Q, alors P -> Q n'est pas directe).
règles de vérification
les noms des entités, associations, attributs sont distincts
chaque entité à au moins un identifiant
tout attribut est élémentaire (càd non décomposable)
les attributs d'une entité sont tous en dépendance fonctionnelle élémentaire de l'identifiant de cette entité (Cf. ci-dessous)
contraintes
sur les valeurs possibles d'un attribut (possible en MCD)
si une valeur d'attribut dépend de la valeur d'un autre attribut (impossible en MCD) sauf dépendance fonctionnelle
l'évolution de valeur d'un attribut (impossible en MCD)
exemple interdire une baisse de salaire
entre entité (possible en MCD grâce aux associations)
entre associations
(impossible en Merise/1, mais possible en Merise/2)
MLD : Modèle Logique de Données
MCD -> MLD
Une entité devient une relation
Un identifiant d'entité devient une clé de relation
Associations
Si association binaire (cardinalités 0, 1 ou 1, 1) alors fusion des entités et association dans la même relation.
Si association (cardinalités 1, 1 et 1, n), on ajoute un attribut dans relation 1,1 qui liait à l'autre entité
Si association (0,n / 1,n des 2 côtés) , l'association devient une relation avec pour clé les clé des 2 autres entités.
Transformations
T1
une relation par super-entité et par sous-entité
La clé de le super-entité devient la clé des sous-entités.
T2
une relation par sous-entité, aucune pour la super-entité
Les attributs de la super-entité descendent dans chaque sous-entité
valeurs nulles pour les attributs spécifiques à la super-relation
obligation de faire des recherches "successives" dans les sous-relation pour trouver une information précédemment contenue dans la super-relation.
T3
une relation pour la super-entité, rien pour les sous-entité + un attribut pour distinguer les sous-entités
Les attributs des sous-entités sont intégrées dans la super-relation. En plus un attribut binaire pour chaque sous-relation est créé pour distinguer les valeurs qui appartenaient à une sous-entité jusqu'alors.
T4
une relation pour la super-entité, rien pour les sous-entité et aucun attribut pour distinguer les sous-entités
Les attributs des sous-entités sont intégrées dans la super-relation. Recherche de valeurs plus difficile que pour le T3.
choix de transformation
priorité à la qualité des données
T1
représentation explicite de la réalité
minimisation des valeurs indéfinies
Priorité au temps de calcul
T3 ou T4
Pas T1 : relation supérieur calculée par jointure
Pas T2 : recherche d'éléments de la super-relation nécessite parcours successif des sous-relations
Pas de préférence particulière
généralisation totale
T3
généralisation disjointe non-totale définie par un attribut
T3
généralisation multiples (sous-classe de plusieurs autres)
T1
plus systématique
toutes les entités sont représentées
pour conclure sur le choix de transformation
le choix d'une transformation n'est pas automatique
T2 souvent impossible
T4 peu pratique
T1 et T3 souvent choisis
suivant les priorités aux données ou aux calculs
puis type d'héritage.
choix à documenter dans le MLD
méthode de transformation choisie
motivation du choix
Normalisation du MLD
FN1 : tous les attributs ne doivent pas être décomposables
FN2 : Comme FN1 auquel ont rajoute des dépendances élémentaire (dépendances entre toute la clef et non une partie de la clef)
FN3 : Comme FN2 auquel on rajoute que les dépendances sont directes (les attributs dépendent tous de la clef)
Un bon MCD donne un MLD normalisé
coût du MLD (en fonction des volumétries du MOD)
optimisation des traitements
modifier les choix sur la représentation des spécialisation
( ex : choix orienté données vers un choix orienté traitement)
transformer les attributs
codage plus petit
attention perte de lisibilité
dénormaliser
attention perte de qualité et risque d'erreur
dupliquer les données dans les super-relations et les sous-relations (donnée plus souvent accessible = donnée plus rapidement accessible)
MOD : Modèle Opérationnel de Données
QOCQ
Où ?
sont stockées les entités / associations (régional, central, local)
Par niveau organisationnel, définir le stockage des données
Qui ?
a accès à quelle entité / association (droit accès, données)
poste de travail
rôle ou les rôles attribués dans l'organisation
localisé géographiquement
positionné dans l'organisation
disposant de ressources
comment les définir ?
analyser les sources
(organigramme, entretiens, étude de documents, etc.)
utiliser les informations du RH
Quels accès leur fournir ?
création
modification
suppression
lecture simple
Matrice CLMS
En colonne : les entités et associations
En ligne : les postes de travail
Dans les cellules : les droits d'accès
(créer, lire, modifier, supprimer)
Combien ?
d'occurrences d'entités / d'associations
Pour chaque donnée (entité / association) définir la quantité maximale prévue dans le SI
Quand
les occurrences sont enregistrées dans le SI et archivées
Pour chaque donnée (entité / association) définir la quantité de donnée par période de temps et la fréquence d'archivage.
mêmes éléments que le MCD, pour chaque QOCQ
MPD : Modèle Physique de Données
implémentation concrète des données
SQL
règles de transformation
primitive de création avec contraintes
individuelle (sous-type des attributs, clés)
inter-relations (clés externes)
trigger pour les contraintes non exprimables
optimisation des données
optimisation par index
structure les données
accès plus rapide
implantation plus structurée
contraintes de sous-type + check éventuel
clé : primary key
clé externe : foreign key
langage de programmation
Transformation en langages physiques
objets
relations entre objets
contraintes
