Migrating from relational GIS to GIS objects a utility implementation perspective
Why migrate from relational design to objects?
Technological advantages that compliment utility network modeling are inherent in
object model designs where as most relational database management models lend
themselves more toward the business functions of an organization. In relational
databases, persistency is obtained by all data stored in tables. Queries and editing
operations performed on these data are stored in tables. The network infrastructure
needed much custom code to be managed and queried in ways that are useful to the day
to day operations of a utility. In object oriented designs (OOD), objects can be made
transient (data used only for the duration of a function or application session) or persistent (data that is created and may available throughout the organization) when
instantiated. Abstraction can provide the capability to change from one to another in
some systems and provides a mechanism of scalability for data model expansion. The
object model itself is the source for maintaining the characteristics that are meaningful to
a utility.
Design differences in relational and object oriented databases, and the addition of new
data users within the enterprise require that agencies redesign the model to take
advantage of existing processes, new technologies, and welcome new users with their
requirements to utilize the enterprise database. The goal is still to provide the primary
data store and promote data utilization enterprise wide to make work-groups more
efficient, to enhance customer satisfaction, and to provide additional cost savings and
payback. However the way that the data is used has changed requiring a design that
allows for component object model (COM) applications to analyze, imbed, and report on
data objects in ways that relational designs could not.
Cost
Managing a GIS can be costly. The data is the most expensive investment in a relational
GIS project and costs are greater when custom applications and functions are required.
End-user and system training is needed with any GIS implementation. The maintenance
of the GIS software and database modifications is where continuing expenditures are also
required.
Since much of the behavior and that which defines a GIS feature is a part of the object
model diagram, new data objects can be added to rectify deficiencies discovered in the
relational model without having to anticipate a large investment in custom application
programming. Application maintenance costs are lower because there is less code to
maintain. Code does not have to change when the data model classes are extended. The
training effort as it relates specifically to GIS maintenance is more efficient since many
commonly used application development tools are used to create the ODBMS and
supporting application code.
Software Development
Object oriented programming methods and tools have become standard to the GIS world
thus the object-oriented database becomes the best implementation to take full advantage
of the benefits that COM applications provide. Since many object-oriented designs are
built to be only somewhat complete yet expandable, components are reusable thus
lowering the cost of software. Modular components also provide better quality software
and a faster development cycle. Applications can be distributed to specific units to
provide users with combinations of common and specialized functions. COM
development, compared to traditional GIS software development, contributes to cost
reductions since programmers can more productive in developing and maintaining
software.
Performance
Modeling requirements of complex relationships that are required by utilities are offered
in object GIS designs. The object database provides a better means of storing and
retrieving GIS and related data. Engineers and field crews can access the data and related
information easier. Emergency response to events such power outages and main breaks
can be analyzed faster and the results delivered easier through COM based applications.
In relational databases information pertaining to a feature is spread out over many tables.
For this reason, response time for queries suffers due to the need to access multiple tables
and join them in order to retrieve feature data. “Object-oriented databases can reduce the
need for paging by enabling only the currently required objects to be loaded into memory
(relational databases load in tables containing both the required data AND other
unnecessary data ).”1
Scalability
Complex data such as images such as network schematics or photographs, video such as
sanitary sewer television inspections, and documents can be managed better within the
object oriented GIS. Conversely, GIS data can be accessed from interfaces to complex
data. Functionality can also be scaled to a particular task or user group. Objects can be
stored in the way they are actually used and COM programming techniques also insure
implementation compatibility to object databases as object oriented technology evolves.
Data layer overhead
Relational designs require layers that convert data to rows and columns for storage. This
layer also has a drain on system processing resources since every application call to the
database requires that this process be executed or analyzed. Essentially the overhead
costs add up and more efficient means of data design and storage are necessary.
Data Maintenance
While GIS may be the focus of the migration, other applications should also be
reassessed for usefulness within the object environment. Many systems such as work
management systems (WMS) may need to be replaced in order to provide a more
comprehensive utilization of the ODBMS implementation and to provide a central
location for facility management data thus eliminating redundant activities between
departments such as CIS and field operations. The stakeholders in each department that
will be effected by the migration should have input into the conceptual design when the
migration project begins. Participation by representatives of all potential groups will help
to identify requirements and minimize design and application selection risks from the
initial conceptual vision to the final deployment of the ODBMS and supporting software.
Business processes, workflow, and source data format will impact the extent of the
migration effort from a conversion, integration and application stand point. These issues
and the resolution to current problems require as much input from stakeholders as can be
obtained. The result should be a single facilities database that can be accessed, with
particular security contraints, by all departments whose daily business functions require
such data.
Relational design limitations:
-
Relational design standards are rigid and not necessarily used to create the
database and the rules that applications and feature tables adhere to.
- Relational designs require application processing to link tables together and
manage user interaction with data tables.
- Other applications and users do not inherently adhere to standards imposed
upon a relational design.
- New data definitions can be introduced into the model but application
programming is required to apply the proper links and rules for the new
feature data or related attribute.
- Standards for developing relational applications are more or less up to
application developers or in-house technicians using a proprietary macro
application language.
- The technology industry has been utilizing object-oriented techniques for
application development for years. Relational models need customization to
applications to create the model relationships at run time and are better suited
for business accounting type processing.
- Design flaws may not be discovered before the model is implemented.
Object design advantages:
- Object model diagrams are the source of the object database. The repository is
born of object model diagrams created using a Unified Modeling Language
(UML).
- Object relationships are established and adhered to based on the object model
diagrams.
- COM allows objects and functions to be shared at the binary level.
- Object models can be modified through the object diagram to introduce
enhancements or new requirements within the object classes without
additional application programming.
- Standards for developing object models and functions are established through
commonly used development environments (Visio, Rational Rose, VB, VBA,
C++, etc.)
- Object models with all of the required relationships and data validation
domains are created with a design tool and are established when the database
is created.
- Design flaws in the model are captured and can be corrected within the
modeling tool.
