Re: How to tell if an object is in use?

Hi, Paul:

A major innovation of System./38 and OS/400 was that all "flat files" were
actually implemented as database files (later called DB2/400). Whether you
create a file using DDS (PF, LFs) or via SQL, this is still true.

The big innovation was that a relational database could be viewed as if it
is a "flat file" so that existing programming languages (COBOL, RPG, etc.)
could access these database files using "traditional" record I/O techniques,
thus allowing programmers to be productive right away, without having to
learn the then-new "relational database" techniques and/or using embedded
SQL.

Here is the fundamental difference between a "true" flat-file and a
"relational" database:

In a flat file, you have fields in a record where each field is "bound" to a
starting position and a length within the record; this "binding" occurs at
"compile-time" (e.g. when the file is created, and when your RPG or COBOL
program is "compiled" it contains a "mapping" -a data structure that maps
the fields in the record in the program's record buffer.

In a true relational database, there is no concept of records with fields in
any given starting position or ordering of fields in a record. In SQL, you
have only columns and rows in a table (or view). Thus, the only "binding" is
between the name of the column (fieldname) and the name of the table (file
name).  In other words, you never have any hard-coded offsets to positions
in a record with SQL;  you ask for columns by name, and the SQL database
takes care of getting them for you and returning them into your host
variables.

This also means that you no longer have the concept of "level-checks" at the
record level; instead, SQL tries to coerce or implicitly convert the data
type of the column in the table to the data type of the corresponding host
variable, on a column-by-column basis, so in this way, SQL tables are
"softer" than "flat files"... if you change the size of a field in a record,
you have to recompile every program that uses it because each program has
that hard-coded data structure to map the offsets of each field in the
record; with relational databases, the only "binding" between a program and
a database is via the table name (or view name) and column name(s) used by
the program.

So, in practice, you can often change the type or length of columns without
necessarily having to recompile every program that uses that table. Of
course, you could get an error on a given column if the actual data in that
column will no longer "fit" into a host variable.  So, the errors that are
conceptually equivalent to a "level check" are at the column (field) level.

Here is my quick reference to map traditional data processing (flat-file)
terminology to relational database terminology:

    traditional            relational
    =======           ======
    field                    column
    record                 row
    file                      table
        PF                      table
        LF                      view (with index)
    records in a file    rows in a table
    fields in a record  columns in a row of a table

Also, here is a similar table mapping "relational" to "object-oriented"
terminology:

    relational                        object-oriented
    ======                        ==========
    table                              class (or object type)
    column of a table            attribute of an object
    row in a table                 instance of an object class
    rows in a table                multiple instances of a class

The "big idea" here is that you can use the same principles and techniques
that lead to good database design (normalization, E/R modeling, etc.) to
design good object class librariees and hierarchies.

Hope that helps... ;-)

Mark S. Waterbury

----- Original Message -----
> From: "PaulMmn" <PaulMmn@xxxxxxxxxxxxx>
> To: "Dave Odom" <Dave.Odom@xxxxxxxxxxxx>
> Cc: <midrange-l@xxxxxxxxxxxx>
> Sent: Saturday, February 12, 2005 8:33 PM
> Subject: RE: How to tell if an object is in use?
>

> Dave--
>
> What's the difference betwen the 'relational' data base I've always
> assumed we got as part of OS/400 and 'real relational?'  Is there any
> difference between a table in DB2 and a 'flat file?'
>
> --Paul E Musselman
> PaulMmn@xxxxxxxxxxxxxxxxxxxx
>
>
> >Dave wrote (in part):
> >
> >I was going to suggest the person re-architect their apps such that
> >they use DB2 tables and SQL
> >and get away from flat files as that's the way things are going anyway.
> --
> This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
> To post a message email: MIDRANGE-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/midrange-l
> or email: MIDRANGE-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/midrange-l.
>