Discussion :

[CinePhil]

Ce n'est pas l'objet principal de cette discussion mais...

Non pour deux raisons, on peut faire une modélisation partielle, tester la validité du modèle ( méthode agile ) et murir sa réflexion.

C'est à dire commencer le schéma de données et commencer à développer avec puis compléter ce schéma au fur et à mesure de l'avancement.
Et il y a là intérêt à ce que le modèle de données soit béton dès le début sinon une modification de ce qui a déjà été modélisé peut entraîner une modification de ce qui a déjà été développé.

Pour la montée en charge c'est faux, une contrainte rajoute du temps de traitement (index, clef, ...), avoir un beau schéma garantie la cohérence des données et non la performance. Je suis en décisionnel et on dénormalise quand le besoin s'en fait sentir. Ce sont des choix d'optimisation.

La lecture de nombreux messages de fsmrel qui a une grande et longue expérience professionnelle dans les grosses bases de données de grands comptes, ainsi que ceux, parfois plus violents, de SQLPro, m'ont convaincu du contraire pour les données de production.
Ma maigre expérience m'a conforté dans l'importance de la modélisation rigoureuse des données, y compris pour les performances.

Je ne connais pas bien le domaine du décisionnel mais j'ai cru comprendre qu'en fait en décisionnel on travaille sur des données mortes qui sont une réplication à un instant t des données de production. Dans ce cas, oui, il peu être utile de construire en quelque sorte des vues matérialisées pour interroger plus rapidement une grande masse de données. Mais la cohérence des données vient de la construction du package que l'on veut interroger. Ensuite on peut mettre à la poubelle ces données qui n'ont pas vocation à être modifiées.

Ceci dit, évitons de polluer cette discussion avec un débat qui dépasse notre débutant valeureux qui veut apprendre à bien faire les choses !

[sowane]

Bonsoir Olivier et Philippe,
Je ne sais plus quoi dire pour vous remercier de vos conseils et de votre patience.
Vos discussions sur les différentes options ne sont pas du tout polluantes ici mais au contraire enrichissantes.
Toute la journée j'ai tout repris selon vos remarques/conseils. J'étais contente du résultat, je pensais avoir bien compris. Et ce soir au moment de mettre au propre pour vous soumettre le résultat je me rends compte que plus rien ne va.
Mais je ne me décourage pas du tout, je jette l'éponge pour ce soir et reprendrai demain à tête reposée.
Très bonne soirée et encore merci,
Sowane

[nathieb]

Bonjour,

C'est dans ces moments là qu'il faut prendre du recul. Prendre le temps, mais pas se focaliser sur le problème, cela va se mettre en place tout seul.

Pour ne pas me décourager, souvent il m'arrive de commencer à écrire le script SQL, ou à implémenter mes idées, dans le jargon, on parle de prototype. cela permet de fixer les idées.
maquette -> prototype -> logiciel , les fonctionnalités ne sont que superficielles.
Cela te permet ainsi de revenir sur la partie conception et de mieux appréhender certains concepts ( notamment UML, Merise ).

Bon courage.

Olivier

[sowane]

Bonsoir Olivier et Philippe,
Merci Olivier pour tes encouragements matinaux.
Je vois plus clair aujourd'hui. J'ai repris et me permets de vous soumettre encore un MCD rectifié.
1) j'ai revu toutes les cardinalités
2) tous mes identifiants seront des clés auto-incrémentées, exceptés "nom_etage" et "nature-roche", je ne vois pas comment faire autrement, un n° ne voudrait rien dire. J'ai renommé toutes les clefs primaires" num_...".
4) beaucoup de réflexion autour des photos : finalement les cardinalités sont :
photo 1,1 (et pas 0,1) ---representer--- 0,n echantillon/gite. En fait s'il n'y a pas de photo il n'y aura pas d'enregistrement dans la bdd. Donc il n'y a pas besoin d'une table associative.
5) j'avais créé les tables d'associations "echantillon_cortex" et "echantillon_patine" mais ça ne colle pas. Il est impossible de mettre un identifiant, à part une clé auto-incrémentée et cela n'a pas de sens pour moi ? Je préfère l'option 2 que vous me proposez : une colonne boléenne "oui" ou "non" et si "oui" une zone de description.
6) J'ai rectifié la table "etage" et l'association "contenir" en incluant "date" dans la table.
7) Tout à fait exact pour l'association terniaire "documenter". Une biblio peut documenter des gites prospectés lors d'une prospection mais peut également être une synthèse de plusieurs prospections ou concerner une prospection et faire référence à d'autres.
8) Je n'avais pas compris pour les intervenants, j'avais créé plein de tables au lieu d'associations. J'ai repris et fait toutes les associations possibles.
8) Une seule cardinalité pose encore problème "documenter" avec 0,1---0,n (cas n° 12 du tableau de Philippe, devenu ma bible). Je pense que cela se règlera dans le MLD ? par une table associative.

Je vous remercie sincèrement si vous avez un peu de temps de bien vouloir encore vérifier ce nouvel essai.
Très bon week-end,
Sowane

[CinePhil]

2) tous mes identifiants seront des clés auto-incrémentées, exceptés "nom_etage" et "nature-roche", je ne vois pas comment faire autrement, un n° ne voudrait rien dire.

Mais justement, une clé primaire auto-incrémentée n'a aucune sémantique ! Elle n'est là que comme identifiant, clé primaire, et distingue d'éventuels jumeaux.
Un nom_etage ou une nature_roche alphanumérique est contre-performant et gourmand en octets.
À lire : l'article de SQLPro sur ce qu'est une bonne clé.

4) beaucoup de réflexion autour des photos : finalement les cardinalités sont :
photo 1,1 (et pas 0,1) ---representer--- 0,n echantillon/gite. En fait s'il n'y a pas de photo il n'y aura pas d'enregistrement dans la bdd. Donc il n'y a pas besoin d'une table associative.

Là non plus, tu n'as pas compris !
Une photo représente un gîte OU un échantillon donc le modèle est celui-ci :
photo -0,1----représenter----0,n- echantillon
|---------0,1----représenter----0,n- gite

Et comme je l'explique dans mon article, il faut deux tables associatives dont la clé primaire sera l'identifiant de la photo.

Dans ton MCD, tu as refait la même erreur qu'au début et une photo représente un gîte ET un échantillon !

5) j'avais créé les tables d'associations "echantillon_cortex" et "echantillon_patine" mais ça ne colle pas. Il est impossible de mettre un identifiant, à part une clé auto-incrémentée et cela n'a pas de sens pour moi ? Je préfère l'option 2 que vous me proposez : une colonne boléenne "oui" ou "non" et si "oui" une zone de description.

Je rappelle la rigueur :

- cortex : c'est oui ou non.

Alors c'est une colonne booléenne.

C'est seulement si oui qu'on rempli les autres critères (épaisseur, couleur, type),

En toute rigueur, il faudrait alors mettre ces données dans une autre table puisque tous les échantillons ne sont pas concernés.
Tu aurais alors un héritage :
echantillon_a_cortex -(1.1)----être----0,1- echantillon

L'échantillon à cortex est identifié relativement à échantillon, c'est à dire que la clé primaire de la future table sera également clé étrangère référençant l'échantillon. C'est le cas typique où l'identifiant d'une table issue d'une entité type du MCD n'est pas auto-incrémenté.

Si tes essais de echantillon_cortex et echantillon_patine correspondent à l'auto-citation que je viens de faire, relis la phrase que j'ai mis en gras : Tu ne mets pas dans ces tables filles une clé auto-incrémentée mais une clé étrangère référençant l'échantillon et qui est en même temps clé primaire de la table fille.

8) Je n'avais pas compris pour les intervenants, j'avais créé plein de tables au lieu d'associations. J'ai repris et fait toutes les associations possibles.

OK mais mets plutôt des cardinalités mini à zéro du côté de l'intervant car avec ton MCD, un intervenant fait tout au moins une fois !
D'une manière générale, évite autant que possible les cardinalités mini à 1 sur toutes les branches d'une association. Ça complique, souvent inutilement, l'implémentation du modèle en BDD.
Par exemple, un étage est, si j'ai bien compris, un référentiel scientifique de classification des terrains qui a son existence propre en dehors de la présence ou non de gîte. Autrement dit, un étage ne dépend pas d'un gîte pour exister donc il peut ne pas y avoir de gîte pour un étage et la cardinalité mini est zéro côté étage.

8) Une seule cardinalité pose encore problème "documenter" avec 0,1---0,n (cas n° 12 du tableau de Philippe, devenu ma bible). Je pense que cela se règlera dans le MLD ? par une table associative.

Tu n'as pas de cardinalités 0,1 - 0,n dans l'association "documenter". D'ailleurs, avec les associations ayant plus de deux branches, c'est beaucoup plus simple : table associative tout le temps !

Je vous remercie sincèrement si vous avez un peu de temps de bien vouloir encore vérifier ce nouvel essai.

Où en étais-je dans ma numérotation... ?

9) Association caractériser
Une association provient d'un gîte et est caractérisé par une roche mais je pense qu'un gîte peut contenir plusieurs types de roches différentes, donnant lieu éventuellement à la prise de plusieurs échantillons différents. Il n'y a pas là une association ternaire comme tu l'as fait mais éventuellement, si tu veux cataloguer toutes les roches présentes sur un site, même s'il n'y a pas d'échantillon de toutes ces roches, il faut deux associations distinctes :
roche -0,n----caractériser----1,1- echantillon
|---------0,n----contenir----1,n----gite

Et en toute rigueur il faudrait une contrainte d'inclusion entre les deux associations pour éviter d'avoir des échantillons d'une roche R prise sur un gîte qui ne contient pas cette roche R.

10) Association prélever
Un intervenant peut prélever un gîte et un gîte peut être prélevé par plusieurs intervenant.
Bizarre cette notion de "prélever un gîte" !
À moins que certains gîtes soient hantés et que parfois l'un d'eux prélèvent un intervenant ?
S'il s'agit de prélever des échantillons sur un gîte, je pense que l'association devrait plutôt être entre intervenant et échantillon.

11) encore quelques truc potentiellement à externaliser
a) qualite_intervenant
C'est probablement le nom d'une fonction (chercheur, assistant...) qui sera donc un texte répétitif. Dans ce cas, il faut l'externaliser. Si par contre c'est une fonction plus précise (Professeur de géologie à la Faculté machin), alors tu peux laisser comme ça.
b) zone_geographique de la prospection
Idem, si c'est la référence à un secteur, une région, un département... tu l'externalises.
Si c'est une zone plus précise relative au lieu de la prospection (près de l'entrée principale de la grotte de Niaux), alors tu laisses comme ça.
c) programme de la prospection
Idem, tu as compris le principe ?
À vérifier sur l'ensemble du MCD. Il ne faut pas avoir peur de créer de petites tables de référence ; ça accélère ensuite le traitement des données.

C'est tout ce que je vois pour l'instant.
Bon courage !

[sowane]

Bonsoir Philippe,
Combien de MCD j'ai fait depuis mon dernier message et votre réponse ! J'ai replongé dans la littérature (Cyril Gruau entre autres). En vain pour le moment, pas de MCD abouti ce soir. J'ai suivi à la lettre les conseils de votre réponse, voici où j'en suis ce soir :

2) Tous mes identifiants ont été rectifiés en auto-incrémentés.
4) Entité « photo » toutes les cardinalités ont été modifiées selon vos conseils. Pour les tables associatives, voir ci-dessous.
5) Tables d’association « echantillon_cortex » et « echantillon_patine » : voir ci-dessous.
8) Entités « intervenants » et "etage" : cardinalités rectifiées.
9) Pourriez-vous, SVP, me dire ce que vous entendez par « contrainte d’inclusion » ? J'ai rectifié les cardinalités.
10) Association « prelever » : en fait il s’agit d’un prospecteur, envoyé dans le cadre d’une prospection, qui va vérifier s’il s’agit bien d’un gîte et si oui prélever des échantillons. On prélève les échantillons d’un gîte, sur ce gîte. Il me semble que l’association devrait se faire entre « intervenant » et « gite » et non pas entre « intervenant » et « échantillon » ? C’est le gîte qui est prélevé par l’intermédiaire d’échantillons. Peut-être que c'est le verbe qui ne correspond pas bien, j'en cherche un autre.
11) a, b et c : externaliser. Je pense que vous parlez de tables d’associations. Pourquoi pas, mais voir ci-dessous.

Pour toutes les tables associatives que vous me conseillez (photo, échantillon à cortex, échantillon à patine, intervenant, zone géographique, programme de la prospection), je pense que je n’ai pas compris quelque chose. Vous dîtes « Il ne faut pas avoir peur de créer de petites tables de référence ; ça accélère ensuite le traitement des données. »
Je les ai toutes créées et mon MCD devient illisible, mon écran 27 pouces ne suffit plus ! Je n’arrive plus à trouver de verbe pour les associations.
Je ne sais pas encore vraiment ce qu’il y a après ce MCD et il me manque des bases : est-ce que ces tables associatives ne sont pas créées automatiquement lors de la création du MLD par le logiciel (Analyse SI) ? C’est ce qu’il me semble quand je vais voir les MLD et le MPD proposés ?
D’autre part, dans AnalyseSI, il n’est pas possible d’utiliser 2 fois le même identifiant ou attribut. Cela pose des problèmes lorsque les clés primaires des nouvelles tables d’association sont les identifiants d’autres entités (par ex. num_echantillon qui doit servir x fois) ? Cela n’est pas accepté par le logiciel et je dois « tricher » avec num_echantillon1, num_echantilon_2…

2 derniers points : dans le pdf de Cyril Gruau, les associations ont souvent des attributs. Je n’en ai aucun, est-ce normal ? Est-ce utile ? Qu’en est-il des CIF dans mon MCD ? Est-ce une étape ultérieure ? Je trouve cette notion complexe.

Je vous remercie si vous aviez le temps de m’apporter encore une réponse. Dès réception je construirais le MCD et vous le soumettrais une ultime fois.

Très bonne soirée, cordialement,
Sowane

[CinePhil]

J'attends de voir le nouveau MCD pour ces points :

2) Tous mes identifiants ont été rectifiés en auto-incrémentés.
4) Entité « photo » toutes les cardinalités ont été modifiées selon vos conseils. Pour les tables associatives, voir ci-dessous.
5) Tables d’association « echantillon_cortex » et « echantillon_patine » : voir ci-dessous.
8) Entités « intervenants » et "etage" : cardinalités rectifiées.

9) Pourriez-vous, SVP, me dire ce que vous entendez par « contrainte d’inclusion »

?
En voici un exemple assez parlant.

10) Association « prelever » : en fait il s’agit d’un prospecteur, envoyé dans le cadre d’une prospection, qui va vérifier s’il s’agit bien d’un gîte et si oui prélever des échantillons. On prélève les échantillons d’un gîte, sur ce gîte. Il me semble que l’association devrait se faire entre « intervenant » et « gite » et non pas entre « intervenant » et « échantillon » ? C’est le gîte qui est prélevé par l’intermédiaire d’échantillons. Peut-être que c'est le verbe qui ne correspond pas bien, j'en cherche un autre.

Si tu veux modéliser le fait qu'un prospecteur (un intervenant) se rend sur un site sans forcément prélever d'échantillon, tu peux modéliser ceci :
intervenant -0,n----visiter----1,1- gite

Les cardinalités 1,1 ci-dessus supposent qu'il s'agit ici de la première visite ne donnant pas forcément lieu à la prise d'échantillon.

Mais tu dis toi-même "qui va vérifier s’il s’agit bien d’un gîte". Ceci laisse supposer que pour ces potentiels gîtes qui n'en sont en fait pas, toutes les propriétés des gîtes ne seront pas renseignés. Peut-être faut-il alors distinguer les "sites" prospecter et faire un héritage vers les gîtes réels ?
gite -(1,1)----être----0,1- site
À toi de voir ensuite par exemple si l'association contenir s'applique entre etage et gite comme actuellement ou plutôt entre étage et site. Autrement dit, va t-on visiter un site parce qu'on sait qu'il y a un ou des étages géologiques intéressants et laissant supposer qu'il peut y avoir des gîtes à étudier ou bien la présence d'un étage quelque part est-elle détectée lors de la visite d'un site qui alors devient un gîte à prospecter ?

11) a, b et c : externaliser. Je pense que vous parlez de tables d’associations.

Pas de tables d'associations mais de tables de références.
Exemple a) qualite_intervenant
Le MCD est le suivant :
intervenant -1,1----avoir----0,n- qualite_intervenant

Il y a donc une table de plus mais la cardinalité 1,1 donnera seulement une clé étrangère dans la table intervenant, pas une table associative.

Pourquoi pas, mais voir ci-dessous.

Pour toutes les tables associatives que vous me conseillez (photo, échantillon à cortex, échantillon à patine, intervenant, zone géographique, programme de la prospection), je pense que je n’ai pas compris quelque chose. Vous dîtes « Il ne faut pas avoir peur de créer de petites tables de référence ; ça accélère ensuite le traitement des données. »
Je les ai toutes créées et mon MCD devient illisible, mon écran 27 pouces ne suffit plus !

Sur le MCD que je vois actuellement, tu peux par exemple rapporcher gite de etage pour gagner de la place, voire même carrément le mettre entre etage et prospection.

Je n’arrive plus à trouver de verbe pour les associations.

Je t'ai suggéré ci-dessus le verbe visiter. Mais c'est vrai par exemple que pour les héritages, ce sera toujours le verbe "être". AnalyseSI interdisant je crois que deux associations portent le même nom, il faut alors les nommer être_1, être_2... ou alors utiliser des acronymes pour les tables dans le nom de l'association. Si tu as par exemple plusieurs associations "avoir" similaires à celle que je viens de donner, tu peux l'appeler ainsi : int_avoir_qlt.
Ce système est d'ailleurs assez utile pour petre sûr de ne jamais utiliser de mot réservé du langage SQL pour les noms de tables et de colonnes lors de la génération de la BDD.
Tu peux lire à ce sujet l'article de SQLPro sur la normalisation des noms des objets en BDD. Mais si tu l'appliques rigoureusement, tu auras besoin de plus de place pour ton MCD !

Je ne sais pas encore vraiment ce qu’il y a après ce MCD et il me manque des bases : est-ce que ces tables associatives ne sont pas créées automatiquement lors de la création du MLD par le logiciel (Analyse SI) ? C’est ce qu’il me semble quand je vais voir les MLD et le MPD proposés ?

Oui. C'est l'avantage de travailler avec un logiciel de modélisation mais AnalyseSI présentait encore de gros manques lorsque je l'avais essayé il y a quelques années. Je ne sais pas si son développement a été repris depuis que son auteur l'a abandonné.

D’autre part, dans AnalyseSI, il n’est pas possible d’utiliser 2 fois le même identifiant ou attribut. Cela pose des problèmes lorsque les clés primaires des nouvelles tables d’association sont les identifiants d’autres entités (par ex. num_echantillon qui doit servir x fois) ? Cela n’est pas accepté par le logiciel et je dois « tricher » avec num_echantillon1, num_echantilon_2…

Cette fois, la norme de SQLPro est utile mais je l'ai adaptée.
SQLPro dit qu'une propriété doit toujours avoir le même nom si elle représente le même concept physique. Ainsi, si l'identifiant d'un intervenant est INT_ID, c'est ce nom qui devra être utilisé en tant que clé étrangère dans les autres tables.
Personnellement, je préfère gardé le concept de l'acronyme qui dit de quelle table provient la colonne lorsqu'on la rencontre dans une requête SQL. La clé étrangère référençant l'intervenant qui a rédigé une biblio sera ainsi pour moi bib_id_redacteur, ce qui suffit à deviner que ce rédacteur est un intervenant puisque c'est la seule table de personnes dans le schéma. L'acronyme "bib" signifie que cette colonne fait partie de la table "biblio".

2 derniers points : dans le pdf de Cyril Gruau, les associations ont souvent des attributs. Je n’en ai aucun, est-ce normal ? Est-ce utile ?

Ce n'est pas forcément très courant ; on ne met des attributs aux associations que lorsque c'est nécessaire.
Les associations engendrant une table associative sont les seules pouvant porter des propriétés.
Je ne vois pas de cas a priori dans ton MCD qui justifierait la présence d'une propriété dans une association mais je vais te donner un exemple.

Supposons que tu veuilles modéliser le fait que les intervenant travaillent sur les gîtes en une ou plusieurs fois et que tu veuilles mémoriser les dates auxquelles ils ont travaillé sur les gîtes. Tu aurais, en première approche, le MCD suivant :
intervenant -0,n----travailler----0,n- gite

Mais avec ce MCD, un intervenant ne peut travailler qu'une seule fois sur un gîte. Il faut alors ajouter à l'association les dates de début et de fin de la période de travail, ce qui donne la table associative suivante :
travailler (trv_id_intervenant, trv_id_gite, trv_date_debut, trv_date_fin)
Comme trv_date_debut participe à la clé primaire, un intervenant peut travailler plusieurs fois sur un même gîte.
En rétro-ingénierie, cette table donnera en fait la création dans le MCD d'une entité fictive pour la date :
intervenant -0,n----travailler----0,n- gite
[date] -0,n-------------------|
C'est ainsi qu'il faudrait normalement modéliser cette association.
Mais même cette association ternaire ne prend en compte que la date de début alors que nous voulons aussi la date de fin, il faut donc ajouter une propriété à l'association.

La suite plus tard, j'ai un rendez-vous.

[sowane]

Bonjour Philippe,
Je vous remercie pour cette longue réponse très précise. Je dois m'absenter jusqu'à mardi en Espagne sans connexion Internet.
Je n'abandonne pas, je posterai mes MCD et MLD dès mon retour mardi soir. J'espère que tout sera OK cette fois-ci
J'ai fait des essais et je trouve que c'est mieux de faire les 2 en parallèle, je visualise mieux ce que vous voulez dire.
Bon week-end prolongé,
Sowane

[sowane]

Bonjour Philippe,
J'ai pris beaucoup de retard, j'espère que vous êtes toujours là.
Je me permets de vous soumettre un nouveau MCD rectifié selon vos conseils, et ci-dessous mes quelques remarques :

4) je ne comprends pas ces 2 tables associatives. Pourquoi 2 ? Dans le MLD, une seule table associative a été créée avec 3 clés primaires :
. num_echantillon
. num_photo
. num_gite

9) Contraintes d’inclusion et d’exclusion : merci pour le lien vers l’article très clair. N’est-ce pas la même chose que les CIF ?

10) Si après vérification sur le terrain il ne s’agit pas d’un gîte il n’y a pas d’enregistrement dans la bdd.

11) a, b, c : c’est fait.

Pour les noms de type int_avoir_qlt : je comprends qu’il s’agit du nom de la nouvelle entité/table associative qui sera créée au niveau du MLD ?
Idem pour les clés étrangères qui deviennent par ex. bib_id_redacteur ? Ce nom pour une clé étrangère doit être changé au niveau du MLD ?
Je rectifierai tous les noms dans le futur MLD.

Non, heureusement, je n’ai pas besoin de date de prospection.

Si vous aviez encore un peu de temps pour regarder ce MCD ce serait super. Avec mes remerciements je vous souhaite une bonne journée,
Sowane

[CinePhil]

Rapidement parce que je n'ai pas beaucoup de temps...

4) je ne comprends pas ces 2 tables associatives. Pourquoi 2 ? Dans le MLD, une seule table associative a été créée avec 3 clés primaires :
. num_echantillon
. num_photo
. num_gite

Il me semble que plus haut il avait été établi qu'une photo représente un gîte OU un échantillon. Dans ton MCD, tu as fait une association ternaire donc une photo représente à la fois un gîte ET un échantillon !

Comme dit dans un précédent message, il te faut deux associations dont les cardinalités imposent en toute rigueur des tables associatives :

Une photo représente un gîte OU un échantillon donc le modèle est celui-ci :
photo -0,1----représenter----0,n- echantillon
|---------0,1----représenter----0,n- gite

La suite plus tard.

[sowane]

Merci Philippe pour cette réponse rapide.
J'ai repris le MCD et créé 2 tables associatives pour les photos avec les associations "representer1" et "representer2", l'association terniaire est donc supprimée.
Cela m'a obligé à créer 2 associations entre "intervenant" et ces 2 tables : "prendre1" et prendre2".
Je vous joins le nouveau MCD pour avoir votre avis et vous en remercie par avance.
Sowane