View
113
Download
4
Category
Preview:
Citation preview
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
Recommended