Re: Unique attributes
Re: Unique attributes
- Subject: Re: Unique attributes
- From: Ian Joyner <email@hidden>
- Date: Thu, 16 Feb 2006 09:53:58 +1100
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).
Of course PKs as used in EO are guaranteed to be unique, but remove
the semantic reasoning about keys from design in order that we can
better understand the data we are dealing with, thus being able to
decide how to break a large mass of data into normalized tables that
can easily be reconstructed into more meaningful things – this kind
of relates to the other discussion we were having on breaking down
classes into small classes that represent single concepts and their
related algorithms and then being able to reuse them with inheritance
or composition.
I think EOModeler could go beyond the E/R modelling it now does and
be a more powerful relational model which could feed into better OO
designs. Apple has always been good at designing things around more
sophisticated concepts without scarring people off (like relational
modelling can do). Maybe this will get into CoreData.
-arturo
On 15/02/2006, at 3:01 PM, Ian Joyner wrote:
On 15/02/2006, at 1:11 PM, Chuck Hill wrote:
Hello Ian,
On Feb 14, 2006, at 5:44 PM, Ian Joyner wrote:
If I were to request a UNIQUE property in EOModeler, should
this be on a per-table basis (which would set UNIQUE against
the column in the underlying database), or on an EO entity (in
the case of single table inheritance, you would not want the
column to be UNIQUE because this may not be guaranteed between
entities)?
Any thoughts?
_______________________________________________
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