Usando N-Tier em Business Intelligence

N-Tier pode ser um termo hipócrita

Acho que o termo 'N-tier' é hipócrita quando usado no contexto de um sistema de business intelligence. Em sistemas transacionais, 'N-Tier' descreve um sistema distribuído com um servidor de aplicativos, ESB ou alguma outra camada intermediária em rede. Os sistemas de armazenamento de dados não funcionam de maneira análoga a isso, portanto, o termo provavelmente gera confusão.

Separando dados e lógica funcional

Você pode construir um sistema em termos de dados o mais bruto possível e, em seguida, colocar uma camada de transformação nele, que é então consumida por uma camada de relatórios. A camada de transformação pode assumir a forma de:

• Uma série de exibições de banco de dados.

• Uma camada de metadados da ferramenta de relatório (por exemplo, um modelo de relatório ou um universo de objetos de negócios). Uma categoria de ferramentas conhecida como 'Enterprise Information Integration' estende a noção da camada de metadados para algo como uma ferramenta ETL na memória, permitindo que a camada lógica funcional ou de relatórios implemente transformações complexas. No entanto, essa abordagem é difícil de implementar e não é amplamente usada, a menos que algo impeça a implementação de uma arquitetura ETL mais convencional.

• Um conjunto de data marts com seu próprio ETL.

Isso forneceria as camadas 'Dados', 'Lógica Funcional' e 'Apresentação' conforme seu exemplo. Alguns sistemas de data warehouse são implementados um pouco assim, embora (pelo menos IMHO) seja uma espécie de antipadrão. Alguns problemas com o push downstream da lógica de negócios do seu ETL incluem:

• Dependendo dos recursos de seu meio lógico funcional, os possíveis recursos transformadores podem ser limitados, resultando em abstrações com vazamentos que limitam o valor de qualquer recurso de relatório ad hoc colocado acima deles. As ferramentas ad hoc precisam de dados limpos que se comportem de forma consistente, e os dados realmente precisam estar em um formato compatível com a ferramenta.
  
  Se os dados não forem consistentes, limpos e no formato correto, você estará efetivamente limitado a relatórios SQL personalizados dos dados ou à construção de data marts suplementares para oferecer suporte a instalações ad hoc. Contar com data marts tende a proliferar um grande volume de processos ETL terciários ad-hoc com funcionalidade sobreposta, mas sutilmente inconsistente. Isso tende a gerar problemas de reconciliação e qualidade de dados e falha em fornecer uma 'fonte única da verdade'.
  
  Geralmente, essa situação gera uma grande carga de trabalho de manutenção e diminui a confiança da comunidade de usuários.

• Um esquema de banco de dados que não é otimizado para geração de relatórios pode ter um desempenho insatisfatório.

• 'Dados brutos' implica que os dados são mantidos em uma forma bastante isomórfica à fonte, que é mutuamente exclusiva com qualquer noção de dados conformados.

• 'Dados brutos' também estão normalmente disponíveis nas áreas de teste e arquivamento, se necessário para auditoria. Você terá uma classe de usuários avançados que 'querem apenas os dados', e essas pessoas podem ter muita influência política. Permitir que isso continue ao lado de um projeto de data warehouse falha no objetivo de 'fonte única da verdade'.
  
  Se o warehouse tiver um mecanismo de dados adequado (por exemplo, um armazenamento de dados operacionais), ele deverá fornecer a fonte única. Lidar com definições conflitantes e comunidades de usuários que insistem em seus próprios sistemas simplificados é um tópico completo em si.

No entanto, isso é mais comum do que se poderia esperar. Acho que o principal motivo pelo qual encontramos projetos de data warehouse implementados dessa maneira é que as ferramentas ETL são bastante complicadas de se trabalhar se seus requisitos de lógica de transformação forem complexos. As ferramentas ETL muitas vezes têm o efeito de simplificar a arquitetura e forçar a lógica na camada de relatórios, o que degrada significativamente a eficácia da iniciativa de data warehouse. O volume de trabalho e a presença de um banco de dados central dão a ilusão de um data warehouse, ao mesmo tempo em que oferecem poucos benefícios.

Outra visão de N camadas de um data warehouse

Pode-se interpretar 'Dados', 'Lógica Funcional' e 'Apresentação' como um ETL e processo de relatório em um sistema de data warehouse mais bem organizado. Nesse caso, 'Dados' podem ser interpretados como a camada de preparação, 'Lógica Funcional' implementada no ETL, apresentando um armazenamento de dados dimensional e/ou conjunto de data marts e 'Relatórios' implementados por meio de relatórios e consultas ad-hoc suíte.

Considerado prejudicial

Por esse motivo, acho que o conceito de 'N-tier' é inútil e até um pouco falso. Parece muito com algo que uma empresa de middleware ou consultoria pode descrever em um white paper - uma noção teórica falha e até um tanto enganosa que soa bem no papel.