PROBLEM IDENTIFICATION

Based on the literature review findings, it can be identified that the existing DSS framework of cognitive decision-making environment has the following challenges.

To design, develop, and implement the DSS framework, in which the following aspects are identified [31,32,48-50]:

■ To adopt user’s constraint.

■ To draft resources and content priorities.

■ To determine the unstructured requirement engineering approach.

■ To manage ambiguity of data.

■ To determine important data from a large group of data.

■ To achieve asynchronous distributed and asynchronous processing.

  • • To develop automated human knowledge decision-making tasks with less intervention of human [5,51].
  • • To develop a framework for the database-driven DSS; this is useful for customized mortality prediction [10].
  • • To organize DSS as services, continuous analytics as sendee, and affordable analytics for masses (i.e., Big Data) [13,52].
  • • To develop a hypothetical database for derived data and fuzzy databases to handle uncertain information in intelligent decision-making [9].
  • • To develop hypothetical databases and “what-if’ analysis-based algorithm to handle uncertain information in a decision-making environment [9].
  • • To achieve a database paradigm shift from relational to object-oriented data and obj ect-oriented data to AODB to meet dynamic, flexible, scalable, expandable, and managing complex data model [36,38,39,40-42,46].

The objective of the undertaken work in this chapter is hereunder:

To add cognitive decision-making mental model and in-data intelligence in the development of IDA-oriented iDSS framework by way of enhancement of the system development methodology of the traditional DSS using the MAS development paradigm fr om the database perspective for predictive analysis.

COMPARATIVE STUDY OF THE EXISTING DDS FRAMEWORK AND DATABASE MODELS

The DSS architectur e defines three modules, as shown in Figure 3.1: interface module, process module, and knowledge module. The first module contains contractor interface agent and client interface agents with the responsibility for receiving user specifications and delivering results. The processing module includes the coordinator agent with the responsibility for coordinating the various tasks that need to perform in cooperative problem solving. The last module contains a database agent, which carries the responsibility for keeping track of what data stored in the database. It provides predefined and ad hoc retrieval capabilities.

Intelligent agent-based DSS. Source

FIGURE 3.1 Intelligent agent-based DSS. Source: Recreated from Ref. [49].

The first databases were repositories of knowledge about data. That simplified the task of writing special-purpose programs for data manipulation to such an extent that in many cases, they could directly specify as queries by a naive user. Agent technology is used to develop enterprise and business modeling using agent-oriented business rules for the deontic assignment [54]. Table 3.1 shows the trends in the database solution used in research by other researchers, and it also depicts the proposed IDA data model.

PROPOSED SOLUTION

The proposed IDA for the cognitive decision-making iDSS framework is based on three-layer architecture shown in Figure 3.2. The proposed framework is expected to be capable to add cognitive decision-making mental model and in-data intelligence in the development of the iDSS framework by way of enhancement of the system development methodology of the traditional DSS to provide predictive analysis in cognitive decision-making using IDA. The first layer marked as “user directive intelligent acquisition” is acquiring the user constraints and can be supportive of retrieving autogenerated strategic information for decision-making from the agent. The second layer marked as “inherit-intelligence transmission to database” is dedicated to working for transmission of user directives with the related data

Work Done by Author

Data Model Used

Database System Used

Future Directions and Challenges

Benefit Achieved

Object-oriented database from relational database [41]

Relational and object-oriented

Conceptual

mapping

Implementing in ODBMS

Easy mapping with C#, Java

Data parallel acceleration of decision support queried [26]

Columnar Data Data- parallel model

Relational. Rapid mind

Multicore processor

Complex DSS query can be accelerated using the hardware platform celLBE and GPU

Agent-oriented enterprise modeling [54]

Agent-oriented data model

Relational database

Agent communication

Business rule implementation

Practical application of triggers [28]

Relational

SQL-99 standard

Performance, uniformity, subtle behavior of trigger

Action event

Extending trigger by example to implement reactive agents in active databases [55]

Relational model, active rules using triggers

PostgreSQL

To generate Agent by example for the resource allocation problem solving

Resource allocation

Column store as an Ш. prototyping [30]

Column-oriented relational data model

MouetDB. Clue Web 1 2

Performance

Improved performance in search engine

Query optimization in OODB [42]

OOD

OODBMS

Complexity of data

Improved performance in individual subqueries

RDB to OODB [25]

Relational and OOD

Conceptual

mapping

Implementation

Support to OOP

Query Optimization [42]

Object Oriented

OODBMS

Diversified Data

Data retrieval

Migration from RDB to OODB [43]

Relational and Object Oriented

OODBMS

Core issues are Consider

Direct and fast application pertinent object access

Xtriggers: XML database triggers [29]

Extended

XML, JAVA

Optimizing context path detection

Application of trigger on document instances and schema

Proposed IDA

Agent-oriented data modeling

OODBMS,

nonrelational

databases

Selection of nonr elational database

Easily migrate relation schema into an agent-oriented schema for cognitive decision-making in real-time scenario

in the operational database as well as AODB. These mainly take care of the creation of new data and the unique identification of decision-making in the dimension of existing data. The thud layer marked as “in-data intelligence database” is responsible for reading and writing an “in-data intelligent,” that is, data as an agent into the AODB.

Three-layered architecture of the proposed AODB-based iDSS framework

FIGURE 3.2 Three-layered architecture of the proposed AODB-based iDSS framework.

In user directive, cognitive knowledge acquisition layer acquires the cognition directives from the user. Decision makers give the input to the in-data intelligence, which specifies the future needs for decision-making. A decision maker’s cognition directive also specifies the processing methods of that data. Data aggregation, data filtration, data integration, and other processing methods are identified in general as a resource to generate meaningful information from data for prediction.

Inherit-intelligence transmission to database layer transforms the user cognition directives data into the strategic rules for decision-making [56-58] to the in-data intelligence database layer to upgrade the intelligent agent of the database. The decision-making model is presented in the next section of this chapter.

In-data IDA layer embeds the cognitions as in-data intelligence, that is, agent in the database. This in-data intelligence agent includes base data, the method to analyze and predict that data as needful for decision-making by using direction, and this in-data defined by the previous two layers as an IDA. Figure 3.3 shows the three-view architecture of the smart database agent model for cognitive decision-making using iDSS for prediction.

Three-view architecture of IDA for cognitive decision-making using i-DSS for prediction

FIGURE 3.3 Three-view architecture of IDA for cognitive decision-making using i-DSS for prediction.

Decision Maker and I-Data Engineer together define the external view. Both users are vital users to generate the conceptual schema of the IDA. Decision Maker creates the need for various decision-making situation and essential piece(s) of information to make the right decision. For example, the educational institutional head needs to decide for the admission process based on currently admitted seats. Based on the decision criteria such as number of applicants, seats vacant, and historical data, other eligibility- criteria-based result declaration by other educational institution, and the current market trends for opting the courses are considered here as decision criteria. Based on these information needs of decision-making, the user I-Data Engineer identifies the current availability of data structure and unstructured information. Then, they prepare the agent-oriented AOR modeling language to structure the decision-making information in the agent-oriented data model for decision-making. These define the conceptual schema of the AODB system.

i-Data Engineer and Database Programmer together represent logical view. This group of the users then generates a logical schema from the agent models. The logical schema defines the in-data intelligence (agent) as an embedded object using object definition language. This view also describes the acquisition methods, link between two agents, and the link between the agent and relational schema, agent, and multidimensional schema as required. The agent, in this view, is defined as an embedded object, which contains data as pieces of data for decision-making. These include decision criteria, methods to link and gather the data from different resources, and actual resources from where the base data are stored.

Database Administrator defines the physical view. This user takes care of the defined agent in the object-oriented database. Figure 3.4 shows in-data intelligence, that is, agent-oriented data model. This agent contains an object and resource, as shown in Figure 3.4. This user also looks after the storage of the embedded object in the database and manages and controls the user accessibility of data from the database.

Agent representation

FIGURE 3.4 Agent representation.

3.5.1 DATA AS AGENT (IN-DATA INTELLIGENCE)

In the proposed framework, “Agent: in-data Intelligence” defines the knowledge as a resource for decision support in the data itself. Available data modeling techniques such as on the relational model, entity-relation- ship model, an object-oriented model, and not even in the multidimensional models such as star schema and snowflake schema are not fulfilling these needs. The proposed model considers the data object along with another object as a resource. This linked embedment of data object along with resource object becomes capable of satisfying the enhanced need of decision makers. The base-data-contained data object is subject to aggregation and analytics. These objects determine the agent as in-data intelligence. In addition, this represented data as an agent in Figure 3.5. An agent is defined with the object(s) and resources (s) required to the decision maker. Object(s) defines base-data object(s) that contains the base data and methods to manipulate it. The resource(s) represents the intelligent criteria and intelligent retrieval methods for decision makers.

In-data intelligence (data as agent)

FIGURE 3.5 In-data intelligence (data as agent).

In general, a sketch of the agent is requir ed to define database data as agent from the artificial intelligence perspective. The architectural components are agent type, performance measure, environment, actuators, sensors, percepts, and action. An agent is defined as rationale agent for each possible percept sequence. A rational agent should select an activity that is expected to maximize its performance measure, based on the evidence provided by the percept sequence and whatever built-in knowledge that the agent has for predictive decision-making. The conceptual architecture is based on PEAS task description defined as a performance measure, which is an objective criterion for the success of an agent’s behavior. For example, a performance measure of a vacuum cleaner agent could be the amount of dht cleaned up, the amount of tune taken, the amount of electricity consumed, and the amount of noise generated. The second element is an “Environment,” in which the agent operates with the following main properties such as accessible/inaccessible, deterministic/nondeterministic, episodic/sequential, static/dynamic, discrete/ continuous, and single-agent/multiagent. The third is “Actuators,” which are the set of devices that the agent can use to act. For a computer, it can be a printer or a screen. The fourth is “Sensors,” which allow the agent to collect the percept sequence that uses for deliberating on the next action. Finally, the percepts refer to the agent’s perceptual inputs at any given instant. An agent’s percept sequence is the complete history of everything the agent has ever- perceived. Now, the definition of data can be proposed that data are fact and figures with intelligence by suggesting data as agent = object+ resources. In this, object defines the basic data facts and figures and its methods to manipulate. Therefore, resources define another embedded object, which describes the environmental components of the agent with the environment, performance measures, actuators, sensors, and its methods to act and percepts. Table 3.2 represents in-data intelligence according to PEAS description. Figure 3.6 depicts an in-data-intelligence of object student.

TABLE 3.2 PEAS Description of Task Environment for an In-Data Intelligence

Agent

Type

Performance

Measure

Environment

Actuators

Sensors

Student

Attendance, results, fees Payments, etc.

Student Database

Management

System

Faculty, Director, Student, display. Mobile

GPS, Cameras, Keyboard, Mobile

3.5.2 PROPOSED IDA FOR IDSS DATABASE DEVELOPMENT METHODOLOGY

In this chapter, data modeling is proposed based on an agent-oriented software engineering approach to embed intelligence into the data object. Few methodologies that are in use for agent-based system developments are, namely, MaSE (1999), GAIA (2000), MESSAGE (2001), PROMETHEUS (2002), PASSI (2002), and SOAD (2002). In this work, the AOR model is used to design the proposed IDA model (AODB model). This model is based on two submodels. An external AOR model corresponds to environment analysis to communicate among agents, that is, as a database agent object interface, and an internal AOR model corresponds to a base-object and resource-object-data design model, as shown in Figure 3.6.

Agent Object Relational Database (AORDB) model consists of an external AOR model coiTespouding to environment analysis to communicate among agents

FIGURE 3.6 Agent Object Relational Database (AORDB) model consists of an external AOR model coiTespouding to environment analysis to communicate among agents.

An internal AOR model corresponds to a base-object and resource-object- data design model. An external AODB model is the view of an external user, that is, data engineer(s)/knowledge engineer(s)/decision maker(s), who observes the agents and then' interactions in the problem environment under consideration. In this work, AODB modeling is implemented using the following database development phases.

3.5.3 PHASEI: DECISION SUPPORT DATABASE, ENVIRONMENT ANALYSIS

In this phase, the database designer has to follow the following four phases to perform and clarify the data requirement at decision support level to define the intelligence in data and its automation through object methods.

To develop a conceptual schema of agent requirement, gathering is done based on the agent architecture, as discussed in the above section. Agent- object relational modeling is used to create a general view of the agent model, which is flexible, manageable, and reusable. It is required to identify BASE OBJECT/TABLES to store and manage necessary data based on PEAS. Then, after identification of RESOURCE object, it is essential to store and automate intelligence of the base object. Determining the requirements to define agent is based on the answer of the following questions to identify architectural components of the agent as suggested in PEAS description.

  • • Identify the actuators (decision makers) are involved in that environment, who has an actual need for the decision-making based on that data object?
  • • Which performance measures are required based on that data object to take the decision?
  • • What is the environment of that data object performance measures are getting affected?
  • • What are the data objects with its attributes and the methods?
  • • What is the intelligence required to define as a resource with data object?
  • • What is the different set of rules based on that data objects and the corresponding set of actions, which are required to perform automatically based on the perception of decision makers?
  • • Which are the events of the system so that decision-supported information such as performance measure and the action report can produce for actuators, that is, decision makers? Fact-finding methods, OBSERVATION, and DOCUMENT REVIEW techniques are used to analyze day-to-day routine analytical needs. Decision-making needs cognitive information collected from university authority. Moreover, identified users are Director, Dean, Registrar, Head of Institute, HoD, faculties, and students. Higher authorities at university need decision-making information for planning, as shown in Table 3.3. This decision-making requirement is highlighted according to different stakeholders of the university. This requirement is for capacity, quality, and efficiency expansion planning for the overall development of the university. While documenting the need, it is categorized in three general organizational, managerial decision-making types, namely, high level, middle level, and lower level. All these three types belong to internal stakeholder’s category.

Next step in PHASE-I is followed to identify architectural components based on PEAS description. Table 3.4 shows the requirement determination of STUDENT agent for the university system along with its description and concepnral-type definition.

3.5.4 PHASED: IDA MODEL DESIGN

hr this phase, as a database designer’s activity, we have to develop the AORDB model, as suggested in the proposed AODB-based database development method [59]. Figure 3.7 represents that an agent can be defined through internal object type and external agents. Domestic object type contains base-data and resource-data objects.

TABLE 3.3 Strategic Requirement for Decision-making

High-Level Requirements for Decision-making

Decision-Making Needs

Cognitive Information Based on Frequency and Purpose of Decision-inaking

Year-wise number of seats approved

Every year for the last five year data to analyze the growth of university course in terms of strength

Year-wise filled seats

Every year for the previous five-year data to analyze the actual number of student enrolled in the university course in course-term of existing students

Monthly attendance analysis of students

Ever month and historical moths to analyze the attendance pattern of the institution for a particular course

Daily attendance analysis of faculty members and other staff member

Every day and all historical data for each month and a whole academic year to analyze the faculty and staff attendance pattern

Middle-Level requirements for Decision-inaking

Year-wise student wise subject performance

Every year the faculties are analyzing students passing ratio in the respective subject to get the teaching learning outcome performance

Monthly attendance analysis of students

Ever month and historical moths to explain the attendance pattern of the student to attend a particular subject that faculties are taking

Daily attendance analysis of faculty members and other staff

member

Every day and all historical data for each month and a whole academic year to analyze the faculty and staff attendance pattern

Lower Level requirement for Decision-making

Year-wise/Semester wise students’ performance

Every year the students are analyzing his/ her performance in the semester, cumulative performance, subject-wise performance to decide the specialization and improve the overall performance

Monthly attendance analysis of students

Ever month and historical moths to analyze the attendance pattern of the student to attend the particular subject that faculties are taking

Year-wise/semester wise account status/library status etc.

Every year and historical semester wise fees paid and pending installation, library dues to make the status clear.

TABLE 3.4 PEAS Description of the Task Environment for Student Agent

Architectural Components of Agent

Description

Conceptual Type

Student

Roll no, Name, address, city, contact no Add. insert, update, delete

Data Object Attributes Data Object Methods

Performance Measure

Attendance, Promoted, Grade, Placed, Library due. Accounts due. Unclear papers

Resource Object Attributes

Environment

Student Information System (database) & co-Agents

Database Platform

Actuators

Faculty, Student, Librarian, accountant. Director

Association among data objects

Percepts

Attendance Rule, Promotion Rule. Library Rule

Resource Object Class Methods

Action

Attendance Rule-based Actions Attendance 100% Send alert Send a letter to parent

Resource Object Class Methods

Sensors

Admission process, accounting process, placement process, time table, attendance entry process

Resource Object Trigger Methods

External AODB model for agent (STUDENT)

FIGURE 3.7 External AODB model for agent (STUDENT).

Ill addition, communication methods depict for message and data passing between two objects. Figure 3.8 illustrates how internal communication takes

Internal AODB model

FIGURE 3.8 Internal AODB model: sequence diagram for interagent communication.

place between agents and within the agents through a sequence diagram. The class diagram is used to represent the relation between the base-data object and resource objects. To define an agent is an aggr egation of both as shown in Figure 3.9.

Internal AODB model

FIGURE 3.9 Internal AODB model: class diagram for inter-relation between the base-data object and resource object.

3.5.5 PHASEIII: AODB MODEL IMPLEMENTATION

hi this phase, the database developer has to implement the agent as an embedded object and its programming features to automate in-data intelligence. Figure 3.10 shows algorithmic steps for iDSS Queiy with AODB-based IDA.

  • • So, which are implemented agents as an embedded data object and resource object.
  • • We have implemented triggers to provide communication between the different agents and base-data objects/tables.
  • • Implement procedures, functions, and packages to provide a data link between different agents using targeted language SQL/OQL/PL-SQL/ NoSQL.
  • 3.5.6 PHASEIV: COGNITIVE DECISION-MAKING THROUGH IDA-BASED IDSS

hi this phase, database statistics are collected based on IDA-oriented iDSS retrieval of decision-making predictive analysis. University system database’s data are collected, which consist of enrollment data, courses, curriculum, timetable, attendance, and exam records of 18,000 students. Daily 75%-80% decision-making information is needed based on these records by the internal stakeholders of the university. This database is used to develop an agent-based data model for cognitive decision-making iDSS queries.

Algorithmic steps for iDSS Query with the AODB-based IDA

FIGURE 3.10 Algorithmic steps for iDSS Query with the AODB-based IDA.

The AODB schema implements direct access to decision-making information, through in-data intelligence. In which implementation of data as embedded objects relational database model with triggers and user-defined functions to automate the processing of data and stored the decision-making information along with data. It accelerates the data retrieval capability within the DSS. Listing 1 specifies the user-defined data type (UDTs) to define the base objects and resource objects. It contains STUDENT_TYPE as an OBJECT data type to define the attributes of students and methods to generate the data for the attributes. The STUDENT_RESOURCE_TYPE as UDT to identify RESOURCE OBJECT data type to determine the decisionmaking attributes/characteristics needs techniques to create that value in the base-object.

The storage of a column objects is similar to the data storage of an equivalent set of scalar columns that collectively make up the object. The difference is the additional overhead of maintaining the atomic null values of any noncollection column objects and their embedded object attributes. These values, called “null” indicators, specify every column object. This stores whether or not the column object is null and whether or not each of its embedded object attributes is null—the STUDENT_AGENT table consisting of two objects such as STUDENTJNFO and STUDENT_RESOURCE. The STUDENT_RESOURCE column object is a nested table, a collection type of column object. The storage for each object and its embedded objects attributes occupy one bit each. Thus, an object with n embedded object attributes has a storage overhead of CEIL (и/8) bytes. There is one null indicator column for each noncollection column object STUDENT_INFO and STUDENT_RESOURCE. The “null” indicator column length is one byte, as one bit represents the object itself, which translates to CEIL (1/8) or 1. Since the null indicator is one byte in size, the overhead of “null” information for each row of the STUDENT_RESOURCE table is two bytes, one for each object column.

STUDENTJNFO rare objects store in object tables. An object table is a specific table that holds objects and provides a relational view of the attributes of those objects. An object table is logically and physically similar to a relational table whose column types correspond to the essential characteristics of the object type stored in the object table. The critical difference is that an object table can optionally contain an additional object identifier (OID) column and index.

In STUDENT_AGENT, “STUDENT_INFO.ENROLLMENTNO” is the primary-key-based OID. Oracle automatically created the OID for the STUDENT_RESOURCE row object. OIDs uniquely identify row objects in object tables. The OID cannot be accessed directly, but it can access through references (REFs). Member methods, DISPLAY_DETAILS,

GETJENROLLMENTNO, GET_ACADEMIC_FACT, and GET_LIBR_ FACT, provide an application with access to an object instances data. GET_ENROLLMENTNO is MAP method, called automatically to evaluate comparison between two object variables. These methods call by the triggers that are implemented to generate the STUDENT_RESOURCE type attributes value as in-data intelligence. In another way, this information is useful for the retrieval of decision-making.

3.5.7 POPULATING DATA STUDENT_AGENT

Three different sets of data volume have been created in the STUDENT_ AGENT based on the described implementation strategy in Figure 3.12. The first set of data is with 400 records, the second set of information is with 50,000 records/tuples, and the third set of data with the 100,000 records/tuples. The decision support query in Figure 3.11 using object query language is executed to generate the decision maker’s dashboard with visualization. The result obtained by way of implementation of earlier data models and the proposed model is filtered and tabulated in Table 3.5 for three sets of records. Table 3.5 contains the statistical data for iDSS query execution in three different data models: relational, star schema, and AODB model. Table 3.6 includes a value for execution time in seconds, memory blocks used, data volume in many records, and the level of aggregate data volume for each schema.

ID As IDA-I-IDA-IY are developed to retrieve the data from STUDENT_ AGENT. In the development of IDA-I-IDA-IV, PL/SQL features are used, such as Cursor, Stored Procedure, and Stored Procedure, using the collection to retrieve the data for query evaluation. The use of the group is required in the embedded, nested table to collect the multiple instances of the resource-data object for each base-data object instance. Table 3.6 represents the summary of query execution. It uses three different features of PL/SQL, which are a cursor, Stored Procedure, and Stored Procedure, obtained through Experiments 5-8.

The result is obtained by implementing PL/SQL features that the execution performance results are nearly similar to the SQL query performance. However, the limitation of SQL query is that only base data can retrieve. If data retrieval requires resource objects, it is necessary to implement collection hr PL/SQL. These stored procedures and functions reside on the server as part of the user’s schema. On “logon” to the database, these methods are called and executed to generate the decision-making data in the STUDENT AGENT table.

STUDENTAGENT implementation

FIGURE 3.11 STUDENTAGENT implementation.

TABLE 3.5 Tabulation of Analytical Finding from One to Three Experiments

Database Models

DV=400

DV=50,000

DV=100,000

ET

MB

ADV

ET

MB

ADV

ET

MB

ADV

Relational

0.0334

5

0

0.531

370

0

0.522

784

0

Star schema

0.0301

5

16

0.521

5

71

0.539

5

275

Proposed agent

0.012

5

0

0.014

662

0

0.016

1252

0

Oriented schema

TABLE 3.6 Query Execution of DSS Query Using PL/SQL (Experiments 5-8)

PL/SQL Features

Is Data Retrieved from Resource Object

Execution Time in Seconds (%)

Using Cursor (IDA-I)

No

0.032

Using a Stored Procedure (ША-П)

No

0.015

Using Collection in Stored Procedure

Yes

0.016

(ГОА-Ш & IDA-IY)

 
Source
< Prev   CONTENTS   Source   Next >