Discussion :

[CinePhil]

Qu'est-ce qu'un synonyme ?
=> un MOT qui a une définition voisine de celle d'un autre MOT.
La synonymie est donc une association de MOT à MOT et non pas une entité-type SYNONYME.

Pour la traduction, plutôt que de faire aujourd'hui une entité-type (donc une future table) pour l'anglais puis plus tard une autre pour l'espagnol, puis pour l'allemand, le russe, le chinois..., il vaut mieux faire toute de suite une association traduire entre MOT et une nouvelle entité-type LANGUE.

Je vous laisse réfléchir à ça.

[escartefigue]

Qu'est-ce qu'un synonyme ?
=> un MOT qui a une définition voisine de celle d'un autre MOT.
La synonymie est donc une association de MOT à MOT et non pas une entité-type SYNONYME.

Oui j'ai proposé page précédente

[...]
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

Il est intéressant de noter sur le site du CRISCO la notion de proximité des synonymes entre eux (visible également sous forme de nuage de points sous réserve d'avoir installé java)

Pour la traduction, plutôt que de faire aujourd'hui une entité-type (donc une future table) pour l'anglais puis plus tard une autre pour l'espagnol, puis pour l'allemand, le russe, le chinois..., il vaut mieux faire toute de suite une association traduire entre MOT et une nouvelle entité-type LANGUE.

Effectivement, c'est sans doute un peu prématuré à ce stade, mais la notion de traduction doit probablement être généralisée en faisant intervenir une ET langue
Un mot peut bien sur avoir plusieurs traductions dans une même langue et une langue traduire plusieurs mots, la plupart des dictionnaires de traduction illustrent par l'exemple des cas d'utilisation.
Ce qui enrichit et complexifie encore un peu le sujet

[CinePhil]

J'avais répondu à partir de mon écran d'hier et je n'avais pas vu ta réponse.

[escartefigue]

J'avais répondu à partir de mon écran d'hier et je n'avais pas vu ta réponse.

Pas de souci, ça aurait été plus embêtant si nous avions exprimé des avis contradictoires

[scamphp]

Modèle Conceptuel de Données (MCD)

Un modèle conceptuel de données (MCD) est la représentation la plus abstraite des données d'un système d'information.
Dans un MCD, on parle d'entité-type et d'association-type
Les données sont représentées sous forme d'entités et d'associations entre entité.
• Une entité est ensemble d'éléments de même nature.
• Une association est un ensemble de liens de même nature entre élément d'ensembles.

Un modèle conceptuel de données est la retranscription des règles de gestion ou métier en spécifications formelles : un type d'attribut, une cardinalité, une contrainte...
Une association-type est munie de cardinalités qui décrivent combien de fois les entité-types interviennent dans l'association-type.
• Cardinalités : modélisation des participations mini et maxi d'une entité à une relation

Il ne faut pas raisonner en termes de table, mais de besoin fonctionnel, par exemple :
• "je souhaite modéliser un dictionnaire en Français"

Il faut d'identifier les objets qui entrent en jeu dans votre besoin :
• les mots,
• leur type,
• leur étymologie,
• leurs synonymes etc...

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

Type de Cardinalité des règles :
• 0,1 : aucun ou un
• 1,1 : un et seulement un
• 0,n : aucun, un ou plusieurs
• 1,n : un ou plusieurs

Modéliser un MCD, car les tables seront la conséquence de cette modélisation (Dans une table il n'y a pas de champ, il y a des attributs ou colonnes).

Les entités-types
Les entités-types doivent avoir un identifiant (auto-incrémentée et qui constituera la clé primaire de la table).
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.

Dans Jmerise :
• Identifiant : clé primaire de la future table.
• Identifiant alternatif : feront l'objet d'une contrainte d'unicité (généralement, un index de type UNIQUE).
• Index : la ou les futures colonnes seront indexées

Les entités-types faible -> identification relative
Si une entité n'a pas d'existence en l'absence d’une autre entité, on dit qu’elle est une entité faible.
Dans ce cas on utiliser l'identification relative qui consiste à identifier l’entité faible par le couple, dans cet ordre, ID_ENTITE + ID_ENTITE_FAIBLE
Cette méthode présente des avantages en termes de performances

Les relations réflexives
Une association d’une ENTITE à une ENTITE INDENTIQUE (BOUCLE) est une relation réflexive.


Voici une petite Synthèse des sujets abordés.

[scamphp]

Maintenant que nous avons balayé l'ensemble MCD -> MLD -> script SQL

Cela me permet d'avoir une vision globale

Même si je ne maitrise pas l'ensemble, le fait d'avoir une vision d'ensemble permet de mieux comprendre l’intérêt de l’exercice.

Je vais laisser décanter un peu...

Avant de reprendre l'exercice dans son ensemble.

Je voulais vous remercier car quand j'ai posté mon 1er Post je ne pensais vraiment pas en arriver là.

Je pensais faire directement une table (mono-table), en réalité quand j'ai écrit mon Post, j'ai indiqué MODELISATION. C'était une erreur de langage, ou un abus de langage... je pensais juste réfléchir sur des truc basique pour créer une table style j'indexe quoi, il faut mieux CHAR ou VARCHAR...

Cette erreur de langage m'a permit d'aller beaucoup plus loin que ce que j'imaginais.

Et grâce à vous j'ai découvert la modélisation, qui avec un peu de recul me semble tout simplement indispensable.

Lors de mon 1er post la réponse :

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

??? mais de quoi il me parle lol ???

Avec un peu d'effort, j'ai appris (disons découvert) pleins de trucs...

Mais bon c'est pas encore gagné car encore un peu flou et abstrait, mais on avance

[escartefigue]

C'est une bonne idée de faire un résumé, à titre didactique

Je rectifie juste quelques points de détail ci dessous

Modèle Conceptuel de Données (MCD)
Les entités-types doivent avoir un identifiant (auto-incrémentée et qui constituera la clé primaire de la table).

L'identifiant auto-incrémenté n'est pas une obligation
Ce qui compte c'est que l'identifiant primaire soit stable et concis.
Typiquement, mais pas obligatoirement, il s'agit d'un identifiant technique, attribué par le SGBD et dénué de signification pour en garantir la stabilité.
Il est en général de type integer (small, medium ou big selon la population estimée à terme), car c'est le type le plus optimal pour un grand nombre de valeurs possibles avec un encombrement le plus limité possible.
"Auto-incrément" est restrictif, certains SGBD proposent aussi du décrément

Les relations réflexives
Une association d’une ENTITE à une ENTITE INDENTIQUE (BOUCLE) est une relation réflexive.

Au niveau conceptuel, on ne parle pas d'entité, mais d'entité-type ou type d'entité
Une relation reflexive n'est pas une relation d'une entité-type avec une entité-type identique, mais avec elle même

La notion de boucle est plutôt du ressort du traitement
Je dirai donc plutôt qu'une association ou relation réflexive est une relation d'une entité-type avec elle même
Le cas d'école est la hiérarchie dans une entreprise : lien de l'entité-type employé avec elle même, dans un sens, la relation identifie les collaborateurs, dans l'autre, elle identifie le responsable.

[escartefigue]

Mais bon c'est pas encore gagné car encore un peu flou et abstrait, mais on avance

En tout cas vous êtes curieux et persévérant, deux qualités indispensable pour progresser, vous êtes sans aucun doute sur la bonne voie

[scamphp]

Et on recommence

J'ai donc une Entité-Type MOT et une Entité-Type DEFINITION

L'entité type MOT regroupe les éléments
ID_mot : identifiant
mot : le mot


L'entité type DEFINITION regroupe les éléments
ID_mot : identifiant
definition : une définition

Choix de l'identifiant ID_mot (stable et concis) un mot n'a pas d'identifiant technique connu -> on laisse faire la BD -> nb de mot langue francaise 35'000 -> type SMALLINT (unsigned) 65.535 soit le double.
Choix de l'identifiant ID_definition (stable et concis) -> on laisse faire la BD -> un mot peut avoir en moyenne 5 définitions = 35'000 x 5 = 175 000 -> type MEDIUMINT (unsigned) 16.777.215 soit 100 x plus.

Mot -> VARCHAR (25) mot le plus long anticonstitutionnellement
Définition -> TEXT soit 65 536 caractères


RELATIONS

un mot est défini une à plusieurs définitions
une définition définit 1 et 1 seul MOT

Relation MCD

MOT -- 1,n -- définir -- 1,1 --DEFINITION

et je donne un nom à ma règle R01



Et comme DEFINITION est une Entité-Type Faible

Il sera plus efficace d'utiliser l'identification relative ID_mot + ID_definition


1°) Je reprend le raisonnement pour vérifier que je raisonnement est bon ?

après j'ai des petites questions complémentaires

2°) Concernant l'identifiant si j'avais une ville je pourrais prendre le code INSEE, si j'avais un livre je pourrais prendre le code ISBN
Mais là je laisse faire la bd avec un Auto-incrément, mais du coup est ce que je peux définir SMALLINT (unsigned) et MEDIUMINT (unsigned) car jmerise ne permet pas le choix Auto-incrément de type SMALLINT, c'est soit Auto-incrément soit SMALLINT



3°) Existe t il ne méthode pour transformer un MOT en Code Numérique Unique (une sorte de ISBN) pour avoir un identifiant (stable et concis) -> style conversion du mot en hexadécimal ou binaire pour avoir un identifiant numéraire unique ou cela n'a aucun sens (on dit que le classement avec des chiffres est plus rapide).

Quand je dis conversion en binaire je comprend bien que cela allonge la logeur ce qui n'est pas top 100110101010101001011010001000011001100101000 mais on doit pouvoir le compresser du style 95354

4°) Pour les définition faut il mieux TEXT ou VARCHAR (on dit toujours VARCHAR c'est mieux que CHAR), mais pour des définitions faut-il rester sur VARCHAR ou TEXT

5°) A quoi ça sert de nommer ses règles MDC -> R01, R02... puisque elle sont explicitées dans le MDC

6°) TEST identification relative

Script sans identification relative

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
CREATE TABLE DEFINITION(
        ID_def     Int  Auto_increment  NOT NULL ,
        Definition Text NOT NULL ,
        ID_mot     Int NOT NULL
	,CONSTRAINT DEFINITION_PK PRIMARY KEY (ID_def)

	,CONSTRAINT DEFINITION_MOT_FK FOREIGN KEY (ID_mot) REFERENCES MOT(ID_mot)
)ENGINE=InnoDB;

Script avec identification relative

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
CREATE TABLE DEFINITION(
        ID_mot     Int NOT NULL ,
        ID_def     Int NOT NULL ,
        Definition Text NOT NULL
	,CONSTRAINT DEFINITION_PK PRIMARY KEY (ID_mot,ID_def)

	,CONSTRAINT DEFINITION_MOT_FK FOREIGN KEY (ID_mot) REFERENCES MOT(ID_mot)
)ENGINE=InnoDB;

[escartefigue]

Quelques remarques rapidement

Et on recommence

J'ai donc une Entité-Type MOT et une Entité-Type DEFINITION

L'entité type MOT regroupe les éléments
ID_mot : identifiant
mot : le mot

L'entité type DEFINITION regroupe les éléments
ID_mot : identifiant
definition : une définition

Stricto-sensu, l'ET "définition" n'a pas pour identifiant Id_mot, mais seulement ID_definition, par contre, si vous optez pour l'identification relative, la table issue de l'ET "definition" possède pour identifiant id_mot + id_definition

Choix de l'identifiant ID_mot (stable et concis) un mot n'a pas d'identifiant technique connu -> on laisse faire la BD -> nb de mot langue francaise 35'000 -> type SMALLINT (unsigned) 65.535 soit le double.
Choix de l'identifiant ID_definition (stable et concis) -> on laisse faire la BD -> un mot peut avoir en moyenne 5 définitions = 35'000 x 5 = 175 000 -> type MEDIUMINT (unsigned) 16.777.215 soit 100 x plus.

Là aussi, si vous choisissez l'identification relative, et c'est opportun de le faire dans ce cas, vous n'avez besoin que d'un type SMALLINT pour identifier la définition
En effet, cet identifiant viendra en complément de l'identifiant du mot, vous n'aurez donc besoin que tout au plus une dizaine de définitions pour un même mot.
Avec l'identification relative, l'id_definition seul n'est pas unique, c'est le couple id_mot+id_definition qui est unique

2°) Concernant l'identifiant si j'avais une ville je pourrais prendre le code INSEE, si j'avais un livre je pourrais prendre le code ISBN
Mais là je laisse faire la bd avec un Auto-incrément, mais du coup est ce que je peux définir SMALLINT (unsigned) et MEDIUMINT (unsigned) car jmerise ne permet pas le choix Auto-incrément de type SMALLINT, c'est soit Auto-incrément soit SMALLINT

Effectivement, le code INSEE et le code ISBN étant des nomenclatures externes, il serait très dangereux de les utiliser comme identifiants primaires
Vous pouvez bien sur les utiliser comme identifiants alternatifs.
Je n'ai pas réussi à activer JMerise, du coup je ne saurais répondre sur ce point.
Quoi qu'il en soit, vous pouvez choisir l'un ou l'autre type et vérifier ce qu'il en est précisément dans le script (CREATE TABLE...) après avoir généré le MPD.
Le script est rarement à utiliser tel quel, le plus souvent il y a des ajustements à faire.

3°) Existe t il ne méthode pour transformer un MOT en Code Numérique Unique (une sorte de ISBN) pour avoir un identifiant (stable et concis) -> style conversion du mot en hexadécimal ou binaire pour avoir un identifiant numéraire unique ou cela n'a aucun sens (on dit que le classement avec des chiffres est plus rapide).

Oui, mais inutile de se compliquer la vie, un identifiant technique étant dénué de signification, autant laisser le SGBD se préoccuper de sa valeur.

4°) Pour les définition faut il mieux TEXT ou VARCHAR (on dit toujours VARCHAR c'est mieux que CHAR), mais pour des définitions faut-il rester sur VARCHAR ou TEXT

La réponse dépend notamment du choix du SGBD et de la taille médiane d'une définition

5°) A quoi ça sert de nommer ses règles MDC -> R01, R02... puisque elle sont explicitées dans le MDC

Par ce que c'est plus simple de manipuler des identifiants que des textes dans leur complétude.
Par exemple si votre MOA - dont le rôle est notamment de relire et valider les règles de gestion - mentionne "je valide les règles R01 à R20, sauf les règles R08 et R15" c'est quand même bigrement plus simple que de citer le texte de toutes ces règles une par une.

[scamphp]

3°) Existe t il ne méthode pour transformer un MOT en Code Numérique Unique (une sorte de ISBN) pour avoir un identifiant (stable et concis) -> style conversion du mot en hexadécimal ou binaire pour avoir un identifiant numéraire unique ou cela n'a aucun sens (on dit que le classement avec des chiffres est plus rapide).

Oui, mais inutile de se compliquer la vie, un identifiant technique étant dénué de signification, autant laisser le SGBD se préoccuper de sa valeur.

Comme la recherche va porter sur le mot, je me disais que dans le script PHP je pouvez transformer le mot en code
et faire ma recherche sur le code plutôt que le mot

se qui serait plus rapide que de chercher (indexer) du texte

après la question est ????

est il plus rapide de transformer le mot en nombre en PHP -> recherche mysql sur un nombre

ou si la recherche directe sur un mot est plus rapide lol

On dit que c'est plus rapide de cherche un nombre avec mysql.... mais peut être que c'est plus long de transformer un mot en nombre avec php je ne sais pas c'est une piste....

[CinePhil]

Sauf dans le cas de l'anonimisation ou le chiffrage des données pour raison de confidentialité, il vaut mieux laisser les informations textuelles en texte (sauf le mot de passe de l'utilisateur, évidemment !).
Imaginons que vous créiez une belle base de données avec les mots transformés en nombre par l'application qui les enregistre. Demain, vous souhaitez développer une autre application qui va utiliser votre première base chiffrée. Il faudra aussi prévoir le chiffrage avec la même méthode dans la nouvelle application.
Autre gros désavantage du chiffrage : l'impossibilité de faire des tris ou des recherches LIKE 'tex%'.
Et vous pouvez avoir un besoin ponctuel d'extraire des données hors application. Là encore, si le chiffrage est fait dans l'application, il faut transcrire le code dans une fonction SQL. Et si c'est votre patron qui vous demande cette extraction de données en urgence pour avant-hier sans faute...

=> Ne vous embêtez pas avec d'hypothétiques problèmes de performance. Une BDD bien modélisée et bien indexée sera bien plus rapide à traiter les données qu'un programme applicatif. Un SGBD est fait pour ça et travaille de manière ensembliste. Il vous faudra plusieurs millions de lignes dans les tables pour que vous commenciez à voir les performances se dégrader.

[escartefigue]

J'abonde dans le sens des propos de Cinephil, et ce d'autant plus que

• Un dictionnaire ne contient pas d'informations confidentielles, c'est même plutôt le contraire, son but est en général de faire partager la connaissance au plus grand nombre
• Un dictionnaire ne risque pas d'atteindre des volumes significatifs d'informations à traiter, je doute que la plus grosse de vos tables atteigne le million de lignes, ce qui est très peu pour une BDD
• MySQL, puisqu'il semble que ce soit votre choix de SGBD, n'est pas le mieux armé en termes de cryptage d'après ce que j'ai pu lire. Je n'ai toutefois pas d'expérience personnelle en la matière.

A ce propos, si vous choisissez MySQL, installez la V8, les versions antérieures sont bien trop limitées en fonctionnalités (pas de CTE et donc pas de requêtes récursives, pas de fonction OLAP, pas de jointure FULL OUTER etc...)

[scamphp]

je vais donc avoir

ET : MOT
ID_mot : Auto_increment SMALLINT (unsigned) NOT NULL
mot : VARCHAR(25)


ET : DEFINITION
ID_mot : SMALLINT (unsigned) NOT NULL il n'est pas auto-incrément car il est une copie du ID_mot de la table MOT (et ne peut pas être null).
ID_def : Auto_incremen SMALLINT (unsigned) NOT NULL
definition : VARCHAR(250) on va dire que c'est un dico pour enfant il peut être null car on peut saisir la définition plus tard

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
TABLE MOT

ID_mot : 1
mot : local

ID_mot : 2
mot : salle


ID_mot : 3
mot : commerce

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
TABLE DEFINITION

ID_mot : 1
ID_def : 1
definition : Pièce, partie d'un bâtiment à destination déterminée.

ID_mot : 1
ID_def : 2
definition :  Qui concerne un lieu, une région, lui est particulier.

ID_mot : 1
ID_def : 3
definition :  Qui n'affecte qu'une partie du corps.


ID_mot : 2
ID_def : 4
definition : Salle à manger pour prendre les repas.

ID_mot : 2
ID_def : 5
definition : Salle de bains pour le bain et la toilette.


ID_mot : 3
ID_def : 6
definition : Commerce électronique, en ligne (sur Internet).

ID_mot : 3
ID_def : 7
definition : Un commerce magasin de détail.

J'attends vous dernières remarques avant de compléter avec type et genre...

[CinePhil]

Vite fait...

definition : VARCHAR(250) on va dire que c'est un dico pour enfant il peut être null car on peut saisir la définition plus tard

1) Le bonhomme NULL est à virer des tables !

2) À quoi sert de créer une ligne dans la table si on n'y écrit pas une définition ?

=> NOT NULL

[scamphp]

avec NOT NULL, si je veux modifier une définition (fausse ou mauvaise) mais que je n'ai pas le temps de suite, je ne peux pas l'effacer (mettre un NULL) pour la récrire plus trad...

Bon j'ai compris vous allez me dire que si je veux supprimer ma déf, il faut que j'efface mon enregistrement (la ligne) pour en récréer une plus tard....

Par contre virer NULL de la table je ne comprends pas... enfin si peut être que vous voulez dire que je ne doit pas avoir de NULL car si j'ai un NULL c'est que je n'aurais pas du créer la ligne...

On ne se sert pas de NULL c'est soit on créé et on enregistre une info, soit on efface, mais si on efface on n'efface pas que l'info, mais la ligne complète....

J'utilise Mysql pour des questions d’hébergement avec le moteur InnoDB;

[CinePhil]

À propos du Bonhomme Null, voir dans la bible de fsmrel sur la normalisation des données :
https://fsmrel.developpez.com/basesr...ion/?page=7#LD

[scamphp]

Et on continu... J'ai juste ajouté un INDEX sur la colonne MOT

ET : MOT
ID_mot : Auto_increment / SMALLINT (unsigned) / NOT NULL
mot : VARCHAR(25) / NOT NULL / INDEX


ET : DEFINITION

ID_mot : SMALLINT (unsigned) / NOT NULL -> il n'est pas auto-incrément car c'est une copie du ID_mot de la table MOT -> EN RÉALITÉ ELLE N'EST PAS AFFICHÉE DANS JMERISE c'est la RELATION DE TYPE <1,1> (relation faible) qui GÉNÉRERA ID_mot dans le SCRIPT SQL

ID_def : Auto_incremen SMALLINT (unsigned) / NOT NULL
definition : VARCHAR(250) / NOT NULL


Maintenant j'ajoute ET -> TYPE

L'entité type TYPE regroupe les éléments
ID_type : Auto_increment / SMALLINT (unsigned) / NOT NULL
code_type : SMALLINT (unsigned) / NOT NULL
libelle_type : VARCHAR(25) / NOT NULL
ordre_type : SMALLINT (unsigned) / NOT NULL


Choix de l'identifiant ID_type (stable et concis) un mot n'a pas d'identifiant technique connu -> on laisse faire la BD -> nb de type : très peut (nom, adjectif, verbe... -> type SMALLINT (unsigned).
code_type -> pour l'abréviation du genre (Adj ou Ad ou Vb ... Nc, Np)
libelle_type -> pour le nom du type complet Adjectif, Adverbe... verbe, Nom Commun, Nom Propre
ordre_type -> Un ordre pour gérer l'ordre d'affichage (autre que alphabétique)


RELATIONS

un MOT est typé par une à plusieurs type (nom, adj...)
un TYPE type aucun, un ou plusieurs MOT

Relation MCD

MOT -- 1,n -- définir -- 0,n --TYPE



et je donne un nom à ma règle R02

TYPE n'est pas une Entité-Type Faible

Mon MLD est



Mon SCRIPT SQL sera donc

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
#------------------------------------------------------------
#        Script MySQL.
#------------------------------------------------------------


#------------------------------------------------------------
# Table: MOT
#------------------------------------------------------------

CREATE TABLE MOT(
        ID_mot Int  Auto_increment  NOT NULL ,
        Mot    Varchar (25) NOT NULL
	,CONSTRAINT MOT_Idx INDEX (Mot)
	,CONSTRAINT MOT_PK PRIMARY KEY (ID_mot)
)ENGINE=InnoDB;


#------------------------------------------------------------
# Table: DEFINITION
#------------------------------------------------------------

CREATE TABLE DEFINITION(
        ID_mot     Int NOT NULL ,
        ID_def     Int NOT NULL ,
        Definition Varchar (255) NOT NULL
	,CONSTRAINT DEFINITION_PK PRIMARY KEY (ID_mot,ID_def)

	,CONSTRAINT DEFINITION_MOT_FK FOREIGN KEY (ID_mot) REFERENCES MOT(ID_mot)
)ENGINE=InnoDB;


#------------------------------------------------------------
# Table: TYPE
#------------------------------------------------------------

CREATE TABLE TYPE(
        ID_type      Int  Auto_increment  NOT NULL ,
        code_type    Smallint NOT NULL ,
        libelle_type Varchar (25) NOT NULL ,
        ordre_type   Smallint NOT NULL
	,CONSTRAINT TYPE_PK PRIMARY KEY (ID_type)
)ENGINE=InnoDB;


#------------------------------------------------------------
# Table: Typer
#------------------------------------------------------------

CREATE TABLE Typer(
        ID_type Int NOT NULL ,
        ID_mot  Int NOT NULL
	,CONSTRAINT Typer_PK PRIMARY KEY (ID_type,ID_mot)

	,CONSTRAINT Typer_TYPE_FK FOREIGN KEY (ID_type) REFERENCES TYPE(ID_type)
	,CONSTRAINT Typer_MOT0_FK FOREIGN KEY (ID_mot) REFERENCES MOT(ID_mot)
)ENGINE=InnoDB;

J'espère que cette fois c'est presque tout juste lol et y a pas de bonhomme NULL

SQLpro : Dès lors la théorie de l'algèbre relationnelle est violée par le fait de cette apparition du NULL (en principe l’algèbre relationnelle manipule des relations à l'aide d'opérateurs qui donnent en sortie de nouvelles relations, donc avec clef, sans doublons et sans null....)

[escartefigue]

Comme mentionné précédemment, un type Small est bien suffisant pour identifier les définitions, c'est bien ce que vous avez mis dans votre réponse qui précède, mais pas dans le MLD

[CinePhil]

L'entité type TYPE regroupe les éléments
ID_type : Auto_increment / SMALLINT (unsigned) / NOT NULL
code_type : SMALLINT (unsigned) / NOT NULL
libelle_type : VARCHAR(25) / NOT NULL
ordre_type : SMALLINT (unsigned) / NOT NULL

1) Un code de type entier ?
À quoi sert d'avoir un code s'il n'est pas signifiant ?
Un code est généralement de type CHAR, même si la chaîne ne comporte que des chiffres, pour éviter que les codes commençant par un ou plusieurs zéros ne soient tronqués.
Exemple typique du code postal :
- de type entier, le code postal de Foix (09000) devient 9000 ;
- en CHAR(5), le code postal reste bien à '09000'.

D'ailleurs, je vois que plus bas vous avez spécifié ceci :

code_type -> pour l'abréviation du genre (Adj ou Ad ou Vb ... Nc, Np)

=> CHAR(3) sera suffisant selon vos exemples.

2) Comme vous aurez très peu de types différents, un TINYINT suffira pour l'ID_Type et pour ordre_type.

Code SQL :

Sélectionner tout - Visualiser dans une fenêtre à part

CONSTRAINT MOT_Idx INDEX (Mot)

Un index n'est pas une contrainte.
Puisque vous utilisez un logiciel de modélisation, laissez-le générez le code SQL et examinez-le pour le corriger éventuellement.

Pour ce qui concerne l'index, regardez la doc MySQL sur le CREATE TABLE :

CREATE [TEMPORARY] TABLE [IF NOT EXISTS] tbl_name
(create_definition,...)
[table_options]
[partition_options]
...
create_definition:
col_name column_definition
| [CONSTRAINT [symbol]] PRIMARY KEY [index_type] (key_part,...)
[index_option] ...
| {INDEX|KEY} [index_name] [index_type] (key_part,...)
[index_option] ...
| [CONSTRAINT [symbol]] UNIQUE [INDEX|KEY]
[index_name] [index_type] (key_part,...)
[index_option] ...

=> la CONSTRAINT est sur UNIQUE, pas sur INDEX.