Path: utzoo!attcan!uunet!dg-rtp!hunt From: hunt@dg-rtp.dg.com (Greg Hunt) Newsgroups: comp.databases Subject: Re: SQL Poser Message-ID: <1990Jun15.215257.15668@dg-rtp.dg.com> Date: 15 Jun 90 21:52:57 GMT References: <6588@umd5.umd.edu> <1990Jun1.132731.6699@oracle.com> <1990Jun4.151555.3479@oracle.com> <2371@anasaz.UUCP> <2385@anasaz.UUCP> Sender: usenet@dg-rtp.dg.com (Usenet Administration) Reply-To: hunt@dg-rtp.dg.com Distribution: comp Organization: Data General Corp., Research Triangle Park, NC Lines: 49 > In article cimshop!davidm@uunet.UU.NET (David S. Masterson) writes: > What does a hierarchical set look like? I presume you are asking about the internals of how the set is organized. I can give you my perspective on how a network model database organizes sets. I don't know if other systems are similar or not. The set itself is a B-tree index, using all the useful B-tree options. The pointer stored with a key value is the address of the data record that contains the key. That part is pretty standard. The rest of the "network model" is stored in the record header. There are two lists that are maintained. The first list contains a number of elements, one for each set that this record could potentially be a member in. If it is a member in a given set, the element contains the record address of the owning record occurrence. The second list also contains a number of elements, one for each set that this record could possibly be an owner of. If it owns a given non-empty set occurrence, then the element contains the address of the root node of the B-tree that contains the keys and record pointers in that set that this record owns. In traversing a path trough the database, you start with the system record, which always exists. From it, find the root node address of the first set in which you want to find a member record. You then search that B-tree to find the key or positional record you're interested in. The index contains the record address of that record. From there on, you repeat this going, down levels until you find the final record you want. The "owner list" in the record header is used to traverse the tree in the reverse direction, or upwards towards the root. This allows you to find the owner of a given record, in a given set occurrence. There is no requirement that a record be connected in all sets that it could potentially be. The pointers in the record header may be null. This is quite valid, and quite useful. Is this what you were interested in? Is my explanation clear? -- Greg Hunt Internet: hunt@dg-rtp.dg.com Data Management Development UUCP: {world}!mcnc!rti!dg-rtp!hunt Data General Corporation Research Triangle Park, NC These opinions are mine, not DG's.