\ue000Oracle Database Creation
\ue001Tablespace for application
\ue001Datafile for tablespace
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
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
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
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
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.
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.
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
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.
\ue000General Index Tablespaces with no partition.
\ue000General Index Tablespaces with partition.
\ue000Index Tablespaces for large Index.
\ue000Bitmap 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.
Example: WA_SALES_DATA, WA_SALES_INDX,
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.
Example: WA_SALES_DATA_01.DBF, WA_SALES_INDX_01.DBF
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.
\ue000Table names should use underscores between words
\ue000Each table should have comments
\ue000Table storage definitions should be appropriate to anticipated table use; it
This action might not be possible to undo. Are you sure you want to continue?