Documents
Resources
Learning Center
Upload
Plans & pricing Sign in
Sign Out

DDD Chapter 1 Overview of Database Definition and Development

VIEWS: 4 PAGES: 48

									Chapter 1

Overview of Database Definition and Development

BASIS System Overview
After you have designed your database application, you need to communicate that design to the BASIS system. This chapter describes BASIS system architecture, focusing on the Definition Database and its parts, and describes steps in the database definition process. Later chapters in this manual provide information and syntax for defining your database. As Figure 1-1 illustrates, the BASIS system can be viewed as a set of concentric rings resembling the cross-section of a tree trunk. User interfaces form the perimeter, and the Kernel exists at the core.

Overview of Database Definition and Development  15

User Interfaces Tools and Utilities Object Management and Programming Database System Operating System Kernel

Figure 1-1: BASIS system overview

User Interfaces

User interface modules and products include:  Fundamental Query and Manipulation (FQM), an interface consisting of   commands that can be entered interactively to retrieve and display data command procedures that can be submitted as batch jobs

16  Overview of Database Definition and Development



a screen-oriented means of entering, updating, and retrieving data on UNIX and VMS operating systems

Overview of Database Definition and Development  17



BASIS Document Manager, which manages documents in a variety of formats, including Standard Generalized Markup Language (SGML) and Hypertext Markup Language (HTML) BASIS WEBserver, which supports Internet and intranet access to documents BASIS Client Suite, a set of application development interfaces that access and update document collections

 

Some of these modules and products are available on a limited set of operating systems and platforms.
Tools and Utilities

Tools and utilities include:   Various utilities to load data, back up and restore the database, manage the queue area, restructure indexes, and perform many other tasks Optional support modules such as Thesaurus Manager (TM) for creating and managing thesauri

Object Management and Programming

Application programming modules include:  Document Handler Interface (DHI) for developing FORTRAN, COBOL, C, and PASCAL interface programs for conventional, sectioned, and continuous records (DHI is not applicable to Windows operating systems.) OpenAPI for developing Windows, Macintosh, and character-cell application interfaces for conventional, sectioned, and continuous records (Sectioned records are not supported on Windows operating systems.) Data Manipulation Language (DML) modules for developing FORTRAN and COBOL interface programs for applications using





18  Overview of Database Definition and Development

conventional records (DML is not applicable to Windows operating systems.) Database System The database system includes:  Database Administrator (DMDBA) module for creating and maintaining database definitions, authorizing users to database models, and performing various database maintenance tasks.

Overview of Database Definition and Development  19

  

BASIS databases, such as the Master Definition Database and Authority Database. Application databases that you develop. One or more Thesaurus Databases, if your site has purchased the Thesaurus Manager module.
The Master Definition Database describes the organization and features of all Definition Databases

The Authority Database controls access to all BASIS databases at your company

Master Definition Database Application Databases contain a variety of interrelated records organized to make information easy to find

Database Application Database Database

Application Application

Authority Database
Application Application Database Thesaurus Database

Database

Thesaurus Databases contain information to control database retrieval vocabulary

Figure 1-2: BASIS and application databases

Master Definition Database

The Master Definition Database (MDDB) is where the system database definition is stored. The BASIS system uses the Master Definition Database behind the scenes when you create or change a Definition

20  Overview of Database Definition and Development

Database. This database is named XSYSA.

Overview of Database Definition and Development  21

Authority Database

The Authority Database (ADB) helps to control access to BASIS application databases. It contains a record for each database and a record for each registered user. A database record indicates the owner (creator) of the database, where its Definition Database is located, and the status of the database. A user record indicates the database models the user may access and contains the user’s database privileges, read and write access codes, and priority. For example, when you use a BASIS module, the system will compare the ID, password, database, and model name that you enter against records in the ADB. If any of the information you provide does not match that of the appropriate ADB record, the system will not let you use the module or it will not let you open the database and model. If all the information you enter is correct, then the system will use the data in the ADB to set your privileges, access codes, and priorities. The system administrator (SA) uses the DMSA module to maintain the ADB. As a database administrator (DBA), you can use the DMDBA module to authorize people to use databases that you create, and you can set their access privileges. This database is named SYSA, but you cannot directly access this database.
Application Database

Each application database that you and others at your site create consists of a pair of related databases: a Record Database (RDB) that stores data and a Definition Database (DDB) that stores information describing the organization and features of records in the Record Database. TOUR, a demonstration database that comes with BASIS, consists of both a Record Database and a Definition Database.

22  Overview of Database Definition and Development

Definition Database

The Definition Database describes the organization and features of your specific database Each Record Database stores data files, journal files, and backup sets

Record Database
Data File(s) Data File(s) Data Journal File(s) Journal File(s) Journal

Record Database Record Database

Backup Set(s) Backup Set(s) Backup

File(s)

File(s)

Set(s)

Figure 1-3: Application database

Definition Database

A site has one Authority Database and one Master Definition Database but can have many Definition Databases and Record Databases. The Definition Database is described later in this chapter, and the rest of this manual describes each of the parts of the DDB in detail.
Record Database

The Record Database stores the data of a database. It consists of data files and (optionally) journal files and backup sets. Journal files keep track of the new or revised records that database users enter. If a system or media failure occurs, you can recover “lost” data by replaying the journals. (Because a Definition Database is in a sense a “Record Database” in relation to the Master Definition Database, you can also use journal files to protect your work in defining the DDB.)

Overview of Database Definition and Development  23

You can create as many as 99 versions of a Record Database. Each version would have the same logical description but would be stored in different files and could contain

24  Overview of Database Definition and Development

different data. For example, you might define four versions of a database for different usages such as production, user training, programmer training, and testing. For a detailed list of maximums for a variety of BASIS components, see “Limits of BASIS.” For more information about the structure of files within the Record Database, see Database Loading and Maintenance. You can use your host operating system’s backup utility to make backup copies of the RDB, DDB, and Journal Files. These copies are called backup sets and can be used to recreate a BASIS database if it has been damaged.
Thesaurus Database

If your site uses the optional Thesaurus Manager (TM) module to control database retrieval vocabulary, the relations and legal terms will be stored in the Thesaurus Database (TDB).
Operating System

The operating system includes interfaces to servers such as UNIX and VMS. The DMSA module is used by system administrators to control access to BASIS and perform various system administration tasks.

Overview of Database Definition and Development  25

Kernel

Controlling the interaction among BASIS modules, among various users, and among various BASIS databases is the central Kernel, the BASIS server module (DMK). The Kernel controls these database activities:

Retrieval Data Entry

The Kernel interprets FQM FIND commands and processes search requests. When users add, change or delete records, the Kernel accesses the database and changes it. The Kernel’s multi-threading capabilities coordinate the activities of many simultaneous users. BASIS uses a database to store the definition of the database you create. The Kernel controls this activity also. The Kernel controls record locking, ensuring that in databases accessed by many concurrent users data updates are processed correctly. It also ensures that users see or update only data they are allowed to see or update.

Database Definition Security

BASIS databases are usually under exclusive control of the Kernel. All user programs and most system programs must access a database indirectly by making requests to the Kernel. Only a few special utilities directly manipulate a database. These utilities must be executed by specially privileged users and can never use a database while it is under the Kernel’s control. The Kernel executes as an independent process under a standard host operating system. It communicates with user programs and BASIS programs by using special Inter-Process Communication (IPC) software. A program uses non-procedural commands to manipulate a database.
26  Overview of Database Definition and Development

These commands are translated into requests which are sent via the IPC software to the Kernel. Requests are always answered with a status code and optionally with data such as records or the result of a query. The Kernel software coordinates, prioritizes, and quickly answers every request. It uses user, program, and database priorities to determine which requests should be processed first.

Overview of Database Definition and Development  27

Some of the major operations performed by the Kernel include:               User authorization Data validation and compression Control of all database reads and writes Dynamic retrieval optimization Maintenance of a journal for each database Maintenance of a system log which includes accounting data Automatic recovery using transaction work files Locking of database structures down to the record level Security control Clustering of related records Efficient allocation of storage Management of all indexes Dynamic buffering of database pages Performance monitoring

Most sites use only one copy of the Kernel to handle all requests, but it is possible to run up to nine copies of the Kernel, each of which handles a subset of the available databases.

28  Overview of Database Definition and Development

BASIS Architecture
Just as the BASIS system can be viewed as a set of concentric rings resembling the cross-section of a tree trunk, so the structure of records in the Record Database can be viewed as an inverted tree. Figure 1-4 displays the structure of records in the Record Database. Definitions follow.
Database

Document Field Group Text Stream Field

Standard Field

Text Image Field

Physical Text

Indexed Text

Subfield

Text Image Line

Text Image Line

Section Field Group Text Stream Field

Standard Field

Text Image Field

Physical Text

Indexed Text

Subfield

Text Image Line
Figure 1-4: BASIS record architecture

Text Image Line

Overview of Database Definition and Development  29

Following are descriptions of objects within a BASIS Record Database:

Database Document

A BASIS database comprises one or more documents or records. The structure of a document depends on the record style: Convention consist of a field group. al records Continuous records Sectioned records consist of a field group (document-level fields) and a text stream field. consist of a documentlevel field group and one or more sections. (Sectioned records are not supported on Windows operating systems.)

For more information about record styles, see “Records.” Field Group A set of non-text-stream fields. The field group cannot exceed a total length of 16,000 bytes. It can contain a total of 500 standard fields and text image fields. Each document can have one document-level field group. (Also see “Section” below). A character or numeric field that does not contain SGML markup. It can consist of as many as 4000 subfields. A standard field that contains only one subfield is a simple field. A standard field that contains more

Standard Field

30  Overview of Database Definition and Development

than one subfield is a compound field. Subfield Contains the data of the standard field.

Overview of Database Definition and Development  31

Text Image Field

A character field that contains markup characters such as SGML. SGML, described in International Standards Organization (ISO) 8879, is a means of identifying the structures of a document so that they can be recognized. A line of data in a text image field or in indexed text. The maximum size of a single line of data is 512 characters and normally represents a line of text as it appears on a printed page. A document can contain from 1 to 8000 sections. Like a document, a section can have a field group (section-level fields). (Sectioned records are not supported on Windows operating systems.) The long text field. Each continuous record can have only one text stream field. Each section of a sectioned record can have one text stream field. The long text field can contain up to 128 million characters. A text stream field can consist of physical and/or indexed text. (Sectioned records are not supported on Windows operating systems.) Revisable text which is normally output from a word processor. It can also be a binary large object (BLOB). BASIS stores physical text; it does not display physical text. American Standard Code for Information

Text Image Line

Section

Text Stream Field

Physical Text

Indexed Text

32  Overview of Database Definition and Development

Interchange (ASCII) text used to index and display text within BASIS modules. Each of the boxes of Figure 1-4 represents an object class. Single-headed arrows represent one-to-one relationships, and double-headed arrows represent one-to-many relationships. Not all records contain all of the parts shown in the figure. For example, conventional records contain neither sections nor text stream fields, and continuous records do not contain sections. For a more detailed description of the structure of the BASIS conventional, continuous, and sectioned record styles, see “Records.”

Overview of Database Definition and Development  33

Sectioned records are not supported on Windows operating systems.
Note:

Figures 1-5 through 1-7 illustrate the subsets of BASIS record architecture represented by each of the BASIS record styles:
Database

Document Field Group

Standard Field

Text Image Field

Subfield

Text Image Line

Figure 1-5: Conventional record architecture

Database

Document Field Group Text Stream Field

Standard Field

Text Image Field

Physical Text

Indexed Text

Subfield

Text Image Line
Figure 1-6: Continuous record architecture

Text Image Line

34  Overview of Database Definition and Development

Database

Document Field Group

Standard Field

Text Image Field

Subfield

Text Image Line

Section Field Group Text Stream Field

Standard Field

Text Image Field

Physical Text

Indexed Text

Subfield

Text Image Line
Figure 1-7: Sectioned record architecture

Text Image Line

Sectioned records are not supported on Windows operating systems.
Note:

Definition Database Overview
A Definition Database (DDB) is a special BASIS database that serves as the data dictionary for a Record Database. It is created and maintained by the DBA using the DMDBA module. Every Definition Database is a standard BASIS database that can be queried by authorized users and used to produce administrative reports.

Overview of Database Definition and Development  35

A DDB contains over 35 record types that are used by BASIS to describe a database, verify requested modifications to the definition, coordinate restructuring and maintenance tasks, control all access, track programs that use the database, and locate all the database files. Different record types describe each record, field, user model, view,

36  Overview of Database Definition and Development

index, area, file, and other definitions. Effectively, every object that can be used in the database definition process is described by a different record type. The name of the Definition Database is derived from the name of the associated Record Database. Its name is the Record Database name prefixed with an X. For example, the name of the DDB for the TOUR database is XTOUR. Thus, a standard record database name may not start with the letter X. As Figure 1-8 illustrates, it consists of three models, different aspects of database structure.

USER DATA MODEL

Local Views

– –

Has subsets of views for various user groups Maps records to views

ACTUAL DATA MODEL

Logical View

– –

Defines all records and fields Defines validation

STRUCTURAL DATA MODEL

Physical View

– –

Defines files, areas, and indexes Maps records and indexes to areas

Figure 1-8: Models in a Definition Database

Overview of Database Definition and Development  37

Actual Data Model The Actual Data Model (ADM) defines the records and fields in the database. It also describes many of the features for facilitating retrieval and ensuring the validity of data. The ADM represents the DBA’s point of view of the database.

38  Overview of Database Definition and Development

User Data Model The User Data Model (UDM) defines who can use what is in the database. It defines models consisting of one or more views of one or more records defined in the ADM. Some of these models may describe views of data for users, while others may describe the layout of view buffers in programs. The UDM represents the users’ points of view of the database. Structural Data Model The Structural Data Model (SDM) maps the records defined in the ADM to areas and data files and it defines how the data is stored on your computer system. The SDM represents the computer storage point of view. Why Three Models? The chief advantage in separating the Definition Database into three models is that it helps isolate the impact of changes. In many cases, if you make a change to one of the models, you won’t have to change the others. The three-model architecture contributes to data independence, which can save you and those who write database application programs considerable effort. The DDB can be used to track all the precompiled (FORTRAN or COBOL) programs that are authorized to use a particular User Data Model. Then, if a UDM is changed, it is easy to list all the programs that use that UDM. For example, if you add a new field to a view of the EMPLOYEE record in a UDM for the TOUR database, you could easily list all programs that use the view. These programs would have to be recompiled so they included the updated description of the view before BASIS would let them execute. One of your most important tasks as a database administrator will be to develop these three models. The “language” that you will use to write these is called the Data Definition Language (DDL).

Overview of Database Definition and Development  39

The next section describes the process of defining your application database. Chapters 2 through 21 of this manual describe each of the three models of the Definition Database in detail.

40  Overview of Database Definition and Development

Defining Your Database
Defining your database is one of the early steps in the database administration process. The following steps outline this process: 1. Plan and design your database 2. Name your DDB and its files 3. Build your database definition 4. Apply the database definition 5. Initialize the RDB and its journals 6. Create application programs, procs, menus, screen formats, and report formats if applicable to your operating system. 7. Authorize users 8. Load the database 9. Maintain the database Step 1 is described in Database Planning and Design. This guide also contains a tutorial for producing a simple database. Steps 2 through 4 are briefly described later in this chapter and described in greater detail later in this manual. The remaining chapters in this manual describe the background and DDL to help you perform step 3. Step 5 is described in “DMDBA Module.” Programming for Conventional Records, Programming with DHI, Programming with OpenAPI, Command Procedures, Screens, Markup and Style Guide, and Reports may assist you with step 6. Step 7 is described in “DMDBA Module.” Steps 8 and 9 are described in detail in Database Loading and Maintenance.

Overview of Database Definition and Development  41

Naming Your Database

After your SA has registered you to use BASIS and authorized you with CREATE database privileges, you can use the DMDBA module to name your database and describe the location of files for its DDB. (The location of the files for its RDB is defined later when you define the SDM.)

42  Overview of Database Definition and Development

You can rename a DDB or copy a DDB to make a new DDB by using PERFORM/MAINT statements in a file used by the DMDBA utility. For information about this and other maintenance-oriented tasks, see “DMDBA Module” and “Administrative Statements.”
Note:

Figure 1-9 illustrates a sample dialog for invoking DMDBA and responding to its prompts. Bold text indicates what you as a DBA might enter. For complete syntax and descriptions of DMDBA module parameters, see “DMDBA Module.”

Overview of Database Definition and Development  43

$ DMDBA DMDBA V5 881230 (L1) USER ID >IDI1 USER PW > DATABASE >TOUR1 There is no such database. Would you like to create the TOUR1 Definition Database (Y/N)? > Y Enter the file descriptor for the Definition Database. (Enter a complete File Descriptor including the directory name) >/idi1/tour/ddb Enter File Descriptor for Journal A of the Definiton Database. (Enter a complete File Descriptor including the directory name) >/idi1/tour/dja Enter File Descriptor for Journal B of the Definition Database. (Enter a complete File Descriptor including the directory name) >/idi1/tour/djb Should journals for the Definition Database be activated (Y/N)? > Y The Definition Database File and its Journals have been initialized. Record database is called: TOUR1 Definition database is called: XTOUR1 Your user name has been authorized for all models in both databases. After you enter and apply your definition, remember to perform the following administrative tasks: a. authorize programmers for the XTOUR1.TRACE model (so they can pre-compile programs) b. authorize users for private models of the TOUR1 database c. initialize your database files. Would you like to enter your definition ( Y/N)? Y

Figure 1-9: Use of DMDBA module to create and locate the DDB

Note that the system does not display the password that you enter. The name you give your database must not be the same as that for another BASIS database at your site. Because names of DDBs begin with X and because the system recognizes databases beginning with SYS for other

44  Overview of Database Definition and Development

purposes, the name of your application database must not begin with X or SYS. It must, however, begin with a letter

Overview of Database Definition and Development  45

and can contain one to seven letters and digits. As Figure 1-9 indicates, BASIS uses this name as the RDB name. The file descriptors in Figure 1-9 are for a UNIX system. For other systems they would differ. Table 1-1 lists the suggested file descriptor formats for various operating systems. The file descriptor for the Definition Database is for the compiled version of the statement or DDL file; note that its extension or suffix is DDB, not DDL.
Table 1-1: File descriptor formats for DDB and journals

Definition Database File Descriptor Format NT dir\DM_dbname.DDB

Journal A and Journal B File Descriptor Format dir\DM_dbname.DJA dir\DM_dbname.DJB dir/DM_dbname/DJA dir/DM_dbname/DJB

UNIX

dir/DM_dbname/DDB

VMS

device:[dir]DM_dbname.D device:[dir]DM_dbname. DB DJA device:[dir]DM_dbname. DJB

After you have answered Y to the question about creating a Definition Database, the system stores your application database name in the Authority Database and initializes the DDB so that you can build your database definition by entering the ADM, UDM, and SDM definitions. After you enter file descriptors for DDB Journals A and B, BASIS initializes these files. You can activate them now or wait until later. These journals store copies of the additions and changes made to the DDB. If the DDB becomes damaged because of a

46  Overview of Database Definition and Development

system or media failure, journals can be replayed to restore the DDB. When Journal A becomes full, the system switches to Journal B. For more information on maintaining, backing up, and restoring DDB and RDB journals, see Database Loading and Maintenance.
Deciding Whether to Activate DDB Journals

Whether or not you activate DDB journals depends on the complexity and frequency of updates to the DDB. Journaling is usually done when you enter a definition in screen mode and you want to keep a record of all the additions and changes you made. In statement mode your DDL file can serve as your backup or journal if ADM, UDM, and SDM are entered in statement mode. It is recommended that you activate DDB journals after you have completed development and testing of your DDB.
Building Your Database Definition

After the system confirms that the DDB journal files have been initialized and confirms the names of your RDB and DDB, it authorizes your user name with database administration privileges for both the RDB and DDB forms of your application database. Then the system asks whether you want to enter the definition for your application database. After you answer Y to that question, DMDBA displays a menu of choices:

Figure 1-10: DMDBA main menu

Overview of Database Definition and Development  47

Note that Option C, Enter a definition in screen mode, will not appear on the DMDBA main menu on Windows operating systems.

48  Overview of Database Definition and Development

Definitions that you enter into the Definition Database transform your database design into definitions that the system can use to validate, organize, and store data in your database. Using the DMDBA module, you can enter your DDB definition in statement mode by having created a text file using your preferred host system editor or in screen mode by using DMDBA menus and screens. Windows supports only statement mode. If you are using Windows operating systems, you should skip screen mode directions and references. However, be careful not to overlook statement mode information referenced within paragraphs that focus on screen mode.
Note:

If you are using BASIS on UNIX or VMS, you are not locked into one way of entering your database definition. You can, for example, begin in statement mode and later use screen mode. Although chapters in this manual show how the definition looks in statement mode, each of these definitions can be created in screen mode as well (but see note above). Before you choose to enter a definition in statement mode, you need to have created a file containing definition statements. If you use screen mode, you enter parts of the definition interactively by means of formatted screens. For a tutorial and information about using statement mode for defining the ADM and screen mode for defining the UDM and SDM, see Database Planning and Design.
Sequence for Building Your Database Definition

You build the ADM first. Then you build the UDM and SDM. Generally in a DDL file, the order is ADM, UDM, and SDM. If your database will have one or more multifield indexes—indexes that are built from fields that are typically searched together—and you want to use the COPY statement in your UDM, the SDM must be defined before the UDM in the DDL file. Otherwise the multi-field indexes will not be usable.
Note:

You should define your ADM before defining your UDM and SDM. Your ADM cannot be applied until after you define your SDM.

Overview of Database Definition and Development  49

Entering the Definition

You can enter ADM, UDM, and SDM definitions in parts. If you are using BASIS on UNIX or VMS, you can use statement mode or screen mode. (Only statement mode is available on Windows.) You can always get a current copy of parts or all of your DDL file by using the Database Extract (DMDDBE) utility. For more information on this and other database administration utilities, see Database Loading and Maintenance.

50  Overview of Database Definition and Development

Statement Mode In statement mode, you write your statements to a file using your host system editor. The file is commonly called a statement file or DDL file so you can give it a .DDL suffix or extension. The name you give this file can be any name that is meaningful to you and is a valid text file name on your host operating system. The name can be the name of the database plus the .DDL suffix or extension. Chapters 2 through 21 of this manual describe the full syntax for your ADM, UDM, and SDM definitions. After you have defined an ADM, UDM, and/or SDM via a statement file, you can invoke DMDBA and select option A from the menu displayed in Figure 1-10. The system responds with a prompt:
Enter the name of the file of statements that describe the database.

>

Statement File In statement mode, if a statement is so long that it needs to be continued on another line, use the plus sign (+) as a continuation character. Except for WORD_LIST and CODE_LIST statements, no ADM, UDM, or SDM statement may exceed 2000 characters. Several statements may be placed on one line if each statement is ended with a semicolon. Comment lines can be inserted in the statement file. An asterisk (*) introduces a comment line. Note that comment lines can be continued by using the plus sign (+) as a continuation character. You must double any embedded quotation marks that you use in your statement file. The statement file should contain standard variable length records. However, BASIS examines at most the first 250 characters of each input record. Statement File Processing After you enter the name of the statement file in response to the prompt, the system then reads (compiles) this file,

Overview of Database Definition and Development  51

checking it for syntax errors as it displays it on your terminal screen or in any output file you have specified. If there are errors, the system identifies them and displays error messages. If your terminal screen is not scrollable, you will need to exit DMDBA and invoke it again, specifying your DDL file and an output file on the command line—for example,
Note:
dmdba UID=your_user_id UPW=your_password DB=your_database_name GET=ddl_file_name MODE=STATEMENTS OUTPUT=output_file_name

52  Overview of Database Definition and Development

If there are syntax errors in your statement file, you can choose option
Y. Spawn to the host command level

or option
Z. Exit this program

from the menu to leave DMDBA and edit the DDL file. When all the errors are corrected, you can try again to enter the definition, repeating this process until the DDL file is error-free. When the DDL file is free of syntax errors and you have defined the ADM, UDM, and SDM, you are ready to apply the database definition. The “Applying Your Database Definition” section below describes this step. Screen Mode Windows supports only statement mode. If you are using Windows operating systems, you should skip screen mode directions and references. However, be careful not to overlook statement mode information referenced within paragraphs that focus on screen mode.
Note:

In screen mode you fill in values for the desired parameters displayed on the screen. Screens display all the objects that can possibly be placed in a DDB. In most cases, one screen corresponds to one statement in a statement file. You create an object by filling in the blanks on the appropriate screen and successfully entering its contents into the Definition Database. Because names of the parameters and default values are already displayed on the screen, screen mode may seem easier than statement mode, but many DBAs prefer statement mode because it eliminates having to navigate from screen to screen to enter DDB definitions. A few screens allow a frequent combination of objects to be created in a single screen. Screen 12 is such a screen. It allows the creation of one record type and all of the fields in it if the fields can be defined with a limited number of parameters. However, if you need to give additional parameters for a field, you can indicate these by filling in special boxes. A different screen is then automatically displayed, which permits entry of the additional parameters. For more information about screens that can be

Overview of Database Definition and Development  53

used to define the ADM, UDM, and SDM, see “ADM Screens,” and see “Creating Models and Views,” “UDM Screens,” and see “SDM Screens.” After you have defined the ADM, UDM, and SDM, you are ready to apply the database definition, as described below.

54  Overview of Database Definition and Development

Applying Your Database Definition

After you have successfully built and entered your database definition, BASIS stores the DDL statements or screen entries as a group of change orders. After you successfully APPLY these change orders, the system transforms them to machine-readable system records to build the database structure for your database in the Master Definition Database. Only after you have successfully compiled or applied the change orders for the ADM, UDM, and SDM is the complete database definition built. Change orders are created whether you enter your definition in statement mode or screen mode. They are also created when you change parts of a previously entered definition.
Looking at Change Orders

If you want to see the currently active change orders for your database before you apply them, choose option
T. Perform administrative tasks

from the DMDBA main menu, and then choose option
O. Show Change Orders

from the Administrative Tasks Menu. Table 1-2 lists and describes change codes associated with adding new definitions to the DDB, and Table 1-3 lists DDB objects and the change codes associated with adding the objects to the DDB. For more information about how to interpret the change codes on change orders and about the effects that changing an object may have on other objects, see “Change Codes.”

Overview of Database Definition and Development  55

Table 1-2: Some change codes and their definitions

Change Code IMMEDIATE

Definition The change can be made immediately. This type of change is isolated. It requires a change to only one DDB statement record and does not affect currently executing programs. No system records are modified. Changes to parameters marked NEXT APPLY are delayed until the next APPLY is performed. No restructures or recompiles need to be performed. Changes to parameters marked NO-RECOMP make it unnecessary to recompile any programs. But the change does not take affect until it has been applied. Changes to parameters marked NON-RETRO are non-retroactive. New data will be required to have this attribute but old data is not checked. Changes to parameters marked RECOMP make it necessary to recompile any precompiler-based user programs that reference this object after the change has been applied. The system will prevent the programs that have not been recompiled from referencing the modified view after the change has been applied. Changes to parameters marked RES-N/A require restructuring the database. If no records of this record type exist, the change order is posted and can be applied. If records of the record type exist, you must dump the records,

NEXT APPLY

NO-RECOMP

NON-RETRO

RECOMP

RES-N/A

56  Overview of Database Definition and Development

Change Code

Definition apply the change, and then reload the records.

Table 1-3 shows the change codes associated with adding new objects to your Definition Database. Entries in the table are grouped according to whether the model is ADM, UDM, or SDM.

Overview of Database Definition and Development  57

Table 1-3: Change codes associated with adding objects

Model ADM

Object RECORD FIELD optional required FIELD_LIST WORD_LIST CODE_LIST ASSERT DOMAIN_CONTROL_SET PARAMETER_SET THESAURUS_DATA_CONTROL_ SET SEARCH_CONTROL_SET REVL

Change Code NEXT APPLY NEXT APPLY NON-RETRO

IMMEDIATE IMMEDIATE IMMEDIATE NON-RETRO NEXT APPLY IMMEDIATE NON-RETRO

NEXT APPLY NON-RETRO IMMEDIATE IMMEDIATE IMMEDIATE NEXT APPLY RECOMP

UDM

MODEL PROGRAMS FIELD_LIST VIEW FIELD

58  Overview of Database Definition and Development

Model

Object BORDER

Change Code NO-RECOMP RES-N/A NEXT APPLY

SDM

INDEX unique not unique RECORD_STORAGE AREA FILE JOURNAL

NEXT APPLY IMMEDIATE NEXT APPLY NEXT APPLY

For a complete list of change codes associated not only with adding various objects but also with changing them or deleting them, see “Change Codes.”
Performing the Apply

To perform the apply, choose option
L. Apply changes made to the definitions

from the DMDBA main menu. Whether you have entered a part or all of a definition in statement mode or screen mode, it is a good idea to apply it. Change orders are applied in the order that statements were entered in the DDL file and entries were made on screens. However, if the system detects one or more errors in the change orders, none of the change orders is applied to the database. To fix these errors, you need to edit your DDL file and re-enter the definition or change the appropriate items on the screens. Then you can try your apply again. If your apply is successful, the system displays the message
APPLY successfully completed.

Overview of Database Definition and Development  59

Changing Your Database Definition

After you have successfully entered and applied your database definition, at some point you will probably want to add another field or add a word to a word list, or make any number of other changes. Making changes before loading the RDB is easier than making changes after loading the RDB when you may need to dump and reload data or drop and recreate indexes. For information about whether you need to apply any changes you enter (whether by re-entering one or more DDL statements or using a DMDBA screen to replace information), see “Change Codes.” If a field or record definition is changed, you need to be aware of the implications of the /UPDATE or /REPLACE qualifier that is part of the RECORD definition.

/UPDATE

Any new fields that you are adding join the fields already in your existing record. Any fields that you are changing replace the current field definitions in the existing record. Fields of the existing record that are not also in the new RECORD definition remain unchanged. This is the default qualifier. The new RECORD definition and FIELD definitions completely overwrite your existing RECORD definition in the ADM. Only those fields included in the new RECORD definition comprise the new record definition. The system posts change orders to delete all fields that were part of the existing definition but are not part of the new RECORD definition.

/REPLACE

If you are changing your database definition in statement mode, you can specify either the /UPDATE or the /REPLACE qualifier on your RECORD definition. If you are changing your database definition in

60  Overview of Database Definition and Development

screen mode, /UPDATE mode is assumed; screen mode can be used to update a definition, not to replace it. The /UPDATE or /REPLACE qualifiers function the same way on the VIEW definition in the UDM as they do on the RECORD definition in the ADM. For both the ADM RECORD and the UDM VIEW the default is /UPDATE. The default for the UDM COPY statement, however, is /REPLACE.
Note:

Overview of Database Definition and Development  61

If you use the DMFORM utility to create or change a screen form view and the system detects errors when you are doing an APPLY, it is best to delete the view using DMDBA before attempting to reenter the view DDL. For more information about the DMFORM utility, see Screens. (DMFORM is not applicable to Windows.) For more information about changing database definitions, see Database Loading and Maintenance.

Performing Administrative Tasks
After you have successfully applied your database definition, you can begin other administrative tasks associated with developing a database, namely initializing the RDB and authorizing users. For more information about performance of these and other administrative tasks via the DMDBA module, see “DMDBA Module.” You can also perform administrative tasks by entering administrative statements in a statement file. For a description of each of these administrative statements, see “Administrative Statements.” To perform one or more of them, invoke DMDBA, specifying the name of the statement file in the GET parameter and the name of the output file in the OUTPUT parameter; if you omit the OUTPUT parameter, output is displayed on your terminal screen.

62  Overview of Database Definition and Development


								
To top