Data Warehouse Architecture through Viewpoint

Data Warehouse Architecture through Viewpoint of Information System Architecture Maria Madalena Dias1, Tania F. Calvi Tait1, André Luís A. Menolli2, Roberto C. Santos Pacheco3 1

Departamento de Informática, Universidade Estadual de Maringá , Phone: +55(44)32614074 (FAX) Av. Colombo, 5790, CEP 87020-900, Maringá, Paraná, Brasil {mmdias, tait}@din.uem.br

2

3

Departamento de Informática, Universidade Estadual do Norte do Paraná, Campus Bandeirantes BR 369, Km 54, CEP 86360-000, Bandeirantes, Paraná, Brasil [email protected]

Programa de Pós-Graduação em Engenharia e Gestão do Conhecimento, Universidade Federal de Santa Catarina, B. Trindade, CEP 88040-970, Florianópolis, Santa Catarina, Brasil [email protected]

Abstract The increasing search for computational solutions to support the decision-making led to the development of new technologies that aim to transform the large volume of data in information and knowledge useful. The data warehousing technology emerged with the aim of structuring the data in the best way possible to facilitate its access, making the process more efficient and effective. Along with it, other areas of research evolved and contribute directly or indirectly to achieve this goal, such as: OLAP (On-Line Analytical Processing), data mining, artificial intelligence, knowledge discovery in database and business intelligence. The creation of a data warehouse (DW) involves the choice of architecture. Thus, this article presented a discussion on the origin of the DW architecture based in the information systems architecture proposed by Zachman. WORD. Keywords: Data warehouse architecture, information systems architecture, Zachman architecture.

1. INTRODUCTION In the first generations of the computation area, the computer was used to solve operational problems of the organization. Until 1980, the architecture concept was just associated to the hardware design. In 1987, in an attempt to solve problems related to the software crisis and, in addition to other features of the software engineering area, the architecture has become associated with the software area [21]. At the end of the decade of 80’s and beginning of the 90, the first concepts and models of Information Systems Architecture (ISA) were defined, considering since the strategic planning until the data storage [20]. The goal was define a set of elements involved in the process of development and implantation of Information Systems (IS). In this context, Zachman [21] defined a IS framework which, according to Tait [20], has been used as the basis to other researchers in the ISA definition. At the end of the decade of 90’s, Inmon et al. [10], based on the Zachman framework, defined a model for DW architecture.

Maria Madalena Dias, Tania F. C. Tait André L. A. Menolli, and Roberto C. S. Pacheco

Data Warehouse Architecture through Viewpoint of Information System Architecture

The objective of this paper is to show as an ISA can give support to DW architecture, covering since business aspects until data storage, and the DW as a tool to obtain information and knowledge. Follow, in Section 2 are described some related works, in Section 3 are related concepts of IS and ISA and described the Zachman Framework; in Section 4 is presented a discussion about the relationship between the DW architecture and Zachman Framework, are discussed aspects about DW architecture, described the architectural framework proposed by Kimball et al. [8] and shown an example of DW; in Section 5 is described the construction of a DW to management in Science & Technology (S&T); in Section 6 are related case studies conducted to the DW built. Finally, in the Section 7, the conclusions of this paper are presented.

enterprise” and “a basis for building the enterprise’s systems”.

3. INFORMATION SYSTEM ARCHITECTURE The Information System is the process of data transforming into information. According to Laudon and Laudon [10], IS is a set of components (data, people, processes, information technology, etc.) interrelated that collect (or recover), process, store and distribute information to give support to decisionmaking and the control within an organization. The Information Systems Architecture (ISA), according to Zachman [21], is a set of elements whose purpose is to provide a mapping of the organization concerning elements involved in the process of IS development and implantation. Accordingly, the contribution of an ISA occurs, specifically, in the connection that make among all elements involved in a software development, dealing in the same level of importance all its components, not just focusing on technology or data [20]. To realize this contribution, an ISA involves a number of components, such as [2]: the business strategy, the IS strategy, the business processing, the information processing architecture, IS planning and its implementation (software development).

2. RELATED WORKS Frankel et al. [5] describe how the OMG’s Model Driven Architecture can be mapped to the Zachman Framework for ilustrating what aspects of the Zachman Framework can be supported by architects, analysts and developers who use MDA. Ertaul and Sudarsanam [4] give an overview of how Zachman Framework help define, design, and create tools for effectively securing an enterprise. They propose a security model to manage enterprise security based on Zachman Framework. Also, discussed the incorporation of this framework in egovernance.

Inmon et al. [7] affirm that the Zachman framework for ISA provides a way to ensure that standards for creating the information environment exist and that they are properly integrated. It puts the techniques, their goals and their artifacts in the same context to provide a complete view of the product, enterprise or business opportunity.

Sousa et al. [19] propose using a set of modeling criteria derived from the Zachman Framework to model business processes activities. The aim is to infer business activities in order to facilitate the consistent representation of business process, facilitating their sharing, dissemination and analysis.

The Zachman framework acknowledges that the computer systems should be related to the world of business and that in this world, people have different perspectives and roles, depending on their need and use of information.

Kingston and Macintosh [9] assert that multiperspective modelling is required for a knowledge asset to be represented in a manner that is accurate, complete, embedded in its context and yet comprehensible. Multi-perspective modelling requires representing a knowledge asset using a collection of knowledge models, each of which takes a different viewpoint on that knowledge. They propose using the six models from CommonKADS methodology [17] as a good starting point for the modelling of knowledge assets and the Zachman framework to difine what aspects of organizational memory need to be represented. According to Kingston and Macintosh [9], the models recommended by the Zachman framework provide “a basis for designing the

According Inmon et al. [7], the Zachman framework represents the perspectives and dimensions in the matrix form. The columns represent the dimensions and the rows represent the perspectives that can be used to see a business, a situation, an opportunity or a system. The perspectives are related to the roles that the peoples occupy in the system development, which are: planner, owner, designer, builder and subcontractor. The dimensions are the necessary elements to the system development, which are: entities, activities, locate, people, time and motivation. In the Table 1 is shown this framework.

2

Maria Madalena Dias, Tania F. C. Tait André L. A. Menolli, and Roberto C. S. Pacheco

Data Warehouse Architecture through Viewpoint of Information System Architecture

Table 1. Zachman Framework (adapted from Inmon et al. [7]) Entities (what)

Activities (how?)

Locations (where?)

People (who?)

Time (when?)

List of processes List of locations List of List of events the business in which the organizations significant to the performs business operates important to the business business Business process Business location Enterprise unit Business event

Motivations (why?)

Planner

List of things important to the business

Owner

Business entity

Designer

Data entity

Application function

Node function

Role

System event

Criterion

Builder

Segment/ row/etc.

Computer function

Hardware/ systems software

User

Executor

Condition

Sub-contractor

Field

Language statement

Address

Identity

Interrupt

Sub-condition

The Planner has an overview and thinks about things that could be implemented to improve the organization business and he also defines the scope of a project, identifying the major components of the desired product and its financial viability (cost vs. benefit).

List of business goals/strategies

Business target

The Time (when?) represents the key events and their dependencies. The Motivations (why?) are the reasons that make the system necessary, which the tangible and intangible benefits of the new system are derived. From motivations are derived rules or restrictions for project and operation.

The Owner is the person who wants practical products that can be built with the restrictions imposed by him. He provides information about the product and its use. He has a specific vision of the organization business.

4. DATA WAREHOUSE ARCHITECTURE THE ZACHMAN FRAMEWORK

AND

The DW is a subject-oriented, integrated, timevariant and non-volatile database, it is derived from operating databases [7]. The DW should be a warehouse of safe and consistent data that have information of an enterprise and available easy to give support to decision-making.

The Designer supplies information about the product in the business and technical perspectives. He defines the system technical model. The Builder manages the process of assembling and manufacturing of components. He defines the system model.

The DW architecture is a set of documents, plans, models, drawings, and specifications, with separate sections for each key component area and enough detail to allow their implementation [6].

The Subcontractors are specialists who build specific parts of a product. They develop software components defined in the system model. The Entities or things (what?) are the data, databases, classes of objects and business items that they represent.

The Zachman Framework define an architecture for managing knowledge, the DW is one of the tools to obtain knowledge. Thus, Inmon et al. [7] define a strategy to build, implement, operate and support the DW, based on the set of guiding principles related to the dimensions of the Zachman Framework.

The Activities (how?) are the functions and processes that need support. Locations (where?) are where the system components may reside or be used (e.g, application server, database server).

The guiding principles of dimension Motivations generate expectations for the capital invested in the levels of service. According to Inmon et al. [7], a DW is built to provide a business benefit to ensure that the value of business is appropriately balanced with the cost, the business units that receive the benefits should return the investment made.

People (who?) are enterprises, departments and people who directly or indirectly interact with the system, as well as workflow and interfaces, or representations.

3

Maria Madalena Dias, Tania F. C. Tait André L. A. Menolli, and Roberto C. S. Pacheco

Data Warehouse Architecture through Viewpoint of Information System Architecture

The guiding principles of dimension Time set expectations for the age of the data.

DW to give support to decision-making and the metadata that describes the content of the DW.

The guiding principles of dimension Locations define where the data reside and the facility to retrieve them. The guiding principles of dimension People define the interaction between people and the DW.

Kimball et al. [8] adapted the Zachman framework in the definition of an architectural framework of DW, which is represented in Table 2. In this framework, the columns represent the dimensions, defined as the major areas of the architecture, which are: data, technical (Back Room and Front Room), and infrastructure, and the rows represent the perspectives that are related with the levels of detail used in the building process of a DW, that are: business requirements, models of architecture, detailed models and implementation. In the crossing between the dimensions and the perspectives are described the needs of each area involved in the construction of a DW, according to the detail level.

The guiding principles of dimension Activities define the process to build and support the DW and anticipate the impact of this process in the development of systems and support activities. In this dimension are established the main stages of a DW development methodology. The guiding principles of dimension Entities define rules on the content of the DW. These rules are related to the quality of data in the DW, origin of the data, processing, integration, the data orientation in the

Table 2. The Data Warehouse Architectural Framework proposed by Kimball et al. [8] Detail Level

Business Requirements

Architecture Models and Documents

Detailed Models

Implementation

Data (What?)

Technical (How?) Back Room

Technical (How?) Front Room

Infrastructure (Where?)

What information do we need to make the better business decisions? Include all contents of DW.

How will we get at the data, transform it, and make it available to our users? How is this done today?

What are the major business issues we face? How will we measure these issues? How do we want to analyze the data?

What hardware and system level capabilities do we need to be successful? What do we currently have in place?

What are the major entities (facts and dimensions) that make up this information, and how do they relate to each other? How should these entities be structured?

What are the specific capabilities we will need to get the data into a usable form in the desire locations at the appropriate times? What are the major data stores, and where should they be located?

What will users need to get the information out in a usable form? What major classes of analysis and reporting do we need to provide and what are the priorities?

Where is the data coming from and going to? Do we have enough calculation and storage capacity? What are the specific capabilities we are counting on? Do they exist? Who is responsible for them?

What are the individual elements, their definition, domains, and rules for derivation? What are the sources, and how do they map to the targets?

What standards and products provide the needed capabilities? How will we integrate them together? What are our development standards for code management, naming, etc?

What are the specifics for the report templates, including the rows, columns, sections, headers, filters, etc.? Who needs them? How often? How do we distribute them?

How we interact with these capabilities? What are the system utilities, calls, APIs, etc?

Creating the databases, indexes backup, etc. Documentation.

Writing the extractions and loads Automattion of the process. Documentation.

Implementation of report and analysis, preparation of the initial report set, and training of the users. Documentation.

Installation and test of new infrastructure components. Connection of the sources to the targets to the Desktop. Documentation.

4

Maria Madalena Dias, Tania F. C. Tait André L. A. Menolli, and Roberto C. S. Pacheco

Data Warehouse Architecture through Viewpoint of Information System Architecture

4.1. AN EXAMPLE OF DW ARCHITECTURE

The data architecture is focused on business processes. The infrastructure area includes hardware, network, operating systems and desktop machines. The technical area contains decision-making technology that will be required for users, as well as their support structures.

Menolli and Dias [12] defined a DW architecture to solve problems of data integration and make available information and knowledge about science and technology in Brazil, but that can be used to others fields of information. This architecture is organized in layers and the DW is conceived from an incremental construction of integrated data marts, as shown in Figure 1.

Through of technical architecture are described: the data flow from source systems for decision-makers and the changes that occur with the data along the way. In the technical architecture also are specified the tools and techniques needed.

This architecture was defined taking like base the Arquitetural Framework proposed by Kimball et al. (1998) and, also, the guiding principles relative a list to the dimensions of the Zachman Framework (Inmon et al., 1997), they were described in the Section 3. The elements that compose it represent the guiding principles and have the function to realize the necessary activities for the creation of the DW and the access to the informations in him contained, responding so to the questions presented in the Table 2.

Some proposals for DW architecture exist, such as: [18], [15], and [12]. Highlight the architecture of Menolli and Dias [12], because it include and represent clearly the main components listed in Figure 1, which is described in the sub-section below.

Researcher

Research Groups

Education Institutions

OLAP and Data Mining Tools

Common Data

Data Mart 2

Work

Work

DB 1

DB 2

Data extraction, transformation and loading Migration for Standard Database

Standard Data Source

Source in other formats

Figure 1: DW Architecture to S&T [12]

5

ETL

New Data Source

Data Sources

Metadata Repository

Data Mart 1

Staging Area Data Warehouse Analysis Area

Therefore, can be conclude that in the DW architecture the dimensions and perspectives represent the necessary elements in the building and use of a DW, whereas in Zachman framework the dimensions and perspectives represent the elements involved in the IS development.

Maria Madalena Dias, Tania F. C. Tait André L. A. Menolli, and Roberto C. S. Pacheco

Data Warehouse Architecture through Viewpoint of Information System Architecture

The incremental construction means that new data marts can be implemented or existing ones can be changed to satisfy new needs that can appear.

In the Analysis Area layer are used query tools like OLAP and data mining tools to represent the consulting services used by decision-makers.

This architecture combines DW technologies with classic technology of relational database, mainly in the Staging Area layer, and has as its main feature the replacement of data sources of several formats for new databases in analytical standards, facilitating the data integration.

In the following section is described, using a practical example, as a DW can be constructed based on the DW architecture proposed by Menolli and Dias [12].

5.

CONSTRUCTION MANAGEMENT IN S&T

The Data Source layer represents all data sources that are used as information suppliers to the DW.

OF

DW

FOR

The DW for management in S&T was built following the defined steps for Kimball et al. [8]. From the analysis of the data models of the origin sources and of interviews with possible users of the system, the data model of the data marts was defined, according to star scheme. This modelling has been chosen because it is consolidated in the DW environment and for the fact of many OLAP and data mining tools need that the data are in this format and, also, because dimensional modeling is widely accepted as the viable technique for delivering data to final users in a DW [8], [13], [1], [3]. Afterwards the DW data model was defined.

The ETL layer represents the stage of data services, and being divided into two modules, a migration module and the other of extraction, transformation, and load. The migration module transforms data in various formats to a reference format, which is the format chosen by the DW designer to be the format of the DW. The extraction module transforms and loads, gather relevant data, which are predefined in the phase of planning and requirements definition, and it stores these data into staging area, processed and cleaned. In the Staging Area layer, the data are integrated and incorporated to data marts. The rules of extraction, transformation and integration are registered in the metadata.

For the definition of the data integration rules, have been used the Bus matrix, defined in the approach of BUS implementation, being the fact and dimensions tables previously structured from way to maintain integration between the datas marts, as shown in Figure 2. Case there are dimensions superposition in the data marts, is created a common area, reducing the data replication between the data marts.

The Data Warehouse layer represents the presentation servers where the data is stored for access by query tools and data mining tools.

Figure 2: Bus Matrix of DW [11]

6

Maria Madalena Dias, Tania F. C. Tait André L. A. Menolli, and Roberto C. S. Pacheco

Data Warehouse Architecture through Viewpoint of Information System Architecture

The implementation of the migration module of the ETL layer have been developed in Delphi 7.0, making possible migrating and integrating data from different institutions, handling replicated data, problems with keys and collations problems that happened.

establish incentive politics to the publication can be got from the analysis of the low number of publications in relation to the master's degree defenses.

Some case studies were accomplished with Oracle9i OLAP tool [14], but the need to follow very rigid steps through a pre-established model interfere a little his use. In the next section is presented one of these case studies

The Brazil has some problems because does not have the culture to make patents and registers. An example of this is that Japanese companies patented the process of cupuaçu (fruit from Brazil north region) derivatives. These companies there are five patents of products elaboration process with cupuaçu. The manufacture process was developed by the Emprapa (Brazilian Company of Agricultural Research), an agency of the federal government, and it have been announced about some years ago, but it did not registered [16].

6.1. STUDY ON INTELLECTUAL PROPERTY

6. CASE STUDY A DW has as objective to be a database to query that can help in the process of decision-making. Thus, in this section are presented the results of case studies accomplished using the DW built for S&T [11], in agreement with the architecture proposed by Menolli and Dias [12].

The application of DW demonstrated that amongst all the processes and products created by the researchers since 1990, only 0.08% patents were generated. Despite to be expected that in Brazil few patents are generated, this number is very low. In Brazil. almost the totality of the research is made in public institutions and the researcher doesn't have the incentive of doing the patent and registrations.

Through consultations to DW, some were obtained results, some waited and other surprising ones. In the analysis of the results, it should be considered that the origin databases are slightly outdated (the data about postgraduate courses are of the year of 1998 and of Lattes1 from 1997 to 1999) and only contain regional data, therefore the national reality can not be reflected, but give a good idea how is the behavior of research and the researchers in Brazil.

6.2. NUMBER OF PUBLICATIONS OF BOOKS

The search showed in this section, compares the difference in the number of book publication or books chapter between men and women in diverse range of age.

The elements observed in the realized studies are: the intellectual property, the degree, the time of defense in the master's degree programs and the number of books publication. These elements were evaluated to try finding a relationship among them. To exemplify, can be verified the number of book publications produced from master's degree programs. So, the DW data, when they are treated through viewpoint of an ISA, can be evidenced:

As showed in Figure 3, the difference in the number of publication until 35 years between men and women is very small. In the range of the 35 until 45 years, this difference increases and after reduces again. It is not possible concludes the reason of that increase, maybe in the range of age from 35 to 45 years the women had children, but this hypothesis cannot be verified, therefore in built DW it doesn't contain the researchers' personal data to prove this.

1) organizational aspects, such as the structure of the master's degree programs and of the teaching institutions;

6.3. TIME OF DEFENSE

The next inquiry of this section, show the relationship between academic regime of the postgraduation program and the time that the students completes the master degree (Figure 4).

2) technical aspects, as the number of students of master's degrees that concluded in the right period; 3) the incentive need to the warranty of the intellectual property;

The Figure 4 is divided in 3 parts. The first part is the conclusion average time in master degree in accordance with the regime period. The second part is the conclusion average time in accordance with the regime period to students who entered in the master degree program before 1996, and the last part is the conclusion time average for students who entered in the master degree program from 1996.

4) the necessity to establish incentive politics to the publications of the results of researches. These evidences are handled starting from the historic data stored in DW. For instance, the need to 1

Platform of curriculum http://lattes.cnpq.br/

of

brazilian

researchers

-

7

Maria Madalena Dias, Tania F. C. Tait André L. A. Menolli, and Roberto C. S. Pacheco

Data Warehouse Architecture through Viewpoint of Information System Architecture

Number of Publications

Number of Publised Books for Year

6 5 4

Women

3

Men

2 1 0 25

de 25 a 35

de 35 a 45

de 45 a 55

55

Range of Age Figure 3: Number of Books Published for Year [11]

Conclusion Average Time in Master Degree Programs

Number of Months

60

Academic Regime of the Program

50 40

General Average Annual Semestral Quarterly

30 20 10 0 General

Before 1996

Since 1996

Year of entrance in the Program

Figure 4: Conclusion Average Time in Master Degree Programs [11]

The conclusion time average in master degree programs from some years behind decrease a lot, as is showed in Figure 4. The year of 1996 was used as delimiter, therefore, through queries was perceived that it had a great difference between the conclusion time before and after this year.

only programs with annual regime period had presented a conclusion average time a little bigger.

7. CONCLUSIONS The ISA include the definition of business strategy until the implementation of IS, all components necessary for the IS development and implantation, whereas the software architecture [16] it just comprehend the set of programs, procedures, data and

Through the Figure 4 it can be verified that, from the moment that the average of conclusion time in master degree programs decrease, the difference between regimes period time average is very small,

8

Maria Madalena Dias, Tania F. C. Tait André L. A. Menolli, and Roberto C. S. Pacheco

Data Warehouse Architecture through Viewpoint of Information System Architecture

Warehousing and OLAP, Washington, USA, pages 22-27, 1998.

documentation related to a software that is part of the composition of a IS. The DW architecture originated from the concepts and models defined for IS architecture and not from software architecture. Thus, in the definition of a DW architecture should be considered components related to the data architecture, infrastructure and technologies needed in the construction and use of a DW.

[4]

The DW architectures proposed in the literature include the set of components defined by Kimball et al. [8], which was based on the architectural framework of DW. This architectural framework of DW was derived from the Zachman Framework [7], where the dimensions and perspectives are designed to elicit the elements involved in the IS development. In the case of DW, the dimensions and perspectives represent the necessary elements in its construction and use.

[6]

L. Hadley. Developing a Data Warehouse Architecture, http://www.users.qwest.net/ ~lauramh/resume/thorn.htm

[7]

W. H. Inmon, J. A. Zachman, J. G. Geiger. Data Stores Data Warehousing and the Zachman Framework: Managing Enterprise Knowledge, McGraw-Hill, 1997.

[8]

R. Kimball, L. Reeves, M. Ross, W. Thornthwaite. The Data Warehouse Lifecycle Toolkit: Expert Methods for Designing, Developing, and Deploying Data Warehouses. John Wiley & Sons Inc., 1998.

[9]

J. Kingston, A. Macintosh. Knowledge management through multi-perspective modelling: representing and distributing organizational memory. Elsevier Science Editor. Knowledge-Based Systems. 13: 121-131, 2000.

[5]

In the Knowledge Discovery in Database (KDD), the first step, known as preprocessing, is responsible for preparing the data, where a DW can be built with data extracted from operational source systems. However, for KDD systems, is not enough just defining a DW architecture, it is needed also have a software architecture to guide the development process of this kind of system. In KDD systems, besides the features to realize the preprocessing, is necessary to define the features for the implementation of data mining and post-processing, which they are part of the knowledge discovery in database.

[10] K. Laudon, J. Laudon. Sistemas de informação gerencial – administrando a empresa digital. Trad.: Arlete Símile Marques. São Paulo: Prentice-Hall, 2004.

KDD Systems and OLAP tools use a DW due to it is an integrated and organized data warehouse, in order to facilitate the obtaining of information and interesting knowledge to decision-making. In this case, it is necessary to define a DW architecture and software architectures to guide the development process of KDD systems and OLAP tools.

[11] A. L. A. Menolli. Definição de uma Arquitetura de Data Warehouse para Gestão em Ciência e Tecnologia no Brasil. Universidade Estadual de Maringá, 2004. [12] A. L. A. Menolli, M. M. Dias. A data warehouse architecture in layers for Science and Technology. In Proceedings of the Eighteenth International Conference on Software Engineering & Knowledge Engineering. San Francisco, pages. 162-165, California, 2006.

REFERENCES

[1]

[2] [3]

L. Ertaul, R. Sudarsanam. Security Planning Using Zachman Framework for Enterprises. In Proceedings of EURO mGOV, pages 153-162, 2005. D. S. Frankel et al. The Zachman Framework and the OMG’s Model Driven Architecture. Business Process Trends. White paper, 2003.

M. Axel, Y. Song. Data Warehouse Design for Pharmaceutical Drug Discovery Research. In Proceedings of the 8th International Conference and Workshop on Database and Expert Systems Applications (DEXA97), Toulouse, pages 644650, France, 1997.

[13] D. Meyere, C. Cannon. Building a Better Data Warehouse, Prentice-Hall, 1998 [14] Oracle9i Database, http://otn.oracle.com/software/products/oracle9i

B. A. Devlim, P. T. Murphy. An architecture for a business and information system. IBM System Journal. 27(1): 60-81, 1988. B. Dinter, C. Sapia, G. Hofling, M. Blaschka. The OLAP Market: State of the Art and Research Issues. In Proceedings of the I Workshop on Data

[15] Sell, D. , Pacheco, R. C. S.: Uma Arquitetura para Distribuição de Componentes Tecnológicos de Sistemas de Informações Baseados em Data Warehouse. In Proceedings of the XXI Encontro Nacional de Engenharia de Produção - ENEGEP,

9

Maria Madalena Dias, Tania F. C. Tait André L. A. Menolli, and Roberto C. S. Pacheco

Data Warehouse Architecture through Viewpoint of Information System Architecture

Salvador, 2001. [16] M. Shaw, D. Garlan. Software Architecture – Perspectives on an Emerging Discipline. Prentice Hall, Upper Saddle River, New Jersey, 1996. [17] G. Schreiber, H. Akkermans, A. Anjewierden, R. Hoog, N. Shadbolt, W. V. Velde, B. Wielinga. Knowledge Engineering and Management, Massachusetts Institute of Technology,2000. [18] H. S. Singh. Data Warehouse: Conceitos, Tecnologias, Implementação e Gerenciamento. Makron Books, 2001. [19] P. Sousa, C. Pereira, R. Vendeirinho, A. Caetano, J. Tribolet. Applying the Zachman Framework Dimensions to Support Business Process Modeling. SpringerLink. Digital Enterprise Technology, pages 359-366, 2007. [20] T. F. C. Tait. Arquitetura de Sistemas de Informação. Maringá, Eduem, ISBN: 857628079-5, 2006. [21] J. A. Zachman. A Framework for Information Systems Architeture. IBM Systems Journal. 26(3): 276285, 1987.

10