To Normalize or not to Normalize?.. that is the question (1 Viewer)

[Carl_R]

I have been tasked with producing a Service Catalogue - essentially, a list of services offered by IT to our business customers.

The Catalogue is a repository of information related to the service - such as, Service Info, Business Info, Server names and location, DB info, Batch and Online times, Network Info (and the list goes on).

Obviously, these are high-level categories. Within each of these (for example. Business Info) there is more granular info such as, Business Owner, Supported Business Area (there can be more than one) and Business Criticality.

Given the data and the fact that some category items may have one or many values for any given field (DB names for example), is this something worthy of a DB?

I have tossed this around in my head and I can't get away from the notion that I will require multiple tables with untold fields (yikes - scary thought!)

I have attached a rough DB but before I put any more time and effort into it, I want to know if I am on the right track.

 

[ajetrumpet]

Here's one opinion....

Yes, you probably are.
You have products in one table, assigned to an autonumber (fine). You also have the applications for service in another table, also assigned to an autonumber. This is probably fine, but I don't know what the meaning of "application" is from looking at the file.

If you have business customers, and services to be offered, then you obviously have one table for each of those, but you need another for services (or service calls) rendered, which, when joined on both the customers and services tables with a "one-to-many" for each, should work fairly smooth.

Another thing I like to think of too when setting up like this..."Primaries" (master tables - e.g. "customers" & "services") are the inputs used to create the outputs (outputs of the business entity, that is). So like, your business inputs (resources / capital / knowledge) are your primaries, and they work together, and build information together, to create the outputs (services / revenue!!!!)

 

[Rabbie]

My advice would be to normalise at least to the extent where you don't store the same info in two separate places as this leads to problems in keeping the data in step.

Remember as a guidline that Access tables should be tall and slim rather than short and broad.

Hope this helps

 

[Pat Hartman]

You are asking the wrong question. The question should be - do I de-normalize? because in the absense of a compelling reason to de-normalize, it is ALWAYS right to normalize.

You need to go through each of your attributes and determine how they relate to each other and to whatever it is you are selling. Even iIf you are selling both items and services, you need to store them in a single table. If there are too many unique attributes for each, then you would create additional tables to hold the unique attributes. These tables would be related to the main table 1-1. The main table would have a type code that you can use to select records of each type.

After you've taken a stab at normalization, post back and we'll review it.