Implications for Relational Design Documentation of the inherent or essential functions of a business sets the stage for creating programs to carry out those functions. If a function simply describes inputs to or retrievals from a database, the only programming required to implement them is specification of simple input or output transactions, probably making use of an appropriate high-level database tool. If an activity is more complex, then more complex logic must be programmed, either for attachment to one of those input/output programs or as a stored procedure to guard the database against invalid operations. In this case, documentation of the detailed workings of the activities will be required, as will detailed specification of the program logic design. Clearly, the database design, as controlled by the data model (see Chapter 3), will significantly affect the structure of any programs involved. In the old days, a program had to be concerned with the details of inputs and outputs and data definition, as well as with underlying logic. Now these categories of processing are largely carried out by database management systems and fourth-generation languages. All that remains is the central logic and the overall architecture of the programs. Implications for Object-Oriented Design To the extent that true entity types behave in the object-oriented sense, the function/entity type matrix can guide the designer to the activities that must be attached to each entity. To the extent that object-oriented analysis simply identified activities that are being called objects, the implementation of these will be, as in the relational approach, pieces of program code. That the code is then attached to dummy objects does not fundamentally change this. |
