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

[Hal]

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

 

[Jeff Boyce]

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

 

[Jeff Boyce]

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]

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?

 

[Hal]

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?

 

[Jeff Boyce]

Hal

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

Regards

Jeff Boyce
Microsoft Office/Access MVP

 

[Jeff Boyce]

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]

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.

 

[Hal]

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.

 

[Jeff Boyce]

Hal

see comment in-line below...

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.

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

 

[Jeff Boyce]

Hal

see comment in-line below...

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.

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

 

[Hal]

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

Hal

see comment in-line below...

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.

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

 

[Hal]

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

Hal

see comment in-line below...

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.

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