Re: Object-oriented thinking in SQL context?

I am not aware of any precisely and consensually OO defined concept.
I have asked hundreds of OO programmers in the past about a definition
about what an object and each of them came with a totally different
definition.

But it's pretty much clear what a UML class diagram is, isn't it.

You are a database desinger, right? Do you ever use the
'entity-relation' method when you design a database?
If so, what is an 'entity'?

The entity-relationship method is often used, advocated and taught
for the design of databases. The design starts by creating
an entity-relationship diagram, that is systematically transformed
and provided with implementation detail until an ER diagram results
that specifies a relational database schema.

An ER diagram is a representation of the relations (tables)
and foreign key relationships in a relational database schema.
The relations in the schema are the entities and many-to-many
relationships in the ER diagram; the foreign keys are the
one-to-many relationships and the links between many-to-many
relathipships and entities in the ER diagram. Every ER diagram
can be created out of a relational schema in this way, but not
every relational schema corresponds to an ER diagram; certain
limitations on the structure of the structure of the foreign keys
apply.

Entity-relationship diagrams and UML class diagrams are very closely
related. The entity sets in an ER diagram correspond to the classes
of an ER diagram; the relationship sets to associations.
There are also many differences, but the starting point is the same.

[...]

In my first post:

"I have a problem with wrapping my mind into the 'right' wrinkles."

"The [system] would be almost trivial to implement in an
object-oriented context [...],
but I don't see how to come up with a table-based database
design."

Think 'class' ~ 'relation' (table), 'reference' ~ 'foreign key',
'object' ~ 'tuple' (row), 'object model' ~ 'database schema'.
But don't equate them: there are important differences.
One is that objects can hold references to objects, while
a database table can only hold attribute values. This is often
resolved by adding a (usually autonumbered) special attribute
to relations that is guaranteed to be unique for each tuple,
and can therefore be used by way of tuple reference; this may
or may not be a good idea, depending on your purpose and
whom you talk to. Tools exist that automatically map a class model
to a relational database using this idea, but some people in this group
are very much against it. They think one should start with
a relational model and when possible only use 'natural' attributes,
i.e. ones with values we humans can observe, otherwise you
run the risk of creating structures with unnecessary levels of
references, duplication of information, and other issues.

The main thing is that the technical differences may appear
small, but the whole approach to handling data is different,
and you can't expect to pick up such differences nmerely by
participating in a newsgroup discussion.

[...]

1) If OO concepts can be handled at all in SQL databases.
2) If so, how it is done.

Well, sometimes you have 'data' classes that do little but
define a bunch of properties with simple values, and you create
and manipulate collections of such objects; such classes and
collections are a quite like database tables. Inheritance
is also a very useful notion in database design, if we apply
it to properties (attributes, columns) only. But nothing
corresponds to the notion of method. Methods invite
class-specific, object-by-object manipulation techniques;
SQL on the other hand is essentially a language that maps
tables to tables with operations such as row selection,
column selection (projection), union, and join. You don't
manipulate or navigate iundividual values and rows, databases
weren't designed for that.

Or maybe you just are not ready to accept the answer as it is.  set
oriented approaches are radically opposites of procedural approaches.

Ah, 'set oriented vs procedural approach'. The first time
I see it. Any synopses on *how* they are different?

Set-oriented: you apply operations on whole sets at once.
Non-procedural: you don't change variables, but yield results.
It's a bit like doing all your programming with functions that take
collections and iterators and return resulting collections and iterators.

I ask the same question: How is SQL different and similar
to what I already know.

In ways you can not tell if you do not go through a self learning
process of education in database concepts.  If you believe this is not
necessary and OO concepts are sufficient to understand database theory
then it will be difficult to help you.

Some people in this newsgroup believe that the relational model
is sacred, its inventor Codd was a holy man, and a guy called Date
who has written a bunch of popular books on the subject is his
replacement on earth. Anything you say to suggest that other people have
something intelligent to contribute on the subject, or have already done
so, perhaps using slightly different ideas or terminology, is met with
the scorn only dogmatists can muster. Pay attention to their ideas,
ignore their attitude.

I'm blaming the community because members seem systematically
unable to project themselves into the shoes of a newbie, and
are thus unable to see the subject from the newbie's perspective.

Not only newbies, anyone with different ideas or different terminology.
This problem is hard to avoid in human communication, but it seems
particularly bad in computer science.

--
Reinier
.

Relevant Pages

  • Re: Object-oriented thinking in SQL context?
    ... But it's pretty much clear what a UML class diagram is, ... for the design of databases. ... that specifies a relational database schema. ... and foreign key relationships in a relational database schema. ...
    (comp.databases.theory)
  • Re: Object-oriented thinking in SQL context?
    ... for the design of databases. ... and provided with implementation detail until an ER diagram results ... and foreign key relationships in a relational database schema. ... That's often derived from the logical data structure. ...
    (comp.databases.theory)
  • Re: EJB - Why do we need java persistence on top of a database?
    ... > a database you have foreing keys, but what does java offer? ... it's far easier to design using Java objects (which are ... universal data model in the database after the fact. ... relationships to other objects (within the context of the diagram ...
    (comp.lang.java.programmer)
  • Re: What is analysis?
    ... database with 20 or 30 columns. ... Prototyping has always been an ... Do you se a diagram? ... Managers also couldn't get "the big picture" from a datasheet view. ...
    (comp.databases.theory)
  • Re: What is analysis?
    ... database with 20 or 30 columns. ... Prototyping has always been an ... Do you se a diagram? ... Managers also couldn't get "the big picture" from a datasheet view. ...
    (comp.databases.theory)