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.