How To Retrieve Data From AMultifile Data Structure In A DBMS Model
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 todays 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 users 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.