Re: Object-oriented thinking in SQL context?

On 9 juin, 23:57, rp@raampje.(none) (Reinier Post) wrote:
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.
Nope. I do not use UML concepts at all in my daily life.

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.
Thanks for the explanations. In a past life, I used visual
representations and diagrams to represent relations, functionnal
dependencies or required components of a data model but I came to the
conclusion that a textual representation was more effective into
representing logical aspects of a model. I now mainly use one tool
for database design: notepad.

Snipped
[...]

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.
Databases are meant to be used to manipulate sets of values. Saying
that databases weren't designed for that seems a hasty conclusion.


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.  
What may appear as dogmatism by a minority is in fact a counter
balance reaction to the indignified promotion of ignorance done by
some others. There is no dogmatism into encouraging people to do some
reading.

Pay attention to their ideas,
ignore their attitude.
Would the *dogmatic* people have some interesting things to say ?

Snipped

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.
The communication is bad because of the ignorance of most computer
science practitionners. For most of them, a limited grasp of computer
science concepts helps making a living, which I respect. But a small
minority of self promoted morons uses the ignorance of the majority to
promote further ignorance.

Anybody serious scientist would tell you that the*serious* basis
science communication is understanding first how fundamental theory
works to be able to relate to common fundamental concepts with larger
audiences.
.

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)