(Solution Manual) Database Systems: Design, Implementation, & Management

Coronel, Morris, 1

Computer Science & Engineering

Solution Manual

1st Edition

• $15.00 $50.00

---

Description

Solution Manual for Database Systems: Design, Implementation, & Management, The downloadable file consists of 478 pages, and the total size of the file is 10.47 MB. Purchase now only for highly discounted price.

Author(s): Coronel, Morris

---

---

Study Note Preview

Appendix F Client/Server Systems 574 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 chang es in end user computing. Using Appendix F, S ection 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 c haracteristics 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 produc tivity. 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 t hese 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 e xpectations 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 cl ient/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 assig n 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 i llustrated 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 Client/Server Systems 575 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, creat ed 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 disc ussion 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 d iscussion question in detail. Specifically, this section shows how the change from traditional to client/server data processing affects the MIS function. Appendix F Client/Server Systems 576 Answers to Review Questions NOTE Since the answers to many of these questions are covered in detai l 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 th ose two computing styles diffe r, 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 focuse s 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 o n 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 distributin g 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. Th us 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, improve d 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 expla ined in greater de tail in section F.7.) Appendix F Client/Server Systems 577 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 de tailed 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 detai led 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 offer s an extensive description of the client and server components . This section also provide s 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 servi ces 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 co mmunicate. 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 chan nel. 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 provide s 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. Appendix F Client/Server Systems 578 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 concern ed 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. Section s F.3.4 and F.3.5 provide additional database middleware software details. 9. Suppose you are currently considering the purchas e 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 impleme nt 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 databa se 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.), thir d 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 manag ement 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 ab out these topics. Always r emember 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 no t the other way around. Unfortunately, in the real world this is a luxury enjoyed by few development projects! Appendix F Client/Server Systems 579 10. Describe and contrast the four client/server computing architectural styles that were introduced in this appendix . This question deals with ide ntifying 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.1 9, “Functional Logic Splitting in Four Client/Server Architect ural 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 mainf rame 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 introdu ction of client/server systems. The managerial issues in client/server systems management aris e 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. Appendix F Client/Server Systems 580 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 persona l 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 t he 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 ba sed on client/server strategy. (You might w ant 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 ou tput for these projects is a business q uality 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 581 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 d elineate 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 environ ment 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 comm on 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 a ny of its sub section s 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. Appendix G Object Oriented Databases 582 Answers t o 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 materia l. 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 rela ted 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 concep tually 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. Attrib utes 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 differenti ation 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. Appendix G Object Oriented Databases 583 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 overa ll 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 specif ic 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 m anipulate 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 co mposed 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, be havior, 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 t he concept of inheritance and the different types of inheritance. Use examples in your explanations. See Section s 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. Appendix G Object Oriented Databases 584 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 Hierarch y 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 Section s G.3.10 - G.4. Show Figure G.17, “Defining Three Abstract Dat a 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 O riented 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 an d 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 Cla ss 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 stude nts. What type of object is needed to depict th at 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 repr esent the M:N relationship between students and classes, you can use the schema shown in Figure Q G.13 to represent the M:N relationship between CLASS and STUDENT: Appendix G Object Oriented Databases 585 Figure Q G.13 The Object Schema for the Relationship between Student and Class CLASS STUDENT ENROLLENROLLSTU_SOC_SEC_NUM STU_LNAME STU_FNAME STU_ADDRESS STU_CITY STU_STATE STU_ZIPCODE CLASS_TAKEN: STU_CUM_GPA STU_SEM_GPAMSTUDENT CLASS: STUDENT: GRADE11ENROLL CLASS_CODE CLASS_DESCRIPTION TAKEN BY:MCLASS As you discuss Figure Q G.13, note the use of an inter Section class (ENROLL) to represent the M:N relationship between STUDENT and CLASS. This inter Section class contains the GRADE attribute, which represents the student's grade in a gi ven 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 i n 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.” Appendix G Object Oriented Databases 586 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 he lp 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.” Appendix G Object Oriented Databases 587 18. What are the e ssential 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 th e 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 s tatic 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, encapsul ation 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 con cept 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 b ased 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 depart ure, 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 include s 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. Appendix G Object Oriented Databases 588 21. Discuss the object/relational model's characteristics. See Section G.9, “How OO Concepts Have Influenced the Relational M odel.” 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 ta bles 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 P G.1). Appendix G Object Oriented Databases 589 FIGURE P G.1 The RRE Trucking Company Database Appendix G Object Oriented Databases 590 As you examine Figure P G.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 P G.1 The OO Conceptual Representation BASETRUCK_NUM c BASE: TRUCK_MILES n TRUCK_BUY_DATE d TRUCK_SERIAL_NUM c1TRUCK M CTRUCKBASE_CODE n BASE_CITY c BASE_STATE c BASE_AREA_CODE c BASE_PHONE c BASE_MANAGER c TRUCKS: BASE M CTRUCKTYPE_CODE n TYP_DESCRIPTION c TRUCKS:TYPE TYPETYPE:1 Note: c = character data d = date data n = numeric dataMM Figure P G.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 P G.1 as a source of information: a. Define the im plied business rules for the relationships. Given the tables in Figure P G.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 T RUCKs belonging to it. 1 1 Appendix G Object Oriented Databases 591 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 P G.1 you can conclude that: • BASE and TYPE are mandatory fo r 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 P G.2C The Conceptual Object Schema OLD: TX34 TRUCK_NUM: 5001 BASE: [BD39] TYPE: [DF56] TRUCK_MILES: 167123.5 TRUCK_BUY_DATE: 11/8/07 TRUCK_SERIAL_NUM: AA -322-12212 -W11TRUCK BASE_CITY: Nashville BASE_STATE: TN BASE_AREA_CODE: 615 BASE_PHONE: 123 -4567 BASE_MANAGER: Andrea D. Gallager TRUCKS: [Y678]OLD: BD39BASE OLD: DF56 TYPE_CODE: 1 TYPE_DESCRIPTION: Single box, double -axle TRUCKS: [Y54F]TYPE OLD: Y678 [TX34], [TX37], [TX65]CTRUCKOLD: Y54F [TX34]CTRUCK Appendix G Object Oriented Databases 592 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 P G.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 ob ject 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 P G.3b. Figure P G.3b The Conceptual Object Schema OLD: TX37 TRUCK_NUM: 5003 BASE: [BD39] TYPE: [DF48] TRUCK_MILES: 221346.6 TRUCK_BUY_DATE: 12/27/07 TRUCK_SERIAL_NUM: AC -445-78656 -Z99TRUCK BASE_CITY: Nashville BASE_STATE: TN BASE_AREA_CODE: 615 BASE_PHONE: 123 -4567 BASE_MANAGER: Andrea D. Gallager TRUCKS: [Y678]OLD: BD39BASE OLD: DF56 TYPE_CODE: 2 TYPE_DESCRIPTION: Single box, single -axle TRUCKS: [Y54F]TYPE OLD: Y678 [TX34], [TX37], [TX65]CTRUCKOLD: Y54F [TX37], [TX65], …… ...CTRUCKOLD: TX65 TRUCK_NUM: 5004 BASE: [BD39] TYPE: [DF56] TRUCK_MILES: 99894.3 TRUCK_BUY_DATE: 2/21/08 TRUCK_SERIAL_NUM: WG -11223144 -T34TRUCK OLD: DF48 TYPE_CODE: 1 TYPE_DESCRIPTION: Single box, double -axle TRUCKS: [Y54F]TYPE Appendix G Object Oriented Databases 593 As you examine Figure P G.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 c reate 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 P G.4.) Figure P G.4 The Conceptual Object Schema BASE_CITY: Nashville BASE_STATE: TN BASE_AREA_CODE: 615 BASE_PHONE: 123 -4567 BASE_MANAGER: Andrea D. Gallager TRUCKS: [Y678]OLD: BD39BASE OLD: DF56 TYPE_CODE: 1 TYPE_DESCRIPTION: Single box, double -axle TRUCKS: [Y54F]TYPE OLD: Y678 [TX34], [TX37], [TX65]CTRUCK OLD: Y54F [TX34]CTRUCKOLD: TX34TRUCKMAKER: Ford YEAR: 1992VEHICLE OLD: VF345 Attributes Inherited From the VEHICLE SuperclassMAKER: Ford YEAR: 1992 TRUCK_NUM: 5001 BASE: [BD39] TYPE: [DF56] TRUCK_MILES: 162123.5 TRUCK_BUY_DATE: 11/08/07 TRUCK_SERIAL_NUM: AA -322-12212 -W11Class/Subclass Relationship Interclass Relationships Appendix G Object Oriented Databases 594 5. Assume the following business rules: • A course contains many Section s, but each Section references only one course. • A Section is taught by o ne professor, but each professor may teach one or more different Section s of one or more courses. • A Section may contain many students, and each student may be enrolled in many Section s. • A Section may contain many students, and each student is enrolled in m any Section s, but each Section belongs to a different course. (Students may take many courses, but they cannot take many Section s of the same course. ) • Each Section is taught in one room, but each room may be used to teach different Section s of one or more courses. • A professor advises many students, but a student has only one advisor. Based on th ose 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 simpl e 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 P G.5a. Appendix G Object Oriented Databases 595 Figure PG.5a The Conceptual Object Schema STUDENTSTU_NUM C STU_LNAME C STU_FNAME C STU_ADDRESS C STU_CITY C STU_STATE C STU_ZIPCODE C ADVISOR: STU_CUM_GPA N STU_SEM_GPA NSTUDENT PROFESSOR SCHEDULE: CLASS1 GRADE NMCOURSE: ROOM: GRADE N11CLASS COURSE PROFESSORPROFESSOR:1 ROOM STUDENTENROLL:MCRS_CODE C CRS_DESCRIPTION C CRS_CREDIT N OFFERING:MCOURSE CLASSPROF_NUM C PROF_NAME C PROF_DOB D DEPT_CODE C TEACH_LOAD: MPROFESSOR CLASSM ADVISEES:BLDG_CODE C ROOM_NUM C RESERVATION: MROOM CLASS Note: C = Character D = Date N = Numeric 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 of fered) 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 advis es 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) Appendix G Object Oriented Databases 596 STUDENT ADVISOR INCLUDES PROFESSOR A STUDENT HAS ONE PROFESSOR (who advises that stu dent) PROFESSOR IS MANDATORY (a student must have an advisor) SCHEDULE INCLUDES CLASS A STUDENT MAY TAKE MANY CLASSES (i.e., SECTION S OF A COURSE) CLASS IS MANDATORY TO STUDENT (a student must take at least one Section of a course) CLASS REQUIRES A COURS E 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 P G.5B-1. Figure P G.5B-1 The Abstract Data Types (Classes) FIRST_NAME c INITIAL c LAST_NAME cNAME MONTH n DAY n YEAR nDOB STREET c APT_NUM c CITY c STATE c ZIPCODE cADDRESS 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 P G.5B-2. Appendix G Object Oriented Databases 597 Figure P G.5B-2 The Object Instance Representation for PROFESSOR PROF_NAME: [M45] PROF_DOB: [456] PROF_ADDRESS: [401] EPT_CODE: CIS TEACH_LOAD: [D40] ADVISEES: [X34]OID: 230843PROFESSOROID: M45 FIRST_NAME: June INITIAL: W LAST_NAME: HasselblattNAME STREET: North Side Blvd. APT_NUM : 1093B CITY: Paris STATE: TN ZIPCODE: 37892ADDRESSMONTH: 10 DAY: 30 YEAR: 1961DOB OID: 456 OID: [401] Within the new object space illustrated in Figure P G.5B-2, the PROFESSOR object instance now contains references to the NAME, DOB, and ADDRESS object instances. c. Use object -represen tation 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 interpret ation 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 Section s (classes), a professor teaches many classes, and a professor advises many students. Appendix G Object Oriented Databases 598 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 P G.5C. Figure P G.5C The Object Representation for an Object of the Class PROFESSOR OID: 230843 PROF_NAME: [M45] PROF_DOB: [456] PROF_ADDRESS: [401] DEPT_CODE: CIS TEACH_LOAD: [D40] ADVISEES: [X34]PROFESSOR STUDENT objectsCollection of STUDENT classes OID: X34 OID: 580 ……………. …………….OID: 556 ……………. …………….OID: 345 ……………. …………….OID: 346 ……………. …………….CLASS objectsCollection of SECTION classes OID: D40 OID: 380 ……………. …………….OID: 369 ……………. …………….OID: 349 ……………. …………….OID: A34332 ……………. ……………. Note that we have omitted the object instances for the classes NAME, DOB, and ADDRESS. (These classe s 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 .