Discussion :

[Nicow57]

Bonjour,

Je bloque sur un point d'analyse depuis un petit moment et j'aimerai avoir votre avis.

Je dois gérer des rendez-vous entre un visiteur et un résident d'une entreprise.

J'ai donc une première entité VISITEUR(ID_visiteur, nom , prénom ,...) et RESIDENT(id_résident,nom prénom,..)
Pour chaque rendez vous un badge est attribué au visiteur. Le badge est détruit à la fin de l'entretien. Le Badge est donc spécifique à une visite

j'ai donc une entité visite que j'aimerai définir comme suis :

VISITE(#ID_visiteur,#id_résident,#date, Id_badge,..) Mais du coup je n'aurais pas d ' ID_visite pour identifier une visite ce qui serait pratique

(exemple :VISITE(Id_visite, id_badge,...)



Seulement ( et comme a chaque fois) je ne sais pas si il faut créer une entité DateRendez-vous ou placer date dans une association entre VISITEUR ET RESIDENT.

De plus je n'arrive pas à réunir les clé nécessaire à l'identification de la visite . L'idéal étant d'avoir un Id_visite pour mieux gérer les visites.

Ci-joint une ébauche de mon MCD faux ...




Règles de gestion :
Un visiteur rencontre 1 et 1 seul Résident par rendez-vous à une date donnée.
Un badge est associé à une seule rencontre et est détruit après.
Un badge est créé par un admin et un admin peut créer plusieurs badges.
Un visiteur peut appartenir à une blackList pour un motif et un seul
Un motif peut être associé à plusieurs visiteurs.

L’idéal serait d’avoir un id_badge et un id_visite pour une simplification du travail au niveau des rapports à effectuer après …




Message d'erreur quand je tente de générer le modèle physique:

Catégorie Vérifier Objet Emplacement
Identifiant d'entité Existence d'attribut d'entité Identifiant 'VISITE.Identifiant_1' ::VISITE
Association Nombre de liens = 2 avec un lien identifiant Association 'RENCONTRE'
Association Association bijective entre deux entités Association 'RENCONTRE'
Association Cardinalité maximale des liens Association 'RENCONTRE'

D'avance merci pour vos petits conseil ou pistes pour gérer au mieu ce problème .
j'espère avoir été suffisament explicite.

[Nicow57]

après réflexion et quelque modification j'obtiens le MCD suivant pouvez vous donner votre avis . S'il est juste , fonctionnelle , pratique ?

Les problèmes que cela génère etc ?
merci

[fsmrel]

Bonjour,


Pertinence de l’entité-type Badge.

Quand je rends visite à l'un de mes clients, l’hôtesse d’accueil me demande mon nom, mon prénom, le nom de ma société et me demande en outre un document prouvant mon identité, qu’elle conserve tant que je n’aurai pas rendu le badge qu’elle me confie et que j’accroche au revers de mon veston ou que je mets dans ma poche, suivant l’humeur du moment. L’essentiel est que ce badge me permette de franchir la borne dont la porte est jusqu’ici bloquée.

Cela dit, parce qu’un badge est un morceau de carton, est-ce pour autant qu’il faille en faire une entité-type ? Toutes les informations qu’il porte sont connues : A vous de démontrer la valeur ajoutée de cette prétendue entité-type, en ayant présent à l’esprit le rasoir de Guillaume D’Ockham, lequel nous avertit : Ne multipliez pas les entités au delà du nécessaire. Du point de vue de la modélisation, un bout de carton peut très bien, a priori, faire l’objet de propriétés portées par des entités-types ou associations-types préexistantes.


Vous précisez la règle de gestion suivante :

Un visiteur rencontre 1 et 1 seul Résident par rendez-vous à une date donnée.

Quelque part, "rendez-vous" est synonyme de "heure de rendez-vous". Autrement dit, l’attribut dateRdz de votre entité-type Date est du type DateHeure.

[Nicow57]

Erf oui dans mon élan de vouloir bien faire j'ai effectivement multiplié mes entités

je vais donc passer l'id_badge dans l'entité VISITE et spécifier que le type de la date est un datetime ^^

mise à part ces remarques judicieuse le modèle semble cohérent ? à mon gout oui mais sait on jamais quand on bosse dessus on manque parfois de recul ...
donc n' hésitez pas à critiquer encore et encore. Je suis en Stage et je ne peux pas laisser quelque chose m'échapper.



En tout cas merci bien.
Recevez la reconnaissance d un jeune padawan d'analyste ...

[Nicow57]

A NOUVEAU BESOIN D'AIDE

Toujours entrain de plancher sur l'analyse... Après tout une bonne analyse permet un bon développement ...
Petit soucis.

Dans mon précédent modèle j'ai la clé primaire de Visite composé de 3 clés.
je souhaiterais dans un soucis d'efficacité pour mes futurs requêtes inséré un ID_visite ( qui pourra être auto incrémenté et qui identifie la visite)
Cependant comment préciser qu'il ne peut y avoir qu'une visite d'un visiteur à un résident à un moment donné. ce trinômes d'entité doit être à mon sens unique.





Pour tenter de faire clair ...

une visite devrait etre identifier par le trinôme id_visiteur,id résident et date mais j'aimerai l'identifier par un ID visite tout en gardant l'unicité de chaque visite.

[Nicow57]

bon finalement j'opte pour un modèle conceptuel pas parfait je contrôlerai les doublons à l'aide de triggers.

[fsmrel]

bon finalement j'opte pour un modèle conceptuel pas parfait je contrôlerai les doublons à l'aide de triggers.

Pour éviter les triggers, conservez plutôt l'identification relative, et si vous tenez vraiment à l'attribut id_visite, faites-en un identifiant alternatif.

[CinePhil]

On sort de la conception pour entrer dans la mécanique du SGBD mais si celui-ci gère ce type de contraintes, et si vous tenez absolument à ajouter un identifiant à Visite, vous pourrez mettre une contrainte UNIQUE sur le triplet qui aurait dû former la clé primaire, et même un index de type UNIQUE sur ces trois colonnes.

Avant de faire ceci, posez-vous quand même la question : "Comment vais-je utiliser les informations figurant dans cette table ?"
Si la réponse est "Dans une grande majorité des cas, je vais devoir la joindre avec au moins une des trois tables fournissant une des clés étrangères", l'utilité de votre id supplémentaire se réduit fortement.

Dans l'état actuel du besoin que vous nous avez exposé, je ne vois pas à quoi pourrait servir d'ajouter cet id, c'est à dire de transformer cette association en entité.