views:

321

answers:

4

I hear a lot about subtyping tables when designing a database, and I'm fully aware of the theory behind them. However, I have never actually seen table subtyping in action. How can you create subtypes of tables? I am using MS Access, and I'm looking for a way of doing it in SQL as well as through the GUI (Access 2003).

Cheers!

+1  A: 

Subtypes of tables is a conceptual thing in EER diagrams. I haven't seen an RDBMS (excluding object-relational DBMSs) that supports it directly. They are usually implemented in either

  1. A set of nullable columns for each property of the subtype in a single table
  2. With a table for base type properties and some other tables with at most one row per base table that will contain subtype properties
Mehrdad Afshari
+1  A: 

The notion of table sub-types is useful when using an ORM mapper to produce class sub-type heirarchy that exactly models the domain.

A sub-type table will have both a Foreign Key back to its parent which is also the sub-types table's primary key.

Mitch Wheat
+7  A: 
jasonco
Sorry but I think you are merely describing a REFERENCE. Your so-called supertype table lacks a type attribute! For a better IMO example see the CREATE TABLE Vehicles post in this thread: http://bytes.com/groups/ms-sql/808389-design-question-type-heirarchy-supertype-queries
onedaywhen
Yes, you are talking about a discriminator column, which is another approach to solve the same problem. I was well aware of that approach. That doesn't mean my solution is incorrect. I just wanted to give a brief SIMPLE example. In the link you posted, the post clearly states that there are many ways to model such structures. A similar example to the one I posted is mentioned in the book "Database Systems: Design, Implementation and Management 6th ed." p. 150, 151 and 159.
jasonco
A: 

Keep in mind that in designing a bound application, as with an Access application, subtypes impose a heavy cost in terms of joins.

For instance, if you have a supertype table with three subtype tables and you need to display all three in a single form at once (and you need to show not just the supertype date), you end up with a choice of using three outer joins and Nz(), or you need a UNION ALL of three mutually exclusive SELECT statements (one for each subtype). Neither of these will be editable.

I was going to paste some SQL from the first major app where I worked with super/subtype tables, but looking at it, the SQL is so complicated it would just confuse people. That's not so much because my app was complicated, but it's because the nature of the problem is complex -- presenting the full set of data to the user, both super- and subtypes, is by its very nature complex. My conclusion from working with it was that I'd have been better off with only one subtype table.

That's not to say it's not useful in some circumstances, just that Access's bound forms don't necessarily make it easy to present this data to the user.

David-W-Fenton