WOW !! MUCH LOVE ! SO WORLD PEACE !
Fond bitcoin pour l'amélioration du site: 1memzGeKS7CB3ECNkzSn2qHwxU6NZoJ8o
  Dogecoin (tips/pourboires): DCLoo9Dd4qECqpMLurdgGnaoqbftj16Nvp


Home | Publier un mémoire | Une page au hasard

 > 

Conception, Implémentation d'une Base de Données pour la Gestion d'un Organisme et Administration Réseau à distance sur base des outils libres "Cas de Projet Limete Université Cardinal Malula"

( Télécharger le fichier original )
par Blaise LUSIKILA LUAMBASU
Ecole supérieure des métiers de l'informatique et du commerce (ESMICOM) - Licence 2007
  

précédent sommaire suivant

Bitcoin is a swarm of cyber hornets serving the goddess of wisdom, feeding on the fire of truth, exponentially growing ever smarter, faster, and stronger behind a wall of encrypted energy
B.3.6 Gestion des dates et du Caractère historique

Dans la bibliothèque du Projet Limete Cardinal Malula, on peut vouloir stocker les emprunts en cours et / ou les emprunts historiques. Pour les emprunts en cours, la date de retour prévu est un attribut de l'entité livre, car un livre ne peut faire l'objet que d'un seul emprunt en cours, dans ce cas, l'établissement du graphe de couverture minimale ne pose aucun problème.

Par là, nous avons un sérieux problème, car un livre peut faire l'objet de plusieurs emprunts historiques et dans ces conditions, la date d'emprunt est déterminante pour une dépendance fonctionnelle ne peut partir que d'un ou plusieurs identifiants. Ces le signe qu'il manque un identifiants :

Le numéro d'emprunt

Id_livre date_emprunt

Titre_livre

date date

retour retour

Prévu effectif id_apprenant

Nom_appre adresse

Nous devons corrigé ce graphe car une date n'est pas être un identifiant.

Id_livre date_d'emprunt

Tire_livre numéro d'emprunt

Date date id_apprenant

retour retour

prévu effectif

nom_appre adresse

À présent nous avons la facilité de le traduire en un modèle entités- associations.

Id_livre

Tire_livre

livres

Numéro_emprunt

date_emprunt

date_retour_prevu

date_retour_effectif

Emprunt historique

Id_appre

Nom_appre

Postnom_appre

Prenom_appre

Téléphone

E-mail

Login

Password

...

Apprenant

Concerner

Avoir effectué

0, n 1,1

1,1 0,n

Nous avons évité même pour une entité historique, il vaut mieux éviter que la date n'entre dans l'identifiant. Notons que l'entité emprunts historiques supplémentaires qui apparaît après tradition ne peut pas être transformé en une association comme on pourrait le croire au simple examen des cardinalités qui l'entourent, en effet, les attributs de l'association qui en resulterait ne verififieraient pas la normalisation des attributs des associations. Notamment, la date de retour effectif ne dépend pas du numéro de livre et du id_apprenant, mais du id_livre et la date d'emprunt.

La normalisation des entités ne s'applique donc pas aux entités qui ont un caractère historique2(*) . à moins que les dates ne soient regroupées dans une entité séparée, ce qui n'est pas conseillé tant qu'aucune information liée aux dates telles que : caractère férié, par exemple n'est nécessaire.

B.3.7 Méthodologie de base utilisé

Face à notre situation bien définie, nous n'avons pas présenté l'ensemble de démarche pour tous entités ou associations, puis que nous puissions aussi procéder sans établir le graphe de couverture minimale, en procédant par les méthodologies de base qui sont :

1. Identifier les entités en présence ;

2. Lister leurs attributs ;

3. Ajouter les identifiants (nous avons beaucoup plus utiliser les auto incrémentes).

4. Lister leurs attributs ;

5. Calculer les cardinalités ;

6. Vérifier les règles de normalisation et en particulier, la normalisation des entités (c'est à ce stade qu'apparaissent les association non binaires), des associations et leurs attributs ainsi que la troisième forme normale de Boyece-codd ;

7. Effectuer les corrections nécessaires ;

Mais il est parfois plus intuitif d'en passer par l'étude de la dépendance fonctionnelle directe ;

8. Identifier les entités en présence et leurs donner un identifiant (numéro arbitraire ou auto incrémente) ;

9. Ajouter l'ensemble des attributs et leurs dépendances fonctionnelles directes avec les identifiant (en commençant par les dépendances élémentaires) ;

10. Traduire le graphe de couverture minimale obtenu en un schéma entités - associations ;

11. Ajouter les cardinalités minimales et ;

12. A ce stade, la majorité des règles de normalisations devraient être vérifiées, il reste tout de même la normalisation de noms, la présence d'attributs en plusieurs exemplaires et d'associations redondantes ou en plusieurs exemplaires à corriger.

Nous avons gardé également en l'esprit que le modèle doit être exhaustif ( c'est -à - dire contenir toutes les informations nécessaires) et éviter toute redondance que nous ne dirions pas assez, constitué une perte d'espace3(*),une démultiplication du travail de maintenance et un risque d'incohérence.

Il va de soi que cette méthodologie ne doit pas être suivie pas à pas une bonne fois pour toute. Au contraire, il faut itérer plusieurs fois les étapes successives, pour espérer converger vers une modélisation pertinente de la situation de notre travail.

* 2LUFUNGULA, cours conception de base de donnée, année 2003-2004, UCM

* 3DONKING, Op. Cit., P.49

précédent sommaire suivant






Bitcoin is a swarm of cyber hornets serving the goddess of wisdom, feeding on the fire of truth, exponentially growing ever smarter, faster, and stronger behind a wall of encrypted energy








"Les esprits médiocres condamnent d'ordinaire tout ce qui passe leur portée"   François de la Rochefoucauld