Oracle8i Spatial User's Guide and Reference Release 8.1.5 A67295-01 |
|
Prior to release 8.1, the Spatial product always used four database tables to store and index spatial data. This database structure is modeled on the first of three Open GIS Features for SQL Implementation options, namely, using numeric SQL types for geometry storage. This schema is different from the new spatial objects model introduced in Spatial release 8.1 and described in Part II of this guide. However there are still some advantages, discussed in Section A.1, to using this model.
The four tables, used to store and index geometry, are collectively referred to as a layer. A template SQL script is provided to facilitate the creation of these tables. See Section A.3.2, "crlayer.sql Script" for details.
Table 10-1 through Table 10-4 describe the schema of a Spatial layer.
Table 10-1 <layername>_SDOLAYERSDO_ORDCNT | SDO_LEVEL | SDO_NUMTILES | SDO_MAXLEVEL1 | SDO_COORDSYS2 |
---|---|---|---|---|
<number> |
<number> |
<number> |
<number> |
<varchar> |
1
SDO_MAXLEVEL is an optional column. 2 SDO_COORDSYS is an optional column. |
SDO_DIMNUM | SDO_LB | SDO_UB | SDO_TOLERANCE | SDO_DIMNAME |
---|---|---|---|---|
<number> | <number> | <number> | <number> | <varchar> |
SDO_GID | SDO_ESEQ | SDO_ETYPE | SDO_SEQ | SDO_X1 | SDO_Y1 | ... | SDO_Xn | SDO_Yn |
---|---|---|---|---|---|---|---|---|
<number> | <number> | <number> | <number> | <number> | <number> | ... | <number> | <number> |
SDO_GID | SDO_CODE | SDO_MAXCODE 1 | SDO_GROUPCODE 2 | SDO_META |
---|---|---|---|---|
<number> | <raw> | <raw> | <raw> | <raw> |
1
SDO_MAXCODE is not required for the recommended fixed-size tile indexing algorithm. 2 SDO_GROUPCODE is not required for the recommended fixed-size tile indexing algorithm. |
The columns of each table are defined as follows:
SDO_TUNE.ESTIMATE_TILING_LEVEL
procedure to determine an appropriate tiling level for your data.
Spatial provides stored procedures that assume the existence of the layer schema as described in this section. While layer tables may contain additional columns, they are required to contain at least the columns described in this section with the same column names and data types.
Figure 10-1 illustrates how a geometry is stored in the database using Spatial and the OGIS V1 schema model. The geometry to be stored is a complex polygon with a hole in it.
<layername>_SDOLAYER
SDO_ORDCNT (number) |
---|
4 |
<layername>_SDODIM
SDO_DIMNUM (number) | SDO_LB (number) | SDO_UB (number) | SDO_TOLERANCE (number) | SDO_DIMNAME (varchar) |
---|---|---|---|---|
1 |
0 |
100 |
.05 |
X axis |
2 |
0 |
100 |
.05 |
Y axis |
<layername>_SDOGEOM
In this example, the <layername>_SDOGEOM table is shown as an 8-column table with 4 ordinates per row. In actual usage, Spatial supports N-wide1 tables. The coordinates for the outer polygon in this example could have been loaded into a single row containing values for coordinates P1 to P8, and then repeating P1 to close the polygon. The coordinates would be stored in the SDO_X1 and SDO_Y1 through SDO_X9 and SDO_Y9 columns.
The data in the <layername>_SDOINDEX table is described in further detail Section 1.6, "Indexing Methods". The SDOINDEX table contains entries of the form [SDO_GID, SDO_CODE] where each SDO_CODE represents a tile that interacts with a geometry identified by SDO_GID. For a given SDO_GID value, there may be one or more SDO_CODEs. Each SDO_CODE value may be associated with one or more SDO_GIDs.
1
A <layername>_SDOGEOM table can have up to 1000 columns. The maximum number of data columns is 1000, minus 4 for the other required spatial columns, and minus any other user-defined columns. For polygons and line strings, storing 16 to 20 ordinates per row is suggested for performance reasons, but not required. The objective is to minimize the number of NULLs stored in the <layername>_SDOGEOM table.