Système de gestion de bases de données. Modélisation des traitements

F. Kohler

Plan Concepts de base pour la manipulation des

informations Concepts de base pour la description de la

dynamique Événement et type d’événement Opération et type d’opération Synchronisation te type de synchronisation Démarche pour l’élaboration d’un schéma conceptuel

des traitements (SCT) Vérification d’un SCT Démarche pour l’élaboration d’un schéma logique des

traitements (SLT) Niveau physique des traitements

Concepts de base pour la manipulation des donées Actions élémentaires sur le schéma ou sur les données :

Ajouter : Enregistrer une entrée => Vérifier si elle existe => Rechercher Si existe : ne pas enregistrer, sinon saisir et enregistrer

Supprimer Rechercher Modifier

Actions : Suite d’actions élémentaires constituant un tout pour

transformer ou faire connaître tout ou une partie du schéma ou des données

Commandes élémentaires : Ordre permettant de déclencher une action élémentaire

Commandes : Ordre permettant de déclencher une action

Événement et type d’événement Événement :

Constatation d’un changement d’état dans l’environnement du SI

Événement externe : arrivée d’un nouveau patient Événement interne : transfert inter-service

Un type d’événement Décrit une classe d’événements : « arrivée d’un patient » Est défini par :

Type de commande qui détermine la ou les actions à effectuer Son message qui décrit les informations qui lui sont associées Un identifiant des occurrences du type d’événement Sa fréquence d’apparition Sa capacité : nombre maximum d’occurrences que l’on peut

prendre en compte

Description lexicale d’un événement Événement : <nom du type

d’événement> Type de commande : <nom opération> Message : <liste , structure et types des

information décrivant le type d’événement>

Identifiant : <attribut(s) identifiant(s) Fréquence : <fréquence> Capacité : <capacité>

Exemple : Type d’événement : « arrivée de patients » Type de commande : Nouveau_Patient Message : N° patient, Nom de famille, nom

d’usage, premier prénom, autres prénoms, date de naissance, sexe… en format balisé.

Identifiant : N°patient, date de création Fréquence : 100/jours Capacité : 120

Opération et type d’opération Action à entreprendre en réaction à un

événement ou à un ensemble d’événement Une opération produit un ou des résultats

(événements) Les informations qui décrivent les messages des

événements qui ont déclenché l’opération servent de paramètres en entrée de l’opération

Les informations qui décrivent les événements produits par l’opération constituent les résultats de l’opération

Type d’opération Un type d’opération est défini par

Le ou les types d’événement à produire à l’issue de l’opération. Cette production peut être conditionnelle, il faut alors expliciter la condition pour tout type d’événement à produire : par exemple produire des étiquettes.

La durée de l’opération : le temps d’attente maximal pour rassembler les événements et activer l’opération conséquence de la synchronisation. Passée cette durée, on effectue une relance (ex : résultats d’examens d’un patient). La durée permet de calculer la capacité

L’action qu’une opération du type réalise. Cette action pourra être spécifiée par le biais d’un algorithme décrivant les actions élémentaires à réaliser sur la base (recherche, ajout, modification, suppression, traitement à faire réellement).

Description lexicale : Opération : <nom opération> Durée : <durée> Action : algorithme exprimant :

Les conditions de production de chaque type d’événement en sortie

Les actions effectuées sur la base et les entités concernées

Remarque : Vérifier que le SCD comporte les éléments nécessaires à la satisfaction des actions

Synchronisation et type de synchronisation Condition de déclenchement d’une opération Un type de synchronisation est décrit par :

La donnée des types des événements qui participent à la synchronisation

Une condition portant sur ces types d’événement Une condition locale qui précise comment choisir

l’occurrence d’un type d’événement à traiter lorsque plusieurs occurrences du même type sont présentes

Un délai de synchronisation qui indique le temps maximum entre l’arrivée du premier événement et celle du dernier qui contribuent à la synchronisation

Une durée limite qui spécifie le temps maximum entre entre l’arrivée du premier événement et celle du dernier qui contribuent à la synchronisation

Description lexicale Synchronisation : <nom de

synchronisation> Condition : <Condition de

synchronisation> Condition locale : <Condition locale> Délai : délai> Durée :<durée limite>

Représentation graphique

Nom du typeD’événement

Nom du typeD’événement

Condition de synchronisationNom de la

Synchronisation

Nom du type d’opération

Condition deproduction

Condition deproduction

Type d’événementInterne (résultat)

Type d’événementInterne (résultat)

2

3

On peut avoir besoin de spécifier le nombre d’occurrences d’un même type d’événement

Démarche pour élaborer un SCT Identification et prise en compte des règles de

gestion Exemple dans un SI d’une assurance

Toute déclaration incorrecte n’est pas enregistrée , elle entraîne un avis au sinistré qui devra faire une nouvelle déclaration

Le règlement ne se fera qu’après réception de la facture du garage

Les dossiers sont archivés à chaque fin d’année calendaire

Identification des acteurs et des flux d’informations entre acteurs

Ordonnancement des flux

Exemple

Déclaration

Demande d’expertise Avis-rectification

Retour d’expertise Facture garage

Règlement

Élaboration du SCT Événement EVT0 : arrivée déclaration

Type de commande : Ouverture-dossier Message : N°assuré, date-déclaration, circonstances, nom-assuré,.. Identifiant : N°assuré et Date-arrivée Fréquence 5/J Capacité 50

Opération Ouverture-dossier Durée ; 4 minutes Action

Si déclaration Ok Alors :

Ouvrir dossier sinistre, Faire demande d’expertise Résultat r=1

Sinon : Renvoyer la déclaration à l’assuré Résultat r = 2

Fin de si Affecter un N° de dossier d et résultat r à la déclaration N° assuré et Date-arrivée Ajouter le dossier d à la base

SCT assurance

Vérification d’un SCT Inspiré des réseau de Pétri

Vérification locale à un nœud Tout attribut en entrée d’une synchronisation doit appartenir au

schéma des données ou en être dérivable (calculable) La cardinalité d’événement en sortie d’une opération ne doit

pas être supérieure à la capacité du type d’événement La participation d’un type d’événement à une synchronisation

ne doit pas être supérieure à sa capacité (surcharge) La disjonction des règles d’émission des types d’événements en

sortie d’une opération doit être vraie (éviter un blocage et être certain de produire un résultat)

Vérification globale Atteignabilité : la composition de diverses conditions de

synchronisation S1, S2,…,Sn ne doit pas conduire à ce qu’une condition de synchronisation Sn+1 soit toujours fausse. En effet, cela signifierait que l’opération dépendante de Sn+1 ne serait jamais déclenchée et par conséquent ses résultats jamais produits

Élaboration du schéma logique des traitements

Intérêt du niveau logique Répartition des tâches homme-machine (Qui) Détermination des postes de travail (Où) Choix du type de traitement : temps réel. Différé

(Comment) Définition des échanges d’informations : (Ce qu’il faut

faire) Format des écrans de saisie Dessin des documents de sortie

Évaluation du coût de la base (coût de stockage et des traitements

Adaptation du SLD et du SLT afin d’optimiser les coûts

Élaboration du schéma logique des traitements Prise en compte des choix organisationnels

Les agences régionales enregistrent les sinistres Elles désignent un expert L’agence centrale effectue les remboursements

Remarque : automatiser le plus d’activités possibles Construction du SLT

Découper les opérations en procédures Affecter chaque procédure à un poste de travail Détailler l’analyse de chaque procédure Définir l’enchaînement des procédures Chaque tâche doit respecter les contraintes suivantes :

Être affectée à un poste de travail Ne pas être interruptible Être déclenchée par une synchronisation ou un événement

Niveau physique des traitements On ne considère que les acteurs machine On prend en compte les contraintes matérielles et

logicielles On détermine l’architecture globale des programmes Les procédures du niveau logique donneront lieu à

des transactions utilisant les outils de manipulation du SGBD (LMD, langage hôte… exemple PHP/mySQL)

Les écrans définis au niveau logique doneront lieu à des définitions d’écrans « physique » : utilisation du gestionnaire d’écran du SGBD, page hôte HTML..

Les étapes suivantes

Chargement de la base d’essai Test et mise au point Mise en exploitation Maintenance et évolution