Testing Data Base - structure to start me off

[SingleSide]

Hi Folks,
Have been surfing a few internet based places for info youtube, forums etc but am still struggling.
I can do Access and have also done a bit of VBA over the years.
What i want is a simple solution that requires little if any VBA.
Infact none would be better!

I am struggling with the database table structure and how the relationships might work.
Basically what i have is when a FAILED test occurs i need to start logging it and also the remedial works when taks get done to try and repair the situation.
Its a bit like snakes and ladders tho because if you get part of the way through from a time perspective and then you get a FAILED sample, you have to go back and do some more remedial works and test all over again.
They seem to be looped but i just cant seem to get my head around how the hell i would start with my tables.


And then....how many do i need without making it too complicated.

Ultimately i will make a report from a query so that i can see what the status is with the FAILURES at each stage of the testing process.

Any pointers or help in the right direction would help my significantly grey hair.

See my jpeg of the flow chart if it helps.

Cheers all

[Micron]

Your flowchart is useful for describing the flow of a process, but might have little bearing on how to construct tables and relationships. In fact, I wouldn't let it influence the decisions too much.
You don't need flags to denote failure if you have a date. If the date is the failure date, then its absence denotes a pass. You might get away with a flag for removal from service, but again, if a date is involved, you don't need that flag either. For each entity that you might have multiple records for, you need a separate table.
Look at this from an entity/attribute relationship. If a test is an entity, then what are its attributes? sample ID, test date, test type, failure date? Why is this about failures instead of test outcome? You might have presented info that's a bit too far into the whole process; just saying that the entity might be the testing and not about failure.

[SingleSide]

Hi Micron,
You are right, i keep looking at the flow chart for inspiration or solutions but i think its preventing me seeing the woods for the trees as they say.
I will try and look at it from another perspective.
Cheers for the reply.

[Micron]

I often post these links for self proclaimed novices that might need tips on normalization (and maybe a bunch of other 'basic' stuff as well). Might help prevent future headaches.
Normalization is paramount. Diagramming maybe not so much for some people.

Normalization Parts I, II, III, IV, and V
http://rogersaccessblog.blogspot.ca/...on-part-i.html
and/or
http://holowczak.com/database-normalization/

Entity-Relationship Diagramming: Part I, II, III and IV
http://rogersaccessblog.blogspot.ca/...ng-part-i.html

How do I Create an Application in Microsoft Access?
http://rogersaccessblog.blogspot.ca/...cation-in.html

Important for success:
One source about how to name things - http://access.mvps.org/access/general/gen0012.htm
What not to use in names - http://allenbrowne.com/AppIssueBadWord.html
About Auto Numbers
- http://www.utteraccess.com/wiki/Autonumbers
- http://access.mvps.org/access/general/gen0025.htm

The evils of lookup fields - http://access.mvps.org/access/lookupfields.htm
Table and PK design tips - http://www.fmsinc.com/free/newtips/primarykey.asp
About calculated table fields - http://allenbrowne.com/casu-14.html