Vérification d'un diagramme puis contraintes

Bonsoir,

Je vais tout d’abord préciser que cela fait un bon moment que je n’ai pas fait de conception de base de données.

J’ai une application qui se trouve sur plusieurs guildes. Une guilde est composées de plusieurs membres et chaque membre peut être présent dans plusieurs guildes. L’application fournit plusieurs commandes. Dans chaque guilde, une commande peut être active ou non. Enfin, une guilde peut avoir des tags. Chaque guilde peut avoir un seul tag ayant le même nom. Le préfixe n’est pas à prendre en compte.

Tout d’abord, je souhaiterai savoir si mon schéma est bien fait par rapport à ce que j’ai dit. Ensuite, je souhaiterai savoir comment relier Tag à Guilde. J’ai trouvé en anglais le terme composite unique constraint. Je pense qu’en SQL, il faut utiliser cette méthode. Par contre, comment faire pour le montrer sur le diagramme ?

Merci d’avance.

Pourquoi ne pas ajouter une nouvelle table qui n’aurait en colonne que id_tag et id_guild (en supprimant le id_guild de la table Tag).

En mettant ces 2 champs en clef primaire, il ne peut, par définition des clefs primaires, y avoir de doublon.

J’y avais pensé mais il n’y a pas de tags génériques comme sont les commandes. Le hasard peut faire que deux guildes créent le même tag (name, description et display identiques) mais je pense que la probabilité est infime. Par contre, name doit apparaître une seule fois par guilde.

Tu peux ajouter "name" et "disabled" dans ta table intermédiaire, et ajouter une contrainte d’unicité sur "id_guild" et "name".

=> ADD CONSTRAINT uniqueNamePerGuild UNIQUE (id_guild, name)

Tu peux le faire directement dans Tag si tu ne fais pas de table intermédiare, ou un truc du genre.

Je ne comprends pas en quoi je devrais utiliser une relation many-to-many entre Tag et Guild. Je pensas faire ça directement dans Tag donc je me demandais comment le montrer sur le diagramme.

Aussi, est-ce que le reste du diagramme semble correct ?

Personne n’a de connaissances en base de données ?

Salut !

Pour guild <-> tag, le mieux semble effectivement de faire une table intermédiaire parce que c’est un many-to-many :

une guilde peut avoir des tags

Maintenant tu veux qu’une guilde n’ait qu’une seule fois le même tag :

Chaque guilde peut avoir un seul tag ayant le même nom.

Pour ça, tu peux utiliser des contraintes d’unicité :

• Tu mets une contrainte d’unicité sur le nom du tag dans la table tag, comme ça t’as jamais 2 tags du même nom.
• Tu mets une contrainte d’unicité sur id_guild, id_tag, comme ça t’as pas 2x le même tag sur la même guilde (ou 2x la même guilde pour le même tag, c’est pareil). Cette contrainte empêche donc d’insérer (2, 8), (2, 8) dans la table intermédiaire.

Le reste du schéma est bien, à part les champs booléen. Il vaut souvent mieux ne pas en utiliser. Remplace par exemple guild_command.disabled par un champ de type DATETIME, où tu inséreras la date à laquelle la commande a été désactivée, ou par un champ disabled_by où tu mettras l’ID de l’admin ayant désactivé la commande. Tu comprends l’idée.