Table A is circuits
Table B is modules
Table C is encryption
Table D is verification code
So, what I see so far might be something like this:
- Each Circuit (A) can have one more modules (B) (I'll call them table AB)
- Each circuit-module AB has one encryption C1
- Each circuit-module AB has one or more codes (D) (I'll call that table ABD)
- Each circuit-module-code (ABD) has an encryption C2, where C1 = C2.
Table A (Circuit)
ID_A (PK)
... Other fields describing the circuit
Table B (Module)
ID_B (PK)
... other fields describing each module type (but not encryption)
Table AB (Circuit Module)
ID_AB (PK)
ID_A (FK to circuit)
ID_B (FK to module description)
C1 (FK to encryption)
... other fields describing this module occurance
Table ABD (Circuit Module Code)
ID_ABD (PK)
ID_AB (FK to Circuit-module)
ID_D (FK to Codes)
C2 (FK to encryption) (C2 = C1)
Table C (Encryption)
ID_C (PK)
... other fields describing the encryption
Table D1 (Codes)
ID_D1 (PK)
... other fields describing this code
Table D2 (code encryption)
ID_D2 (PK)
ID_D1 (FK to D1, code description)
ID_C (FK to Encryption - indicates the encryption used in this module)
That, I think should almost be it. Notice I have used no many-to-many relationships. There is no many-to-many relationship between codes and encryption, because any one occurance (or use) of a code can have only one encryption. Different occurances of the same code can have different encryptions as you said, and that is covered in table D2. All the FK links to code or encryption act as lookups for detailed information.
That's my take on what you have; I'm sure there are others. Let us know how it goes.