ug_ch2.htm

db.* (pronounced dee-be star) is an advanced, high performance, small footprint embedded database fo

record type, as it is redundant. The <b><i>db.*</i></b> DDL would
be modified as follows:</p>
<pre>
<font color="#0000FF">database ckngacct {
   data file "chkng.dat" contains budget, check;
   key  file "chkng.key" contains code, check_no;

   record budget {
      key char code[6];
      char cat_desc[48];
      float allocation;
      float balance;
   }
   record check {
      key int check_no;
      int check_date;
      char paid_to[48];
      float amount;
   }
   set transactions {
      order last;
      owner budget;
      member check;
   }
}</font>
</pre>
<p><font size="2">Any given record type can be the owner of any
number of different sets and also a member of any number of
different sets. Thus, network structures like that shown in Figure
2-3 are valid.</font></p>
<p align="center">&nbsp;</p>
<p align="center"><img alt="Example of a Network Structure" border=
"0" height="197" src="dbstar_2-3.gif" width="276"></p>
<p align="center">Fig. 2-3. Example of a Network Structure</p>
<p>Notice that records of type E may own other records of type E.
Record type C is a member of two sets (A and B) and itself owns two
sets (D and E). Records also can own other records through multiple
sets, as in the case of B owning E. All these are legitimate
constructs in <b><i>db.*</i></b>.</p>
<h2><a name="OtherModels" id="OtherModels"></a>2.4 Other Database
Models</h2>
<p><font size="2">Two other major database models are the
hierarchical and relational models. These are described
below.</font></p>
<h3><a name="Hierarchical" id="Hierarchical"></a>2.4.1 The
Hierarchical Database Model</h3>
<p><font size="2">In the hierarchical database model (a subset of
the network model) a record type is allowed to be a member of only
one set. Record types can still, however, own more than one set.
The owner is called the parent and the member is called the
child.</font></p>
<p>As in the network model, sets are implemented through linked
lists. Figure 2-4 shows an example of a hierarchical schema
structure.</p>
<p align="center">&nbsp;</p>
<p align="center"><img alt="Example of a Hierarchical Structure"
border="0" height="171" src="dbstar_2-4.gif" width="246"></p>
<p align="center">Fig. 2-4. Example of a Hierarchical Structure</p>
<h3><a name="Relational" id="Relational"></a>2.4.2 The Relational
Database Model</h3>
<p><font size="2">The relational database model views the database
as a set of two-dimensional tables (or relations). The columns
(also called attributes) of a table correspond to data fields, and
the rows of the table correspond to record occurrences. This
tabular view of a database is particularly easy to manipulate with
standard relational database operations, which are based on
mathematical set theory.</font></p>
<p>In the relational model, relationships between tables are
usually established through common data fields. Recall from the
initial checking account example that the relationship between the
<b>budget</b> and <b>check</b> records was formed by including in
the <b>check</b> record a <b>budget code</b> field to identify the
budget category.</p>
<p>The principal distinction between the relational and network
models is that in the relational model, relationships are formed
through common data fields between the related record types, while
in the network model those relationships are defined directly.</p>
<p>Note that it is possible to transform databases from relational
to network and from network to relational.</p>
<h2><a name="Combined" id="Combined"></a>2.5 Advantages of the
Combined Model</h2>
<p><font size="2">Relational model database systems have been
extremely popular, primarily because the simplicity of the
underlying data model makes them easy to use. With the network
model, the primary benefits are better performance, reduced storage
requirements, and greater assurance of data integrity. Consider the
diagram in Figure 2-5.</font></p>
<p align="center">&nbsp;</p>
<p align="center"><strong><img alt="Relational DBMS Overhead"
border="0" height="108" src="dbstar_2-5.gif" width=
"251"></strong></p>
<p align="center"><strong>Fig. 2-5. Relational DBMS
Overhead</strong></p>
<p align="left"><font size="2">This diagram shows two tables that
are related through a common data field, C. Note that C must be
defined in both tables and that an index must exist in order to
access the related table 2 occurrences. Contrast this with the
corresponding network model diagram in Figure 2-6.</font></p>
<p align="left">&nbsp;</p>
<p align="center"><strong><img alt="dbstar_2-6.gif - 1962 Bytes"
border="0" height="149" src="dbstar_2-6.gif" width=
"252"></strong></p>
<p align="center"><strong>Fig. 2-6. Network DBMS
Overhead</strong></p>
<p><font size="2">The network model eliminates data redundancy by
relating the two record types directly, without requiring the
duplicate field and index file. Moreover, the related record is
accessed directly with one database read operation, where the
relational model forces you to read first an index and then the
related record.</font></p>
<p><font size="2">For those situations where an index is more
efficient, db.* provides you with that option. With db.*, network
access and indexed access are independent methods, so you can
combine them to suit the needs of your particular application.
Combining these technologies gives you maximum database design
flexibility.</font></p>
<h2><a name="Access" id="Access"></a>2.6 Access Methods in
<i>db.*</i></h2>
<p><font size="2">We have already discussed two access methods
available in <b><i>db.*</i></b>: indexes and sets. A third method
is called sequential access. All three methods can be used together
for navigating and searching in a database. Each has its own ways
of establishing and changing a position in the database. The
methods are nearly orthogonal, meaning that the use of one will not
disrupt the use of the others. The one value they share is the
current record, which points to the record in the database that has
been found most recently. The current record is the default object
for many of the <b><i>db.*</i></b></font> <font size="2">functions.
All three access methods set the current record.</font></p>
<p><font size="2">The indexed method allows you to find a record
occurrence by supplying a key. The key can be an exact match, in
which case you are positioned directly on a record, or a near
match, which will position you just before the record containing a
key value higher in the collating sequence. You can also position
yourself to the first or last keys of a given key type, regardless
of their values. Once at a position, you can move to the previous
or next key in the collating sequence. The keys are maintained and
navigated in the order maintained in the index, regardless of the
physical order of the records to which they point.</font></p>
<p><font size="2">The set method allows you to move through set
connections in various directions. You can move from the owner of a
set instance to the first or last member of the set. From a set
member, you can move to the next or previous member record, or to
the owner record. During the navigation of sets, positions are
established on a per-set basis: the current owner and current
member is indicated for each set type that has been used. If
defined, a system record can be used as the entry point into a
database. When the database is opened, the system record is the
current owner of all sets owned by the system record.</font></p>
<p><font size="2">The sequential method allows you to find the
first, last, next, or previous physical instance of a given record
type. <b><i>db.*</i></b> does not allow the programmer to insert
records at specific physical positions in a file. Their insertion
is normally at the end of a file, but this is not guaranteed if you
are using the delete chain (see the entry on Option Settings in
section 5.2.4, "Option Settings," of Chapter 5). The sequential
method is useful when you are searching all records of a given
type, but do not care about the order.</font></p>
<h2><a name="Elements" id="Elements"></a>2.7 Elements of a
<i>db.*</i> Database</h2>
<p><font size="2">A <b><i>db.*</i></b> database consists
of:</font></p>
<ul>
<li><font size="2">A dictionary, which stores information
describing the content and organization of the database</font></li>
<li><font size="2">Data files, which contain occurrences of one or
more record types</font></li>
<li><font size="2">Key files, which contain an index for one or
more key fields</font></li>
</ul>
<p><font size="2">Records contain data fields, key fields, and set
linkages (which are transparent to the user). They can be accessed
through set navigation (that is, traversing through the linked
lists associated with specific sets), through key fields (using a
fast look-up of the index), sequentially, or through a combination
of all three methods.</font></p>
<p><font size="2">Details relating to these elements are fully
discussed in Chapters 4 and 5, "Database Design," and "Database
Manipulation" respectively.</font></p>
<p><a href="UG_Ch3.htm">Next Page</a></p>
</body>
</html>