Standards and Guidelines for Oracle at DoIT
produced and supported by
DRMT Data Resource 
Management Technology
DoIT Division of  
Information  
Technology 
UW - Madison
 
This document is intended for Oracle database application developers working for or with the Division of Information Technology at the University of Wisconsin - Madison. Email comments, corrections, and requests regarding this document

The Oracle Database Environment at DoIT

The number of Oracle databases is growing constantly.

For read-only decision support, DoIT operates a specialized Oracle server supporting the InfoAccess data warehouse application.

For our own internal "common business systems" (CBS), we have a suite of Oracle Financial applications which, of course, use the Oracle database.

For our Help Desk call-tracking, we operate an Oracle database to support the Clarify suite of products.

For PeopleSoft Student Administration ("ISIS") we are running over ten different Oracle database instances just to prepare for going production.

DoIT also provides system and database support for various Oracle servers owned by other departments on campus.  In addition we rent space in Oracle database "condo's" to campus departments wishing to development while DoIT handles the system and database administration.

For DoIT-developed transaction processing, DoIT maintains two independent Oracle environments -- one for test/development, and one for production.  These servers can, of course, cooperate with other Oracle servers and can also interoperate with DoIT's mainframe DBMS products -- DB2 and IMS.  The standards, guidelines and procedures of this document are intended primarily for our general-purpose, transaction-oriented environments (UWT1 and UWP1).
 

UWT1 and UWP1

DoIT's general-purpose test instance is named "UWT1".

DoIT's general-purpose production instance is named "UWP1".

For a number of reasons, including performance and security, test and production are located on separate machines. As of this writing, UWT1 is located on a model 58H IBM RS/6000 machine affectionately known as "Axle", and UWP1 is located on a model J30 RS/6000 lovingly known as "Humvee".

With rare exceptions, UWT1 is administered so that it communicates only with other test/development database environments (e.g., DSNT in MVS/DB2). With no exception, UWP1 communicates only with other production database environments (e.g., DSNP in MVS/DB2).

Every database object found in the production instance must have a corresponding object of the same name in the test instance. This rule greatly facilitates the movement of objects and applications from test to production. There are 3 Oracle object types that can be exceptions to this "same name" rule:

All 3 are discussed separately later.

Getting Developer Authorization in Test

1. Have your group manager notify a DBA that you should be authorized as a developer in the DoIT Oracle Development Environment. (UWT1)

This notification can be via email and should include:

2. If don't already have an AIX account on Axle...

get one by requesting it at http://axle.doit.wisc.edu/apply.cgi

3. Once you have your AIX account, you must add some Oracle Environment Variables to your environment.

If you are running the Cshell, do this by adding the following lines to your .cshrc file: 
      setenv ORACLE_SID uwt1
      setenv ORAENV_ASK NO
      source /oracle/local/coraenv
      setenv ORAENV_ASK YES
After entering these lines into your .cshrc file, you need to execute them. To do so, you can either login to Axle again, or use the command: 
      source .cshrc
If you are running the Korn or Bourne shell, do this by adding the following line to your .profile: 
      ORACLE_SID=uwt1
      export ORACLE_SID
      ORAENV_ASK=NO
      export ORAENV_ASK
      . /oracle/local/oraenv
      ORAENV_ASK=YES
      export ORAENV_ASK
After entering these lines into your .profile file, you need to execute them. To do so, you can either login to Axle again, or use the command: 
      . .profile
 

Oracle Schemas

For mainframe DB2, DoIT uses a single creator -- the mythical proxy user "UW" -- who owns every application object. For Oracle, DoIT uses a number of proxy users whose schemas will contain a particular subject area.

How many schemas should we have? The actual decision as to how many proxy schemas to use and when to create a new schema is an Applications Technology management judgment. Generally a schema should contain a logical subject area that could be usefully understood and managed by a normal human programmer (or perhaps two or three programmers).
 
 

Naming Standards for Proxy Schemas

Schema names must follow the same standards which apply to MVS/DB2 logical databases.

That is,

New proxy schemas must be approved by the Apps Tech group manager responsible for the subject area. No forms are needed; an email from the Apps Tech manager to the DRMT data administrator can signal approval.

An Oracle DBA will create the proxy user in UWT1, assign an initial password for the proxy user, and email the Apps Tech manager. From then on, changing the proxy's password is the responsibility of the people working in that Apps Tech area.

Schema Security (test environment)

DoIT  developers will routinely need to log on to test Oracle -- not as themselves -- but as the proxy user (AD or PY in the previous example).  To do this, developers use the proxy's Oracle password.  DoIT developers are responsible for protecting the Oracle passwords for their area's proxy users.  The proxy user's Oracle password is the key to each subject area's test data.

Schema Security (production environment)

In production, no one will be enabled to log on as the proxy user. Proxy users in production will have an unknown password and, additionally, will not possess the "create session" system privilege. This has profound implications for how you develop an application. Remember, in production, the proxy user will NOT be logging on EVER. If your application is written in such a way as to require the proxy logging on, then it means your application will never go production.
 

Oracle Passwords

Every person or program which connects to Oracle must connect as some user. The user might be you (a real human being), or the user might be a proxy (e.g., AD or PY in the previous example). In either case, the user needs an Oracle password.

How to Change Oracle Password(s)

One easy way is to go here:
http://www.wisc.edu/drmt/pass_chg.html

Also, in almost any tool that lets you issue SQL statements, you can enter the statement:

ALTER USER your-user-id IDENTIFIED BY your-new-password;

Oracle will reply: 'User altered'... and you're done.

Note:  these procedures will alter your Oracle password in one and only one database instance -- the one you're connected to.  If, for example, you are an Oracle user in both UWT1 and UWT2 -- and you want the same password in both instances -- you must log on to each instance separately and change your password there.
 

A General Overview of the Oracle Application Life Cycle

A. Steps taken while application remains in development environment

B. DRMT Database Administrator recreates production database objects to match tested objects.

Tables

How to Create a Test Table

Table Names

Proxy schema name can be up to 8 characters (A-Z). (See Naming Standards for Proxy Schemas)

Table name can be up to 30 characters (A thru Z, 0 thru 9, and _ ).
 
Format Example
proxy_schema_name.table_name PY.PERSON_DEDUCT
 

DoIT does not have detailed naming standards, but Oracle's own "object naming guidelines" are strongly recommended:

From Oracle's SQL Language Reference Manual:

There are several helpful guidelines for naming objects and their parts:

 

 How to document tables

Our plan for now is to ignore Predict and to document in the Oracle database itself, using Oracle's own facility for table and column comments. The SQL Studio tool is a decent tool for entering the data descriptions, and an excellent tool for integrating the descriptions with the other tasks of PL/SQL development.

To enter/change a comment using SQL Studio, open a view of the TABLE.

Restrictions:  How to print table documentation

Now that you've meticulously documented those Oracle tables, is there any way to print that documentation?? Yes, there is now... You'll need Microsoft Access (a recommended tool for editing Oracle test data, also) and access to the Goliath LAN.

To run the print application

Unlike native Oracle dictionary views (e.g., USER_TABLES, ALL_TABLES), the oradict application allows you to see the structure of any table in any schema. In addition, it is far more useful than the native Oracle dictionary views because it combines multiple Oracle dictionary views to show table, column, primary key, comments and data sizes. This application is particularly recommended if you need to provide hard-copy data dictionary information to customers.

Tablespaces

Oracle tablespaces define the physical location of tables and indexes. Note that DoIT treats Oracle and DB2 tablespaces very differently. In DB2 we want one table per tablespace, leading to thousands of tablespaces. In Oracle we want only a relative handful of tablespaces -- say, 20 or 30. Therefore, many tables will be located within a single Oracle tablespace. Generally Oracle DBA's will try to keep data and indexes in separate tablespaces.

Only DoIT's Oracle DBA's will create new Oracle tablespaces.

Every Oracle user has a default tablespace. DoIT developers can use their default tablespace if they wish to create personal objects (tables, etc. for their own use or experimentation).

The use and location of tablespaces is an important performance tuning parameter. The Oracle DBA is responsible for choosing, monitoring and altering Oracle tablespaces. Because test and production performance issues can be highly dissimilar, tablespaces are an exception to the general rule that test and production instances must be identical.

Views

Naming Standards for views

Same as tables. 

Columns

Standard Columns

Two columns are required in all tables that might plausibly be subject to update by concurrent users. 

ROW_ENTRY_DTG        format: DATE
ROW_ENTRY_LOGONID    format: VARCHAR2(20)

Naming Guidelines for Columns

For positive, common-sense words of advice, see the earlier passage quoted from Oracle's SQL Reference Manual.

To reinforce the very last line of that earlier passage, let's be downright negative:

Don't propose tables where every column contains a prefix indicating the table name.

For example, don't propose a FINANCE table such that every column begins with FIN. Routinely adding prefixes to column names creates different names for exactly the same data item. This makes it very difficult to find all references to the item.

As Oracle Corporation said earlier, 'The department number columns of the EMP and DEPT tables are both named DEPTNO.'

DataTypes

Are certain Oracle datatypes recommended?

DoIT recommends using "the datatype that best suits the nature of the data in the column." For example, a column that will always contain a fixed-length code is well-suited to a fixed-length CHAR datatype. A column that contains strings of varying length is supported naturally by a VARCHAR2 datatype. A column that contains dates is well-suited to the Oracle DATE datatype.

On the other hand, certain host languages -- such as COBOL -- are not well-known for ease-of-use with string manipulations and variable length data. Because the host language may introduce some level of complexity, developers have often preferred the most simple datatypes possible. Developers should make the final choice since it is they who will work with the data types thereafter.

In the absence of strong objection, however, DoIT recommends using the data type that best suits the nature of the data in the column.

Are certain Oracle data types NOT recommended?

Oracle Corporation recommends using the VARCHAR2 rather than VARCHAR data type. Although these data types are currently synonymous, a future version of Oracle may introduce VARCHAR as a separate data type with different comparison semantics.

DoIT will follow this recommendation. VARCHAR is the only data type known to be a problem at this time.
 

Declarative Integrity Constraints

A declarative integrity constraint defines a database rule that is always true. It is not really programmed; it is simply declared, once. From that time on, the rule is enforced by the Oracle database management system. If the rule ever changes (presumably because the business facts of the real world have changed), then the constraint must be disabled or dropped. This, too, is done by a simple declaration.

All Oracle databases are strongly urged to use declarative integrity constraints wherever possible to ensure data integrity. Integrity constraints are discovered and confirmed during data modeling with customers.

Declarative constraints have these benefits:

Guaranteed Integrity and Consistency

Application Development Productivity

Performance

Self-Documenting

Primary Key (PK) constraint

Every Oracle table must have one and only one primary key constraint to identify those column(s) which uniquely identify a row. A PK constraint automatically enforces UNIQUE and NOT NULL constraints on all columns in the primary key.
 
Format Example
PK_ + table_name (or some table_name variant if necessary) PK_PERSON_DEDUCT
 
 

Unique (UK) constraint

If (in addition to the primary key) another column or group of columns must always be unique, use the UNIQUE constraint.
 
Format Example
UK_ + table_name (or some table_name variant if necessary) UK_PERSON_DEDUCT
 
 

Foreign Key (FK) constraints

Specifies a relationship between tables (e.g., a master/detail or parent/child relationship). Creating a foreign key constraint may make the job of creating test data a little harder, but it goes a long way in ensuring the test database is valid.
 
Format Example
FK_ + referenced_table_name (or referenced_table_name variant if necessary) FK_PERSON
 
 
 

CHECK Constraint or FOREIGN KEY Constraint?
The check constraint should not be thought of as a replacement for "code lookup" tables. For example, if a particular column, -- say "Appointment Type" -- should be constrained to hold only only 6 different codes which describe valid types of appointment within the University, we might consider two strategies. One strategy would be to attach a check constraint (where appointment_type in ('FA', 'AS', 'CP', 'CL', 'LI', 'SH')). Another time-honored strategy is to create a lookup table containing the 6 codes and then declare a foreign key constraint referencing that lookup table.

Which strategy is preferred? Generally the lookup table is a more complete solution. The lookup table usually contains additional information such as a name or description for the code. Most applications will need to translate codes into descriptions, and code tables are the preferred way to do this. The table solution also makes it easier for customers to control their own systems.

If a column constraint is as simple as 'Y' or 'N', then a check constraint is more appropriate than an edit table. A check constraint may also be able to enforce cross-column integrity rules that an edit table cannot.
 

Not Null (NN) constraints

Specifies that a column can never contain a NULL value. Naming NOT NULL constraints is optional. If an explicit name is desired, use the following format:
 
Format Example
NN_ + table_name NN_PERSON_DEDUCT_START_DATE
 

If an explicit name is not declared, Oracle assigns its own constraint name with a format of

SYS_C + system-supplied_number

Allowing Oracle to assign a NOT NULL constraint name will generally result in different constraint names in test and production instances. The same logical constraint (e.g., that Person_Name cannot be null) might be named SYS_C00040 in test and SYS_C00055 in production.

  1. If an application wishes to use the constraint name to trap a not null constraint violation, then the NN constraint should be explicitly named.
  2. If there is a plan to replicate the table in another Oracle instance, then the NN constraint should be explicitly named.

Should Nulls be used at all?

Well, maybe they should after all...

There is a huge literature discussing the pros and cons of using null values in databases. DoIT has generally recommended against nulls, but not with an overwhelming conviction. Now, by encouraging the use of primary and foreign key constraints in Oracle, the Data Resource Management group is implicitly encouraging at least some use of nulls.

For example, a business requirement may say that an EQUIPMENT_ITEM "Vendor" can be unknown, but if identified, it must be a vendor we know about. The Oracle design implementation would be to declare a constraint on the Vendor column in our EQUIPMENT_ITEM table, saying that it references our VENDOR table. But, because it's optional (not always known), we must allow nulls in the EQUIPMENT_ITEM vendor column.

As a practical matter, the decision to use nulls falls primarily to the application developers who first use the tables. The greatest practical annoyance is that nulls require special coding (i.e., indicator variables) if the programmer is using host languages such as COBOL or C.
 

Performance Indexes

Behind the scenes, Oracle does create an index to enforce each primary key or unique constraint. Of course, a table may also require additional indexes for the sole purpose of improving performance (no role in enforcing a constraint). For these indexes, the rule of "matching" test and production environments need not apply. The production environment may well introduce performance indexes that are not mirrored in test.
 
Format Example
IX_ + table_name (or some table_name variant if necessary) IX_PERSON_DEDUCT
 
 

Stored Procedures, Functions, Packages, and Triggers

Stored procedures, functions, packages, and triggers should be created in "an appropriate" proxy user's schema.

The "appropriate" schema is related to the development group which creates and continues to be responsible for maintaining the PL/SQL code. For example, the stored procedure get_student might reference tables in several different schemas, say AD and PY. However, if this procedure is developed by a particular development group to support the XX subject area, then their get_student procedure is correctly created as XX.get_student. Naturally, this convention allows for the possibility of more than one get_student procedure (e.g., XX.get_student, AD.get_student, PY.get_student).

WARNING Warning: Various training sources (including Oracle Corp.) seem fond of showing examples where a stored procedure or function is called without explicitly using its qualifying schema name.

For example, v_stdt := get_student(student_id);
rather than v_stdt := AD.get_student(student_id);
This shortcut seems like the worst imaginable real-world practice. Because of the Oracle namespace scoping rules, calling get_student may execute different code depending on WHO is doing the calling. If you've developed a personal copy of get_student in your own schema and an official copy of get_student in the AD schema, then -- depending on whether you're logged on a AD or yourself -- an unqualified call to get_student will execute one piece of code or the other. Every experienced programmer has a memory of being profoundly confused by a situation where the code being executed wasn't what he or she thought. Let's not bother.

Always use fully-qualified names.

Always "create or replace" stored objects using a fully-qualified name. e.g., Create or replace AD.get_student as (....

Always execute fully-qualified stored procedures, functions, and packages. e.g., v_stdt := AD.get_student(....
 

Roles

Roles are important for Oracle security.

An Oracle role is simply a name. Like any other name, they can be "made up". Once a role name is created, specific Oracle privileges can be granted to it. Lastly, the role can be granted to one or more Oracle users, or to other roles.

Oracle privileges can be broadly grouped into types. A system privilege enables a generalized ability to perform an action (e.g., create tables, drop tablespaces). An object privilege enables an action in regard to some particular database object (e.g., UPDATE on table XYZ).

The first two characters of a role name should indicate its general purpose.

In test, proxy users have the ability to create, drop, revoke and grant roles. By logging on as a proxy, a developer inherits this ability.

"S_" System Roles

Roles which grant system privileges must begin with "S_". They are necessarily created by a DBA.

The S_SCHEMA_OWNER Role:

S_SCHEMA_OWNER:  
Privileges             Operations Permitted


CREATE PROCEDURE      Create stored procedures, functions, and
                      packages in the proxy schema

CREATE TRIGGER        Create trigger on a table in the proxy
                      schema
CREATE VIEW           Create views in the proxy schema

Depending on how they connect, developers can exercise two extremely different privilege profiles. By connecting to Oracle as a proxy, a developer has great power within the proxy's schema. By connecting under a personal user ID, the developer has the minimal privileges accorded to any user. So, developers use the proxy IDs to write PL/SQL, and they use their personal user ID's for testing it.

(Warning: Developers can confound their own work by logging on as the proxy user and then granting privileges directly to their own logon ID! This makes it impossible to test application roles [See "A_" Application Roles below]. Proxies should instead grant object privileges to an Application Role, and then grant the application role to their own logon ID.)
 

The S_DEVELOPER Role:

S_DEVELOPER:  
Privileges            Operations Permitted


CREATE PROCEDURE      Create stored procedures, functions, and
                      packages in personal schema

CREATE TRIGGER        Create trigger on a table in personal
                      schema

CREATE VIEW           Create views within personal schema

CREATE TABLE          Create tables within personal schema

CREATE SEQUENCE       Create sequences within personal schema

"A_" Application Roles

An "Application Role" is a name for a bundle of database privileges used in a given application. Used in conjunction with Oracle UserID and password authentication, application roles provide a very sensible way of allowing certain users to execute a given transaction while preventing unauthorized users from doing the same.

Application developers should request a copy of the DoIT/DRMT document, Using Application Roles for On-Line Transaction Security. Contact any Oracle DBA.


 

"E_" Edit/Control Roles

Roles of this type should begin with "E_".

"Q_" Query Roles

Roles of this type should begin with "Q_".

E_ roles and Q_ roles are created in production by an Oracle database administrator.

Approval to create such roles must come from the user custodian(s) of the data tables. Approvals can be accomplished via email. DoIT developers can facilitate by drafting a message with the exact tables and privileges required and sending it to the data custodian. The custodian can signal approval by forwarding the message to the Oracle DBA.

Database Links

All database links are created by an Oracle DBA.
 

Moving to Production

Moving Tables, Constraints, Indexes, Sequences and Views to Production

There's a form named (get ready...) "Oracle Database Object Production Request". It's available from your UWT1/UWP1 DBA. This form basically asks what objects you want the DBA to re-create in UWP1. The form itself is rarely sufficient. Think of it as a chance to have a discussion with the DA and DBA about what needs to be done.

Moving Roles to Production

This, too, is requested on the "Oracle Database Object Production Request" form.

Moving PL/SQL Code (Procedures, Functions, Packages and Triggers) to Production

DRMT supports a web-based tool and a series of background processes which allow developers to move PL/SQL code. Code can be scheduled for 8PM, 5AM, or immediate moves.

For audit purposes, you connect using your personal Oracle ID and password (not the application proxy). An individual developer can move PL/SQL objects only for pre-authorized proxy shemas and only across specific Oracle database instances. AT managers may wish to play a role in approving move-to-production authorizations.

Contact Jeff Lange for authorization setups and problem reports.

Authorizing Users in Production

What the User does: [In fact, we don't know how we will name programs or systems in this new environment. Will the user know a short code name, similar to our current mainframe transaction name? Should we instead use a more descriptive name with real English words? In either case, how do we distinguish between the test and production versions of the system? These are questions that we alone can not answer and are hoping that reviewers of this document will help with. ]

What the System Owner will do:

What DoIT/EUC will do:

What the Database Administrator will do:

Oracle Networking Products

Oracle networking refers to client/server connections, and server-to-server connections. Most of this communication is enabled via Oracle SQL*Net middleware.

Client to Oracle Server

In our environment client workstations communicate with Oracle servers via Oracle SQL*Net using TCP/IP protocol. There are three client environments that are supported: MS-Windows (version 3.1 or Windows95), Macintosh and UNIX. To use Oracle networking, a client workstation must have SQL*Net installed, and have a TCP/IP protocol available. There are many client tools that support communications with Oracle servers via SQL*Net. Some client tools have native Oracle drivers available, that can use SQL*Net directly. Others use ODBC drivers that in turn use SQL*Net.

Some client tools are:  

MACINTOSH                        MS WINDOWS             UNIX

Brio Query                       Brio Query             SQL*Plus

Symantic C program via Oracle's  MS Access (via ODBC)   C program via  Oracle's Pro*C
Pro*C pre-compiler                                      pre-compiler

MS Excel (via ODBC)              SQL Studio             Cobol program via Oracle's
                                                        Pro*COBOL pre-compiler

                                 Powerbuilder

                                 MS Excel (via ODBC)

The tool you choose will depend on the job you need to do.

How do I get SQL*Net...ODBC... etc. installed on my workstation?

Installation Help - SQL Studio, SQL*Net, ODBC drivers for Oracle7...

Oracle Server to Oracle Server

Communications between Oracle servers are achieved via SQL*Net TCP/IP protocol. In the Oracle DBMS a database link is created referring to the remote DBMS server. This link contains the information needed to locate the remote server and to verify the users authorization on the remote server. When data on the remote server is used in a SQL statement the database link is resolved and the data is requested via SQL*Net. A unit of work, or transaction, may include SQL statements that accesses data from both servers.

Oracle Server to Mainframe DB2 and IMS

Communications between an Oracle DBMS server and the mainframe databases are achieved via two Oracle gateways

Development Tools

DRMT has identified some tools that will be useful to a developer. These tools are MS Windows products and will run in the OS/Win environment of OS/2 WARP.

SQL Studio

This tool allows the developer to create, compile, edit and debug PL/SQL code. PL/SQL is the language used for Oracle stored procedures and functions. This tool also has a code manager for these stored procedures. You can check out a code module and work on it. Another developer will not be allowed to check it out if you have it checked out.

The SQL Studio tool also allows the developer to manage roles. Use it to add or revoke privileges and also to grant a role to a user.

Contact DRMT if you would like to purchase this tool.

MicroSoft Access

This personal database system can be used with ODBC drivers to access Oracle tables on a remote server. With Access you can view and edit the data in test data tables.

This tool is part of the MS Office Pro suite and can be purchased from DoIT product sales. Installation procedures are included with the product.

Contact DRMT to get the ODBC connections installed and configured. Procedures are being developed for this installation.

Oracle Reference Material

If you haven't got the necessary reference manual at hand, you can find all of Oracle's official documentation on the web. Oracle's site is:
http://technet.oracle.com

You must 'register' before using the site.  Simply provide the requested professional information about yourself, and Oracle Corporation will promptly email you a password. (Keep that email!... or you'll never remember the password.)

In a pinch, you can also find complete Oracle documentation libraries elsewhere on the web by using your favorite search engine.
 

Other Oracle Documentation

Available at the bookstores and in the DoIT Resource Center

Oracle Press Series Books

This series contains several books that complement and could even replace the Oracle documentation that comes with the product. These books are available at the bookstores and are very readable. These are good:

O'Reilly and Associates Books

Some of these books have been purchased by the DoIT Resource Center and are available for your use. In addition the Resource Center also has some hard copies of the Oracle Documentation that is on the CD.

Glossary

AIX
The name of the operating system used on IBM RS/6000 hardware. An IBM flavor of UNIX.
data administrator
A person responsible for data policies, plans, models, documentation, and consulting. A data administrator (as opposed to a database administrator) is primarily concerned with logical data, with less concern for the physical database management system(s) such as Oracle, DB2 or IMS used to house the data.
database administrator, DBA
A person responsible for installation, operation, performance, backup, and recovery of one or more physical databases. A database administrator is an expert in regard to the system software of a particular DBMS such as Oracle, DB2 or IMS.
instance
The terms "instance" and "database" are often used interchangeably when talking about Oracle. Technically, the term instance refers to all the Oracle processes running in support of the environment which allows us to access the database objects (tables, indexes, procedures, etc.). We'll use the terms interchangeably.
object, Oracle object, database object...
In this document, object is a general reference to things that make up an Oracle database -- tables, tablespaces, indexes, constraints, stored procedures, triggers, etc. It has nothing to do with object-orientation.
proxy user
An Oracle user can be a real, living person; or the user can be fictitious. A fictitious Oracle user is called a "proxy user". Proxy users are created in order to own objects and privileges not appropriate for any particular individual user.
schema
"Schema" describes a collection of objects owned by a user. Every user owns a schema in which objects can be created. The name of that schema is the same as the name of the user. The name of an object can be qualified by the schema in which the object exists. For example, the table EMP in the schema SCOTT can be identified by SCOTT.EMP.
UNIX system administrator
A UNIX expert responsible for installation and support of hardware and operating system.
 

Send comments, corrections, requests regarding this document

From: (your email address please)

Subject: (please don't leave blank)

Message:

You may  when done, or  if you want to start over.