Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > ORM or JDBC?

Reply
Thread Tools

ORM or JDBC?

 
 
Lawrence D'Oliveiro
Guest
Posts: n/a
 
      04-02-2011
In message <LQslp.6717$(E-Mail Removed)>, Arved Sandstrom wrote:

> 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.
 
Reply With Quote
 
 
 
 
Lawrence D'Oliveiro
Guest
Posts: n/a
 
      04-02-2011
In message <gZslp.3268$(E-Mail Removed)>, Arved Sandstrom wrote:

> On 11-03-31 09:10 PM, Lawrence D'Oliveiro wrote:
>
>> In message <IX7lp.805$(E-Mail Removed)>, Arved Sandstrom wrote:
>>
>>> 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.

>
> 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?
 
Reply With Quote
 
 
 
 
Arved Sandstrom
Guest
Posts: n/a
 
      04-02-2011
On 11-04-01 11:45 PM, Lawrence D'Oliveiro wrote:
> In message <gZslp.3268$(E-Mail Removed)>, Arved Sandstrom wrote:
>
>> On 11-03-31 09:10 PM, Lawrence D'Oliveiro wrote:
>>
>>> In message <IX7lp.805$(E-Mail Removed)>, Arved Sandstrom wrote:
>>>
>>>> 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.

>>
>> 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?


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 ****
 
Reply With Quote
 
Arved Sandstrom
Guest
Posts: n/a
 
      04-02-2011
On 11-04-01 11:44 PM, Lawrence D'Oliveiro wrote:
> In message <LQslp.6717$(E-Mail Removed)>, Arved Sandstrom wrote:
>
>> 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.


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 ****
 
Reply With Quote
 
Lew
Guest
Posts: n/a
 
      04-02-2011
Arved Sandstrom wrote:
> 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.

--
Lew
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
modeling--DAO vs ORM Tom Java 1 01-14-2006 07:41 AM
ORM Chris Kennedy MCSD 0 09-06-2005 03:09 AM
Dejavu 1.3, a Python ORM Robert Brewer Python 0 01-21-2005 07:08 AM
Dejavu 1.2.6, a Python ORM Robert Brewer Python 0 12-16-2004 12:09 AM
ORM resources necessary for 70-300 TomTom MCSD 7 08-17-2004 07:08 AM



Advertisments