Discussion :

[jocile]

Bonjour,


Je me permets de vous contacter pour solliciter votre expertise et vos conseils concernant notre projet.
Dans le cadre de notre reconversion professionnelle, nous sommes chargé(e)s de développer un projet fil rouge,
nous avons une étape cruciale en la création d'un Modèle Conceptuel de Données (MCD) pour notre application.

Cependant, en tant que débutant(e)s dans ce domaine, nous éprouvons quelques difficultés à bien cadrer notre projet et à élaborer un MCD efficace.
Nous aimerions bénéficier de vos recommandations et de votre expérience pour nous guider dans cette démarche.

Quels sont les éléments clés à prendre en compte lors de la conception d'un MCD ?
Quelles sont les bonnes pratiques à suivre pour garantir la pertinence et la cohérence de notre modèle ?
De plus, comment pouvons nous assurer que notre MCD répond aux besoins spécifiques de notre projet?

Nous sommes ouverts à toute suggestion ou conseil que vous pourriez avoir à nous offrir.
Votre expertise serait d'une grande aide pour nous permettre d'avancer dans notre projet de manière efficace et structurée.

Nous nous sommes bien entendu documentés de notre côté notamment avec l'ouvrage de
Monsieur Bergougnoux "Modélisation Conceptuelle de Données" et en suivant les différentes discussions du forum.


Description du projet Gestion des équipements :
Entrée et sortie du stock.
Classification des différents types de matériels.
Localisation des équipements. (Etablissement)

Gestion des emprunts :
Suivi des emprunts à courte ou longue durée.
Identification des personnes ayant emprunté un équipement.


Optimisation de la gestion des équipements :
Identification des équipements disponibles ou non pour la location.
Gestion des autorisations d'accès pour une meilleure utilisation des équipements.


Interface utilisateur :
Permet aux emprunteurs de signaler différents événements liés au matériel (dysfonctionnement, panne, demande de retour anticipé, prolongation de prêt, demande de prêt complémentaire).
Interface de gestion complète pour les gestionnaires (état du parc, matériel en prêt, matériel non rendu).


Gestion des réservations :
Planning pour visualiser la localisation des matériels et leurs réservations passées et futures.


Système d'alerte :
Alerte en cas de retard dans le retour du matériel.
Notification des nouvelles demandes d'emprunt.


Gestion documentaire :
Stockage de documents (notice, documentation technique, vidéos)
sur l'utilisation des matériels.


Gestion des profils :
Attribution de droits spécifiques en fonction des profils d'utilisateurs (par exemple, certains utilisateurs ne peuvent pas louer certains types d'équipements).

Nous vous remercions par avance pour votre précieuse assistance.

[fsmrel]

Bonjour jocile,

Voilà du travail soigné, continuez !
 
Quelques petites remarques en passant, parmi celles que les baroudeurs ne manqueront pas de faire (gentiment !)

De l’identification relative :

N’hésitez pas à utiliser l’identification relative. Exemple :

Entité-type declaration_incident à identifier relativement à materiel et utilisateur.

 
En passant, profitez-en pour établir une association avec une entité-type type_incident (cf. ci-dessus).

Selon votre MCD, on peut accorder une demande de réservation sans demande préalable. Votre association accorder relève du voeu pieux... Je suggère une situation à 3 états : demande en cours, demande accordée, demande refusée. Une contrainte d’exclusion permet de signifier qu’une demande ne peut en même temps être accordée et refusée.
 

 
Numéro de série du matériel : clé alternative pour l’entité-type materiel ?

[escartefigue]

Bonjour jocile, bienvenue dans ce forum

Le modèle est déjà bien abouti, bravo.

Quelques remarques toutefois.

entité-type MATERIEL
L'attribut "duree_garantie" est une date, ce faisant, "date_fin_garantie" serait plus approprié. Si c'est bien une durée, alors son type doit être numérique et il peut éventuellement être accompagné d'une unité de mesure de la durée si elle peut changer (mois, années...).
L'attribut "numero_serie" devrait probablement être affublé d'une contrainte UNIQUE (matérialisée par une mise en gras sous looping)
La description gagnerait à être de type varchar(150) plutôt que char(150)


entités-type CATEGORIE et ROLE
Pour les typologies, il est courant d'avoir un code court et unique, par exemple char(3), en plus de l'identifiant et du libellé. C'est le cas pour les départements, les devises, les pays... C'est en effet plus pratique à l'usage que de manipuler le libellé in extenso.


entité-type UTILISATEUR
Le type INT pour le code postal est inadéquat. Le code postal est issu d'une nomenclature externe (celle de la poste en France) et on n'est pas à l'abri d'un changement (la poste pourrait décider de mettre des codes alpha).
Comme aucun calcul n'est à prévoir sur cette zone, un char(5) sera plus adapté.
Pour rappel, ce genre de mésaventure est arrivé il y a quelques années avec les départements, quand la Corse a été divisée en deux départements, le 20 est devenu 2A et 2B, au grand dam de ceux qui avaient choisi un type numérique pour l'héberger
L'adresse mail est normée et peut dépasser 150 caractères. Voyez la norme relative à ces adresses. Là aussi, comme c'est long et de longueur inégale selon les cas, du varchar sera préférable à du char. Le domaine pourrait être externalisé.
L'adresse postale est également normée par la poste, de mémoire 6 x 35 caractères, cette norme est accessible gratuitement sur internet.
Le numéro d'adresse de type char(150) est certainement une erreur.
Le type de voie pourrait être externalisé en créant une entité-type TYPE_VOIE (qui contiendra un identifiant, un code et un libellé) en lien avec l'adresse. Sinon, vous pouvez simplement ajouter une contrainte CHECK sur le type, mais la longueur est à revoir à la baisse


entité-type ETABLISSEMENT
Même remarque concernant l'adresse courriel et l'adresse postale que pour UTILISATEUR.
Le SIRET de l'établissement n'est il pas utile ?

[jocile]

Bonjour fsmrel,

Je voulais tout d'abord vous remercier pour votre aide et soutien.
Je viens de modifier le MCD en ce qui concerne la table type_incident et sa relation à la déclaration.
Merci pour votre suggestion pour la demande de réservation.

Au sujet du matériel, vous citez Numéro de série du matériel : clé alternative pour l’entité type matériel :
Alternative = Clé Primaire

Dans notre cas, le matériel pourra aussi bien être du hardware, mobilier, immobilier... effectivement cela ne fait pas sens puisqu'ils n'ont pas tous un numéro de série ?
Dans ce cas ajouter une table pour l'identification avec une clé étrangère? De type caractéristique artefact.

[escartefigue]

Au sujet du matériel, vous citez Numéro de série du matériel : clé alternative pour l’entité type matériel :
Alternative = Clé Primaire

Dans notre cas, le matériel pourra aussi bien être du hardware, mobilier, immobilier... effectivement cela ne fait pas sens puisqu'ils n'ont pas tous un numéro de série ?
Dans ce cas ajouter une table pour l'identification avec une clé étrangère? De type caractéristique artefact.

Clef alternative n'est pas obligatoirement clef primaire : parmi les clefs candidates, l'une d'entre elles est choisie comme clef primaire, elle devra être stable et concise.
Les autres clefs candidates feront l'objet d'une simple contrainte unique, mais non PK.

Par contre, puisque vous avez toutes sortes de types de matériel et donc probablement aussi de fournisseurs, il n'est plus possible de mettre une contrainte unique sur le n° de série, car on n'est pas à l'abri de doublons éventuels, même s'ils restent assez peu probables.

Vu que le numéro de série est issu d'un organisme externe (les différents fabricants), il ne faut pas choisir de l'integer, mais du char (si court) ou du varchar (si long).

Avez vous vu mes autres remarques plus haut ?

[fsmrel]

Bonsoir,

Au sujet du matériel, vous citez Numéro de série du matériel : clé alternative pour l’entité type matériel :
Alternative = Clé Primaire

 
Par définition, une clé alternative (alternate key) n’est pas une clé primaire (primary key). Toutes les deux sont des clés candidates (candidate keys) garantes de l’unicité : pour citer le Professeur Gardarin (voir son ouvrage Bases de données), une clé candidate est un « Ensemble minimal d’attributs dont la connaissance des valeurs permet d’identifier un tuple unique de la relation considérée ». Pour mémoire, dans le Modèle Relationnel de Données (Relational Model),alias Théorie relationnelle, la relation devient table en SQL et le tuple (n-uplet) devient ligne (row). Ainsi, une valeur de clé candidate ne peut être présente qu’une fois dans une table. L’une des possiblement multiples clés candidates a été rendue primaire, pour sa stabilité (invariance).
 
Prenons l’exemple de l’entité-type ENTREPRISE à la Banque de France. Les concepteurs m’avaient présenté un MCD dans lequel le code INSEE était l’identifiant ce cette entité-type. Je fis observer que le code INSEE pouvait être modifié, suite à erreurs et autres impedimenta signalés par l’Insee. Il me fut répondu que tout avait été prévu concernant la base de données : mise à jour par programmation du code INSEE dans toutes les tables faisant référence à la table ENTREPRISE. J’ai recommandé que la clé primaire soit un code non significatif, invariant, attribué par le SGBD (DB2) et non connu des utilisateurs (y-compris bien entendu les développeurs). Le code INSEE a été ravalé au rang de clé alternative (unicité garantie), modifiable, mais absent dans les autres tables, lesquelles restaient en relation avec la table ENTREPRISE par le jeu des clés étrangères référençant la nouvelle clé primaire de la table ENTREPRISE. Conclusion : la modification des codes INSEE ne concernait plus que la seule table ENTREPRISE et toute la programmation qui avait été initialement prévue est partie de facto à la poubelle. Plus de maintenance en conséquence et bien entendu gain appréciable au plan des performances, etc.

Vous aurez noté qu’escartefigue est en phase avec moi au sujet des définitions.

[fsmrel]

puisque vous avez toutes sortes de types de matériel et donc probablement aussi de fournisseurs, il n'est plus possible de mettre une contrainte unique sur le n° de série, car on n'est pas à l'abri de doublons éventuels, même s'ils restent assez peu probables.

Exact Capitaine, ta vigilance et ton oeil de lynx sont toujours aussi performants.

[fsmrel]

Bonsoir,

A propos de l’entité-type declaration_incident.

jocile, dans votre MCD précédent, l’attribut id_declaration_incident fait l’objet d’une identification absolue, caractéristique des entités-types fortes (qui ne dépendent d’aucune autre entité-type). Techniquement c’est possible, mais ontologiquement parlant, l’entité-type declaration_incident est faible, car dépendant en l’occurrence des entités-types materiel et utilisateur : abstraction faite du dessin, elle reste une association entre materiel et utilisateur.

L’intérêt ici de l’identification relative est notamment de permettre, par exemple, la mise en oeuvre de l’association DIT entre les entités-types declaration_incident et type_incident.

Notez que dans ce que j’ai proposé, j’ai utilisé l’identification relative :
 

[declaration_incident]----1,1(R)-----(DIM)----0,n----[materiel]
 
[declaration_incident]----1,1(R)-----(DIU)----0,n----[utilisateur]

 
Avec Looping, pour que l’attribut id_declaration_incident participe à l’identification relative, la cardinalité (1,1) ne suffit pas, encore faut-il en plus cocher la case « Identifiant relatif » :
 

 
 
Autre point : il faudra qu’on revienne aux demandes de réservation.
 
A l’intention de Paprick : note les cardinalités entre les entités-types materiel et materiel_image...

[escartefigue]

Bonjour,

Nous avons oublié de répondre aux questions relatives à la démarche :

Quels sont les éléments clés à prendre en compte lors de la conception d'un MCD ?
Quelles sont les bonnes pratiques à suivre pour garantir la pertinence et la cohérence de notre modèle ?
De plus, comment pouvons nous assurer que notre MCD répond aux besoins spécifiques de notre projet?

En premier lieu, il faut identifier les acteurs ou objets de gestion qui présentent un intérêt dans notre contexte. Ces acteurs deviendront les types d'entité (les rectangles) du modèle conceptuel.
Puis il faut identifier les interactions entre ces acteurs et leurs caractéristiques (obligatoire, facultative, simple ou multiple), ces interactions deviendront les associations (ovales) du modèle.
On aura parfois des interactions entre les associations : associations exclusives, inclusives... Par exemple, on peut facilement imaginer que l'association "restituer" entre une personne et un matériel porte sur une personne et un matériel connus de l'association "emprunter".
Il faut également chasser les synonymes pour ne retenir qu'un seul terme par concept. Ça évite les confusions.
Egalement, il faut de façon itérative faire valider le modèle par le donneur d'ordre. On a rarement bon du premier coup et on est rarement compris du premier coup .

Si le modèle est complexe, il est recommandé de commencer par un sous-ensemble, en général le cœur de métier.

EDIT le sujet est la gestion d'emprunts de matériel, mais si la réservation est bien matérialisée dans votre MCD, l'emprunt lui même n'est pas modélisé, pas plus que la restitution...
Je suppose que toute réservation n'est pas obligatoirement suivie d'un emprunt effectif ? À compléter donc

Enfin, quand le modèle commence à prendre corps, il ne faut pas hésiter à en décliner un modèle tabulaire pour le mettre à l'épreuve, en particulier sur les effractions aux règles de gestion !

[jocile]

Bonjour Messieurs,

Merci pour vos transmissions, recommandations et bonnes pratiques que vous partagez avec moi.
J'étudierai vos recommandations ainsi que les bonnes pratiques que vous m'avez partagées.
Il est important de souligner que je suis engagée dans une démarche itérative et que je maintiens des échanges réguliers avec la partie prenante.

Le feedback que je reçois est d'une grande valeur, car il me guide efficacement dans la bonne direction.
J'accorde une attention particulière à chaque valeur sémantique afin d'assurer une précision optimale
dans mes actions et de ma compréhension conceptuelle des données, les matérialiser et les faire interagir.
Mon MCD sera complété avec toutes vos recommandations.

Ces concepts sont nouveaux, mais incroyablement passionnants.

Je reviens vers vous début de semaine prochaine. Très bon week-end !!!!!

[fsmrel]

Bonjour jocile,

Bon week-end aussi à vous, profitez-en pour bien charger les batteries...

Ces concepts sont nouveaux, mais incroyablement passionnants.

Tant mieux ! pour approfondir, profitez-en pour vous plonger aussi dans l’ouvrage incontournable de Dominique Nanci (RIP) dont il a fait un cadeau fort précieux à developpez.com : Ingénierie des systèmes d'information - Merise deuxième génération.
 
Intéressez-vous en particulier au chapitre 7 consacré au MCD.
 
En passant : nous nommons de façon différente les entités-types, associations et attributs, mais pas de problème, vous comme escartefigue et moi-même savons interpréter. Nous pouvons tous conserver nos habitudes quand cela nous convient, mais à condition que les noms soient parlants...

En ce sens, pour éviter toute ambiguïté, votre entité-type demande_accord pourrait être renommée en demande_accordee. De même, l’entité-type demande_refus pourrait être renommée en demande_refusee.

Dans la partie du MCD que je vous ai proposée concernant les demandes de réservation, traînent des scories.

Ce que j’avais proposé :

 

 
 
Après aménagement :
 

 
 
En effet, il est évident que les attributs ReservationDateAccord et ReservationMotifRefus n’ont plus rien à faire dans l’entité-type DemandeReservation qui doit en être débarrassée.
 
Votre entité-type demande_reservation comporte un attribut validation. Quelle en est la finalité ?
 
A propos des dates :
 
— attribut date_debut (votre entité-type demande_reservation) : s’agit-il de la date à laquelle la demande a été faite par l’utilisateur ?
 

Dans mon MCD partiel, vous constaterez l’ajout d’une date de refus (attribut DateRefus).
 
Pour le moment, je vois ainsi les choses (je me sers de mon MCD) :

 

— Une demande d1 peut être en cours, auquel cas seule l’entité-type DemandeReservation est renseignée, les entités-types faibles DemandeOK et DemandeKO ne le sont pas. L’attribut DemandeReservationDate contient la date à laquelle la demande de réservation a été faite.
 
— La demande d1 a été accordée, auquel cas l’entité-type DemandeOK est elle aussi renseignée (attribut DateAccord).
 
— La demande d1 a essuyé un refus, auquel cas l’entité-type DemandeKO est elle aussi renseignée (attribut DateRefus).

 

Comme on n’est pas dans un univers quantique, la contrainte d’exclusion (X) entre les entités-types DemandeOK et DemandeKO est là pour signifier de façon formelle qu’une demande ne peut à la fois être accordée et refusée (au stade SQL, il y aura mise en oeuvre d’une assertion ou d’un trigger pour garantir cette exclusion).

 
— Cas de l’attribut date_fin (votre entité-type demande_reservation) : quelle en est la finalité ? En cas de demande accordée ou refusée, cet attribut apporte-t-il une information supplémentaire et nécessaire ? A défaut, le faire disparaître.
 
 
Accessoirement, quel est votre SGBD ?

Bonne reprise !

[fsmrel]

J’ai oublié une chose...
 
Dans votre MCD, les entités-types utilisateur et demande_reservation sont mises en relation au moyen de l’association accorder : cette association doit disparaître. En effet, pour répondre à la question « la demande de réservation d1 faite par l’utilisateur u1 lui a-t-elle été accordée ? », les entités-types demande_accord et demande_reservation sont là pour ça et suffisent.

Même chose pour répondre à la question « la demande de réservation d1 faite par l’utilisateur u1 lui a-t-elle été refusée ? », les entités-types demande_refus et demande_reservation sont là aussi pour ça.

[fsmrel]

Bonjour,

A propos des déclarations d’incidents.

J’ai précédemment proposé le MCD suivant :
 

 

 
A toutes fins utiles, je signale que le MCD suivant est équivalent dans la mesure où le code SQL produit par Looping est le même dans les deux cas :
 

 
Quand Looping traite de la CIF (contrainte d’intégrité fonctionnelle), la clé primaire de la table DeclarationIncident ne comportera que les attributs UtilisateurId et MaterielId. En l’occurrence l’objet de la CIF est de ne pas faire participer l’attribut TypeIncident à la clé primaire de la table.

[escartefigue]

On peut produire une variante graphique du 2^e MCD en cliquant sur la patte entre l'asso (DeclarationIncident) et l'entité [TypeIncident], puis en cochant case "entité ciblée par CIF"
En faisant ainsi, on obtient la représentation simplifiée de la contrainte : une simple flêche sur la patte d'association (symbolique qui a ma préférence)

[jocile]

Bonjour,

Je suis sur le (MCD) et j'ai étudié attentivement vos postes, références d'articles, nomenclatures et bien évidemment le chapitre 7 de l'ingénierie des systèmes (un ouvrage très instructif mais qui nécessiterait une vulgarisation pour les débutantes). J'y retrouve des concepts similaires à ceux abordés dans mes cours de sémiologie, tels que l'attachement aux représentations, les signes, le signifiant, les affordances et l'attachement à l'action verbale.

Notre MCD, qui doit être converti en Modèle Logique de Données (MLD), doit être opérationnel d'ici la fin de la semaine car nous devons créer des données fictives pour les tests. Il est important que je simplifie la démarche conceptuelle pour mes camarades. Les données que nous manipulons sont intangibles car nous n'avons aucun support d'inventaire. J'ai donc travaillé à rendre aussi concrets que possible la conception des données et leurs interactions dans notre future base de données (BD). La pierre angulaire de toute application. Je suis derrière ma machine avec ma matière grise.

SGBD : MySQL

[fsmrel]

Bonsoir jocile,

En l’état, votre MCD doit être aménagé. Merci de présenter une version tenant compte de nos remarques.

[jocile]

Bonjour Messieurs,

Veuillez trouver le MCD mis à jour.

L'adresse postale est également normée par la poste, de mémoire 6 x 35 caractères, cette norme est accessible gratuitement sur internet.
Norme Postale AFNOR NF Z 10-011
6 lignes de 38 caractères maximum (éventuellement une 7ème ligne pour l’international, pour indiquer le pays).

L'adresse mail est normée et peut dépasser 150 caractères. Voyez la norme relative à ces adresses.
J'ai repris les informations du tableau ci-dessous:
https://ineumann.developpez.com/tuto...iation-merise/

— attribut date_debut (votre entité-type demande_reservation) : s’agit-il de la date à laquelle la demande a été faite par l’utilisateur ?
Oui il s'agit bien de la date effectivement

Au plaisir de vous lire, très bonne journée
Jocile

[escartefigue]

Bonjour Jocile

Il reste encore beaucoup d'améliorations à apporter.

[MATERIEL]
L'attribut Date_fin_garantie est de type int :

• si c'est une date, il faut un type date ;
• si c'est une durée, int est ok, mais peut-être faut-il prévoir une unité de mesure de la durée si celle-ci peut varier (jour, semaine, mois...).

Numéro_serie :
Pour les raisons que j'ai données précédemment (plusieurs fabricants), on ne peut finalement pas positionner de contrainte unique sur cet attribut.
De plus, du varchar(200) est certainement beaucoup trop.


[UTILISATEUR]
Vous n'avez pas tenu compte de mes remarques précédentes :

entité-type UTILISATEUR
L'adresse mail est normée et peut dépasser 150 caractères. Voyez la norme relative à ces adresses. Là aussi, comme c'est long et de longueur inégale selon les cas, du varchar sera préférable à du char. Le domaine pourrait être externalisé.
L'adresse postale est également normée par la poste, de mémoire 6 x 35 caractères, cette norme est accessible gratuitement sur internet.
Le numéro d'adresse de type char(150) est certainement une erreur.
Le type de voie pourrait être externalisé en créant une entité-type TYPE_VOIE (qui contiendra un identifiant, un code et un libellé) en lien avec l'adresse. Sinon, vous pouvez simplement ajouter une contrainte CHECK sur le type, mais la longueur est à revoir à la baisse

[ETABLISSEMENT]
Là non plus vous n'avez pas tenu compte de mes précédentes remarques :

Même remarque concernant l'adresse courriel et l'adresse postale que pour UTILISATEUR.
Le SIRET de l'établissement n'est il pas utile ?

[CATEGORIE]
Ce type d'entité est à la fois en lien avec le matériel (via l'association CAM) et avec le rôle (via l'association role_categorie).
Je doute qu'une catégorie de matériel soit éligible pour un rôle et inversement. Il serait sans doute préférable d'avoir une entité-type [CATEGORIE_MATERIEL] et une autre [CATEGORIE_ROLE]


Association (EDU)
Un utilisateur ne peut-il pas changer d'établissement ? Si c'est le cas, cette association devrait être une ternaire en faisant participer une entité-type fictive [DATE]
Ainsi, on pourra retrouver l'établissement de l'utilisateur au moment de la réservation et au moment de l'emprunt.


Par ailleurs, vous n'avez pas modélisé cette partie :

Gestion des profils :
Attribution de droits spécifiques en fonction des profils d'utilisateurs (par exemple, certains utilisateurs ne peuvent pas louer certains types d'équipements).

[fsmrel]

Bonsoir,

[CATEGORIE]
Ce type d'entité est à la fois en lien avec le matériel (via l'association CAM) et avec le rôle (via l'association role_categorie).
Je doute qu'une catégorie de matériel soit éligible pour un rôle et inversement. Il serait sans doute préférable d'avoir une entité-type [CATEGORIE_MATERIEL] et une autre [CATEGORIE_ROLE]

Je suis d’accord, et intuitivement ça a l’air de tenir du mariage de l’eau et de l’huile...
jocile, pour quelle raison tenez vous à l’association Catégorie – Rôle ? Merci de fournir des exemples.