Stai entrando in un campo non complesso, ma non banale... relazioni Gerarchiche.
Se un componente può essere Figlio di un solo Componente, la Tabella va realizzata con un Campo [IdParent] che definisce la PK dell'Oggetto Padre a cui è legato.
Se un Componente è un elemento primario questo campo IdParent, sarà NULL, se un componente ha un legame con un Componete superiore avrà l'Id del componente superiore.
Es(Ambito culinario), per semplicità metto 3 campi:
IdPk | Desc | IdParent
-----------------------------------
1 | Torta di Mele | Null
2 | Uova | 1
3 | Farina | 1
Questa struttura, per essere gestita potrebbe avere necessità di solo 1 Tabella in cui nel diagramma relazionale si inseriscono 2 Istanze della stessa Tabella, e si collega IdPK della 2° su IdParent della 1°.
Questo però andrebbe bene se la Farina tu la usassi SOLO per fare quella Torta di mele... ovvero solo se il Componente 2 venisse usato Solo nel componente Padre 1
Se invece hai un catalogo componenti e vuoi la flessibilità di gestite le aggregazioni gerarchiche, serve una struttura simile ma con una tabella aggiuntiva di Defininizione Gerarchica.
TbComponenti
IdPK
Desc
TbGerarchia
IdPk
IdParent
La Chiave primaria di questa tabella è l'insieme dei 2 campi.
Ovviamente in questa tabella inserirai la ricetta... o i dati specifici dell'aggregazione.
Il problema che poi ti troverai, dal momento che JET non gestisce le Gerarchie in SQL, ed in base al fatto che queste strutture sono tipiche per popolare TreeView, dovrai lavorare di Codice più di quanto pensi..., in ogni caso è il metodo per farlo...