Early in my career database design/visualization tools were
in their infancy and very expensive.
Because of this I used paper and pencil to define tables and columns, draw
relationships, and worked through the normalization process. I am a visual person and this helped me work
out how the database would meet the requirements of the application that I was
building. In those days we were called
programmer/analysts and we did everything including analysis, design, build,
and support. Any flaws in the design
were made evident when programming was started.
I soon came to the realization that the design phase was critical in
preventing problems in the application. I also learned that a flexible design (one
that would adapt to change) was also important going forward because as
everyone knows change is constant. I
will cover flexible design in another blog.
When modeling tools became popular in the CASE tool era they
automated the process of designing and building databases. I threw out my chicken scratch on paper and
enter the information into a visual tool that would allow me to design and
refine the target implantation and then generate the scripts needed to build
the database. This eliminated the requirement
to hand code it the build scripts.
Data modeling and their tools serve several purposes.
- They aid in the process of collecting and validating business information requirements.
- Relationship rules between data elements (entities) are identified and captured.
- Meta data (definitions) about entities and attributes are captured.
- The build process, including implementation details, is automated.
- Data models serve as a specification, build document, post implementation documentation, and communication tool.
Data modeling results in a clear representation of the validated
business information requirements and provides the ability to quickly create
and re-create the physical implementation.
A data modeler’s approach to designing databases is more
holistic in nature. Meaning that the
implementation is not specific to one application (application
independence). This allows the multitude
of applications, reports, query, data analysis, and interfaces to independently
share the same data. All of these needs
are taken into consideration when the physical implementation is designed by
the data modeler/architect. One of Dr.
Edgar F. Codd’s rules for relational databases states that “all data must be
accessible” has helped in this area.
Gone is the need to develop complex programs to access data stored in
obscure formats.
Traditional RDBMS systems are still in use today and will
not be going anywhere in the near future.
Structured data still has its place and continues to meet the needs of
most applications.
So is data modeling still important for traditional RDBMS systems. I would answer yes to that question. Planning and design even in an agile environment is always better than hacking something together hoping that it will work. Though not evident in the beginning, I had a design flaw in a system that I designed early in my career. It took me several months of hard coding time to remove that flaw. The design and build model still works today. Now we just do it in smaller chunks.
