Path: utzoo!attcan!uunet!dg-rtp!hunt From: hunt@dg-rtp.dg.com (Greg Hunt) Newsgroups: comp.databases Subject: Re: SQL Poser Message-ID: <1990Jun27.143543.12064@dg-rtp.dg.com> Date: 27 Jun 90 14:35:43 GMT References: <6588@umd5.umd.edu> 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: 63 In article , cimshop!davidm@uunet.UU.NET (David S. Masterson) writes: > > A set is a collection of records, but a hierarchical set might contain > records > that are also sets (a collection of records). The question I have is what is > this concept useful in representing and what types of queries would result in > a hierarchical set (like what is the management chain of an employee)? This > leads to the question of modelling techniques for a database system that > incorporates this concept. Are normalization techniques capable of arranging > the data model to take advantage of this concept? I think I've misunderstood what you mean by a "hierarchical set". I was thinking you were refering to a set as defined by a hierarchical or network database model (e.g., CODASYL databases). In them, a record occurrence may own other sets of records, but the record itself is not a set. Sets are purely the "connections" between records. A set is owned by an owner record occurrence. The set contains pointers to the member record occurrences that are owned by that owner record. This may have been a terminology problem. A CODASYL "set" is not the same beast as a relational "set" which is based on the definition of an algebraic "set". It seems you mean that the set of records can be "rolled up" into a set that is a record in another set. That is quite a bit different than what I was thinking. Sets and records are not handled that way in the hierarchical or network model databases that I am familiar with. This concept sounds more like what might be found in an object-oriented database, where a set would contain objects, some of which are "records" and some of which are objects that contain other "records". I may have the analogy to an OODB all wrong since I have little experience with them. I posted a way to handle a "parts explosion" problem in a network model database in this thread a couple of weeks ago. If you missed it, I'd be happy to mail it to you. The quick answer to how it's done is this: it's a many-to-many relationship, which cannot be modeled directly since the "employee" record type would have to be both the owner and member in a set. Instead, a "link-record" is used and two sets are defined with the employee record as the owner and the link-record as the member. One of them is a "managed by" set, and the other is a "manager of" set. One or both of the sets must have a manual insertion criterion to allow you to build the proper relationships. To my knowledge, normalization techniques do not simply handle these types of many-to-many relationships. Some more artificial mechanism (like the link-record above) must be used. Other normalization techniques that are regularly applied to relational databases can (and should IMHO) be applied to network databases as well. They help reduce redundant data and relationships. Seeing that I've misunderstood what you were talking about, I'll stop describing the internals of network model databases and how they are used. -- 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.