Fig. 2-1. Example of Set Relationships
This chapter presents the basic database concepts of the RDM Embedded system. The database terms used in this manual are defined in Definitions. The network database model, which forms the basis of the RDM Embedded system, is described in The Network Database Model. Other Database Models, describes the hierarchical and relational database models. Advantages of the Combined Model describes the advantages of the network model over the relational database model. Specific elements of an RDM Embedded database are described in the final section.
To use RDM Embedded productively, you need to understand RDM Embedded database concepts. This chapter's purpose is to provide sufficient information for a database novice to use RDM Embedded effectively. As part of our efforts to familiarize you with database concepts, we have provided a Glossary of database terms at the end of this manual.
The basic unit of information in a database is a field. A field (or data field) is an item of data with attributes such as name, type (for example, a character or an integer), and length. Examples of fields are employee name, date of birth, social security number, inventory item code, and serial number. Other database systems or books may use other terms (such as attribute, entity, or column) for field.
A record is a named collection of related fields, which are stored and accessed as a unit. Other database systems or books may use other terms (such as table or file) for record. For example, a record named check in a checking account database may have the following fields:
date check number paid to amount
Each occurrence (or instance) of a check record in the database contains a value for each of these fields. The definition of a record (made up by its fields) is called the record type and is similar to C structures.
All occurrences of a particular record type are stored in an operating system file. Files are the primary physical storage units of database organization. A database, therefore, is a collection of related files.
A key is a field through which rapid or sorted access to a record is possible. In the check record, you might define check number as a key field, to allow quick retrieval of a check record occurrence through specification of a check number.
An index is a file containing only keys. It is synonymously referred to as a key file. The index to this manual demonstrates the features of a key file: the individual subject entries in the index are the "keys," while the page where the subject is discussed is analogous to the associated "records." You can find the page that discusses a desired subject much more quickly by using the index than by reading through each page. And, because the keys are sorted in the index, you can quickly find a specific key. Key files are similar, except the computer does the sorting and look-ups for you. To maintain its key files, RDM Embedded uses the B-tree method, one of the most efficient techniques for implementing an index.
In a key scan operation, the keys in an index are read in the order they appear. Key scans are used to produce sorted listings of records and for fast search operations requiring inspection of a large number of record occurrences (for example, retrieving all checks entered between two dates).
Data relationships often exist between record types. For example, the checking account database may include budget categories. A second record type named budget could be defined with the following data fields:
budget code (a key field) category description monthly allocation balance
To associate a particular budget category with each check record, we add a budget code field to the check record type, forming a relationship between the budget record and the check record. Whenever a check is entered, the related budget record is located via the budget code, and the balance for that budget is updated by the amount specified in the check record.
The schema is the conceptual definition of the content and organization of a database. A schema will include the definitions of all record types, with their fields and keys. The form of the schema used by the DBMS is called the dictionary. In RDM Embedded (and most other DBMSs) a Database Definition Language, or DDL, specifies the schema. An RDM Embedded DDL specification for the checking account database is shown below. The specifics of the actual DDL statements are explained in the Database Design section.
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 bud_code[6];
char paid_to[48];
float amount;
}
}
A data model (or database model) is a conceptual representation of inter-record relationships. The relational database model establishes and maintains inter-record relationships through common data fields. For example, in the checking account example a common data field, budget code, establishes the relationship between the budget record and the check record.
Other database models, in particular the network database model, establish inter-record relationships directly, through physical links between the related records, rather than through common data fields. These models are discussed in the following sections. Since RDM Embedded supports both the relational and the network database models, you can combine the features of these models to meet the needs of your particular application.
In the network database model, the relationships between record types are explicitly defined and directly maintained through sets. A set defines a one-to-many relationship between two record types. Examples of sets are:
one baseball league has many teams
one baseball team has many players
Sets are implemented with linked lists of pointers to the record locations of the set members and owners. The result is a network of interconnected records.
Figure 2-1 illustrates the set relationships for the baseball example. The boxes represent instances of the league, team, and player record types. The arrows represent the links that connect the related records.
Fig. 2-1. Example of Set Relationships
Schema diagrams are used to illustrate graphically the inter-record relationships of the database design. Figure 2-2 shows the schema diagram for the baseball example. In this diagram (and in all other schema diagrams in this manual), the boxes represent record types and the arrows represent set types. The league_team set forms a one-to-many relationship between the league record type (called the owner of set league_team) and the team record type (called the member of set league_team). The team_player set forms a one-to-many relationship between the team record type and the player record type.
Fig. 2-2. Example of a Schema Diagram
In the checking account example discussed earlier, the relationship between the budget and check record types could be specified using a set called transactions, defining a one-to-many relationship between a budget record (owner) and the check records (members) written against a particular budget category. In this case, the bud_code field in the check record would not be defined in the check record type, as it is redundant. The RDM Embedded DDL would be modified as follows:
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;
}
}
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.
Fig. 2-3. Example of a Network Structure
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 RDM Embedded.
Two other major database models are the hierarchical and relational models. These are described below.
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.
As in the network model, sets are implemented through linked lists. Figure 2-4 shows an example of a hierarchical schema structure.
Fig. 2-4. Example of a Hierarchical Structure
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.
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 budget and check records was formed by including in the check record a budget code field to identify the budget category.
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.
Note that it is possible to transform databases from relational to network and from network to relational.
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.
Fig. 2-5. Relational DBMS Overhead
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.
Fig. 2-6. Network DBMS Overhead
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.
For those situations where an index is more efficient, RDM Embedded provides you with that option. With RDM Embedded, 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.
We have already discussed two access methods available in RDM Embedded: 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 RDM Embedded functions. All three access methods set the current record.
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.
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.
The sequential method allows you to find the first, last, next, or previous physical instance of a given record type. RDM Embedded 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 DCHAINUSE). The sequential method is useful when you are searching all records of a given type, but do not care about the order.
An RDM Embedded database consists of:
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.
Details relating to these elements are fully discussed in Database Design and Database Manipulation sections.
RDM Embedded now supports storage of databases in shared memory, instead of files. The database contents have the same logical structure, whether stored in shared memory or in files. Thus the division of the database into data files, key files and vardata files applies to in-memory databases as well as disk-based databases. However, a database "file" may now be stored as multiple shared memory segments instead of being stored as a file in the file system.
The database dictionary, which is normally stored in a file created by ddlp or sddlp, can now be placed in a static structure in the application program, avoiding the need for any files at all in an RDM Embedded application. The system files created by RDM Embedded, the TAF and the LOG files, will then also be stored in shared memory segments instead of files.
A database may also be stored partially in memory and partially on disk. Some database files may be stored on disk while others are stored in memory. Key files, which can always be generated from the data files, could be held in memory and regenerated whenever the application starts.
Database files can also be read from disk when the database is opened and then maintained in shared memory while the application is running. When the database is closed the contents of the shared memory can then either be discarded (database files defined as "read") or written back to disk (database files defined as "persistent").
A record type, or table, can now be defined as “circular”. Normally, when a table becomes full, RDM Embedded does not allow further record instances to be inserted until some are deleted. With circular tables, when the table becomes full RDM Embedded will still allow new record instances to be created. The new record instances will overwrite existing ones, starting with the oldest. RDM Embedded does not allow explicit deletion of record instances in a circular table.
The definition of a circular table includes a size limit. This provides a useful way of allocating a fixed amount of storage space for storing the most recent instances of a particular record type. For example, this may be useful in storing event data that is being generated rapidly, where only the most recent data is relevant. Circular tables remove the risk that incoming data may fail to be stored due to lack of space, while avoiding the need for the application to delete obsolete data.
Copyright © 2009 by Birdstep Technology, Inc. All rights reserved. RDM Embedded Product Family
