Projecto Final de Licenciatura Engenharia Informática - Computadores e Sistemas. elaborado por: Filipe Manuel Marques Pinto Pinheiro

Tamanho: px
Começar a partir da página:

Download "Projecto Final de Licenciatura Engenharia Informática - Computadores e Sistemas. elaborado por: Filipe Manuel Marques Pinto Pinheiro"

Transcrição

1 OLAP (ONLINE ANALYTICAL PROCESSING) Projecto Final de Licenciatura Engenharia Informática - Computadores e Sistemas elaborado por: Filipe Manuel Marques Pinto Pinheiro orientado por: Engº Paulo Alexandre Duarte Ferreira Instituto Politécnico do Porto Instituto Superior de Engenharia do Porto Departamento de Engenharia Informática Julho de 2001

2 Índice ÍNDICE ÍNDICE... 2 ÍNDICE DE FIGURAS... 5 AGRADECIMENTOS... 6 INTRODUÇÃO... 8 DATA WAREHOUSE INTRODUÇÃO FLUXO DE INFORMAÇÃO INFORMAÇÃO OPERACIONAL INFORMAÇÃO ANALÍTICA CONCEITO DE DATA WAREHOUSE PORQUÊ CONSTRUIR UM DATA WAREHOUSE? CRIAÇÃO DE UM DATA WAREHOUSE CONSTRUÇÃO DE UM SISTEMA DE SUPORTE À DECISÃO OBJECTIVOS DE UM SISTEMA DE SUPORTE À DECISÃO PLANEAMENTO DE UM SISTEMA DE SUPORTE À DECISÃO OLAP - ONLINE ANALYTICAL PROCESSING INTRODUÇÃO PERSPECTIVA HISTÓRICA DIFERENÇAS ENTRE SISTEMAS OLAP E OLTP SISTEMAS OLTP SISTEMAS OLAP TRANSFORMAÇÃO DE DADOS OLTP EM DADOS OLAP JUNÇÃO DE DADOS ELIMINAÇÃO DE DADOS AGREGAÇÃO DE DADOS ORGANIZAÇÃO DE DADOS EM CUBOS ETAPAS PARA TRANSFORMAÇÃO DOS DADOS MANUTENÇÃO DE DADOS OLAP MUDANÇAS NO DATA WAREHOUSE ADIÇÃO DE DADOS ALTERAÇÃO DE DADOS MUDANÇA NA ESTRUTURA SINCRONIZAÇÃO DE DADOS ENTRE O DATA WAREHOUSE E O OLAP ESTRUTURA DE DADOS NORMALIZADA VS. NÃO NORMALIZADA ANÁLISE DE DADOS NUM SISTEMA RELACIONAL NORMALIZADO ANÁLISE DE DADOS USANDO DIMENSÕES E FACTOS FACT TABLE...33 ii

3 Índice 9.2 INFORMATIONAL TABLES ESQUEMAS DE ESTRUTURAÇÃO DE DADOS Esquema Star Esquema Snowflake Principais diferenças DIMENSÕES ASSOCIADAS ÀS INFORMATIONAL TABLES Dimensões de estrutura Dimensões de informação Informational tables construídas a partir de dimensões de partição Dimensões de categoria CUBOS AGREGAÇÕES Explosão de dados Relação entre a granularidade e a explosão dos dados ROLAP, MOLAP E HOLAP ROLAP MOLAP MOLAP vs. ROLAP HOLAP PARTIÇÕES ESTRUTURA CUBOS VIRTUAIS ROLES DTS DATA TRANSFORMATION SERVICES INTRODUÇÃO FUNCIONALIDADES DO DTS EXTRACÇÃO TRANSFORMAÇÃO CARREGAMENTO PACKAGES CONEXÃO TAREFA PASSO Constantes de precedência Uso de múltiplas constantes de precedência...69 MDX MULTIDIMENSIONAL EXTENSIONS INTRODUÇÃO UTILIZAÇÃO DE MDX NUM DATA WAREHOUSE DESENHO DO DATA WAREHOUSE MDX E OS SERVIÇOS OLAP INSTRUÇÕES MDX OS CINCO ELEMENTOS DE UMA INSTRUÇÃO MDX Filipe Pinheiro iii

4 Índice Números Strings Membros Tuplos Conjuntos ESTRUTURA BÁSICA DE UMA INSTRUÇÃO MDX EXEMPLOS DE INSTRUCÇÕES EXEMPLO PRÁTICO CONCLUSÃO BIBLIOGRAFIA BIBLIOGRAFIA Filipe Pinheiro iv

5 Índice de figuras ÍNDICE DE FIGURAS Figura 1 - Sistema de suporte à decisão Figura 2 - Data Warehousing e OLAP Figura 3 - Etapas de transformação e componentes de um Data Warehouse Figura 4 - Esquema star Figura 5 - Representação de uma dimensão Figura 6 - Informational table de um esquema star Figura 7 - Esquema snowflake Figura 8 - Modelo ER de uma dimensão geográfica Figura 9 - Hierarquia relacional dos dados Figura 10 - Exemplo de um cubo Figura 11 - Representação dos valores numa hierarquia Figura 12 - Opções de agregação com performance=50% Figura 13 - Opções de agregação com performance=100% Figura 14 - Opções de agregação com espaço de armazenamento máximo=300 Mb Figura 15 - Esquema de armazenamento ROLAP Figura 16 - Esquema de armazenamento MOLAP Figura 17 - Esquema de armazenamento HOLAP Figura 18 - Criação de um cubo virtual Figura 19 - Solução construída com base em cubos virtuais Figura 20 - Transferência de dados para um Data Warehouse Figura 21 - Objectos de um package Figura 22 - Precedências de execução Figura 23 - Múltiplas constantes de precedência Figura 24 - Modelo de dados em Access Figura 25 - Query Vendas Figura 26 - Query Zonas Figura 27 - Query Produtos_Vendidos Figura 28 - Novo modelo de dados em SQL Figura 29 - Estrutura do Cubo Figura 30 - MDX - Total de vendas por cliente Figura 31 - Vista resultante do Exemplo Figura 32 - MDX - Total de vendas por zona e produto Figura 33 - Vista resultante do Exemplo Figura 34 - MDX - Total de vendas por zona e produto, segundo um vendedor Figura 35 - Vista resultante do Exemplo Figura 36 - MDX - Criação de um calculated member Figura 37 - Vista resultante do Exemplo v

6 AGRADECIMENTOS

7 Agradecimentos Desejo agradecer ao Engº Paulo Alexandre Duarte Ferreira por todo o apoio prestado, quer sob a forma de comentários a este trabalho através da leitura cuidada de todas as suas versões preliminares, ou através da indicação de bibliografia útil para o desenvolvimento deste trabalho. Quero também agradecer à Vânia por todo o apoio que me deu e paciência demonstrada ao longo destes meses, sem a qual eu não conseguiria certamente levar a cabo este trabalho. Por fim, e como não podia deixar de ser, desejo agradecer aos meus pais todo o apoio que me deram não só nesta fase final, como também ao longo de todos estes anos que fui estudante do Departamento de Engenharia Informática do Instituto Superior de Engenharia do Porto. A todos, o meu muito obrigado. Filipe Pinheiro vii

8 INTRODUÇÃO

9 Introdução A tecnologia OLAP é inovadora, não estando ainda generalizada nas organizações que trabalham com grandes quantidades de informação relacionada com a sua área de negócios. Um sistema OLAP é uma ferramenta que auxilia as organizações no seu processo de gestão da informação disponível, por forma a garantir o seu sucesso e prevenir potenciais falhas. Esta tecnologia está associada ao conceito de Data Warehouse que será abordado neste relatório, assim como os conceitos mais importantes relacionados. Associada a esta tecnologia existem outros conceitos que convém explicar, dado que auxiliam o processo de transformação e análise da informação pretendida, de onde se destacam: DTS Data Transformation Services MDX Multidimensional Extensions Para melhor compreender como e onde esta tecnologia pode ser utilizada, serão apresentados alguns exemplos práticos dos vários conceitos abordados. No fim será apresentado um pequeno exemplo prático que engloba todos os exemplo focados anteriormente, e que pretende demonstrar o processo de criação de um cubo, por forma a podermos analisar os dados de um sistema OLAP. Filipe Pinheiro 9 de 90

10 DATA WAREHOUSE

11 Data Warehouse 1 INTRODUÇÃO Nos dias que correm, a gestão da informação nas organizações constitui um dos aspectos mais relevantes para a tomada de decisões que influenciam o seu desempenho a médio e longo prazo. Para alcançar uma gestão eficiente dessa informação, é necessário organizá-la e estruturála de forma a que seja precisa e consistente para permitir uma análise eficiente ao longo do tempo. Na maior parte dos casos, a informação existente não está acessível, devido à falta de meios técnicos para o efeito, ou recursos humanos qualificados para o fazer, o que torna o processo de gestão lento e pouco eficiente. Quando a informação tem origem em fontes de dados diferentes (Aplicações externas, Bases de dados, ficheiros de texto, etc.), este processo torna-se ainda mais complicado. As decisões tomadas com base em informação insuficiente, podem muitas vezes ser prejudiciais para o sucesso das organizações face à pressão constante em mercados muito competitivos e em constante evolução. O sistema ideal deveria permitir o acesso fácil à informação por parte de utilizadores não especializados, em qualquer período de tempo. Para isso, é necessário organizar e estruturar a informação, recorrendo a tecnologias de suporte à decisão. Por vezes, o problema não reside na pouca informação existente, mas sim no seu excesso, exigindo uma correcta filtragem do que é essencial. Uma solução para estas situações consiste na criação de um Data Warehouse com a informação existente e a disponibilização de soluções para acesso rápido e simples como forma de análise e suporte à decisão. 2 FLUXO DE INFORMAÇÃO Para garantir o sucesso de uma organização, é necessário ter a informação correcta no momento certo de forma a que seja possível tomar decisões acertadas e implementá-las na altura devida. As constantes trocas de informação recorrendo a variadas tecnologias, sistemas operativos e diferentes tipos de armazenamento de dados, exigem um formato uniforme e consistente, o que requer um planeamento cuidado e um conjunto de aplicações e infra-estruturas de forma a obter uma performance elevada. Filipe Pinheiro 11 de 90

12 Data Warehouse Existem dois tipos de informação essenciais para o suporte à decisão: Informação Operacional; Informação Analítica. 2.1 Informação Operacional A informação operacional é constantemente actualizada e modificada, ou seja, é dinâmica. Um exemplo disso, consiste na informação de entrada de encomendas numa base de dados. A informação operacional representa a informação corrente numa determinada altura como por exemplo, o estado de uma encomenda pendente, os níveis do stock, etc. Este tipo de informação diz-nos o estado corrente de algo, e pode ser alterada a qualquer momento. 2.2 Informação Analítica A informação analítica, por outro lado, consiste numa informação histórica e normalmente permanece inalterada a partir de uma determinada altura, ou seja é estática. Esta informação deve apenas ser alterada se existir um erro na sua forma original. Por exemplo, ao fim de um certo tempo, uma venda torna-se final e não é reversível. Nesta altura, esta informação torna-se estática e pode ser transferida da fonte de dados dinâmica para uma fonte de dados estática. A informação analítica é utilizada para uma verificação periódica, como por exemplo, para verificar o total de vendas em Janeiro, a quantidade de um produto vendido num determinado dia, ou a variação dos salários dos funcionários nos últimos seis meses. Geralmente, a sua construção é efectuada a partir de informação operacional e é utilizada para efectuar uma análise exaustiva sobre a informação de uma organização num período de tempo. Esta informação deve ser precisa, acessível, e apresentada numa estrutura flexível. A informação analítica nem sempre vem do interior de uma empresa, podendo também ser oriunda de fontes externas e em grandes quantidades, e pode ser disponibilizada, por exemplo, através da Internet a um preço estabelecido. Num Data Warehouse, a informação passa por um processo de verificação da integridade dos dados, é transformada num formato único e armazenada num servidor OLAP (Online Analytical Processing) para fácil acesso. Filipe Pinheiro 12 de 90

13 Data Warehouse 3 CONCEITO DE DATA WAREHOUSE As ferramentas OLAP efectuam análises complexas à informação analítica, recorrendo a uma estrutura de dados especial denominada Estrutura Multidimensional. Estas estruturas são armazenadas numa base de dados específica chamada Data Warehouse. Um Data Warehouse é um armazém de dados que contém a informação recolhida durante a actividade de um negócio num determinado período de tempo. Um Data Warehouse construído correctamente disponibiliza informação histórica consistente para toda a organização. As organizações recolhem informação no decurso normal da sua actividade. A finalidade de um Data Warehouse é de consolidar e organizar os dados de forma a que possam ser analisados e usados para auxiliar a tomada de decisões de negócio. Em muitos casos, o Data Warehouse contém a história viva de uma organização. Um Data Warehouse, normalmente contém dados históricos, recolhidos de uma forma variada, desde sistemas OLAP, ficheiros de texto, folhas de cálculo, etc. O Data Warehouse combina estes dados, verifica a sua consistência e precisão, e organiza-os de forma a tornar os queries mais eficientes e fáceis de executar. Algumas definições de Data Warehouse incluem vários elementos tais como: Área de preparação de dados; Processos de verificação; Base de dados que contém os dados do Data Warehouse; Ferramentas que organizam e apresentam os dados às aplicações cliente. Outras definições restringem o Data Warehouse a uma base de dados. Em grandes aplicações Data Warehouse, os dados são normalmente segmentados em componentes específicos, denominados Data Marts. Algumas definições consideram que os Data Marts fazem parte do Data Warehouse; outras, consideram-nos como entidades separadas. É possível verificar que, depois de construir um Data Warehouse, muitas pessoas na organização apenas acedem a determinadas porções da informação. Desta forma, e estando o Data Warehouse segmentado, não é necessário efectuar inquéritos a todo o armazém, quando se pretende apenas uma parte. Neste caso, os inquéritos são apenas dirigidos aos Data Marts, acelerando os tempos de resposta. Filipe Pinheiro 13 de 90

14 Data Warehouse 4 PORQUÊ CONSTRUIR UM DATA WAREHOUSE? Um Data Warehouse armazena dados estáveis e válidos. Comparando um Data Warehouse com uma base de dados transaccional obtemos as seguintes diferenças: Uma base de dados transaccional auxilia a execução de tarefas e actividades, enquanto que um Data Warehouse ajuda a tomada de decisões. Por exemplo, uma base de dados transaccional pode mostrar que lugares estão disponíveis num voo de modo a que um agente de viagens possa efectuar reservas. Um Data Warehouse, por outro lado, pode mostrar o padrão histórico de lugares vazios por voo de modo a que o gerente da companhia aérea possa decidir se deve ajustar os horários dos voos no futuro; Uma base de dados transaccional é volátil, ou seja, a informação é modificada constantemente conforme as ordens que são dadas ou canceladas, novos produtos são construídos ou eliminados, ou são efectuadas novas reservas. Uma Data Warehouse é estável, ou seja, a sua informação é actualizada periodicamente (anualmente, mensalmente, semanalmente, etc.). O ideal seria que as actualizações apenas acrescentassem novos valores desse período, sem alterar valores previamente armazenados; Uma base de dados transaccional centraliza-se nos detalhes: um agente de viagens ao efectuar uma reserva num voo não necessita de saber a média de lugares vazios. Um Data Warehouse centraliza-se em agregações de alto nível: o gerente ao actualizar os horários dos voos não necessita de saber especificamente quais os lugares vazios, mas sim, ter uma visualização geral da situação. Isto implica que os valores chave num Data Warehouse devem ser numéricos e devem poder ser sumariados; Uma base de dados transaccional providencia toda a informação que é posteriormente armazenada num Data Warehouse. Filipe Pinheiro 14 de 90

15 Data Warehouse 5 CRIAÇÃO DE UM DATA WAREHOUSE Um Data Warehouse utiliza os sistemas OLTP para recolher os dados das transacções diárias do negócio e existem processos de transformação destes dados, que os preparam para um formato estabelecido no Data Warehouse. Finalmente, existem ferramentas que permitem analisar esta informação, como por exemplo uma ferramenta OLAP. Um armazém de informação deste tipo é, normalmente, construído para permitir o suporte às decisões e análise online, possuindo as seguintes características: Contém dados históricos: um Data Warehouse representa dados históricos, ou seja, informação analítica de longos períodos de tempo que descrevem o sistema; Dados read-only: depois dos dados serem transferidos para um data Warehouse, não é possível alterá-los, a não ser que estivessem errados desde o início. Estes dados não são actualizados, alterados ou eliminados, porque representam informação histórica acerca do negócio. As únicas operações possíveis são a adição de novos dados e a realização de inquéritos. Ralph Kimball, defensor da filosofia de Data Warehousing, define um Data Warehouse como sendo simplesmente o local onde as pessoas podem aceder aos seus dados. Ele aponta seis requerimentos fundamentais para um Data Warehouse: 1. O acesso aos dados deve ser rápido; 2. Os dados devem ser sólidos e consistentes: os dados são recolhidos de diferentes fontes, são tratados e tornados consistentes, eliminando redundâncias e utilizando normas estabelecidas para o seu formato; 3. Os utilizadores devem ter a capacidade de extrair e comparar dados; 4. Deve incluir ferramentas de pesquisa fáceis de utilizar; 5. Os dados devem ser fiáveis e precisos; 6. Para que se possa ter dados de qualidade num Data Warehouse, é necessário uma recolha de informação com qualidade. Os serviços de análise (OLAP) desempenham um papel muito importante na estratégia de Data Warehousing de uma organização, mas não satisfazem todas as suas necessidades. De facto, o OLAP por si só, apenas satisfaz dois destes seis requerimentos: ajuda a aceder aos dados Filipe Pinheiro 15 de 90

16 Data Warehouse de uma forma rápida (requerimento 1), e facilita a extracção e comparação dos dados (requerimento 3). O OLAP não providencia directamente ferramentas de pesquisa de informação (requerimento 4) e os três requerimentos restantes que dizem respeito à transformação dos dados de um Data Warehouse tornando-os consistentes, fiáveis e precisos devem ser executados antes de se utilizar esta tecnologia. Por outras palavras, o OLAP assume que já temos um Data Warehouse válido e funcional criado usando bases de dados relacionais e um SGBD como por exemplo o SQL Server. O OLAP cria uma nova camada no cimo de um Data Warehouse relacional já existente, com o objectivo de tornar o acesso aos dados muito rápido e flexível (dois dos requerimentos de Kimball). 6 CONSTRUÇÃO DE UM SISTEMA DE SUPORTE À DECISÃO Fontes de dados Aplicação Servidor BD Ficheiro de texto Informação Operacional DTS Aplicação OLAP Informação Analítica Data Warehouse Servidor OLAP Figura 1 - Sistema de suporte à decisão Quando falamos de um sistema de suporte à decisão, a base de dados analítica é apenas uma parte de um grande sistema. Este sistema inclui ferramentas para armazenar e gerir cubos multidimensionais (OLAP Server e OLAP Manager), ferramentas para apresentar os dados Filipe Pinheiro 16 de 90

17 Data Warehouse (Pivot Table Services, Excel, Visual Basic, etc.) e ferramentas para transformar os dados, se necessário (DTS). 6.1 Objectivos de um sistema de suporte à decisão Profundidade da informação: Um sistema de suporte à decisão deve permitir aos utilizadores uma visualização da informação desde os níveis mais altos aos mais baixos. Assim, o utilizador pode comparar informação de níveis mais elevados com níveis inferiores conforme as suas necessidades; Comparar informação: As comparações mencionadas no parágrafo anterior, constituem uma funcionalidade essencial num sistema de suporte à decisão: A capacidade de comparar conjuntos de informação. Por exemplo, uma das comparações mais comuns consiste no volume de vendas num determinado período comparada com outro período. Um bom sistema de suporte à decisão deve proporcionar facilidade na execução deste tipo de comparações; Informação útil: Ser capaz de extrair grandes quantidades de informação é inútil se esta não for precisa e aplicável aos problemas de negócio que necessitam de resolução. Para além disso, os sistemas devem ser construídos por forma a validar a informação suficiente que permita ao utilizador efectuar as decisões que beneficiem a organização; Disponibilidade da informação: Não é recomendável ter um sistema que demore dias ou semanas para mover a informação para a base de dados analítica, quando é necessário disponibilizá-la em algumas horas. Se a informação é correcta e pertinente, mas chega demasiado tarde à organização, torna-se inútil; Análise rápida: Para satisfazer as necessidades dos utilizadores, cada query deve ser efectuado rapidamente, de forma a que um utilizador possa efectuar vários queries num curto espaço de tempo; Informação acessível: A informação deve ser apresentada num linguagem perceptível no âmbito do negócio, e não numa linguagem específica de sistemas analíticos. O interface deve permitir aos utilizadores uma boa interacção através uma linguagem e termos que lhe sejam familiares. Uma sistema construído desta forma providencia informação útil e detalhada para a maior parte dos processos de negócio de uma organização. Filipe Pinheiro 17 de 90

18 Data Warehouse 6.2 Planeamento de um sistema de suporte à decisão Para construir um sistema de suporte à decisão, é necessário um planeamento cuidado e compreender as diferentes opções disponíveis. Um dos assuntos mais difíceis consiste em integrar os dados de um número variável de fontes de dados. Alguma desta informação pode estar disponível num formato pouco usual e que requer uma manipulação intensiva para ser utilizável no Data Warehouse. Através de uma análise cuidada da organização, um planeamento detalhado e uma análise de risco, é possível identificar estes problemas e criar planos para os resolver. Filipe Pinheiro 18 de 90

19 OLAP - ONLINE ANALYTICAL PROCESSING

20 OLAP 1 INTRODUÇÃO Apesar de algumas vezes serem usados em conjunto, os termos Data Warehousing e OLAP, aplicam-se a componentes diferentes de um sistema muitas vezes denominado de Sistema de Suporte à Decisão. Estes sistemas são constituídos por bases de dados e aplicações que providenciam as ferramentas de análise necessárias às tarefas de tomada de decisão nas organizações. Um Data Warehouse é uma base de dados que contém informação que normalmente representa a área de negócio e a história de negócio de uma organização. Estes dados históricos são usados para análise e mais tarde irão auxiliar na tomada de decisões a muitos níveis, desde o planeamento estratégico, até à avaliação de performance da organização. A informação contida num Data Warehouse está organizada para suportar análise, em vez de processamento de transacções em tempo real, tal como acontece em sistemas OLTP. A tecnologia OLAP possibilita que a informação de um Data Warehouse possa ser usada de uma forma eficiente para análise online, permitindo rápidos tempos de resposta a queries analíticos iterativos e personalizáveis. O modelo de dados multidimensional do OLAP em conjunto com as técnicas de agregação organizam e sumariam grandes quantidades de dados de forma a que possam ser avaliados rapidamente usando ferramentas de análise online e ferramentas gráficas. A resposta a um query executado em dados históricos, geralmente leva a que sejam executados queries sucessivos enquanto decorre o processo de procura da resposta ou então enquanto se exploram todas as possibilidades de resposta. Os sistemas OLAP tornam possível a análise a este tipos de dados em tempo real, através da sua velocidade e flexibilidade. Dados Operacionais ETL* OLAP Utilizadores Data Warehouse *ETL - Extraction (Extracção); Transformation (Transformação); Loading (Carregamento) Figura 2 - Data Warehousing e OLAP Filipe Pinheiro 20 de 90

21 OLAP Um sistema OLAP consiste numa ferramenta que ajuda as empresas no seu processo de gestão da informação disponível, por forma a garantir o seu sucesso e prevenir potenciais falhas. As seguintes afirmações descrevem um sistema OLAP: Os sistemas OLAP são ferramentas utilizadas para analisar a informação de um negócio; Um sistema OLAP pode ser utilizado por analistas, gestores ou executivos para aprofundarem o seu conhecimento acerca do funcionamento da empresa num determinado período de tempo, ou utilizadores externos que buscam uma fonte de informação fiável, flexível e de acesso rápido, disponibilizada por uma empresa; Uma ferramenta OLAP é rápida, consistente e interactiva que permite uma visualização alargada da informação pretendida. 2 PERSPECTIVA HISTÓRICA Em 1980, E. F. Codd revelou o termo Online Transaction Processing (OLTP) e propôs doze critérios para definir uma base de dados OLTP. A sua terminologia e critérios tornaram-se mundialmente aceites como standard para bases de dados utilizadas para gerir operações do diaa-dia (transacções) de uma organização. Em 1990 Codd apareceu com o termo Online Analytical Processing (OLAP) e propôs de novo doze critérios que definiam uma base de dados OLAP. Desta vez, os seus critérios não usufruíram de uma aceitação global, mas o termo OLAP subsistiu, parecendo perfeito para muitos como forma de descrever bases de dados destinadas a facilitar o suporte à decisão de uma organização. Algumas pessoas usam o termo OLAP simplesmente como um acrónimo para Data Warehousing. Normalmente, contudo, o termo OLAP descreve ferramentas especializadas que tornam os dados de um Data Warehouse facilmente acessíveis. Filipe Pinheiro 21 de 90

22 OLAP 3 DIFERENÇAS ENTRE SISTEMAS OLAP E OLTP 3.1 Sistemas OLTP Os dados num sistema OLTP estão organizados de forma a suportar, na sua maioria, transacções que são executadas rapidamente e acedem a pedaços de informação relativamente pequenos. Os sistemas OLTP são destinados e estão afinados para processar centenas ou milhares de transacções ao mesmo tempo. Apesar dos sistemas OLTP serem melhores na tarefa de armazenar os dados necessários para suportar as operações diárias, os dados não estão organizados de forma a disponibilizar a informação necessária aos gestores para planear o trabalho da sua organização de uma forma rápida e simples. Os gestores necessitam de informação sumariada através da qual possam analisar factores que afectem a sua organização ou equipa; têm de encontrar os factores críticos para o sucesso e analisar a melhor forma de ajustar esses factores para aumentar o sucesso da organização. 3.2 Sistemas OLAP Os sistemas OLAP têm a finalidade de executar queries para pesquisar informação necessária para descobrir factores críticos para o sucesso dentro de uma organização. Estes queries normalmente requerem grandes quantidades de dados. Acontece que muitas organizações não possuem apenas um sistema OLTP que guarda toda a informação. Muitas das grandes organizações têm múltiplos sistemas OLTP, muitos dos quais foram desenvolvidos em alturas diferentes e usam diferentes tipos d software e/ou hardware. Em muitos casos, as nomenclaturas e códigos mudam de sistema para sistema. Os gestores que executam queries OLAP geralmente necessitam de referenciar a informação de vários destes sistemas OLTP. Os dados OLAP estão organizados em cubos multidimensionais. Esta estrutura proporciona um aumento de performance aos queries, em relação aos dados organizados em tabelas relacionais. A unidade básica de um cubo multidimensional é denominada measure (unidade dos dados que estão a ser analisados). As measures estão organizadas em dimensões. Os sistemas OLAP são muito diferentes dos sistemas OLTP (Online Transaction Processing). Filipe Pinheiro 22 de 90

23 OLAP As principais características de cada um são resumidas no esquema seguinte: OLTP OLAP Entrada de dados em tempo real Leitura e análise de dados históricos Objectivo Actualização Sim Não Edição Sim Não Fonte dos dados Entrada de dados Dados históricos OLTP Base de dados associada Operacional Analítica, pode ser operacional Uma das principais diferenças entre os sistemas OLAP e OLTP é que os sistemas OLTP têm um conjunto bem definido de queries que o utilizador pode executar, enquanto que num sistema OLAP tal não acontece. Num sistema OLTP, todos os queries que o sistema pode executar (listar todos os clientes, todos os fornecedores, etc.) são predefinidos. Com um sistema OLTP podemos optimizar os queries para obter o máximo de performance por parte do sistema. Quando estamos perante um sistema OLAP, sabemos qual o tipo de informação o utilizador deseja analisar, mas não sabemos exactamente quais os queries que o utilizador irá efectuar. Assim, os queries são executados e optimizados pelo sistema no momento em que são requeridos, conforme as necessidades do utilizador. 4 TRANSFORMAÇÃO DE DADOS OLTP EM DADOS OLAP É necessário transformar o dados OLTP em dados OLAP, de forma a que se proporcione uma performance aceitável em sistemas OLAP. Os processos necessários são apresentados de seguida. 4.1 Junção de dados É necessário que seja possível juntar todos os dados relacionados de múltiplos sistemas OLTP num único sistema OLAP. O processo de junção deve resolver diferenças de codificação entre diferentes sistemas OLTP. Por exemplo, um sistema pode atribuir um ID a cada empregado, e outro sistema pode nem ter ID para cada empregado. O processo de junção deve ser capaz de identificar dados de empregados dos dois sistemas, talvez através da comparação de nomes e moradas nos dois sistemas. Este processo deve também ser capaz de converter dados armazenados usando diferentes tipos de dados em cada sistema para um único tipo de dados utilizado no sistema OLAP. É necessário também seleccionar quais as colunas de cada sistema Filipe Pinheiro 23 de 90

24 OLAP que não são relevantes para o sistema OLAP e então, excluir estas colunas do processo de junção de dados. 4.2 Eliminação de dados O processo de junção de dados OLTP para um Data Warehouse dá-nos a possibilidade de remover dados irrelevantes ou redundantes. Podemo-nos deparar, por exemplo, com sistemas OLTP que dão nomes diferentes para um mesmo item; tal pode ser descoberto pelo processo de junção de dados. Podemos ainda encontrar outras inconsistências, tais como diferentes moradas para a mesma loja, empregado ou cliente. Estas inconsistências têm e devem ser eliminadas antes dos dados poderem ser transferidos para o Data Warehouse para serem usados pelos sistemas OLAP. 4.3 Agregação de dados Os dados OLTP guardam todos os detalhes das transacções. Geralmente, os queries OLAP necessitam apenas de dados sumariados, ou dados agregados de alguma forma. Analisemos o query seguinte: cálculo dos totais de vendas mensais para cada produto durante o ano 2000; este query é executado muito mais rapidamente se a base de dados tiver apenas colunas com dados sumariados das vendas diárias de cada produto, do que se o query tiver de procurar em cada detalhe de transacção do ano 2000, para cada produto, e calcular daí o total de vendas. O detalhe com que se agregam os dados no Data Warehouse depende de muitos factores, tais como a necessidade de performance elevada dos queries OLAP e o nível de granularidade necessário para a análise dos dados. Por exemplo, se agregarmos detalhes de vendas em sumários por dia em vez de sumários por hora, os queries serão executados mais rapidamente. No entanto, esta solução teria interesse se nunca precisássemos de analisar as vendas com base horária, caso contrário seria impossível alcançar este nível de granularidade, com base nessas agregações. 4.4 Organização de dados em cubos Os dados relacionais OLTP estão organizados de uma forma que torna alguns processos de análise difíceis e muito morosos. Implica que quando os dados OLTP são movidos para um Data Filipe Pinheiro 24 de 90

25 OLAP Warehouse, devem ser reorganizados de forma a suportar eficientemente a análise e o suporte à decisão. O processo de construção de um Data Warehouse envolve a reorganização dos dados OLTP armazenados em tabelas relacionais, para dados OLAP armazenados em Cubos Multidimensionais. 5 ETAPAS PARA TRANSFORMAÇÃO DOS DADOS Normalmente, o processo que torna os dados disponíveis através de aplicações OLAP percorre as seguintes etapas: 1. Extracção de dados de fontes OLTP para uma área temporária; 2. Transformação dos dados num formato utilizável num sistema OLAP. Esta etapa envolve processos de eliminação e agregação de dados; 3. Carregar estes dados para um Data Warehouse ou Data Mart. O processo de extracção dos dados de fontes OLTP e a sua transformação para os servidores do Data Warehouse é denominado por ETL (Extraction; Transformation; Loading), e é executado com períodos fixos. Uma vez carregados os dados no Data Warehouse, é fundamental que o sistema OLAP possibilite o acesso aos dados para que se possa analisá-los. A figura seguinte representa as categorias dos componentes de um sistema OLAP que tornam estes serviços possíveis. Fontes de dados Armazém de dados intermédio Servidores Data Warehouse Informação de Negócio Data Warehouse Ferramentas de Inquérito Armazém de dados operacionais Relatórios Data Mart Área temporárea de armazenamento Data Mart Aplicações Analíticas Data Mining Meta Dados Figura 3 - Etapas de transformação e componentes de um Data Warehouse Filipe Pinheiro 25 de 90

26 OLAP Fontes de dados: A informação contida em bases de dados OLTP ou outras fontes, tem que ser transformada em informação OLAP para poder ser transferida para o Data Warehouse ou para o Data Mart; Armazém de dados intermédio: Área de armazenamento de dados que processa, analisa e transforma os dados OLTP em dados utilizáveis pelo sistema OLAP; Servidores Data Warehouse: São os computadores que possuem bases de dados relacionais que contêm os dados para os Data Warehouses e Data Marts, e servidores que gerem os dados OLAP; Informação de negócio: O conjunto de ferramentas e aplicações que executam inquéritos aos dados OLAP e disponibilizam relatórios e informação às pessoas encarregues de tomar decisões no seio da organização; Meta Dados: Modela a organização em termos de dados e aplicações dentro dos diferentes componentes OLAP. Os meta dados descrevem objectos tais como tabelas em bases de dados OLTP, cubos em Data Warehouses e Data Marts, etc. Também regista quais as aplicações que referenciam as diferentes partes da informação. 6 MANUTENÇÃO DE DADOS OLAP A finalidade dos sistemas OLAP é proporcionar um rápido acesso analítico aos dados de um Data Warehouse. Para conseguir isto, o OLAP cria cubos multidimensionais a partir de dados presentes nas tabelas de factos e dimensões (fact e dimension tables) de um Data Warehouse. A measures numéricas são também sumariadas em valores pré agregados durante a construção do cubo. Os cubos são armazenados em estruturas multidimensionais com a finalidade de facilitar um tempo de resposta a inquéritos muito rápido, combinando a informação pré agregada com dados crus da tabela de factos (fact table) para responder a uma variedade muito grande de inquéritos. Filipe Pinheiro 26 de 90

27 OLAP Os cubos podem conter dados sumariados, copiados ou lidos directamente do Data Warehouse. As mudanças na estrutura do Data Warehouse ou dos dados lá contidos podem afectar a integridade e a precisão dos cubos que foram criados a partir do Data Warehouse. Uma vez que o OLAP providencia acesso contínuo aos cubos, quando se efectuam mudanças no Data Warehouse é necessários que se esteja ciente das implicações que isso poderá ter nos cubos. Deverá também existir uma preocupação com a sincronização dos dados do Data Warehouse e dos cubos. Os dados OLAP têm de ser actualizados assim que se verifique uma mudança nos dados do Data Warehouse. É necessário processar os cubos, dimensões e partições para incorporar os novos dados ou os dados alterados do Data Warehouse. O método para processamento de um objecto OLAP depende do próprio objecto e do tipo de operação efectuada no Data Warehouse, podendo ser de adição de dados, alteração de dados ou mudança na sua estrutura. O OLAP em tempo real é uma característica que usa cubos em tempo real para sincronizar automaticamente os dados dos cubos com mudanças na base de dados relacional à qual está ligado. Este tipo de cubos pode ser usado em aplicações que necessitem de monitorizar e analisar dados em tempo real; não tendo como finalidade substituir os cubos tradicionais e aplicações, mas sim aumentar as capacidades do OLAP. 6.1 Mudanças no Data Warehouse Os dados são normalmente adicionados periodicamente ao Data Warehouse de forma a que este possa reflectir a informação mais recente possível acerca das actividades de negócio da organização. As mudanças nos dados que já estão no Data Warehouse são menos frequentes e normalmente ocorrem só para se efectuarem correcções em erros posteriormente descobertos pela fonte através da qual foram transferidos, ou para reestruturar a informação devido a mudanças na estrutura da organização. As mudanças na estrutura do Data Warehouse são as menos frequentes. 6.2 Adição de dados É comum adicionar novos dados ao Data Warehouse. A informação do cubo, que está disponível online às aplicações dos clientes, pode ser afectada quando são adicionados dados ao Data Warehouse, devido à interacção entre os dados e as partições do cubo. Podem-se gerir os Filipe Pinheiro 27 de 90

28 OLAP efeitos da adição de dados, através da criação de filtros de partições ou através da criação de estratégias de sincronização de dados entre o OLAP e o Data Warehouse. 6.3 Alteração de dados As mudanças num Data Warehouse apenas para correcção de erros podem ser minimizadas se as operações de transformação, validação e eliminação dos dados forem executadas com o máximo de atenção. Outras mudanças nos dados existentes no Data Warehouse podem ser resultantes da alteração da estrutura da organização ou dos seus produtos. Por exemplo, a reorganização de produtos em diferentes categorias pode necessitar de mudanças significativas nos dados do Data Warehouse, assim como em relatório derivados do Data Warehouse. Em alguns casos, tais mudanças, podem obrigar a uma completo reestruturação dos cubos. Noutro casos, pode obrigar a reestruturar dimensões, e neste caso basta apenas processar de novo os cubos que usem tais dimensões para que tudo fique actualizado. As alterações para correcção de erros em dados básicos, devem ser incorporadas na base de dados origem (normalmente uma base de dados de um sistema OLTP) e só depois podem migrar para o Data Warehouse de uma forma controlada. Muitas vezes é necessário aplicar mudanças à estrutura de algumas bases de dados OLTP, através do uso de uma transacção que exclui os dados incorrectos e introduz novos dados. É mais fácil gerir o impacto dessas transacções para correcção de dados em dados OLAP. Os cubos podem incorporar novas transacções de dados para corrigir erros em valores. Contudo, as transacções que movem um membro de uma dimensão para outra, podem afectar os resultados das funções de agregação tal como a função Avg. Por exemplo, se o valor de uma venda é colocado a erro mas o registo não é eliminado, este registo será incluído na contagem de vendas e afectará o resultado dos cálculos. Isto também é verdade para bases de dados não OLAP. Dependendo da estrutura de armazenamento do cubo, as alterações nos dados da tabela de factos (fact table) podem afectar a precisão dos queries a um cubo, até que o cubo seja de novo processado. As hierarquias de dimensões podem ser afectadas por mudanças nos dados das tabelas de dimensões do Data Warehouse apesar do esquema da tabela permanecer inalterado. A hierarquia de dimensões é baseado em relações entre membros numa tabela de dimensões. Quando estas relações são alteradas (por exemplo, quando cidades são reorganizadas em diferentes regiões de vendas), a estrutura da dimensão tem que ser reconstruída. Filipe Pinheiro 28 de 90

29 OLAP A integridade referencial deve ser mantida quando são adicionados, alterados ou eliminados dados do Data Warehouse. A perda da integridade referencial pode resultar em erros durante o processamento do cubo, registos que são esquecidos ou informação OLAP imprecisa. 6.4 Mudança na estrutura A estrutura dos cubos OLAP e as dimensões podem ser afectadas por alterações na estrutura do Data Warehouse tais como adição, eliminação ou alteração de tabelas ou de relações entre tabelas. Quando a estrutura altera, deve-se modificar a estrutura dos cubos e dimensões afectadas, redefinir as partições e agregações e processar completamente os cubos e dimensões modificadas. 6.5 Sincronização de dados entre o Data Warehouse e o OLAP Os cubos válidos estão online e disponíveis para as aplicações dos clientes quando o servidor OLAP está a correr. Devido à interacção entre as partições do cubo OLAP e os dados do Data Warehouse, a estrutura do Data Warehouse deve incluir uma estratégia de sincronização para permitir a adição de dados, sem que fazer com que os cubos que estão online devolvam informação errada. Uma estratégia para gerir as adições ao Data Warehouse e aos dados OLAP consiste em criar um sistema de actualizações baseada em processos batch. Neste tipo de estratégia, todos os registos da tabela de factos (fact table) do Data Warehouse incluem um numero batch. Os dados adicionados a uma tabela de dimensões não afectam as dimensões públicas ou partilhadas de um cubo já existentes, até que as dimensões sejam processadas. Um número batch em cada registo de uma tabela de dimensões torna-se desnecessário, mas pode ser útil para garantir a integridade referencial. As dimensões e os cubos ou partições, podem ser processados para incorporar novos dados, após a adição de dados batch à tabela de factos ou dimensões (fact ou dimension table). As dimensões partilhadas devem ser processadas antes dos cubos que as usam. Filipe Pinheiro 29 de 90

30 OLAP 7 ESTRUTURA DE DADOS NORMALIZADA VS. NÃO NORMALIZADA O modelo relacional de desenho é vocacionado para agrupar informação relacionada. É utilizado pelos sistemas OLTP e está provada a sua capacidade de produzir informação consistente. A utilização de bases de dados relacionais permite a um sistema OLTP um funcionamento rápido e eficiente, e que mantém as regras de consistência e flexibilidade da informação. Isto acontece, mesmo com actualizações constantes no sistema. Apesar deste modelo funcionar muito bem num sistema OLTP, o mesmo nem sempre se consegue num sistema OLAP. Como num sistema OLAP a informação deve ser estática e sofrer o mínimo de actualizações possíveis, não se verifica a necessidade de utilizar um modelo relacional, dado que este modelo é utilizado precisamente para tornar o processo de actualização mais eficiente e consistente. É possível utilizar um modelo relacional para estruturar a informação num sistema OLAP de uma forma eficiente, mas não existe essa necessidade. De facto, uma estrutura não normalizada (por completo) aumenta a rapidez do processo de consulta da informação, uma vez que reduz o número de joins necessários para efectuar os inquéritos. Um sistema OLAP apoiado numa base de dados relacional possui uma vantagem: requer menos espaço para o armazenamento. Quando esta necessidade não existe, uma estrutura não normalizada torna o processamento mais rápido e acessível. 8 ANÁLISE DE DADOS NUM SISTEMA RELACIONAL NORMALIZADO Se construirmos um sistema analítico de dados, movendo os dados OLTP para um conjunto separado de tabelas relacionais normalizadas, mas dentro da mesma base de dados operacional, para analisarmos os dados, temos de executar um conjunto de queries SQL que irão incidir sobre essas tabelas. Podemos então chegar a uma situação em que mesmo para executar uma tarefa simples, necessitamos de recorrer a queries relativamente complexos, que se tornam complicadas de analisar, ocupando também muito tempo de processador. Tudo isto faz com que a performance do sistema saia prejudicada, e quando tal acontece, todo o negócio baixa de performance, podendo afectar de uma forma grave todo a organização. A performance pode ser aumentada se criarmos uma cópia dos dados num servidor completamente independente, ou através do uso de um componente separado que corre num segundo servidor, e que é responsável por efectuar todos os cálculos necessários. Através do uso de um segundo servidor, a performance de um sistema OLTP não deverá ser afectada. Filipe Pinheiro 30 de 90

31 OLAP Mas, mesmo com o uso de um segundo servidor, continuamos a ter de executar stored procedures complicadas por cada tipo de análise de dados que o utilizador desejar. Isto significa que, para cada vista que o utilizador tenha dos dados, é necessário escrever queries longos, complicados e específicos. Infelizmente, esta situação não tem remédio, pois num sistema analítico, nunca se pode saber ao certo que tipo de informação é que o utilizador irá desejar, nem o próprio utilizador, muitas vezes sabe que tipo de informação irá necessitar, até ao momento em que ele próprio inicia a procura. Consequentemente, baseando-se apenas em stored procedures como forma de análise da informação, o utilizador tem apenas formas predefinidas de analisar e visualizar informação. Toda esta situação pode ser melhorada através do uso de sistemas OLAP, que trabalham com estruturas de dados relacionais normalizadas. É da responsabilidade do sistema OLAP registar o pedido de informação por parte do utilizador, e consequentemente criar um query eficiente para retornar ao utilizador a informação requerida. Apesar de isto ser um pouco lento, irá permitir tipo de queries analíticos. A velocidade depende dos queries, do tipo de optimização que sofreram e de muitos outro factores. Contudo, o tempo de retorno dos resultados é perfeitamente imprevisível. Esta situação pode ser melhorada, se usarmos uma estrutura de base de dados relacional, multidimensional e não normalizada. 9 ANÁLISE DE DADOS USANDO DIMENSÕES E FACTOS O principal objectivo dos sistemas OLAP é efectuar cálculos e modelar métricas de negócio importantes. Estas métricas são chamadas dimensões. Assim como em matemática e na ciência usamos dimensões de espaço e/ou tempo, dimensões de negócio podem também ser tratadas no tempo e no espaço. No mundo do Data Warehousing, um valor numérico sumariável utilizado para monitorizar um negócio é chamado measure (medida). Quando necessitamos de informação numérica, a primeira questão é: Que measure queremos ver? Alguns exemplos de measures são o volume de vendas de uma empresa, lucros resultantes das vendas, etc. Quando se efectuam análises sobre sistemas OLAP, cada measure é calculada sobre as várias dimensões. Se a measure é total de vendas e as dimensões forem de tempo e geográficas, com tempo igual ao mês de Maio e a geografia igual a Porto, o sistema OLAP calcula o número de vezes que um item foi vendido em Maio na região do Porto. Estes sistemas analisam frequentemente measures sobre várias dimensões, e é por isto que são chamados de multidimensionais. Filipe Pinheiro 31 de 90

32 OLAP Nota Por norma, quando analisamos informação colocamos na seguinte forma: Uma measure por dimensão1, dimensão2,..., dimensão N. Por exemplo, podemos inquirir o seguinte ao sistema OLAP: Quero ver o total de vendas por região e departamento ao longo do tempo. Neste caso, a measure é total de vendas, e as três dimensões são: departamento, região e tempo. Devemos, sempre que possível, induzir os utilizadores do sistema OLAP a colocarem as suas questões nesta forma específica. Uma dimensão é uma métrica de negócio. A métrica actual pode ser representada de muitas formas diferentes. Por exemplo, podemos representar a dimensão tempo como horas, semanas, dias, trimestres ou anos. Um grupo de várias métricas relacionadas entre si formam uma dimensão. Assim sendo, podíamos criar uma dimensão temporal constituída por ano e mês e construir outra dimensão constituída por ano fiscal e trimestre. Podemos querer visualizar uma métrica de muitas formas diferentes e criar diferentes dimensões para cada representação de uma métrica. Os membros de dimensões podem, muitas vezes, ser agrupados em diferentes níveis de uma métrica, estando todos relacionados uns com os outros. Estes diferentes níveis são chamados de hierarquias. As dimensões temporais podem ser representadas por mês e ano. Estas diferentes representações de tempo estão relacionadas entre si (um ano tem doze meses, um mês tem entre vinte e nove e trinta e um dias, etc.). A segunda dimensão temporal que consiste em ano fiscal e trimestres também é uma hierarquia. Uma dimensão geográfica pode ter as seguintes hierarquias: região, distrito e cidade. O OLAP pode percorrer estas hierarquias de forma a que o processo de retorno de informação seja o mais rápido possível. Por exemplo, o OLAP pode proporcionar uma vista das vendas de produtos no Porto durante o mês de Março. Podemos usar o OLAP para visualizar as vendas mensais de qualquer cidade do distrito do Porto através da selecção da cidade adequada. Através do uso de dimensões, hierarquias e measures os sistemas OLAP podem executar uma análise através de períodos sequenciais de tempo, centrar-se em partes específicas de informação e criar, de uma forma rápida, uma nova vista que representa essa porção de informação analisada. Quando se usa um sistema OLAP para analisar dados, pergunta-se muitas vezes Qual a measure usar sobre esta dimensão?. Por exemplo, Quantos pregos foram vendidos no mês de Julho, Agosto e Setembro na região Norte? Esta questão é multidimensional, pois para lhe dar uma resposta é necessário efectuar inquéritos a muitas dimensões. Filipe Pinheiro 32 de 90

33 OLAP Podemos criar uma vista multidimensional através do uso de estruturas de dados construídas a partir de tabelas que contêm measures e dimensões. Existem dois tipos de estruturação das dimensões e measures: os esquemas star e snowflake. 9.1 Fact Table A tabela central de uma base de dados multidimensional é denominada por fact table. As suas linhas constituem os factos. Estas measures constituem as métricas de negócio da organização, que o utilizador necessita de calcular partindo de várias dimensões. As measures são observações do mercado em que a organização está inserida e são muito úteis quando são numéricas e/ou aditivas. Os factos aditivos, permitem ao OLAP somar centenas ou milhares de registos rapidamente. Nas fact tables, em oposição às informational tables, não é suposto que a informação mude ao longo do tempo e, consequentemente, muitas fact tables atingem grandes dimensões (atingindo até milhões de registos), ocupando grandes espaços de armazenamento. As measures não têm que ser aditivas, isto porque em alguns casos não faz sentido adicioná-las umas às outras, como por exemplo o número de artigos em stock. No entanto, já faz sentido calcular a média de artigos em stock. Assim sendo, podemos usar unidades em stock como uma measure, mas fazemos uma média de valores em vez de uma soma. As measures podem também ser baseadas em valores calculados, tal como o total de lucro. Nota O esquema star é constituído por pequenas dimensional tables e grandes fact tables. Quando são processados queries sobre os dados, o OLAP começa por seleccionar o registo correcto das informational tables. Uma vez que estas tabelas são relativamente pequenas, estes queries são rápidos e eficientes. Quando as linhas apropriadas são seleccionadas nas informational tables, é possível utilizar as suas chaves primárias para encontrar o registo correspondente na fact table. Apesar desta tabela ser grande, como as pesquisas são efectuadas sobre atributos chave este processo é eficiente. 9.2 Informational tables As informational tables são tabelas mais pequenas que contêm dados que podem ser alterados ao longo do tempo. Por exemplo, a informational table que guarda os dados dos clientes de uma organização, é alterada se um determinado cliente alterar a sua morada, número Filipe Pinheiro 33 de 90

34 OLAP de telefone, etc. O número de linhas desta tabela é limitado ao número máximo de clientes. Assim sendo, o tamanho desta tabela e de todas as informational tables será muito pequeno em relação à fact table que contém, por exemplo, todas as vendas de Podemos então considerar que as informational tables são pequenas tabelas no mundo do Data Warehouse. As informational tables incluem também campos chave. A chave primária das informational tables são normalmente incluídas como chaves estrangeiras da fact table. Se esta chave primária não estiver incluída na fact table, é denominada por dimensão degenerada (degenerate dimension). Neste caso, as chaves primárias são normalmente geradas pela base de dados analítica. Nota Podemos considerar as informational tables como sendo um grande saco que contém todas as diferentes representações da métrica de negócio da organização, como sendo o tempo, geografia ou o cliente. Para podermos construir as nossas dimensões temos que ir a esse saco e retirar as representações que iremos necessitar para as nossas dimensões. Para primeira dimensão poderíamos retirar ano, mês e dia. Para a segunda ano e semestre. Para a terceira ano e mês. Assim sendo, podemos construir um número muito variado de dimensões a partir dos membros das informational tables. Geralmente, as fact tables têm uma informational table de tempo relacionada. Esta tabela possui as seguintes características: Os atributos da tabela representam divisões por tempo e eventos; As dimensões de tempo mais comuns restringem-se a dia, mês e ano; Períodos de tempo especiais, tais como dia de trabalho, fim de semana, férias, etc. também podem ser representados. As informational tables podem ser construídas usando dois tipos de esquemas: Star Snowflake Filipe Pinheiro 34 de 90

35 OLAP 9.3 Esquemas de estruturação de dados Esquema Star O nome star está relacionado com a forma da estrutura, ou seja, todas as tabelas estão directamente ligadas à fact table, formando uma estrela. A figura seguinte representa um esquema star: Cliente Fact Table: Vendas Produto Tempo Figura 4 - Esquema star As tabelas Cliente, Produto e Tempo apresentadas na figura 4, constituem informational tables cujos atributos representam as métricas de negócio essenciais à organização. A tabela Vendas constitui a fact table que contém não só as measures, como também as chaves estrangeiras que a relacionam com as informational tables. Convém referir que as informational tables podem conter campos para além daqueles que representam as dimensões. Quando queremos converter uma base de dados operacional, relacional e normalizada que obedeça ao esquema star, devemos executar as seguintes operações: 1. Determinar as measures e dimensões; 2. Criar as informational tables; 3. Criar a(s) fact table(s). Filipe Pinheiro 35 de 90

36 OLAP Criação de informational tables para um esquema Star Num esquema star, toda a informação de uma dimensão é colocada numa única informational table. A informação contida nessa tabela inclui um único identificador e os atributos necessários para todas as dimensões que serão construídas a partir dela. Vejamos o exemplo seguinte que representa a dimensão Produto: MARCA IDMarca Nome 1 N PRODUTO IDProduto Nome Preço IDMarca IDCategoria N 1 CATEGORIA IDCategoria Nome Figura 5 - Representação de uma dimensão Num esquema star, estes dados serão agregados numa única informational table não normalizada (tal como na figura 4): PRODUTO IDProduto Nome Preço Marca Categoria Figura 6 - Informational table de um esquema star Nesta tabela, o campo IDProduto identifica unicamente cada produto. Os atributos Marca e Categoria representam respectivamente os nomes da marca e categoria correspondentes a um produto. Como esta tabela não está normalizada, ocupa mais espaço de armazenamento, no entanto, a velocidade de acesso é maior, uma vez que reduz o número de joins. Para além do esquema star, existe um outro método de organizar as informational tables designado por esquema snowflake. Filipe Pinheiro 36 de 90

37 OLAP Esquema Snowflake A figura 7 representa uma estrutura do tipo snowflake, onde múltiplas tabelas definem uma ou mais dimensões da fact table. Isto significa que um esquema deste género constitui uma extensão do esquema star, em que cada tabela extra de uma dimensão está ligada não directamente à fact table, mas sim a outras tabelas da dimensão. Cliente Fact Table: Vendas Produto Marca Categoria Figura 7 - Esquema snowflake Criação de informational tables para um esquema Snowflake Neste tipo de esquema, as informational tables são optimizadas até à terceira forma normal. O exemplo citado anteriormente não sofreria alterações à sua estrutura: MARCA IDMarca Nome 1 N PRODUTO IDProduto Nome Preço IDMarca IDCategoria N 1 CATEGORIA IDCategoria Nome Quando as tabelas são colocadas num diagrama, parecem-se com um floco de neve (daí o nome deste esquema). Para aceder à informação, são necessários vários joins. Estes joins têm uma taxa de ocupação de processamento considerável, mas o espaço de armazenamento é menor. Filipe Pinheiro 37 de 90

38 OLAP Principais diferenças Podemos dizer que, geralmente, um esquema snowflake é menos eficiente que um esquema star. Um quadro comparativo entre estes dois esquemas é apresentado de seguida: Esquema Star Esquema Snowflake Número de linhas Elevado Baixo Leitura Fácil Difícil Número de tabelas Menor Maior Tempo de procura nas dimensões Rápido Lento O esquema snowflake oferece apenas uma vantagem: ocupa menos espaço de armazenamento. A normalização das informational tables não melhora a tarefa de análise dos dados, portanto, talvez seja melhor deixar estas tabelas no seu formato não normalizado. O espaço de armazenamento extra, necessário pela informational table não normalizada é muito pequeno, quando comparado com o espaço de armazenamento requerido pela fact table; sobretudo se compararmos com os ganhos de rapidez em relação a uma estrutura normalizada. 9.4 Dimensões associadas às informational tables Existem quatro tipos de dimensões associadas às informational tables: 1. Estrutura; 2. Informação; 3. Partição; 4. Categoria. A dimensão de estrutura é a mais comum, contendo membros que podem ser colocados numa hierarquia. Dimensões de informação contém atributos necessitam de ser calculados. As dimensões de partição são usadas nas comparações de informação, como por exemplo: vendas previstas e vendas realmente efectuadas. Finalmente, as dimensões de categoria são usadas para criar grupos numa dimensão, baseados em atributos. Filipe Pinheiro 38 de 90

39 OLAP Dimensões de estrutura As dimensões de estrutura apresentam a informação acerca de uma métrica na forma de uma hierarquia. Assim sendo, ano, mês e dia formam uma dimensão de estrutura. Como exemplo de utilização de uma dimensão de estrutura, vamos imaginar que um departamento usa o número total de vendas de um produto como sendo uma measure. Associada a esta measure está a informational table do produto que contém todos os atributos relevantes para descrever as características do produto. As dimensões que podem ser criadas, partindo da informational table do produto são, por exemplo, nome_produto, marca_produto, categoria_produto e família_produto. Como se pode constatar, as dimensões deste produto formam uma hierarquia. Podemos também adicionar, se assim o desejarmos, uma informational table que reflicta o tempo. Podíamos construir uma dimensão de tempo, que iria consistir em ano, mês e dia. Usando esta measure e estas duas dimensões de estrutura, podíamos usar o OLAP para determinar o número total de vendas de um determinado produto durante um período de tempo específico. Alguns exemplos de dimensões de estrutura mais comuns: Dimensão geográfica do cliente: Esta dimensão irá proporcionar uma hierarquia que agrupa clientes, baseando-se para isso no local onde vivem. Um exemplo típico de uma dimensão para cliente é: cliente_cidade, cliente_país, etc. Esta dimensão é muitas vezes usada como forma de se estabelecer uma diferença entre vendas, lucros, etc. entre clientes que vivem em localizações geográficas diferentes. Dimensão tempo: A dimensão temporal irá mostrar quando um determinado evento teve lugar. Exemplos típicos: ano, mês e dia. Dimensão geográfica do vendedor: Esta dimensão irá proporcionar uma hierarquia que agrupa vendedores baseando-se para isso nas zonas onde vende os seus produtos. É muitas vezes usada para comparar vendas, lucros, etc. para as diferentes zonas de venda de produtos. Dimensão do produto: Representa o item que foi comprado. Esta hierarquia pode incluir nome_produto, marca_produto, etc. Esta dimensão é usada para que se possam comparar vendas, lucros, etc. entre diferentes linhas de produtos. Todas estas dimensões de estrutura contêm atributos que são organizados em hierarquias. As hierarquias numa dimensão de estrutura serão demonstradas de seguida. Filipe Pinheiro 39 de 90

40 OLAP Natureza hierárquica das dimensões de estrutura As dimensões de estrutura contêm um conjunto de membros relacionados. Se olharmos para essas dimensões na base de dados operacional original, verificamos que os atributos que formam a dimensão estrutural, normalmente, têm um relação de um para muitos entre si. DISTRITO IDDistrito Designação CONCELHO 1 N IDDistrito 1 N IDConcelho Designação FREGUESIA IDDistrito IDConcelho IDFreguesia Designação Figura 8 - Modelo ER de uma dimensão geográfica As relações representadas na figura 8, encaixam na definição original de um hierarquia, já apresentada. Podemos redesenhar esta informação em termos hierárquicos, através de uma vista parcial dos dados (figura 9). Aveiro Porto... Gondomar Maia... S. Cosme Valbom... Nível 1 Nível 2 Nível 3 Figura 9 - Hierarquia relacional dos dados Existe um factor importante que está relacionado com as hierarquias, e que não deve ser esquecido: cada item na categoria pode ter determinadas measures associadas. As measures aditivas são muito úteis quando trabalhamos com hierarquias. Se sabemos o valor de uma measure aditiva para cada item do fundo da hierarquia, podemos calcular o valor para cada nível mais elevado da hierarquia, desde que a estrutura da hierarquia seja conhecida. Este tipo de measures aditiva, são o melhor tipo de atributos que podemos ter na fact table. Filipe Pinheiro 40 de 90

41 OLAP Podem ser unidades vendidas, volume de vendas ou qualquer quantidade aditiva. Se usarmos dimensões construídas sobre hierarquias e factos aditivos, apenas necessitamos de armazenar os valores para o nível mais baixo dentro da hierarquia. Tal como já foi referido, os valores para os níveis mais elevados podem ser facilmente calculados partindo dos valores dos níveis inferiores. Mas à frente este tema será discutido com maior pormenor quando falarmos em agregações Dimensões de informação As dimensões de informação são construídas a partir de membros calculados. Podemos querer visualizar o total de vendas, por produto e por lucro. Podemos pensar que os produtos com o maior número de vendas tenha maior lucro, mas nem sempre isto acontece. Se subvalorizarmos um produto, podemos verificar que o índice de vendas é muito elevado, mas no entanto o lucro das vendas é muito baixo. Por outro lado, se sobrevalorizarmos um produto podemos ter índices de vendas muito baixos em contrapartida com alto o valor dos lucros. Assim sendo, colocando o lucro como dimensão e o total de vendas como measure, pode ter resultados muito úteis acerca da informação sobre produtos. Podemos fazer dois tipos de cálculos acerca do lucro. O primeiro é lucro por item, que é calculado subtraindo ao preço de venda o preço de compra. Uma vez divulgado o resultado do lucro por produto, podemos multiplicar esse valor pelo número total de vendas desse produto e obter o lucro total por dia. Se criarmos uma dimensão que inclua o lucro por item e o lucro total, temos uma dimensão de informação. Normalmente, os membros calculados são quase sempre measures. No entanto, com um pouco de criatividade podemos usar os atributos calculados em dimensões (em vez de measures) Informational tables construídas a partir de dimensões de partição As dimensões de partição são usadas quando duas ou mais dimensões são criadas a partir da mesma estrutura. Por exemplo, se quisermos criar dimensões que representem as vendas previstas e as vendas reais, a estrutura destas duas dimensões é igual, apenas mudam os valores que cada uma contém. Outro exemplo é a dimensão tempo. Todos os anos têm os mesmos trimestres, meses e dias (excepto nos anos bissextos, mas tal não afecta a dimensão). No OLAP recorre-se frequentemente a dimensões de tempo particionadas para particionar os dados no Data Warehouse. Filipe Pinheiro 41 de 90

42 OLAP Por exemplo, podíamos criar duas dimensões idênticas com a seguinte estrutura: dia mês ano A data numa das dimensões será 1999 e noutra dimensão será Aquando da construção da fact table, podemos particionar as measures em dados de 1999 e dados de Isto trará muitas vantagens, como iremos ver a seguir Dimensões de categoria Uma dimensão de categoria é construída através do agrupamento de valores dos atributos de uma dimensão. Se uma tabela de cliente tem um atributo de representa o rendimento anual, podemos querer visualizar o padrão de compra dos clientes, baseado no seu rendimento. Para realizar isto, temos que criar uma dimensão de categoria que coloque o rendimento anual em categorias. 10 CUBOS Os cubos são os principais objectos de um sistema OLAP, uma tecnologia que proporciona um acesso rápido à informação contida num Data Warehouse. Um cubo é um conjunto de dados, normalmente construído a partir de um subconjunto de um Data Warehouse e é organizado e sumariado numa estrutura multidimensional definida por um conjunto de dimensões e measures. Um cubo proporciona um mecanismo de fácil utilização para inquéritos aos dados com tempos de resposta rápidos e uniformes. Os utilizadores finais usam aplicações cliente para se ligarem a um servidor analítico e fazer queries aos cubos localizados nesse servidor. Em muitas aplicações cliente, os utilizadores finais realizam um query ao cubo, apenas por manipulação dos controlos do interface da aplicação cliente, o que determina o conteúdo do query. Isto poupa os utilizadores do processo de aprendizagem de uma linguagem específica para escrever queries. Os dados pré calculados e sumariados são denominados agregações e são um mecanismo para o rápido e uniforme tempo de resposta dos queries. As agregações são criadas antes que os utilizadores possam aceder aos cubos. Os resultados de um query são retornados a partir das Filipe Pinheiro 42 de 90

43 OLAP agregações, dos dados de origem do cubo no Data Warehouse, ou de uma combinação destes. Um sistema analítico pode suportar muitos tipos de cubos diferentes, como por exemplo, cubos para Vendas, Inventários, Clientes, etc. Cada cubo tem um esquema de armazenamento, que é constituído por um conjunto de tabelas no Data Warehouse, a partir do qual o cubo retira os seus dados de origem. A tabela central é denominada de fact table, que é a fonte das measures para o cubo. As outra tabelas que fazem parte do esquema do cubo são denominadas de dimensional tables, e são a fonte para as dimensões do cubo. Um cubo é definido pelo conjunto de dimensões e measures que contém. Cada dimensão do cubo pode conter uma hierarquia de níveis para especificar a repartição de categorias disponíveis aos utilizadores finais. Cada nível numa dimensão tem uma granilaridade mais fina do que o seu pai. Por exemplo, continentes contém países, e países contêm regiões, etc. Os níveis de dimensões são uma ferramenta poderosa de modelação de dados, porque permite aos utilizadores colocarem questões a um nível mais elevado, e então expandir a hierarquia da dimensão para revelar mais detalhes acerca da questão colocada. Por exemplo, um utilizador pode começar por perguntar as vendas de todo o país, e depois, reparando num valor muito baixo numa dada região, expandir os dados dessa região e analisa-los mais pormenorizadamente para tentar descobrir qual a razão para tal. Esta operação é denominada drill down, e é comum em aplicações cliente. Um cubo pode ter até 128 dimensões, cada uma com milhares ou milhões de membros, a até cerca de 1024 measures. Um cubo é um subordinado imediato da base de dados, na hierarquia de objectos. De seguida é apresentada a hierarquia de objectos que estão imediatamente abaixo do cubo: Fonte de dados: Um cubo te uma única fonte de dados. Pode ser seleccionada a partir de uma fonte de dados já existente na base de dados ou de uma fonte de dados criada no momento da criação do cubo. As dimensões de um cubo devem ter a mesma fonte de dados que o cubo, contudo, as suas partições podem ter fontes de dados diferentes; Measures: As measures de um cubo não podem ser partilhadas com outros cubos. São criadas quando o cubo é criado e podem ser até 1024; Dimensões: As dimensões de um cubo, ou são partilhadas com outros cubos da base de dados, ou então são privadas. As dimensões partilhadas podem ser criadas antes ou durante a criação do cubo. As dimensões privadas são criadas no momento Filipe Pinheiro 43 de 90

44 OLAP de criação do cubo, e, apesar do termo cubo sugerir apenas três dimensões (que são as únicas que se podem representar graficamente), um cubo pode conter até 128 dimensões; Partições: Um única partição é automaticamente criada para um cubo no momento de criação. Contudo, depois do cubo estar devidamente criado, podemos adicionar mais partições; Roles: Cada cubo tem de ter pelo menos um role definido de forma a proporcionar o acesso aos utilizadores finais. Os roles do cubo são derivados dos roles da base de dados, e podem ser definidos antes ou depois da criação do cubo. Quando os cubos são criados, as partições ou as agregações são, normalmente, os objectos seguintes a serem criados. A criação de um cubo envolve três passos: Definição: A definição de um cubo é baseada nos requerimentos analíticos dos utilizadores finais. Para definir um cubo, é necessário seleccionar a fact table e identificar as measures. Seguidamente devemos seleccionar ou criar as dimensões, cada uma constituída por uma ou mais colunas de outra tabela; Definição de agregações: Após a definição do novo cubo, podemos definir as agregações. Esta acção, especifica a estratégia de sumarização dos dados; Processamento: Depois de definidas as agregações de um novo cubo, devemos processar o cubo com a opção Full process. Esta acção cria as agregações. Se, depois do cubo ter sido processado, este sofrer algum tipo de alteração ou se a fonte de dados for alterada, é necessário processar o cubo outra vez. Um cubo é constituído pela fact table e as suas dimensões. Cada célula no cubo, representa um facto correspondente a um nível de detalhe para as diferentes dimensões. Um cubo pode ter até sessenta e quatro dimensões (com o MsOLAP), apesar de só se conseguirem representar três, graficamente. Depois de definidas as dimensões e as measures, podemos construir cubos que através dos atributos das dimensões de negócio. Estes atributos constituem os eixos do cubo, como por exemplo, um eixo para a cidade de um cliente ou um eixo para o dia de uma dimensão de tempo. O cruzamento destes valores é designado por tuplo (tuple). Filipe Pinheiro 44 de 90

45 OLAP O exemplo seguinte representa um cubo para vendas com as dimensões: loja, tipo de produto e ano: Loja Tipo de produto Livros Revistas Postais Ano Figura 10 - Exemplo de um cubo O total de vendas de revistas no ano de 1998 na loja 2 está representado a rosa no esquema anterior. Um cubo permite analisar informação ao longo dos atributos nas dimensões. A movimentação sobre os eixos do cubo designa-se por slicing. É possível obter várias visualizações da informação através da troca de dimensões ao longo dos eixos. Para além disso é possível expandir os dados (drilling) nos seus diferentes níveis, como por exemplo, expandir todas os concelhos da cidade do Porto. A melhor forma de visualizar e compreender dimensões, fact tables e esquemas star ou snowflake sob forma de cubos é vê-los na realidade. Nota Estes cubos não são tecnicamente cúbicos, ou seja, os lados não são iguais. Ainda assim são referidos como cubos, mesmo que tenham mais ou menos que três dimensões. Filipe Pinheiro 45 de 90

46 OLAP 10.1 Agregações Já vimos anteriormente que as dimensões possuem hierarquias. Ao utilizarmos measures aditivas sobre estas hierarquias, é possível verificar que os valores de cada nível correspondem à soma dos níveis inferiores, tal como na figura 11: Todas as lojas c. Porto c. Gaia c. Gondomar c. S ta. Catarina c. Boavista c. Cedofeita c. Arrábida c. S. Cosme c. Nível 1 Nível 2 Nota: Valores apresentados em contos Nível 3 Figura 11 - Representação dos valores numa hierarquia Podemos melhorar significativamente a performance de uma ferramenta OLAP, se estes valores aditivos forem armazenados no Data Warehouse. Este processo dá origem a agregações. O armazenamento das agregações dos valores das measures permitem à ferramenta OLAP efectuar queries mais rápidos. As agregações constituem uma das principais características da tecnologia OLAP e permitem que as ferramentas sejam fiáveis e com tempos de resposta eficientes. O armazenamento das agregações tem um preço, uma vez que requer mais espaço físico. Quanto maior o número de níveis da hierarquia, maior será o número de somas necessárias. Com dimensões grandes (com uma média de cem membros), os espaço requerido para armazenar a informação agregada pode tornar-se elevada. Este processo é normalmente designado por explosão de dados. Filipe Pinheiro 46 de 90

47 OLAP A relação entre a capacidade de armazenamento e a velocidade de processamento é directamente proporcional. Desse modo, é possível ajustar estes valores conforme as necessidades e limitações físicas do sistema. No processamento de um cubo, a ferramenta de agregações existente (Design Storage) permite configurar a relação entre a performance e o espaço de armazenamento pretendidos. Através da comparação dos seguintes gráficos, é possível verificar essa relação: Figura 12 - Opções de agregação com performance=50% Filipe Pinheiro 47 de 90

48 OLAP Figura 13 - Opções de agregação com performance=100% Figura 14 - Opções de agregação com espaço de armazenamento máximo=300 Mb Filipe Pinheiro 48 de 90

49 OLAP No gráfico representado na figura 12, foi especificado um ganho de performance de 50% dando origem a 138 agregações e ocupando um espaço de aproximadamente 22 Mb. No gráfico representado na figura 13 aumentou-se a performance para 100% o que originou uma subida exponencial, aumentando o número de agregações para 785 e o respectivo espaço de armazenamento para aproximadamente 630 Mb. É possível verificar na figura 14 que estabelecendo um espaço físico de armazenamento não superior a 300 Mb, a performance diminui apenas para os 90%. Estas configurações devem ser geridas conforme os requisitos e limitações do sistema. O OLAP oferece uma ferramenta que origina um número mínimo de agregações, obtendo a máxima eficiência. Esta ferramenta de agregações utiliza a regra 80-20, ou seja, um conjunto de agregações é criado tal que apenas 20% das agregações originam um aumento de performance em 80 %. O OLAP faz uma gestão das agregações necessárias para manter esta regra Explosão de dados O tamanho da explosão de dados depende da granularidade dos dados, que indica o detalhe da informação. Podem existir diferentes níveis de granularidade num Data Warehouse. Por exemplo, uma dimensão de tempo pode ser medida em dias, o que representa um nível de granularidade elevado. Pelo contrário, essa dimensão pode ser medida em anos, o que representa um nível de granularidade fraco. Quando construímos um Data Warehouse, devemos escolher o melhor nível de granularidade para cada situação em particular Relação entre a granularidade e a explosão dos dados O nível de granularidade tem um grande impacto na explosão de dados. Por exemplo, numa hierarquia de produtos com 50 nodos, podem ser calculados um conjunto de measures como agregações. Se a dimensão de tempo inclui o ano e os 4 trimestres (granularidade fraca), temos apenas 4*50=200 valores para cada measure. Podemos agregar os valores dos 4 trimestres num único valor para o ano, para os 50 produtos. Estas agregações adicionam apenas mais 50 valores no Data Warehouse. Se adicionarmos 12 meses à dimensão assim como os 365 dias teremos 365*50=18250 valores no Data Warehouse. Se agregarmos as medidas sobre os meses, obtemos 12*50=600 agregações mais as 50 agregações para o ano. Este aumento de Filipe Pinheiro 49 de 90

50 OLAP granularidade resultou num largo aumento dos valores e agregações no Data Warehouse, originando uma explosão dos dados ROLAP, MOLAP e HOLAP Após a criação de um Data Warehouse, podemos construir os cubos que contêm as dimensões e measures que serão usadas pelos serviços OLAP. É possível guardar estes cubos utilizando um dos três formatos disponíveis: ROLAP, MOLAP e HOLAP. Situações diferentes requerem diferentes métodos de armazenamento, não existindo uma resposta universal. Cada uma destas opções tem certos benefícios, dependendo do tamanho da base de dados e de como a informação vai ser utilizada ROLAP Quando utilizamos um formato ROLAP, o OLAP coloca as agregações no Data Warehouse relacional e utiliza os dados para construir cubos e agregações. Isto significa que as estruturas multidimensionais de dados não são utilizadas para armazenar a informação. Uma ferramenta OLAP que funcione com este tipo de formato de armazenamento deve suportar todas as funcionalidades existentes (drilling, slicing, resposta rápida e uniforme, entre outras) e permitir agregações. O OLAP disponibiliza todas estas funcionalidades. Com um esquema ROLAP, o OLAP utiliza as tabelas que permitem a construção dos cubos e agregações, ou seja, as tabelas não são copiadas para uma base de dados multidimensional. Se se armazenarem os valores agregados, estes serão guardados na base de dados relacional. A figura 15 ilustra esta situação: Sistemas OLTP ROLAP Data Warehouse Cliente SQL 7.0 BD Relacional e Agregações Serviços OLAP Aplicação p/ utilizador ORACLE Figura 15 - Esquema de armazenamento ROLAP Filipe Pinheiro 50 de 90

51 OLAP MOLAP Enquanto que o ROLAP coloca tudo na base de dados relacional, o MOLAP faz exactamente o oposto, ou seja, coloca todos os dados requeridos pelos serviços OLAP numa base de dados multidimensional especial. Quando se utiliza a mesma informational table para dimensões idênticas em cubos diferentes, os mesmos dados são copiados para a base de dados multidimensional para todos os cubos, utilizando essa tabela. Por exemplo, se um conjunto de cinco cubos utilizar uma informational table temporal para construir uma dimensão de tempo, teremos cinco cópias de informação idêntica na base de dados multidimensional. Isto não só representa um desperdício de espaço, mas também de tempo para a transferência da informação para a base de dados. Uma base de dados muito grande (com gigabytes de dados) pode levar horas a ser processada. Este formato permite a melhor performance ao nível dos inquéritos, porque é especialmente optimizada para inquéritos multidimensionais. Esta opção é apropriada para pequenos a médios conjuntos de informação. Uma solução MOLAP assemelha-se ao esquema da figura 16: Sistemas OLTP MOLAP Serviços OLAP Cliente SQL 7.0 ORACLE BD Relacional BD Multidimensional com as Agregações e os dados Aplicação p/ utilizador Figura 16 - Esquema de armazenamento MOLAP MOLAP vs. ROLAP Quando utilizamos o ROLAP, os dados são armazenados em tabelas relacionais. Não existe duplicação de dados num esquema ROLAP, uma vez que os dados do Data Warehouse Filipe Pinheiro 51 de 90

52 OLAP são utilizados directamente pelo sistema OLTP. Desta forma, o ROLAP requer menos espaço de armazenamento. Devido ao formato relacional e não multidimensional, a análise dos dados leva mais tempo a ser executada. O drill down requer muito tempo de processamento. O MOLAP requer espaço de armazenamento extra, dado que a informação do Data Warehouse tem que ser movida para a base de dados multidimensional, de forma a que os serviços OLAP possam efectuar queries aos dados. Ainda assim, estes dados são comprimidos, utilizando índices bitmap. Desta forma, é necessário menos espaço extra do que o espaço ocupado pela base de dados relacional original. O MOLAP é extremamente rápido e eficiente, devido à estrutura multidimensional de armazenamento de dados. Os tempos de resposta são rápidos e consistentes. Uma desvantagem do MOLAP consiste no tempo necessário para transferir os dados do Data Warehouse para a base de dados multidimensional. Este tempo pode atingir horas ou dias, dependendo da forma como os dados são transferidos e a sua quantidade. Resumindo, o ROLAP requer menos espaço de armazenamento, mas tempos de acesso mais elevados. O ROLAP é um candidato ideal para um Data Warehouse que contém informação raramente acedida e/ou em quantidades extremas (num intervalo na ordem dos gigabytes). A maioria das organizações divide os seus dados históricos em dois grupos. Um grupo com a informação frequentemente utilizada e que cobre um determinado período. O outro grupo contém os dados que raramente são utilizados e que cobre o tempo posterior ao do primeiro grupo. O tamanho deste tipo de dados pode ser muito grande, uma vez que é possível que represente vários anos ou mesmo décadas. Uma vez que estes dados são pouco acedidos, a performance mais lenta do ROLAP torna-se menos importante. Para a maioria dos Data Warehouses, o MOLAP é uma boa solução. Se os queries são frequentes e a performance constitui um requisito, o MOLAP é a melhor solução. O investimento num sistema mais poderoso é compensado quando se obtém, de uma forma rápida e eficiente, a informação necessária. Um sistema MOLAP, pode disponibilizar informação para qualquer pessoa de uma organização. Combinando o Data Warehouse com a Internet, é possível disponibilizar informação para qualquer pessoa em qualquer parte do mundo. A elevada performance de um sistema MOLAP é fundamental neste cenário. A utilização de um sistema ROLAP para a Internet, seria provavelmente muito lento. Ao contrário, o MOLAP devidamente afinado, permite tempo de resposta muito razoáveis, mesmo na Internet. O MOLAP nem sempre é a melhor solução, mas quando o tamanho da base de dados é menos importante do que a velocidade e a eficiência dos queries analíticos, isto não se verifica. Filipe Pinheiro 52 de 90

53 OLAP Se queremos um sistema que não utilize muito espaço, mas que ainda assim permita uma performance razoável, existe um formato de armazenamento híbrido: HOLAP HOLAP O HOLAP não move os dados do Data Warehouse para uma base de dados multidimensional, tal como no ROLAP. No entanto, as agregações são armazenadas numa base de dados multidimensional. O esquema da figura 17 exemplifica esta solução: Sistemas OLTP HOLAP Data Warehouse Serviços OLAP Cliente SQL 7.0 ORACLE BD Relacional BD Multidimensional com as Agregações Aplicação p/ utilizador Figura 17 - Esquema de armazenamento HOLAP A comparação entre o ROLAP e o MOLAP foca-se essencialmente no armazenamento das agregações e dos dados. Numa base de dados com um elevado nível de agregações, as measures e membros calculados são obtidos rapidamente. Com o formato HOLAP, numa base de dados com um elevado número de agregações, é possível determinar estes valores de uma forma muito rápida, porque apenas as agregações são armazenadas na base de dados multidimensional. Tal como no ROLAP, o drill down é lento, apesar do tempo para obtenção da informação das agregações ser baixo. De uma forma geral, o HOLAP tem uma performance melhor que o ROLAP, à excepção dos membros calculados. Filipe Pinheiro 53 de 90

54 OLAP 11 PARTIÇÕES As partições permitem que os dados fonte e os dados agregados de um cubo possam estar distribuídos entre diferentes servidores. Cada partição num cubo pode ter diferentes fontes de dados. Estas fontes de dados podem referenciar várias bases de dados em diferentes computadores. Adicionalmente, os dados agregados de cada partição, podem ser armazenados no servidor analítico onde a partição está definida, noutro servidor analítico, ou na mesma base de dados que a fonte de dados da partição. Cada cubo tem, pelo menos, uma partição, que contém os dados do cubo; uma única partição é automaticamente criada aquando da criação do cubo. Quando criamos uma nova partição para um cubo, a nova partição é adicionada às partições já existentes. O cubo reflecte os dados combinados de todas as suas partições. A divisão do cubo em partições é um processo completamente transparente para o utilizador final. As partições são uma forma poderosa e flexível de gerir cubos, especialmente os cubos grandes. Por exemplo, um cubo que contenha os dados das vendas, pode conter partições que representem cada um dos trimestres do ano. No fim do ano, as quatro partições que representam os quatro trimestres, podem ser combinadas numa única partição que representa as venda desse ano. As partições podem ser armazenadas usando uma enorme combinação de opções dependendo da origem da fonte dos dados, localização das agregações, modo de armazenamento, e definição das agregações. Esta flexibilidade permite definir estratégias de armazenamento do cubo baseadas nas necessidades das organizações. Cada partição tem uma fonte de dados que pode ser a mesma ou diferente da fonte de dados da partição do cubo. Se for usada a mesma fonte de dados, a partição e o cubo não necessitam de ter a mesma fact table. Se for usada uma fonte de dados diferente, esta deve referenciar a base de dados que contém o conjunto de tabelas que são, essencialmente, as mesmas que estão presentes no esquema do cubo. Cada partição pode armazenar os seus dados agregados no servidor analítico onde a partição está definida; este é o caso pré definido. Contudo, os dados agregados da partição podem ser armazenados noutro servidor analítico; neste caso estamos perante uma partição remota. Cada partição tem um modo de armazenamento, o que determina se os dados agregados da partição estão armazenados no servidor analítico ou na base de dados especificada na fonte de dados da partição. O modo de armazenamento, também determina se uma cópia dos dados de origem está ou não armazenada no servidor analítico. Filipe Pinheiro 54 de 90

55 OLAP Cada partição poder ter diferentes definições de agregações, que determinam o número e conteúdo das agregações criadas para a partição. Podemos moldar a definição das agregações através da especificação de constantes de utilização ou performance dos queries. Com os testes baseados em utilização, podemos executar as mesmas acções e podemos também optimizar a definição das agregações baseando-se para isso em queries previamente enviados para a partição do cubo. Podemos seleccionar os queries, cujos resultados, servem de base à optimização. Um dos factores que pode afectar a escolha do método de armazenamento de dados são as partições. As partições permitem divisões físicas de cubos ROLAP, em porções mais pequenas, que serão armazenadas no disco rígido. As partições permitem que, a diferentes partes do cubo sejam atribuídos diferentes métodos de armazenamento. Isto significa que podemos ter partes do cubo com métodos de armazenamento diferentes, por exemplo, uma parte do cubo usa MOLAP e outra HOLAP. Esta característica torna os cubos muito flexíveis e eficientes para diversos tipos de utilização. Se dividirmos um cubo ROLAP em duas partições, cada uma armazenada em discos rígidos diferentes, podemos colocar parte dos dados numa partição e o restante noutra partição. Podemos transferir dados para o cubo a partir de ambos os disco rígidos ao mesmo tempo, o que faz aumentar a performance em relação à utilização de apenas um disco rígido. Quando criamos uma partição, cada uma tem as suas próprias agregações. Isto significa que podemos armazenar dimensões diferentes em partições diferentes e criar agregações diferentes para as várias dimensões do cubo. Podemos também atribuir diferentes tipos de armazenamento de dados para cada partição, permitindo escolher o melhor método de armazenamento para as dimensões Estrutura A estrutura de uma partição deve ser semelhante à estrutura do cubo a que está associada. O conjunto de dimensões e measures que definem a estrutura do cubo também devem estar presentes na partição. Por esta razão, quando uma partição é criada, automaticamente herda o conjunto de dimensões e measures do cubo. Contudo, é possível que uma partição e o cubo associado tenham fact tables diferentes. Nestes casos, é necessário um elevado grau de semelhança entre as fact tables da partição e do cubo, de forma a garantir um padrão entre a estrutura da partição e o cubo. Um cubo, juntamente com todas as suas partições, deve possuir fact tables com a mesma estrutura. Todas as colunas que são utilizadas na definição de measures devem estar presentes, e Filipe Pinheiro 55 de 90

56 OLAP devem ter os mesmos nomes em todas as fact tables. No entanto, podem existir colunas adicionais numas fact tables e noutras não, assim com o nome das fact tables também pode diferir. Todas as fontes de dados de um cubo, e de todas as suas partições, devem estar referenciadas a bases de dados que usem o mesmo esquema, que o que foi usado aquando da definição do cubo. Todas as dimensional tables presentes no esquema do cubo devem estar presentes, e ter o mesmo nome, em todas as bases de dados. A estrutura destas dimensional tables deve ser a mesma em todas as bases de dados. 12 CUBOS VIRTUAIS Um cubo virtual é um combinação de múltiplos cubos num cubo lógico, à semelhança de uma vista de uma base de dados relacional combinada com outras vista de outras tabelas. Quando criamos um cubo virtual, seleccionamos measures e dimensões a partir de um conjunto consolidados de measures e dimensões dos outros cubos. Os utilizadores finais vêm o cubo virtual como sendo um único cubo. Um cubo virtual pode ser baseado num único cubo, se desejarmos que apenas seja possível aceder a subconjuntos de measures e dimensões desse cubo. Como os cubos virtuais armazenam apenas as suas definições e não os dados dos cubos que o compõem, requerem um espaço de armazenamento físico muito baixo. Podemos usar cubos virtuais para criar combinações e variantes de cubos existentes, sem que para tal seja necessário recorrer a espaço de armazenamento adicional considerável. Um cubo virtual proporciona uma função de segurança muito valiosa, através da limitação do acesso de alguns utilizadores. Se alguma da informação do cubo é mais sensível ou não está destinada à visualização por parte de qualquer utilizador, podemos criar um cubo virtual e omitir a informação que não pode ser visualizada. Desta forma os utilizadores apenas têm direito à consulta dos dados a que estão autorizados. De seguida, podemos ainda criar dois roles de segurança: o primeiro, contém os utilizadores que estão autorizados a consultar a informação confidencial, e o segundo, contendo os outro utilizadores. Por fim, atribuímos permissões de acesso ao cubo aos utilizadores da primeira role de segurança, e acesso ao cubo virtual aos utilizadores que estão na segunda role de segurança. Após a criação de um cubo virtual, é necessário processá-lo, antes que as aplicações cliente possam utilizá-lo para pesquisas. O processamento de um cubo virtual estabelece as ligações internas para as dimensões e measures especificadas nos restantes cubos fonte. Esta operação de Filipe Pinheiro 56 de 90

57 OLAP ligação é efectuada num processo que é muito rápido. Contudo, o processamento de um cubo virtual, origina o processamento de todos os cubos aos quais o cubo virtual está ligado, o que pode aumentar significativamente o tempo de processamento. Os cubos virtuais constituem uma funcionalidade muito poderosa num Data Warehouse. Em vez de construir um cubo com várias partições, podemos construir vários cubos e, usando um cubo virtual, juntar todos esses cubos. A figura 18 ilustra essa situação: Dimensão Cliente Dimensão Tempo Dimensão Produto Dimensão Cliente, Tempo, Produto Figura 18 - Criação de um cubo virtual Para que possamos utilizar os cubos virtuais temos que ter em atenção que todos os cubos têm de ter a mesma fact table, e os três cubos virtuais têm que pertencer ao mesmo Data Warehouse. Podemos utilizar os cubos virtuais se tivermos uma quantidade de dados muito grande. No caso de termos um servidor com um número razoável de processadores e memória, as múltiplas partições podem ser actualizadas ao mesmo tempo. Isto pode reduzir substancialmente o tempo necessário a transferir dados do Data Warehouse para os cubos MOLAP. Contudo existe um uso muito mais poderoso dos cubos virtuais. Vamos agora imaginar que temos dois departamentos na nossa organização e que ambos querem ter Data Marts, onde algumas das dimensões são iguais, enquanto que outras são diferentes. Filipe Pinheiro 57 de 90

58 OLAP Através do uso de cubos virtuais, podemos construir a seguinte solução apresentada na figura 19: Dimensão Cliente Dimensão Tempo Dimensão Produto e Inventário Dimensão Cliente, Tempo, Produto Dimensão Produto, Inventário, Tempo Figura 19 - Solução construída com base em cubos virtuais Assim, os cubos virtuais podem resolver o problema da criação de ilhas de dados. Podemos criar múltiplos cubos contendo dimensões e depois, partilhar estas dimensões ao longo da organização. Desta forma, cada Data Mart pode ter as suas próprias dimensões. Existem ainda outros aspectos a considerar. Se usarmos o ROLAP, podemos impedir a cópia da mesma dimensão para várias bases de dados multidimensionais, através da criação da dimensão uma única vez e depois usando essa dimensão em vários cubos virtuais. Isto torna-se útil, quando temos a dimensão num servidor e esta irá ser utilizada por um Data Warehouse que está localizado noutro servidor. Por outro lado, se as dimensões estiverem no mesmo Data Warehouse, podemos usar dimensões partilhadas. Uma das principais razões porque se utilizam cubos virtuais é segurança. Se tivermos na nossa organização vários departamentos de vendas, organizados por regiões, podemos não querer que os responsáveis de cada região tenham acesso aos dados das outras regiões, mas sim, que apenas os directores tenham acesso total. Podemos então criar um cubo que contém os dados de todas as regiões, e criamos cubos virtuais para cada região. Desta Filipe Pinheiro 58 de 90

59 OLAP forma, quando o director se liga ao sistema, tem acesso ao cubo que possui todas os dados de todas as regiões, enquanto que os restantes elementos da organização apenas têm acesso ao cubo que contém os dados da sua região respectiva Roles Podemos criar roles que nos podem ajudar em diversas situações. Por exemplo, deparamonos muitas vezes com uma situação em que, o director de marketing e o director de vendas de uma mesma organização, querem aceder aos mesmos dados, mas de uma forma diferente. Através da criação de roles para o departamento de marketing e de vendas, e vistas diferentes para cada role, podemos facilmente facilitar a ambos os directores o acesso à informação que pretendem, sem que para isso se tenham que construir Data Warehouses ou Data Marts redundantes. Num sistemas OLAP, as permissões para as roles são baseadas na segurança NT. Podemos colocar utilizadores ou grupos de utilizadores definidos no NT em roles, mantendo essas mesmas permissões já definidas. Filipe Pinheiro 59 de 90

60 DTS DATA TRANSFORMATION SERVICES

61 DTS 1 INTRODUÇÃO Num Data Warehouse é necessário que a informação seja precisa, caso contrário, torna-se inútil. Deve existir um planeamento cuidado da forma como os dados são transferidos para o Data Warehouse. É necessário escolher as fontes de dados, criar nomes standartizados para os campos, e chegar a uma forma standard para apresentar os dados. Quando isto é feito, é necessário construir um sistema para mover e transformar os dados conforme o desenho estabelecido. Por exemplo, podemos transferir os dados de uma base de dados armazenada em Access para um sistema OLAP para a sua difusão. A base de dados relacional, geralmente obtém os dados a partir de um sistema OLTP. Assim, antes de criar o Data Warehouse é necessário mover os dados da sua fonte original para uma base de dados centralizada (figura 1). Não só os dados são transferidos, mas também são filtrados para se adaptarem às necessidades do Data Warehouse. Para isso, são utilizados os DTS (Data Transformation Services). Aplicação OLTP BD Operacional DTS BD Centralizada DTS Data Warehouse Dados externos Validação e transformação de dados Sistema OLAP Figura 20 - Transferência de dados para um Data Warehouse Filipe Pinheiro 61 de 90

62 DTS 2 FUNCIONALIDADES DO DTS O serviço DTS possui numerosas funcionalidades que permitem a movimentação de dados de uma fonte para outra. O DTS é usado tanto para mover dados de um sistema para outro, como para filtrar e alterar esses dados. O termo Sistema de Dados representa qualquer possível fonte de dados, tal como uma base de dados, um ficheiro de texto, um Microsoft Exchange Server, entre outros, porque o DTS trabalha com qualquer fonte OLE-DB compatível. Quando queremos importar ou exportar dados, as três principais funcionalidades para o efeito são: Extracção, Transformação e Carregamento. Estas funcionalidades possibilitam a transferência, filtragem e actualização de dados de um sistema para outro. 2.1 Extracção A extracção permite identificar os elementos no sistema fonte de dados e visualizar a metainformação (dados da estrutura do sistema). Ao utilizar a extracção, é possível obter informação desse sistema e escolher os dados necessários para a transformação. 2.2 Transformação A transformação consiste no mapeamento dos dados de um sistema fonte para um sistema destino e que pode incluir alteração de dados, mas nunca na fonte de origem. Por exemplo, três fontes de dados que representam masculino como Masculino, M, e 0. Estes valores podem ser transformados em um só valor, como Masculino. Os dados podem ser resumidos e condensados, porque o Data Warehouse não necessita de toda a informação do sistema OLTP. Uma parte da transformação consiste na validação dos dados ou na sua correcta formatação. Estas transformações podem ser efectuadas a partir de scripts em Visual Basic ou JavaScritp, ou através da criação de componentes COM construídos a partir de linguagens como Visual Basic ou C++. Para transformações baseadas em cálculos simples utilizando a base de dados OLTP, podemos criar views como por exemplo o preço actual = preço de venda - desconto. A transformação torna mais fácil de implementar validações de dados complexas, pesquisa de informação e conversões de dados durante o processo de importação e exportação. Filipe Pinheiro 62 de 90

63 DTS Permite-nos então: Manipular dados das colunas Por exemplo, podemos mudar o tipo, tamanho, precisão ou a nulidade dos tipos de dados que irão ser inseridos numa coluna; Utilizar funções escritas em linguagens script Estas funções podem aplicar transformações especializadas ou incluir lógica condicional. Por exemplo, podemos escrever uma função numa linguagem de script que examine os dados numa coluna para valores superiores a Sempre que tal valor seja encontrado, é substituído pelo valor de -1, na tabela de destino. Para valores que não sejam superiores a 1000, os dados são simplesmente copiados para a tabela de destino sem qualquer tipo de transformação. 2.3 Carregamento O carregamento envolve a colocação dos dados finais filtrados e alterados no sistema de dados destino. O DTS ajuda a colocar estes dados no sistema de dados correcto e permite ajustar exactamente onde esses dados estarão no sistema. O DTS providencia um mapeamento dos dados da fonte para o destino. Ao utilizar o DTS, podemos criar uma base de dados centralizada com um formato standard, como base de dados intermediária para filtrar e validar os dados. Os dados podem fluir dessa base de dados centralizada para outras fontes dentro de uma organização. Após a validação e filtragem dos dados, é possível movê-los para o Data Warehouse. A arquitectura OLE-DB torna o DTS possível, uma vez que providencia acesso a qualquer fonte OLE-DB como por exemplo o Microsoft SQL Server, Microsoft Access, Oracle, Excel, entre outros. O OLE-DB também funciona com ODBC (Open Database Connectivity), que permite aceder a qualquer fonte de dados que não possui um serviço OLE-DB, mas sim um serviço ODBC. O DTS pode aceder a ficheiros de texto ASCII. O OLE-DB permite ao DTS criar uma comunicação entre, praticamente, qualquer fonte de dados. Uma outra funcionalidade do DTS é o SQL Server Agent, que permite calendarizar a movimentação dos dados. Isto pode ser muito útil para efectuar automaticamente e regularmente transformação e movimentação de dados. Este processo pode ser efectuado durante horas Filipe Pinheiro 63 de 90

64 mortas do sistema, de forma a que não afecte a performance da base de dados OLTP ou do Data Warehouse OLAP. DTS 3 PACKAGES Um package DTS é uma colecção organizada de ligações a fontes de dados, tarefas DTS, transformações DTS e constantes de fluxo de trabalho, juntas quer por meio de programação ou por ferramentas DTS, e gravadas no Microsoft SQL Server. Os Packages são objectos do DTS que contêm todo os passos necessários para transformar e transferir os dados. Um package possui um conjunto de tarefas que são efectuadas durante a transformação. É possível criar, guardar (com password ou não), editar, eliminar e executar packages DTS. Cada package contém um ou mais passos que são executados sequencialmente ou em paralelo assim que o package seja executado. Quando executado, o package estabelece uma ligação às fontes de dados que necessita para que possa copiar dados, objectos da base de dados, transformar dados e notificar utilizadores dos processos ou eventos a decorrer ou concluídos. Os packages possuem um sistema de segurança que limita quem pode executá-los. Eles utilizam transacções, por forma a finalizar as tarefas com sucesso ou não. Assim, um package nunca é executado completamente caso exista erro ou inconsistência nos dados a serem transferidos (duplicação de campos-chave, não correspondência entre campos-chave de diferentes tabelas, etc.). Os packages utilizam três tipos de objectos: Conexão, Tarefa e Passo (figura 2). Filipe Pinheiro 64 de 90

65 DTS Passo 1: Executar a tarefa 1 Tarefa 1 Transferência de dados de uma BD em Access para um servidor SQL BD Access BD SQL DTS Data Pump Connecção 1 Passo 2: Executar a tarefa 2 Tarefa 2 Transferência de dados de uma BD em SQL para um DW BD SQL DW SQL DTS Data Pump Connecção 2 Figura 21 - Objectos de um package 3.1 Conexão Para que possamos executar com sucesso uma tarefa DTS que copia e transforma dados, um package DTS deve estabelecer uma conexão válida com a fonte de dados de origem e destino, e com outras fontes de dados adicionais. Devido à arquitectura do OLE-DB, o DTS permite conexões a dados armazenados num vasto leque de formatos, desde que sejam compatíveis com OLE-DB. Um objecto de conexão providencia os detalhes de todas as fontes de dados envolvidas na transformação. Uma conexão para uma base de dados contém informação acerca dos nomes dos servidores, dos utilizadores, passwords, e o formato dos dados a serem transferidos. Um objecto de conexão para um ficheiro contém informação acerca da sua localização, nome e formato. Filipe Pinheiro 65 de 90

66 Utilizando OLE-DB e a informação da conexão, o DTS possibilita a ligação de sistemas de dados e da sua movimentação entre eles. DTS 3.2 Tarefa Um objecto de tarefa é uma funcionalidade discreta, que é executada como um único passo num package. Cada tarefa define uma parte do trabalho a ser executado como parte da transformação e movimentação dos dados, ou como um trabalho completo a ser executado. O DTS fornece um grupo de tarefas que fazem parte do modelo de objectos do DTS e que podem ser acedidas graficamente através do DTS Designer ou em modo de programação. Estas tarefas, que podem ser configuradas individualmente, cobrem um vasto leque de funcionalidades, como cópia de dados, transformação de dados e notificações: Importação de exportação de dados O DTS pode importar dados de um ficheiro de texto ou de uma fonte de dados OLE- DB (por exemplo Microsoft Access 2000) para um base de dados de um SQL Server. Alternativamente, os dados podem ser exportados de um servidor SQL para uma fonte de dados OLE-DB (por exemplo Microsoft Excel 2000). O DTS também permite carregamento de dados a alta velocidade a partir de ficheiros de texto para tabelas localizadas num servidor SQL. Transformação de dados O DTS Designer inclui uma tarefa de transformação de dados que permite seleccionar dados de uma fonte de dados, mapear as colunas de dados para um conjunto de transformações e depois, enviar os dados transformados para uma fonte de dados destino. A selecção dos dados a seleccionar também pode ser feito através de queries SQL programados e parametrizados. Cópia de objectos da base de dados Com o DTS podemos transferir índices, views, logins, stored procedures, triggers, rules, constraints e tipos de dados definidos pelo utilizador para além doa informação Filipe Pinheiro 66 de 90

67 contida na base de dados. Isto pode ser executado recorrendo a scripts para copiar os abjectos da base de dados. DTS Executar tarefas como trabalhos desde um package Por exemplo, podemos usar a tarefa Execute Process para executar uma aplicação Visual Basic que recolhe e agrega dados diariamente. Depois podemos usar a tarefa Execute Package para correr um segundo package que importa e transforma os dados gerados pela aplicação Visual Basic. Envio e recepção de mensagens O DTS inclui uma tarefa com o nome Send Mail que permite enviar um se o passo de um determinado package sucede ou falha. Isto é muito útil para notificar o administrador da base de dados por , para que este saiba se o package foi executado com sucesso ou não. Inclui também uma tarefa Execute Package que permite a um package correr outro package como se fosse um passo normal na sua execução e ainda, uma tarefa Message Queue que permite o envio e recepção de mensagens entre packages. Como o DTS é baseado num modelo COM extensivo, podemos criar as nossas próprias tarefas personalizadas. Podemos integrar as tarefas personalizadas no interface do utilizador dentro do DTS Designer e gravar tudo como fazendo parte do modelo de objectos do DTS. 3.3 Passo Este tipo de objectos definem a sequência das tarefas a serem executadas. Um passo, não só determina esta sequência, como também determina se uma tarefa depende da finalização completa de outra. Se dois passos não são dependentes entre si, podem ser executados em paralelo. Filipe Pinheiro 67 de 90

68 A sequência de execução dos passo de um package pode ser definida com: Constantes de precedência que permitem ligar duas tarefas, baseando-se para isso se a primeira tarefa é executada, é executada com sucesso ou é executada sem sucesso. Podemos usar constantes de precedência para construir ramos de salto condicional num fluxo de trabalho. Passos que não tenham constantes de precedência definidos, são executados imediatamente; vários passos podem ser executados em paralelo; Scripts de ActiveX que modifiquem o fluxo normal de trabalho. DTS Quando um package é criado por meios de programação, podemos controlar de uma forma mais precisa a relação entre uma tarefa e um passo. Podemos criar múltiplos passos para diferentes packages e associar a execução desses passos com uma única tarefa. Por exemplo, vamos supor que escrevemos um package em Visual Basic e especificamos em várias partes do package que podem ocorrer erros. Ligando os passos associados com esses erros, podemos fazer com que diferentes tipos de erros executem todos a mesma tarefa Send Mail que pode ser uma tarefa para notificar o administrador da base de dados que o package falhou Constantes de precedência No DTS podemos usar três tipos de constantes de precedência: Incondicional Se queremos que a tarefa 2 aguarde até que a tarefa 1 termine, não ligando ao que daí possa advir, devemos ligar as duas tarefas com uma constante de precedência Incondicional. Em caso de Sucesso Se queremos que a tarefa 2 aguarde até que a tarefa 1 termine com sucesso, devemos ligar as duas tarefas com uma constante de precedência Em caso de Sucesso. Em caso de Falha Se queremos que a tarefa 2 seja executada apenas se a tarefa 1 falhe a sua execução, devemos ligar as duas tarefas com uma constante de precedência Em caso de Falha. Filipe Pinheiro 68 de 90

69 A figura 3 mostra-nos a relação entre as constantes de precedência com os passos e as tarefas: DTS Figura 22 - Precedências de execução Neste exemplo, temos as seguintes operações: Passo 1: Contém uma tarefa Execute SQL que é responsável por eliminar uma tabela e depois recriá-la outra vez; Passo 2: Se a tabela de destino foi eliminada e depois recriada com sucesso, os dados são copiados de uma tabela de uma base de dados do Microsoft Access para uma tabela de uma base de dados Microsoft SQL Server. A constante de precedência Em caso de Sucesso, a verde, estabelece uma relação entre estes dois passos. A tarefa de transformação dos dados é mostrada pela seta a cinzento, que une a base de dados Microsoft Access com a base de dados Microsoft SQL Server; Passo 3: Se o processo de cópia dos dados falhar, é enviado um de notificação ao administrador da base de dados. A constante de precedência Em caso de Falha, está representada por uma seta a vermelho e estabelece uma relação entre os passos dois e três Uso de múltiplas constantes de precedência Podemos usar múltiplas constantes de precedência numa tarefa. Por exemplo, na ilustração seguinte, a tarefa C poderia ter ambas as constantes de precedências Em caso de Sucesso (proveniente da tarefa A) e Em caso de Falha (proveniente da tarefa B). Neste caso, o DTS assume uma relação lógica do tipo E (AND). Assim sendo, a tarefa A tem que ser executada com sucesso e a tarefa B tem que falhar, para que a tarefa C possa ser executada. Filipe Pinheiro 69 de 90

70 DTS Tarefa A Tarefa B Tarefa C Figura 23 - Múltiplas constantes de precedência Filipe Pinheiro 70 de 90

71 MDX MULTIDIMENSIONAL EXTENSIONS

72 MDX 1 INTRODUÇÃO O MDX é uma extensão da linguagem SQL. O MDX cria views de dados através da especificação dos pontos do cubo que irão ser usados para avaliar as measures. É possível utilizar o MDX para definir dimensões temporárias, assim como novas measures num cubo. O MDX é uma linguagem poderosa, que permite personalizar soluções OLAP para requisitos específicos de um negócio. Apesar de existirem ferramentas alternativas, como por exemplo ProClarity, que possibilitam a criação de soluções limitadas para o cliente, se utilizarmos o MDX, é possível criar qualquer solução exigida pelo cliente. O MDX é um companheiro indispensável num sistema OLAP e que permite resolver os problemas que possam surgir. 2 UTILIZAÇÃO DE MDX NUM DATA WAREHOUSE Compreender a linguagem MDX é essencial para desenhar, melhorar e manter um Data Warehouse. O desenho de um Data Warehouse pode ser afectado pela própria estrutura do MDX e dos queries MDX específicados. Por exemplo, os nomes dos campos devem ser escolhidos de forma a que sejam compreendidos pelo MDX. Utilizando um mesmo nome para definir um nível em duas dimensões diferentes pode tornar difícil a escrita de queries MDX, assim como a leitura do seu resultado. Para estruturar convenientemente estes queries, devem ser escritos especificamente para cada dimensão utilizando uma nomenclatura adequada. Isto evita que os programadores escrevam código genérico que sirva a todas as dimensões. Uma boa nomenclatura pode não resolver todos os problemas existentes, mas permite que as aplicações do Data Warehouse se tornem um conjunto de queries ilegíveis. 2.1 Desenho do Data Warehouse O administrador não deve desenvolver a ideia para o desenho de um Data Warehouse e esperar que um programador produza uma aplicação baseada nesse desenho. Em vez disso, toda a equipa deve iniciar o seu trabalho directamente com os utilizadores, esquematizando as suas necessidades em cenários e casos de uso. Estes casos de uso devem ser convertidos num conjunto de serviços que os componentes da aplicação possam executar. Quando isto é feito, a Filipe Pinheiro 72 de 90

73 MDX equipa pode começar a desenhar os componentes e o administrador do Data Warehouse pode começar a desenhá-lo. Após o término da etapa de desenho, este reflecte as necessidades dos utilizadores, e só depois, as necessidades da aplicação e do Data Warehouse. 3 MDX E OS SERVIÇOS OLAP Assim como um especialista em OLTP deve saber como elaborar, optimizar e melhorar queries SQL, um especialista em OLAP deve saber elaborar, optimizar e melhorar queries MDX. Existem muitas operações que não são possíveis de realizar sem o recurso ao MDX, como por exemplo, a criação de níveis de segurança. A aprendizagem do MDX é essencial para administrar ou desenvolver um Data Warehouse 4 INSTRUÇÕES MDX A linguagem MDX é constituída por um conjunto de elementos que formam a sintaxe de cada instrução. Estes elementos permitem especificar e criar qualquer conjunto de dados que seja necessário. Este conjunto de dados consiste na informação devolvida por queries MDX sobre um servidor OLAP. 4.1 Os cinco elementos de uma instrução MDX Números Numa instrução MDX, um número pode ser de qualquer tipo: numérico, inteiro, decimal, real, entre outros. É possível aplicar as operações habituais nestes números, tais como: adição, subtracção, multiplicação e divisão. Da utilização destas operações resultam novos números a partir dos existentes. O processo de criação deste números é chamado composição. Filipe Pinheiro 73 de 90

74 MDX Strings Uma string MDX constitui uma sequência de caracteres e podem ter uma formatação especial no cliente Membros Um membro é um valor de qualquer atributo de uma dimensão. Por exemplo, para uma dimensão de tempo que contém os níveis ano e mês, 1988 e Janeiro constituem membros válidos. O MDX possui um conjunto de expressões denominada expressões de membros que podem ser utilizadas sobre qualquer membro de uma dimensão. Estas expressões retornam um membro da dimensão ou zero. Por exemplo, uma destas expressões é o parent. Numa dimensão que inclui o país, a região e a cidade, a expressão parent(porto) retorna o valor Norte, que constitui a região que contém a cidade do Porto. Por outro lado, a expressão parent(portugal) retorna o valor zero, porque constitui o valor mais alta da hierarquia Tuplos Um tuplo MDX consiste numa colecção de membros de diferentes dimensões. Por exemplo, (Porto, [1998]) constitui um tuplo formado por membros de duas dimensões: geográfica e tempo. Os tuplos representam uma posição única nos eixos do cubo, que consiste em múltiplos membros. Não é possível representar a mesma dimensão mais do que uma vez num tuplo, como por exemplo, (Porto, Aveiro) Conjuntos Um conjunto consiste numa colecção de tuplos regulares, mas que representa uma colecção de membros de uma mesma dimensão, ou de diferentes dimensões. Uma instrução MDX pode conter expressões de conjuntos, membros ou funções numéricas e representa uma expressão MDX. Por exemplo, a expressão que representa o conjunto de todos os membros (MEMBERS) retorna todos os membros de um conjunto, desde que não contenha tuplos. Filipe Pinheiro 74 de 90

75 MDX Esta expressão é muito importante para devolver todos os membros de um nível de uma dimensão, porque elimina a necessidade de os escrever a todos num tuplo. 5 ESTRUTURA BÁSICA DE UMA INSTRUÇÃO MDX Para que uma instrução MDX retorne um conjunto de dados, devem ser incluídos os seguintes elementos: O nome do cubo, ou cubos utilizados para extracção dos dados; O número dos eixos do cubos, ou cubos. Nota Torna-se necessário referir que um eixo num cubo representa uma dimensão. Um eixo numa instrução MDX representa um conjunto de dados de uma ou mais dimensões, como por exemplo, no eixo xx podemos ter representados todos os membros de uma dimensão segundo um membro de outra dimensão. Normalmente, o termo dimensão é usado em vez de eixo. Usando o termo dimensão, podíamos dizer que uma folha de cálculo do Excel apresenta um resultado em duas dimensões, e portanto, a instrução MDX tem apenas duas dimensões. Contudo, no OLAP, o termo dimensão é usado para cubos. Assim sendo, e para prevenir confusão, no MDX usamos o termo eixo em vez de dimensão, apesar de terem o mesmo significado. 6 EXEMPLOS DE INSTRUCÇÕES Sintaxe de uma instrução MDX: SELECT <especificação_do_eixo> [,<especificação_do_eixo>,...] FROM <especificação_cubo> WHERE <especificação_filtro> Filipe Pinheiro 75 de 90

76 MDX Exemplo 1: SELECT {([Measures].[Volume_vendas])} ON COLUMNS, {([Tempo].[1999].[Janeiro].[1])} ON ROWS FROM Vendas Este pequeno exemplo permite seleccionar, para as colunas uma medida de negócio: Volume de vendas, segundo o dia 1 de Janeiro de 1999 para as linhas. Tempo Volume vendas 1999 Janeiro $00 Exemplo 2: SELECT {([Measures].[Volume_vendas])} ON COLUMNS, { ([Clientes].[All Clientes].[António Pinto], [Produto].[All Produto].[Bacalhau], ([Clientes].[All Clientes].[António Pinto], [Produto].[All Produto].[Batata], ([Clientes].[All Clientes].[António Pinto], [Produto].[All Produto].[Azeite] } ON ROWS FROM Vendas António Pinto Volume vendas Bacalhau $00 Batata 40000$00 Azeite 70000$00 Neste exemplo, são apurados os volumes de vendas de três produtos que o cliente António Pinto adquiriu. Filipe Pinheiro 76 de 90

77 MDX Exemplo 3: SELECT {([Measures].[Volume_vendas])} ON COLUMNS, [Produto].[Categoria].MEMBERS ON ROWS FROM Vendas WHERE ([Clientes].[All Clientes].[António Pinto], [Tempo].[2000]) Volume vendas Bebidas $00 Padaria $00 Carne $00 Peixe $ Neste exemplo, para o cliente António Pinto e para o ano de 2000, são seleccionados para as colunas as categorias existentes de produtos, e para as linhas os respectivos volumes de vendas. Exemplo 4 (criação de membros calculados): WITH MEMBER MEASURES.[Lucro] AS MEASURES.[Volume_vendas] MEASURES.[Custo] MEMBER [Tempo].[Taxa_97_98] AS ([Tempo].[1998] / [Tempo].[1997]) SELECT {(MEASURES.[Volume_vendas]), (MEASURES.[Custo]), (MEASURES.[Lucro])} ON COLUMNS, {([Tempo].[1997]), ([Tempo].[1998]), ([Tempo].[Taxa_97_98])} ON ROWS FROM Vendas Filipe Pinheiro 77 de 90

78 MDX Volume vendas Custos Lucro $ $ $ $ $ $00 Taxa_97_98 1,3 1,4 1,2 Neste exemplo, foram criados dois membros calculados a partir de membros já existentes: Lucro = Volume vendas Custos; Taxa_97_98 = Valor 1998 / Valor 1997 Filipe Pinheiro 78 de 90

79 EXEMPLO PRÁTICO

80 Exemplo prático A empresa ABC, responsável pela venda por catálogo de produtos de cosmética e perfumaria pretende realizar uma análise exaustiva do módulo de vendas ao longo do tempo de actividade. Posteriormente, pretende alargar este modelo a todos os módulos da aplicação informática. O modelo de dados engloba várias tabelas, mas pretendemos apenas focar a parte relativa às vendas, nomeadamente: Zona da venda; Clientes que comparam; Produtos vendidos. Desta forma, as tabelas necessárias para esta análise e respectivas relações são as seguintes: Figura 24 - Modelo de dados em Access Para a construção do cubo, é necessário, em primeiro lugar, transformar a informação para o novo modelo pretendido. Este modelo deve permitir um cubo com um esquema star, e assim foram criados os seguintes queries para a transformação: Filipe Pinheiro 80 de 90

81 Exemplo prático Vendas: SELECT venda.cod_venda, [venda].[cod_zona] & [venda].[cod_sub_zona] AS id_zona, venda.data, venda.cod_cliente, venda.cod_vendedor, venda.valor_total, venda.items_vendidos FROM (zona INNER JOIN venda ON zona.cod_zona = venda.cod_zona) INNER JOIN sub_zona ON (sub_zona.cod_zona = venda.cod_zona) AND (sub_zona.cod_sub_zona = venda.cod_sub_zona) AND (zona.cod_zona = sub_zona.cod_zona); Figura 25 - Query Vendas Este query permite agrupar os códigos da zona e sub-zona da venda num único código que irá ligar a tabela vendas com a nova tabela zona (query apresentado seguidamente). Zonas: SELECT [sub_zona].[cod_zona] & [sub_zona].[cod_sub_zona] AS id, zona.zona, sub_zona.sub_zona FROM zona INNER JOIN sub_zona ON zona.cod_zona = sub_zona.cod_zona; Figura 26 - Query Zonas Este query permite juntar as tabelas zona e sub_zona numa só tabela. Esta desnormalização é efectuada para que seja possível efectuar posteriormente uma ligação em estrela à fact table do cubo. Produtos_Vendidos: SELECT prod_venda.cod_venda, prod_venda.cod_produto, produto.descricao, produto.preco, prod_venda.quantidade, prod_venda.valor FROM produto INNER JOIN prod_venda ON produto.cod_produto = prod_venda.cod_produto; Figura 27 - Query Produtos_Vendidos Pela mesma razão vista no query anterior, é necessário agrupar a informação dos produtos vendidos em cada venda numa só tabela. Filipe Pinheiro 81 de 90

82 Exemplo prático O passo seguinte consiste em exportar esta informação para um novo modelo no SQL, utilizando os DTS. Foram criados os seguintes packages: DTS_1: Importa para o SQL as tabelas cliente e vendedor do modelo de dados de Access; DTS_2: Importa para um nova tabela no SQL o resultado do query zonas do modelo de dados de Access; DTS_3: Importa para um nova tabela no SQL o resultado do query vendas do modelo de dados de Access; DTS_4: Importa para um nova tabela no SQL o resultado do query produtos_vendidos do modelo de dados de Access. O novo modelo de dados pode ser visualizado através do esquema seguinte: Figura 28 - Novo modelo de dados em SQL É possível, neste momento, elaborar o cubo no OLAP a partir deste modelo. Assim sendo, o novo cubo possui as seguintes características: Fact Table: Tabela vendas; Measures: valor_total e items_vendidos; Informational Tables: vendedor, zona, cliente e produtos; Filipe Pinheiro 82 de 90

83 Exemplo prático Dimensões: cliente (nível 1: nome) zona (nível 1: zona; nível2: sub_zona) produto (nível1: descricao) vendedor (nível1: nome); Formato do cubo: MOLAP; Esquema: Star schema; Performance: 100%. Podemos visualizar o resultado do cubo através do esquema seguinte: Figura 29 - Estrutura do Cubo Agora que o nosso novo cubo foi criado, podemos efectuar alguns queries MDX ao dados que nele se encontram, para que de facto possamos ver como isto funciona, e qual o aspecto primário de uma vista: Exemplo 1: O query apresentado de seguida mostra-nos o valor total de vendas (nas colunas) por cliente (nas linhas). select {[Measures].[Valor Total]} on columns, {([cliente].[nome].members)} on rows from Vendas Figura 30 - MDX - Total de vendas por cliente Filipe Pinheiro 83 de 90

84 Exemplo prático De seguida, podemos ver qual o aspecto de uma vista que incide sobre o query MDX exemplificado: Figura 31 - Vista resultante do Exemplo 1 Exemplo 2: Para visualizarmos o valor total de vendas, por zona e produto, teríamos que efectuar o seguinte query MDX: select {[Measures].[Valor Total]} on columns, crossjoin ({[zona].children},{[produto].members}) on rows from Vendas Figura 32 - MDX - Total de vendas por zona e produto De seguida, podemos ver qual o aspecto de uma vista que incide sobre o query MDX exemplificado: Figura 33 - Vista resultante do Exemplo 2 Filipe Pinheiro 84 de 90

85 Exemplo prático Exemplo 3: Contudo, podíamos desejar refinar o query utilizado no exemplo anterior, para visualizarmos o valor de vendas por zona e produto, mas de um vendedor apenas. Assim sendo, o query seguinte teria de ser utilizado: select {[Measures].[Valor Total]} on columns, crossjoin ({[zona].children},{[produto].members}) on rows from Vendas where [vendedor].[all vendedor].[pedro Miguel de Castro] Figura 34 - MDX - Total de vendas por zona e produto, segundo um vendedor De seguida, podemos ver qual o aspecto de uma vista que incide sobre o query MDX exemplificado: Figura 35 - Vista resultante do Exemplo 3 Filipe Pinheiro 85 de 90

86 Exemplo prático Exemplo 4: Finalmente, vamos poder ver como se adicionam calculated members. Tal como foi já explicado no capítulo anterior, os calculated members são membros que não pertence à estrutura do cubo, e são depois calculados com base em measures já existentes no cubo. Vejamos agora de seguida, um exemplo, em que criamos um calculated member de nome Volume vendas, que consiste na soma das measures Valor Total e Itens Vendidos with member [Measures].[Volume vendas] as '[Measures].[Valor Total] + [Measures].[Items Vendidos]' select {[Measures].[Volume vendas]} on columns, crossjoin ({[zona].children},{[produto].members}) on rows from Vendas where [vendedor].[all vendedor].[pedro Miguel de Castro] Figura 36 - MDX - Criação de um calculated member De seguida, podemos ver qual o aspecto de uma vista que incide sobre o query MDX exemplificado: Figura 37 - Vista resultante do Exemplo 4 Filipe Pinheiro 86 de 90

Módulo 4. Construindo uma solução OLAP

Módulo 4. Construindo uma solução OLAP Módulo 4. Construindo uma solução OLAP Objetivos Diferenciar as diversas formas de armazenamento Compreender o que é e como definir a porcentagem de agregação Conhecer a possibilidade da utilização de

Leia mais

- A crescente necessidade de sistemas inteligentes e de aquisição de conhecimento levaram à necessidade de implementação de Data Warehouses.

- A crescente necessidade de sistemas inteligentes e de aquisição de conhecimento levaram à necessidade de implementação de Data Warehouses. - A crescente necessidade de sistemas inteligentes e de aquisição de conhecimento levaram à necessidade de implementação de. - O que é uma Data Warehouse? - Colecção de bases de dados orientadas por assunto

Leia mais

DATA WAREHOUSE. Introdução

DATA WAREHOUSE. Introdução DATA WAREHOUSE Introdução O grande crescimento do ambiente de negócios, médias e grandes empresas armazenam também um alto volume de informações, onde que juntamente com a tecnologia da informação, a correta

Leia mais

TECNOLOGIAS DA INFORMAÇÃO E COMUNICAÇÃO. SISTEMAS DE GESTÃO DE BASE DE DADOS Microsoft Access TECNOLOGIAS DA INFORMAÇÃO E COMUNICAÇÃO

TECNOLOGIAS DA INFORMAÇÃO E COMUNICAÇÃO. SISTEMAS DE GESTÃO DE BASE DE DADOS Microsoft Access TECNOLOGIAS DA INFORMAÇÃO E COMUNICAÇÃO TECNOLOGIAS DA INFORMAÇÃO E COMUNICAÇÃO Microsoft Access TECNOLOGIAS DA INFORMAÇÃO E COMUNICAÇÃO CONCEITOS BÁSICOS 1 Necessidade das base de dados Permite guardar dados dos mais variados tipos; Permite

Leia mais

A VISTA BACKSTAGE PRINCIPAIS OPÇÕES NO ECRÃ DE ACESSO

A VISTA BACKSTAGE PRINCIPAIS OPÇÕES NO ECRÃ DE ACESSO DOMINE A 110% ACCESS 2010 A VISTA BACKSTAGE Assim que é activado o Access, é visualizado o ecrã principal de acesso na nova vista Backstage. Após aceder ao Access 2010, no canto superior esquerdo do Friso,

Leia mais

Banco de Dados - Senado

Banco de Dados - Senado Banco de Dados - Senado Exercícios OLAP - CESPE Material preparado: Prof. Marcio Vitorino OLAP Material preparado: Prof. Marcio Vitorino Soluções MOLAP promovem maior independência de fornecedores de SGBDs

Leia mais

TÓPICOS AVANÇADOS EM ENGENHARIA DE SOFTWARE

TÓPICOS AVANÇADOS EM ENGENHARIA DE SOFTWARE TÓPICOS AVANÇADOS EM ENGENHARIA DE SOFTWARE Engenharia de Computação Professor: Rosalvo Ferreira de Oliveira Neto OLPT x OLAP Roteiro OLTP Datawarehouse OLAP Operações OLAP Exemplo com Mondrian e Jpivot

Leia mais

Tarefa Orientada 18 Tabelas dinâmicas

Tarefa Orientada 18 Tabelas dinâmicas Tarefa Orientada 18 Tabelas dinâmicas Análise de dados através de tabelas dinâmicas. Conceitos teóricos As Tabelas Dinâmicas são tabelas interactivas que resumem elevadas quantidades de dados, usando estrutura

Leia mais

Arquitecturas de Software Licenciatura em Engenharia Informática e de Computadores

Arquitecturas de Software Licenciatura em Engenharia Informática e de Computadores UNIVERSIDADE TÉCNICA DE LISBOA INSTITUTO SUPERIOR TÉCNICO Arquitecturas de Software Licenciatura em Engenharia Informática e de Computadores Primeiro Teste 21 de Outubro de 2006, 9:00H 10:30H Nome: Número:

Leia mais

DATA WAREHOUSE. Rafael Ervin Hass Raphael Laércio Zago

DATA WAREHOUSE. Rafael Ervin Hass Raphael Laércio Zago DATA WAREHOUSE Rafael Ervin Hass Raphael Laércio Zago Roteiro Introdução Aplicações Arquitetura Características Desenvolvimento Estudo de Caso Conclusão Introdução O conceito de "data warehousing" data

Leia mais

Data Warehousing e OLAP

Data Warehousing e OLAP Data Warehousing e OLAP Jornadas de Engenharia Informática Instituto Politécnico da Guarda Henrique Madeira Departamento de Engenharia Informática Faculdade de Ciências e Tecnologia Universidade de Coimbra

Leia mais

TIC Unidade 2 Base de Dados. Informação é todo o conjunto de dados devidamente ordenados e organizados de forma a terem significado.

TIC Unidade 2 Base de Dados. Informação é todo o conjunto de dados devidamente ordenados e organizados de forma a terem significado. Conceitos relativos à Informação 1. Informação O que á a informação? Informação é todo o conjunto de dados devidamente ordenados e organizados de forma a terem significado. 2. Dados Em informática designa-se

Leia mais

Modelo Cascata ou Clássico

Modelo Cascata ou Clássico Modelo Cascata ou Clássico INTRODUÇÃO O modelo clássico ou cascata, que também é conhecido por abordagem top-down, foi proposto por Royce em 1970. Até meados da década de 1980 foi o único modelo com aceitação

Leia mais

GereComSaber. Desenvolvimento de Sistemas de Software. Universidade do Minho Conselho de Cursos de Engenharia Licenciatura em Engenharia Informática

GereComSaber. Desenvolvimento de Sistemas de Software. Universidade do Minho Conselho de Cursos de Engenharia Licenciatura em Engenharia Informática Universidade do Minho Conselho de Cursos de Engenharia Licenciatura em Engenharia Informática Desenvolvimento de Sistemas de Software Ano Lectivo de 2009/10 GereComSaber Ana Duarte, André Guedes, Eduardo

Leia mais

DEPARTAMENTO DE MATEMÁTICA E CIÊNCIAS EXPERIMENTAIS

DEPARTAMENTO DE MATEMÁTICA E CIÊNCIAS EXPERIMENTAIS DEPARTAMENTO DE MATEMÁTICA E CIÊNCIAS EXPERIMENTAIS Planificação Anual da Disciplina de TIC Módulos 1,2,3-10.ºD CURSO PROFISSIONAL DE TÉCNICO DE APOIO À GESTÃO DESPORTIVA Ano Letivo 2015-2016 Manual adotado:

Leia mais

TECNOLOGIAS DA INFORMAÇÃO E COMUNICAÇÃO - TIC 10º C. Planificação de. Curso Profissional de Técnico de Secretariado

TECNOLOGIAS DA INFORMAÇÃO E COMUNICAÇÃO - TIC 10º C. Planificação de. Curso Profissional de Técnico de Secretariado Escola Básica e Secundária de Velas Planificação de TECNOLOGIAS DA INFORMAÇÃO E COMUNICAÇÃO - TIC Curso Profissional de Técnico de Secretariado 10º C MÓDULO 1 FOLHA DE CÁLCULO Microsoft Excel Conteúdos

Leia mais

Tarefa Orientada 16 Vistas

Tarefa Orientada 16 Vistas Tarefa Orientada 16 Vistas Objectivos: Vistas só de leitura Vistas de manipulação de dados Uma vista consiste numa instrução de SELECT que é armazenada como um objecto na base de dados. Deste modo, um

Leia mais

O Manual do ssc. Peter H. Grasch

O Manual do ssc. Peter H. Grasch Peter H. Grasch 2 Conteúdo 1 Introdução 6 2 Usar o ssc 7 2.1 Gerir os utilizadores.................................... 7 2.1.1 Adicionar um utilizador.............................. 8 2.1.1.1 Associar-se

Leia mais

EXCEL TABELAS DINÂMICAS

EXCEL TABELAS DINÂMICAS Informática II Gestão Comercial e da Produção EXCEL TABELAS DINÂMICAS (TÓPICOS ABORDADOS NAS AULAS DE INFORMÁTICA II) Curso de Gestão Comercial e da Produção Ano Lectivo 2002/2003 Por: Cristina Wanzeller

Leia mais

Transição de POC para SNC

Transição de POC para SNC Transição de POC para SNC A Grelha de Transição surge no âmbito da entrada em vigor, no ano de 2010, do Sistema de Normalização Contabilística (SNC). O SNC vem promover a melhoria na contabilidade nacional,

Leia mais

Ministério das Finanças Instituto de Informática. Departamento de Sistemas de Informação

Ministério das Finanças Instituto de Informática. Departamento de Sistemas de Informação Ministério das Finanças Instituto de Informática Departamento de Sistemas de Informação Assiduidade para Calendários Específicos Junho 2010 Versão 6.0-2010 SUMÁRIO 1 OBJECTIVO 4 2 ECRÃ ELIMINADO 4 3 NOVOS

Leia mais

Data Warehousing. Leonardo da Silva Leandro. CIn.ufpe.br

Data Warehousing. Leonardo da Silva Leandro. CIn.ufpe.br Data Warehousing Leonardo da Silva Leandro Agenda Conceito Elementos básicos de um DW Arquitetura do DW Top-Down Bottom-Up Distribuído Modelo de Dados Estrela Snowflake Aplicação Conceito Em português:

Leia mais

Interatividade aliada a Análise de Negócios

Interatividade aliada a Análise de Negócios Interatividade aliada a Análise de Negócios Na era digital, a quase totalidade das organizações necessita da análise de seus negócios de forma ágil e segura - relatórios interativos, análise de gráficos,

Leia mais

Direcção Regional de Educação do Algarve

Direcção Regional de Educação do Algarve MÓDULO 1 Folha de Cálculo 1. Introdução à folha de cálculo 1.1. Personalização da folha de cálculo 1.2. Estrutura geral de uma folha de cálculo 1.3. O ambiente de da folha de cálculo 2. Criação de uma

Leia mais

PLANIFICAÇÃO MODULAR ANO LECTIVO 2015 / 2016

PLANIFICAÇÃO MODULAR ANO LECTIVO 2015 / 2016 PLANIFICAÇÃO MODULAR ANO LECTIVO 2015 / 2016 CURSO/CICLO DE FORMAÇÃO Técnico de Eletrotecnia e Técnico de Gestão de Equipamentos Informáticos / 2015/2018 DISCIPLINA: Tecnologias da Informação e Comunicação

Leia mais

Suporte Técnico de Software HP

Suporte Técnico de Software HP Suporte Técnico de Software HP Serviços Tecnológicos HP - Serviços Contratuais Dados técnicos O Suporte Técnico de Software HP fornece serviços completos de suporte de software remoto para produtos de

Leia mais

Modelo de dados do Data Warehouse

Modelo de dados do Data Warehouse Modelo de dados do Data Warehouse Ricardo Andreatto O modelo de dados tem um papel fundamental para o desenvolvimento interativo do data warehouse. Quando os esforços de desenvolvimentos são baseados em

Leia mais

GUIA PARA O PREENCHIMENTO DOS FORMULÁRIOS ENTIDADE GESTORA ERP PORTUGAL

GUIA PARA O PREENCHIMENTO DOS FORMULÁRIOS ENTIDADE GESTORA ERP PORTUGAL GUIA PARA O PREENCHIMENTO DOS FORMULÁRIOS ENTIDADE GESTORA ERP PORTUGAL Versão: 1.0 Data: 05-06-2009 Índice Acesso e estados dos Formulários... 3 Escolha do Formulário e submissão... 4 Bases para a navegação

Leia mais

Trabalhos Práticos. Programação II Curso: Engª Electrotécnica - Electrónica e Computadores

Trabalhos Práticos. Programação II Curso: Engª Electrotécnica - Electrónica e Computadores Trabalhos Práticos Programação II Curso: Engª Electrotécnica - Electrónica e Computadores 1. Objectivos 2. Calendarização 3. Normas 3.1 Relatório 3.2 Avaliação 4. Propostas Na disciplina de Programação

Leia mais

Manual do GesFiliais

Manual do GesFiliais Manual do GesFiliais Introdução... 3 Arquitectura e Interligação dos elementos do sistema... 4 Configuração do GesPOS Back-Office... 7 Utilização do GesFiliais... 12 Outros modos de utilização do GesFiliais...

Leia mais

Tarefa 18: Criar Tabelas Dinâmicas a partir de Listas de Excel

Tarefa 18: Criar Tabelas Dinâmicas a partir de Listas de Excel Tarefa 18: Criar Tabelas Dinâmicas a partir de 1. Alguns conceitos sobre Tabelas Dinâmicas Com tabelas dinâmicas podemos criar dinâmica e imediatamente resumos de uma lista Excel ou de uma base de dados

Leia mais

DESENVOLVER E GERIR COMPETÊNCIAS EM CONTEXTO DE MUDANÇA (Publicado na Revista Hotéis de Portugal Julho/Agosto 2004)

DESENVOLVER E GERIR COMPETÊNCIAS EM CONTEXTO DE MUDANÇA (Publicado na Revista Hotéis de Portugal Julho/Agosto 2004) DESENVOLVER E GERIR COMPETÊNCIAS EM CONTEXTO DE MUDANÇA (Publicado na Revista Hotéis de Portugal Julho/Agosto 2004) por Mónica Montenegro, Coordenadora da área de Recursos Humanos do MBA em Hotelaria e

Leia mais

Gestão dos Níveis de Serviço

Gestão dos Níveis de Serviço A Gestão dos Níveis de Serviço (SLM) Os sistemas e tecnologias de informação e comunicação têm nas empresas um papel cada vez mais importante evoluindo, hoje em dia, para níveis mais elevados de funcionamento

Leia mais

Pesquisa e organização de informação

Pesquisa e organização de informação Pesquisa e organização de informação Capítulo 3 A capacidade e a variedade de dispositivos de armazenamento que qualquer computador atual possui, tornam a pesquisa de informação um desafio cada vez maior

Leia mais

Serviço a Pedido ( On Demand ) da CA - Termos e Política de Manutenção Em vigor a partir de 1 de Setembro de 2010

Serviço a Pedido ( On Demand ) da CA - Termos e Política de Manutenção Em vigor a partir de 1 de Setembro de 2010 Serviço a Pedido ( On Demand ) da CA - Termos e Política de Manutenção Em vigor a partir de 1 de Setembro de 2010 A Manutenção do Serviço a Pedido ( On Demand ) da CA consiste numa infra-estrutura de disponibilidade

Leia mais

DEMONSTRAÇÕES FINANCEIRAS COMBINADAS

DEMONSTRAÇÕES FINANCEIRAS COMBINADAS 24 DEMONSTRAÇÕES FINANCEIRAS COMBINADAS Os mercados de capitais na Europa e no mundo exigem informações financeiras significativas, confiáveis, relevantes e comparáveis sobre os emitentes de valores mobiliários.

Leia mais

Data Warehouse. Debora Marrach Renata Miwa Tsuruda

Data Warehouse. Debora Marrach Renata Miwa Tsuruda Debora Marrach Renata Miwa Tsuruda Agenda Introdução Contexto corporativo Agenda Introdução Contexto corporativo Introdução O conceito de Data Warehouse surgiu da necessidade de integrar dados corporativos

Leia mais

MICROSOFT ACCESS MICROSOFT ACCESS. Professor Rafael Vieira Professor Rafael Vieira

MICROSOFT ACCESS MICROSOFT ACCESS. Professor Rafael Vieira Professor Rafael Vieira MICROSOFT ACCESS MICROSOFT ACCESS Professor Rafael Vieira Professor Rafael Vieira - Access - Programa de base de dados relacional funciona em Windows Elementos de uma Base de Dados: Tabelas Consultas Formulários

Leia mais

5. Métodos ágeis de desenvolvimento de software

5. Métodos ágeis de desenvolvimento de software Engenharia de Software 5. Métodos ágeis de desenvolvimento de software Nuno Miguel Gil Fonseca nuno.fonseca@estgoh.ipc.pt Desenvolver e entregar software o mais rapidamente possível é hoje em dia um dos

Leia mais

Manual de Utilizador. Disciplina de Projecto de Sistemas Industriais. Escola Superior de Tecnologia. Instituto Politécnico de Castelo Branco

Manual de Utilizador. Disciplina de Projecto de Sistemas Industriais. Escola Superior de Tecnologia. Instituto Politécnico de Castelo Branco Escola Superior de Tecnologia Instituto Politécnico de Castelo Branco Departamento de Informática Curso de Engenharia Informática Disciplina de Projecto de Sistemas Industriais Ano Lectivo de 2005/2006

Leia mais

Complemento I - Noções Introdutórias em Data Warehouses

Complemento I - Noções Introdutórias em Data Warehouses Complemento I - Noções Introdutórias em Data Warehouses Esse documento é parte integrante do material fornecido pela WEB para a 2ª edição do livro Data Mining: Conceitos, técnicas, algoritmos, orientações

Leia mais

EXCEL. Listas como Bases de Dados

EXCEL. Listas como Bases de Dados Informática II Gestão Comercial e da Produção EXCEL Listas como Bases de Dados (TÓPICOS ABORDADOS NAS AULAS DE INFORMÁTICA II) Curso de Gestão Comercial e da Produção Ano Lectivo 2002/2003 Por: Cristina

Leia mais

A Gestão, os Sistemas de Informação e a Informação nas Organizações

A Gestão, os Sistemas de Informação e a Informação nas Organizações Introdução: Os Sistemas de Informação (SI) enquanto assunto de gestão têm cerca de 30 anos de idade e a sua evolução ao longo destes últimos anos tem sido tão dramática como irregular. A importância dos

Leia mais

GereComSaber. Disciplina de Desenvolvimento de Sistemas de Software. Sistema de Gestão de Serviços em Condomínios

GereComSaber. Disciplina de Desenvolvimento de Sistemas de Software. Sistema de Gestão de Serviços em Condomínios Universidade do Minho Conselho de Cursos de Engenharia Licenciatura em Engenharia Informática 3ºAno Disciplina de Desenvolvimento de Sistemas de Software Ano Lectivo de 2009/2010 GereComSaber Sistema de

Leia mais

1. Ambiente de Trabalho

1. Ambiente de Trabalho 1 Ambiente de Trabalho 1. Ambiente de Trabalho Ao nível do ambiente de trabalho, depois de o Excel 2007 ter introduzido novos componentes (e.g., Botão Office e Friso) e eliminado alguns dos componentes

Leia mais

Chapter 3. Análise de Negócios e Visualização de Dados

Chapter 3. Análise de Negócios e Visualização de Dados Chapter 3 Análise de Negócios e Visualização de Dados Objetivos de Aprendizado Descrever a análise de negócios (BA) e sua importância par as organizações Listar e descrever brevemente os principais métodos

Leia mais

Manual do Gestor da Informação do Sistema

Manual do Gestor da Informação do Sistema Faculdade de Engenharia da Universidade do Porto Licenciatura Informática e Computação Laboratório de Informática Avançada Automatização de Horários Manual do Gestor da Informação do Sistema João Braga

Leia mais

Programa de Parcerias e Submissão de Propostas 2014/15

Programa de Parcerias e Submissão de Propostas 2014/15 DEPARTAMENTO DE INFORMÁTICA Programa de Parcerias e Submissão de Propostas 2014/15 O Departamento de Informática (DI) da Faculdade de Ciências da Universidade de Lisboa (FCUL) procura criar e estreitar

Leia mais

Disciplina: Suprimentos e Logística II 2014-02 Professor: Roberto Cézar Datrino Atividade 3: Transportes e Armazenagem

Disciplina: Suprimentos e Logística II 2014-02 Professor: Roberto Cézar Datrino Atividade 3: Transportes e Armazenagem Disciplina: Suprimentos e Logística II 2014-02 Professor: Roberto Cézar Datrino Atividade 3: Transportes e Armazenagem Caros alunos, Essa terceira atividade da nossa disciplina de Suprimentos e Logística

Leia mais

Uma peça estratégica para o seu negócio

Uma peça estratégica para o seu negócio Uma peça estratégica para o seu negócio INFORMAÇÃO GERAL DA EMPRESA CASO DE SUCESSO EM IMPLEMENTAÇÃO BI PERGUNTAS E RESPOSTAS Fundada em 1997, Habber Tec é uma empresa especializada na oferta de soluções

Leia mais

Curso de Engenharia de Sistemas e Informática - 5º Ano. Ficha T. Prática n.º 1

Curso de Engenharia de Sistemas e Informática - 5º Ano. Ficha T. Prática n.º 1 Análise Inteligente de Dados Objectivo: Curso de Engenharia de Sistemas e Informática - 5º Ano Ficha T. Prática n.º 1 Estudo do paradigma multidimensional com introdução de uma extensão ao diagrama E/R

Leia mais

FACULDADE DE ENGENHARIA DE COMPUTAÇÃO. PROJETO FINAL I e II PLANO DE TRABALHO <NOME DO TRABALHO> <Nome do Aluno> <Nome do Orientador>

FACULDADE DE ENGENHARIA DE COMPUTAÇÃO. PROJETO FINAL I e II PLANO DE TRABALHO <NOME DO TRABALHO> <Nome do Aluno> <Nome do Orientador> FACULDADE DE ENGENHARIA DE COMPUTAÇÃO PROJETO FINAL I e II PLANO DE TRABALHO O Trabalho de Conclusão de Curso (TCC) a ser desenvolvido

Leia mais

Persistência e Banco de Dados em Jogos Digitais

Persistência e Banco de Dados em Jogos Digitais Persistência e Banco de Dados em Jogos Digitais Prof. Marcos Francisco Pereira da Silva Especialista em Engenharia de Software Jogos Digitais - Computação Gráfica 1 Agenda Vantagens de usar a abordagem

Leia mais

ISO 9000:2000 Sistemas de Gestão da Qualidade Fundamentos e Vocabulário. As Normas da família ISO 9000. As Normas da família ISO 9000

ISO 9000:2000 Sistemas de Gestão da Qualidade Fundamentos e Vocabulário. As Normas da família ISO 9000. As Normas da família ISO 9000 ISO 9000:2000 Sistemas de Gestão da Qualidade Fundamentos e Vocabulário Gestão da Qualidade 2005 1 As Normas da família ISO 9000 ISO 9000 descreve os fundamentos de sistemas de gestão da qualidade e especifica

Leia mais

Base de dados I. Uma base de dados é um simples repositório de informação relacionado com um determinado assunto ou finalidade

Base de dados I. Uma base de dados é um simples repositório de informação relacionado com um determinado assunto ou finalidade Base de dados I O que é? Uma base de dados é um simples repositório de informação relacionado com um determinado assunto ou finalidade Para que serve? Serve para gerir vastos conjuntos de informação de

Leia mais

Dadas a base e a altura de um triangulo, determinar sua área.

Dadas a base e a altura de um triangulo, determinar sua área. Disciplina Lógica de Programação Visual Ana Rita Dutra dos Santos Especialista em Novas Tecnologias aplicadas a Educação Mestranda em Informática aplicada a Educação ana.santos@qi.edu.br Conceitos Preliminares

Leia mais

Apresentação da Solução. Divisão Área Saúde. Solução: Gestão de Camas

Apresentação da Solução. Divisão Área Saúde. Solução: Gestão de Camas Apresentação da Solução Solução: Gestão de Camas Unidade de negócio da C3im: a) Consultoria e desenvolvimento de de Projectos b) Unidade de Desenvolvimento Área da Saúde Rua dos Arneiros, 82-A, 1500-060

Leia mais

Fundamentos da Análise Multidimensional

Fundamentos da Análise Multidimensional Universidade Técnica de Lisboa INSTITUTO SUPERIOR DE ECONOMIA E GESTÃO Informática e Sistemas de Informação Aplicados em Economia Fundamentos da Análise Multidimensional Fundamentos da Análise Multidimensional

Leia mais

Capítulo. Sistemas de apoio à decisão

Capítulo. Sistemas de apoio à decisão Capítulo 10 1 Sistemas de apoio à decisão 2 Objectivos de aprendizagem Identificar as alterações que estão a ter lugar na forma e função do apoio à decisão nas empresas de e-business. Identificar os papéis

Leia mais

Engenharia de Software Sistemas Distribuídos

Engenharia de Software Sistemas Distribuídos Engenharia de Software Sistemas Distribuídos 2 o Semestre de 2009/2010 FEARSe Requisitos para a 1 a entrega 18 de Março de 2010 1 Introdução O projecto conjunto das disciplinas de Engenharia de Software

Leia mais

TECNOLOGIAS DE INFORMAÇÃO E COMUNICAÇÃO

TECNOLOGIAS DE INFORMAÇÃO E COMUNICAÇÃO TECNOLOGIAS DE INFORMAÇÃO E COMUNICAÇÃO ACCESS 2010 Conceitos Básicos Ficha Informativa Professor : Vanda Pereira módulo didáctico Conceitos Básicos Necessidade das base de dados Permite guardar dados

Leia mais

Diagrama de transição de Estados (DTE)

Diagrama de transição de Estados (DTE) Diagrama de transição de Estados (DTE) O DTE é uma ferramenta de modelação poderosa para descrever o comportamento do sistema dependente do tempo. A necessidade de uma ferramenta deste tipo surgiu das

Leia mais

Prof. Marcelo Machado Cunha www.marcelomachado.com mcelobr@yahoo.com.br

Prof. Marcelo Machado Cunha www.marcelomachado.com mcelobr@yahoo.com.br Prof. Marcelo Machado Cunha www.marcelomachado.com mcelobr@yahoo.com.br Ementa Introdução a Banco de Dados (Conceito, propriedades), Arquivos de dados x Bancos de dados, Profissionais de Banco de dados,

Leia mais

Planejamento Estratégico de TI. Prof.: Fernando Ascani

Planejamento Estratégico de TI. Prof.: Fernando Ascani Planejamento Estratégico de TI Prof.: Fernando Ascani BI Business Intelligence A inteligência Empresarial, ou Business Intelligence, é um termo do Gartner Group. O conceito surgiu na década de 80 e descreve

Leia mais

Servidores Virtuais. Um servidor à medida da sua empresa, sem investimento nem custos de manutenção.

Servidores Virtuais. Um servidor à medida da sua empresa, sem investimento nem custos de manutenção. es Virtuais Um servidor à medida da sua empresa, sem investimento nem custos de manutenção. O que são os es Virtuais? Virtual é um produto destinado a empresas que necessitam de um servidor dedicado ligado

Leia mais

4 passos para uma Gestão Financeira Eficiente

4 passos para uma Gestão Financeira Eficiente 4 passos para uma Gestão Financeira Eficiente Saiba como melhorar a gestão financeira da sua empresa e manter o fluxo de caixa sob controle Ciclo Financeiro Introdução Uma boa gestão financeira é um dos

Leia mais

Software PHC com MapPoint

Software PHC com MapPoint Software PHC com MapPoint A análise de informação geográfica A integração entre o Software PHC e o Microsoft Map Point permite a análise de informação geográfica, desde mapas a rotas, com base na informação

Leia mais

Planejando o aplicativo

Planejando o aplicativo Um aplicativo do Visual FoxPro geralmente inclui um ou mais bancos de dados, um programa principal que configura o ambiente de sistema do aplicativo, além de uma interface com os usuários composta por

Leia mais

Escola Secundária de Camarate

Escola Secundária de Camarate Escola Secundária de Camarate Ano Lectivo 2014/2015 Planificação da Disciplina de Tecnologias da Informação e Comunicação Curso Profissional de Técnico Auxiliar de Saúde e Técnico de Restauração e Bar

Leia mais

Hardware (Nível 0) Organização. Interface de Máquina (IM) Interface Interna de Microprogramação (IIMP)

Hardware (Nível 0) Organização. Interface de Máquina (IM) Interface Interna de Microprogramação (IIMP) Hardware (Nível 0) Organização O AS/400 isola os usuários das características do hardware através de uma arquitetura de camadas. Vários modelos da família AS/400 de computadores de médio porte estão disponíveis,

Leia mais

DATA WAREHOUSE NO APOIO À TOMADA DE DECISÕES

DATA WAREHOUSE NO APOIO À TOMADA DE DECISÕES DATA WAREHOUSE NO APOIO À TOMADA DE DECISÕES Janaína Schwarzrock jana_100ideia@hotmail.com Prof. Leonardo W. Sommariva RESUMO: Este artigo trata da importância da informação na hora da tomada de decisão,

Leia mais

Google Sites. A g r u p a m e n t o C a m p o A b e r t o 2 0 1 0 / 2 0 1 1

Google Sites. A g r u p a m e n t o C a m p o A b e r t o 2 0 1 0 / 2 0 1 1 Google Sites A g r u p a m e n t o C a m p o A b e r t o 2 0 1 0 / 2 0 1 1 1. Google Sites A Google veio anunciar que, para melhorar as funcionalidades centrais do Grupos Google, como listas de discussão

Leia mais

Ao conjunto total de tabelas, chamamos de Base de Dados.

Ao conjunto total de tabelas, chamamos de Base de Dados. O QUE É O ACCESS? É um sistema gestor de base de dados relacional. É um programa que permite a criação de Sistemas Gestores de Informação sofisticados sem conhecer linguagem de programação. SISTEMA DE

Leia mais

Diagrama de entidades relacionamentos (abordado anteriormente) Diagrama de Fluxo de Dados (DFD)

Diagrama de entidades relacionamentos (abordado anteriormente) Diagrama de Fluxo de Dados (DFD) Diagrama de entidades relacionamentos (abordado anteriormente) Prod_Forn N N 1 Stock 1 1 N Prod_Enc N 1 N 1 Fornecedor Movimento Encomenda Diagrama de Fluxo de Dados (DFD) Ferramenta de modelação gráfica,

Leia mais

2 Diagrama de Caso de Uso

2 Diagrama de Caso de Uso Unified Modeling Language (UML) Universidade Federal do Maranhão UFMA Pós Graduação de Engenharia de Eletricidade Grupo de Computação Assunto: Diagrama de Caso de Uso (Use Case) Autoria:Aristófanes Corrêa

Leia mais

SAMUO APP: MANUAL DO ADMINISTRADOR

SAMUO APP: MANUAL DO ADMINISTRADOR as novas tecnologias ao serviço do desenvolvimento de projectos w w w. i m a d i p. c o m CABO VERDE: REALIZAÇÃO DE UMA ACÇÃO- PILOTO PARA A MELHORIA DA GESTÃO NUM GABINETE TÉCNICO SELECCIONADO OFITEC

Leia mais

Base de Dados para Administrações de Condomínios

Base de Dados para Administrações de Condomínios Base de Dados para Administrações de Condomínios José Pedro Gaiolas de Sousa Pinto: ei03069@fe.up.pt Marco António Sousa Nunes Fernandes Silva: ei03121@fe.up.pt Pedro Miguel Rosário Alves: alves.pedro@fe.up.pt

Leia mais

Análise de Sistemas. Conceito de análise de sistemas

Análise de Sistemas. Conceito de análise de sistemas Análise de Sistemas Conceito de análise de sistemas Sistema: Conjunto de partes organizadas (estruturadas) que concorrem para atingir um (ou mais) objectivos. Sistema de informação (SI): sub-sistema de

Leia mais

Oracle Hyperion Essbase

Oracle Hyperion Essbase Oracle Hyperion Essbase Guia Claudio Bonel Oracle Hyperion Essbase Guia Dedicatória Este Livro é dedicado a minha família. 2 Guia Oracle Hyperion Essbase Sumário Agradecimentos Introdução Capítulo 1: OLAP

Leia mais

Construção de um WebSite. Luís Ceia

Construção de um WebSite. Luís Ceia Construção de um WebSite Para a construção de um WebSite convém ter-se uma planificação cuidada. Para tal podemos considerar seis etapas fundamentais: 1. Planeamento 2. Desenvolvimento de Conteúdos 3.

Leia mais

Aprend.e Sistema integrado de formação e aprendizagem

Aprend.e Sistema integrado de formação e aprendizagem Aprend.e Sistema integrado de formação e aprendizagem Pedro Beça 1, Miguel Oliveira 1 e A. Manuel de Oliveira Duarte 2 1 Escola Aveiro Norte, Universidade de Aveiro 2 Escola Aveiro Norte, Departamento

Leia mais

Gestão da Informação

Gestão da Informação Gestão da Informação Aplicações de suporte à Gestão da Informação na empresa Luis Borges Gouveia, lmbg@ufp.pt Aveiro, Fevereiro de 2001 Sistemas de informação para empresas Manutenção e exploração de sistemas

Leia mais

Utilização do SOLVER do EXCEL

Utilização do SOLVER do EXCEL Utilização do SOLVER do EXCEL 1 Utilização do SOLVER do EXCEL José Fernando Oliveira DEEC FACULDADE DE ENGENHARIA DA UNIVERSIDADE DO PORTO MAIO 1998 Para ilustrar a utilização do Solver na resolução de

Leia mais

SAD orientado a DADOS

SAD orientado a DADOS Universidade do Contestado Campus Concórdia Curso de Sistemas de Informação Prof.: Maico Petry SAD orientado a DADOS DISCIPLINA: Sistemas de Apoio a Decisão SAD orientado a dados Utilizam grandes repositórios

Leia mais

OFICIAL DA ORDEM MILITAR DE CRISTO MEDALHA DE EDUCAÇÃO FÍSICA E BONS SERVIÇOS. Circular n.º 029/2014 PORTAL FPT Abertura aos atletas

OFICIAL DA ORDEM MILITAR DE CRISTO MEDALHA DE EDUCAÇÃO FÍSICA E BONS SERVIÇOS. Circular n.º 029/2014 PORTAL FPT Abertura aos atletas Circular n.º 029/2014 PORTAL FPT Abertura aos atletas Exmo. Sr. Presidente, Após muitos meses de desenvolvimento e melhorias contínuas na nova plataforma informática onde se inclui o amplamente divulgado

Leia mais

Rock In Rio - Lisboa

Rock In Rio - Lisboa Curso de Engenharia Informática Industrial Rock In Rio - Lisboa Elaborado por: Ano Lectivo: 2004/05 Tiago Costa N.º 4917 Turma: C Gustavo Graça Patrício N.º 4757 Turma: C Docente: Professora Maria Estalagem

Leia mais

Engenharia de Software e Sistemas Distribuídos. Enunciado Geral do Projecto

Engenharia de Software e Sistemas Distribuídos. Enunciado Geral do Projecto LEIC-A, LEIC-T, LETI, MEIC-T, MEIC-A Engenharia de Software e Sistemas Distribuídos 2 o Semestre 2014/2015 Enunciado Geral do Projecto O que se segue é uma descrição geral do domínio do projecto a desenvolver

Leia mais

Gestão de Equipas de Vendas

Gestão de Equipas de Vendas Gestão de Equipas de Vendas Análise Comercial Business Intelligence Gestão de Desempenho Atinjo os meus objectivos comerciais? Quais os vendedores com melhor desempenho? A função comercial é o motor de

Leia mais

TECNOLOGIA DA INFORMAÇÃO - TI Elaborado e adaptado por: Prof.Mestra Rosimeire Ayres

TECNOLOGIA DA INFORMAÇÃO - TI Elaborado e adaptado por: Prof.Mestra Rosimeire Ayres TECNOLOGIA DA INFORMAÇÃO - TI Elaborado e adaptado por: Prof.Mestra Rosimeire Ayres Aula 6 Fazendo BI NO EXCEL USANDO TABELA DINÂMICA EXCEL PARA TOMADA DE DECISÕES A ferramenta é nada, o talento é tudo.

Leia mais

DEPARTAMENTO DE MATEMÁTICA E CIÊNCIAS EXPERIMENTAIS (GRUPO INFORMÁTICA) Ano Letivo de 2014/2015 MÓDULO 1 FOLHA DE CÁLCULO

DEPARTAMENTO DE MATEMÁTICA E CIÊNCIAS EXPERIMENTAIS (GRUPO INFORMÁTICA) Ano Letivo de 2014/2015 MÓDULO 1 FOLHA DE CÁLCULO Ensino Regular Diurno Disciplina: T.I.C. Professores: Margarida Afonso Curso Profissional - Técnico de Auxiliar de Saúde Ano: 10.º Turma(s): TAS MÓDULO 1 FOLHA DE CÁLCULO OBJECTIVOS Indicar as principais

Leia mais

PHC Serviços CS. A gestão de processos de prestação de serviços

PHC Serviços CS. A gestão de processos de prestação de serviços PHC Serviços CS A gestão de processos de prestação de serviços A solução que permite controlar diferentes áreas de uma empresa: reclamações e respectivo tratamento; controlo de processos e respectivos

Leia mais

Banco de Dados Microsoft Access: Criar tabelas

Banco de Dados Microsoft Access: Criar tabelas Banco de Dados Microsoft Access: Criar s Vitor Valerio de Souza Campos Objetivos do curso 1. Criar uma no modo de exibição Folha de Dados. 2. Definir tipos de dados para os campos na. 3. Criar uma no modo

Leia mais

Tutorial: criação de uma Ficha de Voluntário online

Tutorial: criação de uma Ficha de Voluntário online Tutorial: criação de uma Ficha de Voluntário online A pedido da Coordenação Nacional, o grupo de Coordenação Distrital de Coimbra elaborou este pequeno tutorial que ensina como criar um formulário online

Leia mais

INSTRUÇÃO DE TRABALHO PARA INFORMAÇÕES GERENCIAIS

INSTRUÇÃO DE TRABALHO PARA INFORMAÇÕES GERENCIAIS INSTRUÇÃO DE TRABALHO PARA INFORMAÇÕES GERENCIAIS Asia Shipping Transportes Internacionais Ltda. como cópia não controlada P á g i n a 1 7 ÍNDICE NR TÓPICO PÁG. 1 Introdução & Política 2 Objetivo 3 Responsabilidade

Leia mais

Banco de Dados Microsoft Access: Criar tabelas. Vitor Valerio de Souza Campos

Banco de Dados Microsoft Access: Criar tabelas. Vitor Valerio de Souza Campos Banco de Dados Microsoft Access: Criar tabelas Vitor Valerio de Souza Campos Objetivos do curso 1. Criar uma tabela no modo de exibição Folha de Dados. 2. Definir tipos de dados para os campos na tabela.

Leia mais

Guia de Estudo Folha de Cálculo Microsoft Excel

Guia de Estudo Folha de Cálculo Microsoft Excel Tecnologias da Informação e Comunicação Guia de Estudo Folha de Cálculo Microsoft Excel Estrutura geral de uma folha de cálculo: colunas, linhas, células, endereços Uma folha de cálculo electrónica ( electronic

Leia mais

Apresentação de Solução

Apresentação de Solução Apresentação de Solução Solução: Gestão de Altas Hospitalares Unidade de negócio da C3im: a) Consultoria e desenvolvimento de de Projectos b) Unidade de Desenvolvimento Área da Saúde Rua dos Arneiros,

Leia mais

Microsoft Access: Criar consultas para um novo banco de dados. Vitor Valerio de Souza Campos

Microsoft Access: Criar consultas para um novo banco de dados. Vitor Valerio de Souza Campos Microsoft Access: Criar consultas para um novo banco de Vitor Valerio de Souza Campos Conteúdo do curso Visão geral: consultas são essenciais Lição: inclui sete seções Tarefas práticas sugeridas Teste.

Leia mais