Short Introduction to the RDBMS Software Redundancy Proposal PROBLEM / GOAL: avoid any loosing of up-time service of an application using either commercial or non-commercial databases due to yet uncovered and undiscovered bugs in database middleware. PROPOSED SOLUTION: Do make use of a redundant approach in the use of the database middleware by diversifying databases, schemas in the databases, relational or non relational data models, or using explicitly modifiers of any kind to SQL statements. The “Multiple Paths” model is proposed: do use multiple different paths and algorithms to access the very same data beneath them all.

Handler Schema 1. Oracle 11g Handler Schema 2. MS SQL Server 2008 Schema 3. IBM DB2 Schema 5. Flat Files Data Model (Critical data access path) Solution A: multiple databases paths Databases Pool Application Handler Schema 4. Ingres, PostgreSQL, etc… Application DB Pool Managers (N managers)

Application DB Pool Managers (N managers) Handler Schema 5. Flat Files Data Model (Critical data access path) Handler Schema 1. Full Relational Data Model Handler Schema 2. “Snow-Flake” Data Model (Partially Denormalized) Handler Schema 3. “Star” Data Model (Completely Denormalized) Handler Schema 5. Oracle Object-Oriented Relational Data Model (i.e. Oracle “Types”) Solution B: multiple access paths e.g. in Oracle Oracle Handler Schema 4. “Multi-dimensional” Data Model (DWH non relational alike)

Solution C: e.g. multiple Oracle statements paths It is a FACT that Oracle SQL statements may be modified by: Choosing the optimizer: RULE, CHOOSE, ALL_ROWS, FIRST_ROWS, etc… Using hints: /*+index …*/, /*+parallel …*/, etc… Using Analytical functions instead of sub-queries Using Semi-joins and Anti-joins instead of sub-queries Using WITH clause … other ways …

Solution D: e.g. multiple paths via Oracle procedures It is a FACT that Oracle SQL statements may be embedded in PLSQL code: PLSQL is interpreted by DIANA, which is modeled following ADA. In PLSQL procedures in a package you may use: Embedded SQL Statements Dynamically created views TEMP Tables Associative arrays and PLSQL (memory) Tables Oracle Types … etc etc …

Henceforth: 1)Combining all of these observations, on average we have hundreds (100’s) of magic paths per statement 2)Attach a probability and a time-out to each path 3)Do compute explicitly for all paths, sum up contributions. The Proposed Solution will have (minimally) the following features: A)An abstract DataModel generator  The input DataModel is entered and checked and from it, iteratively if needed, the whole number of different “paths” is generated. B)A software interface consisting of either the DBO (Dynamic Business Object) model (presented in the dbo.zip file) to represent data-types (intrinsic architecture) or a pre-compiler able to adapt to existing concrete objects and able to generate adapted concrete classes (extrinsic architecture). C)A software interface consisting of the DB pool managers and handlers specific to commercial and non-commercial databases alike (as well as platforms).