Discussion :

[scamphp]

Merci pour toutes vos réponses... je vais donc me lancer dans la modélisation de ma 1ere table (sous vos yeux d'expert).

Plutôt que de partir sur mon projet perso qui n'est pas encore totalement concret... je vais me lancer dans un exercice qui lui est concret et que tout le monde connait déjà les principes comme cela on parle de la même chose lol

Je vais donc vouloir modéliser une (ou des) tables pour faire un Dictionnaire + Synonymes.

Commençons par le plus simple le Dictionnaire

Contraintes :

* un mot qui servira pour la recherche
* un type : Verbe, adverbe, nom
* un genre sauf si c'est un verbe
* une définition


Si j'ai bien compris je vais créer un table DICTIONNAIRE
Je dois utiliser Innob pour avoir une clé étrangère
et un interclassement : utf8mb4_general_ci pour les Œ

1°) Faut-il penser à autre chose lors de la création de la Table ?

En suite je vais définir les champs

un mot qui servira pour la recherche -> le mot le plus long sera anticonstitutionnellement, je dois donc utiliser un VARCHAR(25) et non un CHAR(25) car les valeur vont fortement varier entre 1 et 25
pour les recherches VARCHAR est moins bon car il ne classe pas forcement dans l'ordre contrairement à CHAR, mais l'index corrigera cela...

2°) Pour le Nom le plus approprié est VARCHAR(25) ou pas forcement ?

Je n'ai pas besoin ID auto incrément car la recherche sera forcement sur le NOM.

3°) l'ID n'apporte rien dans le cas d'un dictionnaire ?

SqlPro disait dans un article que pour le numéro de sécurité sociale c'est mieux de créer un champ pour le sexe (1 ou 2) un champ le département, la date.... pour faciliter les recherches.

4°) Pour un dictionnaire faudrait il créer un champ pour la 1ere lettre car cela peut arriver d'afficher les mots qui commence par A, B, C...



Voila je prend le cas d'un dictionnaire car tout le monde sait se servir d'un dictionnaire et que les règles sont plus ou moins communes (utilisation). Alors que si je me base sur des recettes de cuisines chacun fait sa choucroute à sa sauce et cela complique les échanges.

Le dictionnaire me semble un bon exemple pour apprendre et échanger avec vous sur un exemple concret.

J'attends avec impatience vos 1ere remarques sur les 4ere questions avant avancer plus loin...



J’essaie de commenter au maximum mes questions en expliquant mon raisonnement (qu'il soit bon ou mauvais) car je n'attends pas une réponse du type 1+1=2, mais plutôt une explication pour apprendre et comprendre...
Parfois on arrive à la bonne réponse avec le mauvais raisonnement... l'idée c'est aussi de corriger mon raisonnement s'il n'est pas bon, c'est même plus important que la réponse lol

[CinePhil]

Quand on veut créer une base de données, il ne faut pas se lancer de but en blanc sur son SGBD favori mais commencer par modéliser la BDD. Surtout quand on débute !

Il faut commencer par rédiger des règles de gestion des données puis dessiner son Modèle Conceptuel de Données (ou diagramme de classes UML mais le MCD Merisien est plus rigoureux et reste le meilleur outil pour modéliser une BDD) à l'aide d'un logiciel de modélisation (par exemple : jMerise ou DBMain. Pour UML, vous avez BOUML).
Avec le logiciel de modélisation, on peut généralement générer le Modèle Logique de Données (MLD) et même souvent le script de génération de la base de données pour son SGBD favori (il faut quand même vérifier qu'il n'y a pas de coquilles ; certaines subtilités du passage du MCD au MLD et, par voie de conséquence, au script SQL ne sont pas toujours bien programmées dans les logiciels de modélisation).

En procédant à cet exercice indispensable, vous constaterez vite que vous aurez plusieurs tables à créer pour votre base de données Dictionnaire.

Revenez vers nous avec vos règles de gestion des données.

[escartefigue]

Bonjour,

Il ne faut pas raisonner en terme de table, mais de besoin fonctionnel, par exemple : "je souhaite modéliser un dictionnaire de français"
A partir de là, il s'agit d'identifier les objets qui entrent en jeu dans votre besoin : les mots, leur type, leur étymologie, leurs synonymes etc...

Ensuite, il faut identifier comment ces objets interagissent entre eux, c'est à dire identifier les règles de gestion, et les numéroter pour faciliter les échanges et la révision
Par exemple :
R001 : tout mot est au moins d'un type
R002 : un type possède peut concerner plusieurs mots
etc...

De cette base, vous pourrez commencer à modéliser soit un MCD (c'est conseillé au moins quand on est peu coutumier de la modélisation) soit directement au niveau MLD (pour les cas plus simples)
Un logiciel de modélisation est recommandé, ça évite de nombreuses erreurs et facilite la maintenance. Il en existe des gratuits (DB-Main, JMerise...)
Attention : MySQLWorkbench ne permet pas de réaliser des MCD

Commençons par le plus simple le Dictionnaire

Contraintes :

* un mot qui servira pour la recherche
* un type : Verbe, adverbe, nom
* un genre sauf si c'est un verbe
* une définition

Il suffit de consulter quelques dictionnaires existants pour constater que votre liste est erronée : un mot peut être de plusieurs types (ex : court est un substantif et un adjectif) et, c'est plus rare, mais aussi de plusieurs genres (ex: après-midi est à la fois masculin et féminin)
D'où l'importance de bien rédiger les règles de gestion et de bien les faire valider par les gens du métier

Si j'ai bien compris je vais créer un table DICTIONNAIRE
Je dois utiliser Innob pour avoir une clé étrangère
et un interclassement : utf8mb4_general_ci pour les Œ

Les tables seront la conséquence d'une modélisation de qualité et non un but en soi !
Quant au choix du SGBD, il dépend de considérations liées au budget, au fonctionnalités attendues, à la volumétrie estimée, au nombre d'utilisateurs connectés..., mais certainement pas à la présence de clefs étrangères que tout SGBDR prend en compte fort heureusement

En suite je vais définir les champs

Dans une table il n'y a pas de champ, il y a des attributs ou colonnes

un mot qui servira pour la recherche -> le mot le plus long sera anticonstitutionnellement, je dois donc utiliser un VARCHAR(25) et non un CHAR(25) car les valeur vont fortement varier entre 1 et 25
pour les recherches VARCHAR est moins bon car il ne classe pas forcement dans l'ordre contrairement à CHAR, mais l'index corrigera cela...

2°) Pour le Nom le plus approprié est VARCHAR(25) ou pas forcement ?

Je n'ai pas besoin ID auto incrément car la recherche sera forcement sur le NOM.

3°) l'ID n'apporte rien dans le cas d'un dictionnaire ?

Dans tous les cas, un identifiant primaire technique asémantique, stable et concis est très fortement recommandé
Les identifiants primaires entrent en jeu pour garantir l'intégrité des données, via les clef étrangères (FK). Ce sont également ces identifiants qui permettent le plus souvent de réaliser les jointures.
Il est donc très important qu'ils soient invariants sinon la mise à jour en cascade des tables filles via les FK peut prendre un temps considérable.
Or un identifiant fonctionnel est potentiellement modifiable, et donc instable.
De plus, les colonnes fonctionnelles sont le plus souvent de type char ou varchar, donc sensibles à la collation.
Enfin, pour un nombre de valeurs possibles identiques, les colonnes char ou varchar sont beaucoup plus encombrantes que les types integer utilisés pour des id techniques

SqlPro disait dans un article que pour le numéro de sécurité sociale c'est mieux de créer un champ pour le sexe (1 ou 2) un champ le département, la date.... pour faciliter les recherches.

Je ne suis pas d'accord avec cette vision des choses, si le numéro de sécurité sociale est vu comme un identifiant externe, alors il n'y a aucune raison de le découper en tranches fines, il doit être vu comme un tout et il ne faut pas en analyser les sous-parties éventuelles. Le code sexe, le département... doivent être stockés dans d'autres attributs, indépendamment du n° de sécu.
Si on suivait ce raisonnement, alors il faudrait également découper plein d'autres identifiants externes : les n° de téléphone français par exemple (2 1ers caractères = indicatif de région .)

[scamphp]

Bon on va y aller doucement

J'ai une entité TEXTE qui correspond à une et une seule DEFINITION

J'ai une entité DEFINITION qui correspond à un et un seule TEXTE

TEXTE - 1,1 - correspond - 1,1 DEFINITION


c'est une dépendance fonctionnelle
TEXTE -> DEFINITION

Ils seront donc dans la même table

En suite

J'ai une entité TEXTE qui correspond à un ou plusieurs TYPE : Verbe, adverbe, nom
J'ai une entité TYPE qui correspond à aucun, un ou plusieurs TEXTE

TEXTE - 1,n - correspond - 0,n TYPE

En suite

J'ai une entité TEXTE qui correspond à un ou plusieurs GENRE : Masculin, féminin
J'ai une entité GENRE qui correspond à aucun, un ou plusieurs TEXTE

TEXTE - 1,n - correspond - 0,n GENRE

[escartefigue]

C'est un début

Il faut définir les termes comme vous avez commencé à le faire avec les TYPES en complétant pour les GENRES.
Même si ça peut sembler évident, il est préférable de lever toute équivoque
Le cas échéant, précisez les domaines de valeurs possibles.


Il faut ensuite compléter les règles, les identifier par un numéro, et les faire valider par vos correspondants métier

Sauf s'il s'agit d'un exercice, un mot possède souvent plusieurs définitions.
Appuyez vous sur les dictionnaires existants et adaptez selon votre besoin pour éviter les impairs, la validation par les experts métier fiabilisera le tout
L'un des dictionnaires en ligne qui font référence est celui du Centre National des Ressources Textuelle et Lexicales, accessible ICI

[scamphp]

Non pas de correspondants métier, c'est un exercice pour apprendre sur un cas concret... et un dictionnaire me semble un exercice intéressant qui parle à tout le monde...

Mes correspondants métier c'est VOUS !!!

[CinePhil]

J'ai une entité TEXTE qui correspond à une et une seule DEFINITION
J'ai une entité DEFINITION qui correspond à un et un seule TEXTE

Vous allez un chouia vite : on ne parlera d'entité (ou plus correctement d'entité-type) que lors de la réalisation du MCD.

Vos deux phrases traduites en règle de gestion, ça donne ça :
R1 : Un texte est défini par une seule définition et une définition définit un seul texte.

Sauf que, comme l'a fait remarquer escartefigue, dans la vraie vie et dans tous les dictionnaires, vous constaterez vite qu'un mot (plutôt qu'un texte) peut avoir plusieurs définitions.
Donc la bonne règle est la suivante :
R1 : Un mot est défini par une à plusieurs définition et une définition définit un seul mot.

Et le MCD est alors le suivant :
DEFINITION -1,1----définir----1,n- MOT

J'ai une entité TEXTE qui correspond à un ou plusieurs TYPE : Verbe, adverbe, nom
J'ai une entité TYPE qui correspond à aucun, un ou plusieurs TEXTE

Traduction en règle de gestion :
R2 : Un mot (c'est mieux que texte qui peut comprendre plusieurs mots) est typé par un à plusieurs types et un type peut typer plusieurs mots.

MCD :
TYPE -0,n----typer----1,n- MOT

J'ai une entité TEXTE qui correspond à un ou plusieurs GENRE : Masculin, féminin
J'ai une entité GENRE qui correspond à aucun, un ou plusieurs TEXTE

Mais un verbe, par exemple, n'a pas de genre !
Traduction :
R3 : Un genre peut qualifier un mot et un mot peut être qualifié par plusieurs genres.

MCD :
GENRE -0,n----qualifier----0,n- MOT

[scamphp]

waouh c'est plus clair comme ça... c'est un très bon exemple pour comprendre

plus clair le principe de la transcription en MCD

mais après on en fait quoi, c'est quoi l'étape suivante...

Il faut donc surement 4 tables : MOT, DEFINITION, GENRE et TYPE

[escartefigue]

Après il faut commencer à schématiser tout ça sous forme de MCD

Le plus simple est d'utiliser un logiciel gratuit de modélisation tel que DBMAIN ou JMERISE.

L'avantage est que ces logiciels effectuent certains contrôles, que vous pouvez gérez des versions, et aussi et surtout qu'ils vous permettent de générer automatiquement le MLD et le MPD, script inclus (create table, create index...) en fonction du SGBD choisi. Certains logiciels permettent également de faire de la rétro-docuementation : génération des modèles à partir du script !

Pour les tables, patientez encore un peu, il faut d'abord stabiliser le MCD avant de passer au modèle tabulaire : le MLD

[scamphp]

Moi qui pensais créer rapidement ma 1ere table test, vous m'embarquez dans des trucs de fous lol



C'est SUREMENT TOUT FAUX, mais je mets l'image pour montrer que je veux apprendre, je ne suis pas la juste la pour poser une question et attendre une réponse...
Sur le forum beaucoup attendent des réponses... moi je veux apprendre

Donc c'est surement tout faux mais en tous cas je suis vos conseils et veux avancer...

[scamphp]

Bon je fais ce que je peux même si je ne comprends pas tout...

Style pour les relations il me demande de rentrer une valeur et de définir son type (char, varchar...) sinon je ne peux pas modifier les valeurs 0,1,n...

Si on m'avait dit quand j'ai ouvert mon sujet que j'allais découvrir MCD

puis installer un logiciel type Jmerise.... avant de passer au MLD

J'aurais dit que vous étiez fous lol

Bon cela fait un peu beaucoup d'un coup pour quelqu'un qui découvre

Mais je veux apprendre alors je serre les dents et aller on avance (pour info vous avez compris que je n'ai pas les bases lol)

[CinePhil]

On progresse...

Dans les entités-types du MCD, il faut mettre les propriétés de ce que représentent des entités-types.
Comme dit précédemment, les entités-types doivent avoir un identifiant (qui deviendra une colonne dans la table, de type entier et auto-incrémentée et qui constituera la clé primaire de la table).

Par exemple, dans l'entité-type GENRE, vous pourriez mettre id_genre (ou genre_id, ou gnr_id...) pour l'identifiant, un code (genre_code ou code_genre ou gnr_code...) pour l'abréviation du genre ('M' ou 'F') et un libellé (genre_libelle, libelle_genre, gnr_libelle...). Sur ce type d'entité de référence, SQLPro conseille aussi d'ajouter une propriété pour l'ordre d'affichage dans une liste mais ce n'est pas obligatoire, surtout dans le cas du genre qui ne comprend que deux valeurs.

Je vous laisse réfléchir aux propriétés des autres entités-types. En tout cas, ce ne sont pas les noms des entités-types !

Quant aux associations, elles sont rarement munies de propriétés et vous pouvez supprimer ces dernières.

[scamphp]

On avance petit à petit... mais tant que je ne serais pas arrivé au bout de l'exemple, pour voir les tenants et les aboutissants... cela reste très théorique...

[Invité]

slt,

Je vais à l'encontre des interventions qui (à juste titre?) recommandent un procédé scolaire.
Je trouve un peu usine à gaz (ca m'a jamais trop servi et même plutot le contraire).

De base je pense que quelqu'un de feignant s'attend à avoir à la fin:
une seule table
mot
genre
type
definitionS
la table est indexée sur mot (à vérifier pr les perfs)
lutilisateur saisit une lettre, les mots avec leur(s) defs sont retournées.
fini.

pas de jointure ou je sais pas quoi.

__eventuellement__
quelqu'un peut vouloir sortir definitionS parce qu'il dit: wé mais si j'ai fait une faute de frappe dans ma def?? faut que jla modifie
première chose: est-ce une demande valide
deuxième chose: qu'est-ce que j'y gagne à sortir definitionS et à rajouter (au moins) une table définition.
(personnellement, je pense que j'y gagne une calvitie)

__idem__: wé si mon genre jveux plus l'écrire "Masculin" mais je veux ecrire "masculin". faut que je modifie tous mes records als que si javais fait genreId et une table genre je modifie qu'une seule fois..

gardons les choses __simples__ tant que c'est possible

si modéliser genre en dehors de mot ne me sert à rien, pourquoi le modéliser?

[escartefigue]

@galerien69 : il ne faut pas confondre une base de données relationnelles et un tableur.
Dans une base de données relationnelles, il faut justement bien scinder les objets, les entités-type, pour supprimer les redondances et les attributs inutiles

Votre proposition d'une seule table avec pour attribut : mot, type, genre, et définitions implique les conséquences suivantes :

• L' attribut "genre" est présent à tort pour tous les mots de type verbe, adverbe, adjectif, article...
• Très peu de mots sont multi-genre, mais il en existe, donc soit vous perdez l'information pour les rares cas de multi-genre, soit vous avez un deuxième attribut inutile
• Le nombre de définitions d'un mot à l'autre va de une seule à plus de 10 (consultez le dictionnaire en ligne du CNRTL pour vous en convaincre) auquel cas, soit pour certains mots, il vous manquera plusieurs définitions, car votre table ne prévoira pas suffisamment d'occurrences de définitions, soit au contraire, tout un tas de définitions seront inutiles
  Et le jour ou pour un seul mot, il faut une définition de plus que le maximum que vous avez prévu, vous êtes contraint de modifier la BDD !
• Comme il n'y a qu'une seule entité-type, aucune intégrité référentielle ne peut être définie dans la base de données, et par voie de conséquence, rien ne garantit que pour la même information, vous n'aurez pas des valeurs différentes

Ce type de modélisation à plat, type tableur donc, pénalise les évolutions de la base de données, les performances et la fiabilité de l'ensemble.
A fuir comme la peste !

Je cite une illustration de FsmRel, piquée dans un autre sujet, et qui explique fort bien pourquoi la modélisation à plat est une très mauvaise idée :

Ça me rappelle l’histoire d’un de mes collègues qui avait prévu 7 colonnes dans ses stats réseau (une colonne par jour de la semaine) et à qui un beau jour on a demandé de passer à une colonne par jour de l’année : il a compris qu’il aurait mieux valu verticaliser tout ça. Ça me rappelle aussi un tableau au cœur d’un système d’exploitation chez IBM (années soixante), prévue pour qu’un ordinateur gère au maximum 256 périphériques (on occupait à peine 10% de la table) : manque de chance, au début des années soixante-dix, il a fallu passer à 64000 (arrivée des écrans (passifs))...

[Invité]

je pense que

Ce type de modélisation à plat, type tableur donc, pénalise les évolutions de la base de données, les performances et la fiabilité de l'ensemble.
A fuir comme la peste !

n'est pas adaptable à notre cas.

Le gus a un tableau de n elements et il cree n colonnes dans sa table. Ce n'est pas ce que je propose.
je tokenize simplement mes définitions que je stocke dans un __unique__ champs "string".

L' attribut "genre" est présent à tort pour tous les mots de type verbe, adverbe, adjectif, article...

et alors???

Très peu de mots sont multi-genre, mais il en existe, donc soit vous perdez l'information pour les rares cas de multi-genre, soit vous avez un deuxième attribut inutile

qu'il soit inutile alors!!

Le nombre de définitions d'un mot à l'autre va de une seule à plus de 10 (consultez le dictionnaire en ligne du CNRTL pour vous en convaincre) auquel cas, soit pour certains mots, il vous manquera plusieurs définitions, car votre table ne prévoira pas suffisamment d'occurrences de définitions, soit au contraire, tout un tas de définitions seront inutiles

Et le jour ou pour un seul mot, il faut une définition de plus que le maximum que vous avez prévu, vous êtes contraint de modifier la BDD !
et bien ce jour là je modifie ma bdd.

Je conçois la taille de la définition et la limite physique de la taille du champs.
J'ose espérer que les sgbd actuels peuvent supporter un record à 16Mo... ce qui contraint une definition à ...1.5Mo
Zut alors je dois modifier ma base de données!! __en attendant, j'ai bien vécu j'ai gardé mes cheveux et j'ai eu qu'une seule table à maintenir, documenter, utiliser.

Comme il n'y a qu'une seule entité-type, aucune intégrité référentielle ne peut être définie dans la base de données, et par voie de conséquence, rien ne garantit que pour la même information, vous n'aurez pas des valeurs différentes

ce dont on se contrefout puisque l'information atomique c'est mon mot.

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.

@galerien69 : il ne faut pas confondre une base de données relationnelles et un tableur.

merci pour ce rappel
je me demande si les gens me prennent de haut à cause du pseudo?

[scamphp]

Bon comme c'est pour apprendre et je trouve cet exemple intéressant... alors c'est quoi l'étape suivante

PS : les remarques (critiques) sont toujours constructives elles permettent de se poser les bonnes questions... je fais cela parce qu’on m'a dit de le faire... ou je fais cela en tout connaissance de causes.... en confrontant plusieurs points de vues

[escartefigue]

@scamphp :
Votre MCD publié dans votre réponse n° 13 est pas mal, mais j'ai quelques questions et remarques

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
La mise en oeuvre de l'identification relative dépend du logiciel de modélisation, pour DB-Main, vous pouvez suivre l'excellent tuto du non moins excellent FsmRel ICI
250 caractères est probablement un peu court dans certains cas, mais bon vu qu'il s'agit d'un exercice, va pour 250

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.
A quoi servent les attributs Ordre_genre et Ordre_type ?

[scamphp]

Ordre_genre et Ordre_type c'est pour gérer l'ordre d'affichage mais ce n'est pas obligatoire, si j'ai bien compris c'est si on souhaite gérer un ordre d'affichage autre que de a à z.... (nom, verbe, adjectif)

J'aimais bien Jmerise, mais en version gratuite je vais vite être bloqué ? Car pour convertit le MCD en MLD et génère le script sql. il faut l'activer....

Je dois donc passer sur DB-main ?

[escartefigue]

Je ne peux pas me prononcer au sujet de J-Merise que je ne connais pas (je l'ai téléchargé mais je n'arrive pas à l'activer )
DB Main est un bon produit, avec de bonnes fonctionnalités.
Son ergonomie peut paraitre déroutante au départ mais on s'y fait vite.
En plus FSMREL a publié un tutoriel DBMAIN fort utile