Systems Analysis and Design in a Changing World, Fourth Edition -Solutions 12

Systems Analysis and Design in a Changing World, Fourth Edition

12-1

Chapter 12 – Designing Databases Solutions to End-of-Chapter Material Review Questions 1.

List the components of a DBMS, and describe the function of each. Application program interface – An interface engine or library of precompiled subroutines that enable application programs (such as those written in C or Java) to interact with the database. End-user query processor – A program or utility that allows end users to retrieve data and generate reports without writing application programs. Data definition interface – A program or utility that allows a database administrator to define or modify the content and structure of the database (for example, add new fields or redefine data types or relationships). Data access and control logic – The system software that controls access to the physical database and maintains various internal data structures (for example, indices and pointers). Database – The physical data store (or stores) combined with the schema. Schema – A store of data that describes various aspects of the “real” data, including data types, relationships, indices, content restrictions, and access controls. Physical data store – The “real” data as stored on a physical storage medium (for example, a magnetic disk).

2.

What is a database schema? What information does it contain? A database schema is a store of data that describes the content and structure of the physical data store (sometimes called metadata—data about data). It contains a variety of information about data types, relationships, indices, content restrictions, and access controls.

3.

Why have databases become the preferred method of storing data used by an information system? Databases are a common point of access, management, and control. They allow data to be managed as an enterprise-wide resource while providing simultaneous access to many different users and application programs. They solve many of the problems associated with separately maintained data stores, including redundancy, inconsistent security, and inconsistent data access methods.

Systems Analysis and Design in a Changing World, Fourth Edition

4.

12-2

List four different types of database models and DBMSs. Which are in common use today? The four database models are hierarchical, network (CODASYL), relational, and objectoriented. Hierarchical and network models are technologies of the 1960s and 1970s and are rarely found today. The relational model was developed in the 1970s and widely deployed in the 1980s and 1990s. It is currently the predominant database model. The object-oriented database model was first developed in the 1990s and is still being developed today. It is expected to slowly replace the relational model over the next decade.

5.

With respect to relational databases, briefly define the terms row and field. Row – The portion of a table containing data that describes one entity, relationship, or object. Field – The portion of a table (a column) containing data that describes the same fact about all entities, relationships, or objects in the table.

6.

What is a primary key? Are duplicate primary keys allowed? Why or why not? A primary key is a field or set of fields, the values of which uniquely identify a row of a table. Because primary keys must uniquely identify a row, duplicate key values aren’t allowed.

7.

What is the difference between a natural key and an invented key? Which type is most commonly used in business information processing? A natural key is a naturally occurring attribute of or fact about something represented in a database (for example, a human fingerprint or the atomic weight of an element). An invented key is one that is assigned by a system (for example, a social security or credit card number). Most keys used in business information processing are invented.

8.

What is a foreign key? Why are foreign keys used or required in a relational database? Are duplicate foreign key values allowed? Why or why not? A foreign key is a field value (or set of values) stored in one table that also exists as a primary key value in another table. Foreign keys are used to represent relationships among entities that are represented as tables. Duplicate foreign keys are not allowed within the same table because they would redundantly represent the same relationship. Duplicate foreign keys may exist in different tables because they would represent different relationships.

9.

Describe the steps used to transform an ERD into a relational database schema. 1. Create a table for each entity type. 2. Choose a primary key for each table. 3. Add foreign keys to represent one-to-many relationships.

Systems Analysis and Design in a Changing World, Fourth Edition

4. 5. 6. 7. 10.

12-3

Create new tables to represent many-to-many relationships. Define referential integrity constraints. Evaluate schema quality and make necessary improvements. Choose appropriate data types and value restrictions for each field.

How is an entity on an ERD represented in a relational database? Each entity on an ERD is represented as a separate table.

11.

How is a one-to-many relationship on an ERD represented in a relational database? A one-to-many relationship is represented by adding the primary key field(s) of the table that represents the entity participating in the “one” side of the relationship to the table that represents the entity participating in the “many” side of the relationship.

12.

How is a many-to-many relationship on an ERD represented in a relational database? A many-to-many relationship is represented by constructing a new table that contains the primary key fields of the tables that represent each participating entity.

13.

What is referential integrity? Describe how it is enforced when a new foreign key value is created, when a row containing a primary key is deleted, and when a primary key value is changed. Referential integrity is content constraint between the values of a foreign key and the values of the corresponding primary key in another table. The constraint is that values of the foreign key field(s) must either exist as values of a primary key or must be NULL. A valid value must exist in the foreign key field(s) before the row can be added. When a row containing the primary key is deleted, the row with the foreign key must also be deleted for the data to maintain referential integrity. A primary key should never be changed; but in the event that it is, the value of the foreign key must also be changed.

Systems Analysis and Design in a Changing World, Fourth Edition

14.

12-4

What types of data (or fields) should never be stored more than once in a relational database? What types of data (or fields) usually must be stored more than once in a relational database? Non-key fields should never be stored more than once. If a table represents an entity, the primary key values of each entity represented in the table are redundantly stored (as foreign keys) for every relationship in which the entity participates.

15.

What is relational database normalization? Why is a database schema in third normal form considered to be of higher quality than an unnormalized database schema? Relational database normalization is a process that increases schema quality by minimizing data redundancy. A schema with tables in third normal form has less non-key data redundancy than a schema with unnormalized tables. Less redundancy makes the schema and database contents easier to maintain over the long term.

16.

Describe the process of relational database normalization. Which normal forms rely on the definition of functional dependency? The process of normalization modifies the schema and table definitions by successively applying higher order rules of table construction. The rules each define a normal form, and the normal forms are numbered one through three. First normal form eliminates repeating groups that are embedded in tables. Second and third normal forms are based on a concept called functional dependency—a one-to-one correspondence between two field values. Second normal form ensures that every field in a table is functionally dependent on the primary key. Third normal form ensures that no non-key field is functionally dependent on any other non-key field.

17.

Describe the steps used to transform a class diagram into an object database schema. 1. 2. 3. 4.

Determine which classes require persistent storage. Define persistent classes within the schema. Represent relationships among persistent classes. Choose appropriate data types and value restrictions.

Systems Analysis and Design in a Changing World, Fourth Edition

18.

12-5

What is the difference between a persistent class and a transient class? Provide at least one example of each class type. An object of a transient class exists only for the duration of a program execution (for example, the user interface of the program). An object of a persistent class (for example, a customer object in a billing system) retains its identity and data content between program executions.

19.

What is an object identifier? Why are object identifiers required in an object database? An object identifier is a key or storage address that uniquely identifies an object within an object-oriented database. Object identifiers are needed to represent relationships among objects. A relationship is represented by embedding the object identifier of a participating object in the other participating object.

20.

How is a class on a class diagram represented in an object database? A class on a class diagram is represented “as is” in an object database. That is, each object of the class type is stored in the database along with its data content and methods.

21.

How is a one-to-many relationship on a class diagram represented in an object database? The object identifier of each participating object is embedded in the other participating object. The object on the “one” side of the relationship might have multiple embedded object identifiers to represent multiple participants on the “many” side of the relationship.

22.

How is a many-to-many relationship without attributes represented in an object database? The object identifier of each participating object is embedded in the other participating object. The objects on both sides of the relationship might have multiple embedded object identifiers to represent multiple participants on the other side of the relationship.

23.

What is an association class? How are association classes used to represent many-tomany relationships in an object database? An association class is an “artificial” class that is created to represent a many-to-many relationship among “real” classes. The association class has data members that represent attributes of the many-to-many relationship. Each “real” class implements a one-to-many relationship with the association class.

24.

Describe the two ways in which a generalization relationship can be represented in an object database. Generalization relationships can be represented directly (for example, using the ODL keyword extends) or indirectly as a set of one-to-one relationships.

Systems Analysis and Design in a Changing World, Fourth Edition

25.

12-6

Does an object database require key fields or attributes? Why or why not? Key fields aren’t required because they aren’t needed to represent relationships. However, they are usually included because they are useful for a number of reasons, including guaranteeing unique object content and searching or sorting database content.

26.

Describe the similarities and differences between an ERD and a class diagram that models the same underlying reality. Each entity on an ERD corresponds to one class on a class diagram. The one-to-one, oneto-many, and many-to-many relationships among those classes are the same as those on the ERD.

27.

How are classes and relationships on a class diagram represented in a relational database? A class is represented as a table. A one-to-many relationship among classes is represented in the same way as a one-tomany among entities (see answer #11). A many-to-many relationship among classes is represented in the same way as a many-tomany among entities (see answer #12). Note that the table that represents the relationships serves the same purpose as an association class.

28.

What is the difference between a primitive data type and a complex data type? A primitive data type (for example, integer, real, or character) is directly supported (represented) by the CPU or a programming language. A complex data type (for example, record, linked list, or object) contains one or more data elements constructed using the primitive data types as building blocks.What are the advantages of having an RDBMS provide complex data types? Providing complex data types in the RDBMS allows a wider range of data to be represented. It also minimizes compatibility problems that might result from using different programming languages or hardware.

29.

Does an ODBMS need to provide predefined complex data types? Why or why not? No. A required complex data type can be defined as a new class.

30.

Why might all or part of a database need to be replicated in multiple locations? Database accesses between distant servers and clients must traverse one or more network links. This can slow the accesses due to propagation delay or network congestion. Access speed can be increased by placing a database replica close to clients.

Systems Analysis and Design in a Changing World, Fourth Edition

31.

12-7

Briefly describe the following distributed database architectures: replicated database servers, partitioned database servers, and federated database servers. What are the comparative advantages of each? Replicated database servers – An entire database is replicated on multiple servers, and each server is located near a group of clients. Best performance and fault tolerance for clients because all data is available from a “nearby” server. Partitioned database servers – A database is partitioned so that each partition is a database subset used by a single group of clients. Each partition is located on a separate server, and each server is located close to the clients that access it. Better performance and less replication traffic than replicated servers if similar collocated clients use only a subset of database content. Federated database servers – Data from multiple servers with different data models and/or DBMSs is pooled by implementing a separate (federated) server that presents a unified view of the data stored on all the other servers. The federated server constructs answers to client queries by forwarding requests to other servers and combining their responses for the client. Simplest and most manageable way to combine data from disparate DBMSs into a single unified data store.

32.

What additional database management complexities are introduced when database contents are replicated in multiple locations? Replicated copies are redundant data stores. Thus, any changes to data content must be redundantly implemented on each copy. Implementing redundant maintenance of data content requires all servers to periodically exchange database updates.

Systems Analysis and Design in a Changing World, Fourth Edition

12-8

Thinking Critically 1.

The Universal Product Code (UPC) is a bar coded number that uniquely identifies many products sold in the United States. For example, all copies of this textbook sold in the United States have the same UPC bar code on the back cover. Now consider how the design of the RMO database might change if all items sold by RMO were required by law to carry a permanently attached UPC (for example, on a label sewn into garments). How might the RMO relational database schema change under this requirement? The change to the schema is relatively simple. ProductID is replaced with the UPC bar code both as the primary key of ProductItem and all corresponding foreign keys. The change might be more complex if the DBMS were previously responsible for generating values of ProductItem.Number. That function would now be removed from the DBMS because the key values would be externally assigned.

2.

Assume that RMO plans to change its pricing policy. If two or more catalogs are in circulation at the same time, all item prices in the catalogs must be the same. Prices can still rise or fall over time, and those changes will be recorded in the database and printed in newly issued catalogs. Any customer who makes an order will always be given the lower of the current price or the price in the current catalog. What changes to the tables shown in Figure 12-9 will be required to ensure that the RMO database is in 3NF after the pricing policy change? If Price for a single ProductItem cannot vary across catalogs, Price in CatalogProduct is functionally dependent on only ProductID. Thus, CatalogProduct is in 1NF but not 2NF or 3NF. To correct the problem, Price must be removed from CatalogProduct and placed in ProductItem.

3.

Assume that RMO will begin asking a random sample of customers who make orders by telephone about purchases made from competitors. RMO will give customers a 15 percent discount on their current order in exchange for answering a few questions. To store and use this information, RMO will expand the ERD and class diagram with two new entities (classes) and three new relationships. The new entities (classes) are Competitor and ProductCategory. Competitor has a one-tomany relationship with ProductCategory, and the existing Customer entity (class) also has a one-to-many relationship with ProductCategory. Competitor has a single field (attribute) called Name. ProductCategory has four fields (attributes): Description, DollarAmountPurchased, MonthPurchased, and YearPurchased. Revise the relational database schema shown in Figure 12-9 to include the new entities and relationships. All tables must be in 3NF. The following tables must be added to the relational database schema: Competitor = Name ProductCategory = CompetitorName, CustomerAccountNo, MonthPurchased, YearPurchased, Description, DollarAmountPurchased

Systems Analysis and Design in a Changing World, Fourth Edition

12-9

Primary keys are shown in bold, and foreign keys are shown in italics. Note that the primary key of ProductCategory is guaranteed to be unique only if multiple customer purchases from a competitor in the same month and for the same product category (description) are combined in a single row. 4.

Assume that RMO is developing its database using object-oriented methods. Assume further that the database designers want to make some changes to the class diagram in Figure 12-15. Specifically, they want to make ProductItem an abstract parent class from which more specific product classes are specialized. Three specialized classes will be added: ClothingItem, EquipmentItem, and OtherItem. ClothingItem will add the attribute color, and that same attribute will be removed from the InventoryItem class. Equipment item will also add an attribute called color but will not have an attribute called gender. OtherItem will have both the color and gender attributes. Revise the relational database schema in Figure 12-24 to store the new ProductItem generalization hierarchy. Use a separate table for each of the specialized classes. The new and revised table descriptions are: Table ProductItem InventoryItem ClothingItem EquipmentNumber OtherItem

5.

Attributes ProductID, Vendor, Description Number, ProductID, Size, Options, QuantityOnHand, AverageCost, ReorderQuantity ProductID, Color, Gender ProductID, Color ProductID, Color, Gender

Assume that RMO will use a relational database as shown in Figure 12-9. Assume further that a new catalog group located in Milan, Italy, will now create and maintain the catalog. To minimize networking costs, the catalog group will have a dedicated database server attached to its LAN. Develop a plan to partition the RMO database. Which tables should be replicated on the catalog group’s local database server? Update Figure 12-33 to show the new distributed database architecture. The catalog group will most likely require access to the following tables (access types are shown in parentheses following each table name): Catalog (CRUD) CatalogProduct (CRUD) InventoryItem (R) ProductItem (R) Updates to all of these tables are assumed to be relatively infrequent and, thus, the performance cost of complete replication with immediate or frequent updates is minimal. Milan can be represented in Figure 10-32 in the same manner as the warehouse, mail-order center, and phone-order center.

Systems Analysis and Design in a Changing World, Fourth Edition

6.

12-10

Revisit the issues raised in the Nationwide Books (NB) case at the beginning of the chapter. Should NB adopt an ODBMS for the new Web-based ordering system? Why or why not? The issues presented in the NB case are similar to those facing many organizations today. NB has a significant investment in relational database technology—including equipment, software, skills, and storing existing data—and many operational systems depend on that technology. Databases have a longer lifespan than many programs. As such, the following issues must be addressed:       

New programs must be adapted to older database technology. The organization must rewrite older programs to interact with a new DBMS. Parallel databases and DBMSs must be built, maintained, and synchronized. OO software development technology provides new and desirable capabilities, but many of those capabilities are reduced or eliminated if a relational DBMS is used. Interfacing OO software with a relational DBMS requires custom development and specific skills. Interfacing traditional software with an ODBMS also requires custom development and specific skills. (Currently, the interfacing techniques are poorly understood.) The sheer size of most databases and software inventories means that any conversion effort is an expensive, long-term project.

The last two issues are the crux of the current dilemma for NB. The problem is a classic tradeoff between short- and long-term costs. The short-term costs of rewriting existing programs to a new DBMS and/or operating two DBMSs in parallel are very large. In comparison, the short-term costs of foregoing some benefits of new software technology for a single system are much smaller. But over the life of each new system, the costs add up. Delaying the switchover to new technology also puts the organization as a whole further and further behind the leading edge of technology. There is no clear answer to the question because there is too little information to completely justify either choice. Students usually argue for change on the basis that an IS organization should stay current. They tend to underestimate the cost of implementing the change and overvalue the immediate benefits of newer technology. IS operations personnel often argue against change as did the DBA in the case. They tend to undervalue the benefits of new technology and overestimate the cost of change. They are also more keenly aware of the risks involved in large-scale technology changes. When analyzing this case, students should focus more on recognizing the complex tradeoffs that are involved than on arriving at a final solution.

Systems Analysis and Design in a Changing World, Fourth Edition

12-11

Experiential Exercises 1.

This chapter did not discuss network databases in detail, but some database textbooks discuss them. Investigate the network database model and its use of pointers to represent relationships among record types. In what ways is the use of pointers in a network database similar to the use of object identifiers in an object database? Does the similarity imply that object databases are little more than a renamed version of an older DBMS technology? Navigation in an ODBMS is very similar to navigation in a CODASYL (network) database. Relationship sets in an ODBMS correspond with sets in a CODASYL database. However, the similarity between ODBMS and CODASYL does not extend beyond the issue of navigation. All other aspects of OO databases (for example, methods and inheritance) are not present in a CODASYL database.

2.

Access the Object Database Management Group Web site (www.odmg.org), and gather information on the current status of the ODMG standard. The ODMG completed its work in 2001 and was then disbanded. For languages other than Java, the organization considers its work finished with the ODMG 3.0 standard. For Java interfaces, the organization essentially handed off its standard to the Java Community Process, and the older work has been merged into the Java Data Objects (JDO) standard.

3.

Investigate the student records management system at your school to determine what database management system is used. What database model is used by the DBMS? If the DBMS isn’t object-oriented, find out what plans, if any, are in place to migrate to an ODBMS. Why is the migration being planned (or not being planned)? This question is an interesting follow-up to question 6 in the “Thinking Critically” section.

4.

Visit the Web site of an online catalog vendor similar to RMO (such as www.llbean.com) or an online vendor of computers and related merchandise (such as www.cdw.com). Browse the online catalog, and take note of the various types of information contained therein. Construct a list of complex data types that would be needed to store all of the online catalog information. Some examples of typical complex data types include:      

Graphic images in formats such as GIF and JPEG. Motion video in formats such as MPEG and AVI. Sound in formats such as WAV and MP3. Executable programs in formats such as Java and VBScript. Browser-formatted documents in HTML and XML. Hard-copy documents in formats such as Postscript or Acrobat.

Systems Analysis and Design in a Changing World, Fourth Edition

12-12

Systems Analysis and Design in a Changing World, Fourth Edition

12-13

Case Studies Case Study: The Real Estate Multiple Listing Service System 1.

Develop a relational database schema in 3NF. Table Agent Listing Office

2.

Fields Number, OfficeNumber, Name, OfficePhone, HomePhone, EmailAddress, CellPhone Number, AgentNumber, Address, YearBuilt, SquareFeet, NumberOfBedrooms, NumberOfBaths, OwnerName, OwnerPhone, AskingPrice, DateListed, DateLastUpdated, StatusCode Number, Name, ManagerName, Address, Phone, FAX

Develop an ODL database schema. class Agent { attribute integer Number attribute string Name attribute string OfficePhone attribute string HomePhone attribute string EmailAddress attribute string CellPhone relationship Office WorksFor inverse Office::HasAgent relationship Set Lists inverse Listing::IsListedBy } class Listing { attribute integer Number attribute string Address attribute integer YearBuilt attribute integer SquareFeet attribute integer NumberOfBedrooms attribute real NumberOfBaths attribute string OwnerName attribute string OwnerPhone attribute integer AskingPrice attribute string DateListed attribute string DateLastUpdated attribute integer StatusCode relationship Agent IsListedBy inverse Agent::Lists }

Systems Analysis and Design in a Changing World, Fourth Edition

class Office { attribute integer Number attribute string Name attribute string ManagerName attribute string Address attribute string Phone attribute string FAX relationship Set HasAgent inverse Agent::WorksFor }

12-14

Systems Analysis and Design in a Changing World, Fourth Edition

12-15

Case Study: The State Patrol Ticket Processing System 1.

Develop a relational database schema in 3NF. Table Court Driver Officer Ticket TicketOfficer

2.

Fields Number, Name, Address Number, Name, Address, ExpirationDate, DateOfBirth, Restriction Number, Name, Rank, PrimaryAssignment, MailingAddress Number, DriverNumber, CourtNumber, DateOfTicket, Time, Location, ViolationType, FineAmount, DatePaid, Plea, TrialDate, Verdict TicketNumber, OfficerNumber

Develop an ODL database schema. class Court { attribute integer Number attribute string Name attribute string Address relationship Set Tries inverse Ticket::TriedIn } class Driver { attribute integer Number attribute string Name attribute string Address attribute string ExpirationDate attribute string DateOfBirth attribute integer Restriction relationship Set Violations inverse Ticket::BelongsTo } class Officer { attribute integer Number attribute string Name attribute string Rank attribute string PrimaryAssignment attribute string MailingAddress relationship Set Writes inverse Ticket::WrittenBy }

Systems Analysis and Design in a Changing World, Fourth Edition

12-16

class Ticket { attribute integer Number attribute string DateOfTicket attribute integer Time attribute string Location attribute integer ViolationType attribute integer FineAmount attribute string DatePaid attribute integer Plea attribute string TrialDate attribute integer Verdict relationship Driver BelongsTo inverse Driver::Violations relationship Court TriedIn inverse Court::Tries relationship Set WrittenBy inverse Officer::Writes }

Case Study: Computer Publishing Incorporated 1.

Consider the contents of this textbook as a template for CPI’s database content. Draw an ERD and class diagram that represents the book and its key content elements. Which diagram is a more accurate representation of book content? Expand your diagrams to include related product content such as a set of PowerPoint slides, an electronic book formatted as a Web site, and a Web-based test bank. The ERD depicts the hierarchical relationship among the content elements of the textbook. Most of the content is captured in the entities named Book, Chapter, Heading, Text Content, and Graphic Content. Note that Heading has a recursive relationship for nested levels of headings. The granularity of the entity Text Content is undefined, but it would most likely be sentences or paragraphs. Each Graphic Content entity is related to one or more Text Content entities that contain a reference (for example, the phrase Figure 12-5 in a text paragraph). Some relationships have been omitted to simplify the diagram. For example, Key Term should be related to Text Content. There should be several relationships between Index and other entities such as Key Term and Text Content. Many other entities, including Learning Objective, Opening Case, and Overview, could also have relationships with Text Content, Graphic Content, or both.

Systems Analysis and Design in a Changing World, Fourth Edition

12-17

The classes in the class diagram are essentially the same as the entities in the ERD. The entity Question in the ERD is a placeholder for all possible question types. The equivalent class is the parent class of a generalization-specialization hierarchy, which is a more precise representation of the relationships among those classes. Most other relationships in the class diagram are whole-part relationships, which is also a more precise representation. Because its representation of relationships is more precise, the class diagram is a more accurate representation of the textbook’s content.

Systems Analysis and Design in a Changing World, Fourth Edition

12-18

Expanding the model to include Web sites and PowerPoint presentations with the same content would be difficult. In essence, the top part of each diagram is a hierarchical structure that mirrors the physical structure of a book. Web sites and PowerPoint presentations would have a different set of organizational (or aggregate) entities (or classes) and relationships to the same entities (or classes) at the bottom of the diagrams. Drawing all of the entities (or classes) and relationships on a single page would look like a plate of spaghetti. The only practical approach would be to create a separate diagram for each different “packaging” of the content. 2.

Develop a list of data types required to store the content of the book, slides, and Web sites. Are the relational DBMS types listed in Figure 12-26 sufficient?

Systems Analysis and Design in a Changing World, Fourth Edition

12-19

Figures could be represented as LONGRAW if the data types shown in Figure 12-26 were the only possibilities. Other types that couldn’t be part of a printed book, such as sound files and animations, would also have to be represented as LONGRAW data types. Hyperlinks would have to be represented as VARCHAR data types. The relational data types are sufficient, but they fail to capture the true nature of the stored data. 3.

What features of an ODBMS, beyond or different from RDBMS features, might be useful when implementing CPI’s database? Give examples of how they might be used. An ODBMS implementation would allow for custom-developed data types for different content features. It would also provide method storage, making it possible to store formatting rules specific to content type. For example, the class Graphic Element might include an image stored as a bitmap and a caption stored as Unicode text. Various methods could be defined to display the graphic in a format suitable to a particular medium (for example, black and white, color, low resolution, or high resolution). Methods could also be defined to print the full image on some media (for example, paper) and only a hyperlinked caption on other media (for example, Web pages intended for downloading over slow network connections). The majority of the code needed to generate a “finished product” could be stored in the database.

Case Study: Rethinking Rocky Mountain Outfitters 1.

Update the RMO relational database design in Figure 12-9 based on the changes that you made to the ERD. Be sure that all your database tables are in 3NF. The database must now store information about customer charge accounts, charges, and payments. Because some of the information is already stored in the existing database structure, this requirement raises the following issues related to third normal form:  

The existing AccountNo field can also be a customer’s charge account number. One of the values of PaymentMethod in OrderTransaction can be “RMO charge” or something similar. In that case, customer charges are already stored in the OrderTransaction table.

Under these assumptions, the only data that must be added to the database is customer payments and whether the customer has as RMO charge account. The following additions and changes will store that information. Table Customer Payment

Fields AccountNo, Name, BillingAddress, ShippingAddress, DayTelephoneNumber, NightTelephoneNumber, HasRMOChargeAccount AccountNo, Date, Amount

One Boolean field, HasRMOChargeAccount, has been added to the Customer table. The Payment table stores information about customer payments. The new table’s primary key is the combination of AccountNo and Date, which assumes that a customer will never

Systems Analysis and Design in a Changing World, Fourth Edition

12-20

make two payments on the same day. AccountNo in the Payment table is also a foreign key. Note that there is no field to represent the charge account balance. Strict application of the 3NF rule does not allow such a field because it can be computed using data in the OrderTransaction and Payment tables for a specific customer. However, this assumes that transaction and payment information will be stored indefinitely in the database. A more reasonable assumption is that older data will be periodically removed from the database, in which case a CurrentBalance field should be added to the Customer table. 2.

Write ODL schema specifications for all the new classes and relationships that you added to the class diagram. The ODL description for Customer includes only the new relationship to Payment called MadePayment. The ODL description for Payment includes all of its attributes and the inverse relationship PaidByCustomer. class Customer { relationship set MadePayment inverse Payment::PaidByCustomer } class Payment { attribute string date attribute integer amount relationship Customer PaidByCustomer inverse Customer::MadePayment }

3.

Verify that the new classes and relationships are accurately represented in the updated relational database design that you developed for question 1. The table created in answer #1 can also serve as a hybrid object-relational schema without having to be modified.

Case Study: Focusing on Reliable Pharmaceutical Service 1.

Develop a relational database schema in 3NF. The table definitions are shown below. Primary keys are shown in bold, and foreign keys are shown in italics. Client Health-Care Organization OrganizationNumber

Name Address

Systems Analysis and Design in a Changing World, Fourth Edition

Client Unit ClientUnitNumber OrganizationNumber Name Address Floor Wing Drug ChemicalName DrugItem ChemicalName UnitType UnitDosage QuantityOnHand ReorderPoint ReorderQuantity Price DrugItemPackage UPC ManufacturerNumber ChemicalName UnitType UnitDosage PackageType PackageQuantity BrandName Price Manufacturer ManufacturerNumber Name Address Order OrderNumber ClientUnitNumber LicenseNumber Date

12-21

StartTime EndTime OrderItem OrderNumber PrescriptionNumber PatientNumber PatientName RoomNumber ChemicalName Manufacturer UnitType UnitDosage Quantity Frequency SpecialInstructions Patient PatientNumber ClientUnitNumber Name DateOfBirth Sex RoomNumber Pharmacist LicenseNumber Name Prescription PrescriptionNumber PatientNumber ChemicalName UnitType UnitDosage StartDate StartTime EndDate EndTime Quantity Frequency SpecialInstruction

Systems Analysis and Design in a Changing World, Fourth Edition

12-22

Comments: 



 2.

Key fields were invented for all tables except Pharmacist, Drug, Patient, and DrugItemPackage. The Patient number is assumed to be externally assigned, so its uniqueness must be verified. If uniqueness isn’t guaranteed, a new internally generated key field must be added to the Patient table. DrugItem is an example of a weak entity type—that is, an entity whose existence and primary key are dependent on another entity, which, in this case, is Drug. Thus, ChemicalName is part of the primary key of DrugItem. The table Drug could be eliminated if there are no other attributes to be added OrderItem and DrugItemPackage are associative entities. Their primary keys are a combination of the keys of the entities that they associate.

Develop an ODL database schema. class ClientHealthCareOrganization { attribute string name attribute string address relationship set HasUnits inverse ClientUnit::IsPartOf class ClientUnit attribute string name attribute string address attribute int floor attribute string wing relationship ClientHealthCareOrganization IsPartOf inverse ClientHealthCareOrganization::HasUnits relationship Order Orders inverse Order::IsFor class Drug attribute string chemicalName relationship set DeliveredAs inverse DrugItem::DeliveryFormat class DrugItem attribute string unitType attribute string unitDosage attribute int quantityOnHand attribute int reorderPoint attribute int reorderQuantity attribute float price relationship Drug DeliveryFormat Inverse Drug::DeliveredAs relationship set PackagedAs Inverse DrugItemPackage::PackageOf

Systems Analysis and Design in a Changing World, Fourth Edition

relationship Prescription HasPrescriptions inverse Prescription::PrescribedDrugItem class DrugItemPackage attribute string upc attribute string packageType attribute int packageQuantity attribute string brandName attribute float price relationship DrugItem PackageOf Inverse DrugItem::PackagedAs relationship Manufacturer DistributedBy Inverse Manufacturer::Distributes class Manufacturer attribute string name attribute string address relationship set Distributes inverse DrugItemPackage::DistributedBy class Order attribute string date attribute string startTime attribute string endTime relationship set Contains inverse OrderItem::ContainedBy relationship Pharmacist ResponsiblePharmacist inverse Pharmacist:: IsResponsibleFor relationship ClientUnit IsFor inverse ClientUnit::Orders class OrderItem attribute string patientName attribute string roomNumber attribute string chemicalName attribute string manufacturer attribute string unitType attribute string unitDosage attribute int quantity attribute string frequency attribute string specialInstructions attribute float price relationship Order ContainedBy inverse Order::Contains relationship Prescription Fills inverse Prescription::IsFilledBy class Patient

12-23

Systems Analysis and Design in a Changing World, Fourth Edition

12-24

attribute string patientNumber attribute string name attribute string dateOfBirth attribute string sex attribute string roomNumber relationship set Prescriptions inverse Prescription::IsFor class Pharmacist attribute string licenseNumber attribute string name relationship set IsResponsibleFor inverse Order::ResponsiblePharmacist class Prescription attribute string startDate attribute string startTime attribute string endDate attribute string endTime attribute int quantity attribute string frequency attribute string specialInstructions relationship OrderItem IsFilledBy inverse OrderItem::Fills relationship Patient IsFor inverse Patient::Prescriptions relationship DrugItem PrescribedDrugItem inverse DrugItem::HasPrescriptions Comments:  

Most attributes are declared as strings though other specialized types might be more appropriate (such as for dates and times). All invented and foreign keys were removed because they aren’t strictly required; however, they can used to serve other purposes (for example, database searching).

Systems Analysis and Design in a Changing World, Fourth Edition

3.

12-25

Discuss the pros and cons of distributed database architecture. Which architectural approach (or combination of approaches) should Reliable employ in their new system after it is fully implemented? Distributed database architecture, when properly designed and configured, increases system reliability and performance at the expense of increased complexity and cost. System reliability increases when data is redundantly stored in multiple locations, allowing clients to switch among database servers in the event of server failure. Performance and reliability are increased when database servers are placed near their clients due to decreased congestion on WAN links, decreased delay in accessing distant resources, and lack of dependence on WAN links, which may become disabled. Redundant WAN links can improve the reliability of long-distance database access; however, they also increase system cost. Complexity and cost increase under distributed database architecture because there are more servers, software, and network connections to procure, manage, and maintain. Ensuring smooth operation of a distributed database management system is a complex task requiring specialized skills. In many cases, those skills must be replicated at all server locations; however, modern distributed management tools can alleviate that need to some degree. Reliable’s database system will be mission critical and must be very robust. In many cases, patient health is at risk if the system fails because prescriptions will be filled late. Thus, reliability should be a key characteristic of Reliable’s system, and database server redundancy should be an essential architectural feature of the system. Redundancy doesn’t have to go hand-in-hand with distribution. Redundant servers could be connected to distant clients via redundant high-capacity WAN links. The primary advantage of this approach is simpler administration and centralization of specialized management skills at a single location. Because those skills are in short supply and expensive, replicating them in remote semi-rural locations, such as Gallup and Las Cruces, might not be feasible. Instead, the most feasible and cost-effective alternative to managing the system might be to hire both site-specific and centralized administrators. The sitespecific administrators could have only limited database skills, while the centralized administrators should have highly proficient database skills.