A Multifile structure describes multiple types of entities in separate logical files, that is, an entry type corresponds to each entity class. All meaningful relationships are formally defined to the system.

______________________________________________________________________________


______________________________________________________________________________

In a Multifile model, the defined inter-entity relationships need not be only hierarchical relationships (as they are in a hierarchical data structure). Every entity class relates to at least one other entity class within the Multifile data structure. Thus, a Multifile schema diagram with nodes corresponding to entity classes and arcs corresponding to relationships would be a connected graph. Each of the files in a Multifile structure could be a flat file or a hierarchical file

A Multifile data structure schema diagram for our sample database with all relationships represented explicitly in stored data item values within the entity record types. With the addition of a fifth record to store all valid “employee-secondary skill” associations, this becomes a multiple flat file data structure, commonly called a “relational data model”.

Approaches to querying a Multifile data structure

Just because a system offers the ability to define and create Multifile data structure (often called network or relational structures) is no guarantee that it also provides a high-level language capability for querying such structures. In fact, to do so is the exception in today’s marketplace for database management systems.

One common approach is to provide a one-record-at-a-time language with verbs added to or hosted in a conventional programming language. In such host-language systems, the programming user is completely responsible for logically navigating through the database from one record type to the next via particular defined relationships. With a one-record-at-a-time language, the system identifies or delivers at most a single record instance in response to any user request. A user desiring a subset of the records in a file must repeatedly request ”get next” after getting the first instance in the desired subset.

A useful extension of this approach is to identify or deliver multiple record instances (of the same record type) in response to a single user request containing a Boolean selection expression.

Some systems have even made this record-level level language facility available to other online, interactive user-thus providing for online navigation. Some vendors have misleadingly called this a “natural, user-oriented” retrieval facility. Whatever the description, it is still a low-level approach to retrieving from a Multifile structure.

Another approach requires the user to view only a hierarchical data structure within the Multifile structure. This is possible by suppressing some relationships and assuming the rest to be hierarchical relationships. the perceived hierarchical structure may be multipath, but is more often only a single-path hierarchy. The user schema is an appropriate vehicle for defining a user’s hierarchical view within a Multifile data structure.

A variant of this approach allows the user to declare a different hierarchical view immediately before issuing the retrieval request in term of that view. Thus, the hierarchical view can change from one query to the next. Against such a restricted view of the database, the system can now provide a high-level retrieval language as described earlier. This is a common approach to providing some high-level language capability against a stored database which is actually a Multifile data structure.

Multifile retrieval language

A desirable goal is to provide a high-level language which can reference two or more files using a single language statement. Since there may be more than one relationship between any two entity classes, the language must make explicit provision for naming the relationship to be used as part of the language statement. When only one relationship exists between two entity classes referenced in a query, the system can unambiguously determine what entity instances of one class are related to instances of the other class.

The relationship must be defined on a least one data item or domain in each fie. The criteria for establishing the relationship may be simple equality on the values of these data items. Whether or not the data item values are actually stored, the relationship must be based upon logical attributes of the respective entities which can be derived from the stored database.

______________________________________________________________________________


______________________________________________________________________________