The Concept
The Empress Data Management System as an
Information
Management Component
The ConceptThe Empress Data Management System as an
|
|
| A White Paper | |
INDEX
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.
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:
- Designed for embeddable application database subsystem plug-ins
- Designed for handling any object the computer can store
- Designed for handling large volumes of data
- Designed for building knowledge-based databases
- Designed for distributed database and programming processing
- Designed for both disk and in memory database management
- Designed for eXtreme low maintenance
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:
- Works with multiple databases on the same disk
- Supports Mapped Files, Juke Boxes, RAMDISK, RAID, HIPPI, etc.
- Does not impose limits but inherits them from the O/S
- Automatically interchanges 32 bit and 64 bit data
- Automatically allocates Main Memory, Disk and Processors
- Tables can reside on any directory, file system or node
- Link with other libraries to make them available to developers
- Multiple I/O - output of Empress can be input to another program
- Is an integral part of the application
- Requires low system resources to power the application
- Uses the power of the O/S for speed, performance and small footprint
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:
- Be an integral part of an application
- Need no more administration than an application data subsystem
- Need no more system resources than an application database subsystem
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.
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".
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:
- Character data
- Variable length text data (dynamic space allocation)
- National Language Support for character and text data
- Date data (9 external formats)
- Time data (9 external formats)
- Micro second time data
- Decimal data
- Currency data
- Real numbers
- Floating point numbers
- Double precision floating point numbers
- Long, regular and short integers
- Binary data of any kind
- User interpreted binary data with user defined functions
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:
Table: sys_dictionary
Attributes:
dict_creator nlscharacter(31,1,0) dict_tabname nlscharacter(32,1,0) Not Null dict_comptime time(1) dict_comp bulk(20,0,1024,1)
The same methodology can be used for applications that need to store data for both user readable descriptors and computer readable compiled code.
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.
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:
Table: sys_4gl_form
Attributes:
name nlschar(32,1) Not Null compile bulk(20,471,512,1) Not Null application_name nlschar(32,1) Not NullThe 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:
Table: sys_4gl_field
Attributes:
name nlschar(32,1) Not Null application_name nlschar(32,1) Not Null window_name nlschar(32,1) Not Null enter_script nlstext(20,0,64,1) exit_script nlstext(20,70,64,1) mode char(1,1) data_type nlschar(32,1) next nlschar(32,1) previous nlschar(32,1) number integer Not Null next_number char(5,1) previous_number char(5,1) save_name nlschar(32,1) default_expression nlstext(20,42,64,1) range nlstext(20,42,64,1)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:
- Initialization for the enter script clean up for the exit script
- Size of each window
- Definition of each "form" that is associated with each window
- Logic associated with the input device
- Definitions of function keys
- Parameterization of mouse functions
- Definition of Braille devices
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.
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:
CREATE TABLE Storm ( key INTEGER NOT NULL, name CHARACTER (20,1) NOT NULL); CREATE TABLE Storm_data ( key LONGINTEGER NOT NULL, longitude LONG FLOAT NOT NULL, latitude LONG FLOAT NOT NULL, radius LONG FLOAT NOT NULL, category INTEGER NOT NULL, time_value TIME(2) NOT NULL);
For the JAVA program called box_circle_intersection, the interface definition is:
GLOBAL_SHARED_FUNC msbool box_circle_intersection ( double longitude, double latitude, double radius, double long1, double lat1, double long2, double lat2) Input Parameters: longitude: longitude of storm eye latitude: latitude of storm eye radius: radius of storm long1: longitude of Northwest Corner lat1: latitude of Northwest Corner long2: longitude of Southeast Corner lat2: latitude of Southeast Corner Exports: returns true if within region
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:
SELECT DISTINCT name FROM Storm WHERE key IN (SELECT DISTINCT key FROM Storm_data WHERE time_value BETWEEN 19850101 AND 19991231 AND box_circle_intersection (longitude, latitude, radius, -140.0, 24.5, 75.0, 50.0) );
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.
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.
[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.
|
|||||||||
