BR112020007205A2

BR112020007205A2 - uso de um modelo de objeto de dados heterogêneos para facilitar a construção de visualizações de dados

Info

Publication number: BR112020007205A2
Application number: BR112020007205-2A
Authority: BR
Inventors: Justin Talbot; Roger Hau; Daniel Cory; Jiyoung Oh; Teresa Roberts
Original assignee: Tableau Software, Inc.
Priority date: 2017-10-09
Filing date: 2018-08-01
Publication date: 2020-10-13
Also published as: AU2021204978B2; EP3695289B1; CA3078997C; CN111542813B; AU2018347838A1; JP2020537251A; CN111542813A; WO2019074570A1; US20190108272A1; CA3078997A1; JP7345458B2; US11620315B2; AU2021204978A1; EP3695289A1; AU2018347838B2

Abstract

A presente invenção se refere ao processo que recebe uma especificação visual, que especifica fontes de dados, variáveis visuais e campos de dados a partir das fontes de dados. Cada variável visual é associada a um ou mais campos de dados e cada campo de dados é uma dimensão ou uma medida. Para cada medida m, o processo identifica um conjunto R(m) que consiste em dimensões que são acessíveis a partir da medida por uma sequência de relações de muitos para um em um modelo de objeto para as fontes de dados. Para cada conjunto distinto R, o processo forma um conjunto de campos de dados S, que consiste em cada dimensão em R e cada medida m para as quais R(m) = R. Para cada conjunto S e para cada medida no conjunto S, o processo agrega os valores da medida de acordo com as dimensões em S. O processo constrói uma visualização de dados de acordo com os campos de dados no conjunto S e as variáveis visuais às quais são associados.

Description

“USO DE UM MODELO DE OBJETO DE DADOS HETEROGÊNEOS PARA FACILITAR A CONSTRUÇÃO DE VISUALIZAÇÕES DE DADOS” CAMPO DA TÉCNICA

[001] As implementações reveladas se referem em geral à visualização de dados e, mais especificamente, à análise visual interativa de um conjunto de dados com uso de um modelo de objeto do conjunto de dados.

ANTECEDENTES

[002] Os aplicativos de visualização de dados permitem que um usuário entenda um conjunto de dados visualmente, incluindo distribuição, tendências, valores atípicos e outros fatores que são importantes para tomar decisões de negócios. Alguns elementos de dados devem ser computado com base nos dados a partir do conjunto de dados selecionado. Por exemplo, as visualizações de dados usam frequentemente as somas para agregar os dados. Alguns aplicativos de visualização de dados permitem que um usuário especifique um “Nível de Detalhes” (LOD), que pode ser usado para os cálculos de agregado. No entanto, a especificação de um único Nível de Detalhes para uma visualização de dados é insuficiente para desenvolver certos cálculos.

[003] Alguns pedidos de visualização de dados fornecem uma interface de usuário que permite que os usuários desenvolvam visualizações a partir de uma fonte de dados selecionando os campos de dados e colocando os mesmos em regiões de interface de usuário específicas para definir indiretamente uma visualização de dados. Consulte, por exemplo, Pedido de Patente nº de série U.S. 10/453,834, depositado em 2 de junho de 2003, intitulado “Computer Systems and Methods for the Query and Visualization of Multidimensional Databases”, agora, Patente nº U.S. 7.089.266, que é incorporado a título de referência ao presente documento em sua totalidade. No entanto, quando há fontes de dados complexas e/ou múltiplas fontes de dados, pode não estar claro qual tipo de visualização de dados é gerado (se houver) com base nas seleções de um usuário.

SUMÁRIO

[004] A geração de uma visualização de dados que combina os dados das múltiplas tabelas pode ser desafiadora, especialmente quando há múltiplas tabelas de fatos. Em alguns casos, a mesma pode ajudar a construir um modelo de objeto dos dados antes de gerar as visualizações de dados. Em alguns casos, uma pessoa é um especialista particular em dados e essa pessoa cria o modelo de objeto. Através do armazenamento das relações em um modelo de objeto, um aplicativo de visualização de dados pode aproveitar essas informações para ajudar todos os usuários que acessam os dados, mesmo se não forem especialistas.

[005] Un objeto é uma coleção de atributos nomeados. Um objeto corresponde frequentemente a um conceito, evento ou objeto real, como um Loja. Os atributos são descrições do objeto que estão conceitualmente em uma relação 1:1 com o objeto. Desse modo, um objeto de Loja pode ter um único [Nome de Gerente] ou [Contagem de Funcionários] associado ao mesmo. Em um nível físico, um objeto é frequentemente armazenado como uma fileira em uma tabela relacional, ou como um objeto em JSON.

[006] Uma classe é uma coleção de objetos que compartilham os mesmos atributos. Deve ser analiticamente relevante comparar os objetos em uma classe e agregar os mesmos. Em um nível físico, uma classe é frequentemente armazenada como uma tabela relacional ou como um arranjo de objetos em JSON.

[007] Um modelo de objeto é um conjunto de classes e um conjunto de relações de muitos para um entre os mesmos. Classes que são relacionadas por relações 1-para-1 são conceitualmente tratadas como uma única classe, mesmo que sejam significativamente distintas para um usuário. Além disso, as classes que são relacionadas por relações 1-para-1 podem ser apresentadas como classes distintas na interface de usuário de visualização de dados. As relações de muitos-para-muitos são conceitualmente dividias em duas relações de muitos para um pela adição de uma tabela associativa que captura a relação.

[008] Uma vez que um modelo de classe é construído, um aplicativo de visualização de dados pode ajudar um usuário de várias maneiras. Em algumas implementações, com base nos campos de dados já selecionados e colocados em prateleiras na interface de usuário, o aplicativo de visualização de dados pode recomendar campos adicionais ou limitar quais ações podem ser tomadas para impedir combinações indesejadas. Em algumas implementações, o aplicativo de visualização de dados permite a um usuário liberdade considerável em campos de seleção, e usa o modelo de objeto para desenvolver uma ou mais visualizações de dados de acordo com o que o usuário selecionou.

[009] De acordo com algumas implementações, um processo gera visualizações de dados. O processo é realizado em um computador que tem um ou mais processadores e memória que armazena um ou mais programas configurados para execução por um ou mais processadores. O processo recebe uma especificação visual, que específica uma ou mais fontes de dados, uma pluralidade de variáveis visuais, e uma pluralidade de campos de dados a partir de uma ou mais fontes de dados. Cada variável visual é associada a um ou mais dos campos de dados e cada um dos campos de dados é identificado como uma dimensão d ou uma medida m. Em algumas implementações, a especificação visual é uma estrutura de dados que é preenchida com base nas seleções de usuário na interface de usuário. Por exemplo, um usuário pode deslocar os campos de uma paleta de campos de dados para a prateleira de linhas, a prateleira de colunas ou uma prateleira de codificação (por exemplo, codificação de tamanho ou cor). Cada uma das prateleiras corresponde a uma variável visual na especificação visual, e os campos de dados nas prateleiras são armazenados como parte da especificação visual. Em alguns casos, há dois ou mais campos de dados associados à mesma prateleira, assim, a variável visual correspondente tem dois ou mais campos de dados associados. Quando há dois ou mais campos de dados associados a uma variável visual, há tipicamente uma ordem específica. Em alguns casos, o mesmo campo de dados é associado a duas ou mais variáveis visuais distintas. Em geral, uma visualização de dados individual não usa todas as variáveis visuais disponíveis. Ou seja, a especificação visual inclui tipicamente uma ou mais variáveis visuais adicionais que não são associadas a quaisquer campos de dados a partir de uma ou mais fontes de dados. Em algumas implementações, cada uma das variáveis visuais é um dentre: atributo de linhas, atributo de colunas, atributo de filtragem, codificação de cor, codificação de tamanho, codificação de formato ou codificação de rótulo.

[010] Em muitos casos, as medidas são campos numéricos e as dimensões são campos de dados com um tipo de dados em coluna. De modo mais importante, os rótulos “medida” e “dimensão” indicam qual campo de dados é usado.

[011] Para cada medida m dos campos de dados, o processo identifica um respectivo conjunto de dimensões acessíveis R(m) que consiste em todas as dimensões d, dos campos de dados, que são acessíveis a partir da respectiva medida m por uma sequência de relações de muitos para um em um modelo de objeto predefinido para a uma ou mais fontes de dados. Nota-se que a sequência pode ser de comprimento zero, representando o caso em que a dimensão d e a medida m estão na mesma classe. Em algumas implementações, uma dimensão d é acessível a partir de uma medida m quando a dimensão d e a medida m estão em uma mesma classe no modelo de objeto predefinido ou, também, a medida m é um atributo de uma primeira classe C1 no modelo de objeto predefinido, a dimensão d é um atributo de uma n-ésima classe Cn no modelo de objeto, com n > 2, e há uma sequência de zero ou mais classes intermediárias C2, ..., Cn-1 no modelo de objeto predefinido de modo que haja uma relação de muitos para um entre as classes Ci e Ci+1 para cada i = 1, 2,...,nA1.

[012] Nota-se que há também o caso trivial em que R(m) = à, devido ao fato de não há dimensões associadas às variáveis visuais ou há algumas medidas que não podem alcançar qualquer uma das dimensões. Esse é um conjunto válido de dimensões acessíveis.

[013] A construção dos conjuntos de dimensões acessíveis resulta em uma divisão das medidas. Especificamente, a relação — definida por my — m, iff Rim) = R(m,z) é uma relação de equivalência. Na maioria dos casos, há apenas uma divisão (isto é, R(m) é o mesmo para todas as medidas), mas em alguns casos, há mais que uma divisão.

[014] Para cada conjunto de dimensões acessíveis distinto R, o processo forma um respectivo conjunto de campos de dados S. O conjunto S consiste em cada dimensão em R e cada medida m dos campos de dados para as quais R(m) = R. Em geral, cada um dos conjuntos de campos de dados inclui pelo menos uma medida. Em algumas implementações, quaisquer conjuntos de campos de dados sem medidas são ignorados. Em algumas implementações, quando um conjunto de campos de dados S é identificado e não possui medidas, o aplicativo de visualização de dados gera um erro. Em algumas implementações, o aplicativo de visualização de dados constrói visualizações de dados adicionais para cada um dos conjuntos de campos de dados S que não possui medidas (além das visualizações de dados criadas para cada um dos conjuntos de campos de dados S que não incluem uma ou mais medidas).

[015] Para cada conjunto de campos de dados S e para cada medida m no respectivo conjunto de campos de dados S, o processo centraliza os valores da medida m para um nível de detalhes especificados pelas respectivas dimensões no respectivo conjunto de campos de dados S. O processo, então, constrói uma respectiva visualização de dados de acordo com os campos de dados no respectivo conjunto de campos de dados S e de acordo com as respectivas variáveis visuais às quais cada um dos campos de dados em S é associado.

[016] Em algumas implementações, a construção da respectiva visualização de dados inclui recuperar tuplos de dados a partir de uma ou mais fontes de dados com uso de uma ou mais consultas de base de dados geradas a partir de especificação visual. Por exemplo, para fontes de dados de SQL, o processo constrói uma consulta de SQL e envia a consulta para motor de base de dados de SQL apropriado. Em alguns casos, os tuplos incluem dados agregados de acordo com as respectivas dimensões no respectivo conjunto de campos de dados S. Isto é, a agregação é realizada pela fonte de dados.

[017] Em geral, a visualização de dados gerada é exibida em uma interface gráfica de usuário no computador (por exemplo, a interface de usuário para o aplicativo de visualização de dados). Em algumas implementações, a exibição da visualização de dados inclui gerar uma pluralidade de marcações visuais, em que cada marcação corresponde a um respectivo tuplo recuperado a partir de uma ou mais fontes de dados. Em algumas implementações, a interface gráfica de usuário inclui uma região de visualização de dados, e o processo exibe a visualização de dados na região de visualização de dados.

[018] Em algumas implementações, a centralização de valores de uma medida m para um nível de detalhes especificados pelas respectivas dimensões no respectivo conjunto de campos de dados S inclui dividir as linhas de uma tabela de dados que contém a medida m nos grupos de acordo com as respectivas dimensões no respectivo conjunto de campos de dados S, e computar um único valor agregado para cada grupo.

[019] Em algumas implementações, o único valor agregado é computado com uso de uma das funções agregadas SOMA, CONTAG, CONTAGD (contagem de elementos distintos), MÍN, MÁX, MÉDIA (média ponderada), MEDIAN, STDEV (desvio padrão), VAR (variância), PERCENTILE (por exemplo, quartil), ATTR, STDEVP e VARP. Em algumas implementações, o operador de agregação de ATTR() retorna o valor da expressão se tiver um único valor para todas as linhas, e retorna um asterisco caso contrário. Em algumas implementações, os operadores de agregação de STDEVP e VARP retornam os valores com base em uma população orientada ou em toda a população. Algumas implementações incluem mais ou diferentes operadores de agregação a partir daqueles listados aqui. Algumas implementações usam nomes alternativos para os operadores de agregação.

[020] Em algumas implementações, os campos de dados são classificados como “dimensões” ou “medidas” com base em como estão sendo usados. Uma dimensão divide o conjunto de dados, enquanto uma medida agrega os dados em cada uma das divisões. A parti de um conjunto intermediário de SQL, as dimensões são elementos na seção de AGRUPAR POR, e as medidas são os elementos na seção SELECIONAR. Comumente, os dados categóricos distintos (por exemplo, um campo que contém estados, regiõêês ou nomes de produto) são usados para divisão, enquanto os dados numéricos contínuos (por exemplo, lucros ou vendas) são usados para agregação (por exemplo, computação de uma soma). No entanto, todos os tipos de campos de dados podem ser usados como dimensões ou medidas. Por exemplo, um campo categórico distinto que contém nomes de produto pode ser usado como uma medida aplicando-se a função de agregado CONTAGD (contagem distinta). Por outro lado, os dados numéricos que representam alturas de pessoas podem ser usados como uma dimensão, dividindo as pessoas por altura ou faixas de alturas. Algumas funções agregadas, como SOMA, podem apenas ser aplicadas aos dados numéricos. Em algumas implementações, o aplicativo atribui a cada campo uma função padrão (dimensão ou medida) com base no tipo de dados brutos do campo, mas permite que um usuário substitua essa função. Por exemplo, alguns aplicativos atribuem uma função padrão de “dimensão” aos campos de dados categóricos

(coluna) e uma função padrão de “medida” aos campos numéricos. Em algumas implementações, os campos de data são usados como dimensões por padrão, devido ao fato de que são comumente usados para dividir os dados em faixas de data.

[021] A classificação como dimensões ou medidas também se plica às expressões calculadas. Por exemplo, uma expressão como ANO([Data de Compra]) é comumente usada como uma dimensão, dividindo os dados subjacentes em anos. Como um outro exemplo, considerar uma fonte de dados que inclui um campo de Código de Produto (como uma coluna de caractere). Se os primeiros três caracteres do Código de Produto codificarem o tipo de produto, então, a expressão ESQUERDA([Código de Produto], 3) deve ser usada como uma dimensão para dividir os dados em tipos de produto.

[022] Algumas implementações permitem que os usuários especifiquem múltiplos níveis de detalhes com uso da interface gráfica de usuário interativa. Alguns exemplos usam dois níveis de detalhes, mas as implementações permitem tipicamente um número ilimitado de níveis de detalhes. Em alguns casos, os dados calculados de acordo com a agregação em um nível de detalhes são usados em uma segunda agregação em um segundo nível de detalhes. Em algumas implementações, a visualização de dados inclui um “nível de visualização de detalhes”, que é usado por padrão para computar agregações. Esse é o nível de detalhes que é visível na visualização de dados final. As implementações também fornecem o nível de expressões de detalhes, que permite que um usuário especifique um nível particular de detalhes em um contexto específico.

[023] Algumas implementações designaram regiões de prateleira que determinam as características de uma visualização de dados desejada. Por exemplo, algumas implementações incluem uma região de prateleira de fileira e uma região de prateleira de coluna. Um usuário coloca nomes de campo nessas regiões de prateleira (por exemplo, por campos de arrastamento de uma região de esquema), e os nomes de campo definem as características de visualização de dados. Por exemplo, um usuário pode escolher um gráfico de barras vertical, com uma coluna para cada valor distinto de um campo colocado na região de prateleira de coluna. A altura de cada barra é definida por um outro campo colocado na região de prateleira de fileira.

[024] De acordo com algumas implementações, um método para gerar e exibir uma visualização de dados é realizado em um computador. O computador tem um visor, um ou mais processadores, e memória que armazena um ou mais programas configurados para execução por um ou mais processadores. O processo exibe uma interface gráfica de usuário no visor. A interface gráfica de usuário inclui uma região de informações de esquema que inclui uma pluralidade de campos a partir de uma base de dados. O processo recebe a entrada de usuário na interface gráfica de usuário para especificar uma primeira agregação. A especificação da primeira agregação agrupa os dados por um primeiro conjunto de um ou mais campos da pluralidade de campos e identifica um primeiro campo de saída agregado que é criado pela primeira agregação. O processo também recebe a entrada de usuário na interface gráfica de usuário para especificar uma segunda agregação. Em alguns casos, a especificação da segunda agregação faz referência à primeira agregação. A segunda agregação agrupa os dados por um segundo conjunto de um ou mais campos. O segundo conjunto de campos é selecionado a partir da pluralidade de campos e do primeiro campo de saída agregado. O segundo conjunto de campos é diferente do primeiro conjunto de campos. O processo constrói uma especificação visual com base nas especificações da primeira e segunda agregações.

[025] Em algumas implementações, o processo inclui recuperar tuplos de dados a partir da base de dados com uso de uma ou mais consultas de base de dados geradas a partir de especificação visual. Em algumas implementações, os tuplos incluem dados calculados com base na segunda agregação. Em algumas implementações, o processo inclui exibir uma visualização de dados que corresponde à especificação visual, em que a visualização de dados inclui os dados calculados com base na segunda agregação. Em algumas implementações, a visualização de dados exibida inclui múltiplas marcações visuais, sendo cada marcação correspondente a um respectivo tuplo recuperado da base de dados. Em algumas implementações, a interface gráfica de usuário inclui uma região de visualização de dados e o processo exibe a visualização de dados na região de visualização de dados.

[026] Em algumas implementações, a interface gráfica de usuário inclui uma prateleira de colunas e uma prateleira de linhas. Em algumas implementações, o processo detecta ações de usuário para associar um ou mais primeiros campos da pluralidade de campos com a prateleira de colunas e para associar um ou mais segundos campos da pluralidade de campos com a prateleira de linhas. O processo, então, gera uma tabela visual na região de visualização de dados de acordo com as ações de usuário. A tabela visual inclui um ou mais painéis, em que cada painel tem um eixo geométrico x definido com base nos dados para o um ou mais primeiros campos associados à prateleira de colunas, e cada painel tem um eixo geométrico y definido com base nos dados para o um ou mais segundos campos associados à prateleira de linhas. Em algumas implementações, o processo recebe entrada de usuário para associar a segunda agregação à prateleira de colunas ou à prateleira de linhas.

[027] Em algumas implementações, o processo recupera tuplos da base de dados de acordo com os campos associados às prateleiras de linhas e colunas e exibe os tuplos recuperados como marcações visuais na tabela visual. Em algumas implementações, cada operador para a primeira e a segunda agregações é um dentre SOMA, CONTAG, CONTAGD, MÍN, MÁX, MÉDIA, MEDIAN, ATTR, PERCENTILE, STDEV, STDEVP, VAR ou VARP.

[028] Em alguns casos, o primeiro campo de saída agregado é usado como uma dimensão e é incluído no segundo conjunto.

[029] Em algumas implementações, o primeiro campo de saída agregado é usado como uma medida e a segunda agregação aplica um dos operadores de agregação ao primeiro campo de saída agregado. Por exemplo, em alguns casos, a segunda agregação computa médias de valores para o primeiro campo de saída agregado.

[030] Em algumas implementações, o processo exibe uma interface gráfica de usuário em um visor de computador. A interface gráfica de usuário inclui uma região de informações de esquema e uma região de visualização de dados. A região de informações de esquema inclui múltiplos nomes de campo, em que cada nome de campo é associado a um campo de dados das bases de dados específicas. A região de visualização de dados inclui uma pluralidade de regiões de prateleira que determinam as características da visualização de dados. Cada região de prateleira é configurada para receber o posicionamento de usuário de um ou mais dos nomes de campo da região de informações de esquema. O processo constrói a especificação visual de acordo com a seleção de usuário de um ou mais do nomes de campo e posicionamento de usuário de cada nome de campo selecionado por usuário em uma respectiva região de prateleira na região de visualização de dados.

[031] Em algumas implementações, a visualização de dados compreende um painel de instrumentos que inclui uma pluralidade de visualizações de dados de componente distintas. A especificação visual compreende uma pluralidade de especificações visuais de componente, e cada visualização de dados de componente tem como base uma respectiva das especificações visuais de componente.

[032] Em algumas implementações, as características de visualização de dados definidas pela especificação visual incluem tipo de marcação e zero ou mais codificações das marcações. Em algumas implementações, o tipo de marcação é um dentre: gráfico de barra, gráfico de linha, gráfico de dispersão, tabela de texto ou mapa. Em algumas implementações, as codificações são selecionadas a partir de tamanho de marcação, cor de marcação e rótulo de marcação.

[033] De acordo com algumas implementações, um sistema para gerar visualizações de dados inclui um ou mais processadores, memória e um ou mais programas armazenados na memória. Os programas são configurados para execução por um ou mais processadores. Os programas incluem instruções para realizar qualquer um dos métodos descritos no presente documento.

[034] De acordo com algumas implementações, um meio de armazenamento legível por computador não transitório armazena um ou mais programas configurados para execução por um sistema de computador que tem um ou mais processadores e memória. O um ou mais programas incluem instruções para realizar qualquer um dos métodos descritos no presente documento.

[035] Desse modo, os métodos, sistemas e interfaces de usuário gráficas são fornecidos para análise visual interativa de um conjunto de dados.

BREVE DESCRIÇÃO DOS DESENHOS

[036] Para um melhor entendimento das implementações mencionadas anteriormente da invenção bem como implementações adicionais, deve-se fazer referência à Descrição de Implementações abaixo, em conjunto com os seguintes desenhos em que os números de referência similares se referem às partes correspondentes ao longo de todas as figuras.

[037] A Figura 1 ilustra conceitualmente um processo de construção de uma visualização de dados de acordo com algumas implementações.

[038] A Figura 2 é um diagrama de blocos de um dispositivo de computação de acordo com algumas implementações.

[039] A Figura 3 é um diagrama de blocos de um servidor de visualização de dados de acordo com algumas implementações.

[040] A Figura 4 fornece uma interface de usuário de visualização de dados exemplificativa de acordo com algumas implementações.

[041] A Figura 5 ilustra um modelo de objeto simples com três classes, de acordo com algumas implementações.

[042] A Figura 6 ilustrou uma única classe que tem duas relações distintas com uma outra classe, de acordo com algumas implementações.

[043] As Figuras 7A e 7B ilustram um conjunto bowtie de relações entre quatro classes, e visualizações de dados que podem ser apresentadas nesse contexto, de acordo com algumas implementações.

[044] A Figura 8 ilustrta um modelo de objeto muito simples em que uma visualização de dados é criada para uma única classe, de acordo com algumas implementações.

[045] As Figuras 9A a 9C ilustram a construção de visualizações de dados que incluem dimensões a partir de duas classes distintas que não são hierarquicamente embutidas, de acordo com algumas implementações.

[046] As Figuras 10 e 11 ilustram seleção de usuário de medidas que são atributos de duas ou mais classes distintas em um modelo de objeto, de acordo com algumas implementações.

[047] As Figuras 12A a 12C ilustram a seleção de usuário de um ou mais medidas que estão hierarquicamente acima de uma ou mais dimensões selecionadas, e visualizações de dados correspondentes, de acordo com algumas implementações.

[048] As Figuras 13A a 13D ilustram a seleção de usuário de medidas e dimensões de duas ou mais classes em um modelo de dados que não são conectadas no modelo, e as visualizações de dados correspondentes que podem ser gerados, de acordo com algumas implementações.

[049] As Figuras 14A a 14C e 15 ilustram a seleção de usuário de medidas de duas ou mais classes distintas em um modelo de objeto, com pelo menos uma classe hierárquica que conecta as mesmas, bem como visualizações de dados que podem ser geradas para esse cenário, de acordo com algumas implementações.

[050] A Figura 16 fornece descrições de pseudocódigo para determinar quais dimensões em um modelo de objeto são acessíveis, de acordo com algumas implementações.

[051] A Figura 17 é uma captura de tela de uma janela de interface de usuário para definir filtros dentro de um aplicativo de visualização de dados, de acordo com algumas implementações.

[052] As Figuras 18A a 18C fornecem um fluxograma de um processo que usa um modelo de objeto ao construir as visualizações de dados, de acordo com algumas implementações.

[053] Os numerais de referência similares se referem às partes correspondentes ao longo de todos os desenhos.

[054] Será feita agora referência em detalhes às implementações, cujos exemplos são ilustrados nos desenhos anexos. Na seguinte descrição detalhada, vários detalhes específicos são apresentados a fim de fornecer um entendimento completo da presente invenção. No entanto, ficará evidente àquele de habilidade comum na técnica que a presente invenção pode ser praticada sem esses detalhes específicos.

DESCRIÇÃO DOS DESENHOS

[055] Algumas implementações de um aplicativo interativo de visualização de dados usam uma interface de usuário de visualização de dados 102 para desenvolver uma especificação visual 104, conforme mostrado na Figura 1. A especificação visual identifica uma ou mais fontes de dados 106, que podem ser armazenadas localmente (por exemplo, no mesmo dispositivo que exibe a interface de usuário 102) ou podem ser armazenadas externamente (por exemplo, em um servidor de base de dados ou na nuvem). A especificação visual 104 também inclui variáveis visuais. As variáveis visuais especificam características da visualização de dados desejada indiretamente de acordo com os campos de dados selecionados a partir das fontes de dados 106. Em particular, um usuário atribui zero ou mais campos de dados a cada uma das variáveis visuais, e os valores dos campos de dados determinam a visualização de dados que será exibida.

[056] Na maioria dos casos, nem todas as variáveis visuais são usadas. Em alguns casos, algumas das variáveis visuais têm dois ou mais campos de dados atribuídos. Nesse cenário, a ordem dos campos de dados atribuídos para a variável visual (por exemplo, a ordem na qual os campos de dados foram atribuídos à variável visual pelo usuário) afeta tipicamente como a visualização de dados é gerada e exibida.

[057] Algumas implementações usam um modelo de objeto 108 para desenvolver as visualizações de dados apropriadas. Em alguns casos, um modelo de objeto se aplica a uma fonte de dados (por exemplo, uma base de dados de SQL ou um arquivo de planilha), mas um modelo de objeto pode abranger duas ou mais fontes de dados. Tipicamente, as fontes de dados não relacionadas têm modelos de objeto distintos. Em alguns casos, o modelo de objeto imita intimamente o modelo de dados das fontes de dados físicos (por exemplo, classes no modelo de objeto que corresponde às tabelas em uma base de dados de SQL). No entanto, em alguns casos, o modelo de objeto é mais normalizado (ou menos normalizado) que as fontes de dados físicos. Um modelo de objeto agrupa em conjunto os atributos (por exemplo, campos de dados) que têm uma relação um para um entre si para formar classes, e identifica relações de muitos para um entre as classes. Nas ilustrações abaixo, as relações de muitos para um são ilustradas com setas, com o lado de “muitos” de cada relação verticalmente menor que o lado de “um” da relação. O modelo de objeto também identifica cada um dos campos de dados (atributos) como uma dimensão ou uma medida. No mencionado a seguir, a letra “D” (ou “d”) é usada para representar uma dimensão, enquanto a letra “M” (ou “m”) é usada para representar uma medida. Quando um modelo de objeto 108 é construído, o mesmo pode facilitar a construção de visualizações de dados com base nos campos de dados que um usuário seleciona. Devido ao fato de que um único modelo de dados pode ser usado por um número ilimitado de outras pessoas, a construção do modelo de objeto para uma fonte de dados é comumente delegada a uma pessoa que é um especialista relativo da fonte de dados,

[058] À medida que um usuário adiciona os campos de dados à especificação visual (por exemplo, indiretamente pelo uso da interface gráfica de usuário para colocar os campos de dados nas prateleiras), o aplicativo de visualização de dados 222 (ou aplicativo de web 322) agrupa (110) em conjunto com os campos de dados selecionados pelo usuário de acordo com o modelo de objeto 108. Tais grupos são chamados de conjuntos de campos de dados 294. Em muitos casos, todos os campos de dados selecionados pelo usuário estão em um único conjunto de campos de dados

294. Em alguns casos, há dois ou mais conjuntos de campos de dados 294. Cada medida m está em exatamente um conjunto de campos de dados 294, mas cada dimensão d pode estar em mais que um conjunto de campos de dados 294. O processo para construir os conjuntos de campos de dados 294 é descrito em mais detalhes abaixo em relação às Figuras 10, 11, 138A a 13C, 14A-14C, 15, 16 e 18Aa 18C.

[059] O aplicativo de visualização de dados 222 (ou aplicativo de web 322) consulta (112) as fontes de dados 106 para o primeiro conjunto de campos de dados 294 e, então, gera uma primeira visualização de dados 122 correspondente aos dados recuperados. A primeira visualização de dados 122 é construída de acordo com as variáveis visuais 282 na especificação visual 104 que tem campos de dados atribuídos 284 do primeiro conjunto de campos de dados 294. Quando há apenas um conjunto de campos de dados 294, todas as informações na especificação visual 104 são usadas para desenvolver a primeira visualização de dados 122. Quando há dois ou mais conjuntos de campos de dados 294, a primeira visualização de dados 122 tem como base uma primeira subespecificação visual que consiste em todas as informações relevantes ao primeiro conjunto de campos de dados 294. Por exemplo, supõe-se que a especificação visual original 104 inclua um filtro que usa um campo de dados f. Se o campo f estiver incluído no primeiro conjunto de campos de dados 294, o filtro faz parte da primeira subespecificação visual e, desse modo, é usado para gerar a primeira visualização de dados 122.

[060] Quando há um segundo (ou subsequente) conjunto de campos de dados 294, o aplicativo de visualização de dados 222 (ou aplicativo de web 322) consulta (114) as fontes de dados 106 para o segundo (ou subsequente) conjunto de campos de dados 294 e, então, gera a segunda (ou subsequente) visualização de dados 124 correspondente aos dados recuperados. Essa visualização de dados 124 é construída de acordo com as variáveis visuais 282 na especificação visual 104 que tem campos de dados atribuídos 284 do segundo (ou subsequente) conjunto de campos de dados 294.

[061] A Figura 2 é um diagrama de blocos que ilustra um dispositivo de computação 200 que pode executar o aplicativo de visualização de dados 222 ou o aplicativo de web de visualização de dados 322 para exibir uma visualização de dados

122. Em algumas implementações, o dispositivo de computação exibe uma interface gráfica de usuário 102 para o aplicativo de visualização de dados 222. Os dispositivos de computação 200 incluem computadores do tipo desktop, computadores do tipo laptop, computadores do tipo tablet e outros dispositivos de computação com um visor e um processador capaz de executar um aplicativo de visualização de dados 222. Um dispositivo de computação 200 tipicamente inclui uma ou mais unidades/núcleos de processamento (CPUs) 202 para executar módulos, programas e/ou instruções armazenados na memória 214 e realizando, através disso, operações de processamento; uma ou mais interfaces de rede ou outras interfaces de comunicações 204; memória 214; e um ou mais barramentos de comunicação 212 para interconectar esses componentes. Os barramentos de comunicação 212 podem incluir conjunto de circuitos que interconecta e controla as comunicações entre os componentes de sistema. Um dispositivo de computação 200 inclui uma interface de usuário 206 que compreende um visor 208 e um ou mais mecanismos ou dispositivos de entrada 210. Em algumas implementações, o dispositivo/mecanismo de entrada inclui um teclado; em algumas implementações, o dispositivo/mecanismo de entrada inclui um teclado “macio”, que é exibido conforme necessário no visor 208, permitindo que um usuário “pressione as chaves” que aparecem no visor 208. Em algumas implementações, o visor 208 e dispositivo/mecanismo de entrada 210 compreendem um visor de tela sensível ao toque (também chamado de um visor sensível ao toque). Em algumas implementações, o visor é uma parte integrada do dispositivo de computação 200. Em algumas implementações, o visor é um dispositivo de exibição separado.

[062] Em algumas implementações, a memória 214 inclui memória de acesso aleatório de alta velocidade, como DRAM, SRAM, DDR RAM ou outros dispositivos de memória de estado sólido de acesso aleatório. Em algumas implementações, a memória 214 inclui memória não volátil, como um ou mais dispositivos de armazenamento de disco magnético, dispositivos de armazenamento de disco óptico, dispositivos de memória flash ou outros dispositivos de armazenamento de estado sólido não volátil. Em algumas implementações, a memória 214 inclui um ou mais dispositivos de armazenamento remotamente localizados a partir de CPUs 202. À memória 214 ou alternativamente o dispositivo (ou dispositivos) de memória não volátil dentro da memória 214, compreende um meio de armazenamento legível por computador não transitório. Em algumas implementações, a memória 214 ou o meio de armazenamento legível por computador da memória 214 armazena os seguintes programas, módulos e estruturas de dados ou um subconjunto dos mesmos:

[063] Um sistema de operação 216, que inclui procedimentos para manusear vários serviços de sistema básico e para realizar tarefas dependentes de hardware;

[064] um módulo de comunicação 218, que é usado para conectar o dispositivo de computação 200 a outros computadores e dispositivos através de uma ou mais interfaces de rede de comunicação 204 (com fio ou sem fio) e uma ou mais redes de comunicação, como a Internet, outras redes de área ampla, redes de área local, redes de área metropolitana, e assim por diante;

[065] Um navegador de web 220 (ou outro aplicativo de cliente), que permite que um usuário se comunique através de uma rede com computadores ou dispositivos remotos;

[066] um aplicativo de visualização de dados 222, que fornece uma interface gráfica de usuário 102 para um usuário construir gráficos visuais (por exemplo, uma visualização de dados individual ou um painel de instrumentos com uma pluralidade de visualizações de dados relacionadas). Em algumas implementações, o aplicativo de visualização de dados 222 é executado como um aplicativo autônomo (por exemplo, um aplicativo de desktop). Em algumas implementações, o aplicativo de visualização de dados 222 é executado dentro do navegador de web 220 (por exemplo, as um aplicativo de web 322);

[067] uma interface gráfica de usuário 102, que permite que um usuário desenvolva uma visualização de dados pela especificação visual de elementos, conforme ilustrado na Figura 4 abaixo;

[068] em algumas implementações, a interface de usuário 102 inclui uma pluralidade de regiões de prateleira 250, que são usadas para especificar características de uma visualização de dados desejada Em algumas implementações, as regiões de prateleira 250 incluem uma prateleira de colunas 230 e uma prateleira de linhas 232, que são usadas para especificar a disposição dos dados na visualização de dados desejada. Em geral, os campos que são colocados na prateleira de colunas 230 são usados para definir as colunas na visualização de dados (por exemplo, as coordenadas x de marcações visuais). De modo similar, os campos colocados na prateleira de linhas 232 definem as linhas na visualização de dados (por exemplo, as coordenadas y das marcações visuais) Em algumas implementações, as regiões de prateleira 250 incluem uma prateleira de filtros 262, que permite que um usuário limite os dados visualizados de acordo com um campo de dados selecionado (por exemplo, limite os dados às linhas para as quais um certo campo tem um valor específico ou tem valores em uma faixa específica). Em algumas implementações, as regiões de prateleira 250 incluem uma prateleira de marcações 264, que é usada para especificar várias codificações de marcações de dados. Em algumas implementações, a prateleira de marcações 264 inclui um ícone de codificação de cor 270 (para especificar cores de marcações de dados com base em um campo de dados), um ícone de codificação de tamanho 272 (para especificar o tamanho de marcações de dados com base em um campo de dados), um ícone de codificação de texto (para especificar rótulos associados às marcações de dados), e um ícone de detalhes de nível de vista 228 (para especificar ou modificar o nível de detalhes para a visualização de dados);

[069] As especificações visuais 104, que são usadas para definir características de uma visualização de dados desejada Em algumas implementações, uma especificação visual 104 é construída com uso da interface de usuário 102. Uma especificação visual inclui fontes de dados identificadas 280 (isto é, especifica quais são as fontes de dados), que fornecem informações suficientes para encontrar as fontes de dados 106 (por exemplo, um nome de fonte de dados ou nome de trajetória completa de rede). Uma especificação visual 104 também inclui variáveis visuais 282, e os campos de dados atribuídos 284 para cada uma das variáveis visuais. Em algumas implementações, uma especificação visual tem variáveis visuais correspondentes a cada uma das regiões de prateleira 250. Em algumas implementações, as variáveis visuais incluem também outras informações, como informações de contexto sobre o dispositivo de computação 200, informações de preferência de usuário ou outros recursos de visualização de dados que não são implementados como regiões de prateleira (por exemplo, recursos analíticos);

[070] Um ou mais modelos de objeto 108, que identificam a estrutura das fontes de dados 106. Em um modelo de objeto, os campos de dados (atributos) são organizados em classes, em que os atributos em cada classe têm uma correspondência um-para-um entre si. O modelo de objeto também inclui relações de muitos para um entre as classes. Em alguns casos, um modelo de objeto mapeia cada tabela em uma base de dados para uma classe, com relações de muitos para um entre classes que correspondem às relações-chave estranhas entre as tabelas. Em alguns casos, o modelo de dados de uma fonte subjacente não mapeia claramente um modelo de objeto dessa maneira simples, assim, o modelo de objeto inclui informações que especificam como transformar os dados brutos em objetos de classe apropriados. Em alguns casos, a fonte de dados brutos é um simples arquivo (por exemplo, uma planilha), que é transformado em múltiplas classes;

[071] um gerador de visualização de dados 290, que gera e exibe visualizações de dados de acordo com as especificações visuais. De acordo com algumas implementações, o gerador de visualização de dados 290 usa um modelo de objeto 108 para determinar quais dimensões em uma especificação visual 104 são acessíveis a partir dos campos de dados na especificação visual. Para cada especificação visual, esse processo forma um ou mais conjuntos de dimensões acessíveis 292. Isso é ilustrado abaixo nas Figuras 10, 11, 13A a 13C, 14A-14C, 15, 16 e 18A a 18C. Cada conjunto de dimensões acessíveis 292 corresponde a um conjunto de campos de dados 294, que inclui geralmente uma ou mais medidas além das dimensões acessíveis no conjunto de dimensões acessíveis 292.

[072] Os parâmetros de visualização 236, que contêm informações usadas pelo aplicativo de visualização de dados 222 diferentes das informações fornecidas pelas especificações visuais 104 e pelas fontes de dados 106; e

[073] zero ou mais bases de dados ou fontes de dados 106 (por exemplo, uma primeira fonte de dados 106-1), que são usadas pelo aplicativo de visualização de dados 222. Em algumas implementações, as fontes de dados podem ser armazenadas como arquivos de planilha, arquivos de CSV, arquivos de XML, arquivos planos, arquivos de JSON, tabelas em um base de dados relacional, bases de dados de nuvem ou bases de dados estatísticos.

[074] Cada um dos módulos executáveis identificados acima, aplicativos ou conjunto de procedimentos pode ser armazenado em um ou mais dos dispositivos de memória anteriormente mencionados, e corresponde a um conjunto de instruções para realizar uma função descrita acima. Os módulos ou programas identificados acima (isto é, conjuntos de instruções) precisam ser implementados como programas, procedimentos, ou módulos de software separados e, assim, vários subconjuntos desses módulos podem ser combinados ou, de outro modo, dispostos novamente em várias implementações. Em algumas implementações, a memória 214 armazena um subconjunto dos módulos e estruturas de dados identificados acima. Em algumas implementações, a memória 214 armazena módulos ou estruturas de dados adicionais não descritas acima.

[075] Embora a Figura 2 mostre um dispositivo de computação 200, a Figura 2 é mais destinada como a descrição funcional dos vários recursos que podem ser apresentados em vez de uma esquemática estrutural das implementações descritas no presente documento. Na prática, e conforme reconhecido por aquele de habilidade comum na técnica, os itens mostrados separadamente podem ser combinados e alguns itens podem ser separados.

[076] A Figura 3 é um diagrama de blocos de um servidor de visualização de dados 300 de acordo com algumas implementações. Um servidor de visualização de dados 300 pode acolher uma ou mais bases de dados 328 ou pode fornecer vários aplicativos ou módulos executáveis. Um servidor 300 inclui tipicamente uma ou mais unidades/núcleos de processamento (CPUs) 302, uma ou mais interfaces de rede 304, memória 314 e um ou mais barramentos de comunicação 312 para interconectar esses componentes. Em algumas implementações, o servidor 300 inclui uma interface de usuário 306, que inclui um visor 308 e um ou mais dispositivos de entrada 310, como um teclado e um mouse. Em algumas implementações, os barramentos de comunicação 312 incluem conjunto de circuitos (algumas vezes chamado de um chipset) que interconecta e controla as comunicações entre os componentes de sistema.

[077] Em algumas implementações, a memória 314 inclui a memória de acesso aleatório de alta velocidade, como DRAM, SRAM, DDR RAM, ou outros dispositivos de memória de estado sólido de acesso aleatório, e podem incluir memória não volátil, como um ou mais dispositivos de armazenamento de disco magnético, dispositivos de armazenamento de disco óptico, dispositivos de memória flash ou outros dispositivos de armazenamento de estado sólido não volátil. Em algumas implementações, a memória 314 inclui um ou mais dispositivos de armazenamento remotamente localizados a partir de CPU (ou CPUs) 302. A memória 314 ou alternativamente o dispositivo (ou dispositivos) de memória não volátil dentro da memória 314, compreende um meio de armazenamento legível por computador não transitório.

[078] Em algumas implementações, a memória 314 ou o meio de armazenamento legível por computador da memória 314 armazena os seguintes programas, módulos e estruturas de dados ou um subconjunto dos mesmos:

[079] Um sistema de operação 316, que inclui procedimentos para manusear vários serviços de sistema básico e para realizar tarefas dependentes de hardware;

[080] um módulo de comunicação de rede 318, que é usado para conectar o servidor 300 a outros computadores através de uma ou mais interfaces de rede de comunicação 304 (com fio ou sem fio) e uma ou mais redes de comunicação, como a Internet, outras redes de área ampla, redes de área local, redes de área metropolitana, e assim por diante;

[081] um servidor de web 320 (como um servidor de HTTP), que recebe as solicitações de web a partir dos usuários e responde fornecendo-se páginas de web responsivas ou outros recursos;

[082] um aplicativo de web de visualização de dados 322, que pode ser transferido por donwload e executado por um navegador de web 220 no dispositivo de computação de um usuário 200. Em geral, uma aplicativo de web de visualização de dados 322 tem a mesma funcionalidade que um aplicativo de visualização de dados de desktop 222, mas fornece a flexibilidade de acesso de qualquer dispositivo em qualquer localização com conectividade de rede, e não exige instalação e manutenção. Em algumas implementações, o aplicativo de web de visualização de dados 322 inclui vários módulos de software para realizar certas tarefas. Em algumas implementações, o aplicativo de web 322 inclui um módulo de interface de usuário 324, que fornece a interface de usuário para todos os aspectos do aplicativo de web

322. Em algumas implementações, o módulo de interface de usuário 324 especifica as regiões de prateleira 250, conforme descrito acima para um dispositivo de computação 200;

[083] o aplicativo de web de visualização de dados também armazena especificações visuais 104 à medida que um usuário seleciona as características da visualização de dados desejada. As especificações visuais 104 e os dados que armazenam, são descritos acima para um dispositivo de computação 200;

[084] um ou mais modelos de objeto 108, conforme descrito acima para um dispositivo de computação 200;

[085] um gerador de visualização de dados 290, que gera e exibe visualizações de dados de acordo com fontes de dados selecionadas por usuário e campos de dados, bem como um ou mais modelos de objeto que descrevem as fontes de dados 106. A operação do gerador de visualização de dados é descrita acima com relação a um dispositivo de computação 200, e descrita abaixo nas Figuras 10, 11, 13A a 13C, 14A a 14C, 15, 16 e 18A a 18C;

[086] em algumas implementações, o aplicativo de web 322 inclui um módulo de recuperação de dados 326, que constrói e executa consultas para recuperar os dados de uma ou mais fontes de dados 106. As fontes de dados 106 podem ser armazenadas localmente no servidor 300 ou armazenadas em uma base de dados externa 328. Em algumas implementações, os dados de duas ou mais fontes de dados podem ser misturados. Em algumas implementações, o módulo de recuperação de dados 326 usa uma especificação visual 104 para desenvolver as consultas, conforme descrito acima para o dispositivo de computação 200 na Figura 2;

[087] uma ou mais bases de dados 328, que armazenam os dados usados ou criados pelo aplicativo de web de visualização de dados 322 ou aplicativo de visualização de dados 222. As bases de dados 328 podem armazenar fontes de dados 106, que fornecem os dados usados nas visualizações de dados geradas. Cada fonte de dados 106 inclui um ou mais campos de dados 330. Em algumas implementações, a base de dados 328 armazena preferências de usuário. Em algumas implementações, a base de dados 328 inclui um registro cronológico de histórico de visualização de dados 334. Em algumas implementações, o registro cronológico de histórico 334 rastreia cada vez que a visualização de dados se torna uma visualização de dados.

[088] As bases de dados 328 podem armazenar dados em muitos formatos diferentes e inclui comumente muitas tabelas distintas, cada uma com uma pluralidade de campos de dados 330. Algumas fontes de dados compreendem uma única tabela. Os campos de dados 330 incluem tanto campos brutos da fonte de dados (por exemplo, uma coluna de uma tabela de base de dados ou uma coluna de uma planilha) quanto campos de dados derivados, que podem ser computados ou construídos a partir de um ou mais outros campos. Por exemplo, os campos de dados derivados incluem computar um mês ou quarto de um campo de data, computar um espaço de tempo entre dois campos de data, computar totais cumulativos para um campo quantitativo, computar crescimento em porcentagem, e assim por diante. Em alguns casos, os campos de dados derivados são acessados por procedimentos ou vistas armazenadas na base de dados. Em algumas implementações, as definições de campos de dados derivados 330 são armazenadas separadamente da fonte de dados 106. Em algumas implementações, a base de dados 328 armazena um conjunto de preferências de usuário para cada usuário. As preferências de usuário podem ser usadas quando o aplicativo de web de visualização de dados 322 (ou aplicativo 222) faz recomendações sobre como visualizar um conjunto de campos de dados 330. Em algumas implementações, a base de dados 328 armazena um registro cronológico de histórico de visualização de dados 334, que armazena as informações sobre cada visualização de dados gerada. Em algumas implementações, a base de dados 328 armazena outras informações, incluindo outras informações usadas pelo aplicativo de visualização de dados 222 ou aplicativo de web de visualização de dados

322. As bases de dados 328 podem ser separadas do servidor de visualização de dados 300, ou podem ser incluídas com o servidor de visualização de dados (ou ambos).

[089] Em algumas implementações, o registro cronológico de histórico de visualização de dados 334 armazena as especificações visuais 104 selecionadas pelo usuário, que podem incluir um identificador de usuário, um carimbo data e hora de quando a visualização de dados foi criada, uma lista dos campos de dados usados na visualização de dados, o tipo da visualização de dados (algumas vezes referido como um “tipo de vista” ou um “tipo de gráfico”), codificações de dados (por exemplo, cor e tamanho de marcações), as relações de dados selecionadas e quais conectores são usados. Em algumas implementações, uma ou mais imagens em miniatura de cada visualização de dados também são armazenadas. Algumas implementações armazenam informações adicionais sobre visualizações de dados criadas, como o nome e localização da fonte de dados, o número de linhas da fonte de dados que foram incluídas na visualização de dados, versão do software de visualização de dados e assim por diante.

[090] Cada um dos módulos executáveis identificados acima, aplicativos ou conjuntos de procedimentos pode ser armazenado em um ou mais dos dispositivos de memória anteriormente mencionados, e corresponde a um conjunto de instruções para realizar uma função descrita acima. Os módulos ou programas identificados acima (isto é, conjuntos de instruções) precisam ser implementados como programas, procedimentos, ou módulos de software separados e, assim, vários subconjuntos desses módulos podem ser combinados ou, de outro modo, dispostos novamente em várias implementações. Em algumas implementações, a memória 314 armazena um subconjunto dos módulos e estruturas de dados identificados acima. Em algumas implementações, a memória 314 armazena módulos ou estruturas de dados adicionais não descritas acima.

[091] Embora a Figura 3 mostre um servidor de visualização de dados 300, a Figura 3 é mais destinada como a descrição funcional dos vários recursos que podem ser apresentados em vez de uma esquemática estrutural das implementações descritas no presente documento. Na prática, e conforme reconhecido por aquele de habilidade comum na técnica, os itens mostrados separadamente podem ser combinados e alguns itens podem ser separados. Além disso, algum dentre os programas, as funções, os procedimentos ou os dados mostrados acima em relação a um servidor 300 pode ser armazenado ou executado em um dispositivo de computação 200. Em algumas implementações, a funcionalidade e/ou os dados podem ser alocados entre um dispositivo de computação 200 e um ou mais servidores

300. Além disso, um elemento versado na técnica reconhece que a Figura 3 não precisa representar um único dispositivo físico. Em algumas implementações, a funcionalidade de servidor é alocada através de múltiplos dispositivos físicos que compreendem um sistema de servidor. Conforme usado no presente documento, as referências a um “servidor” ou “servidor de visualização de dados” incluem vários grupos, coleções ou matrizes de servidores que fornecem a funcionalidade descrita, e os servidores físicos não precisam ser fisicamente colocalizados (por exemplo, os dispositivos físicos individuais podem ser distribuídos por todos os Estados Unidos ou por todo o mundo).

[092] A Figura 4 mostra uma interface de usuário de visualização de dados 102 de acordo com algumas implementações. A interface de usuário 102 inclui uma região de informações de esquema 410, que também é referida como um painel de dados. A região de informações de esquema 410 fornece elementos de dados nomeados (por exemplo, nomes de campo) que podem ser selecionados e usados para desenvolver uma visualização de dados. Em algumas implementações, a lista de nomes de campo é separada em um grupo de dimensões e um grupo de medidas (tipicamente quantidades numéricas). Algumas implementações também incluem uma lista de parâmetros. A interface gráfica de usuário 102 também inclui uma região de visualização de dados 412. A região de visualização de dados 412 inclui uma pluralidade de regiões de prateleira 250, como uma região de prateleira de colunas 230 e uma região de prateleira de linhas 232. Essas também são referidas como a prateleira de coluna 230 e a prateleira de fileira 232. Além disso, essa interface de usuário 102 inclui uma prateleira de filtros 262, que pode incluir um ou mais filtros 424.

[093] Conforme ilustrado aqui, a região de visualização de dados 412 também tem um grande espaço para exibir um gráfico visual. Devido ao fato de que nenhum elemento de dados foi selecionado ainda nessa ilustração, o espaço inicialmente não tem gráfico visual.

[094] Um usuário seleciona uma ou mais fontes de dados 106 (que podem ser armazenadas no dispositivo de computação 200 ou armazenadas remotamente), seleciona os campos de dados a partir da fonte (ou fontes) de dados, e usa os campos selecionados para definir um gráfico visual. O aplicativo de visualização de dados 222 (ou aplicativo de web 322) exibe o gráfico gerado 122 na região de visualização de dados 412. Em algumas implementações, as informações que o usuário fornece são armazenadas como uma especificação visual 104.

[095] Em algumas implementações, a região de visualização de dados 412 inclui uma prateleira de marcações 264. A prateleira de marcações 264 permite que um usuário especifique várias codificações 426 de marcações de dados. Em algumas implementações, a prateleira de marcações inclui um ícone de codificação de cor 270, um ícone de codificação de tamanho 272, um ícone de codificação de texto 274 e/ou um ícone de detalhes de nível de vista 228, que podem ser usados para especificar ou modificar o nível de detalhes para a visualização de dados.

[096] Um modelo de objeto pode ser descrito como um gráfico com classes como nós e suas relações de muitos para um como bordas. Conforme ilustrado no presente documento, esses gráficos são dispostos de modo que o lado de “muitos” de cada relação esteja sempre abaixo do “lado de um”. Por exemplo, na Figura 5, a classe de escritórios 502 tem uma relação de muitos para um 512 com a classe de empresas 504, e a classe de escritórios 502 também tem uma relação de muitos para um 514 com a classe de países 506. Nesse gráfico, as empresas podem ter múltiplos escritórios e os países podem ter múltiplos escritórios, mas um escritório individual pertence a uma única empresa e país. O modelo de objeto na Figura 5 é conectado, mas nem todos os modelos de objeto são conectados. Em geral, o modelo de objeto 108 para uma fonte de dados 106 é construído em avanço. Quando um usuário posteriormente constrói uma visualização de dados, a estrutura do modelo de objeto 108 auxilia na geração de visualizações de dados apropriadas.

[097] Tipicamente, qualquer par de classes é unido por no máximo uma trajetória através do gráfico de relação. Quando múltiplas trajetórias são possíveis, o usuário pode precisar especificar qual trajetória usar, ou descompactar o conjunto de dados para combinar as duas trajetórias em uma.

[098] Algumas das seguintes figuras ilustram vários modelos de objeto, e ilustram a seleção de usuário de dimensões D e medidas M dentro dos modelos de objeto. Com base nas localizações das dimensões e medidas dentro de um modelo de objeto, o gerador de visualização de dados 290 determina como muitas visualizações de dados distintas são geradas e quais são desenvolvidas. Nesse contexto, é útil definir o conceito de uma dimensão que é acessível a partir de um outro campo de dados dentro de um modelo de objeto. Especificamente, uma dimensão D é acessível a partir de um campo de dados quando há uma sequência de relações de muitos para um que começa a partir da classe contendo o campo de dados e termina com a classe que contém a dimensão. Além disso, se uma dimensão D está em uma classe C, então, a dimensão D é acessível a partir de todos os outros campos de dados na classe C. Nesse caso, há uma sequência de zero relações de muitos para um que começa com o campo de dados e termina com a dimensão.

[099] Com essa definição de “acessível”, torna-se possível definir o conjunto de dimensões que são acessíveis a partir de um determinado nó no gráfico. Em particular, para cada campo de dados (dimensão ou medida) em uma especificação visual 104, o conjunto acessível de dimensões 292 consiste em todas as dimensões na especificação visual no mesmo nível de detalhes (LOD) como o determinado campo de dados ou acessível atravessando-se o gráfico a partir do campo de dados.

[0100] Para cada campo de dados, também é útil identificar o conjunto acessível de filtros de visualização. Isso inclui todos os filtros em dimensões que são acessíveis. Nota-se que os filtros medidos podem ser implicitamente tratados como filtros de dimensão no nível de detalhes apropriado.

[0101] A Figura 16 fornece consultas de pseudocódigo para determinar as dimensões acessíveis para cada campo de dados (dimensão ou medida) dentro de um modelo de objeto.

[0102] Para cada campo de dados, o conjunto de dimensões acessíveis e filtros acessíveis cria um esquema floco de neve implícito centralizado no campo de dados. Isso significa que há uma maneira única e bem definida de aplicar filtros ao campo de dados e agregar medidas. A exibição dos resultados de cada consulta do campo de dados por si só facilita a interpretação dos resultados.

[0103] Além disso de facilitar que o usuário desenvolva visualizações desejadas, o uso de dimensões acessíveis pode aumentar o desempenho da recuperação de dados. As consultas são mais rápidas devido ao fato de que precisam apenas se unir em dimensões que são acessíveis através de relações de muitos para um. Isso pode ser entendido como uma forma generalizada de comportamento agressivo de seleção de junção. Uma consulta precisa entrar em contato com as tabelas que são estritamente necessárias para criar a visualização desejada.

[0104] Para uma visualização de dados que usa N campos de dados, o processo pode resultar em um máximo teórico de N consultas distintas. No entanto, muitos desses serão redundantes. O resultado de uma consulta podem estar contido no resultado de uma ou mais outras consultas. Além disso, as consultas que computar as medidas no mesmo nível de detalhes podem ser combinadas. Portanto, esse processo executa, de fato, poucas consultas.

[0105] A partir de uma perspectiva de desempenho, a geração de múltiplas consultas independentes em vez de uma consulta monolítica única através de junções de muitos-para-um tem uma vantagem adicional: as consultas podem ser executadas em paralelo. Devido a isso, algumas implementações são capazes de começar a apresentar a visualização de dados antes que todas as consultas tenham retornado seus resultados.

[0106] Dada as semânticas de consulta acima, surgem dois desafios principais: múltiplos níveis de detalhes e múltiplos domínios. Em primeiro lugar, as consultas independentes podem produzir resultados em diferentes níveis de detalhes. Se os níveis de detalhes se encaixam (por exemplo, (Estado, Cidade) com Estado), isso não é particularmente problemático. O processo pode simplesmente replicar os valores de LOD maiores para os valores de LOD. Isso é mais desafiador quando os LODs particularmente se sobrepõem (por exemplo, (Estado, Cidade) e (Estado, CEP)) ou são separados (por exemplo, (Estado, Cidade) e (Produto, Subproduto)). Em segundo lugar, as consultas independentes podem produzir resultados com domínios diferentes. Por exemplo, a computação de SOMA(População) por Estado pode retornar uma entrada para cada um dos 50 estados (se a tabela de população estiver completa para os Estados Unidos). No entanto, a computação de SOMA(Vendas) por Estado apenas retorna os estados para os quais há transações de vendas. Se a tabela de vendas não incluis transações em 10 estados, então, a consulta retornará os resultados para apenas os 40 estados.

[0107] Para abordar os múltiplos níveis de detalhes, o processo começa combinando os resultados de consulta que estão no mesmo nível de detalhes em tabelas de resultado conglomerado. O processo também combina resultados de consulta alinhados (aqueles que estão em uma relação de LOD estritamente de subconjunto/superconjunto). Isso resulta em duplicação dos resultados alinhados,

mas não é prejudicial devido ao fato de que permite comparar os totais com os subtotais.

[0108] Mesmo após combinar todos esses casos juntos, há casos com múltiplas tabelas de resultado quando os níveis de detalhes são particularmente sobrepostos ou separados. As implementações usam várias abordagens para visualizar os resultados nesses casos

[0109] Além disso de abordar múltiplos níveis de detalhes, as implementações abordam outros cenários também. Há casos em que um campo de dados tem dois ou mais domínios diferentes de valores. Por exemplo, o conjunto de todos os estados pode ser diferente do conjunto de estados que tem pedidos, que pode ser diferente do conjunto de estados que tem funcionários. O modelo de objeto permite que um único conceito lógico (por exemplo, “Estado”) tenha múltiplos domínios associados ao mesmo.

[0110] Um outro cenário é quando há múltiplas tabelas principais (“de fato”). A existência de múltiplas tabelas de fato pode introduzir replicação (duplicação) e relações de muitos-para-muitos. Além disso, as múltiplas tabelas de fato podem alterar como as junções são implementadas. Em muitos casos, uma única tabela de fatos com uma estrutura floco de neve pode ser consultada expondo-se a junção como uma árvore. No entanto, com múltiplas tabelas de fato, há ambiguidade inerente sobre qual tabela designar como o centro do floco de neve, e juntar nas tabelas de modo que não possa ser uma visualização satisfatória do modelo de dados do usuário.

[0111] Um outro cenário ocorre quando uma tabela tem duas ou mais referências à mesma tabela (e sua sub-árvore). Por exemplo, considerar um cenário em que cada Pedido inclui tanto uma OrderDate e um ShipDate. Há várias maneiras para que esses dados possam ser estruturados. Em um primeiro caso, tanto OrderDate quanto ShipDate são campos de dados na própria tabela de Pedido. Nesse caso, os dados são fáceis de consultar. Em um segundo caso, há tabelas separadas de OrderDate e ShipDate, assim, há junções separadas entre a tabela de Pedidos e cada uma dessas tabelas distintas.

Em um terceiro caso, as informações de

[0114] Em cada diagrama de modelo de objeto, As fontes de dimensões e medidas para a especificação visual atual 104 são rotuladas com “D” e “M”. No caso mais simples, há uma única classe que inclui todas as dimensões e medidas da especificação visual atual 104, conforme ilustrado na Figura 8. Nesse cenário, as medidas e dimensões se originam da mesma classe, e as semânticas de computação são triviais. O processo centraliza as medidas para o nível de dimensão de detalhes. Isso resulta em uma única tabela contendo as dimensões e medidas agregadas.

[0115] A criação de uma exibição múltipla pequena para essa tabela de resultados não é necessariamente óbvio, devido ao fato de que não há relações modeladas entre os atributos em uma única classe. No entanto, o modelo de prateleira (linhas 232 e colunas 230) fornece um conjunto de heurísticas para abordar as mesmas. As dimensões na mesma prateleira criam eixos hierárquicos (por exemplo, como na Figura 9B), enquanto as dimensões em diferentes prateleiras criam eixos cruzados. Múltiplas medidas no mesmo eixo geométrico são concatenadas (conforme ilustrado pelas duas colunas 704 e 706 na Figura 7A). Outras prateleiras são usadas para criar marcações e definir sua aparência visual.

[0116] Em um modelo de floco de neve, as medidas se originam de uma única classe, conforme ilustrado na Figura 9A. As dimensões se originam da mesma classe ou classes acessíveis atravessando o gráfico de relação a partir da classe das medidas. O processo junta as dimensões à classe da classe de medidas ao longo das bordas de relação. As medidas são agregadas até o nível de dimensão de detalhes. Todas as outras classes são ignoradas. Por exemplo, na Figura 9A, todas as medidas se originam da tabela de pedidos 904, e a visualização de dados tem dimensões tanto na classe de produto 902 quanto na classe de região 908. As dimensões na classe de produto 902 e na classe de região 908 definem o nível de detalhes para agregar as medidas da classe de pedidos 904. Nesse exemplo, não há dimensões ou medidas para a visualização de dados que se originam da classe de estado 906, assim, seus dados não são usados. No entanto, a classe de estado 906 pode ser necessária em uma consulta a fim de conectar as medidas da classe de pedidos 904 à classe de região 908.

[0117] O modelo de objeto indica se há uma relação de encaixe ou uma relação de cruzamento entre as dimensões, que é usado em algumas implementações para determinar o comportamento padrão. No exemplo da Figura 9A, o produto e a região são independentes entre si, assim, podem ser cruzados em uma exibição múltipla pequena independente da possibilidade ou não de estarem no mesmo eixo geométrico. No entanto, algumas implementações permitem que um usuário substitua o comportamento padrão. Por exemplo, mesmo quando o modelo mostra uma relação cruzada entre dimensões independentes, um usuário pode desejar se encaixar simplesmente com base na relação definida pelos valores de dados atuais. Inversamente, mesmo quando o encaixe faz sentido, um usuário pode desejar mostrar uma visualização cruzada e introduzir espaços brancos em que não há pareamento correspondente entre as dimensões encaixadas.

[0118] A exibição das dimensões cruzadas no mesmo eixo geométrico é ilustrada na Figura 9B. Nesse caso, o usuário colocou as duas dimensões independentes, segmento 920 e categoria 922, na mesma prateleira (a prateleira de colunas 230). O usuário colocou a medida Vendas 924 na prateleira de linhas 232, que é agregada aqui com uso de CONTAG(). As dimensões de segmento e categoria são independentes, assim, por padrão, são cruzadas. O cabeçalho de coluna superior 940 lista os segmentos e o cabeçalho de coluna inferior 942 lista as categorias. Devido à cruz, cada uma das categorias é exibida para cada um dos segmentos, e isso poderia ocorrer mesmo se não houvesse dados para algumas combinações de segmento/categoria. Em algumas implementações, a interface de usuário 102 aborda interações de usuário para manusear o cruzamento. Por exemplo, em algumas implementações, a seleção de um cabeçalho (por exemplo, o primeiro cabeçalho de mobiliário 926) em um eixo geométrico cruzado resulta na seleção de todas os dados correspondentes (por exemplo, os dados de mobiliário 930, 932 e 934 para todas as colunas com a mesma categoria de mobiliário).

[0119] Em algumas implementações, quando há dimensões encaixadas nos diferentes eixos geométricos, o visor usa uma técnica alternativa para mostrar apenas as combinações relevantes, conforme ilustrado na Figura 9C. Nesse caso, o campo de dados “subcategoria” é encaixado no campo de dados “categoria” e esses dois campos de dados estão em eixos geométricos distintos. As subcategorias para cada categoria são completamente diferentes (por exemplo, estantes e cadeiras na categoria de mobiliário, mas equipamentos, ofício e persianas na categoria de material de escritório). Devido a isso, o visor inclui um conjunto separado de cabeçalhos de coluna para cada fileira na visualização de dados. Algumas vezes, isso é chamado de um gráfico Trellis. Garante-se que cada subcategoria é apenas mostrada dentro da categoria apropriada.

[0120] A mistura é uma generalização do caso floco de neve em que as medidas podem se originar de múltiplas classes. Isso é ilustrado na Figura 10. As dimensões são acessíveis a partir de todas as medidas através de uma única classe (algumas vezes chamada de “LOD de junção”). Na Figura 10, a classe de estado 1004 é o “LOD de junção”.

[0121] Se cada medida é considerada independentemente, esse cenário é o mesmo que de um floco de neve. Cada medida pode ser acumulada até o LOD de dimensão independentemente. Desse modo, as medidas agregadas podem ser unidas em conjunto no LOD de dimensão. Por exemplo, as medidas da tabela de pedidos 1002 são agregadas de acordo com as dimensões na classe de região 1008, e as medidas da classe de fornecedores 1006 também são agregadas de acordo com as dimensões na classe de região 1008. Devido ao fato de que medidas tanto da classe de pedidos 1002 quanto da classe de fornecedores são agregadas no mesmo nível de detalhes, os conjuntos de resultados podem ser unidos diretamente para formar uma única tabela no LOD de dimensão.

[0122] Se a visualização de dados não tiver dimensões (por exemplo, está mostrando totais gerais), então, é um caso de mistura trivial devido ao fato de que todas (zero) dimensões podem ser alcançadas a partir de qualquer medida. Nesse caso, todas as medidas são acumuladas até o LOD de dimensão vazia (isto é, um valor de dados agregados é computado para cada medida) e os agregados são exibidos em uma única visualização. Isso funciona mesmo se o modelo de objeto não for conectado.

[0123] A restrição de que todas as dimensões são acessíveis através da mesma classe pode ser flexibilizada. À medida que todas as dimensões são acessíveis a partir de todas as medidas atravessando-se o gráfico, o processo pode usar as mesmas semânticas de consulta e exibição visual que a mistura padrão. Isso é ilustrado na Figura 11, que adiciona a classe de produto 1110 ao modelo de dados mostrado na Figura 10. Nesse exemplo, as medidas tanto dos pedidos 1002 quanto dos fornecedores 1006 podem ser acumuladas de acordo com as dimensões na classe de região 1008 e na classe de produto 1110 apesar de não passar por um único LOD de junção.

[0124] Nota-se que a relação das dimensões entre si (cruzada ou encaixada) é independente do conjunto de medidas usadas, assim, a exibição do visor múltiplo pequeno pode usar as mesmas regras que com a mistura mais simples.

[0125] Algumas vezes, uma medida pode ser definida acima de uma dimensão no modelo de objeto, conforme ilustrado na Figura 12A. Nesse caso, as medidas na classe de região 1208 (talvez a População), não será totalmente agregadas. De fato, a medida será replicada (duplicada) para o LOD de dimensão (de acordo com as dimensões na classe de pedidos 1202 e na classe de produto 1210)

como um atributo. Em efeito, o aplicativo de visualização de dados trata essa medida apenas como uma outra dimensão.

[0126] Para tornar esse comportamento mais claro para os usuários, algumas implementações suprimem a função de agregação na pílula correspondente na prateleira de linhas 232 ou na prateleira de colunas 230 conforme ilustrado na Figura 12C. Em vez de mostrar SOMA(Lucro) 1250, a interface de usuário mostra Lucro 1252. Em algumas implementações, a interface de usuário altera a aparência da expressão de outros modos, como visualmente desenfatiza a mesma. Além disso, algumas implementações reconhecem visualmente a duplicação em seleções, como os cabeçalhos de duplicada nos eixos geométricos cruzados. Por exemplo, na Figura 12B, todas as linhas 1230 na visualização de dados mostram o mesmo valor para a categoria vendas (há apenas um valor de dados), e as linhas são destacadas em conjunto quando visualizadas.

[0127] Problemas mais desafiadores de nível de detalhes surgem quando nem todas as dimensões são acessíveis a partir de todas as medidas que não são de atributos. Por exemplo, considerar o modelo de objeto na Figura 13A, que tem uma classe de empresa 1302 e um classe de país 1304, mas nenhuma relação definida entre as mesmas. Isso não é tão estranho quanto parece devido ao fato de que um usuário não tem que definir uma relação entre dois objetos antes que os objetos possam ser usados.

[0128] Em algumas implementações, isso resulta em duas visualizações de dados verticalmente concatenadas 1322 e 1324, conforme ilustrado na Figura 13B. Em algumas implementações, as duas visualizações de dados distintas são concatenadas horizontalmente, conforme ilustrado nas Figuras 13C e 13D. Na Figura 13C, os topos das duas visualizações 1332 e 1334 são horizontalmente alinhados. Na Figura 13D, os fundos das duas visualizações de dados 1342 e 1344 são horizontalmente alinhados. Nota-se que os gráficos nas Figuras 13C e 13D não compartilham um eixo geométrico.

[0129] Em algumas implementações, quando há múltiplas visualizações de dados, uma visualização é mostrada em um tempo, permitindo que os usuários revistem a mesma. Para ajudar os usuários a entender quais campos são usados para fabricar uma visualização, algumas implementações desestabilizam os campos ou filtros não usados quando a visualização correspondente não é mostrada ou não tem destaque.

[0130] Em alguns casos, as dimensões e medidas são ligadas através de uma relação muitos-para-muitos, conforme ilustrado na Figura 14A. Nesse exemplo, as dimensões e medidas da classe de clientes 1402 são conectadas através de uma relação de muitos para um com a classe de estado 1406. De modo similar, as dimensões e medidas da classe de empresas 1404 são conectadas por uma relação de muitos para um com a classe de estado 1406.

[0131] Esse caso é muito similar à mistura, exceto pelo fato de que as dimensões foram incluídas a partir de ambas as duas classes de fundo 1402 e 1404. O resultado é aquele em que as dimensões da classe de empresas 1404 não são acessíveis a partir das medidas na classe de clientes 1402 e vice versa. Esse caso é similar ao caso de gráfico desconectado na Figura 13A, exceto pelo fato de que a classe de estado adicional 1406 foi adicionada.

[0132] Em alguns cenários, algumas implementações combinam a mistura e comportamentos desconectados, mostrando visualizações de dados independentes para clientes e empresas, encaixadas com estado, conforme ilustrado na Figura 14B. Conforme mostrado na Figura 14B, as dimensões de estado são acessíveis tanto a partir da classe de clientes 1402 quanto a partir da classe de empresas 1404, assim, a visualização geral é alinhada pelo estado 1420. Por exemplo, a visualização de dados parcial na Figura 14B mostra os dados para Alabama 1422 e Arizona 1424.

Dentro de cada região horizontal para um estado, há uma listagem de empresas 1426, juntamente com as marcações visuais 1428 que representam as vendas para cada empresa. Além disso, cada região de estado horizontal também tem uma lista de nomes de cliente 1430, juntamente com as marcações visuais 1432 (por exemplo, barras) representando o lucro para cada desses clientes individuais. Isso ilustra o alinhamento parcial com base na dimensão (ou dimensões) compartilhada da classe de estado 1406.

[0133] A Figura 14C ilustra uma visualização de dados que algumas implementações criam com uso de uma seleção diferente de campos de dados do mesmo modelo de objeto mostrado na Figura 14A. Para a Figura 14C, um usuário selecionou a medida vendas da classe de clientes 1402, e selecionou a medida vendas da classe de empresas 1404 também. No entanto, o usuário não selecionou quaisquer dimensões de qualquer uma dessas duas classes. Devido ao fato de que o estado de dimensão é acessível a partir de todas as medidas, há uma única visualização de dados com cada uma das medidas centralizadas para o estado. No entanto, com as duas tabelas de fatos, e vendas limitadas, surge a questão relacionada a quais estados mostrar. Em algumas implementações, o comportamento padrão deve realizar uma junção externa completa, mostrando cada um dos estados, e tanto as vendas de empresa quanto as vendas de cliente para cada um dos estados (vazio indica zero). Por exemplo, na Figura 14C, Alabama não teve vendas 1450 para empresas ou clientes. Por outro lado, Califórnia teve tanto vendas de empresa 1452 quanto vendas de cliente 1454. Alguns estados têm apenas um ou o outro, como Flórida que tem apenas de empresa 1456 e Illinois que tem apenas vendas de cliente

1458. Em algumas implementações, o usuário pode selecionar quais dados são exibidos (por exemplo, omitindo os estados que não tiveram dados da classe de clientes 1402 ou da classe de empresas 1404). Em algumas implementações, os estados sem atividade para empresas ou clientes são omitidos por falha.

[0134] A Figura 15 ilustra um cenário que é igual ao das Figura 14A, exceto pelo fato de que a dimensão da classe de estado 1506 foi omitida. Devido ao modelo de objeto, sabe-se que a classe de clientes 1502 e a classe de empresas 1504 têm uma relação muitos-para-muitos através da classe de estado 1506. No entanto, o usuário não solicitou que o estado fosse incluído na visualização.

[0135] Nesse cenário, algumas implementações simplesmente ignoram a ligação através estado e produzem a mesma visualização como no cenário desconectado (Figuras 13A a 13D). Essa abordagem tem a vantagem de uma transmissão que não tem estado na visualização de dados tendo estado incluído é de alguma forma natural. Um usuário começa com duas listas independentes, então, a adição de estado criaria duas listas independentes para cada estado.

[0136] Algumas implementações abordam esse cenário de uma outra maneira. Algumas implementações produzem visualizações separadas, mas destacam automaticamente o comportamento de ligação no estado. Em alguns casos, isso é significativo. Por exemplo, se clientes puderem ser atendidos pelas empresas no mesmo estado, então, clicar em um cliente na lista de cliente destacaria as empresas em seu estado que poderiam servir para os mesmos. Inversamente, clicar em uma empresa destacaria os clientes que podem ser para a mesma. Por outro lado, quando não há tais semânticas de interesse, destacar as empresas no mesmo estado que algum cliente pode ser uma predefinição contraprodutiva ou distrativa. Esse tipo de destaque em cruz também pode ser computacionalmente caro, assim, tornar o mesmo um comportamento padrão não é prático para implementações em dispositivos com recursos computacionais limitados.

[0137] Com base nesses exemplos, algumas implementações realizam as seguintes etapas com base nas dimensões e medidas selecionadas e no modelo de objeto correspondente. Em primeiro lugar, o processo divide as medidas na especificação visual 104 pelo conjunto de dimensões acessíveis de cada (criando um ou mais conjuntos de dimensões acessíveis 292). Em segundo lugar, para cada conjunto de medidas que pode alcançam o mesmo conjunto de dimensões, o processo centraliza as medidas para o nível de dimensão de detalhes. Cada conjunto de dimensões acessíveis 292 juntamente com suas medidas correspondentes formam um conjunto de campos de dados. 294. Em terceiro lugar, o processo cria uma visualização de dados separada para cada conjunto de campos de dados 294 com uso dos mapeamentos de variável visual associados às dimensões e medidas no conjunto de campos de dados. O processo ignora todos os outros mapeamentos.

[0138] Algumas implementações também abordam a situação ilustrada nas Figuras 14B. Nesse caso, há listas independentes de Cliente e Empresa encaixadas dentro do Estado. Nesse caso, é útil encaixar as visualizações separadas em uma dimensão comum. Os cenários similares surgem onde é útil exibir um conjunto de medidas como um subtotal ou total geral intercalado com ou na margem do visor de um outro conjunto de medidas.

[0139] Algumas implementações impedem que um usuário entre em um cenário com visualização múltipla limitando o mesmo a um dos cenários mais fáceis acima. Por exemplo, algumas implementações limitam os usuários ao cenário de mistura exigindo que os mesmos escolham o objeto de “LOD de junção” para cada lâmina e, desabilitando, desse modo, as dimensões não acessíveis subindo o gráfico a partir do LOD de junção e medidas não acessíveis subindo a árvore.

[0140] Na mistura, nem sempre está claro qual lado as relações de muitos para um se direcionam. A mistura gera resultados corretos e úteis quando uma relação de muitos para um funciona de forma esperada. Quando não funciona como o esperado, um “* é exibido. Algumas implementações assumem uma abordagem similar às questões de modelo de objeto aqui. Por exemplo, em vez de fazer listas independentes, algumas implementações mostram o produto em cruz das listas e duplicam as medidas. Isso é descrito em mais detalhes abaixo.

[0141] A aplicação dos filtros está intimamente relacionada ao problema do domínio. Os filtros definitivamente devem ser aplicados no gráfico de relação (de um para muitos). No modelo de objeto da Figura 5, um filtro nas empresas deve ser aplicado também a escritórios. A filtragem do gráfico (por exemplo, se um filtro remover todos os escritórios no Reino Unido, o Reino Unido deve ser filtrado também?) é mais questionável.

[0142] Em algumas implementações, cada filtro tem um LOD atribuído, e é aplicado naquele nível de detalhes.

[0143] Em algumas implementações, quando o processo acima pode levar a duas ou mais visualizações de dados distintas, o processo realiza uma junção natural de todos os conjuntos de resultados conglomerados para produzir uma única tabela cruzada de resultados. O conglomerado é uma única tabela, assim, pode ser definido da maneira usual. Essa é uma forma estendida de mistura de dados, conforme descrito em mais detalhes abaixo. Essa abordagem duplica os dados, mas a duplicação acontece após a agregação, assim, é menos provável que seja analiticamente errado.

[0144] Para ajudar os usuários a entender como um campo particular foi computado, quando um usuário clica em uma pílula em uma região de prateleira, algumas implementações desabilitam todos os campos e filtros que são inalcançáveis a partir dessa pílula. O texto pairado para a pílula indica, por exemplo, que, “SOMA(Vendas) foi computado para cada Estado, filtrado pela Data de Embarcação (1 dimensão e 2 filtros não foram usados)”.

[0145] Essa abordagem duplica potencialmente muitos dados. Isso pode resultar em muitas marcações de dados, que podem causar problemas de desempenho de renderização. No entanto, a duplicação é feita após todas as computações serem feitas, assim, o tempo de consulta não é impactado. A duplicação de dados pode causar alguma confusão para os usuários. Algumas implementações abordagem esse problema destacando-se de modo interativo os dados de duplicada na visualização para o usuário. Alternativamente, algumas implementações evitam o empilhamento automático dos dados quando sabe-se que os mesmo é duplicada. Ao visualizar os dados, algumas implementações mostram os conjuntos de resultados separados para ajudar o usuário a entender o nível de detalhes de cada ponto de dados.

[0146] Algumas implementações combinam a mistura de com um modelo de objeto para construir visualizações de dados. A mistura de dados é um recurso de integração de dados ad hoc, que permite que os usuários se conectem facilmente a múltiplas fontes de dados desiguais e construam visualizações que usam os dados a partir de todos os mesmos. Isso permite que os usuários respondam a questões analíticas de negócios comuns quando dados relevantes podem ser armazenados em vários locais, como servidor Tableau, depósitos de dados corporativos, arquivos de planilha e arquivos de CSV,

[0147] A mistura de dados elimina a distinção entre as fontes de dados primária e secundária. Na mistura de dados, não há distinção visível de usuário entre as fontes de dados primária e secundária. Uma implicação importante dessa simetria consiste no fato de que os usuários serão capazes de misturar as “cadeias” de fontes de dados em conjunto (por exemplo, uma misturada com B misturada com C), permitindo a criação de esquemas não estrela.

[0148] A mistura de dados fornece semânticas de junção externa completa em vez de ser limitada às semânticas de junção restantes entre a fonte de dados primária e todas as fontes de dados secundárias. Desse modo, o domínio da análise não é limitado pelo conjunto de entradas na fonte de dados primária. Na mistura de dados, o padrão deve sempre mostrar todos os dados a partir de todas as fontes de dados. Os usuários têm capacidade de controlar esse comportamento através dos filtros e/ou configurações nas relações de fonte de dados. Adicionalmente, os campos relacionados são tratados de modo intercambiável, mostrando sempre todo o domínio coalescente, independente da fonte de dados. Por exemplo, se duas tabelas distintas estiverem juntas em um campo de dados de Estado, então, o campo de dados de Estado da tabela pode ser usado da mesma maneira. Se os usuários desejarem limiar o domínio a uma das fontes de dados de entrada, os mesmos podem abandonar um campo relacionado na prateleira de filtragem e obter uma opção de diálogo de filtro especial que permite a seleção múltipla das fontes de dados que contribuem para o domínio.

[0149] A mistura de dados elimina a necessidade de gerenciar o estado de ligação no visualizador de esquema. As ligações no visualizador de esquema permitem que os usuários controlem o nível de detalhes nos quais as fontes de dados misturadas são unidas. Na mistura de dados, a necessidade por ícones de ligação por lâmina é eliminada devido às semânticas de junção externas. Os usuários irão precisar ainda especificar as relações de fonte de dados, mas UI facilita isso.

[0150] A mistura de dados suporta todos os cálculos e conceitos de modelagem de dados em qualquer parte. Todos os cálculos funcionam em todas as fontes de dados, devido ao fato de que não há uma fonte que é designada como primária na mistura de dados. Em particular, os agregados não aditivos, como CONTAGD e MEDIAN, funcionam em todas as fontes de dados; dimensões de todas as fontes de dados dividem a vista com uso de dados de nível bruto (nenhuma agregação de ATTR é usada por padrão); cálculos de fonte de dados em cruz funcionam em dados de nível bruto e podem ser usados como dimensões; a geocodificação é feita para os dados de todas as fontes de dados e os resultados podem ser usados como dimensões na visualização; e conjuntos, grupos, caixas, campos combinados, e expressões de LOD funcionam consistente e independente de qual fonte de dados se originam.

[0151] A mistura de dados fornece relações de fonte de dados satisfatórias. Na mistura de dados, os usuários podem misturar nos resultados de geocodificação (e em algumas implementações, os usuários se podem misturar com cálculos de tabela). Além disso, os usuários podem especificar um conjunto mais rico de operadores de relação, como inclusão espacial, juntamente com mais operações padrão como < e É.

[0152] É útil comparar o processo ad hoc de mistura de dados às junções realizadas na integração de dados. Há pelo menos três partes de integração de dados que se referem à mistura de dados. Em primeiro lugar, as semânticas de integração de dados exigem tipicamente que as junções ocorram no começo do canal de processamento de dados. Isso tem vários resultados indesejados que são mais bem resolvidos com a mistura de dados.

[0153] A experiência do usuário para a integração de dados começa em uma ferramenta de modelagem de dados. Os usuários tem que tomar decisões complexas como aquelas das tabelas de base de dados para incluir sua fonte de dados e aqueles tipos de junção para usar antes que possam visualizar seus dados. Em contrapartida, a mistura de dados permite que os usuários construam incrementalmente o conjunto de tabelas que os mesmos usam em sua análise e definam relações apenas quando necessário. Algumas implementações ainda inferem algumas relações padrão para as mesmas. Esse aspecto de mistura de dados é a experiência padrão em algumas implementações. Os usuários apenas têm que definir junções específicas em cenários raros em que, por exemplo, o comportamento de duplicação de junções é atualmente desejável.

[0154] A junção antes da agregação duplica os dados, que frequentemente tornam os agregados incorretos. Isso pode algumas vezes ser evitado com uso de expressões de LOD para desfazer a duplicação. Por outro lado, na mistura de dados, o comportamento de junção após a agregação soluciona uma faixa muito mais ampla de cenários analíticos e é um padrão melhor. Além disso, é geralmente muito mais eficaz executar as junções após a agregação.

[0155] As junções alteram os dados do usuário. As junções internas, a esquerda e a direita filtram os dados de entrada, alterando o domínio dos dados do usuário. As junções externas, a esquerda e a direita introduzem NULOs em campos, que também podem ser muito desordenados, especialmente se já há NULOs nos dados. Atrasando as junções para mais tarde no canal e não expondo os detalhes das junções para o usuário, a mistura de dados tem flexibilidade para fornecer melhor comportamento por padrão.

[0156] Por essas razões acima, algumas implementações fornecem uma interface de usuário em que as semânticas de mistura são o padrão. Permite-se a especificação das junções concretas na definição de fonte de dados, mas isso se tornaria um cenário avançado para cobrir uma fração menor de casos de uso de integração de dados.

[0157] Uma segunda maneira de comparar a integração de dados com a mistura de dados é o diagrama de junção UI na janela de preparação de dados. Algumas implementações de mistura de dados utilizam o mesmo diagrama de junção básico.

[0158] A terceira maneira de comprar a integração de dados e a mistura de dados está relacionada à federação de dados. Algumas implementações de mistura de dados usam federação de dados. Isso significa que as computações de mistura podem ser movidas para onde a federação é realizada (por exemplo, o motor de dados Tableau).

[0159] Na mistura de dados, todas as fontes de dados se comportam essencialmente como fontes “primárias” de dados. Uma implicação importante desse projeto consiste no fato de que quando há uma relação muitos-para-muitos entre dimensões de múltiplas fontes de dados, o gerador de visualização de dados 290 pode duplicar visualmente as medidas através das múltiplas marcações. Isso é como pretendido. De fato, isso é exatamente a maneira na qual as expressões de LOD funcionam. Se duas expressões de LOD computam os agregados que são maiores que o LOD de visualização, cada uma das mesmas é duplicada através de todas as marcações.

[0160] Um ponto importante para se notar com as semânticas de mistura é que as junções podem introduzir as marcações de duplicada, mas os valores agregados ainda são significativos. Em contrapartida, as junções na integração de dados duplicam os primeiros dados, resultando frequentemente em valores agregados sem sentido e marcações duplicadas. As semânticas de mistura são, desse modo, o comportamento padrão.

[0161] Ageocodificação pode ser aplicada a ambas as tabelas primeiro para permitir a mistura em tipos espaciais que resulta da geocodificação. Isso é tratado como a mistura em qualquer outro cálculo.

[0162] A densificação é aplicada após a mistura de dados. Com uso de junção externa completa, as semânticas evitam a necessidade de aplicar a densificação primeiro devido ao fato de que todos os dados são retirados de ambas as fontes de dados.

[0163] Ao usar a mistura de dados, todos os campos relacionados têm uma opção “Usar fontes de dados selecionadas” 1702 que substitui a opção “Usar Todas”, conforme ilustrado na Figura 17. Aqui, os usuários podem especificamente selecionar quais domínios de fonte de dados devem ser coalescente para fornecer o domínio do campo relacionado.

[0164] Os filtros gerais nos campos relacionados são aplicados no nível de fileira a todas as tabelas relacionadas em relação ao domínio do campo relacionado (que é a união dos domínios de campo de entrada).

[0165] Os filtros N de Condição e Topo nos campos relacionados são tratados como filtros campo não relacionado na tabela contendo os campos usados no cálculo de classificação.

[0166] Os filtros nos campos não relacionados são sempre aplicados à tabela de fonte no nível de fileira.

[0167] Os filtros nos campos não relacionados são computados na tabela de fonte e, então, a tabela é transferida até o nível de campo relacionado para obter o domínio de campo relacionado que passa pelo filtro. Esse filtro é, então, aplicado para remover os valores que não passam pelo filtro. De modo importante, o mesmo não é usado para remover valores que existem em uma tabela relacionada, mas não existem na tabela de fonte.

[0168] Algumas implementações geram uma árvore de consulta para todas as consultas de base de dados. Em um alto nível, algumas implementações usam o seguinte padrão para gerar as consultas para uma visualização:

[0169] aplicar os filtros de fonte de dados a cada fonte de dados.

[0170] avaliar cálculos específicos de fonte de dados, incluindo a geocodificação.

[0171] usar as relações de mistura definidas para criar um árvore de junção através das fontes de dados filtradas. O padrão é usar junções externas onde o usuário não especificou explicitamente. Inserir a avaliação de cálculos de fonte de dados cruzados quando necessário na árvore (se um cálculo em cruz de fonte de dados for usado como um campo de relação, será necessário que seja avaliado o meio da árvore de junção). Os campos relacionados por igualdade são coalescentes em um único campo.

[0172] aplicar filtros de dimensão. De modo importante, os filtros que não excluem explicitamente valores “não correspondido” são assumidos para manter os mesmos.

[0173] Para cada fonte de dados, selecionar as combinações distintas de dimensões de visualização e campos de relação de dados a partir dessa fonte de dados. O resultado é uma tabela que mapeia a partir desses campos de relação da fonte de dados (“o LOD de junção”) para o LOD da visualização.

[0174] unir essa tabela de volta para a fonte de dados correspondente e aplicar um “grupo por” ara transferir o resultado até o LOD de visualização. Todos os agregados são diretamente transferidos do nível de fileira para o LOD de visualização.

[0175] unir todas as tabelas resultantes juntas nas colunas de LOD de visualização para gerar a tabela de dados de visualização.

[0176] aplicar os filtros medidos Seguidos pelo restante do canal de consulta padrão.

[0177] Para expressões de LOD, os filtros com subconsultas de N de Topo ou condições de agregado são gerados os quais replicam as peças da árvore acima.

[0178] Enquanto o padrão acima especifica o processo geral para construir a árvore de consulta para qualquer cenário de mistura, além disso, podem ser aplicadas otimizações que traduzem isso para uma forma muito mais eficaz.

[0179] Para permitir as otimizações, algumas implementações incluem metadados que rastreiam as dependências funcionais entre os campos de dados em cada tabela. Em algumas implementações, essas informações são disponíveis a partir das informações chave primárias na fonte de dados ou a partir das relações de campo calculadas. Para conjuntos de dados extraídos, algumas implementações analisaram anteriormente a tabela durante a extração e tornaram esses metadados disponíveis para o canal de consulta.

[0180] Algumas implementações também usam dependências de inclusão, como informações-chave estranhas/informações-chave primárias. Para as tabelas da mesma conexão de SQL, algumas implementações obtém essas informações a partir dos metadados de base de dados. Em outros casos, um usuário fornece essas informações.

[0181] Algumas implementações aprendem essas propriedades de metadados a partir das consultas anteriores, como a partir de um registro cronológico de histórico de visualização de dados 334.

[0182] Em algumas implementações, a mistura de dados usa federação em vez de fazer a mistura como um estágio de caso especial no interpretador de dados. A mistura de dados é implementada como uma árvore lógica de AQL (Linguagem de Consulta Analítica) que é compilada em uma árvore federada com uso de um canal de consulta (com algumas extensões de otimização apropriadas).

[0183] Em algumas implementações, a árvore federada é, por fim, executada primariamente no Motor de Dados de Tableau. Apara tornar os cenários analíticos espaciais possíveis, algumas implementações movem a geocodificação para o Motor de Dados Tableau também.

[0184] Algumas — implementações “incluem várias otimizações de desempenho. Em algumas implementações, as otimizações incluem:

[0185] dividir MÍN/MÁX/SOMA/CONTAG através dos níveis de detalhes de modo que esses agregados possam ser solicitados na primeira consulta, sem precisar de uma segunda passagem.

[0186] se as dependências de inclusão são conhecidas, as junções externas completas que não aumentam o tamanho do domínio podem ser simplificadas ou removidas

[0187] se algumas dependências funcionais são conhecidas, o processo pode evitar uma centralização que não faça nada.

[0188] algumas otimizações existentes podem ser generalizadas. Em particular, o pressionamento de filtro pode melhorar o desempenho.

[0189] Uma suposição para a mistura consiste no fato de que o processo pode criar uma tabela que mapeia a partir de dados de nível brutos de uma fonte de dados para as dimensões na vista (por exemplo, o conjunto de marcações). Isso é algumas vezes chamado de “tabela de junção” em alguma implementação da mistura de dados. Para permitir o comportamento de tabela primário para todas as fontes de dados em mistura de dados, o processo envia uma tabela de junção correspondente para cada fonte de dados que tem agregados em execução.

[0190] Conceitualmente, a tabela de junção mapeia a partir das colunas relacionadas de uma fonte de dados para as dimensões em execução na visualização de dados. Isso pode ser simplificado criando, em vez disso, uma tabela que mapeia a partir das colunas relacionadas para um índice de marcação (por exemplo, um número inteiro único para cada combinação de valores de dimensão). Isso evita a necessidade de enviar dimensões para as fontes de dados. Os valores de dimensão podem ser grandes, resultando em consultas complexas. e se os valores de dimensão forem cadeias (o que é comum), o processo poderá ter problemas de agrupamento ao mover dados entre fontes de dados. Um índice de marcação evita esses problemas.

[0191] Dada uma tabela de junção que mapeia a partir das colunas relacionadas ao índice de marcação, o processo pode se unir à base de dados remota de várias maneiras. Se as colunas relacionadas determinam funcionalmente o índice de marcação (que é o cenário mais comum), o processo pode converter a junção em uma sempre expressão de caso desde que não haja muitos casos. Se as colunas relacionadas não determinam funcionalmente o índice de marcação, o processo pode converter a tabela de junção em uma tabela literal, desde que a base de dados suporte as tabelas literais (por exemplo, servidor de SQL ou Postgres) e não haja muitas linhas na tabela. O processo pode criar uma tabela temporária na base de dados remota e se unir à mesma. Isso funciona apenas se o usuário tiver permissões para criar tabelas temporárias. Por fim, o processo pode puxar a fonte de dados remota no Motor de Dados Tableau e fazer sua junção no mesmo.

[0192] As Figuras 18A a 18C fornecem um fluxograma de um processo 1800 para gerar (1802) visualizações de dados de acordo com algumas implementações. O método é realizado (1804) em um dispositivo de computação 200 que tem um ou mais processadores e memória. A memória armazena (1806) um ou mais programas configurados para execução por um ou mais processadores.

[0193] O processo recebe (1808) uma especificação visual 104, que especifica uma ou mais fontes de dados 106, uma pluralidade de variáveis visuais 282, e uma pluralidade de campos de dados 284 a partir de uma ou mais fontes de dados 106. Cada uma da pluralidade de variáveis visuais 282 está associada (1810) a um respectivo ou mais dos campos de dados 284, e cada um desses campos de dados atribuídos 284 é uma dimensão d ou uma medida m. Tipicamente, a especificação visual 104 inclui (1812) uma ou mais variáveis visuais adicionais que não são associadas a quaisquer campos de dados 330 a partir de uma ou mais fontes de dados 106. Em algumas implementações, cada uma das variáveis visuais 282 é (1814) um dentre: atributo de linhas, atributo de colunas, atributo de filtragem, codificação de cor, codificação de tamanho, codificação de formato ou codificação de rótulo.

[0194] Para cada medida m dos campos de dados, o processo identifica (1816) um respectivo conjunto de dimensões acessíveis R(m) 292 que consiste em todas as dimensões d, dos campos de dados, que são acessíveis a partir da respectiva medida m por uma sequência de relações de muitos para um em um modelo de objeto predefinido para a uma ou mais fontes de dados. A sequência pode ser de comprimento 0, representando o caso em que a dimensão e a medida estão na mesma classe. Em algumas implementações, uma dimensão d é acessível (1820) a partir de uma medida m quando a dimensão d e a medida m estão em uma mesma classe no modelo de objeto predefinido ou, também, a medida m é um atributo de uma primeira classe C1 no modelo de objeto predefinido, a dimensão d é um atributo de uma n-ésima classe Cn no modelo de objeto, com n > 2, e há uma sequência de zero ou mais classes intermediárias C2, ..., Cn-1 no modelo de objeto predefinido de modo que haja uma relação de muitos para um entre as classes Ci e Ci+1 para cada i = 1, 2,...,nA1.

[0195] Para cada conjunto de dimensões acessíveis distinto R 292, o processo forma (1822) um respectivo conjunto de campos de dados S 294 dos campos de dados, em que S consiste em cada dimensão em R e cada medida m dos campos de dados para os quais R(m) = R.

[0196] Para cada um (1824) dos conjuntos de campos de dados S 294, o processo gera uma respectiva visualização de dados. Em primeiro lugar, para cada medida m no respectivo conjunto de campos de dados S, o processo centraliza (1826) os valores da medida m para um nível de detalhes especificados pelas respectivas dimensões no respectivo conjunto de campos de dados S. Em algumas implementações, centralizar os valores da medida m para um nível de detalhes especificados pelas respectivas dimensões no respectivo conjunto de campos de dados S inclui (1828) dividir as linhas de uma tabela de dados que contém a medida m nos grupos de acordo com as respectivas dimensões no respectivo conjunto de campos de dados S, e computar um único valor agregado para cada grupo.

[0197] Tipicamente, o operador que computa a única agregação é (1830) um dentre: SOMA, CONTAG, MIN, MÁX ou MÉDIA. Em algumas implementações, as palavras-chave CNT e MÉDIA são usadas em vez de CONTAG e MÉDIA. Algumas implementações fornecem operadores de agregação adicionais. Por exemplo, algumas implementações fornecem um operador de agregado ATTR(). Para cada grupo, o operador de ATTR() determina se todos os valores no grupo são iguais. Se forem, o operador de ATTR() retorna aquele único valor para o grupo; de outro modo,

o operador de ATTR() retorna “*”, indicando que há múltiplos valores para o grupo. Em algumas implementações, o único operador de agregação é (1830) um dentre: SOMA, CONTAG, CONTAGD, MÍN, MÁX, MÉDIA, MEDIAN, ATTR, PERCENTILE, STDEV, STDEVP, VAR, e VARP.

[0198] Para cada (1824) conjunto de campos de dados S 294, o processo também constrói (1832) uma respectiva visualização de dados de acordo com os campos de dados no respectivo conjunto de campos de dados S 294 e de acordo com as respectivas variáveis visuais 282 aos quais cada um dos campos de dados em S está associado. Em algumas implementações, a construção da respectiva visualização de dados inclui (1834) recupera os tuplos de dados a partir de uma ou mais fontes de dados 106 com uso de uma ou mais consultas de base de dados geradas a partir da especificação visual 104. Em algumas implementações, esses tuplos incluem (1836) dados agregados de acordo com as respectivas dimensões no conjunto de campos de dados S 294.

[0199] Em algumas implementações, o processo exibe (1838) a respectiva visualização de dados em uma interface gráfica de usuário 102 para o dispositivo de computação 200. Em algumas implementações, a exibição da visualização de dados inclui (1840) gerar uma pluralidade de marcações visuais, em que cada marcação corresponde a um respectivo tuplo recuperado a partir de uma ou mais fontes de dados. Em algumas implementações, a interface gráfica de usuário 102 inclui uma região de visualização de dados 412, e a visualização de dados é exibida na região de visualização de dados.

[0200] A terminologia usada na descrição da invenção no presente documento é para o propósito de descrever implementações particulares apenas e não se destina a ser limitante da invenção. Conforme usado na descrição da invenção e das reivindicações anexas, as formas singulares “um”, “uma”, “a” e “o” são destinadas a incluir as formas plurais também, a menos que o contexto indique claramente o contrário. Também será entendido que o termo “e/ou” conforme usado no presente documento se refere e abrange qualquer e todas as combinações possíveis de um ou mais dos itens listados associados. Será adicionalmente entendido que os termos “compreende” e/ou “compreendendo,” quando usados neste relatório descritivo, especificam a presença de recursos, etapas, operações, elementos e/ou componentes indicados, mas não excluem a presença ou adição de um ou mais outros recursos, etapas, operações, elementos, componentes e/ou grupos dos mesmos.

[0201] A descrição anterior, com a finalidade de explicação, foi descrita com referência às implementações específicas. No entanto, as discussões ilustrativas acima não são destinadas a serem exaustivas ou a limitar a invenção às formas precisas reveladas. Muitas modificações e variações são possíveis tendo em vista os ensinamentos acima. As implementações foram escolhidas e descritas a fim de explicar melhor os princípios da invenção e suas aplicações gráficas, para, através disso, permitir que outras pessoas versadas na técnica utilizem melhor a invenção e várias implementações com várias modificações visto que são adequadas para o uso particular contemplado.

Claims

U7

REIVINDICAÇÕES

1. Método para gerar visualizações de dados CARACTERIZADO pelo fato de que compreende: em um computador que tem um ou mais processadores, e memória que armazena um ou mais programas configurados para execução por um ou mais processadores: receber uma especificação visual, que especifica uma ou mais fontes de dados, uma pluralidade de variáveis visuais, e uma pluralidade de campos de dados a partir de uma ou mais fontes de dados, em que cada variável visual é associada a um respectivo ou mais dos campos de dados e cada um dos campos de dados é identificado como uma dimensão d ou uma medida m; para cada medida m dos campos de dados, identificar um respectivo conjunto de dimensões acessível R(m) que consiste em todas as dimensões d, dos campos de dados, que são acessíveis a partir da respectiva medida m por uma sequência de relações de muitos para um em um modelo de objeto predefinido para a uma ou mais fontes de dados; para cada conjunto de dimensões acessível distinto R, formar um respectivo conjunto de campos de dados S dos campos de dados, em que S consiste em cada dimensão em R e cada medida m dos campos de dados para a qual Rm) = R; e para cada conjunto de campos de dados S: para cada medida m no respectivo conjunto de campos de dados S, centralizar os valores da medida m para um nível de detalhes especificados pelas respectivas dimensões no respectivo conjunto de campos de dados S; e construir uma respectiva visualização de dados de acordo com os campos de dados no respectivo conjunto de campos de dados S e de acordo com as respectivas variáveis visuais aos quais cada um dos campos de dados em S está associado.

2. — Método, de acordo com a reivindicação 1, CARACTERIZADO pelo fato de que a especificação visual inclui adicionalmente um ou mais variáveis visuais adicionais que não são associadas a quaisquer campos de dados a partir de uma ou mais fontes de dados.

3. — Método, de acordo com a reivindicação 1, CARACTERIZADO pelo fato de que a construção da respectiva visualização de dados compreende adicionalmente recuperar tuplos de dados a partir de uma ou mais fontes de dados com uso de uma ou mais consultas de base de dados geradas a partir de especificação visual.

4, Método, de acordo com a reivindicação 3, CARACTERIZADO pelo fato de que os tuplos incluem dados agregados de acordo com as respectivas dimensões no respectivo conjunto de campos de dados S.

5. Método, de acordo com a reivindicação 3, CARACTERIZADO pelo fato de que compreende adicionalmente exibir a respectiva visualização de dados em uma interface gráfica de usuário para o computador.

6. — Método, de acordo com a reivindicação 5, CARACTERIZADO pelo fato de que a exibição da visualização de dados compreende gerar uma pluralidade de marcações visuais, em que cada marcação corresponde a um respectivo tuplo recuperado a partir de uma ou mais fontes de dados.

7. — Método, de acordo com a reivindicação 5, CARACTERIZADO pelo fato de que a interface gráfica de usuário inclui uma região de visualização de dados, o método compreende adicionalmente exibir a visualização de dados na região de visualização de dados.

8. Método, de acordo com a reivindicação 1, CARACTERIZADO pelo fato de que cada uma das variáveis visuais é selecionada a partir do grupo que consiste em: atributo de linhas, atributo de colunas, atributo de filtragem, codificação de cor, codificação de tamanho, codificação de formato e codificação de etiqueta.

9. “Método, de acordo com a reivindicação 1, CARACTERIZADO pelo fato de que uma dimensão d é acessível a partir de uma medida m quando a dimensão d e a medida m estão em uma mesma classe no modelo de objeto predefinido ou também a medida m é um atributo de uma primeira classe C1 no modelo de objeto predefinido, a dimensão d é um atributo de uma n-ésima classe Cn no modelo de objeto, com n > 2, e há uma sequência de zero ou mais classes intermediárias C2, ..., Cn-1 no modelo de objeto predefinido de modo que haja uma relação de muitos para um entre as classes Ci e Ci+1 para cada i = 1,2, ..., n-1.

10. Método, de acordo com a reivindicação 1, CARACTERIZADO pelo fato de que a centralização dos valores da medida m para um nível de detalhes especificados pelas respectivas dimensões no respectivo conjunto de campos de dados S compreende dividir as linhas de uma tabela de dados que contém a medida m nos grupos de acordo com as respectivas dimensões no respectivo conjunto de campos de dados S, e computar um único valor agregado para cada grupo.

11. Método, de acordo com a reivindicação 10, CARACTERIZADO pelo fato de que a computação do único valor agregado compreende aplicar uma função de agregado selecionada a partir do grupo que consiste em: SOMA, CONTAG, CONTAGD, MÍN, MÁX, MÉDIA, MEDIAN, ATTR, PERCENTILE, STDEV, STDEVP. VAR e VARP.

12. Sistema de computador para gerar visualizações de dados CARACTERIZADO pelo fato de que compreende: um ou mais processadores; e memória; em que a memória armazena um ou mais programas configurados para execução por um ou mais processadores, e em que o um ou mais programas compreendem as instruções para:

receber uma especificação visual, que específica uma ou mais fontes de dados, uma pluralidade de variáveis visuais, e uma pluralidade de campos de dados a partir de uma ou mais fontes de dados, em que cada variável visual é associada a um respectivo ou mais dos campos de dados e cada um dos campos de dados é identificado como uma dimensão d ou uma medida m; para cada medida m dos campos de dados, identificar um respectivo conjunto de dimensões acessível R(m) que consiste em todas as dimensões d, dos campos de dados, que são acessíveis a partir da respectiva medida m por uma sequência de relações de muitos para um em um modelo de objeto predefinido para a uma ou mais fontes de dados; para cada conjunto de dimensões acessível distinto R, formar um respectivo conjunto de campos de dados S dos campos de dados, em que S consiste em cada dimensão em R e cada medida m dos campos de dados para a qual Rm) = R; e para cada conjunto de campos de dados S: para cada medida m no respectivo conjunto de campos de dados S, centralizar os valores da medida m para um nível de detalhes especificados pelas respectivas dimensões no respectivo conjunto de campos de dados S; e construir uma respectiva visualização de dados de acordo com os campos de dados no respectivo conjunto de campos de dados S e de acordo com as respectivas variáveis visuais aos quais cada um dos campos de dados em S está associado.

13. Sistema de computador, de acordo com a reivindicação 12, CARACTERIZADO pelo fato de que a construção da respectiva visualização de dados compreende adicionalmente recuperar tuplos de dados a partir de uma ou mais fontes de dados com uso de uma ou mais consultas de base de dados geradas a partir de especificação visual.

14. Sistema de computador, de acordo com a reivindicação 13, CARACTERIZADO pelo fato de que os tuplos incluem dados agregados de acordo com as respectivas dimensões no respectivo conjunto de campos de dados S.

15. Sistema de computador, de acordo com a reivindicação 13, CARACTERIZADO pelo fato de que o um ou mais programas compreendem adicionalmente instruções para exibir a respectiva visualização de dados em uma interface gráfica de usuário para o computador.

16. Sistema de computador, de acordo com a reivindicação 15, CARACTERIZADO pelo fato de que a exibição da visualização de dados compreende gerar uma pluralidade de marcações visuais, em que cada marcação corresponde a um respectivo tuplo recuperado a partir de uma ou mais fontes de dados.

17. Sistema de computador, de acordo com a reivindicação 12, CARACTERIZADO pelo fato de que cada uma das variáveis visuais é selecionada a partir do grupo que consiste em: atributo de linhas, atributo de colunas, atributo de filtragem, codificação de cor, codificação de tamanho, codificação de formato e codificação de etiqueta.

18. Sistema de computador, de acordo com a reivindicação 12, CARACTERIZADO pelo fato de que uma dimensão d é acessível a partir de uma medida m quando a dimensão d e a medida m estão em uma mesma classe no modelo de objeto predefinido ou também a medida m é um atributo de uma primeira classe C1 no modelo de objeto predefinido, a dimensão d é um atributo de uma n-ésima classe Cn no modelo de objeto, com n > 2, e há uma sequência de zero ou mais classes intermediárias C2, ..., Cn-1 no modelo de objeto predefinido de modo que haja uma relação de muitos para um entre as classes Ci e Ci+1 para cada i =1,2,..., n-1.

19. Sistema de computador, de acordo com a reivindicação 12, CARACTERIZADO pelo fato de que a centralização dos valores da medida m para um nível de detalhes especificados pelas respectivas dimensões no respectivo conjunto de campos de dados S compreende dividir as linhas de uma tabela de dados que contém a medida m nos grupos de acordo com as respectivas dimensões no respectivo conjunto de campos de dados S, e computar um único valor agregado para cada grupo.

20. Meio de armazenamento legível por computador não transitório CARACTERIZADO pelo fato de que um ou mais programas configurados para execução por um sistema de computador que tem um visor, um ou mais processadores e memória, em que o um ou mais programas compreendem as instruções para: receber uma especificação visual, que específica uma ou mais fontes de dados, uma pluralidade de variáveis visuais, e uma pluralidade de campos de dados a partir de uma ou mais fontes de dados, em que cada variável visual é associada a um respectivo ou mais dos campos de dados e cada um dos campos de dados é identificado como uma dimensão d ou uma medida m; para cada medida m dos campos de dados, identificar um respectivo conjunto de dimensões acessível R(m) que consiste em todas as dimensões d, dos campos de dados, que são acessíveis a partir da respectiva medida m por uma sequência de relações de muitos para um em um modelo de objeto predefinido para a uma ou mais fontes de dados; para cada conjunto de dimensões acessível distinto R, formar um respectivo conjunto de campos de dados S dos campos de dados, em que S consiste em cada dimensão em R e cada medida m dos campos de dados para a qual Rm) =R; e para cada conjunto de campos de dados S: para cada medida m no respectivo conjunto de campos de dados S, centralizar os valores da medida m para um nível de detalhes especificados pelas respectivas dimensões no respectivo conjunto de campos de dados S; e construir uma respectiva visualização de dados de acordo com os campos de dados no respectivo conjunto de campos de dados S e de acordo com as respectivas variáveis visuais aos quais cada um dos campos de dados em S está associado.

Interface de Usuário de Visualização de Dados 102 Figura 1 EE ES ] 104 | Especificação Visual:

identificar as Fontes de Dados identificar os campos de dados atribuídos às variáveis visuais

110 108 Agrupar os campos de dados na Especificação Modelo de ta, Visual em um ou mais conjuntos de campos para as fontes ae Dados de dados de acordo com o Modelo de Objeto das Fontes de Dados 106 Pos 112 CC 1 ; Consultar as Fontes Fonte Consultar as Fontes de Dados de Dados para o primeiro (ou Fontes)| para o segundo conjunto conjunto de campos de dados de Dados de campos de dados Visualização de Dados 124, Visualização de Dados 122-, - ST : — — ai aforaniienen AE

Memória 214 216 Sistema de Operação 1 Dispositivo de Computação 200 Módulo ds Comunicaçãos 220 N Servidor da web [Aplicação de Visualização de Dados 222 102 Interface de Usuário Gráfica 250 Regiões de prateleira 230 Prateleira de colunas 232 Prateleira de fileiras Prateleira de filtros 262 = 264 Prateleira de marcações 2 e 270 202 Ícone de Codificação de Cor”, 374 CPU(s) 22 2º E 206 [a | 104 Especificação (ou Especificações) Visual á 280 Intertama da uonério Fontes de Dados Identificadas 208 262 Mecanismo/ 210 Variáveis Visuais Dispositivo 284 de Entrada Campos de Dados Atribuídos 204 Li | 108 STS Tou TAIS TEe=O) Modelo (ou Modelos) de Objeto 200 de comunicação Gerador de Visualização de Dados 292 7 294 Conjuntos de campos de Dados P: de Visual 26 . SS RS SNS Figura 2 “" Fontes de Dados/Base de Dados 106-1 Fonte de Dados 1

Memória 314: S - 316 Sistema de Operação = RNA 318 Módulo de comunicação ão Servidor da web Aplicação de Web de Visualização de Dados Se? Módulo de Interface de Usuário Seo Regiões de prateleira o Prateleira de colunas 232 Servidor de Visualização Prateleira de fileiras 262 de Dados 300 Prateleira de filtros N Sã , 264 Prateleira de marcações 70 ícone de Codificação de Cor rs — 272 202 Fi Crua [O 312 Da Especificação (ou Especificações) Visual 206 N Fontes de Dados Identificadas [2º bro N AAA 282 A A TIndrs "E Variáveis Visuais | Interface de usuário À 284 | 1 Visor (Campos de Dados Atribuídos EEB RL no — 11 ERES No or L = Eres Modelo (ou Modelos) de Objeto 1 290 Gerador de Visualização de Dados 292 204 Ss 294 Interface (ou Interfaces) |conjuntos de campos de Dados - — 326 Módulo de Recuperação de Dados a 7 ns 236 Parâmetros de Visualização j 328 Figura3 Base de Dados 106 Fonte (ou Fontes) de Dados Campos de Dados so Famlstra Cronológico de Aigtárico 334 de Visualização de Dados o Tv aaa A AÊ ESA IRA A ENS ISRAR EA A TOASE ce Co qse ae NE os cais uoccaoaou AC UCA RICA NA EN o a o EM RA o A EA A a A A AAA UERR oo oo sn Co O O SE MA o CSS ca sas dns | poe msn miicateicíio] RE: CAME A Mo 8 UN: SAS e o NEN RR co NU NAS o AS A REINO o RN a EEB o lua so E RN: No a o SEER O o Gus su dgelis era So eco Ro soe ds sons slsstinasídrS 1 000 E a Pesa o O õ Mol o poe do Ro cem E rá 7 Po AA A A E à e es lg ppp A w E dC / Pas DN Be E/S Duo A ac O Mao AE E n/a SM a EE EO E: 1 MA A A E & de, o É EE AA = Bee, 1.& .tVD0T- cc eat AEE BO OE js al eeA E E E A UEC A ad ia dando À s = Ss, ÃO a Eeeee ritARtÕto: PRADA DR eae O DQEDNR leme eine te rat eee MEIRA it Ba Ego o adro | hei inb À o ". BR: 21 ] E 1 o So" dagitiiisiiidasad: 88 dio 2d o ca NIISSSANSSISS ABS AESA DODNDdA SÉ BIAS filiiicediciesti ss sessesessss à | 8 o

S T = o co

À À o o 8 = & 3 8 E 8 3 & o [e] o o = — Po Po o o o [ e & T o O o w F & O — .— 2 . v v 1H â E A Ao 27/ e" mm e : 8 s /T às 2 £ : e *O: = o uns E 2 Ss a É õ vv co

A S a é o

E o ) - ê u Té ds E 5

VV o à

É ã E = ie, o $ uu & e 1. 2 É 11: Tê | : < aa] pro a Nm usa Sã so de Er 5 E EDEO Esso ee oo ca Eram 2 E ie | 8 À o 3 z | o.

Etta m h à = | g Ã * | P : | bes dd: no: ice Eee 1 qo 2 i : 131, — 8ig|ã à ssi - É El, iz SS) si NS z 2 3 :

7IN7 o o 3 | z í s $ io E ss : E $í 8 ú 8 o) = > ww 8 É Y Pr oo | 2 ' e é 3 2º m BR 4 7 it o 8 SN ss 2 SS 3 O o $$ z Ss t 8 e SE 18º o od õo ã e 8 & & Ss 3 EM: o TV .— 8 É É x ss /q, E = o . s S ão É = 2 s 8 2 E E 132 : dE 3 É EE 8 &:% OE 8 ns x = " 332 8 SEE & S s

Micolunas — Subeategoris i TaFileias — Soedao LUIS Soco: Subcategoria Categoria Estantes Cadeias Fido o 5,000 e. & Ss Mobiliário - so e e Equipamentos Ofício Persianas S5,000 o Material de 2 o Escritório — 3 * ? €Ç 48,008 “ Acessórios o 15,000 Tecnologia 5 30 EO Figura 9€ região, 1004 Ú o “— estado pedido , fornecedores 1009 . oo Figura 10 eai região, produto 1004 | : Seo “—estado pedidos — fornecedores ,, / AD 1oo2 Figura 11 o”

região ,, 1210 ”. NX 1208 “produto , estado pedidos , 12090 : Figura 12A Subcategoria Vendas de Categoria Acessórios — 836154 0320990937 Fauipamentos | ISORIOOIORADTS O Abc Persianas 7IOATOSAOONARS ac Estantes 741989 7983 | Cadeiras 741998.7958 i Copiadoras 836154 0329989997 Envelopes “FsdaTossaadaas AE Prendedores IneDST GssaNDONS é ape 1230 Móveis AAanaaao aatittas a Máquinas 238154 032590897 Papel aee Telefones 536154 032890987 Fornecedores MSgatpIaADaDos ame Mesas 7419697983 Figura 12B PO 1252 Figura 12C

1202 ss. empresas om países ,,, Figura 13A Empresa Fring stapis pack =: DE accoHIDE | ep m ivato AAA anence | ampas É ves País Estados Unidos RAS 1324 o 200 4ou sos eoo Contagem diferente do Nome do Cliente Figure 13B

—— & 3 3 : e 3 8 E o ' : ; í e : & 7) 3 zZ :$ : ss Ê [. : : 5 és : : a 8 : 42 ss à : as 8 ' =? : 8 A $ : E j 5 | g . OQ a as SS . SR s 3 r ; E : : 8 à, É É á Z ú & És 3 s% cd | : | E se > : E 1.) css as l 1) 8 BLESS REÇITR RS SNINENEDO: E ASNEA Es 4 s$4E “é o ai E so *? & : Mp)

T S o

S S tê E 8 2? Ss : is o ss > & ES 2 x Ss nº -. 8 FÃ Tê F. e E. ES É 2 é êS se 8 s : a : 8 Sr 8 "mm T ! | RN a Ci góri = O Mn A o À E PST ASA a 7? i Bea aoSSSadosas e : Ss &

T PESSSSPPSESSAL - S aitiisiisiiilo om | gs Dis SSSISR IA N oo G > >sasBeseiivçãos UM = z Tc ERPAR THE - gE3 239 A 82º S 2

E S iz 18 I— 2 vo = dd 4 No A o a /õ o Í o. - e =| EI o = Ai) s 3 to St TE o = —. ls r< E 8 Ó Rs = z 8 “gil Re. 2244 â 2 » 5 cs

O o e It: $ á I— j 2 = "o. ã g z o qo x ao o * z

1506, estado

15025. E. S [71 clientes pm empresas ,,, Figura 15 Dimensão: SELECIONAR Dimensão, <Reachable Dimensions> DE <Snowflake> EM QUE <Reachable Filters> AGRUPAR POR Dimensão, <Reachable Dimensions> Medição : SELECIONAR AGG (Medição), <Reachable Dimensions> DE <Snowflake> EM QUE <Reachable Filters> AGRUPAR POR <Reachable Dimensions> Figura 16 FDA ta NANA a LEUEREUAS Í MGerailid asteristico condição superior i Selecionar — ListadeValor Fontesdedados.. Í 9 Sta Personalizada SD selecionadas de uso. | Inserir lista de busca Ss T | Hipermercado 1 1702 | cadeiras de café Í | 1 voos : | — Figura17 Todos Mentum mar 1 Reme Seleção! Selecionou Ode 49valores oo aerea fofos — condição Nenhum time Sena COS OS Redefinir — Aplicar Cancelar :

q Figura 18A 1802- . Um método gera visualizações de dados 1804 ã á s S Es. ” O método é realizado em um dispositivo de computação que tem um ou mais processadores e memória 1806]. | A memória armazena um ou mais programas configurados para execução por um ou mais processadores 1808 Receber uma especificação visual, que específica = uma ou mais tontes de dados, uma pluralidade de variáveis visuais e uma pluralidade de campos de dados a partir de uma ou mais fontes de dados.

1810. CTada variável visual é associada ao respectivo um ou mais dos campos de dados e cada um dos campos de dados é identificado como uma dimensão d ou uma medida m. 1812 " A especificação visual inclui uma ou mais i 1 variáveis visuais adicionais que não estão associadas |

1... à quaisquer campos de dados de uma ou mais fontes de dados. ! 1814--] ! cada uma das variáveis visuais é um dentre: atributo de fileiras. atributo à ide colunas, atributo de filtro, codificação de cor, codificação de tamanho, L codificação de formato ou codificação de rótulo 1 1816 Para cada medida m dos campos de dados, identificar um respectivo conjunto de dimensões alcançáveis R(m) que consiste em todas as dimensões d, dos campos de dados, que são alcançáveis a partir da respectiva medida m por uma sequência de relações muitos para um em um modelo de objeto predefinido para uma ou mais fontes de dados. ImeeneeseeennreeeeendAente tece dmemememrmrmememmmmmnmanroo | Uma dimensão d é alcançável a partir de uma medida m quando a ' 1820 : a. ” a 1 |) dimensão d e a medida m estão em uma mesma classe no modelo de ' 1 objeto predefinido ou, além disso, a medida m é um atributo de uma : 1 primeira classe C1 no modelo de objeto predefinido, a dimensão d é um : 1 atributo de uma n-ésima classe Ch no modelo de objeto, com n > 2, e há i ' 1 uma sequência de zero ou mais classes intermediárias C2,..., Cn-1 no modelo | 1 de objeto predefinido de modo que haja uma relação de muitos para um 1 L entre as classes Ci e Ci+1 para cadaum ii =1,2,..., n-1. 1

1822 Para cada conjunto de dimensões alcançáveis distintas R, a partir de um respectivo conjunto de campos de dados S dos campos de dados, em que S consiste em cada dimensão em R e cada medida m dos campos de dados para cada R(m) = R. 1824 Para cada conjunto de campos de dados S: 1826 Para cada medida m no respectivo conjunto de campos de dados S, centralizar os valores da medida m para um nível de detalhes especificado pelas respectivas dimensões no respectivo conjunto de campos de dados S.

ImemmeneemeemeeeeeemenemememmemmememmmmmmmamnnacA 1828— | Centralizar os valores da medida m para um nível de detalhes especificado i 1 pelas respectiva dimensões no respectivo conjunto de campos de dados S inclui 1 | dividiras fileiras de uma tabela de dados contendo a medida m em grupos de | | — acordo com as respectivas dimensões no respectivo conjunto de campos — | ' de dados S e computar um único valor agregado para cada grupo. ' ' ' É quesmemameeessmeesmenaaee sm secam À 1830 o E à ta 11 Computaro único valor agregado compreende aplicar uma das 1 1 | funções de agregado SOMA, CONTAG, CONTAGD, MIN, MÁX, MÉD, Hs i à MEDIAN. ATTR, PERCENTILE, STDEV, DTDEVP, VAR ou VARP. à. i ia .. a .. i Lesss======—===="="—===="—=—==——=-=———-—=-==——-——-———-. E | Figura 18B

1824 Para cada conjunto de campos de dados (continuação):

1832. Construir uma respectiva visualização de dados de acordo - com os campos de dados no respectivo conjunto de campos de dados S e de acordo com as respectivas variáveis visuais às quais cada um dos campos de dados em S está associado.

peqscnbencenmPanaeneeneeanmennenenamenenenen—areSTT| 1834 1 Construira respectiva visualização de dados inclui recuperar ' 1 tuplos dos dados a partir de uma ou mais fontes de dados com — | | usode uma ou mais consultas de base de dados geradas a partir — | i da especificação visual. ' À pessnsrensbnetrcoeeronconacraaSEESESSSSERSESO 1836— 1 1 Ostuplos incluem dados agregados de acordo com as ia 1 | respectivas dimensões no respectivo conjunto de campos de ' ' | Lossesssesseccee sea SEIOSSo a natanaantasS À : ' bits radiante aid eira rabo aiaicoi: EE | 1838 1! Exibirarespectiva visualização de dados em umainterface 4 1 Do de usuário gráfica para o computador. vo O va 1840 E E O mr A ir É ' —1 1 1 Exibira visualização de dados inclui gerar uma pluralidade! + 1 1 | idemarcações visuais, em que cada marcação corresponde; + 1 11 | aumrespectivo tublo recuperado a partir de uma ou mais! | i 1 À ' fontes de dados. 1) Cs) 2 1 1 bessesesseersesesessess.-———..--====—=——.-.. 4 1 A. 1 É pemenoeenemeentenemeagententenmaeeententea: À à A ada z ' 1842 | 411 Ainterfacedeusuáriográficaincuiumaregiãode — à 4 À 111 visualiaçãodedadoseavisualzaçãodedadosé — | 4 1 Dao exibida na região de visualização de dados. ao 1 T EsSsSSSSSCSSNSSESTSSTESCSRSCRRCENCSNREENSS à | Desen! ' Figura 18C