MySQL Forums
Forum List  »  Newbie

Re: structure and normalization help
Posted by: Roland Bouman
Date: July 16, 2005 02:15PM

it seems that the following is quite clear cut:
You need one table for storing product categories, and one table for storing products; of course, the products table references the categories table, so that a product knows what category it is in, right?
I guess, you got there already ;)

What seems to raise some questions is how you should handle the Immunoassays. It's quite clear that all products that are in the category immunoassays have a whole bunch of properties and relationships that are not at all applicable to say Antigens or Polymerases.

In the first place, an immunoassay is a product with a name, category, price etc. just like any other product. At the same time, Immunoassays have something extra: they can be related to one or more substances (reactivity), and they always have a particular attribute that can have the RIA,ELISA,IRMA or LIA value; all unlike any other product.

The combination of sameness (it's a just a product) and distinctness (it's unlike any other product) qualifies as a subtype: In this example, product would be the supertype, and immunoassay would be the subtype.

One way of implementing this would be to have all relationships and attributes that constitute the subtype apply optionally to the supertype. This is a easy and straightforward implementation, and it could be just fine for your problem. Drawbacks are that the checks you need perform ('ImmunoAssay type is null, unless the product is in the ImmunoAssay category', 'ignore the substance_product table, unless it's a product in the ImmunoAssay category, in case it sums up the reactivity') are, that even if you have implemented checking at the database level (and you should if you can) usually, you still have to built these checks again in the data entry front-end applications to help the users understand what they're doing.

A cleaner way of doing this is to create a separate table for the subtype (immunoassy_product) that contains all the attributes that apply to the subtype specifically. Also, the reactivity could then be modelled in a 'immunoassay_reactivity' table, that references immunoassy_product, not just product. TO model that each row in immunoassy_product also is a product, the immunoassy_product would have a reference to the product table, and the columns that make up this reference would unique for both the immunoassy_product and the product table. Traditionally, the primary key the subtype table would reference the primary key of the supertype table.

There are still some others questions that you should consider. right now there's not enough information to repsond in full:

1) Does the immunoassay type really constitute an attribute of products in the immunoassy category? Isn't this immunoassy type not another level in the product_category table (this would lead to a category hierarchy)
2) Should reactivity be modelled as a collection of substance-immunoassy combinations, or is it sometimes the case that a immunoassay has reactivity to an entire class of substances.

By the way, I don't know what is a ridiculous query in your opinion. What matters most is that you can get to the correct information, and that the structure allows data inserts, updates etc. without introducing inconsistencies due to redundancy.
More normalized systems have these properties, but usually require more complex queries in terms of the amount of tables that need to be joined.

Hope it helps, Good luck!

Options: ReplyQuote


Subject
Written By
Posted
Re: structure and normalization help
July 16, 2005 02:15PM


Sorry, you can't reply to this topic. It has been closed.

Content reproduced on this site is the property of the respective copyright holders. It is not reviewed in advance by Oracle and does not necessarily represent the opinion of Oracle or any other party.