ISBN-10:
0201674769
ISBN-13:
9780201674767
Pub. Date:
12/23/1999
Publisher:
Addison-Wesley
Database Solutions: A Step by Step Guide to Building Databases / Edition 1

Database Solutions: A Step by Step Guide to Building Databases / Edition 1

by Thomas Connolly, Carolyn Begg

Other Format

Current price is , Original price is $62.25. You
Select a Purchase Option (Older Edition)
  • purchase options

Product Details

ISBN-13: 9780201674767
Publisher: Addison-Wesley
Publication date: 12/23/1999
Series: Database Solutions Series
Edition description: Older Edition
Pages: 256
Product dimensions: 7.38(w) x 9.08(h) x 0.85(d)

About the Author

Thomas Connolly was a designer of RAPPORT, the world's first commercial portable DBMS, and of the LIFESPAN configuration management tool -- a winner of the British Design Award.

Carolyn Begg specializes in the application of database systems in biological research. They are both authors of the best-selling book Database Systems, also published by Addison-Wesley.



0201674769AB04062001

Read an Excerpt

PREFACE: Contents

 

Preface

Background

The database is now the underlying framework of the information system and has fundamentally changed the way many companies and individuals work. The developments in this technology over the past few years have produced database systems that are more powerful and more intuitive to use, and users are creating databases and applications without the necessary knowledge to produce an effective and efficient system. Looking at the literature, we found many excellent books that examine a part of the database development life-cycle. However, we found very few that covered analysis, design, and implementation and described the development process in a simple-to-understand way that could be used by both technical and non-technical readers.

Our original concept therefore was to provide a book primarily for the business community that explained as clearly as possible how to analyze, design, and implement a database. This would cover both simple databases consisting of a few tables and large databases containing tens to hundreds of tables. During the initial reviews that we carried out, it became clear that the book would also be useful for the academic community and provide a very simple and clear presentation of a database design methodology that would complement a more extensive recommended textbook, such as our own book Database Systems.

The methodology we present in this book for relational Database Management Systems (DBMSs)— the predominant system for business applications at present — has been tried and tested over the years in both industrial and academic environments. The methodology is divided into two phases:

a logical database design phase, in which we develop a model of what we're trying to represent while ignoring implementation details;

a physical database design phase, in which we decide how we're going to realize the implementation in the target DBMS, such as Access, Paradox, Oracle, Informix, or SQL Server.

We present each phase as a series of simple-to-follow steps. For the inexperienced designer, we expect that the steps will be followed in the order described, and guidelines are provided throughout to help with this process. For the experienced designer, the methodology can be less prescriptive, acting more as a framework or checklist.

Helping to understand database design

To help you use the methodology and understand the important issues, we provide a comprehensive worked example that is integrated through the book based on a video rental company called StayHome. To reinforce the methodology we work through a second case study in Chapters 18 and 19 based on a veterinary clinic called Perfect Pets.

To help you further, we have included additional database solutions in Appendix D (with corresponding SQL scripts included on the accompanying CD-ROM). Each solution has a small introduction, which you may like to read and then try to produce the database design yourself before looking at our sample solution.

Common data models

As well as providing you with additional experience of designing databases, Appendix D also provides you with many common data models that you may find useful. In fact, it has been estimated that one-third of a data model consists of common constructs that are applicable to most companies and the remaining two-thirds are either industry-specific or company-specific. Thus, most database design work consists of re-creating constructs that have already been produced many times before in other companies. The models featured may not represent your company exactly, but they may provide a starting point from which you can develop a more suitable model that matches your company's specific requirements. Some of the models we provide cover the following common business areas:

Customer order entry

Inventory control

Asset management

Project management

Course management

Human resource management

Payroll management.

UML (Unified Modeling Language)

Increasingly, companies are standardizing the way in which they model data by selecting a particular approach to data modeling and using it throughout their database development projects. A popular high-level data model used in logical database design, and the one we use in this book, is based on the concepts of the Entity-Relationship (ER) model. Currently there is no standard notation for an ER model. Most books that cover database design for relational DBMSs tend to use one of two conventional notations:

Chen's notation, consisting of rectangles representing entities and diamonds representing relationships, with lines linking the rectangles and diamonds;

Crow's Feet notation, again consisting of rectangles representing entities and lines between entities representing relationships, with a crow's foot at the end of a line representing a one-to-many relationship.

Both notations are well supported by current CASE tools. However, they can be quite cumbersome to use and a bit difficult to explain. In this book, we instead use the class diagram notation from the latest object-oriented modeling language called UML (Unified Modeling Language). UML is a notation that combines elements from the three major strands of object-oriented design: Rumbaugh's OMT modeling, Booch's Object-Oriented Analysis and Design, and Jacobson's Objectory. It is anticipated that UML will become a standard, and the Object Management Group (OMG) has adopted UML as the standard notation for object methods.

We believe you will find this notation easier to understand and use. To help, we provide an evaluation copy of the Rational Rose visual modeling tool on the accompanying CD-ROM. This tool supports UML and will allow you to create your ER diagrams.

Showing how to implement a design

We believe it is important to show you how to convert a database design into a physical implementation. In this book, we show how to implement the first case study (the video rental company called StayHome) in the Microsoft Access 97 DBMS. In contrast, we show how to implement the database design for the second case study (the veterinary clinic called Perfect Pets) in the Oracle 8 DBMS.

Who should read this book?

Who should read this book? We have tried to write this book in a self-

contained way. The exception to this is physical database design, where you need to have a good understanding of how the target DBMS operates. Our intended audience is anyone who needs to develop a database, including but not limited to the following:

information modelers and database designers;

database application designers and implementers;

database practitioners;

data and database administrators;

Information Systems, Business IT, and Computing Science professors specializing in database design;

database students, both undergraduate, advanced undergraduate, and graduate;

anyone wishing to design and develop a database application.

Structure of this book

We have divided the book into five parts and a set of four appendices:

Part 1 — Background. We provide an introduction to DBMSs and the relational model in Chapters 1 and 2. We also provide an overview of the database application lifecycle in Chapter 3.

Part 2 — Database analysis and design techniques. We discuss techniques for database analysis in Chapter 4 and show how to use some of these techniques to analyze the requirements for the video rental company StayHome. We show how to draw Entity-Relationship (ER) diagrams using UML in Chapter 5 and how to apply the rules of normalization in Chapter 6. ER models and normalization are important techniques that are used in the methodology we describe in Part 3.

Part 3 — Logical database design methodology. We describe a step-by-step approach for logical database design. In Step 1, we create a local logical data model for each view of the company. In Step 2, we map each model to a set of database tables, and in Step 3 we merge the local data models together to provide a global model of the company.

Part 4 — Physical database design methodology. We describe a step-by-step approach for physical database design. In Step 4, we design a set of base tables for the target DBMS. In Step 5, we choose file organizations and indexes. In Step 6, we consider the introduction of controlled redundancy to achieve improved performance. In Step 7, we design the security measures that will protect the data from unauthorized access. Finally, in Step 8 we monitor and tune the operational system. As we've just mentioned, we show you how to implement the design for the StayHome database application in Microsoft Access 97.

Part 5 — Second worked example. In Chapters 18 and 19, we work through a second case study for the veterinary clinic Perfect Pets. We show you how to implement the design for the Perfect Pets database application in Oracle 8.

Appendices. Appendix A examines the two main alternative ER notations: Chen's notation and the Crow's Feet notation. Appendix B provides a summary of the methodology as a quick reference guide. Appendix C provides some background information on file organization and storage structures that may help you understand some aspects of the physical database design methodology presented in Part 3. Appendix D provides a set of 15 common data models.

To make the book as readable as possible, we have adopted the following style and structure:

A set of objectives for each chapter, clearly highlighted at the start of the chapter.

A summary at the end of each chapter covering the main points introduced.

Each important concept that is introduced is clearly defined and highlighted by placing the definition in a box.

A series of notes and tips — you'll see these throughout the book with an icon adjacent to highlight them.

Diagrams are liberally used throughout to support and clarify concepts.

A very practical orientation. Each chapter contains many worked examples to illustrate the points covered.

A glossary at the end of the book, which you may find useful as a quick reference guide. We also tend to use the margins to give you a reference to the section of the book that defines a concept we're discussing.

Accompanying CD-ROM

The accompanying CD-ROM contains the following aids to help you with this book:

(1) An evaluation copy of the visual modeling tool, Rational Rose.

(2) An implementation of the StayHome database application in Microsoft Access 97.

(3) An SQL script to create an implementation of the Perfect Pets database application. This script can be used to create a database in many relational DBMSs, such as Oracle, Informix, and SQL Server.

(4) An SQL script for each common data model defined in Appendix D to create the corresponding set of base tables for the database application. Once again, these scripts can be used to create a database in many relational DBMSs.

Corrections and suggestions

As this type of textbook is so vulnerable to errors, disagreements, omissions, and confusion, your input is solicited for future reprints and editions. Comments, corrections, and constructive suggestions should be sent to Addison-Wesley at Pearson Education, or by electronic mail to:

thomas.connolly@paisley.ac.uk

Acknowledgments

This book is the outcome of many years of our work in industry, research, and academia. It is therefore difficult to name all the people who have directly or indirectly helped us in our efforts. For those people we are about to omit, we apologize now. However, special thanks and apologies must first go to our families, who over the years have been neglected while we have been writing our books.

We would like to thank Sally Mortimore, our editor, Alison Birtwell, publishing coordinator, Susan Harrison, production editor, and Annette Abel, copyeditor, for their marvelous help, advice, and encouragement. We would also like to thank the reviewers of this book, who contributed their comments, suggestions, and advice. In particular, we would like to mention Stuart Anderson, Andy Osborn, and Willie Favero.

We would also like to thank our secretaries Lyndonne MacLeod and June Blackburn, for their help and support during the years.

Thomas M. Connolly

Carolyn E. Begg

Glasgow, September 1999



0201674769P04062001

Table of Contents

Prefacexv
Part 1Background
1Introduction3
1.1Examples of the use of database systems3
1.2Database approach5
1.2.1The database5
1.2.2The Database Management System (DBMS)6
1.2.3Views6
1.2.4Components of the DBMS environment8
1.2.5DBMS architectures8
1.3Functions of a DBMS10
1.4Database design15
1.5Advantages and disadvantages of DBMSs15
2The relational model18
2.1What is a data model?19
2.2Terminology19
2.2.1Relational data structure19
2.2.2Properties of relational tables22
2.2.3Relational keys23
2.2.4Representing relational databases25
2.3Relational integrity27
2.3.1Nulls28
2.3.2Entity integrity28
2.3.3Referential integrity28
2.3.4Business rules29
2.4Relational languages29
3The database application lifecycle32
3.1The software crisis32
3.2The information systems lifecycle33
3.3The database application lifecycle34
3.4Database planning34
3.5System definition36
3.5.1User views36
3.6Requirements collection and analysis37
3.7Database design39
3.8DBMS selection41
3.9Application design41
3.9.1Transaction design42
3.9.2User interface design42
3.10Prototyping43
3.11Implementation44
3.12Data conversion and loading44
3.13Testing45
3.14Operational maintenance45
Part 2Database analysis and design techniques
4Fact-finding51
4.1When are fact-finding techniques used?52
4.2What facts are collected?52
4.3Fact-finding techniques54
4.3.1Examining documentation54
4.3.2Interviewing54
4.3.3Observing the business in operation56
4.3.4Research56
4.3.5Questionnaires56
4.4The StayHome case study58
4.4.1An overview58
4.4.2Database planning61
4.4.3System definition67
4.4.4Requirements collection and analysis69
4.4.5Database design79
5Entity-Relationship modeling81
5.1Entities82
5.2Relationships83
5.2.1Degree of a relationship84
5.2.2Recursive relationships85
5.3Attributes85
5.3.1Simple and composite attributes85
5.3.2Single-valued and multi-valued attributes86
5.3.3Derived attributes86
5.3.4Keys87
5.4Strong and weak entities88
5.5Multiplicity constraints on relationships89
5.5.1One-to-one (1:1) relationships90
5.5.2One-to-many (1:*) relationships91
5.5.3Many-to-many (*:*) relationships92
5.5.4Multiplicity for non-binary relationships93
5.5.5Cardinality and participation constraints95
5.6Attributes on relationships95
5.7Design problems with ER models96
5.7.1Fan traps97
5.7.2Chasm traps97
6Normalization102
6.1Introduction103
6.2Data redundancy and update anomalies103
6.2.1Insertion anomalies104
6.2.2Deletion anomalies105
6.2.3Modification anomalies105
6.3First normal form (1NF)106
6.4Second normal form (2NF)107
6.5Third normal form (3NF)111
Part 3Logical database design
7Overview of the methodology119
7.1Introduction to the database design methodology119
7.1.1What is a database design methodology?120
7.1.2What are the aims of a database design methodology?120
7.1.3Why build data models?121
7.1.4Critical success factors in database design124
7.2Overview of the database design methodology124
8Logical database design - Step 1129
Step 1Build local logical data model for each view130
Step 1.1Identify entities130
Step 1.2Identify relationships133
Step 1.3Identify and associate attributes with entities or relationships137
Step 1.4Determine attribute domains142
Step 1.5Determine candidate and primary key attributes143
Step 1.6Specialize/Generalize entities (optional step)146
Step 1.7Remove features not compatible with the relational model147
Step 1.8Check that model supports user transactions154
9Logical database design -- Step 2159
Step 2Create and check tables for each local logical data model159
Step 2.1Create tables for local logical data model160
Step 2.2Check table structures using normalization171
Step 2.3Check tables support user transactions172
Step 2.4Define integrity constraints175
Step 2.5Review local logical data model with users180
10Logical database design - Step 3181
10.1The Business view of StayHome182
10.1.1Users' requirements specification182
10.1.2Local logical data model184
Step 3Build and check global logical data model184
Step 3.1Merge local logical data models into global model187
Step 3.2Check global logical data model194
Step 3.3Check for future growth195
Step 3.4Review global logical data model with users196
11Advanced modeling techniques197
11.1Specialization/Generalization198
11.1.1Superclasses and subclasses198
11.1.2Superclass/Subclass relationships198
11.1.3Attribute inheritance199
11.1.4Specialization process200
11.1.5Generalization process200
11.1.6Constraints on superclass/subclass relationships202
11.2Creating tables to represent specialization/generalization204
Part 4Physical database design
12Physical database design - Step 4211
12.1Comparison of logical and physical database design212
12.2Overview of the physical database design methodology213
Step 4Translate global logical data model for target DBMS214
Step 4.1Design base tables for target DBMS215
Step 4.2Design business rules for target DBMS222
13Physical database design - Step 5227
13.1Understanding system resources228
13.2Step 5 Design physical representation230
Step 5.1Analyze transactions231
Step 5.2Choose file organizations237
Step 5.3Choose indexes240
13.3File organizations and indexes for StayHome with Microsoft Access 97245
13.3.1Guidelines for choosing indexes245
13.3.2Indexes for StayHome246
14Physical database design - Step 6249
Step 6Consider the introduction of controlled redundancy249
Step 6.1Consider derived data251
Step 6.2Consider duplicating columns or joining tables together253
15Physical database design - Step 7267
Step 7Design security mechanisms267
Step 7.1Design user views268
Step 7.2Design access rules270
16Physical database design - Step 8276
Step 8Monitor and tune the operational system276
17Sample StayHome queries using SQL and QBE279
17.1Introduction to Microsoft SQL and QBE279
17.1.1SQL279
17.1.2QBE (Query-By-Example)281
17.2Sample queries for StayHome282
Part 5Second worked example
18Perfect Pets - Logical database design293
18.1Perfect Pets293
18.1.1Data requirements293
18.1.2Transaction requirements296
18.2Using the logical database design methodology297
19Perfect Pets - Physical database design313
19.1Using the physicial database design methodology313
What next?339
Appendices
AAlternative data modeling notations343
A.1ER modeling using the Chen notation343
A.2ER modeling using the Crow's Feet notation343
BSummary of the database design methodology350
CFile organizations and indexes357
C.1Basic concepts358
C.2Heap files359
C.3Ordered files360
C.4Hash files362
C.5Indexes362
C.5.1Types of indexes363
C.5.2Secondary indexes363
C.5.3Multilevel indexes364
C.5.4B[superscript +]-Trees365
DCommon data models367
D.1Customer order entry368
D.2Inventory control371
D.3Asset management373
D.4Project management375
D.5Course management378
D.6Human resource management381
D.7Payroll management385
D.8Vehicle rentals387
D.9Student accommodation390
D.10Client transportation393
D.11Publisher printing395
D.12County library397
D.13Real estate rentals400
D.14Travel agent403
D.15Student results407
Glossary411
References419
Index421

Preface

Contents

 

Preface

Background

The database is now the underlying framework of the information system and has fundamentally changed the way many companies and individuals work. The developments in this technology over the past few years have produced database systems that are more powerful and more intuitive to use, and users are creating databases and applications without the necessary knowledge to produce an effective and efficient system. Looking at the literature, we found many excellent books that examine a part of the database development life-cycle. However, we found very few that covered analysis, design, and implementation and described the development process in a simple-to-understand way that could be used by both technical and non-technical readers.

Our original concept therefore was to provide a book primarily for the business community that explained as clearly as possible how to analyze, design, and implement a database. This would cover both simple databases consisting of a few tables and large databases containing tens to hundreds of tables. During the initial reviews that we carried out, it became clear that the book would also be useful for the academic community and provide a very simple and clear presentation of a database design methodology that would complement a more extensive recommended textbook, such as our own book Database Systems.

The methodology we present in this book for relational Database Management Systems (DBMSs) — thepredominant system for business applications at present — has been tried and tested over the years in both industrial and academic environments. The methodology is divided into two phases:

a logical database design phase, in which we develop a model of what we're trying to represent while ignoring implementation details;

a physical database design phase, in which we decide how we're going to realize the implementation in the target DBMS, such as Access, Paradox, Oracle, Informix, or SQL Server.

We present each phase as a series of simple-to-follow steps. For the inexperienced designer, we expect that the steps will be followed in the order described, and guidelines are provided throughout to help with this process. For the experienced designer, the methodology can be less prescriptive, acting more as a framework or checklist.

Helping to understand database design

To help you use the methodology and understand the important issues, we provide a comprehensive worked example that is integrated through the book based on a video rental company called StayHome. To reinforce the methodology we work through a second case study in Chapters 18 and 19 based on a veterinary clinic called Perfect Pets.

To help you further, we have included additional database solutions in Appendix D (with corresponding SQL scripts included on the accompanying CD-ROM). Each solution has a small introduction, which you may like to read and then try to produce the database design yourself before looking at our sample solution.

Common data models

As well as providing you with additional experience of designing databases, Appendix D also provides you with many common data models that you may find useful. In fact, it has been estimated that one-third of a data model consists of common constructs that are applicable to most companies and the remaining two-thirds are either industry-specific or company-specific. Thus, most database design work consists of re-creating constructs that have already been produced many times before in other companies. The models featured may not represent your company exactly, but they may provide a starting point from which you can develop a more suitable model that matches your company's specific requirements. Some of the models we provide cover the following common business areas:

Customer order entry

Inventory control

Asset management

Project management

Course management

Human resource management

Payroll management.

UML (Unified Modeling Language)

Increasingly, companies are standardizing the way in which they model data by selecting a particular approach to data modeling and using it throughout their database development projects. A popular high-level data model used in logical database design, and the one we use in this book, is based on the concepts of the Entity-Relationship (ER) model. Currently there is no standard notation for an ER model. Most books that cover database design for relational DBMSs tend to use one of two conventional notations:

Chen's notation, consisting of rectangles representing entities and diamonds representing relationships, with lines linking the rectangles and diamonds;

Crow's Feet notation, again consisting of rectangles representing entities and lines between entities representing relationships, with a crow's foot at the end of a line representing a one-to-many relationship.

Both notations are well supported by current CASE tools. However, they can be quite cumbersome to use and a bit difficult to explain. In this book, we instead use the class diagram notation from the latest object-oriented modeling language called UML (Unified Modeling Language). UML is a notation that combines elements from the three major strands of object-oriented design: Rumbaugh's OMT modeling, Booch's Object-Oriented Analysis and Design, and Jacobson's Objectory. It is anticipated that UML will become a standard, and the Object Management Group (OMG) has adopted UML as the standard notation for object methods.

We believe you will find this notation easier to understand and use. To help, we provide an evaluation copy of the Rational Rose visual modeling tool on the accompanying CD-ROM. This tool supports UML and will allow you to create your ER diagrams.

Showing how to implement a design

We believe it is important to show you how to convert a database design into a physical implementation. In this book, we show how to implement the first case study (the video rental company called StayHome) in the Microsoft Access 97 DBMS. In contrast, we show how to implement the database design for the second case study (the veterinary clinic called Perfect Pets) in the Oracle 8 DBMS.

Who should read this book?

Who should read this book? We have tried to write this book in a self-

contained way. The exception to this is physical database design, where you need to have a good understanding of how the target DBMS operates. Our intended audience is anyone who needs to develop a database, including but not limited to the following:

information modelers and database designers;

database application designers and implementers;

database practitioners;

data and database administrators;

Information Systems, Business IT, and Computing Science professors specializing in database design;

database students, both undergraduate, advanced undergraduate, and graduate;

anyone wishing to design and develop a database application.

Structure of this book

We have divided the book into five parts and a set of four appendices:

Part 1 — Background. We provide an introduction to DBMSs and the relational model in Chapters 1 and 2. We also provide an overview of the database application lifecycle in Chapter 3.

Part 2 — Database analysis and design techniques. We discuss techniques for database analysis in Chapter 4 and show how to use some of these techniques to analyze the requirements for the video rental company StayHome. We show how to draw Entity-Relationship (ER) diagrams using UML in Chapter 5 and how to apply the rules of normalization in Chapter 6. ER models and normalization are important techniques that are used in the methodology we describe in Part 3.

Part 3 — Logical database design methodology. We describe a step-by-step approach for logical database design. In Step 1, we create a local logical data model for each view of the company. In Step 2, we map each model to a set of database tables, and in Step 3 we merge the local data models together to provide a global model of the company.

Part 4 — Physical database design methodology. We describe a step-by-step approach for physical database design. In Step 4, we design a set of base tables for the target DBMS. In Step 5, we choose file organizations and indexes. In Step 6, we consider the introduction of controlled redundancy to achieve improved performance. In Step 7, we design the security measures that will protect the data from unauthorized access. Finally, in Step 8 we monitor and tune the operational system. As we've just mentioned, we show you how to implement the design for the StayHome database application in Microsoft Access 97.

Part 5 — Second worked example. In Chapters 18 and 19, we work through a second case study for the veterinary clinic Perfect Pets. We show you how to implement the design for the Perfect Pets database application in Oracle 8.

Appendices. Appendix A examines the two main alternative ER notations: Chen's notation and the Crow's Feet notation. Appendix B provides a summary of the methodology as a quick reference guide. Appendix C provides some background information on file organization and storage structures that may help you understand some aspects of the physical database design methodology presented in Part 3. Appendix D provides a set of 15 common data models.

To make the book as readable as possible, we have adopted the following style and structure:

A set of objectives for each chapter, clearly highlighted at the start of the chapter.

A summary at the end of each chapter covering the main points introduced.

Each important concept that is introduced is clearly defined and highlighted by placing the definition in a box.

A series of notes and tips — you'll see these throughout the book with an icon adjacent to highlight them.

Diagrams are liberally used throughout to support and clarify concepts.

A very practical orientation. Each chapter contains many worked examples to illustrate the points covered.

A glossary at the end of the book, which you may find useful as a quick reference guide. We also tend to use the margins to give you a reference to the section of the book that defines a concept we're discussing.

Accompanying CD-ROM

The accompanying CD-ROM contains the following aids to help you with this book:

(1) An evaluation copy of the visual modeling tool, Rational Rose.

(2) An implementation of the StayHome database application in Microsoft Access 97.

(3) An SQL script to create an implementation of the Perfect Pets database application. This script can be used to create a database in many relational DBMSs, such as Oracle, Informix, and SQL Server.

(4) An SQL script for each common data model defined in Appendix D to create the corresponding set of base tables for the database application. Once again, these scripts can be used to create a database in many relational DBMSs.

Corrections and suggestions

As this type of textbook is so vulnerable to errors, disagreements, omissions, and confusion, your input is solicited for future reprints and editions. Comments, corrections, and constructive suggestions should be sent to Addison-Wesley at Pearson Education, or by electronic mail to:

thomas.connolly@paisley.ac.uk

Acknowledgments

This book is the outcome of many years of our work in industry, research, and academia. It is therefore difficult to name all the people who have directly or indirectly helped us in our efforts. For those people we are about to omit, we apologize now. However, special thanks and apologies must first go to our families, who over the years have been neglected while we have been writing our books.

We would like to thank Sally Mortimore, our editor, Alison Birtwell, publishing coordinator, Susan Harrison, production editor, and Annette Abel, copyeditor, for their marvelous help, advice, and encouragement. We would also like to thank the reviewers of this book, who contributed their comments, suggestions, and advice. In particular, we would like to mention Stuart Anderson, Andy Osborn, and Willie Favero.

We would also like to thank our secretaries Lyndonne MacLeod and June Blackburn, for their help and support during the years.

Thomas M. Connolly

Carolyn E. Begg

Glasgow, September 1999



Customer Reviews

Most Helpful Customer Reviews

See All Customer Reviews