SQL for IBM i: A Database Modernization Guide - Softcover

Victória-Pereira, Rafael

Softcover

ISBN 10: 1583474498 ISBN 13: 9781583474495

Verlag: MC Press, 2018

Inhaltsangabe

This book aims to give IBM i technical users basic to intermediate SQL knowledge and tools they can use to get more out of the IBM i database. The book can be useful to veteran IBM i programmers, who have RPG and COBOL roots, system administrators looking to get more information out of their IBM i system, or even Java and .NET developers who need to 'talk' to IBM i database. The author provides comprehensive examples and exercises to help readers understand and practice what they have learned.

Über diesen Titel

Über die Autorin bzw. den Autor

Rafael Victória-Pereira has more than 16 years of IBM i experience as a programmer, analyst, and manager. 

Auszug. © Genehmigter Nachdruck. Alle Rechte vorbehalten.

SQL for IBM i

A Database Modernization Guide

By Rafael Victória-Pereira

MC Press

Copyright © 2018 Rafael Victória-Pereira
All rights reserved.

ISBN: 978-1-58347-449-5

Contents

Acknowledgments, 
Why You Need This Book, 
1: Meet the UMADB: Our Example Database, 
2: A Data Manipulation Language Basics Recap, 
3: A Data Definition Language Basics Recap, 
4: Making the Database User-Friendly, 
5: Tidying Up the Database, 
6: Introducing Data-Centric Programming and SQL/PSM, 
7: Creating and Using Stored Procedures, 
8: Exploring User-Defined Functions, 
9: Making a Trigger-Happy Database, 
10: Moving Business Validations to the Database, 
11: Exploring the Database Catalog Information, 
12: Parting Gifts, 

CHAPTER 1

Meet the UMADB: Our Example Database

This chapter introduces 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 in the book. UMADB is in bad shape and will be improved throughout the book, by applying the concepts discussed in each chapter.

Behind (almost) every application worthy of that name is a database. Some databases 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 is also 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 with 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 received, 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 of the database. 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 existing 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 depth. 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 (Table 1.1).

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 identifier was deemed unimportant, because all searches are done using the student's name.

These flaws are just a couple of 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 book, 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. Let's move on to the Courses table.

The Courses Table

Let me take a moment to explain the structure of the information in this database. The students take classes, which are taught by teachers, and are part of courses. At the end of each semester, the teachers grade the students in each of the classes they attended. This may sound obvious and redundant, but it's important to keep the structure in mind from this point on. In a way, the Students and Courses tables are the center of the database, because all the other tables are somehow linked to one (or both) of these tables.

Now let's take a look at the Courses table structure, shown in Table 1.2.

Again, the table is pretty typical: the same cryptic names and the lack of a unique record identifier that characterized the Students table. By the way, I imagine that you're curious about the hidden flaw in the Students table, mentioned earlier. Don't worry, it's going to become obvious in the next section, where we'll look at the Teachers table.

Meanwhile, there's something common to all the tables in this database: a status column. As the name implies, it indicates the status of the record. The convention used here is the following:

• 0 — Created but not active record

• 1 — Active record

• 9 — Inactive (deleted) record

This is something that has to be taken into account when querying the database, and it has been the source of many misunderstandings. Sometimes the users forget to include a condition in their queries and end up mixing active and inactive records, which leads to inconsistent or just plain wrong information.

The Teachers Table

The teachers are a very important part of any teaching system. They're also a very important part of the application our database supports, although the table that keeps their records is not very "polished." You'll see what I mean when we analyze the Teachers table, shown in Table 1.3.

This table is similar to the previous ones, but it includes a sensitive piece of information: the teacher's salary. As things stand, anyone with access to the table can see how much each teacher earns, which might not be a very good idea. I'll get back to this later, when I discuss how to hide a column's data from prying eyes.

Notice the similarities between this and the Students table: the personal information (addresses and IDs) is the same....

Details zur Ausgabe

• Verlag: MC Press
• Erscheinungsdatum: 2018
• Sprache: Englisch
• ISBN 10: 1583474498
• ISBN 13: 9781583474495
• Einband: Taschenbuch
• Anzahl der Seiten: 376
• Kontakt zum Hersteller: Nicht verfügbar
• Verantwortliche Person: Nicht verfügbar