Re: OODB question?

From: akmal b chaudhri <akmal_chaudhri_at_my-deja.com>
Date: 2000/04/01
Message-ID: <8c5pil$cb8$1_at_nnrp1.deja.com>


In article <38E63768.D29B8808_at_cs.cityu.edu.hk>, Dora <swsleung_at_cs.cityu.edu.hk> wrote:
>
>
> akmal wrote:
>
> > On Sat, 1 Apr 2000, Dora wrote:
> >

[snip]

> > Hi Dora!
> >
> > Not sure what you mean. You need to create the schema and load into
 UniSQL
> > before you create classes anyway. The schema file may have extended
 SQL
> > statements, thus:
> >
> > CREATE CLASS part
> > ;
> > CREATE CLASS conn
> > ;
> > ALTER CLASS part ADD ATTRIBUTE
> > id integer,
> > part_type char(11),
> > x integer,
> > y integer,
> > build integer,
> > connected_to set(conn),
> > connected_from set(conn)
> > ;
> > ALTER CLASS conn ADD ATTRIBUTE
> > from_part part,
> > to_part part,
> > conn_type char(11),
> > length integer
> > ;
> >
> > COMMIT WORK;
> >
> > UniSQL comes with some tools that will allow you to dump out the
 database
> > - check the manuals. The format may be something like this when
> > written-out:
> >
> > %id glo_name 6
> > %id glo_holder 7
> > %id glo 8
> > %id part 9
> > %id conn 10
> > %id audio 11
> > %id slcaudio 12
> > %id agent 13
> > %id audio_agent 14
> > %id image 15
> > %id twod_image 16
> > %id threed_image 17
> > %id pbm 18
> > %id rawpbm 19
> > %id x11bitmap 20
> > %class part (build y x id part_type connected_from connected_to)
> > 1: 436436119 43359 61358 1 'part-type4 ' {_at_10|1} {_at_10|2,
> > _at_10|3,
> > _at_10|4}
> > 2: 578654140 18509 70911 2 'part-type5 ' {_at_10|5} {_at_10|6,
> > _at_10|7,
> > _at_10|8}
> > ...
> > ...
> > ...
> > etc.
> >
> > If you have a complex schema, the utility will still write it out
 to a
> > text file, but then it is your responsibility to "munge" the data
 into a
> > suitable format for loading into something else.
> >
> > HTH
> >
> > akmal
>
> Hi akmal,
>
> Thanks for your help!
>
> I'm a new learner of UniSQL.
>
> I have create the schema and create some tables in the UniSQL
 database. My
> problem is that my supervisor ask me to
> convert the UniSQL database into the Informix database by using
 Visual Basic as
> the translator. That is a question. I don't know how to change a OODB
 into a
> Relational DB. Therefore, I think I need to get the UniSQL schema and
 transform
> it into Informix schema. Also I need to download all data in the
 UniSQL and
> upload to the new Informix database. But, the most difficult part is
 I need to
> transform UniSQL methods into Informix stored procedure. All these
 processes
> must do in the VB translator.
>
> Therefore, I just want to know how to get the schema from the UniSQL
> without using other tools support?
> Also, how to download data in the UniSQL database? Do I need to write
 a
> method or a program to download/copy data from the UniSQL?

Dora:

I don't want to interfere with your supervisor, but I would suggest you take it one step at a time. So, you could:

  1. Check the UniSQL schema first. See what the relationships between classes are. Remember that UniSQL may be an ORDB, but still uses tables underneath. It does offer extensions to SQL. Once you have the schema, you should be able to remodel it for Informix. It's been a long time since I looked at UniSQL, but I recall that there are some tools available that should help you (in other words, you should be able to find what tables there are and the relationships between them).
  2. You can decide what behaviour to capture using Stored Procedures (as you mention above).
  3. The data can be dumped out into ASCII files using the UniSQL database unload utility. The format is something similar to what I posted earlier. Obviously your data will be different. Using the unload utility is the safest and fastest way to do dump. I had many problems trying to load/unload using just C++ when I used the product about 3-4 years ago. Once the data are saved, you just need to write your VB programs to reformat into input files for Informix. Much of the code will be just checking for fields, field separators, etc. Depending upon how complex your original schema is, you may have to spend quite a bit of time on checking that relationships are correctly captured. In UniSQL, as in some other ORDBs, you can use references (pointers) between rows of different tables. The dump utility also writes out these references. For example, using the partial dump above:

...
%id part 9
%id conn 10
...
%class part (build y x id part_type connected_from connected_to) 1: 436436119 43359 61358 1 'part-type4 ' {_at_10|1} {_at_10|2, _at_10|3,
_at_10|4}
2: 578654140 18509 70911 2 'part-type5 ' {_at_10|5} {_at_10|6, _at_10|7,
_at_10|8}
...
...

what this says is that I have a class part (id 9) with the fields: build, y, x, id, part_type, connected_from and connected_to. The next line marked "1:" (a unique instance identifier for this class in this dump) then gives me instance values:

build = 436436119
y = 43359
x = 61358
id = 1
part_type = 'part-type4 '
connected_from = {_at_10|1}
connected_to = {_at_10|2, @10|3, @10|4}

The {} indicates a set. So connected_to has three set elements and the references are to the class with id 10 (_at_10) and instance numbers 2, 3 and 4 - these are forward references and would be defined further in the file where data for class with id 10 appears. If inverse relationships are used, the class with id 10 will have similar references back to class with id 9 and you may get something with {_at_9|1} for example (with the @9 meaning class with id 9 and the 1 referring to the "1:" mentioned a couple of paragraphs above). A complete example would help, but I cannot access my system files at the moment. However, the UniSQL manuals should cover this in detail. Although I did find a number of bugs in some of the example code, overall, the manuals were not so bad I think. At least the sections on data loading/unloading were fairly clear.

I'm sure there are other wasy to tackle this, but IMHO, I would use the data loading/unloading utilities first, then write code to manipulate the database dump into another format.

HTH akmal

--
[ -- akmal_chaudhri at bigfoot dot com -- ]
[ http://www.bigfoot.com/~akmal_chaudhri/ ]


Sent via Deja.com http://www.deja.com/
Before you buy.
Received on Sat Apr 01 2000 - 00:00:00 CEST

Original text of this message