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  

Multivalue Fields and Normalization



 
 
Thread Tools Display Modes
  #11  
Old February 5th, 2009, 04:06 AM posted to microsoft.public.access.tablesdbdesign
Brian Carlson
external usenet poster
 
Posts: 49
Default Multivalue Fields and Normalization

Allen:

I am an extreme novice to this, but I will give it a whirl. Where would I
find the Northwinds sample database so I could take a ganderand see if I
could decipher it? Thanks for the help.

Brian

"Allen Browne" wrote:

So you are investigating alternatives to sub-subforms, Brian?

In the old Northwind sample database, there's a form named Customer Orders.
It has a subform where you select an order. When you do, the details of that
order appear in another subform below it. This is not a sub-subform (i.e.
both subform sit directly on the main form.) Its Link Master Fields is:
[Customer Orders Subform1].Form![OrderID]

I've used a modified version of that approach several times, so when you
click on a record in one continuous subform, the details are displayed in
the other continuous subform beside it.

If the sub-subform is for display purposes only, another option might be to
place a list box in the Form Footer of your continuous subform.

For me, those are preferable to MVFs. For you, take your pick. :-)

--
Allen Browne - Microsoft MVP. Perth, Western Australia
Tips for Access users - http://allenbrowne.com/tips.html
Reply to group, rather than allenbrowne at mvps dot org.

"Brian Carlson" wrote in message
...
You have touched on the crux of my problem. I am using a main form with
multiple subforms. One of these subforms has a subform underneath it.
However, the first tier subform will not allow continous view, which is
causing me problems.



  #12  
Old February 5th, 2009, 04:06 AM posted to microsoft.public.access.tablesdbdesign
Brian Carlson
external usenet poster
 
Posts: 49
Default Multivalue Fields and Normalization

John:

If you say it would be a little hassle, for me it would be near impossible.
I am not up to that level of sophistication...I just figured out
subforms...some what.

One follow-up question: It seems that having a subform to a form should
create a relationship between the two tables represented, but looking at the
relationship windows this is not the case...am I missing something?


Brian

"John W. Vinson" wrote:

On Wed, 4 Feb 2009 16:40:00 -0800, Brian Carlson
wrote:

John:
You have touched on the crux of my problem. I am using a main form with
multiple subforms. One of these subforms has a subform underneath it.
However, the first tier subform will not allow continous view, which is
causing me problems.


You can use "correlated subforms" with a little bit of hassle. For example you
can put a textbox on Mainform with a control source

=SubformA.Form!LinkingFieldControl

and use that textbox as the MasterLink field for SubformB, to make SubformB
dependent on the currently selected record on SubformA.
--

John W. Vinson [MVP]

  #13  
Old February 5th, 2009, 05:41 AM posted to microsoft.public.access.tablesdbdesign
Allen Browne
external usenet poster
 
Posts: 11,706
Default Multivalue Fields and Normalization

If you have the default install of Access 2003 or earlier, you will find it
on your local hard disk, in your Program Files, under Microsoft Office, if
you follow the tree down.

--
Allen Browne - Microsoft MVP. Perth, Western Australia
Tips for Access users - http://allenbrowne.com/tips.html
Reply to group, rather than allenbrowne at mvps dot org.

"Brian Carlson" wrote in message
...
Allen:

I am an extreme novice to this, but I will give it a whirl. Where would I
find the Northwinds sample database so I could take a ganderand see if I
could decipher it? Thanks for the help.

Brian

"Allen Browne" wrote:

So you are investigating alternatives to sub-subforms, Brian?

In the old Northwind sample database, there's a form named Customer
Orders.
It has a subform where you select an order. When you do, the details of
that
order appear in another subform below it. This is not a sub-subform (i.e.
both subform sit directly on the main form.) Its Link Master Fields is:
[Customer Orders Subform1].Form![OrderID]

I've used a modified version of that approach several times, so when you
click on a record in one continuous subform, the details are displayed in
the other continuous subform beside it.

If the sub-subform is for display purposes only, another option might be
to
place a list box in the Form Footer of your continuous subform.

For me, those are preferable to MVFs. For you, take your pick. :-)

"Brian Carlson" wrote in message
...
You have touched on the crux of my problem. I am using a main form
with
multiple subforms. One of these subforms has a subform underneath it.
However, the first tier subform will not allow continous view, which is
causing me problems.


  #14  
Old February 5th, 2009, 06:36 AM posted to microsoft.public.access.tablesdbdesign
John W. Vinson
external usenet poster
 
Posts: 18,261
Default Multivalue Fields and Normalization

On Wed, 4 Feb 2009 19:06:24 -0800, Brian Carlson
wrote:

John:

If you say it would be a little hassle, for me it would be near impossible.
I am not up to that level of sophistication...I just figured out
subforms...some what.


If you'll post the names of the two subform controls and the name of the
fields that link them, one of us can give you precise step by step
instructions.

One follow-up question: It seems that having a subform to a form should
create a relationship between the two tables represented, but looking at the
relationship windows this is not the case...am I missing something?


Yes. You're missing the fact that tables are PRIMARY, and forms are *nothing
but tools*, windows that let you interact with the data in table. Forms don't
have relationships; tables do. The form may well reflect the relationship
between the tables, but that's actually optional. Nothing you do to the
structure of a form affects the underlying tables in any way.
--

John W. Vinson [MVP]
  #15  
Old February 5th, 2009, 05:53 PM posted to microsoft.public.access.tablesdbdesign
Jeff Boyce
external usenet poster
 
Posts: 8,621
Default Multivalue Fields and Normalization

Mark

I'm with you ... unless an application is easy to use, it's ... 'shelfware'.

But a well-designed graphical user interface would never expose end users to
the underlying table structure, and wouldn't require them to know anything
about relational databases or normalization.

From my experience, "Easy ... is HARD!". Easy to use (an end-user
assessment) requires considerable work from the developer to hide all the
intricacies and protect the user from ever making an 'unnormalized' entry.
Doing that is NOT "easy to set up".

And since most end-users view data entry as a necessary evil in managing
some process, it is as critically important that the end-users have an easy
way to get information back out. This is where I believe the use of
multi-valued fields starts creating difficulties.

Good luck!

Regards

Jeff Boyce
Microsoft Office/Access MVP

"Mark" wrote in message
...
Sure, by "nice" I mean they are both easy to set up and easy to use. Most
databases are designed with other end users in mind besides the database
creator. In most cases, these end users aren't as knowledgeable about
proper
database design and use, so it is important to design the database and its
interface in as simplistic a fashion as possible, both so that it's easy
for
them to use and so that they don't "screw it up" by entering unnormalized
data. Rather than making users create entries themselves in a separate
related table, MVF's simply allow them to choose the applicable values
from a
list of choices. It is more of an intuitive process than the alternative.

Mark

"Jeff Boyce" wrote:

Define "nice" ... ?easy to set up ... ?easy to make do what you want

Regards

Jeff Boyce
Microsoft Office/Access MVP

"Mark" wrote in message
...
While the other posters' points are very true, I do think multi-valued
fields
are great for small databases that are never destined to be anything
larger
than Access. If there's any chance that you're going to have to
transition
this database to another system, save yourself the trouble and avoid
MVF's.
However, if this is something small, maybe for an individual department
or
office, I've found multi-valued fields to be a nice feature.

Mark

"Brian Carlson" wrote:

In general are multivalue fields a bad idea to use? I am trying to
ensure my
small database is normalized as possible, but it seems that I every
table
I
try to create ends us breaking into smaller related tables and these
having
to be additionally broken. It seems that multivalue fields will allow
me
to
eliminate some of this, but I do not want to lose functionality for
conveniance. Thanks in advance.






  #16  
Old February 6th, 2009, 12:46 AM posted to microsoft.public.access.tablesdbdesign
Brian Carlson
external usenet poster
 
Posts: 49
Default Multivalue Fields and Normalization

John:


I am not sure if your original suggestion is the same as or a slight
variation of Allen's, but in either case. I curretnly have a table called
t_CrewDaily. This table has the following fields: CrewDate, CrewName,
CrewLabor, and CrewEquipment. The CrewEquipment field is currently the
multivalue field, which is being looked up from another table t_Equipment. I
would like to get rid of the multivalue field without losing the option to
have t_Crewdaily as a continous subform, yet still have the option have the
CrewEquipment field as a lookup. I am not sure if this is clear, but in
either case thank you in advance for taking the time to assist me.

Brian

"John W. Vinson" wrote:

On Wed, 4 Feb 2009 19:06:24 -0800, Brian Carlson
wrote:

John:

If you say it would be a little hassle, for me it would be near impossible.
I am not up to that level of sophistication...I just figured out
subforms...some what.


If you'll post the names of the two subform controls and the name of the
fields that link them, one of us can give you precise step by step
instructions.

One follow-up question: It seems that having a subform to a form should
create a relationship between the two tables represented, but looking at the
relationship windows this is not the case...am I missing something?


Yes. You're missing the fact that tables are PRIMARY, and forms are *nothing
but tools*, windows that let you interact with the data in table. Forms don't
have relationships; tables do. The form may well reflect the relationship
between the tables, but that's actually optional. Nothing you do to the
structure of a form affects the underlying tables in any way.
--

John W. Vinson [MVP]

 




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 08:17 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.