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