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