Um Pouco Sobre Joins

Olá pessoal, espero que estejam todos bem.

Hoje vou atender a um pedido de um colega que confessou não ter entendido como funciona um Join.

Primeiramente devo mencionar que a teoria de banco de dados é, em grande parte, retirada da teoria de conjuntos matemáticos. Um join (junção) é utilizado na consulta de tabelas em conjunto, serve para que possamos fazer consultas comparativas entre tabelas relacionadas.

Certo, então como funciona um Join?

Fazemos isso todos os dias e se tornou tão natural para nós q não paramos mais para pensar em com é 

feito.

Se tivermos três conjuntos numéricos, “Números de 1 a 10”, “Números pares” e “Números impares” e eu quiser saber quais são os números pares, podemos fazer um Join.

Funcionará da seguinte forma. Verificaremos quais números estão no conjunto dos pares e em seguida compararemos esses números para ver quais se encontram na tabela dos números de 1 a 10.

Desta forma através de comparação entre os conjuntos chegamos a um resultado que não é nem a 1ª e nem a 2ª tabela, mas sim uma nova tabela temporária para nossa pesquisa.

Imaginemos agora que não são conjuntos e sim tabelas e que elas não possuem apenas um dado, mas sim PKs e Fks, digamos que é temos três tabelas:

Funcionários {Cod_Func(PK), Nome, Telefone}

Gerentes{Cod_Func(PK e FK), Cod_Departamento(FK)}

Departamentos{Cod_Departamento(PK), Nome}

Então quero saber o nome e o número de telefone dos funcionários que são gerentes e somente destes. Na tabela funcionários não há essa indicação e na tabela de gerentes não tenho o nome nem número de telefone. Nesse caso devo fazer um join que me gerará uma tabela temporária com essa informação.

Então seleciono os nomes e telefones da tabela funcionário onde o código de funcionário da tabela funcionário seja igual ao código de funcionário da tabela gerentes.

Em SQL:

 select FUNCIONARIOS.NOME, FUNCIONARIOS.TELEFONE

from FUNCIONARIOS, GERENTES

where FUNCIONARIOS.COD_FUNC=GERENTES.COD_FUNC;

O será gerado através da comparação entre os campos relacionados, e serão mostrados somente os campos pedidos na seleção.

Existem três tipos de Join:

·        Inner Join: Que trará somente os resultados que  atenderem as condições nas duas

tabelas.

select  FUNCIONARIOS .NOME, FUNCIONARIOS .TELEFONE

from FUNCIONARIOS inner join GERENTES

on FUNCIONARIOS.COD_FUNC=GERENTES.COD_FUNC;

O resultado desta pesquisa será igual ao do join simples.

·        Right Join: Que irá trazer como resposta todos os resultados da tabela da direita, mesmo que não atendam a ou as condições informadas e mais os dados que atenderem as condições e estiverem na tabela da esquerda.

select FUNCIONARIOS.NOME, FUNCIONARIOS.TELEFONE

from FUNCIONARIOS right join GERENTES

on FUNCIONARIOS.COD_FUNC=GERENTES.COD_FUNC;

·        Left Join: Que irá trazer como resposta todos os resultados da tabela da esquerda, mesmo que não atendam a  ou as condições informadas  e mais os dados que atenderem essas condições e estiverem na tabela da direita.

select  GENRETES.COD_FUNCIONARIO, GENRETES.COD_DEPARTAMENTO

from FUNCIONARIOS left join GENRETES

on GENRETES.COD_FUNCIONARIO=FUNCIONARIOS.COD_FUNCIONARIO;

Repare que tanto em Rigth Join quanto em Left Join ocorre repetição de elementos da tabela para evitar isso devemos usar a clausula group by no final da sintaxe e assim agrupar os resultados.

Obrigado pela visita. Espero ter elucidado um pouco sobre o Join!

Até o próximo post.

Bibliografia:

http://www.techonthenet.com/sql/joins.php

http://psoug.org/snippet/INNER-JOIN-example-and-syntax_730.htm

Procedures Cursores - Básico

Olá, pessoal!

Hoje vou falar sobre cursores. Uma possibilidade existente em PL/SQL e procedures que pode ser muito útil.

O que é um Cursor?

Um cursor em PL/SQL armazena uma área da memória para guardar o resultado de uma pesquisa. Esta pesquisa pode conter nenhum, um ou muitos dados que serão armazenados em linhas e colunas.

Então dentro de uma procedure podemos utilizar um cursor, que terá um nome e poderá se comportar como uma variável, porém uma variável que armazena mais de um campo dos dados. Através deste armazenamento é possível manipular ou comparar as informações

Os cursores podem ser Implícitos ou Explícitos sendo que o Explícito acaba por consumir mais recursos de memória.

Em uma procedure ou function o cursor deve ser declarado junto das variáveis, ou seja, antes do Begin e depois do create procedure/function. E podemos utiliza-lo de duas formas.

Forma Extensa ou Forma Resumida.

A Forma Extensa não é a forma mais utilizada e usamos os seguintes comandos:

·         Open: Abre o cursor e executa o comando de pesquisa select informado na declaração, tendo executado a pesquisa o cursor separa um espaço da memória para guardar temporariamente esses dados de linhas e colunas. Já que agora esses dados estão armazenados na memória, o cursor não precisará mais acessar o banco para obtê-los. É nesse momento, também, que é passado para o cursor os parâmetros, caso tenha utilizado de parâmetros de entrada.

·         Fetch:   Informará qual valor do cursor uma determinada variável receberá. Funciona através do conceito de ponteiro, onde ele irá informar a esta variável qual a linha corrente e em seguida posicionar o ponteiro na linha seguinte para a próxima repetição da operação. As linhas no cursor somente poderão ser acessadas quando seus valores forem passados para uma variável possível de ser manipuladas em PL/SQL.

·         Close: Fecha o cursor após sua execução e assim libera a área de memória onde o cursor estava armazenado.

Cursor Implícito Extenso:

O cursor implícito leva esse nome por suas ações ficarem “escondidas”. Ele não informa o que está fazendo, apenas faz. E assim podemos utilizar alguns comandos de manipulação.

Cursor Implícito Resumido

No Cursor Implícito Resumido utilizamos somente um comando que irá substituir os outros três. Este comando a estrutura de repetição FOR. Este comando irá abrir o cursor, criar a variável do tipo registro que irá receber os dados sem necessidade de declara-la, realizar cópias das linhas, uma a uma a cada repetição, controlará o final do cursor e seu fechamento.

Cursor Explícito

Os cursores explícitos são utilizados para controle de processamento, sempre que é necessário que apareça o que o cursor está fazendo.

Neste exemplo o que o cursor faz é simplesmente informar os valores encontrado na tabela para aquele campo especifico.

Ele é chamado explícito porque sua forma de ação é declarada, ele informa algo que está acontecendo em sua execução.

É isso, pessoal! Quado acontecem erros nas ferramentas de ETL temos como observar qual o código que foi gerado. Tendo essa noção sobre PL/SQL e principalmente sobre procedures e cursores podemos entender o que foi feito e analisar para descobrir qual o erro na geração do código para corrigirmos as definições de carga.

Espero ter ajudado, até o próximo post!

Bibliografia:

http://www.devmedia.com.br/formas-de-manipulacao-de-cursores-em-pl-sql/1713

http://www.linhadecodigo.com.br/artigo/1778/cursores-no-oracle-parte-1.aspx

http://www.adp-gmbh.ch/ora/plsql/cursors/for_update.html

Procedures PL/SQL - Básico

Uma parte importante sobre o ETL é entender como essas ferramentas trabalham na camada semântica. O ETL é feito através de procedures em SQL.

E o que é uma procedure?

Uma procedure é um bloco de SQL nomeado. Funciona logicamente como uma programação estruturada, se você já teve a oportunidade de estudar Pascal ou C sabe muito bem como funciona. De qualquer forma vamos ver o básico para termos uma ideia.

Para poder criar uma procedure o usuário deve ter permissão create procedure (GRANT CREATE PROCEDURE TO NOME_USUARIO) e para criar a procedure em outro schemas o usuário deve ter permissão alter any procedure (GRANT ALTER ANY PROCEDURE TO NOME_USUARIO).

Vou utilizar a linguagem PL/SQL

Esta é a sintaxe básica para a criação de uma procedure:

Onde:

·         Replace: Indica que se já existe uma procedure como nome indicado, esta será eliminada e substituída pela procedure que o código criará.

·         Bloco PL/SQL: Inicia-se com um BEGIN e termina com um END ou um END NOME_PROCEDURE. No corpo, entre o inicio e fim, escrevemos os comandos que a procedure irá executar.

·         Parâmetro: Indica o nome da variável que é passada na chamada da procedure ou retornará os valores.

·         Modo: Indicará se o parâmetro é de entrada (IN), saída (OUT) ou os dois (IN OUT). Caso não informemos default será IN.

·         Tipo de Dado: Como o nome diz, indicará o tipo de dados da variável. Pode ser declarado qualquer tipo de dado do SQL ou do PLSQL e não será necessário informar o tamanho.

·         IS|AS: A sintaxe do comando aceita os dois, por convenção usamos IS para criação de procedures. Indica que o algoritmo que se segue deve ser executado quando chamada a procedure.

Esse é um exemplo de procedure simples.

Certo, esta é uma procedure que tem uma única função, inserir um registro de uma determinada tabela.

Vamos analisar sua estrutura.

Começa com a sintaxe de criação ou reposição de uma procedure e seu nome, no caso “inserir”.

A seguir temos o parâmetro, tipo de parâmetro (se é de entrada ou saída) e seu datatype, entre parênteses, seguido pela palavra IS.

Após isso iniciamos nosso algoritmo. Abrimos com “Begin” e se segue em PL/SQL o que queremos que ela faça. Inserir os dados passados pelos parâmetros para tabela chamada “Tb_funcionarios”.

Dizemos também que depois de cumprida esta tarefa ela deve confirmar a alteração com o “commit”. E encerramos a procedure com o “End inserir;” sinalizando que sua função foi cumprida e sua execução terminou.

Para executarmos a procedure, com parâmetros, o comando é:

Exec nome_procedure (valor_parametro);

No caso exemplo então:

 Exec inserir (215, 9, 'Emerson Fitipaldi', 'R ficticia, 101', 'Sao Paulo', 'SP').

Claro que inserir um registro é simples o suficiente, criar uma procedure se torna mais trabalhoso que digitar o próprio comando diretamente. Para que, então, precisaremos de uma procedure. Simples, podemos fazer com que mais de um comando sejam executados, nos poupando tempo. Por exemplo, podemos criar uma procedure que não só insira, mas que caso já exista código de funcionário informado ela atualize os valores passados nos parâmetros.

Vamos ver essa alternativa:

Nesta alternativa mantivemos os parâmetros passados o algoritmo de inclusão de dados. Só que quando um valor de um campo unique já existe na tabela, não poderá ser repetido na inserção gerando um erro. A novidade desta alternativa está em pedir para a procedure que se houver o erro ela deve atualizar todos os campos daquele registro na tabela e depois confirmar a alteração.

Após a execução do programa a procedure confirmará a alteração e encerrará a atividade.

No caso a clausula “exception when” trata exatamente do erro. Através dessa clausula podemos dizer qual o erro esperado e dizer o que fazer quando este aparecer. Quando eu informo o “others” estou dizendo que deve proceder com a atualização seja o erro que for. Como sempre, não existe uma única solução e sim soluções mais eficazes que possam prever outros erros ou ações.

Outras soluções podem ser criadas por procedures no banco de dados. As ferramentas de ETL funcionam com criação e execução de procedures mais complexas que estas.

Caso queira se aprofundar no assunto e buscar por exercícios de procedure recomento o seguinte endereço http://www.univasf.edu.br/~mario.godoy/Aulas-BDII/BD%20II%20-%20Aula%209.pdf, os exercícios começam na pág. 24.

Obrigado pela visita e até o próximo post. 

Bibliografia:

http://codigofonte.uol.com.br/artigo/banco-de-dados/procedures-e-funcoes-em-plsql

http://www.linhadecodigo.com.br/artigo/335/pl_sqlprocedures-e-funcoes.aspx

http://www.devmedia.com.br/criando-procedure-stored-procedures-em-pl-sql/24232

Modelagem Relacional - Prática(M.E.R.)

Olá, pessoal. Passei conceitos de modelagem relacional e vou passar hoje um Passo-a-Passo baseado em um artigo que li na SQL Magazine ano 09 edição 101.  Acredito que este exercício dará uma boa base sobre modelagem e normalização. Então vamos a ele.

Utilizaremos como base de nosso modelo esta ficha de locações da locadora. A partir dela retiraremos os objetos, relacionamentos e normalizações.

Podemos observar que existem alguns assuntos tratados na ficha. Nosso primeiro passo será identificar os atributos existentes e agrupa-los em objetos.

Código Locação

Título Locado

Filme

Jogo

Data Retirada

Data Prevista Entrega

Data Efetiva Entrega

Nome

Numero Carteirinha

CPF

Telefone1

Telefone2

Endereço1

Endereço2

Multa

Pago

Valor Total

Certo, identificamos todas as informações existentes na ficha. Passaremos ao agrupamento.

Temos dois tipos de informação básica:

·         Aluguel

Código Locação, Título Locado, Filme, Jogo, Data Retirada, Data Prevista Entrega, Data Efetiva Entrega, Multa, Valor Total, Pago.

·         Cliente

Nome, numero da carteirinha, cpf, tel1, tel2, end1 e end2.

Teremos então a principio dois objetos:

Organizá-los e normaliza-los.

Devemos definir qual a PK de cada um dos objetos para que possamos também depois normalizar.

Então criaremos um atributo identificador para os objetos que não possuem ainda e, se houver, definiremos um atributo já existente como PK.

Como temos campos de identificação nos objetos Cliente e Aluguel, podemos defini-los. No caso do objeto Cliente podemos escolher Cpf ou Numero da Carteirinha. Escolhi o número da carteirinha, pois poderemos assim cadastrar os dependentes no mesmo Cpf do titular gerando novo número de controle para o cliente na carteirinha. É claro que isso é uma escolha que deve ser estudada com o contratante do projeto, uma vez que este pode ter outra forma de identificar esta categoria de clientes.

Já para o objeto Aluguel defini o Código de Locação. E nosso M.E.R ficou assim:

Bom, agora já temos nossas entidades como mais cara de objeto. Vamos então normaliza-las. Você pode até pensar que a dificuldade é grande, mas é só questão de prática. Saber as três formas normais é sempre bom para guia-lo.

·         1FN: Não é permitida a existência de atributos multivalorados, ou seja, um atributo não pode receber mais de um valor.

Conhecendo essa definição saberemos o que fazer, mas como fazê-lo?

Temos que nos atentar, geralmente atributos com nomes repetidos, diferenciado por números são multivalorados. Isso faz com que em nosso objeto Cliente possuamos quatro atributos destes fazendo referência a telefone: telefono1, telefone2 e a endereço: endereço1 e endereço2. Devemos então criar novos objetos para esses atributos e relacioná-los com o objeto Cliente por suas PKs como FK, pois estes atributos podem conter mais de um valor sabendo que o cliente pode ter mais de um tel e mais de um endereço para cadastro. Sendo assim criarei os objetos Telefone e Endereço com os atributos correspondentes e uma PK que será criada para cada.

O objeto Aluguel possui três atributos como data, podemos separa-los também criando um novo objeto Datas. Temos também dados relacionados ao item que foi alugado e se é jogo ou filme. Também podemos observar que existem dois atributos que podem ter valor sim ou não, são eles Multa e Pago. Devemos criar entidades para ambos e criar PKs também.

·         2FN: Deve estar na primeira forma normal. Todas as colunas devem ser totalmente dependentes da PK.

Os objetos relacionados ao Cliente não necessitam de mais normalizações.

O objeto aluguel em si já está na segunda forma normal também.

Já com relação ao objeto Item podemos então separa-lo em dois objetos. O Tipo_Item que nos dirá se é filme e o próprio Item.

·         3FN: Deve estar na segunda forma normal. Não pode haver atributos que tenham origem de cálculo derivados de outros atributos.

Esses atributos geralmente são os relacionados a algum cálculo que seja feito para fim de relatório ou conhecimento de valores. Nesse momento temos que verificar que, para que o atributo Valor_Total do objeto Aluguel possa ter alguma informação, precisamos saber quais os valores dos filmes, jogos e multas.

Podemos criar um novo objeto que conterá esses valores. Chamarei de Financeiro e conterá os atributos:

·         Financeiro:

Cod_Financeiro, Valor_Jogo, Valor_Filme, Valor_Multa.

Tendo normalizado nossos objetos podemos começar a verificar seus relacionamentos e duplicidades.

Sabemos que em nossa ficha de aluguel temos atributos referentes aos clientes, então é lógica uma relação entre esses objetos. O objeto Aluguel também deve receber a chave estrangeira dos objetos Data e Item já que precisará das informações referentes a estes. O objeto Item precisa das informações sobre Tipo dele (se é filme ou jogo) então relacionaremos Item e Tipo_Item. O objeto Tipo_Item poderá relacionar-se aos objetos Financeiro, assim saberemos os valores unitários de cada tipo de item (filme, jogo e consideraremos multa como item, para efeito de cálculos). Em um M.E.R. coloca-se também o tipo de relacionamento que um objeto tem com o outro, geralmente informado por um verbo (“tem”, “possui”, “recebe”, “faz”, etc...).

Com os relacionamentos nosso M.E.R. ficará desta forma:

Lembre-se que não existe um modelo certo ou errado e sim um modelo mais ou menos eficaz o que vai depender das exigências de negócio do cliente.

Após isso se inicia a faze do modelo físico que levará em conta tipo e capacidades da plataforma de banco de dados que será utilizado. Podendo então definir tipo dos dados que os atributos receberão.

Mas pararemos por aqui, por enquanto espero que ajude a entender um pouco mais o passo a passo e assim fixar melhor as informações sobre modelagem.

Obrigado pela visita e até o próximo post.

Bibliografia:

Revista SQL Magazine - Ano 9 :: Edição101. Artigo: Normalização de dados na prática; por Roberto de Angelo Jr.

Modelagem Relacional

Olá pessoal! Espero que estejam todos bem e evoluindo. Nesse poste vou falar sobre Modelagem Relacional

Os princípios básicos da modelagem de dados relacionais foram referenciados a teoria de conjuntos.

“O mundo está cheio de coisas que possuem características e se relacionam entre si”

“A lei do mundo” de Peter P. Chen nos passa esse conceito. Tudo aquilo que pode ser classificado ou categorizado é definido como coisa que poderá ser definido como entidade dependendo da abordagem. Essas coisas possuem características iguais ou semelhantes que permitem que as agrupemos. Elas irão se relacionar com outras coisas ou outros grupos e essa será a forma de comunicação entre as coisas.

Por que modelar?

Modelamos para que possamos representar o ambiente de forma que podemos prevenir futuras correções em coisas simples que podem nos obrigar a ter trabalho em dobro na hora de corrigirmos. Também serve com normalização e documentação do como funciona nosso ambiente para que outras pessoas do grupo ou clientes possam entender o que será feito e desta forma validar e aperfeiçoar os relacionamentos entre os objetos.

Agora que já vimos o porquê podemos passar para a parte de como e para entendermos esse tipo de modelagem de banco de dados precisamos aprender alguns conceitos básicos à própria modelagem.

Como modelar?

A modelagem de dados passa por três etapas:

Modelo Conceitual - Representa as regras de negócio sem limitações tecnológicas ou de implementação por isto é a etapa mais adequada para o envolvimento do usuário que não precisa ter conhecimentos técnicos. Neste modelo temos:

·         Visão Geral do negócio

·         Facilitação do entendimento entre usuários e desenvolvedores

·         Possui somente as entidades e atributos principais

·         Pode conter relacionamentos n para m.

Modelo Lógico - Leva em conta limites impostos por algum tipo de tecnologia de banco de dados. Suas características são:

·         Deriva do modelo conceitual e via a representação do negócio

·         Possui entidades associativas em lugar de relacionamentos n:m

·         Define as chaves primárias das entidades

·         Normalização até a 3a. Forma normal

·         Adequação ao padrão de nomenclatura

·         Entidades e atributos documentados

Modelo Físico - Leva em consideração limites imposto pelo SGBD (Sistema Gerenciador de Banco de dados) e pelos requisitos não funcionais dos programas que acessam os dados. Características:

·         Elaborado a  partir do modelo lógico

·         Pode variar segundo o SGBD

·         Pode ter tabelas físicas (log , lider , etc.)

·         Pode ter colunas físicas (replicação)

Objeto ou Entidade:

Entidade ou Objeto é uma representação de algo sobre o qual se deseja guardar informações. Informações essas que devem ser compreendidas pelo sistema de informações que será utilizado.

 Podemos identificar as entidades de três formas pelo menos:

·         Coisas tangíveis: Tudo aquilo que é físico, que possui existência física como caderno, mesa ou garrafa.

·         Funções: Tudo aquilo que atua que age que pratica uma ação. Por exemplo: Professor, Departamento, Cliente.

·         Eventos ou Ocorrências ou Movimentação: Observado quando há algo que ocorre e continua a ocorrer. Algo como uma ação enquanto ela está acontecendo. Exemplo: Lançamento em conta corrente.

Atributo:

Existem três tipos de atributos, Atributos Descritivos que são aqueles capazes de demonstrar, representar as características do objeto, Atributos Nominativos são aqueles que além de terem a função de descrição também identificam o objeto, como nome ou qualquer outra informação que seja identificadora, e por último, Atributos Referenciais que são aqueles que não necessariamente pertencem ao objeto, mas sim fazem a relação deste com outro objeto.

Enfim, atributo é tudo aquilo que é próprio do objeto e o diferencia perante aos demais.

Relacionamento:

Relacionamento é uma ligação existente entre objetos. Essa relação define como é o comportamento de um objeto, quais suas restrições, dependências e acessos a outros objetos. A regra de negócio do banco de dados definirá se o objeto terá muitos ou um relacionamento e qual sua cardinalidade.

Cardinalidade é a quantidade de vezes que uma relação pode acontecer entre determinados objetos relacionados. Seguindo a notação os relacionamentos podem ser:

          ·         N: muitas vezes.

             ·        1: único, somente uma vez

            ·         0: não acontecer.

Então, por exemplo: Um Professor pode ter vários Alunos, se tivéssemos dois objetos, Professor e Aluno a o relacionamento de Professor para Aluno seria de N, pois um professor se relaciona com vários alunos.

Opcionalidade analise se as ocorrências de um objeto o obrigam a se relacionar com outros, existem três:

·         Opcional: É quando as ocorrências dos objetos que se relacionam não dependem umas das outras.

·         Contingente: Somente um objeto possui independência. Ou seja, um dos lados é obrigado a se relacionar enquanto o outro não.

·         Mandatórios: As ocorrências dos objetos existirão, somente se ambos existirem. Ou seja, os objetos são completamente dependentes um do outro para que existam.

Os tipos mais comuns de relacionamento são:

·         Ternário: Quando três objetos se relacionam da mesma forma entre si.

·         Auto-Relacionamento: É quando um objeto se relaciona consigo mesmo.

·         Agregação: Este relacionamento possui uma condição de existência. Quando o relacionamento é ternário e o relacionamento fundamental tem relação de N:N(muitos pra muitos), forma-se este tipo.

·         Especialização: É quando um grupo de objetos que possuem uma característica em comum, geralmente deriva do desmembramento de outro objeto. Por exemplo, um objeto Pessoas, nesse objeto pode haver vários subgrupos. Então, sendo de interesse para o negocio, podemos separa-los.

·         Entidade Supertipo: Possui a chave primária e os atributos comuns a todos.

·         Entidade Subtipo: Herda a chave primária e contém os atributos específicos àquele grupo.

Restrições:

Existem algumas restrições das quais as mais importantes, para um iniciante em modelagem relacional, são a chave primária (primary key), unique e not null/null.

·         Primary Key (PK): A chave primária é um atributo que deve ser único em relação a todos os outros da tabela, sua definição implica em assumir que este atributo também não terá campos nulos ou repetidos e por isso não há a necessidade de defini-lo também como unique ou not null. Essa restrição deve-se ao fato de que a PK servirá como identificação dos dados da tabela.

A PK pode ser simples ou composta. Ou seja, podemos definir como chave primária um atributo ou mais desde que sejam únicos e não nulos na tabela.

Por exemplo, o Objeto Cliente possui os seguintes atributos:

CLIENTE (cpf, nome, sobrenome, rua, numero, cidade, nascimento).

Definimos CPF como PK, pois não haverá registros duplicados ou nulos, sendo assim este atributo poderá servir para identificar os demais campos da tabela.

Outro exemplo é o Objeto Associado que possui os seguintes atributos:

ASSOCIADO (cpf_cliente, RG, nome, sobrenome).

Neste caso a definição de cpf_cliente e RG como chave primária se dá, pois estes atributos não terão valores repetidos ou nulos e poderão identificar os demais campos da tabela.

Como mencionei existem outros conceitos de restrições como:

·         NOT NULL: Quando um atributo não poderá receber valores nulos. Caso não seja definido como nulo o atributo automaticamente assumirá a possibilidade de valores nulos.

·         UNIQUE: Quando um atributo não poderá receber valores repetidos.

Em ambos os casos o atributo definido independerá da definição da chave.

Integridade:

Quando fazemos o relacionamento entre objetos, normalmente desejamos que a chave primária de um faça parte da chave do outro objeto. Isso se chama Chave Estrangeira ou Foreign Key (FK)   .

Por exemplo, na relação entre os objetos CLIENTE e ALUGUEL de uma locadora, onde os atributos são os seguintes:

CLIENTE(numero_carteirinha(PK), cpf, nome)

ALUGUEL(registro_aluguel(PK), numero_carteirinha(FK), quantidade, registro_filme, data_retirada, data_saida).

Então sabemos que existe relação entre as tabelas e que o objeto ALUGUEL tem acesso às informações do objeto CLIENTE através de sua chave primária.

Normalização:

Para evitar anomalias nas inserções, exclusões e alterações de linhas e evitar redundâncias existem as normalizações. Sendo realizadas as normalizações os dados permanecerão confiáveis e íntegros, facilitar esse trabalho é um dos principais objetivos da modelagem.

Existem três formas de normalização:

·         Primeira Forma Normal     : O objetivo é retirar os atributos ou grupos repetitivos. Temos que nos assegurar que nenhum atributo o grupo se repete dentro do objeto de maneira a fazer com que cada linha tenha apenas uma ocorrência de um determinado dado. Esse processo se chama Atomicidade de Dados.

·         Segunda Forma Normal: Estando dentro da primeira forma normal atingiremos a segunda garantindo que todos os atributos que não forem chave sejam dependentes da chave primária. Os atributos que não dependerem totalmente da chave primária deve formar uma nova tabela relacionada.

·         Terceira Forma Normal: Para termos esta normalização é necessário que a tabela já esteja na segunda forma normal. Devemos retirar os atributos que não tiverem ligação direta com a chave primária mesmo que este tenha ligação através de outro atributo. Devemos verificar se haverá a necessidade de construirmos outra tabela ou se é possível eliminar o atributo.

Certo, esse é o conceito modelagem relacional. Importante no mundo do BI tanto para analise de negócio quanto para a construção do modelo multidimensional.

Obrigado pela visita e até o próximo post.

Bibliografia:

http://www.macoratti.net/cbmd1.htm

http://www.devmedia.com.br/modelagem-relacional/19614

http://www.ime.usp.br/~andrers/aulas/bd2005-1/aula12.html

O que é business intelligence parte V - Data Mining

Olá pessoal, espero que estejam todos bem e evoluindo nos estudos.

Hoje vamos fechar essa primeira série de posts sobre “O que é Business Intelligence”. Vou falar sobre Data Mining.

O que é:

Data Mining ou em português, mineração de dados é o processo através do qual podemos fazer uma varredura pelo banco de dados, em nosso caso pelo DW, para encontrar padrões de relacionamento entre os dados e gerar novos subgrupos de informações. Enfim o data mining é como um agregador e organizador de dados. Feita a varredura e o novo agrupamento das informações, são gerados dados estatísticos que irão aparecer nos relatórios gerados para a tomada de decisão em BI. Porém para que se possa utilizar este processo é necessário ter metas bem definidas para que seja possível extrair o conhecimento contido nos novos agrupamentos. Essas metas podem ser alcançadas por meio dos seguintes métodos:

·          Classificação: Classifica um item em uma ou várias categorias pré-determinadas. Uma boa técnica estatística para classificação é a análise descriminante. Essa técnica resume-se a descrições gráficas ou algébricas em uma ou mais classes pré-definidas. A ideia básica é substituir o conjunto original de diversas mensurações em um valor único, definido como conjunto linear delas. Esse tipo de análise permite comparar dois grupos e dizer se há alguma diferença entre eles e qual a natureza dessa diferença, separando-os em duas ou mais categorias mutuamente exclusivas.

·         Modelos de Relacionamento Entre Variáveis: Associa um item a uma ou mais variáveis de valores reais, consideradas variáveis independentes ou exploratórias. Técnicas estatísticas como regressão linear simples, múltipla e modelos lineares por transformação são utilizadas para verificar o relacionamento funcional que, eventualmente, possa existir entre duas variáveis quantitativas, ou seja, constatar se há uma relação funcional entre X e Y.

·         Analise de Agrupamento ou Cluster: Associa um item a uma ou várias categorias (clusters), em que as classes categóricas são divididas pelos dados, diferente da classificação na qual as classes são pré-definidas. Essa técnica detecta a existência e existência de grupos diferentes dentro de conjunto de dados.

·         Sumarização: Determina a descrição para um subconjunto. Utilizam-se medidas de posição e variabilidade, por exemplo. As funções de sumarização são frequentemente usadas na análise exploratória de dados com geração automatizada de relatórios, sendo responsáveis pela descrição compacta de um conjunto de dados. A sumarização é utilizada, principalmente, no pré-processamento dos dados, quando valores inválidos são determinados por meio do cálculo de medidas estatísticas – como mínimo, máximo, média, moda, mediana e desvio padrão amostral –, no caso de variáveis quantitativas, e, no caso de variáveis categóricas, por meio da distribuição de frequência dos valores.

·         Modelo de Dependência: Os Modelos de Dependência existem em dois níveis, estruturado e quantitativo e descreve dependências significativas entre as variáveis. Geralmente em forma de gráfico, o nível estruturado diz quais variáveis são localmente dependentes. Já o nível quantitativo utiliza escala numérica para informar o grau de dependência.

·         Regras de Associação: As Regras de Associação definem a relação entre os campos de uma tabela. Utiliza a derivação de correlação multivalorada que fornece subsídios para a tomada de decisão. Descobrir essas associações é, geralmente, o motivo das pesquisas e orienta análises, conclusões e evidenciação de achados da investigação.

·         Análise de Séries Temporais: Como o próprio nome diz esse método faz análise por tempo, então podemos comparar dados que foram coletados e analisa-los por hora ou por dia e formando um gráfico com essas informações. As séries são formadas por quatro padrões, tendência, variações clínicas, variações sazonais e variações irregulares.

E com esse terminamos esta série de artigos. Espero ter elucidado alguns métodos e objetivos do BI. Vou continuar estudando e espero que vocês possam fazer o mesmo e assim possamos crescer.

Obrigado por visitarem o blog. Até o próximo post.

O que é business intelligence parte IV - ETL

Olá, pessoal. Espero que eu esteja ajudando vocês nesse início de aprendizado sobre o BI.

Já vimos definição de BI e um básico sobre OLAP e DW. Hoje vou falar sobre ETL.

O ETL (Extract, Transform and Load) é um processo destinado à extração transformação e carga de dados vindos de um banco transacional para um DW.

Nesse processo são obrigatórias às fazes de extração e carga já que se os dados estiverem no mesmo formato ou linguagem do destino não será necessário a faze de transformação.

O que é ETL:

O processo de ETL é o mais longo e trabalhoso da faze de construção de um BI, pois é a extração dos dados de uma base transacional de origem, transformação, limpeza desses dados e carregamento no DW.

Extração:

Segundo Inmon é normal que aproximadamente 80% dos esforços de um BI sejam concentrados neste processo, já que para o funcionamento correto do BI proporcionando análises confiáveis os dados devem refletir a pura verdade e nada mais, o que faz do ETL um processo que deve ser pensado e realizado com cuidado.

Esta etapa do processo deve se basear na busca das informações mais importantes em sistemas fontes ou externos e que estejam em conformidade com a modelagem do DW. Essa busca, na maioria, é dificultada pelo fato de as informações estarem armazenadas em fontes distintas de dados. Num primeiro momento é normal que a carga inicial seja feita para que todos os dados do sistema origem sejam transferidos para uma área do DW chamada de Stage e posteriormente passada para a área chamada ODS, também no DW. Após isso as demais cargas serão incrementais que segundo Kimball é a mais eficiente e carrega somente os registros que foram alterados ou inseridos na base origem.

Transformação:

A etapa seguinte à extração é a transformação, nesta fase faz-se também a limpeza dos dados. Verificam-se erros de digitação, restrições de permissão dos bancos (quando o há alguma restrição do tipo o usuário não pode inserir no DW), padronizam-se as abreviações, etc.

Para garantir a qualidade dos dados o devemos observar o seguinte:

·         Unicidade: Evitar duplicações de informação.

·         Precisão: Os dados não devem perder suas características originais assim que são carregados no DW.

·         Completude: Não deve gerar dados parciais dos dados importantes para a análise.

·         Consistência: Os dados devem ser coerentes com os dados das dimensões, devem ter forma homogênea para a carga no DW.

Enquanto busca-se a homogeneidade dos dados podem ocorrer dois tipos de conflitos:

Semânticos: São aqueles que envolvem a palavra ou o nome associado às estruturas de modelagem, como ter o mesmo nome para entidades distintas.

Estruturais: São os que dizem respeito à própria estrutura da modelagem e os mais típicos são:

·         Diferenças de unidades: Quando as unidades utilizadas diferem, embora forneçam a mesma informação. Como uma distância em metros ou em quilômetros.

·         Diferenças de precisão: Quando a precisão escolhida varia de um ambiente para outro. Se um valor monetário é armazenado (10,2) dez casas antes da vírgula e duas depois ou (10,6) dez casa antes da vírgula e seis depois.

·         Diferenças em códigos ou expressões: Quando o código utilizado difere um do outro. Por exemplo, quando o sexo é definido com código M(masculino) e F(feminino) ou (1) masculino e (2) feminino.

·         Diferenças de abstração: quando a forma de estruturar uma mesma informação segue critérios diferentes. Quando um endereço está armazenado em uma coluna ou em várias separado em nome da rua, número, complemento, etc.

 Depois de termos identificado os conflitos criamos regras de conversão que visam exatamente corrigi-los. Essas regras podem ser criadas através de ferramentas de integração

Após essas observações pode-se iniciar o processo de carga.

Carga:

Nesse momento são carregados os dados das Dimensões e da Fato. Este processo pode ser bastante demorado e requerer muito recurso de processamento, procura-se torná-lo mais curto, pois o DW será utilizado constantemente. Por isso devemos tomar alguns cuidados. Como:

·         Desligamento de índices e referências de integridade (isso pode prejudicar a validade dos dados, pois não são validados no momento da inserção).

·         Utilização de comando tipo TRUNCATE ao invés de DELETE já que nos sistemas atuais esse recurso não gera armazenamento de informações em áreas de recuperação de dados.

·         Ter consciência de que alguns dados podem não ser carregados no momento da carga e assim devemos verificar os motivos para que possamos solucionar o problema.

 Após as dimensões estarem corretamente carregadas, já é possível iniciar a carga da fato, que depois de modelados para conter apenas os dados de importância para a empresa, direcionam quais regras serão utilizadas como, por exemplo, filtros do que serão inserido ou somas a serem realizadas, provocando o aparecimento de regras que passaram despercebidas no início da modelagem.

No entanto, a fato demanda cuidados na sua carga, como o uso das chaves artificiais das dimensões para que se tenha uma integridade referencial, controle de valores nulos obtidos no momento da transação para que não gerem a falta de integridade referencial como datas que, estando nulas, invalidarão o histórico do fato. Técnicas para amenizar o processo devido ao grande volume de dados podem ser usadas, como a carga incremental da fato, que irá carregar apenas dados novos ou alterados, execução do processo em paralelo e em momentos de pouco ou nenhum uso do SGBD e a utilização de tabelas auxiliares que serão renomeadas como definitivas ao fim da carga.

A figura abaixo mostra o ciclo do ETL em um DW

Para nós do BI o ETL aplica-se na construção do DW, porém pode-se usa-lo em qualquer tipo de trabalho envolvendo importação, transformação e carga de dados.

Este é o básico sobre ETL, este conceito é um pouco difícil de digerir sem um exemplo real, mas como sempre a base também é importante para identificarmos os passo em nosso dia-a-dia. Obrigado pela visita ao blog e até o próximo post.

Bibliografia:

http://www.fsma.edu.br/si/Artigos/V2_Artigo1.pdf

http://vivianeribeiro1.wordpress.com/2011/06/28/o-que-e-etl-2/