Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
integration:rdbms:oracle:tables [2011/03/31 17:29]
doc
integration:rdbms:oracle:tables [2016/06/28 22:38] (current)
Line 11: Line 11:
 [[integration:​rdbms:​oracle:​databases|Databases]] | [[integration:​rdbms:​oracle:​databases|Databases]] |
 **[[integration:​rdbms:​oracle:​tables|Tables]]** | **[[integration:​rdbms:​oracle:​tables|Tables]]** |
 +[[integration:​rdbms:​oracle:​constraints|Constraints]] |
 +[[integration:​rdbms:​oracle:​datatypes|Datatypes]] |
 [[integration:​rdbms:​oracle:​queries|Queries]] | [[integration:​rdbms:​oracle:​queries|Queries]] |
 [[integration:​rdbms:​oracle:​updates|Updates]] |  [[integration:​rdbms:​oracle:​updates|Updates]] | 
-[[integration:​rdbms:​oracle:​storedproc|Stored Procedures]] | 
 [[integration:​rdbms:​oracle:​example|Example]] [[integration:​rdbms:​oracle:​example|Example]]
  
Line 19: Line 20:
  
 ==== Tables ==== ==== Tables ====
 +
 +=== The CREATE TABLE Statement ===
  
 The [[dev:​sql:​statements:​create_table:​home|CREATE TABLE]] statement is used to declare an Oracle table or view within an Omnidex Environment File.  The Omnidex Environment File will contain a declaration for each Oracle table or view to be accessed, and will correlate all of the schema information between Omnidex and Oracle, including object names and datatypes. This statement can either be issued directly, or it can be extracted from Oracle using the EXTRACT statement as discussed in the previous section. The [[dev:​sql:​statements:​create_table:​home|CREATE TABLE]] statement is used to declare an Oracle table or view within an Omnidex Environment File.  The Omnidex Environment File will contain a declaration for each Oracle table or view to be accessed, and will correlate all of the schema information between Omnidex and Oracle, including object names and datatypes. This statement can either be issued directly, or it can be extracted from Oracle using the EXTRACT statement as discussed in the previous section.
 +
 +The following example compares the Oracle declarations with the Omnidex declarations.  ​
 +
 +**Oracle CREATE TABLE Statement**
  
 +<​code>​
 +create table STATES
 +       ​(STATE_CD ​               CHAR(2),
 +        DESCRIPTION ​            ​VARCHAR2(31),​
 +        STATE_NUM ​              ​CHAR(2),​
 +        REGION_CD ​              ​CHAR(2),​
 +        COUNTRY_CD ​             CHAR(2),
 +        TAX_RATE ​               NUMBER(16,​6));​
 +</​code>​
 +
 +
 +**Omnidex CREATE TABLE Statement**
 <​code>​ <​code>​
 create table          "​STATES"​ create table          "​STATES"​
- ​physical ​            "​MYUSER.STATES"​+ ​physical ​            "​SIMPLE.STATES"​
  (  (
-  "​STATE" ​            ​CHARACTER(2),​+  "​STATE" ​            ​CHARACTER(2) ​  physical "​STATE_CD"​,
   "​DESCRIPTION" ​      ​STRING(31),​   "​DESCRIPTION" ​      ​STRING(31),​
-  "​STATE_CODE" ​       CHARACTER(2),​ +  "​STATE_CODE" ​       CHARACTER(2) ​  physical "​STATE_NUM"​
-  "​REGION" ​           CHARACTER(2),​ +  "​REGION" ​           CHARACTER(2) ​  physical "​REGION_CD"​
-  "​COUNTRY" ​          ​CHARACTER(2),​ +  "​COUNTRY" ​          ​CHARACTER(2) ​  physical "​COUNTRY_CD"​
-  "​TAX_RATE" ​         FLOAT+  "​TAX_RATE" ​         FLOAT
-  constraint STATES_STATE_PK primary ("​STATE"​),​ +
-  constraint STATES_COUNTRY_FK foreign ("​COUNTRY"​) references "​COUNTRIES"​+
  )  )
  ​in ​                  "​simple.xml";​  ​in ​                  "​simple.xml";​
 </​code>​ </​code>​
  
-=== Omnidex'​s View of the Oracle Data Objects ​===+=== Using the Table and Column PHYSICAL Clauses ​===
  
-When Omnidex ​accesses a tableit only knows about the data objects ​that are declared in the Omnidex ​Environment File.  It does not have an independent understanding of the Oracle ​environment This allows administrators ​to shape the Omnidex ​Environment ​the way that they want.  ​Some of the opportunities ​that this provides ​are:+In the Omnidex ​declarationnote that the optional PHYSICAL clause for the table allows ​Omnidex ​to have a different table name than Oracle. This is most commonly used to allow a //​user.table//​ designation for the Oracle table, but can also be used when administrators wish a different name in the Omnidex ​environment or need to shorten a table name to meet the 32-character limit in Omnidex.  ​If the PHYSICAL clause is not present, Omnidex assumes ​that the table names are the same between Omnidex and Oracle.
  
-  ​* Omnidex can have a controlled view of the Oracle database, limited to only the tables, columns ​and views that the application requires.+Column declarations can similarly use a PHYSICAL clause to allow Omnidex to have a different column name than Oracle. ​  
 + 
 +=== Modifying Omnidex'​s View of the Oracle Data Objects === 
 + 
 +When Omnidex accesses a table, it only knows about the data objects that are declared in the Omnidex Environment File.  It does not have an independent understanding of the Oracle environment. ​ This allows administrators to shape the Omnidex Environment the way they want.  Some of the opportunities this provides are: 
 + 
 +  ​* Omnidex can have a controlled view of the Oracle database, limited to only the tables ​that the application requires. ​ Similarlyadministrators can choose to include only the columns ​for each table that the application requires.
   * Omnidex tables can point to Oracle views, allowing an easy approach to reshaping the application'​s view of the data.   * Omnidex tables can point to Oracle views, allowing an easy approach to reshaping the application'​s view of the data.
 +  * Omnidex can use different names for tables and columns by using the PHYSICAL clause in the TABLE or COLUMN sections of the CREATE TABLE statement to map to the underlying Oracle names.
   * Omnidex columns can often be assigned datatypes that differ from the Oracle datatype. ​ Character-class datatypes can be interchanged,​ allowing applications to easily receive the datatype that works best for its needs. ​ Binary datatypes can be assigned to any of the integer or floating point datatypes; in fact, this is a necessity since Oracle'​s NUMBER datatype is only an internal datatype.  ​   * Omnidex columns can often be assigned datatypes that differ from the Oracle datatype. ​ Character-class datatypes can be interchanged,​ allowing applications to easily receive the datatype that works best for its needs. ​ Binary datatypes can be assigned to any of the integer or floating point datatypes; in fact, this is a necessity since Oracle'​s NUMBER datatype is only an internal datatype.  ​
   * Omnidex tables can include [[admin:​features:​expressioncols:​home|Expression-based Columns]], which are columns derived from a SQL expression rather than a specific column in the underlying database.   * Omnidex tables can include [[admin:​features:​expressioncols:​home|Expression-based Columns]], which are columns derived from a SQL expression rather than a specific column in the underlying database.
  
-The following example compares the Oracle ​declarations with the Omnidex declarations.  ​+=== Referencing ​Oracle ​Views ===
  
-<​code>​ +Omnidex ​table declarations can reference Oracle Views. ​ Omnidex will retrieve from the Oracle view just as though it is a table Oracle Views can be used to provide different views of the data, appropriate for the application.
-create ​table STATES +
-       ​(STATE_CD ​               CHAR(2), +
-        DESCRIPTION ​            ​VARCHAR2(31),​ +
-        STATE_NUM ​              ​CHAR(2),​ +
-        REGION_CD ​              ​CHAR(2),​ +
-        COUNTRY_CD ​             CHAR(2), +
-        TAX_RATE ​               NUMBER(16,​6));​ +
- +
-alter table STATES +
-        add constraint STATES_STATE_PK +
-        primary key (STATE) +
-        using index +
-        pctfree 20 +
-        tablespace SIMPLE +
-        storage (initial ​    ​100k +
-                 ​next ​       100k +
-                 ​minextents ​  1 +
-                 ​maxextents ​  ​unlimited +
-                 ​pctincrease ​ 0);+
  
-alter table STATES +When referencing an Oracle view, it is necessary to declare a UNIQUE ​constraint.  This requirement for the UNIQUE constraint is independent of any PRIMARY or FOREIGN constraints,​ discussed in the next page.  The UNIQUE constraint tells Omnidex how to uniquely identify a row.  When Omnidex retrieves individual rows, it will use this unique value; therefore, it is important that access to this column ​(or columnsbe properly indexed in the underlying table.  ​
-        add constraint ​STATES_COUNTRY_FK +
-        foreign key (COUNTRYreferences COUNTRIES(COUNTRY);​+
  
 +**Oracle CREATE VIEW Statement**
 +<​code>​
 +create view STATES_VIEW ​
 + (
 +   ​CTRY_DESCRIPTION,​
 +   ​CTRY_CAPITAL,​
 +   ​STATE_CD,​
 +   ​DESCRIPTION,​
 +   ​STATE_NUM,​
 +   ​REGION_CD,​
 +   ​COUNTRY_CD,​
 +   ​TAX_RATE
 + ) as 
 +   ​select C.DESCRIPTION,​
 +          C.CAPITAL,
 +          S.STATE_CD,
 +          S.DESCRIPTION,​
 +          S.STATE_NUM,​
 +          S.REGION_CD,​
 +          S.COUNTRY_CD,​
 +          S.TAX_RATE
 +   ​from ​  ​SIMPLE.STATES S, SIMPLE.COUNTRIES C
 +   ​where ​ S.COUNTRY_CD = C.COUNTRY_CD;​
 </​code>​ </​code>​
  
- +**Omnidex ​CREATE TABLE Statement**
- +
-In the Omnidex ​declaration,​ note that the PHYSICAL clause for table points to the Oracle syntax of //​user.table//​. ​ Also note that the columns use the PHYSICAL clause to point to the underlying Oracle column name, and use Omnidex datatypes rather than Oracle datatypes. +
 <​code>​ <​code>​
-create table          "STATES+create table          "STATES_VIEW
- ​physical ​            "​MYUSER.STATES"+ ​physical ​            "​SIMPLE.STATES_VIEW"
  (  (
 +  "​CTRY_DESCRIPTION" ​ STRING(47),
 +  "​CTRY_CAPITAL" ​     STRING(31),
   "​STATE" ​            ​CHARACTER(2) ​  ​physical "​STATE_CD",​   "​STATE" ​            ​CHARACTER(2) ​  ​physical "​STATE_CD",​
   "​DESCRIPTION" ​      ​STRING(31),​   "​DESCRIPTION" ​      ​STRING(31),​
Line 90: Line 115:
   "​COUNTRY" ​          ​CHARACTER(2) ​  ​physical "​COUNTRY_CD",​   "​COUNTRY" ​          ​CHARACTER(2) ​  ​physical "​COUNTRY_CD",​
   "​TAX_RATE" ​         FLOAT,   "​TAX_RATE" ​         FLOAT,
-  constraint ​STATES_STATE_PK primary ​("​STATE"​)+  constraint ​STATES_STATE_UK unique  ​("​STATE"​)
-  constraint STATES_COUNTRY_FK foreign ("​COUNTRY"​) references "​COUNTRIES"​+
  )  )
  ​in ​                  "​simple.xml";​  ​in ​                  "​simple.xml";​
 </​code>​ </​code>​
- 
  
  
Line 101: Line 124:
  
 **[[integration:​rdbms:​oracle:​databases|Prev]]** | **[[integration:​rdbms:​oracle:​databases|Prev]]** |
-**[[integration:​rdbms:​oracle:​queries|Next]]**+**[[integration:​rdbms:​oracle:​constraints|Next]]**
  
 ====== Additional Resources ====== ====== Additional Resources ======
 
Back to top
integration/rdbms/oracle/tables.1301592553.txt.gz · Last modified: 2016/06/28 22:38 (external edit)