Discussion :

[Neelix57]

Bonjour,

Je poste ici le schéma de ma base de données Lego. J'ai repris le schéma de base de la bdd du site 'rebrickable', dont les tables sont mises à disposition et l'ai modifiée en conséquence de mes besoins. J'aimerais savoir si ma base est correcte.



En sachant que :

- Un set peut contenir un ou plusieurs inventaires. Un inventaire peur contenir des pièces ou d'autres sets, ou même les deux.
- La table "stock" contient les pièces dont je dispose.
- La table "required_parts" contient les pièces nécessaire pour reconstituer plusieurs set. (Dans l’immédiat, je l'utilise à des fins de test). A terme, c'est à partir des autres tables que je récupérerai cette liste de pièces nécessaire à reconstituer un ou plusieurs sets.

[fsmrel]

Bonjour Neelix57,

Les règles de gestion étant absentes, on ne peut pas donner d'avis pertinent.

[Neelix57]

Je n'ai pas l'habitude de donner des règles de gestion de base de données. Je m'excuse si, par malheur, j’enfreins certaines règles en la matière.

- Les sets de lego complets (un ou plusieurs simultanément) en ma possession seront sélectionnés dans la table "sets" contenant tous les sets existants.
- Ce(s) set(s) seront stockés dans une table contenant les sets complets.
- La sélection d'un ou plusieurs set affichera ou insérera dans une table l'inventaire de ses pièces.
- La base contient également les pièces que je possède.
- Des pièces que j’achèterai seront sélectionnées dans la table "parts" pour être ajoutée à la table contenant mon stock.
- Grâce à la liste de pièces nécessaires et à celle des pièces en stock, je pourrai calculer le nombre de pièces manquantes.
- Quand un set est marqué "complet", les pièces le constituant (dans le stock, ainsi que dans les pièces nécessaires ne seront plus sélectionnées)
- Tous les sets sont classés par thèmes, un thème pouvant contenir des sous-thèmes. Ils se situent dans une table unique.
- Toutes les pièces sont classées par catégorie et peuvent être de différentes couleurs.
- Un set peut contenir un ou plusieurs inventaires.
- Un inventaire peut contenir des sets et/ou des pièces.
- Les sets on tous un numéro qui leur est propre.
- Les pièces ont un numéro qui leur est propre, mais qui peut varier en fonction de certains critères (ex. La pièce 3004 est une brique. La même brique contenant un motif représentant une grille portera le numéro 3004p06).
- La table parts "contient" toutes les pièces existantes, avec leur numéro, et leur dénomination.
- La table "sets" contient tous les sets existants, avec leur numéro, leur dénomination, l'année de sortie et le nombre de pièces qu'ils contiennent.
- La table "inventories" répertorie tous les inventaires et est reliée à la table "inventory_parts", qui renvoie l'inventaire des pièces pour un set donné, ainsi qu'à la table "inventory_sets", qui renvoie l'inventaire des sets pouvant être contenu dans un set principal. Un inventaire peut avoir plusieurs versions.

[fsmrel]

Bonsoir Neelix57,


Les règles de gestion sont du niveau utilisateur qui ne connaît rien à l’informatique, donc ne sait pas a fortiori ce qu’est une table, on évitera d’utiliser un tel terme.

On commence à percevoir un peu votre univers, mais qu’est-ce donc qu’un set de lego ? Merci d’en donner une définition afin de nous éclairer.

 

[Neelix57]

Ce que l'on appelle un set est tout simplement une boite de lego. Dans le cas de ma base de données, certains sets pourront également être un ensemble de sets. (dans le cas d'une promo par exemple)

[Neelix57]

Mille excuses. Je me rends compte que j'ai voulu aller un peu trop vite.

En fait, je me rends compte que j'ai oublié la table contenant les sets que je possède. Egalement, je n'ai pas besoin de répéter tous les champs dans la table "stock". J'ai donc modifié mon schéma en conséquence. Quand à la table "required_parts", je ne l'avais crée que pour faire mes premiers essais.

[fsmrel]

Bonsoir Neelix57,


En l’absence de la connaissance de votre outil de modélisation, votre diagramme suscite pas mal d’interrogations avant même d’en juger la pertinence. Quel est cet outil ?

Ainsi, les liens entre tables sont de couleurs différentes. Quel rôle attribuer à ces couleurs ?

Les connecteurs synonymes de « plusieurs » ressemblent parfois à des moitiés de sphères pleines (cf. par exemple celui qui est accolé à inventory_sets dans le lien entre inventory_sets et sets), parfois à des moitiés de sphères creuses : quelle signification donner à ces différences ?

Les mickeys situés à gauche des noms des attributs peuvent peut-être signifier des choses différentes. c’est le cas du "#" accompagnant l’attribut "year" (table sets) et celui qui accompagne l’attribut parent id (table themes).

Bref, pour qu’on comprenne mieux votre modélisation, merci en outre d’afficher le code SQL généré par l’outil.

Les noms des attributs d’une table constituent l’en-tête de celle-ci, lequel donne lieu à un prédicat au sens sémantique et de la logique d’Aristote. Exemple de la table SETS :

Le set identifié par ID, ayant pour numéro SET_NUM pour nom NAME date de l’année YEAR et a pour thème THEME_ID.

Cela a pour conséquence que le nom d’une table étant celui de son prédicat, ce nom doit être au singulier (SET au lieu de SETS). En français c’est encore mieux...

 

[Neelix57]

J'ai crée ma base sous phpmyadmin. Le schéma est issu du concepteur.

[fsmrel]

J'ai crée ma base sous phpmyadmin. Le schéma est issu du concepteur.

Ce qui ne m’avance pas plus !

Le plus simple est que vous postiez le script de création des tables SQL que votre outil fournit.

 

[Neelix57]

Je ne sais pas comment m'y prendre pour récupérer le script de création de table. En faisant un export de la base, le fichier obtenu est trop lourd pour être uploadé, même zippé. Et impossible d'insérer le texte dans la discussion par copier/coller.

[fsmrel]

En faisant un export de la base, le fichier obtenu est trop lourd

Il ne s’agit pas d’exporter le contenu de la base de données ! Mais la liste des instructions CREATE TABLE (quelques kilo-octets), commençant par exemple ainsi :

CREATE TABLE BOITE 
(
  boiteId   INT  NOT NULL
, annee     INT  NOT NULL
, CONSTRAINT BOITE_PK PRIMARY KEY (boiteId)
) ;

A cet effet, en cherchant sur la toile "phpmyadmin script create table", on trouve par exemple un lien vers une explication de la manip.

 

[Neelix57]

Voila ce que c'est quand on ne réfléchit pas.

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
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
Table 	Créer Table
categories 	CREATE TABLE `categories` (
 `id` int(4) NOT NULL DEFAULT '0',
 `name` varchar(200) DEFAULT NULL,
 PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8
colors 	CREATE TABLE `colors` (
 `id` int(4) NOT NULL DEFAULT '0',
 `name` varchar(200) DEFAULT NULL,
 `rgb` varchar(6) DEFAULT NULL,
 `is_trans` tinyint(1) DEFAULT NULL,
 PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8
inventories 	CREATE TABLE `inventories` (
 `id` int(4) NOT NULL DEFAULT '0',
 `version` int(4) DEFAULT NULL,
 `set_num` varchar(20) DEFAULT NULL,
 PRIMARY KEY (`id`),
 KEY `set_num` (`set_num`),
 CONSTRAINT `inventories_ibfk_1` FOREIGN KEY (`set_num`) REFERENCES `sets` (`set_num`) ON DELETE NO ACTION ON UPDATE NO ACTION
) ENGINE=InnoDB DEFAULT CHARSET=utf8
inventory_parts 	CREATE TABLE `inventory_parts` (
 `inventory_id` int(4) DEFAULT NULL,
 `part_num` varchar(20) DEFAULT NULL,
 `color_id` int(4) DEFAULT NULL,
 `quantity` int(4) DEFAULT NULL,
 `is_spare` tinyint(1) DEFAULT NULL,
 KEY `inventory_id` (`inventory_id`),
 KEY `color_id` (`color_id`),
 KEY `part_num` (`part_num`),
 CONSTRAINT `inventory_parts_ibfk_1` FOREIGN KEY (`inventory_id`) REFERENCES `inventories` (`id`) ON DELETE NO ACTION ON UPDATE NO ACTION,
 CONSTRAINT `inventory_parts_ibfk_2` FOREIGN KEY (`color_id`) REFERENCES `colors` (`id`) ON DELETE NO ACTION ON UPDATE NO ACTION,
 CONSTRAINT `inventory_parts_ibfk_3` FOREIGN KEY (`part_num`) REFERENCES `parts` (`part_num`) ON DELETE NO ACTION ON UPDATE NO ACTION
) ENGINE=InnoDB DEFAULT CHARSET=utf8
inventory_sets 	CREATE TABLE `inventory_sets` (
 `inventory_id` int(4) DEFAULT NULL,
 `set_num` varchar(20) DEFAULT NULL,
 `quantity` int(4) DEFAULT NULL,
 KEY `inventory_id` (`inventory_id`),
 KEY `set_num` (`set_num`),
 CONSTRAINT `inventory_sets_ibfk_1` FOREIGN KEY (`inventory_id`) REFERENCES `inventories` (`id`) ON DELETE NO ACTION ON UPDATE NO ACTION,
 CONSTRAINT `inventory_sets_ibfk_2` FOREIGN KEY (`set_num`) REFERENCES `sets` (`set_num`) ON DELETE NO ACTION ON UPDATE NO ACTION
) ENGINE=InnoDB DEFAULT CHARSET=utf8
my_sets 	CREATE TABLE `my_sets` (
 `id` int(4) NOT NULL AUTO_INCREMENT,
 `sets_id` int(4) NOT NULL,
 `is_build` tinyint(1) DEFAULT NULL,
 PRIMARY KEY (`id`),
 UNIQUE KEY `sets_id` (`sets_id`),
 CONSTRAINT `my_sets_ibfk_1` FOREIGN KEY (`sets_id`) REFERENCES `sets` (`id`) ON DELETE NO ACTION ON UPDATE NO ACTION
) ENGINE=InnoDB DEFAULT CHARSET=latin1
parts 	CREATE TABLE `parts` (
 `id` int(4) NOT NULL AUTO_INCREMENT,
 `part_num` varchar(20) NOT NULL DEFAULT '',
 `name` varchar(250) DEFAULT NULL,
 `category_id` int(4) DEFAULT NULL,
 PRIMARY KEY (`id`),
 UNIQUE KEY `part_num` (`part_num`),
 KEY `category_id` (`category_id`) USING BTREE,
 CONSTRAINT `parts_ibfk_1` FOREIGN KEY (`category_id`) REFERENCES `categories` (`id`) ON DELETE NO ACTION ON UPDATE NO ACTION
) ENGINE=InnoDB AUTO_INCREMENT=35156 DEFAULT CHARSET=utf8
sets 	CREATE TABLE `sets` (
 `id` int(4) NOT NULL AUTO_INCREMENT,
 `set_num` varchar(20) NOT NULL DEFAULT '',
 `name` varchar(256) DEFAULT NULL,
 `year` int(4) DEFAULT NULL,
 `theme_id` int(4) DEFAULT NULL,
 `num_parts` int(4) DEFAULT NULL,
 PRIMARY KEY (`id`),
 UNIQUE KEY `set_num` (`set_num`) USING BTREE,
 KEY `theme_id` (`theme_id`),
 CONSTRAINT `sets_ibfk_1` FOREIGN KEY (`theme_id`) REFERENCES `themes` (`id`) ON DELETE NO ACTION ON UPDATE NO ACTION
) ENGINE=InnoDB AUTO_INCREMENT=15643 DEFAULT CHARSET=utf8
stock 	CREATE TABLE `stock` (
 `part_id` int(4) NOT NULL,
 `quantity` int(4) DEFAULT NULL,
 KEY `part_id` (`part_id`),
 CONSTRAINT `stock_ibfk_1` FOREIGN KEY (`part_id`) REFERENCES `parts` (`id`) ON DELETE NO ACTION ON UPDATE NO ACTION
) ENGINE=InnoDB DEFAULT CHARSET=utf8
themes 	CREATE TABLE `themes` (
 `id` int(4) NOT NULL,
 `name` varchar(40) DEFAULT NULL,
 `parent_id` int(4) DEFAULT NULL,
 PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8

[fsmrel]

Bonsoir Neelix57,

Merci pour le code SQL, je vais examiner tout ça.
Pour être complet, pourriez-vous fournir le code SQL des tables THEMES et STOCK ? Merci.

A suivre.

 

[Neelix57]

Voilà le codes SQL pour ces deux tables.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
CREATE TABLE `stock` (
 `id` int(4) NOT NULL AUTO_INCREMENT,
 `part_id` int(4) NOT NULL,
 `quantity` int(4) DEFAULT NULL,
 PRIMARY KEY (`id`),
 KEY `part_id` (`part_id`),
 CONSTRAINT `stock_ibfk_1` FOREIGN KEY (`part_id`) REFERENCES `parts` (`id`) ON DELETE NO ACTION ON UPDATE NO ACTION
) ENGINE=InnoDB AUTO_INCREMENT=1677 DEFAULT CHARSET=utf8
CREATE TABLE `themes` (
 `id` int(4) NOT NULL,
 `name` varchar(40) DEFAULT NULL,
 `parent_id` int(4) DEFAULT NULL,
 PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8

[fsmrel]

Bonsoir Neelix57,

Je ne vous oublie pas, mais je suis bien pris par ailleurs.

 

[fsmrel]

Bonsoir Neelix57,


Que de NULL dans le script SQL ! Rappel préliminaire : soit une table T donnée ; l’intersection d’une colonne C et d’une ligne L données de T constitue une cellule (C, L). NULL n’est pas une valeur pouvant être prise par (C, L), mais une marque précisant que (C, L) ne contient pas de valeur, essentiellement pour les motifs suivants :

— (C, L) devrait normalement contenir une valeur, mais on ne sait pas pour le moment quelle peut être celle-ci : son statut est « applicable » ;

— (C, L) n’a pas à contenir de valeur (son statut est « inapplicable »).


Table THEME

Quand vous écrivez :

[...] un thème pouvant contenir des sous-thèmes

Je suppose que la finalité de la colonne parent_id est de permettre d’associer un thème parent à un sous-thème.

(Q01) Vrai/faux ?

Selon votre script SQL, La colonne name est nullable : un thème pourrait donc ne pas avoir de nom.

(Q02) Vrai/faux ?

La colonne parent_id est nullable. En connexion avec (Q01), je suppose que chaque sous-thème fait référence à un thème parent, mais qu’un thème peut ne pas avoir de parent, auquel cas la colonne parent_id est marquée NULL (au sens inapplicable) .

(Q03) Vrai/faux ?


Table SETS

Selon le script SQL, les colonnes name, year, theme_id, num_parts sont nullables.

(Q04) Quelles sont celles qui peuvent être effectivement marquées NULL, et pour quel motif ?


Table MY_SETS :

La table MY_SETS est dotée d’une clé alternative (contrainte UNIQUE) {sets_id}, qui est aussi clé étrangère par rapport à la table SETS. Or selon le code SQL, la colonne quantity a disparu, vous ne vous autorisez donc la possession que d'un seul exemplaire d’un jeu donné.

(Q05) Vrai/faux ?

Il faudra une contrainte pour que la colonne is_build ne puisse prendre que deux valeurs (par exemple 0 et 1). Par ailleurs cette colonne ne doit pas être nullable (sinon on rentre dans le monde redoutable de la logique trivalente).


table INVENTORIES

En théorie la référence à la table SETS devrait mettre en jeu la colonne sets_id et non pas la colonne set_num qui au demeurant est déclarée nullable, ce qui fait qu’un inventaire pourrait donc ne pas concerner un jeu appartenant à la table SETS. Si on se fie strictement au script SQL, un inventaire peut effectivement ne pas concerner un jeu appartenant à la table SETS.

(Q06) Vrai/faux ?


Table INVENTORY_SETS

Vous écrivez :

[..] ainsi qu'à la table "inventory_sets", qui renvoie l'inventaire des sets pouvant être contenu dans un set principal

Le concept de « set principal » n’est visiblement pas formellement modélisé.

(Q07) Comment sait-on qu’un jeu est principal ? Est-ce le fait qu’il soit référencé par des jeux présents dans la table INVENTORY_SETS ?

Chaque jeu présent dans INVENTORY_SETS référence à la fois SETS et INVENTORIES : il y a manifestement une redondance et la référence à INVENTORIES devrait suffire.

(Q08) Vrai/faux ? Si faux, pourquoi ?

INVENTORY_SETS est un sac, car dépourvu de clé primaire, il faut remédier à cela. Par ailleurs, toutes les colonnes sont nullables, shocking ! Remédier là aussi.

Je poursuis l’exploration du script SQL en relation avec votre description des jeux.


 

[Neelix57]

Table THEME

Je suppose que la finalité de la colonne parent_id est de permettre d’associer un thème parent à un sous-thème.

(Q01) Vrai

Selon votre script SQL, La colonne name est nullable : un thème pourrait donc ne pas avoir de nom.

(Q02) Faux

La colonne parent_id est nullable. En connexion avec (Q01), je suppose que chaque sous-thème fait référence à un thème parent, mais qu’un thème peut ne pas avoir de parent, auquel cas la colonne parent_id est marquée NULL (au sens inapplicable) .

(Q03) Vrai. Un thème parent n'a pas de parent.


Table SETS

Selon le script SQL, les colonnes name, year, theme_id, num_parts sont nullables.

(Q04) Quelles sont celles qui peuvent être effectivement marquées NULL, et pour quel motif ?

- La colonne YEAR peut être marquée NULL; si l'année de sortie est inconnue.
- La colonne NUM_PARTS peut être marqué NULL; si le set ne contient pas de pièce. (Dans le cas d'un set ne contenant qu'un ensemble de sets)

Table MY_SETS :

La table MY_SETS est dotée d’une clé alternative (contrainte UNIQUE) {sets_id}, qui est aussi clé étrangère par rapport à la table SETS. Or selon le code SQL, la colonne quantity a disparu, vous ne vous autorisez donc la possession que d'un seul exemplaire d’un jeu donné.

(Q05) Vrai


table INVENTORIES

En théorie la référence à la table SETS devrait mettre en jeu la colonne sets_id et non pas la colonne set_num qui au demeurant est déclarée nullable, ce qui fait qu’un inventaire pourrait donc ne pas concerner un jeu appartenant à la table SETS. Si on se fie strictement au script SQL, un inventaire peut effectivement ne pas concerner un jeu appartenant à la table SETS.

(Q06) Faux. Chaque inventaire est lié à un jeu appartenant à la table SETS.


Table INVENTORY_SETS

(Q07) Comment sait-on qu’un jeu est principal ? Est-ce le fait qu’il soit référencé par des jeux présents dans la table INVENTORY_SETS ?

S'il est référencé dans la table SETS, ce sera un jeu principal. Il peut aussi faire partie d'un jeu principal, dans ce cas, il sera également référencé dans la table INVENTORY_SETS.

Chaque jeu présent dans INVENTORY_SETS référence à la fois SETS et INVENTORIES : il y a manifestement une redondance et la référence à INVENTORIES devrait suffire.

(Q08) Faux ? Car la table INVENTORIES permet de lister l'inventaire des pièces constituant un set; inventaire contenu dans INVENTORY_PARTS. Quand à la référence à la table INVENTORY_SETS, elle permet de récupérer les sets constituant un jeu principal.

[fsmrel]

Bonjour Neelix57,


Table THEME

En réponse à (Q02), vous avez répondu "faux" : il faudra donc que la colonne "name" soit déclarée NOT NULL.

A (Q03) vous avez répondu "vrai" et précisé qu’un thème parent n'a pas de parent. Un jeu ne peut donc pas être à la fois parent et enfant, et on a au plus deux niveaux : thème et sous-thème.
(Q10) On est en accord ?

(Q11) Un thème peut-il être parent de plusieurs sous-thèmes ?

(Q12) Un sous-thème peut-il être utilisé pour plus d’un thème ?


Table MY_SETS

A (Q05) vous répondez "faux" : la structure SQL de la table MY_SETS n’est donc pas valide. Si pour un set de la table SETS on peut avoir plusieurs occurrences dans la table MY_SETS, alors la contrainte UNIQUE n’est pas licite et doit disparaître. Quant au nombre d’occurrences, il est connu par un COUNT SQL (la colonne QUANTITY est alors de fait inutile).
(Q13) Votre position ?


Table SETS

(Q14) Chaque set fait-il nécessairement référence à un thème ?

En réponse à (Q04), vous dites que la colonne NUM_PARTS est marquée NULL quand le set ne contient pas de pièces. Vu les ravages que peut provoquer le bonhomme NULL, il est préférable de déclarer NOT NULL cette colonne et la valoriser à 0. Vous précisez que ceci ne concerne que les sets « ne contenant qu’un ensemble de sets ». Appelons superset un set S1 qui contient un ensemble de sets S2, S3, ..., Sn,
(Q15) comment sait-on que S2, S3, ..., Sn appartiennent à S1 ?


table INVENTORIES

A (Q06) vous répondez "faux" et précisez que chaque inventaire est lié à un jeu appartenant à la table SETS. Il faudra donc faire en sorte que la colonne SET_NUM de la table INVENTORIES soit déclarée NOT NULL.


Table INVENTORY_SETS

A (Q07) vous répondez qu’un jeu principal est toujours référencé dans la table SETS, ainsi que chaque jeu appartenant à un jeu principal. Donc tous les jeux principaux et les jeux qui en sont les composants ont leur image dans la table INVENTORY_SETS. Les autres jeux en sont exclus et ne figurent que dans les tables SETS et INVENTORIES.
(Q16) Vrai ou faux ?

Si la réponse est positive, l’association entre INVENTORY_SETS et INVENTORIES est une surcharge inutile et doit disparaître. Quand vous écrivez que la référence à la table INVENTORY_SETS permet de récupérer les sets constituant un jeu principal, on sait faire cela par une requête :

SELECT x.set_num
FROM   inventories AS x
  JOIN inventory_sets AS y ON x.set_num = y.set_num
;

 

[Neelix57]

Table THEME

A (Q03) vous avez répondu "vrai" et précisé qu’un thème parent n'a pas de parent. Un jeu ne peut donc pas être à la fois parent et enfant, et on a au plus deux niveaux : thème et sous-thème.

(Q10) En fait, on a jusqu'à trois niveaux. Mais si un thème peut-être parent et enfant, ou avoir plusieurs parents, il apparaît autant de fois dans la table. Par exemple, si J'ai un thème parent "juniors" comprenant un sous-thème "cars", ainsi qu'un thème parent "cars", "cars" apparaîtra deux fois dans la table. Celui qui est le thème parent, prenant la valeur 0.

(Q11) Un thème peut-il être parent de plusieurs sous-thèmes ?

Oui

(Q12) Un sous-thème peut-il être utilisé pour plus d’un thème ?

Oui. Et dans ce cas, il apparaîtra autant de fois que nécessaire dans la table.


Table MY_SETS

A (Q05) vous répondez "faux" : la structure SQL de la table MY_SETS n’est donc pas valide. Si pour un set de la table SETS on peut avoir plusieurs occurrences dans la table MY_SETS, alors la contrainte UNIQUE n’est pas licite et doit disparaître. Quant au nombre d’occurrences, il est connu par un COUNT SQL (la colonne QUANTITY est alors de fait inutile).

(Q13) Votre position ? Je ne m'autorise la possession que d'un seul exemplaire de chaque set. En fait, ce fût une erreur de ma part que j'ai corrigée tôt ce matin, et je m'en excuse.


Table SETS

(Q14) Chaque set fait-il nécessairement référence à un thème ?

Oui

(Q15) comment sait-on que S2, S3, ..., Sn appartiennent à S1 ?

La colonne "inventory_id" de la table INVENTORY_SETS correspond à la clé primaire "id" de la table SETS. En fait j'ai gardé la relation figurant dans le schéma trouvé sur le site Rebrickable, qui met sa base de donnée à disposition.


Table INVENTORY_SETS

A (Q07) vous répondez qu’un jeu principal est toujours référencé dans la table SETS, ainsi que chaque jeu appartenant à un jeu principal. Donc tous les jeux principaux et les jeux qui en sont les composants ont leur image dans la table INVENTORY_SETS. Les autres jeux en sont exclus et ne figurent que dans les tables SETS et INVENTORIES.

(Q16) Faux. Tous les jeux figurent dans la table SETS. Dans la plupart des cas, le jeu (ou set) ne sera composé que de pièces.

[fsmrel]

Bonsoir Neelix57,


Table THEME

Vous avez répondu positivement à (Q11) et (Q12),c’est-à-dire qu’un thème T1 peut-être parent de plusieurs thèmes et qu’un thème T2 peut être enfant de plusieurs thèmes.

(Q17) Une demande de précision : si T1 est parent de plusieurs thèmes peut-il en même temps être enfant de plusieurs thèmes ?


Table MY_SETS

A (Q13) vous avez répondu : « Je ne m'autorise la possession que d'un seul exemplaire de chaque set ». Donc la contrainte UNIQUE est licite.
(Q18) On est en phase ?


Table INVENTORIES

(Q19) Variation sur (Q07) et (Q16) : la table INVENTORIES est bien dédiée aux seuls sets qui contiennent des pièces ?


Table INVENTORY_SETS

Votre réponse à (Q15) : « La colonne "inventory_id" de la table INVENTORY_SETS correspond à la clé primaire "id" de la table SETS. »

Hum... Selon votre script SQL, la colonne "inventory_id" de la table INVENTORY_SETS fait référence à la clé primaire {id} de la table INVENTORIES, pendant que la colonne set_num de la table INVENTORY_SETS fait référence à la clé alternative {set_num} de la table SETS.
En l’occurrence, le script SQL est en contradiction avec votre affirmation selon laquelle la colonne "inventory_id" de la table INVENTORY_SETS correspond à la clé primaire "id" de la table SETS.
(Q21) Qu’en est-il ?

Vous dites : « En fait j'ai gardé la relation figurant dans le schéma trouvé sur le site Rebrickable, qui met sa base de donnée à disposition. »
(Q22) Quelle relation ? celle qui existe entre INVENTORY_SETS et INVENTORIES ?

Vous répondez négativement à (Q16). On est au moins d’accord que tous les jeux sont présents dans la table SETS !

Cela dit, soit I1 l’ensemble des jeux figurant dans INVENTORIES et soit E1 l’ensemble des jeux principaux et E2 l’ensemble des jeux composant ces jeux principaux.

Si les jeux appartenant à E1 ou E2 n’ont pas de pièces en propre, ils figurent alors dans INVENTORY_SETS, mais jamais dans INVENTORIES.
(Q23) Est-ce bien cela ?

Par contre, les jeux appartenant à I1 ne peuvent pas figurer dans INVENTORY_SETS.
(Q24) Est-ce bien cela ?

Si vous répondez positivement aux questions (Q19), (Q23) et (Q24), alors INVENTORY_SETS et INVENTORIES constituent deux partitions, c’est-à-dire deux ensembles disjoints dont l’union représente l’ensemble des jeux présents dans SETS.
S’il faut conserver l’association entre INVENTORY_SETS et INVENTORIES, la seule explication que je trouve à cela, c’est que cette association permet de savoir quels jeux à pièces (à savoir I1) sont utilisés par quels jeux pas à pièces (à savoir E1 et E2).
(Q25) Vrai ? Faux ?

Supposons que vous répondiez positivement à (Q25). Si des jeux sont principaux (à savoir E1) et ont des composants (à savoir E2) associés à des I1, on pourra au besoin savoir combien de pièces comportent ces E2, mais :
(Q26) question subsidiaire, comment sait-on qu’un E2 est composant d’un E1 ? On retrouve ma question (Q15).