oracle development guide.doc

ORACLEDevelopment Guide

Revised May 2006

ORACLE - Development Environment Guide

Introduction ................................................................................................................................................................................ iii

Purpose ......................................................................................................................................................................................................... iii

Audience ....................................................................................................................................................................................................... iii

Oracle Project Roles .................................................................................................................................................................. iii

Database Administrator (DBA) ...................................................................................................................................................................... iii

Oracle Instances ........................................................................................................................................................................ iv

Development ................................................................................................................................................................................................. iv

Test ............................................................................................................................................................................................................... iv

Training ......................................................................................................................................................................................................... iv

Production ...................................................................................................................................................................................................... v

Emergency Fix .............................................................................................................................................................................................. v

Off-site ........................................................................................................................................................................................................... v

Application Short Name .............................................................................................................................................................. v

Application Schemas .................................................................................................................................................................. vi

Object Schema .............................................................................................................................................................................................. vi

Application Schema ...................................................................................................................................................................................... vi

Headstart Schema ........................................................................................................................................................................................ vii

Conversion Schema ..................................................................................................................................................................................... vii

Web Schema ................................................................................................................................................................................................ vii

Oracle Object Standards .......................................................................................................................................................... viii

Tablespaces ................................................................................................................................................................................................ viii

Tables .......................................................................................................................................................................................................... viii

Standards .................................................................................................................................................................................................... viii

Views ............................................................................................................................................................................................................. ix

Columns ........................................................................................................................................................................................................ ix

Integrity Constraints ....................................................................................................................................................................................... x

Indexes .......................................................................................................................................................................................................... xi

Sequences ................................................................................................................................................................................................... xiii

Database Triggers ....................................................................................................................................................................................... xiv

Procedures, Functions and Packages ........................................................................................................................................................ xiv

Synonyms .................................................................................................................................................................................................... xv

Virtual Private Databases ............................................................................................................................................................................ xvi

Roles ........................................................................................................................................................................................................... xvi

Database Change Request (DCR) .............................................................................................................................................................. xvi

User Connection Logging .......................................................................................................................................................................... xviii

Operations Support .................................................................................................................................................................. xix

Backup and Recovery ................................................................................................................................................................................. xix

i

ORACLE - Development Environment GuideSource Backup System ............................................................................................................................................................................... xix

Availability of Oracle Environments ............................................................................................................................................................. xix

Appendix A - Oracle 10g Supported Features .......................................................................................................................... xx

ii


Introduction

Purpose

This document defines the standards, procedures and guidelines set by the Database Administration (DBA) group of the Information and Technology Management Branch (ITMB) for the construction phases of applications using the Oracle Database Management System (DBMS) at the Ministries of Education and Advanced Education.

The focus of this document is on technical issues related to the construction and implementation of Oracle based systems.

Audience

This guide will be of interest to the following people:• IMB Business Analysts: when defining system requirements.• Programmers: when creating or maintaining Oracle application systems.

Oracle Project Roles

Database Administrator (DBA)

• Reviews all physical data.

• Provides consulting to application developers on issues such as:◊ Oracle database design techniques◊ programming techniques◊ application performance tuning◊ data conversion and loads◊ recovery of data after system, application and media failure

• Identifies and sponsors the development of commonly used functions/procedures that can be used by multiple application systems.

• Defines and enforces all Oracle database object standards.

• Executes the DDL to define all Oracle database objects (except procedures, functions and packages) for all applications in all database environments (except any off-site environments and Ministry Development environments).

• Ensures the integrity of all Oracle production data by:◊ developing adequate database backup procedures◊ performing recovery procedures after system or media failure

• Defines and maintains developer Oracle user accounts and assigns Oracle roles to users.

• Ensures a high level of availability for all Oracle environments.

• Configures tuning parameters for Oracle instances.

• Identifies the need for Oracle and related third party product installations on the server.

• Reviews and customizes Oracle product installations on the server.

• Performs Oracle capacity planning (disk space and memory utilization).

• Creates application directories on the server.

iii


Oracle Instances

An Oracle Instance contains one or more Oracle schema. Each instance is assigned a four character Oracle system identifier (SID). The system identifier is of the format EEEn where EEE is the environment alias name and n is a sequential number (e.g. DEV1).

Development

Instance Name: DEV2

The Development environment is to be used by Programmers for the development and unit testing of application components. This environment is not normally available to end-users.

Test

Instance Name: TST2

The Test environment is to be used for integration and acceptance testing by Programmers and end-users alike. This environment is separate from development in order to ensure that users can perform testing in a stable environment. The purpose of integration and acceptance testing is to ensure that major problems will be detected before systems are implemented in the production environment.

The only way components are created or updated in the Test environment is through a formal release from the Development environment. For instance, developers therefore cannot make ad-hoc changes to this environment that impact end-users in the process of acceptance testing.

Training

Instance Name: TRN2

The Training environment may or may not be used by a particular application system. Its purpose is to teach end-users how to use a new or changed application. This stable environment is to contain production-like data that can be updated without impacting the actual production application. The application components in the Training environment are normally exact copies of those in Production.

iv


Production

Instance Name: PRD2

The Production environment is the "live" environment where the Ministry's business functions are performed. The Production environment differs from the other environments in the following ways:

• Targets are established for system availability and performance.• Integrity of data are carefully managed. For example, full point-in-time recovery of data are guaranteed. • Change to the environment is tightly controlled in order to meet targets for performance, availability and reliability.• Components are created or updated in the Production environment only through a release from the Test

environment.

Emergency Fix

Instance Name: EFX2

The Emergency Fix environment may or may not be used by a particular application system. Its purpose is to test patches that need to be applied into the Production environment for critical errors. This environment is to contain production-like data that can be updated without impacting the actual production application. The application components in the Emergency Fix environment are normally exact copies of those in Production.

Off-site

Consulting firms developing applications for the Ministry may create and manage their own "off-site" development environment. These environments will be constructed using the consulting firm's own hardware and software.

The Off-site environment is to be used by consultants (Programmers) for the development and unit testing of application components. Once unit testing is complete, the application should be migrated to the Ministry's Development environment. The consulting firm will be responsible for the migration of the application to the Ministry's Development infrastructure.

Application Short Name

The application short name is a three-character code that uniquely identifies the system within the Oracle Systems Environment at the Ministry of Education IMB. The application short name comprises the first three or four characters of the associated Oracle Designer application names.

Format: aaa

where: aaa is the unique application short name

Length: 3 characters

Example: HRS

CDM Ref; OMS-61605

v


Application SchemasEach project will have a minimum of two (2) schemas and a maximum of five (5) schemas. Each schema will have specific purpose, with specific objects, and specific system grants and privileges. Any additional schemas or grant will need to be submitted to the DBA group for approval.

Object Schema

The object schema should contain all database objects for the application. Developers will not have access to this schema beyond the development environment. All changes to this schema beyond development will have to be done through the DCR process (* See Page 18*).

Objects within the Object schema:Tables IndexesSequences TriggersViews ConstraintsPolices

Schema privilegesCreate Session Create Database LinkCreate Sequences Create SynonymsCreate Table Create TriggerCreate View Create Role

Naming Convention

Format: aaa



Example: HRS

Application Schema

The application schema should contain all application code. Developers will have access to this schema in all environments. Developers will do all changes to this schema and no DCR's are required.

Objects within the Application schema:Procedures PackagesFunctions

Schema privilegesCreate Session Create ProcedureCreate Synonyms

Naming Convention

Format: aaa_APP



Example: HRS_APP

vi


Headstart Schema

The headstart schema should contain all headstart objects and data related to the application.

Objects within the Headstart schema:Tables IndexesSequences TriggersViews ConstraintsPolices ProceduresPackages Functions

Naming Convention

Format: aaa_HST



Example: HRS_HST

Conversion Schema

The conversion schema should contain all code and objects required to convert archival data for the new application.

Naming Convention

Format: aaa_CONV

where: aaa is the unique business application short name


Example: HRS_CONV

Web Schema

The web schema should contain NO objects or code. This schema is used as an entry point for applications being used over the internet

Naming Convention

Format: aaa_WEB

where: aaa is the unique business application short name


Example: HRS_WEB

vii


Oracle Object Standards

Tablespaces

Each application will have a maximum of six tablespaces: three for all application data and three for the application indexes. The amount of data stored in an object determines the tablespace to be used. See the guidelines in the table below to determine which tablespace should be used for the object:

Object Size Tablespace Object Indexes0K - 500K aaa_small_data aaa_small_idx501K - 5 M aaa_medium_data aaa_medium_idx5.01M and up aaa_large_data aaa_large_idxAll tablespaces will be created as locally managed

Naming Convention

Format: aaa_sss_tttt

where: aaa is the application short name

sss is the size of tablespace

tttt is the tablespace type:

• DATA

• IDX

Length: 13 characters maxium

Example: HRS_MEDIUM_DATA, HRS_SMALL_IDX

Tables

Standards

• The Oracle DBA is the only user who has the authority to create tables and related database objects (excluding procedures, packages and functions) in the TST, TRN, PRD and EFX environments.

• Each table must have its primary key defined using an integrity constraint. For more information on integrity constraints, please refer to the Integrity Constraint section.

• Table Names are prefixed with the application short name of the application that is primarily responsible for the entry of the data contained in them. An example would be HRS_EMPLOYEE.

Guidelines

• Tables should always be in third normal form (3NF). An exception to this rule is when de-normalization is required for performance reasons. For example, a column may be duplicated from another table in order to avoid performing a specific costly table join. Approval from the DBA is required before performing any de-normalization.

• Use the SQL COMMENT statement to document the purpose of each table and column. Limit the comment to 80 characters to comply with the Oracle Designer standard.

• Columns that contain nulls should be grouped at the end of the table definition to conserve space.

viii

ORACLE - Development Environment GuideNaming Convention

Format: aaa_tttttttttttttttttttttttttt

where: aaa is the business application short name

tt...t is a descriptive name for the table

Length: 30 characters maximum

Example: CES_CONTRACT, HRS_EMPLOYEE, BIS_SPAN_MATERIAL

CDM Ref: OMS-42103, OMS-61561

Views

Views need not be defined for every table. However, views may be created in order to:

• Enable users and/or programmers to retrieve information from multiple tables without coding an SQL join. This is done by coding the join in the view definition.

• Limit access to certain rows or columns in a table to authorized users.

• Allow different column names to be used instead of those in the base table.

• Present data in a different format. For instance, a view could summarize data in a table.

Please note that even though integrity constraints are defined on the table/column level, they are still automatically enforced when using a view based on that table.

Naming Convention

Format: aaa_V_vvvvvvvvvvvvvvvvvvvvvvvv


vv...v is a descriptive name for the view


Example: HRS_V_ACTIVE_EMPLOYEE

CDM Ref OMS-42202

Note: Aside from the "V_" prefix, the view name should follow the same naming convention as table names.

Columns

Standards

• Integrity constraints must be defined for all columns that are a primary key, unique (non-primary) key or a foreign key. Refer to the Integrity Constraints section for more details.

Guidelines

• Foreign key column names should be the same as the referencing primary key column names.

• VARCHAR2 should be the default data type for character data. Do not use the CHAR data type. The VARCHAR2 datatype should only be used to store short character data. Character data that may exceed 1000 characters should be stored in a CLOB instead.

ix

ORACLE - Development Environment Guide• The data type LONG should NOT be used.

Naming Convention

Format: cccccccccccccccccccccccccccccc

where: cc...c is a descriptive name for the column


Example: SALARY_AMOUNT, DEPARTMENT_CODE, EMPLOYEE_ID,

CLIENT_COMMENT_TEXT, UPDATE_USERID, UPDATE_TIMESTAMP

Notes:

• Columns names are very similar to the attribute name in the Logical Data Model (e.g. UPDATE_TIMESTAMP vs. UPDATE TIMESTAMP

• The column name of a foreign key should match the corresponding primary key column name in the parent table. For example, the DEPARTMENT_CODE column in the HRS_EMPLOYEE table matches the name of the DEPARTMENT_CODE primary key of the HRS_DEPARTMENT table.

• Suffix all column names with the data class.

• Abbreviate column names only when the length is greater than 30 characters

Integrity Constraints

Integrity constraints are used by Oracle to prevent invalid data from being entered into tables

Standards

• When creating a primary or unique key constraint, explicitly specify the tablespace name for the associated index .

Guidelines

• Check constraints may be used, but are not recommended. Although they do allow simple business rules to be defined, complex rules must still be coded in database triggers. In addition, check constraints must be re-coded for each column that contains a particular business rule. The recommended approach is to code all business rules in database triggers. Rules that may be referenced by multiple columns should be defined in a common stored procedure and called directly from triggers.

•

Naming Convention

Primary Key Constraints

Format: aaa_tt …tt_PK

where: aaa application short name

tt…..t is the table/view alias

x

ORACLE - Development Environment GuideExample: HRS_EMPL_PK

CDM Ref: 42113

Unique Key Constraints

Format: aaa_tt…ttt_UK#

where: aaa is table alias name

tt…t is the table/view alias

# is a sequence number starting at 1, added to the constraint name to make it unique in case there are more unique key constraints defined for the same table

Example: HRS_EMPL_UK1

CDM Ref: OMS-42112

Foreign Key Constraints

Format: aaa_tt…t_tt…tt_nnnn_FK

where: aaa is application short name

tt…t is the referance table or view

nnnn is the logical name, when there is more than one foreign key contraint definedfor the same referance table or view

Example: HRS_EMPL_ACTEMPL_FK

CDM Ref: OMS-45019

Check Constraints

Format: aaa_tt...t_nnnn_CH

where: aaa is application short name

tt...t is the table or view alias

nnnn is the logical name indicating what the check contraint is about

Example: HRS_EMPL_HIRE_DATE_ON_WKDAY_CH

CDM Ref: OMS-42115

Note: The maximum length of constraint names is 30 characters. If necessary, names should be shortened to 30 characters using the same method as for column names.

Indexes

Indexes are automatically created for primary keys and unique keys when integrity constraints are created. Additional indexes may be required for a variety of reasons.

Standards

xi

ORACLE - Development Environment Guide• When creating an index, always explicitly specify a tablespace name.

xii


Guidelines

• Use the following rules to identify columns (other than primary and unique keys) that require an index:

◊ create an index on frequently-used queries. In addition, queries should retrieve less than 15% of the rows in a table.

◊ create an index on columns used in table joins (e.g. foreign keys).

◊ do not create an index on a column that has a large percentage of null values when there are no queries searching for non-null values.

◊ since indexes require considerable overhead to maintain, only create those that are currently needed. Additional indexes can be easily added as the need arises.

Naming Convention

Format: aaa_tt…t_cc...c_IDX



cc...c is the name of all columns in the index


Example: HRS_EMPL_NAME_IDX

Sequences

Oracle sequences generate sequential numbers that may be used as unique primary key values for application tables. Without sequences, primary key values must be generated with application logic

Standards

• Use the CACHE keyword on the CREATE SEQUENCE statement to specify the number of sequence numbers to cache. A value of 10-20 is normally sufficient.

• Ensure that an appropriate MAXVALUE is always specified.

Guidelines

• The NOCYCLE option will be specified for a large majority of sequences. Rarely will applications allow the re-assignment of sequence numbers.

Naming Convention

Format: aaa_tt…t_SEQ#



# is a sequence starting at 1, added to the sequence name to make it unique in case there are more sequences defined for the same table

Length: 30 characters maximumxiii

ORACLE - Development Environment GuideExample: HRS_EMPL__SEQ3

CDM Ref: OMS-42353

Database Triggers

• Applications should not use LOGON TRIGGERS. The ministry currently utilizes a Single Sign On architecture for its databases.

Although there are many types of database triggers, only two will be regularly used.• triggers to enforce business rules ("before row" triggers). These will contain all of the business rules for an individual

table.• triggers to maintain a de-normalized column ("after row" triggers). These will ensure that a de-normalized column is

updated whenever the parent column is altered. Triggers are stored in the Object schema since they are vital for database security and integrity. Any procedures, functions or packages required for the triggers will also be stored in the Object schema. Triggers are compiled by the DBA.

Standards

• Keep triggers to a maximum of 60 lines. The best way to do this is to put the majority of trigger logic in called procedures and functions. In addition to improving performance this allows code to be re-used. Trigger size can also be reduced by separating triggers according to the event type (i.e. have a separate trigger for inserts, updates and deletes).

Naming Convention

Format: aaaaaaaaaa_eeeeeeeeeee_TR

where: aa...a is the alias name of the table

ee...e are the events that cause the trigger to be fired.


Example: HRS_EMPL_AUDIT_TR

Procedures, Functions and Packages

Programmers have the ability to create and maintain Oracle stored procedures, functions and packages in all environments. However, all such code must be created in the Application (aaa_APP). Procedures, functions and packages coded for trigger logic can be stored in the Object schema. .A public or private synonym will be created so that the schema name will not have to be specified in application code.

Standards

• In error situations, invoke raise_application_error with the following parameters:

• An error number between -20000 and -20999. This number should be unique within each application. If more than 999 messages are required, the numbers will have to be reused and software components (e.g. SQL*Forms code) will have to parse the error text to distinguish individual errors.

• Appropriate error message text beginning with the literal 'Error: ...'.

xiv


Guidelines

• Whenever possible, avoid stand-alone procedures and functions. Instead, group related functions and procedures into packages.

Naming Convention

Packages:

Format: aaa_dd...d


dd...d is a description of the purpose of the code


Example: HRS_FIELD_EDITS, MIN_DATE_ROUTINES, MYTEST_FIELD_EDITS

Procedures:

Format: aaa_dd...d


dd...d describes the purpose of the code in the context of the package


Example: HRS_HIRE_EMPLOYEE, HRS_RAISE_SALARY

Functions:

Format: aaa_dd...d


dd...d describes the purpose of the code in the context of the package


Example: HRS_HIRE_DATE, HRS_LEAP_YEAR

Synonyms

All references to tables, views, sequences, packages, procedures and functions must be unqualified. That is, the schema name should never have to be specified in application programs or ad-hoc queries. This will be accomplished by defining a public or private synonym for each object after it has been created. The public or private synonym will be identical to the name of the base object.

Naming Convention

Format: nnnnnnnnnnnnnnnnnnnnnnnnnnnnnn

where: nn...n is the synonym for a base object


Example: HRS_EMPLOYEE will be a public synonym for the table HRS.HRS_EMPLOYEE.

xv


Virtual Private Databases

Virtual Private Database (VPD) are server-enforced, fine-grained access control, together with secure application context, which enable multiple customers and partners to have secure direct access to mission-critical data. Within a single database, the Virtual Private Database enables data access control by user with the assurance of physical data separation.

The Virtual Private Database feature provided fine-grained access control and application context. It secures data in the database by providing security at the row level, across the application, by attaching a security policy directly to a table or view.

Associating one or more security policies with tables or views enables the Virtual Private Database. Direct or indirect access to a table with an attached security policy causes the database to consult a function implementing the policy.

Standards

• All policies must allow access, to all data in all objects, to users with "EXP_FULL_DATABASE" role.

Example: IF DBMS_SESSION.is_role_enabled('EXP_FULL_DATABASE') THEN l_where := '1 = 1';

Roles

In this context, a role is a collection of Oracle object (and possibly system) privileges that provide access to an application system. Object privileges can be granted on tables, views, sequences, packages, procedures and functions.

Access to an application is controlled by:

• creating a set of user ids and roles

• granting privileges to roles

• granting roles to individual users.

Naming Convention

Format: aaa_jj...j


jj...j is the job description of the user.

Descriptions may include (but are not limited to):

• SYS_ADMIN - user with R/W access to all tables.

• USER - user with R/W access to most tables.

• DEVELOPER - application programmer

• MANAGER - more privileges than USER role.

• DATA_ENTRY - less privileges than USER role.

Length: 26 characters maximum. Oracle role names must be unique in their first 10 characters.

Example: HRS_SYS_ADMIN

Database Change Request (DCR)xvi

ORACLE - Development Environment GuideOracle Designer allows the developer of an application system to define a physical database design in a central repository. The physical design can then be used to automatically generate DDL statements to create the necessary database objects. If a developer manually codes DDL to create database objects, then these objects must be reverse-engineered into the dictionary.

DBA will generate all of the necessary DDL scripts from Oracle Designer to create the database objects for production.

Since Oracle Designer can easily regenerate DDL, a complex DDL source management system will not be used. The DBA may keep such DDL files on the system for informational purposes, but objects will always be altered or recreated from Designer.

Changes to tables, sequences, views, policies, indexes, triggers and constraints (the object schema) will be submitted to the DBA in a database change request (DCR). A DCR consist of a DCR form and all of DDL files required to alter the objects grouped into one sql block of code. DCR's will be reviewed by the DBA and then promoted to the next phase of the development cycle. DCR's will be implemented by the DBA in appropriate ministry change windows.

The developers or the application support team will implement changes to procedures, functions and packages (the Application Schema. These changes do not require a DCR process.

Naming Convention

Format: dcr_xxx.sql

where: xxx is a unique file identifier (numeric retrieved from DCR table)

Length: 8 characters (plus file extension)

Examples: DCR_001.sql

• DCR_001.sql contains DDL to change a table in the HRS system and their associated integrity constraints.

xvii


User Connection Logging

Every application should maintain a log of user connections. This log can be used by operations support to determine the usage characteristics of the application.

The application log should, at a minimum, contain the date/time and userid for every connection made to the application. If the application authenticates users rather than using database authentication then the log should include both successful and failed login attempts and should indicate which are which.

Applications that use database authentication can implement this requirement by adding a login trigger. Applications that perform their own user authentication will need to add this requirement to their authentication processing.

xviii


Operations Support

Backup and Recovery

The Database Administrator will ensure that appropriate backup procedures are in place to protect application data against system, media and software failure. When such outages occur, the DBA will execute all necessary restart and recovery procedures. The DBA is responsible to ensure the integrity of all application data while maximizing the availability of the Oracle production environment.

The application data in the Oracle production environment is protected by both database backups and on-line/archived redo logs. This gives the DBA the ability to restore application data to any recent point-in-time. Some applications also require the ability to restore data on a table-by-table basis. For instance, applications with batch update programs or those allowing ad-hoc deletions may need such protection. In these cases the DBA should be notified as soon as possible so that the additional backup and recovery procedures may be implemented.

Source Backup System

The UNIX system administrator has set up a procedure to back up all application source and executables.

If you would like to have a version of a file restored from tape, contact the Helpdesk for the appropriate application. The Helpdesk will pass on the request to the UNIX system administrator and inform her/him of:• the file name (including the full path) to be restored• the date the file should be restored from.

Availability of Oracle Environments

The Development, Test, and Production Oracle environments are normally available seven days a week. Additional outages to these environments may be scheduled by the DBA, the UNIX System Administrator, or the Oracle Product Support person in order to perform maintenance and upgrades. The duration of the outage will be determined on an as-needed basis. These outages will occur during change control windows.

xix


Appendix A - Oracle 10g Supported Features

The following table lists the features that are supported by the Ministry. Please consult the DBA’s about any non supported features.

Area Ministry Support

XML DB Yes

Java Yes

Application Express (HTML DB) Yes

xx

oracle development guide.doc

Documents