App-F-G Client/Server Systems – Database Systems: Design, Implementation, and Management : Book Guide

This Document Contains Appendixes F to G Appendix F Client/Server Systems Discussion Focus Why may client/server computing be considered an evolutionary, rather than a revolutionary, change? Client/server computing didn't happen suddenly. Instead, it is the result of years of slow paced changes in end user computing. Using Appendix F, Section F.2's evolution of client/server information systems, first illustrate the typical mainframe scenario (users accessing dumb terminals), then move the discussion to the development on the microcomputer and its impact on work styles to set the stage for the current PC-based client/server computing scenario. Use Appendix F, Table F.1 to illustrate the contrasting characteristics of the mainframe-based and client/server-based information systems. Why may the client/server evolution be characterized as a bottom-up change and how does this change affect the computing environment? Modern end users use intelligent computers, GUIs, user-friendly systems, and data analysis tools to effectively increase their productivity. In addition, data sharing requirements make efficient use of network resources a priority issue. Given such an end user-based environment, it is not surprising that the end user drives the client/server architecture’s development and acceptance. Given this introduction and expanding on its theme, students are more easily able to contrast the PC-based client/server computing model and the traditional mainframe-computing model. After identifying the differences in computing style that characterize these models, the discussion may be shifted toward the formal definition of client/server systems, the forces that drive client/server systems, and the managerial expectations of client/server system benefits. Section F.7.2's examination of the managerial expectations of client/server systems benefits is the key to understanding the opportunities and risks associated with client/server systems. Students will benefit from the suggested readings in this section, so we suggest their assignment. What are the client/server's infrastructure requirements and how do they function? Appendix F’s Client/Server Architecture Section F.3 deals with the technical details of the client/server main components. This discussion is more likely to be fruitful if you first assign Appendix G, “Client/Server Network Infrastructure,” and Appendix F’s section F.3 as background reading to acquaint students with the basic network components such as cabling, topology, types, communication devices and network protocols. Use the example illustrated in Figure F.3 to briefly explain the interaction among the main components: client, server, and communications channel or network. Emphasize that each of these components requires a combination of hardware and software subcomponents. We suggest that, before discussing the technical details of each client/server component, it will be helpful to explain the Client/Server architectural principles that govern most client/server systems. Use the OSI network reference model illustrated in Appendix F, Table F.2 to explain the communications channel components, and then use Appendix F, Figure F.7 to illustrate the flow of data from the client to the communication channel to the server. What is middleware and why is it a crucial client/server component? Middleware is part of the communications channel. Its presence is so important in a successful client/server environment that some authors define three client/server architectural components: client, server, and middleware. To explain the need for and use of middleware software, use Appendix F, Figure F.11 to illustrate how middleware functions in ORACLE and SQL Server databases. Appendix F, Figure F.12 illustrates the use of middleware in an IBM DB2 shop. Note that even the middleware software can have client and server components. What, if any, client/server standards exist and how do such standards affect the client/server database environment? There is no single standard to choose from at this point. However, there are several de facto standards, created by market acceptance. (See Appendix F, Section F.4, “The Quest for Standards.”) Therefore, client/server developers have many "standards" to choose from when developing applications. The important issue in database is how the selection of one of the de facto standards affects database design, implementation, and management. Section F.7 explains some of the desired features of client/server databases. What are the logical components of a client/server application and how are these components allocated in a client/server environment? Appendix F's Client/Server Architectural Styles section defines an application's main logical components and how those components can be allocated to clients and/or servers. Use Appendix F, Section F.6 as the basis for a discussion about the different levels of processing logic distribution. (Note particularly Figure F.16.) What are some of the managerial and technical issues encountered in the implementation of client/server systems? Appendix F, Section F.7 addresses this discussion question in detail. Specifically, this section shows how the change from traditional to client/server data processing affects the MIS function. Answers to Review Questions NOTE Since the answers to many of these questions are covered in detail in Appendix F, we have elected to give you section references to avoid needless duplication. 1. Mainframe computing used to be the only way to manage data. Then personal computers changed the data management scene. How do those two computing styles differ, and how did the shift to PC-based computing evolve? The evolution toward client/server information systems is explained in section F.2. The main differences between mainframe-based information systems and PC-based client/server information system are illustrated in Table F.1. The answer to this question may also include a discussion, based on Section F.2, of the forces that drive client/server systems. 2. What is client/server computing, and what benefits can be expected from client/server systems? Client/Server is a term used to describe a computing model for the development of computerized systems. This model is based on the distribution of application's functions among two types of independent and autonomous entities: servers and clients. A client is any process that request specific services from server processes. A server is a process that provides requested services for clients. See section F.1 for additional client/server definition details. Note that client/server is a computing model that focuses on the separation and distribution of the application's functions. Therefore, the application is divided into client and server processes. The clients request services from the server processes. Note also that the client and server processes can reside on the same or on different computers connected by a network. The final result is an application in which part of the processing is done at the client side and part of the processing is done at the server side. The advantages of separating and distributing the application's processing are efficient resource utilization and maximization of resource effectiveness. Perhaps the greatest single advantage is found in the utilization of the existing personal computer power for local data access and processing. Thus the end user is able to use local PCs to access mainframe and minicomputer legacy data and to process such data locally by using user-friendly PC software. Used correctly, this computing approach yields greater information autonomy, lower costs, improved access to information, and, therefore, a greater potential for better decision making. These benefits may yield better service to customers, thus generating more business. (The managerial expectations of client/server benefits are explained in greater detail in section F.7.) 3. Explain how client/server system components interact. The main client/server components are the client, the server, and the communications channel. Some experts include middleware as a separate component. Section F.3.1 provides a detailed explanation of the component interactions. 4. Describe and explain the client/server architectural principles. Client/Server components must conform to some basic architectural principles if they are to interact properly. Section F.3 includes a detailed description and explanation of the client/server architectural principles. 5. Describe the client and the server components of the client/server computing model. Give examples of server services. Section F.3 offers an extensive description of the client and server components. This section also provides several examples of server services. Figures F.5 and F.6 illustrate client and server internal components. Server services – file, print, fax, communications, database, transaction, and miscellaneous services such as CD-ROM, video, and back-up -- are detailed in section F.3.3. 6. Using the OSI network reference model, explain the communications middleware component's function. The communications channel provides the means through which clients and servers communicate. The communications channel connects clients and servers and its main function is the delivery of messages between clients and servers. Using the OSI network reference model, section F.3.5 provides a detailed explanation of the communication channel. Note that we use the OSI network reference model because most of the client/server applications are based on a scenario in which clients and servers are tied together through a network. 7. What major network communications protocols are currently in use? The client/server network infrastructure includes the network cabling, network topology, network type, communication devices, and network protocols. Section F.3.6 provides a detailed description of these components and their use. The network protocols determine how messages between computers are sent, interpreted and processed. The main network protocols in use today are Transmission Control Protocol/Internet Protocol (TCP/IP), Sequenced Packet Exchange/Internet Protocol (SPX/IPX), Network Basic Input Output System (NetBIOS). Section F.3.6 provides a more detailed explanation of these and other network protocols. 8. Explain what middleware is and what it does. Why would MIS managers be particularly interested in such software? Middleware is software that is used to manage client/server interactions. Most important to the end user and MIS manager is the fact that middleware provides services to insulate the client from the details of network protocols and server processes. MIS managers are usually concerned with finding ways to improve end user data access and to improve programmer productivity. By using middleware software, end users can access legacy data and programmers can write better applications faster. The applications are network independent and database server independent. Such an environment yields improved productivity, thereby generating development costs savings. Sections F.3.4 and F.3.5 provide additional database middleware software details. 9. Suppose you are currently considering the purchase of a client/server DBMS. What characteristics should you look for? Why? A client/server DBMS is just one of the components in an information system. The DBMS should be able to support all applications, business rules, and procedures necessary to implement the system. Therefore, the DBMS must match the system's technical characteristics, it must have good management capabilities, and it must provide the desired level of support from vendor and third parties. Specifically: • On the technical side the database should include data distribution, location transparency, transaction transparency, data dictionary, good performance, support for access via a variety of front ends and programming languages, support several Client types (DOS, UNIX, Windows, etc.), third party support for CASE tools, Application Development Environments, and so on. • On the managerial side the database must provide a wide variety of managerial tools, database backup and recovery, GUI based tools, remote management, interface to other management systems, performance monitoring tools, database utilities, etc. • On the support side the DBMS must have good third party vendor support, technical support, training and consulting. Section F.7 provides additional details about these topics. Always remember that DBMS selection is a task within the system development process and normally follows the requirements definition task. In other words, the DBMS features should be determined by the characteristics of the system that is going to be built, and not the other way around. Unfortunately, in the real world this is a luxury enjoyed by few development projects! 10. Describe and contrast the four client/server computing architectural styles that were introduced in this appendix. This question deals with identifying the application processing logic components and deciding where to locate them. Section F.6 covers this very important topic in great detail. (Note particularly the summary in Figure F.19, “Functional Logic Splitting in Four Client/Server Architectural Styles.”) Note that client/server computing styles include several layers of hardware and software in which processing takes place. This layered environment is quite different from the homogeneous environment encountered in traditional mini and mainframe programming. 11. Contrast client/server and traditional data processing. From a managerial point of view, client/server data processing tends to be more complex than traditional data processing. In fact, client/server computing changes the way in which we look at the most fundamental computing chores and expands the reach of information systems. These changes create a managerial paradox. On the one hand, MIS frees end users to do their individual data processing and, on the other hand, end users are more dependent on the client/server infrastructure and on the expanded services provided by the MIS department. Client/server computing changes the way in which systems are designed, developed and managed by forcing a change from: • proprietary to open systems • maintenance-oriented coding to analysis, design and service • data collection to data deployment • a centralized to a distributed style of data management • a vertical, inflexible organizational style to a more horizontal, flexible style. For additional details on these and related topics refer to section F.7.1. 12. Discuss and evaluate the following statement: There are no unusual managerial issues related to the introduction of client/server systems. The managerial issues in client/server systems management arise from the changes in the data processing style discussed in Section F.7, the management of multiple hardware and software vendors, the maintenance and support of the client/server infrastructure, such as communications, applications and the management and control of associated costs. Problem Solutions 1. ROBCOR, a medium-sized company, has decided to update its computing environment. ROBCOR has been a minicomputer-based shop for several years, and all of its managerial and clerical personnel have personal computers on their desks. ROBCOR has offered you a contract to help the company move to a client/server system. Write a proposal that shows how you would implement such an environment. Because question 13 cannot be answered properly without addressing the computing style issue in question 14, the answers to both questions are supplied after question 14. 2. Identify the main computing style of your university computing infrastructure. Then recommend improvements based on client/server strategy. (You might want to talk with your department's secretary or you may want to talk to your advisor to find out how well the current system meets their information needs.) Questions 13 and 14 are research questions that yield extensive class projects. The questions are designed with two ideas in mind: 1. To have the student assume the consultant's "proactive" role. 2. To entice the students to use the knowledge acquired in this appendix to develop an integrated approach to client/server systems implementation. The expected output for these projects is a business quality paper and a professional-level class presentation of the findings, recommended solutions, and the suggested implementation. The material presented in Section F.7 yields an outline appropriate for such a paper. It will be beneficial if students have taken at least an introductory course in Systems Analysis and Design. Keep in mind that you can either use the two scenarios presented in these questions or you can assign students a real world case to accomplish the same goals. In the first case, the professor assumes the role of the end user. In the second case, an external third party is the end user. The problem with real world cases is that the professor must procure commitment from the third party. Unfortunately, it is sometimes difficult for company managers to provide possibly sensitive internal information to students and to devote scarce time resources to student projects. Even if the project is kept within the university's bounds, you are likely to discover that the university administrators may not be able or willing to provide critical information. Students should be encouraged to use the presentations as a basis for further analysis of the more nettlesome issues that must be confronted in the development of client/server systems. We suggest several class discussion sessions in which different student groups present alternative solutions. Such presentations will force students not only to design a solution but also to sell the solution to management. Appendix G Object-Oriented Databases Discussion Focus Because an OO model necessarily forces the student to come to terms with some very abstract notions, begin the discussion by pointing out the practical benefits of system modularity; then carefully delineate the OO features that almost inevitably lead to modularity. At this point, students should be familiar with the relational model, so show how the OO model handles attributes and demonstrate that: 1. Although the term "object" in a relational environment is sometimes used as synonymous with "entity," an object in an OO environment contains much more than attributes. Use Figure G.2 to show that the object contains both data and methods: Every operation to be performed on the object is implemented by a method! And the methods are carried along with the object, thus producing modularity! 2. An OO attribute (not its value!) can reference one or more other objects. 3. Unlike the relational model, the OO model does not need a JOIN to link tables through their common attribute values. 4. There is quite a difference between the relational model's primary key and the OO model's OID. Section G.5, “OODM and Previous Data Models: Similarities and Differences,” yields an excellent summary of the OO data model; do not omit any of its subsections in your discussion. Next, it is crucial that you shift attention to Section G.5.1's Figure G.34, “An Invoice Representation”; this is where students are most likely to see the database's conceptual modeling implications. Answers to Review Questions NOTE To ensure in-depth chapter coverage, most of the following questions cover the same material that we covered in detail in the text. Therefore, in most cases, we merely cite the specific section, rather than duplicate the text material. 1. Discuss the evolution of object-oriented concepts. Explain how those concepts have affected computer-related activities. See Section G.2. 2. How would you define object orientation? What are some of its benefits? How are OO programming languages related to object orientation? See the definition of OO in Section G.1, “Object Orientation and Its Benefits.” The benefits derived from the application of OO concepts are summarized in Table G.1, “Object Orientation Contributions.” The relationship between OO and OO programming languages (OOPL) is discussed in Section G.3.5, “Messages and Methods.” Add to this discussion that OO concepts have created a powerful programming environment that has radically changed both programming and systems development. Although traditional programmers tended to agree that modularity is one of the primary goals of structured programming and good design, modularity was often difficult to achieve. Even a cursory examination of OO concepts leads to the conclusion that the conceptually autonomous structure (in which an object contains both data and methods) makes the much sought-after modularity almost inevitable. 3. Define and describe the following: a. Object See Section G.3.1, “Objects: Components and Characteristics.” b. Attributes See Section G.3.3, “Attributes (Instance Variables.” c. Object state See Section G.3.4, “Object State.” d. Object ID See Section G.3.2, “Object Identity.” 4. Define and contrast the concepts of method and message. What OO concept provides the differentiation between a method and a message? Give examples. Methods and messages are discussed in Section G.3.5, “Messages and Methods.” Use Figure G.3, “Method Components,” to illustrate the role of methods and messages. 5. Explain how encapsulation provides a contrast to traditional programming constructs such as record definition. What benefits are obtained through encapsulation? Give an example. Encapsulation hides the object's internal data representation and method implementation, thus ensuring the object's data integrity and consistency. The programmer needs only ask an object to perform an action, without having to specify how the action is to be performed. Since the implementation details need not be specified, the programmer can concentrate on the overall process. Clearly, an object is an independent entity. Therefore, object independence assures system modularity. For example, an object-oriented system is formed by possibly thousands of independent objects (or even more) that interact to perform specific actions. In short, what we have just described is a perfectly modular system. In contrast, the programmer who uses traditional programming languages has direct access to the internal components of a record type. Therefore, the programmer can directly manipulate the data elements at will. This ability is not necessarily valuable; programmers can (and do) make mistakes, thus causing problems in critical systems. For example, when you create a record type "customer" in your program, you have direct access to all the data elements of such a record, so there is no protection of the data. 6. Using an example, illustrate the concepts of class and class instances. See Section G.3.6, “Classes.” Use Figure G.5, “Class Illustration,” to illustrate that a class is composed of objects or object instances; then use the example summarized in Figure G.6, “Representation of the Class STUDENT.” As you discuss the example in Figure G.5, note that each class instance is an object with a unique OID and that each object knows to which class it belongs. 7. What is a class protocol, and how is it related to the concepts of methods and classes? Draw a diagram to show the relationship between these OO concepts: object, class, instance variables, methods, object's state, object ID, behavior, protocol, and messages. See Section G.3.7, “Protocol.” Use the summary presented in Figure G.8, “OO Summary: Object Characteristics,” to tie the OO concepts together. 8. Define the concepts of class hierarchy, superclasses, and subclasses. Explain the concept of inheritance and the different types of inheritance. Use examples in your explanations. See Sections G.3.8, “Superclasses, Subclasses, and Inheritance,” and G.3.9, “Method Overriding and Polymorphism.” The examples are illustrated in Figures G.9 - G.14. 9. Define and explain the concepts of method overriding and polymorphism. Use examples in your explanations. See Section G.3.9, “Method Overriding and Polymorphism.” Illustrate the example with reference to Figure G.14, “Employee Class Hierarchy Polymorphism.” 10. Explain the concept of abstract data types. How they differ from traditional or base data types? What is the relationship between a type and a class in OO systems? See Sections G.3.10 - G.4. Show Figure G.17, “Defining Three Abstract Data Types,” to illustrate the use of abstract data types. Use Table G.3, “Comparing the OO and ER Model Components,” to illustrate the distinction between type and class. 11. What are the five minimum attributes of an OO data model? See Section G.6, “Object Oriented Database Management Systems.” Note especially Table G.4, “The Thirteen OODBMS Rules. Table G.4’s subsection, “Rules that make it a DBMS,” lists the five characteristics (rules) that define an OO data model. 12. Describe the difference between early and late binding. How does each of those affect the object-oriented data model? Give examples. Late and early binding are discussed and illustrated in Section G.4.4, “Late and Early Binding: Use and Importance.” See particularly Figures G.32, “Inventory Class with Early Binding” and G.33, OODM Inventory Class with Late Binding.” 13. What is an object space? Using a graphic representation of objects, depict the relationship(s) that exist between a student taking several classes and a class taken by several students. What type of object is needed to depict that relationship? The object space or object schema is the equivalent of a database schema. The object space is used to represent the composition of the state of an object at a given time. For example, to represent the M:N relationship between students and classes, you can use the schema shown in Figure QG.13 to represent the M:N relationship between CLASS and STUDENT: Figure QG.13 The Object Schema for the Relationship between Student and Class As you discuss Figure QG.13, note the use of an interSection class (ENROLL) to represent the M:N relationship between STUDENT and CLASS. This interSection class contains the GRADE attribute, which represents the student's grade in a given course. NOTE Now's the time to tie the OO concepts and constructs together. Show how the OO model uses objects, object instances, and object sharing, then explore the 1:1, 1:M, and M:N relationships illustrated in Figures G.23 trough G.28. Next, show how an object space may be represented, using Figure G.29 as an example. Finally, show how abstract data types help the designer implement the OO model. 14. Compare and contrast the OODM with the ER and relational models. How is a weak entity represented in the OODM? Give examples. Section G.4, “Characteristics of an Object Oriented Data Model,” sets the discussion stage. Use Table G.3, “Comparing the OO and ER Model Components,” to summarize the comparisons between the OO model and the ERM. (The acronym “ERM” denotes the Entity Relationship Model.) This question is also address extensively in Section G.9, “How OO Concepts have Influenced the Relational Model.” Section G.5.1, “Object, Entity, and Tuple,” is and excellent comparison source. Your students may get an “I got it!” moment when they examine Figure G.34, “An Invoice Representation.” Although the OODM has much in common with relational and ER data models, the OODM introduces some fundamental differences. Table QG.14 provides the summary that will help you clarify the OODM characteristics we introduced in this appendix. (Although a case may be made for the OO data model’s contributions, we urge you to let your students read and discuss C. J. Date’s “Third Manifesto,” referenced in Section G.9.) Table QG.14 A Comparison of OODM, ERM, and Relational Model Features OODM ER Model (ERM) Relational Model Type Entity definition (limited) Table definition (limited) Object Entity Table row or tuple Class Entity set Table Instance variable Attribute Column (attribute) OID N/A N/A N/A Primary key Primary key Object schema ER diagram Relational schema Class hierarchy N/A* N/A Inheritance N/A* N/A Encapsulation N/A N/A Method N/A N/A You may find it useful to point out the similarities between (entity type and subtypes) and (class hierarchy and inheritance.) Remember that entity types and subtypes are design constructs that provide data modeling with data abstraction, but these constructs do not automatically imply the existence of inheritance. In fact, no RDBMS supports these constructs directly; instead, the programmer has to link the tables at run time to ensure that the attributes will be “inherited”. You could also create views to ensure that the constructs include the “inherited” attributes. 15. Name and describe the 13 mandatory features of an OODBMS. See Section G.6.1, “Features of an Object Oriented Database,” and use the thirteen OODBMS commandments listed in Table G.4, “The Thirteen OODBMS Rules.” 16. What are the advantages and disadvantages of an OODBMS? See Section G.8, “OODBMS: Advantages and Disadvantages.” 17. Explain how OO concepts affect database design. How does the OO environment affect the DBA's role? See Section G.9, “How OO Concepts have Influenced the Relational Model.” 18. What are the essential differences between the relational database model and the object database model? Start by using Table QG.14 – shown in the answer to question 14 -- to show and contrast the basic concepts of the object model, the entity-relationship model, and the relational model. A more detailed discussion of the similarities and differences among the models is found in Section G.5, “OODM and Previous Data Models: Similarities and Differences.” In this section, we have shown that: • An object extends beyond the static concept of an entity or tuple in the other data models. • Like the entity set and table, a class includes the data structure. However, unlike the entity set and table, the class also includes methods. • Unlike its relational and ER counterparts, encapsulation allows an object’s “internals” to be hidden from the outside • Unlike its relational and ER counterparts, inheritance allows an object to inherit attributes and methods from a parent class. • The Object Id is a concept associated with the primary key concept in the relational and ER model, but it is not quite the same thing. An object Id is an attribute that is not directly exposed, user definable, or directly accessible as the PK is in the relational model. • The relational and ER model relationships are based on the primary key/foreign key relationships. Such relationships are “value” based; that is, they are based on having two attributes in different tables sharing equal values. The relationships in the object model are not based in the specific value of any attributes. • Data access in the relational model is based on a query language known as SQL. SQL is a set-oriented language that uses associative access methods to retrieve related rows from tables. In contrast with the relational model, the object data model suffers from the lack of a standard query language. Because of its identity based access style, the object model resembles the record-at-a-time access of older hierarchical and network models. 19. Using a simple invoicing system as your point of departure, explain how its representation in an entity relationship model (ERM) differs from its representation in an object data model (ODM). (Hint: Check Figure G.34.) Use the appendix’s Figure G.34 to illustrate the idea that the object model represents the INVOICE as an object containing other objects (CUSTOMER and LINE). In contrast, the ER model uses three different and separate entities related to each other through their primary key/foreign key attributes. Note that the object model automatically includes the CUSTOMER and LINE object instances when each INVOICE line instance is made current. 20. What are the essential differences between an RDBMS and an OODBMS? Section G.6, “Object Oriented Database Management Systems,” explains the basic characteristics of an OODBMS. Such characteristics clearly show that the OODBMS shares features such as data accessibility, persistence, backup and recovery, transaction management, concurrency control, and security and integrity with the RDBMS. In addition, the OODBMS has unique characteristics such as support for complex objects, encapsulation and inheritance, abstract data types, and object identity. 21. Discuss the object/relational model's characteristics. See Section G.9, “How OO Concepts Have Influenced the Relational Model.” Section G.5.1, “Object, Entity, and Tuple,” is and excellent comparison source. Your students may get an “I got it!” moment when they examine Figure G.34, “An Invoice Representation.” Problem Solutions 1. Convert the following relational database tables to the equivalent OO conceptual representation. Explain each of your conversions with the help of a diagram. (Note: The RRE Trucking Company database includes the three tables shown in Figure PG.1). FIGURE PG.1 The RRE Trucking Company Database As you examine Figure PG.1, note that, for simplicity's sake, we have chosen not to represent BASE_MANAGER as an abstract data type belonging to the class PERSON. Figure PG.1 The OO Conceptual Representation Figure PG.1 also illustrates that the CTRUCK class represents a collection of TRUCK objects. In other words, one instance of the CTRUCK class will contain several instances of the class TRUCK. 2. Using the tables in Figure PG.1 as a source of information: a. Define the implied business rules for the relationships. Given the tables in Figure PG.1, you may develop the following relationships: • A BASE can have many TRUCKs. • Each TRUCK belongs to only one BASE. • A TRUCK has only one truck TYPE. • Each truck TYPE may have several TRUCKs belonging to it. b. Using your best judgment, choose the type of participation of the entities in the relationship (mandatory or optional). Explain your choices. From the data shown in Figure PG.1 you can conclude that: • BASE and TYPE are mandatory for TRUCK. • A TRUCK must have a BASE. • A truck is of a given TYPE. • TRUCK is mandatory for BASE. • A BASE must have at least one TRUCK to be considered a BASE. • TRUCK is optional for TYPE. There can be zero, one, or more TRUCKs belonging to a TYPE. c. Develop the conceptual object schema. Using the results of Problems (a) and (b), the conceptual object schema is represented by Figure PG.2C. Figure PG.2C The Conceptual Object Schema 3. Using the data presented in Problem 1, develop an object space diagram representing the object's state for the instances of TRUCK listed below. Label each component clearly with proper OIDs and attribute names. a. The instance of the class TRUCK with TRUCK_NUM = 5001 The instance of this class is shown in problem 2c's conceptual object schema. (Figure PG.2c.) b. The instances of the class TRUCK with TRUCK_NUM = 5003 and 5004. As you examine the conceptual object schema shown in problem 2c, note the following features: • OIDs are used to reference the object instances of the classes BASE and TYPE. • The BASE and TYPE object instances reference two different CTRUCK object instances. • Using the OIDs, each CTRUCK object instance contains the reference to several object instances of the class TRUCK. Using these features, the conceptual object schema looks like Figure PG.3b. Figure PG.3b The Conceptual Object Schema As you examine Figure PG.3b’s conceptual object schema, note the following features: • OIDs are used to reference the object instances of the classes BASE and TYPE. • Both object instances reference the same BASE and TYPE object instances. This property is also called referential object sharing. 4. Given the information in Problem 1, define a superclass VEHICLE for the TRUCK class. Redraw the object space you developed in Problem 3, taking into consideration the new superclass that you just added to the class hierarchy. To add a superclass VEHICLE to the TRUCK class, first define the superclass VEHICLE, after which you can create the subclass TRUCK. After this task has been completed, the end user will see only the attributes and methods that were inherited from VEHICLE. (The user does not perceive the difference!) To illustrate this point, the object space must also show the new VEHICLE instance. (See Figure PG.4.) Figure PG.4 The Conceptual Object Schema 5. Assume the following business rules: • A course contains many Sections, but each Section references only one course. • A Section is taught by one professor, but each professor may teach one or more different Sections of one or more courses. • A Section may contain many students, and each student may be enrolled in many Sections. • A Section may contain many students, and each student is enrolled in many Sections, but each Section belongs to a different course. (Students may take many courses, but they cannot take many Sections of the same course.) • Each Section is taught in one room, but each room may be used to teach different Sections of one or more courses. • A professor advises many students, but a student has only one advisor. Based on those business rules: a. Identify and describe the main classes of objects. Using the business rules 1 through 6, we may identify the objects: COURSE STUDENT CLASS ROOM PROFESSOR NOTE We commonly use CLASS to identify a Section of a COURSE. (IN fact, all of the examples in Chapters 2 and 3 were based on this convention.) Therefore, we use CLASS to identify a Section of a COURSE. We use this convention for the simple reason that it properly reflects commonly used language. For example, students invariably will tell you that they have enrolled in your class; they'll tell you they're going to your class, rather than going to your Section. However, do keep in mind that "class" has a specific (and different!) meaning in the OO environment. Fortunately, the context in which "class" is used easily identifies which "class" you're talking about. The classes corresponding to these objects are shown in Figure PG.5a. Figure PG.5a The Conceptual Object Schema Use the following descriptions to characterize the model's components: COURSE OFFERING INCLUDES CLASS A COURSE CAN GENERATE MANY CLASSES CLASS IS OPTIONAL TO COURSE (a course may not be offered) PROFESSOR TEACH_LOAD INCLUDES CLASS A PROFESSOR CAN TEACH MANY CLASSES CLASS IS OPTIONAL TO PROFESSOR (a professor may not teach a class) ADVISEES INCLUDES STUDENT A PROFESSOR MAY ADVISE MANY STUDENTS STUDENT IS OPTIONAL TO PROFESSOR (in the advises relationship) ROOM RESERVATION INCLUDES CLASS ONE ROOM CAN HAVE MANY CLASSES SCHEDULED IN IT CLASS IS OPTIONAL TO ROOM (a room may not have classes scheduled in it) STUDENT ADVISOR INCLUDES PROFESSOR A STUDENT HAS ONE PROFESSOR (who advises that student) PROFESSOR IS MANDATORY (a student must have an advisor) SCHEDULE INCLUDES CLASS A STUDENT MAY TAKE MANY CLASSES (i.e., SECTIONS OF A COURSE) CLASS IS MANDATORY TO STUDENT (a student must take at least one Section of a course) CLASS REQUIRES A COURSE COURSE IS MANDATORY (a class can't exist without a course) PROFESSOR IS MANDATORY (a class must have a professor) ROOM IS MANDATORY (a class must be taught in a room) A CLASS MAY HAVE MAY STUDENTS ENROLLED IN IT STUDENT IS OPTIONAL ( a class may not have any students enrolled in it) AN ENROLLED STUDENT RECEIVES A GRADE b. Modify your description in Part (a) to include the use of abstract data types such as NAME, DOB, and ADDRESS. An abstract data type allows us to create user-defined operations for that new type. To create a new data type, first define the abstract data types or classes: NAME, DOB (date of birth), and ADDRESS, as shown in Figure PG.5B-1. Figure PG.5B-1 The Abstract Data Types (Classes) Having created the new abstract data types or classes, we must redefine PROFESSOR and STUDENT classes so they can reference these newly created classes. For example, the object instance representation for a PROFESSOR will look like Figure PG.5B-2. Figure PG.5B-2 The Object Instance Representation for PROFESSOR Within the new object space illustrated in Figure PG.5B-2, the PROFESSOR object instance now contains references to the NAME, DOB, and ADDRESS object instances. c. Use object-representation diagrams to show the relationships between: • Course and Section. • Section and Professor. • Professor and Student. To answer this question, we must remember how 1:M relationships are interpreted in the OODM. We must also remember that the OODM interpretation of such 1:M relationships yields some important implications. Keep in mind that all pairs of objects exist in a 1:M relationship: A course has many Sections (classes), a professor teaches many classes, and a professor advises many students. To save space in this manual, we will illustrate only one case of 1:M relationships; the same concepts apply to all cases. We will focus our attention on the relationships of the objects in the class PROFESSOR. The object representation for an object of the (OO) class PROFESSOR will look like Figure PG.5C. Figure PG.5C The Object Representation for an Object of the Class PROFESSOR Note that we have omitted the object instances for the classes NAME, DOB, and ADDRESS. (These classes are shown in the answer to problem 5g.) Note also that we have used the "collection of" classes to represent the collection of • CLASSes taught by the PROFESSOR. • STUDENTs advised by the PROFESSOR. Collection objects are used to implement 1:M relationships. Use object representation diagrams to show the relationships between: • Section and Student. • Room and Section. What type of object is necessary to represent those relationships? The relationship between CLASS (Section) and STUDENTS is M:N; that is, each class has many students, and each student has many classes. The relationship between CLASS and ROOM is 1:M, because each class is taught in only one room and each room is used to teach several classes. We covered the use and representation of 1:M relationships in our answer to question 5c, so please refer to that material. Depending on the level of abstraction used, representing a M:N relationship in an object representation diagram is fairly simple. For example, at the conceptual level, we can show the relationship between CLASS and STUDENT in Figure PG.5D-1: Figure PG.5D-1 The Relationship Between CLASS and STUDENT As you examine Figure PG.5D-1, note that: • A student must be registered in one or more CLASSes, and the student earns a GRADE in each CLASS. (Reminder: We’ve used CLASS to represent a Section of a course.) • The CLASS requires a COURSE, a PROFESSOR, and a ROOM. • The CLASS may have one or more STUDENTS, each of whom earns a GRADE in that CLASS. In other words, STUDENT is optional to CLASS. From a conceptual point of view, the preceding diagram captures both the nature and characteristics of the relationship between CLASS and STUDENT. At the implementation level, the object-oriented data model uses an intersection-class to manage M:N relationships only when additional information (attributes) about the M:N relationship between the objects is required. In this case, GRADE is our additional information, so a GRADE is associated with a CLASS and a STUDENT. The intersection-class is automatically included within the STUDENT and CLASS object space and represents the individual characteristics of the M:N relationship among them. For clarity’s sake we have label this new object as STU-REC. In this case the STU-REC object illustrates what students are in which Section, and in which Sections is the student registered? And what is the grade of each student registered in a Section? The object diagram in Figure PG.5d-2 shows such relationships: Figure PG.5D-2 The Object Diagram for Problem PG.5d As you discuss Figure PG.5D-2, note that STU_REC (the student record) is the intersection class that represents the M:N relationship between STUDENT and CLASS. e. Using an OO generalization, define a superclass PERSON for STUDENT and PROFESSOR. Describe this new superclass and its relationship to its subclasses. A superclass PERSON can be defined for STUDENT and PROFESSOR. PERSON will contain the following attributes: Attribute name Data Type NAME NAME DOB DOB ADDRESS ADDRESS STUDENT and PROFESSOR will inherit the above attributes from their superclass PERSON. The class hierarchy will look like Figure PG.5E. Figure PG.5e The Class Hierarchy As you discuss Figure PG.5E, note the differences between inheritance and interclass relationships. Explain that: • Inheritance is automatic. • Inheritance moves from top to bottom within the class hierarchy. • Inheritance represents a 1:1 relationship between the superclass and its subclass(es). • Inheritance need not be explicitly defined through the attribute data type. In contrast, interclass relationships must be defined explicitly through the attribute's data type. In addition, interclass relationships may represent a 1:1, a 1:M, or a M:N relationship. 6. Convert the following relational database tables to the equivalent OO conceptual representation. Explain each of your conversions with the help of a diagram. (Note: The R&C Stores database includes the three tables shown in Figure PG.6) FIGURE PG.6 The R&C Stores Database The conversion is shown in Figure PG.6-1. Figure PG.6-1 The Completed OO Conceptual Representation for the R&C Stores Database Note that Figure PG.6-1 reflects the following conditions: • Each REGION can have many STOREs. • The STORE object includes references to the REGION and EMPLOYEE objects. The EMPLOYEE object references reflect that an employee is a manager of a store and that each store employs many employees. • The EMPLOYEE object has reciprocal relationships with the STORE object. These relationships reflect that each employee works at one store and that each store is managed by one employee. The latter relationship makes STORE optional to EMPLOYEE, because not all employees manage a store. 7. Convert the following relational database tables to the equivalent OO conceptual representation. Explain each of your conversions with the help of a diagram. ) Note: The Avion Sales database includes the tables shown in Figure PG.7). FIGURE PG.7 The Avion Sales Database The OO representation is shown in Figure PG.7-1. Figure PG.7-1 The Completed OO Conceptual Representation for the Avion Sales Database 8. Using the ERD shown in Appendix C, “The University Lab Conceptual Design Verification, Logical Design, and Implementation,” Figure C.22 (the Check_Out component), create the equivalent OO representation. Figure E.22 in Appendix C shows how the M:N relationship of USER and ITEM can be implemented by modeling this relationship through the Check_Out (bridge) entity. The OO representation of the M:N USER and ITEM relationship uses a CHECKOUT object. This object will have its own attributes and it will reference the USER and ITEM objects as shown in Figure PG.8. Note that the CHECKOUT object is a complex object that contains a group of repeating attributes: item, location, quantity, and date in. Figure PG.8 The Completed OO Conceptual Representation for Figure E.22's Check-Out Component 9. Using the contracting company’s ERD in Chapter 6, “Normalization of Database Tables,” Figure 6.15, create the equivalent OO representation. Figure 6.15 depicts the M:N relationship between EMPLOYEE and PROJECT. The object representation of this relationship is shown in Figure PG.9. Figure PG.9 The Completed OO Conceptual Representation for Figure 6.15's Contracting Company ERD Solution Manual for Database Systems: Design, Implementation, and Management Carlos Coronel, Steven Morris 9781337627900, 9781305627482