📄 ug_ch4b.htm
字号:
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"><html><head><meta name="generator" content="HTML Tidy for Linux/x86 (vers 1 September 2005), see www.w3.org"><meta http-equiv="content-type" content="text/html; charset=us-ascii"><meta name="Generator" content="Microsoft Word 97"><title>db.* User's Guide Chapter 4</title></head><body><h3><a name="Alignment" id="Alignment"></a>4.3.2 ddlpAlignment</h3><p><font size="2">The structures defined in <b>dbname.h</b> may beused to store the contents of a record. When a variable is definedas a certain structure, the variable may be passed by reference to<b><i>db.*</i></b> functions for storage into or retrieval from thedatabase. The offsets of each element in the structure is dependenton how the compiler aligns structure elements. When <b>ddlp</b> isbuilt with a certain compiler, it performs its own measurements onthe compiler s alignments and uses those to compute offsets intothe record s structure. Hence the offsets computed by <b>ddlp</b>and the offsets in the C structure should match up if theapplication program is built with the same compiler as<b>ddlp</b>.</font></p><p>To see if a different compiler, or a newer version of thecompiler will result in a different alignment, rename your existingdatabase dictionary (<b>.dbd)</b> file and then run a <b>ddlp</b>built with the new compiler on your schema. Then use <b>prdbd</b>to examine the alignments of the two dictionaries. If they're thesame, you won't have a problem using the different compiler. Ifthey're different, you can choose whether or not to convert yourapplication to the newer version.</p><p>If you have existing data that needs to be preserved, you canuse the <b>dbexp</b> and <b>dbimp</b> utilities.</p><h4><a name="Nested" id="Nested"></a>Nested Structures</h4><p><font size="2">Be very careful about using nested structures inrecords. The alignment of nested structures is verycompiler-dependent. Although <b><i>db.*</i></b> compensates forthis dependence, <b>ddlp</b> may not always be able to produce thecorrect alignment of nested structures.</font></p><p>While numeric and character data can be included in the samerecord, we recommend that numeric data and character data not bemixed together. You should put the <b>double</b>s, <b>long</b>s,<b>int</b>s, and <b>short</b>s first, with the <b>char</b>s last.This will create the smallest possible records without artificiallypacking the structures and avoid most alignment problems.</p><p>If you plan to use nested structures, we recommend that theystart on word boundaries (that is, with numeric data). Starting thestructures on eight-byte boundaries may be necessary on somemachines when the structures contain <b>double</b> data types.</p><h2><a name="Considerations" id="Considerations"></a>4.4 DatabaseDesign Considerations</h2><p><font size="2">C programmers prefer the flexibility to makeintelligent decisions based on a number of design alternatives,rather than having to rely on a less flexible system (which may doa lot more of our work for us, but not always in the way we want itdone). Much of the power of <b><i>db.*</i></b> stems from theflexibility it allows the application developer in organizing thedatabase. This flexibility, however, requires the programmer tomake design decisions from a wide variety ofalternatives.</font></p><p>This section presents database design considerations as theypertain to <b><i>db.*</i></b>. These design considerations areseparated into logical design and physical design issues. Logicaldesign (as defined here) involves those aspects of the databaseorganization that directly affect the manner in which the Capplications have to access and manipulate the stored information.Physical design addresses the organization of the database intodata and key files and (except for file renaming andinitialization) is transparent to the application program.</p><h3><a name="Logical" id="Logical"></a>4.4.1 Logical DesignConsiderations</h3><p><font size="2">The logical design considerations discussed hereaddress the use of keys, sets, and multiple databases. Note thatthe examples given show only the DDL and not the actual code thatuses it. Chapter 5, "Database Manipulation," will complete many ofthese examples by providing the necessary code.</font></p><h4><a name="UseKeys" id="UseKeys"></a>Use of Keys</h4><h5>General Key Usage</h5><p><font size="2">Key fields are basically used:</font></p><ul><li>To provide fast access to individual record occurrences</li><li>To provide efficiently sorted and selectable retrieval of alarge number of record occurrences</li></ul><p>What are the possibilities for locating a specific recordoccurrence among many? One could read and inspect each recordoccurrence in the order they were stored in the file, until thedesired record is found. This would take some time if there aremany occurrences. On average, half of the records on file wouldhave to be inspected to find a specific record, and all would haveto be inspected to determine that the record was not on file.</p><p>Alternatively, sets could be navigated through the networkstructure to locate the desired record (see section 4.5.3,"Database Design"). This would generally mean that fewer recordswould have to be read, but the process still would be too slow,depending on the application requirements.</p><p>Because of the efficiency of the B-tree indexing method,locating a record through a key will involve at most only a fewdisk read operations (usually three or four). Thus, it is an idealway to locate specific record occurrences rapidly.</p><p>In <b><i>db.*</i></b>, any field defined in a record can be akey. Thus there are a wide variety of potential ways to access aparticular record. Fields can be defined as unique keys, to preventthe entry of records containing duplicate key values. When keyfields are not defined as unique, records with duplicate keys areallowed to reside in the database. For example, zip code may be akey in a person record containing an address.</p><p>In the checking account database, <b>check_no</b> was defined asa unique key to allow the program to retrieve the check record fora particular check number. Other examples of data fields that wouldbe good candidates for keys are:</p><div style="margin-left: 2em"><p>employee number</p><p>social security number</p><p>vehicle identification number</p><p>inventory item number</p><p>budget code</p><p>serial number</p><p>personal name</p></div><p>Many different kinds of fields containing coded values are bestimplemented using a key. If new codes are needed, they can be addedto the database without recompiling. For example, consider thefollowing record declarations:</p><pre><font color="#0000FF">/* vehicle make validation table */record vehicle { unique key vma_code[7]; /* vehicle make code */ char vma_desc[25]; /* vehicle make description */}/* vehicle fleet record */record fleet { unique key char vin[25]; /* vehicle id number */ char vma[5]; /* vehicle make */ char vmo[5]; /* vehicle model */ char vyr[3]; /* vehicle year */ int lsd; /* last svc. date */}</font></pre><p><font size="2">An example vehicle record occurrence mightbe:</font></p><pre><font color="#0000FF">vma_code: CHEVvma_desc: Chevrolet</font></pre><p><font size="2">When a new <b>fleet</b> record is entered, theapplication program can easily validate that the <b>vma</b> fieldcontains a correct code by doing a key find operation on itscontents (specifics of how to do this are explained in section5.4.1, "Data Retrieval Using Keys").</font></p><p>The <b>check_date</b> field in the checking account databaseexample was not a unique key. This provided the ability to writemultiple checks with a common date and to quickly retrieve allchecks written on a specific date or within a particular range ofdates.</p><p>Key fields can also be used for rapid pattern-matching typesearches. Many more keys than records can be retrieved in a singledisk read. Use of a key field for certain search requirements willresult in much faster processing, especially when all occurrencesneed to be checked by the search operation.</p><p>For example, consider a law enforcement database containing"method of operation" records, which give the details of howspecific crimes were committed. These records contain perhaps 25data fields, each containing a numeric code identifying aparticular aspect of the crime. One field in the record mightdescribe a burglar's method of entry into a home as follows:</p><table border="0" cellpadding="7" cellspacing="0" width="361"><tr><td valign="top" width="19%"><p><b><font size="2">Code</font></b></p></td><td valign="top" width="81%"><p><b><font size="2">Meaning</font></b></p></td></tr><tr><td valign="top" width="19%"><p align="justify"><font size="2">1</font></p></td><td valign="top" width="81%"><p><font size="2">Broke in through front door</font></p></td></tr><tr><td valign="top" width="19%"><p align="justify"><font size="2">2</font></p></td><td valign="top" width="81%"><p><font size="2">Broke in through back door</font></p></td></tr><tr><td valign="top" width="19%"><p align="justify"><font size="2">3</font></p></td><td valign="top" width="81%"><p><font size="2">Broke in through window</font></p></td></tr><tr><td valign="top" width="19%"><p align="justify"><font size="2">4</font></p></td><td valign="top" width="81%"><p><font size="2">Picked front door lock</font></p></td></tr><tr><td valign="top" width="19%"><p align="justify"><font size="2">5</font></p></td><td valign="top" width="81%"><p><font size="2">Picked back door lock</font></p></td></tr><tr><td valign="top" width="19%"><p align="justify"><font size="2">6</font></p></td><td valign="top" width="81%"><p><font size="2">Came down the chimney</font></p></td></tr><tr><td valign="top" width="19%"><p align="justify"><font size="2">7</font></p></td><td valign="top" width="81%"><p><font size="2">Other</font></p></td></tr></table><p><font size="2">The reason for maintaining m.o. records in thedatabase is, of course, to allow searches for a match of aselection of the fields. The key for the search would be a25-element byte array in which each element's value would be anumeric code, with zero meaning "not supplied."</font></p><pre><font color="#0000FF">record mo { key char mo_data[25][1];}</font></pre><p><font size="2">The fields in the key would be ordered with thehighest priority search field first and the lowest priority searchfield last. The highest priority search field is the one most oftenused in the searches. By listing it first, you can reduce thenumber of keys to be scanned in the maximum number of cases. If thefirst field is not used in the search, all keys must bescanned.</font></p><h5>Compound Key Usage</h5><p><font size="2">In general, compound keys are used when one ofthe following conditions exists:</font></p><ul><li>A data field needs to participate in more than one key in therecord.</li><li>A key is needed that contains multiple fields, where a mix ofascending and descending order is required among the sortfields.</li></ul><p>Suppose a record is to be searched based on the contents of twofields, where search values for either field are not alwaysavailable. If a <b>struct</b> key field were used and the firstfield in the key was not available, all keys would need to bescanned. The use of two compound keys would solve the problem.</p><pre><font color="#0000FF">record combo_search { int field1; int field2; compound key f1_1st { field1; field2; } compound key f2_1st { field2; field1; }}</font></pre><p><font size="2">If only <b>field1</b> data were available for thesearch, then key <b>f1_1st</b> would be scanned. If only<b>field2</b> data were supplied, then key <b>f2_1st</b> would bescanned. If both were supplied, by convention, <b>f1_1st</b> wouldbe scanned.</font></p><p>Compound keys allow sort fields to be individually sorted ineither ascending or descending order. Suppose in the checkingaccount database we wanted to be able to list the checks sorted bythe <b>paid_to</b> field, and, within that, in check number orderwith the most recent checks listed first, as in the followingexample :</p><pre><font color="#0000FF">record check{ unique key int check_no; key int check_date; char paid_to[48]; float amount; compound key pay_list { paid_to ascending; check_no descending; }}</font></pre><h5>Optional Key Usage</h5><p><font size="2">Optional keys are not created when the record iscreated, but only when specifically requested by the applicationprogram through the <b>d_keystore</b> function.</font></p><p>Optional keys should be used for fields that are not mandatory(the field's contents are not always supplied), but that need to bekeyed when they are used.</p><p>Optional keys can also be used when it is desirable to defer thekey creation to a time other than when the record is first stored.In real-time applications the number of record updates per a giventime period (called the transaction rate) often needs to bemaximized. Normally, the key fields in a record are created whenthe record is created, and this involves additional overhead of upto three or four disk input and output operations per key. Theability to defer key creation can greatly improve the transactionrate. Usually a separate program performs the key creation duringnon-peak system load times (for example, late at night).</p><h4><a name="UseSets" id="UseSets"></a>Use of Sets</h4><p><font size="2">Set relationships form the basis of the networkdatabase model. The basic use of sets in forming one-to-manyrelationships was introduced in Chapter 2, "Database Concepts," andillustrated in the checking account database example. This sectionwill expand the use of sets by showing how they can be used toimplement many-to-many relationships and variable-lengthrecords.</font></p><h5>Many-to-Many Relationships</h5><p><font size="2">Many-to-many set relationships are best explainedthrough an example. A typical example is students and classes incollege. Each class has many students and each student takes manyclasses. Thus, there is a many-to-many relationship between classesand students.</font></p>⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -