Open to criticism... (1 Viewer)

[kmb]

Hi all,
I don't have a specific problem, I am just trying to improve and learn. That said, I am attaching the relationships diagram for my current dB. I know that I haven't been that great at a consistent naming pattern, but I am wondering if anyone wanted to comment on the design or normalization or whatever you can glean from this.

BTW: there are two categories and two respective subcategories for each organization.

Thanks in advance.
KMB

 

[georgedwilkinson]

You have several problems. Take a look at: http://www.tdan.com/view-articles/5014 for a good discussion on normalizing Organizations. Duplicate the logic there for the rest of your model.

Post back here with specific questions once you understand that.

 

[Scooterbug]

BTW: there are two categories and two respective subcategories for each organization.

There is no need to have two separate tables for the same data. (Catgories and Catagories_1). Same goes for the Sub Catagories.

Also, in your Organization Table, you have both Catagory and Catagory2. You said that each Organization can have two catagories. Can you say for certain that in the future there will be absolutly, positively, beyond a shadow of a doubt that a third, fourth or more catagories will need to be added? Probably not...so the catagories should be in their own table.

Also, your Catogory Type table only has one field. If you wanted to limit the selection for Catgory Types, you should add an ID field to the Catagory Type table and join it on the ID number

 

[kmb]

thanks, I will read up on the website george suggested.

for clarity, there is only one category table where the PK in that table is referenced by two different FKs in the org table and ditto for subcategories.

Thanks for the ID advice in the cat type table.

The reason I started this thread was because I am trying to normalize the org table and am trying to figure out whether it is worth it/good idea to separate out the address fields into new tables.

If anything else strikes you, please feel free to let me know.
regards
kmb

 

[Scooterbug]

for clarity, there is only one category table where the PK in that table is referenced by two different FKs in the org table and ditto for subcategories.

What I was getting at is that you are storing the same type of data in two different tables. Both tables (Categories and Categories_1) have identical field names. You should only have one Catagories and SubCatagories table. If you are only going to store 2 catagoryIDs in the Organization (They should actually be in their table IMHO) then there is no need for two catagory tables. If you want to limit which catagories go into which Catagory fields in the Organization Table, add a field to differenate which Catagories are available to choose from.

The reason I started this thread was because I am trying to normalize the org table and am trying to figure out whether it is worth it/good idea to separate out the address fields into new tables.

Generally, unless the Organization can have multiple addresses, you shouldn't need to store the address in a new table.

[/quote]

 

[Galaxiom]

There is really only one reasons to separate out addresses to another table.
Support for an unlimited number of addresses to be assigned to a primary record. For example, multiple locations or historical tracking of previous addresses.

Basic rule. 1:1 relationship means they go in the same table.

 

[kmb]

I know its been a while since the last post, but I just wanted to say thanks for those who had input here. I would also like to note that thanks to the many kind people here and around the net, that my first real dB is becoming a success. It is mostly normalized and I have learned a lot, including more code everyday. Again thanks alot to all you helpful experts.
Kalan