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

 > 

Gestion et approvisionnement d'un stock. Cas de l'Hôpital principal de Dakar

( Télécharger le fichier original )
par Dismas MANIRAKIZA
Institut supérieur d'informatique de Dakar - Brevet de technicien supérieur en informatique 2009
  

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

II.5.3. 9. Non option

La participation d'un objet à une relation ne peut pas être optionnelle. Pour chaque occurrence d'une relation, il doit obligatoirement exister une valeur et une seule des identifiants des objets participants.

Si une participation est optionnelle, alors il faut décomposer en autant de relations que nécessaire.

Illustration :

CarteBancaire

NumCaisse DateHeure MonatPerçu MontantRendu

Espece

CodeBanque Numchèque MontantChèque

Chèque

Facture

NumTransaction

NumCarte MontantPrélévé

NumFacture DateFacture MontantTotalFacture

Il s'agit de traduire qu'une facture peut être réglée par plusieurs moyens de paiement, par exemple partie en chèque, partie en espèces, partie par carte bancaire. Toutes les combinaisons sont possibles et plusieurs factures peuvent être réglées simultanément.

CarteBancaire

NumTransaction NumCarte MontantPrélévé

0,n

Chèque

NumFacture DateFacture MontantTotalFacure

Facture

1,n

Regler

0,n

0,n

CodeBanque NumChèque MontantChèque

Espèce

NumCaisse DateHeure MontantParçu MontantRendu

- 68 -

Une erreur serait de proposer la modélisation suivante :

En effet, avec cette représentation, il faut pour chaque occurrence de la relation « REGLER » une occurrence de chacun des objets carte bancaire, chèque et espèce. Cela signifierait que chaque facture doit être obligatoirement payée avec chacun de ces moyens de paiement.

La représentation est en réalité celle-ci :

NumFacture DateFacture MontantTotalFacture

Facture

0,n

0,n

0,n

Prelever

Payer

Liquider

1,n

1,n

1,n

NumTransaction NumCarte MontantPrélévé

CodeBanque Numchèque MontantChèque

NumCaisse DateHeure MonatPerçu MontantRendu

CarteBancaire

Espece

Chèque

II.5.3. 10. Cohérence des cardinalités

Après avoir contrôle l'ensemble du modèle, il reste à vérifier que les cardinalités autour d'un objet sont cohérentes.

NumAssuré NomAssuré PrénomAssuré AdresseAssuré

Assuré

0,n

0,n

Souscrire

Déclarer

1,n

1,n

ContratAssurVoitu

Immatriculation Marque

Couleur

NumContrat
DateContrat

Voiture

<pi

- 69 -

Un client possède des véhiculent pour lesquels il souscrit des contrats d'assurance.

Pour une occurrence de l'objet ASSURE, il a au moins une occurrence de la relation SOUSCRIRE, ce qui signifie que chaque client géré a au moins souscrit un contrat d'assurance voiture.

Pour une occurrence de l'objet ASSURE, il peut ne pas y avoir d'occurrence de la relation DECLARER, ce qui signifie qu'un client peut ne pas avoir de voiture.

Il y a donc probablement une incohérence entre ces deux cardinalités.

Il faut que ces deux cardinalités soient identiques (0, n) ou (1, n) en fonction des règles de gestion.

- 70 -

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








"Ceux qui rêvent de jour ont conscience de bien des choses qui échappent à ceux qui rêvent de nuit"   Edgar Allan Poe