Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> comp.databases.theory -> Re: Does Codd's view of a relational database differ from that ofDate&Darwin?[M.Gittens]

Re: Does Codd's view of a relational database differ from that ofDate&Darwin?[M.Gittens]

From: vc <boston103_at_hotmail.com>
Date: 20 Jun 2005 08:26:15 -0700
Message-ID: <1119281175.503879.311020@o13g2000cwo.googlegroups.com>


Hi,

Jan Hidders wrote:
> VC wrote:

[...]
> > Are you talking about the FDM (Shipman) as reperesented by the Daplex
> > language?
>
> Yes.
>
> > If so, my recollection is that the FDM is not much different
> > from the network/OODB approach in which case the argument can be reduced to
> > "the network model/OODB contra the RM".
>
> Yes and no. Although the data models look roughly the same, the term
> "network model" carries with it a few assumptions about how it should be
> implemented, and these no longer apply. So it may look similar at the
> surface, but it is actually very different.
>

OK, let's skip the word 'network' although I am not sure if the network model, as understood today, carries implemetation assumptions. Instead, let's make the following comparison:

In Java (OODB):

class employee {
  string getName();
  int getAge();
  department getDepartment();
....
}

In Daplex (FDM):

declare employee ->> entity
declare getName(employee) -> string
declare getAge(employee) -> int
declare getDepartment(employee) ->department

Now, in order to get the department object/entity, given an employee, we would do this:

In Java: employee.getDepartment()
In Daplex : getDepartment(employee)

Assuming, a department is located in a building, one would get it so:

In Java: employee.getDepartment().getBuilding() In Daplex: getBuilding(getDepartment(employee))

In short, it appears that FDM uses the same data model as the OODB does (ignoring minor syntactical and terminological differences, like 'entity' vs. 'class'). Therefore, an argument about the FDM vs. the RM can be reduced (equated with) an argument about the OODB model (class graph) vs. the RM model. If I am wrong with respect to how the FDM is different from the OODB model (and perhaps the network model), I'd like to know where exactly I might be wrong.

> > I am sure you know that Daplex,
> > btw, is a navigational language, not a declarative one.

"Navigational" is probably not a good word. I should have written that a Daplex query produces items ('print') in an imperative way:

for each s in employee

    print(getName(s), getAge(s),
getName(getBuilding(getDepartment(s))))

... which might make one to assume a mental navigational model for the entire language, rather than declarative/functional ['fucnctional' as in functional programming] one. Besides, a Daplex query is not 'closed'.

>
> It's no more or less declarative than, say, first order logic is.

See above.

>There
> is in both cases a naive implementation model one might consider
> navigational but there is an easy and straighforward translation to an
> implementation model that works at set-level.

Well, if we translate the FDM to sets, a natural question is, why bother ? Why not use the real thing instead ? On the other hand, if we claim that FDM has something interesting on its own, then we are back to the OODB vs. the RM. Not that I have any interest in such debate. I'd be interested, though, to understand what the FDM has to offer that might be different from the OODB approach.

> Compare this also to the
> relationship between the nested relational calculus (NRC) and the nested
> relational algebra (NRA) as defined by Limsoon Wong et al. One could
> probably argue that NRC is navigational and NRA is declarative but the
> two are straightforwardly translatable into each other, so such a
> statement is largely superficial and at a deeper level simply doesn't
> make much sense.

Right, the difference [from the relational calculus/algebra] is just in looking at the problem as sets vs. graphs.

>
> >>and probably even more so in it's modern incarnation that is the data model
> >>for Description Logics.
> >
> > I am not sure how the old FDM is related to the Description Logic, the
> > latter being a function free subset of FOL with at most three variable
> > names (that is if our vocabularies coincide).
>
> There are many different types of Description Logics, but I would in
> general say it is more like the two-variable fragment. For example, the
> satisfiability of the three-variable fragment is undecidable, and DLs
> usually are decidable. On the other hand many DLs actually go a bit
> beyond FO^2.
>
> Anyway, the relationship between them is that their data models are
> essentially the same: binary relations over possibly abstract domains.

If the data models are the same, then we can try and see in what respect the FDM differs from the OODB model.

>
> -- Jan Hidders

vc Received on Mon Jun 20 2005 - 10:26:15 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US