2 Présentation du projet
En vue d'avoir un suivi quotidien de l'activité de l'entreprise : la Brigade de Sapeurs Pompiers de Paris, une solution de Business Intelligence doit être mise en place afin de faciliter l’accès aux statistiques opérationnelles.
Pour cela, une base relationnelle qui actuellement sert d'historique va être utilisée. Cette base, ancienne, ne respecte pas les règles classiques d'une base relationnelle (absence de clé primaire, ...), ce qui ne sera pas sans poser quelques problèmes.
La structure de la table est difficile à comprendre au premier abord, ce qui illustre parfaitement la difficulté d’accès aux informations pour toutes personnes ne connaissant pas la structure de la base.
La structure est décrite ci-dessous plus précisément.
2.1 Gestion des adresses et des sites
La BSPP a recensée toutes les rues de sa zone d’intervention. On distingue dans cette zone trois types de sites :
- Adresses classiques
- Etablissements signalés
- Etablissements répertoriés.
Toutes les informations concernant les rues de la zone d’intervention de la BSPP et les différents types de sites sont disponibles dans les tables suivantes :
- rue4 (contient les numéros et libelles des rues)
- numrue, clé primaire
- deno : dénomination des rues
- mc5 (contient les informations complémentaires (type de rue, mots clefs))
- numrue : identification de la rue
- codtyp : avenue, boulevard,...
- motcle : mots clefs permettant la recherche lors d'un d'appel
- proche (contient des informations complémentaires sur le découpage des rues par zone d’intervention ainsi que les informations concernant les établissements répertoriés)
- numrue : identification de la rue
- numsit : identification du site (égal à « NULL » si adresse classique, ainsi, si une rue contient quatre établissements, il y aura cinq entrées dans la table).
- signale ( contient les informations sur les établissements signalés, la structure étant la même que « proche », ces informations auraient pu être directement intégrées dans la table « proche »)
- numrue : identification de la rue
- numsit : identification du site (ne contient que des établissements signalés, ainsi, si une rue contient quatre établissements, il y aura quatre entrées dans la table) (pour « proche » et « signale » : d’autres champs concernant le découpage par zone existe, mais dans la mesure ou ceux-ci ne sont pas utiles dans le cadre du rapport de statistiques opérationnels, ils ne sont pas présentés).
- site (contient les informations sur les établissements (signalés et répertoriés))
- numsit : identification de l’établissement
- raisoc : raison sociale de l’établissement
- commune (contient le nom de la ville ainsi que le département)
- codvil : identification de la ville
- ville : libelle de la ville
- coddep : code du département
- types (contient le libelle du type de voie (avenue, rue, ...)
2.2 Motifs d’interventions
Deux tables existent pour la gestion des motifs d’interventions :
- motif (contient tous les motifs de départ de véhicules en interventions)
- motinv (contient tous les motifs réels d’interventions : renseignés par le responsable de l’intervention après celle-ci, cela permet de renseigner plus précisément le type d’intervention effectué et de corriger les erreurs du au manque de précision lors des appels)
Ainsi, il est possible qu’un véhicule qui part pour feu de poubelle soit en réalité confronté à un feu d’appartement. Ce système permet de distinguer le motif de départ et l’intervention réellement effectuée.
2.3 Intervention, ordre et CS
Trois autres tables vont être nécessaires pour la mise au point du projet.
- intervention (contient les informations sur l’intervention : lieu, date de l’appel, …)
- numint : numéro de l’intervention (remis à zéro chaque année)
- csemet : centre émetteur du départ sur intervention (csemet + numint forment la clef primaire par année des interventions)
- numrue : adresse de l’intervention
- numsit : établissement concerné (si nécessaire)
- datapp : date de l’appel (date + heure (à la seconde))
- codmtf : motif de départ
- codint : motif réel
- ordre (recense la date de l’ordre de départ en intervention et le CS (centre de secours) sélectionné pour cette intervention (il peut donc y avoir plusieurs entrées pour une intervention))
- numint : numéro de l’intervention (remis à zéro chaque année)
- csemet : centre émetteur du départ sur intervention (csemet + numint forment la clef primaire par année des interventions)
- datord : date de l’ordre de départ
- csint : CS concerné par l’intervention
- cs (recense tous les centres de secours de la brigade)
- codcs : identifiant du CS
- libcs : libellé du CS
- grpt : groupement du CS (la zone brigade est découpée en trois groupement)
- pccie : compagnie du CS (chaque groupement est subdivisé en compagnie d’incendie)
Il s’agit des champs qui seront utilisés durant le projet.
2.4 Problèmes liés à la structure de la base de données
Comme cela est visible, la base est loin d'être optimisée (peu de clef primaire, information redondante). En effet, maintenant que la structure de type relationnelle du projet est présentée, il est possible de se rendre compte des problèmes que peut poser une base de ce type. Ces problèmes empêchent un accès simple aux données dans le but de prendre une décision.
Les problèmes qui vont se poser sont les suivants :
Pas de jointure simple possible entre intervention et ordre dans la mesure ou nous travaillons sur une base ancienne de plusieurs années et que « numint » se remet à zéro tous les ans. Il va être nécessaire d'utiliser les dates, mais les mêmes références ne sont pas disponibles dans ces deux tables (« datord » diffère de « datapp »).
La gestion des rues est très complexe, avec des redondances d'informations. Il va être nécessaire de revoir entièrement la structure de la table adresse en décomposant selon trois cas : le cas des adresses classiques, le cas des établissements répertoriés et le cas des établissements signalés (ces deux derniers pouvant être traités de la même façon.
Il faudra enfin prendre en compte les possibles évolutions : changement de nom de rue, ... afin de créer un historique de ces interventions.
Nous allons pouvoir corriger ces problèmes avec integration services.
 Sommaire
Introduction
1. Business Intelligence et SQL Server 2005
2. Présentation du projet
2. Integration services
3. Analysis services
4. Reporting services
Annexe 1 - Gestion de la sécurité du site de reporting
Annexe 2 - Personnalisation du site de reporting
Conclusion
|
|
 |
 Pour afficher ou poster un commentaire, cliquez sur ce lien : Forum-Microsoft
|
|
Solution de Business Intelligence avec SQL Server 2005
