Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations gkittelson on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

generalisation/specialisation relationship

Status
Not open for further replies.

p27br

Programmer
Aug 13, 2001
516
GB
hello,

in my database I have a main table for all reports.then I have specific types of reports that need additional attributes. So I created subtables with a one-to-one relationship to the main report table on report id.
Is this correct ?

thanks in advance for your help

Paul
 
Not clear what you mean. The most usual reason for creating tables with one to one relationships is to hide the info contained in the subsdidiary table. Is this what you are trying to do. If not, why create the second table?


Access makes all things possible. It even makes them intelligible
 
Paul,

It sort of depends on what your data look like. If it's just a few fields that are different, I would just jam them all in one table--hard drives are pretty cheap these days. But if it's a bunch of fields, then yes, your table structure sounds sound.

Clearly, a strict reading of normalization tells you that what you've done is correct. But real world applications require a bit of softening from time to time. There will be a lot more querying to do with the structure you've described than if you drop all those fields into one table, and that may or may not be more onerous than having blank fields in each of your records.

It sounds like you've got a pretty good grip on normalization issues, but if you're looking for something to read, check out the &quot;Fundamentals&quot; article on my website. I didn't write it, so it's OK if I tell you that it's really excellent <g>.

Jeremy

==
Jeremy Wallace
AlphaBet City Dataworks
Affordable Development, Professionally Done

Please post in the appropriate forum with a descriptive subject; code and SQL, if referenced; and expected results. See thread181-473997 for more pointers.
 
jeremy,

thanks for the answer.You're right, I have learned the basics on normalization but I lack practice in creating real world databases. It does seem a good idea to put all fields in just one table and allow nulls for these fields. It will simplify the design.
i'll go have a look at your website now.

regards

Paul
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top