Another non-god here - though some folks put me way towards the OTHER end of that scale. {does anyone smell molten sulfur? Let me put down the pitchfork for a moment...}
John 471's approach is solid though his details might not exactly match your true needs. See, he doesn't know exactly what you want to do. It is hard to explain that in the space (and time) available on these forums. But his approach is exactly spot-on.
First, read up on Normalization. Access Help has a topic "Normalization" and you can Google-search about a gazillion hits on the longer "Database Normalization" category. (If you leave out "database" on Google, you'll also get Diplomatic Normalization and some mathematical references to normalization as a way to analyze disparate sample distributions.)
For the Google searches, only read the first two or three articles from reputable .EDU sites or vendor .COM sites for database products you know. ORACLE comes to mind. MIT and Cal Tech have nice articles. Univ. of New Zealand published something nice, too.
Now decide what things, what ENTITIES you have to track. These can be people, documents, cases, evidence exhibits, etc. Here, purity is essential. Tables that track cases NEVER track documents. Tables that track documents NEVER track people - including the authors. Tables that track people never track cases. etc. etc.
OK, NOW comes the real work... deciding exactly how they fit together. This is where you define relationships. You have already said that at least some if not all of your things to track can be multi-linked or multi-relevant.
So... define tables that list the items and their relationships to other items. This style of table is called a JUNCTION table. Let's pick on just a couple of examples to show the principle. First, people and cases. The cases can have defense and prosecutorial lawyers, judges, witnesses, plaintiffs, defendants, ...
So you have a Person table that lists each name. You have a Case table that lists each case. You define a Roles table that lists codes you can use to indicate given roles a person (or entity) can play. (If you forget a role you can add it later without a problem.) Now your PersCase table looks like
tblPersCase
PersID - foreign key to a single record in the person table.
CaseID - foreign key to a single record in the case table.
RoleID - foreign key to a single record in the role table.
This table might have no primary key because you can have more than one defendant, more than one witness, more than one defense lawyer... but you can query THIS table to find everyone associated with a case - and see what role they played. AND if the same person appears in other cases, you already have captured that person's data. You only need to store a NEW record for the NEW case and role. AND you can have a person play more than one role in the same case - if that is legally possible. (Witness and arresting officer - for criminal cases?)
OK, you've got documents... Since Documents has been defined as a simple stand-alone table, you can have "floating" documents that were written for anything including
in amicus curiae or Prospectuses in your publicly traded law firm (if it goes that far). Or on a whim.
So how do you relate documents to other things? You can build a case-to-document list showing all the documents submitted for a particular case by linking document ID to case ID in another junction table. You can include another role code if documents can take multiple roles - evidence, brief, pleading, supplemental information, ... You can just stick more role codes in the role table to cover these kinds of role. There is nothing sacred about having a mixed-entity role table. You just use one subset of the codes for people and a different subset for documents. No sweat.
You can also build a list of document-to-person relationships. A document can be AUTHORED by a person, ABOUT a person, SENT TO a person, etc. etc. - again, a many-to-many case since more than one document can be authored by a single person and a document can be sent to many people. Same principle applies.
OK, I've got you started on how to orient yourself. But its your problem and only you will see the nuances. This is HOW you do it. It is up to YOU to finish the job.
Oh... how do you tie these together? In reports, you can make cases your main entity (e.g.) and then build queries that tie together the document table to the case/document junction table. Build a report for that query. Then make it a sub-report in the main report and tie it to the case number in a parent-child FORMS relationship. The subform control wizard will do this for you. Build another query for the case/people relationships and make it a second subform on the same master report. (Both of these sub-reports go in the detail section of the case report in order for the parent/child links to work right.)
How do you manage the relationships? Build a form. Take that case/person query. Build a sub-form with it. Allow the sub-form to pick the appropriate member from the corresponding list. If it is a case form, the sub-form picks from the person list ... and another sub-form, perhaps on another tab control of the parent case form, selects the document relationships.
USING these forms would require that the raw data for person, case, document etc. would be already present in their respective "pure entity" tables before you can select them. But once they exist, you can add the relationship and role entries as needed.
