Page 1 of 2 12 LastLast
Results 1 to 15 of 16
  1. #1
    Join Date
    Aug 2009
    Posts
    3

    Database Experts Opinions please.

    Okay, at work I'm having a big disagreement with the project management team who has no database experience at all. Here is the issue.

    We have 10 product lines, in each product line there are certain number of attribute names, such as height, weight, color, price and so on. We have a total of 670 attribute names for all 10 product lines. The project management team is wanting to create a master file in excel that contains all 670 attribute names, regardless if the attribute name pertains to the product line or not. So let's say 'Widget A' has only 70 attribute names, they want to still add the other 600 attribute names and enter a dash for the value (You can only import if the value has a character in the field). We have to import each product line one-by-one since that is what the software requires.

    To me, this is not the proper way to build a database since we are creating a database that will have hundreds of thousands of null characters. They say this is normalizing the databse, and I told them it is he complete opposite of normalizing a database.

    I look forward to your opinions as well.

  2. #2
    Join Date
    Apr 2002
    Location
    Toronto, Canada
    Posts
    20,002
    you're both right

    normalization is not about avoiding nulls, unless you are willing to go to 5th normal form (or whatever it is)

    normalization is all about the relationships between the table's primary key and its non-key attributes

    so the single table actually does satisfy 3NF

    however, you are right too, if instead of "normalize" we substitute the verb "design effectively"

    do a search for supertype/subtype -- you may want to use several subtype tables
    rudy.ca | @rudydotca
    Buy my SitePoint book: Simply SQL

  3. #3
    Join Date
    Aug 2009
    Posts
    3
    But the files that we have to create to add in the extra attribute names do nothing, but create a lot more work and add no value. Once the data is loaded into the database, it won't matter.

  4. #4
    Join Date
    Apr 2002
    Location
    Toronto, Canada
    Posts
    20,002
    Quote Originally Posted by ketchupaholic
    But the files that we have to create to add in the extra attribute names do nothing, but create a lot more work and add no value. Once the data is loaded into the database, it won't matter.
    so it sounds like you've made up your mind about the way you want it
    rudy.ca | @rudydotca
    Buy my SitePoint book: Simply SQL

  5. #5
    Join Date
    Aug 2009
    Posts
    3
    8) Not really. My problem is that they are not going to do the work, I am. This is going to take hours, upon hours and accomplish the same thing.

  6. #6
    Join Date
    Dec 2007
    Location
    London, UK
    Posts
    741
    I agree with Rudy's suggestion about using multiple subtype tables. But if it's just a temporary piece of work to do the migration then do whatever works for you and gets the job done most effectively.

  7. #7
    Join Date
    Feb 2004
    Location
    One Flump in One Place
    Posts
    14,912

    Thumbs up

    Quote Originally Posted by r937
    however, you are right too, if instead of "normalize" we substitute the verb "design effectively"
    Just in point of fact, I believe that is a verb and an adverb
    Testimonial:
    pootle flump
    ur codings are working excelent.

  8. #8
    Join Date
    Jun 2003
    Location
    Ohio
    Posts
    12,592
    Quote Originally Posted by ketchupaholic
    8) Not really. My problem is that they are not going to do the work, I am. This is going to take hours, upon hours and accomplish the same thing.
    ...for which you are getting paid, I assume.
    The question you should be focusing on, and which should be driving your design, is how you are going to manage the addition of new product lines and attributes once the database is in production.
    If it's not practically useful, then it's practically useless.

    blindman
    www.chess.com: "sqlblindman"
    www.LobsterShot.blogspot.com

  9. #9
    Join Date
    Mar 2009
    Location
    Sydney, Australia
    Posts
    258
    Ketchupaholic

    I would rather not comment on the reponders so far, but this needs to be stated in order to avoid confusion. There is a lot of misinformation, weird and changing understandings of what Normalisation is. There have been textbooks written about if for almost 30 years, so I will not be "explaining" what it is or getting into "debates". Unfortunately, some responders at this site have not read or understood or practised any of them, but they post responses anyway, and argue with established experts.

    You have asked a simple, straight-forward question, to an expert (you did ask for that), the answer is simple and straight-forward:
    1 You are right.
    It is not just your point about nulls; it is the total lack of Normalisation; and the massive maintenance burden that will follow.
    2 The Project Manager is grossly wrong.
    Typically these people want to do things in the only way they know. It is the bane of developers/DBAs (classy managers understand that they need to manage people whose work they do not understand; idiots want to tell their more technically qualified staff how to do their job).

    How you handle that, is a separate issue. Get everything in writing, including your warnings about the method and the outcome. Print this post. Email it to the auditors now, do not wait for the poverbial to hit the fan. There is a certain undeniable insanity is telling you to implement some unqualified persons design. As long as the instructions are in writing, and attributed to the boss, along with your serious concerns, then there is no danger in implementing the insanity, just step back before it crashes.
    Last edited by Derek Asirvadem; 08-27-09 at 12:43.
    Regards
    Derek Asirvadem (Formerly DerekA)
    Information Architect / Senior Sybase DBA
    Copyright 2009 Software Gems Pty Ltd

    I answer questions from the Original Poster only. If you have a genuine question, as the moderators have requested, start a new thread.

    http://www.softwaregems.com.au

  10. #10
    Join Date
    Apr 2002
    Location
    Toronto, Canada
    Posts
    20,002
    Quote Originally Posted by Derek Asirvadem
    Unfortunately, some responders at this site have not read or understood or practised any of them, but they post responses anyway, and argue with established experts.
    are you referring to me? please confirm or deny
    rudy.ca | @rudydotca
    Buy my SitePoint book: Simply SQL

  11. #11
    Join Date
    Feb 2004
    Location
    One Flump in One Place
    Posts
    14,912
    Derek

    I welcomed you back to the forum. You said you hoped everyone here had grown up and barely paused to write several novels before taking two opportunities to open hostilities with snipes at people that have been helping A LOT of professionals in your absence.

    Please be respectful in your conduct. I would expect that any action taken this time round would be much swifter.
    Testimonial:
    pootle flump
    ur codings are working excelent.

  12. #12
    Join Date
    Jun 2003
    Location
    Ohio
    Posts
    12,592
    Somebody just opened up a big can of stinky-butt.
    Lets open some windows...
    If it's not practically useful, then it's practically useless.

    blindman
    www.chess.com: "sqlblindman"
    www.LobsterShot.blogspot.com

  13. #13
    Join Date
    Oct 2004
    Location
    Melbourne, Australia
    Posts
    201
    GETTING BACK TO THE BUSINESS AT HAND . . .
    Here is a suggestion which might help organise the required data without a lot of work.

    Set up an MS Access database with a master file and with a subfile for each of your attributes. The subfile only holds the keys of the master records which have that attribute (though there is a bonus in that you could add fields to hold attribute-specific data if you wanted to). Your form in Access would contain fields for the master file, plus a listbox allowing multiple entries, where the attributes are listed. You select them simply by clicking on them and the subfiles are updated automatically.
    Output from the system would be driven by queries which export the data to the Excel files desired by management. The nice thing is that the queries can filter out most of the null data which will make the Excel tables more readable.
    More sophisticated data extraction can be handled by VBA functions called up by the Queries.
    I hope this helps.

  14. #14
    Join Date
    Mar 2009
    Location
    Sydney, Australia
    Posts
    258

    Damned if I do, and damned if I don't

    Pootle flump

    Rather than hijacking this thread (after all we are here for the seeker, not for arguing amongst ourselves, right), I have responded to you in a separate thread in Suggestions & Feedback:Completely False Information and Introduced Confusion
    Last edited by Derek Asirvadem; 08-28-09 at 02:10. Reason: Non-technical discussion moved to a separate thread
    Regards
    Derek Asirvadem (Formerly DerekA)
    Information Architect / Senior Sybase DBA
    Copyright 2009 Software Gems Pty Ltd

    I answer questions from the Original Poster only. If you have a genuine question, as the moderators have requested, start a new thread.

    http://www.softwaregems.com.au

  15. #15
    Join Date
    May 2009
    Location
    India
    Posts
    66
    Would you put 12 month's figures in an row for an annual sales data base - say? What happens if you want to anlyse more than 12 months and YOY or moving average?

    In the OP's (ketchupaholic) query, what happens if you want to add a 671st attribute? Change the structure? Reimport all master data?

    IMHO, a different design is definitely called for.

    (1) Product line master.
    (2) Attributes master.
    (3) (Product line + attribute) master having two foreign keys.
    (4) Transaction data.

    End

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •