A Microsoft Office (Excel, Word) forum. OfficeFrustration

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.

Go Back   Home » OfficeFrustration forum » Microsoft Access » Database Design
Site Map Home Register Authors List Search Today's Posts Mark Forums Read  

I think I'm almost there...except for...



 
 
Thread Tools Display Modes
  #41  
Old May 24th, 2006, 04:19 PM posted to microsoft.public.access.tablesdbdesign
external usenet poster
 
Posts: n/a
Default I think I'm almost there...except for...

"Immanuel Sibero" wrote:

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.


Very succinct. I think I'm going to make that into a poster for my office.

  #42  
Old May 24th, 2006, 04:37 PM posted to microsoft.public.access.tablesdbdesign
external usenet poster
 
Posts: n/a
Default I think I'm almost there...except for...





mnature,


Very succinct. I think I'm going to make that into a poster for my

office.

I have a fish tank in my office :-)

I think you are the only one that got through to the OP. We all should thank
you for your persistence.
I have a feeling the OP will be back.

Immanuel Sibero




"mnature" wrote in message
...
"Immanuel Sibero" wrote:

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.


Very succinct. I think I'm going to make that into a poster for my

office.



  #43  
Old May 24th, 2006, 04:39 PM posted to microsoft.public.access.tablesdbdesign
external usenet poster
 
Posts: n/a
Default I think I'm almost there...except for...

My database is a lot simpler than you think.

Employee


Currentwork (what does this mean? My note: Are they working for the company or not)


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? My Note: I know it now!!!!)
MonthID (Again, why??? My note: same again)


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.)


My note: WeekID is in the xx/xx/xxxx format.

Department (no primary key? My note: Don't need one)


timehalfhrs (Why are you defining the type of hours in a field name? My note: Type of hours: simple Numerical format. How many overtime hours worked at 1*5 times the hourly fee


dbletimehrs (You are going to put in two types of hours within one record?)


My note: Type of hours: simple Numerical format. How many overtime hours
worked at twice the hourly fee. Yes I do have a key: weekID.


  #44  
Old May 24th, 2006, 04:43 PM posted to microsoft.public.access.tablesdbdesign
external usenet poster
 
Posts: n/a
Default I think I'm almost there...except for...

I've made it into a poster:

You find a starving man

First, try to teach him how to fish

If that fails, then give him a fish

If he is still starving,
the real problem could be
Not that he is starving
But, that he doesn't even know
What a fish is


  #45  
Old May 24th, 2006, 05:13 PM posted to microsoft.public.access.tablesdbdesign
external usenet poster
 
Posts: n/a
Default I think I'm almost there...except for...

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.)

My note: WeekID is in the xx/xx/xxxx format.


scubadiver, no matter what format WeekID is in, if it is declared a primary
key, then it is required to be unique. If you attempt to use the same WeekID
for two employees, the database will bring up a warning, and not allow you to
do that. So, how are you going to handle having more than one employee per
WeekID?
  #46  
Old May 25th, 2006, 01:08 PM posted to microsoft.public.access.tablesdbdesign
external usenet poster
 
Posts: n/a
Default I think I'm almost there...except for...


Jamie Collins wrote:
Craig Alexander Morrison wrote:
The best and most practical advice is learn how to normalise your data


I am of the opinion that 'Learn how to normalise your data' falls some
way short of the most practical advice. Actually, I consider it a
non-answer, right up there with 'Learn how to do DBMS design' and
'Learn how to program'.


In the interest of fairness, I trawled fir the ten most recent replies
mentioning normalization (although I admit to saving the best one until
last). Although none were very specific (would you believe it wasn't
until the eleventh that 3NF was name-checked g?), there are not as
many 'cringers' as I was expecting:

"a more normalized structure"

"isn't normalized"

"in need of normalization"

"Keep it well-normalized"

"properly normalized"

"a different normalized format"

"NOT the best normalized method"

"good normalization"

"a normalized union query"

"is not strictly normalized"

"search for normalisation on the web and you'll find the rules which
should be applied to a database in order to make it relational"

  #47  
Old May 25th, 2006, 02:56 PM posted to microsoft.public.access.tablesdbdesign
external usenet poster
 
Posts: n/a
Default I think I'm almost there...except for...

Jamie, you are bringing up some good points. Speaking of normalization as if
it were a self-evident expression is certainly not helping people.

However, there are a number of posts to this forum, where it is obvious that
these people have no experience in programming Access other than the ability
to click on an icon to open the program. Isn't it fair to say that if they
are sent off to search for information about normalization, that they will
probably stumble across other information about programming databases, and
thus become better able to do whatever project they want to do? In the case
of scubadiver, it would be better for everyone if he would go out and buy a
few beginner books about Access, and then actually read them.

I would like to ask you directly, then: What is the best way to talk to
someone who seems to be rather clueless about databases? Some people seem to
respond quite well to being told to study the subject, and come back a few
days later with some excellent questions. Some people respond well to actual
samples of what we think they need (learn by example). Some can be told to
think of each table as a separate subject, and intuitively grasp the concept
of normalization through that.

I look at it as a graded approach to the problem, depending on how the
problem is presented. Someone posts some tables, you mention they are in
need of normalization. They come back with different tables, and you realize
they have no idea what normalization is, so you tell them to go learn
normalization. They come back with even different tables, that are an even
worse design, so you post what you think their tables should look like
(basing that upon whatever clues they have given about what they are trying
to do). You also try to explain, in simple terms, what is meant by
normalization. By this point, they usually are starting to understand. But
not always.

So, is there a better way to proceed?

  #48  
Old May 25th, 2006, 03:34 PM posted to microsoft.public.access.tablesdbdesign
external usenet poster
 
Posts: n/a
Default I think I'm almost there...except for...


mnature wrote:
I would like to ask you directly, then: What is the best way to talk to
someone who seems to be rather clueless about databases?
is there a better way to proceed?


I can only repeat repeat what I have said up thread:

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 your recommended normal form.

[Use] phrases to make you advice more practical:

"By doing x you have violated 1NF."

"You could y and your design will be in 3NF."

Jamie.

PS ...or do as I do and don't give advice pertaining to normalization
g.

--

 




Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is Off
HTML code is Off
Forum Jump


All times are GMT +1. The time now is 07:36 PM.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright ©2004-2024 OfficeFrustration.
The comments are property of their posters.