Database Application Programming with Linux


All the tools and techniques you'll need to get started on database programming with Linux Linux's popularity as an enterprise programming solution has skyrocketed recently thanks to support from major database software providers. With new software coming out each year, and constant improvements in existing software, programmers need to be able to develop database applications using Linux. Written by experts in the database and open source communities, this comprehensive, hands-on guide provides all the tools, ...
See more details below
Other sellers (Paperback)
  • All (12) from $1.99   
  • New (4) from $57.50   
  • Used (8) from $1.99   
Sending request ...


All the tools and techniques you'll need to get started on database programming with Linux Linux's popularity as an enterprise programming solution has skyrocketed recently thanks to support from major database software providers. With new software coming out each year, and constant improvements in existing software, programmers need to be able to develop database applications using Linux. Written by experts in the database and open source communities, this comprehensive, hands-on guide provides all the tools, techniques, and skills you'll need to start your way to becoming a Linux database expert. Bringing you quickly up to speed on real-world database development basics, the book begins with software design basics, including requirements gathering, database and user interface design, and Object-oriented design. You'll then discover in-depth discussions of database engines and APIs such as PostgreSQL, MiniSQL, Sybase, and Oracle, design tools and programming languages such as Java, Perl, and C. In addition, you'll learn more about application frameworks, components, and distributed components. And you'll find the most up-to-date coverage of Linux database applications to help make this an indispensable resource.
With this book, you'll gain a better understanding of the critical pieces of Linux project planning and development, including:
*Design and specification issues
*Database design and theory
*User interface design principles
*UML and Patterns for object-oriented analysis and design. You'll also learn about:
*Getting started with PostgreSQL, MySQL, Sybase, Oracle, and MiniSQL
*Implementation-level differences between variousdatabases
*Administration and modeling tools
*Programming with CORBA
*Example programs
*Reusable code
Read More Show Less

Editorial Reviews

A guide to building desktop database applications for Linux. Begins with software design basics, such as requirements gathering, database and user interface design, and object-oriented design, then discusses database engines and APIs, design tools and programming languages, application frameworks, and distributed components. Appendices offer SQL and UML references. For inexperienced programmers. Jepson is a programmer and consultant specializing in Internet and intranet database development. Annotation c. Book News, Inc., Portland, OR (
Read More Show Less

Product Details

  • ISBN-13: 9780471355496
  • Publisher: Wiley
  • Publication date: 7/17/2000
  • Edition number: 1
  • Pages: 528
  • Product dimensions: 7.53 (w) x 9.15 (h) x 1.21 (d)

Table of Contents

Ch. 1 Requirements 3
Ch. 2 Database Design 23
Designing a Database 24
SQL 44
Ch. 3 User Interface Design 61
The Development Process 61
Ch. 4 Construction 87
Finding Reusable Code 87
Style and Techniques 94
Algorithms 106
Building Routines and Modules 113
Ch. 5 Object-Oriented Programming 121
Characteristics of Object-Oriented Languages 122
Ch. 6 Software Engineering 133
Object-Oriented Development to the Rescue? 134
The Cathedral and the Bazaar 136
The Spiral Model, 4GL, and RAD 138
OO and 4GL 139
The Magic Cauldron 143
Ch. 7 Object-Oriented Analysis 147
The Unified Modeling Language 148
Using UML in Object-Oriented Analysis 150
Use Cases 152
The Conceptual Model 160
System Sequence Diagrams 170
Contracts 172
Ch. 8 Object-Oriented Design 179
Three-Tier Architecture 179
Patterns for Object-Oriented Design 183
Using UML in Object-Oriented Design 188
Collaboration Diagrams for Borrow Books 190
Class Diagrams 198
UI and Database Design in Context 202
From Design to Code 205
Ch. 9 Databases 215
What Is an RDBMS? 215
Getting Started with an RDBMS 222
Common Database Issues 241
Administrative Issues 257
Database Features Quick Reference 268
Ch. 10 Linux Development Tools Catalog 275
Database Tools 275
Drivers and Driver Managers 284
Modeling/Diagramming Tools 291
Ch. 11 Java, Swing, and JDBC 293
JDBC 293
Running the Example Programs 298
Using JDBC 299
Swing 311
Separating Content and Presentation 323
Ch. 12 DBI and Perl 335
The Perl DBI 335
User Interface in Perl 350
Object-Oriented Perl 372
Tangram: Object-Relational Mapping in Perl 375
Ch. 13 Gnome 387
Keeping Up with the Developers 388
The GNOME Application Framework 389
GNOME Programming 391
Overview of GNOME-DB 413
Using GNOME-DB 423
Programming GNOME-DB 425
Ch. 14 Software Architecture 449
Modularity and Troubleshooting 449
Architectural Choices 450
Message Passing Facilities 452
Networking 454
The Wonder of Relational Databases 456
Ch. 15 Introduction to CORBA 461
CORBA Terminology 462
CORBA Implementations for Linux 464
Using CORBA 465
CORBA Goodies 486
App. A SQL Reference 491
App. B UML Reference 501
Index 507
Read More Show Less

First Chapter

Note: The Figures and/or Tables mentioned in this sample chapter do not appear on the Web.



"Building a 4-foot tower requires a steady hand, a level surface, and 10 undamaged beer cans. Building a tower 100 times that size doesn't merely require 100 times as many beer cans. It requires a different kind of planning and construction altogether."

Steve McConnell, Code Complete

Recognizing the potential irony of having a reference to a Microsoft book in the first sentence of a book about Linux, we added three extra sentences much as you would pad a data structure with extra bytes in hopes of aligning it optimally in memory. But, there's nothing we can do about that quote up there. It's from the same book, and we like that quote, so there it stays!

In Code Complete (Microsoft Press, 1993), Steve McConnell suggests that building a physical structure is an appropriate metaphor for software construction. Building a medium-sized software system is very close in complexity and cost to building a single-family house. Building a large software system parallels the complexity and cost of a large office building.

As with constructing a physical structure, the cost of fixing mistakes goes up the longer the mistake goes undetected. If you realize you need to make a fundamental change to the foundation of a house just as the shingles are going on, the cost can be prohibitive. It's the same for software development: The earlier a defect is introduced, the more expensive it is to fix as time goes on. For example, an error in the requirements analysis may cost a negligible amount with respect to the overall cost of the project if it is detected while you are validating the requirements. It will cost significantly more if it is detected while you are implementing the software. For this reason, it's important to get the requirements right. Before you build a system, make sure you are solving the right problem.

In this chapter, we'll look at some approaches to the traditional problems of system design. However, in Chapter 6, "Software Engineering," we'll take a fresh look at these problems in the context of open source development processes.

Toward a System Design

To build a system, you need a good blueprint. The first step in developing this blueprint is to state the problem that the system will solve. From there, you can develop a requirements document that states what the functionality of the system will be. You can then design the system, starting with its architecture, and move on to the design of its individual components.

The Problem Definition

The problem definition states the problem that needs to be solved. When I wrote that last sentence, I was tempted to say "the problem that the system will solve," but even that supposes too much. As a general guideline, the problem definition should state the problem without specifying a solution, including whether a system will be developed to solve the problem. This leaves room for other solutions to problems, such as modifications to existing business processes. Like other stages of the requirements process, the prob-lem definition should be developed by the users, system designers, and developers working together.

Let's take a look at a problem definition that violates this guideline:

We need a system to capture the amount of time an employee spends working on a given task and store that information in a database so we can query it later.

This problem definition skips over the problem itself and jumps right to the solution. It would be better to say:

Our present method of tracking the amount of time an employee works on a given task is inefficient. This method uses a spreadsheet for each employee to track informa-tion. It is error-prone, difficult to extract information from, and difficult to consoli-date. Consolidating spreadsheets from multiple employees is the most time-consuming and error-prone part of this process.

Given a statement of the problem, you can move on to analyzing the problem and coming up with a requirements specification.

Requirements Analysis

The process of analyzing requirements begins with an analysis of the prob-lem definition, and goes on to define and specify the requirements. The requirements analysis is a process that brings you and the user community together to discuss what must be done. The problem definition is your first clue. At the end of the process, you'll have a document that states what the user needs and what the user will get.

Working with People

To do a thorough job of requirements analysis, you'll need to spend time with your user community, their managers, and other people affected by the system (such as the developers of systems that your system needs to exchange data with). All of these people are collectively referred to as stakeholders. To gather information for requirements analysis, you'll need to interview the stakeholders, converse with them to clarify ambiguities, and, ultimately, obtain their approval on the completed requirements document. This approval is colloquially called "buy-in," and reinforces the notion that the stakeholders have something invested in the success of the project.

In Software Engineering (Addison-Wesley, 1995), Ian Sommerville discusses several issues to keep in mind when you interact with stakeholders:

Differing terminology. Some stakeholders, such as end users, cannot articulate their needs in technical terms. Instead, they will articulate their needs using terms and concepts they are familiar with. These terms and concepts may not be familiar to you, the software engineer. You'll need to become familiar with the concepts and terminology of the problem's domain. If possible, ride shotgun with users and learn their business.

Misunderstanding of scope and scale. Stakeholders who are not versed in software engineering have no idea of the costs and complexity involved with software development. You should use metaphors (such as the one discussed at the beginning of this chapter) to explain how complicated software development is. Explain that it's easy to verify when something like a Web page is finished by inspection (and the fact that the Web browser doesn't generate an error when you load the document). You can't do this with software. In practice, you can't verify the correctness of software with 100-percent confidence.

Conflicting requirements. Different stakeholders may have requirements that conflict with others. This is especially likely if the group of stakeholders is made up of members from different communities and corporate cultures. Citing the requirements in a document that is readable by both you and the stakeholders helps everyone to come to a consensus on the end product. It also becomes the basis of a contract between the developers and the stakeholders.

External influences. Remember that political, business, and economic factors have an influence on the process. A high-level agenda may influence the way in which users deal with the requirements process. High-level organizational changes can result in a project being canceled. If business practices change, the requirements may also change.

The Analysis Process

Sommerville describes six activities that make up the requirements analysis process. These activities do not always happen in sequence. In other words, as you complete one activity, you may learn something that changes your understanding of an activity you've already completed. This iterative process is one of continual refinement. The following are some important steps in the analysis process:

Domain understanding. The domain is the area or realm that the problem affects. Before you analyze the problem and the requirements, you need to become an expert in the domain. For example, in investment banking, programmers often spend time on a trading desk to learn about the business. Some of them master the business so well, they become traders or analysts themselves. Many good software engineers have been lost this way!

Requirements collection. Don't wait until you've mastered the users' business to start learning about what they want. Interview the stakeholders to learn what kind of system they need. Write everything down. As you do this, you'll also develop a better understanding of the problem domain.

Classification. After you collect requirements, you'll no doubt be left with a random collection of notes written on cocktail napkins, index cards, and the back of your hand. Classification takes these random items and structures them by grouping similar or related items into the same general classifications. For example, you might classify all the attributes of a consultant (such as name, address, phone number) into data-related requirements, and all the activities (such as "set the consultant's rate," or "assign the consultant to a project") directly into functional requirements.

Conflict resolution. If the problem involves different stakeholders, you may be left with some conflicting requirements. You'll need to find these conflicts and resolve them. This process can be politically tricky. For example, in some cases, this conflict resolution can reanimate rivalries within the organization that had long slumbered.

Conflict resolution may also emphasize gaps in the knowledge of Pointy-Haired Bosses (of Dilbert fame: also known as PHBs). It's not always easy telling someone who signs the paychecks that he or she is wrong, but in many cases, the people in the trenches know better than the higher-ups. If you want to master the fine art of dealing with such situations, you might look at books on topics such as conflict management, interpersonal conflict, problem employees, or business communication.

Prioritization. Users may ask for the world. While you can't give it all to them, you can ask them to prioritize their needs. This lets you determine what is most important, and sets the stage for creating incremental deliverables later on in the process.

Validation. By now, you have a set of raw requirements. Next, you need to review the raw requirements to determine whether you have everything the stakeholders think they want. This won't be the last time you'll validate the requirements, but it's good to validate them before you move toward the final requirements document.

Assuming that we've been through this process with the problem definition that appears at the beginning of this chapter, the raw requirements might look like:

Timesheet System Requirements

A system is needed that automates the capture and reporting on the number of hours a consultant works on a project. Our company provides consulting services, and we need to track how the consultants spend their time, and use this information to invoice the customers.

Each consultant may be assigned to one or more projects. The rate for that consultant is determined on a per-project basis. A project is associated with a single customer, who is responsible for paying us the consultant's rate.

Each project is broken down into tasks that have a fixed start and end date. When a consultant submits the number of hours she worked on a given day, those hours must be associated with a particular task.

The system should track the following information about a consultant:

  1. First name.
  2. Last name.
  3. Address.
  4. Home phone number.
  5. Projects the consultant is assigned to.
  6. The rate at which the consultant is billed to each project.

The Staff Coordinator is responsible for assigning consultants to projects and setting their rates.

The system should track the following information about a project:

  1. Customer name.
  2. Customer address.
  3. Manager in charge of the project.
  4. Manager's phone number.
  5. Manager's fax number.
  6. Project name.
  7. Project start date.
  8. Project end date.

The Staff Coordinator is responsible for adding customers and projects to the system.

The system should track the following information about a task:

  1. Start date.
  2. End date.
  3. Company name.
  4. Project name.
  5. Task code.

The Clerk is responsible for maintaining a list of tasks.

The task must also contain a list of days and hours (a timesheet). Each timesheet must contain:

  1. The consultant's name.
  2. The week-ending date (the Saturday at the end of the week).

Each timesheet entry must contain:

  1. Day of week.
  2. Task code.
  3. Total hours.

How a consultant is to submit a timesheet. By 9: 00 A. M. every Thursday, the consultant should submit a timesheet for the preceding week. (This form is shown in Figure 1.1.)

How the Clerk is to enter a timesheet into the system. When all the timesheets have been collected, the Clerk will enter in each consultant's timesheet information. They need to give the system all the information that is on the timesheet.

How the Staff Coordinator gets the timesheet figures. The system should gener-ate a Weekly Summary Report that lists each customer name. For each customer name, the report should state the total number of hours for all consultants, and the total amount to bill the customer. Within each customer, the report must show each project, the total number of hours for all consultants who billed to that project, and the total amount to bill for that project. Within each project, the report must show the name and rate of each consultant who worked on the project, the name of the task he or she worked on, and the total amount of hours and dollar amount billed for that task. An example of the report is shown in Figure 1.2.

A Viewpoint Model for Analysis

Once you have the raw requirements written down and validated, you can make them easier to understand and absorb by using several representational models. For example, Sommerville suggests a viewpoint model. Used in conjunction with the raw requirements, viewpoint model diagrams can provide a great deal of insight about a system, and serve as the basis for the requirements document, system architecture, and detailed system design.

The viewpoint analysis takes a look at the requirements from the viewpoint of different users. Figure 1.3 shows a possible viewpoint hierarchy for the timesheet requirements.

Sommerville places the viewpoint model within a larger requirements analysis framework, which is worth investigating for further research on requirements analysis. For the purposes of the analysis in this chapter, the viewpoint hierarchy suffices to provide a visual representation of the requirements. This technique can also be used as inspiration for user scenarios (as described in Chapter 3, "User Interface Design") or use cases (see Chapter 7, "Object-Oriented Analysis") to arrive at a better understanding of the requirements.

The Formal Requirements Document

Sommerville points out three major problems with requirements that are specified in natural language. First, natural language is ambiguous. Anyone who has read a document in legalese knows the extremes to which we must go to make natural language precise. Second, a free-flowing natural language description can fail to distinguish between important categories of information (such as functional versus nonfunctional requirements, described in the next paragraph). Finally, requirements that are expressed using informal natural language may amalgamate requirements (that is, they may express multiple requirements as a single requirement).

To avoid these problems, we need to put the raw requirements into a more formal statement. The level of formality will depend on the complexity of your project and your own style. Aside from the format presented here, Sommerville discusses alternative formats, including Program Design Language (PDL), a structured pseudocode notation used to design programs. We discuss PDL in Chapter 4, "Construction."

The raw requirements we have discussed so far include only functional requirements, which are the requirements directly related to the purpose of the system. Another class of requirements is nonfunctional requirements. These are usually constraints, such as choice of operating system, development language, response time, and so forth.

In the formalized requirement that follows, I have used three guidelines, inspired by Sommerville:

Each requirement should express only one system task. Do not express multiple requirements as a single requirement.

Use a stylized notation. For example, the key points of a requirement are shown in bold, and a numbered outline system is used to group related requirements.

Justify each requirement. Notice that each requirement is accompanied by a rationale.

Here are the requirements for the timesheet system:

  1. Timesheet System Requirements

  2. 1.1 Overview of Business Needs
    A system is needed that automates the capture and reporting on the number of hours a consultant works on a project. Our company provides consulting services, and we need to track how the consultants spend their time, and use this information to invoice the customers.

    1. 1.1.1 The Consultant
      A consultant is an employee of the company who is hired out to various customers. Each consultant may be assigned to one or more projects. The rate for that consultant is determined on a per-project basis. A project is associated with a single customer, who is responsible for paying us the consultant's rate.

    2. 1.1.2 The Project
      Each project is broken down into tasks that have a fixed start and end date. When a consultant submits the number of hours she worked on a given day, those hours must be associated with a particular task.
2.1 Data Entities
The system should track certain entities, such as consultants and customers. Each entity has a number of attributes.

  1. 2.1.1 The Consultant
  2. The system should store the following information about a consultant:
  3. First name.
  4. Last name.
  5. Address.
  6. Home phone number.
  7. Projects the consultant is assigned to.
  8. The rate at which the consultant is billed to each project.

  9. 2.1.2 The Project
  10. The system should store the following information about a project:
  11. Customer name.
  12. Manager in charge of the project.
  13. Manager's phone number.
  14. Manager's fax number.
  15. Project name.
  16. Project start date.
  17. Project end date.

  18. 2.1.3 The Customer
  19. The system should store the following information about a Customer:
  20. Customer name.
  21. Customer address.

  22. 2.1.4 The Task
  23. The system should store the following information about a task:
  24. Start date.
  25. End date.
  26. Company name.
  27. Project name.
  28. Task code.

  29. 2.1.5 The Timesheet
  30. The task must also contain a list of days and hours (a timesheet). Each timesheet must contain:
  31. The consultant's name.
  32. The week-ending date (the Saturday at the end of the week).

    1. The Timesheet Entry
    2. Each timesheet entry (a line item on the time sheet that corresponds to work done on a task for a given day) must contain:
    3. Day of week.
    4. Task code.
    5. Total hours.

3.1 Data Entry Requirements
The system shall provide various forms to support entering data into the system.

3.1.1 Consultant-Related Data Entry
The system shall provide a Consultant Maintenance form, which must support the following operations:

  1. Add a Consultant
    The Consultant Maintenance form must allow the user to add a consultant to the system. To add a consultant, the user must supply the Consultant's first name, last name, address, and home phone number.
    Rationale: As new consultants join our company, we need to add them to the system.

  2. Delete a Consultant
    The Consultant Maintenance form must allow the user to delete a consultant from the system.
    Rationale: As consultants leave our company, we need to delete them from the system.

  3. Assign a Consultant to a Project
    The Consultant Maintenance form must allow the user to assign a consultant to a customer's project.
    Rationale: Our principal source of income is derived from hiring consultants out to customers.

  4. Set the Consultant's Rate for a Project
    The Consultant Maintenance form must allow the user to set the consultant's rate for a project.
    Rationale: The rate for a consultant is negotiated on a per-project basis.

  1. 3.1.2 Customer-Related Data Entry
    The system shall provide a Customer Maintenance form, which must support the following operations:

    1. Add a Customer
      The Customer Maintenance form must allow the user to add a customer to the system. To add a customer, the user must supply the customer name and address.
      Rationale: As we start doing business with new customers, we need to add them to the system.

    2. Delete a Customer The Customer Maintenance form must allow the user to delete a customer from the system.
      Rationale: As we conclude our business with certain customers, we need to delete them from the system.

  1. 3.1.3 Timesheet-Related Data Entry
    The system must provide a Timesheet Maintenance form, which must support the following operations:

    1. Input Timesheet Information
      The Timesheet Maintenance form must allow the user to add a timesheet to the system. To add a timesheet, the user must supply the consultant name, and the week-ending date.
      Rationale: Each timesheet is handled on a weekly basis.

    2. Input Hourly Detail
      Once a user has added the consultant and week-ending date to a timesheet, the user must add the hourly detail. The hourly detail consists of the day of week (Sunday, Monday, Tuesday, Wednesday, Thursday, Friday, or Saturday), the number of hours, and the task that the hours pertain to.
      Rationale: In order to manage the efficiency of our consultants, we need to track their time usage at the task level.

    3. Create New Task
      If the user tries to enter hourly detail for a task that does not exist already, the Timesheet Maintenance form must allow that user to add the task to the system.
      Rationale: All billable hours must be associated with a particular task.

  1. 3.2 Reporting Requirements
    This section describes each report that the system must produce.

    1. 3.2.1 Weekly Summary Report
      The system should generate a Weekly Summary Report, which has three levels of detail. Figure 1.2 shows an example of this report.
      Rationale: This information is needed by the Staff Coordinator to perform her duties.

      1. Weekly Summary Report: Customer Detail
        For each customer name, the report should state the total number of hours for all consultants, and the total amount to bill the customer.
        Rationale: The Staff Coordinator needs this information to produce an invoice for the customer.

      2. Weekly Summary Report: Project Detail
        For each customer, the report must show each project, the total number of hours for all consultants who billed to that project, and the total dollar amount to bill for that project.
        Rationale: This gives the Staff Coordinator the ability to quickly access the cost to the customer of an individual project.

      3. Weekly Summary Report: Consultant Detail
        Within each project, the report must show the name and rate of each consultant who worked on the project, the name of the task he or she worked on, and the total amount of hours and dollar amount billed for that task.
        Rationale: This provides the level of detail needed to track the utilization and efficiency of a consultant.

  1. 4.1 Nonfunctional Requirements
    A number of nonfunctional requirements have been specified.

    1. 4.1.1 Hardware
      This system must be deployed on SPARC, Alpha, and Intel hardware. Rationale: We have a large investment in older models of these machines, and we have no budget to replace them immediately.

    2. 4.1.2 Operating System
      This system must be portable to Linux, OpenBSD, or NetBSD.
      Rationale: We found that any of these operating systems offer the optimal solution for keeping our hardware running with a modern, efficient operating system. They provide support for older models that the hardware vendors' operating systems either do not support, or on which the hardware vendors' operating systems perform poorly.

    3. 4.1.3 Memory
      Each component of this system should require no more than 4 to 8 megabytes of physical and virtual memory.
      Rationale: All of our machines have a minimum of 48 megabytes of memory, but our users may want to run other applications at the same time, such as Netscape or a word processor.

5.1 Forms
This section describes paper forms that act as input for the data entry process.

  1. 5.1.1 The Timesheet Form
    The Consultant must submit a timesheet form on a weekly basis. (This form is shown in Figure 1.1.)

Using a Prototype to Validate Requirements

Once you have established the formal requirements, you need to validate them. One of the best methods for validating requirements is to build a prototype. This prototype should not be confused with a prototype of the user interface, which is discussed in detail in Chapter 3.

As difficult as it may be to let something go, in most cases, you should throw away (or archive) your prototype and implement the system almost from scratch. You don't have to throw away everything. If you have followed a modular approach in building the prototype, you can reuse some of the modules and/ or objects you built while you developed the prototype. Take care when invoking this privilege, however. If you know that you might want to reuse a module, build it as though you were building it for a production system, not for a prototype. It may slow things down in the short term, but in the long run, you will save time.

Sommerville warns against building a general-purpose prototype. A prototype should have one purpose, such as one of the following: prototyping the user interface, validating the requirements, or demonstrating the feasibility of the project. If you are (and you should be) using the prototype to verify the requirements, make sure this is the only thing you use the prototype for. A prototype that is put together to validate the requirements may not make the best user interface prototype.

What to build the prototype with. Fortunately, Linux users have at their disposal many wonderful tools for developing prototypes. Any of the most popular scripting languages, such as Perl, Python, or Tcl, support a variety of user interfaces. These scripting languages can be used to quickly develop a prototype complete with a user interface and database connectivity (and any of these languages is fine for building the final product, as well).

How much design? How much design needs to go into the prototype? To a large extent, you should use this book to familiarize yourself with the techniques for building an application. Then, as you are building a prototype, you can select the techniques that you feel are appropriate for the level of detail your prototype will capture. Many prototypes focus on areas of uncertainty in the requirements: If the area of uncertainty is in something that greatly affects the database design, you may want to put more effort into the prototype's database design.

The Volatility of Requirements

There is no such thing as a stable set of requirements. All you can hope for is a snapshot in time of what the stakeholders need. As time goes on, the requirements will change. In fact, it is likely that they will change as you design and develop the system. With this in mind, you need a firm change control procedure in place. The stakeholders must understand that a change in the requirements can have one of two outcomes.

  • The change will be incorporated in the system you are writing, in which case it will involve additional expense as you adjust the schedule.

  • The change can be incorporated in a future release of the system.

One key to successfully building a system is successfully managing changes in the requirements. McConnell suggests some strategies for managing changes that can help you as you develop the software (however, see Chap-ter 6's section titled The Cathedral and the Bazaar, which refers to and is titled after Eric S. Raymond's essay of the same name, for a different perspective on this problem):

Create a formal procedure for requesting changes. This will help you manage the inevitable flood of requests and keep them from over-whelming you.

Establish a change-control board. The change-control board is a committee or group that is responsible for deciding what changes are allowed to be made.

Deal with changes in batches. All of us have given in to the urge to implement a change that seems easy to implement. If you implement every change this way, some good changes might fall through the cracks if they occur to you too late in development. Dealing with them in batches also gives small changes greater visibility in the overall schedule.

Estimate the cost of every change. Because of the inherent complexity in software development, even the simplest change can have large effects on other parts of the system. Before you agree to a change, make sure you know what it will cost.

Major change requests indicate something is wrong. If you're getting major change requests during development, you should strongly consider apply-ing the brakes on the development process and going back to the require-ments stage. Perhaps you had been prototyping to validate the requirements without knowing it!

The System Architecture

Before you can proceed to a detailed design of the system, you need to sort out the system's architecture. The architecture is a high-level model of the system that clearly depicts its subsystems and the connections among them.

System Structuring

When you break the system down into its structure, you need to divide it into subsystems, smaller systems that function independently of other sub-systems. The requirements document shown earlier in this chapter hints at a system made up of three independent smaller systems: a Consultant Maintenance subsystem, a Company Maintenance subsystem, and a Timesheet Maintenance subsystem.

The fact that these subsystems exchange data does not make them dependent upon each other. Instead, we look to one of the models that Sommerville discusses, the repository model. In one type of the repository model, each subsystem exchanges data with the others through a shared database. Since this is a book about building database applications, we are going to use this model for every example in this book. Figure 1.4 shows a possible structure for this system.

Some features of the repository model include:

Agreement. Each subsystem must agree on the structure of the shared data-base. Since this book approaches database design from a system level (rather than on a subsystem-by-subsystem basis), this is not a problem. Chapter 2, "SQL and Relational Database Design," discusses how you can take the system requirements and develop a database design.

Centralization. The database administrator can maintain central control over access control, security, backups, and other issues.

Extensibility. Since there is an agreed-upon database structure, new tools can be easily integrated into the system.

Control Modeling

The next step is to model how control will flow within and between the sub-systems. One of the models that Sommerville discusses is the event-based control model. In this model, there is no central system that governs the flow of control. Instead, events that originate outside of the system control determine which subsystems are activated and how control flows between subsystems. Such events can come from other systems or from the system's user interface.

Since this book is concerned with GUI-enabled desktop database applications, as opposed to batch-oriented systems, the event-based model fits our example rather well.

However, if we assume the existence of a single application entry point, we need to include that entry point (the Main Screen in Figure 1.5) in our control model. So, our model derives a bit from a centralized control model (also discussed by Sommerville), as well as an event-based control model. In the centralized model, a single subsystem takes responsibility for the initial control of the other subsystems. Figure 1.5 shows a control model for the timesheet system.

Rather than being completely controlled by a subsystem that has central control, many parts of it will be controlled by responding to external events: a user starting the application, clicking the mouse, or typing some text.

Modular Decomposition

Once you have completed the previous steps, you can move on to breaking the system into smaller pieces. One of the biggest problems with large software projects is that it is not possible for any one person to comprehend the system as a whole. When you break the system down into smaller pieces, you create manageable components that can be understood by one person. In Chapter 8, "Object-Oriented Design," we look at techniques for designing systems that are made of manageable components.

System Design

There are three activities involved in designing the types of applications we are covering in this book: database design, user interface design, and module or object design. Once these activities are completed, developing the system becomes quite manageable. Although this book presents them in a specific order, don't look at these activities as something that must be performed one at a time, in sequence to completion. It's much more iterative than that. In fact, you may complete your database and user interface designs, and when you move on to object design, you may learn something that sends you back to user interface design. The reality is that these activities feed into one another.

Database design. This activity models the system data in a manner than can be easily processed by a relational database system. Unfortunately, the output of this process is not always something that is intuitive to humans. Instead, the output of the database design process ensures that the database is correct, consistent, and efficient. The burden falls on the user interface design to present a pretty face. Database design is covered in detail in Chapter 2


User interface design. This activity models the system's data and behavior in a visual manner. User interface design involves many factors that affect human cognition, such as memory (human, not computer memory) issues, spatial organization, and aesthetics. User interface design is discussed in Chapter 3.

Module or object design. Object-oriented analysis and design models the system's data and behavior in a way that is close to how humans think of real-world objects. Modular design isolates related processes and data in a way that maximizes code reuse. Chapter 4, "Construction," discusses modularity, and object-oriented concepts are introduced in Chapter 5, "Object-Oriented Programming." Chapters 7 and 8 discuss object-oriented analysis and design.


Before you start building software, it's important to make sure you are solving the right problem. To this end, there are four areas you need to pay special attention to:

The problem definition. This answers the question, "why am I building this system?" It's the most important thing to get right. If you don't get the problem definition right, you run the risk of solving the wrong problem.

Requirements analysis. In order to build up a document that serves as a roadmap for the system, you need to analyze the problem. To do this, you will need to become involved with the stakeholders, understand their business needs, and pay attention to many details.

The formal requirements document. Using a formalized, organized approach, you can build a document that unambiguously specifies what it is you are to build. As you build the system, you will need to exert some control over the changes that will be made to the requirements.

The prototype. Once you have developed this document, you may need to validate the requirements with a prototype.

System architecture and design. Before you can proceed to the design of the system objects, the database, and the user interface, you must determine the architecture of your system. This encompasses three stages: system structuring, control modeling, and modular decomposition. The concepts discussed in Chapters 4, 5, 7, and 8 can be applied to modular design.

This chapter offers the image of building a physical structure as a metaphor for constructing a software system. It's important to keep in mind that one metaphor does not fit all cases. In practice, the building metaphor is most appropriate to the specification and design stage of a software project. Where it still fits in other stages, we'll build on this metaphor. However, in Chapter 6, "Software Engineering," we'll take a look at some of the advantages that the open source approach can offer over (or in combination with) the approaches discussed in this chapter.

Read More Show Less


Welcome to the first edition of . This book is, for the most part, about building desktop database applications for Linux, although the way we address that topic will open your mind to a lot of other great stuff. If you opened this book hoping to learn how to build an application that uses a relational database to store data, and a graphical front-end to interact with users, you came to the right place!

There is one thing we should make perfectly clear: this book does not talk about how to develop web database applications. There are many books on this topic (Brian has even written a couple of them), and perhaps we will address it in a future edition of this book. However, with the growth of desktop application environments such as KDE and GNOME, we felt challenged to produce a book with a desktop focus.

It wouldn't be fair to say that this book is only about plugging databases into a pretty user interface. In fact, it's much more than that. In this book, we're going to look at a lot of things that will help you build better applications, and you'll be able to apply many of these things to other programming endeavors. Here are some of the topics we discuss:

Database systems
In this book, we look at five popular database systems for Linux: PostgreSQL, MySQL, Mini SQL, Sybase, and Oracle. Wherever possible (and incompatibilities permitting), we have developed example code that works with as many of these databases as possible. Differences that were known to us during writing and testing are documented where appropriate, and Chapter 9, "Databases," takes a close look at these databases. Two areas we focus on in particular are how you can get up and running with the database system of your choice, and how each database server deals with specific database development issues. We also take a good look at the different data types and date formats, two things that are confusing when developing cross- database applications.

If your favorite database system was not covered in this book, we apologize, but we had a limited amount of time to produce this book, and we chose these database systems so we could best leverage the experience of the authors. If you are interested in other database systems for Linux, see Christopher Browne's resource on this topic at

Conceptual Modeling
In this book, we spend as much time talking about what you must do to prepare for programming as we do about programming itself (I think I heard a groan from the back of the room). Don't fear - even the chapters about analysis and design are peppered lightly with some concrete examples, and we think you'll find it useful. We won't mind if you skip ahead to the implementation-oriented stuff, which begins in Chapter 9. We're hoping that if you do that, you'll eventually come back to the earlier stuff.

UML and Patterns
Perhaps these are two buzzwords you've heard a lot, or perhaps these are two things with which you are familiar. For those who don't know, UML and Patterns are modeling aids that are used by programmers and designers to better communicate with others. UML is a notation that documents a number of things, including the mental model you have of a system that you're going to build, the classes that make up a system, and how these classes are related. Patterns are a way of expressing solutions to problems in a context. When you are looking at a problem that needs to be solved, you can apply one or more Patterns to reach a solution. This makes it easy for you to find a solution, gives you confidence that you are doing something tried and true, and makes it easier for other people to understand your design. Chapter 7, "Object-Oriented Analysis," and Chapter 8, "Object-Oriented Design," talk about how you can apply UML and Patterns to analyze and design your project.

Chapter 2, "Database Design," specifically addresses SQL, the programming language used by all five database servers we discuss in this book. Before we dive into the SQL, though, we take a good look at how to design a database in the context of a problem that needs to be solved. We look at a particular set of requirements, plan a database for a system, and refine it until it's designed well enough to work well with an SQL database system. Then, we show you how to create the tables that make up the database, and how to work with them in SQL. Appendix A, "SQL Reference," will help you find your way around the language. Chapter 9 treats many database issues, including several special topics in SQL.

Programming languages
Chapters 11, 12, and 13 cover Java, Perl, and C, respectively. In all three chapters, we look at how you can develop graphical applications in these languages that talk to an SQL database back-end. Chapter 13 looks at C programming in the context of GNOME, an exciting desktop application framework for Linux and other operating systems.

Who Can Use This Book
Before we wrote this book, we decided to keep one user in particular in mind: someone who has been using the Linux system for a little while, and who may have learned a bit of programming. This is not to say that expert users or complete novices should be afraid; in fact, we felt that by targeting the inexperienced programmer, we would diminish barriers to entry as much as possible. Also, by concentrating on delivering a lot of information in this book, we felt there would be plenty of interest for even the most experienced programmers.

How to Use This Book
For the total Linux newbie, we suggest that you take the time to get comfortable with Linux, and get to know your way around the Linux shell (bash, the Bourne Again Shell) before you try to tackle this book. It's best if you've had some experience doing light programming in a language such as Perl, Tcl, or Python, and that you understand the basics of programming (functions, variables, and data structures such as arrays, linked lists, and hashtables, for example).

For the expert developer, there are certainly parts of the book that you can skip, if you feel like it. We think that the chapters are set up in a way that you can simply read the first few paragraphs of each chapter to decide whether the chapter will be helpful.

For the rest of you (and total newbies after you've learned the basics), we'd like you to try going through the book from start to finish. The first thing you'll see is Chapter 1, "Requirements," which talks about software development from a very traditional perspective. Although we use this approach as the basis of the next three chapters (Chapter 2, "Database Design"; Chapter 3, "User Interface Design"; and Chapter 4, "Construction"), we take a fresh look at the issue in the chapters that follow. Chapter 5, "Object-Oriented Programming," is a quick introduction to object-oriented programming, and in Chapter 6, "Software Engineering," we look at software engineering from an open source perspective. Finally, we wrap up the Part One of the book by looking at how you can use UML and Patterns to design a system. Then, it's on to Part Two.

Part Two of the book looks at implementation issues. Chapter 9 looks at what you need to get up and running with any of the five database servers we talk about in this book. Chapter 10, "Linux Development Tools Catalogue," takes a quick look at various tools that will help you develop Linux database applications; everything from graphical query tools to environments that are similar to 4GL tools like Access. From there on, the next chapters look at programming database applications in Java, Perl, and in C under the GNOME framework. After that, we wrap up the book with chapters on distributed components and CORBA.

Read More Show Less

Customer Reviews

Be the first to write a review
( 0 )
Rating Distribution

5 Star


4 Star


3 Star


2 Star


1 Star


Your Rating:

Your Name: Create a Pen Name or

Barnes & Review Rules

Our reader reviews allow you to share your comments on titles you liked, or didn't, with others. By submitting an online review, you are representing to Barnes & that all information contained in your review is original and accurate in all respects, and that the submission of such content by you and the posting of such content by Barnes & does not and will not violate the rights of any third party. Please follow the rules below to help ensure that your review can be posted.

Reviews by Our Customers Under the Age of 13

We highly value and respect everyone's opinion concerning the titles we offer. However, we cannot allow persons under the age of 13 to have accounts at or to post customer reviews. Please see our Terms of Use for more details.

What to exclude from your review:

Please do not write about reviews, commentary, or information posted on the product page. If you see any errors in the information on the product page, please send us an email.

Reviews should not contain any of the following:

  • - HTML tags, profanity, obscenities, vulgarities, or comments that defame anyone
  • - Time-sensitive information such as tour dates, signings, lectures, etc.
  • - Single-word reviews. Other people will read your review to discover why you liked or didn't like the title. Be descriptive.
  • - Comments focusing on the author or that may ruin the ending for others
  • - Phone numbers, addresses, URLs
  • - Pricing and availability information or alternative ordering information
  • - Advertisements or commercial solicitation


  • - By submitting a review, you grant to Barnes & and its sublicensees the royalty-free, perpetual, irrevocable right and license to use the review in accordance with the Barnes & Terms of Use.
  • - Barnes & reserves the right not to post any review -- particularly those that do not follow the terms and conditions of these Rules. Barnes & also reserves the right to remove any review at any time without notice.
  • - See Terms of Use for other conditions and disclaimers.
Search for Products You'd Like to Recommend

Recommend other products that relate to your review. Just search for them below and share!

Create a Pen Name

Your Pen Name is your unique identity on It will appear on the reviews you write and other website activities. Your Pen Name cannot be edited, changed or deleted once submitted.

Your Pen Name can be any combination of alphanumeric characters (plus - and _), and must be at least two characters long.

Continue Anonymously

    If you find inappropriate content, please report it to Barnes & Noble
    Why is this product inappropriate?
    Comments (optional)