3.11. Le modèle logique des
données relationnel (MLDR)18(*)
Le modèle Logique des Données Relationnel (MLDR)
est la suite normale du processus Merise. Son but est de nous rapprocher au
plus près du modèle physique. Pour cela, nous partons du
Modèle Conceptuel des Données et nous lui enlevons les relations,
mais pas n'importe comment, il faut en effet respecter certaines
règles :
a) Cas (0, n), (1,1) ou (1,
n), (0,1)
On commence par supprimer les associations. Cela se
réalise de façon tout à fait mécanique.
L'entité ayant la cardinalité de type 1,1 ou 0,1 absorbe
l'identifiant de l'entité la plus forte (0, n ou 1, n). Cet identifiant
est alors appelé la clé
étrangère
b) Cas (0, n), (0, n) ou (1,
n), (1, 1)
Dans le cas où la cardinalité maximale est
n de chaque côté de la relation,
celle-ci se transforme en entité et absorbe les identifiants de chaque
entité reliée. Les identifiants absorbés forment la
nouvelle clé de l'entité. Cette nouvelle clé est donc
formée par la concaténation des clés
étrangères des entités reliées.
# Modèle créé le : Sun Sep 08 09:21:09 CEST
2013
Membre (NumFolio, Nom, Postnom, sexe, Etatcivil,
Lieunais, datenaissance, NumcarteId, profession, Tel_Bureau, Tel_mobile,
commune, Quartier, DateAdhesion, Lieu_Adhesion, photo, montant_solde,
Frais_ouverture, #Iduser)
T_DetailRemboursement (Id_remboursement,
Type_remb, Remboursement, Total_Remboursement, #Iduser)
T_pret
(id_pret, Type_credit, GarantieCredit, AutreGarantie, Montant_Pret, But,
TauxInteret, Interet, TotalRembour, Date_pret, #Iduser)
Depot
(Id_depot, M1, M5, M10, M20, M50, M100, Montant_depot, Depose_par,
Ancien_solde, Nouvo_solde, Guichetier, #Iduser)
Retrait (Id_retrait,
M11, M55, M1010, M2020, M5050, M100100, Montant_retire, Retire_par,
Ancienn_solde, Nouveau_solde, Guichitier, #Iduser)
T_login (Iduser,
Identifiant, Pwd, Privilege)
Etaler (id_pret,
Id_remboursement, Date_remboursement)
Solliciter (NumFolio,
id_pret, Date_sollicite)
Retirer (NumFolio,
Id_retrait, dateretrait)
Deposer (NumFolio, Id_depot,
Datedepot)
3.12. Le modèle physique de
données19(*)
Construire le Modèle Physique des Données
consiste à transformer le Modèle Logique des Données en
une suite de relations. Cette étape finalise le processus de traitement
des données. L'implémentation de la base de données peut
alors être réalisée de façon optimale.
Modèle Physique de données d'un
système d'information de gestion des coopératives d'epargne et de
crédit
3.13. Transcription SQL du Modèle
Physique des Données généré par l'utilitaire
AnalyseSI
# script créé le : Sat Sep 07 19:11:15 CEST 2013 -
syntaxe MySQL ;
# use GEST_COOPEC.SQL ;
DROP
TABLE IF EXISTS Membre
;
CREATETABLEMembre(NumFolioNUMERICNOTNULL,
Nom
VARCHAR(35),
PostnomVARCHAR(35),
sexeVARCHAR(1),
EtatcivilVARCHAR(15),
LieunaisVARCHAR(35),
datenaissanceDATETIME,
NumcarteIdVARCHAR,
profession
VARCHAR(35),
Tel_BureauVARCHAR(15),
Tel_mobileVARCHAR(15),
commune
VARCHAR(35),
Quartier
VARCHAR(35),
DateAdhesionDATETIME,
Lieu_AdhesionVARCHAR(20),
photo
TEXT,
montant_soldeNUMERIC(10),
Frais_ouvertureNUMERIC(10),
PRIMARYKEY(NumFolio))
ENGINE=InnoDB;
DROP TABLE IF EXISTS
T_DetailRemboursement
;
CREATETABLET_DetailRemboursement(Id_remboursementINTNOTNULL,
Type_rembVARCHAR(35),
RemboursementVARCHAR(35),
Total_RemboursementNUMERIC(10),
PRIMARYKEY(Id_remboursement))
ENGINE=InnoDB;
DROP TABLE IF EXISTS T_pret
;
CREATETABLET_pret(id_pretINT(10)NOTNULL,
Type_creditVARCHAR(35),
GarantieCreditVARCHAR(35),
AutreGarantieVARCHAR(35),
Montant_PretNUMERIC(15),
But
VARCHAR(80),
TauxInteretNUMERIC(10),
InteretNUMERIC(10),
TotalRembourNUMERIC(10),
Date_pretDATETIME,
PRIMARYKEY(id_pret))
ENGINE=InnoDB;
DROP TABLE IF EXISTS Depot
;
CREATETABLE Depot
(Id_depotINTNOTNULL,
Num_bordNUMERIC,
M1
NUMERIC(10),
M5
NUMERIC(10),
M10
NUMERIC(10),
M20
NUMERIC(10),
M50
NUMERIC(10),
M100
NUMERIC(10),
Montant_depotNUMERIC(10),
Depose_parVARCHAR(30),
Ancien_soldeNUMERIC(10),
Nouvo_soldeNUMERIC(10),
GuichetierVARCHAR(30),
PRIMARYKEY(Id_depot))
ENGINE=InnoDB;
DROP TABLE IF EXISTS Retrait
;
CREATETABLERetrait(Id_retraitINTNOTNULL,
Num_bordereauNUMERIC(12),
M11
NUMERIC(10),
M55
NUMERIC(10),
M1010
NUMERIC(10),
M2020
NUMERIC(10),
M5050
NUMERIC(10),
M100100
NUMERIC(10),
Montant_retireNUMERIC(10),
Retire_parNUMERIC(25),
Ancienn_soldeNUMERIC(10),
Nouveau_soldeNUMERIC(10),
GuichitierNUMERIC(25),
PRIMARYKEY(Id_retrait))
ENGINE=InnoDB;
DROP TABLE IF EXISTS T_login
;
CREATETABLET_login(IduserINTNOTNULL,
IdentifiantVARCHAR(10),
PwdVARCHAR(10),
Privilege
VARCHAR(10),
NumFolioNUMERICNOTNULL,
Id_retraitINTNOTNULL,
Id_remboursementINTNOTNULL,
Id_depotINTNOTNULL,
id_pretINT(10)NOTNULL,
PRIMARYKEY(Iduser))
ENGINE=InnoDB;
DROP TABLE IF EXISTS Etaler
;
CREATETABLEEtaler(id_pretINT(10)NOTNULL,
Id_remboursementINTNOTNULL,
Date_remboursementDATETIME,
PRIMARYKEY(id_pret,
Id_remboursement))
ENGINE=InnoDB;
DROP TABLE IF EXISTS Solliciter
;
CREATETABLESolliciter(NumFolioNUMERICNOTNULL,
id_pretINT(10)NOTNULL,
Date_solliciteDATETIME,
PRIMARYKEY(NumFolio,
id_pret))
ENGINE=InnoDB;
DROP TABLE IF EXISTS Retirer
;
CREATETABLERetirer(NumFolioNUMERICNOTNULL,
Id_retraitINTNOTNULL,
dateretraitDATETIME,
PRIMARYKEY(NumFolio,
Id_retrait))
ENGINE=InnoDB;
DROP TABLE IF EXISTS Deposer
;
CREATETABLE Deposer
(NumFolioNUMERICNOTNULL,
Id_depotINTNOTNULL,
DatedepotDATETIME,
PRIMARYKEY(NumFolio,
Id_depot))
ENGINE=InnoDB;
ALTERTABLET_loginADDCONSTRAINTFK_T_login_NumFolioFOREIGNKEY(NumFolio)REFERENCESMembre(NumFolio);
ALTERTABLET_loginADDCONSTRAINTFK_T_login_Id_retraitFOREIGNKEY(Id_retrait)REFERENCESRetrait(Id_retrait);
ALTERTABLET_loginADDCONSTRAINTFK_T_login_Id_remboursementFOREIGNKEY(Id_remboursement)REFERENCEST_DetailRemboursement(Id_remboursement);
ALTERTABLET_loginADDCONSTRAINTFK_T_login_Id_depotFOREIGNKEY(Id_depot)REFERENCES
Depot
(Id_depot);
ALTERTABLET_loginADDCONSTRAINTFK_T_login_id_pretFOREIGNKEY(id_pret)REFERENCEST_pret(id_pret);
ALTERTABLEEtalerADDCONSTRAINTFK_Etaler_id_pretFOREIGNKEY(id_pret)REFERENCEST_pret(id_pret);
ALTERTABLEEtalerADDCONSTRAINTFK_Etaler_Id_remboursementFOREIGNKEY(Id_remboursement)REFERENCEST_DetailRemboursement(Id_remboursement);
ALTERTABLESolliciterADDCONSTRAINTFK_Solliciter_NumFolioFOREIGNKEY(NumFolio)REFERENCESMembre(NumFolio);
ALTERTABLESolliciterADDCONSTRAINTFK_Solliciter_id_pretFOREIGNKEY(id_pret)REFERENCEST_pret(id_pret);
ALTERTABLERetirerADDCONSTRAINTFK_Retirer_NumFolioFOREIGNKEY(NumFolio)REFERENCESMembre(NumFolio);
ALTERTABLERetirerADDCONSTRAINTFK_Retirer_Id_retraitFOREIGNKEY(Id_retrait)REFERENCESRetrait(Id_retrait);
ALTERTABLE
Deposer
ADDCONSTRAINTFK_Deposer_NumFolioFOREIGNKEY(NumFolio)REFERENCESMembre(NumFolio);
ALTERTABLE
Deposer
ADDCONSTRAINTFK_Deposer_Id_depotFOREIGNKEY(Id_depot)REFERENCES
Depot (Id_depot);
3.14. Le diagramme
relationnel généré par les contraintes de Microsoft SQL
Server
Diagramme relationnel d'un système d'information
de gestion des coopératives d'epargne et de crédit
3.15. Le diagramme des
requêtes de synthèse construit à partir de Microsoft visual
Studio 2010 Professionnel
Dataset relationnel d'un système d'information de
gestion des coopératives d'epargne et de crédit
3.16.
Représentation des accès en réseau.
Notre architecture étant multi utilisateur, nous allons
présenter ici les accès dans l'application suivant les
privilèges pour le mode écriture et lecture des données de
chaque utilisateur. L'architecture comporte en soit les utilisateurs suivants:
un administrateur de la base de données, un gérant de la
coopérative, les guichetiers au dépôt et les guichetiers au
retrait
· Illustration des accès de
l'administrateur système
Dans le présent système d'information
l'administrateur a le droit d'accès à toutes les données
et fonctionnalités pour assiter les utilisateurs et faire la maintence
coorective de l'application en cas de neccessité.
Cette figure illustre les activités de l'administrateur
du système d'information selon les activités qu'il doit effectuer
au niveau de la base de données. Lorsqu'il se connecte il peut
parcourir l'ensemble de l'application et verifier si touts les postes clients
accédent à la base de données distante.
· Illustration des accès du
Gérant
Cette figure illustre les droits d'accès du
gérant selon son privilège, il a droit de lire et d'écrire
dans la table adhésion des membres, il peut également lire et
valider les différents Dépôts-Retraits et peut lire et
écrire dans la table de démande de prêt et dans la table de
remboursement. Ici il n'a pas droit d'accéder au formulaire de gestion
des utilisateurs du système.
· Illustration des accès des guichetiers
au dépôt
Cette figure illustre le droit d'accès aux
données par les différents guichetiers au Dépôt. Ici
le guichetier Dépôt peut lire dans la table Membre pour afficher
les informations de base d'un membre qui vient faire l'opération de
dépôt et il peut lire et écrire dans la table
Dépôt. En fin après l'opération de
dépôt, il peut faire la mise à jour du solde en compte du
memebre concenré. Le reste des opérations restent
desactivées pour lui.
· Illustration des accès des guichetiers
au retrait
Cette figure illustre les accès des différents
guichetiers au retrait. Ici le guichetier Retrait peut lire dans la table
Membre pour afficher les informations de base d'un membre qui vient faire
l'opération de retrait et il peut lire et écrire dans la table
Retrait. En fin après l'opération de Retrait, il peut faire la
mise à jour du solde en compte du memebre dont l'opération de
retrait concerne. Le reste des opérations restent
désactivées pour ce dernier.
* 18Jean-Luc BAPTISTE,
Merise, guide pratique (modélisation des données et des
traitements, langage SQL), ENI Editions, 2009, p.75
* 19Idem
|
|
