ORM or JDBC?

[Silvio]

On 03/29/2011 12:06 PM, Alessio Stalla wrote:
[snip]

If you skip the domain model part, and pretend the GUI is the model of
your application, then you're simply not doing Object-Oriented
Programming. That is not a crime, mind you, but then I don't
understand why you're using Java in the first place.

Alessio

I could not disagree more. There is no "one ultimate OO way" of doing
things. Nor is it clear cut whether any program fragment is "OO" or not.
Neither does OO mean you have to have an object model that is separate
from the UI (or any other part of the system). Why would coupling an
object model to the UI be any worse than coupling it to the database? In
most cases I would strive to decouple it from both.

OO is a programming methodology, just like functional programming and
even procedural programming. Neither methodology prescribes a single
solution for any problem.


And I am not using Java (which I consider only a weakly Object Oriented
language). I program in Scala but I am using the JVM and my share of
Java libraries.

 

[Lew]

Sometimes whan I am sad I think of:
http://en.wikipedia.org/wiki/Galileo_Galilei

Sometimes when I am sad I think of kittens and butterflies.

 

[Lawrence D'Oliveiro]

Normalization is something else - that's not semantics. It's a technique
for taking a relational database model and turning it into something
practical for use inside an RDBMS.

No it is not. It is integral to the mathematical concept of relations.

 

[Lawrence D'Oliveiro]

Sometimes whan I am sad I think of:
http://en.wikipedia.org/wiki/Galileo_Galilei

Could be worse <http://en.wikipedia.org/wiki/Giordano_Bruno> ...

 

[Lawrence D'Oliveiro]

In message

Instead, ORMs exist because most people find it useful to represent
the domain model as "something" which is neither the DB, nor the GUI.

I would describe that as the “business logic APIâ€, insofar as parts of it
need to be common across multiple applications.

Fair enough that parts of that cannot be expressed merely as database
constraints, but I would not like to see it tied to a GUI.

 

[Arved Sandstrom]

No it is not. It is integral to the mathematical concept of relations.

Lawrence, normalization is basically a set of design techniques
associated with the relational data model, and the relational data model
is a _logical_ data model, not a conceptual one that defines the
semantics. So how is normalization integral to semantics again?

And by the way, if you can't define a relation without using the term
"normalization" then you're missing the point. And don't confuse a
modern relational database with the relational model.

AHS

--
That's not the recollection that I recall...All this information is
certainly in the hands of the auditor and we certainly await his report
to indicate what he deems has occurred.
-- Halifax, Nova Scotia mayor Peter Kelly, who is currently deeply in
the shit

 

[Lawrence D'Oliveiro]

Lawrence, normalization is basically a set of design techniques
associated with the relational data model, and the relational data model
is a _logical_ data model, not a conceptual one that defines the
semantics.

Difference being?

And by the way, if you can't define a relation without using the term
"normalization" then you're missing the point.

Maybe you’ve been befogged by SQL, to the point where you don’t notice the
mathematics underneath.

 

[Tom Anderson]

the relational data model is a _logical_ data model, not a conceptual
one that defines the semantics.

What's the difference between a logical model and a conceptual model?

tom

 

[Arved Sandstrom]

What's the difference between a logical model and a conceptual model?

tom

Let's put it this way - I doubt you'll find an authoritative reference
that informs us exactly what is a conceptual data model, exactly what is
a logical data model, and exactly what is a physical data model. However
the terminology, and that division into three levels of abstraction of
data modeling, is quite common.

A conceptual model equates to a business model. You might have entities
for Person, Address, and LifeEvent, say. There is just enough
information in the description of each to support a _business-level_
discussion of relationships and identifying information and extra
information.

It's in the logical model that, assuming we are talking about a
relational logical data model, that we might say that Person has
person_id as a primary key, that there's a M:N between Person and
Address and we describe the join table, there's a 1:N between Person and
LifeEvent, we specify exactly what the tables are and what columns
exist, what columns are foreign keys, and so forth.

In a physical model not only do I already know that I'm using an RDBMS,
I know I'm using Oracle or SQL Server. I'm writing the details of my JPA
and deciding what my indexes are, and what the syntax is for a boolean
data type.

In the conceptual model there's no such thing as tables or columns, and
we're not overly worried about datatypes or about exactly how we are
going to define the primary key for Person. You should be able to take
your conceptual model and be able to choose something other than a
relational model as your logical data model, is the point.

AHS
--
That's not the recollection that I recall...All this information is
certainly in the hands of the auditor and we certainly await his report
to indicate what he deems has occurred.
-- Halifax, Nova Scotia mayor Peter Kelly, who is currently deeply in
the shit

 

[Arved Sandstrom]

Difference being?

See my explanation to Tom.

Maybe you’ve been befogged by SQL, to the point where you don’t notice the
mathematics underneath.

I'm reasonably familiar with the mathematics of tuples and relations. I
also know that when I'm using a typical RDBMS and SQL that I'm not
constrained to a relational representation of my data.

AHS
--
That's not the recollection that I recall...All this information is
certainly in the hands of the auditor and we certainly await his report
to indicate what he deems has occurred.
-- Halifax, Nova Scotia mayor Peter Kelly, who is currently deeply in
the shit

 

[Lawrence D'Oliveiro]

A conceptual model equates to a business model. You might have entities
for Person, Address, and LifeEvent, say. There is just enough
information in the description of each to support a _business-level_
discussion of relationships and identifying information and extra
information.

It's in the logical model that, assuming we are talking about a
relational logical data model, that we might say that Person has
person_id as a primary key, that there's a M:N between Person and
Address and we describe the join table, there's a 1:N between Person and
LifeEvent, we specify exactly what the tables are and what columns
exist, what columns are foreign keys, and so forth.

I still don’t see how you separate between “conceptual†and “logicalâ€. One
flows from the other; there is no boundary between them.

 

[Lawrence D'Oliveiro]

I'm reasonably familiar with the mathematics of tuples and relations. I
also know that when I'm using a typical RDBMS and SQL that I'm not
constrained to a relational representation of my data.

How else do you express relationships?

 

[Arved Sandstrom]

How else do you express relationships?

That's not exactly what I was getting at, relationships, although I'll
touch on that. Assuming however that I am using a relational model for
my data (e.g. I have relation Person, relation Address, and relation
LifeEvent, say), the 1:N relationship that I have between relation
Person and relation LifeEvent I can describe by having a foreign key
column in LifeEvent, the domain of which is the primary keys of Person;
obviously a query that exploits that relationship also returns relations.

This is all relationships in a relational data model, though. If I am
not even using relations to describe my entities, why would you expect
relationships to be described in a relational manner?

Back to my original point: common RDBMSs aren't completely relational.
We can have duplicate rows in tables (this includes relations returned
by queries), and you can't have duplicate tuples in relations. This
whole business with DISTINCT is a patch...and can also be a code smell
since it may be hiding errors. Also, NULL isn't quite kosher - it's an
SQL afterthought. In that relationship I concocted above, I can have a
foreign key, potentially, on a row of LifeEvent which is NULL...that is,
it points to no Person. I can constrain that foreign key to be NOT NULL
but I shouldn't be allowed to make values NULL in the first place. The
use of NULLs in general mean that you've got poorly structured data.
Coupled with what you can do with SQL it can/will often lead to yet more
errors.

AHS
--
That's not the recollection that I recall...All this information is
certainly in the hands of the auditor and we certainly await his report
to indicate what he deems has occurred.
-- Halifax, Nova Scotia mayor Peter Kelly, who is currently deeply in
the shit

 

[Arved Sandstrom]

I still don’t see how you separate between “conceptual†and “logicalâ€. One
flows from the other; there is no boundary between them.

There is no super-distinct boundary, no. But there is a boundary
nonetheless. In the conceptual (semantic) model when we are thinking
about Person, we'll have a notion of Person identity - what attributes
of Person make them unique - but at this level that uniqueness could be
opaquely described as PersonID of no particular datatype, and we then go
on to discuss other attributes of Person that are necessary for the
business problem. Similarly, when thinking at this conceptual level
about LifeEvent, we might simply say that each LifeEvent instance will
point at a Person using the PersonId value.

At this stage of the game nobody is talking about tables and rows
(relations and tuples), and if we decide to not use a relational model
we don't have to.

Part of the real-world problem is that in the majority of projects
people already _assume_ relational. So all of their
business/conceptual/semantic work is intertwined with implementation
details.

AHS
--
That's not the recollection that I recall...All this information is
certainly in the hands of the auditor and we certainly await his report
to indicate what he deems has occurred.
-- Halifax, Nova Scotia mayor Peter Kelly, who is currently deeply in
the shit

 

[Lew]

There is no super-distinct boundary, no. But there is a boundary
nonetheless. In the conceptual (semantic) model when we are thinking
about Person, we'll have a notion of Person identity - what attributes
of Person make them unique - but at this level that uniqueness could be
opaquely described as PersonID of no particular datatype, and we then go
on to discuss other attributes of Person that are necessary for the
business problem. Similarly, when thinking at this conceptual level
about LifeEvent, we might simply say that each LifeEvent instance will
point at a Person using the PersonId value.

To this excellent taxonomy I would add only that the conceptual "PersonID"
would identify the natural, or innate identifying data, one might say the
"primary key". That's not correct at this level, though - what we're aiming
for are the attributes that determine entity identity within the semantic model.

A surrogate key, such as an integer-valued ID that perhaps is from a sequence,
is something introduced in the physical model.