Re: Designer 2000, use of foreign keys

From: Andy Hardy <Andy_Hardy_at_camk.demon.co.uk>
Date: 1997/10/03
Message-ID: <DSVamCArNLN0MwBV_at_camk.demon.co.uk>#1/1


In article <3433b984.26319019_at_69.0.9.9>, Tim Hall <tim.hall_at_spambuster.com> writes
>On Thu, 2 Oct 1997 14:19:10 +0100, Andy Hardy
><Andy_Hardy_at_camk.demon.co.uk> wrote:
>
 [snip]
>>At table level, after running the database wizard, D2K uses the ERD to
>>determine that a foreign key is required and, therefore, a new column
>>must be added to the created table to facilitate this. You end up with a
>>new column called something like 'FE_FIRST_KEY'.
>>
>
>The column should be a copy of whatever forms the unique identifier of
>the second entity. You should define the UIDs of entities before you
>start using the database wizard.

Ah... I've just found the Run Option in the Create Database Wizard which turns off the prefixing of foreign key columns by the short name of the table they come from. Thanks for making me look harder!

>That's not really a big problem as it might look. The reason you
>don't specify foriegn keys is so you can define relationships before
>the unique identifiers need to be specified.

It's starting to make sense.

>Unfortunately there's no way to associate a relationship with a
>business function, you can only imply it by referring to the both
>entities in the same function. 99% of the time it's perfectly clear
>what it means.

I'll take your word for it here.

>I think you're confusing the physical and logical data models.
>Although they both represent the same system, they're defined
>differently, because they're used for different purposes.

You are correct, I'm constantly thinking of the ERD as a way of representing the physical schema, when it is only a conceptual device. This is probably because I get involved in the development process at the translation of ERD to physical schema level. In this way I'm glossing over the important differences between the ERD and the schema.

>Reverse-engineering a physical data schema to produce a logical model
>is intended for when you want to re-engineer an existing system,
>either to take advantage of new database technology, or to clean up a
>old legacy system that might not have been fully normalised.
>
>Hope this helps.
>----------------------------------------------------
>Tim Hall, Indus International

Tim, you've been very patient and have clarified a number of important points. It looks like I need to re-evaluate the way I've been trying to use D2K.

Andy

-- 
Andy Hardy
Senior IT Systems Engineer
Cegelec AEG
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Opinions are mine and do not necessarily reflect those of Cegelec AEG
Received on Fri Oct 03 1997 - 00:00:00 CEST

Original text of this message