📄 ug_ch4a.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><h1><a name="Design" id="Design"></a>Chapter 4<br>Database Design</h1><h2><a name="Introduction" id="Introduction"></a>4.1Introduction</h2><p><font size="2">A database design is a description of the datathat will be stored in a database and the relationships that willexist within that data. The design of a particular database isdriven by the requirements of the application it will support andis therefore a major part of the total application designprocess.</font></p><p>Our purpose in this chapter is to provide you with theinformation necessary to design <b><i>db.*</i></b> databases. Ifyou carefully study this chapter and the example database design,you should be able to design a workable <b><i>db.*</i></b>database, even if you have no database design experience.</p><p>The chapter begins with a detailed description of the<b><i>db.*</i></b> Database Definition Language (DDL). Each DDLstatement is explained and illustrated through examples. Theoperation of the DDL processor is explained followed by a sectionon database design considerations. The final section builds on the<b>tims</b> database example introduced in Chapter 3 by expandingthe requirements and describing how the database design supportsthose requirements.</p><h2><a name="Language" id="Language"></a>4.2 Database DefinitionLanguage (DDL)</h2><h3><a name="Basics" id="Basics"></a>4.2.1 DDL Basics</h3><p><font size="2">A <b><i>db.*</i></b> database design is specifiedin the Database Definition Language. One DDL specification fileexists for each <b><i>db.*</i></b> database. In general there isone database per application, although some applications mayrequire the use of several databases. (Section 4.4.1, "LogicalDesign Considerations," discusses multiple database design.) A DDLspecification identifies the database, defines the files thatcomprise the database, and contains declarations for all recordtypes, data and key fields, and set relationships that will existin the database.</font></p><p>Below is an example DDL specification. It is an expanded versionof the checking account schema given in Chapter 3. It is providedhere to illustrate some additional DDL statements and to serve as abaseline example in the descriptions that follow. A complete DDLsyntax summary can be found in Chapter 2, "Utility Descriptions,"of the <b><i>db.*</i> Reference Manual</b>.</p><pre><font color="#0000FF">database ckngacct[512]{ timestamp records budget; data file datfile = "chkg.dat" contains budget, check; key file[1024] keyfile1 = "chkg.k01" contains code; key file[2048] keyfile2 = "chkg.k02" contains check_no, check_date; record budget { unique key char code[6]; char cat_desc[48]; float alloc; float balance; } record check { unique key int check_no; key int check_date; char paid_to[48]; float amount; } set transactions { order last; owner budget; member check; }}</font></pre><p><font size="2">The DDL specification is stored in a text fileand is created using your usual text editor. Input is free formwith comments specified, as in C, between /* */ pairs. Comments donot nest.</font></p><p>Identifiers are used to name the database, files, records,fields, and sets. They are formed, as in C, from any combination ofletters, digits, and underscores (_) beginning with a letter.</p><p>File, record, and set statements may be interspersed providedthat:</p><ul><li>Data and key file statements are specified ahead of thedeclarations of the records and key fields they contain.</li><li>The declarations of set owner and member record types arespecified ahead of their respective set declarations.</li></ul><p>Timestamp statements may appear anywhere within a DDLspecification.</p><p>General practice is to place all file statements first, followedby all timestamp statements, followed by all record typedeclarations, followed by all set declarations. The <b>ddlp</b>can, optionally, produce a record, field, and set namecross-reference listing to help you locate names contained in along DDL specification (see section 4.3, "DDL ProcessorOperation").</p><h3><a name="Database" id="Database"></a>4.2.2 DatabaseStatement</h3><p><b><font size="2">Syntax:</font></b></p><pre><font size="+0">database <i>dbname [</i> [<i>pgsize</i>] <i>]</i> { ddl statements ...}</font></pre><p><b>Description:</b></p><p><font size="2">The database statement is used to specify thename of the database and, optionally, the default page size of allfiles.</font></p><p><font size="2">The name of the database <i>dbname</i> is anidentifier and is used by <b>ddlp</b> to form the names of thedatabase dictionary file and the C or C++ header file. Thedictionary file is named <b><em>dbname</em>.dbd</b> and the headerfile is named <b><em>dbname</em>.h</b>. Note that the length ofthis name can be up to 31 characters.</font></p><p><font size="2">The database name, <i>dbname</i>, is passed tofunction <b>d_open</b> to identify the name of the database to beopened and subsequently accessed. It is also passed to utilitiessuch as initdb to identify the database to be operated on(initialized) by the particular utility.</font></p><p><font size="2">The <i>db.*</i> data and key files are blocked ordivided into fixed-length pages, each containing as many record orkey occurrences as will fit on a page. The <i>pgsize</i> parameterdetermines the default database page size in bytes. This valueshould, for performance reasons, always be a multiple of the basicblock size for your operating system (a multiple of 512 will workfor most systems). If not specified, the default database page sizeis at least 1024 bytes, but will be the first number divisible by512 that is large enough to contain the largest record.</font></p><h5>Examples:</h5><pre><font color="#0000FF">database ckngacct[512] { ... }</font></pre><p><font size="2">For the checking account example, the name of thedatabase is <b>ckngacct</b> and it has a default database page sizeof 512 bytes. The name of the dictionary file created by<b>ddlp</b> is <b>ckngacct.dbd</b>. The name of the C header filecreated by <b>ddlp</b> is <b>ckngacct.h.</b></font></p><pre><font color="#0000FF">database acctsrec { ... }</font></pre><p><font size="2">The above is a possible database statement for anaccounts receivable database. Since no page size parameter isspecified the default database page size is 1024 bytes. Thedictionary will be stored in file <b>acctsrec.dbd</b> and the Cheader file will be named <b>acctsrec.h</b>.</font></p><h3><a name="Timestamp" id="Timestamp"></a>4.2.3 TimestampStatement</h3><p><b><font size="2">Syntax:</font></b></p><pre><font color="#0000FF">timestamp records [ recname [, recname...] ] ;timestamp sets [ setname [, setname...] ] ;</font></pre><h5>Description:</h5><p><font size="2">Timestamping is a multi-user database techniqueused to detect possible changes to record and set occurrences sincethe last time they were accessed by a particular user. Refer tosection 7.4, "Timestamping," for a complete discussion of the useof timestamping.</font></p><p>Timestamp statements may appear anywhere within a DDLspecification.</p><p>Record types or set types to be timestamped are listed,separated by commas, in the <b>timestamp</b> statement. If norecord or set names appear in the <b>timestamp</b> statement thenall record types or set types will be timestamped.</p><p>Record timestamping adds eight bytes of additional disk spaceoverhead to each timestamped record slot. Set timestamping addsfour bytes of additional overhead to each set pointer contained inset owner records. (Section 4.4.2, "Physical DesignConsiderations," describes all record and set space overhead.)</p><h5>Examples:</h5><pre><font color="#0000FF">timestamp records budget;</font></pre><p><font size="2">In the checking account database, only the<b>budget</b> record type is to be timestamped. This allows anappraisal to see if another user has modified or deleted aparticular budget record before a check is written to the database,which updates the balance for that budget category.</font></p><pre><font color="#0000FF">timestamp records;timestamp sets;</font></pre><p><font size="2">The database for the above example requires thatall record and set types be timestamped.</font></p><h3><a name="File" id="File"></a>4.2.4 File Declarations</h3><p><b><font size="2">Syntax:</font></b></p><pre><font color="#0000FF">data file [[pgsize]] [fileid =] filename contains recname[, recname]... ;<b></b>key file [[pgsize]] [fileid =] filename contains [recname.]keyfld [, [recname.]keyfld]... ;</font></pre><h5>Description:</h5><p><font size="2">File declarations identify the physical files tocontain the data stored in the database. The <b>data file</b>statement defines a file that will contain the occurrences of oneor more record types. The <b>key file</b> statement defines a filethat will contain the index for one or more key fields.</font></p><p>The <b><i>db.*</i></b> data and key files are blocked or dividedinto fixed-length pages, each containing as many record or keyoccurrences as will fit on a page. The optional <i>pgsize</i>parameter specifies the page size for the file. If not specified,the page size for the file will be the default database page size.This value should always be a multiple of the basic block size foryour operating system (a multiple of 512 will work for mostsystems). Otherwise, the operating system's file access performancewill be impaired.</p><p>The name of the file, <i>filename</i>, is a string enclosed inquotation marks (") containing the physical (operating system) nameof the file. It may be a fully qualified path name but must notexceed 47 characters in length. If the name of the file is notqualified (that is, it does not include a directory name),applications using the database must be executed from within thedirectory containing the database files, subject to theenvironmental conditions discussed in section 5.2.2, "OperationalEnvironment."</p><p>Associated with a database file is an optional file,<i>fileid</i>, which is used to identify files within anapplication program independent of the physical name of the file.It is intended to be used for dynamic initialization of individualfiles using the <b>d_initfile</b> function (section 5.2.3, "DynamicDatabase Initialization") or for dynamically substituting filesusing the <b>d_renfile</b> function (section 5.2.2, "OperationalEnvironment").</p><p>All record types defined in the DDL must be contained in a datafile. All occurrences of the record types listed in the<b>contains</b> clause will be stored in that file. Occurrences ofa given record type can only be stored in a single file. Each pagein the data file consists of one or more fixed-length record slots.The size of the record slot is based upon the size of the largestrecord type contained in the file. Smaller record types will occupythe same record slots, thus leaving unused space. You can defineall record types to be contained in one file or you can have aseparate data file for each individual record type.</p><p>A special system-defined record named <b>system</b> may belisted as the first record type in the <b>contains</b> clause ofone (and only one) of the data files. Only one occurrence of thesystem record exists in the database. It is used as the owner ofany number of sets to provide the means for records to be connectedto the top or root of the network. When the database is opened, thecurrent record and the current owners of all system-owned sets areinitialized to the system record.</p><p>All key fields defined in the DDL must be contained in a keyfile. All occurrences of the key fields listed in the<b>contains</b> clause will be stored in the file. Occurrences of agiven key type can only be stored in a single file. Each page inthe key file consists of one or more fixed-length key slots. Thesize of the key slot is based upon the size of the largest keyfield contained in the file. Smaller key fields will occupy thesame slots, thus leaving unused space. You can define all keyfields to be contained in one file or you can have a separate keyfile for each individual key field.</p><p>Section 4.4.2, "Physical Design Considerations," provides someguidelines to help you determine the best file organization foryour particular application.</p><h5>Examples:</h5><pre><font color="#0000FF">data file datfile = "chkg.dat" contains budget, check;key file[1024] keyfile1 = "chkg.k01" contains code;key file[2048] keyfile2 = "chkg.k02" contains check_no;</font></pre><p><font size="2">The checking account database consists of onedata file and two key files. The data file identified as<b>datfile</b> contains occurrences of both the budget and checkrecord types in the physical file named <b>chkg.dat</b>. From thedatabase statement the page size for <b>datfile</b> is 512 bytes.The key file identified as <b>keyfile1</b> has a page size of 1024bytes and contains the index for key field code in file<b>chkg.k01</b>. Key file <b>keyfile2</b> has a page size of 2048bytes and contains the index for key field <b>check_no</b> in file<b>chkg.k02</b>.</font></p><pre><font color="#0000FF">data file "/client/master.dat" contains system, master;</font></pre><p><font size="2">The above file name specified in this data filestatement includes the fully qualified path for file<b>master.dat</b> located in the <b>client</b> directory. Inaddition to the occurrences of the <b>master</b> record, this filewill contain the <b>system</b> record.</font></p><pre><font color="#0000FF">key file "invnt.k01" contains stock.id_code;key file "invnt.k02" contains bkorder.id_code;</font></pre><p><font size="2">The above example shows duplicate key names thatare qualified by the record type in which they are defined. Whenduplicate field names are used, it is necessary to use the<b>-d</b> option with the <b>ddlp</b> command (see section 4.3,"DDL Processor Operation").</font></p><h3><a name="Record" id="Record"></a>4.2.5 Record Declarations</h3><p><b><font size="2">Syntax:</font></b></p><pre><i><font color="#0000FF">[</font>static] record recname { [field_stmt] ... [comkey_stmt] ...}</i></pre><h5>Description:</h5><p><font size="2">The <b>record</b> statement defines a group ofrelated data fields named <i>recname</i> that will be stored andaccessed together on the database as a single unit. The recorddeclaration consists of zero or more field statements followed byzero or more compound key statements. A record specification withno data fields is valid, and often is used in the implementation ofmany-to-many sets (see "Use of Sets" in section 4.4.1).</font></p><p>The <b>ddlp</b> utility will use the identifier <i>recname</i>to create two C identifiers in the <b>dbname.h</b> file. A<b>struct</b> named <b>recname</b>, containing the C declarationsfor the data fields defined in the record, will be declared in<b>dbname.h</b>. The name of the <b>struct</b> or class willidentically match the name of the record as specified in the DDL.An upper-case form of <i>recname</i> will define an integerconstant record number to be passed to those <b><i>db.*</i></b>runtime functions that manipulate records. Record names, therefore,should never be specified entirely in upper-case.</p>⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -