Modelo Relacional: Abstração e Estruturas de Dados

1 MODELO RELACIONAL VISÃO ABSTRATA DOS DADOS Um dos grandes benefícios dos sistemas gerenciadores de banco de dados BD é disponibilizar uma visão abstrata dos dados O sistema é capaz de ocultar as informações de armazenamento e a manutenção dos dados A eficiência da recuperação de informações está diretamente relacionada à forma como as estruturas de representação são projetadas os modelos e dada a complexidade elas devem ser divididas em níveis de abstração Os níveis de abstração são Nível de visão possibilita uma visão parcial do banco de dados Diferentes visões são usadas por diferentes usuários Nível lógico define quais dados serão armazenados e quais são os interrelacionamentos existentes entre eles Usado pelos administradores de banco de dados e programadores Nível físico define como os dados estão armazenados e quais são suas estruturas internas descrição em detalhes das estruturas de dados Administradores de banco de dados devem ter noções da organização desse nível Os bancos de dados sofrem mudança periodicamente à medida que as informações são inseridas alteradas ou excluídas A coleção das informações armazenadas é uma instância do banco de dados O projeto geral do banco de dados é o esquema O esquema de banco de dados corresponde às declarações de variável em um programa 2 MODELO DE DADOS Modelos de dados são a base para a construção de um projeto Propósitos dos modelos Comunicação Categorização Descrição Especificação Investigação Desenvolvimento Análise O Modelo de Dados fornece abstração a um BD São as informações que descrevem a estrutura de uma base de dados Por estrutura de uma base de dados entendese os tipos de dados os relacionamentos e as restrições aos dados Tipos de modelos de dados Hierárquico Rede Relacional Orientado a Objetos O modelo relacional atualmente é o mais utilizado e será discutido com detalhes Parte superior do formulário 3 DEFINIÇÃO DO MODELO RELACIONAL O Modelo Relacional MR é um modelo de dados efetivamente usado em aplicações comerciais atualmente Foi introduzido por E F Codd em 1970 no artigo A Relational Model for Large Shared Data Banks É o modelo que possui a base mais formal entre os modelos de dados entretanto é o mais simples e com a estrutura de dados mais uniforme Um banco de dados relacional é a coleção de relações ou tabelas de duas dimensões TabelaRelação Empregos ID Empregado Primeiro Nome Último Nome Email 1 Mariana Santos marianasantosmackenziebr 2 Joao Santos joaosantosmackenziebr TabelaRelação Departamento ID Departamento Nome Departamento ID Empregado Gerente Nome 10 Marketing 1 No exemplo acima o objetivo é armazenar informações dos funcionários de uma empresa e seus departamentos Podemos conceituar da seguinte forma Relação é o conjunto não ordenado de tuplas não existem tuplas duplicadas Conjunto de relações pode ser visualizada como uma tabela Tuplas é um conjunto ordenado de valores Valores são os atributos Codd em 1985 estabeleceu as 12 regras que determinam o quanto um banco de dados é relacional Alguns sistemas gerenciadores de banco de dados SGBD não fornecem suporte a elas Regra das informações em tabelas As informações a serem armazenadas no banco de dados devem ser apresentadas como relações tabelas formadas por linhas e colunas e o vínculo de dados entre as tabelas deve ser estabelecido por meio de valores de campos comuns Isso se aplica tanto aos dados quanto aos metadados que são descrições dos objetos do banco de dados Regra de acesso garantido Para que o usuário possa acessar as informações contidas no banco de dados o método de referência deve ser o nome da tabela o valor da chave primária e o nome do campocoluna Regra de tratamento sistemático de valores nulos O SGBD deve ser capaz de tratar valores que não são fornecidos pelos usuários de maneira que permita a distinção de dados reais Valores nulos devem ter um tratamento diferente de valores em branco Regra do catálogo relacional ativo Toda a estrutura do banco de dados domínios campos tabelas regras de integridade índices etc deve estar disponível em tabelas também referenciadas como catálogo Sua manipulação é possível por meio de linguagens específicas Essas tabelas são geralmente manipuladas pelo próprio sistema no momento em que o usuário efetua alterações na estrutura do banco de dados Regras de atualização de altonível Essa regra diz que o usuário deve ter capacidade de manipular as informações do banco de dados em grupos de registros ou seja ser capaz de inserir alterar e excluir vários registros ao mesmo tempo Regra de sublinguagem de dados abrangente Pelo menos uma linguagem deve ser suportada para que o usuário possa manipular a estrutura do banco de dados como criação e alteração de tabelas assim como extrair inserir atualizar ou excluir dados definir restrições de acesso e controle de transações commit e rollback por exemplo Deve ser possível ainda a manipulação dos dados por meio de programas de aplicativos Regra de independência física Quando for necessária alguma modificação na forma como os dados estão armazenados fisicamente nenhuma alteração deve ser necessária nas aplicações que fazem uso do banco de dados assim como devem permanecer inalterados os mecanismos de consulta e manipulação de dados utilizados pelos usuários finais Regra de independência lógica Qualquer alteração efetuada na estrutura do banco de dados como inclusão ou exclusão de campos de uma tabela ou alteração no relacionamento entre tabelas não deve afetar o aplicativo que o usa Da mesma forma o aplicativo somente deve manipular visões dessas tabelas Regra de atualização de visões Uma vez que as visões dos dados de uma ou mais tabelas são teoricamente suscetíveis a atualizações então um aplicativo que faz uso desses dados deve ser capaz de efetuar alterações exclusões e inclusões Essas atualizações no entanto devem ser repassadas automaticamente às tabelas originais Regra de independência de integridade As várias formas de integridade de banco de dados integridade de entidade integridade referencial restrições obrigatoriedade de valores etc precisam ser estabelecidas dentro do catálogo do sistema ou dicionário de dados e ser totalmente independentes da lógica dos aplicativos Regra de independência de distribuição Alguns SGBD notadamente os que seguem o padrão SQL podem ser distribuídos em diversas plataformasequipamentos que se encontrem interligados em rede Essa capacidade de distribuição não pode afetar a funcionalidade do sistema e dos aplicativos que fazem uso do banco de dados Regra nãosubversiva O sistema deve ser capaz de impedir qualquer usuário ou programador de transgredir mecanismos de segurança regras de integridade do banco de dados e restrições utilizando algum recurso de linguagem de baixo nível que eventualmente possa ser oferecido pelo próprio sistema 4 MODELO ENTIDADERELACIONAMENTO O modelo entidaderelacionamento MER fornece um meio de identificar entidades a serem representadas no banco de dados e verificar como essas entidades são relacionadas O MER foi desenvolvimento para facilitar o projeto de um banco de dados permitindo a especificação de um esquema que represente sua estrutura geral Uma entidade é algo do mundo real coisa ou objeto É baseada em uma percepção de uma realidade que consiste em uma coleção de objetos O MER deve ser intuitivo e representado graficamente por meio das informações modeladas Componentes do MER Entidades Atributos Relacionamentos Entidades São uma representação abstrata de um objeto do mundo real Um conjunto de objetos do mundo real que tem as mesmas características é chamada de entidade Atributos São as propriedades descritas das entidades Um atributo pode ser originário de outras tabelas Relacionamentos Uma associação entre entidades 5 MAPEAMENTO MER vs RELACIONAL Os modelos de dados podem ser Modelo Conceitual uma descrição do banco de dados de forma independente de implementação Modelo EntidadeRelacionamento Modelo Lógico uma descrição de um banco de dados no nível de abstração visto pelo usuário do SGBD Modelo Relacional O mapeamento do MER para o Modelo Relacional é um procedimento executado em seis passos consecutivos que antecedem a criação dos objetos no banco de dados 1 Mapeamento de todas as entidades regulares 2 Mapeamento de todas as entidades fracas 3 Mapeamento de todos os relacionamentos binários de cardinalidade 11 4 Mapeamento de todos os relacionamentos binários de cardinalidade 1N 5 Mapeamento de todos os relacionamentos binários de cardinalidade NN 6 Mapeamento de todos os relacionamentos de grau 3 ternários quaternários etc Exemplos MER Figura 1 Modelo Conceitual do relacionamento entre empregado e departamento Fonte Elaborada pelo professor MODELO RELACIONAL Figura 2 Modelo Relacional de um relacionamento entre empregado e departamento Fonte Elaborada pelo professor A partir do modelo relacional é possível gerar um script com os comandos necessários para implementar o modelo físico que é o de criação das tabelas Segue exemplo abaixo MODELO FÍSICO Departamento Empregado Logico CREATE TABLE Empregado codempregado INTEGER PRIMARY KEY nomeempregado VARCHAR 30 coddepartamento INTEGER CREATE TABLE Departamento coddepartamento INTEGER PRIMARY KEY nomedepartamento VARCHAR 30 ALTER TABLE Empregado ADD CONSTRAINT FK Empregado Departamento FOREIGN KEY coddepartamento REFERENCES Departamento coddepartamento ON DELETE RESTRICT Os scripts gerados a partir do modelo relacional geralmente necessitam ser customizados para atender a algumas padronizações existentes na empresa TOPBANCDADA1 Texto de apoio Anterior 5 MAPEAMENTO MER vs RELACIONAL Sair do livro 6 REFERÊNCIAS BIBLIOGRÁFICAS DATE C J Introdução a Sistemas de Banco de Dados 7 ed São Paulo Campus 2000 Capítulo 1 Uma visão geral do gerenciamento de banco de dados Capítulo 2 Arquitetura de sistemas de banco de dados ELMASRI R NAVATHE S Sistemas de banco de dados 6 ed São Paulo Pearson 2011 Biblioteca Virtual Universitária Pearson Capítulo 7 Modelagem de dados usando o modelo EntidadeRelacionamento ER Páginas 131148 151154 HEUSER A C Projeto de banco de dados São Paulo Artmed 2009 Minha Biblioteca Introdução Páginas 2426 29 Capítulo 2 Abordagem entidaderelacionamento Páginas 3454 6264 Capítulo 3 Construindo modelos ER Páginas 7279 8393 SILBERCHATS A KORTH H F SUDARSHAN S Sistemas de Banco de Dados 3 ed São Paulo Makron Books 1999 Capítulo 1 16 Apêndices A e B Parte inferior do formulário AULA 2 1 MODELO MULTIDIMENSIONAL APOIO À DECISÃO As aplicações de banco de dados geralmente são classificadas em sistemas de processamento de transação e sistemas de apoio à decisão Os sistemas de processamento de transação também conhecidos como OLTP Online Transaction Processing são sistemas que registram informações sobre transações Uma transação é uma unidade de execução do programa que pode incluir alterar ou excluir vários itens de dados de forma controlada A integridade dos dados é garantida com os usos das seguintes propriedades das transações Atomicidade Todas as operações da transação são refletidas corretamente no banco de dados ou nenhuma Consistência A execução de uma transação preserva a consistência dos dados Isolamento Cada transação não percebe a existência de outras transações Durabilidade As mudanças efetuadas durante a execução da transação deverão ser persistidas no banco de dados mesmo que existam falhas no sistema O termo processamento analítico online OLAP Online Analyical Processing pode ser definido como o processo de criar administrar analisar e gerar relatórios sobre dados que auxiliam no processo de tomada de decisão É importante salientar que o processamento analítico exige algum tipo de agregação de dados Os sistemas de apoio à decisão são sistemas que auxiliam na análise de informação do negócio A tomada de decisão exige uma visão abrangente de todos os aspectos da empresa Para os sistemas de apoio à decisão a consolidação de informações de vários bancos em um local único denominado de Data Warehouse facilitou e incentivou a utilização de ferramentas de análise dos dados Muitas características das consultas de apoio à decisão tornam os sistemas SQL tradicionais inadequados Cláusula WHERE com muitas condições AND e OR Funções estatísticas não suportadas na linguagem SQL A linguagem SQL não fornece suporte adequado em consultas que envolvam condições ao longo do tempo ou que exigem agregação ao longo do tempo O ambiente tradicional não está adaptado à execução em conjunto de muitas consultas relacionadas Os bancos de dados de apoio à decisão têm como característica principal a de ser apenas de leitura A atualização é realizada somente por meio de carga dos dados Não é permitido qualquer tipo de atualização na informação e a exclusão de dados é feita de forma ocasional As principais características dos bancos de dados de apoio à decisão são Colunas são usadas em combinação Integridade não essencial é importante considerar que os dados são originais de sistemas transacionais e já foram devidamente validados A inclusão de campo com características de tempo nas chaves Banco de dados para tomada de decisão acumulam grande quantidade de informação em comparação aos bancos de dados tradicionais Os bancos de dados são indexados A redundância de informação é controlada mas não é tão importante como nos bancos de dados tradicionais As características dos bancos de dados de apoio à decisão associadas às consultas conduzem a necessidade de desempenho 2 DATA WAREHOUSE O Data Warehouse é um banco de dados que contém dados selecionados de sistemas transacionais É estruturado para processamento de consultas orientado por assunto não volátil histórico e integrados com o principal objeto de facilitar a obtenção de dados de apoio à decisão transformando dados em informação Um Data Warehouse deve ter as seguintes características Integração Orientação por assunto Variabilidade no tempo Não volatilidade O Data Warehouse é estruturado como ilustra a Figura 1 Os dados fluem do ambiente operacional para o Data Warehouse Na passagem do nível operacional para o nível de Data Warehouse ocorre uma quantidade de transformações sobre os dados Figura 1 Estrutura do Data Warehouse A fonte de dados da Figura 1 representa de onde os dados são retirados para compor o Data Warehouse até a utilização pelo usuário final Os dados passam por um processo de ETL extração transformação e carga onde geralmente são enviados para uma área intermediária chamada de Stage Area e depois são carregados em Data Marts que têm informação departamental ou para o Data Warehouse 3 MODELO MULTIDIMENSIONAL O Modelo Relacional MR é o modelo de dados efetivamente usado em aplicações e o ambiente operacional que apoia os usuários em suas funções do dia a dia são chamados OLTP Online Transaction Processing Os sistemas OLTP são pouco flexíveis em relação à quantidade de relatórios e consultas Para ajudar no processo de tomada de decisões é recomendável o uso de ferramentas flexíveis e customizáveis Os sistemas OLAP Online Analytical Processing permitem aos usuários navegarem entre os dados da empresa com maior facilidade proporcionando uma visão multidimensional desses dados A modelagem multidimensional é a técnica que busca apresentar os dados em um modelo padronizado e intuitivo que permita o entendimento por parte de usuários com alto desempenho de acesso Modelo de dados Multidimensional são ambientes em que as informações sobre um Fato do negócio se relacionam com as Dimensões relevantes para sua análise sendo representadas por um Cubo ou hipercubo mais que três dimensões conforme a figura abaixo Figura 2 Cubo de três dimensões O foco da modelagem multidimensional é o cruzamento de variáveis e a simplicidade deve ser buscada A visão inicial deve ser conceitual para que se entenda a necessidade de negócio Para a criação de um modelo multidimensional é necessário responder às seguintes questões Quando Onde O quê Quem Como A Figura 3 na forma de estrela ilustra esse questionamento Figura 3 Perguntas a serem respondidas para elaboração de um modelo multidimensional genérico Figura 4 Questões para um sistema de vendas Figura 5 Questões para um sistema de compras Figura 6 Questões para um sistema de produção Outro item necessário na elaboração do modelo multidimensional são as tabelas Fato e Dimensão Tabelas Fato Fatos são as informações importantes para a gestão do negócio são números e valores que podem ser somados agregados para indicar o desempenho da empresa unidade de negócio ou departamento São identificados durante a fase de Análise de Requisitos do projeto Tabelas Fato têm as seguintes características Armazenam os dados que medem o processo que estamos modelando Compõese de Chaves e Métricas Figura 7 Tabela Fato identificado como FatoVendas Para identificar as Tabelas Fato responda às seguintes questões Que processo está modelando Por exemplo Vendas O que se usa para medir esse processo Por exemplo Valor das vendas quantidade vendida A que nível esta métrica é significativa Granularidade Por exemplo Vendas no trimestre Tabelas Dimensão As dimensões são as formas como os gestores querem visualizar o negócio São informações pois dão significado aos números medidas valores métricas As dimensões são identificadas durante a fase de Análise de requisitos A Tabela Dimensão é uma perspectiva pela qual se pretende observar as métricas relativas ao processo que estamos modelando Compõese de um ou mais atributos Figura 8 Tabela Dimensão identificada como DimCliente Descobrindo tabela dimensão Geralmente as dimensões são derivadas das perguntas do usuário após entendimento da métrica Reescreva a pergunta do usuário utilizando a seguinte forma Métrica POR Dimensão POR Dimensão Por exemplo Quais foram as vendas no período de junho a julho deste ano na região sul Seria Valor das vendas POR período POR região Existem diversas técnicas de modelagem de Data Warehouse As mais utilizadas são o esquema Estrela Star Schema e o Floco de Neve Snowflake será comentado o esquema Estrela No modelo Estrela um único FATO tabela fato é colocado no centro e ligado às DIMENSÕES tabelas dimensões como uma estrela Cada dimensão é representada por uma única tabela A chave primária PK de cada dimensão está relacionada com uma chave estrangeira FK da tabela fato E todas as medidas da tabela Fato estão relacionadas com todas as Dimensões isto significa que elas têm o mesmo nível de Granularidade Figura 9 Esquema Estrema Fato Medidas Granularidade Dimensão Atributos Hierarquias Na Figura 10 está ilustrado um exemplo do esquema Estrela Figura 10 Exemplo esquema Estrela Fato Os dados foram consolidados por dia e por venda ETL Valor da venda por dia e por vendedor Dimensões Tempo Vendedor 4 REFERÊNCIAS BIBLIOGRÁFICAS DATE C J Introdução a Sistemas de Banco de Dados 7 ed São Paulo Campus 2000 Capítulo 21 Apoio à decisão ELMASRI R NAVATHE S Sistema de banco de dados 6 ed São Paulo Pearson 2011 Biblioteca Virtual Universitária Pearson Capítulo 25 Data Warehousing e Apoio à Decisão INMON W H WELCH J D GLASSEY K L Gerenciando Data Warehouse São Paulo Makron Books 1999 Capítulo 1 Monitorando a Atividade do Data Warehouse Capítulo 2 Monitorando Dados do Data Warehouse SILBERCHATS A KORTH H F SUDARSHAN S Sistemas de Banco de Dados São Paulo Elsevier 2012 Capítulo 18 Mineração e Análise de Dados AULA 3 1 ETL INTRODUÇÃO Os dados que atendem a necessidades operacionais são fisicamente diferentes dos dados que atendem a necessidades informacionais ou analíticas A tecnologia de suporte ao processamento operacional é fundamentalmente diferente da tecnologia utilizada para prestar suporte a necessidades informacionais ou analíticas Para que o processo de tomada de decisão seja feito é importante que os dados informacionais sejam disponibilizados no formato analítico para isso podese usar o processo de ETL extração transformação e carga Segue uma sugestão de arquitetura de um processo de ETL Para a realização do processo de ETL devem ser identificados os requisitos de negócios os formatos e deficiências dos dados de origem os sistemas legados existentes e as necessidades em constante mudança e legítimas dos usuários finais Dois segmentos simultâneos devem ocorrer ao se construir um sistema de ETL o segmento de planejamento e design o segmento de fluxo de dados Ambos progridem de forma ordenada da esquerda para a direita nos diagramas PLANEJAMENTO E DESIGN Para a realização do planejamento e design os seguintes requisitos são necessários Necessidades de negócios Perfil de dados e outras realidades da fonte de dados Requisitos de conformidade Requisitos de segurança Integração de dados Latência de dados Figura 1 Planejamento e Design Adaptado de The Data Warehouse ETL Toolkit 3 FLUXO DE DADOS O fluxo de dados é uma generalização simples do ETL Extração Transformação Carga Figura 2 Fluxo de Dados Adaptado de The Data Warehouse ETL Toolkit 4 ETL A construção de um ambiente de Data Warehouse DW ou de um Big Data passa por diversas etapas até sua consolidação A modelagem multidimensional e o processo ETL são as principais técnicas para essa construção Em algumas situações essa estrutura pode ser chamada de Data Mart Um DW comparado aos bancos de dados tradicionais possui uma grande quantidade de dados de várias fontes que podem ser de diferentes modelos sistemas e plataformas Então para criar e manter um DW é preciso que os dados passem por um processo de ETL Extração Transformação e Carga ETL Extract Transform and Load é um processo de extração transformação e carga para a construção de um DW ou para um ambiente de Big Data O processo de ETL exige esforço e a maior parte do tempo de construção será o de extrair dados de fontes de dados heterogêneas e alimentar a base de dados de forma homogênea e concisa uma vez que servirá de base para gerar relatórios e gráficos de apoio à decisão para a gerência da corporação não podendo trazer resultados inconsistentes Os objetivos principais do processo de ETL são Extração extrair informações das diversas fontes de dados Transformação transformar limpar modificar a informação Carga gravar os dados em seu destino independentemente de seu formato que pode ser em um arquivo em uma tabela da base transacional em uma dimensão ou tabela fato de um cubo ou em formato Big Data 5 EXTRAÇÃO Acessa os dados das diversas fontes banco de dados arquivos txt csv xml páginas da web formatos Big Data como Cassandra MongoDB dentre outras fontes extraindoos e transferindoos para o ambiente de DW O processo de extração é responsável por se comunicar com as diversas fontes de dados para capturar os dados que na maioria dos casos são inseridos em área intermediária chamada Staging Area A qualidade de dados dos sistemas de origem é diferente da qualidade exigida pelos Data Warehouse O processamento de qualidade de dados pode envolver as seguintes etapas incluir a verificação de valores válidos garantindo a consistência entre os valores remover informações duplicadas verificar se regras e procedimentos de negócios complexos foram aplicados 6 TRANSFORMAÇÃO Nesta etapa realizamse os devidos ajustes podendo melhorar a qualidade dos dados e consolidar dados das diversas fontes ou seja Limpar os dados Garantir qualidade dos dados Descartar dados inválidos Padronizar Tamanho e tipo Substituição de caracteres estranhos Correção de erros de digitação Comparação fonética para evitar duplicidade de informações por exemplo o mesmo nome escrito de formas diferentes com ou sem acentuação Substituição de dados não preenchidos por Não Informado por exemplo Padronização de unidades de medida pois em determinado sistema a unidade pode estar em metros e em outro estar em polegadas Exemplos do que poderá ser feito nesta etapa Padronizar os dados com relação às diferentes definições de informação por exemplo em um sistema há a definição de H para homem e M para mulher em outro M para masculino e F para feminino CARGA Os dados serão lidos na área de Staging e carregados no Data Warehouse Data Mart ou Big Data 7 ARQUITETURA DE UM PROCESSO DE ETL 8 REFERÊNCIAS BIBLIOGRÁFICAS FERREIRA João et al O Processo ETL em Sistemas Data Warehouse Universidade do Minho INForum 2010 II Simpósio de Informática 910 set 2010 p 757765 Braga Portugal Disponível em httpswwwresearchgatenetpublication265195317OProcessoETLemSistemasDataWarehouse Acesso em7 maio 2021 IMMON William H Como construir o data warehouse Tradução de Ana Maria Netto Guz Rio de Janeiro Campus 1997 KIMBALL Ralph CASERTA J The data warehouse ETL toolkit practical techniques for extracting cleaning conforming and delivering data Indianapolis Wiley Publishing Inc 2004 AULA 1 DASHBOARDS INTRODUÇÃO Por que visualizamos dados Vejamos por que é vital visualizar os números começando com a Tabela 1 Existem quatro grupos de números cada um com 11 pares Se a tabela não mostra nada e as estatísticas não revelam muito o que acontece quando plotamos os números conforme Figura 1 Agora é possível verificar as diferenças Ver os números em um gráfico mostra algo que as tabelas e algumas medidas estatísticas não conseguem Tabela 1 Nome Grupo A Grupo B Grupo C Grupo D x y x y x y x y 1000 804 1000 914 1000 746 800 658 800 695 800 814 800 677 800 576 1300 758 1300 874 1300 1274 800 771 900 881 900 877 900 711 800 884 1100 833 1100 926 1100 781 800 847 1400 996 1400 810 1400 884 800 704 600 724 600 613 600 608 800 525 400 426 400 310 400 539 1900 1250 1200 1084 1200 913 1200 815 800 556 700 482 700 726 700 642 800 791 500 568 500 474 500 573 800 689 Adaptado de The Big Book of Dashboards Figura 1 A visualização dos dados definidos na Tabela 1 Fonte Elaborado pelo autor Visualizamos dados para identificar relacionamentos e tendências Para ler a tabela precisamos consultar todos os valores um de cada vez Este exemplo é a criação de Frank Anscombe um estatístico britânico Ele criou esse conjunto de números chamados Quarteto de Anscombe em seu artigo Graphs in Statistical Analysis em 1973 2 VISUALIZAÇÃO DE DADOS Como visualizamos os dados Para fazer isso primeiro precisamos examinar duas coisas atributos préatencionais e tipos de dados Atributos préatencionais A visualização de dados requer que transformemos os dados em marcas em uma tela Que tipo de marca faz mais sentido Uma resposta está nos chamados atributos préatencionais preattentive atributes Esses itens são apresentados em destaque e fazem com que nosso cérebro processe em milissegundos antes de prestarmos atenção a todo o resto Vejamos um exemplo Observe a Figura 2 comparea com a Figura 3 e avalie como é fácil responder à pergunta de quantas letras ã existem Figura 2 Nome Adaptado de The Big Book of Dashboards Figura 3 Nome Adaptado de The Big Book of Dashboards Tipos de dados Existem três tipos de dados Categóricos Ordinais Quantitativos Categóricos Os dados categóricos ou nominais representam coisas Essas coisas são rótulos mutuamente exclusivos sem nenhum valor numérico Por exemplo O aluno João Cursa Tecnologia da Informação Geralmente são usados para descrever algo Ordinais Os dados ordinais são semelhantes aos dados categóricos exceto por terem uma ordem clara Por exemplo O código de matrícula do João A data de nascimento do João Outros tipos de dados ordinais incluem por exemplo nível de satisfação com relação ao curso Quantitativos Os dados quantitativos são os números Dados quantitativos ou numéricos são dados que podem ser medidos e agregados Por exemplo As notas do João As faltas em cada período de aula Outros tipos de medidas quantitativas incluem vendas lucro média no semestre número de aluno em um determinado curso Os dados quantitativos podem ser expressos de duas maneiras como dados discretos ou contínuos Os dados discretos são apresentados em pontos exatos predefinidos Os dados contínuos permitem um número infinito de valores intermediários possíveis Na Figura 4 utilizaremos o número de nascimentos em São Paulo para identificar os tipos de dados Figura 4 Nascimentos em São Paulo Tabela 2 Identificação dos tipos de dados 3 FERRAMENTAS DE VISUALIZAÇÃO O que você pode fazer com uma ferramenta de visualização Visualize seus dados por meio de gráficos e tabelas altamente configuráveis Conectese a várias fontes de dados com facilidade Compartilhe insights com a equipe ou com o mundo Colabore com sua equipe na geração de relatórios As ferramentas de visualização transformam seus dados em relatórios e painéis informativos fáceis de ler e de compartilhar e totalmente personalizáveis Use os recursos da ferramenta para contar sua história de dados com gráficos incluindo gráficos de linhas barras e pizza mapas geográficos gráficos de área e bolhas tabelas de dados paginadas tabelas dinâmicas e muito mais criar relatórios interativos com os filtros de visualizador e controles de período Exemplo de ferramentas de visualização Data Studio do Google Power BI da Microsoft Oracle Data Analytics da Oracle Tableau da Tableau Software 4 REFERÊNCIAS BIBLIOGRÁFICAS AJUDA do Data Studio Disponível em httpssupportgooglecomdatastudioanswer6287179 ANSCOMBE F J Graphs in Statistical Analysis The American Statistician v 27 n 1 p 1721 fev 1973 Disponível em httpswwwjstororgstable2682899 Acesso em 7 maio 2021 ECKERSON W W Performance Dashboards measuring monitoring and managing your business Hoboken Wiley 2010 POWER BI Disponível em httpspowerbimicrosoftcomptbr WEXLER S SHAFFER J COTGREAVE A The Big Book of Dashboards visualizing your data using realword business scenarios Hoboken Wiley 2017 Aula 5 1 BANCO DE DADOS ORIENTADOS A OBJETOS E BANCOS DE DADOS DE OBJETO RELACIONAL INTRODUÇÃO Os sistemas de banco de dados relacionais estão preparados para aceitar uma pequena coleção fixa de tipos de dados Os desenvolvimentos em linguagem de programação orientada a objetos estão conduzindo a manipulação de dados complexos herança e outros recursos Ao mesmo tempo a tecnologia de banco de dados relacional está sendo ampliada para combinar recursos de gerenciamento de dados com a aplicação de regras lógicas para fornecer informações mais refinadas para o gerenciamento Os dados complexos têm sido armazenados em sistemas de arquivos do sistema operacional ou em estruturas de dados especializadas em vez de em um Sistema de Gerenciador de Banco de Dados 2 CONCEITOS DE ORIENTAÇÃO A OBJETOS Objetos complexos Objetos complexos são construídos a partir de outros mais simples aplicando construtores a eles Os objetos mais simples são inteiros caracteres cadeias de bytes de qualquer comprimento booleanos e flutuantes Existem vários construtores de objetos complexos como tuplas sets bags e lists Os construtores de objeto devem ser ortogonais ao objeto ou seja qualquer construtor deve se aplicar a qualquer objeto O construtor do modelo relacional não atende a esse requisito porque o conjunto de construtores só pode ser aplicado a tuplas e o construtor de tupla só pode ser aplicado a valores atômicos Operadores apropriados devem ser fornecidos para lidar com objetos complexos qualquer que seja sua composição Ou seja a operação em um objeto complexo deve se propagar transitivamente para todos seus componentes 2 CONCEITOS DE ORIENTAÇÃO A OBJETOS 21 Identidade do objeto OID A identidade do objeto existe há muito tempo em idiomas de programação mas o conceito é mais recente em bancos de dados A ideia é que em um modelo com identidade de objeto um objeto tem uma existência independente de seu valor Dois objetos podem ser idênticos eles são o mesmo objeto ou eles podem ser iguais eles têm o mesmo valor Cada objeto tem um OID A identidade de um objeto é independente de seu valor Um objeto pode ser visto como um par OID valor Características do OID do objeto São gerados pelo sistema Não são visíveis para usuários São independentes do endereço de armazenamento São imutáveis É desejável que seja utilizado apenas uma vez mesmo após a exclusão do objeto Objetos podem ter seus valores atualizados sem perder suas identidades Relação entre OID e PRIMARY KEY Uma PK é única dentro de uma relação os OID são únicos dentro de um sistema A PK é implementada pelo programador o OID é implementado pelo sistema A PK é mais significativa para o usuário Isso gera dificuldades na hipótese de alteração Os OID não carregam informações semânticas da aplicação e não podem ser alterados As PK são acessadas pelos usuários Alguns sistemas não permitem acesso aos OID É necessário assimilar novos conceitos de comparação entre objetos Identidade Dois objetos são o mesmo possuem o mesmo OID Igualdade Dois objetos são iguais possuem o mesmo valor 2 CONCEITOS DE ORIENTAÇÃO A OBJETOS 22 Encapsulamento de dados e de código A ideia de encapsulamento vem da necessidade de uma distinção clara entre a especificação e a implementação de uma operação e da necessidade de modularidade A modularidade é necessária para estruturar aplicativos complexos projetados e implementados por uma equipe de programadores Ela também é necessária como uma ferramenta de proteção e autorização Existem duas visões de encapsulamento visão da linguagem de programação que é a visão original uma vez que o conceito se originou ali e a adaptação do banco de dados dessa visão A ideia de encapsulamento em linguagem de programação vem de tipos de dados abstratos Nessa visão um objeto tem uma parte de interface e uma parte de implementação A tradução do banco de dados do princípio é que um objeto encapsula o programa e os dados No mundo do banco de dados não está claro se a parte estrutural do tipo é parte da interface enquanto no mundo da linguagem de programação os dados são claramente parte da implementação e não da interface Cada objeto tem nele encapsulado um comportamento e uma estrutura Estrutura formada por atributos que juntos representam o estado do objeto Comportamento formado pelo conjunto de métodos que podem ser executados sobre o objeto Conjunto de variáveis que armazenam o estado do objeto Conjunto de mensagens às quais o objeto responde Conjunto de métodos contendo o código de programa que implementa a mensagem 2 CONCEITOS DE ORIENTAÇÃO A OBJETOS 23 Tipos de dados Um tipo em um sistema orientado a objetos resume as características comuns de um conjunto de objetos Corresponde à noção de um tipo de dado abstrato Possui duas partes a interface e a implementação Apenas a parte da interface é visível para os usuários do tipo A interface consiste em uma lista de operações junto com suas assinaturas A noção de classe é diferente da de tipo Suas especificações são as mesmas de um tipo mas é mais uma noção de tempo de execução Ele contém dois aspectos uma fábrica de objetos e um armazém de objetos A fábrica de objetos pode ser utilizada para criar novos objetos realizando o new na classe ou clonando algum objeto protótipo representativo da classe O warehouse de objetos permite que a classe seja anexada à sua extensão ou seja o conjunto de objetos que são instâncias da classe O usuário pode manipular o warehouse aplicando operações em todos os elementos da classe As classes não são usadas para verificar a exatidão de um programa mas sim para a criação e manipulação de objetos Existem fortes semelhanças entre classes e tipos Os nomes foram usados com ambos os significados e as diferenças podem ser sutis em alguns sistemas A noção clássica de um esquema schema de banco de dados será substituída por um conjunto de classes ou um conjunto de tipos 2 CONCEITOS DE ORIENTAÇÃO A OBJETOS 24 Herança A herança tem duas vantagens é uma ferramenta poderosa de modelagem porque fornece uma descrição concisa e precisa do mundo e ajuda na fatoração de especificações de compartilhamento e implementação em aplicativos 3 ORIENTAÇÃO A OBJETOS É NECESSÁRIO Precisamos de BDOO Não vivemos bem com BD Relacional Caracteristicas das aplicações convencionais Uniformidade de instância Grande número de itens de dados com estrutura semelhante e com tamanho idêntico Orientação a registros O tipo básico de dados é o registro de estrutura e seu tamanho fixo Pequenos itens de dados Campos são de pequeno tamanho Campos atômicos Não há estrutura dentro dos campos Registros estão na primeira forma normal Características dos bancos de dados relacionais Uniformidade entre itens de dados Orientação a registro Itens de dados pequenos Campos atômicos Transações curtas Esquemas conceituais estáticos Os bancos de dados relacionais são limitados para atender a requisitos relacionados com persistência de objetos complexos Estes requisitos estão presentes em certas categorias de aplicações denominadas não convencionais CAD Geoprocessamento mapas satélites GPS Hipermídia Multimídia Mobile Games Do ponto de vista da persistência aplicações desenvolvidas sob o paradigma da orientação a objetos são mais indicadas para atender aplicações não convencionais O problema é que a camada de persistência não acompanhou a evolução da POO de forma sincronizada Do ponto de vista da orientação a objetos para bancos de dados temos duas possibilidades SGBDOO Sistemas de gerenciamento de banco de dados orientado a objetos Alternativa para SGBD relacionais Enfoque Objetos complexos Programação orientada a objetos SGBDOR Sistemas de gerenciamento de banco de dados de objeto relacional Extensão para SGBD relacionais Ponte entre Relacional e OO Vantagens de usar BDOR no lugar de BDR Tipos de dados mais ricos Modelagem OO Vantagens de usar BDOR em lugar de BDOO Suporte à SQL Gerência de transações Processamento e otimização de consultas Aplicações legadas 3 ORIENTAÇÃO A OBJETOS É NECESSÁRIO 31 Extensões ao Modelo Relacional Definição de novos tipos de dados Tipos de dados complexos Incorporação de novas funcionalidades ao SGBD para manipular estes novos tipos de dados Suporte à herança Manipulação de objetos pelo usuário Extensões à SQL para manipular e consultar objetos 4 REFERÊNCIAS BANCILHON F DELOBEL C KANELLAKIS P Building an ObjectOriented Database System The Story of 02 Massachusetts Morgan Kaufmann Publishers 1992 ELMASRI R NAVATHE S Sistemas de Banco de Dados 7 ed São Paulo Pearson 2018 HANSEN G W HANSEN J V Database Management and Design 2 ed Nova Jersey Prentice Hall 1996 RAMAKRISHNAN R GEHRKE J Sistemas de Gerenciamento de Banco de Dados 3 ed Porto Alegre AMGH 2008 AULA 6 1 BANCO DE DADOS NoSQL INTRODUÇÃO Os primeiros Sistemas Gerenciadores de Banco de Dados Relacionais SGBDR surgiram por volta de 1960 e dentre as principais características de um SGBDR destacamos controle de concorrência segurança recuperação de falhas gerenciamento dos mecanismos de armazenamento de dados e controle das restrições de integridade do BD Vantagens do modelo relacional SQL todo mundo conhece linguagem bem flexível muitos operadores boas ferramentas Dados bem padronizados e normalizados Relacionamentos e junções ACID Atomicidade tudo ou nada Consistência validação respeita integridade Isolamento concorrência retorna resultado válido Durabilidade uma vez gravado é definitivo Atualmente há um grande e crescente volume de dados digitais das redes sociais por exemplo que requerem o gerenciamento de grandes quantidades de dados não estruturados os quais são gerados diariamente por milhões de usuários em busca do compartilhamento de informações conhecimentos e interesses Bancos de dados relacionais não foram projetados para gerenciar tais dados pois precisam que os dados tenham uma estrutura rígida e com pouca mudança além de sua limitação de escalabilidade vertical Neste contexto surgiu uma nova categoria de Banco de Dados chamada NoSQL Not Only SQL que foi proposta com o objetivo de atender aos requisitos de gerenciamento de grandes volumes de dados semiestruturados ou não estruturados que necessitam de alta disponibilidade e escalabilidade De acordo com sua estrutura podemos classificar os dados em Dado estruturado possui estrutura formal Dado semiestruturado não possui estrutura rígida mas pode possuir marcas ou tags como XML ou JSON Dado não estruturado não possui estrutura alguma e pode se referir a documentos comerciais PDF conteúdo de redes sociais artigos digitalizados vídeo áudio conteúdo web entre outros O termo NoSQL foi utilizado pela primeira vez em 1998 como nome de um banco de dados relacional de código aberto que não possuía uma interface SQL Porém o termo só voltou a ser assunto em 2009 em um evento para discutir bancos de dados open source distribuídos Os NoSQL são diferentes sistemas de armazenamento que vieram para suprir necessidades nas quais os bancos de dados tradicionais relacionais são ineficazes Muitas dessas bases apresentam características interessantes como alta performance escalabilidade replicação entre outras O NoSQL surgiu da necessidade de uma performance superior e de alta escalabilidade Ele tem uma grande facilidade na distribuição horizontal ou seja mais dados mais servidores não necessariamente de alta performance Um grande utilizador desse conceito é o Google que usa computadores de pequeno e médio porte para a distribuição dos dados Essa forma de utilização é muito mais eficiente e econômica Atualmente temos vários bancos NoSQL que podem resolver diversos problemas Mas eles não são a chave para todos os problemas pois existem cenários em que os bancos relacionais são mais indicados visto que eles possuem as propriedades ACID para tratamento de transações principalmente Logo os bancos relacionais são melhores em cenários nos quais os dados são muitíssimo importantes e não pode haver nenhuma quebra de referência Ou seja não seria indicado utilizar algum banco NoSQL para sistemas de transações financeiras por exemplo Mas se seu sistema é alguma rede social ou algum site que necessite de alta disponibilidade ou escalabilidade com certeza seria indicado um banco NoSQL Entretanto não precisamos mudar todo o sistema para algum banco NoSQL mas sim utilizar um banco NoSQL e um banco relacional em conjunto 2 CARACTERÍSTICAS DE UM BANCO DE DADOS NoSQL Os bancos de dados NoSQL apresentam algumas características fundamentais que os diferenciam dos tradicionais sistemas de bancos de dados relacionais tornandoos adequados para o armazenamento de grandes volumes de dados não estruturados ou semiestruturados A seguir serão descritas algumas características dos bancos NoSQL Escalabilidade horizontal Ausência de esquema ou esquema flexível Suporte nativo à replicação Consistência eventual 2 CARACTERÍSTICAS DE UM BANCO DE DADOS NoSQL 21 Escalabilidade À medida que o volume de dados cresce aumenta a necessidade de escalabilidade e melhoria de desempenho Dentre as soluções para esse problema temos Escalabilidade vertical que consiste em aumentar o poder de processamento e armazenamento das máquinas Escalabilidade horizontal na qual ocorre um aumento no número de máquinas disponíveis para o armazenamento e processamento de dados Figura 1 Escalabilidade Horizontal Fonte Elaborada pelo autor 2 CARACTERÍSTICAS DE UM BANCO DE DADOS NoSQL 22 Ausência de esquema ou esquema flexível Uma característica evidente dos bancos de dados NoSQL é a ausência completa ou quase total do esquema que define a estrutura dos dados modelados Em contrapartida não há garantias da integridade dos dados o que ocorre nos bancos relacionais devido a sua estrutura rígida Essas estruturas são em sua maioria baseadas em um conceito de chavevalor permitindo uma alta flexibilidade na forma como os dados são organizados 2 CARACTERÍSTICAS DE UM BANCO DE DADOS NoSQL 23 Suporte nativo à replicação Outra forma de prover escalabilidade é por meio da replicação Permitir a replicação de forma nativa diminui o tempo gasto para recuperar informações Figura 2 Paralelismo Fonte Elaborada pelo autor 2 CARACTERÍSTICAS DE UM BANCO DE DADOS NoSQL 24 Consistência eventual É uma característica de bancos NoSQL relacionada ao fato da consistência nem sempre ser mantida entre os diversos pontos de distribuição de dados Essa característica tem como princípio o teorema CAP Consistency Availability e Partition Tolerance que diz que em um dado momento só é possível garantir duas de três propriedades entre consistência disponibilidade e tolerância à partição Principais motivos para utilizar um banco de dados não relacional Flexibilidade Escalabilidade Disponibilidade Raízes open source Baixo custo operacional Geralmente os bancos NoSQL são classificados por seu modelo de dados como banco de dados chavevalor banco de dados orientado a documentos banco de dados orientado a família de colunas banco de dados orientado a grafos 2 CARACTERÍSTICAS DE UM BANCO DE DADOS NoSQL 25 Banco de dados chavevalor Esse é o tipo de banco de dados NoSQL mais simples O conceito dele é uma chave e um valor para essa chave ou seja o banco de dados é composto por um conjunto de chaves as quais estão associadas a um único valor É o que suporta mais carga de dados Este modelo permite que os dados sejam rapidamente acessados pela chave e com isso aumenta a disponibilidade de acesso aos dados As operações disponíveis para manipulação de dados são bem simples como o get e o set que permitem retornar e capturar valores respectivamente A desvantagem é a de não permitir a recuperação de objetos por meio de consultas mais complexas ou seja possibilitam a busca pelos dados somente por meio de suas chaves Exemplos de bancos chavevalor Amazon DynamoDB não é open source Project Voldemort implementação open source do Amazon DynamoDB Redis Riak Azure Table Storage etc 2 CARACTERÍSTICAS DE UM BANCO DE DADOS NoSQL 26 Banco de dados orientados a documentos Como o próprio nome diz este modelo armazena coleções de documentos Um documento em geral é uma estrutura de dados na forma de arvores No modelo chavevalor apenas uma única tabela hash é criada para todo o banco Já no modelo orientado a documentos temos um conjunto de documentos e em cada documento temos um conjunto de campos chaves e o valor desse campo Outra característica importante é que este modelo não depende de um esquema rígido ou seja não exige uma estrutura fixa como ocorre nos bancos relacionais Assim é possível que ocorra uma atualização na estrutura do documento com a adição de novos campos por exemplo sem causar problemas ao banco de dados Na Figura 3 a seguir temos um exemplo de documento representando um post de um blog onde os campos definidos foram Assunto Autor Data Tags e Mensagem Para cada um desses campos temos seus valores associados Não há restrições em atualizar o documento mesmo que agora exista um novo campo chamado comentários Essa flexibilidade é uma das grandes vantagens deste modelo Figura 3 Exemplo de Post de Blog Fonte Elaborada pelo autor Dentre as principais soluções que adotam o modelo orientado a documentos destacamse o MongoDB 2 CARACTERÍSTICAS DE UM BANCO DE DADOS NoSQL 27 Bancos de dados orientados a família de colunas Os bancos de dados orientados a família de colunas permitem que você armazene dados com chaves mapeadas para valores e os valores são agrupados em múltiplas famílias de colunas cada uma dessas famílias de colunas funcionando com um mapa de dados Exemplos de bancos de dados de família de colunas Cassandra Hbase Hypertable Amazon DynamoDB 2 CARACTERÍSTICAS DE UM BANCO DE DADOS NoSQL 28 Bancos de dados orientados a grafos Os bancos de dados orientados a grafos permitem que se armazene entidades e um relacionamento entre as entidades Esse modelo apresenta uma representação explícita de relacionamento entre os dados por meio de um modelo com vértices chamados de nós e arcos chamados de relações Exemplos de bancos de dados orientados a grafos Neo4j GraphDB 3 REFERÊNCIAS FOWLER M SADALAGE P J NoSQL Essencial São Paulo Novatec 2013 HOWS D MEMBREY P PLUGGE E Introdução ao MongoDB São Paulo Novatec 2015 INTRODUÇÃO aos bancos de dados NoSQL DevMedia sd Disponível em httpwwwdevmediacombrintroducaoaosbancosdedadosnosql26044 Acesso em 11 jun 2021 LÓSCIO B F OLIVEIRA H R NoSQL no desenvolvimento de aplicações Web colaborativas In SIMPÓSIO BRASILEIRO DE SISTEMAS COLABORATIVOS SBSC 8 2011 Paraty MACHADO F T S SACCOL D B Mineração de dados para modelos NoSQL um survey In ESCOLA REGIONAL DE BANCO DE DADOS 2016 Londrina Anais da Escola Regional de Banco de Dados 2016 AULA 7 1 BIG DATA INTRODUÇÃO A tempos não temos uma palavra tão forte no cenário de informática como Big Data O termo está sendo falado em todos os tipos de negócios cursos meios de comunicação etc conforme a Figura 1 Figura 1 A Palavra do Momento Big Data Fonte Elaborada pelo autor Atualmente temos um volume grande de informações sendo geradas pela internet e pelas redes sociais assim como smartphones e câmeras de controle que geram um grande volume de diversos tipos de informação estruturada ou não estruturada Os dados atualmente são em sua maioria armazenados em meio digital graças à queda nos custos dos computadores e dos sistemas de armazenamento e também ao crescimento das capacidades de processamento e armazenamento que permitiram a utilização de informação digital Nas Figuras 2 e 3 temos o que acontece em 60 segundos com relação às informações na internet Figura 2 O Que Aconteceu a Cada 60 Segundos em 2020 Figura 3 O Que Aconteceu a Cada 60 Segundos em 2019 Tanto os dados gerados pelas redes sociais como diversos dados gerados para outras finalidades são de extrema importância se levarmos em consideração o quanto eles podem nos auxiliar e indicar por meio de suas correlações o tipo de comportamento de compra de um determinado cliente ou até mesmo prenunciar uma crise em um setor da economia a migração de clientes para a concorrência e surtos de doenças infeciosas como a COVID19 ou o Zika Vírus 2 DEFINIÇÃO O termo Big Data em tradução livre para o português significa Grandes Dados e foi definido originalmente no início dos anos 2000 por um analista do Gartner Group Segue a definição de Big Data para o Gartner Group Big Data em geral é definido como ativos de alto volume velocidade e variedade de informação que exigem custobenefício de formas inovadoras de processamento de informações para maior visibilidade e tomada de decisão Conforme Machado 2018 Big Data é o termo que descreve o enorme volume de dados estruturados e não estruturados que podem impactar os negócios de qualquer empresa no seu dia a dia O que é realmente importante é como que as empresas farão para identificar e definir quais são os dados que realmente importam e são desejados e o que fazer com eles O termo Big Data Analytics que está sendo muito utilizado no momento identifica não somente poderosos softwares capazes de tratar esses dados como também as técnicas utilizadas com o objetivo de transformar o volume de dados em informações úteis às organizações Iniciativas apoiadas em Big Data Analytics possibilitam analisar dados estruturados e não estruturados Big Data pode ser definido como ferramentas e práticas que gerenciam e analisam grandes volumes de dados de diferentes fontes em velocidade considerável buscando agregar às organizações valor de negócios e maior confiabilidade em relação às decisões a serem tomadas Portanto Big Data é A capacidade de administrar um volume enorme de diferentes dados na velocidade certa e dentro do prazo para permitir análises e reações em tempo real O conceito fundamental para definir Big Data está relacionado aos 3 Vs Volume Velocidade Variedade Volume O volume diz respeito aos grandes volumes de informações Cada pessoa produz uma infinidade de informações que podem ser muito valiosas para a obtenção de valor desde suas preferências musicais sua localização durante os diferentes horários do dia seu meio de transporte os aplicativos que acessou e até o restaurante que almoçou Multiplique essa grande quantidade de informações por bilhões de pessoas conectadas à rede e podemos ter uma ideia do volume astronômico de dados Velocidade O tempo necessário para disponibilizar dados para análise é cada vez menor Atualmente para alguns negócios 1 minuto pode ser muito tempo para detectar fraudes liberar pagamentos ou analisar dados médicos por exemplo Variedade A variedade tem sua origem na grande diversidade de informações que podem ser úteis para a geração de valor o texto de uma opinião registrada em um site de reclamações uma curtida em uma rede social coordenadas de um GPS upload de fotos e gravações em um aplicativo de mensagens instantâneas filmagens transmitidas em tempo real por um drone conectado à rede Com relação aos tipos de dados que podem ser tratados temos Dados estruturados atualmente a minoria provenientes de sistemas estruturados tradicionais são organizados em linhas e colunas geralmente são encontrados em banco de dados relacionais são eficientes quanto à recuperação e ao processamento Dados não estruturados a imensa maioria gerados por emails mídias sociais Facebook Twitter Youtube entre outros documentos eletrônicos vídeos e imagens sensores etc muitas vezes não dispõem de componentes necessários para a identificação de tipo de processamento e interpretação tornando seu uso um desafio principalmente em aplicativos empresariais grande parte dos dados digitais gerados atualmente principalmente por meio de mídias sociais são do tipo não estruturados ou seja cerca de 80 dos dados corporativos são dados não estruturados podendo ser encontrados na forma de emails comentários em redes sociais vídeos entre outros Dado semiestruturados Dados que utilizam tags como HTML e JSON Algumas definições de Big Data ainda consideram outros 2 Vs conforme ilustrado pela Figura 4 Veracidade faz referência à necessidade de se garantir que os dados sejam autênticos com relação à fonte da informação e que são verdadeiros naquele momento Valor representa o ponto mais importante quando falamos de Big Data Nada dos conceitos e exemplos citados anteriormente faz sentido se não for possível extrair valor dos dados Figura 4 Os 5 Vs do Big Data Fonte Elaborada pelo autor Nada dos conceitos citados anteriormente faz sentido se não for possível extrair algum valor dos dados que seja útil para análises sobre os negócios de uma empresa 3 DIFERENÇAS ENTRE BI E BIG DATA Conforme Machado 2018 o BI Business Intelligence é uma base sólida para buscar explorar analisar os dados e as informações utilizadas no Big Data É importante termos um ambiente de BI devidamente estruturado e com seus indicadores bem definidos Os dois podem e devem existir simultaneamente Empresas que possuem uma solução de BI sólida provavelmente terão mais maturidade para embarcar em projetos extensivos de Big Data Os relatórios dashboards do BI fazem sentido com seus dados internos apresentados de maneira bastante visual e facilitada mas não é possível fazer análises além dos limites das operações da empresa Para encontrar correlações de dados novos segmentos de mercados e fazer previsões são necessárias soluções mais complexas capazes de enriquecer sua percepção da realidade do negócio O BI utiliza dados estruturados originários de bancos de dados relacionais Como atualmente 80 a 90 dos dados gerados são não estruturados é importante e necessário adaptarse a essa nova realidade O BI trata das perguntas conhecidas e de nossas preconcepções em relação aos dados históricos Já o Big Data busca descobrir novos padrões e fatos decorrentes que podem acontecer 4 CASO DE SUCESSO NO USO DE BIG DATA Por isso um dos exemplos mais conhecidos de empresa que faz uso intensivo da análise de dados é a WalMart comentado por Hays 2004 A WalMart utiliza diversas técnicas de análise de dados para melhorar sua competitividade de várias formas entendendo melhor o padrão de consumo de seus clientes correlaciona o acontecimento de eventos à compra de produtos alimentícios exemplificado por Linda M Dillman CIO da WalMart No passado não sabíamos que as vendas de Pop Tarts de morango um cereal doce que os americanos comem no café da manhã aumentavam em até sete vezes antes de um furacão e complementando que o item mais vendido antes de um furacão é a cerveja De posse dessa informação os gerentes passaram a colocar o doce logo na entrada da loja ao lado dos equipamentos para emergências quando havia um aviso meteorológico de furacão 5 REFERÊNCIAS CEZAR T Big Data Rio de Janeiro Brasport 2013 HAYS C L What WalMart knows about customers habits The New York Times 14 nov 2004 Disponível em httpswwwnytimescom20041114businessyourmoneywhatwalmartknowsaboutcustomershabitshtml Acesso em 11 jun 2021 MACHADO F N R Big Data o futuro dos dados e aplicações São Paulo Erica 2018 MAYER V CUKIER S K Big Data como extrair volume variedade velocidade e valor da avalanche de informação cotidiana São Paulo Campos 2013 SAHI A Big Data Analytics disruptive technologies for changing the game Idaho MC Press 2012 Anterior 4 CASO DE SUCESSO NO USO DE BIG DATA AULA 6 Ele explica HADOP