Many to Many problem

JohnDC

New member
Local time
Today, 20:53
Joined
Apr 17, 2008
Messages
9
Hi there

My problem is simple and I know what I want to do, but have no idea how to do it.
Problem:
I have two tables Doors (277 records), attachments (60 records), each door can have numerous attachments with varying quantities and obviously numerous doors can have the same attachments (many to many relationship).
I need to be able to store the Door with attachments, including the quantity of attachments for that door (i.e. 3 hinges, two handles etc.).
What I would like is to choose the door (just simple navigation) then choose the attachments, by either list (difficult because of the quantity field) or just simple navigation.
Hope this makes sense. Thank you in advance.

John:confused:
 
Last edited:
Can the attchments be split into groups so you could have a tblHinges, tblHandles and so on? You could then have a combo or list for each on your form. So create record 1 then you could lookup the door type then the fittings and add them to the record? Just my twopenn'orth there's probably a better way......
 
Thanks for the quick reply, I have just expanded on my information as it may be a bit misleading, I would still need to add the quantities, i.e. 3 hinges, 2 handles etc.
Breaking them into groups is a good idea and I am going to give this route a try.
 
I whizzed this together see if it helps
 

Attachments

That is brilliant, thank you very much.
I was going to do this in Excel, but this has saved my life!!
 
Hi

I am not sure if this is really a many to Many relationship.

There is cleary a 1 to many relationship between Doors and attachments. Just because similar (or identical) attachments are used on different doors does not make this a many to many relationship.

To take an analogy in many databases you have an Orders table and an OrderDetails table which have a 1 to many relationship even though there will often be identical items from the OrderDetails linked to different Orders. This does not make it a many to many relationship if you follow my drift.
 
That is true, I was looking at it both ways, but yes you are right it is One door to many attachments and one attachment to many doors.
Simple when someone points it out.
Cheers Rabbie
 
That is true, I was looking at it both ways, but yes you are right it is One door to many attachments and one attachment to many doors.
Simple when someone points it out.
Cheers Rabbie
No you misunderstand me. I clearly haven't explained myself properly. One Attachment can't go on many doors. Its identical twin can but the relationship is a standard 1 to many between Doors and Attachments.
 
rabbie - i am sure this is a real many to many relationship.
attachments are many and homegenous, unlike order details which are unique (and therefore can only be on the many side of a one-to-many)

in the case of attachments it is certtainly legitimate to ask - on which doors did i add part BR1234, "a victorian brass letterbox", or part BR1235 , "a georgian brass letterbox"

so a door can have many attachments

- a letterbox
- a lock
- a lock surround
- a handle
- a knocker

and each of these can be on many door designs. (as opposed to being on many instances of individual door sales)
 
Gemma, I see where you are coming from but I fail to see the logical difference between different designs and different sales.

In a standard sales system it is also legitimate to query "How many left handed Widgets did I sell this month?" and possible to do this in a 1 to many realtionship.

I suppose I am seeing the Many to Many as an extra complication that may not needed.

We are all agreed that a individual door can have many attachments. Where we differ is whether different attachments can be on more than 1 door. I may have the same style of hinges on my front and back door but they are separate hinges.

I suppose from purist point of view in the Orders/ Orderdetails model the Orderdetails table can be acting as a junctiontable between Orders and the Pricelist table.

Don't you just love Relational Database design :)
 
I would like to agree with the hinges part, but the doors I produce have different style hinges (H209 and H92), this rings true with all the other attachments, I have different types of letterboxes, handles etc. Which indeed makes everything a nightmare.
I would like to view both ways i.e. What door has what attachments, but also what attachments are attached to what door, which I believe is the many-to-many relationship.

Can I just add, this is not an ordering database, it is purely a costing database, as I have to find the true cost for each of the 277 doors I have. At present this is based on rough estimate.

I am just starting to get into relational databases as I need this information imported to my Excel spreadsheet.
At least all this keeps the mind going!!
 
I agree with Rabbie.

An insurance data base could have 10000 clients and 50000 records for policy type or policy benefit. However, those policy types might be only 50 in number. Also, Jack, Tom and Bill can all own identical policies with identical benefit amounts.Tom can also have 3 policy benefits and each benefit is identical.

I have only scanned the thread but Doors would be One and attachments Many.

Now of course if things went further Doors could also (and perhaps will) become a Many to customers who orders doors. Likewise Customers could go onto become a Many for the sales representatives.
 
That is brilliant, thank you very much.
I was going to do this in Excel, but this has saved my life!!

Steady on! I'm not one of the experts here and the little I've learned has been gleaned mainly from this great forum but if my example has opened up some possibilities for you I'm happy.:)
 
I would like to view both ways i.e. What door has what attachments, but also what attachments are attached to what door, which I believe is the many-to-many relationship.

That is true for a particular search/query you might do. We do that sort of thing all the time with insurance. Which policy holders own policy benefit abc for xyz benefit amount.
 
OK - so what I really have is a One (door) to Many (attachments) to Many (sub-attachments). From this I can run a query to find out what doors they equate to.
If this is the case (which it looks like it is) how can I attact the items easily to the door, BarryMK has produced an answer, but there is a hitch, in some attachments I have to attach more than one item from there, as far I have seen (from this forum and else where) I would need a listbox which I can multiselect items from, then update the associated door. Which then makes adding the quantity more difficult.
 
johndc

to get back to your problem (and avoid a discussion on semantics), perhaps this will resolve rabbie's issues (and thinking about it, perhaps i agree with rabbie now!)

first, you need a parts table including both plain doors and attachments (or mayber two separate tables, but i think it is easier with a single parts table)

base solid oak door
base sapele door
base walnut veneer door
brass knocker type A
brass knocker type B

now what you are trying to deal with is an assembly of some sort - (an important question is do you sell the door ready furnished, or do you sell it as a package ie base door plus letterbox, lock etc for the fitter to fit (i presume the latter))

so maybe you need some sort of assembly table that give

georgian oak door pack and comprises

1* base door
2* hinges
1* knocker
1* doorplate
1* letterbox

etc etc

now you can cost this door from the asembly table, by adding the costs of the constituents.

---------
so now, all we have is a single one to many relationship

one door part -- to -- many assemblies

-----------
this can get a bit complex - you may want to add the complete assembly back in, as a complete package - but mark it in some way, as you want to use this to pick stock eg, but avoid double counting the base parts AND the entire assembly, but its all doable.

------

thinking about the many to many thing again, perhaps depends on whether you have separate tables for doors and attachments

if you have two tables then you do have

doors many --- atachments many

and it can be resolved with the assembly table

doors 1... m assembly m ------ 1 attachments

---------
or if you just have one table then

doors/attachments 1 ..... m assembly

-------------
personally i think i would go for the one table solution!
 
I think Rabbie would be correct if each item of furniture had a unique serial number which John actually wanted to record in his database. As it's a costing database I think Gemma's right. What I would do is have a third table (tblItemUsage, say) with columns txtDoorStyle, txtFurnitureItem and intNumberUsed which would 'resolve the many-to-many'. I'd then have a tabular view sub-form on the door style form which would display the rows of tblItemUsage relevant to each door style. Am I right?
 
I sell doors to big airports, I am developing the system from quote to delivery, I have completed the quote system in Excel VBA, now have come to the costing, at present a price is plucked out the sky and given to the door. We do have sets of assemblies, but the problem is we make bespoke doors, so I need the ability to pick and choose which attachment goes on a door, so I can price the door more acurately.
---
I am liking the one table solution as this keeps it very simple, all attachments have a unique part code. If I used one table the table would be very large, I have over 75 different possible attachments for every door.
I am sorry if I sound like I have not tried, I have since Monday (databases was never my strong point at university)
--
If I had a table of doors and a table of attachments, could I have fields within the attachments table that stated quantities for that particular door, if this is a yes do I need a third intermedairy table with unique id's for both door and attachment? If this is yes how do I display the list of attachments so I can choose quantities for each door (hope that makes sense).
--
This is the first time I have used access in 6 years please be patient I will get there.
--
 
Yes John, you do need the third table. If you don't have it you would need one column in the Attachments table for each type of door and you'd need to add another column to the table whenever you found that a given attachment was used on more door types than any other.

This is classic example of a repeating group (a bit like having a separate column for each child in a parent table, some people have no children, some have two, some have a football team, etc). It sounds like a lot of work to add the extra table and deal with it in form and report terms but I don't think you'll get what you want without it.
 
John,

If needed you can have a big table in Access, after all it provides for 255 fields. I aslo use a very large main table but it is not large because of lots of multiple instances of the same data.

If you do it all in one table then it will in fact be more complicated not less complicated. Let me illustrate with a very simple example, often found in personal contact data bases.

Among the details we wish to keep are the names, ages, gender, school or whatever of the children in each familiy. There are two ways to go in one table.

Let's say John Andrews has 3 kids. We make three records for John Andrews, all the same except for the details of each child. We will need to enter John Andrews, his address etc 3 times. If he changes his phone number etc.we need to change in in 3 places and if he has 10 kids then we need to do it in 10 places. If there were two tables, one with the children's details we could make a query that would join the two tables and duplicate the 3 entries (or 10 or 100) in one table but we would not have to enter the data more than once.

The second way is to give John Andrews one record and allow several fields for different children, same principle as you are proposing. This solves the problem of any details being changed. But how many fields do we allow for entering childrens data.

Next problem. We are going to need fields for the children like Name1, Age1, Gender1...Name2, Age2, Gender2 etc and onto perhaps name10, Age10 and Gender10

Now lets say we want to know how many children there are in our data base who are between 8 and 10 years of age, who are girls etc. That would be one huge job if they are all on one row. How many of the fields would you search. Then the problem that each set of child's data has to have a different field name.

If I had a table of doors and a table of attachments, could I have fields within the attachments table that stated quantities for that particular door, if this is a yes do I need a third intermedairy table with unique id's for both door and attachment? If this is yes how do I display the list of attachments so I can choose quantities for each door (hope that makes sense).

Yes, you can have what you like. At one extreme there is one record with say a 6 in a field and at the other end there are 6 records for attachments. The attachmenst record (s) do not have unique IDs. They have the same ID as the Door.

As to choosing the quanity from a list that is now getting into macros, code. For example, if 6 of attachment A are required then Attachment A could be selected from a drop down list and if 6 is the quantity then a simple click would either create 6 records of each attachment, inset the Door ID number or if it was done as a single record then the macro/code would stick a 6 in the appropriate field and insert the Door ID number.

You said you have 75 different attachment types. What happens if for some reason you come to need to 3 fields to describe each attachment. That will then burn up 225 of the possible 255 fields.
 

Users who are viewing this thread

Back
Top Bottom