This is a question I am frequently asked, as data modeling seems to be
associated to SQL databases while there is no support (available,
possible, necessary?) for so called NoSQL databases.
To put a possible short answer into perspective, I like to include some preliminary thoughts.
I strongly believe that (business) data modeling is the single most
important discipline for any medium and large organization. To proceed
effectively and efficiently, to acknowledge the principles of data
governance, master data management, data quality etc., each organization
should have one standardized method to create all
their conceptual and logical data models and employ a data modeling tool
that allows them to link and manage all their models under one hood. I
think it's safe to say that, over the past decades and over all
organizations that have practiced data modeling, relational modeling
has proven to be the most relevant and viable method to represent
business data models.
On the other hand, given that most medium and large organizations
cannot avoid to deal with multiple software suppliers, given that
requirements regarding data volume, velocity, views, human-machine
interfaces etc. each may dictate (or at least strongly support) a
particular software solution, organizations find themselves exposed to a
myriad of storage technologies which include SQL, NoSQL, NewSQL (and
whatever-type of) databases.
Despite the attempt of non-RDBMS suppliers to differentiate
themselves from the competition by introducing new jargon,
apparently all storage technologies are based on the concepts of database, table and column, i.e.
the physical models of RDBMS- as well as non-RDBMS-related storages can
be obtained by denormalizing logical models. An organization's data
modeling tool of choice should allow to derive the physical model for
the respective application and storage technology from the existing
business data model while maintaining the link between the objects
(tables, columns) of the business model and the physical storage model.
Doing so does not only serve application development, but constitutes an
important measure to ensure that the organization is in control of
definitions, lineage, usage etc. of all their data elements in order to
suffice legal obligations, achieve regulatory compliance or in general
to be able to flexibly (re)act if business and/or technical requirements
change.
As long as storage technologies can be reduced to the three-level container principle database-table-column
(and potentially other common constructs such as indexes), the
(denormalized) physical models already include the primary ingredients
for the related DDL. The employed data modeling tool should be
extensible to support generating the CREATE / DROP statements (or their
equivalents) for the respective target storage system from a physical
model. (E.g. the current version of Grandite's SILVERRUN modeling tools also offers to generate the DDL for Cassandra and Neo4j.)
If you like to discuss this more in detail or challenge me on the
above, please be invited to comment here or to contact me by email (axel
. troike [at] grandite . com)
[In the spirit of full disclosure: I represent Grandite, a supplier of data modeling tools]
