This document establishes naming standards for Oracle database objects, schemas, accounts, and files within the IRS environment. Key points include: - Database objects, schemas, and accounts will include the project identifier or acronym to uniquely identify each project. - Critical database files like control files, redo logs, archive logs, and data files will be placed in standardized locations and follow consistent naming conventions. - Tablespaces will be used to logically group related database objects together and simplify administration. Datafiles will be explicitly created for each tablespace. - Standards cover areas like mount points, directory structures, application file paths, schema and account formats to promote organization and ease of management.

1. 1
1 Oracle Database Naming Standards
1.1 Purpose
This section establishes the standards, guidelines, procedures, processes, and policies
that will govern the use of Oracle DBMS software within the IRS Modernization effort
and the Tier II Consolidated Environment.
1.2 Scope
These standards are applicable for all Oracle schema objects, operating system data files, and
instance names.
These standards and guidelines are to be followed for all IRS Modernization Development and
Deployment using the Oracle database environment.
For Legacy applications, continue using the naming convention in place for that application's
legacy data. Work toward aligning legacy data with the new standards whenever feasible.
Include resource requirements in the project budget to comply with these standards.
1.3 Reference Publications
The following publications contain related information that is useful in understanding the Oracle
database environment:
• Oracle Database Concepts
• Oracle Server SQL Language Reference Manual
• Oracle Server Administrator’s Guide
• Oracle Server Installation Guide
• Optimal Flexible Architecture (OFA), Oracle Corporation
• Oracle Network Dictionary
1.4 Oracle Memory Structure and Processes Overview
An Oracle server uses memory structures and processes to manage and access the database.
All memory structures exist in the main memory of the computers that constitute the database
system. Processes are jobs that work in the memory of these computers.
The architectural features discussed in this section enable the Oracle server to support:
• Many users concurrently accessing a single database
• The high performance required by concurrent multiuser, multiapplication database
systems
The figure below shows a typical variation of the Oracle server memory and process structures.

2. 2
Memory Structures and Processes of Oracle
Note:
In a UNIX environment, most Oracle processes are part of one master Oracle process, rather
than being individual processes. On Windows NT, all processes consist of at least one thread. A
thread is an individual execution within a process. Threads enable concurrent operations within
a process so that a process can run different parts of its program simultaneously on different
processors. A thread is the most fundamental component that can be scheduled on Windows
NT. In UNIX documentation, such as this book, whenever the word "process" is mentioned, it is
considered a "thread" on Windows NT.

3. 3
1.5 Definitions
The following definitions are presented here for understanding the Oracle database
environment.
• System Global Area (SGA)
• A group of shared memory structures that contain data and control information for
one Oracle database instance. If multiple users are concurrently connected to the
same instance, then the data in the instance's SGA is shared among the users.
Consequently, the SGA is sometimes referred to as the shared global area.
• Instance
• A system global area (SGA) and the Oracle background processes constitute an
Oracle instance. Every time a database is started, a system global area is allocated
and Oracle background processes are started. The SGA is deallocated when the
instance shuts down.
• Background Process
• Background processes consolidate functions that would otherwise be handled by
multiple Oracle programs running for each user process. The background processes
asynchronously perform I/O and monitor other Oracle processes to provide
increased parallelism for better performance and reliability.
• Oracle creates a set of background processes for each instance.
• SID - Oracle System Identifier (SID)
• A name that identifies a specific instance of a running Oracle database. For any
database, there is at least one instance referencing the database. For databases,
SID is used to identify the database. The SID is included in the connect descriptor of
a tnsnames.ora file and in the definition of the listener in the listener.ora file.
• tnsnames.ora file
• A configuration file that contains one or more domains mapped to connect
descriptors. This file is used for the local naming method. The tnsnames.ora file
typically resides in $ORACLE_HOME/network/admin on UNIX platforms, and
ORACLE_HOMEnetworkadmin on Windows platforms.
Refer to the Oracle Network Dictionary in Appendix A for a complete list of definitions relevant to
the Oracle database environment.
1.6 The Tier II UNIX File Structure and Application File Naming Standards
The Tier II Consolidated Environment utilizes the UNIX Operating System (OS). The following
standards are presented to provide an understanding of the Tier II UNIX File structures and
standards for applications.
For database applications in the Tier II environment, a three level mount point name of:

4. 4
/”Project-Indentifier”/”Mountpoint-Identifier”/”purpose” has been adopted where the “Project-
Identifier” is the acronym for the project, e.g., icp or als; “Mountpoint-Identifier would be ‘u01 (or
u1, or apps)’; and “purpose” would be ‘bin’, ‘etc’, ‘usr’.
The first level of the directory structure must indicate the project name/acronym.
Having the project name always the first level of the mount point would allow a Systems
Administrator (SA) to ‘cd’ (change directory) into that directory, and at a glance, see all file
systems associated with that project.
This structure will include any application executables.
The following standard will be followed for Application file names and paths:
• Root
• /”Project-Identifier”/”Mountpoint-Identifier”/bin
• /”Project-Identifier”/”Mountpoint-Identifier”/etc
• /”Project-Identifier”/”Mountpoint-Identifier”/usr
Continue this naming hierarchy for all directories within the application
Lower level directories may be used if required by the application.
For other Operating System (OS) environments, (e.g., Windows), adjust the naming pattern to fit
the OS. An example for the Windows Operating System (OS) is presented below:
• Root
• ”Project-Identifier”bin
• ”Project-Identifier”etc
• ”Project-Identifier”usr
Continue this naming hierarchy for all directories within the application
1.7 Tier II UNIX Oracle Database Object Definition and Naming Standards
1.7.1 Oracle Mount Point, File Placement, and Path Naming Standards
Oracle Database Mount Point, File Placement and Path Naming Standards included are:
1.7.1.1 Mount Point Definition
In computers, to mount is to make a group of files in a file system structure accessible to a user
or user group. In some usages, it means to make a device physically accessible.
In a UNIX environment, the mount command attaches discs, or directories logically rather than
physically.
The UNIX mount command makes a directory accessible by attaching a root directory of one file
system to another directory, which makes all the file systems usable as if they were
subdirectories of the file system they are attached to. UNIX recognizes devices by their location,
as compared to Windows, which recognizes them by their names (C: drive, for example). UNIX
organizes directories in a tree-like structure, in which directories are attached by mounting them
on the branches of the tree.

5. 5
The file system location where the device is attached is called a mount point.
1.7.1.2Oracle Data File Mount Point
A mount point for a project’s database data files using EMC or native DASD will be:
/”Project-Identifier”/ ”mount point id”/”ora<purpose>” /”database SID”.
Allowable purposes are: data, idx (index), log.
The following are examples of database mount points with sub-directories:
• Data - /efds/u01/oradata/EFDS
• Index - /efds/u01/oraidx/EFDS
• Log - /efds/u01/oralog/EFDS
1.7.1.3 Control Files
Place one control file in /var/opt/oracle/”database SID”/ctl. (This will be in the root partition and
will be mirrored.)
Place another control file in /opt/app/oracle/admin/”database SID”/ctl.
• Examples: /var/opt/oracle/efds/ctl/EFDScontrol.ctl and
/opt/app/oracle/admin/efds/ctl/EFDScontrol.ctl.
Control files are now spread across EMC mount points.
1.7.1.4 Parameter File
Place the init<SID>.ora parameter file under:
/opt/app/oracle/admin/”database SID”/pfile.
• Example: /opt/app/oracle/admin/EFDS/pfile /initEFDS.ora.
For Oracle Release 8.1.7.4; in order to make startup easier, you may place an additional
init<SID>.ora file in the $ORACLE_HOME/dbs directory which only includes an IFILE parameter
pointing to the actual location.
An example IFILE entry is: IFILE = “/opt/app/oracle/EFDS/pfile/initEFDS.ora”.
For Oracle Releases after 8.1.7.4; Oracle now recommends the use of the “spfile”. Create an
“spfile” through the use of Oracle commands in the default location (ORACLE_Home/dbs). This
file must be regenerated each time you edit the “init.ora” file to enable the changes.
1.7.1.5 Core Dump Destination Path
Oracle’s OFA normally places it under:
/”mount point”/oracle/admin/”database SID”/cdump.
• Example: /opt/app/oracle/admin/EFDS/cdump.
Do not place the core dump file on EMC DASD.

6. 6
If EMC DASD must be used, point the core dump file to a mount point named as follows:
/”Project-Identifier”/”mount point id”/oralog/”database SID”/cdump.
• Example: /efds/u02/oralog/EFDS/cdump.
1.7.1.6 Background Dump File Path
Oracle’s OFA normally places it under:
/”mount point”/oracle/admin/”database SID”/bdump.
• Example: /opt/app/oracle/admin/EFDS/bdump.
Do not place the background dump file on EMC DASD.
If EMC DASD must be used, point the background dump file to a mount point named as follows
/”Project-Identifier”/”mount point id”/oralog/”database SID”/bdump.
• Example: /efds/db1/oralog/EFDS/bdump.
1.7.1.7 User Dump File Path
Oracle’s OFA normally places it under:
/“mount point”/oracle/admin/”database SID”/udump.
• Example: /opt/app/oracle/admin/EFDS/udump.
Do not place the user dump file on EMC DASD.
If EMC DASD must be used, point the user dump file to a mount point named as follows:
/”Project-Identifier”/”mount point id”/oralog/”database SID”/ udump.
• Example: /efds/u01/oralog/EFDS/udump.
1.7.1.8 Audit File Destination Path
If the Oracle auditing is written to an operating system file instead of an Oracle table inside the
database, Oracle’s OFA normally places the audit file under:
/”Project-Identifier”/“mount point id”/oracle/admin/”database SID”/adump.
• Example: /opt/app/oracle/admin/EFDS/adump.
Do not place an Oracle generated operating system audit log file on EMC DASD.
If EMC DASD must be used, point the audit log file to a mount point named as follows:
/”Project-Identifier”/”mount point”/oralog/”database SID”/adump.
• Example: /efds/db1/oralog /EFDS/adump.
The IRS currently stores audit trail data to a table in the database. Extracts of this data will be
written to:
• /var/audit/oracle.
Procedures will be implemented to back up this file to tape before being deleted from
/var/audit/oracle.

7. 7
1.7.1.9 Archive Log File Path
Place archive log files in a mount point named as follows:
/”Project-Identifier”/”mount point id”/oralog/”database SID”/arch.
• Example: /efds/db1/oralog/EFDS/arch.
Whenever possible, do not place archive logs on the same mount point or physical device as
the redo logs for the same database.
1.7.1.10 Redo Log File Path
Place the redo logs under a mount point named as follows:
/”Project-Identifier”/”mount point id”/oradata/”database SID”/.
• Example: /efds/db1/oradata/EFDS.
The “Redo Log File” is a database data file, which is required for the database to run properly.
Therefore, it is placed under oradata rather than oralog. Do not place redo logs on the same
mount point or physical device as the archive logs for the same database.
1.7.2 Oracle Internet Application Server Naming Standards
1.7.2.1 Installation Mount Point
The IRS standard base directory for installation of Oracle’s application server is as follows:
/opt/app/oraweb.
1.7.2.2 Project Apache Listeners and Java Virtual Machine (JVM)
The projects deploying web-based applications in a shared environment will configure their
Apache Listeners and JVMs in a copy of the Application Server’s Apache Listener and JVM
software in a base mount point named as follows:
/”Project-Identifier”/apps/Apache.
• Example: /ictrs/apps/Apache.
1.7.2.3 Web Server Application Sub-Directories
Application sub-directories must be in a sub-directory under:
/”Project-Identifier”/apps.
• Example: /ictrs/apps/htmldoc would be the main directory for html pages.
1.8 General Oracle Naming Standards
The following standards will apply for the naming of Oracle objects.
A general guideline for naming Oracle objects is presented below:

8. 8
• The object name in the Logical Model may be extended to the length supported by
the design tool employed.
• The object name in the Physical Model will be limited to the constraints inherent in
the target DBMS.
• As an example, DB2 limits table names to 18 characters. If a table has been
defined for the Enterprise in DB2 with a name length of 18 characters (or less),
use that same name when defining an Oracle table. In other words, use the
“Lowest Common Denominator” (in this case, Table name) when defining an
object.
1.8.1 Oracle Database Schema Naming Standards
The following standards will apply for the naming of Oracle database schemas.
Every project must have a unique acronym.
All schema names will be in the following format:
• Project-Identifier/Acronym_Function-ID
• The ‘Function-ID’ is optional. See the examples below for usage.
• Examples are listed below:
• EFDS
• If separate schemas are required by the application, use the format below:
• Project-Identifier_RG01 (Region 1)
• Project-Identifier_RG02 (Region 2)
If a database is used by more than one (1) project, the database will be named for the first
project. All other projects will use an alias to emulate a separate database. The alias will be the
“Project Name” applied through the “tnsnames.ora” file.
1.8.2 Oracle Database Account Naming Standards
The following standards will be followed for the naming of Oracle database accounts.
1.8.2.1 Schema Account
For projects using a single instance of the Oracle database, the Oracle Schema account ID is
“Project Acronym”.
For projects requiring multiple instances of the Oracle database, the Oracle Schema account ID
is “Project Acronym_Function”.
1.8.2.2 Non-Schema (User) Account
Oracle application user accounts will use the IRS network logon account ID. This standard will
be enforced for all applications, and their associated user base.
In cases where the database has been configured to add a prefix to the logon, the username
shall be the prefix concatenated with the network login in the form: PrefixNetworkLogon.

9. 9
1.8.3 Definition of Oracle Tablespaces, Databases, and Datafiles
1.8.3.1 Tablespaces
A database is divided into logical storage units called tablespaces, which group related logical
structures together. For example, tablespaces commonly group together all application objects
to simplify some administrative operations.
1.8.3.2 Databases, Tablespaces, and Datafiles
The relationship between databases, tablespaces, and datafiles (datafiles are described in the
next section) is illustrated in figure below.
Databases, Tablespaces, and Datafiles
This figure illustrates the following:
• Each database is logically divided into one or more tablespaces.
• One or more datafiles are explicitly created for each tablespace to physically store the
data of all logical structures in a tablespace.
• The combined size of the datafiles in a tablespace is the total storage capacity of the
tablespace. (The SYSTEM tablespace has 2 megabyte (Mb) storage capacity, and USERS
tablespace has 4 Mb).
• The combined storage capacity of a database's tablespaces is the total storage capacity
of the database (6 Mb).
1.8.3.3 Online and Offline Tablespaces
A tablespace can be online (accessible) or offline (not accessible). A tablespace is generally
online, so that users can access the information in the tablespace. However, sometimes a
tablespace is taken offline to make a portion of the database unavailable while allowing normal
access to the remainder of the database. This makes many administrative tasks easier to
perform.
1.8.3.4 Datafiles

10. 10
Every Oracle database has one or more physical datafiles. The datafiles contain all the
database data. The data of logical database structures, such as tables and indexes, is
physically stored in the datafiles allocated for a database.
The characteristics of datafiles are:
• A datafile can be associated with only one database.
• Datafiles can have certain characteristics set to let them automatically extend when the
database runs out of space.
• One or more datafiles form a logical unit of database storage called a tablespace, as
discussed earlier in this chapter.
Data in a datafile is read, as needed, during normal database operation and stored in the
memory cache of Oracle. For example, assume that a user wants to access some data in a
table of a database. If the requested information is not already in the memory cache for the
database, then it is read from the appropriate datafiles and stored in memory.
Modified or new data is not necessarily written to a datafile immediately. To reduce the amount
of disk access and to increase performance, data is pooled in memory and written to the
appropriate datafiles all at once, as determined by the database writer process (DBWn)
background process.
1.8.4 Oracle Database Tablespace Naming Standards
The standard tablespace types are:
Tablespace Function
SYSTEM (Oracle default) System tablespace
DATAnn Generic data
IDXnn Generic indexes
Application_Name_DATA Application specific data
Application_Name__INDEX Application specific indexes
RBS Rollback Segment
USERS Miscellaneous user data
TEMP Temporary segments
TOOLS Tools data (COTS)
Tablespace naming will be controlled by the project. No two projects will share a tablespace.
All Oracle Tablespace names will include a “tablespace identifier” of “tbs”.
Oracle Database Tablespace Naming Standards included are:
• Data Tablespace – “Project-Identifier”||“tablespace identifier”||”abbreviated data
tablespace descriptive name”||”tablespace type”
• Example: efds_tbs_annual1_data.
• Exceptions to this standard are listed below:
• System Tablespace (SYSTEM),
• Temporary Tablespace (TEMP),
• Rollback Tablespace (RBS, RBS1, etc),
• Users Tablespace (USERS),

11. 11
• Tools Tablespace (TOOLS),
• Other COTS tablespaces.
• Index Tablespace Files – “Project-Identifier”||“tablespace identifier”||”abbreviated index
tablespace descriptive name”||”tablespace type”.
• Example: efds_tbs_annual1_idx.
For Legacy applications, continue using the naming convention in place for that application's
legacy data. Work toward aligning legacy data with the new standards whenever feasible.
Include resource requirements in the project budget to comply with these standards.
1.8.5 Oracle Database Data File Naming Standards
In the Oracle environment, as Data File is defined as:
• A physical operating system file on disk that was created by Oracle and contains data
structures such as tables and indexes. A data file can only belong to one database.
Oracle Database Data File Naming Standards included are:
• Data Tablespace Files – “Project-Identifier”||”_”||“tablespace identifier”||”_”||”tablespace
name including tablespace type”||”_”||”tablespace file no.”||”.dbf”.
• Example: efds_tbs_curr_stars_data_01.dbf
• Index Tablespace Files – “Project-Identifier”||”_”||“tablespace identifier”||”_”||”tablespace
name including tablespace type”||”_”||”tablespace file no.||”.dbf”.
• Example: efds_tbs_curr_stars_idx_01.dbf
1.8.6 Database
In a multi-database environment, database names (and thus SIDs) must reflect the business
activity environment. The following conventions will be used:
• DEV - The combined development and unit testing instance of the data base where all
objects are initially constructed and tested, and where unit testing will be conducted prior
to migration to SAT.
• SAT – The test instance of the database where Systems Acceptance Testing (SAT)
testing will be conducted prior to migration to QA4.
• IMT - The integration test instance of the database where Infrastructure Migration Testing
(IMT) will be conducted prior to migration to production.
• TRNG - The Training instance of the database where the user training will be conducted.
• PROD - The production instance of the database that the client will use.
• Maximum length of the instance name will be 8 characters.
1.8.7 Table
The following standards apply for naming tables in the Oracle environment:
• A table name must contain only the letters of the alphabet and a word separator.
• A table name must describe the business entity that the table will represent.
• A table name must be concise. Prepositions (especially "of"), conjunctions (and, or), and
articles (a, an, the) must not be used in the name.
• Example: FILER

12. 12
The table name must use nouns and must be in the singular form.
The table name in the Logical Model may be extended to the length supported by the
design tool employed.
The table name in the Physical Model will be limited to the constraints inherent in the
target DBMS.
1.8.8 Key(s)
A key is a column or set of columns that identifies a row in a table. Three types of keys are:
• Primary
• Foreign
• Alternate
For indexes that enforce a constraint, such as Primary Key, Foreign Key and Alternate Key
constraint, the index will have the same name as the constraint. Specific guidance follows.
1.8.8.1 Primary Key Constraint
The standard naming convention for primary keys is:
• PK_TableName
• Example: PK_FILER
For physical database implementation, in the case of a Primary Key composed of many
columns, a “surrogate key” may be used (e.g., sequence generated number). In this case, the
Primary Key is a candidate for implementation as an Alternate Key.
1.8.8.2 Foreign Key Constraint
The standard naming convention for foreign keys is:
• FKnn_TableName
• Example: FK03_FILER_NUMBER
1.8.8.3 Alternate Key Constraint
An alternate key is a column or set of columns, different from the primary key, which can be
used to uniquely identify a row in a table.
The standard naming convention for alternate keys is:
• AKnn_TableName
• Example: AK01_FILER_ADDRESS
1.8.9 Index
The standard naming convention for indexes that do not support keys is:
• Inn_TableName_Function

13. 13
The standard naming convention for indexes that support keys is:
• KeyTypennTableName
The table name references the table being indexed and the number is a unique indicator for that
particular index.
1.8.10 Views
The following standards apply for naming views in the Oracle environment:
• A view name must contain only the letters of the alphabet and a word separator.
• A view name must describe the business entity, or entities, that the view represents.
• A view name must be concise. Prepositions (especially "of"), conjunctions (and, or), and
articles (a, an, the) must not be used in the name.
The standard naming convention for views is:
• V_ViewName
• Example: V_FILER_RETURN
1.8.10.1 Materialized View
A ‘Materialized View’ is used to speed data retrieval and summarization for (predefined) reports
and ad-hoc analysis (which could include the use of virtual (logical) “data cubes”. A materialized
view is typically on 1 fact table, several dimension tables, and involves aggregate functions such
as: SUM.
The standard naming convention for materialized views is:
• MV_ViewName
• Example: MV_FILER_RETURN
1.8.10.2 XML View
A ‘XML View’ is a view created on a XMLType table. Refer to Oracle’s documentation for details
regarding the use of XML with Oracle.
The standard naming convention for XML views is:
• XV_ViewName
• Example: XV_FILER_RETURN
1.8.11 Dimensions
Dimensions are Oracle objects that take no physical space. They are normally defined in
conjunction with materialized views. They aid the ability of the Oracle optimizer to perform
‘query rewrite’ (where one or more materialized views are substituted for some or all of the
selection and aggregation requirements of the SQL statement. As they define logical
relationships both within and (sometimes) between tables, they record very useful metadata.
The standard naming convention for dimensions is:

14. 14
• D_DimensionName
The dimension name should describe the function of the dimension.
1.8.12 Sequence
The standard naming convention for sequences is:
• S_SequenceName
The sequence name describes the function of the sequence.
1.8.13 Synonym
Public Synonyms shall have the same name as the object it represents
1.8.14 Procedure
The standard naming convention for procedures is:
• PR_ProcedureName
• Example: PR_InsertFiler
The procedure name describes the function of the procedure.
1.8.15 Package/Package Body
The standard naming convention for packages and package bodies is:
• PA_Package Name
Package Headers and package bodies have the same name and must reflect the purpose of the
package.
1.8.16 Functions
The standard naming convention for functions is:
• FN_FunctionName
• Example: FN_VerifyFiler
The FunctionName must reflect the purpose of the function.
1.8.17 Trigger
The standard naming convention for triggers is:
• [Trigger Time][Trigger Event(s)][Trigger Granularity]_TableName.
A trigger name will be specified as: [B:A][I:U:D][r:s]_TableName.

15. 15
The following rules apply when naming triggers:
• Trigger Time is defined as follows:
• B: Before
• A: After
• Trigger Events are defined as follows:
• I: INSERT
• U: UPDATE
• D: DELETE
• Trigger Granularity is defined as follows:
• r: Row
• s: Statement
• Only one of the [B:A] or [r:s] may be used in any given trigger statement, however any or
all of the [I:U:D] may be used.
An example of a named trigger is presented below:
• Example: [B][IU][r]_FILER_RETURN).
This standard naming convention must be followed for application triggers.
1.8.18 Snapshots
Snapshots will be created as needed for communications between databases.
1.8.19 Renaming an Object or Attribute
Renaming an object or attribute will be considered and approved on a case-by-case basis. In
general, renaming these items should be avoided, as all associated objects related to the object
will also have to be renamed, such as indexes, triggers, constraints, etc. for a table. All renamed
objects must comply with above-mentioned naming standards.
1.8.20 Database links
Database link names must reflect the name of the remote database and schema to which the
user will connect.
• Example: a database link used to connect to database “test” and schema “appstuff”
would be named “test_appstuff”.
Public database links without a USERNAME will connect the user with the same ID and
password that they are currently logged on with.
1.9 Sample Oracle SQL CREATE Statements
The SQL CREATE statement is used to define (create) Oracle objects.
Refer to the Oracle Server SQL Language Reference Manual for a detailed explanation of the
syntax, and all applicable parameters for each variant of the CREATE statement. Other SQL
statements may be addressed as the requirement is defined.

16. 16
The following sample Oracle SQL CREATE statements are provided to illustrate the correct
usage of SQL when defining Oracle objects. Primary emphasis is placed on providing examples
of the naming standards defined above.
The guidelines and examples that follow provide examples of the following forms of the SQL
CREATE statement for defining Oracle objects:
• CREATE Schema
• CREATE User
• CREATE Tablespace
• CREATE Table
• CREATE View
1.9.1 CREATE SCHEMA
Use the CREATE SCHEMA to create multiple tables and views and perform multiple grants in a
single transaction.
To execute a CREATE SCHEMA statement, Oracle executes each included statement. If all
statements execute successfully, Oracle commits the transaction. If any statement results in an
error, Oracle rolls back all the statements.
Note:
This statement does not actually create a schema. Oracle automatically creates a schema when
you create a user (see CREATE USER). This statement lets you populate your schema with
tables and views and grant privileges on those objects without having to issue multiple SQL
statements in multiple transactions.
1.9.1.1 CREATE SCHEMA Prerequisites
The CREATE SCHEMA statement can include CREATE TABLE, CREATE VIEW, and GRANT statements.
To issue a CREATE SCHEMA statement, you must have the privileges necessary to issue the
included statements.
1.9.1.2 CREATE SCHEMA Examples
Creating a Schema: Example (Single Project Schema)
The following statement creates a schema named efds for the sample user efds, creates the
table new_filer, creates the view V_new_filer_view, and grants SELECT privilege on
V_new_filer_view to the sample human resources user JHSMIT00 (John H. Smith at
National Office).
CREATE SCHEMA AUTHORIZATION efds
CREATE TABLE new_filer
(filer_tin VARCHAR2(10) PRIMARY KEY, filer_name VARCHAR2(35)
CREATE VIEW V_new_filer_view
AS SELECT filer_tin, filer_name FROM new_filer WHERE filer_tin > '0'
GRANT select ON V_new_filer_view TO JHSMIT00;

17. 17
Creating a Schema: Example (Multiple Project Schemas)
The following statements create a series of schemas named efds_RGnn for the sample user
efds, creates the table new_filer, creates the view V_new_filer_view, and grants SELECT
privilege on V_new_filer_view to the sample human resources user JHSMIT00 (John H.
Smith at National Office). In this example, RG01 would be used for Region 1, and RG02
would be used for Region 2.
CREATE SCHEMA AUTHORIZATION efds_RG01
CREATE TABLE new_filer
(filer_tin VARCHAR2(10) PRIMARY KEY, filer_name VARCHAR2(35)
CREATE VIEW V_new_filer_view
AS SELECT filer_tin, filer_name FROM new_filer WHERE filer_tin > '0'
GRANT select ON V_new_filer_view TO JHSMIT00;
CREATE SCHEMA AUTHORIZATION efds_RG02
CREATE TABLE new_filer
(filer_tin VARCHAR2(10) PRIMARY KEY, filer_name VARCHAR2(35)
CREATE VIEW V_new_filer_view
AS SELECT filer_tin, filer_name FROM new_filer WHERE filer_tin > '0'
GRANT select ON V_new_filer_view TO JHSMIT00;
Refer to Oracle Corporation’s documentation regarding any limitations and/or restrictions on
multiple schemas.
1.9.2 CREATE USER
Use the CREATE USER statement to create and configure a database user, or an account through
which you can log in to the database and establish the means by which Oracle permits access
by the user.
Note:
You can enable a user to connect to Oracle through a proxy (that is, an application or
application server). For syntax and discussion, refer to the ‘ALTER USER’ statement in Oracle’s
documentation.
1.9.2.1 CREATE USER Prerequisites
You must have CREATE USER system privilege. When you create a user with the CREATE USER
statement, the user's privilege domain is empty. To log on to Oracle, a user must have CREATE
SESSION system privilege. Therefore, after creating a user, you should grant the user at least
the CREATE SESSION privilege.
There are many parameters associated with the CREATE USER command. Please refer to
Oracle’s documentation for a complete explanation of the syntax.
1.9.2.2 CREATE USER Examples
Creating a Database User: Example

18. 18
If you create a new user with PASSWORD EXPIRE, the user's password must be changed before
attempting to log in to the database. You can create the user JHSMIT00 by issuing the following
statement:
CREATE USER JHSMIT00
IDENTIFIED BY welcome
DEFAULT TABLESPACE efds_tbs_01
QUOTA 10M ON efds_tbs_01
TEMPORARY TABLESPACE temp
QUOTA 5M ON temp
PROFILE efds_user
PASSWORD EXPIRE;
The user JHSMIT00 has the following characteristics:
• The password welcome
• Default TABLESPACE efds_tbs_01, with a quota of 10 megabytes
• Temporary tablespace temp
• Access to the tablespace TEMP, with a quota of 5 megabytes
• Limits on database resources defined by the profile efds_user
• An expired password, which must be changed before JHSMIT00 can log in to the
database
Refer to Oracle’s documentation for other examples of the CREATE USER command including:
• Creating External Database Users
• Creating a Global Database User
1.9.3 CREATE TABLESPACE
Use the CREATE TABLESPACE statement to create a tablespace, which is an allocation of space
in the database that can contain persistent schema objects.
When you create a tablespace, it is initially a read/write tablespace. You can subsequently use
the ALTER TABLESPACE statement to take the tablespace offline or online, add datafiles to it, or
make it a read-only tablespace.
You can also drop a tablespace from the database with the DROP TABLESPACE statement.
You can use the CREATE TEMPORARY TABLESPACE statement to create tablespaces that contain
schema objects only for the duration of a session.
1.9.3.1 CREATE TABLESPACE Prerequisites
You must have CREATE TABLESPACE system privilege.
Before you can create a tablespace, you must create a database to contain it, and the database
must be open.
To use objects in a tablespace other than the SYSTEM tablespace:

19. 19
• If you are running the database in rollback undo mode, at least one rollback segment
(other than the SYSTEM rollback segment) must be online.
• If you are running the database in Automatic Undo Management mode, at least one
UNDO tablespace must be online.
There are many parameters associated with the CREATE TABLESPACE command. Please
refer to Oracle’s documentation for a complete explanation of the syntax.
1.9.3.2 CREATE TABLESPACE Examples
Creating an Undo Tablespace: Example
The following example creates a 10 MB undo tablespace efds_undots1 with datafile
efds_undotbs_1a.f:
CREATE UNDO TABLESPACE efds_undo_tbs_1
DATAFILE 'efds_undo_tbs_1a.f'
SIZE 10M AUTOEXTEND ON;
Creating a Tablespace with Default Storage: Example
This statement creates a tablespace named efds_tbs_01 with one datafile:
CREATE TABLESPACE efds_tbs_01
DATAFILE 'efds_tbs_f2.dat' SIZE 20M
DEFAULT STORAGE (INITIAL 128K NEXT 128K
MINEXTENTS 1 MAXEXTENTS 999)
ONLINE;
Refer to Oracle’s documentation for other examples of the CREATE TABLESPACE command
including:
• Enabling Autoextend for a Tablespace
• Specifying Minimum Extent Size
• Creating a Locally Managed Tablespace
• Specifying Segment Space Management for a Tablespace
• Creating Oracle-managed Files
1.9.4 CREATE TABLE
Use the CREATE TABLE statement to create one of the following types of tables:
• A relational table which is the basic structure to hold user data.
• An object table which is a table that uses an object type for a column definition. An
object table is a table explicitly defined to hold object instances of a particular type.
You can also create an object type and then use it in a column when creating a relational table.
Tables are created with no data unless a query is specified. You can add rows to a table with the
INSERT statement. After creating a table, you can define additional columns, partitions, and
integrity constraints with the ADD clause of the ALTER TABLE statement. You can change the

20. 20
definition of an existing column or partition with the MODIFY clause of the ALTER TABLE
statement.
1.9.4.1 CREATE TABLE Prerequisites
To create a relational table in your own schema, you must have the CREATE TABLE system
privilege. To create a table in another user's schema, you must have CREATE ANY TABLE
system privilege. This is a privilege granted to Database Administrators (DBAs) only. Also,
the owner of the schema to contain the table must have either space quota on the tablespace to
contain the table or UNLIMITED TABLESPACE system privilege.
In addition to these table privileges, to create an object table (or a relational table with an object
type column), the owner of the table must have the EXECUTE object privilege in order to
access all types referenced by the table, or you must have the EXECUTE ANY TYPE system
privilege. These privileges must be granted explicitly and not acquired through a role.
Additionally, if the table owner intends to grant access to the table to other users, then the owner
must have been granted the EXECUTE privileges on the referenced types with the GRANT
OPTION, or have the EXECUTE ANY TYPE system privilege with the ADMIN OPTION. This is
a privilege granted to Database Administrators (DBAs) only. Without these privileges, the
table owner has insufficient privileges to grant access to the table to other users.
To enable a unique or primary key constraint, you must have the privileges necessary to create
an index on the table. You need these privileges because Oracle creates an index on the
columns of the unique or primary key in the schema containing the table.
To create an external table, you must have the READ object privilege on the directory in which
the external data resides.
There are many parameters associated with the CREATE TABLE command. Please refer to
Oracle’s documentation for a complete explanation of the syntax.
1.9.4.2 CREATE TABLE Examples
General Example
This statement shows how the FILER table could be created:
CREATE TABLE employees_demo
( employee_id NUMBER(6)
, first_name VARCHAR2(20)
, last_name VARCHAR2(25)
CONSTRAINT emp_last_name_nn NOT NULL
, email VARCHAR2(25)
CONSTRAINT emp_email_nn NOT NULL
, phone_number VARCHAR2(20)
, hire_date DATE DEFAULT SYSDATE
CONSTRAINT emp_hire_date_nn NOT NULL
, job_id VARCHAR2(10)
CONSTRAINT emp_job_nn NOT NULL
, salary NUMBER(8,2)
CONSTRAINT emp_salary_nn NOT NULL

21. 21
, commission_pct NUMBER(2,2)
, manager_id NUMBER(6)
, department_id NUMBER(4)
, dn VARCHAR2(300)
, CONSTRAINT emp_salary_min
CHECK (salary > 0)
, CONSTRAINT emp_email_uk
UNIQUE (email)
);
This table contains twelve columns. The employee_id column is of datatype NUMBER. The
hire_date column is of datatype DATE and has a default value of SYSDATE. The last_name
column is of type VARCHAR2 and has a NOT NULL constraint, and so on.
Refer to Oracle’s documentation for other examples of the CREATE TABLE command including:
• Storage Example
• Temporary Table Example
• Substitutable Table and Column Examples
• PARALLEL Example
• NOPARALLEL Example
• ENABLE VALIDATE Example
• DISABLE Example
• Nested Table Example
• Multi-level Collection Example
• LOB Column Example
• Index-Organized Table Example
• External Table Example
• XMLType Examples
• XMLType Table Examples
• XMLType Column Examples
• Partitioning Examples
• Range Partitioning Example
• List Partitioning Example
• Partitioned Table with LOB Columns Example
• Hash Partitioning Example
• Composite-Partitioned Table Examples
• Object Column and Table Examples
• Creating Object Tables: Examples
• Creating Tables with a Scoped REF: Example
• Creating a Table with a User-Defined OID: Example
• Specifying Constraints on Type Columns: Example
1.9.5 CREATE VIEW
Use the CREATE VIEW statement to define a view, which is a logical table based on one or more
tables or views. A view contains no data itself. The tables upon which a view is based are called
base tables.

22. 22
You can also create an object view or a relational view that supports LOB and object datatypes
(object types, REFs, nested table, or varray types) on top of the existing view mechanism. An
object view is a view of a user-defined type, where each row contains objects, each object with
a unique object identifier.
You can also create XMLType views, which are similar to an object views but display data from
XMLSchema-based tables of XMLType.
1.9.5.1 CREATE VIEW Prerequisites
To create a view in your own schema, you must have CREATE VIEW system privilege. To create a
view in another user's schema, you must have CREATE ANY VIEW system privilege.
To create a subview, you must have UNDER ANY VIEW system privilege or the UNDER object
privilege on the superview.
The owner of the schema containing the view must have the privileges necessary to either
select, insert, update, or delete rows from all the tables or views on which the view is based.
The owner must be granted these privileges directly, rather than through a role.
To use the basic constructor method of an object type when creating an object view, one of the
following must be true:
• The object type must belong to the same schema as the view to be created.
• You must have EXECUTE ANY TYPE system privileges.
• You must have the EXECUTE object privilege on that object type.
There are many parameters associated with the CREATE VIEW command. Please refer to
Oracle’s documentation for a complete explanation of the syntax.
1.9.5.2 Partition Views
Partition views were introduced in Oracle Release 7.3 to provide partitioning capabilities for
applications requiring them. Partition views are supported in Oracle9i so that you can upgrade
applications from Release 7.3 without any modification. In most cases, subsequent to upgrading
to Oracle9i you will want to migrate partition views into partitions.
In Oracle9i, you can use the CREATE TABLE statement to create partitioned tables easily.
Partitioned tables offer the same advantages as partition views, while also addressing their
shortcomings. Oracle recommends that you use partitioned tables rather than partition views in
most operational environments.
1.9.5.3 CREATE VIEW Examples
Creating a View: Example
The following statement creates a view of the sample table filer named V_filer_view_MD. The
view shows the filers in Maryland and their gross and net income:

23. 23
CREATE VIEW V_filer_view_MD AS
SELECT file_last_name, gross_income, net_income
FROM filer
WHERE state_code = ‘MD’;
Refer to Oracle’s documentation for other examples of the CREATE VIEW command including:
• Creating a View with Constraints
• Creating an Updatable View
• Creating a Join View
• Creating a Read-Only View
• Creating an Object View
• Creating a View on an XMLType Table
• Creating an XMLType View