Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations gkittelson on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Three Dimensional Table (3D 3)

Status
Not open for further replies.

LARiot

Programmer
Feb 7, 2007
232
Are three dimensional tables available in Access? I have data that has a long list of elements, each element has two corresponding fields (points and weight).

If not I would have to create two tables (one for points, the other for weight) each with long lists of fields (corresponding to the element). The other way would be to create one table with a field called Elements, but they would repeat when a new record occurs.

Thanks.
 
In some sense a database table is like a set of n-tuples in n-dimensional space. Each row is a point in that space. The coordinates of the point are the values of the n-tuple, that is, the row of values in the table.

Given that I would think that a table with two columns, points and weight, and with one row for each element would store the data.

Generally speaking, it is standard practice to have a third column which is the unique identifier for the row, the primary key. This is not thought of as a dimension in the space, more as the name of the point. And it is handy for linking the row to another table which might have associations or relationships with the points.

How is your requirement different than this?
 
What about a table with 3 columns, like this ?
Elements (PK)
points
weight

Hope This Helps, PH.
Want to get great answers to your Tek-Tips questions? Have a look at FAQ219-2884 or FAQ181-2886
 
I think PHV has the right idea. You would have a base table called Element. Then your table would look like:

Element Table
-------------
ElementID (primary key)
Element attribute #1
Element attribute #2
etc.


Summary Table
-------------
TableID (a generated primary key)
ElementID (foreign key to Element table)
Points
Weight


-------------------------
The trouble with doing something right the first time is that nobody appreciates how difficult it was - Steven Wright
 
There's also dealer code which would make the elements repeat every time there's a new dealer.

I just realized that points are always 1 for any element making this a two dimensional table. However, it's still a good subject so here's the information modified to have varying points.

Dealer Element Points Weight
12345 Phone 1 .1
12345 Addr 2 .4
12345 Year 4 .5
12345 VIN 7 .5
23456 Phone 1 .1
23456 Addr 2 .4
23456 Year 4 .5
23456 VIN 7 .5
 
Maybe two tables with like this(if points varied):

ElementValue
----------
Element
Point
Weight

DealerElement
-------------
Dealer
Element

It seems that references eliminate the need for three dimensional tables... Or maybe there essentially the same thing.

Thanks for the help guys.
 

Actually, you need a 3rd table, to identify the dealer.

Table 1 (tblDealer)
DealerID
Dealer
...any other items particular to a dealer

Table 2 (tblElement)
ElementID
Element
Point
Weight
...any other element attributes

Table 3 (tblDealerElementJOIN)
DealerID
ElementID


Randy
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top