Refining Database Retrievals with Comparison Predicates

Photo by Domenico Loia on Unsplash

In a previous post, we saw that, using SQL, it’s easy to retrieve all the data contained in a database table with a simple SELECT statement, such as:

SELECT * FROM customers ;

We also saw that it’s almost as easy to retrieve only what we want from a table, leaving behind all the rest:

SELECT * FROM customers

                WHERE state = ‘CA’ ;

That returns only the customers located in California.

The equals operator (=) is an example of a comparison operator and when two operands are compared with the equals operator, it is called a comparison predicate. A comparison predicate either evaluates to a true value or a false value. A customer is either located in California or she is not.

In addition to the ‘is equal to’ operator, there are five additional comparison operators. They are:

Is not equal to (<>)

Is less than (<)

Is greater than (>)

Is less than or equal to (<=)

Is greater than or equal to (>=)

All six of these operators may be used with numerical operands. It makes sense to say that:

One number is equal to another number

One number is unequal to another number

One number is less than another number

One number is greater than another number

One number is less than or equal to another number

One number is greater than or equal to another number

Similarly, all six operators make sense when applied to dates and times. However, all six do not make sense when applied to text strings. One string may be equal to another string, or unequal to it. However if you try to apply any of the others, such as less than, you will probably not receive the result you are looking for.

Comparison predicates enable you to zero in on the exact information that you want to extract from a database.

Four Myths about SQL

Some people may decide not to learn SQL because of something they may have heard, or just assumed, that is completely untrue. Myths such as these can stand in the way of people moving ahead in their careers. There are number of these myths that hold people back, but I would like to discuss just four of them.

  1. SQL is a programming language and I am not a programmer. Although SQL is a language, it is not a programming language in the way you are probably thinking. Most computer languages are procedural languages. To use them, a programmer creates a procedure in which a series of instructions are written in a step-by-step manner to cause a computer to perform some action. The programmer must understand what is going on at a deep level in order to generate the correct sequence of instructions.

 SQL is not like that. It is not a procedural language. It is called a non-procedural language because there is no need to write a procedure. With SQL all you need to do is write a statement that tells the computer what action you want it to perform. The DBMS figures out the details of how to do that, then goes ahead and does it.

  1. Knowing SQL would be of no value to me since I don’t have a programming job. Although it is true that information technology professionals have the most to do with databases, these days practically everyone in an organization has some exposure to them and may need information contained in them in order to do their jobs. You may not work with a database every day, but occasions will arise when you will need a fact contained in a database and there is no IT professional available to obtain it for you. Anyway, you should be able to perform basic database retrieval operations for yourself. It makes you a more valuable employee.
  2. You need to be some kind of brainiac to understand SQL. There is a mystique surrounding computers in general and SQL in particular that they are beyond the comprehension of ordinary people. This is particularly untrue about SQL, which consists of simple statements that are very similar to ordinary English-language sentences. If you can compose and write down a sentence, you could just as easily write an SQL statement that would perform a query.
  3. Knowing SQL won’t be of any value to me. This is the biggest myth of all. Our world today is totally dependent upon computers and the data stored within them. A lot of jobs will become obsolete and disappear within the next ten years, but jobs associated with information technology will not be among them. Learning SQL could be one of the most effective things that you could do to guarantee your future employability.

5 Reasons Why You Need SQL


Some people may decide not to learn SQL because of something they may have heard, or just assumed, that is completely untrue. Myths such as these can stand in the way of people moving ahead in their careers. There are number of these myths that hold people back, but I would like to discuss just four of them.

1. SQL is a programming language and I am not a programmer. Although SQL is a language, it is not a programming language in the way you are probably thinking. Most computer languages are procedural languages. To use them, a programmer creates a procedure in which a series of instructions are written in a step-by-step manner to cause a computer to perform some action. The programmer must understand what is going on at a deep level in order to generate the correct sequence of instructions.

SQL is not like that. It is not a procedural language. It is called a non-procedural language because there is no need to write a procedure. With SQL all you need to do is write a statement that tells the computer what action you want it to perform. The DBMS figures out the details of how to do that, then goes ahead and does it.

2. SQL is only for people who have a programming job. Although it is true that information technology professionals have the most to do with databases, these days practically everyone in an organization has some exposure to them and may need information contained in them in order to do their jobs. You may not work with a database every day, but occasions will arise when you will need a fact contained in a database and there is no IT professional available to obtain it for you. Anyway, you should be able to perform basic database retrieval operations for yourself. It makes you a more valuable employee.

3. You need to be some kind of brainiac to understand SQL. There is a mystique surrounding computers in general and SQL in particular that they are beyond the comprehension of ordinary people. This is particularly untrue about SQL, which consists of simple statements that are very similar to ordinary English-language sentences. If you can compose and write down a sentence, you could just as easily write an SQL statement that would perform a query.

4. Knowing SQL won’t be of any value to me. This is the biggest myth of all. Our world today is totally dependent upon computers and the data stored within them. A lot of jobs will become obsolete and disappear within the next ten years, but jobs associated with information technology will not be among them. Learning SQL could be one of the most effective things that you could do to guarantee your future employability.

What SQL Is and What It Isn’t

SQL is not a procedural language.

Procedural languages such as C++ or Python operate on data items one item at a time. People who program in languages such as C++ and Python write procedures that perform a sequence of operations one after another until an entire task is completed.

SQL is considered a non-procedural language because when you use it, you do not code instructions to perform a sequence of operations. In other words, you do not specify a sequence of operations to perform a task. Instead, you merely tell the DBMS you are using what you want done, and it would proceed to do it without any further instructions from you. If what you want is to retrieve specific information from a set of database records, just specify exactly what you want, and the DBMS will decide how best to satisfy your request, then return the result to you.

Application programmers embed SQL statements in their programs to interact with databases, and use procedural code to construct user interfaces, screens, reports, and program logic. If all you want to do is retrieve some data from a database to answer a question, you don’t need to go to all the trouble of writing a program. You can just feed an SQL statement directly to the DBMS and read out the result when it is returned to you.

For people who are not programmers, and who do not intend to become one, a working knowledge of how to craft SQL queries can be very useful. Even if an application program with embedded SQL exists for a database, questions are bound to arise that were not anticipated when that application program was written. It can be quite valuable to be able to answer such questions quickly and easily with a simple SQL query.

If you think that a basic knowledge of SQL might be helpful to you, click here to find out about a short course that will bring you up to speed.

Creating a Database that Meets User Needs 3: The Requirements Phase

Computer Storage

After the scope of a database development project has been established during the Definition Phase, you need to find out what the stakeholders in the project need it to do for them. That is the job of the Requirements Phase. In the Definition Phase, you talk with the client. This is the person who has the authority to hire you or, if you are already an employee, assign you to this development task. This person is not, however, the only one with an interest in the project. In all probability, someone other than the client will use the system on a daily basis. Even more people may depend on the results generated by the system. It is important to find out what those people need and what they prefer because your primary client may not have a complete understanding of what would serve them best.

The amount of work you must do in the Requirements Phase depends on the client. If can be quick and easy if your are dealing with a client who has prior experience with similar database development projects. Such a client has a clear idea of what he wants and, equally important, what is feasible within the time and budget constraints that apply.

On the other hand, this phase can be difficult and drawn-out if the client has no experience with this kind of development, only a vague idea of what he wants, and an even vaguer idea of what can reasonably be done within the allotted time and budget.

Aside from your primary client, other stakeholders in the project, such as various users, managers, executives, and board members, also have ideas of what they need. These ideas often conflict with each other. Your job at that point is to come up with a set of requirements that everyone can agree upon. This will probably not meet everyone’s desires completely. It will be a compromise between conflicting desires, but will be the solution that gives the most important functions to the people who need them.

The Statement of Requirements

The Statement of Requirements is an explicit statement of the database application’s deliverables, including its display, update, and control mechanisms. It will answer such questions as:

  • What will the display look like? How will components be arranged? What will be the color scheme?
  • What items will need to be updated, and how will that be done?
  • How will users navigate between screens?
  • Will selections be made by key depressions, and if so, which  keys will do what?
  • Will operations be initiated by mouse clicks? If so, which operations?
  • What will the maximum acceptable response time to a query be?

The Statement of Requirements must be as detailed as possible because it is essentially a contract between you and your client. You are agreeing on exactly what will be delivered and when it will be delivered. To seal the arrangement, bot you and your client should sign the Statement of Requirements, signifying agreement on what you will be responsible for delivering.

Sumarizing, in the Requirements Phase you must:

  • Interview typical members of all classes of stakeholders in the project.
  • Provide leadership in getting stakeholders to agree on what is needed.
  • Create the Statement of Requirements, which describes in detail what the system will look like and what it will do.
  • Obtain client approval of the Statement of Requirements, indicated by a signature and date.

Creating a Database that Meets User Needs 2: The Definition Phase

Computer Storage

In the first installment of this series of posts I said that for a development effort to succeed in meeting its objectives, a series of steps should be taken, each one building upon the previous ones, without leaving any out. This series of steps or phases is called the System Development Life Cycle (SDLC). The phases are:

  • The Definition Phase
  • The Requirements Phase
  • The Evaluation Phase
  • The Design Phase
  • The Implementation Phase
  • The Final Documentation and Testing Phase
  • The Maintenance Phase

Rookie developers often, after receiving a development assignment, start building the database and its associated application. Unfortunately, that is what should be done in the Implementation Phase. They have just skipped the first four phases of the SDLC and consequently, their chance of success is minimal. It is really important to go through all the phases and to perform all the tasks within each phase.

Every phase is important, but the Definition Phase is crucial, because if you don’t define the task properly at the beginning, there is no chance that the final product will meet your client’s needs.

There are five major tasks that must be performed as part of the Definition Phase. They are:

  • Define the task to be performed. A database project begins when a person or group realizes that they have a problem and that a database is probably part of the solution of that problem. Depending on how experienced they are with such things, they may have a very clear idea of what the database should be and how it should perform, or they may have only a vague notion of what is needed. If you are called in to be the developer of this project, it is up to you to develop a detailed definition of exactly what the product of the development effort will do.
  • Determine the scope of the project. In addition to defining the task to be performed, at this point you also want to estimate how big the project is. What equipment will be needed? How much system analyst time will it take? How much programmer time? What is the required completion date?
  • Perform a feasibility analysis. The client has an idea of what she wants, when she wants it, and how much she is willing to pay for it. It is up to you to determine whether the project can be completed at all, given those constraints. If you determine that you cannot meet the requirements, you can negotiate for more time, more budget, or fewer features, or you can graciously decline to take the job.
  • Form a project team. You might be able to complete a simple project by yourself, but for a big project on a tight deadline, you should build a team, where each member works on the part of the overall task that they are best qualified to address. Network with fellow professionals so that when jobs arise, you have a pool of qualified people you can draw from for a development team.
  • Document everything. One important part of a development project that is often not given the attention it deserves is the documentation of what is learned and what is done.  Seemingly, documentation is a side issue, perhaps to be taken up after the “real” work of producing the database is done. Nothing could be further from the truth. Documenting every step along the way is vital. It is the only way to keep things on track, starting with the initial specification of what the project is supposed to do and ending with the post mortem after it is finally retired for good. On countless occasions, you will find that detailed documentation will keep you from going down the wrong path, and often it will save you from the database becoming unmaintainable when a key team member leaves.
  • Get the client to approve the Definition Phase document, in writing. It is important that you and your client be of one mind about exactly what the task is that you have been engaged to perform. Documenting exactly what you will provide (the deliverables) protects you both. It’s not uncommon for a client to tell you what you want, and then after you deliver it, say “Oh, but I thought we had agreed that you would also provide the “X” capability.” Fill in whatever you want for X. This all too common experience is called scope creep. The client wants you to do more, but does not want to pay you more for it. Your best defense is to get the client to sign the Definition Phase document at the conclusion of the Document Phase, before you start work in earnest on the project. If any additional work is desired beyond what is specified in the document, you are in a strong position to ask for additional payment.

Creating a Database that Meets User Needs

Computer Storage

 

A database is a repository for some person’s or organization’s data. For it to meet user needs, it must satisfy several criteria:

  • It must be easy to enter new data into it.
  • It must be easy and fast to retrieve just the information you want from it.
  • It must store the data in such a way that database operations do not corrupt it.

A database system consists of the hardware the database resides on, the operating system that controls that hardware, the database management system (DBMS) that performs operations on the database, the database application that translates the user’s commands into instructions the DBMS understands, and the database itself.

The database application is the part of the system that interfaces directly with the user, so it is the part that must make it easy to enter new data, and easy and fast to retrieve the desired information. This is the part of the system that database developers create. The DBMS comes from a vendor such as Microsoft or Oracle or from a consortium of professionals as is the case for open source DBMSs such as PostgreSQL or MySQL. The operating system (OS) comes from an OS vendor, such as Microsoft, or from an open source community, as is the case with Linux. Finally, the hardware comes from a hardware vendor such as IBM, Dell, or HP.

The hardware, operating systems, and DBMSs are all general purpose and have proven to be reliable in the marketplace. For these things, you can just buy the components that have enough capacity to meet your needs. The custom part is the database application. This is the software piece that solves the particular problem that you have. Since your needs are not exactly like anyone else’s you are either going to have to produce this part yourself, or hire someone to do it. Even if you decide to hire someone, it is good to understand what’s important so that you can make sure that what is finally produced actually does meet your needs.

There is a time-tested method for making sure that an application that results from a development effort actually meets the needs of those who will be using it. That method, which guides developers through the entire life of the development project is called the System Development Life Cycle (SDLC). The SDLC breaks down the development effort into a sequence of phases that, when carefully followed give a high probability of a successful project. The SDLC is not restricted to database development. It applies to development projects of any kind.

The phases are:

  • Definition
  • Requirements
  • Evaluation
  • Design
  • Implementation
  • Final Documentation and Testing
  • Maintenance

Each phase is important and skipping any one of them can cause the entire project to fail. I will describe each of these phases in detail in subsequent posts, including why it is important.