Chapter 4
Data Management: Warehousing, Access, and Visualization

Look at the multimedia demonstrations on the following web sites:
 

Leisureplan Multimedia Travel Decision System by Leisureplan International	http://www.leisureplan.com
Illustra Information Technologies, Inc.	http://www.illustra.com
Visual Intelligence Corp.	http://www.illustra.com
ADB-Matisse	http://www.adb.fr
RealAudio	http://www.realaudio.com

Back to the Top

Database Vendors
 

Vendor	Web Address
Cognos	http://www.cognos.com
SAP A & G	http://www.sap.com
SAS Institute	http://www.sas.com
Oracle Corp.	http://www.oracle.com
Comshare	http://www.comshare.com
Sybase, Inc.	http://www.sybase.com
IBM	http://www.ibm.com
Gentia Software Place	http://www.gentia.com
Netiva	http://www.netiva.com
Handi Links to Databases	http://www.ahandyguide.com/cat1/d/d183.htm

Back to the Top

Current Census Data

Are available from the Missouri State Census Data Center (MSCDC),
Office of Social and Economic Data Analysis, University Outreach & Extension, University of Missouri System and Lincoln University.

Also, search the Web for other sites, or, download directly from here.

These files are courtesy of the MSCDC:

Excel State Census Worksheets (zipped)

Excel MSA Census Worksheets (zipped)

Lotus State Census Worksheets (zipped)

Lotus MSA Census Worksheets (zipped)

Back to the Top

Appendix W4-A: Object-oriented Systems Analysis, Design, and Programming

W4-A.1 Introduction to the Object-oriented Approach

The object-oriented approach toward system analysis, design, and programming is a new development, although the first object-oriented programming language, Simula, was developed in 1967. The basic idea is that objects are created and manipulated, rather than 'items' in programs. The definition of a system involves items, people, things, resources, and so on-in other words, objects. Just as in real systems, in a computer system (which can be viewed as a model of a real system), everything is an object. The objects have certain features or attributes, exhibit certain behaviors, and interact. Objects can be grouped and classified, like real-world objects. Furthermore, specific objects (a person named Sharon) have certain attributes by being in a class (employees, citizens, customers, and so on).

W4-A.2 Object Think

In "object think" (for example, the object-oriented approach), the design of systems and their development takes a whole different approach, though it has many features in common with the traditional system development life cycle (SDLC). Instead of focusing on procedures and programs, the system analyst focuses on the user requirements that lead directly to the definition and subsequent development of objects. The objects have characteristics that they exhibit, and inherit characteristics directly from their class and from their "parents." For example, in a university library, there is a class of objects called Books and another class of objects called Borrowers. These classes are shown, along with what they know and what they know how to do, in Figure W4-A.1. A specific instance of a book knows its title, author, publisher, and so on. It also knows how to be borrowed and checked in; a borrower knows its ID number, phone number, how to borrow a book, how to check in a book, and so on. When an object is asked about something it does not know, it would respond with "I don't know that" or "I don't know how to do that." For example, if a book is lost and the librarian requests the price, based on the information in Figure W4-A.1, a book would not know its price. Furthermore, a borrower would not know what to do if he or she loses a book. (One hopes that the librarian would know what to do, but this object is currently undefined!) These holes in object abilities indicate that certain system requirements need to be developed. Furthermore, other objects may need to be created as they are required by the system (other subclasses of borrowable items such as magazines and videos).

W4-A.3 Important Object-oriented Approach Terminology ¹

The concepts of object, class, attributes of a class, association relationships, whole-part relationships, methods or services, encapsulation or information hiding, message sending, polymorphism, classification hierarchies and inheritance, and reuse are important to the object-oriented approach to system development.

Object An object is a thing-a specific instance-such as a book titled Gone with the Wind, a person named Michael, or a dog named Daisy. An object knows what it is and what it can do. For example, an object might be a specific book, titled The Hitchhiker's Guide to the Galaxy by Douglas Adams. It would know all the information shown in Figure W4-A.1 about itself, and it would know how to be borrowed and checked in.

Class A class is a type of thing, and all specific things that fit the general definition of the class belong to the class. It is like a data entity type when modeling data. A class is the general category and an object is a specific instance. For the library, books and borrowers are two classes. There may be other classes, subclasses, or superclasses.

Attributes of a Class The attributes that all of the objects in the class share define a class of objects. The attribute values are part of what an object knows when using the object think approach. A person knows his or her name, gender, and so on. In the library example, a book knows the information shown in Figure W4-A.1. These are equivalent to attributes of a data entity type.

Association Relationships Objects may be related to other objects. These are similar to relationships in a data model. A relationship is an association based on the context in which we view objects, or a natural association. For example, a house may have a relationship with its owner, or a book with its borrower. In the object think approach, an object knows about other objects with which it is associated or to which it is connected. These relationships clearly lead to the definitions of what data are required for different objects in a system. For example, a book must know its borrower's ID number and perhaps his or her name. As in traditional systems analysis modeling, these relationships have names, can be optional or mandatory, and have cardinality (the number of associations that naturally occur between objects, such as one to one, one to many, or many to many). For example, a borrower may borrow many books or none (optional relationship, zero to many), but a book may have either zero or one borrower (an optional relationship, or 1:1).

Whole-Part Relationships These relationships are stronger than association relationships. A whole-part relationship implies strong relationships between an object and other objects that are really its parts. For example, a book has a cover and pages. Mandatory versus optional relationships and cardinality also apply to whole-part relationships.

Methods or Services of a Class A method is something the object knows how to do. The term service is something that the object knows how to do for a requester. Often these terms are used interchangeably. These procedures are often defined using structured programming rules, so the object think approach does not imply that programming is obsolete. The programs are simply described in terms of manipulating objects. Also, they are hidden from the view of the user when specifying the system and because the basic attributes and relationships of objects are defined rather than programmed directly, it can lead to their reuse in other parts of the system or other systems (see encapsulation and reuse below).

There are standard services that all objects know how to do (from the superclass called All Objects). Standard services include adding a new object, showing information about an object, deleting an object, and changing the values of the attributes of an object. These correspond to the database operations such as add, query, delete, and update. Other standard services include connecting to another object (establishing a relationship) and disconnecting from another object (breaking a relationship). Complex services (which may actually be quite simple in nature) are those that have been custom designed for the class of objects. These are the procedures that the system developer might have to write.

Encapsulation or Information Hiding Encapsulation means packaging several items together into one unit. For object think, it involves packaging both the attributes and services of the class together so that the object knows things (attributes) and how to do things (services). This allows us to hide the internal structure of an object from the environment. It means we do not have to know how an object works to use it.

Message Sending End-users can send messages to objects to perform a service (change your title, for a book), and objects can send messages to other objects for the same purpose (if copy 1 of a specific book is deleted from the system, it can request that all other copies decrement their numbers by one). See Figure W4-A.2. These messages may be thought of as an input or an output. Messages may also be triggered temporally.

Polymorphism (Multiple Forms) There may be different kinds of items that can be borrowed from the library-books, tapes, videotapes, and magazines-each with some different characteristics, but all are in a superclass of borrowable items.

Inheritance, Classification Hierarchies, and Reuse Classification hierarchies allow classes of objects to inherit attributes from larger classes. For example, there may be student borrowers and faculty borrowers. Each class has the same attributes as the class of borrowers, but perhaps students are not allowed to borrow videotapes or, as shown in Figure W4-A.3, there are different limitations to student and faculty borrowing privileges. Classification hierarchies streamline the development process because an analyst can reuse objects and modify them to create new subclasses that inherit common properties from the larger class. For example, suppose a new class of borrower, Staff, is needed. It would inherit all the properties from the class Borrower, and some specific attributes would be added in the design phase as the system requirements are developed. This reuse is a primary benefit of the object-oriented approach to system analysis, design, and implementation. Some programming languages come with pre-defined classes of interface objects (such as, Visual Basic), thus simplifying one of the most difficult aspects of system development: the user interface (see Chapter 7).

¹Some of this material is from Satzinger and Orvik [1996].

W4-A.4 The Object-oriented System Development Cycle ²

The focus of the object-oriented approach is clearly on the definition of objects, classes, classification hierarchies, and so on. One clear advantage in this approach is that the analysis and design steps tend to be merged. The analyst works with the user to define objects based on the requirements of the system rather than on the data needs. Messages are used to define data transfer, and the notation is much simpler than that of the traditional systems approach. The conventional wisdom is to combine the traditional system development life cycle with object think to derive a modified life cycle. One recommended object-oriented life cycle involves

• Object-Oriented Analysis
• Object-Oriented Design
• Object-Oriented Implementation

The recommended approach is to define system requirements through scenarios or use cases. Then, build an object model with the ability to satisfy the requirements. The systems analyst carefully studies the user's work context and, through interviews and other research, begins building a model of the appropriate objects and classes. (Note that there are several popular modeling notations.) A prototyping approach is taken where a few classes of objects are defined with a few scenarios or use cases. State transition diagrams are also used. Sometimes, when an organization has developed an object library, the existing class library will have many or all of the attributes needed for the new system. Eventually, the models are completed and reviewed with the users, but the analysis may not be complete in that the need for new attributes or classes may be uncovered in the design phase. The output of the analysis phase is the requirement model.

Object-oriented Design

The requirement model is used to develop more physical models that show how the new system will actually be implemented. The requirement model created in the analysis phase is enhanced in the design phase. The same models and model notation are used, so the object and class definitions follow directly - no translation is needed. Sometimes more attributes and services are added. Interface objects are also added at this point. Again, class libraries are typically used to find existing objects that can be used directly in the new system.

Object-oriented Implementation

In the implementation phase, a usable system is developed. Object-oriented programming languages allow the programmer to directly create the object classes that were previously defined. These include work context object classes, as well as interface and operating environment objects. Sometimes links to a separate database management system must be provided, although a new class of object-oriented database management systems (OODBMS) is currently on the market.

Object-oriented CASE Tools

Object-oriented CASE tools (iCASE, or integrated computer-assisted software engineering) are evolving along with the object-oriented development methodologies and object-oriented programming languages. New capabilities to handle the object-oriented approach are being developed quickly.

² Some of this material is from Satzinger and Orvik [1996].

W4-A.5 Object-oriented Programming Languages

There are two kinds of object-oriented programming languages: pure and hybrid. The pure ones support and require all the object-oriented concepts, whereas the hybrid ones are typically developed as extensions of existing languages. SmallTalk is the best known pure object-oriented programming language. C++ is an object-oriented extension of the C programming language. It supports the object-oriented concepts, but also contains the entire C language. Other object-oriented languages include object-oriented COBOL (see DSS in Focus W4-A.1), Ada, Objective C, Object Pascal, Actor, Eiffel, CLOS (see Taylor [1992] for details). In February 1996, Sybase released Optima++ (Independent Development Environment),(IDE), an extension of C++ with embedded 4GL client server tools. PowerSoft Optima (bundling PowerSoft's Object Cycle) provides the first purely visual RAD environment for C++. Furthermore, it generates both ANSI-standard C++ and Java source code for World Wide Web deployment (see "C++ Made Easy," InformationWeek, Feb.5, 1996, p. 72.).
 

DSS in Focus W4-A.1 Object-oriented COBOL  Object-oriented COBOL (OO COBOL) is the familiar and popular COBOL with enhanced extensions such as objects, methods, and classes. OO COBOL is a serious alternative for corporations with large COBOL code and labor investments that want the benefits of object technology such as code reuse, modular development, and ease of maintenance. One of the most attractive features of OO COBOL-- backward compatibility for COBOL programs not using OO constructs -- may turn out to be its Achilles heel as well because this feature lets programmers develop programs not using OO constructs and thus fails to derive the associated OO benefits.  Advantages of Adopting OO COBOL  I/S organizations are unlikely to risk converting a huge COBOL install base to C++ or fourth-generation language (4GL) just to receive the benefits of object orientation. OO COBOL allows these organizations to keep their installed base and their programming skill base, and to adopt object-based development in a low-risk fashion. OO COBOL is also a good match where C++ is perceived as too complex and 4GL application development is considered more suitable for prototyping than for mission-critical application development.  Outlook for OO COBOL  On the positive side, COBOL vendors will increasingly provide support for object orientation, which will make the vendors strive for compliance and enhance COBOL's position, over other object-oriented solutions. Current COBOL users will upgrade to an object-oriented compiler by default. OO COBOL is a low-risk way to embrace object orientation, particularly for users with a large code base and programmer knowledge base. OO COBOL is a good intermediary between complex alternatives such as C++ and SmallTalk.  On the negative side, COBOL is perceived as an out-dated language and OO COBOL faces a perception barrier. With the increased popularity of client / server applications and non-programming end-users favoring software packages and visual development tools, the need for in-house software development using languages such as OO COBOL is likely to decline. The emerging trend toward using the Web for corporate Internets will favor Java and Active X. Further, the upcoming generation of programmers is far more likely to be conversant with 4GL / visual programming tools.  OO COBOL Vendors  OO COBOL is available from IBM Corp. (Armonk, NY http://www.software.ibm.com), Micro Focus Ltd. (Palo Alto, CA http://www.mfltd.co.uk/win95.html), Computer Associates International Inc. (Islandia, NY http://www.cai.com/products/vrt.htm), and Hitachi Ltd. (New York, oocobol@hitachi.com).  (Source: Condensed from R. Rajagopal, "Object-Oriented Cobol Under Consideration in I/S," Application Development Trends, Vol. 3, No. 11, Nov. 1996, pp. 47-54.)

W4.A-6 Object-oriented Database Management Systems

An object-oriented database (OODB) is an integration of object-oriented concepts combined with traditional database capabilities (Norman [1996]). Once object-oriented programming languages were developed (Simula and PS-Algol in the early 1980s), the notion of developing an OODB was conceived. Given the unique features of the object-oriented approach, combined with solution of the persistence problem (objects would disappear when an object-oriented program stopped running), the OODB became a reality. The two reasons that object think is a sound basis for database implementations are that object think can embody the relational data model and the object-oriented approach encapsulates data and programs, which enhances the understanding and development of complex systems. A set of object-oriented database management system manifesto rules was defined (see Norman [1996], p. 282). These are that the database system must

• Support complex objects
• Support object identity
• Allow objects to be encapsulated
• Support types or classes
• Support inheritance
• Avoid premature binding
• Be computationally complete
• Be extensible
• Be able to remember data locations
• Be able to manage large databases
• Accept concurrent users
• Be able to recover from hardware/software failures
• Support data query in a simple way

Strengths:

• Data modeling
• Nonhomogeneous data
• Variable length and long strings
• Complex objects
• Version control
• Schema evolution
• Equivalent objects
• Long transactions
• User benefits

• New problem-solving approach
• Lack of a common data model with a strong theoretical foundation
• Limited success stories

W4-A.7 Commercial Applications of the Object-oriented Approach

Many successful commercial applications of the Object-oriented approach are described in Taylor [1992], Chapter 12. They range in scope from enterprise information systems, maintenance management, and financial applications to geographical information systems (see Chapter 7). Among the many successes is EDS's Maintenance Management System (MMS), which was designed to help in the maintenance of machinery at General Motors. A comparison was made between a CASE-oriented traditional system development approach and the object-oriented approach. The existing MMS was written in PL/I and was 265,000 lines of source code; it took 152 staff-months to design, develop, and test it over a total of 19 months. The finished program ran in 13.6 megabytes of main memory. The object-oriented MMS was written in Smalltalk-80, consisted of 22,000 source code lines took 10.4 staff-months to develop, and was completed in 3.5 months. It required 1.1 megabytes of main memory. Overall, the object-oriented approach had a measured productivity ratio of 14:1 over the traditional approach. Furthermore, only one full-time programmer worked on the object-oriented system versus three full-time equivalent programmers for the traditional framework.

Cable television giant Time Warner Communications opted for an object-oriented development environment to build a variety of business applications. The tools let even inexperienced developers build applications quickly and embed them with business logic without having to get their hands dirty with an object-oriented programming language. The resulting customer service application, for example, let Time Warner speed up business processes and offer more competitive services (Baum [1996]). Sprint Corp. developed an object-oriented order-entry sales system to speed the providing of phone service. Instead of waiting days, customers wait mere minutes to hours for their accounts to be set up. The OO approach replaced a slow, cumbersome sales automation system with a new object-oriented system that emphasized speed and flexibility. Corporate customers get faster service and Sprint sales representatives have more time to talk on the phone (Corcoran [1996]). See DSS In Action W4-A.3 for details on another successful commercial application.
 

DSS In Action W4-A.3 Object-Oriented Technology Reducing BankBoston Risks  In the banking industry, assessing risk is essential to staying competitive or even solvent. Because banking and economics are constantly changing, banks must be flexible in calculating, assessing, and managing risks. Banks face many different types of risks, including market risks, credit risks, liquidity risks, and operation risks, that must be assessed and managed. Each type of risk has its own set of characteristics and is calculated distinctly using methods proprietary to each bank.  BankBoston saw the need to rebuild its entire trading structure and risk management systems early in the 1990s, when the decision was made to use distributed objects in a three-tiered client / server environment.  At the time, limited information was shared through a variety of databases running on a variety of hardware platforms. Traders on the floor and their managers could not instantly analyze their positions and the potential risk of each trade. Instead, they had to wait for the back-office systems to calculate the data they had to input.  In the early 1990s, executives recognized the need to build a new computing infrastructure that could support and sustain expected growth: a three-tiered, distributed computing environment using distributed objects. A goal of the project was to minimize the number of operating systems running inside the bank and to create an open environment that could easily be modified and scaled. Fusion Systems Group was selected for its experience in working with object-oriented technology.  The Treasury Risk Management System (TRMS) was the first project to be rolled out by the team, making its debut in early 1995. TRMS was developed entirely with the C++ object-oriented language using a Corba-compliant Object Request Broker developed in-house as the communications layer. Persistence is created with a Sybase SQL Server database in the back office running on a Unix-based Sun UltraSparc system. The system utilizes TCP/IP to tie all the systems together, and the TIB and Object Bus from Teknekron, Palo Alto, CA, provide market data feeds. Corba provides an open architecture, and C++ provides an emerging technology without too much risk.  The TRMS system was first deployed in the bank's Boston headquarters, and then spread to offices across the United States. The system enables traders and managers to instantly calculate the risk of a trade before it is executed. The trader can enter the pending trade into the system, and within seconds, 10,000 calculations can be carried out against real-time data, allowing traders to assess the risk and simulate their positions, as well as the bank's, in the marketplace. "We can slice and dice the data a lot of different ways," Scullen, director of treasury systems, said. Scullen did not disclose the cost of the project, but did say the bank continually analyzes the project's cost-to-savings ratio. New releases are being deployed virtually every nine months.  To Kevin Webber, general manager of Fusion's Boston office, the biggest advantage of distributed object technology is that it gives developers the ability to model and manage complexity, as well as a number of technical components -- very important capabilities in a project of this magnitude. "We can build extensible releases with efficiency using object technology," Webber said.  (Source: Condensed from "Object-oriented Technology Reducing BankBoston Risks," Application Development Trends, Vol. 3, No. 11, Nov. 1996, pp. 14, 18.)

W4-A.8 Summary and Conclusions

The object-oriented approach, though well beyond its infancy, still has a long way to go. It has many demonstrated successes, but for an organization to attain the promised gains, a paradigm shift is required. The entire organization must adopt objectthink. Such change is not evolutionary, but revolutionary. The object-oriented system development methodology is based on sound principles that have evolved from the well-accepted system development life cycle. Fortunately, the payback for the move to the object-oriented approach has been documented as being swift, though the transition may be bumpy. Almost every book on the subject indicates how to make the transition. The development tools are still evolving, but the object-oriented approach concept is stable. Research from International Data Corp. indicates that 35 % of the U.S. programming force had confronted object technology in some form by 1995, a figure expected to reach 60 % by the end of 1996. Fortunately, working with objects is becoming easier as many of the technical and organizational obstacles blocking conventional programmers are knocked down (Baum [1996]). There are a number of standard notations, but most are fairly easy to convert from one to another, and all attempt to convey the same basic information when building an object-oriented model (see Jurvis [1996] for a description of a new proposed modeling standard). The object-oriented approach to system development is a viable alternative to modern structured analysis.

Back to the Top

Additional References

Baum, D. (1996, July 29). “Objects Go Mainstream,” InformationWeek, p. 1A-6A.

Booch, G. (1994). Object-Oriented Analysis and Design with Applications (2nd ed.). Menlo Park, CA: Benjamin/Cummings.

Coad, P., D. North and M. Mayfield. (1995). Object Models: Strategies, Patterns, and Applications. Englewood Cliffs, NJ: Prentice Hall.

Coad, P. and E. Yourdon. (1991a). Object-Oriented Analysis. Englewood Cliffs, NJ: Yourdon Press / Prentice Hall.

Coad, P. and E. Yourdon. (1991b). Object-Oriented Design. Englewood Cliffs, NJ: Yourdon Press / Prentice Hall.

Corcoran, C. T. (1996, March 25). “Order-entry Sales System Speeds Sprint Phone Service,” InfoWorld, p. 76.

Foley, J. (1995, October 30). “Infoglut: New Tools Can Help Tame an Ocean of Data.” InformationWeek.

Jurvis, J. (1996, Sept. 23). Jurvis, J., “Standard Object Modeling,” InformationWeek, pp. 9A-14A.

Kemper, A. and G. Moerkotte. (1994). Object-Oriented Database Management: Applications in Engineering and Computer Science. Upper Saddle River, NJ: Prentice Hall ESM.

Martin, J. (1993). Principles of Object-Oriented Analysis and Design. Englewood Cliffs, NJ: Prentice Hall.

Norman, R. J. (1996). Object-Oriented Systems Analysis and Design. Upper Saddle River, NJ: Prentice Hall.

Parsaye, K. and M. Chignell. (1993). Intelligent Database: Object-Oriented, Deductive Hypermedia Technologies. New York: Wiley.

Ricciuti, M. (1993, Sept. 15). “Object Databases Find their Niche,” Datamation.

Satzinger, J. W. and T. U. Orvik. (1996). The Object Oriented Approach: Concepts, Modeling and System Development. Danvers, MA: boyd & fraser publishing company.

Sodhi, M. S. (1996, March/April). “Development of a DSS for Fixed-Income Securities Using OOP.” Interfaces.

Taylor (1992).

Yourdon, E. (1994). Object-oriented System Design: An Integrated Approach. Englewood Cliffs, NJ: Prentice Hall.

Yourdon, E. and C. Argila. (1996). Case Studies in Object Oriented Analysis & Design. Upper Saddle River, NJ: Prentice Hall PTR.

Yourdon, E., K. Whitehead, J. Thomann, K. Opell and P. Nevermann. (1995). Mainstream Objects: An Analysis and Design Approach for Business. Upper Saddle River, NJ: Yourdon Press / Prentice Hall PTR.

Back to the Top