JOURNAL OF COMPUTER SCIENCE AND ENGINEERING, VOLUME 16, ISSUE 1, NOVEMBER 2012

© 2012 JCSE www.Journalcse.co.uk

9

Conceptual Design Process Model for Executive Information System Data Store: A

Communication-Driven Perspective Ifiok J. Udo, Babajide S. Afolabi and Bernard I. Akhigbe

Abstract—Conceptual design process model for Executive Information System (EIS) data store depicts a coherent set of activities to be carried out during the early design phase of such systems. Being a complex system that supports executives in business decision making and strategic planning, it requires a well-specified design at its conceptual level to ensure clarity, accuracy and adaptability. In this paper, a presentation of conceptual design process model for EIS data store which is driven by efficient communication paths among various stakeholders such as designers, decision makers, system owners and end users is discussed. This model is also pro-posed to easily communicate by way of feedback, the changing business requirements which may arise as a result of unforeseen influ-ence factors on business transactions. Moreover, data from different source systems and user requirements are both considered and integrated in the model to allow the easy reconciliation of conflicting requirements at the early stage of system design, thus enhancing the quality of data in EIS data store.

Index Terms— Communication-driven design, Conceptual design process model, Executive Information System

—————————— u ——————————

1 INTRODUCTIONXECUTIVE Information System (EIS) is a kind of In-formation System (IS) designed to provide a sum-mary of information for executives and decision

makers in an organization. According to [1], EIS is a sys-tem that provides information to senior managers and directors. This allows the timely presentation of a wide range of information across organisational functions and hierarchies. At the appropriate level, EIS is required to support decision making at a senior executive level. While EIS is built with the aim of supporting and facilitat-ing decision makers in the process of making right deci-sions and strategic planning, data available for EIS are being extracted from its data store. A typical example of such a store is the Data Warehouse (DW). [2] defined DW as a collection of consistent, subject-oriented, integrated, time-variant, non-volatile data and the processes on them, based on available information which enables people to make decisions and predictions about the future. This definition characterized an EIS data store which is capable of performing functions such as: filtering, compressing and tracking of critical data as would be determined by the decision makers in quest of accurate information. These functions permit various analyses on data namely: trend and adhoc analysis, as well as the determination of critical success factors and key performance indicators at desired level of granularity

which are necessary for strategic business planing. The phenomenon which is known as drill-down and roll-up operations in the DW context is made possible by the multidimensional nature [3] of data in DW environment. The drill-down and roll-up operations result in summa-rizing the data in its store. The summarized data can therefore be used for analyses, planning as well as react-ing to the changing business needs which may be due to unforseen influences on business transactions. Neverthe-less, the decision maker can take advantage of instant reaction and adaptability to changing business needs and unforeseen influence factors on business to compete fa-vourably with others. The availability of just-in-time in-formation which supports business competitiveness is potdue to adequate and timely analysis of the stored EIS data. Therefore, EIS data store must be designed to mini-mize the level of frustration posed to decision makers when compared with operational databases in the course of business data analysis.

The benefits that accrue to decision makers (or the ex-ecutives) because of a well designed EIS data store; among others, is the provision of a more flexible infra-structure to support efficient and accurate responses to complex queries than operational databases. In Infor-mation System (IS), where every components of the or-ganization are captured; integrating these componenets is needful. This is necessary for the purpose of accurate and informed decision making that will enable the executive to carry out strategic planning.

However, the function (s) provided by IS form the ba-sis of its classification. Typically, IS are classified as fol-lows: Transaction Processing System (TPS), Management Information System (MIS), Decision Support System

E

———————————————— • I.J. Udo is with the Information Storage and Retrieval Group, Department

of Computer Science and Engineering, Obafemi Awolowo University, Ile-Ife, Nigeria.

• B.S. Afolabi. is with the Department of Computer Science and Engineering, Obafemi Awolowo University, Ile-Ife, Nigeria.

• B.I. Akhigbe is with the Department of Computer Science and Engineering, Obafemi Awolowo University, Ile-Ife, Nigeria.

10

(DSS), Communication and Collaboration System (CCS), Executive Information Sytem (EIS) and Office Automa-tion System.

However, EIS data store being a component of com-plex IS which aid executives and decision makers in deci-sion making requires a well-specified design process model. This is particularly necessary at the conceptual level, so as to ensure clarity, accuracy and adaptability during the design stage of its developments. According to [4], Information Systems are best specified at the concep-tual level for correctness, clarity and adaptability. There-fore, the conceptual design process model for EIS data store depicts a well-specified coherent set of activities to be carried out during the early design (i.e. conceptual) phase of such systems.

The major problem facing EIS data store is that the re-search community is not paying much attention to devel-oping complete design methods for data warehouses. Generally, there is no conceptual design in particular to cope with the challenge of unforeseen influence factors that can cause business requirements to change. Conse-quently, DWs lack a widely accepted design method that covers all the necessary design steps and the contents of each of the design levels [5]. Hence, there is no well-established conceptual design method for multidimen-sional data [6].

Therefore, in an effort to achieve a well-established conceptual design methods and models, some authors [5, 6] have invented many approaches to DW design. These approaches are requirements-driven (otherwise called top-down or demand-driven), data-driven (otherwise called bottom-up or supply-driven), Online Analtical Pro-cessing (OLAP) tools approach and mixed approaches. These approaches have either failed to address the user requirements or the data sources purposively in a concep-tual design phase. With adequate feedback measures; system users, designers and system owners are able to enhance communication with clarity, correctness and adaptability. Quite unlike the existing software process models that specify the overall software development process; the presentation of a detailed design process alone at the con-ceptual level (otherwise called conceptual design process model) for EIS data store is discussed. This is driven by efficient communication paths among various stakehold-ers such as designers, decision makers, system owners and end-users. As a result, changing business require-ments are easily accommodated without resort to build-ing a new system. Apart from the changing business re-quirements, unforeseen influence factors such as the peo-ple involved, the orientation and the purpose of the sys-tem, the organisational content, standards utilized, and so on [7]; may need to be adapted to the designed system. Moreover, data from different source systems such as data marts and transaction processing systems, and user requirements are both considered and integrated at this process model level. This is meant to give room for recon-ciliation of conflicting requirements at the early stage of system’s development, thus improving the quality of data in EIS data store. This paper succinctly argues that the EIS data store is most adequate when user requirements and data sources are both integrated during the early design

phase of system development. Otherwise building the system on either data from different source systems or user requirements alone as it was the practice in the past, is not commendable.

The remaining part of this paper is organized as fol-lows: Section 2 presents the overview of EIS data store, and section 3 the related approaches on multidimensional design that is subsumed; and the proposed communica-tion-driven process model and the analysis of each steps that is involved in the process model are discussed in sec-tion 4. The conclusion is drawn in section 5.

2 OVERVIEW OF EIS DATA STORE According to [8], EIS provides summary information for the executives and decision makers, using data that is automatically extracted from a data store e.g. DW. The EIS data store contains data extracted from different transaction processing systems [9] and user requirements as illustrated in Figure 1. A characteristic feature of the data in EIS data store is its multidimensional nature. This permits the drill-down and roll-up operations to be per-formed on these data. These operations allow critical data in EIS data store to be filtered, compressed and tracked as would be desired by decision-makers. According to [3], multidimensional data is defined as a function of fact, dimension, measures and fact-dimension.

While EIS applications make use of data extracted from data store, the EIS data store is fed with data obtained from different source systems such as transaction pro-cessing systems and data marts. For such a complex In-formation System to meet the needs of its users, it is also necessary to design the system with user requirements taken into consideration at the early design stage. Apart from striving to meet the overall needs of its users, con-flicting requirements would also be reconciled easily.

Fig. 1. Diagram showing the overview of EIS data store

3 RELATED LITERATURE Many authors [5, 6] in the pasts, have presented concep-tual models and methods for designing a data store that supports EIS, Business Intelligence and Online Analytical Processing (OLAP) applications. These models and meth-ods are proposed to either provide a graphical solution to modelling multidimensional data or series of steps that can be adopted during the design process of EIS data

11

store. According to [10], conceptual models are used for design to provide a graphical support that can be easily understood by designers and users alike when discussing and validating requirements. These models include among others, Dimension Fact Model (DFM) [11], Unified Modeling Language (UML) [12, 13], Entity Relation Mod-el (ERD) and it extensions (e.g. StarER [14, 15], Snowflake, and MultDimER [16]), Yet Another Multidimensional Model (YAM2) [17], and model without explicit model as well as Adhoc models [18]. Similarly, the design methods such as classical database design approach that comprises conceptual, logical and physical phases have been studied and adopted by many designers of the pasts in an effort to develop a well-specified method for EIS data store de-sign.

3.1 Multidimensional Design The multidimensional concept apart from being beyond the scope of this paper is also not relevant at the concep-tual phase of our design process model. The reason for its exclusion is to avoid the confusion that often arises be-tween designers and users during requirements defini-tion and validation. But it is important to understand the fact that EIS data store is built on multidimensional mod-els. The previous approaches to multidimensional designs differed from a designer to another, thus it can be classi-fied into four basic approaches. These approaches are data-driven, requirement-driven, mixed approaches and Online Analytical Processing (OLAP) tool approach.

3.1.1Data-driven approach This is otherwise called the bottom-up approach of DW design. The designers consider the different data sources such as operational databases and data marts for integra-tion. This approach brings to the fore, Extraction-Transformation-Loading (ETL) [19] process. The draw-back of this approach apart from the fact that user re-quirements are not being considered; is that the DW schemas [20] must contain exactly the existing data sources which is often times unrealistic in practice.

3.1.2 Requirement-driven approach In this approach, DW design adopts the classical database design approach which spans three levels of abstraction namely: Conceptual, logical and physical phases. It is the top-down approach to DW design that explicitly takes into account user requirements at the conceptual design phase. The approach though consists of well - defined phases does not consider data from different source sys-tems, thus resulting in low quality DW design.

3.1.3 OLAP tool approach The designers and vendors of OLAP tools [21] claim that multidimensional modelling is an intuitive and quasi -immediate process which does not need a sophisticated effort. This approach only considers designing the DW to suit existing OLAP tools. However, it has often resulted in a number of system failures due to lack of proper methods.

3.1.4 Mixed approach The mixed approach to DW design takes the user re-quirements and data from different source systems into consideration in the design stage. This approach is com-prehensive. This is because the DW quality can be guar-anteed. It is because using this approach allows the need of the system users and data from varied source systems to be balanced. The major drawback of this approach is knowing where and when to reconcile the user require-ments and data from source systems. Some authors [22] have considered the data sources confrontation at the conceptual design level, while others have proposed data integration at the physical design layer. Moreover, data source confrontation at the conceptual level often results in confusion of requirements with the non-expert design-ers and stakeholder. This is because system users may not understand the concepts of multidimensionality while defining requirements. Similarly, data sources confronta-tion at the physical level of design makes it difficult to reconcile data sources with user requirements.

4 COMMUNICATION-DRIVEN CONCEPTUAL PROCESS MODEL

This is the set of activities that can be used to describe different stages of system design at the early design phase of system development without paying attention to im-plementation level details. For instance, in a classical da-tabase design, there are three major phases of design which spans the conceptual, logical and physical design phases. In this paper, effort is geared towards presenting a conceptual design process model by making use of data from different source systems such as transaction pro-cessing systems, data marts and user requirements as illustrated in Figure 1. This paper stresses a process mod-el that can describe data in a way that is not governed by implementation level issues. It also incorporates adequate feedback measures to enhance communication among various system stakeholders. Specifically, this is in the face of changing business needs and unforeseen influence factors from the system environment during the concep-tual design of EIS data store. According to [8], an important part of any communica-tion model is feedback by which the receivers’ response is made known to the sender. Therefore, in order to achieve effective communication among various stakeholders in EIS data store design at the conceptual level, appropriate feedback mechanism is employed in the design process. The objective of the communication-driven conceptual design process model is to identify multiple streams of communication paths. It is also meant to enhance infor-mation flow during the conceptual design process to achieve accuracy, clarity and adaptability. It also increas-es the level of interaction between designers and relevant stakeholders in an enterprise so that requirements are unambiguously presented as such guard against critical business needs from being overlooked. It is pertinent not to address the multidimensional concepts at this level to avoid confusion of basic requirements of the system with

12

users who may not have expert knowledge of the design. This approach is also an enrichment of the mixed multi-dimensional design approach that takes into considera-tion the requirements of the users and data from different source systems. The diagram in Figure 2 illustrates the coherent set of activities and multiple communication paths necessary for EIS data store design.

4.1 Analysis of the Proposed Process Model The communication-driven conceptual process makes use of data from different source systems and user require-ments. This is with a view to achieving high profit margin at minimal cost, improved efficiency with minimal or no error. It consists of processes such as: analysis and proto-typing; initial conceptual modelling; correctness checking and multidimensional modelling as well as enrichment and transformation of the conceptual multidimensional model that are carried out in succession. There are four different communication paths. In these paths feedback mechanisms are incorporated to allow designers and var-ious stakeholders of the system to efficiently communi-cate. This communication is necessary during the design process at different levels of the processes. The descrip-tion of conceptual processes is further expatiated and pre-sented as follows, with the conceptual design process model addressed in two phases namely: Phase A: This phase accepts user requirements as input; performs necessary operations on it so that irrelevant, unrealistic and infeasible requirements are removed. The product of this phase is the business requirement state-ment for conceptual modelling. The designer and various stakeholders participate through requirements prototyp-ing system. The purpose is to perform requirements anal-ysis on the collected requirements, and turning it into business requirement statement which is used for initial conceptual modeling. The conceptual modelling is per-formed with a suitable conceptual Meta model e.g. UML, ERD etc. To this end, a conceptual model is obtained. Phase B: This phase accepts conceptual model and data sources from different source systems; then output an enriched and transformed multidimensional model for logical design phase. It accepts conceptual model result-ed from business requirement statement and database schema(s) from different source systems. It checks for correctness, and reconciles data sources and user re-quirements. It also performs multidimensional modeling using any of the conceptual multidimensional Meta mod-els (e.g. UML, StarER, DFM, MultiDimER etc). These models are capable of addressing temporal and non-temporal dimensions alike. The multidimensional model is therefore enriched and later transformed to suit the logical design phase of system design. However, the dis-cussion on the logical design phase is beyond the scope of this paper.

4.1.1 User requirements The requirements of users cut across all the stakeholders’ needs of the system. These stakeholders include:

System owners: These are the people that pay for the building of the system. They also set the conditions and priorities for the operating environment of the system to be functional. In some cases, system owners may or may not form the executives or decision makers for the busi-ness organization.

Fig. 2. Diagram of a communication-driven conceptual process model for EIS data store

Executives: These are the people that decide and strategi-cally plan for the successful operation of the business. They are otherwise called decision makers. Designers: The designer uses information requirement collection tools e.g. questionnaires and relevant require-ments gathering techniques such as interviews, Joint Ap-plication Design (JAD) sessions. They study existing re-ports and observation of events in decision makers’ envi-ronment and collect every needed information require-ments from both system users and owners. The designer has an expert knowledge of the system; but would not bring it to play when requirements are collected and re-fined in order to avoid confusion of terminologies with non-expert designers. End Users: The end users which form the vast majority of information workers are taken into consideration.

13

4.1.2 Analysis/ prototyping phase In analyzing the collected requirements, a goal-oriented approach [22] is preferred. This allows the business goal to be specified in relation to decision makers. The busi-ness goals which are categorized in hierarchical form comprise strategic, decision and information goals. These may be represented with adequate flowcharting tool e.g. i* framework [23]. A database of entities can be generated from the semantics of resulting models. The resulting models of i* framework are Strategic Rationale (SR) and Strategic Dependency (SD) models which provides a de-tailed level of modelling internal relationships of different actors in the system. A prototype of the information re-quirements is developed by providing an interface to sys-tem users, owners and designers alike to communicate requirements more efficiently. The interface which inter-acts with the database of entities and existing relations between them are meant to present collected and ana-lyzed requirements back to decision makers and system owners for conflicting requirements to be reconciled. The prototype interface also displays the buttons for names of entities and relationships in the generated database so that it can be updated when the need arises. These can be achieved by employing a suitable High Level Language e.g. Java, MySQL and others. The requirement prototype should be a web-based application that grants remote users the privilege to comment and communicate re-quirements unambiguously to decision makers. This usu-ally would also serve as a medium of receiving feedback from the designer. The expected outcome of this phase is a business requirement statement.

4.1.3 Conceptual modeling The designer defines the business requirement in a formal language (e.g. UML) to assess whether the requirement is measurable and attainable. At this point, multidimen-sional concepts are not defined, to enable maximal reuse of system analysis methods use in transaction systems engineering. Concepts and how they are related are major design considerations in this phase.

4.1.4 Correctness check and multidimensional modeling

To avoid errors at schema level of design during inte-gration of data from heterogeneous data sources (e.g. data marts, databases etc) and business requirement statement schema; the Data Manipulation Language (DML) and Data Definition Languages (DDL) are used to query and manipulate data in existing schemas to avoid errors. The-se errors are integrity constraint as well as poor design issues. The error check may be encapsulated in a wrapper that supports the schema transformation from database to a multidimensional environment. In a multidimensional setting, an object is defined as a function of facts, dimen-sions, measures and fact-dimension relationship. Hierar-chical dimensions are also defined at this point. This ob-ject can be suitably represented in conceptual multidi-mensional Meta model.

4.1.5 Model enrichment/ transformation The resulting multidimensional model is enriched to suit the logical multidimensional schema. This may be achieved by extending the former model. For instance, for the purpose of reverse engineering, standard UML Meta model can be extended using stereotypes, tagged values and constraints.

5. CONCLUSION The proposed feedback conceptual process design model presents the following merits over the reviewed methods and models as discussed above. These are as follows: It provides quick feedback to system users, owners and decision makers during requirement definition and vali-dation by means of prototyping. Prototyping which is the most appropriate method of communicating require-ments to stakeholders and domain experts [24] is em-ployed. Due to this, critical business needs are expected to be well defined and clearly stated by presenting a would-be scenario of the requirements to the decision makers at every step of the design process. It may be interesting to note that prototyping is not considered independently but as part of requirement analysis to cut the cost of sys-tem design. Moreover, data sources are fully integrated and reconciled at the conceptual design phase with no recourse to confusing users and owners with multidimen-sional terminologies. The output of this conceptual pro-cess model is most likely to undergo less change during development. As a result, overall system development time is shortened, since requirement definition and vali-dation based on a prototype tends to undergo less change during system development. It is obvious too that there are numerous benefits derived from paying particular attention to and adopting a communication-driven con-ceptual design process model for EIS data store design. As information system requires the best specification at conceptual level for clarity, correctness and adaptability, it behoves EIS data store as a complex information system and an integral part of modern DSS to adopt the commu-nication-driven conceptual design process in order to dis-tinctly balance the needs of system users as well as data from different source systems. Moreover, the communica-tion channel among the designers and various stakehold-ers of the system allows for conflicting requirements to be settled. Hence, confusion that often arises from mixing multidimensional concepts with user requirement is min-imized. Therefore, due to the immense benefit obtained from this approach, we are of the opinion that it should be adopted for future EIS data store design where clarity of purpose, correctness of data and adaptability cannot be compromise.

6 REFERENCES [1] A. Cornford, “Computer-based information systems” Undergraduate

study in Economics, Management, Finance and the Social Sciences. London School of Economics, University of London, 2001.

[2] W. H. Inmon, ”Building the Data Warehouse”. 3rd edition, QED Press: John Wiley, 2002.

14

[3] J. Skyt, S. Jensen, T. B. Christian and Penessen,. “Specification-based data Reduction in dimensional data warehouses” Information Systems. Vol. 33, no. 1 pp36-63, 2008.

[4] T. Halpin,” Object-Role Modeling (ORM/NIAM")”, Journal of Data-base Management. Vol. 10, no.14 pp:4-13, 1998.

[5] N. Prat, J. Akoka. & I. Comyn-Wattiau, “A UML-based Data Ware-house Design Method”. Decision Support System. Vol. 42, no. 3. pp:1449-1473(2006),

[6] E. Malinowski, & E. Zimanyi, “Advanced Data Warehouse Design: From Conventional to Spatial and Temporal Application”. Springer-Verlag, Heidelberg, 2009.

[7] F. G. Filip “Designing and Building Modern Information Sys-tems; A Series of Decisions to Be Made,”Computer Science Jour-nal of Maldova, vol. 19, no. 2, pp.119-129, 2011.

[8] W. Bussen, & M. D. Myers, “Executive Information System failure: a New Zealand case study. Journal of Information Technology. vol . 12, no. 2. pp.145-153, 1997.

[9] I. J. Udo, & B. S Afolabi, “Hybrid Data Reduction Technique for Clas-sification of Transaction Data”, Journal of Computer Science and Engi-neering 6(2):12-16, 2011.

[10] S. Rizzi. “Conceptual Modeling Solutions for the Data Warehouse”, DEIS-University of Bologna, Italy, IGI global, 2009.

[11] M. Golfarelli, & S. Rizzi, “A Methodological Framework for Data Warehouse Design”, Proceedings of 1st ACM International Workshop on Data Warehousing and OLAP (DOLAP '98), Washington DC, USA, pp. 3-9, 1998.

[12] Nguyen,T. B.,Tjoa A. M. & Wagner, R.. An Object-Oriented Multidimen-sional Data Model for OLAP. Proceedings of International Confer-ence on Web-Age Information Management, Shanghai, China, pp. 69-82, 2000.

[13] J. I. Akoka, Comyn-Wattiau & N. Prat, “Dimension hierarchies de-sign from UML generalizations and aggregations”, Proceedings of 20th International Conference on Conceptual Modeling (ER 2001), Yoko-homa, Japan, pp. 442-455, 2001.

[14] R. Kimball,. “The Data Warehouse Toolkit”. John Wiley & Sons Inc, USA, 1996.

[15] N. Tryfona, F. Busborg, & J. B. Christiansen, “starER: A Conceptual Model for Data Warehouse Design”, Proc. of the ACM International Workshop on Data warehousing and OLAP, Kansas City, Kansas, 3-8, 1999.

[16] E. Malinowski, & E. Zimanyi, “Hierarchies in a Multidimensional Model: From conceptual modelling to logical representation”, Data and Knowledge Engineering, vol. 59, pp. 348–377, 2006.

[17] A. Abello, J. Samos, & F. Saltor, “YAM2: A Multidimensional Con-ceptual Model Extending UML”, Information Systems. vol. 3. no. 6. pp. 541–567. 2006.

[18] B. Husemann, J. Lechtenborger, & G. Vossen, “Conceptual Data Warehouse Design”, Proceedings of 2nd International Workshop on De-sign and Management of Data Warehouses (DMDW 2000). Stockholm, Sweden, 6.1- 6.11, 2000.

[19] S. Lujan-Mora,. & J.Trujillo, “Data Warehouse Design with UML”, Ph.D Thesis, Department of Software and Computing Systems, University of Alicante, Spain, 2005.

[20] M. Jarke, M. Lenzerini, Y. Vassiliou, & Vassiliadis, P. “Fundamentals of Data Warehouses”, 2nd edition, Springer-Verlag, 2003.

[21] S. Chaudhuri, & U. Dayal, (1997). An Overview of Data Warehousing and OLAP technology, SIGMOD Record vol. 26, no. 1, pp. 65–74.

[22] J. N. Mazon, J. Trujillo, & J. Lechtenborger, “Reconciling Require-ment-driven Data Warehouses with Data Sources via Multidimen-sional Normal Forms”, Data & Knowledge Engineering vol. 63 pp. 725–751, 2007.

[23] E. Yu,. “Towards Modeling and reasoning Support for Early-Phase Requirements Engineering”, Proc.. 3rd IEEE International Symposium on Requirement Engineering, 226p, 1997.

[24] J. Conallen, “The Role of Functional Prototyping in the Development Process”. Rational Software. http//www.therationaledge.com /content/sep-02/rdn.jsp, 2002.

Ifiok J. Udo holds both Bachelor and Master of Science degrees in Computer Science. His research interest spans Information System design and Data mining. He has published many articles in journals of both local and international repute. Babajide S. Afolabi holds a Ph. D in Information and Communica-tion Sciences. He is currently the team leader of Information Storage and Retrieval Group in the Department of Computer Science and

Engineering, Obafemi Awolowo University, Ile-Ife, Nigeria. Bernard I. Akhigbe is a member of the Information Storage and Retrieval Group. His research interest spans Infromation retrieval and Users Satisfaction modelling.