Gathering Business Requirements and Determining Database Schemas

  • CoolKid40

    SSC Enthusiast

    Points: 183

    What is simplest way to go about gathering business requirements and determining database schemas?

  • pietlinden

    SSC Guru

    Points: 62607

    Don't you determine entities and relationships first, and then determine groupings of those and put those into schemas?

    Your questions are REALLY vague. Maybe you should clarify them.

  • Jeff Moden

    SSC Guru

    Points: 994945

    CoolKid40 wrote:

    What is simplest way to go about gathering business requirements and determining database schemas?

    Create a functional flow diagram.

    --Jeff Moden


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column.
    "If you think its expensive to hire a professional to do the job, wait until you hire an amateur."--Red Adair
    "Change is inevitable... change for the better is not."
    When you put the right degree of spin on it, the number 3|8 is also a glyph that describes the nature of a DBAs job. 😉

    Helpful Links:
    How to post code problems
    Create a Tally Function (fnTally)

  • Cary Hower-563110

    SSChasing Mays

    Points: 632

    I start by asking the business what things they care about (nouns). I then request business definitions of all of those things. These things are either entities or facts of entities. These definitions and some iterative discussions with the business provide me with the information that I need to create a data model. I can then sit down with the business and validate the data model.

    My premise is that the things a business cares about change relatively little with time, at least as long as they stay in the same business. Their processes are more likely to change with time. In my experience, once the business has a good handle on what data they are managing, good business processes to manage that data become more readily apparent. I took this approach over 30 years ago when I designed the patient and claims databases for a large health insurance company. We did not have a relational database at the time but used an in-house written database. The structure remained unchanged for over 14 years, except for new data elements being added as a result of contract changes. I am told that the database was eventually replaced with a relational database.

Viewing 4 posts - 1 through 4 (of 4 total)

You must be logged in to reply to this topic. Login to reply