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. |
|
|
Thread Tools | Display Modes |
#1
|
|||
|
|||
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
|
|||
|
|||
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
|
|||
|
|||
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
|
|||
|
|||
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
|
|||
|
|||
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
|
|||
|
|||
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
|
|||
|
|||
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 | |
|
|