3.2. MODELE PHYSIQUE DE DONNES RELATIONNEL
Les schémas relationnels de la base de données a
été implémenter en utilisant le SGBD relationnel Microsoft
Access 2002. Compte tenu de la commodité du mémoire et de la
multiplicité des tables ainsi que des spécificités
techniques du SGBD Microsoft Access, nous demandons aux lecteurs de pouvoir
consulter le CO d'accompagnement pour la visualisation en ligne du
modèle physique de notre base de données.
Toutefois, pour crédibiliser ce renvoi, nous avons
présenté ci-dessous le schéma (ou la structure) physique
graphique de la table Etudiant issue des schémas relationnels
traduits en modèle physique de données : vue interne d'une
table.
171
En outre, les schémas relationnels physiques
constituant le modèle physique de données (MPD), de part sa
vue relationnelle, se présente graphiquement comme suit :
172
Section 4 : MODELISATION PHYSIQUE DES TRAITEMENTS
Le modèle physique de traitements représente la
solution technique de construction du logiciel, c'est l'ensemble des programmes
informatiques assurant l'exécution des traitements informatisés
du système d'information. Cet ensemble est organisé en une
architecture technique de programmes matérialisant la logique des
traitements spécifiée dans le modèle logique de
traitements, en fonction des possibilités techniques et des moyens de
programmation. Ces programmes sont, suivant la terminologie technique
adoptée, désignés par :
transaction, programme, unité de
traitement...1
4.1. LE FORMALISME DE LA MODELISATION PHYSIQUE DE
TRAITEMENTS
Il faut reconnaître que la méthode Merise n'a
jamais eu l'ambition d'aborder de façon détaillée cette
modélisation physique des traitements. Aussi, aucun formalisme n'a
jusqu'à présent été proposé pour la
spécification des programmes.
Le schéma du modèle physique de traitements
représente alors l'articulation et les enchaînements possibles
entre les différents programmes.2
Dans le processus de regroupement d'ULT en programmes, on peut
constater les usages suivants :
? Dans un environnement batch, les ULT correspondant à
une phase automatisée différée se regroupent dans un
programme ; les ULT peuvent souvent se traduire par des sous-programmes ou des
blocs copiables ; le programme regroupe généralement un grand
nombre d'ULT.
? Dans les environnements transactionnels classiques, les ULT
correspondant à une tâche conversationnelle sont
généralement regroupées autour d'une ULT principale
comprenant un module dialogue selon le principe "une transaction, un
écran" ; l'accès aux différentes transactions ainsi
que certaines ULT de guidage sont traduits par des menus.
? Dans les environnements récents ou futurs, le
regroupement d'ULT en programmes ne dépend plus de l'enchaînement
logique, mais de la nature des ULT et d'objectifs de modularité (les
modules de guidage ensemble, les modules de dialogue ensemble, les accès
aux
1 Dominique NANCI et Bernard ESPINASSE,
Op.cit., p. 439.
2 Dominique NANCI et Bernard ESPINASSE, Idem,
p. 440.
1 Dominique NANCI et Bernard ESPINASSE,
Op.cit., p. 440.
173
données ensemble...) ; le modèle physique de
traitements n'a alors plus vraiment d'intérêt.1
| 
