Decision Support Systems' Knowledge Bases
Once the concept and purpose of a DSS (decision support system) has been established, one must build a knowledge base (KB) from which to glean the information needed by applying processes.
Where to get this information? All over. People tend to run right to the Internet for the knowledge base, but the problem is that this is a single source (and one the decision maker could probably go to directly) – and the quality and veracity of the information is often doubtful.
I have used all kinds of information for a DSS, depending on its nature and purpose. One starts with the decision-maker’s normal avenue of information. But a good developer tries to find other sources as well.
Some sources of knowledge:
- personal interviews with involved people (this usually results in history information and information more valued in processes)
- manufacturers’ inventory databases
- real estate Multiple Listing Systems (MLS)
- libraries
- Chamber of Commerce
- Internet historical sites
- Human Resource Dept. records
- Accounting Dept. records
- Internal (company confidential) records
- Build-your-own-product WWW sites, as for cars, real estate and computers
In other words, find any sources related to the decision to be made. If a group of employees wants a DSS to help them decide where to have the Friday lunch each week, the developer would amass menus and prices from nearby eateries, and route to them, employee favorites (perhaps one of them never eats Mexican, or there has to be vegetarian meals available).
As the knowledge is amassed, it should all be pulled together into a single database, which could be a bunch of tables in Access or a collection of worksheets in Excel, set up in database format (row 1 is the field names, no blank columns or rows).
An example of a high-end DSS might be a LINK trainer – a flight simulator for pilots. While inside the trainer, the pilot sees the instrumentation and views through the window of an airplane. The pilot’s movements with the instruments (wheels, flaps, rudder, etc.) give input to the DSS, which in turn determines what would actually occur in real life, then simulates the same to the pilot. The pilot must then make a decision of what the next move would be.
One of the toughest problems is the Mars-vs-Venus problem – having the decision maker ask the questions so that the DSS can understand them, and having the DSS return answers in a way the decision maker can understand. For this reason, many DSSs are actually built for a particular person, or are so user-friendly that confusion is not a problem.
An example of a computer acquiring knowledge on its own – Web spiders. A Web spider is a program that is constantly running, wandering all over the World Wide Web, and collecting key words and URLs to add to a search engine database. If I remember right, AltaVista is a Web spider. A data mining company might design a spider to find particular subject matter. This is the concept behind copyright infringement monitors.
There are many more examples of this principle – collecting series of tips from newsletters into electronic documents; the use of a Microsoft Word Table of Contents to go directly to a page on the topic of interest, etc.
When I develop a database application for an organization, I also develop standard queries and reports. I then, usually over time and based on questions called into my office, develop queries the client can modify to handle ad hoc instances using the existing knowledge base.
Development of rules and modules takes a rather sophisticated user. Rules can be created in DBMSs (database management systems), spreadsheets, just about any application software. People are most familiar with rules in e-mail packages (“if the name of the sender is ‘big savings’, delete without opening”). Most rules are more familiarly known as macros; they can go further and can be modules (which are coded directly).
An example of a “problem processor” – a qualitative analysis system:
- Test for pH
- If pH is acid, start acidic run of tests
- If pH is alkaline, start lye tests
- If pH is acid, and there is a presence of sulfur…
- etc.
In this instance, the result of one test opens the avenue for the next test. By defining these decisions, choices and avenues, the developer can determine what information should be included in the knowledge base.
