SIRA_PRISE benefits and advantages

A new DBMS is not very useful unless it offers opportunities to its users that other DBMS's don't have.  This section explains how two of SIRA_PRISE's main features can translate into very significant cost cutting for its users : its support for database constraints of arbitrary complexity and its support for temporal data.  We also give an indication how these facts translate into figures.

Database constraints of arbitrary complexity

Unlike any other existing DBMS known today (*), SIRA_PRISE offers support for the functionality that is equivalent to the CREATE ASSERTION statement of the SQL standard.  What this essentially means, is that SIRA_PRISE users no longer have any need for application-enforced integrity.  You can declare just any constraint, and SIRA_PRISE will enforce for you that the data will never violate that constraint.  No programmer has to write one single byte of code to achieve that.  Meaning that you need less programmers to complete your projects.  No programmer can still make any mistakes in writing all that application-enforced integrity code.  Meaning that you need less testing effort to complete your projects.  No testers can still make the human error of overlooking some test scenario that happened to have been needed to detect an error that was indeed present.  Meaning that less errors will make it to the production stage of your application, meaning that your applications will become much more reliable and stable.

To illustrate the point, we refer to the AM4DP book mentioned in the introduction.  That book provides a fully worked-out example of all the things it takes to bring database constraint validation inside an SQL DBMS, using the mechanism of triggers.  A database constraint as simple as "each customer must have at least one address", imposed on a database with two relvars, customer and address, can easily grow several pages of code tall when implemented "the SQL way".  In SIRA_PRISE, it's just a matter of declaring a formula as simple as "SEMIMINUS(CUSTOMER,ADDRESS)" as being a database constraint.  The SQL way can take hours of work to get it right, certainly if you include the testing part, with SIRA_PRISE, you're done in a matter of seconds.

(*) With the exception of Rel, which is also a fully-and-truly relational DBMS, but which we disregard here because unlike SIRA_PRISE, its main intended area of use is in educating the theory.  SIRA_PRISE intends to turn that theory into practice.

Temporal data

The need to keep records of "history data" is visibly growing in the IT world.  All over the world, database designers are ever more frequently confronted with the need for including history data in their databases.  Everyone who has already tried this, knows that this is not a trivial thing to do using any of the SQL-based systems known today.  And that is equally true of that "other" kind of history data, namely the history of which data have been recorded in our databases, "bitemporal" data, to name it by its hot-topic-of-the-momoent name.

SIRA_PRISE makes life easier for the database designer by offering support for interval types, combined with support for a set of operators that is commonly known as "Allen's operators".  The advantages that SIRA_PRISE has over SQL-based systems may often seem small, but they are so numerous that when taken together, there cannot be any doubt that technology such as SIRA_PRISE's cannot be missed when dealing with temporal data, as is illustrated by the following table, comparing the database design tasks involved in a few of the most common kind of requirements when dealing with temporal data :

Temporal data management feature. SIRA_PRISE SQL
Temporal keys to guarantee non-overlap of tuples. Declarative.  Include the interval-typed attribute in the declared key and you're done. Procedural.  Extra triggers have to be coded (or extra application checks have to be included in each application) to find any overlap.  Only exception are the engines that already implement the temoral features of the new SQL:2011 standard.  At the time of writing, the count of the engines known to do this is 1.  Things will obviously be moving in this area.
Autopack ("temporal coalescing") of relations. Automatic.  No code needed. Procedural.  Extra triggers have to be coded to find rows that are "mergeable".  And depending on the limitations imposed by the particular DBMS system of what and what cannot be done inside triggered code, it may even be simply impossible, pushing the implementation of the feature toward the application.  The new SQL:2011 standard does not include such a feature either, so it is not unreasonable to expect that no industrial engine will include any such support in the short or mid-term future.
Temporal RI to guarantee the integrity of an FK throughout an entire period of time. Declarative just like any other database constraint. Procedural.  Extra triggers have to be coded to look up the corresponding data, and verify the inclusion property of both time periods involved. Only exception are the engines that already implement the temoral features of the new SQL:2011 standard.  At the time of writing, the count of the engines known to do this is 1.  Things will obviously be moving in this area.

Getting from facts to figures : the business case

From the foregoing, it should be clear where the potential cost savings are : there are massive numbers of lines of code, that do need to be written down with currently available technology, but no longer need to be written down with SIRA_PRISE.  But what does that  mean of in terms of man-months, which is the same as talking in terms of hard cash ?

Following activities occur in any software development project : requirements analysis & high-level design, detailed design & coding & unit testing, acceptance testing & deployment (user training, installation, ...).  Typical distribution of time spent on each could be something like 30% / 50% / 20%.  In a hypothetical 50 man-month project P, this means : 15 man-months analysis & design, 25 man-months coding & unit testing, 10 man-months acceptance testing & deployment.

In the requirements analysis phase, it should be clear that SIRA_PRISE will make little difference.  If you just don't understand your user, no DBMS can ever help you overcome that.

In the high-level design phase, SIRA_PRISE might help materialise some benefit, because of its much better and cleaner separation between logical and physical design.  SIRA_PRISE allows you to specify a logical design, without forcing you to specify the physical design at the same time.  So to a certain extent, SIRA_PRISE can also take on the role of "integrated database design tool", replacing whatever E-R tools (and workflows !) that you are using now for that purpose.  These gains, if any, are however likely to be comparatively small (and at any rate, SIRA_PRISE certainly doesn't have a graphical component for visualising database designs).  Little changes are to be expected for our 15 man-months analysis & design.

Intuitively, the same can be said for the acceptance testing & deployment phase.  It would be curious if any DBMS had some quality that made the applications built atop that DBMS lend themselves better to user acceptance testing, let alone to user training of the new system ...  So switching to SIRA_PRISE will not change anything to our 10 man-months of acceptance testing & deployment either.

But what about the other 25 man-months of coding & testing ?  Most modern software applications are built according to some kind of multi-layer structure, usually consisting of at least a layer of UI code (the "presentation layer"), a business layer, and some kind of data access layer.  Typical distribution of time spent on each could be something like 45% / 35% / 20%.

Of these, it will be intuitively clear that the least potential for cost savings are in the presentation layer.  It is not a typical feature of DBMS's to help you design your user screens, your user reports, etc. etc.

Now what about the business layer ?  The largest chunk of code in this layer concerns itself with the enforcement of business rules.  As has already been established, SIRA_PRISE has the power to do this all by itself.  So the largest chunk of the man-months needed for "enforcing business rules" can simply be eliminated alltogether from the project plan.  Savings for our 50 man-month project : 35% of 25 man-months = 8.75 man-months.  Round it down to 8, so we have some time left for doing stuff like "sending e-mail notifications upon certain events occurring".

And what about the data access layer ?  There we can be very short : a good DBMS _IS_ that data access layer.  That was the entire point of Codd's idea of "separation between logical and physical model".  A database, and a DBMS, if and when used properly, simply eliminates the very need for any kind of data access layer coded separately.  SIRA_PRISE supports and encourages exactly that.    Savings for our 50 man-month project : 20% of 25 man-months = 5 man-months.

Concrete consequence for our 50 man-month project : minus 13 man-months, or minus roughly 25% of the overall development cost.  At 6000 EUR per man-month, that's minus 780000 EUR for a project comparatively modest in size ...

Conclusion : we deliberately leave this open.  You're free to draw your own.