From: deacon@apelc5.inf.ethz.ch (Andrew Deacon)
Subject: Re: Date's 12 Rules for DISTRIBUTED databases
Keywords: distributed database
Organization: Dept. Informatik, Swiss Federal Institute of Technology (ETH), Zurich, CH
Date: Mon, 28 Sep 1992 20:32:38 GMT

Evaluating DATE's 12 Rules for Distributed Databases makes for an interesting
debate. What I want to add here is some of Date's more recent comments on his
"rules". The problem with evaluating products using the "rules" or as Date
now prefers to call them, objectives, is that its difficult because each
system does things differently. Consequently one tends to favour the system
one knows best as one does not immidiatly think of other ways of doing 
things.  There is no guarantee that Date is right either! 
I have added a few of my comments about Ingres (but have not changed
the score as I don't believe they are very useful).


>In article <a#4nvr=.tcox@netcom.com> tcox@netcom.com (Thomas Cox) writes:

>The topic had been commercial products, so I spoke only of commercial
>products -- Ingres 6.4, Informix 5.0, Sybase 4.x, and the like,
>including Oracle 6.0 and 6.2.  If one allows non-commercial software to
>be considered, the unquestioned winner must be Oracle v7.  (Some of you
>wondered if I thought otherwise.  Hardly.)

>The classic rule of thumb evaluation of a distributed relational
>database was offered by C.J. Date in his "12 Rules for Distributed
>Database", a follow-on to Codd's earlier 12 rules for relational.

>Here is a re-posting of Date's 12 Rules, and my own evaluations as to
>how Ingres and Oracle stack up.  

>The quick score:  	Oracle 6, 6.0 rules (8 if you're generous)
>			Ingres,   6.5 rules (7 if you're generous)
>			Oracle7, 10.0 rules (10.5 if you're generous)
]                       Informix  9.0 rules (10 if you apply a transaction 
]						monitor for rule #12)

In addition paulwo@informix.com (Paul Wolmering) has  "scored" informix
which will be indicated by ]


>		DATE's 12 Rules for Distributed Databases

In Date's new book "Relational Database Writings 1989-1991" he comments in
a footnote on p 486 that he now wished he had been a little more circumspect
in his choice if the term "rule" as it sounds too dogmatic! The word 
"objectives" is now sugested as a milder replacement. He then quotes the 
origional articel which said "There is probably no such thing as the ultimate 
distributed system...different users will attach different degrees of 
imortance to different rules [or objectives] in the list."

>Rule 0: A distributed database should look no different than a database
>that is not distributed.

>	v6 PARTIAL ('yes', but read-only)
>	v7 YES
>	Ingres YES
]       Informix: Rule 0????


>The implication here is that the *users* of the database, either people or
>applications, should be shielded from the fact of the database being
>distributed.  (Those databases that must hard-code data locations into
>triggers, i.e. Sybase, cannot truly be said to comply with this rule.  Note
>that Oracle v7 triggers avoid this error.)

This is not realy a rule, but the fundamental principle of distributed 
databases.  When one should say YES or NO to a given system is unclear. 
One could though indicate if one of the system goals is to provide such a 
facility. Sybase provides few such promisses to system developers, while
Ingres/Star and Oracle v7 (and some others) promisses a lot.
If Informix gets so many YES's for the other objectives it must also be
included here too.

>Rule 1: Local Autonomy; Local data is owned and managed locally
>with local accountability and security.  Local operations remain local and no
>site should depend on another for successful functioning.

>	v6 YES
>	v7 YES
>	Ingres NO
]       Informix YES

I am a little confused why Ingres gets a NO here as all Ingres/Star databases
must be created and owned by local users of the various nodes. There is no
problem with contining to use local databases once tables have been registered
with some Star database. There are a number of academic articles that
classify the Ingres/Star as a federated DBS which implies local autonomy.
[see ACM Computing Surveys Sep 1990]

>Rule 2: No Reliance on a Central Site; All sites must be treated as
>equals, with no reliance on a master site.

>	v6 YES
>	v7 YES	
>	Ingres NO
]       Informix YES

>Note that this Rule is not a reference to a two-phase commit coordinator, but
>rather to the idea of a SINGLE central "daddy" machine.  Ingres*Star, for
>example, requires that one site be the "daddy" site that maintains a master
>list of all database objects and resources.  Thus, Ingres' latest product fails
>Rule 2; ORACLE versions 5, 6, and 7 all pass Rule 2.

While Ingres uses one process (Ingres/Star) to coordinate the distributed 
operations, this does not mean that there can only be one such process. 
Ingres does not support any data replication mechanism or distributed triggers.
A consequence of this is that it cannot replicate its data dictionary for the
distributed database.  Thus the centralized architecture is a result. However, 
one could very easily create copies of the data dictonary on every site with 
Star processes running at each. Here there is no SINGLE central "daddy" 
machine. 

Ingres does not automatically ensure that all remain consistent. This must 
be performed manually. I don't know how big a practical problem this is, 
but this problem of maintaining between data dictionaries on different 
sites is largely unrelated to this objective ("rule"). 


>Rule 3: Continuous Operation; There should never be any need for a
>planned shutdown, so that installations at one site should not affect
>operations at another.  New installations should not affect existing
>programs, nor should removing a node from service cause interruptions in
>service.  Portions of databases should be able to be created and
>destroyed without stopping any component.

>	v6 YES
>	v7 YES	
>	Ingres PROBABLY YES
]       Informix YES

>This is a reference to several features, such as site autonomy and the ability
>to activate or de-activate a node without having to take some central "daddy"
>database offline to be modified.  Any node can create or modify its own
>resources and need neither (A) register this with any central authority such as
>a central data dictionary, nor (B) shut down other nodes.


>Rule 4: Location Independence; Users should not have to know where data
>is physically stored and should be able to act as if all data were
>stored locally.

>	v6 PARTIAL (i.e. only if the read-only limitation is acceptable)
>	v7 YES
>	Ingres Yes in theory; NO in practice
]       Informix YES

>Most commercial Ingres sites seem to have hard coded data locations into
>their applications, to avoid the network delays that Ingres' Master-
>Slave architecture forces.

In Date's book [see above] he identifies five levels and gives Ingres/Star
as an example of the highest level while Informix is on the third. Some systems
like DB2 have support for multiple levels. I guess that even with these
facilities application developers may choose a lower level of independance
to improve performance, but this will always happen and should be possible.

>Rule 5: Fragmentation Independence; Relations between data elements
>should be able to be fragmented for physical storage.  Nonetheless,
>users should be able to act as if data were not fragmented.

>	v6 NO
>	v7 NO
>	Ingres PROBABLY NO
]       Informix NO

Ingres does provide views that can be JOINs and UNIONs of tables on
different sites. This does provide some form of fragment independence
but this is not very close to that asked for by Date. However, what Date is
proposing would remove almost all local autonomy for the fragments. The
form of fragment independence is required for a specific application may
vary, but what Ingres does provide can be very useful in hiding fragements.

>Rule 6: Replication Independence; Relations and fragments should be able
>to be represented at the physical level by multiple, distinct, stored
>copies or replicas at distinct sites, transparent to the user.

>	v6 NO
>	v7 PARTIAL
>	Ingres NO
]       Informix NO

>(The V7 snapshot facility provides a partial solotion.  It allows for
>multiple read-only copies of a master table which are updated at a user defined
>interval.  Also V7 triggers and 2PC provide a partial synchronous replication
>facility.  The problem here is that you have to code your own in
>triggers, which is less elegant.)


>Rule 7: Local processing and input/output activity needs to take place
>at multiple sites, with some amount of data communications between them.
>Both local and global optimization of query processing should occur.

>	v6 PARTIAL
>	v7 PARTIAL (better)
>	Ingres PROBABLY YES
]       Informix YES

>V6 does some query optimization.  V7's optimizer does a better job optimizing
>distributed queries.

Ingres also does some query optimization (uses transmision cost information
if given).  

>Rule 8: Distributed Transaction Management; Single transactions
>execute code at multiple sites, causing updates at multiple sites.

>	v6 NO
>	v7 YES	
>	Ingres YES
]       Informix YES

>This covers the Transparent Two Phase Commit, the RPCs that are protected by
>2PC, Triggers and Stored Procedures that can have effects across sites.


>Rule 9: Hardware Independence; Distributed databases should be able to
>run on different kinds of hardware, with all machines participating as
>equal partners where appropriate.

>	v6 YES
>	v7 YES	
>	Ingres NO
]       Informix YES

>Ingres does not allow equal partnership.  

I don't quite understand this comment. There is no fundamental reason why
a distributed database cannot be on different hardware that I know of.
Although, I know for example that the recovery mechanism does place 
constraints on how databases are configured when in a VAX cluster and 
using NFS.  This is trying to be safe rather than sorry.  But these are 
not realy distributed database problems but rather are the problems of 
distributing data and processes on different machines in a local network.  
Of cause one would always want greater support.	 

>Rule 10: Operating System Independence; Distributed databases should be
>able to run under different kinds of operating systems.

>	v6 YES
>	v7 YES	
>	Ingres SOMEWHAT
]       Informix YES

>Ingres Star was confined to VMS; it may have made it to some Unix
>platforms by now.

They have Ingres/Star on UNIX now too. They seem to bring things
out on VMS first and then onto UNIX and anything else.

>Rule 11: Network Independence; Distributed databases should be able to
>work with different kinds of communications networks.

>	v6 YES
>	v7 YES	
>	Ingres PROBABLY YES
]       Informix YES

One always wants more!

>Rule 12: Database Independence; Distributed databases should be able to
>work with different kinds of databases, providing they have the same
>interfaces.

>	v6 PARTIAL read-only and using SQL*Connect
>	v7 YES	Foreign databases can be included in 2PC.
>	Ingres AT LEAST SOMEWHAT
        Informix NO
        Informix YES ( if you use a transaction monitor )

>Specifically, a 2PC coordinated by an ORACLE database can include one foreign
>database.  A 2PC coordinated by a Transaction Processing Monitor (TP Monitor)
>can include any number of foreign databases.

Ingres does not provide and distributed transaction capabilities
using "gateway" databases. This functionality is typical of many
federated databases systems.

General comment:
Ingres would need a distributed trigger mechanism (combined with
support for replicated data?) to be able to have at least partial
support for the objectives which it has almost no support for currently.


>   You should be able to win free drinks with a simple bar room bet:  ask
>   someone how many rules there are in Date's 12 Rules.  (There are 13 Rules,
>   numbered 0 through 12.)

Be careful - if the person says that "Rule 0" is rather a fundamental
principle - he may want a drink from you.

>-- 
>Tom Cox      DoD #1776   '91 CB 750 Nighthawk   tcox@netcom.netcom.com
> This note is my exercise of my First Amendment right to make a fool of
> myself in public.  I do not speak for anyone but myself.  Ever.

Well I must go along with that. It would be interesting in the comments
that Tim has made could be extended with the help of others who have
a good knowledge of a product (and don't try and say YES to everything,
because its the comments that are more important as they give an idea
of the level of support provided by a product for a given objective).

- Andrew Deacon 
Newsgroups: comp.databases