lotus

previous page: 9.3) Odapter/OpenODB: Ordering Information
  
page up: Object-Oriented Technology FAQ
  
next page: 9.3) Phyla (Commercial Systems - OO Data Model - Object-oriented Databases And Vendors)

9.3) OOFILE (A.D. Software) (Commercial Systems - OO Data Model - Object-oriented Databases And Vendors)




Description

This article is from the Object-Oriented Technology FAQ, by Bob Hathaway rjh@geodesic.com with numerous contributions by others.

9.3) OOFILE (A.D. Software) (Commercial Systems - OO Data Model - Object-oriented Databases And Vendors)

WHAT IS OOFILE?
OOFILE is a c++ framework. It can be used as a "traditional" ODBMS or can be
used to access a more traditional RDBMS or record-oriented database. The
current release is implemented with a Faircom c-tree Plus ISAM backend
on Mac and MS Windows. There would be very little difficulty in porting
this to any platform supported by Faircom, and we already have over 8
OS/compiler combinations in use (including 3 in-house).

Design Goals
- everything is native C++ with no (database) preprocessor required

- external interfaces to enable calling from Hypercard, Smalltalk etc.

- keep syntax very simple, familiar to 4GL users and not needing c++ gurus

- safe syntax that makes it hard to do the wrong thing by mistake, making
maximum use of c++ compiler type-checking

- implement with a choice of database engines for the backend

- integrate with a range of common application frameworks

- provide additional classes for managing gui interfaces to help construct
typical database applications, where features are not commonly part of
application frameworks

- use a widely available level of c++ (no RTTI, templates or exception handling)

WHO IS OUR MARKET
1) c++ developers (or wannabees) wanting an embedded database for writing
applications, probably working in combination with an application framework
such as zApp, OWL or PowerPlant.

2) World Wide Web developers seeking a database and report-writer
combination to create web pages in response to queries, searching hundreds
of thousands of records (at least).

BASIC PHILOSOPHY
Object-oriented design is mainly about classes, not individual objects.

OOFILE is similar. Most of the time you model your data in terms of
classes. You do NOT declare individual objects (unlike the ODMG model).

Consider a database from the user's view. They generally see collections of
data and edit or interact with individual records from the collection. The
user doesn't care about individual object identity, they don't create
symbolic names for particular objects. These things may be important inside
the database, but do not need to be exposed.

SOME SIMPLE EXAMPLES
Note: for more examples, including online queries, look on
http://www.highway1.com.au/adsoftware/oofile.html

Before venturing into database definitions, let's consider some
operations on a database containing People, Job Histories and Companies.

// print my address
cout << People["Andy Dent"].Address;

// get a separate list (iterator) of people who worked for software companies
dbPeople softP( People.PrevJobs->Company->MainBusiness()=="Software" );

// for the current softP record (ie person), print the number of large companies
// where they've worked, and the current company size
cout << softP.Name() << "\t"
<< (softP.PrevJobs->Company->NumEmployees() > 100).count()
<< "\t"
<< softP.CurrentJob->Company->NumEmployees() << endl;

NOTE:
The () at the end of fields, as shown above, are optional for all cases except
fields in relational expressions, eg: People.CurrentJob->StartDate().

DECLARING SIMPLE TABLES
To define a table with a few fields, the simplest declaration would be:
CLASS_TABLE(dbPeople)
dbChar Name, Address;
dbInt Salary;
};

This defaults the size of the dbChar fields to 80 chars. To specify the
size of the fields, and/or control indexing options, you need to add a
constructor:
CLASS_TABLE(dbPeople)
dbChar Name, Address;
dbInt Salary;

dbPeople : Name(40, "Name", kIndexNoDups),
Address(255, "Address"),
Salary("Salary", kIndexed)
{};
};

Note that the constructors also specify the field name strings. These
are optional, but are of great benefit when writing query and
report-writer logic or when constructing a database schema that should
be readable by others.

SOME OTHER FEATURES
- Derived fields, either specified as a combination of existing fields or
user-calculated

- User-defined relations

- keyword indexing

- phonetic indexing

- inbuilt report-writer

RELATIONS
One of the big features of an ODBMS is modelling the relationships between
objects. OOFILE allows you to model relations in a pure ODBMS sense, using
object identifiers, or explicitly perform runtime joins over database fields.
This would be mainly used by people porting existing database structures. There
are a number of syntaxes available to establish relationships, eg:

   dbConnect_ctree theDB;    // the physical database
   dbAcademics Academics;    // a couple of tables
   dbStudents  Students;
  
   dbRelation Supervision("Supervision");  // a concrete relation
  
   Supervision.Names("Supervises",        "is Supervised by")
              .Tables(Academics,           Students)
              .Links(Academics.Supervises, Students.Boss)
              .JoinField(Academics.StaffNo, Students.SupervisorNo);

APPLICATION FRAMEWORKS AND OOFILE
GUI Integration classes are under development for zApp & PowerPlant with more
frameworks to follow. A "non-intrusive" approach has been taken of providing
helper classes and instructions that let you incorporate OOFILE use into an
existing program.

These helper classes include subclasses of the native edit fields, that
store data directly into the database. Depending on your framework,
other classes are added for displaying lists of records, managing
multiple page input forms and similar business application functions.

For Macintosh users, the popular AppMaker code generator is being enhanced
to generate OOFILE applications. You will be able to go from drawing your
interface to a complete working database application, without writing code.
The next AppMaker and CodeWarrior CD's will contain more information and
samples.

STATUS
The current c-tree implementation is solid and the inbuilt test data generator
has been used to create databases of up to 200Mb in various configurations. The
largest beta tester is operating a 270Mb+ database on a Sparc Classic.
(500,000+ IP-flow objects as of mid July).

Product release, including (at least) zApp and PowerPlant integrations is
anticipated for September

TEST PLATFORMS in-house
c-tree+ v6.4B

Mac
- Symantec c++ v7.0.4
- CodeWarrior 6.1

MS Windows
- Borland c++ v4.5p3

SunOS 4.3
- g++ v2.6.3

CONTACT
Andy Dent
A.D. Software
94 Bermuda Drive
Ballajura, Western Australia 6066
Phone/Fax +61-9-249-2719
eWorld: DentA
CompuServe: 100033,3241
Internet: dent@highway1.com.au
ftp://ftp.highway1.com.au/pub/adsoftware/
http://www.highway1.com.au/adsoftware/

MAINTENANCE
Priority fixes/consulting rate (drop-everything mode) $60/hour

Patches to each version - free.

Major upgrades - 30% per seat.
or
Annual Maintenance, regardless of number of upgrades - 40% per seat

UPGRADES
Upgrading between database and report-writer options is at the cost difference.

Changing from one GUI to another is 50%. If you decide to later reactive the
original, it's also at 50% (ie: net result same as buying the 2nd GUI outright).

Note: if later GUI kits are at different prices, exchange rules will vary
to suit.

SITE LICENSING
(Excluding bundled c-tree)
by negotiation for large sites.
or
40% off 2nd and subsequent copies

Andy Dent, Product Architect, A.D. Software, Western Australia
OOFILE - "the cross-platform OODBMS that speaks c++"
ftp://ftp.highway1.com.au/pub/adsoftware/
http://www.highway1.com.au/adsoftware/

 

Continue to:













TOP
previous page: 9.3) Odapter/OpenODB: Ordering Information
  
page up: Object-Oriented Technology FAQ
  
next page: 9.3) Phyla (Commercial Systems - OO Data Model - Object-oriented Databases And Vendors)