This document presents the TITANIUM® database
engine in a manner that allows developers to thoroughly assess its
suitability for their applications. While TITANIUM offers more capabilities
than needed for modest functions, applications with complex relationships
benefit substantially from its utilization.
Introduction
TITANIUM is a high performance database engine
designed for developers of complex, mission-critical applications.
Through patented, multi-model DPA technology (U.S. Patent Nos. 5,611,076
& 5,713,014), TITANIUM implements complex data models and relationships
directly in the physical database repository, providing unmatched
performance with minimal use of system resources. Further, TITANIUM
is a multi-model database system, built specifically to offer the
strengths of the relational, object-oriented, and navigational/network
data models while avoiding the weakness of database systems that
offer only one model or a hybrid. With TITANIUM, developers can
create complex applications which cannot be built with conventional
database technology without considerable compromise.
TITANIUM also has unique capabilities because it
is a low-overhead, highly efficient engine designed to provide optimal
performance for computers with modest hardware configurations. For
example, a complex database application using conventional database
technology normally requires a mainframe or high-end multiprocessor
server to attain acceptable performance levels. With TITANIUM, however,
the same or higher performance levels are attainable on an inexpensive
PC running Microsoft Windows NT or a low-end UNIX workstation. TITANIUM
also takes advantage of advanced hardware capabilities, with performance
increasing exponentially.
Further, TITANIUM, is a highly reliable, fault-tolerant
database system. It has unique features to ensure that data is saved
in a logically and physically consistent state, even in the event
of hardware failure. For this reason, it is used for mission-critical
applications in areas ranging from financial, manufacturing, and
health care to flood control and aircraft maintenance.
The following pages examine TITANIUM's patented
physical architecture and explains how it achieves its efficiency,
performance, and reliability. The multi-model concept is then defined,
along with technical examples showing how each of the multiple models
is used. The operating environments, languages, and interfaces supported
by TITANIUM are also described, with detailed technical examples,
in addition to some of its specific unique features.
TITANIUM DPA Physical Architecture
TITANIUM has the most efficient physical storage
layer available today. The underlying architecture is designed to
minimize I/O operations to the physical media, especially for complicated
operations spanning many tables or entity types.
TITANIUM's patented, multi-model Dynamic Pointer
Array (DPA) technology delivers extremely fast query responses.
DPA technology simplifies queries and updates on
databases with complex data models. By eliminating the cumbersome
joins and redundant intersect tables associated with typical databases,
TITANIUM delivers sub-second response times with even the largest
of databases.
The power of DPAs is illustrated in the following
diagrams:
 |
 |
| Typical One-To-Many Relationships |
TITANIUM One-To-Many Relationships |
| |
|
Typical relational databases use redundant keys
to manage relationships between tables. Performing a query of these
two tables requires a join operation, where the primary keys in
Table 1 are paired with rows containing matching foreign keys in
Table 2. In many cases, as in Figure 1, an index on the foreign
keys is used to speed the joining process. As the size of these
tables (and indexes) increases, the join process slows down due
to increased disk operations. This problem is particularly acute
when joining three or more tables together.
TITANIUM uses DPAs to manage relationships between
tables (Figure 2). DPAs are specialized index structures that replace
the need for redundant keys and encapsulate the join information
between tables. Each Table 1 record references (with a 4-byte pointer)
a DPA, which in turn references only those Table 2 records associated
with the given Table 1 record. The net effect is an instantaneous
join between the individually related records within each table.
The join time does not increase with the size of the tables; instead,
it slowly increases only with the actual increase in the number
of related records. And since DPAs are used at all levels of the
storage hierarchy, the time required to join three or more tables
is reduced logarithmically over typical databases.
As powerful as DPAs are for one-to-many relationships,
the advantage of DPA technology is best demonstrated with many-to-many
relationships.
 |
 |
| Typical Many-To-Many Relationships |
TITANIUM Many-To-Many Relationships |
Traditional relational databases require an intersect
(or join) table to manage many-to-many relationships (Figure 3).
The intersect table contains pairings of primary keys from Table-1
and Table-2. Performing a many-to-many query requires two joins,
a complicated SQL "select" statement, and a large number
of hard disk operations. As more data is added to the database,
the intersect table can grow at an alarming rate, further slowing
the join operations.
TITANIUM manages many-to-many relationships directly
by simply adding a second set of DPAs to the one-to-many relationship
(Figure 4). Join operations are instantaneous in both directions
and significant space is saved since intersect tables (and their
associated foreign key indexes) are eliminated. TITANIUM is the
only database which supports true many-to-many relationships without
intersect tables, redundant keys, or joins.
For all relationship types (one-to-many, many-to-many,
and so on) DPAs eliminate overhead and data redundancy. In addition
to the resulting performance gains and storage savings, database
integrity and reliability are enhanced. Further, the TITANIUM architecture
eliminates logical database corruptions by removing the need to
manage redundant data.
TITANIUM's Comprehensive Relationship Support
Since DPAs physically separate pointers used to relate information
across tables from the data, modeling flexibility is available to
the developer. TITANIUM directly supports all of these relationship
types in the physical database:
- One-to-one
- One-to-one recursive
- One-to-many
- One-to-many recursive
- Many-to-one
- Many-to-one recursive
- Many-to-many
- Many-to-many recursive
- One-to-many (n-ary)
- One-to-many (n-ary) recursive
- Many (n-ary)-to-one
- Many (n-ary)-to-one recursive
- Many (n-ary)-to-many (n-ary)
- Many (n-ary)-to-many (n-ary) recursive
Examples of some of these relationship types are
illustrated in Figures 5-8.
As with normal one-to-many and many-to-many relationships,
the recursive and n-ary variations do not require redundant keys,
intersect tables, or joins. In fact, the same DPA structure is used
for all relationship types. Many-to-many recursive relationships
(Figure 6), common in bill of materials and parts explosion problems,
utilize DPAs for both downstream and upstream navigation. The developer
can also select different ordering criteria in each direction (for
example, ordered by part number downstream and by cost upstream).
TITANIUM also supports n-ary relationship combinations.
N-ary relationships allow developers to specify a single DPA to
relate many different record types together. Figure 7 illustrates
an n-ary relationship where one DPA is used to link various bank
account types to a customer. If the checking, savings and pension
records have a field in common, such as an account number, the DPA
can be built in sorted order.
Referential Integrity
Unlike traditional relational databases, where the developer must
maintain consistency between multiple tables, referential integrity
is not an issue for TITANIUM databases. Because unique data is stored
only once, physical redundancy is eliminated. Further, DPAs are
managed automatically by the database engine as data is created,
updated, and deleted. Neither the developer nor the user needs to
understand how DPAs work, or even that they exist.
Physical Database Optimization
In addition to DPAs, TITANIUM utilizes other sophisticated storage
optimization techniques. The developer can design the physical schema
to store or cluster logically related records together. For instance,
the designer can specify checking, savings, and pension records
to be stored on the same page (TITANIUM database
files are divided into pages, where a page is the physical I/O unit
between the database engine and the storage media) as the
customer record to which they belong. In addition to clustering,
TITANIUM supports record hashing, variable length fields, automatic
field compression, configurable index widths, configurable page
sizes, and many other performance tuning features.
TITANIUM Multi-Model Architecture
TITANIUM's unique multi-model architecture allows
the developer to choose the most appropriate model for the application
while fully harnessing the power of DPA technology. The architecture
is illustrated below (Figure 9):
TITANIUM allows simultaneous access to the database
by programs using different logical data models, combining the strengths
of each model while avoiding the weaknesses inherent in each.
The internal physical structure of the TITANIUM
database directly implements complex objects and connections (relationships)
between those objects, allowing each model to act as a different
view of a complex 3-D structure.
- The TITANIUM relational model allows users and SQL developers
to view the database as a simple collection of tables.
- The TITANIUM object-oriented model provides a standard ODMG
(Object Data Management Group) interface to developers using the
object-oriented C++ language.
- The TITANIUM navigational model provides simple, straightforward
APIs callable from non-object-oriented languages such as C, Visual
BASIC, and COBOL.
Benefits of Multi-Model
TITANIUM's multi-model architecture provides the
strengths of each model while avoiding many of the weaknesses. Each
model is "pure" within itself. Complexities and compromises
introduced by mixing models within a program are avoided and transparent
to the end user. No special training is required by developers or
end users to be productive, even if the developer or user is familiar
with only one of the models. Multiple programs using any of the
models can simultaneously access the database.
Strengths of the TITANIUM Relational Model
The TITANIUM relational model allows users and
SQL developers to use their SQL schema with TITANIUM viewing the
database as a simple collection of tables. With its advanced DPA
technology, TITANIUM supports SQL schema definitions. No extensions
to the SQL query language are required, yet relational users have
full read/write access to the database. The SQL syntax required
to work with the TITANIUM relational view is less convoluted than
that required by DBMSs that use only the relational model. A complex
operation that requires a multi-table join in a simple relational
system can be implemented as a simple update or query to one table
in TITANIUM. Features such as triggers and columns defined via stored
procedure allow developers to do complex operations transparently.
The results are presented to end users as simple column values.
TITANIUM fully implements the ANSI-92 SQL standard and supports
standard SQL call-level APIs such as the Microsoft ODBC (Open DataBase
Connectivity) interface.
Strengths of the TITANIUM Object-Oriented
Model
The TITANIUM object-oriented model provides a standard
ODMG (Object Data Management Group) interface to developers using
the object-oriented C++ language. This interface provides all the
benefits of a pure object-oriented database. For example:
- Declaration and manipulation of database objects is intuitive
and natural to the object-oriented developer.
- A close correspondence exists between the declaration and manipulation
of objects in the developer's code and the declaration and manipulation
of persistent objects in the database.
- End users benefit from the speed of complex applications created
with this model. Navigation of complex relationships between objects
is inherently fast because of the object interface's low-level
access to each individual object and its relationships. TITANIUM's
patented physical architecture enhances this speed.
TITANIUM's object interface is a thin layer with
low overhead compared to object-only databases. TITANIUM also gives
developers control over when and how objects are stored in the database,
contrasting with object databases that compromise performance and
efficiency for nonessential features.
Strengths of the TITANIUM Navigational Model
The TITANIUM navigational model provides simple,
straightforward APIs callable from non-object-oriented languages
such as C, PASCAL, BASIC, and COBOL. These APIs allow the same high-speed
navigational access to complex data as with the object-oriented
model. Since TITANIUM is language independent, developers familiar
with existing languages do not have to learn an entirely new paradigm.
Object-Oriented Model
TITANIUM Object Definition Language (ODL)
An object-oriented schema is created using the
Object Definition Language (ODL), which is part of the ODMG standard.
The same complex relationships can be specified in this schema language,
a partial example of which is shown below (Figure 10):
|
Figure 10: Example of object-oriented schema (ODL) |
//
etdemo.odl - This file defines the database used by the Employee-Task
database.
//
const long NameLen = 80;
// The term "interface" is ODL's
keyword for
// a persistent class definition
interface Employee
(
// an extent defines a collection for
access
// to all objects of this class
// keys define index lookup methods for fast
// access to the persistent objects
extent Employees
keys EmployeeName=EmployeesByName,
EmployeeIDNumber=EmployeesByIDNumber
)
{
// attributes are the actual instance
// variables of this object/record.
attribute long EmployeeIDNumber;
attribute string<NameLen> EmployeeName;
attribute string<NameLen> EmployeeFirstName;
attribute date BirthDate;
// relationships are now defined for
// relationships to other objects in this
// database. Each relationship has a name
// and an "inverse", which is the name for
// the relationship navigating in the
// opposite direction. An Employee
// "worksIn" a Department, and a Department
// "employs" an Employee. Since no collection
// type defined, there is only one Department
// per Employee (1:1 relationship)
relationship Department worksIn inverse Department::employs;
// An Employee "performs" a
Task, and a Task
// is "assigned" to an Employee. The order_by
// clause orders the results by TaskName. The
// set<Task> collection implies this is a
// one-to-many (1:M) relationship, implemented
// with TITANIUM's efficient DPAs. The inverse
// is also one-to-many, so combination is
// actually a many-to-many (M:N) relationship
// (a given Employee performs many Tasks, and a
// Task may be assigned to many Employees).
// Because the collection is a set (as opposed
// to a bag or other collection type) we will
// not allow duplicate elements (i.e., those
// with the same TaskName) to be inserted
// into the relationship.
relationship set<Task> performs inverse Task::assigned
{ order_by TaskName };
// An Employee manages other Employees,
and
// may be managedBy another Employee. Recursive
// one-to-many relationship.
relationship set<Employee> manages inverse Employee::managedBy
{ order_by EmployeeName };
relationship Employee managedBy inverse Employee::manages;
// While biographical data about an Employee
// might be kept with the Employee record,
// for reasons of security and performance
// we will store that information as a
// separate record. Note that this
// relationship is a 1:1 relationship.
relationship Biograph biographyOf inverse Biograph::bioFor;
// For our database, we have three ways
to pay
// the Employees:
// Salaried - Employees with a fixed pay check.
// Hourly - Employees paid per hour of work.
// Commissioned - Employees payed per amount sold.
//
// Wages is the abstract superclass of these
// different pay methods.
relationship set<Wages> wagesOf inverse Wages::emp;
// Define exceptions for the class.
exception NoSuchEmployee {
long EmployeeIDNumber;
};
exception EmployeeHasManager {
long EmployeeIDNumber;
};
// Define C++ methods for the class.
//
// Print the Employee to the screen.
void Print();
// Create records for dependent entities/objects
void add_Biography();
void add_Payinfo();
// Link Employee to related objects
void link_Department();
void link_Manager();
void link_Tasks();
}; |
| End
Figure 10 |
TITANIUM Object Manipulation Language (OML)
- C++ Class Library
An object database, such as the one defined above,
may be manipulated in application code with the TITANIUM C++ Class
Library, as shown in the example below (Figure 11). Collections
and other classes are generated specific to the database from the
ODL definition.
|
Figure 11: Example of object-oriented C++ Class Library code
(OML) |
//*******************************************************************
// File: odmgdemo.cpp
//
// This sample application for the TITANIUM ODMG C++ Class Library,
// based on the Employee/Tasks database, uses many of the classes
// and methods defined in the ODMG library.
//
//*******************************************************************
// Basic definitions for TITANIUM C++ Class Library
#include <tde_cpp.h>
// Class definitions for this database
generated
// from ODL specification
#include "odmgdemo.h"
// Database object.
d_Database *aDatabase;
// Call open() to open the database. The
try & catch
// tell us if there is any error opening the database.
void initDatabase(char* databaseName, char* userName,
char *passWord, char * serverName)
{
try {
aDatabase->open(databaseName,
userName,
passWord,
d_Database::read_write,
"C++
Employee-Task Demo",
serverName);
} catch(d_Error &err) {
cout << "Error opening Database " << endl;
cout << err.what() << endl;
cout << err.where() << endl;
exit(-1);
}
}
// Delete all the employee records
void empDeleteAll()
{
// Dummy instance of Employee
d_Ref<Employee> emp = new (aDatabase) Employee;
// Since modifying the database, wrap
in a transaction.
d_Transaction update(aDatabase);
update.begin();
// Remove all the records of employee.
By removing from
// the extent, the record is deleted from the database.
emp->EmployeesByName.remove_all();
update.commit();
}
// Add an Employee record.
void empAdd(char *empName, long empID)
{
// Create an employee instance, set name,
and ID.
d_Ref<Employee> emp = new(aDatabase) Employee;
emp->setEmployeeName(empName);
emp->setEmployeeIDNumber(empID);
d_Transaction update(aDatabase);
try {
// Since modifying the database, wrap
in a transaction.
update.begin();
// Inserting the record will force a creation
in the database
// since the record does not exist currently.
emp->EmployeesByName.insert_element(emp);
// optionally add biography and wage/salary
data for new emp
emp->add_Biography();
emp->add_Payinfo();
// commit changes to database
update.commit();
// optionally link this employee to department,
manager, tasks
// these functions create their own transactions
emp->link_Department();
emp->link_Manager();
emp->link_Tasks();
// Display the record added.
cout << "The employee record added is: " <<
endl;
emp->Print();
} catch(d_Error &err) {
// Display the error, where and what kind.
cout << err.what() << endl;
cout << err.where() << endl;
// Abort the transaction.
update.abort();
}
} |
| End
Figure 11. |
Relational Model
TITANIUM SQL schemas provide flat, tabular views
of the complex 3-D structure within the physical database. The developer
or database administrator creates SQL schemas in one of three ways:
- Use standard SQL CREATE commands in the TITANIUM SQL DDL (TSDL)
utility.
- Create a Table Definition File (TDF) that maps database elements
to flat tables.
- Use extended SQL commands such as CREATE JOIN interactively
or with TSDL.
TITANIUM TSDL supports full ANSI-standard SQL DDL
commands such as CREATE TABLE, CREATE INDEX, ALTER TABLE. It is
a standalone utility that creates a new TITANIUM database.
Table Definition Files are provided for compatibility
with previous versions of TITANIUM. However, all essential features
of Table Definition Files are available through TITANIUM extended
SQL, including DPA-based joins, writable joins, trigger definitions,
and columns defined through stored procedures.
CREATE JOIN creates a flat SQL view of a 3-D structure
containing multiple objects, as if it were an SQL JOIN of multiple
tables. However, the CREATE JOIN makes use of TITANIUM's DPA architecture
to optimize queries made using this join, providing higher speed
query response times than a join created at run time as with traditional
databases. An example of this command is shown below (Figure 12).
|
Figure 12: Example of CREATE JOIN in TITANIUM SQL |
CREATE
JOIN Dept_Tasks_Emps_Pay_Info
(
Employee.EmployeeName AS Employee_Name,
Employee.EmployeeIdNumber AS Employee_ID,
SalariedEmployeeDetails.Salary AS Salary,
HourlyEmployeeDetails.HourlyRate AS Wage,
CommissionedEmployeeDetails.BaseSalary AS Base_Salary,
CommissionedEmployeeDetails.CommissionPercentage AS Commission,
Task.TaskName AS Task_Name,
Department.DepartmentName AS Department
)
USING (EmployeesByName, Assigned, Earns, Staffed);
CREATE JOIN Employee_Pay_Info
(
Employee.EmployeeName AS Employee_Name,
Employee.EmployeeIdNumber AS Employee_ID,
SalariedEmployeeDetails.Salary AS Salary,
SalariedEmployeeDetails.BenefitsPackage AS Benefits,
HourlyEmployeeDetails.HourlyRate AS Wage,
HourlyEmployeeDetails.WorkShift[1] AS Start_Shift,
HourlyEmployeeDetails.WorkShift[2] AS End_Shift,
CommissionedEmployeeDetails.BaseSalary AS Base_Salary,
CommissionedEmployeeDetails.CommissionPercentage AS Commission,
)
USING (EmployeesByIDNumber, Earns);
CREATE JOIN Assignments
(
Employee.EmployeeName AS Employee_Name,
Task.TaskName AS Task_Name
)
USING (EmployeesByName, Assigned) OR (TasksByName, Assigned)
|
| End
Figure 12. |
Once a relational view of the database is created,
standard query language (SQL) requests can be made to the database
server. Note that once the views are created, the end user need
not be aware of the underlying complexities of the data. The user
(and the front-end SQL tool) sees Employee_Task_Salary as a simple
table, although it contains fields from five physical entity types.
For tables which are built from n-ary relationships, such as Employee_Pay_Info,
NULL values are returned for fields which do not apply. Tables involving
many-to-many relationships, as with the Assignments table, consist
of a row (or tuple) for each DPA connection between the two entity
types.
Simplified SQL Queries
TITANIUM's SQL schemas allow users to design highly
complicated queries with extremely simple SQL statements. The TITANIUM
SQL engine automatically locates the physical entities which make
up a table, without having to specify those entities in a complex
SQL query. Only the name of the table with the pre-joined entities
needs to be specified. The following examples show the simplicity
of SQL statements executed against the TITANIUM table definitions
in Figure 12.
SELECT Employee_Name, Salary, Wage, Base_Salary FROM
Employee_Pay_Info
WHERE Employee_ID<10
SELECT Department, Employee_Name, Task_Name, Salary, Wage, Base_Salary
FROM Dept_Tasks_Emps_Pay_Info |
The last query in a typical relational database
requires a SQL query similar to the following:
SELECT Department.Department_Name, Employee.Last_Name,
Task.Task_Name
FROM Departments, Employees, Salaried, Hourly, Commissioned,
Tasks
WHERE Employee.Department_ID = Department.Department_ID AND
(Hourly.Employee_ID = Employee.Employee_ID OR Commissioned.Employee_ID
= Employee.Employee_ID OR
Wage.Employee_ID = Employee.Employee_ID) AND
Task.Employee_ID = Employee.Employee_ID |
Not only is this query complex to understand, it
requires time-consuming processing at the time of the query to execute.
The TITANIUM query uses the pre-defined joins in the DPA physical
structure to produce the same answer in substantially less time.
Of course, TITANIUM's SQL engine can also do on-the-fly joins if
pre-defined joins do not exist. Create joins can be executed at
runtime using TISQL.
Read/Write SQL
TITANIUM supports full read/write operations via
the SQL INSERT, UPDATE, and DELETE commands to base tables defined
in the SQL schema, as shown below.
INSERT INTO Employees VALUES (10101, `Smith`, `John`,
`Manager`, DATE `1960-4-22`)
UPDATE Employees
SET Last_Name = `Smith`
WHERE Identification_Number = 10101
DELETE FROM Employees
WHERE Identification_Number = 10101 |
ANSI SQL and ODBC Standards
The TITANIUM SQL language follows the ANSI SQL-92
and Microsoft ODBC standards. The SQL call level interface is a
driver that implements Microsoft ODBC standard calls such as SQLConnect()
and SQLExecute(). Developers can use this driver to embed ODBC-compliant
SQL calls into applications. Similarly, users can access TITANIUM
databases through any ODBC-compliant tool, such as Microsoft Excel.
For more complex query needs, TITANIUM's SQL query
optimizer can call into the C/C++ stored procedures engine. The
virtual and user-defined fields created in this manner offer limitless
flexibility while maintaining ODBC data definition compliance.
Navigational Model
The developer, using the navigational model, accesses
TITANIUM through an extensive set of simple, straightforward APIs
or library calls. TITANIUM API commands like TDE_SetOwnerToMember
tell the database engine to utilize DPAs rather than executing lookups
into large indexes. TITANIUM navigational model commands are also
bi-directional. For example:
TDE_FindFirstMember("Manages") finds
the first instance of an employee managed by the current employee
and TDE_FindFirstOwner("Manages") finds the first (and
only) manager of the current employee.
Figure 14 shows some of the extensive sets of commands
available to the developer through the navigational API.
| Figure 14: Examples of TITANIUM
Navigational APIs |
TDE_OpenDatabase
TDE_CloseDatabase
TDE_AbortTrans
TDE_AllocateUser
TDE_BeginTrans
TDE_CommitTrans
TDE_CreateRecord
TDE_DeleteCurrent
TDE_ExecuteCSP
TDE_ExpandArea
TDE_FindFirstByHashKey
TDE_FindNextByHashKey
TDE_FindNextMember
TDE_FindNextMemberByItem
TDE_FindNextMemberBySortKey
TDE_FindNextOwner
TDE_FindNextOwnerByItem
TDE_FindNextOwnerBySortKey
TDE_FindNextSequential
TDE_FindPriorMember
TDE_FindPriorMemberByItem
TDE_FindPriorMemberBySortKey
TDE_FinishDatabase
TDE_FreeCurrentLock
TDE_FreeLocks
TDE_FreeSetLock
TDE_FreeUser
TDE_GetAreaFileName
TDE_GetAreaInfo
TDE_GetCurrentItem
TDE_GetCurrentType |
TDE_GetCurrentValueLabel
TDE_GetDatabaseAvail
TDE_GetDatabaseStats
TDE_GetDbKey
TDE_GetEngineInfo
TDE_GetExtendedDatabaseStats
TDE_GetExtendedErrorInfo
TDE_GetExtendedErrorString
TDE_IntersectMembersMembers
TDE_IntersectMembersOwners
TDE_IntersectOwnersMembers
TDE_IntersectOwnersOwners
TDE_LockCurrentExclusive
TDE_LockCurrentWrite
TDE_LockRecordTypeExclusive
TDE_LockRecordTypeWrite
TDE_LockSetExclusive
TDE_LockSetWrite
TDE_LogMessage
TDE_SetEngineMemory
TDE_SetEngineOptions
TDE_SetImageFile
TDE_SetLogFile
TDE_StartRemoteDatabase
TDE_StopRemoteDatabase
TDE_PrepareTrans
TDE_GetCurrentBlob
TDE_DeleteRecord
TDE_GetRecord
TDE_PutRecord
TDE_PutItemRecord |
| End Figure 14. |
Third and Fourth Generation Languages
TITANIUM has library interfaces to numerous languages
and compilers. Supported languages include C, C++, COBOL, Borland
Delphi, and Visual Basic. For DOS, NLM, and UNIX, a direct-link
library is used to resolve embedded TITANIUM API calls. For Windows,
Windows 95, Windows 98, and Windows NT, the TITANIUM API calls are
supplied as a dynamic link library (DLL). Migrating an application
from stand-alone to client/server, or from one network protocol
to another (e.g., from Novell IPX/SPX to TCP/IP), is a simple matter
of changing the TITANIUM library, no application code changes are
required.
MDBS IV Applications
With an available compatibility feature, users
of the MDBS IV® network database find TITANIUM a natural, seamless
migration.
TITANIUM Schemas
The demands of software applications and databases
are becoming more complicated. In addition to the simple data structures
needed to support concepts like mailing lists and balance sheets,
databases must support complex structures, such as those required
for parts explosion and bill of materials problems. Support for
unstructured data is also required to manage pictures, sound, and
other elements commonly used by multi-media applications. In situations
where a single database repository is needed to manage complex data,
it is necessary to use a database engine which is designed for these
requirements. Use of either a relational database product which
has been given certain object-oriented "extensions," or
an object-oriented database with limited SQL support may not provide
the necessary performance or functionality for demands beyond the
original design of the product.
TITANIUM's data modeling layers provide logical
views of the data which are "mapped" into the physical
database. A high-level entity-relationship data model can be mapped
into relational or navigational models. An object-oriented data
model can be mapped into object-oriented and relational models as
well.
Entities, relationships, referential integrity,
and database optimization features are specified in a TITANIUM database
design or schema. Developers have several mechanisms for building
TITANIUM schemas. One way is to create a text file containing TITANIUM
DDL (Data Definition Language) or TITANIUM ODL (Object Definition
Language) commands. Relational SQL schemas can be created with the
TITANIUM SQL Access Manager component, TSDL.
TITANIUM also has a database restructuring tool
(TDBRS) for changing the physical database schema. TDBRS automatically
modifies all database objects affected by the changes.
TITANIUM Employee-Task Example Database
The following examples (Figures 15-16) use the
Employee-Task example database shown in the entity-relationship
data model below.
 |
| Figure 15: Employee-Task
Example Database |
This example (Figure 15) illustrates a company
with Employees who work in Departments. Each Employee is assigned
one or more Tasks. A single Task may be performed by many Employees.
An Employee may manage other Employees. Employees may be paid in
a variety of ways, including an annual salary, hourly wage, or sales
commission. An Employee may have an optional Biography.
While not a large data model, this example shows
the complex relationships that TITANIUM can model with ease, including
one-to-one (Biography), one-to-many (WorksIn), many-to-many (Assigned),
recursive one-to-many (Manages), and recursive many-to-many (Subtask).
Object-oriented inheritance is implemented for the Commissioned,
Hourly, and Salaried Employees.
Example: TITANIUM Entity-Relationship Data Definition
Language (TDDL)
The TDDL definition is a physical database design
that specifies the entities, attributes, and the relationships between
them, as well as information about the physical database characteristics.
The developer or database designer writes a Data Definition Language
(DDL) script to describe the entities and relationships within the
database, as shown in this example (Figure 16).
| Figure 16:
Example of a partial TITANIUM Data Definition Language (TDDL) |
entity Employee
attribute Identification_number unsigned 4 /*
4 byte unsigned integer */
attribute Last_name string 40 /* variable
length, compressed */
attribute Middle_initial char 1 /* fixed
length */
attribute First_name string 20
attribute Birth_date date /* automatically
compressed */
entity Task
attribute Name string 80
attribute Priority_level integer 1 /*
1 byte signed integer */
entity Salaried_employee
attribute Salary idec 9,2 /* idec = Internal
DECimal */
/* 9 digits, 2 digits past decimal point
*/
attribute Benefits_package string 250
entity Hourly_employee
attribute Hourly_wage idec 4,2
attribute Shift time occurs 2 times /*
array of 2 time stamps */
entity Sales_employee
attribute Base_salary idec 9,2
attribute Commission_percentage real 2 /*
2 byte floating point value */
relationship Employees /* primary
index on employee entities */
type 1:M
owner System /* system relationships are
equivalent to indexes */
member Employee
order sorted ascending by (Last_name, First_name, Middle_initial)
relationship Assigned /* connects employees
to their assigned tasks */
type M:N /* relationship type is many-to-many
*/
owner Employee
order sorted ascending by Identification_number
member Task
order sorted ascending by (Priority_level, Name)
relationship Manages /* recursive relationship
for building management hierarchy */
type 1:M /* relationship type in one-to-many
*/
owner Employee
member Employee /* owner and member types
are the same, indicating recursion */
order sorted ascending by Identification_number
relationship Is_Paid /* connects an
employee to his/her compensation record */
type 1:1 /* relationship type is one-to-one
*/
owner Employee
members (Salaried_employee, Hourly_employee, Commissioned_employee)
/* n-ary relationship */
|
| End Figure
16. |
In this example TDDL script (Figure 16), pay close
attention to the comments, which illustrates TITANIUM's power and
flexibility. Also note that the script is not a complete schema
and that many optional clauses have been excluded to keep the example
as simple as possible.
The example illustrates how complex relationships
are easily implemented in TITANIUM without redundant keys, intersect
tables, or joins. However, if the developer requires a redundant
key or intersect table for logical reasons (such as with relational
or hierarchical views), TITANIUM supports these structures.
TITANIUM Reliability
Modern online transaction processing (OLTP) applications
have demanding integrity and security requirements. TITANIUM meets
these demands by providing:
- Complete reliability against any kind of hardware failure or
other disaster.
- Real-time, mission-critical performance for the smallest peer-to-peer
workgroup networks to the largest wide-area networks and clusters.
Transaction Logging (Roll Forward)
Provided that TITANIUM supports bracketed transactions, ensuring
that the ACID properties of atomicity, consistency, isolation, and
durability for all database operations. The database server writes
all relevant information for each transaction which modifies the
database to a transaction log (or journal) file. In the event database
recovery is necessary, the most recent backup can be restored, and
the TITANIUM transaction recovery program can be run to reapply
(or roll forward) all database modifications since the last backup
using the log file(s). Since the recommended practice is to put
the log file on a separate disk device, logging also protects from
physical disk media failures.
Fault Tolerance (Roll Back)
For online transaction processing requirements, TITANIUM has an
integrated fault tolerance mechanism ensuring a quick recovery from
service interruptions such as power failures. With this feature,
whenever a change is made to the database, the modified database
page is captured in its original state in a page image file (PIF).
The PIF is reset at short, defined intervals when the database is
in a physically and logically consistent state. If a service interruption
occurs, all incomplete transactions which have modified the database
since the last complete transaction are effectively eliminated by
restoring the pages in the PIF to the database (roll back). When
the database is restarted, the database engine checks for the indication
of an abnormal termination. The engine automatically restores the
PIF pages to the database, re-establishing a consistent and usable
state. Recovery up to the last complete transaction is assured even
if multiple overlapping transactions are outstanding at the time
of the failure. All page image operations, as well as transaction
logging operations, are automatic and completely hidden from the
user.
Abortable Transactions
All TITANIUM transactions are abortable through user command. If
one of a series of logically related operations fails for any reason,
the entire series can be backed out. Object, relational, and navigational
developers implement transactions through the standard transaction
commands for their language. This capability uses the page image
mechanism described above for maximum efficiency and throughput.
Nested Transactions
TITANIUM transactions may be nested inside one another to provide
transaction protection within nested modules of application code.
Two-Phase Commit
TITANIUM supports the two-phase commit protocol for operations crossing
multiple databases. Begin, Prepare, Commit, and Abort phases are
supported with the TITANIUM TDE_BeginTrans, TDE_PrepareTrans, TDE_CommitTrans
and TDE_AbortTrans commands.
Online Backup
The TITANIUM database server permits database file backups to be
performed without any interruption to user interaction with the
database. Automatic data compression can be turned on or off by
the database administrator. A replaceable device communications
layer permits backups to be made to disk, tape, or any other device
for which a device driver can be created.
Online Validation
The TITANIUM database server also performs online checks of database
validity and consistency while users are actively accessing the
database. Corrections to inconsistencies can be made automatically.
TITANIUM Features
Stored Procedures
Stored procedures are pre-written routines stored and executed by
the database server. An application can invoke the execution of
a stored procedure with an explicit call from a client workstation.
By executing a group of database functions via a stored procedure,
network traffic is reduced significantly, thus improving overall
performance.
The database server dynamically calls in a C library
compiled by the developer (see Figure 17a & 17b), passing any
kind of input and/or output block. C compiled routines provide maximum
32-bit performance and flexibility for a stored procedures language.
Developers can design integrity rules for the database, perform
calculations and analysis, issue remote procedure calls to other
databases, and so on.
TITANIUM uses the advanced protection features
available in each operating environment, such as Structured Exception
Handling under Microsoft Windows NT, to ensure that programming
faults do not interrupt the server or affect other processes.
Triggers
Triggers are stored procedures automatically invoked when data in
a relational TITANIUM table is selected, inserted, updated, or deleted.
Triggers ensure logical data integrity in a complex data model.
Extensive Data Type Support
TITANIUM provides extensive data types including UNICODE, VARUNICODE,
internal decimal (fixed or BCD decimal), binary, real, character,
string (compressed variable-length character), time, and date types.
The TITANIUM DATE 3 type allows dates ranging up to 10,000 years,
capabilities beyond Year 2000 compliance, and provides the ability
to handle calendar applications covering extensive periods of time.
Binary Large Objects (BLOBs)
For very large text and binary data items, TITANIUM provides a Binary
Large Object (BLOB) data type that can store single items ranging
up to two gigabytes in size. BLOB items span database pages and
can be stored with DPAs, allowing efficient access to any part of
the BLOB while still allowing the application to logically view
the BLOB as a single data item.
Very Large Databases
Individual TITANIUM databases can be up to a terabyte in size, with
no limits on the size of tables or collections of objects. Applications
using multiple databases can have an even larger capacity. TITANIUM
supports 64-bit file systems on those operating environments with
capabilities such as NTFS.
Windows NT Integration
TITANIUM is designed for full integration into the Windows NT environment,
with a graphical interface for server administration and optimizations
specific to Windows NT. The database server runs as a Windows NT
service, providing for fully automatic operation upon system startup,
link to performance counters, as well as control through standard
Windows NT facilities.
Administrative API
A programmable API interface is included for starting and stopping
databases and servers, controlling on-line backup and validation,
and other online administrative functions. This feature allows full
embedding of the database operations in the application as well
as creation of simple application-specific interfaces for end users.
| Figure 17a: Example client code
to call C stored procedure |
/********* example client code to
call C stored procedure ********/
#include <stdio.h>
#include "tde_api.h"
int status;
struct _trans_in_ tin;
struct _trans_out_ tout;
.
.
.
/* setup data for transfer, including */
/* source account, destination account*/
/* and amount to transfer */
.
.
.
/* call stored procedure */
status = TDE_ExecuteCSP("Transfer", &tin, &tout);
/* process returned data */
if (!status) { printf(tout->acct.name);
printf(tout->acct.number);
} else {
/* error returned */
} /* end of client function
*/ |
| End Figure 17a. |
| Figure 17b: Example server code
to execute C stored procedure |
/******* example
server code to execute C stored procedure ********/
#include <stdio.h>
#include "tde_csp.h"
int status;
struct _trans_in_ tin;
struct _trans_out_ tout;
unsigned ui;
unsigned long localTime;
.
.
.
/* stored procedure code */
int Transfer(NULL,
struct _trans_in_ *tin,
struct _trans_out_ *tout)
{
/* get TITANIUM source account record
*/
status = TDE_ObtainMemberBySortKey(
"accountsByID", tin->sourceAcct);
if (status) {
/* return error */
}
ui = 1;
/* save off TITANIUM database key of source
account */
TDE_SetUserIndToCurrent(&ui);
/* get TITANIUM destination account record
*/
status = TDE_ObtainMemberBySortKey("accountsByID",
tin->destinationAcct);
if (status) {
/* return error */
}
/* get system clock time */
localtime(&localTime);
/* start transfer with TITANIUM Transaction
*/
while (status = TDE_BeginTrans());
tin->sourceAccount.balance -= tin->amount;
tin->sourceAccount.timestamp = localTime;
tin->destinationAccount.balance += tin->amount;
tin->destinationAccount.timestamp = localTime;
tout->destinationAccount.balance = tin->destinationAccount.balance;
/* update TITANIUM destination account
record */
if (status = TDE_PutCurrent(&tin->destinationAccount))
{
/* return error */
}
/* retrieve TITANIUM address of destination
account */
TDE_SetCurrentToUserInd(&ui);
/* update TITANIUM source account record
*/
if (status = TDE_PutCurrent(&tin->sourceAccount)) {
/* return error */
}
/* commit TITANIUM Transaction */
status = TDE_CommitTrans();
if (status) {
/* return error */
}
return 0;
}
/* end of server function */ |
| End Figure 17b. |
TITANIUM Environments
Client/Server Architecture
Client/Server architecture separates front-end client applications
from back-end database servers. The client controls the user interface
of the application and makes requests, or calls, to the database
server, including queries or update transactions. The database server
controls all database file I/O, user contention, record locking,
optimization, and security.
|
| Figure 18.
TITANIUM client/server and thin client architecture |
Developers can use numerous combinations of development
languages, API sets, client operating systems, network protocols,
and database server machines. If additional database server throughput
is required, the server can be moved to a different environment
without any changes to front-end applications. A server machine
can run multiple database servers, depending on system resources,
due to TITANIUM's extremely low resource usage. While most database
server products require 16-128M of RAM, the TITANIUM database server
load image is less than 400K, allowing a greater percentage of real
memory to be used for page buffers or disk cache, and thus improving
performance and reducing hardware costs. The TITANIUM server can
handle over 1000 users simultaneously on a single database.
Thin Client Architecture
TITANIUM supports server-based (thin client) application architecture
as well as traditional client/server architecture. In the server-based
architecture, application logic residing on the server uses the
fast, efficient TITANIUM shared-memory interface to interact directly
with the database server at memory access speed. Applications using
multi-tier or application specific communications architectures
can be implemented efficiently as well with this interface.
Stand-Alone Version
TITANIUM is also available in a stand-alone version for Windows
and all of the database server operating systems. For all of these
environments, multiple user contexts are supported, complete with
transaction processing and contention features, allowing multi-user
application development to occur on a single machine. And since
the TITANIUM database libraries require less than 400K of RAM, sophisticated
applications can be distributed on modestly configured machines.
Stand-alone and multi-user versions of TITANIUM
use the same database file format and API calls, allowing applications
to be fully scaleable from single-user PCs to large client/server
configurations.
Stand-alone applications on database servers can
perform batch operations with unsurpassed speed, simultaneous with
client/server operations and independent of any client.
TITANIUM Modules and Utilities
TITANIUM is a complete database development system
for professional application developers. Numerous modules are available
to assist in TITANIUM development efforts.
TITANIUM Database Engine: The core module
of TITANIUM, the database engine performs all database I/O operations,
user contention and currency control, record locking, security,
integrity, transaction processing, fault tolerance and all other
functions central to the database server.
TITANIUM SQL Access Manager (TDESQL): This
module provides the SQL server components, ODBC interface, TSDL,
and drivers for TITANIUM. With this module, users query TITANIUM
databases with any ODBC-compliant tool.
TITANIUM Interactive SQL module (TISQL):
This module is an interactive SQL query utility for developers to
perform ad-hoc SQL queries against the database without requiring
a separate ODBC front-end utility.
TITANIUM Network Communications Servers
(TDENET): These modules are used to connect remote client workstations
to TITANIUM database server machines via industry standard network
protocols. Supported protocols include NetBIOS, Novell IPX/SPX,
WinSock2 IPX/SPX Named Pipes, and TCP/IP.
TITANIUM Data Definition Language (TDDL):
Developers use this module to create the physical and network model
database schemas. The module takes a TDDL script consisting of entity
and relationship definitions to create a new TITANIUM database.
TITANIUM Transaction Recovery module (TDRCV):
This module is used to recover from lost or corrupted database files.
Transactions are recovered using a roll forward process from a log
file to a backup copy of the database. The log files are generated
by the database engine module.
TITANIUM Database Administration module
(TDBADM): Administrators use this tool to make database backups,
create and change user passwords and security levels, create new
database files, reset and create new log files, compile database
storage statistics, view the database schema, and repair physically
damaged database files.
TITANIUM Database Restructuring system (TDBRS):
This module is used by developers and database administrators to
make changes to the physical database structure. In addition to
creating, deleting and modifying entity and relationship definitions,
this module can also be used to recapture fragmented free space,
balance indexes and DPAs, and rebuild logical data clusters.
TITANIUM Database Interactive Manipulation Language
(TDIML): Used by developers, this module allows individual data
manipulation language (DML) calls to be made against the database
without the need for a program. TDIML is ideal for quickly testing
database code logic before implementing it in a program or for making
quick modifications to a database.
TITANIUM Language Interfaces: Numerous API
libraries are available for developers to embed TITANIUM database
function calls into application programs. Libraries are available
for C, Microsoft Visual C++, Microfocus COBOL, Visual Basic, and
Borland Delphi.
TITANIUM C++ Class Library: Object-oriented
class interface to TITANIUM implementing the ODMG standard including
the ODL and OML components for C++.
For Additional Information
For downloadable documentation for TITANIUM and related products, click here.
To purchase TITANIUM-related tools, click here.
For additional information about purchasing the TITANIUM development system
or other mdbs products, contact:
Savitar Corporation
Copyright 2000-2003 Micro Data Base Systems, Inc.
Copyright 2004 Savitar Corporation
This
material is provided for the use of the customer and the customer's
employees. No part of this documentation may be reproduced by any means.
TITANIUM®
is protected by U.S. Patent Nos. 5,611,076 and 5,713,014,
in addition to any patent applications pending.
TITANIUM®,
MDBS IV® , MDBS III®, KnowledgeMan®, GURU®,
and Object/1® are registered trademarks.
All
other brands and product names may be trademarks or registered
trademarks of their respective holders.
|
|
|
|
