If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
Thread Tools | Display Modes |
#31
|
|||
|
|||
I think I'm almost there...except for...
The advice was practical; the analogies were to demonstrate that.
I'm not so sure that your analogies were entirely fair to the OP. The definition of practical in your message seems to be short term and limited. Why would it be -impractical- for the OP to learn about normalistion? After all the OP is not designing an insignificant hobby database but one that has financial data and therefore financial implications for their company, why not do it right, even if that means they cannot do it right now? -- Slainte Craig Alexander Morrison Crawbridge Data (Scotland) Limited "Jamie Collins" wrote in message ups.com... Craig Alexander Morrison wrote: Sure you can give them a fish or two but if they learn how to fish so much the better. I can go with the fish analogy g. This guy is saying to you, the well-fed fish eater, "I'm dangling some string into my bath but I don't seem to be getting any bites" and you're shouting, "LEARN HOW TO FISH". Not practical advice. I can go with the car analogy g. This guy is saying to you, the Ferrari owner, "I'm thinking of buying a unicycle to get me from A to B" and you're shouting, "LEARN HOW TO CHOOSE A CAR". Not practical advice. Analogies: not practical advice. Perhaps a brief explanation of each normal form (the rules and the tests) would help Now you're thinking along the right lines. While you're about it, make it *practical* for the OP by relating it to their spec. Jamie. -- |
#32
|
|||
|
|||
I think I'm almost there...except for...
Craig Alexander Morrison wrote: Now you're thinking along the right lines. While you're about it, make it *practical* for the OP by relating it to their spec. The advice was practical; the analogies were to demonstrate that. I again urge you to go with your earlier idea e.g. explain in which normal form (if any) you think the OPs design is currently, which of the normal forms he should be aiming for and - to give it the practical element lacking thus far - what you think he needs to do to get his design to to your recommended normal form. Jamie. -- |
#33
|
|||
|
|||
I think I'm almost there...except for...
I would urge you to read my earlier replies and others on the subject of
understanding the problem domain. Why do you appear to believe it is impractical to learn about normalisation? -- Slainte Craig Alexander Morrison Crawbridge Data (Scotland) Limited "Jamie Collins" wrote in message oups.com... Craig Alexander Morrison wrote: Now you're thinking along the right lines. While you're about it, make it *practical* for the OP by relating it to their spec. The advice was practical; the analogies were to demonstrate that. I again urge you to go with your earlier idea e.g. explain in which normal form (if any) you think the OPs design is currently, which of the normal forms he should be aiming for and - to give it the practical element lacking thus far - what you think he needs to do to get his design to to your recommended normal form. Jamie. -- |
#34
|
|||
|
|||
I think I'm almost there...except for...
DK/NF is the goal, 3NF/BCNF is acceptable in most situations, but that is
accepted convention. Do you think you have enough information from the OP to tell me the answer to your own question? -- Slainte Craig Alexander Morrison Crawbridge Data (Scotland) Limited "Jamie Collins" wrote in message oups.com... Craig Alexander Morrison wrote: Now you're thinking along the right lines. While you're about it, make it *practical* for the OP by relating it to their spec. The advice was practical; the analogies were to demonstrate that. I again urge you to go with your earlier idea e.g. explain in which normal form (if any) you think the OPs design is currently, which of the normal forms he should be aiming for and - to give it the practical element lacking thus far - what you think he needs to do to get his design to to your recommended normal form. Jamie. -- |
#35
|
|||
|
|||
I think I'm almost there...except for...
I think I have cracked it.
Well, in a word: NO. I still need to do some tests and some slight modifications Won't take many tests for you to find that this just won't work. And it isn't just slight modifications that you need. I have identified a couple of problems but I haven't changed the fields too much from what I stated originally I know you haven't changed the fields too much from what you stated originally. I'm not sure why you haven't changed them. You have been presented with a number of different ways of normalizing your tables, in order for your database to just simply work. It will not work in this form that you have posted. Employee EmployeeID (PK) EmployeeName Currentwork (what does this mean?) Workstatus HourRate Calender EmployeeID (FK) YearID (Why are you putting this in? Why not just have a simple date, and extrapolate whatever you want from that date?) MonthID (Again, why???) WeekID (PK) (You cannot make this a true week-of-the-year number, and also have it as the primary key. Your database fails with this particular field alone. As soon as you start putting in data, that should become obvious.) Department (no primary key?) weekID (FK) Dept Subdept Costcentre Contracthrs timehalfhrs (Why are you defining the type of hours in a field name?) dbletimehrs (You are going to put in two types of hours within one record? Plus, you don't have a reasonable foreign key to relate these hours back to any particular week or person.) I've posted suggestions before. I will not do that here. But this will not work, so you need to try reshuffling everything again. |
#36
|
|||
|
|||
I think I'm almost there...except for...
I again urge you to go with your earlier idea e.g. explain in which
normal form (if any) you think the OPs design is currently, which of Sorry should have kept this all in a single message but... It would be difficult not to be in 1NF, I am sure you would know this. It was your idea to delve into the user requirements and apply them to the rules and tests of normalisation my idea was that the OP should learn the rules and tests so that they can apply them to the user requirements themselves. I am happy to post those rules and tests and even the preamble to the normalisation process, however these are available from many sources already. -- Slainte Craig Alexander Morrison Crawbridge Data (Scotland) Limited "Jamie Collins" wrote in message oups.com... |
#37
|
|||
|
|||
I think I'm almost there...except for...
"Jamie Collins" wrote:
I again urge you to go with your earlier idea e.g. explain in which normal form (if any) you think the OPs design is currently, which of the normal forms he should be aiming for and - to give it the practical element lacking thus far - what you think he needs to do to get his design to to your recommended normal form. Jamie. Jamie and Craig, I have been trying to explain things to scubadiver. I'm not in the same class as you two on understanding database design, I'm more of a semi-talented beginner about all of this. But I've tried to give scubadiver some good basic advice, and he won't listen. And his database design doesn't get any better (his latest is actually a regression). I've enjoyed your philosophical exchange on how to guide a clueless beginner into designing a reasonable database. I'd like to invite both of you to just jump in and try to help this poor schlimazel, each with your own special philosophy of how to help a beginner. Please. Pretty please. Your combined wisdom and knowledge would be an inspiration to us all. |
#38
|
|||
|
|||
I think I'm almost there...except for...
Well now I have been challenged by Jamie and asked nicely by you.
I will review all of the OPs threads in the last 14 days and try to document what I believe they are trying to achieve and what the problems may be. I will add this caveat - that Database Design by Email is a very dangerous exercise but I will detail any assumptions I make that would affect the result. In other words the answer maybe wrong for the OP but right for the assumptions that have been made about the OP's user requirements and problem domain. These assumptions are normally questions you would be asking the end user about how they use and would want to use the data as this affects the structures required. -- Slainte Craig Alexander Morrison Crawbridge Data (Scotland) Limited "mnature" wrote in message ... "Jamie Collins" wrote: I again urge you to go with your earlier idea e.g. explain in which normal form (if any) you think the OPs design is currently, which of the normal forms he should be aiming for and - to give it the practical element lacking thus far - what you think he needs to do to get his design to to your recommended normal form. Jamie. Jamie and Craig, I have been trying to explain things to scubadiver. I'm not in the same class as you two on understanding database design, I'm more of a semi-talented beginner about all of this. But I've tried to give scubadiver some good basic advice, and he won't listen. And his database design doesn't get any better (his latest is actually a regression). I've enjoyed your philosophical exchange on how to guide a clueless beginner into designing a reasonable database. I'd like to invite both of you to just jump in and try to help this poor schlimazel, each with your own special philosophy of how to help a beginner. Please. Pretty please. Your combined wisdom and knowledge would be an inspiration to us all. |
#39
|
|||
|
|||
I think I'm almost there...except for...
"Craig Alexander Morrison" wrote:
Well now I have been challenged by Jamie and asked nicely by you. I will review all of the OPs threads in the last 14 days and try to document what I believe they are trying to achieve and what the problems may be. I will add this caveat - that Database Design by Email is a very dangerous exercise but I will detail any assumptions I make that would affect the result. The original poster may have given up on us. He just posted a separate thread saying that none of us are very helpful and that his database is now working (he has posted that message several times before, though). One of the problems with helping scubadiver has been his total lack of information of what he is really trying to do. I'm not sure if he is tracking payroll paid or just hours worked, whether he has departments and/or subdepartments. He is obsessed with tracking per week and doesn't want to put in dates. He randomly chooses a field to be a primary key, and then argues when told he shouldn't do that. I'm almost tempted to say that this is a college prank, where someone who really does know better about databases is trying to set a record of how many frivolous posts they can generate before people give up on them. I have a hard time believing that someone could really be this stubborn about not learning. |
#40
|
|||
|
|||
I think I'm almost there...except for...
mnature,
I can sympathize with you. I tried to help but the OP didnt even acknowledge my posts and I don't know why he has not acknowledged my posts.... hell, I dont know why I'm still posting on this thread trying to help him (I do have a demanding and full time job... working on relational database design no less g). I think Jamie and Craig's arguments are both valid, the circumstances would eventually determine which one is effective. Each circumstance is different. The OP is quite a challenge because my posts trying to help him have actually taken both Jamie's and Craig's methods. I initially posted to say that he plain and simple just needs to *brush up* on relational database design (incl. normalization). OP didnt respond to this. I then tried to critique the OP's own design by poking holes on it and pointing out that his tables are not normalized and the reasons why those tables are not normalized. Still, the OP didnt not respond. I dont even know if he reads my posts. As I stated before in my other post, I think this is a case where the OP knows enough about relational database design to realize that he needs help, but he doesnt know enough about it to recognize a solution if the solution bit him in the eye. This makes it very difficult to help him. To use Craig's fish analogy... You first try to teach him how to fish, if that fails then give him a fish. The problem is, he doesnt even know it's a fish. Immanuel Sibero "mnature" wrote in message ... "Jamie Collins" wrote: I again urge you to go with your earlier idea e.g. explain in which normal form (if any) you think the OPs design is currently, which of the normal forms he should be aiming for and - to give it the practical element lacking thus far - what you think he needs to do to get his design to to your recommended normal form. Jamie. Jamie and Craig, I have been trying to explain things to scubadiver. I'm not in the same class as you two on understanding database design, I'm more of a semi-talented beginner about all of this. But I've tried to give scubadiver some good basic advice, and he won't listen. And his database design doesn't get any better (his latest is actually a regression). I've enjoyed your philosophical exchange on how to guide a clueless beginner into designing a reasonable database. I'd like to invite both of you to just jump in and try to help this poor schlimazel, each with your own special philosophy of how to help a beginner. Please. Pretty please. Your combined wisdom and knowledge would be an inspiration to us all. |
Thread Tools | |
Display Modes | |
|
|