After reviewing the tables in the sample uploaded, I confirmed that the table design did indeed reflect what is often referred to as a "spreadsheet style" table because it looks exactly like a spreadsheet imported into Access as a table. In fact, that's a very common way they get created.
The hallmark of such tables is the existence of multiple fields of the same type, named differently to reflect the data: LeadFor and AsbestosFor, for example. Both refer to the same thing, the person for whom a sample was taken. But sometimes the sample is for "Lead" and sometimes for "Asbestos". Unfortunately, those data points get encoded into the field names like these did.
Here's how I would recommend the tables be redesigned to reflect an appropriate Relational database design.
NOTE: Because results for Lead sampling and for Asbestos Sampling are different, it is actually correct to have two tables for those results, but ONLY for the results.
NOT: Fields which are common to both are in the Sample table, renamed SampleCorrected in this diagram, such as SampleFor, which replaces the two original "XXXXFor" fields. It includes one additional field, called SampleTypeID. There are two (and possibly more) values for SampleType, "Lead" or "Asbestos".
Finally, the two results tables both link to the sample table. Each set of results, however, is store in one or the other, depending on the sample Type.
I uploaded the accdb with these corrections. Further analysis is always possible, of course. The point is that we are now in the world of relational database applications, not the world of spreadsheets and the way tables are designed must reflect that environment to be practical.