Self-Referencing tables

[John E]

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.

[pietlinden]

if a company has more than one predecessor (formed by a merger of 2+
companies) or more than one successor, then you would have to split the
predecessor and succesor information into separate tables.

Some database applications will let you do this kind of thing by using
things like repeating fields. (Like FileMaker) They're somewhat
useful, but if you want to write reports on a subset of repeating field
values, then forget it. You have to split the repeating fields.

If you *really* want to reference the same Company table in the
Predecessor and Successor fields, you could create a combobox for each
and use SELECT CompanyID, CompanyName FROM Company as the rowsource for
your combobox...But I would lean toward creating separate tables for
the Predecessor and Successor info. Then you should be able to track
what you need.

Sounds like a rough place to start with Access. I may be wrong, but
this does not sound like an easy question.

[pietlinden]

if a company has more than one predecessor (formed by a merger of 2+
companies) or more than one successor, then you would have to split the
predecessor and succesor information into separate tables.

Some database applications will let you do this kind of thing by using
things like repeating fields. (Like FileMaker) They're somewhat
useful, but if you want to write reports on a subset of repeating field
values, then forget it. You have to split the repeating fields.

If you *really* want to reference the same Company table in the
Predecessor and Successor fields, you could create a combobox for each
and use SELECT CompanyID, CompanyName FROM Company as the rowsource for
your combobox...But I would lean toward creating separate tables for
the Predecessor and Successor info. Then you should be able to track
what you need.

Sounds like a rough place to start with Access. I may be wrong, but
this does not sound like an easy question.

[Allen Browne]

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" <n7***@hotmail. com> wrote in message
news:11******** **************@ o13g2000cwo.goo glegroups.com.. .

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.

[Allen Browne]

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" <n7***@hotmail. com> wrote in message
news:11******** **************@ o13g2000cwo.goo glegroups.com.. .

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.

[John E]

I don't *have* to do it with a single table. Because I am referencing
exactly the same type of information, I figured that it could stay in
the same table. A predecessor company, for example, would also be a
record with the same kinds of basic information about it, and it could
also have predecessors as well as successors.

The variable number of repeating fields in a record does seem tricky,
though.

[John E]

I don't *have* to do it with a single table. Because I am referencing
exactly the same type of information, I figured that it could stay in
the same table. A predecessor company, for example, would also be a
record with the same kinds of basic information about it, and it could
also have predecessors as well as successors.

The variable number of repeating fields in a record does seem tricky,
though.