See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/282404642

Mapping and Modeling of Oil and Gas Relational Data Objects for Warehouse
Development and Efficient Data Mining

Conference Paper · August 2006

DOI: 10.1109/INDIN.2006.275809

CITATIONS READS

10 1,720

2 authors:

Shastri Lakshman Nimmagadda Heinz Dreher

Curtin University 108 PUBLICATIONS   553 CITATIONS   
125 PUBLICATIONS   316 CITATIONS   
SEE PROFILE
SEE PROFILE

Some of the authors of this publication are also working on these related projects:

IS Development Methodologies View project

Computer Science View project

All content following this page was uploaded by Shastri Lakshman Nimmagadda on 16 September 2016.

The user has requested enhancement of the downloaded file.

 Mapping and Modeling of Oil and Gas Relational Data Objects for
Warehouse Development and Efficient Data Mining

Shastri L Nimmagadda and Heinz Dreher

the industrial scenario have been exhaustively discussed in

Abstract— Oil and gas industries archive volumes of [5] and [15]. Data objects relevant to petroleum industry
heterogeneous data. These companies, by virtue of their diverse have been described in [6].
operations, comprise of complicated organizational structure.
The nature of organizational set-up with several operational
II. PROBLEM STATEMENT
units, often results with communication barriers among
operational units. In order to effectively and efficiently Different object classes, sub classes and attributes of the
perform oil and gas company’s business activities, the flow of oil and gas industry are identified. These objects and their
data and information must be consistent and sharing among its relationships are intended to be mapped for
units. In order to improve information sharing among oil and
multidimensional modeling and for the purpose of data
gas company’s personnel, heterogeneous data from various
sources are integrated. Data warehouse is a solution, in which, warehouse development. One key dimension of the data
oil and gas data entities, identified as class objects, are used for warehousing is period, which is interpreted as an object
multidimensional modeling. Relational data structures class, has relation with other objects of the oil and gas
constructed using these class objects, are stored in a company’s data. These data associations will be mapped and
warehousing environment to minimize the complexity of thus dimensional models will be created. It is intended to
heterogeneous data and enhances power of data integration
design multidimensional data structuring for warehousing
and information sharing among different operational units.
historical data of oil and gas industry.
I. INTRODUCTION
III. METHODOLOGY
O il and gas industry as a system deals with different
operational units, each with different types of data. This
complex system possesses several sub-systems such as
Using a relational database approach, object relational
data structures are developed using oil and gas company
exploration, drilling, production and marketing which can be exploration data. Star and snowflake schemas have been
viewed as class objects with common boundaries and used to develop multidimensional data models to be
attributes. Each sub-system is further composed of several described in the next section.
sub-classes. In order to reduce the complexity in data A. Star Schemas
structuring, concepts of object relational, logical Several fact and dimension objects have been identified
dimensional data modeling and data warehousing have been from the oil and gas companies. In the star structural data
introduced. Data warehousing is widely accepted database model, associated object dimensions surround several object
technology in many industries, such as banking, transport, facts in a star style.
health and insurance industries. In recent years, oil and gas The basic idea of the star schema is to retain the
industries have realized the significance [8, 10] of these multidimensional capability of the cube while providing the
warehousing and data mining technologies. flexibility of smaller data storage.
Practical aspects of data modeling have been discussed in
[1] and [11], with examples of star and snowflake schema Dimensions
Contractor
applications in [2]. Various class objects, programming Survey Lines

syntaxes and coding procedures have been demonstrated in

1
[3] and [13]. Metadata, using an object relational approach
Dimensions

1
Dimensions

0.. & 0.. &

for data warehouse development has been detailed in [4]. Surveys

Several data cube views have been interpreted through 0.. & 0.. &

OLAP in [7, 12, 14], and issues relevant to data mining in Facts
1 1
Period
Survey Schedules

Manuscript received March 31, 2006. Shastri L Nimmagadda, Kuwait

Santa Fe, Project and Petroleum Engineering Company, PO Box 9250, Dimensions

Ahmadi, Kuwait City, 61003, Kuwait. (phone: 965 398 3639; e-mail:
NIMM@chevron.com). Fig. 1: A star schema data model of “surveys” object
Heinz Dreher, Curtin University of Technology, GPO Box U1987 Perth,
Western Australia 6845. (e-mail: h.dreher@curtin.edu.au)

1201
1-4244-9701-0/06/$20.00

c 2006 IEEE
 As shown in Fig. 1, the star schema represents a dice of In the implementation model, primary keys of dimensions
four object dimensions (contractor, survey lines, survey are generated when the object model is transferred to the
schedule and survey period) with survey object facts. data model. The facts of the oil and gas data thus refer to the
The fact object class refers to every associated object dimensions using the key migration from the migration
dimension, which is to be placed in a cell of the cube. The tables. When the data models are composed, foreign keys
dimensions in our example are: are identified. Slicing and dicing in star schemas have a
1) The contractor object class describes each individual limitation (selection) of dimensions. It is a run-time issue,
contractor of the contracting company (chosen by the oil & not a modeling one, but the model has to recognize the need
gas company) identified by name, ID, contractors not of it.
obliged to the terms and conditions are not part of the data Alternatively, all the links or associations among
warehouse. dimension and fact tables can also be stored in separate
2) Survey schedule is the schedule of surveys to be tables that logically created, called associative schemas.
conducted in a basin During design and implementation stages, these associative
3) Survey lines possess several survey lines laid for this schemas are triggered for mapping dimensional and fact data
survey tables.
4) Period is the start of survey (including ending date of
B. Snowflake Schemas
survey)
5) Type of survey conducted in a type of basin The basic star schema does not satisfy all the needs of
data mining. Composite dimensions are used such as period
The survey object fact describes here a single survey of survey in the example above. The analyst investigates the
engaged by a contractor at a period, choosing a specific patterns of data according to day, week, month, quarter, year
survey with number of survey lines. The analytical space etc... In such a case, during the mapping process, dimension
can be the whole cube, or the analytical space can be sliced relations have to be normalized. Redundancy of dimension
according to the dimension in to smaller pieces. Each tables is needs to be addressed to reduce the complexity of
dimension is described according to an object class, which is data slicing. The schema that is derived with such a process
specified according to a business subject. This is most is called a snowflake. As shown in Fig. 3, the period
important for the success of data warehouse design. Typical dimension is normalized to days, weeks, months, quarters,
users are exploration manager, exploration database analyst, and year. For every additional normalized dimension: day,
or a marketing engineer. The fact table itself is another week, month, quarter and year, slices can be made from the
object, represented again by a class object. The fact table cubes. For this reason the dimension of period is pre-
refers to every dimension. The association between the fact selected using one of the normalized tables, which is a
tables and dimension tables is always one to many, which simple addition to the data mining queries.
means each fact is associated with exactly one unit of the Object Classes

single dimension, and each unit of the dimension (each :Period

0.. & 1 :Day

contractor, period etc…) can be associated with any number

of facts (including 0) Transforming the object model into the
lasses

0.. & 0.. &

Classes
1 :Month
C

data model implies an implementation of the star schema as

shown in Fig. 1. As shown in Fig. 2, automatically
generated primary and foreign key constraints are hidden in
:Year
1

the display. The dimensions of the star schema are Classes

represented as independent tables. Fig. 3 Normalized period dimension

Object Classes

:Contractor

[PK] Contractor_ID : Integer

:Survey Lines
The resulting snowflake with normalized dimension is as
[PK]SurveyLine_ID : Integer

11 11
shown in Fig. 4.
0.. & 0.. & Object Classes
<<Non-Identifying>> <<Non-Identifying>>
:Year
:Day
:Surveys
Object Classes

:Month
Object Classes

[PK]Survey_ID : Integer
[FK]SurveyLine_ID : Integer 1 1
[FK]SurveySchedule_ID : Integer
1
[FK]Contractor_ID : Integer 0.. &
[FK]Period_ID: Integer 0.. &
bject Classes

0.. &
:Period
Object Classes

0.. & 0.. &

<<Non-Identifying>> 1 <<Non-Identifying>>
1
1
O

0.. &
:Surveys
:Period
:Survey Schedules
[PK]Period_ID : Integer 0.. & 0.. &
[PK]SurveySchedule_ID : Integer
1 0.. & :SurveySchedule
:Contractor

Object Classes 1
1
:SurveyLines

Fig. 2: Implementation of star schema for Object Classes

“survey/contractor” problem Fig. 4: A snowflake schema with normalized period

dimension associated with survey facts

1202 2006 IEEE International Conference on Industrial Informatics

 Of course, all the dimensions may be normalized like the associations. Documenting such a relationship must be made
period example. This results in simplifying more complex in practice for the snowflake schemas. The simple object
data schemas. The implementation schema (data model) view gives the opportunity for understanding the concept,
developed out of this snowflake is shown in Fig. 5. Again, whereas general data view informs the implementation
the generated constraints are hidden in our model display. stage.
Slicing in a snowflake is possible not just at the basic period Dimensions

dimension, but also at normalized days, week, month, Period

[PK]Period_ID : Integer
Survey Lines
[PK]SurveyLine_ID: Integer
[FK]Day_ID : Integer
quarter and year. [FK]Month_ID: Integer
[FK]Year_ID : Integer 1
1@ <<Identifying>>
Object Classes 1 0.. &
<<Non-Identifying>> SurveyLine Relation
Day Month Year [FK]Survey_ID : Integer

Dimensions
[FK]SurveyLine_ID : Integer
[PK]Day_ID : Integer [PK]Month_ID : Integer [PK]Year_ID : Integer
0.. &

Dimensions
<<PK>>PK_DY20() <<PK>>PK_YR20() <<Identifying>>
<<PK>>PK_MO19()
1
1 1 0.. &
<<Non-Identifying>>
1
1
<<Non-Identifying>> Surveys
0.. & <<Non-Identifying>>
0.. & 0.. & [PK]Survey_ID: Integer
Period
Object Classes

[FK]SurveyLine_ID : Integer
[PK]Period_ID : Integer [FK]SurveySchedule_ID : Integer
[FK]Day_ID : Integer 0.. & [FK]Contractor_ID : Integer

Object Classes
[FK]Month_ID: Integer [FK]Period_ID : Integer
[FK]Year_ID : Integer 0.. &
1
1 <<Non-Identifying>> 11 <<Non-Identifying>>
0.. &
Facts
<<Non-Identifying>>
Survey Schedule 1
Surveys Contractor
[PK]Survey_ID: Integer [PK]SurveySchedule_ID: Integer
[FK]SurveyLine_ID : Integer [PK]Contractor_ID : Integer
[FK]SurveySchedule_ID : Integer
[FK]Contractor_ID : Integer
Dimensions
[FK]Period_ID : Integer
0.. & 0.. &
0.. &
<<Non-Identifying>>

Fig. 7: A snowflake data model with normalized period

<<Non-Identifying>> <<Non-Identifying>>
1 1
1
1
1
Survey Schedule Contractor
Survey Lines

[PK]SurveyLine_ID: Integer [PK]SurveySchedule_ID: Integer [PK]Contractor_ID : Integer dimension associated (many-to-many) with surveys object
Object Classes
D. Object class hierarchies
Fig. 5: A snowflake schema model with normalized period Data mining discovers both corporate and operational
dimension and association with “Surveys” object information from the oil and gas company data that is
hidden at the bottom of the operational sub-systems.
C. Many to-many relationships Demography data can be built based on the contractor
On every survey or investigation, there may be many dimension in different hierarchies. Contractor is grouped
survey lines. There can be several of them if the survey is according to the city, or state or zip code, then according to
extended on offshore and transitional zones from onshore country as shown in Fig 8.
areas. In such a case, one-to-many relationships will not be Dimensions
Dimensions

there between survey facts and survey line dimensions, but

Dimensions
Contractor ZIP Code Country
many-to-many associations exist. However such an
association cannot be implemented in the star schema. A 0.. & 1 0.. & 1

special form of a snowflake schema implements the Dimensions

necessary structure of the data to comprehend this need. Our

model will be changed to many-to-many associations Fig. 8: The hierarchy of “contractor” object
between the fact and the dimension tables. This is just a
The hierarchy is specified using an aggregation which
change in the cardinality of the association as shown in Fig
defines the containment. The country contains the zip codes
6.
Dimensions and the zip code will link to composite attribute, such as
Contractor Survey Lines
address of multiple contractors. Using aggregation, the
1
0..&
dimension table is used at any level as defined in Fig. 9.
Contractor, zip code, or country attributes can slice the
0..&
ns

0..&
D
sio

im

Surveys
n

en
ime

analytical space.
sion
D

0.. &
s

0..&
Facts
Dimensions
1 1
Period Survey Schedule Period
Survey Schedules
[PK]Period_id : Integer
[PK]SurveySchedule_ID : Integer [FK]Day_ID : Integer
1
[FK]Month_ID : Integer
<<Non-Identifying>>
Dimensions [FK]Year_ID : Integer
<<Non-Identifying>> 0.. & 0.. &

Surveys
Dimensions

Fig. 6: A star schema with many-to-many relationship [PK]Survey_ID : Integer

[FK]SurveySchedule_ID : Integer
Dimensions

[FK]Contractor_ID : Integer 1
dimension of “Survey Lines” 0.. & [FK]Period_ID : Integer
<<Non-Identifying>>
<<Identifying>>
1 0.. &
Contractor SurveyLine Relation
[FK]Survey_ID : Integer
The many-to-many association cannot be implemented
[PK]Contractor_ID : Integer
[FK]SurveyLine_ID : Integer
[FK]ZIPCode_ID : Integer
0.. & 0.. &

with a relational database, but another kind of snowflake <<Non-Identifying>>

ZIP Code
1
<<Identifying>> 1

[PK]ZIPCode_ID : Integer Survey Line

schema can be used to implement these relationships. As [FK]Country_ID : Integer
[PK]SurveyLine_ID : Integer

shown in Fig. 7, many-to-many relations are implemented in

0.. &
Country
<<Non-Identifying>> 1 [PK]Country_ID : Integer

which an additional dimension refers to the dimension Dimensions

survey type and the survey facts object class. Relationships

Fig. 9: A snowflake schema implementing aggregates of
are identified and used to resolve many-to-many
“contractor” object

2006 IEEE International Conference on Industrial Informatics 1203

 IV. ANALYSIS AND DISCUSSIONS examined in Fig 12.
The basic star schema creates a multidimensional space
Data Mining
(often called dice), using the basic capabilities of a relational
database utilities [12]. One needs to understand a
Decision
multidimensional space. A multidimensional analysis space Exploration Support

Data Mining
Data Mart
is depicted in the Fig. 10. A geometrical dice is an example Information

Data Mining
of three dimensional space with all three dimensions of the
Oil & Gas
same size. Imaging a cube with each object class dimension
of three units, we get 44 = 256 cells of equal structure. The
Data Delivery
Decision
multidimensional analysis space (or a data warehouse dice) Production Support
Data Mart Information
differs just in details from a geometrical space.

Data Mining

Fig. 11: Position of the data mart within an oil and gas
company
Contractor

Fact Fact Fact

architecture

Fact Fact
META DATA
Time

Fact

Cleaning

data-mining
Integration
Etc... DW Server
Wells

Fig. 10: A dice with dimensions wells, contractor, time

Data Marts
However, the dimensions are not just limited to just three.
It is not easy to handle a cube with several object class
dimensions, which often result in most of the Background Data-Mining
Processes DW Server OLAP Engine Analysis
implementations, limited to six or seven object dimensions.
However, one should never expect a good graphical Fig. 12: Integration of data objects from different marts
representation of more than three object dimensions. All
object dimensions are not of the same size and unit. The size On Line Analytical Processing (OLAP) [7] has capability
can differ from few units to several millions of units. The to look into oil company’s data object models in depth, map
units can be period (day, quarter, month or year), contractor, and present them in interpretable ways by decision makers.
wells or an exploration department, with several fact tables
(see Fig. 10). The data cube needs much memory to store all Mapping of Petroleum Fie ld Objects of Gulf Bas ins

the facts. For this reason, we design multidimensional Field2

Petro Data
schemas in a warehouse environment, optimizing storage
Ma ppi ng of Petrole um Fi eld Objects of Gulf Ba sins

Warehouse
Field1
capacity and preserving the flexibility of data structuring.
Field3
The data warehouse developed using the relational objects
of the oil and gas data items, has several architectural views. Field4
Data Mining
With the design of data structures designed and application Knowledge Mapping

developed, for oil and gas company, these architectures Petro Data Mining
Exploration

possess great flexibility. An example of architecture with the Field6 Period

Field5
positioning of data warehouse and data marts is shown in January
February

March
Fact s Facts

Fig. 11.
F a c ts

F a c ts

April
F acts

May

The purpose of mapping objects of oil and gas company June

Production

data is to keep the operational managers active and sharp in Petroleum bear ing field objec ts of Gulf Ba sins

their managerial decision support to act promptly. Million Fig. 13: Interoperability of data objects among petro-fields
dollar decisions are taken based on the information
processed by data warehouse with accountability and it Two of such situations discussed in this paper, such as,
provides an added value in return, tens of millions of dollars contractor-surveys, operator-wells problems have been
saved. Data objects from different warehouse marts, such as processed and interpreted as shown in Figs. 16, 17a and 17b.
exploration, drilling and production are integrated as Oil-field base data objects are reused (interoperability)

1204 2006 IEEE International Conference on Industrial Informatics

 Aggregated Object Views
among multiple petroleum fields (Fig. 13), so that (C)
Period ID = 15
(D)
Survey ID = SR-GP1001

knowledge built from data integration, is interpreted in terms Start of Survey = 4/15/76
End of Survey = 12/25/77
Date of VSP = 12/5/7
Period ID = 15
Survey ID = SR1001
Start of Project = 15/4/76 G
D

of drillable exploratory or development location as given in Date of Uphole = 5/10/78

(G)
End of Project = 6/30/77

Contractor ID = CR1100

an OLAP model as demonstrated in Fig 14. C

Aggregated Object Views

Geophysicist ID = GP1001
Surveyor = John
(F) H

Time
Contractor ID = CT1001 F
Logger ID = LG1003
Special Survey = 3D-Time Lapse
Distance Survey ID = WS1001

r
o
Date Logging = 12/5/78

ct
ra
(H)

nt
Contractor ID = CT1001

o
C
Geologist ID = EN1001 E
Geologist Name = Reuben
(E) B
Contractor ID = CT1001
Depth

Contractor Name = Charles

Survey ID = WS1001
Period ID = 21

(B)
Survey ID = SR1001 Surveys
Survey Name = 2D Seismic
Start Date = 15/4/78
End Date = 12/05/77
Contractor ID = CT0100
Aggregated Object Views
H

OWC Region Object

Fig. 16: Aggregated computed views of “survey” object

Line Objects Multidimensional object data views for super class object
Net Oil-Pay Region Object “wells” are shown in Figs. 17a and 17b. All the available
Net Reservoir Region Object
Point Object Structure Region Object data and information are now integrated (Fig.16) and
available in a centrally located enterprise data warehouse
Fig. 14: OLAP model for petroleum exploration (EDW), making it easy for all managers to take timely
decisions. Different data warehouse architectures may be
Exploration managers are responsible for providing the tried creating several data marts that can map and process
valued processed exploration information, so that critical individual operational units’ object classes and make them
decisions made in planning new exploratory or development available to exploration managers. Similar data marts may
wells in the frontier oil bearing sedimentary basins are be initiated for drilling, production, marketing, human
accurate and precise. Fig.15 exhibits the interoperability of resources and other support engineering class objects.
petroleum data objects among basins, when data objects are Aggregated Object Views

conceptualized using petroleum ontology [9]. D

G
Contractor

Time
F

r
o
ct
ra
A

nt
o
C
Time E

Wells

Wells

Fig. 17a: Example of 3D data cube showing three

dimensions wells, contractor and time

Aggregated Object Views

(C)
Period ID = 21
Well ID = WS1001 (D)
Start of Drilling = 4/15/78 Period ID = 20 D
End of Drilling = 12/25/78 Well ID = WS1001
Date of Logging = 12/5/78 Start of Project = 15/4/77 G
Date of Spud = 5/10/78 End of Project = 6/30/80

(G)
Contractor ID = CT1001
Engineer ID = EN1001 C
Aggregated Object Views

Fig. 15: Interoperability of petroleum data objects among

Engineer Name = John
(F) H
Time

Contractor ID = CT1001 F
petroleum bearing sedimentary basins Logger ID = LG1003
Logger Name = Edward
Well ID = WS1001
r
to

Date Logging = 12/5/78

ac

(H)
All the survey information processed by OLAP is
tr
on

Contractor ID = CT1001
Geologist ID = EN1001
C

E
presented by different combination of aggregated views as (E)
Geologist Name = Reuben

B
shown in Fig. 16.
Contractor ID = CT1001
Contractor Name = Charles
Well ID = WS1001
Period ID = 21

(B)
Well facts stored in the oil and gas data warehouse or data Well ID = WS1001
Well Name = Karrata1
Wells
Start Date = 15/4/78
marts, are processed by OLAP procedure [7] and presented End Date = 12/25/78
Contractor ID = CT0012
Aggregated Object Views
in aggregated data views convenient to interpret and extract
knowledge from the past historical oil and gas business data. Fig. 17b: Computed aggregate views of “wells” object

2006 IEEE International Conference on Industrial Informatics 1205

 V. SUMMARY AND CONCLUSIONS [10] Nimmagadda, S.L, Dreher, H. and Rudra, A. (2005b) Warehousing of
Object Oriented Petroleum Data for Knowledge Mapping, published in the
The object class model describes an integrated proceedings of 5th International Conference of IBIMA, Cairo, Egypt
multidimensional data structuring in a data warehouse [11] Ozkarahan, E., (1990). Database Management, Concepts, Design and
Practice., Prentice Hall Publications., 15-200p.
environment. The object class models described in this paper [12] Pujari, K. A. (2001) Data Mining Techniques, Universities Press, p. 7-
can easily be implemented in an oil and gas industry. The 67.
data models are generated for specific classes of oil and gas [13] Rumbaugh, T., M. Blaha, W. Premerlani, F. Eddy, and W. Lorensen.
data object classes. For surveys – contractor, wells - (1991). Object-Oriented Modeling and Design. Englewood Cliffs, NJ:
Prentice-Hall.
operator problems, star and snowflake multidimensional [14] Smith, J.R. (2004). A Wavelet Frame Work for Adapting Data Cube
structuring appear to be consistent. It is appropriate to argue Views for OLAP, IEEE Trans. On Knowledge and Data Engineering, Vol.
multidimensional structuring in a data warehouse 18(5), pp.552-565.
[15] Zaima, A. and Kashner, J., (2003). A data mining premier for the data
environment offers better data integration functionality, the warehousing professional, Business Intelligence Journal, Vol 8(2).
database administrator needs to tune the data warehouse for http://www.tdwi.org.
multi users. This paper analyzes the oil and gas company’s
business data object classes; develops logical models for
implementing them in a warehouse. This paper establishes
applicability and feasibility of object class data modeling
and mapping procedures for oil and gas Company. Millions
of facts and hundreds of dimensions have been identified
from operations such as exploration, drilling, production and
marketing classes, in which several other sub-classes, are
interpreted as objects. This paper restricts to mapping of
surveys and wells data objects that belong to super class
exploration object. There is future scope and application of
these logical modeling concepts in other areas of drilling,
production, marketing class objects and integrating with
several other object classes from other support services of
oil and gas company, thereby drastically reducing the
complexity of data items and enhancing the information
sharing and data integrity among operational units of an oil
and gas company.

REFERENCES
[1] D’Orazio, R., and Happel, G. (1996). Practical Data Modelling for
Database Design. The information Technology Series, John Wiley & Sons
Australia Ltd., 180-280p.
[2] Gornic, D (2000) Data Modelling for Data Warehouses, Rational
Software White Paper,
www.rational.com/worldwide.
[3] Hoffer, J.A, Presscot, M.B and McFadden, F.R (2002). Modern
Database Management, Sixth Edition, Prentice Hall, 260-520p.
[4] Huynh, T.N. Mangisengi, O. and Tjoa, A.M., (2000). Metadata for
Object-Relational Data Warehouse., Proceedings of the International
Workshop on Design and Management of Data Warehouses., Stockholm,
Sweden., June 5-6.
[5] King, E. (2000). Data Warehousing and Data Mining, Computer
Technology Research Corporation, 50-110p, http://www.ctrcorp.com.
[6] Longley, I.M. Bradshaw, M.T. and Hebberger, J. (2001) Australian
petroleum provinces of the 21st century, in Downey, M.W. Threet, J.C.
Morgan, W.A (2001) Petroleum provinces of the 21st century, AAPG
Memoir 74, pp.287-317.
[7] Moody, L. D and Kortink, M.A.R (2003). From ER Models to
Dimensional Models: Bridging the gap between OLTP and OLAP Design,
Part1 and Part 2, Business Journal Intelligence, Summer Fall editions, Vol.
8(3), http://www.tdwi.org.
[8] Nimmagadda, S.L, Dreher, H. and Rudra, A. (2005a) Data Warehouse
Structuring Methodologies for Efficient Mining of Western Australian
Petroleum Data Sources, published in the proceedings of IEEE conference
of INDIN 05, Perth, Australia
[9] Nimmagadda, S.L., Dreher, H. and Rudra, A. (2005a) Ontology of
Western Australian petroleum exploration data for effective data warehouse
design and data mining, published in the proceedings of the 3rd international
IEEE conference on Industrial Informatics, held in Perth, Australia, August.

1206 2006 IEEE International Conference on Industrial Informatics

View publication stats