Processo de construção de um DW

Fiz uma série de posts falando sobre BI, onde falei de conceitos e ferramentas relacionadas ao assunto. Contudo, senti falta de falar sobre o processo de construção de DW e sobre as atividades envolvidas nesse processo.

Entendo que o primeiro passo é entender o que o cliente quer, definindo quais métricas e quais descritores ele quer analisar.

Definido o objeto de estudo, é importante buscar nos sistemas transacionais, os insumos para  compor o DW e verificar a forma que estes dados serão extraídos.

Com os dados em mãos, partimos para higienização dos mesmos. Neste caso, importa-se esses dados para uma área que chamados de stage, aonde realizamos transformações e enriquecimentos. Nesta hora, o auxílio de uma ferramenta de ETL ajuda bastante.

Após o tratamento dos dados, partimos para a modelagem dimensional, onde criamos as dimensões e os fatos que comporão o DW.

Feito isso, é preciso montar uma estratégia para realizar a carga das tabelas criadas. Mais uma vez uma ferramenta de ETL ou até mesmo, scripts nos ajudarão nesta tarefa.

Segue abaixo as atividades envolvidas no processo. 

DW pronto, é importante encontrar uma boa ferramenta de visualização de dados para permitir a análise dos dados.

De forma resumida é isso.

Inté!

O que é Engenharia de Dados

         Até pouco tempo atrás, nos deparávamos com um cenário onde os sistemas eram monolíticos, persistindo e consultando informações em bancos de dados relacionais. 

        Os mais avançadinhos criavam bancos de dados dimensionais visando performance e facilidade na busca das informações.

        Com o tempo, esse cenário foi mudando. Com o advento da Internet e Internet das coisas, hoje praticamente tudo gera informação, nem sempre de forma estruturada. O formato varia de acordo com o dispositivo que gera a informação. Exemplo: Câmeras que geram fotos, roteadores que geram logs em formato txt, uma peça de um automóvel que indica ao fabricante a necessidade de reparo, entre outros.

        Daí surge algumas questões: Como e onde guardar esses dados? Como produzir informação com os dados gerados se estes, nem sempre são estruturados e possui diversos formatos. Seria o DBA o responsável por resolver essas questões? É nesse cenário que surge a Engenharia de Dados, visando promover a governança das estruturas que irão receber dados desta natureza.

     Em um outro post falamos de ETL, aonde extraímos dados de bancos relacionais, realizamos transformações e geramos informações de acordo com a necessidade do negócio envolvido, com a finalidade de alimentar um banco de dados dimensional(Um DW estruturado). Mas, quando estamos lidando com dados semiestruturados ou ainda dados não estruturados, a ordem dos fatores se altera. Ocorre outro tipo de processo que é conhecido como ELT. É feita a carga desses dados não estruturados para o que chamamos de Datalake, onde é feita a transformação dos dados.

    Resumindo, um Engenheiro de Dados é o profissional que desenvolve, opera e mantem estruturas de dados complexas e heterogêneas, sendo responsável pela segurança, integridade, disponibilidade e confiabilidade desses dados.

O cinto de utilidades ETL

 Na postagem anterior, ficaram algumas questões a serem respondidas. Para responder a estas questões, vamos criar um cenário hipotético.

A empresa na qual você trabalha demandou a criação de uma base de dados OLAP para subsidiar um Data Warehouse. Essa empresa possui dois Sistemas OLTP para apoiar o trabalho desempenhada por ela: Um sistema de gestão administrativo no qual são mantidos o cadastro dos funcionários entre outros e outro sistema de gestão para gerir vendas efetuadas pela Empresa. Ao demandar a criação da base OLAP, o solicitante indicou aonde obter aos dados que irão compor a base em questão, com a finalidade de analisar as vendas efetuadas pelos funcionários da Empresa. Parte dessas informações encontram-se na base de dados que subsidia o sistema administrativo. Outra parte, pode ser obtida na base de dados do sistema que subsidia o sistema de vendas e ainda há informações constantes em planilhas preenchidas pelos vendedores e por seus gerentes.

Daí você pensa: Vou fazer um select desses dados nas bases de dados indicadas e fazer um insert no banco de dados OLAP. Simples assim! Simples? Como fica a questão das planilhas? E ainda como vincular as informações extraídas desses sistemas e das planilhas mencionadas? Além disso, verificou-se que os dados contidos nessas bases de origem possui formatos distintos, ou seja, não seguem um padrão único. 

Chega a fazer a gente pensar que com a solução do Select/Insert é impossível resolver essa questão. Impossível não é, mas daria um "trabalhão" danado. Ainda mais, se levássemos em consideração a atualização periódica dessa base OLAP.

Complicou, né? E para descomplicar, surgiram no mercado ferramentas que fazem esse trabalho de Extração, Tranformação e carga dos dados.

ETL, vem do inglês Extract Transform Load, ou seja, Extração Transformação Carga. O ETL visa trabalhar com toda a parte de extração de dados de fontes externas, transformação para atender às necessidades de negócios e carga dos dados dentro do Data Warehouse. 

Abaixo, uma ilustração do processo

Vamos descrever as atividades envolvidas nesse processo:

Na extração, é feita a coleta de dados dos sistemas de origem , extraindo-os e transferindo-os para o ambiente de DW, permitindo ao sistema de ETL operar sobre os dados de forma independente.

 Na etapa de transformação, é feita a limpeza, os ajustes e a consolidação dos dados ingeridos. É nesta etapa que realizamos os devidos ajustes, podendo assim melhorar a qualidade dos dados e consolidar dados de duas ou mais fontes. O estágio de transformação aplica uma série de regras ou funções aos dados extraídos para ajustar os dados a serem carregados. Algumas fontes de dados necessitarão de muito pouca manipulação de dados. Em outros casos, pode ser necessários trabalhar algumas transformações, como por exemplo, junção de dados provenientes de diversas fontes, seleção de apenas determinadas colunas e tradução de valores codificados. Por exemplo, se o sistema de origem armazena 1 para sexo masculino e 2 para feminino, mas o data warehouse armazena M para masculino e F para feminino.

A entrega ou Carga dos dados, consiste em fisicamente estruturar e carregar os dados para dentro da camada de apresentação seguindo o modelo dimensional. Dependendo das necessidades da organização, este processo varia amplamente. Alguns data warehouses podem substituir as informações existentes semanalmente, com dados cumulativos e atualizados, ao passo que outro DW (ou até mesmo outras partes do mesmo DW) podem adicionar dados a cada hora. A latência e o alcance de reposição ou acréscimo constituem opções de projeto estratégicas que dependem do tempo disponível e das necessidades de negócios. 

Há ainda a parte de Gerenciamento que é composta por serviços para auxiliar no gerenciamento do DataWarehouse. Aqui existem tasks específicas para gerenciamento de jobs, planos de backup, verificação de itens de segurança e compliance.

A intenção aqui, era fazer um overview sobre o assunto. Existem diversas ferramentas deste tipo no mercado. Cabe a vocês pesquisarem sobre elas:

• Data Stage da IBM 
• PowerCenter da Informatica
• Data Integrator da Oracle
• SSIS – Sql Server Integration Services da Microsoft

Hoje com o crescimento dos projetos de Big Data aumenta-se mais ainda a necessidade de fazer ETL entre plataformas heterogêneas, para isso, projetos como o Hadoop, possuem ferramentas próprias para carga de dados, como :

SQOOP – Ferramenta para movimentar dados dentre bancos de dados relacionais e o ambiente Hadoop.

HIVE – Ambiente de SQL sobre um cluster Hadoop.

PIG – Ferramenta de Script para transformação e processamento de dados.

SPARK – Framework de processamento em memoria.

É isso!

Modelagem dimensional na prática

 Em outro post, tentei desmistificar o conceito de Data warehouse. Voltando a ler o Post, senti falta de um exemplo prático que mostrasse as vantagens e desvantagens de modelar de forma dimensional uma base de dados para atender a um DW.  A ideia deste post é tentar apresentar uma resposta a estas questões.

Conforme mencionado no outro post, o DW visa resolver questões de performance na execução das consultas.  E como se resolve isso? A forma encontrada foi modelar a base de um jeitão meio diferente, o que ficou conhecido como Modelagem dimensional.

A Modelagem dimensional é uma técnica de design de banco de dados projetada para suportar consultas de usuários finais em um Data Warehouse.  

A ideia é que os usuários consigam fazer consultas sem necessitar da ajuda de profissionais especializados em SQL. 

Em modelos relacionais, é prezada a questão da normalização. Na modelagem dimensional, para melhorar o desempenho das consultas, há redundância planejada dos dados, compensando os gastos com armazenamento e atualização das informações, fazendo com o que a base de dados fique de certo modo desnormalizada.

O modelo dimensional é composto por tabelas fato e por tabelas conhecida como dimensões.

Na prática, a tabela fato armazena as chaves das dimensões e armazena também as métricas a serem analisadas por quem vier a consultar o DW.

Já as tabelas de dimensão são compostas basicamente de atributos que descrevem as entidades envolvidas no modelo. 

Modelando desta forma, o modelo fica parecido com uma "estrela"

Nesse modelo os dados são desnormalisados para evitar joins entre tabelas, diminuindo o tempo de consultas, no entanto devido a repetição de dados, utiliza mais espaço em disco. A vantagem desse modelo é a eficiência na extração de dados, o que é um grande diferencial em se tratando de um datawarehouse.

A chave da tabela fato é uma chave composta, uma vez que trata-se da junção das chaves das tabelas de dimensão.

Importante também é não misturar os fatos. Exemplo: A finalidade é analisar o volume de vendas? Devemos criar uma tabela fato específica para isso. Ao analisar o volume de compras, deve-se criar outra tabela fato com essa finalidade.

Quando a quantidade de atributos das dimensões é muito grande,  costuma-se normalizar as tabelas de dimensão. Neste caso, o modelo fica parecendo um floco de neve (Snow Flake ). Isto porque cada tabela de dimensão seria normalizada, "quebrando-se" a tabela original ao longo de hierarquias existentes em seus atributos. 

A adoção de um modelo ou de outro de implementação trás vantagens e desvantagens em relação a performance das consultas e volume de armazenamento dos dados. Cabe aos analistas decidirem qual será a melhor abordagem.

Cheguei a conclusão de que a melhor maneira de entender a modelagem dimensão é através de exemplos. Abaixo coloquei alguns exemplos de modo a clarear o entendimento deste tipo de modelagem.

Exemplo de um modelo conceitual

Exemplo de modelo para análise de despesas

Exemplo de modelo para análise de produção

A dica aqui é procurar nos pais dos burros (Google) mais modelos de modo a fixar a ideia desse tipo de modelagem.

Como entrevistar os usuários de um DW? Segue um texto legal do Piton nesse link https://rafaelpiton.com.br/blog/data-warehouse-como-modelar/

E aí? O post deu uma clareada? Em caso afirmativo, fico satisfeito. Tem outras questões a serem respondidas. Como importar os dados da origem de dados que comporão as tabelas do DW? Como atualizar esses dados ao longo do tempo? Se os dados que vierem compor o DW provierem de fontes de dados distintos, com formatos diferentes, como unificar o padrão desses dados? A resposta a essas perguntas estará em outro post sobre ETL.

Valeu!!!

Desmistificando a BIG DATA

Quando iniciei na faculdade, nos final dos anos 90, os mais abastados tinham um computador pessoal em casa, acesso discado a internet e um "tijolão" pendurado na cintura.

Naquela altura, o DOS estava dando lugar ao Windows, os arquivos textos que registravam as informações geradas pelos sistemas de informação, já haviam sido substituídos por banco de dados relacionais. Ao invés de ler ou escrever diretamente em arquivos texto, os sistemas de informação passaram essa responsabilidade para os SGBD's e o acesso aos dados passou a ser feito através de SQL.

Os sistemas de informação já possuíam uma arquitetura cliente servidor (sistema instalado na máquina do usuário e banco de dados instalado em um servidor de banco de dados).

Nessa época, um banco de dados com cinco, dez, cinquenta tabelas, atendiam bem as demandas.

 

O volume de informações crescia exponencialmente. Logo verificou-se que o modelo relacional não servia para um volume grande de informações. As consultas já estavam comprometendo o desempenho dos bancos. Como solução, surgiu a modelagem dimensional e com ela, os conceitos de BI, DATA WAREHOUSE, bases OLAP.

Com a popularização da Internet, os navegadores Web se tornaram os aplicativos mais usados nos computares pessoais. Logo este tipo de aplicação se tornou uma plataforma para o uso dos sistemas de informação.

Os tijolões deram lugar a celulares menores e logo em seguida, aos smartphones. Surgem os aplicativos mobile. 

Lembro de um professor de JAVA entusiasta que falava que nossos eletrodomésticos no futuro, teriam embutidos, sistemas informatizados com funcionalidades, aonde seria possível registrar listas de compras, receitas, bloco de recados, etc.

Como estava iniciando os meus estudos na área de tecnologia de informação, confesso que achava aquilo tudo uma bobagem e ficava me perguntando se aquilo de fato ia acontecer. 

E quanto aos eletrodomésticos informatizados? Aconteceu! Com a popularização da Internet, praticamente TUDO passou a estar conectado a ela. Estamos falando que as coisas passaram a se conectar a Internet, o que ficou conhecido como  INTERNET DAS COISAS. E essas coisas passaram a gerar dados.

Confesso a vocês que não tenho noção do volume de dados que é produzido a cada segundo por esses dispositivos, mas podemos imaginar que é algo astronômico. Pesquisando na Internet sobre o assunto, fala-se em zetabytes de dados.

Sem ir muito longe, pense na quantidade de posts que nós fazemos no Facebook ou ainda na quantidade de pesquisas que realizamos na Internet e multiplique isso pelo número de usuários desses serviços no mundo todo. Imagine ainda, a quantidade de vídeos produzidos e publicados no Youtube a cada minuto.

Levando-se em conta a topologia, a natureza híbrida dos dispositivos conectados a Internet, o grande volume e a alta velocidade com o qual esses dados são produzidos, surgem algumas questões: Aonde armazenar esses dados? Levando-se em conta que os dados produzidos por esses dispositivos nem sempre são estruturados, como processa-los e armazena-los?  E Por fim, como produzir informação com base nesses dados, de modo a gerar insights interessantes? É grande o desafio, não é mesmo? 

BIG DATA foi o termo criado para descrever esse cenário com imenso volume de dados - estruturados ou não - que são gerados a cada segundo e que impactam os negócios no dia a dia.

Num cenário como este, algumas premissas devem ser alcançadas. As tecnologias envolvidas devem ser capazes de suportar grande VOLUME de dados, capazes de armazenar uma grande VARIEDADE de dados (estruturados, semiestruturados e não estruturados) e possuir VELOCIDADE na ingestão, processamento e retorno das informações.

A cada dia, novas tecnologias surgem para solucionar problemas relacionados ao cenário descrito aqui, mas sobre essas, eu falarei em outros Posts, OK?

Espero ter mais esclarecido do que confundido.

Valeu!

Descomplicando uma sopa de letrinhas chamada Business Intelligence

Você faz parte de uma equipe de TI de uma empresa relativamente nova. Desenvolve um sistema de gestão para a mesma, visando a este apoiar as atividades dos colaboradores de outras áreas da Empresa.

Daí o gerente da área de vendas da Empresa pede um relação das vendas efetuadas nos últimos três anos. Mais tarde, esse mesmo gerente solicita a relação dessas vendas agrupados por Vendedor, de modo a calcular as comissões a serem pagas para esses vendedores. A Empresa vai crescendo, inaugurando uma filial a cada ano e consequentemente o volume de vendas, de vendedores e de dados sobre as vendas também.

Aquela relação solicitada constantemente pelo Gerente cresce exponencialmente dificultando a análise desta, além de onerar o Banco de Dados alimentado pelo velho e bom Sistema de Gestão mantido por você. Seu Gerente que muitas vezes não entende nada de TI, fala que vem recebendo uma série de reclamações sobre a lentidão do Sistema e fala pra você se virar de modo a resolver o problema.

Para complicar ainda mais, surgem novos pedidos de informações de vendas daquele e de outros gerentes de outras áreas da Empresa. Você então pensa: "Vou ter que extrair essas informações em horários de vale (momentos em que os usuários não estão utilizando o Sistema). A empresa começa a receber uma quantidade imensa de pedidos e resolve ampliar o expediente de trabalho de modo a atender esses pedidos. Extrair as informações fica cada vez mais difícil, mais demorado.

Os colaboradores da Empresa começam a reclamar da demora na entrega das relações solicitadas a equipe de TI. Chega um momento que você não consegue mais atender as solicitações dos colaboradores no tempo que as atividades da Empresa exige. Daí você pensa: "Tô fudido!" e se pergunta:"O que fazer?".

Ao mesmo tempo, aquele diretor que tomava as decisões baseado nas experiências dele  deixa a Empresa e no lugar dele, entra um camarada bem intencionado, mas que não possui experiência tão aprofundada quanto a do antigo diretor.

O novo diretor chega e demanda informações dizendo que a Empresa está perdendo vendas por falta de produtos em alguns momentos e em outros, tendo que fazer promoções por conta de muito produto em estoque. Daí você pensa:"Dá zero pra ele! Será que esse diretor não é burro?". E daí ele fala pra você: "Arruma uma solução, ô inteligência!"

Você então começa pensar num modo de resolver a situação. O diretor precisava se basear em informações para tomar decisões. Por mais que o diretor tivesse experiência, dependendo do cenário, as decisões por mais que pareçam estar corretas poderiam acarretar em consequências desastrosas para a Empresa.

A conclusão a que você vai chegar é que a empresa deveria adquirir uma inteligência de modo a evitar e prever problemas futuros para o negócios da Empresa. E é aí que o BI (Business Intelligence), surge.

Hoje em dia o pai Google tem solução pra tudo. Você digita  algo no google rezando pra que surja uma resposta. Entaum o Google mostra um monte de coisas.BI,OLAP,OLTP, DW, modelagem dimensional...  Pesquisando um pouco mais, eis que surge o nome de um camarada de sobrenome "Kimbal" que já vinha pensando sobre o assunto há muito tempo.

A primeira conclusão a que você vai chegar é que não devemos utilizar a base de dados do Sistema de gestão para extrair as informações para apoiar a decisões da empresa. Segundo a terminologia esses sistemas são conhecidos como OLTP (Online Transaction Processing ou Processamento de Transações em Tempo Real) são sistemas que se encarregam de registrar todas as transações contidas em uma determinada operação organizacional.

Bom, se você não pode usar o Sistema de Gestão da Empresa, e muito menos a base de dados que ele alimenta, como resolver o problema? A solução será utilizar ou desenvolver um outro tipo de sistema que proporcione a capacidade de ter idéias sobre os dados, permitindo analisá-los profundamente em diversos ângulos. Esses sistemas são classificados como do tipo OLAP (Online Analytical Processing).

Para modelar o Sistema de Gestão, você fez uso da metodologia de modelagem do tipo Entidade - Relacionamento. O tal do Kimball preconizou que para modelar uma base de dados para um sistema do tipo OLAP deveria se fazer isso de um jeitão meio diferente. Surge então modelagem dimensional, onde a ideia é criar um modelo que se destine à análise de dados. No que diz respeito à análise de dados, o que se espera do modelo de dados para um sistema OLAP é que:

• Seja uma representação simples do modelo de negócios estudado;
• Seja um modelo físico de fácil interpretação, de modo que usuários sem treinamento formal em TI possam entendê-lo;
• Facilite a implementação física do modelo de modo a maximizar performance das consultas aos dados.

 Portanto, no modelo multidimensional, deixamos de focar a coleta de dados para nos ocuparmos com a consulta aos dados.

Isso não quer dizer que você deva esquecer a modelagem relacional. Tudo o que sabemos a respeito de modelagem relacional, vale novamente para a modelagem multidimensional.  Na modelagem multidimensional, teremos novamente que identificar entidades, tabelas, atributos, chaves primárias, integridade referencial e normalização. A principal diferença está em relação à normalização.

O modelo multidimensional usa sim normalização, mas considera apenas até a Segunda Forma Normal.

Damos o nome de modelo multidimensional ou modelo relacional em esquema estrela por causa da distribuição das tabelas no diagrama. Teremos sempre uma tabela central, que armazena as transações que vamos analisar. Esta tabela é chamada de tabela fato. Ao redor da tabela fato, temos as tabelas que chamamos de dimensões.

Todas as dimensões se relacionam exclusivamente com a tabela fato, daí a referência da estrela.

Traduzindo isso para o modelo proposto inicialmente, temos como resultado o modelo a seguir:

Este modelo é chamado de estrela porque a tabela de fatos fica ao centro cercada das tabelas dimensionais assemelhado a uma estrela. Mas o ponto forte a fixar é que as dimensões não são normalizadas.

No final das contas, o que nos importa é que a tabela fato armazena os indicadores que iremos analisar e as chaves que caracterizam a transação. Estas chaves são os elos de ligação com as tabelas de dimensão. Estas, por sua vez, armazenam as classificações que usaremos para analisar os indicadores. Cada dimensão registra uma entidade que caracteriza a transação e mais todos os atributos associados a esta entidade.

Algumas implicações sobre este modelo são descritas a seguir:

Característica 1 - Uma das candidatas a chave primária da tabela fato seria uma chave composta pelas chaves primárias de todas as dimensões.

Característica 2 - As dimensões devem conter todos os atributos associados à sua chave primária. Por exemplo: digamos que temos uma dimensão TEMPO no nosso modelo que monitora transações por dia. Neste caso, a dimensão conteria todos os atributos relacionados à chave dia: mês, trimestre, ano, dia da semana, semana do ano, etc. 

É por conta desta característica das dimensões que dizemos que o modelo multidimensional está na Segunda Forma Normal. Para lembrar um pouco da teoria sobre normalização, observe que as tabelas do modelo identificam as entidades descritas (não possuem tabelas aninhadas) e cada atributo não-chave da chave primária inteira.

Mas o modelo não atende à Terceira Forma Normal, porque, neste caso, suas tabelas precisariam respeitar os dois critérios que acabamos de descrever e ainda atender a mais um: que não existam dependências entre atributos não chave. Claramente isso não acontece com as tabelas de dimensão, que incluem até as hierarquias de atributos associados à chave primária.

Característica 3 - Os atributos de cada dimensão devem ser organizados em uma seqüência lógica que caracterize a(s) hierarquia(s) relacionada(s) à chave primária.

Dizemos que existe uma relação hierárquica entre dois atributos quando há entre eles uma relação de um para muitos. Uma hierarquia é caracterizada pelo encadeamento de dois ou mais atributos que apresentam relação hierárquica entre si.

Assim, no exemplo da dimensão TEMPO descrito acima, identificamos três hierarquias, como descrito a seguir: Dia, mês, trimestre, ano;

Além do modelo estrela existe uma outra estratégia de modelagem chamada modelo Floco de Neve (Snow Flake)

No modelo Floco, as tabelas dimensionais relacionam-se com a tabela de fatos, mas algumas dimensões relacionam-se apenas entre elas, isto ocorre para fins de normalização das tabelas dimensionais, visando diminuir o espaço ocupado por estas tabelas, então informações como Categoria, Departamento e Marca tornaram-se tabelas de dimensões auxiliares.

Considerações sobre ambos modelos

O Modelo Floco (Snow Flake) reduz o espaço de armazenamento dos dados dimensionais mas acrescenta várias tabelas ao modelo, deixando-o mais complexo, tornando mais difícil a navegação pelos softwares que utilizarão o banco de dados. Um outro fator é que mais tabelas serão utilizadas para executar uma consulta, então mais JOINS de instrução SQL serão feitos, tornando o acesso aos dados mais lento do que no modelo estrela.

O Modelo Estrela (Star Schema) é mais simples e mais fácil de navegação pelos softwares, porém desperdiça espaço repetindo as mesmas descrições ao longo de toda a tabela, porém análises feitas mostram que o ganho de espaço normalizando este esquema resulta em um ganho menor que 1% do espaço total no banco de dados, sendo assim existem outros fatores mais importantes para serem avaliados para redução do espaço em disco como a adição de agregados e alteração na granularidade dos dados, estes temas serão abordados em colunas posteriormente.

O recomendado é utilizar um modelo estrela, pois fornece um acesso mas rápido aos dados e mais fácil de se navegar, criando tabelas auxiliares para dimensões somente para dimensões especificas quando for estritamente necessário ou quando demonstrar um beneficio que justifique a perda de desempenho nas consultas, que também não é tão grande dependendo da forma que estas tabelas são construídas e a quantidade de registros que elas contiverem.

A modelagem dimensional é usada para modelar um banco que irá subsidiar sistemas do tipo OLAP. A esse tipo de banco de dados, damos o nome de DATA WAREHOUSE que nada mais é que um banco com dados extraídos de um banco de dados que subsidia sistemas do tipo OLTP.

Isto não quer dizer que um data warehouse possua apenas dados provenientes de um BD relacional. Um DW pode conter informações provenientes de planilhas, arquivos texto, webservices, entre outros.

Outro conceito importante é o que chamamos de Data Mart que são subconjuntos de dados de um Data warehouse.

Muito bem! Você modelou o DW da Empresa. Mas e os dados? Como popular as as tabelas fato e as dimensões? Qual estratégia utilizar para fazer isso? Daí surge o conceito de ETL do inglês Extract Transform Load (Extração Transformação Carga). São ferramentas de software cuja função é a extração de dados de diversos sistemas, transformação desses dados conforme regras de negócios e por fim a carga dos dados geralmente em um Data Mart e um Data Warehouse, porém nada impede que também seja para enviar os dados para um determinado sistema da organização. A extração e carga são obrigatórias para o processo, sendo a transformação/limpeza opcional.

Depois de falar de vários conceitos envolvidos na construção de um DW, segue um modelo com a finalidade de ilustrar um processo de BI.

Bom, é isso aí! Será que descompliquei a sopa de letrinhas? Cabe ressaltar que isso é um resumo que fiz para fixar os conceitos, mas há muito a se discutir sobre o assunto.

Até a próxima!

Projeto Físico de Banco de dados

Após a criação do modelo lógico de banco de dados, partimos para a construção do modelo físico, ou seja, produzimos um desenho com a definição das tabelas e de suas colunas com os tipos de dados, de seus índices , visões, relacionamentos, etc.

Cabe aqui colocarmos algumas regras para criação das tabelas.

Quando temos um relacionamento um para um entre duas entidades, devemos avaliar a necessidade de criarmos duas tabelas. Geralmente quando se tem um relacionamento deste tipo entre duas entidades cria-se apenas uma tabela.

Para os relacionamentos um para muitos entre duas entidades, devemos criar duas tabelas onde a chave primária ficará do lado um e a chave estrangeira no lado muitos.

Nos relacionamentos muitos para muitos, além das duas tabelas representando as duas entidades que se relacionam, cria-se uma terceira tabela que recebe a chave das duas tabelas criadas para as entidades em questão.

No caso de entidade com auto-relacionamento um para muitos, cria-se uma tabela com uma chave estrangeira que receberá valores da chave primária da própria tabela.

Para auto-relacionamento muitos para muitos cria-se duas tabelas onde um delas recebe a duas chaves de uma mesma tabela.

Em casos de relacionamento ternário, utiliza-se a tabela associativa criada para associar tabelas cujo relacionamento é muitos para muitos inserindo uma nova chave a essa tabela.

Em caso de Generalização/Especialização, podemos optar por duas alternativas. A primeira é adicionar os atributos das entidades especializadas na tabela da entidade genérica. A segunda é criar uma tabela para a entidade generalizada e tabelas para as entidades especializadas.

Após a criação das tabelas devemos definir os tipos de dados das colunas que as constituem.

Após a conclusão do modelo físico, devemos elaborar um script em linguagem SQL para a criação das tabelas no banco de dados. Existem uma série de ferramentas de apoio que auxíliam ao analista na elaboração desses scripts. Erwin, Power Designer são alguns exemplos de ferramenta CASE para este propósito.

É possível também realizar o que chamamos de engenharia reversa, ou seja, a partir de um banco de dados já implementado, gerar os modelos físico e lógico do banco de dados.

Bom, é isso aí!

Abraço!

HUGO

Projeto lógico de Banco de dados

No último post falamos sobre alguns conceitos importantes sobre bancos de dados. Aqui iremos apontar quais etapas devem ser realizadas para criação de um modelo conceitual de um banco de dados.

O projeto lógico de banco de dados consiste na análise e modelagem utilizando o modelo de entidade e relacionamento e normalização de dados.

Copiando Peter Chen, as principais etapas para construção de um projeto lógico de banco de dados são:

1. Identificar as entidades;
2. Identificar os tipos de relacionamentos entre essas entidades;
3. Desenhar o diagrama de entidade X relacionamento prevendo os itens acima;
4. Identificar os atributos que as entidades terão;

Nomalização de dados

A normalização é o processo pelo qual são aplicadas regras a um conjunto de dados para se obter uma estrutura de dados quase livre de redundâncias. Ao final do processo de normalização, deve-se valida-lo com o modelo de entidade e relacionamento.

Esse processo pode ser feito em até seis etapas, mas geralmente, ao se chegar a terceira etapa( terceira forma normal) já se obtem um modelo de dados estável.

As três fases de normalização de dados são:

• primeira forma normal - O objetivo aqui é eliminar grupos de dados repetitivos da estrutura e coloca-los em uma nova entidade.
  

Vamos analisar uma nota fiscal. Nesta existem uma série de produtos (itens repetitivos). Neste caso vamos criar uma nova entidade PRODUTO para inclusão desses itens.

• segunda forma normal - Deve-se localizar dados que não dependa única e exclusivamente da chave primária da entidade em questão. Ao se identificar grupos de dados independentes dessa chave deve-se separá-los em outras entidades.

Os dados do cliente na nota fiscal não dependem única e exclusivamente da chave primária da Nota fiscal, assim devem ser colocados em uma nova entidade (CLIENTE).

• terceira forma normal - Nessa etapa, devemos localizar atributos com dependência transitiva. São atributos que podem ser obtidos através de outros e que portanto não precisam existir fisicamente. Deste modo devem ser excluídos.

No exemplo da nota fiscal tempos o campo valor total. O valor desse campo é obtido através da soma do valor unitário de cada produto na nota, portanto não há a necessidade de se criar um campo para guardar esse valor.

Após a construção do modelo conceitual, partimos para a construção do modelo físico, e para a criação do script de criação dos objetos que constituirão o banco de dados

Conceitos de Banco de dados

Um sistema de informação tem o objetivo de receber dados, processa-los e gerar informação.

O usuário "entra" com dados, o sistema "processa" esses dados e produz uma "saída".

Mas vamos com calma! Qual é a diferença entre dado e informação? De forma simplista, podemos dizer que o dado é um fato ou característica isolado referente a algum objeto, coisa ou entidade. Já a informação é um conjunto de dados relacionados. Por exemplo, uma pessoa possui nome, telefone, endereço entre outros dados. O nome é um dado, já o conjunto nome, telefone, endereço é uma informação.

Todo o processamento de dados é feita na memória principal do computador, porém como sabemos essa memória é volátil, ou seja, é apagada quando se desligar o computador e é aí que entra em cena os bancos de dados.

Você poderia dizer o seguinte: por que não gravar essas informações em arquivos? Bom, respondendo a essa pergunta com outra pergunta. Como organizar esses arquivos se o volume das informações for muito grande e com taxa de crescimento for constante? O banco de dados é a solução para o problema.

Armazenar informações organizadas e recuperá-las sem faltar um pedacinho sequer, sempre que necessário é a função principal dos bancos de dados.

Todo mundo que usa telefone costuma ter uma agenda telefônica. Nela cada amigo tem nome, endereço, número da linha, aniversário e nos tempos atuais e-mail e quando precisamos ligar para alguém, vamos à letra incial do nome e buscamos o número do telefone.

Essa "agendinha" expressa bem o conceito de banco de dados - um armazém de informações relevantes, organizadas de maneira coerente e lógica, que precisa ser recuperadas com frequência.

Esse universo envolve conceitos importantes que precisamos entender para torna-lo útil. Vamos a eles:

Sistema de gerenciador de banco de dados e Banco de dados

É importante não confundir os conceitos de sistema gerenciador de banco de dados e banco de dados.

O primeiro refere-se a programas que auxiliam ao usuário na tarefa de manipular e administrar os dados contidos em um banco de dados. Esses programas promovem os controles de acesso, redundância, integridade e o mecanismo de cópias de segurança dos dados presentes em um banco de dados.

Se você perguntar a um DBA com que banco de dados ele trabalha ele poderá responder que trabalha com o MySQL, Oracle, Sql server e por aí vai, porém se você fizer essa pergunta a um analista de sistemas ou a um analista de negócios, este poderá lhe responder que trabalha com o banco de dados do RH ou com o banco de dados acadêmico, por exemplo.

Modelagem de dados

A modelagem de dados é o processo pelo qual trabalham-se os dados de modo a promover estruturas de amazenamento estáveis. Esse processo se por meio da criação de modelos conceituais de entidade e relacionamento ou pela nomalização de dados, fazendo com que essas estruturas possam evoluir com o tempo, sem prejudicar o desenvolvimento de sistemas.

Entidade

Entende-se como um grupo de coisas semelhantes. Essas coisas podem ter uma existência física (pessoa, carro) ou abstrata (pedido, ordem de serviço). Cada entidade possui diversar instâncias do objeto que o representa.

Quando se transpõe a entidade para um modelo físico, criamos uma tabela. Já no modelo Orientado a objeto, temos o que chamamos de classe.

Atributo

O atributo é um qualificador lógico de um objeto. É um dado e como tal, serve para descrever o caracterizar o objeto em questão.

Quando se transpõe para o modelo físico o atributo torna-se um campo. No modelo orientado a objeto é conhecido com propriedade ou atributo mesmo.

Tupla

Uma tupla é o conjunto de características do objeto. No modelo físico uma tupla é um registro presente em uma tabela. No modelo orientado a objetos, dizemos que esta é uma instância de um objeto.

Tabela

A tabela é uma estrutura composta por registros compostos por linhas e colunas. A linha representa um objeto do mundo real e as colunas servem para qualificar esse objeto.

Chave

A chave é um qualificador único de um registro. É o campo escolhido para identificar exclusivamente um registro e por conta disso esse campo não poderá conter valores em branco ou repetidos.

Vamos imaginar qual atributo de uma pessoa seria a melhor opção para ser um chave. O campo nome com certeza não seria a opção a ser escolhida visto que existem pessoas com nomes homônimos. O CPF talvez seja um atributo candidato, pois é um documento obrigatório para uma pessoa adulta, porém esse documento não é obrigatório para crianças.

Nos casos em que nenhum dos atributos sejam qualificados para ser o campo chave do registro, deve-se criar um campo específico para isto (ex: matrícula). As chaves podem ser classificadas nos tipos abaixo:

• Primária - Classificam unicamente um registro. Toda tabela deve possuir uma chave primária.
• Estrangeira - Servem para relacionar as tabelas do banco de dados. Por exemplo temos duas tabelas: CLIENTE e NOTA_FISCAL. Cada tabela tem um chave primária , porém para relacionar essas tabelas a tabela nota fiscal deverá possuir a chave estrangeira CLIENTE que possuirá como valor um código de um cliente.
• Secundária - São os demais campos do registro que possui a função de subclassificar esses registros. É muito utilizado nos índices de uma tabela (falaremos sobre eles daqui à pouco).

Relacionamento

Os objetos do mundo real apesar de distintos guardam um certo grau de relacionamento com outros objetos.

Voltando ao exemplo do cliente/nota fiscal notamos que existe uma relação de interdependência entre essas duas entidades, ou seja, para emitirmos uma nota fiscal é necessária a existência de um cliente. A essa interdependência, damos o nome de relacionamento e este pode ser classificado de duas formas:

• Opcionalidade - indica se é obrigatória ou não a ocorrência ou indicação de um registro no outro.
• Cardinalidade - A cardinalidade indica quantas ocorrências de um registro podem se relacionar com outro registro.

Existem 3 tipos de cardinalidade:

• Um para um (1:1) - é quando cada tupla de uma entidade está relacionada a apenas uma tupla de outra entidade.
• Um para muitos (1:M) - é quando cada tupla de uma entidade pode estar relacionada a muitas tuplas de uma outra entidade.
• Muitos para muitos (M:M) - Neste caso várias tuplas de uma entidade podem estar relacionadas a várias tuplas de uma outra entidade.

Integridade referencial

A integridade referencial é o mecanismo utilizado pelos gerenciadores de bancos com o objetivo de manter a consistência dos dados do banco.

Digamos que um usuário tente emtir uma nota fiscal com um código de cliente inexistente? Ou ainda apagar registro de um cliente que possui diversas notas fiscais cadastradas? Como ficaria a consistência dessas tabelas? Um bom SGBD deve garantir a integridade referencial do banco.

Restrições (Constraints)

As restrições são utilizadas para melhorar a qualidade da informação guardada nas tabelas do banco. Já falamos sobre duas restrições: chaves primárias e estrangeiras, contudo existem outras restrições muito importantes:

• Nulos - servem para determinar se é permitido a inserção de um valorou não em um determinado campo;
• Exclusivos (unique) - servem para determinar se o campo pode ou não receber valores repetidos;
• Padrão - Serve para informar um valor padrão quando um valor não é informado pelo usuário;
• Domínio - Serve para limitar os valores a serem inseridos em um campo. Exemplo: O campo Sexo só pode receber dois valores (Masculino ou Feminino).
  

Transação

Sempre que ocorrer a alteração no conteúdo de uma ou mais tabelas de um banco de dados. Deste modo sempre que houver uma inclusão, alteração ou exclusão em um registro é gerada uma transação. O usuário ou o sistema gerenciador de banco de dados, nomento da operação, pode optar pela efetivação (COMMIT) ou pelo abandono da mesma (ROLL-BACK).

Procedimentos armazenados

São pequenos códigos executados em um banco de dados que fim guardados para posterior utilização. São eles:

• Stored Procedures - código que realiza operações no banco de dados. Não retornam valor;
• Functions - idêntico a uma Stored procedures exceto por retornar valor;
• Triggers - são procedimentos disparados por eventos (a inclusão, alteração ou exclusão de um registro).

Algum desses conceitos são vistos como objetos em um banco de dados (tabelas, constraints, índices, stored procedures, usuários etc).

Bom, acho que com esses conceitos já dá para praticarmos um pouco de modelagem de dados, mas isso será assunto para outro post.