Re: Relational database & OO

"H. S. Lahman" <h.lahman@xxxxxxxxxxx> wrote in
1aJ5h.2229$bj1.1326@trndny05:">news:1aJ5h.2229$bj1.1326@trndny05:


And when was the last time you saw an RDB that stored a telephone
number as individual fields?

Pardon me but the example of the phone number is silly.

The modern relational theory permits to store values of user-defined type:
it does not limit itself by primitive data types. Several modern databases
instrument the user-defined type. One can utilize the user-defined type
and extract the area code in the fashion that is theoretically pure. If
the database does not offer the user-defined type, one can emulate the the
type with the string datatype of the proper format: that is what one does
in pratique. What is there to discuss ?

If the fields are separated they need to
be in their own table to avoid 3NF problems. That's because the
simple domains are individually dependent solely on the identity of
the telephone number, which /is/ the telephone number.

You must make yourself familiar with the modern relational theory before
you try to make the ridiculous declarations. It makes a decade that the
user-defined datatype is utilized in the modern database.

One of the examples of C.J. Date:

TYPE POINT { X NUMERIC, Y NUMERIC } ;

One can create the phone datatype: type phone {area integer, local_office,
extension integer} or analogue that suits the requirements.


....


The relational data model is a mathematical model. The RDB paradigm
is a way of applying that model to practical data storage.

There is the relational data model that is founded on the rigorous
mathematiques; there is no "RDB paradigm". One must read the works of C.J.
Date to comprehend the relational model. The real SQL database, one
regrets to say, is an imperfect "way of applying that model to practical
data storage" but that is not a "paradigm": it is called an imperfect
realization of the relational model.



Consider 6-32 screws
in an inventory. They are effectively clones without explicit
identity values but they are still uniquely identifiable in the
problem space. So long as the object corresponding to each screw has
a unique address, it is identifiable in the same sense that the
physical screws in the problem space are. The only way you can avoid
2/3NF problems for that situation in an RDB is by adding an
artificial explicit identity (e.g., autonumber) to the tuple itself.


And what is the normalization problem with that?

I said specifically that one /avoids/ the normalization problem
through the kludge of providing an explicit tuple identity that does
not exist in the problem space.

Why is it that one needs to have the identity of the screw ? When one
needs to have the identity like of a car, the identity is the candidate
key that can be the VIN or one other attribute or set of attributes.


However, I don't see that as being very relevant. My point is that
the application's problem solution doesn't care how the data is
stored.

Neither do the relational model or SQL.

The RDM, yes. But try using SQL on flat sequential files or an OODB.


SQL using flag files would be possible and is done all the time. Most
SQL databases uses flat files for persistence. Actually JDO claim
that an hybrid SQL language (JDO-SQL) can be used on non-relational
databases. Obviously the underlying database need to support
relational calculus or the JDO product has to implement it on top.

I'm talking about SQL and flat sequential files where there is no
embedded tuple identity and the files are read by character or by
block.
SQL is meaningless in that context.

I can not comprehend this: why is it that one needs to read the flat file
with the SQL ? It is without reason. The flat file and the relational
model is like the apple and the orange.

.....

Do you have any pointers to some website explaining "tuple-based
relationsships of the OO paradigm".

Any OOA/D book will do. In an OO context an object maps relationally
to a tuple in a class set relation. Relationships are defined at the
class level but they are instantiated at the object level.

1 R1 *
[A] --------------- [B]

If we have

A1 related to B2, B3
A2 related to B1
A3 related to B4, B5, B6

then A1 has a relationship collection of {B1, B3}; A2 has a
relationship collection of {B1}; and A3 has a relationship collection
of {B4, B5, B6}. When the relationship is navigated one only accesses
the members of the [B] set that are specifically related to the A in
hand. IOW, the navigation always accesses /only/ the relevant members
of [B] for the A in hand.

That contrasts with the RDB-style class relationship where one
potentially accesses every member of [B] to locate the members of [B]
related to the A in hand. One can reduce the exhaustive search by
providing a special index on the [B] set that is ordered for the
specific query, but one still has an O(NlnO) search. One could also
provide a "custom" index for every member of the [A] set just like the
OO paradigm does routinely, but that would run out of resources pretty
quickly.

Your comprehension of the SQL database performance is not good. There are
lot of fashions to join relational tables in addition to the row by row
nested loops: hash join, merge join, semi-join, et cetera.. You can have
benefit when you make yourself familiar with for example Oracle or SQL
server. The modern SQL database operates with sets of rows very
effectively using multiblock disk reads when your network datamodel
traverses the graph node by node or block by block: that is not efficient.

In sum, your comprehension of the relational model and the SQL database is
not adequate to critique the one or the other.

--\
Tegi
.

Relevant Pages

  • Re: SQL
    ... persistence to RDBs in the computing space. ... SQL has already made that implementation choice. ... purpose access to persistence, much less general computing. ... implements the RDB view of persistence and only the RDB view. ...
    (comp.object)
  • Re: Searching OO Associations with RDBMS Persistence Models
    ... I agree those pesky DB language do tend to thrash a lot. ... Both SQL and C++ can be extended with custom data types. ... The RDB has no idea that this is the ... The programming language is also always a detail. ...
    (comp.object)
  • Re: SQL
    ... That let's SQL out because it depends upon the specific ... > RDB implementation of the RDM. ... > just use SQL to talk to the RDB. ... This depends on how one defines "problem space abstraction". ...
    (comp.object)
  • Re: Relational database & OO
    ... The modern relational theory permits to store values of user-defined type: it does not limit itself by primitive data types. ... If the database does not offer the user-defined type, one can emulate the the type with the string datatype of the proper format: that is what one does in pratique. ... then the RDB must support ADTs and that ADT needs to be defined in the database schema. ... In most databases the DBA doesn't do that because SQL already provides a mechanism for extracting the elements. ...
    (comp.object)
  • Event log errors after moving sharepoint 3.0 database
    ... After following a procedure to move the location of the SQL databases from ... SQL Database 'WSS_Content' on SQL Server instance ... The local computer may not have the necessary registry ... information or message DLL files to display messages from a remote computer. ...
    (microsoft.public.sharepoint.windowsservices)