Discussion :

[Guelykoy]

Bonsoir à tous,
Je continue sur mon deuxieme projet d'apprentissage . Je remercie bcp ce forum ou 70% de mon debut en depend.
Voici mon projet ci-dessous avec mes regles de gestions et identifications des entités , avant d'evoluer vers le MCD si quelqu'un peut me donner coup de main juste savoir si j'evolue bien. Si oui je vous enverrai le mcd.

Description du projet
Le bureau du BAIV (bureau d’appui au initiatives villageoises) dispose d’une GuestHome composé des chambres à coucher et d’un restaurant pour permettre l’hébergement des visiteurs suivant leur possibilité financière.
L’administration/finance est en charge de la gestion financière du guestHome. Pour mieux assurer cette gestion, il est établi un planning journalier qui permet de savoir si les chambres sont occupées, libres ou réservées et le nombre des occupant par chambre.
Chaque client est enregistré avec son nom, son titre, son numéro de téléphone et autres détails de son adresse permettant de l’identifier ou de le retrouver plus facilement. Les clients sont ensuite informés des tarifs des chambres et de la restauration selon leurs caractéristiques. Pour les fonctionnaires du BAIV, le payement peut-être déduit des frais de mission (FM) ou sur les indemnités mensuelles (IM). Les visiteurs externe par contre effectuent leur payement en cash avant leur départ.
Les employés du guestHome envoient journalièrement un état des jours passés au guestHome et des repas consommés à l’administration/finance qui émet une facture détaillée au client pour sa signature. Le client propose un mode de payement qui convient à l’administration, l’originale de la facture est remise au client après payement, et la copie conservée dans les archives.
Enfin, les informations sont mises à jour à la fin de chaque journée pour faciliter le travail. Un récapitulatif mensuel de la gestion financière du guestHome est signé par l’administration /Finance et envoyé au bureau de la sous délégation.

Règle de gestion :
1- Une chambre est occupée par un client selon un planning établi ;
2- Un client a au maximum un titre ;
3- Un client peut posséder plusieurs boite email et téléphone
4- Le téléphone a un type ;
5- Une chambre a au moins un tarif selon ses caractéristiques ;
6- Une facture est établie à un client ;
7- Une facture possède au moins une ligne de facture ;
8- Une facture est réglée par un mode de payement.

Les entités identifiées sont :
CHAMBRE ; PLANNING ; CLIENT ; TITRE ; TARIF ; FACTURE ; LIGNE-FACTURE ; MODE-PAYEMENT ; TELEPHONE ; TYPE ; EMAIL.

[CinePhil]

1- Une chambre est occupée par un client selon un planning établi

Pourquoi pas mais :

le nombre des occupant par chambre.

Donc une chambre peut avoir plusieurs occupants.

Quant au planning, c'est plutôt un traitement qui effectuera des interrogations sur la base de données qu'une entité et le résultat de ce traitement.
Quelles seraient les attributs de l'entité Planning ?

3- Un client peut posséder plusieurs boite email et téléphone

Ce n'est pas dans l'énoncé.

son numéro de téléphone

Au singulier !

4- Le téléphone a un type ;

Ca non plus ce n'est pas dans l'énoncé.

5- Une chambre a au moins un tarif selon ses caractéristiques ;

Et donc une chambre a des caractéristiques non ? Sinon comment établit-on le tarif de la chambre ?

Les entités identifiées sont :
CHAMBRE ; PLANNING ; CLIENT ; TITRE ; TARIF ; FACTURE ; LIGNE-FACTURE ; MODE-PAYEMENT ; TELEPHONE ; TYPE ; EMAIL.

J'ai déjà donné mon avis sur l'entité Planning.
L'Email (que j'appellerais plutôt en français l'Adrel mais bon...), ne figure pas dans l'énoncé.
Par contre y figure cette phrase :

et autres détails de son adresse

N'y aurait-il pas dans ces "détails" :
- rue ;
- commune ;
- code postal ?
Commune ne pourrait-elle pas être une entité de référence pour les adresses ?
En poussant plus loin, on peut aussi imaginer une entité Code postal et répondant aux règles de gestion :
Un code postal peut coder plusieurs communes et une commune peut avoir plusieurs codes postaux.

Courage pour la suite !

[Guelykoy]

Merci bcp pour votre reponse. Je vais prendre un petit moment rediscuter le projet avec l'administratrice de l'entreprise pour mieux harmoniser la modelisation. Il s'agit de me donner d'une maniere explicite ce qu'est " les autres details de l'adresse du client''; ensuite de savoir s'il n'ya pas des clients qui donnent leur adresses email et aumoins un numero de telephone selon moi. Je voudrais tenir compte de l'evolution des données.

Pour Planning je vais simplement l'enlever , j'ai compris votre explication.

Je vous enverrai sur le forum le mcd avec la modification du sujet dés que possible s'ils acceptent certaines propositions .

A bientot

[Guelykoy]

Bonsoir a tous, je reviens avec mon exercice projet de perfectionnement avec son MCD ci-joint . J'apprends ici et c'est mon 2eme grand exo.
Sur ce projet j'ai de difficulté pour representer le planing journalier qui permet de savoir si les chambres sont occupées, reservées et le nbre des occupant dans la chambre. Je m'excuse peut-etre le texte est long à la lecture.

Je remercie d'avance à tous ceux qui vont s'interesser pour m'orienter.

Description du projet
Le bureau du BAIV (bureau d’appui au initiatives villageoises) dispose d’une GuestHome composée des chambres à coucher et d’un restaurant pour permettre l’hébergement des visiteurs suivant leur possibilité financière.
L’administration/finance est en charge de la gestion financière du guestHome. Pour mieux assurer cette gestion, il est établi un planning journalier qui permet de savoir si les chambres sont occupées, libres ou réservées et le nombre des occupant par chambre.
Chaque client est enregistré avec son nom, son titre, le nom de son entreprise et son adresse du domicile pour permettre de le retrouver plus facilement en cas de besoin. Les clients peuvent avoir plusieurs numéros de téléphone et adresses électronique. Les clients sont ensuite informés des tarifs des chambres et de la restauration. Toutes les chambres ont les caractéristiques communes. Pour les fonctionnaires du BAIV, le payement peut-être déduit des frais de mission (FM) ou sur les indemnités mensuelles (IM). Les visiteurs externe par contre effectuent leur payement en cash avant leur départ.
Les employés du guestHome envoient journalièrement un état des jours passés au guesthouse et des repas consommés à l’administration/finance qui émet une facture détaillée au client pour sa signature. Le client propose un mode de payement qui convient à l’administration, l’originale de la facture est remise au client après payement, et la copie conservée dans les archives.
Enfin, les informations sont mises à jour à la fin de chaque journée pour faciliter le travail. Un récapitulatif mensuel de la gestion financière du guesthouse est signé par l’administration /Finance et envoyé au bureau de la sous délégation.
Règle de gestion :
1- Une chambre est occupée par un client selon un planning établi ;
2- Une chambre peut avoir plusieurs occupants ;
3- Un client possède au maximum un titre ;
4- Un client peut avoir une adresse de domicile ;
5- Un client possède au moins un numéro de téléphone ;
6- Un client possède au moins une adresse électronique ;
7- Une chambre coûte un tarif ;
8- Une facture est établie à un client ;
9- Une facture possède au moins une ligne de facture ;
10- Une facture est réglée selon un mode de payement.

Les entités identifiées sont :
CHAMBRE ; CLIENT ; TITRE ; ADRESSE_DOMICILE ; TARIF ; FACTURE ; LIGNE_FACTURE ;MODE_PAYEMENT ;ADRESSE_ELECTRONIQUE ; TELEPHONE

[mayloshi]

QUestions:

1. QUelle est la "durée de vie" d'un client dans le système GuestHome? Est ce le temps de son séjour dans le guest house, ou par un abonnement périodique? (mensuel, trimestriel, annuel...) Je pose cette question pour savoir si a chaque fois qu'un client X va réserver une chambre, il faudra le considérer comme un nouveau client. Si ce n'est pas le cas, je pense qu'il sera nécessaire de mettre la date de début ainsi que la date de fin d'occupation d'une chambre dans la relation "occuper", si tu veux garder la cardinalité (1,n) de "occuper" sur "client" qui signifie qu'un client peut occuper plusieurs chambres (1 à n), ou plusieurs fois une(des) chambre(s). D'ailleurs une règle mentionne "selon le planning établi"...

2. Pourquoi (1,1) sur "chambre" (toujours avec la relation "occuper")? Une chambre ne peut être occupée que par un et un seul client? Pourtant on veut connaître le nombre d'occupants d'une chambre, donc il peut y en avoir plusieurs (d'ailleurs une règle de gestion le mentionne), non?

3. On dit également qu'une facture est établie au client. En consultant ton MCD, je voudrai savoir quand est ce qu'une facture n'est pas établie au client, parce que tu mets (0,n) sur client pour la relation "reçoit". Donc ce qui signifie qu'on peut avoir des clients qui louent des chambres (1,n pour l'occupation des chambres, donc tout client loue au moins une chambre), mais qui ne reçoivent pas de factures, c'est ça?

4. Les règles 5 et 6 sont clairs, un client a au moins UNE adresse électronique et UN numéro de téléphone. DOnc possède1 et possède2 doivent avoir (1,n) sur "client".

C'est ce que je trouve pour l'instant.

[fsmrel]

Bonjour,


Certaines de mes remarques recoupent celles qui ont été faites précédemment. A vous de trier.


Remarques générales

« Une chambre est occupée par un client selon un planning établi. »

Où sont les dates de début et de fin correspondantes ?

« il est établi un planning journalier qui permet de savoir si les chambres sont occupées, libres ou réservées et le nombre des occupant par chambre »

Votre MCD ne prévoit ni la gestion de la situation des chambres (occupée, etc.), ni le nombre d’occupants (à moins que chaque occupant ne fasse systématiquement l’objet d’une instance de CLIENT ; c’est un peu comme une rate et sa portée : on connaît le nombre de ratons composant cette dernière, mais on n’identifie pas les ratons, à moins que tel ou tel ait à être identifié pour des raisons diverses et variées...)

« Une chambre coûte un tarif »

Vous avez établi une relation 1,N-1,N avec Tarif, ce qui signifie qu’une chambre peut avoir plusieurs tarifs : contradiction. En toute logique, si une chambre a un et un seul tarif, soit celui-ci figure en tant que propriété de la chambre, soit il figure dans une entité-type permettant de connaître le tarif en fonction de la catégorie de la chambre.
En plus, selon votre MCD, le prix d’une chambre varie en fonction des repas...

« Pour les fonctionnaires du BAIV »

Comment sait-on qu’un client est du BAIV ?

« Une facture est établie à un client »

Il manque un attribut Numéro de facture pour l’entité-type FACTURE. En effet, ce type d’information est connu de l’utilisateur (voire géré par lui). L’identifiant FAC_ID ne doit être connu que du système et servira au niveau SQL pour traiter efficacement de l’intégrité référentielle et des opérations relationnelles telles que la jointure.
Les fonctionnaires du BAIV sont-ils concernés ? Est-il normal qu’un client ne soit pas facturé ? Pour quelle raison un client peut-il faire l’objet de plusieurs factures ? Est-ce au motif de l’archivage des copies ?

« Une facture possède au moins une ligne de facture »

Pour quelle raison ? Où est le libellé accompagnant chaque ligne ? (en tant que client, j’exige que chaque montant soit expliqué).

Entités-types à supprimer

« Un client peut avoir une adresse de domicile »

Puisqu’un client a au plus une adresse de domicile, vous pouvez remonter la donnée correspondante dans l’entité-type CLIENT. Si un client n’a pas de domicile, l’attribut correspondant prendra une valeur par défaut ("Sans objet", "Inconnu", etc.)

Cardinalités à revoir

La cardinalité 0,1, voilà l’ennemie, car au niveau SQL elle est traduite par une marque nulle, chose qui met en échec l’algèbre relationnelle et fait patiner les optimiseurs des SGBDR. 0,1 doit être remplacé par 1,1. Sont concernées les associations-types entre CLIENT et TITRE, ainsi que FACTURE et MODE_PAIEMENT. En conséquence :

TITRE : prévoir un titre « à blanc ».

MODE_PAIEMENT : a priori, on connaît le mode paiement. Mais si vraiment tel n’est pas le cas (supposons que cela concerne les fonctionnaires du BAIV ou que le client ne quitte pas les lieux ce jour), alors prévoir le mode de paiement "Sans objet", "A régler", ...

« Un client possède au moins un numéro de téléphone »

La cardinalité 0,N doit être transformée en cardinalité 1,N.

« Un client possède au moins une adresse électronique »

La cardinalité 0,N doit être transformée en cardinalité 1,N.

Identification relative

Certaines entités-types correspondent à des propriétés (multivaluées) d’autres entités-types :

TELEPHONE, ADRES_ELECTRONIQUE, FACTURE, LIGNE_FACTURE.

Il est recommandé de les identifier relativement plutôt que de façon absolue. Pour signifier que l’on identifie de façon relative, utiliser un mickey du genre 1,1 (R) (cf. FAQ Merise).


N.B. Pourquoi utilisez-vous l’expression angloricaine « Guest House » ? Votre projet concerne-t-il un pays anglophone ?

[Guelykoy]

Merci à fsmrel et mayloshi pour vos reponses.
- pour savoir si les fonctionnaires sont du BAIV , j'ai inclu l'attribut nom d'entreprise dans l'entité client.
- c'est une entreprise qui travaille sous la supervision d'une agence des Nations Unies c'est pourquoi cette terminologie anglophone mais je vais leur recommander d'harmoniser tous en français, c'est possible.
- J'ai ajouté l'entité GUESTHOUSE a mon MCD avec objectif d'inclure les tarification du restaurant.

Ci-joint mon MCD avec les nouvelles orientations.

[fsmrel]

Bonjour,

- pour savoir si les fonctionnaires sont du BAIV , j'ai inclu l'attribut nom d'entreprise dans l'entité client.

Attention. Si vous codez ce nom comme critère de sélection dans les requêtes et que pour un fonctionnaire donné la saisie du nom de l’entreprise comporte un iota de différence (un doigt qui ripe sur le clavier lors de la saisie : « vureau d’appui au initiatives villageoises » au lieu de « bureau d’appui au initiatives villageoises »), il sera surpris d’être considéré comme ne faisant pas partie de la maison. Par ailleurs, si le nom de l’entreprise change un jour, il faudra le répercuter dans toute la table CLIENT et modifier toutes les requêtes dans lesquelles ce nom figure. Il me paraît préférable de mettre en place un attribut de type booléen pour savoir si oui ou non un client fait partie du BAIV.

Vous pourriez peut-être aussi mettre en œuvre une entité-type SOCIETE (du client), ce qui permettrait d’éviter les ennuis évoqués (toutes les lignes CLIENT concernant les fonctionnaires du BAIV feraient référence à la ligne SOCIETE concernant le BAIV). L’entité-type SOCIETE pourrait servir de référentiel à des fins statistiques et commerciales, dans le suivi ses entreprises (notamment les plus importantes) dont font partie les clients qui ne sont pas que de simples touristes. Mais je vais peut-être un peu trop loin par rapport aux objectifs de la maîtrise d’ouvrage.

J'ai ajouté l'entité GUESTHOUSE a mon MCD avec objectif d'inclure les tarification du restaurant.

Quelque chose me choque. En effet, selon votre MCD, le prix des repas est déterminé par la chambre occupée par le client. Certes, dans une chambre d’hôtel, sont affichés les prix du petit déjeuner, de la pension ou de la demi-pension s’il y a lieu, mais confirmez par une règle écrite ce qu’il en est exactement de la relation entre CHAMBRE et GUESTHOUSE (entité-type que j’aurais tendance à renommer REPAS ou TARIF_REPAS), à savoir s’il s’agit seulement de respecter la loi, ou bien si les repas sont obligatoirement facturés (même s’ils ne sont pas pris), etc. A défaut, cette partie du MCD est peut-être à revoir (repas effectivement pris par les clients).

Adresse du client

Si cela peut intéresser l’utilisateur (à des fins statistiques, commerciales et autres), vous pouvez mettre en évidence certains éléments figurant dans l’adresse du client : Pays, code postal. A des fins de cohérence, vous pourriez alors récupérer les fichiers INSEE des communes et établir les relations qui vont bien (au moins pour les communes françaises).

Cardinalités 1,N à revoir

Le lien entre l’entité-type TITRE et l’association-type « a » est porteur d’une cardinalité 1,N : cela veut dire que tout titre doit être associé à au moins un client. Une cardinalité 0,N serait plus appropriée. Même principe concernant les modes de paiement.

Identification relative

Je n’ai rien vu dans le sens des suggestions que j’ai faites.

[Guelykoy]

Merci fsmrel pour ta reponse et suivi. J'ai opté pour une entité societé qui est representée dans le MCD ci-joint.
En ce qui concerne les prix de repas, nous avons introduit le texte suivant qui fera une regle de gestion: le client n'est pas obligé de solliciter le repas du restaurant donc les chambres sont independantes des repas. Ci-joint j'ai ajouté une entité Repas pour permettre de savoir les prix;
L'adesse du client, je tiens compte et nous inserons ces attributs dans le sujet ( si necessaire), mais la commune je l'ai pas ajouté.
Les cardinalités sont modifiées comme suggerées ci-joint.
Identitification relative, c'est une regle que je ne metrise pas bien par rapport aux autres surtout ses consequences, j'ai lu pusieurs fois que l'identifiant d'une entité est absolue , mais dans le cas d'une entité faible, l'identifiant est relative. J'ai essayé ci-joint, mais si je comprends le pourquoi ça va bcp m'aider.

A bientot

[fsmrel]

Bonjour,

J'ai opté pour une entité societé

D’accord.

j'ai ajouté une entité Repas pour permettre de savoir les prix;

D’accord. Mais :

1) Il me paraît préférable de remplacer les 3 attributs TARIF_PETIT-DEJEUNER, TARIF_DEJEUNER, TARIF_DINER par un seul attribut TARIF_REPAS, sinon quelque part vous associez le client à un chacun des trois types de repas, alors que peut-être seul l’un ou l’autre l’intéresse.

2) Le lien connectant REPAS et SOLLICITE est porteur d’une cardinalité 1,1, c'est-à-dire qu’il n’y a qu’un et un seul client ayant pu solliciter le repas identifié par REP_CODE = 1, un et un seul client ayant pu solliciter le repas identifié par REP_CODE = 2, etc. Or, à mon sens, l’entité-type REPAS a plutôt les caractéristiques d’un type de repas, en sorte que les clients Alain et Bernard pourraient tous les deux solliciter le repas de type REP_CODE = 1 (petit-déjeuner par exemple). Dans ces conditions, la cardinalité maximale serait plutôt N que 1 entre REPAS et SOLLICITE. Par ailleurs, il faut savoir combien de petits-déjeuners seront à facturer à Alain : on peut définir un attribut à cet effet, porté par l’association-type SOLLICITE. Pour des raisons de traçabilité (en cas de contestation de la part du client, de changement des prix, suivi statistique, etc.), il pourrait être utile de prendre en compte la date à laquelle Alain a pris tel repas (et en quelle quantité si c’est lui qui paye pour ceux qui l’accompagnent).

Ceci m’amène à faire observer qu’il est d’usage de faire mention de la date à laquelle le prix d’une prestation, d’un service, d’un produit, etc. entre en vigueur. Cette date devrait figurer dans l’entité-type REPAS (cela vaut pour l’entité-type CHAMBRE, toutes choses égales par ailleurs). Je vous propose un MCD prenant en compte les tarifs en vigueur pour les repas, ainsi que l’historique de ces tarifs.

Une proposition d’aménagement du MCD (j’ai utilisé Power AMC pour modéliser et qui a un mickey à lui pour l'identification relative) :


Notes : On sait quel est le prix à ce jour d’un repas, quel que soit son type. Exemple d’instanciation :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
 
REPAS (RepasId   RepasLibelle      RepasTarif   DateApplicabilite)
         1       Petit-dejeuner        10         2009-07-01    
         2       Dejeuner fruste       30         2009-06-15    
         3       Dejeuner gourmet      50         2009-06-17    
         3       Diner                 25         2009-06-15    
        ...      ...                  ...         ...

On sait combien de repas de tel type ont été sollicités par tel client et à quelle date. Exemple d’instanciation :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
SOLLICITER (CliId   RepasId   Date          RepasNombre)
              1        1      2008-12-20        3
              1        3      2008-12-20        2
              1        1      2009-07-02        1
             ...      ...     ...              ...

Le MCD que je vous propose est peut-être trop « riche » et il est évidemment à aménager selon vos véritables besoins, il n’est là que pour illustrer la mise en œuvre des concepts, notamment touchant à l’aspect temporel des choses.


Concernant l’identification relative, je vous expliquerai cela dans mon prochain message.

[Guelykoy]

fsmrel, je n'ai pas de mot pour vous dire plus que merci.

Je progresse pas mal, ci-joint le MCD s'il ya des remarques .

A bientot

[fsmrel]

Bonsoir Guelykoy,

Je progresse pas mal, ci-joint le MCD s'il ya des remarques.

Je regarderai un peu plus tard, car je commence par la tartine qui suit.

Bonne lecture.

_____________________

Dans mon précédent message, j’ai écrit que je traiterai de l’identification relative. En fait, je commencerai par une approche de l’aspect dynamique des données, de leur métabolisme et des rapports de force qu’entretiennent les entités-types au travers de leurs relations. En effet, vous utilisez Merise et cette méthode ne traite au niveau conceptuel que de l’aspect statique des choses, et je trouve dommage d’attendre de passer au niveau logique pour étudier le comportement des entités, car il y a là un bon moyen (parmi d’autres) de valider ce qui a été modélisé de façon strictement statique.

Les rapports de force entre entités-types

Si E1 et E2 sont deux entités-types distinctes pour lesquelles on a établi une relation, on peut, d’un point de vue sémantique, étudier le rapport des forces en présence. Ce rapport peut être équilibré : en l’occurrence, les événements qui affectent une entité donnée e1 de E1 (ce que l’on appelle en Merise une occurrence d’entité) n’influent en rien sur les entités avec lesquelles e1 est en relation, autrement dit, E1 ne joue pas de rôle dominant vis-à-vis de E2. Par exemple, si mes clients achètent mes produits et si j’ai modélisé une entité-type CLIENT ainsi qu’une entité-type PRODUIT, le fait que dans ma base de données, je crée, modifie ou supprime un client, cela n’aura aucune incidence sur les produits, pas plus que la création, la modification ou la suppression d’un produit n’auront de répercussion sur les clients. De façon imagée, les stimuli émis d’un côté n’affectent pas l’autre côté : seules les relations pourront être touchées.

On doit chercher à pousser les investigations et vérifier si le rapport des forces entre les entités-types E1 et E2 n’est pas déséquilibré. Considérons par exemple les entités-types CLIENT et TELEPHONE de votre MCD. Si l’on avait souhaité ne prendre en compte qu’un seul numéro de téléphone par client, l’entité-type CLIENT aurait été porteuse d’un attribut CLI_TEL_NO et l’entité-type TELEPHONE n’aurait pas existé. Dans ces conditions, en cas de suppression d’un client, son numéro de téléphone est évidemment supprimé lui aussi. En toute logique, si le client a plusieurs numéros de téléphone, tous doivent disparaître. Dans le cas du téléphone unique, comme tous les autres attributs de l’entité-type CLIENT, CLI_TEL_NO aurait été un attribut monovalué. En choisissant de prendre en compte plus d’un numéro de téléphone par client, l’attribut CLI_TEL_NO devient multivalué. On pourrait en rester là, mais il y a un grain de sable qui vient perturber notre système...

La règle de vérification

Bien que cela ne soit absolument pas une nécessité, nous devrons nous conformer à une règle prescrite par Merise, dite de vérification et ainsi formulée, je cite : « La vérification permet de s’assurer que dans chaque occurrence d’individu-type ou de relation-type on ne trouve qu’une seule valeur de chaque propriété » (H. Tardieu, A. Rochfeld, R. Colletti. La Méthode MERISE, Tome 1. Principes et outils.). Selon cette règle (qui à mon sens n’a pas de justification objective¹), les attributs doivent être systématiquement monovalués. Soyons donc « merisement » corrects, conformons-nous à cette règle de modélisation, acceptons de nous résoudre à supprimer l’attribut CLI_TEL_NO et en remplacement mettre en oeuvre une entité-type TELEPHONE (comme vous l’avez fait) : il n’en demeure pas moins que malgré ce déguisement, sémantiquement parlant TELEPHONE reste bien une propriété multivaluée de CLIENT. En conséquence, il ne faudra pas oublier que, lors de la suppression d’un client dans la base de données, ses téléphones devront disparaître : l’entité-type TELEPHONE n’est pas autonome, on dit encore qu’elle est faible (weak entity) par rapport à l’entité-type CLIENT réputée forte (regular entity). (Voyez l’article de Peter Chen.)

Recherche systématique des rapports de force entre entités-types

Lors de la modélisation, il est indispensable de vérifier si pour chaque relation entre entités-types, le rapport des forces est équilibré, c'est-à-dire si une entité-type dépend ou non d’une autre, si elle en est une propriété multivaluée. Analysons quelques cas de votre MCD.

Cas des entités-types CLIENT et TITRE. Il es évident que la suppression d’un client n’a aucune incidence sur les titres recensés par le BAIV : TITRE est clairement une entité-type forte. D’un autre côté, la suppression d’un titre ne doit pas avoir d’effet sur les clients concernés. Lors d’une tentative de suppression d’un titre, un stimulus parvient jusqu’à ces clients : leur réaction doit être violente et la tentative doit échouer. Au niveau conceptuel la modélisation étant statique, il faudra attendre d’en passer au niveau logique pour prendre en compte le veto des clients et le signifier de façon formelle (par le truchement d’une contrainte référentielle SQL). Nous reparlerons de cela un plus loin, et pour le moment contentons-nous de noter que des deux entités-types CLIENT et TITRE, aucune ne dépend de l’autre, n’en est la propriété.

Cas des entités-types CLIENT et TELEPHONE. Comme on l’a vu ci-dessus, TELEPHONE est une propriété multivaluée de CLIENT, donc entité-type faible par rapport à celle-ci : la suppression d’un client entraîne celle de ses téléphones. Là encore, il faudra attendre le passage au niveau logique pour le signifier de façon formelle.

Cas des entités-types CLIENT et SOCIETE. On retrouve la situation précédente, à savoir que ces entités-types sont à considérer comme fortes et notamment que la suppression d’une société dans la base de données ne peut pas entraîner celles de ses collaborateurs (sinon, je vous laisse imaginer les conséquences vis-à-vis du BAIV lui-même...)

Un cas intéressant concerne les rapports de force entre les entités-types CLIENT et FACTURE. Je pense que l’on peut dire que la suppression d’une facture n’a pas de conséquence sur le client qui en est le destinataire (à ceci près qu’il faudra régler le problème de la suppression de sa dernière facture : le client doit-il disparaître avec celle-ci ? (présence d’une cardinalité 1,N)). D’un autre côté, la suppression d’un client implique-t-elle la suppression de ses factures ? Ce serait une aubaine pour les clients ayant une ardoise, mais je pense que le BAIV défendra la thèse selon laquelle FACTURE est une entité-type forte...

Cas des entités-types FACTURE et LIGNE_FACTURE. LIGNE_FACTURE est une propriété multivaluée de FACTURE et la suppression d’une facture entraîne celle de ses lignes.

On retiendra que certaines entités-types sont vraiment fortes, soit qu’elles ne sont absolument pas impactées par les événements qui affectent leurs partenaires (TITRE, MODE_PAIEMENT), ou si peu (SOCIETE), soit qu’elles s’opposent violemment à toute atteinte à leur intégrité (CLIENT, FACTURE). En revanche, il existe des entités-types faibles, qui ne sont en réalité que des propriétés multivaluées déguisées en entités-types au nom de la règle de vérification (TELEPHONE, LIGNE_FACTURE). Je vous laisse le soin de poursuivre l’étude pour les entités-types que je n’ai pas citées.

Identification absolue vs identification relative

Chaque entité-type réputée forte (et seulement forte) est identifiée de manière absolue, son identifiant est composé d’un attribut artificiel, unique. Parmi celles que j’ai citées, c’est donc le cas des entités-types TITRE, MODE_PAIEMENT, SOCIETE, CLIENT, FACTURE.

Chaque entité-type F réputée faible est identifiés de manière relative : elle hérite de l’identifiant de l’entité-type E dont elles est une propriété multivaluée, complété par un attribut artificiel permettant de distinguer chaque occurrence de F. (On dit encore que l’on établit une relation identifiante entre E et F).

Sur le MCD, les attributs hérités par identification relative ne figurent pas. Seuls sont représentés les attributs complétant l’identification. En cela votre MCD est conforme (entités-types TELEPHONE, LIGNE_FACTURE).

Intérêt de l’identification relative

Au niveau conceptuel (statique), comme on vient de le voir, l’identification relative est un moyen de mieux percevoir le poids relatif de deux entités-types dans les relations qu’elles entretiennent.

Au niveau logique (dynamique) on dispose d’une indication permettant de signifier le comportement d’une entité-type dépendante lors des opérations de mise à jour (voir plus loin le couplet sur le métabolisme des données). C’est aussi un moyen pour simplifier l’écriture de certaines requêtes (en les allégeant).

Au niveau physique, c’est un moyen de rendre incomparablement plus performantes les requêtes lourdes et les traitements par lots (batch). A mon sens, c’est fondamentalement là que l’identification relative est synonyme de puissance et justifie un travail minutieux en amont, même si en théorie on n’a pas au niveau conceptuel à se préoccuper de considérations bassement matérielles.

Je ne reviendrai pas sur l’aspect sémantique, et m’intéresserai désormais à l’aspect logique puis physique des choses.

Supposons que les entités-types SOCIETE et CLIENT de votre MCD soient fortes. Au niveau logique, la structure des tables correspondantes est la suivante (les clés issues des identifiants sont soulignées) :

SOCIETE (SOC_ID, SOC_NOM, ...)

CLIENT (CLI_ID, CLI_NOM, CLI_PRENOM, SOC_ID, ...)

N.B. La présence de l’attribut SOC_ID dans la table CLIENT est essentielle : c’est par son canal que l’on établit les relations entre les tables CLIENT et SOCIETE. On répond ainsi au Principe de l’information (ou Principe de représentation uniforme) énoncé par Ted Codd et caractérisant le Modèle Relationnel de Données :

Toute l’information contenue dans la base de données doit être explicitement représentée sous forme de valeurs dans les tables et par aucun autre moyen.

(Par exemple, l’utilisation de pointeurs est de facto proscrite).

Supposons encore que l’entité-type FACTURE soit forte (on examinera plus loin un autre scénario). La structure de la table FACTURE est la suivante :

FACTURE (FAC_ID, FAC_NUM, CLI_ID, ...)

Concernant l’entité-type LIGNE_FACTURE, sémantiquement faible :

Comme on l’a vu, l’identification relative se traduit par le fait que l’entité-type réputée faible hérite de l’identifiant de l’entité-type réputée forte. L’entité-type LIGNE_FACTURE est identifiée relativement à l’entité-type FACTURE et hérite en conséquence de l’identifiant FAC_ID de FACTURE. L’attribut LIF_ID vient compléter cet identifiant et la structure de la table qui est dérivée de l’entité-type LIGNE_FACTURE est la suivante :

LIGNE_FACTURE (FAC_ID, LIF_ID, LIF_REMISE_MONTANT, ...)

L’entité-type TELEPHONE donne à son tour lieu à la table suivante :

TELEPHONE (CLI_ID, TEL_ID, TEL_NO)

Le contenu de la base de données relatif à CLIENT et TELEPHONE pourra ressembler à quelque chose comme ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
 
CLIENT (CLI_ID   CLI_NOM    CLI_PRENOM)
          1      Guelykoy   Alain}
          2      fsmrel     François

TELEPHONE (CLI_ID   TEL_ID     TEL_NO)
             1        1        +33 6 07 08 09 10
             1        2        +33 6 07 08 09 11
             1        3        +33 6 07 08 09 19
             2        1        +33 6 10 99 98 97
             2        2        +33 9 10 11 12 13}

Les liens entre les deux tables sont définis par les valeurs communes de l’attribut CLI_ID. On constate aussi que les valeurs prises par l’attribut TEL_ID commencent à 1 pour chaque client et qu’il y a incrémentation d’une unité pour chaque téléphone supplémentaire d’un client : en ce sens on peut confirmer que l’on parle d’identification relative de TELEPHONE par rapport à CLIENT.

A noter que, si un numéro de téléphone n’appartient qu’à un client, l’attribut TEL_NO peut faire l’objet d’une clé dite alternative, garantissant l’unicité réclamée pour les numéros. On notera aussi que, contrairement aux attributs CLI_ID et TEL_ID qui sont des invariants, un numéro de téléphone peut faire l’objet de modifications (erreur de saisie, etc.)

Impact de l’identification relative sur l’écriture des requêtes

Supposons maintenant que l’on veuille par exemple connaître le total des remises consenties à la société Dubicobit.
Notre système est le suivant :

SOCIETE (SOC_ID, SOC_NOM, ...)

CLIENT (CLI_ID, CLI_NOM, CLI_PRENOM, SOC_ID, ...)

FACTURE (FAC_ID, FAC_NUM, CLI_ID, ...)

LIGNE_FACTURE (FAC_ID, LIF_ID, LIF_REMISE_MONTANT, ...)

La requête SQL correspondante requerra une jointure entre la table SOCIETE (porteuse du nom de la société) et la table CLIENT pour obtenir l’ensemble des (clés des) clients faisant partie de Dubicobit, ainsi qu’une jointure entre la table CLIENT et la table FACTURE pour obtenir l’ensemble des (clés des) factures correspondantes, ainsi qu’une jointure avec la table LIGNE_FACTURE pour récupérer les remises. Le système accèdera donc aux quatre tables pour répondre à la question posée.

Maintenant, identifions FACTURE relativement à CLIENT. Notre système devient :

SOCIETE (SOC_ID, SOC_NOM, ...)

CLIENT (CLI_ID, CLI_NOM, CLI_PRENOM, SOC_ID, ...)

FACTURE (CLI_ID, FAC_ID, FAC_NUM, ...)

LIGNE_FACTURE (CLI_ID, FAC_ID, LIF_ID, LIF_REMISE_MONTANT, ...)

Je vous ferai observer que, grâce à l’identification relative, l’attribut CLI_ID s’est propagé jusqu’à LIGNE_FACTURE et donc qu’il est inutile de faire participer la table FACTURE à la requête SQL. Le système n’aura ainsi à accéder qu’à seulement trois tables, à savoir SOCIETE, CLIENT et LIGNE_FACTURE. Pour mémoire, le SGBD DB2, élimine de lui-même la table FACTURE de la requête si elle y est mentionnée, car il comprend qu'elle est inutile.

Retenons que, si l’identification relative s’impose pour les entités-types faibles, elle peut être appliquée à des entités-types fortes, telles que FACTURE. On pourra rétorquer que l’on entre dans un processus d’optimisation qui déborde du strict cadre de la modélisation, mais j’assume. L’utilisateur apprécie que la réponse à ses requêtes soit rapide.

A propos du métabolisme des données

Comme on l’a vu, une entité-type faible est particulièrement sensible aux stimuli émis par l’entité-type dont elle est dépendante : la suppression d’un client dans la base de données entraîne la suppression de ses téléphones, de ses adresses électroniques. La suppression d’une facture entraîne la suppression des lignes de facture qui la composent.

Vous me direz : mais comment faire prendre en compte ces histoires de métabolisme, de réaction à des stimuli ? On sait que le MCD étant statique, il faudra attendre d’être au niveau logique pour régler ce problème. Cela est rendu possible par le biais d’un déclencheur associé à une contrainte référentielle associant les tables dérivées des objets-types du MCD. L’objet de ce déclencheur est de signifier au SGBD comment il doit se comporter lors des opérations de mise à jour. Par exemple, pour interdire la suppression d’un mode de paiement sur lequel sont branchées des lignes de facture, la contrainte référentielle portée par la table LIGNE_FACTURE et la mettant en relation avec la table MODE_PAIEMENT sera dotée d’un déclencheur de type ON DELETE RESTRICT (ou NO ACTION selon les SGBD), tandis que la contrainte référentielle portée par la table LIGNE_FACTURE et la mettant en relation avec la table FACTURE sera dotée d’un déclencheur de type ON DELETE CASCADE, signifiant que les lignes de facture d’une facture donnée acceptent de disparaître avec cette facture.

Identification relative et Modèle physique des données

Il faut savoir que les SGBD ont la fâcheuse habitude de recopier la structure des tables (concept logique) dans les fichiers sur le disque (structure physique) et qu’il n’y a donc pas indépendance des niveaux. En conséquence, la performance de certaines requêtes dépend du rangement des données sur le disque. L’identification relative joue un rôle déterminant, au niveau physique (c'est-à-dire sous le capot) pour les transactions lourdes, ou encore pour les traitements par lots (batch) revenant périodiquement et stressent la Production informatique. Exemple : « fournir la liste des clients et de leurs factures ».

Si les identifiants des clients figurent dans la structure des lignes de facture, on a alors la possibilité de ranger dans la même page sur le disque (ou au besoin dans des pages contiguës) les lignes de facture de chaque client (et par facture). Même principe pour les factures. Pour le BAIV, cela ne se ressent peut-être pas, mais quand vous avez dix millions de clients pour lesquels vous voulez tout savoir, il n’y a pas photo quant à la performance des requêtes. A défaut, les données sont éparpillées sur les disques et joue alors un phénomène appelé I/O Bound qui vous transforme un Armstrong (Lance) en un autre Armstrong (Neil) mais un scaphandre pour faire le Tour de France, ça n’est l’idéal...

Pour avoir une idée un peu plus précise, voyez par exemple le message #6 de la discussion ouverte par Igou77. Dans ce contexte, il est bon aussi de savoir à quoi sert et ressemble un index (voir à partir du message #38 de la discussion ouverte par master_och).

_______

¹ Au niveau logique relationnel, l’homologue de la règle de vérification de Merise porte le nom de Première forme normale (1NF). En utilisant le vocabulaire SQL, la 1NF s’énonce ainsi : Une table est en première forme normale si chacune de ses lignes contient exactement une valeur pour chacun de ses attributs.

En surface, les énoncés de la règle de vérification de Merise et la Première forme normale sont comparables, mais la réalité est très différente. Pour en savoir plus, vous pouvez vous reporter à ce que j’ai écrit à ce sujet (Bases de données relationnelles et normalisation).

[JPhi33]

Bonjour,

En effet, vous utilisez Merise et cette méthode ne traite au niveau conceptuel que de l’aspect statique des choses

Juste une petite précision à ce sujet.

Au niveau conceptuel, Merise ne traite dans le MCD que de l'aspect statique du SI. En effet, l'aspect dynamique est traité dans le MCT. Dans Merise, parler d'aspect dynamique du SI dans un MCD est donc contradictoire.

[fsmrel]

Bonsoir,

en effet vous utilisez Merise et cette méthode ne traite au niveau conceptuel que de l’aspect statique des choses

Au niveau conceptuel, Merise ne traite dans le MCD que de l'aspect statique du SI. En effet, l'aspect dynamique est traité dans le MCT. Dans Merise, parler d'aspect dynamique du SI dans un MCD est donc contradictoire.

Il est vrai que j’aurais dû être plus précis et écrire :

« en effet, vous utilisez un MCD Merise, et l’on n’y traite [au niveau conceptuel] que de l’aspect statique des choses ».

Dont acte.

Mais votre remarque m’amène à poursuivre sur le sujet du métabolisme des données.

Je suis bien d'accord que c’est avec le MCT que l’on traite de l’aspect dynamique : par exemple, QUAND et dans quelles CONDITIONS on supprime un client du BAIV.

Cela dit, le métabolisme des données relève-t-il du MCD ou du MCT ? Quitte à paraître hérétique et contradictoire, j’estime que le métabolisme échappe au MCT car d’instinct je le ressens comme consubstantiel aux données, et peu importe que le MCD soit réputé anatomique, je n’hésite pas à y injecter de la vie. Que dans le MCT on ait décidé quand et dans quelles conditions on déclenche une opération de suppression d’un client, cela est orthogonal au comportement de celui-ci : si Tartempion a des factures, et que le BAIV a décidé que cela devait se traduire par un rejet de l’opération, ces factures devront réagir aux stimuli et brandir leur veto, empêchant que Tartempion disparaisse de la base de données. Si Tartempion a des téléphones, ceux-ci devront accepter de disparaître (au cas où, bien sûr, Tartempion disparaîtrait effectivement de la circulation), etc. Si le BAIV avait décidé que la suppression d’un client devait entraîner celle de ses factures, à leur tour celles-ci auraient envoyé des stimuli vers les lignes de facture (réaction en chaîne).

Je n’hésite donc pas à prendre en compte le métabolisme dans un MCD. Et pour en rendre compte, je n’ai pas besoin de monter une usine à gaz, une lettre suffit...

Pour signifier que la suppression d’un client n’est pas possible tant qu’il a une ardoise, je représenterais ainsi la chose dans le MCD de Guelykoy :

[ CLIENT ]---0,N---( Reçoit )---1,1 (R)---[ FACTURE ]

La lettre « R » mise entre parenthèses signifiant « RESTRICT », terme repris du Modèle Relationnel de Données et donnant lieu à l’expression relationnelle au niveau du MLD :

VAR {FACTURE ...} ... FOREIGN KEY (CLI_ID) REFERENCES CLIENT ON DELETE RESTRICT ...

Si la suppression du client devait entraîner celle des factures :

VAR { FACTURE...} ... FOREIGN KEY (CLI_ID) REFERENCES CLIENT ON DELETE CASCADE ...

expression symbolisée ainsi dans le MCD (la lettre « C » mise entre parenthèses signifiant « CASCADE ») :

[ CLIENT ] ---0,N---( Reçoit )---1,1 (C)---[ FACTURE ]

Bien sûr, je me suis inspiré de la théorie relationnelle pour traiter du métabolisme au niveau du MCD. On pourrait donc me reprocher que mon MCD n'est pas un MCD, que j'anticipe et me place dans un contexte particulier. Mais que de temps gagné lors de l'étape suivante (MLD) dans l’expression des contraintes référentielles (sujet sensible s'il en est...), nul besoin pour le DBA que je suis de fouiller dans des dossiers de conception, de courir derrière les concepteurs de la SSII Dubicobit (qui entre temps sont partis vers de nouvelles aventures, etc.) Cela fait 20 ans que je fonctionne comme cela et ça marche.

[JPhi33]

« en effet, vous utilisez un MCD Merise, et l’on n’y traite [au niveau conceptuel] que de l’aspect statique des choses ».

Effectivement, avec cette formulation, ma remarque n'a plus lieu d'être...

Quitte à paraître hérétique et contradictoire...

En fait, non. Le groupe 135 de l'Afcet (1990) animé par Yves TABOURIER a établi qu'il est souhaitable de pouvoir définir des contraintes dynamiques dans le modèle EA. Celles-ci sont liées aux transitions entre états du système. Parmi ces "contraintes de stabilité", on trouve la notion d'association définitive. Une occurrence de cette association ne peut être détruite que si une occurrence d'entité qu'elle met en jeu est elle-même détruite. On note (D) à la suite du nom de l'association.

José MOREJON (1995) affine la définition de cette contrainte en la déportant sur la patte reliant une entité à l'association. L'association est "définitive par rapport l'entité", ce qui signifie qu'une occurrence de l'association ne peut être supprimée que si l'occurrence de l'entité, par rapport à laquelle elle est définitive, est elle-même supprimée. On note (D) entre l'entité et l'association (ou sur la patte, ce qui revient au même).

[ PRODUIT ]--0,n----( DetailCommande )---1,n-(D)-[ COMMANDE ]

Une fois la commande établie, une occurrence de DetailCommande s'y rapportant ne peut être supprimée que si la commande l'est elle-même.

[Guelykoy]

Bonsoir ,

J'ai compris ma question et voire plus, j'ai aussi imprimé vos interventions pour completer mes documents de perfectionnements. J'essai encore de patienter un tout petit peu pour la derniere confirmation de mon MCD avant de cliquer sur RESOLU. A mon avis j'en ai fini.

Je vous remercie bcp

[Guelykoy]

Je n'ai pas pu retouver le bouton "resolu" pour cloturer cette discussion
satisfaisante.

Juste merci à tous les intervenants, je viens de finir mon MPD.



A bientot