[fdo-internals] Standardising FDO Schema's

Orest Halustchak orest.halustchak at autodesk.com
Fri Aug 29 09:21:25 EDT 2008


This is a very interesting discussion.

Let's look at this from another angle.

The FDO schema itself is a logical schema. The provider is responsible for mapping the logical schema to physical implementations. Different physical formats have different concepts and constraints. Even between RDBMS products, there are differences.

>From the FDO perspective, we have the following layers.

                Data store: This is actually the container or repository of an integrated set of objects. Within a data store, objects are modeled by classes within one or more schemas.

                Schema: This is a logical grouping of classes. There is no specific constraint as to how to group classes, but the grouping is usually based on the close relationships between classes, e.g. a LandUse schema, a Transportation schema, a WaterUtility schema, etc.

                Classes: Describes the type of a real world object.


Consider this example.

                LandUse Schema:
                                Classes: Parcel, Park, Lake, Agricultural, Industrial, ...
                Transportation Schema:
                                Classes: Interstate, Highway, Road, Railway, BikePath, ...
                WaterUtility Schema:
                                Classes: WaterPipe, WasteWaterPipe, Valve, ...
                GasUtility Schema:
                                Classes: Pipe, Valve, ...

Now, I may have a number of data stores that use the above: CityOfDenver, CityOfBoulder, CityOfColoradoSprings, ...

The above is a logical schema. How could that be mapped to physical schema? The discussion started with Oracle. Let's say I have an Oracle instance called ORCL. The main physical grouping mechanism that Oracle has is an Oracle Owner. So, one mapping is that the FDO Data Store maps to Oracle Owner, then FDO Schema.Class maps to table. That keeps the integrated set of data within a single Oracle owner. Another mapping is to map FDO schema to Oracle Owner, i.e. define Oracle owners LANDUSE, TRANSPORTATION, etc. But, then how do we separate CityOfDenver parcels from CityOfBoulder parcels? I could have DENVER_LANDUSE, BOULDER_LANDUSE, etc. There is a third mapping possible, and that's to use a separate Oracle instance for each data store, but users may not want to set up separate physical instances for this purpose, especially if they have a large number of data stores.


From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Zac Spitzer
Sent: Thursday, August 28, 2008 10:00 PM
To: fdo-internals at lists.osgeo.org
Subject: [fdo-internals] Standardising FDO Schema's

Hey everyone,

I have written up some ideas on FDO schema's as they stand and making them
provider agnostic and predictable across all FDO providers.


Mateusz Loskot suggested I post this here to get some feedback and then
maybe write it up into a RFC.


Zac Spitzer -
http://zacster.blogspot.com (My Blog)
+61 405 847 168
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/fdo-internals/attachments/20080829/a2e563e9/attachment.html

More information about the fdo-internals mailing list