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  

Relating Multiple tables with one-to-many & many-to-many relations



 
 
Thread Tools Display Modes
  #1  
Old May 12th, 2009, 03:52 PM posted to microsoft.public.access.tablesdbdesign
Hal
external usenet poster
 
Posts: 127
Default Relating Multiple tables with one-to-many & many-to-many relations

I'm trying to construct a database the relates a building info table with a
utility accounts table, utility provider table, utility type table, and
individual tables for each utility account the will hold monthly transaction
data. I've successfully related the building table and the utility account
table together, and have related the supplier table and utility type table as
well. I have not been able to properly connect the individual utility account
tables to either the "building" table or the "accounts" table.

I get a "too many indexes" error message.
Any help on this issue. Please
--
Thanks, Hal
  #2  
Old May 12th, 2009, 04:04 PM posted to microsoft.public.access.tablesdbdesign
Jeff Boyce
external usenet poster
 
Posts: 8,621
Default Relating Multiple tables with one-to-many & many-to-many relations

Hal

Why? As in "why do you believe you need that many tables?" In a relational
database like Access, you need one table per "entity". What entities
(things about which you wish to keep data) do you have?

One phrase in particular caused me to ask ... "... and individual tables for
each utility account ... hold monthly transaction data." If I'm not
misinterpreting, this would mean that every single account gets its own
transaction table. That would be a SPREADSHEET, not a relational database
table.

More info, please...

Regards

Jeff Boyce
Microsoft Office/Access MVP

"Hal" wrote in message
...
I'm trying to construct a database the relates a building info table with
a
utility accounts table, utility provider table, utility type table, and
individual tables for each utility account the will hold monthly
transaction
data. I've successfully related the building table and the utility account
table together, and have related the supplier table and utility type table
as
well. I have not been able to properly connect the individual utility
account
tables to either the "building" table or the "accounts" table.

I get a "too many indexes" error message.
Any help on this issue. Please
--
Thanks, Hal



  #3  
Old May 12th, 2009, 04:34 PM posted to microsoft.public.access.tablesdbdesign
Hal
external usenet poster
 
Posts: 127
Default Relating Multiple tables with one-to-many & many-to-many relat

Jeff, thanks for the reply. Somehow I assumed that I needed to separate the
"account transaction" data for each utility type since not all of the data,
e.g. "gallons", kWh, therms, for is the same.
Are you recommending that I use one table to hold all of the transaction
data, and have the database "relate" the individual transaction to the
"building/utiltiy" tables?

--
Thanks, Hal


"Jeff Boyce" wrote:

Hal

Why? As in "why do you believe you need that many tables?" In a relational
database like Access, you need one table per "entity". What entities
(things about which you wish to keep data) do you have?

One phrase in particular caused me to ask ... "... and individual tables for
each utility account ... hold monthly transaction data." If I'm not
misinterpreting, this would mean that every single account gets its own
transaction table. That would be a SPREADSHEET, not a relational database
table.

More info, please...

Regards

Jeff Boyce
Microsoft Office/Access MVP

"Hal" wrote in message
...
I'm trying to construct a database the relates a building info table with
a
utility accounts table, utility provider table, utility type table, and
individual tables for each utility account the will hold monthly
transaction
data. I've successfully related the building table and the utility account
table together, and have related the supplier table and utility type table
as
well. I have not been able to properly connect the individual utility
account
tables to either the "building" table or the "accounts" table.

I get a "too many indexes" error message.
Any help on this issue. Please
--
Thanks, Hal




  #4  
Old May 12th, 2009, 07:34 PM posted to microsoft.public.access.tablesdbdesign
Jeff Boyce
external usenet poster
 
Posts: 8,621
Default Relating Multiple tables with one-to-many & many-to-many relat

Hal

I don't understand your situation well enough to tell you what you might
need yet.

Regards

Jeff Boyce
Microsoft Office/Access MVP

"Hal" wrote in message
...
Jeff, thanks for the reply. Somehow I assumed that I needed to separate
the
"account transaction" data for each utility type since not all of the
data,
e.g. "gallons", kWh, therms, for is the same.
Are you recommending that I use one table to hold all of the transaction
data, and have the database "relate" the individual transaction to the
"building/utiltiy" tables?

--
Thanks, Hal


"Jeff Boyce" wrote:

Hal

Why? As in "why do you believe you need that many tables?" In a
relational
database like Access, you need one table per "entity". What entities
(things about which you wish to keep data) do you have?

One phrase in particular caused me to ask ... "... and individual tables
for
each utility account ... hold monthly transaction data." If I'm not
misinterpreting, this would mean that every single account gets its own
transaction table. That would be a SPREADSHEET, not a relational
database
table.

More info, please...

Regards

Jeff Boyce
Microsoft Office/Access MVP

"Hal" wrote in message
...
I'm trying to construct a database the relates a building info table
with
a
utility accounts table, utility provider table, utility type table, and
individual tables for each utility account the will hold monthly
transaction
data. I've successfully related the building table and the utility
account
table together, and have related the supplier table and utility type
table
as
well. I have not been able to properly connect the individual utility
account
tables to either the "building" table or the "accounts" table.

I get a "too many indexes" error message.
Any help on this issue. Please
--
Thanks, Hal






  #5  
Old May 12th, 2009, 08:08 PM posted to microsoft.public.access.tablesdbdesign
Hal
external usenet poster
 
Posts: 127
Default Relating Multiple tables with one-to-many & many-to-many relat

Jeff, again thanks. Here's what I have:
Building table= BuildingNumber (alphanum) key, address, property manager,
accountNumber (alphanum), supplierID. (one-to-many relationship to
"BuildingNumber).
Utility Accounts Table= SupplierID, (number), BuildingID, SupplierID,
AccountNumber, meterNumber, +accounting fields.
Utiltiy Supplier Table= related to Utility Account Table (one-to-Many
through "supplierID).
Utility Category Table= related to Utility Supplier Table (one-to-many
throught "utilityID")
I'm trying to capture all of the utiltiy transactions; monthly consumption
(in kwh, gallons, therms, btu, etc for each type of utility) and cost, and be
able to show those transaction by building or account using the
"AccountNumber"
Based upon what you've said so far, I may not be thinking about these
relationships in a proper context. I'm learning the program and have a need
to manipulate all of these data elements.
Thanks for your thinking and time. Any insight to get me on track will be
helpful.
--
Thanks, Hal


"Jeff Boyce" wrote:

Hal

I don't understand your situation well enough to tell you what you might
need yet.

Regards

Jeff Boyce
Microsoft Office/Access MVP

"Hal" wrote in message
...
Jeff, thanks for the reply. Somehow I assumed that I needed to separate
the
"account transaction" data for each utility type since not all of the
data,
e.g. "gallons", kWh, therms, for is the same.
Are you recommending that I use one table to hold all of the transaction
data, and have the database "relate" the individual transaction to the
"building/utiltiy" tables?

--
Thanks, Hal


"Jeff Boyce" wrote:

Hal

Why? As in "why do you believe you need that many tables?" In a
relational
database like Access, you need one table per "entity". What entities
(things about which you wish to keep data) do you have?

One phrase in particular caused me to ask ... "... and individual tables
for
each utility account ... hold monthly transaction data." If I'm not
misinterpreting, this would mean that every single account gets its own
transaction table. That would be a SPREADSHEET, not a relational
database
table.

More info, please...

Regards

Jeff Boyce
Microsoft Office/Access MVP

"Hal" wrote in message
...
I'm trying to construct a database the relates a building info table
with
a
utility accounts table, utility provider table, utility type table, and
individual tables for each utility account the will hold monthly
transaction
data. I've successfully related the building table and the utility
account
table together, and have related the supplier table and utility type
table
as
well. I have not been able to properly connect the individual utility
account
tables to either the "building" table or the "accounts" table.

I get a "too many indexes" error message.
Any help on this issue. Please
--
Thanks, Hal






  #6  
Old May 12th, 2009, 09:34 PM posted to microsoft.public.access.tablesdbdesign
Jeff Boyce
external usenet poster
 
Posts: 8,621
Default Relating Multiple tables with one-to-many & many-to-many relat

Hal

see comment in-line below...

"Hal" wrote in message
...
Jeff, again thanks. Here's what I have:
Building table= BuildingNumber (alphanum) key, address, property manager,
accountNumber (alphanum), supplierID. (one-to-many relationship to
"BuildingNumber).


I don't understand. How can this table have a one-to-many relationship to
BuildingNumber? Tables have relationships to other tables. I also don't
understand how a "building" can have a "supplier" (supplierID). And I don't
understand your situation well enough to know how [accountNumber] relates
.... is it an attribute of the building itself, the [property manager], or
????

Utility Accounts Table= SupplierID, (number), BuildingID, SupplierID,
AccountNumber, meterNumber, +accounting fields.


How come [AccountNumber] and [SupplierID] (twice?) show up in this table,
too? A well-normalized relational database doesn't need duplicated data
(same data in multiple tables).

Utiltiy Supplier Table= related to Utility Account Table (one-to-Many
through "supplierID).


What does this table hold? ?Attributes of Utility Suppliers?

Utility Category Table= related to Utility Supplier Table (one-to-many
throught "utilityID")


If this really contains "utility categories", then it wouldn't be related
via [UtilityID], it would be related via a [UtilityCategoryID] field.

I'm trying to capture all of the utiltiy transactions; monthly consumption
(in kwh, gallons, therms, btu, etc for each type of utility) and cost, and
be
able to show those transaction by building or account using the
"AccountNumber"
Based upon what you've said so far, I may not be thinking about these
relationships in a proper context. I'm learning the program and have a
need
to manipulate all of these data elements.
Thanks for your thinking and time. Any insight to get me on track will be
helpful.
--
Thanks, Hal


I get the impression that the table structure you're using is meaningful,
but I don't get the meaning!g

To get the best use of Access' relationally-oriented features/functions, you
have to 'feed' it well-normalized data. If you don't, you'll pay later. So
it's a "pay now (learn normalization) or pay later (come up with kludges and
workarounds)" situation.

If this were mine, I'd turn off the PC, grab paper and pencil, and write
down what I believe the entities to be. Clearly, you have buildings ... so
that's probably one of the entities. And you have utilities (do you mean
water, sewer, electrical, etc., or Power Company A, Power Company B, ...?).
So jot down just the names of the entities.

Then draw lines between them and jot down statements like:

One building can have multiple utilities.

One utility can serve multiple buildings.

One building can have monthly transactions for each (of its multiple)
utility(ies).

NOTE -- I don't know if any of these statements are true -- only you do!
Write down what you know.

Then use those statements to fill in the relationships (along the lines)
between/among your entities.

Now add attributes to each entity. I'd be willing to bet that Buildings do
not have an attribute of "supplier" (but hey, I don't know your situation!).

Try the above and post back with what you come up with. There's a fairly
steep learning curve for relational and normalization, so again, it's "pay
now or ....!

Regards

Jeff Boyce
Microsoft Office/Access MVP




  #7  
Old May 13th, 2009, 07:14 PM posted to microsoft.public.access.tablesdbdesign
Hal
external usenet poster
 
Posts: 127
Default Relating Multiple tables with one-to-many & many-to-many relat

Jeff, sorry for the confusion. From the beginning... I have a buildings table
with the building number as unique ID (alphanum); a Utility account table
listing all of the utility accounts for all buildings; a utiltiy provider
table with all of the utility providers listed; a table for the utility types
(oil, gas, elect, steam, water). The one-to-many relationships are e.g. one
building + many accounts; one supplier + many accounts; one utility type +
many accounts. My idea was to have individual tables for each account that
would hold the transaction data: cost, consumption (i.e.#kwh) month, year,
rather than one massive table that would hold all transaction data for all
accounts. Am I thinking about this the wrong way?
Hope this is clearer. Thanks
--
Thanks, Hal


"Jeff Boyce" wrote:

Hal

see comment in-line below...

"Hal" wrote in message
...
Jeff, again thanks. Here's what I have:
Building table= BuildingNumber (alphanum) key, address, property manager,
accountNumber (alphanum), supplierID. (one-to-many relationship to
"BuildingNumber).


I don't understand. How can this table have a one-to-many relationship to
BuildingNumber? Tables have relationships to other tables. I also don't
understand how a "building" can have a "supplier" (supplierID). And I don't
understand your situation well enough to know how [accountNumber] relates
.... is it an attribute of the building itself, the [property manager], or
????

Utility Accounts Table= SupplierID, (number), BuildingID, SupplierID,
AccountNumber, meterNumber, +accounting fields.


How come [AccountNumber] and [SupplierID] (twice?) show up in this table,
too? A well-normalized relational database doesn't need duplicated data
(same data in multiple tables).

Utiltiy Supplier Table= related to Utility Account Table (one-to-Many
through "supplierID).


What does this table hold? ?Attributes of Utility Suppliers?

Utility Category Table= related to Utility Supplier Table (one-to-many
throught "utilityID")


If this really contains "utility categories", then it wouldn't be related
via [UtilityID], it would be related via a [UtilityCategoryID] field.

I'm trying to capture all of the utiltiy transactions; monthly consumption
(in kwh, gallons, therms, btu, etc for each type of utility) and cost, and
be
able to show those transaction by building or account using the
"AccountNumber"
Based upon what you've said so far, I may not be thinking about these
relationships in a proper context. I'm learning the program and have a
need
to manipulate all of these data elements.
Thanks for your thinking and time. Any insight to get me on track will be
helpful.
--
Thanks, Hal


I get the impression that the table structure you're using is meaningful,
but I don't get the meaning!g

To get the best use of Access' relationally-oriented features/functions, you
have to 'feed' it well-normalized data. If you don't, you'll pay later. So
it's a "pay now (learn normalization) or pay later (come up with kludges and
workarounds)" situation.

If this were mine, I'd turn off the PC, grab paper and pencil, and write
down what I believe the entities to be. Clearly, you have buildings ... so
that's probably one of the entities. And you have utilities (do you mean
water, sewer, electrical, etc., or Power Company A, Power Company B, ...?).
So jot down just the names of the entities.

Then draw lines between them and jot down statements like:

One building can have multiple utilities.

One utility can serve multiple buildings.

One building can have monthly transactions for each (of its multiple)
utility(ies).

NOTE -- I don't know if any of these statements are true -- only you do!
Write down what you know.

Then use those statements to fill in the relationships (along the lines)
between/among your entities.

Now add attributes to each entity. I'd be willing to bet that Buildings do
not have an attribute of "supplier" (but hey, I don't know your situation!).

Try the above and post back with what you come up with. There's a fairly
steep learning curve for relational and normalization, so again, it's "pay
now or ....!

Regards

Jeff Boyce
Microsoft Office/Access 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 01:09 AM.


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