Gathering Business Requirements and Determining Database Schemas

Question

Post reply

Gathering Business Requirements and Determining Database Schemas

CoolKid40

SSC Enthusiast

Points: 186
More actions
October 14, 2019 at 6:01 pm

#3688620

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

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

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

pietlinden SSC Guru Points: 63503 More actions · Answer 1

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: 1004324 More actions · Answer 2

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.

Change is inevitable... Change for the better is not.

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

Cary Hower-563110 Say Hey Kid Points: 662 More actions · Answer 3

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.