Spatial Table Design

In mvdemo(Demo tables from oracle) we have tables STATES, COUNTIES, INTERSTATES and CITIES. So can I say that u should have a separate table for each Feature(Layer).
Suppose I have two Features CITIES and TOWNS both of them have the same non spatial fields. Here should I create two separate tables or a single table where I can put both the CITIES and TOWNS data.
Is there any advantage of putting similiar kind of data in two separate tables just because they are of different layers.

Dan's advice is sound.
Just a comment to reinforce what Dan is suggesting.
Most people normally put towns, villages, cities etc in one table. Often
a single attribute is used to CLASSIFY them. This attribute can be
used to drive symbolisation so that cities are rendered with a symbol
differently from towns etc. If you are rendering all the records in the table
in a single map theme/layer by the classification attribute no performance
hit will be incurred.
However, if you decided to render the data into 3 separate themes then
problems might start to arise especially if the table was very large (for
example, it held all places in the world) and you decided to create views
over the base table to show only villages, only towns, only cities etc via
a WHERE clause that referenced this attribute
eg WHERE placetype = 'Village'
Then you just might start to hit some performance problems. Why? Because
whereever the number of values in a classification attribute is small (for example 3 - village, town, city) relative to the number of records in the table (say 1,000,000),
Oracle's query engine would probably prefer to do what is called a "full table scan"
each time someone extracts data from any one view. What about creatnig
an attribute index on the classification attribute, you might say? The problem
is that an attribute with this sort of value distribution is a poor attribute for
indexing. If you were in this situation, you would be better off splitting
the data into 3 tables.
regards
Simon

Similar Messages

More than one SDO_GEOMETRY columns in one Oracle 8i spatial table

I have a spatial table as follows:
CREATE TABLE TEST(
ID VARCHAR2(255) NOT NULL,
POINT MDSYS.SDO_GEOMETRY,
LINE MDSYS.SDO_GEOMETRY,
POLYGON MDSYS.SDO_GEOMETRY,
PRIMARY KEY(ID));
Is it a good practice to have more than one SDO_GEOMETRY columns
in one spatial table? What are the drawbacks if any to have a
spatial with more than one layer?

I have one question about more than one SDO_GEOMETRY columns
in one table in Oracle 8.1.7. When I wanted to create two
spatial indices for this table, every time I got some error.
Can anyone tell me how to figure it out?
Thanks very much,
Fan Fan,
You need to insert metadata record before creating spatial
indices.
Try the following:
REM USER_SDO_GEOM_METADATA :
REM insert a row for the geom layer for TEST TEST2 tables
REM
INSERT INTO USER_SDO_GEOM_METADATA
( TABLE_NAME, COLUMN_NAME, DIMINFO, SRID)
VALUES ('TEST', 'POINT', MDSYS.SDO_DIM_ARRAY
(MDSYS.SDO_DIM_ELEMENT('LON', -180,
180, .000005),MDSYS.SDO_DIM_ELEMENT('LAT', -90, 90, .000005)),
NULL);
INSERT INTO USER_SDO_GEOM_METADATA
( TABLE_NAME, COLUMN_NAME, DIMINFO, SRID)
VALUES ('TEST', 'LINE', MDSYS.SDO_DIM_ARRAY
(MDSYS.SDO_DIM_ELEMENT('LON', -180,
180, .000005),MDSYS.SDO_DIM_ELEMENT('LAT', -90, 90, .000005)),
NULL);
INSERT INTO USER_SDO_GEOM_METADATA
( TABLE_NAME, COLUMN_NAME, DIMINFO, SRID)
VALUES ('TEST', 'POLYGON', MDSYS.SDO_DIM_ARRAY
(MDSYS.SDO_DIM_ELEMENT('LON', -180,
180, .000005),MDSYS.SDO_DIM_ELEMENT('LAT', -90, 90, .000005)),
NULL);
REM create a spatial index based on TRAFFIC.GEOM
REM
REM
CREATE INDEX TEST_G_POINT_IDX ON TEST(POINT) INDEXTYPE IS
MDSYS.SPATIAL_INDEX;
CREATE INDEX TEST_G_LINE_IDX ON TEST(LINE) INDEXTYPE IS
MDSYS.SPATIAL_INDEX;
CREATE INDEX TEST_G_POLYGON_IDX ON TEST(POLYGON) INDEXTYPE IS
MDSYS.SPATIAL_INDEX;

Error while updating spatial table

Hi,
When i try to update a spatial table with the following syntax i get the below error,
UPDATE tab1 SET MP = 1, AT = 3,
RDATE = TO_DATE('30:04:2001:16:04:08', 'DD:MM:YYYY:HH24:MI:SS'),
ODATE = TO_DATE('30:12:1899:00:00:00', 'DD:MM:YYYY:HH24:MI:SS'),
REP = 1
WHERE ID = 7
ERROR at line 1:
ORA-29877: failed in the execution of the ODCIINDEXUPDATE routine
ORA-00600: internal error code, arguments: [kcbgtcr_1], [], [], [], [], [],
Any idea why is this happening??
Thanks
Shiva
null

Hi Dan,
we are using oracle 8.1.6.3 on Solaris 8.
Table description is as follows.
ID NOT NULL NUMBER(10)
ROUTE_NUMBER NOT NULL VARCHAR2(255)
MP NUMBER(8,3)
GEOM MDSYS.SDO_GEOMETRY
AT NUMBER(10)
RDATE DATE
CDATE DATE
ODATE DATE
REPORT NUMBER(10)
CLEAR NUMBER(10)
OFFER NUMBER(10)
X NUMBER(8,6)
Y NUMBER(8,6)
This table has a valid entry in the user_sdo_geom_metadata table. And the spatial index is valid.
Thanks
Shiva

Spatial tables in Data warehouse database or separate?

Hi all,
I have a question from a customer who's asking what the recommendation is of storage of the spatial tables and the warehouse tables.
Should they reside on the same database for best performance or doesn't it matter where the spatial tables are located.
Is there any official recommednation from Oracle on this?
Best regards,
Hakan

Hi Hakan,
it's not easy to give a quick answer here.
a) you want to compare warehouse tables with spatial tables
To answer this very well you should define what is a warehouse table and what is a spatial table. In this forum you will get for spatial tables the definition "A spatial table is a table with one or more columns of type SDO_GEOMETRY". How do you define a spatial table and how do you define a warehouse table?
b) you ask for performance
Performance is not depending only on table type. Performance is depending on a lot of steps. For example on the work which has to be done to answer the question, can data read from buffer cache or must they be read from physical devices, execution plan .....
I don't know if there is a official statement from Oracle which is usefull to answer your query.
Can you ask a little bit particular please?
In my experience there it is not adviseable to store tables in different databases (instances) when I have to query it together. If you split the tables in different instances, the execution has much more overhead because you have to talk to 2 instances and it will very hard for the optimizer to find the best execution plan.
Regards
U. Martin

Table Designer third rule thick is not working for me. Any suggestions?

I am trying to turn the third rule in a four row table thick. I go into Table Designer and select Every 3rd Thick. The others are all none. The table is not responding to the command to make the third rule thick as I need it to be. Does anyone have any suggestions? Thank you.

To remove table format overrides, you need to go to Table > Format > Custom Ruling and Shading, and set as follows:
For more info, see page 171 of my book.
-Matt
Matt R. Sullivan
co-author Publishing Fundamentals: Unstructured FrameMaker 11

How to perform DML Operations on Spatial Table Using ADF

Hi
I have an urgent requirement. I have a table with Spatial column. I have generated Business components based on Spatial Table.
Now I have to perform Create,Read,Update and Delete operations using ADF Business Components on Spatial Table.
I have written custom create(),read(),update() and delete() methods in my Application Module and i have to implement those methods.
Can any one help me out how to acheive above four functionalities using ADF Business Components.
Thanks in Advance

HI,
see this example.
u can do like this.
DATA: BEGIN OF seats OCCURS 0,
        carrid   TYPE sflight-carrid,
        connid   TYPE sflight-connid,
        seatsocc TYPE sflight-seatsocc,
      END OF seats.
DATA seats_tab LIKE HASHED TABLE OF seats
               WITH UNIQUE KEY carrid connid with header line.
SELECT carrid connid seatsocc
       FROM sflight
       INTO table seats.
loop at seats.
COLLECT seats INTO seats_tab.
endloop.
LOOP AT seats_tab.
write:/ seats_tab-carrid,seats_tab-connid,seats_tab-seatsocc.
ENDLOOP.
rgds,
bharat.

Creating spatial index on spatial table

Hi there. Just a quick query on creating spatial indexes on spatial tables. I have a table called System_Sessions which has the following four fields and types:
USER_ID NUMBER(10)
SESSION_ID NUMBER(10)
SESSION_BOUNDARY MDSYS.SDO_GEOMETRY (polygon)
START_POINT MDSYS.SDO_GEOMETRY (point)
I am inserting one row per user session into this table. I also need to retrieve the session ids of previous sessions involving a particular user based on the session's start point. The query i am running is an sdo_within_distance query which looks as follows:
Select session_id from joeweaker.system_sessions where user_id = 1003 and SDO_WITHIN_DISTANCE(start_point,
(MDSYS.SDO_GEOMETRY(2001, 8265, MDSYS.SDO_POINT_TYPE
(-105.0,40.0, NULL),NULL, NULL)), 'DISTANCE = 10000')='TRUE';
However I encounter the following error whenever I attempt to execute this query:
ORA-13226: interface not supported without a spatial index
ORA-06512: at "MDSYS.MD", line 1723
ORA-06512: at "MDSYS.MDERR", line 8
ORA-06512: at "MDSYS.SDO_3GL", line 255
I know I haven't built the spatial index on the table so I was hoping that somebody might show me how to do this. Thnaks a lot, Joe

Thnaks a lot Dan for the prompt reply. I have done as you advised and everything appears to be fine. However I have a second table called Session_Interest_Areas which appears as follows:
USER_ID----NUMBER(10)
SESSION_ID----NUMBER(10)
AREA_ID----NUMBER(10)
AREA_BOUNDARY----MDSYS.SDO_GEOMETRY
I inserted the necessary detail into the user_sdo_geom_metadata table and then attempted to create the index as follows (exactly the same format as my other spatial tables:
create index session_interest_areas_idx on
session_interest_areas (area_boundary)
indextype is mdsys.spatial_index;
When I execute this query I get the following stream of error messages:
ORA-29855: error occurred in the execution of ODCIINDEXCREATE routine
ORA-13249: internal error in Spatial index: [mdidxrbd]
ORA-13249: Error in Spatial index: index build failed
ORA-13249: Error in spatial index: [mdrcrtxfergm]
ORA-13249: Error in spatial index: [mdpridxtxfergm]
ORA-13200: internal error [ROWID:AAAHocAAJAAAAC8AAA] in spatial indexing.
ORA-13206: internal error [] while creating the spatial index
ORA-13373: Element of type Extent is not supported for Geodetic data
ORA-06512: at "MDSYS.SDO_INDEX_METHOD_9I", line 7
ORA-06512: at line 1
Why does this give me an error when the same approach worked fine for my other spatial tables? Is it something to do with the SRID? Also the index appears to have been created so I presume it has been created incorrectly. Thanks for your time, Joe

FND tables design

Hi,
I was going through FND Design Data section on eTRM website .
I need to understand a few things about table design here.
I was surprised to see one composite primary key and one composite unique key instead of primary keys in single columns(concurrent_queue_id,concurrent_program_id and concurrent_processor_id) in the following tables
FND_CONCURRENT_QUEUES -- Primary Key: FND_CONCURRENT_PROCESSORS_PK(columns:application_id,concurrent_queue_id)
               Primary Key: FND_CONCURRENT_PROCESSORS_UK1(columns:application_id,concurrent_queue_name)
FND_CONCURRENT_PROGRAMS -- Primary Key: FND_CONCURRENT_PROGRAMS_PK(columns:application_id,concurrent_program_id)
               Primary Key: FND_CONCURRENT_PROGRAMS_UK1(columns:application_id,concurrent_program_name)
FND_CONCURRENT_PROCESSORS -- Primary Key: FND_CONCURRENT_QUEUES_PK(columns:application_id,concurrent_processor_id)
               Primary Key: FND_CONCURRENT_QUEUES_UK(columns:application_id,concurrent_processor_name)
Let's consider FND_CONCURRENT_QUEUES table for instance.
As per my understanding, concurrent manager name and id has to be unique throughout the suite.
But, by decalring them as composite primary/unique key with application_id column,Oracle is saying that the uniqueness of concurrent manager's id and name is maintained across one particular module(application like AP,GL etc) only and not across the entire suite.
Is that actually the case?
Also,this concurrent_queue_id column is used as foreign key for many tables.
Now, for a column to be used as a foreign key, it has to be either unique key or primary key itself alone(not a part of a composite key) in its parent table.
In this case the column is a part of a composite primary key and still being referred from many tables as foreign key.
Please clarify.Any additional comments on this are very welcome.
I have exactly the same questions for the PROGRAMS and PROCESSORS(program library) tables as well.
Thanks,
Rushi

http://etrm.oracle.com/pls/etrmlatest/etrm_search.search
requires a metalink userid

SQL plus and Spatial tables

I have some spatial tables in 10g. I can use 'select query' on non spatial attributes but if try
select * or
select geom then my SQL plus gives error ::
Program Error - sqlplusw.exe has generated errors and will be closed by Windows. You will need to restart the program. An error log is being created.
<Cancel>
But I am able to use isqlplus without any errors.
Earlier SQL plus used to work fine. I don't understand what happened to it in between.
How can I bring my SQL plus working again.

I created a copy for a spatial table using.
create table copy as select * from original, and it was successful .
Other than that I haven't done anything other than select queries.

Does CDC work on spatial tables?

I'm trying to prototype using change data capture on some spatial tables. I'm able to create the cdc tables and subsribe, etc. with no errors. But when I go to try and update a record in my spatial table I keep getting the following errors:
ERROR at line 1:
ORA-31495: error in synchronous change table on "FULL"."GEONAME_FEATURE"
ORA-01733: virtual column not allowed here
My non-spatial tables that I set up the same way work fine for updates and inserts.
The spatial CDC table and the base spatial table look the same. Is there something about Spatial that prohibits it from being used with change data capture?

This might be related to bug 3561140 - we are working with the appropriate folks in Oracle to try to resolve it. If you can post your view definition then we can try to ensure this is fixed at the same time (a small test case would be appreciated).

Table design help

I have simple table design issue which I would appreciate some feedback on. Lets say I have two tables to start: users and addresses. Both tables have their primary keys of userid and addressid. Assume no two users can share an addresss.
Is it better to have the userid in the address table, so as to associate the addresses to users OR is it better to have a third table only for associating userid's and addressid's? The latter requires an extra table but appeals to me more because the address table remains purely addresses... seems more appropriate for some reason, but I could be wrong.
Thanks

Frank Kulash wrote:
Hi,
When deciding which is the best option, weigh the costs and benefits of each option. What are the advantages and disadvantages of each?
The two-table model is certainly simpler. Joins will be more efficient, and slighltly less storage will be required.
What is the advantage of the three-table model? Why does it appeal to you? In the imaginary world where no two users can share an address, it makes sense to think of resident as an attribute of address. Each address can be related to (at most) one user, just like each address can be related to (at most) one postal code.
But, as others have said, that is an imaginary world. Even if you're designing an application where you know there is some kind of business rule that prevents two users from being at the same address, can you be sure that business rule won't change next month?
So I see the relevant costs ot the two-table design as: (the probablility of proving inadequate in the future) * (cost of re-writing all the queires based on the two-table design)
I see the costs of the three-table design as: extra time needed to write and execute joins + marginal costs of an additional table.
In practice, few applications really treat address as an entity. It's more common for address to be considered an attribute of the person, or, if a person can have multiple addresses, to have a separate table that links each address to a single person, with no attempt to minimize duplicates.You make two key points here that I'd like to highlight, just for re-emphasis to the OP.
The first is that business rules can change. When analyzing data relationships, one should always ask if the relationship definition is immutable or simply a reflection of the current business rule. For instance, gender is considered to be immutable. If gender is a property of the entity being tracked, you can pretty much figure that there will never be but two possible values, and only one value current at any given time. But if the business rule says an entity can only have one address ... that rule is definitely subject to change. So the design should be such as to already allow for a different rule. I spent 21 years at an auto manufacturing plant. When the plant was first built, the business rule was there would only be one line of vehicles, and only one shift a day. The IT people tried to build systems to allow more flexibility, but the business side said NO. They paid for that for the next 20 years. In the case of the OP's example, it is most definetly possible for a person (or business) to have more than one address, and it is just as possible for more than one person (or business) to share a single address. The system should be designed for that regardless of the business rule.
The other big point is that data designers need to pay close attention to what constitutes an "entity" vs. an "attribute". Making that distinction is key to getting a good 3NF design.

Fact table design horizontal vs vertical

Hi Guys,
I am putting together a list of advantages and disadvatages of horizontal vs vertical fact table orientation.
Vertical:
ID, DimensionKey1, DimensionKey2, Factno (or KPIDimensionKey), Fact
Advantages:
-Easily extendible when new facts are integration
-A lot more rows
-Density
Disadvantages:
-Applications that can only deal with the horizontal format require a few to
transpose the rows into columns (additional computing time)
Horizontal:
ID, DimensionKey1, DimensionKey2, Fact1, Fact2, Fact3, Fact4, Fact5,...
Advantages:
-The most common fact table design
-Possibly faster access
Disadvantages:
-Sparsity
-Not easy to extend

Do you agree or can add something?

TABLE DESIGN

Hi I have this business rule which makes my table design very complex(at least for me)
My application keeps track of all the patients who are admitted to the hospital with some diagnosis(disease) like TB,asthma,Heart attack etc.Also my application is suppose to keep track of any procedure (operations) like Heart transplant,heart surgery etc performed on the patients.Later,depending upon the diagnosis and procedure ,the patients are clubbed under one group (help is needed to create the table for this group).
To satisfy my requirements I create a the following tables
DIAGNOSIS
Diagnosis_code pk
Diagnosis_Desc
PROCEDURE
Procedure_Code pk
Procedure_Desc
Now I am confused on how to create the table for patient group.I mean if any patient is suffering from a diagnosis like heart attack and has undergone a procedure like Heart transplant then this kind of patient should be clubbed under the group say XYZ.Similarly if any patient is suffering from TB and has undergone a procedure like Kidney transplant then he should be clubbed under the group say ABC.In short for every patient in the hospital this table is read to club the patient under certain group.Example
PatientGroup1 SomeDiagnosisCode1 SomeDiagnosisCode2 SomeProcedureCode1
PatientGroup2 SomeDiagnosisCode1 SomeProcedureCode6
PatientGroup3 SomeDiagnosisCode8 SomeProcedureCode9 Some DiagnosisCode6
etc etc
Please help with the design of the Patient group table.
thanks
MS

Depends on a few factors ...
The most flexible (that I can think of right now) design would be as follows:
DIAGNOSIS
diag_id
diag_desc
PROSEDURE
proc_id
proc_desc
PATIENT
patient_id
patient_name
PATIENT_DIAG -- associates zero, one, or more diagnosis with a patient
patient_diag_id
patient_id
diag_id
PATIENT_PROC -- associates zero, one, or more procedures with a patient
patient_proc_id
patient_id
proc_id
DIAG_PROC_CAT -- identifies a Group
diag_proc_cat_id
diag_proc_cat_desc
DIAG_PROC_CAT_DIAG -- associates zero, one, or more diagnosis with a Group
diag_proc_cat_diag_id
diag_proc_cat_id
diag_id
DIAG_PROC_CAT_PROC -- associates zero, one, or more procedures with a Group
diag_proc_cat_proc_id
diag_proc_cat_id
proc_id
PATIENT_DIAG_PROC_CAT -- associates zero, one, or more Groups with a patient
patient_diag_proc_cat_id
patient_id
pdpc_precedence_nmbr -- (1=highest ... don't need it if you're only gonna allow one association)
diag_proc_cat_id
Put the business rule code in TRIGGERs for PATIENT_DIAG and PATIENT_PROC to INSERT appropriate values into PATIENT_DIAG_PROC_CAT ... INSERT proper rows into DIAG_PROC_CAT, DIAG_PROC_CAT_DIAG, and DIAG_PROC_CAT_PROC tables to support business rule (if patient has same diagnosis and procedures as a Group/Category, then assign that Group/Category to the patient ... if more than one applies, you may or may not allow it ... if you do, indicate which is primary if doubling on reports/ui is a bad thing) ... Users may modify DIAG_PROC_CAT, DIAG_PROC_CAT_DIAG, and DIAG_PROC_CAT_PROC tables as needed to manage their own Groups/Categories.
Good luck.

Table design question

Hello,
I have a quick question on a table design. I currently have a table that will store approval information on a report. The individual report will need to go through 3 levels of approval before it's considered final. I have considered a few different scenarios on how to design the table but I'm not sure on what is the best choice. Currently I'm using 3 columns that will store each approval. For example,
Table 1:
file_id,
subject,
summary,
division_approve,
program_approve,
group_approve
I thought about using one column and simply stepping through a higher numeric value for each approval but found that doesn't work if I want to view items that were approved only at the division_approve level. Does anyone else have any suggestions? Hopefully I provided enough information.....
Thanks in advance!
Randy

yes, better going for higher level of normalisation and desiging more tables:
tab_aproval ( id,File_id,Approval_authority,rank )
id      File_id Approval_level rank
1     1 first_level 1
2     1 second_level 2
3     1 third_level 3
4     2 first_level 1
5     2 second_level 2
tab_file_approval
file_id, subject, summary, id
1 'doc 1' 'first level done' 1
1 'doc 1' 'second level done' 2
1 'doc 1' 'third level done' 3

Advise on Table design

Dear all,
I have a pool of data which are based organized has CATEGORY and SUB-CATEGORY. When I am configuring the database I should be able to define all categories at once, then being able to define which one is the Parent category of the others.
For exemple if I have a set of Dishes for a restaurant, then I can classify those dishes in different menu category which are then the Parents category for dishes.
Please note that a SUB-CATEGORY can have other sub categories attached.
To have a better idea of what I am trying to do is similar things when you create folders and sub folders on a file system. From the configuration side of the database I should be able to define my category and subcategories and then organize them by a link
ID or other stuff, in the same way I will organize folder.
What will be the best Database table design for that scenario ?
I am not a DBA, but have some basis so try to speak the same language as me :-)
Thanks for help
regards

I think you have it with your design. There are a few ways to represent a hierarchy in SQL, and having two tables like this:
CategoryID    CategoryName
ParentCategoryID
1001
Dishes          NULL
1002          Desserts
1001
1003          Icecream
1002
SubCategoryID    SubCategoryName
CategoryID
10001
Vanilla
1003
10002
Strawberry
1003
10003                   Butterscotch             1003
Make sense ONLY if you can guarantee a two level hierarchy (or a fixed number of levels, where you might have yet another table SubSubCategory). Having a fixed number of levels can make processing a ton easier because your queries can be written in
a straightforward manner because the levels of nodes in the tree remain the same.
Your requirements here:
"CATEGORY can have other sub categories attached."
Leads to the more flexible solution like you have set up:
CategoryID    CategoryName
ParentCategoryID
1001
Dishes          NULL
1002
Starters
1001
1003
Item1
1002
1004
SubCat1
1003
1005
SubCat2
1003
1006
SubCat3
1003
Because adding a subcategory on SubCat3 is as simple as:
1007          SubSubCat1
1006
Processing the hierarchy becomes an iterative process (using a recursive CTE) if you have needs to do a lot of aggregation on groups. There are techniques available to make things go faster than using this pattern in the implementation, but unless
you are going to need 1000s of nodes, then this pattern works great (known as the adjacency list, where you are basically storing the adjacent node in your tree).
Louis
Without good requirements, my advice is only guesses. Please don't hold it against me if my answer answers my interpretation of your questions.

Spatial Table Design

Similar Messages

Maybe you are looking for