The following topics are listed under the 'general' topic area:

What is Polyhedra?

Polyhedra couples the benefits of an SQL relational database with features for real-time applications, such as built-in fault tolerance, data persistence and event driven data change notification. Whether running on an embedded system or on a server, Polyhedra's reliable client-server architecture has been successfully deployed in high performance and mission critical applications worldwide.

The company Polyhedra was founded in the UK in 1990 to bring relational database technology to the real time market - a market which traditionally had not been served well by database management systems. It was bought by Enea Data in 2001.

While designed primarily for embedded systems, Polyhedra also offers a solution for server-level applications. See the pages Polyhedra for Embedded Systems and Polyhedra for Server-level applications for more details.

What was Polyhedra designed for?

Polyhedra was designed to provide a coherent set of development tools for database applications in several specific market areas normally not well served by conventional database vendors (both Object-oriented and Relational).
The core Real Time Relational Database (RTRDB) is designed to sit in an Open Systems environment employing TCP/IP and UDP for connections to clients and other database servers.

• Real Time Data Management - The heart of Polyhedra is a fast memory-resident relational database management system called the rtrdb, that is ideally suited to applications requiring both real-time responses to data changes coupled with the flexibility of modern database technology. Such applications exist in the markets of Process Control and Automation, Telecommunications, Point of Sale, Materials Handling and many others.
• Embedded Systems - As the Polyhedra database is memory resident, it is ideally suited to embedded systems that are often diskless. The Polyhedra database has been successfully employed in several embeded systems running on a variety of target achitectures, including Intel x86 and PowerPC-based systems.
• System Front Ends - The RTRDB is capable of communicating directly and actively with other databases, systems and external devices. This makes it an ideal choice for integrating a lot of disparate data systems together into a single coherent application.

The toolset contains standards-conforming APIs for those wanting to write client applications in C, C++ or Java, and for use on Windows it also has an ODBC driver and OLE DB data Provider. As client applications can be colocated or remote from the database(s) they are using, great flexibility is provided in the organisation of the overall system.

What is different about Polyhedra?

Polyhedra offers significant advantages over traditional DBMS systems:

• Memory Resident - The RTRDB is entirely memory resident. This provides performance that is significantly greater and more predictable than disk-based alternatives. Independent research shows in-memory databases to be an order of magnitude faster than disk based systems, even where the disk based system is cached into RAM.
  This may appear to be very limiting on the data size capability of the RTRDB. This is not the case. The RTRDB was initially for applications that require only several megabytes of data. Now, in fact, main computer memory - and therefore Polyhedra applications - can now be expanded to over a gigabyte. The memory residency ensures the most rapid response possible for even the most demanding applications. Many optimisations (in terms of indices and foreign key traversals etc.) may be implemented that would otherwise be totally impractical.
  Data is persisted (written to a non-volatile store) by the creation of a journal file. Data be marked as persistent or transient to control whether changes to it are journalled, and an application can ask to be notified of a transaction's completion either after the transaction has committed in main memory, or after the journal record has been written. The timing of the creation of a "snapshot", a checkpoint of the current state of the database, is under the control of the application.
• Fault Tolerant - Polyhedra can be configured so that servers run in a 'hot-standby' arrangement, so that if the master database fails the standby can immediately take over in a matter of milliseconds. Switchover control can be closely integrated into the mechanisms used to detect board failure, leading to a fault-tolerant solution ideally suited to the needs of the real-time application developer.
• Active Queries - Polyhedra incorporates a unique concept called active queries, which allow connected clients to specify the data requirements in terms of SQL. The RTRDB (or any other Polyhedra data server) will return the resultant data set and then subsequently inform the client of any changes to that set whenever the database contents change in such a manner as to affect the result of the initial query. These deltas include all attribute changes (individually) of any affected records, any new records that are now included and information regarding any records deleted from the result. This behaviour ensures Polyhedra clients never need to poll the server in order to be kept up to date. The entire system becomes event driven. The query can usually accept updates in the opposite direction (depending on the complexity of the query) such that any data value manipulated directly by the client will cause a database update. All updates are done in the context of transactions. Updates can be grouped together into single atomic transactions
• Active Database - Polyhedra supports the creation of scripts which are triggered by data changes. By use of these, the database becomes an active component in any application and not just a passive data repository like many others.
• Heterogeneous Client-server Architecture - the separation of the the server (and the data it holds) from the client application code protects the database from rogue code, especially in environments where memory-protection is enabled. The platform-independence (heterogeneity) of the protocol used means that clients can be running on separat machines, using different operating systems and processor types to that on which the database is running
• External Database Access - The RTRDB can map the results of an active query placed on another Polyhedra server (such as another RTRDB) into a table or single object. This table or object is maintained as the delta values arrive from the other database.
  These tables can have their own object methods specified that respond to these changes or perform any other operation on the mapped objects. The data connection is two-way.

can Polyhedra databases be accessed from web browsers?

The Polyhedra database can be user-programmed to send and receive arbitrary TCP/IP messages. The database can thus be programmed to exhibit the capabilities of a full web server, allowing full access by standard Web browsers; sample class definitions are supplied with the evaluation system and is available to all registered customers. This technology has been used to implement the web server running on our support web site, http://support.polyhedra.com/eval.htm.

Obtaining Polyhedral Models and Pictures of Polyhedra

Despite the name, the Polyhedra company does not make, sell, distribute, research or hold information about the aspect of mathematics known as polyhedral models. We suggest instead the following site as a starting point for your seaches if you want information on this topic:

The Geometry Junkyard.

A nice set of picture of Polyhedra can be found at http://www.mathconsult.ch/showroom/unipoly/unipoly.html.

The WinkWorks site has a good collection of links to sites about Polyhedra.

What are 'active queries'?

The main purpose of an active query is for a client to monitor information in the server, and be told when data changes without having to poll. In fact, it is better than that, since the client is not just told that a change has occurred, but is told just enough information to bring it up to date.

When an active query is established, the client is given the initial results, and then the server sets up internal triggers, so that whenever anything occurs in the database that would invalidate the previous results, the query manager is told. At the end of the transaction in which the change or changes occurred, assuming no rollback occurs the query manager calculates what information has to be sent to the client, which is then sent through to the client as a 'delta', a batch of changes. The internal trigger mechanism in the core database engin is the essential feature that means no time is wasted re-evaluating queries that have not been effected by a given transaction.

The query manager has two mechanisms for ensuring that the communications traffic is not excessive. Firstly, if a client is running slow and not able to keep up with all the deltas it receives, the server needs to control the number of deltas sent. This is done by only sending a delta when the previous one had been acknowledged; if many relevant transactions had occurred in the meantime, the client is only told about the current state, not any intermediate ones.

The second performance enhancement is the ability for the client to specify a bandwidth limit when the query is established. If updating a mimic diagram, for example, viewers will not be able to absorb too-frequent updates, so it makes sense to limit the delta to at most, say 10 per second. In fact, the limit is expressed not as a frequency - which might be taken as implying some form of polling - but as a time period: once one delta has been sent, further deltas are blocked for that interval or until the client acknowledges the outstanding delta, whichever is later.