rbeck@cive.ri.cmu.edu (Robert Beck) (04/10/90)
I am working on a system for integrating image data from ground penetrating radar with other sensor data from a hazardous materials environment . (e.g. - chemical concentration, temperature, height ). So far I have investigated both Relational and Object Oriented DataBases for a solution to this problem. The best solution I have found is Empress - a Relational system with a BULK datatype that can be used for any format binary data. It's SQL can be extended to include your own C functions for application specific operations. Does anybody know of other systems that might be better ? What about opinions on the Relational versus Object Oriented debate for Image DBS ? Thank you. Bob Beck (rbeck@ri.cmu.edu)
jkrueger@dgis.dtic.dla.mil (Jon) (04/12/90)
rbeck@cive.ri.cmu.edu (Robert Beck) writes: >I am working on a system for integrating image data from ground penetrating >radar with other sensor data from a hazardous materials environment . (e.g. - >chemical concentration, temperature, height ). So far I have investigated >both Relational and Object Oriented DataBases for a solution to this problem. >The best solution I have found is Empress - a Relational system with a BULK >datatype that can be used for any format binary data. It's SQL can be extended >to include your own C functions for application specific operations. >Does anybody know of other systems that might be better ? What about >opinions on the Relational versus Object Oriented debate for Image DBS ? Empress is currently the only RDBMS (to my knowledge) which lets users add their own functions to the query language. This is impressive, useful, laudable, but it is not support for user defined ADT's. The vendor supplied data types can still do things that the user's can not, such as index. Since performance is a valid concern of database applications, and since data types with bit intensive representations tend to polarize variations in performance, this issue ranges from important to critical. For example, consider four queries (that I hope are meaningful for your application): /* find thermally hot sites */ select s_date, site, kelvin_to_fahrenheit(temperature) from table where temperature > fahrenheit_to_kelvin(100) This query uses two convenient if terminally verbose functions that demonstrate why you might want to extend query languages. But it does not create a new type, just extends the integer type with conversion functions. Thus if the query language interpreter is simply smart enough to evaluate fahrenheit_to_kelvin(100) once "outside the loop", the query can make use of an index on temperature. /* find last January's readings */ select s_date, site, radar_image from table where s_date >= date("1/1/89") and s_date < date("2/1/89") This query uses a function supplied by most vendors to implement a date ADT. Clearly without such functions queries would be unmanageble, e.g. qualifications like s_date > 662080000 to express seconds since 1/1/70. But unlike the first example, this query both selects on an ADT and also on a function related to its implementation. However, as in the first example, the query can use an index on s_date. /* find bad-looking sites at high altitudes */ select s_date, site, height, radar_image from table where height > 1000 and gradient(radar_image) >= 0.5 This query selects on both a vendor supplied data type and a user defined data type. Clearly, it can make use of an index on height. So even if you can't index on radar_image, the query optimizer can select on height and only evaluate gradient() for the rows selected by height > 1000. But you can see where I'm heading, right? /* find bad-looking sites */ select s_date, site, height, radar_image from table where gradient(radar_image) >= 0.5 Uh, oh. Exhaustive scan of table, exhaustive fetch of image from each row, exhaustive evaluation of expensive function on each image. The bad news is that currently there are no commercially available RDBMSs that allow user defined ADTs as first class citizens, to my knowledge. The good news is that there will be. For your needs, this seems a necessary and sufficient software base to be productive developing useful, robust applications. There may still be advantages to using object oriented approaches, however. On the other hand, you can start from either approach and end up wanting features of the other. The good news is that vendor supplied tools are converging in this very way. -- Jon -- Jonathan Krueger jkrueger@dtic.dla.mil uunet!dgis!jkrueger Drop in next time you're in the tri-planet area!