Re: Unique attributes
Re: Unique attributes
- Subject: Re: Unique attributes
- From: Ian Joyner <email@hidden>
- Date: Thu, 16 Feb 2006 16:48:19 +1100
On 16/02/2006, at 2:38 PM, Arturo Pérez wrote:
On Feb 15, 2006, at 5:53 PM, Ian Joyner wrote:
On 16/02/2006, at 1:25 AM, Arturo Perez wrote:
Ian Joyner wrote:
Thinking on it a little further and an afternoon walk (now I
need my afternoon nap), perhaps unique is not as high in the
semantic chain as we would like, since identifying candidate
keys in relations implies unique across the set of attributes in
the key. This would help in being able to identified if things
were normalized into at least 3NF or BCNF or where to
denormalize for performance reasons.
That way, I think EOModeler could be made into a much more
useful tool than just the ER approach it supports and people may
be normalizing things and doing good design without realizing
it! (OK, I have to reread the books on normalization everytime :-()
Ian
I'm not sure I follow what you're saying here. Are you looking
for something like
EO1 relatedTo EO2 unique?
Or are you just looking for (EO1.attr1, EO2.attr2) UNIQUE?
Postgres will do this but without database logic I don't see how
to do the other.
Nothing about relationships between tables, but just
identification of candidate keys within a table, ie, all
attributes or sets of attributes that can be used to uniquely
identify records. EO just uses the PK as a pointer between records
and as such it is just underlying implementation mechanics, which
is for the most part rightly made invisible. However, this means
that the many other semantic and design uses of keys are not
supported, except in our paper designs. Such a key to identify a
person record could be surname x first_name (which is not a really
good key because in reality uniqueness is not guaranteed, so
usually an employee number is used in preference, but it's
probably the simplest example I can think of). A better example
probably comes from relationship tables which relate two or more
other tables (join tables) like BOOK_LOAN where a candidate key
would be book_number x borrower_number (maybe with a date in case
of multiple borrowings of same book by same person).
Ah, I see what you're getting at. EO does support multi-value PKs
(for the join table example) but that doesn't address your point.
My perspective might be colored by my preferences and I'm just
thinking out loud but...
I am a big fan of model-based fetchspecs. The code-based ones
violate the "if you're writing code, you're doing it wrong" rule.
As such, I believe (with no evidence to back it up) that perhaps
model-based fetchspecs were intended to address your point to a
certain extent.
You need alternate keys and a fetchspec would provide that. It
will return EOs properly etc.
Excellent. I can see how specifying the combination of attributes to
make a key for a fetch spec would do that. I'm still just trying to
come up with a good pattern of usage for fetchspecs – they seem very
powerful, but I don't think I've got my head around the whole thing
yet, and yes I'd prefer to do a fetchspec than write code.
Now, what won't a model-based fetch spec do? You'd need to couple
them to validation somehow. That's one thing that would need to be
addressed. What are other things your mental model requires? I
think redoing some of the object-uniquing EOF does based on PK
would need to be redone. Anything else?
I think, what I am getting at is just the data modelling issue that
is done before any consideration of queries is addressed – get the
model right and then you can do very powerful ad hoc queries. Perhaps
once you have your candidate keys, those could form the basis of
fetchspecs? I'm looking at some relational DB texts to figure this
out (CJ Date, Introduction to Database Systems, and John Hughes
Database Technology), which give formal definitions of candidate
keys, along with their uniqueness and irreducibility properties, and
how they relate to normalization.
Anyway, I think that rather than just adding unique to a column or
set of columns that unique could be derived from a candidate key
property somehow. (A candidate key being built on actual data values,
rather than implementation pointers which is how primary and foreign
keys are done in EO.)
I'm probably, just making things more confusing now, while trying to
get at something that would simplify design issues.
Ian
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden