Good database design begins
before the model. Documentation and user interviews may not be enjoyable to
you, but if you want your database to fulfill the business needs it is supposed
to address, they are critical processes. It is important that your client is
thinking about what data the application needs to be useful. Knowing the scope
of the application and what business purpose(s) it fulfills clarifies your
purpose and process.
Once the functional requirements are documented, the technical specifications
should start taking shape. It is imperative that you ask questions clarifying
how the data relates to other elements and discover additional business rules
and data items. Users are generally more familiar with how the data relates to
itself than they are aware. Asking a few simple questions makes your job a lot
easier. Listen to your client; it will make your job easier and the project
more successful. You do not want to intimidate the user(s) so do not speak
about attributes, relations and domains. Instead, make them feel smart by
speaking their language; ask if a member will ever have multiple addresses. Getting
a handle on what data needs to be stored and how it relates to other data
facilitates the database designing itself (seriously, they do that).
A well designed database accommodates all reporting so use the reporting
requirements to ensure that you have all relevant elements; you should not need
to adjust your design for reports. If you do, it may point to a design flaw or
two.
To recap, requirements are important. They provide you an understanding of the
client’s needs and show your understanding of what data needs to be stored and
how the data relates to itself. Participate in the requirement gathering as the
rest of your team may not ask the questions that you need answered.
Requirements are the start of your database.