Mike Ault White paper

White Paper
WHITE PAPER PAGE 2

COPYRIGHT © 2002 ROBO BOOKS. ALL RIGHTS RESERVED.

 Notice
While ROBO Books makes every effort to ensure the information presented in
this white paper is accurate and without error, ROBO Books, its authors and its
affiliates takes no responsibility for the use of the information, tips, techniques
or technologies contained in this white paper. The user of this white paper is
solely responsible for the consequences of the utilization of the information,
tips, techniques or technologies reported herein.

Change History
Release Date Description By
1.0 8/2/2002 Initial release in ROBO Books format Michael R. Ault

WHITE PAPER PAGE 3

COPYRIGHT © 2002 ROBO BOOKS. ALL RIGHTS RESERVED.

 Table Of Contents
Notice....................................................................................................................................3
Change History..............................................................................................................................3
Table Of Contents................................................................................................................4
Introduction..........................................................................................................................5
Use of Standard Abbreviations..........................................................................................5
Databases.............................................................................................................................6
Tablespaces..........................................................................................................................6
Tables....................................................................................................................................8
Columns................................................................................................................................8
Constraints...........................................................................................................................9
Indexes................................................................................................................................10
Views...................................................................................................................................11
Redo Logs...........................................................................................................................11
Sequences..........................................................................................................................11
Oracle8 Types.....................................................................................................................12
Summary.............................................................................................................................12

WHITE PAPER PAGE 4

COPYRIGHT © 2002 ROBO BOOKS. ALL RIGHTS RESERVED.

 WHITE PAPER

Introduction
When designing a database it is imperative that a naming standard be developed. The naming standard
should address all levels of the process, from the database itself down to constraints on individual
columns. A naming standard provides a common reference point for developers, and users, to use to
obtain information on objects within the database and avoids latter confusion over what the developer or
designer was trying to accomplish with the names given to database objects.

Naming conventions need to be applied across an entire enterprise model. This universal application of
the standards prevents duplicate names and the ensuing confusion that may cause.

Use of Standard Abbreviations

A set of standard abbreviations should be developed that is provided to all developers and designers. This
list of abbreviations should also include common synonyms, and provide definitions for any acronyms in
common use in the company. This list should be a living document with periodic reviews to keep it current.
If possible it should be an online reference that is readily available to everyone using the system.

Examples of Abbreviations:

Word Standard Abbreviation

Activity ACTVY
Action ACTN
BreakOut BRKOT
. .
. .
. .
Zerox ZX

The standard abbreviation should be used for table, column and constraint naming.

Examples of a Synonym List:

Word Possible Synonyms

Dog Canine, mutt
Cat Feline
Automobile Car

The word listed in the synonym list as the main word should be the one you want them to use.

Examples of an Acronym List:

Acronym Meaning
USA United States of America
ATM Asynchronous Transaction Methodology
INS Inertial Navigation System

WHITE PAPER PAGE 5

COPYRIGHT © 2002 ROBO BOOKS. ALL RIGHTS RESERVED.

 WHITE PAPER

UFO Unidentified Flying Object

The acronym list should contain all of the acronyms commonly used in your business. These acronyms
can be used for table and column names. A defined list prevents confusion such as ATM meaning
Automated Teller Machine to one developer and Asynchronous Transaction Methodology to another.

In conclusion, when developing a database the first step should be to gather a comprehensive set of
standard abbreviations, synonyms and acronyms for your company or group. This collection of data should
be distributed to the entire development team and its use strictly enforced. Any new abbreviations should
be added as should new synonyms or acronyms.

Databases
The database name should be meaningful and convey information. For example, suppose you are creating
a database that acts as a Procurement Information Tracking System. This name is a bit long for a
database name so we reduce it to an acronym, PITS. This acronym will be in our allowed acronym list.
Next, we would like to know what database this application is written in, our approved abbreviation for
Oracle is OR. It would also be nice to know if a database is used for development (D), testing (T) or
Production (P) work. Finally, we may have multiple databases so let's put a numeric identifier that
corresponds to the order in which this database was created. Our instance name becomes:

ORPITSD1 for our first development instance, ORPITST1 for our first training instance and ORPITSP1 for
your first production instance and so on. A simple glance at the instance name now tells us the database
the system was developed in, the application it is applied to, whether this is a development, test or
production instance and a relative idea of when this database was created (first, second, third, etc.).

Oracle databases are limited to eight (8) characters for their name.

Names such as TEST, DEV and PROD should be avoided unless this is a very small development effort.

For parallel or shared instances, it is suggested a non-numeric be used in the name to denote this, so for
two parallel PITS test instances the names would be:

ORPITSTA
ORPITSTB

If this or a similar convention is used, the site specific convention document should state this relationship.

Tablespaces
Tablespaces should be named according function. In cases where multiple databases share the same
directory for file storage the instance name should be included in the tablespace name. Generally
speaking the file extension should be uniform for all database tablespace files. Usually the extension is
either “.dbf” or “.dat” depending on your operation system. Each file in a tablespace should have a
sequential number that relates to when it was created (1 for the first file, 2 for the next and so forth).

A database will have three types of tables, dynamic, static and temporary. It is suggested that the
tablespaces be created using “dyn”, “stat” and “tmp” as a part of their name if the tables are partitioned in
this manner. Using our database example name this would generate the following datafiles for table
storage:

WHITE PAPER PAGE 6

COPYRIGHT © 2002 ROBO BOOKS. ALL RIGHTS RESERVED.

 WHITE PAPER

ORPITST1_DATA_DYN_1.dbf For dynamic, growing tables

ORPITST1_DATA_STAT_1.dbf For static, configuration tables
ORPITST1_DATA_TMP_1.dbf For temporary or report tables

Indexes should be placed in their own tablespaces, following the above convention:

ORPITST1_INDX_DYN_1.dbf For dynamic, growing tables indexes

ORPITST1_INDX_STAT_1.dbf For static, configuration tables indexes
ORPITST1_INDX_TMP_1.dbf For temporary or report tables indexes

Rollback segments should be placed in their own tablespace which should be named accordingly:

ORPITST1_RBKS_1.dbf

If a large rollback segment is required, place it in its own tablespace and name it accordingly:

ORPITST1_LRG_RBK_1.dbf

There are certain base tablespaces that are a requirement in any environment. These are the SYSTEM
and TEMPORARY tablespaces:

ORPITST1_SYSTEM_1.dbf
ORPITST1_TMP_1.dbf

If a table is large enough to require its own tablespace (or an index) then name the tablespace
accordingly. For example, if we are the federal government, our VENDORS table may be several hundred
megabytes in size and require being spread across several tablespaces on several drives:

ORPITST1_VENDOR_1.dbf First partition

ORPITST1_VENDOR_2.dbf Second partition
.
.
.
ORPITST1_VENDOR_n.dbf Last partition

And for the tables index:

ORPITST1_VENDOR_I_1.dbf First partition

ORPITST1_VENDOR_I_2.dbf Second partition
.
.
.
ORPITST1_VENDOR_I_n.dbf Last partition

This convention again tells you what instance the tablespace is for, the general or specific purpose and the
number of the datafile for tablespaces with more than one file.

In Oracle8 and greater databases partitioned tables may be used. Partitioned tables should be stored in
tablespace that are named for the partition they contain.

If your system limits the number of characters for a file name, the above standard can be shortened by
removing the underscores, using standard abbreviations and, if you follow a directory naming convention
that partitions the files for a specific database into their own subdirectories, the instance name. However,
use as much space as you can to provide clear, meaningful tablespace datafile names.

WHITE PAPER PAGE 7

COPYRIGHT © 2002 ROBO BOOKS. ALL RIGHTS RESERVED.

 WHITE PAPER

Tables
Following the relational model, table names should always be a plural noun since they are collections of
entities (it logically follows that entity names should be singular in data models). Names should be as short
as possible, usually equal to or less than eight (8) characters. This length restriction to eight characters is
important since for column foreign key definitions and constraint naming the table name is used in
conjunction with column names.

For example, the table used to track ACCOUNTS PAYABLE in the PITS application would be:

ACCT_PAY

assuming the standard abbreviation for ACCOUNT is ACCT and PAYABLE is PAY.

Wherever possible abbreviations and acronyms should be used to shorten the table name. The
TAB_COMMENTS and TAB_COL_COMMENTS tables can be used to store a more detailed name which
can be used in a simple help stored procedure to provide detailed information on the table and its columns.

The importance of short table names cannot be stressed enough. However, using codes like A1, B1, Z28
for your tables is also to be avoided. Short meaningful names are the best.

A specialized type of table is the intersection table. An intersection table allows resolution of many-to-many
and recursive relationships. Let's say we have a many-to-many relationship between the PARTS table and
the VENDORS table (VENDS for short). The resolving intersection table should be named:

VENDS_PARTS (assuming the VENDORS table is the driving table for the relationship).

In Oracle8 and greater versions tables may be partitioned. Table partitions should contain the table name
and an indication of which partition the partition is, for example the first monthly partition would contain
MON1 as a part of its name while the first quarterly partition would contain the year and quarter 99Q1.

Columns
Column names should be as short and as meaningful as possible. The requirement that the column names
be short is driven by the fact that they are used along with the table names for constraint and index
naming. The column should be named according to abbreviation and acronym standards. You may also
strip vowels out of names to shorten them as required. However, each new abbreviation should be entered
into the list so that it can be used across the application development effort. The entity VENDOR has the
following attributes:

VENDOR

VENDOR CODE The primary identifier

PRODUCT CODE Must have at least one code
DESCRIPTION OF SERVICES An optional description field

The standard abbreviation list has the following pertinent entries:

Name Abbreviation
VENDOR VND

WHITE PAPER PAGE 8

COPYRIGHT © 2002 ROBO BOOKS. ALL RIGHTS RESERVED.

 WHITE PAPER

VENDORS VNDS
PRODUCT PRD
CODE CD
DESCRIPTION DSC
SERVICES SVC

So the table definition would be:

Table: VNDS

VNDS_CD NUMBER NOT NULL

VNDS_PRD_CD VARCHAR2(64) NOT NULL
VNDS_DSC_SVC VARCHAR2(200)

The primary key would be:

PK_VNDS

A lookup index on the Product code would be:

LI_VNDS_PRD_CD_1

Our examples illustrate the importance of short, meaningful names for columns and tables.

Constraints
There are five types of constraints in an Oracle database these are:

Primary Key
Foreign Key
Unique Value
Check Value
Default Value

Constraints should be named by function. For primary and foreign key constraints the constraints should
be named the same as their supporting indexes.

For example, for a primary key constraint on the ACCT_PAY table:

PK_ACCT_PAY or P_ACCT_PAY or ACCT_PAY_PK, etc.

For the unique value on the vendor code in the ACCT_PAY table the name could be:

UV_ACCT_PAY_VENDCD -- or -- UV_ACCT_PAY_1 (if it is the first unique value)

-- or -- ACCT_PAY_VENDCD_U (The supporting index would be named the same)

Within the 32 character limit imposed by Oracle this name can be as wordy as you wish.

For a foreign key constraint, the constraint indicator, the constraint table and the foreign table should be
included in the name, so for the foreign key to the VEND table from the ACCT_PAY table the constraint
would be:

WHITE PAPER PAGE 9

COPYRIGHT © 2002 ROBO BOOKS. ALL RIGHTS RESERVED.

 WHITE PAPER

FK_ACCT_PAY_VEND --or-- ACCT_PAY_VEND_FK

It may not always be possible to include all the column names in a foreign key name. If this is this case
you can make it just a numeric reference or describe the situation:

FK_ACCT_PAY_8COL_VEND --or-- FK_ACCT_PAY_1

For other types of constraint use a simple type indicator such as CK for check type constraints (such as
NOT NULL constraints) and DV for default value. Include the table name and the column name. So for a
NOT NULL on the VNDCD column:

CK_ACCT_PAY_VNDCD

You may also use a NN for NOT NULL instead of CK and reserve CK for special check constraints.

Indexes
Index names should reflect the table they belong to, their function and any other important data in their
name. There are four types of indexes in most applications, these are:

Primary key Index

Unique Index
Foreign Key Index
Lookup Index

Assign a single or double digit abbreviation that reflects these types:

Index Type Double Digit Code Single Digit Code

Primary key Index PK P
Unique Index UI U
Foreign Key Index FK F
Lookup Index LI L

This single or double digit code should either come before or after the rest of the name. Next, the table
name should be included, for a primary, unique or lookup index this may be all that is required. If there is
more than one unique or lookup index, a sequence indicator or column name may also be included. For
example, for a primary key on the ACCT_PAY table:

PK_ACCT_PAY or P_ACCT_PAY or ACCT_PAY_PK, etc.

For the lookup index on the vendor code in the ACCT_PAY table could be:

LI_ACCT_PAY_VENDCD -- or -- LI_ACCT_PAY_1 (if it is the first lookup index)

-- or -- ACCT_PAY_VENDCD_L

Within the 32 character limit imposed by Oracle this name can be as wordy as you wish.

For a foreign key index the index indicator, the index table and the foreign table should be included in the
name, so for the foreign key to the VEND table from the ACCT_PAY table the index would be:

FK_ACCT_PAY_VEND --or-- ACCT_PAY_VEND_FK

WHITE PAPER PAGE 10

COPYRIGHT © 2002 ROBO BOOKS. ALL RIGHTS RESERVED.

 WHITE PAPER

We recommend naming the indexes with the index type indicator first so you can tell with a quick glance at
an object list what are indexes and what are tables; however, this is a matter of personal preference.

Views
View names should include a VW to indicate they are a view (a synonym may be created to hide this fact
from the users) followed by the table name or names that the view includes (if possible).

For example, if we have view that includes the ACCT_PAY and VEND tables it would be called:

VW_ACCT_PAY_VEND and may have a synonym of CREDITORS.

Another method is to name the view according to function so the above view name would be
VW_CREDITORS with a synonym of CREDITORS.

Redo Logs
Redo logs should be named such that they contain thread, group and member information. The instance
name can also be included on systems where multiple databases reside. It is suggested that the word
“LOG” be included either in the name or the file extension:

For a two thread, three group, two member per group database:

ORPITST1_LOG11A.dbf -- or -- ORPITST1_11A.log For thread 1, group 1 member 1

ORPITST1_LOG11B.dbf -- or -- ORPITST1_11B.log For thread 1, group 1 member 2
ORPITST1_LOG12A.dbf -- or -- ORPITST1_12A.log For thread 1, group 2 member 1
.
.
.
ORPITST1_LOG23B.dbf -- or -- ORPITST1_23B.log For thread 2, group 3 member 2

Note: Since multi-threaded logs are usually only used for multi-instance databases, there may be two
instances (or more) involved in a multithreaded redo log naming standard. For grouped instances, ensure
this is reflected in the instance naming, such as by using A, B in place of numbering of the instances. This
should be defined in the site naming conventions.

Sequences
Sequences are used for derived primary keys, or for other situations where a number is required in the
database. Sequences should be named for the table and column they are used for. The SEQ indicator
should be either the last or first part of the name to differentiate sequences from other database objects. A
sequence used to derive the vendor code for the vendor table would be named:

VNDS_VNDCD_SEQ -- or --- SEQ_VNDS_VNDCD

WHITE PAPER PAGE 11

COPYRIGHT © 2002 ROBO BOOKS. ALL RIGHTS RESERVED.

 WHITE PAPER

Sometimes sequences may be shared for a group of tables. In this case the tables should form a section
of the database such as the VENDOR section or the PRODUCT section. It is not advisable to have a
single sequence used by an entire application. In the above situation name the sequence for the section in
which it is used:

PRODUCT_SEQ -- or -- VENDOR_SEQ

Oracle8 Types
Generally, types should follow the previously noted naming conventions. However, there are some basics
constructs in types that require new rules.

1. All defined TYPES end in “_t”

2. All VARRAYs constructed from types or standard datatypes end in “_v” (use “_vw” for views)
3. All NESTED TABLES constructed from types or standard datatypes end in “_list”.
4. When used in a DDL statement native datatypes are capitalized while user defined types are
lowercase.
5. The entities are singular while the tables or objects that they become are plural or are a plural or
neutral form.
6. All REF columns end in “_r”.
7. All Object ID indexes (OID) have the prefix “OID_” followed by the table name.

Summary
The importance of naming conventions cannot be stressed enough. The database needs to be designed
using standard names, abbreviations and synonyms. If naming conventions aren’t created and applied
consistently a database quickly becomes unmanageable.

WHITE PAPER PAGE 12

COPYRIGHT © 2002 ROBO BOOKS. ALL RIGHTS RESERVED.