Thoughts on SDE

Thoughts on SDE [Transformation]

Endless Learning2010-03-03 14:39:44 Read11 Comment0 Font Size:LargeMediumSmall

Because my understanding of ArcSDE is still relatively simple and vague, but I have the idea of extending the ArcSDE function in my mind. I don't know if SDE supports secondary development, can we integrate the spatial data management feature into it? FirstArticleAdd to favorites here:

Vitality of ArcSDE Middleware Technology

Taking the ArcSDE technology as a "chicken ribs" for spatial data management, it is actually a simple and "metaphysical" viewpoint. The logic of thinking is: Since ArcSDE and oraclespatial are both used to store space data, what is the use of ArcSDE when oracle is used? Obviously, the premise of this logic is to equate ArcSDE with cancelspatial. Incorrect premise leads to invalid conclusion. In addition to non-technical (or commercial) reasons, the root cause of the premise error is the lack of in-depth understanding of ArcSDE and spatial data management technologies and their development trends.

First, the positioning of ArcSDE is different from that of Oracle spatial. Oracle Spatial emphasizes or cares about how to enable the database managed by Oracle DBMS to "spatiallyenabled". In fact, it expands the spatial data model on the original database model. In the same way, apart from Oracle, IBM's DB2 and Informix are also working on their spatial extender and spatialdatablade technologies. Their Positioning should be basically the same. Unlike DBMS vendors, ESRI's ArcSDE is positioned to manage and apply spatial data, rather than simply Virtualize databases. It is precisely because of different positioning that oraclespatial only implements the storage and retrieval of simple spatial elements such as "points, lines, and surfaces, in addition, ArcSDE can also manage object-oriented notes, plane topologies, linear topologies, raster (image) data, and CAD data, it also provides version-based workflows and long transaction processing mechanisms. The difference in positioning makes data models, implementation technologies, and client applications of ArcSDE and oraclespatial quite misplaced. for users, the two are not mutually exclusive.

The fact is that Oracle, IBM, Informix (now acquired by IMB) and other DBMS vendors are ESRI partners, ESRI has in-depth cooperation with ESRI in the development of space data management technology. ESRI contributes to its profound knowledge of space data management and application. ESRI and DBMS vendors have a long and mutually beneficial relationship.

Secondly, for the physical model of spatial data, ArcSDE and Oracle Spatial support five types:

A. Compressed binary long raw; (supported by ArcSDE)

B. Compress binary lob; (supported by ArcSDE)

C. varray related to objects; (supported by Oracle)

D. OGC space type (supported by ArcSDE)

E. Standardized storage. (Oracle Support)

The three formats supported by ArcSDE are either consistent with the simple featurespecification for SQL promulgated by OGC (OpenGIS Consortium) (d), or completely include the OGC specifications, and made a considerable extension. The two formats supported by Oracle are not fully compatible with the OGC specification. This will naturally affect the data sharing and interoperability of GIS systems fully based on the platform in the future. Data sharing and system interoperability are key trends in the development of the GIS platform and its applications.

Third, the five physical implementation methods of spatial data mentioned above are as follows: A, B, C, D, and E. ArcSDE has the highest efficiency. Because it is necessary to solve the massive space data management and driver for multi-user concurrent access, efficiency is always a key concern of ArcSDE.

Fourth, the varray method related to Oracle Objects is the so-called "white box", that is, the content of the "package" of data objects can be directly accessed and manipulated. The ArcSDE method is called "Black Box". The client cannot directly operate on the content in the underlying data object structure at the database table level (because it is binary, right ?). The advantage of "white box" is that its client can access data directly through SQL, which is one of the reasons why many GIs vendors rely on oraclespatial directly to avoid being too heavy in space data management. But because of this, data consistency becomes a problem. DB2 and infomix both seem to have seen the problem, so they also abandoned the "white box" model.

From the above four points, we can see that ArcSDE is not redundant because of Oracle spatial. On the contrary, for applications that not only meet the requirement of finding a place to store space data (applications with higher requirements), ArcSDE is a more reasonable choice.

Compared with the DBMS, ArcSDE plays the role of "Middleware. Why middleware? It is because there is no database platform that can "take the big bag" across the world in different operating systems, different levels, and applications in different fields. However, different DBMS systems vary greatly in terms of data models and physical implementations. To overcome these differences, DBMS vendors cannot solve the problem themselves. DBMS vendors certainly hope to unify the world, but it turns out that in a fully competitive business environment, this is impossible in the visible future. This is true for the database field and for other e-commerce fields. So what is the solution? The answer is: middleware. Through the role of middleware, the differences between different operating system platforms and database platforms will be shielded from the middleware and will be oriented to specific fields (such as spatial data management and application) the required technologies are highly specialized (abstract) for efficient sharing and interoperability between different clients.

Of course, DBMS cannot unify the world, nor can it be used as an ArcSDE for space data servers. At the moment, GIS vendors except ESRI have not yet launched a powerful "Middleware" similar to ArcSDE. Many GIS vendors are helpless in attacking the "Middleware" of spatial data management. However, in the information society, it is necessary to eliminate information islands. In order to ensure interconnection and interoperability between information islands, or to unify all information platforms, you can either communicate with different platforms in a certain way and establish application-oriented virtual spaces and interfaces for different fields. The former is impossible, while the latter is being led by a variety of "Middleware. "Middleware" is widely used in e-commerce and other Internet applications (with a global output of more than $70 billion). In the field of spatial data management, ArcSDE is only a first step.

______________________

The red part clearly states that the middleware blocks different data and exposes the same interface. So what does middleware do between these differences? In our spatial information field, it refers to converting the spatial data stored in different data models and data structures on different database platforms into GIS applications.ProgramIdentifies and processes spatial objects. Can we abstract more functions from GIS software into SDE? That is, functions that are commonly used in the space field and can be automatically completed and very commonly used, such as projection conversion and scale transformation, are removed from GIS software and integrated into SDE. What data is obtained from SDE is not the original data, but the data that is automatically processed by SDE? Of course, it is impossible for all functions to be obtained in SDE. Only operations that can be automatically completed without manual intervention, such as a simple buffer zone computing.

Reprinted from: http://blog.163.com/sky_zzb/blog/static/1213095172010232394486/