Welcome to Scribd. Sign in or start your free trial to enjoy unlimited e-books, audiobooks & documents.Find out more
Standard view
Full view
of .
Look up keyword
Like this
0 of .
Results for:
No results containing your search query
P. 1
Oracle Database Application Design Rules

Oracle Database Application Design Rules

Ratings: (0)|Views: 236|Likes:
Published by api-3759101

More info:

Published by: api-3759101 on Oct 15, 2008
Copyright:Attribution Non-commercial


Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See more
See less





Oracle Database Application Design
I.Int roduct ion
II. Oracle Layout
\ue000Development Environment
\ue000Quality Assurance Environment
\ue000Production Environment
III. Naming Standard

\ue000Oracle Database Creation
\ue001Tablespace for application
\ue001Datafile for tablespace

\ue000Objects for Schema
\ue001Temporary and Stage Tables
\ue001Database Triggers
\ue001Database Links
\ue001Program Files

\ue000Application Security
\ue001Schema IDs

\ue000Base Word
\ue000Abbreviation List
I. Introduction

The objective of this documentation is to provide information relevant to the day-
to-day operations of the Oracle server and suggested best practices to follow
when developing Oracle related applications.

Standards for the creation and maintenance of relational databases should be as
much a part of the infrastructure for software development as the computers and
the database itself. Good standards do not constrain the creativity of designers
and developers, but rather encourage the development of best practices. Also, as
the name implies, an enterprise now has common and consistent practices that all
members of the IT team can easily understand. If a standards document exists,
then all contractors and employees have a reference for how to interpret existing

Page 1 of 9
Design Rules
htt ://iwww.basf-cor .com/NTI/R/DatabaseAdmin/desi n_rule.htm

code and database objects. Even if the enterprise\u2019s standards are different from
an individual\u2019s common practice, it still creates the consistent common
environment. This can save hours of time and confusion and sometimes avoid
costly mistakes.

This document covers standards for Oracle database creation, objects for
application and application security. This paper does not cover standards for
design and coding (including SQL, PL/SQL, HTML, Java, etc.), GUI design,
database and system administration (e.g. SID names, control file names,
database file names, etc.), other file naming conventions and enterprise modeling
The intended audiences of this documentation are database administrators and
application developers. Knowledge of Oracle is the prerequisite to understanding
this document.

II. Oracle Layout
Three kinds of database environments are recommended for application. These
\ue000Quality Assurance

Within any given database, there may be more than one application assigned.
Operating policy will allow for applications to access and/or share their data within
the same database, different databases, or even from different databases type.
But access security must be followed Corporation standard and carefully

Development Environment

The Development environment is used for the development, maintenance, and
enhancement and debugging of applications. It is also used for the initial
installation, upgrades and testing of both system software and application
software. This database environment will allow developers to access all database
objects owned by the application. But application security MUST be implemented
in this environment.

Quality Assurance Environment

The Quality Assurance environment is used for acceptance testing by both end-
user communities and operations. This database environment is controlled.
Changes made to programs, databases objects and etc. will be approved,
monitored by the appropriate groups and then be executed by Database
Administrators. This database environment should be used to test and verify
changes before implementation in the production environment.

Production Environment

The Production environment is the most stable, restricted and controlled of all the
database types. Changes made to this environment will be carried out by
Database Administrators.

III. Naming Standard
Oracle Database Creation
Oracle software installation and database creation must be conducted by
Database Administrators.
Tablespace for application
Page 2 of 9
Design Rules
htt ://iwww.basf-cor .com/NTI/R/DatabaseAdmin/desi n_rule.htm

An oracle database consists of one or more logical storage units called
tablespaces which collectively store all of the database\u2019s data. Each application
will have its own tablespaces for data, indexes, text indexes and bitmap indexes.

Tablespaces can be classified as follows:
\ue000Data Tablespaces with no partition.
\ue000Data Tablespaces with partition.
\ue000Data Tablespaces for Large Table

\ue000General Index Tablespaces with no partition.
\ue000General Index Tablespaces with partition.
\ue000Index Tablespaces for large Index.
\ue000Bitmap Index Tablespaces.

\ue000Text Index Tablespaces.

The tablespace names should be the form of
<Application name>_<Function name>_<PRT>_<nnn>_DATA/INDX
Application name isabb re vi ati on of Application name. (e.g. WA for world account)
Function name is like SALES, PURCHASE etc. PRT is the partition type which
depends on type of application. For the data mart type of application where we
keep only fixed number of periods, the partitions <nnn> will be the sequence
number depending on the number of periods. For the data warehouse type of
application, the partitions <nnn> may be the partition year, or quarter or month.
Tablespace structure and size should be done jointly by Database Administrators
and Application Developers.

Datafile for tablespace

For performance reason, the data files of tablespace should spread out multiple
spindles (LUNs). Especially, data files for index and data tablespace. The datafile
name for tablespace should be the form of <Tablespace name>_<nnn>,dbf,
where nnn is the file sequence number for this tablespace.

Objects for Schema
It is prohibited to use Oracle data dictionary naming conventions like V$, X$,
USER_ and ALL_ for application object names. Use BASF standards for
abbreviation. The following type of objects is the most commonly used. If other
type of object is needed in your application, please contact Database
Administration Service for naming standard.

Table names should be short but meaningful. Avoid generic meaningless table
names like DETAIL_DATA, TMP3 or NEWSTUFF. Table names must be unique
throughout an application and describe their full significance within the
organization, not just within the application. It is a recommended practice to have
columns to capture details of creation or modifications to a table.

Below are the rules for table names:
\ue000Table names should be meaningful to business

\ue000Table names should use underscores between words
\ue000Each table should have comments
\ue000Table storage definitions should be appropriate to anticipated table use; it

is normal for storage clauses to be adjusted over time
\ue000Every table should have a primary or unique key
(This means that these two tables belong to the SALES schema.)
Page 3 of 9
Design Rules
htt ://iwww.basf-cor .com/NTI/R/DatabaseAdmin/desi n_rule.htm

Activity (8)

You've already reviewed this. Edit your review.
1 thousand reads
1 hundred reads
jayavardhankoti liked this
ellyacool2319 liked this
Pranay Patel liked this
Pranay Patel liked this
mkghai liked this
fmg_mdq liked this

You're Reading a Free Preview

/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->