wsmith@m.cs.uiuc.edu (10/17/88)
(mdbs Inc. lost their usenet connection and it may be a few weeks before it is restored. I worked for them summer and would like to try to field the question of extended network databases vs. network databases. My references will be "Principles of Database Systems" by J. Ullman and the MDBS III manuals. The word "set" is overloaded between Ullman's book and the MDBS III manual and I will try to use the word set in the sense of MDBS III. Record type is the term I use for a "set of entities.") Ullman says on page 83: "Roughly the network data model is the entity-relationship model with all relationships restricted to binary, many-to-one relationships.(*)" This makes forming many-to-many relationships awkward because a dummy record type and two "sets" must be created that simulates the many-to-many relationship. The data model that MDBS III calls extended network is at the heart, by this definition an "entity relationship model with all relationships restricted to binary relationships." A "set" may be 1-to-1, 1-to-many, many-to-1 or many-to-many. With this information one can organize the structure of an MDBS III database, but there are several other features that may be used to improve the power and usefulness of the data declarations of the data base. First, someone earlier mentioned security features, which I am not very familiar with. Secondly, each "set" is ordered and may be traversed forward or backwards according to that order. For example, a fifo set will be traversed forward in the order that the members were added to the set. Sets may also be sorted and indexed by keys. Sets may also be "recursive" so that the owner record type and member record types are the same or there may be several different record types that are members of the same set. These two features may be combined. For example, one program I am working on allows me to create a typed file system with the directory and file heirarchy represented directly within the MDBS III database. I think with the data modeling features of MDBS III, it is significantly easier for a programmer to design a data base than it is with a "pure" network model and that MDBS III has enough variations from the standard network scheme that a name such as "extended network" is a more accurate than "network." It is also important to distinguish things that are awkward from things that are impossible. edg@squid.rtech.com mentioned on-the-fly queries. They aren't impossible but the simpler program structure used when you hardwire the database into the program is inappropriate for that problem. One of the MDBS III utilities uses a different organization that interprets the queries instead of having them compiled into the program. A similar organization might be appropriate for other applications. Bill Smith uiucdcs!wsmith wsmith@cs.uiuc.edu (I hope this wasn't too much of an advertisement.) (*) Ullman gives a footnote saying: "Some rather general definitions of the network model allow many-to-many relationships, requiring them to be only binary."