|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| C H A PT E R 1 | ||||||||||||||||||||||
| ObjectiveThinking | ||||||||||||||||||||||
| Sorting, categorizing, and list-making seem to be instinctive ways by which we organize our world, create structure, and banish chaos. | ||||||||||||||||||||||
| In a world of objects, we automatically group objects according to type. Our categories tend to be flexible and we know, without being told, that one object can fall under multiple categories. The often intricate network of relationships that objects and types of objects form does not confuse us. We have an inherent understanding of object structure. One of the earliest signs of cognition in infants is when they begin to sort by shape, by type, by color, by size, or other perceived parameter. | ||||||||||||||||||||||
| Our instinctive need to sort objects, added to an ever-increasing volume and complexity of objects and information, eventually required humankind to create a structures for information maintenance. In other words, since we couldn?t remember everything, we had to write it down. Since we might want to find the things we had written down, we had to organize the papers. | ||||||||||||||||||||||
| Thus were databases created. We called them files, cabinets, address books, mailing lists, and so on. This pre-electronic nomenclature still dominates naming conventions in our computerized era. | ||||||||||||||||||||||
| It may have been as little as a few hours before our civilization would have vanished forever beneath stacks of papers, folders, and index cards, that the computer was introduced. Heaving a collective sigh of relief, we transferred our paper data to computers. | ||||||||||||||||||||||
| Very Important People predicted the coming of a paperless society with instantaneous data storage and retrieval. | ||||||||||||||||||||||
| As it turned out, these predictions were not precisely on the mark. | ||||||||||||||||||||||
| If The World Breaks Down Into Tables, Am I a Chair? | ||||||||||||||||||||||
| Despite exponential developments in the computer field, both in software and hardware, data storage and retrieval remain a major issue as we move into the next century. Notwithstanding huge investments in ever-larger computer systems, systems are never big enough or fast enough. | ||||||||||||||||||||||
| Most commercial databases are Relational (known as RDBs) and are table-driven. All data must be stored in tables. Key fields, usually an ID number or other abstract code, link one table to another. Lookup fields allow users to search for data. The more data you store, the bigger the tables become. More and bigger tables mean an ever-increasing drain on computer resources. From a user?s point of view, this means s-l-o-w. | ||||||||||||||||||||||
| Perhaps even more importantly, a purely table-driven database requires that all data tabulate. Since reality is not always amenable to this approach, many kinds of intuitive data links cannot be expressed in an RDB. | ||||||||||||||||||||||
| Real World Data Modeling | ||||||||||||||||||||||
| The KnowledgeCenter lets you create a format that fits your data. Using the KnowledgeCenter, you can express the data?s inherent complexity so that retrieving and manipulating it feels intuitive. The logic is not forced. Life is not table-driven and neither is the KnowledgeCenter. | ||||||||||||||||||||||
| As an example, think about your car. You know its manufacturer and its model. You remember when you got it, how much you paid for it, and what, if anything, you owe on it. Your car brings up fond memories of places to which you have traveled in it, and perhaps less fond memories of places where it broke down. This information and more is linked in your mind through a single object: your car. | ||||||||||||||||||||||
| Applications That Mirror Reality | ||||||||||||||||||||||
| Wouldn?t it be great if your database reflected that level of complex linking? Wouldn?t it be wonderful if finding ?your car? gave you instant access to all related information? | ||||||||||||||||||||||
| That?s exactly what object linking in the KnowledgeCenter does provide. No longer need you force data into tables. Instead, you can examine the data and from it, design data structures and links that replicate the reality in which data is actually used, making object-based development easy and natural. | ||||||||||||||||||||||
| The rules you create are extensions of the data itself. You need not impose an unnatural structure on unwilling objects. Rather, you are going to examine the objects and project how they should operate. From there, you can make it possible for objects to do what comes naturally. | ||||||||||||||||||||||
| The Knowledge Center is a rapid application development tool for creating highly scalable distributed database applications. | ||||||||||||||||||||||
| Intelligence Can Be Objective | ||||||||||||||||||||||
| The object-based nature of the KnowledgeCenter is among its greatest strengths. Independence from tables vastly speeds information retrieval. Linking allows warp-speed movement between areas in the system. Commands embedded in objects allow users to send messages to ?smart? objects that know what to do. | ||||||||||||||||||||||
| Just as the Mad Hatter asked Alice, "Why is a raven like a writing-desk?", we pose our own riddle: Why is the KnowledgeCenter like an RDB? | ||||||||||||||||||||||
| The most obvious similarity between the KnowledgeCenter and an RDB is that both store data. Regardless of database type, certain information universally breaks down into similar parts. Using a common employee data base as an example, it?s obvious that many data items are ubiquitous. Employees have names, addresses, telephones, Social Security numbers, and so on. RDB or KnowledgeCenter, this data will exist. | ||||||||||||||||||||||
| An RDB is table-based. Its primary structure is the table. Fields, represented as columns in tables, allow the assignment of data. | ||||||||||||||||||||||
| The KnowledgeCenter is object-based. Its primary structure is the class. Classes own attributes that let you assign data to the class. Attributes are roughly analogous to fields in a table. | ||||||||||||||||||||||
| Because it is object-based, the KnowledgeCenter uses no key or lookup fields. It does not need them. Instead, the KnowledgeCenter uses pointers: Object Pointers that point to a single object, and Object Collections that point to groups of objects. Pointers actually know the system address of linked objects, eliminating searching and enabling a literally instant connection. | ||||||||||||||||||||||
| Pointers are much more than tracking devices. Not only do they know where other linked objects live, but they enable seamless, instantaneous navigation between these objects, whether one-to-one, one-to-many, or many-to-many. For example, in an ordering system where each line item is a separate object, the ?Object Collection? attribute locates all line items for the order. No tables are searched, no key or lookup fields are required. The data is just there. | ||||||||||||||||||||||
| Linking makes KnowledgeCenter objects smarter than RDB tables, but you can make the objects in your applications even smarter by encapsulating scripts for methods and commands in them. These will allow the objects you create to know what to do with the various messages sent them You control the process; exactly how smart any object will be depends on you. | ||||||||||||||||||||||
| The primary difference between the KnowledgeCenter and RDB lies in how data is managed. | ||||||||||||||||||||||
| An object inherits every characteristic of its parent. This powerful feature enormously shortens development time. For example, to create a class of employees called ?Supervisors,? you would create a subclass of the employee class. Supervisors would automatically inherit all the attributes and capabilities of an employee. You would need only create those attributes and/or commands unique to supervisors, such as a Object Collection pointer for subordinates, plus some commands that might allow the supervisor to promote employees, or authorize expenditures. All the other ?stuff? the supervisor needs would already be in place, inherited from the Employee class from which it was derived. | ||||||||||||||||||||||
| Comparing Terminology | ||||||||||||||||||||||
| Comparing an RDB to the KnowledgeCenter is much like comparing apples with oranges. Although both are fruit, they are very different in taste, color, shape, and type. RDB terminology differs from KnowledgeCenter terminology. | ||||||||||||||||||||||
| Class vs. Table | ||||||||||||||||||||||
| The basic structure of RDB is the table. The basic structure of the KnowledgeCenter is the class. Whereas in the RDB world you create a table, in the KnowledgeCenter you create a class. | ||||||||||||||||||||||
| Field Vs. Attribute | ||||||||||||||||||||||
| In an RDB table for employee data, each discrete item of information would become a field. Name, address, phone number, Social Security Number, and so on, would each be one field. A key field, such as "Employee ID" would provide a link with other tables. Key and Lookup fields would let the end-user find related information in linked tables. | ||||||||||||||||||||||
| In the KnowledgeCenter, you would create an employee class that would contains attributes such as name, address, phone number, Social Security Number, and so on. The employee class could also contain pointers that could tell each employee the system address of other related objects, such as projects and supervisors. | ||||||||||||||||||||||
| From the end-user's viewpoint, this means direct, instant access to all related information by clicking on the linked object. Users can intuitively follow pointers along logical paths from an original object, through other objects, to information quite remote from the starting point. | ||||||||||||||||||||||
| All traditional searches and queries are also available in the KnowledgeCenter. Navigation in the KnowledgeCenter requires no more than the click of a mouse on an object's icon in Link view, or a navigation icon in any view. The application user perceives this as immediate. | ||||||||||||||||||||||
| Links vs. Key Fields | ||||||||||||||||||||||
| Traditional RDBs use Key and Lookup fields to hook related data. No matter what the level of complexity of an RDB, the linking process is essentially the same: key field to key field, table to table. | ||||||||||||||||||||||
| The KnowledgeCenter lets you embed within the design of a class knowledge of itself and other objects. Each instance of a class is thus ?born? knowing where it lives and where all objects linked to it live. This embedded knowledge renders key and lookup fields superfluous. | ||||||||||||||||||||||
| The KnowledgeCenter links an object to another object or a group of objects using ?pointers? that contain the actual system address of each object. | ||||||||||||||||||||||
| Objects actually link to other objects rather than to a field or attribute. Linking is one of the most powerful features of the KnowledgeCenter. The user need not initiate any special searches, queries, procedures, or commands to follow these links. There are no keys to remember, no tables to access. | ||||||||||||||||||||||
| You, as the builder, define the links, and will probably define most links as "reciprocal," meaning that the Order points to the Line Item, and the Line Item points back to the Order. Reciprocity lets application users view all links between related objects and follow a data trail intuitively. Application users thus experience virtually instantaneous data retrieval. | ||||||||||||||||||||||
| Instances vs. Records | ||||||||||||||||||||||
| Each table entry in an RDB table becomes a record. Thus in an organization that has 400 employees, the employee table in an RDB would contain 400 records. | ||||||||||||||||||||||
| Each occurrence of a class is called an instance. Using the KnowledgeCenter, the same company would have 400 instances of the employee class or object. | ||||||||||||||||||||||
| Navigation: Beam me up, Scottie | ||||||||||||||||||||||
| When you build an application, you need not limit your users to navigating between directly linked, or adjacent, objects. You can write a short navigation script as a command on an object thus creating paths between any objects in the database. Such scripted navigation paths are more like the transporter on the Starship Enterprisethan they are like roads. | ||||||||||||||||||||||
| The ability to view links and find adjacent objects is ?free.? You need no special scripts, queries, searches, or reports. Jumping between non-adjacent objects costs just ?a few pennies more.? | ||||||||||||||||||||||
| Moving from "here" to "there" is immediate, with no discernible time lapse for travel. | ||||||||||||||||||||||
| You can click any navigation icon on the navigation bar or select the equivalent command from the Navigate menu to seamlessly transport to that item. | ||||||||||||||||||||||
| (Excerpt; proprietary material deleted) | ||||||||||||||||||||||
| Return to Home | ||||||||||||||||||||||