Modélisation du système d’information – la gestion locative
Modélisation du système d’information
Modéliser, c’est construire des modèles, c’est décrire de manière visuelle et graphique les besoins et les solutions fonctionnelles et techniques de l’applicatif en conception [18]. Un modèle est un ensemble de concepts clairs et d’outils utilisés pour réaliser un schéma permettant de communiquer sans ambigüité [19].
Il s’agit ici d’utiliser des formalismes précis et normalisés pour modéliser les différents axes (données et traitements) du système d’information à chaque niveau d’abstraction.
Cependant, puisque dans un système d’information en fonctionnement, données et traitements apparaissent intimement liés (surtout du point de vue de l’utilisateur) [9] et paraissant toutefois suffisants pour une modélisation Merise, trois modèles dont le modèle conceptuel des données (MCD), le modèle logique des données (MLD) et le modèle physique des données (MPD) ont été choisis dans le cadre de ce travail et présentés selon le formalisme navigationnel.
Mais pour bien représenter le MCD, il faut élaborer selon les règles de l’art le dictionnaire des données.
Dictionnaire des données
Le dictionnaire des données est un document qui permet de recenser, de classer et de trier toutes les informations (les données) collectées lors des entretiens ou de l’étude des documents. Il est dit brut lorsqu’il répertorie les informations de tout type, c’est-à-dire les données paramètres, les données élémentaires ainsi que les données calculées.
En revanche, il est dit épuré lorsqu’il ne répertorie que les données élémentaires, les données paramètres et calculées restant écartées [6].
Les données du dictionnaire des données du système sous étude ont été tirées de nos entretiens avec le gestionnaire (annexe 1) et des différents documents mis à notre disposition, notamment le registre des locataires (annexe 2), le contrat de location (annexe 3) et le reçu de paiement (annexe 4).
Ces données sont de format alphanumérique (AN), alphabétique (A), numérique (N) et date (D), et de type élémentaire (Elém) et calculé (Calc).
Les tableaux 2.1 et 2.2 présentent respectivement le dictionnaire des données brut et le dictionnaire des données épuré du système sous étude.
Tableau 2.1. Dictionnaire des données brut
| Code | Nom | Format | Taille | Type | Règle de gestion | Document | |
| Elém | Calc. | ||||||
| numLocataire | Numéro de locataire | AN | 10 | X | Registre | ||
| nomComplet | Nom complet | AN | 50 | X | Nom et post-nom | Registre | |
| adrProv | Adresse de provenance | AN | 50 | X | Registre | ||
| nomPere | Nom du père | AN | 50 | X | Nom et post-nom | Registre | |
| nomMere | Nom de la mère | AN | 50 | X | Nom et post-nom | Registre | |
| nomTuteur | Nom du tuteur | AN | 50 | X | Nom et post-nom | Registre | |
| Telephone | Numéros de téléphone | AN | 50 | X | Registre | ||
| numContrat | Numéro du contrat | AN | 10 | X | Contrat | ||
| totalLoyer | Montant total du loyer | N | 6 | X | Contrat | ||
| dateLocation | Date de location | D | 10 | X | Contrat | ||
| dureeContrat | Durée du contrat | AN | 10 | X | jj/mm/aaaa | Contrat | |
| numPaiement | Numéro du paiement | AN | 15 | X | Reçu | ||
| montantPaye | Montant payé | N | 6 | X | Reçu | ||
| Solde | Solde à payer | N | 6 | X | Loyer total-total payé | Reçu | |
| datePaiement | Date de paiement | D | 10 | X | jj/mm/aaaa | Reçu | |
| modePaiement | Mode de paiement | AN | 30 | X | Reçu | ||
| motifPaiement | Motif de paiement | AN | 50 | X | Reçu | ||
| anneeAcademique | Année académique | AN | 12 | X | Registre | ||
| description | Description de l’année | AN | 50 | X | Registre | ||
| numChambre | Numéro de la chambre | AN | 5 | X | Registre | ||
| desiChambre | Désignation chambre | AN | 50 | X | Registre | ||
| numBatiment | Numéro du bâtiment | AN | 5 | X | Registre | ||
| desiBatiment | Désignation bâtiment | AN | 50 | X | Registre |
Tableau 2.2. Le dictionnaire des données épuré.
| Code | Nom | Format | Taille | Type élémentaire | Règle de gestion | Document |
| numLocataire | Numéro de locataire | AN | 10 | X | Registre | |
| nomComplet | Nom complet | AN | 50 | X | Nom et post-nom | Registre |
| adrProv | Adresse de provenance | AN | 50 | X | Registre | |
| nomPere | Nom du père | AN | 50 | X | Nom et post-nom | Registre |
| nomMere | Nom de la mère | AN | 50 | X | Nom et post-nom | Registre |
| nomTuteur | Nom du tuteur | AN | 50 | X | Nom et post-nom | Registre |
| Telephone | Numéros de téléphone | AN | 50 | X | Registre | |
| numContrat | Numéro du contrat | AN | 10 | X | Contrat | |
| totalLoyer | Montant total du loyer | N | 6 | X | Contrat | |
| dateLocation | Date de location | D | 10 | X | Contrat | |
| dureeContrat | Durée du contrat | AN | 10 | X | jj/mm/aaaa | Contrat |
| numPaiement | Numéro du paiement | AN | 15 | X | Reçu | |
| montantPaye | Montant payé | N | 6 | X | Reçu | |
| datePaiement | Date de paiement | D | 10 | X | jj/mm/aaaa | Reçu |
| modePaiement | Mode de paiement | AN | 30 | X | Reçu | |
| motifPaiement | Motif de paiement | AN | 50 | X | Reçu | |
| anneeAcademique | Année académique | AN | 12 | X | Registre | |
| description | Description de l’année | AN | 50 | X | Registre | |
| numChambre | Numéro de la chambre | AN | 5 | X | Registre | |
| desiChambre | Désignation chambre | AN | 50 | X | Registre | |
| numBatiment | Numéro du bâtiment | AN | 5 | X | Registre | |
| desiBatiment | Désignation bâtiment | AN | 50 | X | Registre |
Modèle conceptuel des données
Le modèle conceptuel de données (MCD) est la représentation de l’ensemble des données du système, sans tenir compte des aspects techniques et économiques de mémorisation et d’accès et sans se référer aux conditions d’utilisation par tel ou tel traitement [9]. Il exprime les règles de gestion de l’entreprise à travers les cardinalités des relations entre les entités ou objets-types.
Ces données sont organisées en entités ou objets-types et sont appelées les propriétés de ces entités.
Pour le système sous étude, le MCD conçu comprend six objets-types en relation, à savoir l’objet- type Locataire, l’objet-type ContratLocation, l’objet-type Batiment, l’objet-type Chambre, l’objet-type Paiement et l’objet-type AnneeAcademique.
L’objet-type Locataire regroupe toutes les informations que le gestionnaire souhaite savoir sur la locataire, c’est-à-dire son identifiant, son nom complet, son numéro de téléphone, son institution, son adresse de provenance, les noms de son père, de sa mère et de son tuteur.
L’objet-type ContratLocation regroupe les informations relatives au contrat de location, c’est-à- dire le numéro du contrat, sa durée, la date de location ainsi que le loyer total à payer.
L’objet-type Batiment regroupe les informations concernant le bâtiment en location, c’est-à-dire son numéro et sa désignation.
L’objet-type Chambre regroupe les informations concernant la chambre en location, c’est-à-dire le numéro de la chambre ainsi que sa désignation.
L’objet-type Paiement regroupe les informations relatives au paiement effectué, c’est-à-dire le numéro de paiement, le montant payé, le motif de paiement et le mode de paiement.
L’objet-type AnneeAcademique regroupe les informations concernant l’année académique concernée par le contrat de location, c’est-à-dire l’année académique et sa description.
En plus, les règles de gestion locative telles qu’identifiées au Centre Olame sont les suivantes :
(i) une locataire peut conclure un ou plusieurs contrat de location et un contrat de location est conclu par une et une seule locataire ; (ii) un contrat de location concerne une et une seule chambre, mais une chambre peut être concernée par deux contrats de location à la même année;
(iii) un bâtiment peut comporter zéro ou plusieurs chambres et une chambre se trouve dans un et un seul bâtiment ; (iv) un contrat de location est associé à une et une seule année académique, mais à une année académique, zéro ou plusieurs contrats peuvent être associés ; (v) une locataire peut effectuer zéro ou plusieurs paiements, mais un paiement est effectué par une et une seule locataire ; (vi) un paiement se rapporte à une et une seule année académique, mais à une année académique zéro ou plusieurs paiement peuvent se rapporter.
Ainsi, la figure 2.1 présente le modèle conceptuel des données du système sous étude suivant le formalisme navigationnel, la propriété identifiant l’objet étant en gras-soulignée et marquée par une clé à côté, la cardinalité portée de part et d’autre d’une relation donnée représentant le nombre d’occurrences de la relation que possède l’occurrence d’un objet-type via cette relation.
Figure 2.31. Modèle conceptuel des données (MCD).
Modèle logique des données
Le modèle logique de données (MLD) décrit les structures de données indépendamment de la gestion physique des bases de données. Le MLD est adapté à une famille des SGBD donnée. Il dérive du MCD en transformant tous les objets-types en tables, toutes les propriétés des objets- types en attributs et la propriété identifiant l’objet en clé primaire selon les règles d’usage [6].
En plus, en vertu de la règle de transformation de l’identifiant relatif, la table issue de l’objet-type dépendant contient comme clé étrangère, la clé primaire de l’autre table [6].
Le modèle logique des données construit dans cette étude est adapté à la famille des systèmes de gestion des bases de données relationnelles.
Un système de gestion des bases de données est dit relationnel (SGBDR) lorsqu’il réunit dans des tables l’ensemble des données et tous les liens qui les unissent et comporte essentiellement un langage relationnel de définition et de manipulation des données (19).
Ainsi, nous obtenons le MLD de la figure 2.2 de la manière suivante : (i) l’objet-type Locataire devient la table Locataire. Son identifiant (numLocataire) devient la clé primaire de la table Locataire et la clé étrangère des tables ContratLocation et Paiement ; (ii) l’objet-type ContratLocation devient la table ContratLocation.
Son identifiant (numContrat) devient la clé primaire de la table Locataire ; (iii) l’objet-type Batiment devient la table Batiment. Son identifiant (numBatiment) devient la clé primaire de la table Batiment et la clé étrangère de la table Chambre ; (iv) l’objet-type Chambre devient la table Chambre.
Son identifiant (numChambre) devient la clé primaire de la table Chambre et la clé étrangère de la table ContratLocation ; (v) l’objet-type Paiement devient la table Paiement. Son identifiant (numPaiement) devient la clé primaire de la table Paiement ; et (vi) l’objet-type AnneeAcademique devient la table AnneeAcademique.
Son identifiant (anneeAcademique) devient la clé primaire de la table AnneeAcademique et la clé étrangère des tables ContratLocation et Paiement.
Figure 2.2. Modèle logique des données (MLD).
Modèle physique des données
L’optimisation physique consiste à tirer parti des possibilités du système de gestion de base de données (SGBD) utilisé pour implanter au mieux les différentes tables de la base de données, ceci sans remettre en cause le modèle logique de données déjà défini [9].
Le modèle physique des données (MPD) conserve ainsi la structure en table et colonnes du modèle logique des données, mais en y ajoutant les types des données de chacune des colonnes.
La figure 2.3 présente le modèle physique des données du système d’information sous étude suivant le formalisme navigationnel, tout en restant adapté à la famille des SGBDR.
Figure 2.33. Modèle physique des données (MPD).
Conclusion
L’analyse de l’existant et la modélisation du système d’information présentées dans ce chapitre nous ont permis d’exprimer le système d’information sous étude en des termes clairs que nous pensons comprendre.
Grâce aux possibilités qu’offre JMerise version Etudiante 0.5, nous avons exprimé ce système d’information à travers des modèles, notamment le modèle conceptuel des données, le modèle logique des données et le modèle physique des données.
Les différents modèles présentés étape par étape peuvent ainsi ouvrir la voie à l’implémentation de la nouvelle application.
