It’s time to start discussing more-advanced SQL topics, such as modernizing a database by making its tables more user-friendly. For that, we’ll have to use a fictitious database; let’s get to know it in this article.

This article and the next article introduce the UMADB, a database for a university management application. It’s important to have a notion of how this database is built—its flaws and shortcomings—because I’ll be using it in almost every example from this point on. UMADB is in bad shape and will be improved over the next articles by applying the concepts discussed in each one of them.

Behind (almost) every application worthy of that name is a database. Some are small, some are huge, some are simple, and some (I’d say most) are complex. In IBM i’s world, they’re usually old, big, and confusing. Although our example database, UMADB, is not very big (I downsized it for simplicity’s sake), it’s poorly built and can be rather confusing to both programmers and users.

Let’s start with what this database should do: it supports a university management application. This means it should manage student, teacher, class, course, classroom, grade, and timetable records. In its current state, it kind of does, but there’s some room for improvement. The UMA application, an “old-style” RPG application, should keep track of the students’ academic lives: the classes they attended, the grades they were awarded, and so on. It should also keep track of classroom usage and timetables, for both students and teachers. However, these last two tasks were deemed “too complex for the application” by the application’s manager and were left out. In other words, these are manual tasks, performed by the university administrative staff. This is one of the many shortcomings of the application and its database.

There are plans to change the current state of the application, and we (you, dear reader, and I) are part of them. We are going to improve the current database, which is basically a set of DDS-defined physical files, by applying DB2 for i SQL techniques, tricks, and novel features!

But first, you need to get to know the database in some detail. Let’s take a look at the current database structure, table by table, starting with the students table.

The Students Table

The students table started with a simple student name column and grew to include other pieces of data, as do many DB2 tables in real-life applications. However, the growth was not planned properly (again, as in many real-life DB2 tables), and there are some problems in this table, which might not be obvious at first. But we’ll get back to that later; now let’s have a look at the actual table (below).

This looks just like most IBM i physical files I’ve seen: cryptically short file (or table) and field (or column) names, concentrating a lot of information in a single row. The columns are mostly unremarkable as well: the list includes student contacts (addresses and phone numbers) and IDs (driver’s license and Social Security number).

There are a couple of eyebrow-raising features. First, the column that stores the date of birth is a decimal with a length of 8,0, meaning that it’s a number, not a date. Note that the database isn’t prepared to validate the content of the field; it’s just a number that some convention says represents a date.

Another noticeable “feature” is the absence of the student’s record unique identifier. This was not deemed important, because all searches are done using the student’s name.

These flaws are just a few examples of textbook problems with IBM i tables: they are, in a word, dumb. Even though it’s possible, for instance, to perform basic checks like the validity of a date at database level, this and many other similar tasks are almost always performed at application level, thus making the database a simple (and dumb) repository of data. The same could be said about the absence of a record ID. The problem occurs when there are other, non-native applications accessing and manipulating the data. Without checks at the database level, it’s possible, and very likely, to insert rubbish into the tables. Introducing those checks is actually very easy to do. Later in this article series, you’ll learn how to create validations that mimic (and can even go a step further and actually replace) business rules that currently exist for RPG programs.

There’s something else wrong with this table, but it’s not obvious yet. We’ll need to go over a couple more tables for you to see it. However, I’ll let you think about what it might be. Write your guesses in the comments section below. I’ll explain it in the next article.

Rafael Victória-Pereira has more than 20 years of IBM i experience as a programmer, analyst, and manager. Over that period, he has been an active voice in the IBM i community, encouraging and helping programmers transition to ILE and free-format RPG. Rafael has written more than 100 technical articles about topics ranging from interfaces (the topic for his first book, Flexible Input, Dazzling Output with IBM i) to modern RPG and SQL in his popular RPG Academy and SQL 101 series on mcpressonline.com and in his books Evolve Your RPG Coding and SQL for IBM i: A Database Modernization Guide. Rafael writes in an easy-to-read, practical style that is highly popular with his audience of IBM technology professionals.

Rafael is the Deputy IT Director - Infrastructures and Services at the Luis Simões Group in Portugal. His areas of expertise include programming in the IBM i native languages (RPG, CL, and DB2 SQL) and in "modern" programming languages, such as Java, C#, and Python, as well as project management and consultancy.

---

MC Press books written by Rafael Victória-Pereira available now on the MC Press Bookstore.

		Evolve Your RPG Coding: Move from OPM to ILE...and Beyond Transition to modern RPG programming with this step-by-step guide through ILE and free-format RPG, SQL, and modernization techniques. List Price $79.95 Now On Sale
		Flexible Input, Dazzling Output with IBM i Uncover easier, more flexible ways to get data into your system, plus some methods for exporting and presenting the vital business data it contains. List Price $79.95 Now On Sale
		SQL for IBM i: A Database Modernization Guide Learn how to use SQL’s capabilities to modernize and enhance your IBM i database. List Price $79.95 Now On Sale

Also Read

SQL 101: DDL Recap—Improving Our Basic SQL Tables, Part 2

TechTip: Automate Complex Tasks Using SQL and User-Defined Table Functions

SQL 101: DDL Recap—Improving Our Basic SQL Tables, Part 1