Hey Gilrucht,
I'm sure Mr. George and Ms. Hartman will jump in when they get a chance. Until then I'll try to lend a hand. I am very much still learning so I do not understand near like those two, so here goes.
"I have 2 questions. First, Why would I want to put all due dates, criminal and civil, federal and civil, in one table? As currently structured, each of these subgroups-State civil. state criminal. Federal Criminal and Federal Civil are completly independent of each other and there is no inter-relationship whatsoever. For all intents and purposes they are 4 seperate dbs. "
I think what you have said here, states how normalization could be sideways for your db. You are building a "relational database" if you have four "completely independent of each other and there is no inter-relationship whatsoever," then you've stated that the database is not relational cause there is no inter-relationship.
"Wouldn't I want to follow this structure and have 4 duedates tables-one for each subgroub since we plan on generating 4 seperate reports and keeping each supgroup completly seperate?"
The answer here should be no, cause if you do, then your creating redundant data. While the data may be referring to four different instances, the data is the same for all four instances, therefor is redundant. If you keep the "subgroups completely seperate" then your database is no longer relational.
"Second, It seems I am back where I started when I first posted. I need to determine how to create a table of related data for my due dates table. An example will illustrate the problem. To record the Statute of limitations I need the date of the accident, fall, surgery,contract or publication depending on whether it is auto accident, slip & fall, Med Mal, Breach of Contract or Defamation Action. I also need the clients date of birth because the date is extended for a minor. That is one set of dates."
Yes, you probably will be back to where you started but not completely back cause you've already indentified quite a few things now, that you didn't know when you started. Why would I know this? Been there, done that. I am also a victim of Mr. George pointing out that my database was not normalized and had to start again.
"If a Judge issues a order directing a response by a date certain I need to record the Judge, the date of his order, the due date and the response ordered.. Another due date.
If a pleading is filed I need to record who filed it, what it is and when a response is due. Another due date.
If a deposition is scheduled I need to record who is being deposed, who scheduled it, where it is and when.
If discovery requests are filed I need to record who filed them, what they are and when they are due.
If Medical records or Hospital records are requested I need to record from who and when so they can be tracked.
If a hearing or trial is scheduled I need to record when, where, who the judge is , the time, the purpose, if a hearing, whether or not witnesses have been notified , etc. "
All of the above should really help you to identify what is needed, but when it gets all separated out. It needs to relate to each other.
"I agree I need a duedates table. The problem I am having is that given the dissimilar nature of the information I don't see how they can all be put in one table. I wish they could. Maybe I don't understand normalization but if I put all this unrelated data in one table wouldn't I be violating Normalization principles? Thats why I initially asked if there was a way to send the information to a "central location" from the after update event as it was entered. I understand I would have some redundancy but I don't know that it is unnecessary redundancy. "
You may have already done this but really look at the fields themselves and you should start seeing a similar pattern. While you may have four different instances of what could happen, in the end they do relate to each other. My database I'm building is for our small family owned business, selling medical equipment. We have a ton of different types of equipment to sell, with vendors that sell it and a bunch of ways to get it paid for, but in the end it does boil down to us serving a patient and getting the right equipment, from the correct vendor and paid for (hopefully now days) by the correct funding source. When I sat down and looked at this it seemed like one big cobweb and I was tempted many times to split it all out but working with it long enough got me to see how everything really did relate back to one another.
As far as "maybe not understanding normalization," welcome aboard. It's not an easy subject to wrap your mind around. I've also noticed it's somewhat like a golf swing. There's only one way to hit the ball but there sure are a lot of opinions about how you could hit it better.
Good luck on your project and I hope I helped in some way.
Shane
