Discussion :

[escartefigue]

PS: je ne jette pas de la merde sur ce que tu racontes parce que c'est pas faux.
je contrebalance simplement qu'on augmente la complexité du modèle pour la o-dite "évolution" qu'on ne sait pas quand elle aura lieu (si d'ailleurs elle a lieu), ni sur quoi.

Pour faire court : s'il ne s'agissait que des maintenances de la BDD ce ne serait pas très grave, mais comme je l'ai dit plus haut, ce sont aussi les performances qui sont mises en péril et surtout l'intégrité de la BDD !
Dans un modèle de données à plat, on ne peut pas garantir l'intégrité des données. Or que vaut une base de données quand le contenu est incertain... pas grand chose !

On peut dans certains cas simplifier la BDD après l'avoir modélisée dans les règles de l'art. Ca s'appelle la dénormalisation. Mais avant de dénormaliser il avoir normalisé.

Ne vous inquiétez pas au sujet de votre pseudo, mon métier ne vaut pas mieux, cf mon profil

[Invité]

Mais avant de dénormaliser il avoir normalisé.

pour la pédagogie probablement.
sinon bon..ya qd même des paradigmes autres que la normalisation

Dans un modèle de données à plat, on ne peut pas garantir l'intégrité des données.

idem scamphp semble vouloir abstraire la reflexion et apprendre ce type de modélisation dc les schémas type #13 sont qd même un bel exercice.

maintenant pr être précis,
le modèle que je propose est plus rapide
- Une jointure aussi optimisée qu'on veut ca reste plus lent que pas de jointure.
- J'insiste sur l'atomicité du mot

présente moins de pb d'intégrité (subjectif)
pas de cascade delete, de questions de type qu'est-ce qui se passe si je supprime un mot. Vu que pof c'est fini
oui mon genre est dénormalisé
oui le type aussi

le seul pb à l'instant t=0 qui se pose est l'encodage de leS definitions en un seul champs.
avec une base nosql c'est trivial.
avec une base type postgres il y a maintenant (au moins deux ans...pbmlnt beaucoup plus) le support du json pour un champs.

Evidemment si on veut changer le modèle ben d'accord le _changement_ sera peut être plus dur.
(encore qu'honêtement je vois pas bien comment ca peut être dur de modifier/splitter une pauvre table de 50k lignes avec des records sans aucune dépendance , mais pr la pédagogie pe que ce que je propose n'est pas une bonne approche? (en tout cas ca m'aurait personnellement dégouté qu'avant d'écrire ma première table on me dise mcd, mld, bouml, ..., et que je recupe 5 tables plus tous les wrappers et les jointures induites alors que tout ce que je veux c'est (pour le coup) un bete clé valeur où ya même pas d'update qui sont prévus )

[scamphp]

oui c'est sur que pour une 1ere table j'en mange des concepts lol

L'idée serait déjà d'arriver au bout de l'exemple... et une fois que j'aurais la vision globale... je pourrais intégrer les remarques (suggestions) de galerien69.

A la base pour une 1ere table, j'étais plus sur le principe de galerien69, je ne m'attendais pas (ou pas trop) a devoir utiliser mcd, mld...

Mais maintenant j'ai le nez dedans et il faut reconnaitre que cela oblige a se poser plus de questions (après on les prends en compte ou pas, mais au moins on se pose les questions).

Je vous propose de continuer la théorie... on verra déjà si j'arrive a suivre jusqu'au bout lol

car il reste encore beaucoup de chemin et de concepts (wrappers et les jointures...) et après on pourra débattre des solutions alternatives...

[scamphp]

ha si quand même je pense qu'une modélisation (découpage) permet une évolutivité -> style si on décide d'ajouter des Synonymes (quoi que on pourrait aussi l'ajouter à un tableau plat)

[Invité]

une fois que tu as fait ton mcd,
- tu peux faire ton mld (si necessaire à la main*)
- apres on te dira mpd (où tu spécifies la "taille" et le type précis de tes champs en plus)
- puis normalisation pour toi là c'est "bon". (c'est ptet le seul truc que j'avais apprécié (l'algèbre relationnel..te servira pblmt jamais))

Il y a des outils pour générer/construire automatiquement ta base depuis ton mld/mpd mais je n'en connais plus...

- puis tu rejoindras enfin le domaine applicatif (en gros le code...)


tu as plus d'informations ici (soit dit en passant qui est un bon "rappel" https://www.developpez.net/forums/d3...-utilite-mcds/). Tu apperçois problablement la carotte.

* encore une fois, je suis d'approche itérative. Ton but c'est de comprendre/apprendre. C'est dommage de te faire stopper à cause d'un outil.
L'outil te sert à gagner du temps, mais pour un petit schéma, le crayon à papier lui est bien supérieur.

------
Je m'attendais à me faire plus downrater que ca quand j'ai participé.
forum catégorie schéma, titre avec mcd, pensées hérétiques
J'aimerais juste demander à mes chers collègues si ca leur arrive tjs de développer et surtout si ils utilisent mcd, mld, par logiciel pour tous leurs projets __perso__ ?

[escartefigue]

le modèle que je propose est plus rapide
- Une jointure aussi optimisée qu'on veut ca reste plus lent que pas de jointure.

Cette affirmation est d'autant plus fausse que la table grossit (en largeur, pas en nombre de lignes) et que le nombre d'accès concurrents augmente
Les tables dites "obèses" sont l'un des facteurs principaux de ralentissement des traitements dans un contexte fortement concurrentiel !
Prenons exemple d'une gestion de personnes, la modélisation Merise classique est la suivante
PERSONNE (id, nom, prenom....) 0,n --- posseder --- (1,1) ADRESSE(id, adr1, adr2,..., ville)
De ce mini MCD découlent 2 tables : PERSONNE et ADRESSE
Avec un modèle dénormalisé, on n'a qu'une seule table dans laquelle on aura prévu l'emplacement pour mettons 2 adresses

Si une application veut modifier la partie adresse d'une personne.
Avec un modèle normalisé et donc deux tables, le verrou posé pour modification ne gène aucunement les transactions qui souhaitent modifier la partie signalétique (nom, prénom...) et inversement.
Avec un modèle dénormalisé, ces deux traitements se gènent l'un l'autre.
Plus on dénormalise, plus ce phénomène de verrouillage devient critique.

Autre raison qui pénalise les performances : au lieu d'avoir quelques index répartis sur plusieurs tables, on a un grand nombre d'index sur une seule table, ce qui provoque des lenteurs lors des opérations de mise à jour (update, insert, delete). La maintenance des index a un coût.

De plus, si la table "obèse" comporte des colonnes de type varchar (ou nvarchar) on multiplie les risques de désorganisation de la table lors des mises à jour, là encore au détriment des performances.

présente moins de pb d'intégrité (subjectif)
pas de cascade delete, de questions de type qu'est-ce qui se passe si je supprime un mot. Vu que pof c'est fini

Pas subjectif, avéré !
L'intégrité d'une BDD ne se résume pas aux instructions ON DELETE / ON UPDATE !

le seul pb à l'instant t=0 qui se pose est l'encodage de leS definitions en un seul champs.

D'une part, les "champs" n'existent pas dans une base de données, les champs sont les attributs d'un formulaire
D'autre part, l'encodage n'a absolument aucun rapport avec le respect ou non des formes normales



Bref, vous mélangez allègrement des concepts qui sont sans rapport entre eux, en utilisant un vocabulaire approximatif et en affirmant péremptoirement des choses fausses

Je ne sais pas si chez vous, vous mettez dans la même armoire vos chaussettes, boites de conserves, médicaments et outils de jardin, mais c'est à peu près ce que vous proposez en terme de modélisation de base de données...

[Invité]

Cette affirmation est d'autant plus fausse que la table grossit (en largeur, pas en nombre de lignes) et que le nombre d'accès concurrents augmente

il va falloir m'expliquer le succes des base nosql alors.

La maintenance des index a un coût.

oui une modélisation trop complexe aussi.

D'une part, les "champs" n'existent pas dans une base de données, les champs sont les attributs d'un formulaire

merci pour cette remarque. Quel est donc le vocabulaire adéquat?

D'autre part, l'encodage n'a absolument aucun rapport avec le respect ou non des formes normales

je vois pas pourquoi souligner ce fait, ai-je lié ma forme normale ou pas avec l'encodage de mon xxx

c'est à peu près ce que vous proposez en terme de modélisation de base de données...

merci encore une fois pour cette remarque bien construite.

Je sais que chez moi j'aime être simple quand c'est possible car c'est bien une aubaine.

Quant aux pb de performances allons donc.
On parle d'un dictionnaire (!!!).
Est-il question d'en faire un wikipedia?

[CinePhil]

Je m'attendais à me faire plus downrater que ca quand j'ai participé.
forum catégorie schéma, titre avec mcd, pensées hérétiques

Je ne m'en suis pas privé... mais je n'a qu'une voix !

J'aimerais juste demander à mes chers collègues si ca leur arrive tjs de développer

Oui, je développe et je considère que le meilleur outil de modélisation d'une base de données reste le MCD.
Il est vrai que l'appli que je développe actuellement au boulot utilisant une BDD MySQL/MariaDB, je suis passé directement au "Entity/Relationship Diagram" de MySQL Workbench mais j'ai quand même fait quelques morceaux de MCD sur papier pour avoir les idées claires sur certaines parties délicates.

Je ne compte plus les applications ayant une base de données pourrie qui nuit aux performances (CMS divers, Moodle, Jira, GLPI...).

Un exemple que je cite de temps à autre...
Il y a 10 ans, j'ai travaillé à l'INRA sur une application et je me suis vite aperçu que la BDD avait été développée au fur et à mesure des besoins, sans conception sérieuse préalable.
Lorsqu'on lançait une étude statistique à l'aide de cette application, celle-ci affichait un beau "Traitement en cours, veuillez patienter"... pendant parfois plus d'une minute.
Après ma reconception de la BDD et correction des programmes en fonction du nouveau modèle, le même traitement prenait moins de 2 secondes.
Ce qui causait la lenteur était l'enregistrement en base de données dans une colonne VARCHAR de tous les paramètres du traitement, y compris cosmétiques. En organisant mieux les données, j'avais supprimé ce délai inutile ; le temps d'exécution restant était celui réellement dû au traitement statistique des données.

et surtout si ils utilisent mcd, mld, par logiciel pour tous leurs projets __perso__ ?

Je développe également un projet perso et j'utilise JMerise pour la modélisation des données. J'ai généré avec JMerise le MLD puis le script SQL que j'ai vérifié et corrigé avant de le donner à manger à PostgreSQL.
En développant, j'ai toujours JMerise ouvert sur mon MCD pour savoir quoi utiliser dans la BDD.
Autant je peux facilement lire un MCD et en déduire facilement l'architecture des tables, autant je n'ai jamais aimé le MLD que je trouve moins parlant. Je préfère alors le "Entity/Relationship Diagram" de MySQL Workbench... mais il ne fonctionne qu'avec MySQL/MariaDB.
Quant au diagramme de classes UML, je le trouve trop permissif. On peut faire n'importe quoi, notamment parce qu'on ne voit pas la différence entre une classe représentant une entité-type et une classe représentant une association-type.

Je milite pour un développement qui commence par la modélisation rigoureuse des données. Ce n'est pas l'application qui dicte le modèle de données. Elle ne fait que l'utiliser.

[escartefigue]

Quant aux pb de performances allons donc.
On parle d'un dictionnaire (!!!).
Est-il question d'en faire un wikipedia?

On parle d'un dictionnaire, mais aussi d'un exercice.
Il s'agit donc d'apprentissage. En ce cas, il faut veiller à donner les bon conseils, même si ça peut paraitre luxueux dans le cas présent, car ce sera la base nécessaire dans les cas plus riches et moins scolaires.

[CinePhil]

il va falloir m'expliquer le succes des base nosql alors.

Pour autant que je sache (je n'ai pas étudié ça en détail), les bases noSQL n'ont rien à voir avec les bases de données relationnelles. Elles sont basées sur une technique clé => valeur. Elles n'ont pas d'intégrité. Elles sont plutôt faites pour des données qui n'ont pas vraiment besoin d'intégrité et qui sont peu ou pas soumises à modifications.
Ça m'étonnerait beaucoup qu'une entreprise un tant soit peu importante gère les données comptables ou RH avec une base noSQL !
Par contre, la gestion des archives comptables et RH (telle boîte d'archive contient les bulletins de salaire des salariés de A à L pour l'année 2017, elle est rangée à l'emplacement 12 de l'étagère 3 du rayon 5), pourquoi pas ! C'est stable et on ne l'utilise pas tous les jours.

La maintenance des index a un coût.

oui une modélisation trop complexe aussi.

Un promeneur, voyant un bûcheron suer comme une éponge à scier un tronc d'arbre sans grande efficacité, s'approche et lui dit : "Peut-être faudrait-il que vous affutiez votre scie ?" Le bûcheron répond, en continuant de souffrir à scier avec sa scie usée : "Pas le temps ; faut que je scie !"

D'une part, les "champs" n'existent pas dans une base de données, les champs sont les attributs d'un formulaire

merci pour cette remarque. Quel est donc le vocabulaire adéquat?

La tables des bases de données relationnelles sont composées de colonnes et de lignes ; pas de champs ni d'enregistrements.

Quant aux pb de performances allons donc.
On parle d'un dictionnaire (!!!).
Est-il question d'en faire un wikipedia?

Alors pour être clair, faisons l'historique qui a conduit à cette discussion...

scamphp a posé plusieurs questions relatives aux bases de données dans le forum MySQL.
Il a notamment créé une discussion dont le titre était (de mémoire) "Création de ma première table" et qui constituait le premier message de la présente discussion qui a été déplacée dans le forum Schéma puisqu'on y parlait de conception de données.
Il est débutant en matière de base de données et souhaite apprendre.
Pour qu'il ne prenne pas d'emblée de mauvaises habitudes, et comme il a toujours été ouvert et réceptif à nos remarques sur ce qu'il voulait faire, d'instinct, nous avons préféré lui détailler les étapes de conception d'une base de données relationnelle.
Sa modélisation d'un dictionnaire est pour lui un exercice d'apprentissage de réalisation d'une base de données. Il pensait au départ faire ça dans une seule table et nous lui avons expliqué en quoi c'est une mauvaise idée, toujours dans le paradigme général de conception d'une base de données relationnelle puisqu'il voulait s'initier à MySQL. Je n'aurais pour ma part pas choisi cet exemple mais c'est son choix alors on s'adapte.

Donc merci de ne pas venir détruire nos efforts de pédagogie par vos remarques non pertinentes.

[scamphp]

hé les gars ne vous tapez dessus lol

Une fois le modèle créé, on fait quoi

Car je suppose que des relations cardinales différentes ont des conséquences et problématiques différentes...

On a pas fait tout cela pour rien lol ça doit bien servir à en déduire quelque chose

[CinePhil]

Une fois le modèle créé, on fait quoi

Où en étions-nous ?

Le MCD me semblait pas mal, même si escartefigue avait fait quelques remarques complémentaires.
Si j'ai bien compris, tu ne peux pas générer le MLD avec JMerise parce que tu n'as pas activé le logiciel ? C'est dommage que la dernière version de JMerise ne soit plus totalement gratuite mais c'est le choix de l'ami RabDev (contributeur de Developpez.net) qu'on a beaucoup aidé, avec fsmrel, à améliorer son logiciel et qui a fait un sacré bon boulot depuis ses premiers contacts avec nous. C'est son choix et, après tout, il faut bien qu'il vive !

Si cet exercice te plait, tu peux refaire ton MCD sur DBMain et là, tu pourras générer le MLD puis le script SQL de création de la BDD.

Car je suppose que des relations cardinales différentes ont des conséquences et problématiques différentes...

Employons les bons termes !
Une relation vient de l'algèbre relationnelle, si chère à fsmrel et qu'on pratique, comme Monsieur Jourdain, généralement sans le savoir quand on conçoit et développe des bases de données.
Dans un MCD, on parle d'entité-type et d'association-type. On a déjà expliqué de quoi il s'agit.
Une association-type est munie de cardinalités qui décrivent combien de fois les entité-types interviennent dans l'association-type.
=> Les "relations cardinales", ça n'existe pas, sauf si un cadre de l'église catholique a des copains, des copines, et plus si affinités !

On a pas fait tout cela pour rien lol ça doit bien servir à en déduire quelque chose

Alors concrètement, à partir du MCD de ton message #13, la génération du MLD va entraîner :
- la reproduction à l'identique sur le plan schématique des entité-types MOT, TYPE et GENRE en tables ;
- la reproduction quasi à l'identique sur le plan schématique de l'entité-type DEFINITION, avec cependant l'ajout d'une clé étrangère référençant le MOT ;
- le remplacement de l'association-type Définir par une flèche ;
- le remplacement des associations-types Qualifier et Typer par des tables associatives qui contiendront les colonnes référençant les entité-types participant à l'association-type.

Ceci devrait donner l'ensemble de tables ci-dessous :
GENRE (ID_genre, Code_genre, Nom_genre, Ordre_genre)
TYPE (ID_type, Code_type, Nom_type, Ordre_type)
MOT (ID_mot, Mot)
DEFINITION (ID_def, ID_mot, Definition)
Qualifier (ID_mot, ID_genre)
Typer (ID_mot, ID_type)

=> Clés primaires soulignées et clés étrangères en italique.
=> La liste ci-dessus ne tient pas compte des remarques d'escartefique dans son message #18

[Invité]

Donc merci de ne pas venir détruire nos efforts de pédagogie par vos remarques non pertinentes.

je Vous trouve un peu présomptueux de définir ce qui est pertinent ou pas.

quant à l'allégorie du bucheron, elle fonctionne evidemment dans les deux sens.

Un bucheron coupe sa buche et transpire avec sa hache.
Un passant lui propose alors de construire une scierie pour scier sa buche.

scamphp a posé plusieurs questions relatives aux bases de données dans le forum MySQL.

historique dont je n'avais pas connaissance. Je vous laisse sereinement continuer à le former je ne suis pas là pour avoir raison mais simplement proposer une ouverture d'esprit

[escartefigue]

=> Les "relations cardinales", ça n'existe pas, sauf si un cadre de l'église catholique a des copains, des copines, et plus si affinités !

[rabDev]

Bonjour à toutes et à tous,

Une petite précision :

CinePhil
de Si j'ai bien compris, tu ne peux pas générer le MLD avec JMerise parce que tu n'as pas activé le logiciel ? ....

Tu peux largement générer le MLD et le Script SQL pour ce MCD de la discussion. certes si vous avez un MCD avec plus de 15 tables et un script sql dépassant 200 lignes... dans ce cas, il faut activer JMerise.

Bonne journée à toutes et à tous.

[scamphp]

Aller j'avance...

Dans le MCD


Dans les OPTIONS pour les ID -> il y a 3 contraintes : INDENTIFIANT, INDENTIFIANT ALTERNATIF et INDEX

J'ai ajouté INDENTIFIANT pour les ID



Mais je pense qu'un petit commentaire explication sur les 3 types d'options s'impose

Ce qui me donne



et la c'est le drame lol

dans le MLD j'ai



J'ai des clés ID_mot_typer et ID_mot_typer_1

Je ne sais pas d'ou cela sort

[CinePhil]

Sans avoir ouvert JMerise...

Identifiant : tu as compris ; la colonne marquée identifiant participe à la clé primaire de la future table.
Identifiant alternatif : je suppose qu'il s'agit d'une clé alternative donc la colonne marquée comme identifiant alternatif participe à un groupe de colonnes (ou bien elle toute seule) qui feront l'objet d'une contrainte d'unicité (généralement, un index de type UNIQUE).
Index : la future colonne sera indexée, potentiellement avec d'autres colonnes participant au même index.

Exemple avec ma table GENRE (ID_genre, Code_genre, Nom_genre, Ordre_genre) du message #32 :
Identifiant : ID_Genre
Identifiant alternatif : Code_genre
2 Index : Nom_genre et Ordre_genre

Ensuite, il y a effectivement un problème dans le MLD pour la table Typer ! N'aurais-tu pas fait quelques manipulations hasardeuses qui auraient entraîné ça ? Je laisse RabDev répondre ; c'est son logiciel.

[scamphp]

Avant d'aller plus loin ou plutôt la synthèse de tout ce que vous m'avez expliqué

je me lance dans une petit adaptation, pour voir si j'ai bien compris les bases.

L'idée étant d'avoir une traduction des mots en anglais + des Synonymes en français




en attendant la réponse de RabDev (sur mon petit problème ID supplémentaires....).
Chaque fois qu'il y a indiqué plusieurs liens en rouge cela génère des ID supplémentaires -> cela le fait aussi pour Correspondre il génère en plus ID_synonyme_correspondre
il n'aime pas les relation MCD 1,n --- xxx --- 0,n

[rabDev]

Bonjour ou Bonsoir à toutes et à tous,

cette remarque est abordée dans la discussion (ici)

Quand la mention Plusieurs liens apparait (en rouge) dans JMerise, ça veut dire que vous avez créé au moins deux liens reliant une entité type avec une relation type
voir l'exemple de la figure ci-dessous :


je vous laisse le soins de transformer ce MCD et de le comparer avec ce que JMerise génère.

Si vous voulez laisser qu'un seul lien alors il faut supprimer un. cliquez sur ce lien (sélectionnez ) et appuyez sur la touche suppr de votre clavier.

Bonne journée ou soirée à toutes et à tous

[escartefigue]

Bonjour Scamphp,

Vous n'avez pas tenu compte de la remarque

Entité-type DEFINITION :
La définition d'un mot est ce que l'on appelle une entité-type faible : la définition n'a pas d'existence en l'absence du mot
Du coup, vous pouvez utiliser l'identification relative qui consiste à identifier la définition par le couple, dans cet ordre, ID_mot + ID_def
Cette méthode présente des avantages en termes de performances [...]

Ni de la remarque

Entités-type GENRE et TYPE :
Un code est généralement de type char, par exemple, "M" pour le genre masculin, "Adj" pour le type adjectif...
Le libelle (plutôt que le nom) doit par contre être beaucoup plus long que 5.

Par ailleurs, un synonyme est bien sur un mot !
Il faut donc définir une relation reflexive entre un mot et un autre pour définir un synonyme et non pas créer une entité-type "synonyme" qui serait une redondance
Cette relation pourra être porteuse d'attributs pour typer le synonyme et sa proximité
Je vous recommande la consultation du dictionnaire de synonymes du CRISCO à titre d'exemple ICI