Uma aplicação de Data Warehouse com CAD para Projetos de Edificações

Transcrição

1 UNIVERSIDADE DE SÃO PAULO ESCOLA POLITÉCNICA Pós-Graduação Disciplina PCS5704 Sistemas de Banco de Dados e Suas Diferentes Estruturas Solange Nice Alves de Souza Uma aplicação de Data Warehouse com CAD para Projetos de Edificações Rita C. Ferreira 1, Vilmar de S. Machado 2 1 Departamento de Engenharia Civil Escola Politécnica da Universidade de São Paulo (POLI-USP), Av. Prof. Almeida Prado, trav.2 nº. 83 CEP São Paulo SP Brasil, rita.ferreira@poli.usp.br 2 Departamento de Engenharia Elétrica Escola Politécnica da Universidade de São Paulo (POLI-USP), Av. Prof. Luciano Gualberto, trav.3 nº.158 CEP São Paulo SP Brasil, vilmarsm@uol.com.br Resumo. Observa-se a tendência ao uso de um modelo único de informações para o desenvolvimento do projeto de edifícios, chamado de BIM ( Building Information Modeling ), em diversos pacotes comerciais de CAD para construção. Essa abordagem caminha na direção da integração de informações geométricas do edifício e de controle do processo de desenvolvimento de projetos nessa área. Tendo em vista esta tendência, o objetivo deste artigo é investigar o uso de banco de dados multidimensionais aplicado na área de CAD ( Computer Aided Design ) para a construção de edifícios. 1. Introdução Os bancos de dados multidimensionais têm sido utilizados nas mais diversas áreas da engenharia da informação. Percebe-se, entretanto, que na área da construção civil, essa tecnologia é pouco explorada. O CAD (Computer Aided Design), que é uma ferramenta poderosa e robusta, oferece diversos recursos na parte geométrica, mas é deficitária na área de controle de processos que estão fora dos limites da geometria. Sistemas alternativos são utilizados para suprir essa outra parte não contemplada no CAD. O problema encontra-se no fato de não haver uma ligação direta entre esses sistemas, fazendo com que não exista uma integração direta das informações. Ferreira, R.C.; Machado, V. de S. 1

2 Diante disso, os bancos de dados multidimensionais suprem essa deficiência, permitindo que as informações estejam dentro de um repositório único. A partir desse momento, as informações podem ser tratadas, processadas e apresentadas de forma otimizada para a descoberta de fatos, não percebidos anteriormente. 2. Bancos de Dados Multidimensionais 2.1. Definição de Data Warehouse O Data Warehouse, cuja tradução literal é Armazém de Dados, pode ser definido como um banco de dados destinado a sistemas de apoio à decisão e cujos dados foram armazenados em estruturas lógicas dimensionais, possibilitando o seu processamento analítico por ferramentas especiais (OLAP e Mining) [Barbieri, 2001]. O conceito de Data Warehouse define uma base de dados preparada em vários níveis de granularidade e obtida a partir dos sistemas estruturados (legacy systems). Os sistemas de informações desenvolvidos até então, por serem baseados em necessidades focadas em aplicações independentes, não oferecem a visão consolidada de informações capaz de preparar os processos decisórios complexos e, por vezes, vitais, que as empresas enfrentarão em um mundo de alta competitividade pela nova economia. A idéia do Data Warehouse é armazenar os dados em vários graus de relacionamento e sumarização, de forma a facilitar e agilizar os processos de tomada de decisão por diferentes níveis gerenciais [Kimbal, 1997]. Esses dados, vindos de diversos sistemas de informação, deverão estar detalhados, integrados e sempre disponíveis, permitindo outras formas de consultas através de mecanismos amigáveis aos usuários. Dados detalhados são dados que passaram por um processo de identificação, homologação e transformação e que são necessários aos negócios da empresa [Inmon, 1997] Data Mart Empresas que têm exigências mais modestas, como as que não necessitam construir Data Warehouse para departamentos individuais, podem escolher em construir pequenos Data Marts que utilizam uma arquitetura baseada em rede [Oliveira, 2002]. Pela complexidade de fatores que envolvem um Data Warehouse corporativo, a construção do projeto é lenta e cara. Para equilibrar os gastos e oferecer resultados em prazos mais curtos, é possível construir Data Marts, que são pequenos Data Warehouse departamentais. Os Data Marts são subconjuntos de dados da empresa armazenados fisicamente em mais de um local, geralmente divididos por departamento (Data Marts "departamentais"). Existem diferentes alternativas de se implementar os Data Marts, porém, a proposta original é a aquela onde os Data Marts são desenvolvidos a partir de um Data Warehouse Central. [Oliveira, 2002]. Os Data Marts se diferenciam do Data Warehouse pois atendem às necessidades de um departamento específico ou grupos de usuários e possuem menor volume de dados. Um dos problemas dos Data Marts é o grande risco de desvio do modelo original, pois pode acontecer um crescimento desestruturado. Por ser muito utilizado e estar em Ferreira, R.C.; Machado, V. de S. 2

3 constante aperfeiçoamento, pode ocorrer a replicação das mesmas informações em vários locais, o que dificulta uma futura integração de todos os Data Marts em um único Data Warehouse [DW Brasil]. Como o desenvolvimento de um Data Warehouse demanda muito tempo, planejamento e custo muito elevado, para atenuar esses fatores optou-se pelo desenvolvimento indireto de um Data Warehouse com a idéia de desenvolver primeiramente os Data Marts para depois gradativamente construir o Data Warehouse corporativo unindo os Data Marts [Barbieri, 2001] (Figura 1). Figura 1 - União de vários Data Marts para a formação de um Data Warehouse 2.3. Modelo Estrela Tradicionalmente, modelos de bases de dados relacionais apresentam tabelas com relacionamentos complexos e com múltiplas uniões circulares entre dois pontos do modelo. Para a maioria dos usuários que utilizam para compor suas consultas, é necessário que o acesso a base de dados seja simples o suficiente para facilitar o acesso direto à base de dados. Para acomodar as necessidades de todos os usuários e facilitar a atualização do Data Warehouse o projetista deve criar um modelo que o usuário final possa facilmente entender em termos do negócio [Oliveira, 2002]. O principal tipo de modelo multidimensional é o chamado modelo Star (Estrela), onde existe uma tabela dominante no centro, chamada Tabela de Fatos, com múltiplas junções conectando-a a outras tabelas, sendo estas chamadas de Tabelas de Dimensão [Inmon, 1997]. Cada uma das tabelas secundárias possui apenas uma junção com a tabela central. O modelo Estrela, ilustrado na Figura 2, tem a vantagem de ser simples, intuitivo e também faz uso de novos enfoques de indexação e união de tabelas. Ferreira, R.C.; Machado, V. de S. 3

4 Figura 2 - Representação do Modelo Estrela A Tabela de Fatos contém milhares ou milhões de valores e medidas do negócio da empresa, como transações de vendas ou compras. Cada uma destas medidas é tomada segundo a intersecção de todas as dimensões [Inmon, 1997]. Os Fatos melhores e mais úteis são numéricos, continuamente valorados (diferentes a cada medida) e aditivos, já que estes facilitam a geração do conjunto de respostas. Uma outra característica da Tabela de Fatos é que se não existe um cruzamento para alguns valores das dimensões, a tabela de fatos não armazena zeros [Oliveira, 2002]. As Tabelas de Dimensão armazenam as descrições textuais das dimensões do negócio. Cada uma dessas descrições textuais ajuda a definir um componente da respectiva dimensão. Uma das principais funções dos atributos de Tabelas de Dimensão é servir como fonte para restrições em uma consulta ou como cabeçalhos de linha no conjunto de resposta do usuário. Tabelas Dimensões tendem a utilizar tipos caracteres ao invés de numéricos, de forma que suas linhas são muito mais longas, mas em pouca quantidade ocupando uma pequena percentagem de espaço em disco. As Tabelas de Fatos podem utilizar até 95% da área destinada ao Data Warehouse [Campos, 1997]. Na maioria das vezes as dimensões representam hierarquias, como por exemplo, um produto, que é de uma marca ou categoria, que por sua vez pertence a uma subcategoria, entre outros. Só que, na maioria das vezes, quando esta é representada na dimensão, não temos várias tabelas normalizadas com ligações um-para-muitos, e sim uma única Tabela de Dimensão. Isso faz com que a performance das consultas aumente muito, já que não são necessários joins para se obter os dados relacionados com algum assunto. Outro fato importante é que como a Tabela de Fatos, na verdade, representa os relacionamentos muitos-para-muitos entre as Tabelas de dimensões, esta tem como chave primária uma chave composta de todas as chaves estrangeiras das Tabelas de Dimensão [Oliveira, 2002]. Para um bom desempenho do modelo Estrela é necessário que os projetistas antecipem, na modelagem do Data Warehouse, as consultas mais freqüentes a serem realizadas pelos usuários. Ferreira, R.C.; Machado, V. de S. 4

5 2.4. Variação do Modelo Estrela Outro tipo de estrutura bastante comum é o modelo de dados Snow Flake (Floco de Neve), que consiste em uma extensão do Modelo Estrela onde cada uma das "pontas da estrela" passa a ser o centro de outras estrelas. Isto porque cada tabela de dimensão seria normalizada, "quebrando" a tabela original ao longo de hierarquias existentes em seus atributos [DW Brasil]. Este modelo pode ser ilustrado imaginando-se a classificação de um automóvel, onde a dimensão do produto possui uma hierarquia definida: categoria se divide em marca e a mesma em produtos, como ilustrado na Figura 3. Figura 3 - Representação da variação do modelo estrela Snow Flake Da mesma forma, a dimensão tempo inclui ano que contém mês e este contém dia-domês. Cada um destes relacionamentos "muitos-para-um" geraria uma nova tabela em um Modelo Floco de Neve. 3. Granularidade Após abordar o conceito de modelagem do Data Warehouse o mais importante aspecto do projeto é a questão da granularidade. A granularidade diz respeito ao nível de detalhe ou de resumo contido nas unidades de dados existentes no Data Warehouse. Quanto mais detalhe, mais baixo o nível de granularidade. Quanto menos detalhe, mais alto o nível de granularidade [Barbieri, 2001]. A granularidade de dados tem se mantido como uma questão delicada de projeto. Nos primeiros sistemas operacionais que foram criados, a granularidade era tida como certa. Quando os dados detalhados eram atualizados, era quase certo que eles seriam armazenados no nível mais baixo de granularidade. No entanto, no ambiente de Data Warehouse, a granularidade não é um pressuposto [Barbieri, 2001]. Ferreira, R.C.; Machado, V. de S. 5

6 Figura 4 Níveis de Granularidade 1 A segunda camada de dados existentes no Data Warehouse, que é o nível mais baixo de granularidade, é armazenada no nível de dados verdadeiramente históricos. No nível de dados históricos, todos os detalhes vindos do ambiente operacional são armazenados. Há uma verdadeira montanha de dados neste nível. Por essa razão, faz sentido armazenar os dados em um meio como fita magnética. Ao criar dois níveis de granularidade no nível detalhado do Data Warehouse, a maior parte do processamento SAD (Sistema de Apoio a Decisão) dirige-se aos dados levemente resumidos que são compactos e de fácil acesso. 4. OLAP O termo OLAP - On-line Analytical Processing referencia-se ao conjunto de tecnologias voltadas para acesso e análise ad-hoc dos dados. O principal objetivo de uma ferramenta OLAP é transformar dados em informações para que as mesmas sejam capazes de dar suporte a decisões gerenciais de forma amigável e flexível ao usuário e em tempo hábil [Kimbal, 1998]. O Processo Analítico On-Line tem motivação pela necessidade de minerar conhecimento e padrões em diferentes níveis de abstração através de análises multidimensionais dos dados, ou seja, uma visão lógica dos mesmos. É uma análise interativa dos dados, permitindo ilimitadas visões através de agregações em todas as interseções de dimensões possíveis. Um OLAP executa queries (consultas) com um tempo de resposta pequeno, pois procura-se através de otimização do Data Warehouse manter as informações solicitadas com maior freqüência em memória. A análise é dinâmica, onde o usuário faz a consulta que quiser sem depender de um técnico, e multidimensional compartilhada. Essa última análise multidimensional é a 1 A figura 2 foi extraída do site Warehouse_grao.gif Ferreira, R.C.; Machado, V. de S. 6

7 principal característica do OLAP, que consiste em ver determinados cubos de informações de diferentes ângulos, e de vários níveis de agregação. Os "cubos" são massas de dados que retornam das consultas feitas ao Banco de Dados e podem ser manipulados e visualizados por inúmeros ângulos (usando a tecnologia de Slice-and-dice) e diferentes níveis de agregação (usando a tecnologia chamada Drill) [Kimbal, 1998]. As ferramentas que disparam uma instrução SQL de um cliente qualquer para o servidor e recebem o microcubo de informações de volta para ser analisado na workstation, chamam-se DOLAP (Desktop On Line Analytical Processing). [Oliveira, 2002] O que esta arquitetura proporciona é o pouco tráfego que se dá na rede, visto que todo o processamento OLAP acontece na máquina cliente e há maior agilidade de análise, além do servidor de Banco de Dados não ficar sobrecarregado, sem incorrer em problemas de escalabilidade. A desvantagem é que o tamanho do microcubo não pode ser muito grande, caso contrário, a análise passa a ser demorada e/ou a máquina do cliente pode não suportar em função de sua configuração. As ferramentas ROLAP (Relational On-Line Analytical Processing) possuem uma engenharia de acesso aos dados e análise OLAP com uma arquitetura um pouco diferente. Nesse caso, a consulta é enviada ao servidor de Banco de Dados relacional e processada no mesmo, mantendo o cubo no servidor [Oliveira, 2002]. A principal vantagem dessa arquitetura é que ela permite analisar enormes volumes de dados, em contrapartida, uma grande quantidade de usuários acessando simultaneamente poderá provocar sérios problemas de performance no servidor, causando, inclusive, o travamento do mesmo [Oliveira, 2002]. A arquitetura MOLAP (Multidimensional On-Line Analytical Processing) processa-se da seguinte forma: com um servidor multidimensional, o acesso aos dados ocorre diretamente no banco, ou seja, o usuário trabalha, monta e manipula os dados do cubo diretamente no servidor. Isso traz grandes benefícios aos usuários no que diz respeito a desempenho, mas tem problemas com escalabilidade, além de ter um custo alto para aquisição Ferramentas OLAP As ferramentas OLAP são as aplicações a que nossos usuários finais têm acesso para extraírem os dados de suas bases com os quais geram relatórios capazes de responder às suas questões gerenciais. Elas surgiram juntamente com os sistemas de apoio à decisão para fazerem a extração e análise dos dados contidos nos Data Warehouses e Data Marts Consultas Ad-hoc Segundo Inmon [apud Oliveira, 2002], "são consultas com acesso casual único e tratamento dos dados segundo parâmetros nunca antes utilizados, geralmente executados de forma iterativa e heurística. Ferreira, R.C.; Machado, V. de S. 7

8 Isso tudo nada mais é do que o próprio usuário gerar consultas de acordo com suas necessidades de cruzar as informações de uma forma não vista com métodos que o levem a descoberta daquilo que procura Slice-and-Dice Esta característica das ferramentas OLAP é de extrema importância. Com ela, nós podemos analisar nossas informações de diferentes prismas limitados somente pela nossa imaginação. Utilizando esta tecnologia, conseguimos ver a informação sobre ângulos que, anteriormente, inexistiam sem a confecção de um Data Warehouse e a utilização de uma ferramenta OLAP [Inmon, 1997]. 5. CAD CAD pode significar Computer Aided Drafting ou Computer Aided Design. As aplicações desenvolvidas para CAD em geral têm ferramentas para as drafting, no sentido de contemplar representações da geometria plana, com linhas, pontos, etc. As aplicações desenvolvidas para CAD no sentido de design possuem estruturas que permitem associar as informações de uma determinada área específica da engenharia. Uma das áreas da engenharia é chamada de AEC, referindo-se a Arquitetura, Engenharia e Construção (ou em inglês,), por vezes também chamado de AEC/FM (Architecture, Engineering and Construction and Facilities Management). No caso de sistemas CAD para AEC, estas incorporam objetos com informação específica da área. Assim, a informação relativa à geometria plana ou espacial transforma-se, composta, em portas, janelas, paredes etc., incorporando operações próprias desses objetos. Como exemplo, temos uma porta. Uma porta possui diversas características e operações. Uma das operações de uma porta é abrir, que pode ser à direita, à esquerda, superior, e assim por diante. Atualmente, os sistemas CAD na área de AEC estão evoluindo para uma maior aderência entre os objetos e o projeto dos diversos subsistemas que o compõem. Estes sistemas têm sido chamadas de BIM (Building Information Model). Existem diversos formatos de exportação da informação gráfica, em geral no formato ASCII. A seguir serão apresentados alguns exemplos dos mais populares formatos, tais como DXF, STL e IGES, bem como serão discutidos formatos mais recentes com tendência a serem utilizados como padrão não proprietário (normalizado), como STEP, IFC ISO e XML. Ferreira, R.C.; Machado, V. de S. 8

9 5.1. DXF Este é o formato mais popular para exportação de dados bidimensionais, de propriedade da Autodesk. A estrutura de sua informação pode ser observada no quadro a seguir: Ponto de inserção (código $INSBASE) Variável Y (código 20) = 0.0 Limite inferior da grade visível da área de trabalho (código $EXTMIN) X= Y= Z=0.0 $INSBASE $EXTMIN $EXTMAX Variável X (código 10) = 0.0 Variável Z (código 30) = 0.0 Limite superior da grade visível da área de trabalho (código $EXTMAX) X= Y= Z=0.0 Figura 5 Trecho de informação no formato DXF 5.2. IGES Initial graphic exchange specification, ou IGES, é um dos formatos de exportação da informação gráfica. Este formato é um dos mais antigos e tem a capacidade de transportar informações gráficas 3D em arame, superfícies e sólidos. IGES é um padrão de propriedade da National Computer Graphics Association (NCGA) [Lockardt, 2000]. Ferreira, R.C.; Machado, V. de S. 9

10 Figura 6 Exemplo de dados obtido pelo padrão IGES STL STL (STereo Lithography) é um formato utilizado para exportar geometria 3D para sistemas de prototipagem rápida. Este formato transforma as superfícies do modelo tridimensional em faces triangulares. O número e o tamanho dessas faces são proporcionais à precisão do objeto original criado. [Lockardt, 2000] 5.4. STEP STEP é o acrônimo que significa Standard for Exchange of Product, que tem sido discutido pela ISO para servir de padrão de informação do modelo 3D. Este formato, além de conter informações sobre a geometria completa do objeto de projeto no CAD, tem sido trabalhado para incorporar-se a sistemas gerenciados de produto, do tipo PDM (Product Data Management). Ferreira, R.C.; Machado, V. de S. 10

11 5.5. IFC ISO Na tentativa de consolidar um padrão de objetos da indústria AEC, evoluiu-se o trabalho feito inicialmente através do STEP, concluindo recentemente a ISO :2001, que define uma estrutura de classes genéricas. Paralelamente ao trabalho da ISO, a AIA (International Alliance for Interoperability) vem desenvolvendo o padrão IFC (Industry Foundation Classes). Figura XML Recentemente, os pacotes de CAD têm incorporado o padrão XML (extensible Markup Language) para compartilhamento de informações entre áreas diferentes da empresa através da porta 80 do serviço http. Os sistemas CAD para AEC mais recentes, como o Architectural Desktop da Autodesk, incoporam os padrões XML em suas estruturas de dados. A partir desse momento, os objetos gráficos deixam de ser geometrias simples (linhas, pontos, curvas etc.) para agregarem informações relativas à especificação do produto. A seguir, apresenta-se um exemplo de arquivo com dados de tipos de paredes (Wall Types.xml), Figura 8. Ferreira, R.C.; Machado, V. de S. 11

12 Figura 8 Parte do código de um arquivo com tipos de paredes, Wall Types.xml (Autodesk, 2004) 6. Proposta de aplicação em integração de projetos para produção de edifícios O presente artigo pretende apresentar uma proposta de aplicação em projetos para construção de edifícios, a partir dos conceitos de Data Warehouse. Diversas pesquisas apontam que problemas de execução em obra estão diretamente relacionados à capacidade de identificação de problemas e solução dada pelo projeto [Ferreira, Santos e Codinhoto, 2005]. Muitos desses problemas poderiam ser minimizados com a introdução dos avanços de tecnologia da informação no desenvolvimento de projeto, especialmente em projetos complexos. Neste caso um sistema integrado de informação é a base para a introdução de inteligência capaz de auxiliar o projetista na identificação e solução dos problemas, objeto do seu trabalho. Entretanto, no caso de projetos para engenharia de produto, é necessário considerar a complexidade da informação utilizada, que envolve dados geométricos e não-geométricos. Um exemplo é a proposta de integração feita por Froese et al. (2000), apresentada na Figura 9. Ferreira, R.C.; Machado, V. de S. 12

13 Figura 9 - Protótipo de integração (Froese et al, 2000) No processo de integração da informação para o desenvolvimento de projetos, será necessária a troca de dados entre as diversas especialidades envolvidas. Atualmente a arquitetura baseada em XML mostra-se adequada e aderente a maior parte dos pacotes CAD comerciais (AutoCAD e Microstation são os sistemas mais utilizadas na área de construção). A seguir, apresenta-se um modelo de integração utilizando-se XML (Figura 10). Figura 10 Modelo de troca de informação baseado em arquivo XML (Froese et al., 2000) 6.1. Projeto Proposto O objetivo da proposta é prover meios de extrair as informações relevantes, dentro dos projetos de CAD, bem como integrar outras fontes de informações relativas ao mesmo projeto. Ao final, utilizar uma ferramenta OLAP que apresente essas informações de forma bastante coerente e otimizada. Ferreira, R.C.; Machado, V. de S. 13

14 O problema é bastante complexo, visto que as ferramentas de desenvolvimento de projeto na construção civil não prevêem outros aspectos do projeto, como custos, problemas encontrados na fase de desenvolvimento e soluções aplicadas aos processos de projeto. Diante desse cenário, existem outros sistemas que dão suporte para os aspectos acima citados. Esses sistemas, normalmente, não são integrados ao CAD. Assim, surge a idéia de integração dessas informações através de um banco de dados multidimensional. A primeira etapa para o desenvolvimento do modelo multidimensional, concentra-se em descobrir quais são as informações relevantes nesse tipo de projeto. Na proposta, os requisitos relevantes são: Quais os projetos que possuem o maior custo por região; Quais os projetos que apresentam os maiores problemas; Quais são os problemas mais comuns nos projetos; Quais os custos envolvidos nos projetos em uma determinada região; Quais são os itens (janelas, portas, parede) que estão envolvidos no projeto; Qual o custo dos problemas apresentados nos projetos; Quais são os projetos mais utilizados por região; Com essas informações, propõe-se a utilização do seguinte modelo multidimensional no formato Star Schema (Estrela): ItemServ ico Região Data DicionárioP eca Custo Projeto Problema Figura 11 Modelo Star Schema para o projeto No modelo acima proposto, a tabela fato chama-se Custo e as suas dimensões são Projeto, Problema, DicionárioPeça, Data, Região e ItemServiço. Com esse modelo, é possível obter as informações necessárias para os requisitos solicitados. Uma outra etapa tão importante quanto o projeto do banco de dados multidimensional, é a extração, transformação e carga das informações para o Data Warehouse. Esse processo é importante, pois é responsável pela extração dos dados, nas mais diversas Ferreira, R.C.; Machado, V. de S. 14

15 fontes, transformação desses dados para deixá-los compatíveis e depois a realização da carga ou transporte dessas informações para o DataWarehouse. O processo que realiza todas essas tarefas é chamado de ETL (Extração, Transformação e Carga de dados, do inglês Extract, Transform and Load). Portanto, apresenta-se a seguinte estrutura: CAD Sistema de Custos ETL DataWarehouse proposto pelo modelo acima representado Sistema de Administração de Problemas Figura 12 Modelo ETL A ferramenta OLAP utilizada deve ter um recurso poderoso de busca, dentro de atributos do tipo texto. Algumas informações deverão ser pesquisadas dentro do projeto CAD que está transformado no formato XDF e armazenado no Data Warehouse. Isso inviabiliza a utilização de métodos de pesquisa como o SELECT utilizando a cláusula LIKE. Existem alguns outros meios de otimização como um UltraSearch que realiza uma busca bastante rápida pois utiliza índices com estruturas próprias para pesquisa utilizando elementos alternativos (coringas). Todos os elementos utilizados, estão baseados em uma estrutura da Oracle através dos produtos WarehouseBuilder, Oracle Discoverer e UltraSearch para OracleText. O XML é utilizado para compartilhamento de informações entre os projetos utilizados dentro da empresa. 7. Conclusão Através do desenvolvimento desse projeto, conclui-se que o mercado de CAD tem apresentado muitas soluções voltadas para a área do projeto gráfico, negligenciando as outras etapas como custo. Conclui-se também que é possível obter todas as informações envolvidas no projeto, além dos itens geométricos. Para isso o Data Warehouse é uma solução viável, pois apresenta uma estrutura flexível que permite obter todas as informações provenientes das mais diversas fontes de dados. A ferramenta OLAP também apresenta um papel fundamental, pois é ela que apresenta os resultados planejados e obtidos de forma bastante eficiente. Para trabalhos futuros, há evidências de que a utilização da mineração de dados para obtenção de informações mais detalhadas é um caminho interessante para a integração dos diversos processos de desenvolvimento do produto na área da construção.. Ferreira, R.C.; Machado, V. de S. 15

16 8. Referências bibliográficas Autodesk, Inc. (2000) AutoCAD Architectural Desktop Help: User Documentation. Help on-line. Autodesk, Inc. (2004) AutoCAD Architectural Desktop 2005 Help: User Documentation. Help on-line. Barbieri, Carlos. (2001) BI Business Intelligence: Modelagem e Tecnologia. Rio de Janeiro: Axcell Books do Brasil Editora,, 448 Págs. Caldas, Carlos H., Soilbelman, Lucio, e Gasser, Les. (2005). "Methodology for the Integration of Project Documents in Model-Based Information Systems." Journal of Computing in Civil Engineering, Volume 19, nº 1, p Campos, Maria Luiza e Rocha Fº, Arnaldo V. (1997) Data Warehouse. In XVII Congresso da Sociedade Brasileira de Computação. DW Brasil. Apresenta informações técnicas, Históricas, Bibliográficas Sobre Data Warehouse, Data Mart, Metodologias, OLAP e Estruturas envolvidas no Business Intelligence. Disponível em : Acesso em 11 de abril de Ekholm, Anders. (2005). "ISO and IFC - Prerequisites for Coordination of Standards for Classification and Interoperability." ITcon. Volume 10, p Ferreira, R. C, Santos, E. T, e Codinhoto, R. (2005) "Comparação entre os Resultados de Percepção de Problemas Relacionados à Compatibilização Geométrica em Projetos para Produção de Vedações, Usando CAD 2D e CAD 3D." Anais...TIC 2005: Tecnologia da Informação e Comunicação na Construção Civil. São Paulo, CD-Rom.. Froese, T. et al. System Architectures for AEC Interoperability. CIT 2000, CIB-W78, IABSE, EG-SEA-AI International Conference On Construction Information Technology, 2000, Reykjavik, Islândia. Anais... Reykjavik: Icelandic Building Research Institute, p Disponível em: Acesso em: 22 nov IAI, International Alliance for Interoperability. IFC Model Development. Disponível em: Acesso em 22 de Novembro de Inmon, W.H. (1997) Como Construir o Data Warehouse, Campus, Rio de Janeiro, 387 págs. Kimbal, Ralph (1997) DBMS Tools & Strategies for IS Professionals, In Mantelmedia Editora - No. 1. Kimbal, Ralph. (1998) Data Warehouse Toolkit - Editora Makron Books. Lockhard, Shawna D., and Johnson, Cindy M. (2000). Engineering design communication: conveying design through graphics. USA: Prentice-Hall. Oliveira, Wilson J. de (2002). Data Warehouse. Visual Books, Florianópolis. Ferreira, R.C.; Machado, V. de S. 16