You are on page 1of 6

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

Conceptual Design Process Model for Executive Information System Data Store: A Communication-Driven Perspective
Ifiok J. Udo, Babajide S. Afolabi and Bernard I. Akhigbe
AbstractConceptual 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 proposed to easily communicate by way of feedback, the changing business requirements which may arise as a result of unforeseen influence 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

1 INTRODUCTION

XECUTIVE Information System (EIS) is a kind of Information System (IS) designed to provide a summary of information for executives and decision makers in an organization. According to [1], EIS is a system 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 facilitating decision makers in the process of making right decisions 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, subjectoriented, 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

I.J. Udo is with the Information Storage and Retrieval Group, Department of Computer Science and Engineering, Obafemi Awolowo University, IleIfe, 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. 2012 JCSE www.Journalcse.co.uk

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 summarizing the data in its store. The summarized data can therefore be used for analyses, planning as well as reacting to the changing business needs which may be due to unforseen influences on business transactions. Nevertheless, the decision maker can take advantage of instant reaction and adaptability to changing business needs and unforeseen influence factors on business to compete favourably with others. The availability of just-in-time information which supports business competitiveness is potdue to adequate and timely analysis of the stored EIS data. Therefore, EIS data store must be designed to minimize 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 executives) because of a well designed EIS data store; among others, is the provision of a more flexible infrastructure to support efficient and accurate responses to complex queries than operational databases. In Information System (IS), where every components of the organization 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 basis of its classification. Typically, IS are classified as follows: Transaction Processing System (TPS), Management Information System (MIS), Decision Support System

10

(DSS), Communication and Collaboration System (CCS), Executive Information Sytem (EIS) and Office Automation System. However, EIS data store being a component of complex IS which aid executives and decision makers in decision 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 conceptual level for correctness, clarity and adaptability. Therefore, 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 research community is not paying much attention to developing 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. Consequently, 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 wellestablished conceptual design method for multidimensional 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 Processing (OLAP) tools approach and mixed approaches. These approaches have either failed to address the user requirements or the data sources purposively in a conceptual 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 conceptual level (otherwise called conceptual design process model) for EIS data store is discussed. This is driven by efficient communication paths among various stakeholders such as designers, decision makers, system owners and end-users. As a result, changing business requirements are easily accommodated without resort to building a new system. Apart from the changing business requirements, unforeseen influence factors such as the people involved, the orientation and the purpose of the system, 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 reconciliation of conflicting requirements at the early stage of systems 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 follows: Section 2 presents the overview of EIS data store, and section 3 the related approaches on multidimensional design that is subsumed; and the proposed communication-driven process model and the analysis of each steps that is involved in the process model are discussed in section 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 performed 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 processing systems and data marts. For such a complex Information 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, conflicting 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 conceptual models and methods for designing a data store that supports EIS, Business Intelligence and Online Analytical Processing (OLAP) applications. These models and methods 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 Model (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 design.

3.1 Multidimensional Design The multidimensional concept apart from being beyond the scope of this paper is also not relevant at the conceptual phase of our design process model. The reason for its exclusion is to avoid the confusion that often arises between designers and users during requirements definition and validation. But it is important to understand the fact that EIS data store is built on multidimensional models. The previous approaches to multidimensional designs differed from a designer to another, thus it can be classified 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 integration. This approach brings to the fore, ExtractionTransformation-Loading (ETL) [19] process. The drawback of this approach apart from the fact that user requirements 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 systems, 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 requirements and data from different source systems into consideration in the design stage. This approach is comprehensive. This is because the DW quality can be guaranteed. 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 requirements 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 designers and stakeholder. This is because system users may not understand the concepts of multidimensionality while defining requirements. Similarly, data sources confrontation 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 implementation level details. For instance, in a classical database 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 processing systems, data marts and user requirements as illustrated in Figure 1. This paper stresses a process model 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 conceptual design of EIS data store. According to [8], an important part of any communication 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 information flow during the conceptual design process to achieve accuracy, clarity and adaptability. It also increases 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 multidimensional design approach that takes into consideration 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.

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 business organization.

4.1 Analysis of the Proposed Process Model The communication-driven conceptual process makes use of data from different source systems and user requirements. 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 prototyping; 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 various stakeholders of the system to efficiently communicate. This communication is necessary during the design process at different levels of the processes. The description of conceptual processes is further expatiated and presented 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 statement for conceptual modelling. The designer and various stakeholders participate through requirements prototyping system. The purpose is to perform requirements analysis on the collected requirements, and turning it into business requirement statement which is used for initial conceptual modeling. The conceptual modelling is performed 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 resulted from business requirement statement and database schema(s) from different source systems. It checks for correctness, and reconciles data sources and user requirements. It also performs multidimensional modeling using any of the conceptual multidimensional Meta models (e.g. UML, StarER, DFM, MultiDimER etc). These models are capable of addressing temporal and nontemporal dimensions alike. The multidimensional model is therefore enriched and later transformed to suit the logical design phase of system design. However, the discussion on the logical design phase is beyond the scope of this paper.
Fig. 2. Diagram of a communication-driven conceptual process model for EIS data store

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

Executives: These are the people that decide and strategically 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 requirements gathering techniques such as interviews, Joint Application Design (JAD) sessions. They study existing reports and observation of events in decision makers environment and collect every needed information requirements 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 refined 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 business 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 detailed level of modelling internal relationships of different actors in the system. A prototype of the information requirements is developed by providing an interface to system users, owners and designers alike to communicate requirements more efficiently. The interface which interacts with the database of entities and existing relations between them are meant to present collected and analyzed 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 requirements unambiguously to decision makers. This usually 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, multidimensional 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 integration 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. These 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, dimensions, measures and fact-dimension relationship. Hierarchical dimensions are also defined at this point. This object can be suitably represented in conceptual multidimensional 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 validation by means of prototyping. Prototyping which is the most appropriate method of communicating requirements to stakeholders and domain experts [24] is employed. Due to this, critical business needs are expected to be well defined and clearly stated by presenting a wouldbe 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 system design. Moreover, data sources are fully integrated and reconciled at the conceptual design phase with no recourse to confusing users and owners with multidimensional terminologies. The output of this conceptual process model is most likely to undergo less change during development. As a result, overall system development time is shortened, since requirement definition and validation 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 conceptual 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 communication-driven conceptual design process in order to distinctly balance the needs of system users as well as data from different source systems. Moreover, the communication channel among the designers and various stakeholders of the system allows for conflicting requirements to be settled. Hence, confusion that often arises from mixing multidimensional concepts with user requirement is minimized. 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] [2] A. Cornford, Computer-based information systems Undergraduate study in Economics, Management, Finance and the Social Sciences. London School of Economics, University of London, 2001. W. H. Inmon, Building the Data Warehouse. 3rd edition, QED Press: John Wiley, 2002.

14

[3] [4] [5] [6]

[7]

[8] [9] [10] [11]

[12]

[13]

[14] [15]

[16] [17] [18]

[19] [20] [21] [22]

[23] [24]

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. T. Halpin, Object-Role Modeling (ORM/NIAM"), Journal of Database Management. Vol. 10, no.14 pp:4-13, 1998. N. Prat, J. Akoka. & I. Comyn-Wattiau, A UML-based Data Warehouse Design Method. Decision Support System. Vol. 42, no. 3. pp:1449-1473(2006), E. Malinowski, & E. Zimanyi, Advanced Data Warehouse Design: From Conventional to Spatial and Temporal Application. SpringerVerlag, Heidelberg, 2009. F. G. Filip Designing and Building Modern Information Systems; A Series of Decisions to Be Made,Computer Science Journal of Maldova, vol. 19, no. 2, pp.119-129, 2011. 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. I. J. Udo, & B. S Afolabi, Hybrid Data Reduction Technique for Classification of Transaction Data, Journal of Computer Science and Engineering 6(2):12-16, 2011. S. Rizzi. Conceptual Modeling Solutions for the Data Warehouse, DEIS-University of Bologna, Italy, IGI global, 2009. 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. Nguyen,T. B.,Tjoa A. M. & Wagner, R.. An Object-Oriented Multidimensional Data Model for OLAP. Proceedings of International Conference on Web-Age Information Management, Shanghai, China, pp. 69-82, 2000. J. I. Akoka, Comyn-Wattiau & N. Prat, Dimension hierarchies design from UML generalizations and aggregations, Proceedings of 20th International Conference on Conceptual Modeling (ER 2001), Yokohoma, Japan, pp. 442-455, 2001. R. Kimball,. The Data Warehouse Toolkit. John Wiley & Sons Inc, USA, 1996. 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. E. Malinowski, & E. Zimanyi, Hierarchies in a Multidimensional Model: From conceptual modelling to logical representation, Data and Knowledge Engineering, vol. 59, pp. 348377, 2006. A. Abello, J. Samos, & F. Saltor, YAM2: A Multidimensional Conceptual Model Extending UML, Information Systems. vol. 3. no. 6. pp. 541567. 2006. B. Husemann, J. Lechtenborger, & G. Vossen, Conceptual Data Warehouse Design, Proceedings of 2nd International Workshop on Design and Management of Data Warehouses (DMDW 2000). Stockholm, Sweden, 6.1- 6.11, 2000. S. Lujan-Mora,. & J.Trujillo, Data Warehouse Design with UML, Ph.D Thesis, Department of Software and Computing Systems, University of Alicante, Spain, 2005. M. Jarke, M. Lenzerini, Y. Vassiliou, & Vassiliadis, P. Fundamentals of Data Warehouses, 2nd edition, Springer-Verlag, 2003. S. Chaudhuri, & U. Dayal, (1997). An Overview of Data Warehousing and OLAP technology, SIGMOD Record vol. 26, no. 1, pp. 6574. J. N. Mazon, J. Trujillo, & J. Lechtenborger, Reconciling Requirement-driven Data Warehouses with Data Sources via Multidimensional Normal Forms, Data & Knowledge Engineering vol. 63 pp. 725 751, 2007. E. Yu,. Towards Modeling and reasoning Support for Early-Phase Requirements Engineering, Proc.. 3rd IEEE International Symposium on Requirement Engineering, 226p, 1997. J. Conallen, The Role of Functional Prototyping in the Development Process. Rational Software. http//www.therationaledge.com /content/sep02/rdn.jsp, 2002.

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.

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 Communication Sciences. He is currently the team leader of Information Storage and Retrieval Group in the Department of Computer Science and

You might also like