GOAL-ONTOLOGY ETL PROCESSES SPECIFICATION

The design-related problems for extract, transform, load (ETL) processes are far away from being resolved due to the ambiguity of user requirements and the complexity of operations. Current approaches are based on existing software requirement methods that have limitations on reconciliation of the requirement semantics toward generating the ETL processes specification. The solution is to apply the RAMEPs (Requirement Analysis Method for ETL Processes) that was developed to facilitate the design of the ETL processes in the perspectives of organization, decision-maker, and developer. The results are the ETL processes specification, which was validated on the correctness of the goal-ontology model and evaluated in the case study of Gas Malaysia Data Warehouse (DW) system. The case study illustrated how the goal-ontology approach was successfully implemented in designing and generating the ETL processes specification.


INTRODUCTION
Data Warehouse (DW) is a system for gathering, storing, processing, and providing huge amounts of data with analytical tools to present complex and meaningful information for decision makers (Ta'a, Abdullah & Norwawi, 2010).These data are collected, stored, and accessed in centralized databases in order to sustain competitiveness in the business environment.However, the DW system requires the ETL processes for providing the required data (Kimball & Caserta, 2004).Specifically, the success of the DW system is highly dependent on the ETL processes specification.Many issues in modelling and designing the ETL processes are due to the problems of capturing and analysing the appropriate requirements of DW (Simitsis, 2004;Kimball & Caserta, 2004).Moreover, the design tasks need to tackle the complexity of the ETL processes from the early phases of the DW system development to ensure the appropriateness of the information produced from the DW systems (Giorgini, Rizzi & Garzetti, 2008).
The complexity of the ETL processes always refers to the problem of defining the integration and transformations of data sources.These transformations involve the reconciliation semantic of user requirements and data sources heterogeneity (Alexiev, Breu, Bruijn, Fensel, Lara & Lausen, 2005;Allemang & Hendler, 2008).Generally, an ambiguous definition of user requirements occurs because the users are unable to define their requirements precisely and clearly (Inmon, 2002).Moreover, various meanings of data (e.g.attributes, tables, constraints) make it difficult for integrating the user requirements to the appropriate data sources.Thus, reconciliations of user requirements and data sources are important for generating the ETL processes accordingly.The designing of the ETL processes should commence from the early phases of the DW system development and guided by a suitable methodology.Therefore, this research has applied the RAMEPs, a requirement analysis method for the ETL processes (Ta'a et al., (2010), and generated the ETL processes specification from the Gas Malaysia DW system case study.

REQUIREMENT ANALYSIS MODEL FOR ETL PROCESSES
Requirement analysis of the ETL processes focuses on the informal statements of user requirements into a formal expression of the ETL processes specifications.The informal statements are derived from the requirement of users and analysed from the organization and decision-maker perspectives (Giorgini et al., 2008).However, we argue that analysing the user requirements toward the ETL processes specification is better defined by supporting of the developer perspectives.This is clearly important for tackling the complexity issues, which analyse abstract knowledge to the detail execution of the ETL processes.It is widely accepted that the early requirement analysis significantly reduces the possibility of misunderstanding user requirements (Yu, 1995).The better the understanding among users, the higher are the chances of agreeing on the terms and definitions used in the ETL processes specification.Therefore, the RAMEPs is centered on the organizational and decisional modeling and focuses on the transformation analysis from the perspective of a developer model.
The focus on the works in RAMEPs are highlighted in the thick box area of Figure 1.The organizational modeling is used to identify the goals that are related to facts, and attributes.The decisional modeling is focused on the information needs decision makers and related to facts, dimension and measures.The developer modeling is used to define the related actions and business rules for the data sources.Detailed explanation on the RAMEPs can be referred to in Ta'a et al., (2010).

GOAL-ONTOLOGY FOR REQUIREMENT ANALYSIS MODEL
The aim of RAMEPs is to facilitate the design of the ETL processes by analysing and producing the DW requirements for decision-makers and organizations.Through RAMEPs, the ETL processes are modeled and designed by capturing important knowledge such as the DW schemas and transformation activities.Indeed, the goal-oriented approach is utilized to capture and represent the knowledge about the ETL processes as defined from the perspectives of the organization, decision-maker, and developer.Developer perspectives are pressing beside the organization and the decisionmaker perspectives in order to complete the requirements analysis model of the ETL processes.

Goal-orientedApproach
Goal-oriented is utilizing goals for requirements elicitation, evaluation, negotiation, elaboration, structuring, documentation, analysis and evolution of the software system through the cooperation of its agents (Bresciani, Perini,  Giorgini, Giunchiglia & Mylopoulos, 2003;Lamsweerde, 2010).Specifically, this research uses goals to elicit and analyse the DW requirements with the cooperation of three modeling: organizational, decisional, and developer.
Organizational Modelling -consists of three different analyses, which are produced in the iterative process.The types of analyses is goal analysis, fact analysis, and attributes analysis.All goals, facts, and attributes are defined in the context of organization views.
Decisional Modelling -consists of four different analyses, which are produced in the iterative process.However, these analyses are focused on the goal of a decision-maker that is represented by the actors as defined in the organizational model.The types of analyses are goal analysis, fact analysis, dimension is required for supporting the decision making.
Developer Modelling -consists of three different analyses, which are produced in the iterative process.The analysis is focused on the goal of a decision-maker which is represented by the actors as defined in the decisional model.The analyses are data sources analysis, business rules analysis, and transformation analysis.The transformation analysis is based on plan modelling in Tropos methodology (Bresciani, Perini, Giorgini, Giunchiglia & Mylopoulos, 2004).The developer modelling explains the facts about actions and rules applied to the data sources in the perspectives of ETL developers.The developer modelling will complete the goal-driven analysis of user requirements in order to produce the ETL processes model for the DW system.
As comparism, the outcome of each of the modelling is presented in Table 1.

Ontology-based Approach
The organizational, decisional, and developer models have determined the ETL processes glossaries (i.e.facts, dimensions, measures, attributes, business rules, actions) through goal-driven diagrams.The glossaries for facts, dimensions, attributes, measures, and actions must be agreed up on by the users.This will be used for building the conceptual design of ETL processes according to RAMEPs approach.Since these agreeable glossaries will be mapped to the heterogeneous data sources, the semantic heterogeneity problems will remain in the implementation of ETL processes.Importantly, the agreeable glossaries should be able to present the semantics of user requirements accordingly.Thus, the semantic heterogeneity problems in the data sources can be resolved by using an ontology model.The same approach was successfully applied to resolve the data integration problems from the various data sharing systems (Alexiev, Breu, Bruijn, Fensel, Lara & Lausen, 2005;Allemang & Hendler, 2008).
In ontology modelling, the process for constructing the DW requirements ontology (DWRO) is semantically described in the requirement glossaries.
The semantics of the DW requirements are described in high-level meaning, so that the DW requirements can be possibly mapped to the data sources ontology (DSO) for accomplishing the transformation and integration process.The strong linkages between requirement glossaries and appropriate data sources through ontology structure will produce the ETL processes specification automatically.This can be done through invoking an appropriate algorithm and reasoning.In particular, the use of ontology is based on description logic (DL), which constitutes the most commonly use of knowledge representation formalism (Hutter, Stephan, Baader, Horrocks & Sattler, 2005).This research uses the OWL language for knowledge representation that adopted the DL formalism.The Resource Description Framework (RDF) is used together with OWL in presenting the DWRO and DSO for modelling the concepts of the domain, relationships between concepts to attributes, and the attributes and relationship that belong to each attribute.The concepts refer to the facts, whereas the dimensions, measures,business rules, and actions refer to the attributes.The concepts of the domain are represented by classes, and relationships or attributes are represented by the properties.Moreover, theconcept, relation, and attribute components were also applied in representing the semantic sentences through the concept relational model (CRM), which was concerned with the ambiguity of sentences (Abdullah, Selamat, Ibrahim, Chulan & Nasharuddin, 2009).
Due to the specialty of aggregation and population operation in the DW systems, specific representation classes are necessary to specify.However, the RDF/OWL features need to be suited for high-level representation, since all the glossaries are defined in the abstract form.For this purpose, the RDF/ OWL features and ontology notations were adopted as shown in Table 2.The mapping results between DWRO and DSO created new classes and properties pertaining to the ETL processes activities, and produced merging requirement ontology (MRO).These new classes and properties will capture the knowledge of the ETL processes such as aggregated, aggregation, range, table, formation, and others.The type of knowledge applied for this case study is shown in Table 3.These new classes need to be organized accordingly into the MRO.Again, this task is done through Protégé-OWL.This process is finished until the ontology structure is reconstructed and rechecked by using the Pellet reasoner.New RDF/ OWL document is produced to represent the entire specification of the ETL processes.Then, the RDF/OWL document is used to determine the appropriate ETL processes specification.However, few refinements on the MRO need to be carried out in order to ensure the ontology structure is fully satisfying the ETL processes operation.Through a reasoning process, the inferred MRO is semantically organized in presenting the knowledge of the ETL processes.By using the semantic Jena 2 framework as a web-programming language, the ETL processes specification is produced.Furthermore, the generated ETL processes specification can be used for implementing the DW system.

THE CASE STUDY
The case study discussed in this paper is focused on the Gas Malaysia utility company.This company promotes, constructs, and operates the Natural Gas Distribution System within Peninsular Malaysia.The company's mission in providing the cleanest, safest, cost effective, and reliable energy solutions were motivated them to provide innovative energy solutions to the nation.The requirements gathering was carried out with the company stakeholders and focused on the information needed.These requirements were focused on the billing area, which was comprised of billing transaction activities.The billing system was implemented in the Utility Billing Information System (UBIS).
It was focused on the residential customers and supported by the external application systems namely the JDE System and the Call Center System (CCS).The main goals of Gas Malaysia are shown in Figure 2.

Organization Modelling
The main goal of the company is Innovative Value for Energy Solutions Provider.This main goal is supported by four sub-goals that need to be fulfilled for achieving the main goal.To simplify the evaluation process, the case study is focused on the Cost Effective Energy Solution that is related to the billing area.The analyses task was commenced by modelling the DW requirements in the perspective of the Billing Department.The stakeholders involved in the billing area were identified and represented by using an actor model.An actor model explains the dependencies among the actors (i.e.billing department, customer, billing operator, call center department).The next step was to analyse the facts that aim to identify all the relevant facts for the billing area.
The facts explain the information required within the goal structure in the billing area.Thus, the analysis was carried out by identifying the facts for each goal from top to down of the goal hierarchy.The final diagram for organization modelling that defines two facts (i.e.Sale Volume and Revenue and Customer and Billing Status) is illustrated in Figure 3 and Figure 4 respectively.

Organization Modelling
The main goal of the company is Innovative Value for Energy Solutions Provider.This main g supported by four sub-goals that need to be fulfilled for achieving the main goal.To simpli evaluation process, the case study is focused on the Cost Effective Energy Solution that is related billing area.The analyses task was commenced by modelling the DW requirements in the perspect the Billing Department.The stakeholders involved in the billing area were identified and represen using an actor model.An actor model explains the dependencies among the actors (i.e.billing depar customer, billing operator, call center department).The next step was to analyse the facts that a identify all the relevant facts for the billing area.The facts explain the information required with goal structure in the billing area.Thus, the analysis was carried out by identifying the facts for eac from top to down of the goal hierarchy.The final diagram for organization modelling that define facts (i.e.Sale Volume and Revenue and Customer and Billing Status) is illustrated in Figure 3 and F 4 respectively.

Decisional Modelling
There are four phases in decisional modelling: goal analysis, fact analysis, dimension analysis, and measure analysis.All four analyses are connected to each other and aimed to identify the DW components.The analysis is focused on the decision-maker goals in order to define the requirements.The analysis process starts with identifying the actors in the goal analysis, and extends to the fact, dimension, and measure.In this case study, a Billing Manager (BM) was selected as an actor for the decision maker.In previous approaches, the requirement analysis process ended at this stage.The knowledge of facts, dimensions, attributes, and measures will be used in further designs of the is the DW and ETL processes.However, the extended analysis of data transformation thats related to defining facts, dimensions, and measures needs to be carried out to ensure the successful implementation of the DW system.
The final diagram for decisional modelling that define the few measures is illustrated in Figure 5 and Figure 6 respectively.

Developer Modelling
In business rule analysis, the developer needs to identify the restrictions applicable to the ETL processes according to the user requirements.The ETL processes will populate the data sources according to the restrictions given.In

Decisional Modelling
There are four phases in decisional modelling: goal analysis, measure analysis.All four analyses are connected to each components.The analysis is focused on the decision-maker goals analysis process starts with identifying the actors in the goal ana and measure.In this case study, a Billing Manager (BM) was sel In previous approaches, the requirement analysis process ended dimensions, attributes, and measures will be used in further desig However, the extended analysis of data transformation thats re measures needs to be carried out to ensure the successful imple diagram for decisional modelling that define the few measures respectively.

Developer Modelling
In business rule analysis, the developer needs to identify the rest according to the user requirements.The ETL processes will po restrictions given.In this case study, the business rules were Revenue and Billing and Customer Status.According to the anal Table 3.

Account Number
Customer Type Supply Type

Gas Consume
Cost Billing

Billing Mode
Total Consumption this case study, the business rules were identified for facts of Sale Volume and Revenue and Billing and Customer Status.According to the analysis, list of business rules is presented in Table 3.  7 nager (BM) was selected as an actor for the decision maker.lysis process ended at this stage.The knowledge of facts, used in further designs of the is the DW and ETL processes.sformation thats related to defining facts, dimensions, and he successful implementation of the DW system.The final e the few measures is illustrated in Figure 5 and Figure 6 sures Figure 6.Customer and Billing Status Measure to identify the restrictions applicable to the ETL processes processes will populate the data sources according to the siness rules were identified for facts of Sale Volume and cording to the analysis, list of business rules is presented in

Ontology Modelling
The design of the ETL processes is conceptualized by the DW components that are produced from the goal-oriented requirement analysis process.Both databases handle the billing transaction for gas consumption of the residential and the industrial respectively.These data sources are implemented in the different systems that is dissimilar in their data structure and semantics.This scenario creates the heterogeneity problems during the integration and transformation of the data sources.Therefore, the integration of both data sources is resolves the semantic heterogeneity problems by defining the ontology concepts and classes between the data sources and the DW requirements.
The mapping and matching process as involve the identification of similarity and dissimilarity of concepts and associate attributes of the DWRO and the DSO.These elements are defined in the ontology as follows: Based on the mapping definition as described in Ta'a, Abdullah and Norwawi (2010), the ontology mapping between the DWRO and the DSO for Sale Volume and Revenue is shown in Table 5.This ontology mapping should maintain the semantics of user requirements as defined in the DWRO.Table 5 presents the mapping specifications of the DWRO and the DSO that are derived from the analysis process of user requirements and supported by the related data sources.To complete the entire cycle of the ETL processes activities, the actions for extract and loading are added in the actions plan.Based on the mapping results, new classes and properties pertaining to the merging ontology (MRO) were produced.These new classes and properties are shown in Table 6.These new classes and properties are reorganized properly into the MRO after the merging process is successful through Protégé-OWL.Moreover, the ontology merging is done through the ontology setting as defined in Table 7.This process is finished when the ontology structure is reconstructed and rechecked by using the Pallet reasoner.The new appearance of the MRO with the new classes and properties that represent the ETL processes specification is shown in Figure 9.

Constructing the ETL Processes Specifications
Using the MRO as knowledge representation of the DW requirements and the ETL operations of thebilling area, the generation of the ETL processes specification is done automatically.This task can be realized by manipulating the semantic annotation of the user requirements and the data sources in the MRO.The manipulation process proposes a set of ETL processes specifications that transform the data sources to the DW schemas as determined in the goaloriented analysis approach.The generic data transformations used in this case study are EXTRACT, MERGE, FILTER, CONVERT, AGGREGATE, and LOAD.As presented in the MRO, the knowledge about the information as required and their related data sources have been defined according to the RDF/OWL-based language.Thus, the MRO is processed to determine and propose a set of ETL processes specifications.Ontology reasoning is applied on classes and their related properties to derive the ETL processes specifications according to the generic data transformation tasks.
The MRO structure that is represented by the RDF/OWL language (as shown in Figure 10) is manipulated through the Jena 2 framework.To generate the ETL processes specifications, a prototype application for reading, and manipulating the MRO was developed by using Java running on the Eclipse platform.The derivative of the ETL processes specification is based on an algorithm (as shown in Figure 11) that is adapted from Skoutas and Simitsis (2007).The result of this application is the ETL processes specifications as shown in Figure 12.

VALIDATION AND EVALUATION
Since the RAMEPs is based on the goal-oriented and ontology approach, the validation process is emphasized on the correctness of both approaches.Consequently, the correctness of the RAMEPs is not enough until it can be evaluated in the real design of the ETL processes.To validate the correctness and ensuring the satisfaction of the RAMEPs, appropriate goal-oriented and ontology compliant tools are required for capturing and analysing the DW requirements.The compliant goal-oriented tools must be able to accommodate the elements of organizational, decisional, and developer into the modelling functionalities.Moreover, the compliant ontology tools must be able to capture and present the DW requirements and data sources in an ontology model.The evaluation was conducted for ensuring the usefulness of the RAMEPs for designing the ETL processes and was implemented in the real DW project case studies.
Generally, model checkers are used to verify the correctness of the software systems at the design stage.The correctness of a software system is verified according to the system's properties that must be a model-checked.System properties in the RAMEPs are the DW components (i.e.facts, dimensions, measures, business rules, measures) as defined from the goal-oriented analysis.The method proposed by Ogawa, Kumeno and Honiden ( 2008) was adopted to validate the DW components by using compliant tools (DW-Tool and Protégé-OWL).This method was chosen because it uses-goal oriented requirement analysis for formal presentation of the software properties.Moreover, the validation of properties is focused on the sufficiency of design against requirements, which is similar to our objectives.However, our 15

VALIDATION AND EVALUATION
Since the RAMEPs is based on the goal-oriented and ontology approach, the validation process is emphasized on the correctness of both approaches.Consequently, the correctness of the RAMEPs is not enough until it can be evaluated in the real design of the ETL processes.To validate the correctness and ensuring the satisfaction of the RAMEPs, appropriate goal-oriented and ontology compliant tools are required for capturing and analysing the DW requirements.The compliant goal-oriented tools must be able to accommodate the elements of organizational, decisional, and developer into the modelling functionalities.Moreover, the compliant ontology tools must be able to capture and present the DW requirements and data sources in an ontology model.The evaluation was conducted for ensuring the usefulness of the RAMEPs for designing the ETL processes and was implemented in the real DW project case studies.
Generally, model checkers are used to verify the correctness of the software systems at the design stage.The correctness of a software system is verified according to the system's properties that must be a model-checked.System properties in the RAMEPs are the DW components (i.e.facts, dimensions, measures, business rules, measures) as defined from the goal-oriented analysis.The method proposed by Ogawa, Kumeno and Honiden (2008) was adopted to validate the DW components by using compliant tools (DW-Tool and Protégé-OWL).This method was chosen because it uses-goal oriented requirement analysis for formal presentation of the software properties.Moreover, the validation of properties is focused on the sufficiency of design against requirements, which is similar to our objectives.However, our approach is based on the Tropos model that emphasises the goal and resources that describe the DW characteristics.The model checking process and tools are illustrated in Figure 13.
In the checking method, the compliant tools are used to ensure the DW components are properly captured from one model to the next model.For examples, the goals, facts, and attributes in the organizational modelling correctly support the goals, facts, dimensions, and measures in the decisional modelling.These DW components in the decisional modelling correctly support the developer modelling.The complete DW requirements are modelled as ontology and rechecked for their correctness as ontology structure by using the Pallet ontology reasoner.Since the DW-Tool (Giorgini, Rizzi & Garzetti, 2008) does not support data transformation analysis as required for the ETL processes, a transformation analysis (TA-Tool) was developed to provide the data transformation diagram used in developer modelling.
approach is based on the Tropos model that emphasises the goal and resources that describe the DW characteristics.The model checking process and tools are illustrated in Figure 13.
In the checking method, the compliant tools are used to ensure the DW components are properly captured from one model to the next model.For examples, the goals, facts, and attributes in the organizational modelling correctly support the goals, facts, dimensions, and measures in the decisional modelling.These DW components in the decisional modelling correctly support the developer modelling.The complete DW requirements are modelled as ontology and rechecked for their correctness as ontology structure by using the Pallet ontology reasoner.Since the DW-Tool (Giorgini, Rizzi & Garzetti, 2008) does not support data transformation analysis as required for the ETL processes, a transformation analysis (TA-Tool) was developed to provide the data transformation diagram used in developer modelling.

Model Checking Example for Goal Modelling
In the organizational modelling phase, the goal cannot be updated in the fact definition.Furthermore, the facts also cannot be updated in the dimension definition.The DW-Tool will ensure the goals only can be inserted or updated within the goal definition area as shown in Figure 14.The grey area of goal description explains the checking mechanism of the model correctness.This principle applies for all phases of modelling to avoid inconsistency among

Model Checking Example for Goal Modeling
In the organizational modelling phase, the goal cannot be updated in the fact definition.Furthermore, the facts also cannot be updated in the dimension definition.The DW-Tool will ensure the goals only can be inserted or updated within the goal definition area as shown in Figure 14.The grey area of goal description explains the checking mechanism of the model correctness.This principle applies for all phases of modelling to avoid inconsistency among the diagrams produced by the DW-Tool.The goal diagram in the DW-Tool is stored in XML and helps the developer to add new diagrams as proposed for the data transformation analysis.the diagrams produced by the DW-Tool.The goal diagram in the DW-Tool is stored in XML and helps the developer to add new diagrams as proposed for the data transformation analysis.In the organizational modelling phase, the goal cannot be updated in the fact defin facts also cannot be updated in the dimension definition.The DW-Tool will ensur inserted or updated within the goal definition area as shown in Figure 14.T description explains the checking mechanism of the model correctness.This p phases of modelling to avoid inconsistency among the diagrams produced by t diagram in the DW-Tool is stored in XML and helps the developer to add new di the data transformation analysis.The ontology model is validated by using the Pellet reasoner.The Pellet reasoner is a complete protege-OWL checker, which is based on DL formalism.The current Pellet reasoner, which comes together with the protégé-OWL has an ability to validate the RDF/OWL-based ontology model by executing the following functions (Sirin, Parsia, Grau, Kalyanpur & Katz, 2007): • Consistency checking -ensures the ontologyis free from any contradictory facts such as type property-value, equality and inequality assertion.

•
Concept satisfiability -checks whether the classes should have any instance or not.

•
Classification -computes the subclasses' relations between every named class to create the complete class hierarchy.

•
Realization -find the most specific classes that belong to a specific individual.
In protégé-OWL, the Pellet reasoner has integrated with the OWL editor for easy use by the developer.By invoking the Pellet reasoner, the ontology model is checked for correctness and consistency.As a result, the representation of the ETL processes semantic through ontology is validated and shown as an inferred ontology.Any incorrect classes, properties, and axioms are highlighted in red color and can be fixed instantly.Therefore, the usefulness of the RAMEPs approach depend on the correctness of the ETL processes specifications that are produced from the correctness of the ontology structure.
Additionally, consistency checking is used to ensure that the ontology class, properties, relationships, and formal ontology definitions are free from any contradictory facts.For example, the consistency for the existing class name while creating a newly class CUSTOMER is checked as shown in Figure 15.

Expert Reviews
The Expert reviews were conducted to clarify the strengths and weaknesses of the RAMEPs.The review process is based on the Gas Malaysia case study and has adopted the method that focuses on the evaluation of the requirement engineering methodology.This method is known as an exemplar and has been proven in evaluating the software requirement engineering approach (Cysneiros, Werneck, & Yu, 2004).A set of questionnaires together with the case study was disseminated to seven DW developers, of whom four are from government agencies, and the others from DW companies.Their experiences are within the range of three to seventeen years in developing and implementing the DW systems in various organizations.
The questionnaires were designed and accommodated within the scope of the RAMEPs and aimed to highlight the issues of the abstraction level, participants in a domain, understanding terminology, requirement elicitation and analysis, the DW and the ETL design decision, DW evaluation and evolution, the tool used and the learning curve.The questionnaire was designed in order to capture feedback about the RAMEPs processes within the knowledge scales of yes, no, and neutral.This scale was enough to probe the capabilities and limitations of the RAMEPs methodology by supporting of the open-ended real-world exemplar.Additionally, briefings and explanations about the RAMEPs were given to the experts on separate occasions.Based on their knowledge and experiences, the experts responded to the questionnaires as shown in Table 8.Based on the feedback, the experts generally agree that the RAMEPs can be implemented by using proper tools and going through proper learning exercises.
This finding is indicated by the higher number of Yes for questions 1 to 9 that explain about the ETL processes design and the lower number of No for question 11 to 13 that explain the RAMEPs learning process.Specifically, the feedbacks for finding requirements, the ETL processes design, tool supports, and the learning curve are illustrated in Figure 16, Figure 17, Figure 18, and Figure 19 respectively.
The implementation in the real environment will be challenging because of the complexity of the DW model and requires longer time for learning the RAMEPs.Nevertheless, the RAMEPs approach enables the DW developers to model the DW system from the early phases to the generation of the ETL processes, which currently no specific tools have supported.
However, the RAMEPs has facilitated most of the important activities in the DW system development, especially in the ETL processes design.The implementation in the real environment will be challenging because of the complexity of the DW model and requires longer time for learning the RAMEPs.Nevertheless, the RAMEPs approach enables the DW developers to model the DW system from the early phases to the generation of the ETL processes, which currently no specific tools have supported.However, the RAMEPs has facilitated most of the important activities in the DW system development, especially in the ETL processes design.

ANALYSIS OF RESULTS
The results have shown that the ETL processes specifications can be derived from the early stages of user requirements.The ETL processes specification represents the data transformation of utility billing for producing the information of Sale Volume and Revenue and Billing and Customer Status.The ETL processes specification can be further translated into SQL statements or applied to any ETL tool for the DW system implementation.However, it is out of the scope of this paper.The sequence of the ETL processes executions follow the results as produced in the generation process.Therefore, the execution order may not necessarily follow the sequences of the ETL processes activities.However, the best practices still depend to the developer efforts, experiences, and knowledge.
Importantly, by properly analysing the requirements within the organization, decision-maker, and developer perspectives, the main components of the ETL processes were successfully captured.This is shown in the Gas Malaysia case study.The DW experts have reviewed the RAMEPs and positively support the method to be implemented in the real DW environment.Most of the experts believe that the The implementation in the real environment will be challenging because of the complexity of the DW model and requires longer time for learning the RAMEPs.Nevertheless, the RAMEPs approach enables the DW developers to model the DW system from the early phases to the generation of the ETL processes, which currently no specific tools have supported.However, the RAMEPs has facilitated most of the important activities in the DW system development, especially in the ETL processes design.

ANALYSIS OF RESULTS
The results have shown that the ETL processes specifications can be derived from the early stages of user requirements.The ETL processes specification represents the data transformation of utility billing for producing the information of Sale Volume and Revenue and Billing and Customer Status.The ETL processes specification can be further translated into SQL statements or applied to any ETL tool for the DW system implementation.However, it is out of the scope of this paper.The sequence of the ETL processes executions follow the results as produced in the generation process.Therefore, the execution order may not necessarily follow the sequences of the ETL processes activities.However, the best practices still depend to the developer efforts, experiences, and knowledge.
Importantly, by properly analysing the requirements within the organization, decision-maker, and developer perspectives, the main components of the ETL processes were successfully captured.This is shown in the Gas Malaysia case study.The DW experts have reviewed the RAMEPs and positively support the method to be implemented in the real DW environment.Most of the experts believe that the The implementation in the real environment will be challenging because of the complexity of the DW model and requires longer time for learning the RAMEPs.Nevertheless, the RAMEPs approach enables the DW developers to model the DW system from the early phases to the generation of the ETL processes, which currently no specific tools have supported.However, the RAMEPs has facilitated most of the important activities in the DW system development, especially in the ETL processes design.

ANALYSIS OF RESULTS
The results have shown that the ETL processes specifications can be derived from the early stages of user requirements.The ETL processes specification represents the data transformation of utility billing for producing the information of Sale Volume and Revenue and Billing and Customer Status.The ETL processes specification can be further translated into SQL statements or applied to any ETL tool for the DW system implementation.However, it is out of the scope of this paper.The sequence of the ETL processes executions follow the results as produced in the generation process.Therefore, the execution order may not necessarily follow the sequences of the ETL processes activities.However, the best practices still depend to the developer efforts, experiences, and knowledge.
Importantly, by properly analysing the requirements within the organization, decision-maker, and developer perspectives, the main components of the ETL processes were successfully captured.This is shown in the Gas Malaysia case study.The DW experts have reviewed the RAMEPs and positively support the method to be implemented in the real DW environment.Most of the experts believe that the The implementation in the real environment will be challenging because of the complexity of the DW model and requires longer time for learning the RAMEPs.Nevertheless, the RAMEPs approach enables the DW developers to model the DW system from the early phases to the generation of the ETL processes, which currently no specific tools have supported.However, the RAMEPs has facilitated most of the important activities in the DW system development, especially in the ETL processes design.

ANALYSIS OF RESULTS
The results have shown that the ETL processes specifications can be derived from the early stages of user requirements.The ETL processes specification represents the data transformation of utility billing for producing the information of Sale Volume and Revenue and Billing and Customer Status.The ETL processes specification can be further translated into SQL statements or applied to any ETL tool for the DW system implementation.However, it is out of the scope of this paper.The sequence of the ETL processes executions follow the results as produced in the generation process.Therefore, the execution order may not necessarily follow the sequences of the ETL processes activities.However, the best practices still depend to the developer efforts, experiences, and knowledge.
Importantly, by properly analysing the requirements within the organization, decision-maker, and developer perspectives, the main components of the ETL processes were successfully captured.This is shown in the Gas Malaysia case study.The DW experts have reviewed the RAMEPs and positively support the method to be implemented in the real DW environment.Most of the experts believe that the system development.The methodology used in analysing the user requirements has been validated by the compliant tools (i.e.DW-Tool and Protégé-OWL) successfully.The evaluation approach was carried out by implementing the RAMEPs into the Gas Malaysia DW system.The DW experts have reviewed the RAMEPs and certainly support the method to be implemented in the real DW environment by using proper tools and training.By adopting this method, the developers can define clearly the ETL processes activities prior to the detailed design of the DW system.This can accelerate the implementation of the DW systems.Furthermore, the goal and ontology paradigm had helped a developer to resolve user requirements ambiguity and semantic heterogeneity problems during data integration and transformation.Thus, the ETL processes specifications can be easily generated and implemented.

Figure 3 .
Figure 3. Sale Volume and Revenue Fact

Figure 4 .
Figure 4. Customer and Billing Status Fact

Figure 6 .
Figure 6.Customer and Billing Status Measure on the business rules given, the transformation analysis can be carried out for conceptualizing the actions to be taken for transforming data sources to the DW.The transformation analysis emphasized on the achievement of the ETL processes model for user requirements and required business rules to absorb the complexity of the data sources.Based on the extended goal diagram of the BM, the actions for Total Customers and Total Consumption for Sale Volume and Revenue goal are presented in Figure7.The actions for Count Total Customer Billing and Count Total Customer Status for Customer and Billing Status are presented in Figure 8.

Figure 7 .
Figure 7. Sale Volume and Revenue Actions

Figure 8 .
Figure 8. Customer and Billing Status Actions The DW components used to construct the DWRO are based on the ontology model(Ta'a et al., 2010):dimensions (D 1 , D 2 , D 3 , ….D n ) M = Set of measures (M 1 , M 2 , M 3 , ……M n ) Br = Setof business Rules (Br 1 , Br 2 , Br 3 , …..Br n ) Ac = Set of actions (Ac 1 , Ac 2 , Ac 3 , ….Ac n ) Based on DWRO, the four classes of measures have been identified as Total Customer, Total Consumption, Total Customer Status, and Total Customer Billing.Each of the classes contains properties such as account number, customer type, supply type, gas consume, cost billing, billing mode, and customer status.The relationship between the classes and the properties are defined as has Measure Total Customer, has Measure Sum Consumption, has Action Count Customer, has Action Sum Consumption, and so on.Additionally, the axioms are defined based on business rules (e.g.Only Spot and Prepaid Billing) and actions (e.g.aggregation -SUM for usage of gas in volume).The ontology model for data sources UBIS and JDE is constructed based on the ontology model(Shen, Huang, Zhu & Zhao, 2006):DSO = (C,R, A, I) Where: C = Finite set of concepts in the domain R = Set of relations between concepts.A = Set of axioms imply in property of concepts.I = Instance of the concept that presents the values of the ontology tuple.

Figure 9 .
Figure 9.The MRO for Gas Malaysia

Figure 9 .
Figure 9.The MRO for Gas Malaysia

Figure 12 .
Figure 12.The ETL Processes Specification

Figure 12 .
Figure 12.The ETL Processes Specification

Figure 13 .
Figure 13.Model Checking Process and Compliant Tools

Figure 14 .
Figure 14.Goal Model Checking for Consistency

Figure 14 .
Figure 14.Goal Model Checking for Consistency Figure 15.Consistency Ch

Figure
Figure 16.Finding Requirements Figure 17.ETL Processes Design

Table 1
Outcomes of the Modelling

Table 2
OWL Features and Ontology Notations

Table 3
Description of New Classes for ETL Processes

Table 3
List of Business Rules

Table 4 . 8
Based on the business rules given, the transformation analys actions to be taken for transforming data sources to the DW. the achievement of the ETL processes model for user require the complexity of the data sources.Based on the extended g Customers and Total Consumption for Sale Volume and R actions for Count Total Customer Billing and Count Total Status are presented in Figure8.

Table 4
DWRO and DSO Mapping for Sale Volume and Revenue 8 le Volume and Revenue goal are presented in Figure7.The and Count Total Customer Status for Customer and Billing tions Figure 8. Customer and Billing Status Actions Classes (i.e.Sale Volume and Revenue, Customer and Billing Status) • Relationship = Properties (e.g. has Measure Total Customer, has Dimension Customer Type, has Action Count Customer) • Specific element in DW setting = new Classes (e.g.SUM, COUNT) • The restriction = Axioms (e.g."Only for Spot and Prepaid Billing")

Table 5
DWRO and DSO Mapping for Sale Volume and Revenue

Table 6
New Classes and Properties

Table 7
Ontology Merging Setting for Sale Volume and Revenue

Table 8
The Summary of DW Expert Reviews