JMAP SPATIAL OLAP

Com as in´umeras iniciativas para prover uma total integra¸c˜ao entre processamento multidimen- sional e geogr´afico, tornou-se comum o uso do termo SOLAP (Spatial OLAP ). Em [247, 248, 14], os autores definem as ferramentas para OLAP espacial, bem como apresentam conceitos rela- cionados a elas. Al´em disso, s˜ao descritas caracter´ısticas essenciais e desej´aveis dessa nova cate- goria de ferramentas para processamento anal´ıtico e espacial. A Figura 3.1, mostra a estrutura de um ambiente de OLAP espacial segundo a vis˜ao destes autores [247, 248, 14]. Um ambiente SOLAP geralmente ´e composto por: i) Ferramentas para extra¸c˜ao, integra¸c˜ao, limpeza e carga dos dados oriundos de fontes convencionais e de bancos de dados geogr´aficos; ii) Data Ware- house Geogr´afico; iii) Mecanismos para processamento anal´ıtico-multidimensional e geogr´afico e iv) Aplica¸c˜oes com interface gr´afica, sincronizando mapas, tabelas e gr´aficos para a visualiza¸c˜ao

3.2 JMAP SPATIAL OLAP 19

e an´alise dos dados.

Figura 3.1 Estrutura de um Ambiente SOLAP (Adaptado de [248])

Um sistema SOLAP pode conter trˆes tipos de dimens˜oes espaciais [248, 13]: i) dimens˜oes n˜ao geom´etricas, que s˜ao aquelas implementadas pelas ferramentas OLAP tradicionais, nas quais apenas dados descritivos s˜ao representados (e.g. nomes dos estados, das cidades e dos lugares); ii) dimens˜oes geom´etricas, que s˜ao aquelas que, para cada membro de um n´ıvel existe uma geo- metria associada (e.g. pol´ıgono representando o limite do estado), podendo estes membros ser visualizados em mapas e podem ser consultados e manipulados com a utiliza¸c˜ao de operadores espaciais; e iii) dimens˜oes mistas, nas quais apenas alguns n´ıveis possuem geometrias associadas aos seus membros (e.g. o n´ıvel pa´ıs ). No que se refere a medidas espaciais, o trabalho dis- tingue dois tipos de medidas: i) conjunto de geometrias, que necessitam de opera¸c˜oes espaciais como uni˜ao ou intersec¸c˜ao para serem computadas; e ii) valor resultante da aplica¸c˜ao de alguma opera¸c˜ao topol´ogica ou m´etrica [248].

As id´eias apresentadas em [247, 248] resultaram na implementa¸c˜ao da ferramenta comercial para OLAP espacial chamada JMap Spatial OLAP [277]. A Interface gr´afica da ferramenta JMap ´e apresentada na Figura 3.2. Um dos estudos de caso realizados com JMap foi na ´area de sa´ude, com dados sobre doen¸cas e informa¸c˜oes sobre qualidade do ar, entre outros. Dessa

3.2 JMAP SPATIAL OLAP 20

forma, com JMap, os usu´arios podem realizar consultas para encontrar, por exemplo, a rela¸c˜ao existente entre a ocorrˆencia de doen¸cas respirat´orias e a qualidade do ar em determinadas regi˜oes.

Figura 3.2 Interface Gr´afica do JMap Spatial OLAP

Com rela¸c˜ao `a implementa¸c˜ao, os seguintes aspectos s˜ao apresentados para o sistema JMap: i) Para constru¸c˜ao da base de dados, foram utilizadas as solu¸c˜oes propriet´arias Microsoft SQL Server [70] para registro dos dados convencionais e Intergraph GeoMedia 4 [156] para armazena- mento dos dados espaciais; ii) Para o desenvolvimento do servidor SOLAP, foi utilizado o Mi- crosoft Analysis Services 2000 em conjunto com o Intergraph GeoMedia 4 ; iii) Na aplica¸c˜ao cliente, componentes comerciais da ProClarity [238] foram utilizados em conjunto com o Inter- graph GeoMedia 4 para visualiza¸c˜ao dos gr´aficos, tabelas e mapas; iv) Finalmente, a linguagem de programa¸c˜ao utilizada para a elabora¸c˜ao da interface gr´afica foi o Visual Basic.

No JMap, as medidas espaciais s˜ao implementadas atrav´es de ponteiros, que fazem a liga¸c˜ao dos dados armazenados em uma estrutura de DW (i.e. baseada no esquema flocos de neve ou estrela [163]) com fei¸c˜oes geogr´aficas armazenadas em algum formato de dado espacial que

3.3 MAPWAREHOUSE 21

n˜ao pertence ao sistema gerenciador de banco de dados, ou seja, n˜ao possuem um DWG com base integrada de dados e utilizam a mesma t´ecnica para armazenamento de dados geogr´aficos apresentada em [268, 267].

Quanto aos tipos de opera¸c˜oes dispon´ıveis no JMap, s˜ao priorizadas as opera¸c˜oes de agrega¸c˜ao e desagrega¸c˜ao (i.e. roll-up e drill-down). Inclusive, s˜ao propostas duas varia¸c˜oes para os operadores roll-up e drill-down (i.e. operadores Close e Open respectivamente). Estes operadores s˜ao utilizados para agregar ou desagregar somente determinados membros em uma dimens˜ao, o que ´e equivalente aos operadores DrillDownMember e DrillUpMember implementa- dos na linguagem MDX [67, 297]. Entretanto, os autores n˜ao informam se a ferramenta ´e capaz de realizar an´alises integrando operadores espaciais (e.g. operadores topol´ogicos, m´etricos ou direcionais) e operadores anal´ıticos (e.g. rank). Isto indica que a abordagem realiza apenas mapeamentos, ou seja, a partir das liga¸c˜oes existentes entre os dados convencionais e suas geo- metrias, os mapas s˜ao constru´ıdos e manipulados atrav´es de cliques efetuados pelos usu´arios na interface gr´afica.

3.3 MAPWAREHOUSE

Outro trabalho que prop˜oe integra¸c˜ao entre processamento multidimensional e geogr´afico ´e o MapWarehouse [251]. Neste trabalho, ´e apresentado um modelo l´ogico para Data Warehouse Geogr´afico, o qual ´e implementado sobre um SGBD objeto-relacional. O modelo proposto ´e baseado em uma extens˜ao do modelo estrela tradicional [163] contendo: i) conceitos e estruturas do modelo objeto-relacional e ii) componentes espaciais. A abordagem possibilita a utiliza¸c˜ao de medidas espaciais como objeto de an´alise, e opera¸c˜oes OLAP como drill-down e roll-up s˜ao implementadas atrav´es das fun¸c˜oes de agrega¸c˜ao dispon´ıveis no SGBD Oracle Spatial (e.g. uni˜ao de geometrias).

A Figura 3.3 mostra o metamodelo espacial e multidimensional da proposta MapWarehouse. Como pode ser analisado nesta figura, o modelo consiste da extens˜ao do modelo tradicional de DW, acrescentando os conceitos de Cubo Espacial, Medida Espacial, Dimens˜ao Espacial, Hierarquia Espacial, N´ıvel Espacial e Atributo Espacial.

Em [251], um Data Warehouse Geogr´afico ´e conceitualmente visualizado como um cubo ge- ogr´afico composto de medidas geogr´aficas e n˜ao geogr´aficas, com dimens˜oes, hierarquias e n´ıveis geogr´aficos e n˜ao geogr´aficos. Assim, os autores n˜ao deixam claro a diferen¸ca entre modelagem multidimensional voltada para representar o cubo de dados e a modelagem dimensional voltada para a representa¸c˜ao do DW. Existe uma diferen¸ca entre a modelagem do Data Warehouse Geogr´afico e dos cubos geogr´aficos. A modelagem do DWG ´e dimensional e os conceitos de m´ultiplas dimens˜oes, hierarquias e n´ıveis n˜ao fazem parte deste contexto. Uma vez criado o DWG (base de dados), passa a ser poss´ıvel a cria¸c˜ao de cubos de dados geogr´aficos, para fornecer diferentes vis˜oes dos dados armazenados, inclusive envolvendo in´umeras dimens˜oes, hierarquias

3.3 MAPWAREHOUSE 22

Figura 3.3 Metamodelo Espacial e Multidimensional do MapWarehouse [251]

e n´ıveis, provendo uma vis˜ao configur´avel dos dados sob diferentes perspectivas. Dessa forma, a maneira com que os dados foram organizados no DWG pode auxiliar na cria¸c˜ao destes cubos de dados para posterior an´alise dos dados. Maiores detalhes sobre modelagem dimensional e multidimensional podem ser obtidos em [120].

Um estudo de caso para a ´area de produ¸c˜ao agr´ıcola ´e apresentado para demonstrar as id´eias na pr´atica. Neste estudo, ´areas de plantio s˜ao armazenadas em um DWG e posteriormente analisadas via consultas SQL. A Figura 3.4 mostra o esquema da base de dados da abordagem MapWarehouse. A implementa¸c˜ao deste estudo de caso fez uso do Oracle Spatial [75], no qual os objetos geogr´aficos foram armazenados utilizando o tipo de dados SDO Geometry do Oracle Espacial, tornando a solu¸c˜ao dependente de uma ferramenta comercial.

As consultas aos dados s˜ao realizadas atrav´es da extens˜ao espacial da SQL dispon´ıvel no SGBD Oracle. Dessa forma, a elabora¸c˜ao de consultas mais complexas necessariamente dever˜ao ser realizadas por profissionais da ´area de banco de dados, que conhecem o esquema do DWG em detalhes e tamb´em as fun¸c˜oes dispon´ıveis e a sintaxe da extens˜ao espacial da linguagem. Por exemplo, uma consulta do tipo: Exiba as ´areas geogr´aficas de planta¸c˜ao de milho e feij˜ao e quantidades de milho e feij˜ao por ´area geogr´afica, dentro de uma janela retangular, para cada meso-regi˜ao e para cada micro-regi˜ao do estado da Para´ıba, durante maio de 2003, na atual

3.4 GEWOLAP 23

Figura 3.4 Esquema Estrela Estendido do MapWarehouse (Adaptado de [251])

sintaxe de consulta do MapWarehouse seria expressa da forma apresentada na Figura 3.5. Como podemos perceber, existe uma complexidade agregada `a atividade de elaborar consultas deste tipo, e esta complexidade pode aumentar consideravelmente com a inser¸c˜ao de um n´umero maior de operadores (espaciais ou anal´ıticos) em uma ´unica consulta. Isto poderia ser minimizado com a utiliza¸c˜ao de uma interface gr´afica apropriada ao contexto geogr´afico e multidimensional ou com uma linguagem de consulta otimizada para este prop´osito. A Figura 3.6 mostra um exemplo de como os resultados s˜ao visualizados ap´os a execu¸c˜ao das consultas, entretanto, n˜ao fica claro como ´e realizada a intera¸c˜ao entre a aplica¸c˜ao e a interface gr´afica no MapWarehouse. Al´em disso, o fato das fun¸c˜oes utilizadas pela aplica¸c˜ao serem do componente espacial do Oracle, pode aumentar o custo de aplicar a abordagem com a utiliza¸c˜ao de um SGBD diferente.

3.4 GEWOLAP

A proposta GeWOlap [18, 19] tem como objetivo prover processamento geogr´afico e multidi- mensional na Web. Esta proposta ´e baseada em trabalhos anteriores dos mesmos autores, que englobam a especifica¸c˜ao de um modelo de dados multidimensional e geogr´afico e uma ´algebra que redefine operadores OLAP tradicionais (e.g. Roll-up, Drill-Down, Slice e Dice) [240] para serem utilizados no ambiente de Data Warehouse Geogr´afico [17, 18].

3.4 GEWOLAP 24

Figura 3.5 Exemplo de Consulta na abordagem MapWarehouse

Muitas das id´eias apresentadas em [19] s˜ao muito similares `as descritas no artigo [83], no qual uma arquitetura em camadas ´e apresentada, contendo os mesmos componentes na primeira e segunda camadas (i.e. Data Warehouse Geogr´afico e o mecanismo de processamento multidi- mensional e geogr´afico, respectivamente). Al´em disso, as abordagens assemelham-se em alguns aspectos de implementa¸c˜ao, como por exemplo a extens˜ao do Servidor OLAP Mondrian [224] com funcionalidades para manipula¸c˜ao de dados geogr´aficos e a utiliza¸c˜ao do JPivot [239] como componente de interface gr´afica e visualiza¸c˜ao dos resultados.

Neste trabalho, s˜ao discutidas as maneiras mais comuns de incluir dados geogr´aficos em um Data Warehouse tradicional, para torn´a-lo um DWG. A primeira forma ´e a utiliza¸c˜ao de dimens˜oes espaciais no modelo multidimensional e a segunda consiste na utiliza¸c˜ao de medidas espaciais. Na primeira abordagem, os dados geom´etricos n˜ao s˜ao armazenados nas dimens˜oes juntamente com os dados descritivos. Na Figura 3.7-(A), ´e apresentado um exemplo de mode- lagem considerando o uso de dimens˜oes espaciais para an´alise das taxas de mortalidade. Na segunda abordagem, ´e utilizado o conceito de medida espacial, no qual a geometria ´e armazenada na tabela de fatos do DWG ou consiste de um ponteiro para um dado geogr´afico. Nesta segunda op¸c˜ao existe o problema relacionado com a defini¸c˜ao de fun¸c˜oes de agrega¸c˜ao e desagrega¸c˜ao para serem aplicadas sobre estas medidas. A Figura 3.7-(B) mostra a modelagem de um DWG

3.4 GEWOLAP 25

Figura 3.6 Interface Gr´afica do MapWarehouse

Figura 3.7 Modelagem de um DWG para An´alise da Mortalidade utilizando Dimens˜oes e Medidas Espaciais

para a an´alise das taxas de mortalidade, no qual o objeto geogr´afico que representa a geometria dos departamentos ou setores ´e o objeto de an´alise na tabela de fatos.

A Figura 3.8-(A) mostra a arquitetura de software GeWOlap. Como pode ser analisado, na camada de dados, o DWG ´e criado utilizando o SGBD propriet´ario Oracle, e conseq¨uentemente, utiliza sua extens˜ao espacial Oracle Spatial para manipula¸c˜ao dos dados geogr´aficos. Na camada

3.5 SOVAT 26

Figura 3.8 Arquitetura GeWOlap

de aplica¸c˜ao, encontra-se o servidor OLAP Mondrian, e na camada de interface ´e utilizado o JPivot juntamente com o MapXtreme, o qual ´e utilizado para exibi¸c˜ao dos dados geogr´aficos resultantes da consulta.

Na Figura 3.8-(B), pode ser visualizado o resultado de uma consulta processada pelo sistema GeWOlap constru´ıdo pelos autores. Neste estudo de caso, um DWG ´e utilizado para an´alise da mortalidade, no qual os departamentos s˜ao utilizados como medidas espaciais. O resultado exibido na tabela multidimensional utilizando o JPivot mostra que as medidas espaciais referem- se a ponteiros para objetos geogr´aficos e para valores agregados. Em um trabalho dos mesmos autores, apresentado em [17], ´e feita a referˆencia para um prot´otipo desktop, chamado G´eOlap, que usa apenas medidas num´ericas. Os dados geogr´aficos s˜ao representados implementando o conceito de dimens˜oes geogr´aficas. Entretanto, detalhes de implementa¸c˜ao n˜ao s˜ao informados.

3.5 SOVAT

SOVAT (Spatial OLAP visualization and analysis tool ) [252, 253] ´e outro trabalho interessante na ´area de processamento anal´ıtico e espacial, possibilitando a visualiza¸c˜ao dos resultados de uma consulta em mapas e gr´aficos. A arquitetura proposta pode ser visualizada na Figura 3.9. Como podemos observar nesta figura, a arquitetura cont´em as camadas de dados, de aplica¸c˜ao e de interface gr´afica com o usu´ario.Na camada de dados, podemos perceber que um DWG n˜ao ´e usado como base de dados integrados. Os dados multidimensionais e geogr´aficos s˜ao mantidos em bases distintas. Na camada de aplica¸c˜ao, m´odulos de software foram desenvolvidos utilizando

3.5 SOVAT 27

a plataforma .NET [71] para permitir a integra¸c˜ao e explora¸c˜ao dos dados multidimensionais e geogr´aficos armazenados na camada de dados. S˜ao permitidas an´alises espec´ıficas do ambiente OLAP e tamb´em minera¸c˜ao de dados, as quais s˜ao providas pelos componentes OLAP e de Minera¸c˜ao de dados do Microsoft SQL Server [70].

Figura 3.9 Arquitetura de Software da proposta SOVAT (Adaptado de [253] )

No que se refere ao processamento geogr´afico, n˜ao foi poss´ıvel identificar quais opera¸c˜oes espaciais podem ser utilizadas. Somente comentam que ´e poss´ıvel realizar consultas envolvendo o operador espacial Buffer e utilizar a t´ecnica de an´alise de redes para encontrar a melhor rota em um mapa espec´ıfico. Por´em, com rela¸c˜ao aos operadores topol´ogicos e posicionais (e.g. intersects, touches, crosses e within ) nada ´e comentado. No trabalho discutido em [252, 253] tamb´em ´e apresentado o operador Drill-Out, que possibilita recuperar as fei¸c˜oes geogr´aficas que s˜ao vizinhas de uma determinada fei¸c˜ao geogr´afica, o que possivelmente ´e implementado verificando a intersec¸c˜ao entre objetos geogr´aficos. Tamb´em s˜ao omitidos detalhes sobre como ´e mantida e manipulada a liga¸c˜ao entre os dados multidimensionais do DW e os objetos geogr´aficos da base de dados. A Figura 3.10 mostra como os resultados das consultas realizadas no ambiente SOVAT s˜ao exibidas pela interface gr´afica.

Para demonstrar as id´eias na pr´atica, foi desenvolvido um estudo de caso com dados de um departamento de sa´ude e com dados estat´ısticos sobre doen¸cas, popula¸c˜ao, n´umero de interna¸c˜oes e dados s´ocio-econˆomicos. Dois princ´ıpios guiaram o desenvolvimento da interface gr´afica do ambiente SOVAT : a facilidade de uso e a completa integra¸c˜ao entre SIG e OLAP.

3.6 PQL 28

Figura 3.10 Interface Gr´afica SOVAT

Com o estudo de caso desenvolvido, testes de usabilidade da ferramenta foram realizados com membros da comunidade de sa´ude, o que contribuiu para a realiza¸c˜ao de melhoramentos na interface ao final de cada bateria de testes.

3.6 PQL

Outro projeto interessante que pode ser encontrado na literatura de Banco de Dados ´e o da lin- guagem PQL (Pictorial Query Language) [231, 111, 112, 232, 229]. Nessa pesquisa, Pourabbas et al. apresentam um modelo de dados geogr´aficos orientado a objetos, que ´e estendido para dar suporte ao uso de links para cubos de dados multidimensionais. Entretanto, n˜ao ´e apre- sentada uma linguagem de consulta que permita a total integra¸c˜ao entre operadores espaciais e multidimensionais, sendo discutida uma linguagem baseada em SQL e muito semelhante `as abordadas no Cap´ıtulo 2.

Conforme detalhado em [232], PQL possibilita que a partir do resultado de uma consulta espacial, possa se chegar aos dados multidimensionais relacionados, devido `as liga¸c˜oes existentes entre estes dados. Al´em disso, conforme mostrado em [111], a base de dados geogr´afica ´e mantida separada da base multidimensional, n˜ao considerando a existˆencia de um DW geogr´afico, sendo isto uma das desvantagens da proposta PQL.

3.6 PQL 29

Figura 3.11 Instˆancias dos Atributos Funcionais vendas carro e vendas brinquedos [111]

Em [112], ´e comentada a importˆancia da existˆencia de uma integra¸c˜ao entre os ambientes geogr´afico e multidimensional, para aumentar a efic´acia e qualidade das consultas para suporte `

a decis˜ao. O elemento chave para possibilitar a integra¸c˜ao destes ambientes ´e a dimens˜ao geogr´afica, a qual est´a sempre presente, implicitamente ou explicitamente, em um banco de dados multidimensionais [112].

Esta proposta utiliza atributos espec´ıficos, chamados de atributos funcionais, na estrutura do banco de dados geogr´afico orientado a objetos. Estes atributos funcionais tˆem como obje- tivo descrever todos os fenˆomenos representados pelo cubo de dados multidimensional e cada atributo ´e formado por um par contendo o nome do cubo e o nome da vari´avel do cubo. O primeiro campo corresponde ao fenˆomeno considerado (e.g. vendas de carro por modelo, mˆes e munic´ıpio) e representa os fatos do cubo. O segundo campo ´e composto por todos os nomes das vari´aveis, exceto a geogr´afica, pois esta implicitamente tem o mesmo nome da instˆancia geogr´afica (e.g. Munic´ıpio - ver Figura 3.11). Dessa forma, esta abordagem associa dados que est˜ao armazenados em bases separadas, e a partir desta liga¸c˜ao, se torna poss´ıvel a realiza¸c˜ao de consultas multidimensionais e geogr´aficas. Neste trabalho, n˜ao fica claro se o prot´otipo im- plementa todas as funcionalidades apresentadas e tamb´em n˜ao informam sobre as tecnologias utilizadas no desenvolvimento do projeto.

3.7 PIET 30

A Figura 3.11, adaptada de [111], mostra as associa¸c˜oes existentes entre os dados geogr´aficos e multidimensionais que podem ser realizadas atrav´es dos atributos funcionais e que se assemel- ham a referˆencias entre objetos.

3.7 PIET

Piet [104] ´e outro trabalho dispon´ıvel na literatura de banco de dados, que tem como objetivo a integra¸c˜ao entre SIG e OLAP. Nesse trabalho, que ´e baseado no modelo publicado em [130], uma dimens˜ao geogr´afica ´e composta de um conjunto de grafos, cada um descrevendo um conjunto de geometrias de uma camada tem´atica. Estas geometrias est˜ao relacionadas a membros de n´ıveis de um cubo multidimensional. O modelo ´e implementado por um arquivo XML, chamado de Piet-Schema, que cont´em os mapeamentos entre os objetos geogr´aficos e o cubo de dados.

Uma linguagem de consulta chamada GISOLAP-QL ´e tamb´em proposta. Esta linguagem de consulta ´e composta por duas partes, separadas pelo caracter pipe (|). A primeira parte consiste em uma consulta cuja sintaxe ´e muito semelhante `a SQL espacial, mantendo as cl´ausulas SELECT, FROM e WHERE, entretanto, com o caractere ponto e v´ırgula (;) ao final de cada cl´ausula. A segunda parte ´e uma consulta formada de acordo com a sintaxe MDX [297] (i.e. Consulta Espacial| Consulta MDX).

O processamento ocorre da seguinte forma: A primeira parte da consulta (i.e. parte espacial) ´e executada com o aux´ılio do documento XML que cont´em os mapeamentos entre o cubo OLAP e as geometrias e indica em qual tabela do banco de dados est´a armazenada cada informa¸c˜ao. O retorno desta consulta ´e utilizado para reescrever a parte MDX da consulta, a qual ´e processada novamente, para recuperar o resultado final.

Para exemplificar o funcionamento da proposta Piet, ´e dada a seguinte consulta: Listar o to- tal de unidades vendidas e seu custo, por produto, forma de divulga¸c˜ao da promo¸c˜ao (promotion media - e.g. r´adio, tv, jornal) e lojas que est˜ao localizadas em prov´ıncias cortadas por algum rio. Na Figura 3.12-(A), esta consulta ´e especificada na sintaxe da linguagem GISOLAP-QL. A Figura 3.12-(B) mostra como fica a consulta reescrita em MDX ap´os o processamento parcial, que retorna somente as prov´ıncias cortadas por algum rio e na Figura 3.12-(C), ´e mostrado o resultado final da consulta.

Como pode ser observado na Figura 3.12, a proposta Piet n˜ao possui uma interface gr´afica ´

unica, que permita a visualiza¸c˜ao integrada dos dados multidimensionais e geogr´aficos. Piet possui duas interfaces: i) a primeira (ver Figura 3.12-(C)), que utiliza o cliente JPivot [239] para exibir o resultado das consultas em tabelas multidimensionais a partir da execu¸c˜ao de consultas especificadas na linguagem GISOLAP-QL ; ii) a segunda interface, utilizada para realizar consultas espaciais, faz uso da aplica¸c˜ao Jump [161] para conectar ao SGBD e exibir os resultados, conforme mostra a Figura 3.13. A base de dados da proposta Piet ´e implementada com o SGBD PostgreSQL [228] com sua extens˜ao espacial PostGIS[241]. Como servidor OLAP,

3.7 PIET 31

Figura 3.12 Exemplo de Consulta Piet

para a defini¸c˜ao dos cubos multidimensionais e execu¸c˜ao das consultas MDX, ´e utilizado o Mondrian [224].

Para otimiza¸c˜ao de consultas, a abordagem Piet apresenta uma t´ecnica que particiona as ca-