G
Guest
Immanuel Sibero said:
Very succinct. I think I'm going to make that into a poster for my office.
Very succinct. I think I'm going to make that into a poster for my office.
I
Immanuel Sibero
mnature,
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
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
G
Guest
My database is a lot simpler than you think.
My note: WeekID is in the xx/xx/xxxx format.
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.
My note: WeekID is in the xx/xx/xxxx format.
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.
G
Guest
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
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
G
Guest
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.)
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?
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.)
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?
J
Jamie Collins
Jamie said:
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"
G
Guest
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?
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?
J
Jamie Collins
mnature said:
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>.
--