In a recent post (Subfile Lookup Tables) I mentioned system number maps. Let’s talk a little more about these.
Each node in the nodal structure is assigned a unique number known as its system number. This is an integer value which is quite separate from its nodal number, such as 1.2.3, and is usually assigned in the order in which it is created. The first node to be created would have system number 1, the second would have system number 2, and so on. The reason for system numbers is that nodes can be moved around in the structure, so their nodal numbers can change. System numbers, in contrast, never change, no matter where the node is located in the structure. If you think of nodal numbers as street addresses, system numbers would be the equivalent of social insurance numbers, or whatever is the equivalent government identification number in your country. If you move from one house to another, your street address will change, but not your government ID number.
Referring back to the previous post, let’s assume that node 1.3 has been exported as subfile 2, and suppose its system number in the master file is 8. Subfile 2 is then expanded by its owner, and in due course is imported back into the master file. In the interim, let’s suppose that the master file owner has added a new node to the 1.1/1.2/1.3 sibling group, and decided that it should go immediately after node 1.2. This means that the new node is now 1.3, and the original 1.3 has become 1.4:
If subfile 2 were imported back into node 1.3, there would be a major mixup. However, in reality subfile 2 is imported back into the node with system number 8, which is now identified with node 1.4, so the subfile will be imported back into the correct place.
Let’s look at what happens to subfile 2 before it is imported back again. It’s owner decides to add three new nodes, which will be 1.3.1, 1.3.2 and 1.3.3:
These are all given appropriate system numbers. The original top-level node 1.3 becomes system number 1 in the subfile, and the new nodes become system numbers 2, 3 and 4 respectively. It doesn’t matter that system numbers in the subfile don’t correspond to system numbers in the parent file, because we are going to create a map translating one to the other.
When the subfile is first created, the system number map will consist of a single entry: system number 1 in the subfile relates to system number 8 in the parent file. We then add three more nodes in the subfile. At this point they have no equivalent numbers in the parent file because the subfile has not yet been imported back into the parent. However, when import occurs, these new nodes are given the first three available system numbers in the parent file – let’s say these are 45, 46 and 47. The system number map after import will then record that system numbers 2, 3 and 4 in the subfile correspond to 45, 46 and 47 in the parent file.
System number maps are unnecessary if you are only going to import the subfile once, because in such cases you can presumably throw the subfile away once it has been imported. However, if the subfile is going to have an ongoing existence, and will be imported back into the parent multiple times, as and when new data becomes available in the subfile, then you need to know which nodes in the subfile correspond to which nodes in the parent file, and a system number map is required. The map will be a living document, because it will need to be updated whenever any additions are made to the subfile nodal structure.
PARENTS AND SUBFILES
You will have noticed that I’ve been talking about importing into the parent file, rather than importing into the master file. A parent file is simply the file from which a subfile was originally derived, and may be the master file or may be a subfile itself. System number mapping applies at all levels in the subfile structure.
Suppose that subfile 2 as described above is imported back into its parent, and then at a later date the subfile owner decides that node 1.3.3 is not required, and deletes it. This poses a problem when the subfile is next imported into its parent, because while node 1.3.3 will exist in the parent (because it was placed there on a previous import), it no longer exists in the subfile. We get around this difficulty by negating numbers in the system number map which have been deleted in the subfile so that there is a permanent record of the deletion, and allowance can be made for it on any future imports.
There is no provision for the opposite case, where the same node is deleted in the parent file, because the deleted node will simply be reinstated when the subfile is next imported. This implies that data flow is always one-way, i.e. from subfile to parent. You can design systems that permit two-way flow, but they are a whole lot more complicated, so you don’t use them unless you really need to.