Message-ID: <6143@unisql.UUCP> Date: 10 Sep 93 14:26:04 GMT References: <CD1Ln5.9G3@dcs.glasgow.ac.uk> Organization: UniSQL, Inc., Austin, Texas, USA >>... For UniSQL/X, feel free to contact me (email, snail-mail or phone). UniSQL/X is a SQL compliant database with Object Oriented extensions (classes, inheritance, methods, etc). We have an information packet available which includes a white-paper on our OORDMS approach. Jon Higby Technical Services Consultant UniSQL, Inc. 9390 Research II, Suite 200 Austin, Texas 78759-6544 (512) 343-7297 ***************************************************************************** Standard disclaimer ... All opinions expressed are my own and not of my employer....................................... ***************************************************************************** > Versant (Versant Object Technology) Versant is a client/server object database management system (ODBMS) targeted at distributed, multi-user applications. Versant runs on UNIX and PC platforms, including Sun, IBM, HP, DEC, SGI, Sequent, OS/2, with support for Windows NT is planned during 1993. Versant provides transparent language interfaces from object-oriented programming languages such as C++ and Smalltalk. Versant also supports a C API. Versant is built with an object-level architecture, which means that operations are generally performed on the object (or group thereof) level. Key Versant features include: Performance ----------- * Object-level locking for fine granularity concurrency control * Server-based query processing to reduce network I/O * Dual caching to speed warm traversals * Dynamic space reclamation and reuse Distribution ------------ * Immutable, logical object identifiers for data integrity * Object migration (transparent relocation across nodes) * Transparent cross-node references (distributed db) * Automatic two-phase commit Other ----- * Schema evolution (online via lazy updates) * Standard workgroup features (e.g., versioning, checkin/out) * Detachable, personal databases * DBA utilities Additional information available from info@versant.com (General information) davek@versant.com (Dave Kellogg) Versant Object Technology 1380 Willow Road Menlo Park, California 94025 415-329-7500 phone. 415-325-2380 fax. On Schema Evolution (from original survey): We support run-time schema evolution. It uses a lazy scheme, so schema operations are very fast. Objects on disk may have an older `storage class' and they will be updated to the new schema when they are used. In older releases schema evolution was allowed only on leaf classes (those with no subclasses). In our new release 2 (going to beta test soon) you can do schema evolution on any class. In the future we're working on more general view mechanisms so you can see a subset of the attributes in memory, or some more complicated transformation. This goes together with support for multiple compilers and multiple languages. [Joe Keane <osc!jgk@amd.com>] Also: 1-800-Versant Other Models ------------ Research Systems ________________ > GRAS -------------------------------------------------------------- GRAS - A Graph-Oriented Database System for SE Applications Copyright (C) 1987-1993 Lehrstuhl Informatik III, RWTH Aachen -------------------------------------------------------------- See the GNU Library General Public License for copyright details. Contact Adresses: Dr. Andy Schuerr Lehrstuhl fuer Informatik III, University of Technology Aachen (RWTH Aachen), Ahornstr. 55, D-5100 Aachen Email to andy@i3.informatik.rwth-aachen.de GRAS is a database system which has been designed according to the requirements resulting from software engineering applications. Software development environments are composed of tools which operate on complex, highly structured data. In order to model such data in a natural way, we have selected attributed graphs as GRAS' underlying data model. A first prototype of the GRAS (GRAph Storage) system - described in /BL 85/ - was already realized in 1985. Since this time gradually improving versions of the system have been used at different sites within the software engineering projects IPSEN /Na 90/, Rigi /MK 88/, MERLIN /DG 90/, and CADDY /EHH 89/. Based on these experiences, almost all parts of the original prototype have been redesigned and reimplemented. Thus, nowadays a stable and efficiently working single-process version of the system GRAS with interfaces for the programming languages Modula-2 and C is available as free software for Sun workstations (the GRAS system itself is implemented in Modula-2 and consists of many layers which might be reusable for the implementation of other systems): Via anonymous ftp from ftp.informatik.rwth-aachen.de in directory /pub/unix/GRAS in file gras.<version-no>.tar.Z. There are several files containing documentation, sources, binaries, application examples, and libraries. All binaries are for Sun/4 machines. Sun/3 binaries are shipped only if explicitly requested. You have to use the following sequence of operations for installing the GRAS system at your site: 1) 'ftp ftp.informatik.rwth-aachen.de' (with login name "anonymous" and password equal to your mail address). 2) 'cd pub/unix/GRAS' (for changing the current directory). 3) 'binary' (command for changing ftp mode). 4) 'get gras.<version-no.>' (use 'ls' for finding the currently used GRAS version nr.). 5) 'bye' (for exiting ftp). 6) 'uncompress gras.<version-no>.tar'. 7) 'tar xvf gras.<version-no>.tar' (creates a subdirectory GRAS_2 for the Modula-2 implementation of GRAS including its C-interface). 8) Follow the instructions in file GRAS_2/README. The current version has programming interfaces for Modula-2 and C and supports: - the manipulation of persistent attributed, directed node- and edge-labeled graphs (including the creation of very long attributes and of attribute indexes). - the manipulation of temporary/volatile generic sets/relations/lists, - the coordination of graph accesses by different GRAS applications (multiple-read/single-write access with graphs as lock units), - error recovery based on shadow pages and forward logs, - nested transactions and linear undo/redo of arbitrarily long sequences of already committed graph modifying operations based on forward and backward logs, - event-handling (with certain kinds of graph-modifications as events and graph-modifying transactions as event-handlers), - primitives for version control comprising the capability for efficiently storing graphs as forward/backward deltas to other graphs, - and primitives for declaring graph schemes and for incremental evaluation of derived attributes. Furthermore, tools for (un-)compressing graphs and a X11R5-based graph browser are part of this release. A multi-process version of the system GRAS supporting the inter- action of multiple client and multiple server processes within one local area network is nearby completion (version 6.0/0). Thus, the GRAS system may be considered to be the core of a graph oriented DBMS environment. The development of such an environment based on a very high-level specifications language named PROGRES is under way (the underlying calculus of this specifcation language are so-called PROgrammed GRaph REwriting Systems). This environment will comprise the following tools (a prerelease of this environment might be made available upon request): - a syntax-directed editor for graph schemes, graph rewrite rules, and sequences of graph rewrite rules, - an incrementally working consistency checker, - an incrementally working compiler&interpreter translating PROGRES specifications into sequences of GRAS procedure calls (for C as well as for Modula-2), - and an "enhanced" graph (scheme) browser. References ---------- Refer to the following publications for further info about GRAS, PROGRES, and related topics: /BL85/ Brandes, Lewerentz: A Non-Standard Data Base System within a Software Development Environment. In Proc. of the Workshop on Software Engineering Environments for Programming-in-the- Large, pp 113-121, Cape Cod, June 1985 /DHKPRS90/ Dewal, Hormann, Kelter, Platz, Roschewski, Schoepe: Evaluation of Object Management Systems. Memorandum 44, University Dortmund, March 1990 /Feye92/ Feye A.: Compilation of Path Expressions (in German), Diploma Thesis, RWTH Aachen (1992) /Hoefer92/ Hoefer F.: Incremental Attribute Evaluation for Graphs (in German), Diploma Thesis, RWTH Aachen (1992) /HPRS90/ Hormann, Platz, Roschweski, Schoepe: The Hypermodel Benchmark, Description, Execution and Results. Memorandum 53, University Dortmund, September 1990 /KSW92/ * Kiesel, Schuerr, Westfechtel: GRAS, A Graph-Oriented Database System for (Software) Engineering Applications. Proc. CASE 93, Lee, Reid, Jarzabek (eds.): Proc. CASE '93, 6th Int. Conf. on Computer-Aided Software Engineering, IEEE Computer Society Press (1993), pp 272-286 Also: Technical Report AIB 92-44, /Klein92/ Klein P.: The PROGRES Graph Code Machine (in German), Diploma Thesis, RWTH Aachen (1992) /Kossing92/ Kossing P.: Modelling of Abstract Syntax Graphs for normalized EBNFs (in German), Diploma Thesis, RWTH Aachen (1992) /LS88/ Lewerentz, Schuerr: GRAS, a Management System for Graph- Like Documents. In Proceedings of the Third International Conference on Data and Knowledge Bases, Morgan Kaufmann Publ. Inc. (1988), pp 19-31 /Nagl89/ Nagl (ed.): Proc. WG'89 Workshop on Graphtheoretic Concepts in Computer Science, LNCS 411, Springer-Verlag (1989) /NS91/ Nagl, Schuerr: A Specification Environment for Graph Grammars, in Proc. 4th Int. Workshop on Graph-Grammars and Their Application to Computer Science, LNCS 532, Springer- Verlag 1991, pp 599-609 /Schuerr89/ Schuerr: Introduction to PROGRES, an Attribute Graph Grammar Based Specification Language, in: /Nagl89/, pp 151-165 /Schuerr91a/ * Schuerr: PROGRES: A VHL-Language Based on Graph Grammars, in Proc. 4th Int. Workshop on Graph-Grammars and Their Application to Computer Science, LNCS 532, Springer- Verlag 1991, pp 641-659 Also: Technical Report AIB 90-16 /Schuerr91b/ Schuerr: Operational Specifications with Programmed Graph Rewriting Systems: Theory, Tools, and Applications, Dissertation, Deutscher Universitaetsverlag (1991) (in German) /SZ91/ * Schuerr, Zuendorf: Nondeterministic Control Structures for Graph Rewriting Systems, in Proc. WG'91 Workshop in Graph- theoretic Concepts in Computer Science, LNCS 570, Springer- Verlag 1992, pp 48-62 Also: Technical Report AIB 91-17 /Westfe89/ Westfechtel: Extension of a Graph Storage for Software Documents with Primitives for Undo/Redo and Revision Control. Technical Report AIB Nr. 89-8, Aachen University of Technology, 1989 /Westfe91/ Westfechtel: Revisionskontrolle in einer integrierten Soft- wareentwicklungsumgebung, Dissertation, RWTH Aachen, 1991 /Zuendorf89/ Zuendorf: Kontrollstrukturen fuer die Spezifikationssprache PROGRES, Diplomarbeit, RWTH Aachen, 1989 /Zuendorf92/ * Zuendorf A.: Implementation of the Imperative/Rule Based Language PROGRES, Technical Report AIB 92-38, RWTH Aachen, Germany (1992) /Zuendorf93/ * Zuendorf A.: A Heuristic Solution for the (Sub-) Graph Isomorphism Problem in Executing PROGRES, Technical Report AIB 93-5, RWTH Aachen, Germany (1993) * : All reports marked with an asterisk are available via anonymous ftp from ftp.informatik.rwth-aachen.de in directory /pub/reports/... . See also PROGRES documentation. [See also APPENDIX E] > IRIS (HP Labs) [Iris is a system out of HP Labs that began as a prototype and eventually became a commercial product. I believe it was eventually incorporated into the new HP product, OpenODB. - clamen] Long and short system summaries can be found in: [FISH89] D.H. Fishman et. al. Overview of the Iris DBMS. In Won. Kim and Frederick H. Lochovsky, editors, Object-Oriented Concepts, Databases and Applications, chapter 10, pages 219--250. Addison-Wesley, Reading, MA, 1989. [FBC+87] D.H. Fishman, D. Beech, H.P. Cate, E.C. Chow, T. Connors, J.W. Davis, N. Derrett, C.G. Hock, W. Kent, P. Lyngbaek, B. Mahbod, M.A. Neimat, T.A. Tyan, and M.C. Shan. Iris: An object-oriented database management system. ACM Transactions on Office Information Systems, 5(1):48--69, January 1987. The abstract of the latter (written early in the project) follows: The Iris database management system is a research prototype of a next-generation database management system intended to meet the needs of new and emerging database applications, including office automation and knowledge-based systems, engineering test and measurement, and hardware and software design. Iris is exploring a rich set of new database capabilities required by these applications, including rich data-modeling constructs, direct database support for inference, novel and extensible data types, for example to support graphic images, voice, text, vectors, and matrices, support for long transactions spanning minutes to many days, and multiple versions of data. These capabilities are, in addition to the usual support for permanence of data, controlled sharing, backup and recovery. The Iris DBMS consists of (1) a query processor that implements the Iris object-oriented data model, (2) a Relational Storage Subsystem (RSS) -like storage manager that provides access paths and concurrency control, backup and recovery, and (3) a collection of programmatic and interactive interfaces. The data model supports high-level structural abstractions, such as classification, generalization, and aggregation, as well as behavioral abstractions. The interfaces to Iris include an object-oriented extension to SQL. On Schema Evolution (from original survey): Objects in the Iris system may acquire or lose types dynamically. Thus, if an object no longer matches a changed definition, the user can choose to remove the type from the object instead of modifying the object to match the type. In general, Iris tends to restrict class modifications so that object modifications are not necessary. For example, a class cannot be removed unless it has no instances and new supertype-subtype relationships cannot be established. Commercial Systems __________________ > IDL (Persistent Data Systems) IDL is a schema definition language. Schema modifications are defined in IDL, requiring ad-hoc offline transformations of the database, in general. A simple class of transformations can be handled by IDL->ASCII and ASCII->IDL translators (i.e., integer format changes, list->array, attribute addition). [conversation with Ellen Borison of Persistent Data Systems] ADDITIONAL REFERENCES: John R. Nestor. "IDL: The Language and Its Implementation". Prentice Hall. Englewood Cliffs, NJ., 1989. > Kala Kala Technical Brief Summary Kala(tm) is a Persistent Data Server managing distributed, shared, arbitrarily complex and evolving persistent data. Kala is highly efficient and secure. Kala manages the visibility of persistent data elements to its clients, thus supporting any types of transactions, versions, access control, security, configurations. Kala does not restrict you to any particular model. Kala provides the mechanism, but imposes no policy. Usable as either a link library communicating to a server or as a standalone, Kala is compact and simple. Kala is used for applications such as: kernel of DBMS products, substrate for extended file systems, implementation of language persistence, data manager for groupware applications as well as applications which deal with large, complex, and changing volumes of data (text databases, financial distributed transaction systems). Our current customers use Kala in applications ranging from CASE repositories to CAD systems, from document management for financial institutions to OODBMS platforms, from real-time applications to database research. Kala is a component of broad reuse. Motivation The simplest persistent data storage available to you is the file system on your disk drive. File systems have some attractive characteristics; their performance is good, they can hold any data, they're easy to use, and, of course, the price is right. Conversely, files are unreliable. They provide no mechanism for in maintaining data consistency and only primitive data sharing facilities. Few file systems offer version control and all require that you transform data between "internal" and "external" forms all the time. Unlike a file system, a true database management system provides mechanisms for sharing data and for ensuring the integrity of the data. It supports transactions and version control, although the specifics of these functions may not be exactly what your application needs. Finally, a database system is scalable, and much more robust than a file when your hardware or software fails. The downside to a database system is that, compared to a file system, it is slower by an order of magnitude or more. Also, a database system generally confines you to dealing only with the kind of data that it can handle. In addition, a database is usually very complicated, difficult to learn and use, and expensive, both in terms of your cost of operation and in the amount of system resources they consume. Whether you choose a file system or a database manager, then, you have to sacrifice either economy or performance. Is there a happy medium? Something with the speed and flexibility of files, the reliability, shareability and robustness of databases, and at a cost that won't break your wallet or the available hardware? Sure there is! Kala is a first in a new breed of products, persistent data servers, aimed squarely at the yawning gap between DBMSs and file systems. Overview Kala is *not* a DBMS. Instead, you use Kala whenever the few canned combinations of DBMS features do not meet the needs of your application. A DBMS product constrains you to accept *its* choice of an end-user graphical interface, a query language binding, a specific high level data or object model, a particular transaction model, a single versioning scheme, etc. This either compromises your application's functionality, or forces your to spend substantial development effort and money to bridge the impedance mismatch to the application. Instead, Kala allows *you* to develop no more and no less than the functionality you need. You build your domain specific functionality our of a small set of primitives with very little code. Your gains in productivity, efficiency, and flexibility are substantial. To sustain this level of flexibility and reuse, Kala manages any data that you can represent in machine memory out of bits and references. Examples include records, dynamically linked graphs and lists, executable code, and object encapsulations. Kala can handle data as small as one bit, and as large as the virtual memory and more, while being totally unaware of the data's semantics. Its stores and retrieves data efficiently, and compactly over a distributed and dynamically reconfigurable set of Stores. Upon retrieval, Kala dynamically relocates embedded references to retain the original topological structure of the data, thus preserving referential integrity. Kala also supports active data, physical store management, and automatic archiving. Kala repackages the fundamentals and universals of data management in one reusable data server, separating them from the application domain specific models and policies. Kala defines a low level interoperabi- lity point for the data storage domain, just as X does for the display domain and Postscript does for the printing domain. Kala has matured through four successive versions to its present industrial strength implementation and stable API. Kala is lean, compact, and portable. Kala is a high performance, low overhead system. We call it a Reduced Instruction Set Engine (RISE). Unlike large, complex, and typically bulky DBMS products, Kala is small, simple, and suitable for managing anywhere from a single diskette to terabytes of distributed data. Benefits * For those who need functionality traditionally associated with databases, but cannot tolerate the overhead and complications DBMS products introduce, Kala offers a flexible, compact, performant, elegant, and simple alternative. * For those whose application domain requires data models where the mapping to those offered by today's DBMS products is cumbersome, introduces development and execution overhead, and is not portable across multiple linguistic and environmental platforms, Kala offers a data model independent interface against any data model expressible in terms of bits and pointers can be easily built. * For those who need DBMS functionality or qualities that no single DBMS product now has, Kala offers the opportunity to build that functionality now with little effort out of a simple set of primitives, and not wait for one vendor or another to deliver it later. * For those who have determined that the only viable option for their application's persistent data needs is the file system, and have resined to the idea that they will have to build everything else they need from scratch, Kala offers an off-the-shelf implementation without loss of any of files' advantages. * For those who need performance, size, portability, storage compactness, and industrial strength that no single DBMS product can now satisfy, Kala offers all of the above now. * For those who realize that while object-level interoperability is a strong desideratum, the likelihood of a single, universal such model in the foreseeable future is quite low, Kala offers a solid, long term alternative. Data store interoperability that brings us beyond file systems is the best practical bet. Kala is the basis for data store interoperability now. * Finally, for all of you who are concerned about the economics of software, and take the view that there are many elements that could contribute negatively to the soundness of your business, such as operational costs, software maintenance costs, software licensing costs, software development and learning costs, etc., you will find Kala an economically sound, sensible, and practical product. Features - The execution architecture is that of multiple (communicating) servers and multiple clients. Kala can also be configured in a standalone (single process) mode. Kala's IPC is built for maximum performance, portable to any given datagram protocol. - The managed data elements are made out of uninterpreted bits and references. Data elements (named `monads') are universally uniquely identified. Bits are stored with no overhead. References, represented in memory as native machine pointers, are stored very compactly, introducing an average of 2.5 bytes overhead. - Kala is a fully recoverable system, short of media damage. Recovery from hardware failures can be supported by the layer beneath Kala. - The Kala primitives support arbitrary transaction models, including classic short transactions, long (persistent) transactions, nested transactions, shared transactions, pessimistic and optimistic policies, etc. Concurrency control is achieved through two locking mechanisms (short-term and long-term (persistent, shared) locking), with full support for atomicity of operations and two-phase commit. - The Kala primitives support arbitrary versioning models, allowing versions to co-exist in split/rejoined networks, various version organization strategies (single-thread, tree, DAG, etc.). Kala primitives provide mechanisms for arbitrary access and update triggers, such as notifications, security checks upon access/update, etc. __ with no limitations on what the trigger code does. Kala provides protection measures against virus and other intruding executions. - The Kala primitives support a wide range of access control, security and protection models, including revocable access rights, access control without the overhead of ACL management, arbitrary access validation routines, etc. Kala does not introduce any more security holes than the operating environment already has. - Kala has primitives for physical store allocation and de-allocation management, for a wide spectrum of store administrative tasks, as well as licensing administration. The latter includes application- sensitive time-limited client-connect-based licensing, as well as metered (connect/load/store) usage. Kala can be set up to do automatic archiving and backup of its physical store. - Kala provides a wide spectrum of licensing schemes, usable by platforms and applications built upon Kala to their customer base. Kala provides renewable licenses, perpetual licenses, full protection against duplication without hardware (hostid) support, metered (pay-by-use) usage, etc. - And more ... not fitting on this page-long Technical Brief. Availability o Kala is available now on Sun platforms (SunOS / 68K & SPARC), as well as on 80x86/MS-DOS (both Microsoft and Borland compilers & runtimes supported) platforms. If you are interested in a port to your favorite platform, call us to discuss our Development and Porting Partnership Programme. o Kala's interface is ANSI C, also callable from C++. If you are interested in an interface or a binding to your favorite programming language, please call us to discuss out Development Partnership Programme. o For pricing and other information, please contact us by phone, fax or via e-mail at Info@Kala.com _ _ ____ _ ____ tm ____________________________________ \\ / | \ \ | \ \\\\ \\ /__ \ __ \ \ \ __ \ \\\\ \\ \ \ \ \ \ \ \\\\ \\ \ \ \ \ \ \ \\\\ No more than you need !!! \\' \' \' \' '____' \' \' \\\\ No less than you want !!! ........................................................................ Penobscot Development Corporation email: Info@Kala.com One Kendall Square Building 200 Suite 2200 Cambridge MA 02139-1564 USA voice +1-617-267-KALA fax +1-617-859-9597 tech support +1-201-539-7739 ...............(5252) fax +1-617-577-1209............................. +---------------------------------------------------------------+ | Copyright (c) 1992-93, Penobscot Development Corporation. | | Kala is a Trademark of Penobscot Development Corporation. | +---------------------------------------------------------------+ On Schema Evolution (from original survey): Kala manages an untyped persistent store, implementing the semantics of robust, distributed, secure, changing, and shareable persistent data. Layers built upon the Kala platform can implement the semantics of objects with the same properties. As it operates below the schema layer, Kala does not address schema evolution directly. However, It supports the building of schema'ed layers above it and below the application, and those layers can provide for schema evolution conveniently using Kala primitives. This parts-box approach requires extra work on the part of the developer compared to out-of-the-box solutions, but provides power and flexibility sufficient for relatively low cost solutions in difficult environments (e.g. graph-structured data, dynamic classing) where no out-of-the-box solution is available. Contacts: Sergiu Simmel sss@kala.com Ivan Godard ig@kala.com general information info@kala.com subscription to moderated newsletter forum-request@kala.com REFERENCES: Segui S. Simmel and Ivan Godard. "The Kala Basket: A Semantic Primitive Unifying Object Transactions, Access Control, Versions, annd Configurations > Pick With Pick and its variants you only have problems if you want to redefine an existing field. Because of the way the data are stored and the separation of the data and the dictionary you can define additional fields in the dictionary without having to do anything to the data - a facility which we have found very useful in a number of systems. There is no general facility to redefine an existing field - you just make whatever changes are required in the dictionary then write an Info Basic program to change the data. We have seldom needed to do this, but it has not been complicated to do. If a field in the database is no longer used, it is often easiest simply to delete the reference to that field in the dictionary, and accept the storage overhead of the unused data. In such cases, while the data cannot be accessed through the query language, (Pick)Basic programs can still access them. [Geoff Miller <ghm@ccadfa.cc.adfa.oz.au>] Interfaces ---------- Research Systems ________________ > Penguin (Stanford) Penguin is an object-oriented interface to relational databases. Penguin has its own simple language-independent object model with inheritance for composite objects defined as views (called view-objects) of a relational database. These view-objects represent data according to application requirements in such a way that multiple applications can share overlapping, but different, sets of data. Multiple applications may share data by having overlapping schemata with differing composite objects and differing inheritance mappings. We have a C++ binding, which supports multiple inheritance. The result is a framework for collaboration among multiple users, each with differing perspectives about the system and its data. For additional information, please contact ark@db.stanford.edu References: ``A C++ Binding for Penguin: a System for Data Sharing among Heterogeneous Object Models,'' Arthur M. Keller, Catherine Hamon, Foundations on Data Organization (FODO) 93, October 1993, Chicago. ``Querying Heterogeneous Object Views of a Relational Database,'' Tetsuya Takahashi and Arthur M. Keller, Int. Symp. on Next Generation Database Systems and their applications, Fukuoka, Japan, September 1993, to appear. ``Updating Relational Databases through Object-Based Views,'' by Thierry Barsalou, Niki Siambela, Arthur M. Keller, and Gio Wiederhold, ACM SIGMOD, Denver, CO, May 1991. ``Unifying Database and Programming Language Concepts Using the Object Model'' (extended abstract), Arthur M. Keller, Int. Workshop on Object-Oriented Database Systems, IEEE Computer Society, Pacific Grove, CA, September 1986. Commercial Systems __________________ > Persistence PERSISTENCE(TM): BRIDGING THE GAP BETWEEN OBJECT ORIENTED DEVELOPMENT AND RELATIONAL DATA Persistence is an application development tool which provides object oriented access to existing relational data. Persistence uses an automatic code generator to convert object models into C++ classes which know how to read and write themselves to a relational database. Leverage existing data Persistence enables object oriented access to existing relational databases. Applications built with Persistence can work side by side with legacy systems. Automate database access By generating the methods to convert relational data into objects, Persistence saves the developer from having to write literally hundreds of lines of code per class. Speed application development With Persistence, major changes to the application object model can be completed in minutes, not weeks. Quality Persistence generates tested, bug-free code. Using Persistence helps ensure the reliability and reusability of your applications. Performance At Runtime, Persistence manages an object cache to enhance performance while ensuring data integrity. The Persistence object cache can provide a factor of ten performance improvement for data intensive applications. Portability Code generated by Persistence is database independent. You can choose which database to work with at link step, increasing application portability. TECHNICAL SPECIFICATIONS The Persistence Database Interface Generator converts object schemas into C++ classes. Custom Code | v Object schema ---> Persistence ----> Generated Generator Classes ^ | v Persistence Object Cache ^ | v Legacy Data Encapsulation Each class generated by Persistence maps to a table or view in the database. - Query using ANSI SQL or attribute values - Add custom code to generated classes - Preserve custom code when model changes Inheritance Persistence supports inheritance of attributes, methods and relationships. - Propagate superclass queries to subclasses - Use virtual methods for polymorphism Associations Persistence maps associations to foreign keys in the database. Each class has methods to access related classes. - Ensure referential integrity between classes - Specify delete constraints for associations Object Caching The Persistence Runtime Object Management System caches objects during transactions and ensures data integrity. In the object cache, Persistence "swizzles" foreign key attributes into in-memory pointers, speeding object traversal. Transactions When a transaction is committed, Persistence walks through the object cache and writes out changes to the database. Environment Platforms/Operating systems Persistence will support all major Unix and Intel platforms - Sun/SunOS 4.x, Solaris 2.x - HP/HP-UX 8.0, 9.0 - IBM/AIX (planned 11/93) - Intel/NT (planned 3/94) Development Tools Persistence supports all major C++ compilers and integrates with GE's OMTool, allowing developers to go straight from an object model to a running C++ application. - Cfront 2.1: ObjectCenter 1.0, SPARCompiler, ObjectWorks - Cfront 3.0: ObjectCenter 2.0, SPARCompiler, Softbench C++ - GE's OMTool Databases Persistence provides database independence. With our Objectivity integration, we also provide a clear migration path to object databases. - Oracle V6, V7 - Sybase 4.x - Ingres 6.x - Objectivity ODBMS - Informix (planned 9/93) - ODBC (planned 3/94) CUSTOMER QUOTES "We wanted to use object technology while continuing to support our legacy systems. Persistence made this feasible by automating over 30 percent of our development cycle." Steve Hunter, Sterling Software "Persistence cut our development time by approximately 40%, because we would have had to do all the mapping functions ourselves." Jim Adamczyk, Partner, Andersen Consulting "I'm convinced we'll save weeks or months of time because of Persistence." Mike Kubicar, SunSoft Defect Tracking Team "The good thing is that you can change your object model and just re-generate the database interface classes at the press of a button." Richard Browett, Product manager, K2 Software Developments, Ltd. "The Persistence package saved at least 25 to 50 percent of the development time, and seemed extremely robust. Support has been nothing short of phenomenal." Stew Schiffman, DuPont Research and Development FOR MORE INFORMATION For more information on Persistence, please contact Carl White, VP Sales: - By phone: (415) 341-1280 - By fax: (415) 341-8432 - By email: information@persistence.com Persistent Data Systems PO Box 38415 Pittsburgh, PA 15238-9925 > SubtlwareGo Back Up