Re: Self-Referencing tables
- From: "Allen Browne" <AllenBrowne@xxxxxxxxxxxxxx>
- Date: Thu, 4 Aug 2005 00:57:33 +0800
Interesting question, John.
The table can refer to another record in itself, just by adding a foreign
key field that refers to its primary key. To create the relation window,
drag a 2nd copy of the table into the Relationships window (Tools menu.)
Access aliases the 2nd copy with an "_1" suffix, and you can create the
relation as normal. For an introductory example, see:
Self Joins: tables that look themselves up (Pedigrees example)
at:
http://allenbrowne.com/ser-06.html
In your case, you are wanting to deal with multiple predecessors and
successors, so a self-join may not be enough. You may need a junction table
containing fields:
PredecessorID foreign key to Main.MainID
SuccessorID also a foreign key to Main.MainID
This would allow you to define any records as predecessor of any others.
In terms of interface, you would have a main form, with 2 subforms. The
first subform shows the predecessors of the current record, and the 2nd
subform shows its successors. This is an incredibly simple but very flexible
design, that works very well. I used the design once and had no problems at
all until the client asked for the data to be exported in flatfile format
which proved to be messy.
Where it becomes complex is if you are asked to trace the generations up or
down to an unknown depth, especially if there is a possibility of a
predecessor also being a successor of itself (cyclic relationship.) To study
the general design of one part holding other parts that are parts in their
own rights, search on "bill of materials". Here's a starting point:
http://www.mvps.org/access/modules/mdl0027.htm
The SQL langauge is not good at handling this kind of relation, so
ultimately it can get messy. More reading:
http://www.intelligententerprise.com/001020/celko.shtml
http://www.dbmsmag.com/9603d06.html
http://www.dbmsmag.com/9604d06.html
http://www.dbmsmag.com/9605d06.html
http://www.dbmsmag.com/9606d06.html
HTH
--
Allen Browne - Microsoft MVP. Perth, Western Australia.
Tips for Access users - http://allenbrowne.com/tips.html
Reply to group, rather than allenbrowne at mvps dot org.
"John E" <n7hmw@xxxxxxxxxxx> wrote in message
news:1123086825.684756.239800@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
>I have a question about how to make records in a table reference other
> records in the same table....
>
> Suppose I'm building a small database to track some basic information
> on several companies. In addition to the ID and other info, I want to
> track predecessor and succesor companies, if any.
>
> In other words, a given company may have come into being from the
> merger of two or more predecessors, may have been spun-off from a
> single predecessor, or may not have a predecessor as a start-up.
>
> Conversely, a company may no longer exist because it merged with
> another to form a new company, or may have divided itself to form
> multiple new companies. (The successors.)
>
> In this scenario my questions are:
>
> 1. How do I set things up so that a record in the table references one
> or more other records in that same table? Keeping in mind that there
> could be multiples each of predecessors and successors.
>
> 2. How would the form be set up, as the number of predecessors and
> successors will vary? I assume a couple of subforms are in order here.
> Datasheet style is fine for my purposes.
>
> Typically flat-file databases have served my needs in the past, but
> I've been trying to get a better handle on RDBMSs, and this is a bit
> beyond my current experience.
>
> My version of Access 2000.
.
- References:
- Self-Referencing tables
- From: John E
- Self-Referencing tables
- Prev by Date: Re: Self-Referencing tables
- Next by Date: Unexplained behavior in Windows 2000 Adv. Server environment
- Previous by thread: Re: Self-Referencing tables
- Next by thread: Unexplained behavior in Windows 2000 Adv. Server environment
- Index(es):
Relevant Pages
|
