The Base/OPEN Data Base Management System (DBMS) is optimized for long-lasting and large transactions which are characteristic of engineering applications. It provides facilities to create and maintain a common data base for different applications. The data base is object-oriented, which provides for natural, real-world oriented data modelling making it particularly efficient for CAD/CASE-applications. It is available for several modern workstations making it possible to write portable applications.

Product Perspective
The purpose of the Base/OPEN DBMS is to be supremely useful for engineering applications, e.g. CAE, CAD, CASE. We take a practitioner's view, how to make things work. Extensions to traditional database models, like object-orientation, are a means to ths end, not goals by themselves.

Performance
The first question a potential application developer asks about a DBMS is invariably. "What about performance?" EasyDB is designed to allow applications to keep much of their run-time data structures in the database, without sacrificing too much performance compared to hard-wired tool specific data structures.

Conceptual Simplicity
The philosophy is to achieve performance by conceptual simplicity. This is another aspect of performance orientation. The value of added concepts and facilities have been carefully weighed against their cost in terms of performance.

The Classical Database Problem
EasyDB provides solutions for "the classical database problem": achieving data independence under the assumption that data is a shared resource. Here lies much of the motivation for using a DBMS in the first place. Main goals are,

• To make data definitions visible, sharable (in contrast to being buried in application code), and largely programming language independent.
• To free data definitions from storage mechanism considerations (in contrast to being hardware-dependent).
• To allow data definitions to be modified (or at least extended) without invalidating existing data or applications.

EasyDB Product Description
Interfaces
The Base/OPEN EasyDB has two generic interfaces - DDL and DML. The DDL (Data Definition Language) is based on the well-known Entity/Relationship modeI and is used to define the structure of data in terms of entity types, relationships and attributes. The DML (Data Manipulation Language) works on two different levels: interactive for ad-hoc access and query and as an embedded language for highest performance.

Data Definition Language
The data description language is strongly influenced by entity-relation ship concepts. It allows you to define entity types and relationships between them. An entity type is defined as a set of attributes. Relationships are inherently bi-directional. This is the basic framework upon which two strains of DDL are defined - C-DDL and A-DDL. All DDL definitions are stored in a data dictionary (DD). G-DDL is an interactive graphical modeling tool.

C-DDL - Concepts:

• entity type
  single inheritance between entities
• attribute
  entity types may have attributes
  database keys model global relationship
• relationship
  bi-directional, between entity types, local
• cluster type
  collection of related entity types introduces version control level

Entity types
The basic modelling unit is the entity type which has a name and may have attributes. An attribute has a name and a value. The entity is the small grain object.

Attributes
There is a rather complete type system for attributes. In addition to conventional data types there are two specialized ones: Bytestream for storing large varying length character strings - the source code for a program module, for instance. Database key for storing references between entity instances in different clusters in the data base thus used to model global relationships.

Domains
Strictly speaking, an attribute is associated with a domain rather than with a type. A domain is defined as a base type plus a range of possible values. Domain definitions are collected in compilation units called packages.

Relationships
Relationship types in EasyDB are binary and local, connecting two entity types within a cluster. Relationships may be traversed in both directions, i.e. they are bi-directional. Thus referential integrity is guaranteed. Relationship types may be of different cardinalities. The cardinalities are:

• one-to-one and
• one-to-many.

Inheritance
An entity type may inherit another entity type. All attributes and relationships are inherited in such case. Any number of inheritance levels are allowed.

-- C-DDL text: . . . ENTITY Female ISA Person : femaleType -- Female inherits Person . . . REL bore ONE Female MANY Person -- A Female may have given birth to many -- Persons (Male or Female)

Cluster types
The implementation independent nature of C-DDL is broken by the concept of cluster type. This sets a physical boundary around a structure of entity types and relationships thus defining a large grain object or aggregation. Relationships crossing a cluster type boundary are called global in contrast to local relationships. The global relationship is in EasyDB modelled by the Database key attribute which is a one-directional pointer.

Aggregation
The main reason for not concealing cluster boundaries behind a logical layer is performance. In CAE a large design is always divided into comprehensible design objects, e.g. a Document consists of section headers, paragraphs etc.. Thus we believe there is generally a natural mapping between design objects and cluster types.

Structural OO
In the terminology of Dittrich, K.R. EasyDB (ODBMS) is structurally object-oriented. That is, methods are not stored in the data base.

Universe
C-DDL is also used to define a data universe for applications. A universe may be, for example, all data needed by all CAD tools, the "cad-production-universe", or a "test-universe" for testing out new applications and changed schemas. The universe consists of a number of cluster types.

Schema Evolution
New cluster types can be added to a universe at any time. A cluster type definition can be modified, as long as it is only extended, without disrupting data base operation. E.g. you can add a new attribute, a new relationship etc. to an entity type without any need of re-compiling old applications. In other words, there may be several versions of one and the same cluster type. Instances of old cluster type versions may co-exist with instances of newer versions.

Versioning
The cluster is the unit of physical i/o. A cluster, when opened, is transferred in its entirety to virtual memory. The cluster is also the unit of versioning and access control. Cluster versions are organized in tree structures called version trees. The version tree is the unit of distribution.

A-DDL
A universe may contain many cluster types. Application DDL (A-DDL) is used to define a view (application schema), i.e. a subset of the total schema. A data base application has to be associated with one or more views.

Data Manipulation Language
EasyDB offers two DML's for program development, NQL (for programs written in Ada83 and C) and DBI (for programs written in Ada95 and C++).

Dynamic and static DML
There are two strategies when accessing data, static and dynamic access. Static access is type-safe and the fastest in terms of execution speed. Dynamic access is the flexible way, useful for instance when writing application independent database browsing tools, like DBed.

NQL - a Ada83 and C Interface
The basic DML is called NQL (Navigational Query Language). It is embedded in a host language (Ada83 and C at the moment). NQL in itself is host-language independent. As its name suggests, NQL is navigational.

NQL - Concepts:

• cursor
  refers to an entity instance or is nil
• navigation
  move cursor from entity to entity by select
• query and update attribute values
  
• create/delete, attach/detach entities
  
• other
  open/close on clusters

NQL (C-language binding) - Example:

/*  * Print the name (and age) of all children  * not older than 18 years. See "C-DDL" figure.  */ NQL DECLARE (CURSOR) cur; . . . NQL EVERY cur(Female) MEMBER bore   WHERE { cur(Person)->age <= 18 }   FROM femaleCur     printf("Name %s", cur(Person)->name);     printf(" Age %d\n", cur(Person)->age); NQL ENDEVERY

NQL (Ada83-language binding) - Example:

-- -- Print the name (and age) of all children -- not older than 18 years. See "C-DDL" figure. -- NQL DECLARE (CURSOR) cur; . . . NQL EVERY cur(Female) MEMBER bore   WHERE { cur(Person)->age <= 18 }   FROM femaleCur     Text_IO.Put("Name " & cur(Person)->name);     Text_IO.Put_Line(" Age " & Integer'Image(cur(Person)->age)); NQL ENDEVERY

DBI - a Ada95 and C++ Interface
DBI is a class interface to EasyDB. It deals with data manipulation, i.e. it is a DML (like NQL) as opposed to a DDL. DBI is used for writing Ada95/C++ application programs to access data in EasyDB. The DBI system has two main parts:

• the predefined class library, and
• the view generator program.

DBI - Concepts:

• entity handle concept
  typed reference to an entity instance or is nil
• navigational
  move handle from entity to entity by select or iteration
  -- by member functions
• query and update attribute values
  -- by member functions
• create/delete, attach/detach entities
  -- by member functions
• other
  open/close on clusters
  -- by member functions

• Create a schema description with C-DDL or G-DDL tools. The result will be a representation of the schema which is stored in the Data Dictionary.
• Define the application view, a subset of the conceptual schema, by means of A-DDL.
• Generate ready-to-use schema-specific Ada95 classes, types and constants with the adaview tool, and C++ classes, types and constants with the cxxview tool.
• Write your Ada95/C++ application programs utilizing the DBI library and the generated classes to create a data base and manipulate its contents. It is possible, and sometimes very useful, to write an application without using generated classes at all. This is called dynamic DBI versus static DBI where you use the names defined in the schema. The DBI example uses static DBI - i.e. we call member functions of generated schema-specific classes.

DBI (Ada95-language bidning) - Example:

-- -- Print the name (and age) of all children -- not older than 18 years. See "C-DDL" figure. -- Person_H : SReg.Person(My_Module); -- declare handle My_It : DBI.Iterator; -- declare iterator Status : DBI_Standard.DBI_Bool := DBI_Standard.DBI_True; . . . -- initialize an iterator SReg.Every(SReg.Get_Bore(Female_H), Female_H, My_It,            DBI_Standard.DBI_LEQ,            (SReg.Age, SReg.Age, 18)); while Status = DBI_Standard.DBI_True loop   DBI.Next(My_It, Person_H, Status);   if Status = DBI_Standard.DBI_True then     Text_IO.Put("Name " & SReg.Name(Person_H));     Text_IO.Put_Line(" Age " & Integer'Image(SReg.Age(Peson_H)));   end if; end loop;

BGL
Interfaces provided by a DBMS (either procedural or embedded textual language) are often aimed at optimizing application run-time performance with the disadvantage being the necessity of relying on special programs written in C or C++. The Base/OPEN BGL tool set, on the other hand, functions at a higher level and is optimized to minimize development time.

BGL Tool Set
The Base/OPEN BGL tool set consists of graphical modeling and interactive query tools. By employing BGL it is possible to develop and maintain conceptual models and to accelerate the development of query and update applications.

Furthermore greater independence from the underlying DBMS concepts is achieved as the work itself is conducted on the well-known, extended entity-relationship concept level. With the BGL tool set it is no longer necessary to iterate in the edit-compile-run-debug loop.

Graphical DDL
The Graphical Data Definition Language (``G-DDL'') is a tool for conceptual modeling and schema definition based on the data modeling concepts Entity-Relationship-Attribute (ERA) combined with Object-Orientation (OO).

Interactive DML
The interactive DML is called DBed. DBed is a tool for ad-hoc query ("interactive NQL") and rapid development of data base applications. DBed also supports scripting and provides interactive query access to the data dictionary (DD), of EasyDB. DBed is written entirely in C and dynamic NQL, thus demonstrating the strength and openness of the EasyDB interfaces.

DBed (interactive DML) - Example:

-- Print the name (and age) of all children -- not older than 18 years. See "C-DDL" figure.   Female >> every bore (age <= 18) {print :name :age} Attribute: 'name' = 'John' Attribute: 'age' = '13' Attribute: 'name' = 'Susan' Attribute: 'age' = '9' (DBed) No more members. -- Query DataDictionary for relationships, -- where Female has the role of Head.   Female >> dd head HEAD --> sreg.Female           Female -(bore)* Person           Female -(married)- Male

EasyDB Productivity
The figure below illustrates the productivity in using DBI - the C++ interface to EasyDB. Assume we start off from one schema picture with 15 entities each having 5 attributes, 15 relationships and 5 clusters, created with the G-DDL modelling tool. From this, about 200 lines C-DDL may be generated. The schema is compiled into the data dictionary with the cddl tool. The cxxview class generator reads the data dictionary and creates schema specific-classes, query member functions etc., for the view defined with the addl tool. The generated code will be about 5000 lines of C++ code in this case, ready to use in application (appl.C in the figure) development or for extending DBI with user-defined member function.

EasyDB Architecture
The EasyDB system is implemented as two levels of data managers in a multi-client - multi-server architecture. This is illustrated in the next figure. The data managers are called ADM and SDM.

• ADM - Application Data Manager, library to be linked with the application.
• SDM - Storage Data Manager. One process for each host/disk you want to store database contents on.

Example Configurations
EasyDB can be configured in numerous configurations as outlined in the following figures.

Light weight EasyDB LiTE	Multi-client / server EasyDB

The above figure first shows light weight EasyDB LiTe and next multi-user EasyDB in a single server and multi-client configurations. The clients need not run on the same host as the servers. Below we have added more EasyDB servers running on different hosts in a local area network, a multi-server configuration. Clients running on different hosts in the network have transparent access to data managed by the different servers. This is configured by the database administrator. EasyDB includes other server processes not included in the figures.

Multi-client / multi-server EasyDB

Performance Considerations
Here are some major performance-related design considerations.

• The whole EasyDB design rests on the assumption that a large number of operations are performed on a cluster once it has been opened.
• NQL has strong (static) type checking. As much work as possible is moved from run-time to compile-time. (Most NQL statements appear in two versions, with static or dynamic type checking. Dynamic type checking is sometimes very useful, but not as efficient as static type checking.) This is a strong reason for making NQL embedded rather than implementing it as a procedure library.
• The run-time system uses a binary summary of pertinent schema data. This data structure (called a cluster map) is generated by the C-DDL compiler. It eliminates the need for run-time access to the data dictionary.

Documentation
The following documentation is provided with the EasyDB product:

• EasyDB C-DDL Reference Manual
  B/O 90 082
• EasyDB NQL Reference Manual
  B/O 90 060
• EasyDB DBed Reference Manual
  B/O 89 206
• EasyDB Tools Reference Manual
  B/O 91 013
• EasyDB DBI Reference Manual
  B/O 91 088
• EasyDB NQL C example
  B/O 91 008
• EasyDB NQL Ada example
  B/O 93 012
• EasyDB and C++ - example
  B/O 91 123
• EasyDB Modelling
  B/O 91 009
• EasyDB Installation and Release Document
  B/O 91 116
• EasyDB LiTe Installation and Release Document
  BO 96 202
• EasyDB Administrator's Guide
  B/O 91 115
• EasyDB Glossary
  B/O 91 002
• EasyDB DBed sample session
  B/O 90 110
• EasyDB GDDL, Ramatic, Reference
  B/O 91 137