Há quem pense que a modelação de dados é passado e que já não é relevante. De facto, a teoria da modelação de dados já tem mais de 30 anos e algumas ferramentas andam por cá há cerca de 20 anos. No entanto, a modelação de dados continua a ser essencial. Na realidade, actualmente até pode ser considerada mais necessária do que no passado.
Apesar de existirem outras técnicas e notações de modelação, como a Modelação de Processos de Negócio (BPM), ou a Linguagem de Modelação Unificada (UML), a modelação de dados foi concebida unicamente para capturar com exactidão os requisitos de dados de negócio e transformá-los em num desenho estrutural fiável de base de dados. O elemento diferenciador chave é o facto de só a modelação de dados colocar o enfoque nos "dados estáticos", enquanto que todas as outras técnicas e notações colocam o enfoque em "dados dinâmicos".
Outra forma de dizer o mesmo é afirmar que a modelação de dados se concentra em questões que conduzem a um desenho de base de dados sólido, enquanto que as outras técnicas se concentram em questões que resultam em melhores desenhos aplicacionais, ou em coisas úteis para os programadores, nomeadamente estruturas de dados, objectos, classes, métodos, geração do código aplicacional, etc.
Têm existido vários conflitos - muitos deles legais - com pedidos de indemnização avultados porque as aplicações de bases de dados apresentam problemas de desempenho e/ou de exactidão dos dados. Em todos os casos não se conseguiram criar modelos de dados para os requisitos de negócio, algo que se traduziu em perda de eficácia dos dados. Em muitos casos, o desenho de bases de dados ad-hoc, ou a utilização de técnicas e de ferramentas mais programáticas, também resultou em desenhos ineficientes. Os queixosos ganharam sempre este tipo de disputas.
Utilização da modelação de dados no Data Warehousing
Uma das razões porque a modelação de dados tem vindo a ressurgir em força prende-se com o crescimento dos armazéns de dados. Uma vez que o armazenamento de dados é relativamente barato nos dias que correm, a maior parte das organizações podem manter grandes quantidades de dados para a tomada de decisões estratégicas. Com a acumulação de muitos sistemas OLTP (online transaction processing), existem duas formas chave de abordar um data warehouse cheio de dados:
Figura 1. Data warehouse via ODS intermédio.
Figura 2. Data warehouse via alimentações separadas.
Existem opiniões divergentes sobre qual das abordagens é melhor. Neste texto não iremos falar desse aspecto, mas antes referir que, independentemente da abordagem seguida, o desenho de base de dados é vital. Isto porque num data warehouse os próprios dados e a informação de negócio que contêm são o activo mais valioso e relevante. As queries típicas a data warehouses, bem como os relatórios produzidos com base em ferramentas de inteligência de negócio, irão processar esse activo para suportarem decisões estratégicas.
Uma forma chave da modelação de dados suportar o esforço de data warehousing consiste em mapear os campos de dados para os seus correspondentes no data warehouse. O mapeamento cuidado dos dados de negócio de front-line para o data warehouse ajudará no desenho de queries e de relatórios, bem como ao nível dos esforços de programação ETL (extract, translate and load). Sem este tipo de mapeamento, à medida que os sistemas de OLTP utilizados forem evoluindo, deixará de existir qualquer ligação automática à informação de data warehousing dependente. Consequentemrente, será necessário proceder a uma quase total reengenharia, em vez de seguir simplesmente as ramificações da fonte de dados OLTP que vão dar ao data warehouse e aos pontos de BI (inteligência de negócio).
Utilização da modelação de dados no desenvolvimento de sistemas
A modelação de dados é importante, não só para os projectos de data warehousing, mas também para o desenvolvimento de sistemas OLTP mais tradicionais. Infelizmente, as pessoas costumam deixam-se enredar de tal modo em novos paradigmas - como a extreme programming, agile software development, ou scrum - que comprometem ou passam completamente ao lado da modelação de dados. O problema nestes casos é que as novas abordagens nem sempre dizem exactamente como é que a modelação de dados deve ser incorporada. Consequentemente, as pessoas esquecem-na.
Independentemente da metodologia de desenvolvimento escolhida, a modelação de dados deve ser integrada no processo de desenvolvimento sempre que isso fizer sentido. A Figura 3 mostra como é que a modelação de dados conceptual e física deve encaixar-se no processo global de desenho de bases de dados, independentemente de estarmos perante um sistema totalmente novo, ou um sistema existente que precisa de ser actualizado ou submetido a um processo de total reengenharia.
Figura 3. Esquema geral da modelação de dados.
A modelação de dados como parte de um processo de desenvolvimento formal
Existe uma última razão para que a modelação de dados tenha vindo a ganhar mais atenção. Em muitos casos, as organizações estão a exigir modelos de dados para aceitarem entregáveis no processo de desenvolvimento. Isto poderá ser uma tentativa das empresas seguirem os conceitos inerentes ao CMMI (Capability Maturity Model Integration) do SEI (Software Engineering Institute) e a outras metodologias ou standards internacionais.
A ideia é bastante simples: para tornar o nosso processo de desenvolvimento mais maduro, independentemente da técnica, precisamos de pensar tanto em termos de processos como de ferramentas utilizados para alcançar o resultado desejado. Por exemplo, a utilização adequada e eficaz de ferramentas de gestão de projecto é referida normalmente como a única forma de passar do nível um (Caos) para o nível dois (Repetível) do modelo CMMI. A ideia central de que os processos e as ferramentas em conjunto podem melhorar a maturidade ajudou a revigorar o interesse pela modelação de dados.
Baseado num texto com o título "Why Data Modeling Is Still Relevant", da autoria de Bert Scalzo, publicado no site http://solutions.internet.com/.