Remerciez-le!

Remerciez @Admin pour avoir partagé cet document gratuitement, de la manière la plus simple, en partageant sur les réseaux sociaux.

Projet de Bases de Données : Système d’information d’une clinique dentaire Rapp

Projet de Bases de Données : Système d’information d’une clinique dentaire Rapport Xavier Milhaud, Basile Voisin 2 mai 2007 Ce document détaille les diﬀerentes étapes de la conception de notre base de données et explique les principaux choix qui ont dû être fait aﬁn d’aboutir à notre modélisation. Il regroupe aussi la mise en place de l’application de gestion de notre base de données. Table des matières 1 Dépendances fonctionnelles et premières modélisations 2 1.1 Dèpendances fonctionnelles explicites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.2 Autres dépendances fonctionnelles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.3 Contraintes et remarques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.3.1 Personnel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.3.2 Patients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.3.3 Soins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.3.4 Paiements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2 Schéma Entités/Associations 4 3 Passage au relationnel 5 3.1 Entités simples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.2 Entités faibles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.3 Associations dont une des cardinalités est (1,1) . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.4 Associations dont une des cardinalités est (0,1) . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.5 Autres associations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.6 Contraintes supplémentaires introduites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.7 Commentaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.8 Bilan relationnel, formes normales et contraintes ne pouvant pas être vériﬁées au niveau rela- tionnel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.8.1 Récapitulatif des relations et formes normales . . . . . . . . . . . . . . . . . . . . . . . 7 3.8.2 Contraintes à vériﬁer dans le programme . . . . . . . . . . . . . . . . . . . . . . . . . 7 1 Xavier Milhaud, Basile Voisin 2 4 Fonctionnalités supportées 8 4.1 Gestion des patients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.2 Gestion du personnel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.3 Gestion des soins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.4 Historique des soins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.5 Gestion des rappels de paiement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.6 Statistiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 5 Transactions et requêtes 9 5.1 Quand gère-t-on les transactions ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 5.2 Vériﬁcation des transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 6 Contraintes vériﬁées dans notre programme 11 7 Détail des fonctions Java 12 Xavier Milhaud, Basile Voisin 3 1 Dépendances fonctionnelles et premières modélisations 1.1 Dèpendances fonctionnelles explicites La lecture de l’énoncé nous a permis d’extraire certaines dépendances fonctionnelles particulièrement explicites : • Personnel : NSR − →NomPers, PrenomPers, TelPers Et pour des catégories de personnel bien déﬁnies : - NSR − →ProfAdmin, SalFixe pour le personnel administratif ; - NSR − →ProfMed, TxHor pour les médecins ; - NSR − →ProfAux, TxHor pour le personnel auxiliaire médical. Le fait que ces trois catégories de personnel aient certaines propriété en commun et d’autres spéciﬁques à une catégorie nous amene naturellement à créer un sous-type de personnel par catégorie dans le schéma entités/associations. • Patients : NSS − →NomPat, PrenomPat, SexPat, BirthPat, TelPat • Adresses des patients et du personnel (nous avons décomposé l’adresse de façon a n’avoir que des propriétés atomiques) : - NSR − →Num, Rue, CodePostal, Ville, Pays - NSS − →Num, Rue, CodePostal, Ville, Pays Ce qui correspond à l’entité adresse, et aux associations persHabite, et patHabite. • Interventions : NomInterv − →Materiaux, CoutInterv, MontRemb, Duree ce qui se traduit par l’entité catalogue int sur notre schéma. • Fiche de soin / de consultation (il n’y a qu’une consultation par jour pour un patient donné) : NSS, DateCons − →CoutTot Cette dépendace traduisant bien le fait qu’il n’y a pas de consultations sans patient nous conduit à modéliser l’entité ﬁche soin par une entité faible reliée à patient par l’association subit (coût tôtal d’une consultation : cf. section1.3). • Factures : NumFact − →MontFact, DateButFact (montant d’une facture : cf. section1.3). • Mensualités : NumFact, DateButMens − →, MontMens Il est clair ici qu’il ne peut y avoir de mensualité sans facture, c’est pourquoi nous représentons l’entité mensualité comme entité faible reliée à facture par l’association divisee (date butoir uploads/Sante/ cr-gestionclinique-2.pdf