Home Computer Science
Table of Contents:
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.
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.
FIGURE 3.1 Intelligent agent-based DSS. Source: Recreated from Ref. .
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 . 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.
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
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.
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.
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.
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.
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
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.
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.
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 . 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
TABLE 3.4 PEAS Description of the Task Environment for Student Agent
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
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.
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.
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.
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.
FIGURE 3.11 STUDENTAGENT implementation.
TABLE 3.5 Tabulation of Analytical Finding from One to Three Experiments
TABLE 3.6 Query Execution of DSS Query Using PL/SQL (Experiments 5-8)