The Concept




The Empress Data Management System as an
Information Management Component



by Njai Wong

  A White Paper

INDEX

  1. Introduction
  2. Empress Data Management System Backgrounder
  3. Tier 1 Component: Operating System Extensions
  4. Tier 2 Component: Application Database Plug-in
  5. Information Management of Any Kind of Data
  6. Application Data
  7. Meta Data
  8. Information: Application Programming Logic as Data
  9. Example 1: Application Programming Logic in Tables
  10. Example 2: Application Programming Logic in Schema
  11. Conclusion
  12. References


1. Introduction

The Empress Data Management System was designed as the two tiered Information Management Component (IMC) of application software.

I = M C 2 represents the concept of a two tiered Information Management Component where:

I represents Information

M represents the Empress RDBMS

C 2 represents the Two Tiered Component

The Empress Data Management System works as a two tiered component. The first tier works as an extension of the Operating System file system. The second tier works as an embeddable application database subsystem plug-in. Together, the two tiers create the Force that governs universal data. This Force can process data into information and make it useful.


2. Empress Data Management System Backgrounder

The Empress Data Management System is a powerful, reliable and cost-effective embeddable knowledge and rule-based relational data management system. It is designed for high-performance, mission-critical, maintenance-free applications on Unix, Linux, Real Time and Windows environments. Such applications are typically developed for Aerospace, Military & Defense, Meteorological, Simulator Design, Satellite Imaging, Network Management, Electronic Publishing, Telecommunications and Process Control.

The Empress Data Management System is powerful and cost effective. The power is shown by its speed, small footprint, adaptability, scalability and extensibility. Its cost effectiveness is shown by its portability, ease of use, ease of integration and ease of maintenance.

The Empress Data Management System product differentiators are revealed in its design:


3. Tier 1 Component: Operating System Extensions

One of the basic tasks of the operating system is to interface with storage devices such as disks, allocate storage, keep track of files and directories, provide the input and output of data from disk, and even provide data management functionality.

Definition

"Operating System: An integrated collection of routines that service the sequencing and processing of programs by a computer.
Note: An operating system may provide many services, such as resource allocation, scheduling, input/output control, and data management. Although operating systems are predominantly software, partial or complete hardware implementations may be made in the form of firmware."1

In general, an Operating System (O/S) provides users with a large and unified collection of utilities and file handling tool. The Empress Data Management System provides an integrated toolkit for information management to complement the standard Operating System facilities and extend the computer resources available to the user.

The Empress Data Management System uses the O/S file system as its native file system while adopting the O/S operational environment as its standard environment. Together with its open architecture, the Empress Data Management System becomes a functional extension of the O/S file system. Empress thus provides a data management system with speed, performance and small footprint together with the power of the O/S.

By adopting the O/S file system as its native file system and the O/S operating environment as its standard environment, the Empress Data Management System interfaces seamlessly with the operating system. For example Empress:


4. Tier 2 Component: Application Database Plug-in

A complete application consists of hardware and the following software components: operating system, application logic, application input/ output (application data) and some form of data management system. The Empress Data Management System can be configured as an application plug-in allowing seamless integration with the whole application system.

An ideal database management system should:

Most commercial database management systems cannot seamlessly integrate with applications, need dedicated database administrators and require heavy system resources.

The Empress Data Management System was designed as an embeddable application database subsystem plug-in. Multiple databases can be created at the application developer's specified locations, on both local and remote machines. With Empress, the application database subsystem is under the control of the application developer and becomes an integral part of a complete application. For a developer, this is what a database management system should be.


5. Information Management of Any Kind of Data

The Empress Data Management System was designed to handle any information the computer can store. This includes anything from name, address, phone number to JPEG images to compiled C++ programs to MP3 files to Meta data about application programs. This allows developers to create event driven, expert, knowledge and rule based systems. The result is a radically different paradigm for a database system where algorithms and visualization are placed "next" to user data. This new paradigm unites the executable code, user data and its meaning under the umbrella of the term "database".


6. Application Data

The Empress Data Management System provides a wide variety of data types, enabling users to choose the data type most suited for the type of data being stored and the application. These data types are:


7. Meta Data

A good example of using relational tables to store Meta data is the Empress database data dictionary. The Empress database data dictionary consists of several relational tables, which hold information about database tables and attributes. These tables can be accessed like any other tables that hold application data. However, for faster retrieval, all this information is compiled and stored in one binary (bulk) attribute dict_comp in the sys_dictionary table:

The same methodology can be used for applications that need to store data for both user readable descriptors and computer readable compiled code.


8. Information: Application Programming Logic as Data

Application programming logic can be stored both in the Empress database tables and in the database schema. Application logic that executes depending on certain data is a candidate for storing in database tables. Application logic that acts or reacts to selected data is a good candidate for storing in the database schema such as triggers and stored procedures. The following sections provide examples of each.


9. Example 1: Application Programming Logic in Tables

The Empress 4GL and GUI are both examples of application development environments that allow developers to create event-driven applications. The following shows how the Empress 4GL is structured within the database. All information about 4GL applications is stored in several tables in the database. When the developer creates a form, this form is stored in the database table with 3 attributes:

The form is compiled into a user interpreted data structure and stored as binary (bulk) data in the attribute "compile".

Fields are associated with a form. Fields allow data to be input and displayed. The information about a field is also stored in a database table:

enter_script and exit_script store 4GL logic (programs) which are executed when the field is entered or exited. In a similar fashion, database tables are defined for other objects to keep track of and provide meaning for:

All information about the application is compiled into one attribute value, in one record, in one table (sys_4gl_compile) which is then linked (sys_4gl_link) with associated libraries. When the user calls the application, the attribute value in compile that matches the application name in the sys_4gl_link table is executed.


10. Example 2: Application Programming Logic in Schema

A database contains information of hurricane watches and warnings on tropical cyclones over the Atlantic, Caribbean, Gulf of Mexico and the Eastern Pacific over the past 20 years. Reseachers work with this data to improve hurricane forecasting techniques. To assist this process, a Java function was written that returns "true" if a rectangle (geographic area under consideration) and a circle (the hurricane) intersect.

Storing this piece of programming logic in the Empress database schema turns it into "reusable code" which can be shared by many applications. Below are the table definitions and the interface definition for the JAVA program:

For the JAVA program called box_circle_intersection, the interface definition is:

Once this program is stored in the Empress database schema, it can be used by all the Empress interfaces. These include interactive, dynamic and static SQL, C, C++ and Fortran, ODBC, JDBC, Report Writer, etc.

The SQL statement below lists the names of hurricanes that occurred in the given geographical region near Florida between January 1, 1985 to December 31, 1999:

The parameter values of longitude, latitude, and radius for the function box_circle_intersection are obtained from the Storm_data table. This value changes each time a record is obtained from the outer select statement.


11. Conclusion

The Empress Data Management System with its unique two tiered component architecture provides the developer with the "can do" flexibility of a developer created database plug-in without the inconvenience and overhead of traditional databases. The Empress Data Management System not only deals with the storage and retrieval of data but also programming logic and user defined functions that turn data into information. The resulting application with the Empress Data Management System works seamlessly resulting in a small footprint, efficient and robust information application that requires virtually no maintenance.


12. References

[1] National Communications System Technology & Standards Division, "Telecommunications: A Glossary of Telecommunications Terms - Federal Standard 1037C", General Services Administration Information Technology Service, August 7, 1996.

For a more detailed description of Example 2 dealing with Hurricanes and specified geographic locations as well as more details how the user can extend the Empress Database Management System, please see:

[2] S. Savchenko, "Extending Database Functionality Through Persistent Stored Modules", Seventh Workshop Proceedings on Meteorological Operational Systems, European Centre for Medium-Range Weather Forecasts, November 1999.

For a more detailed look at the Empress Database Management System Datatypes, the Data Dictionary, storing compiled code, storing other binary data, adding persistent stored modules and user defined functions, please see:

[3] Empress Software Inc, "Empress V8.60 Manual Set", Empress Software Inc, April 2000.

For a more detailed look at the Empress Database Management System Distributed Database capability including Peer to Peer, please see:

[4] N. Wong, "Beyond Client Server", Empress Software Inc. White Paper, 2001.




I = M C 2 The Concept

by Njai Wong

Empress Software, Inc.

US inquiries:

Phone: (301) 220-1919

Fax: (301) 220-1997

International inquiries:

Phone: (905) 513-8888

Fax: (905) 513-1668

www.empress.com
info@empress.com