Difference between revisions of "DB2"

From MidrangeWiki
Jump to: navigation, search
(External Definition)
m
Line 32: Line 32:
 
** Triggers
 
** Triggers
 
** Stored Procedures
 
** Stored Procedures
 +
 +
=== Terminology Navigation ===
  
 
=== External Definition ===
 
=== External Definition ===

Revision as of 16:36, 10 June 2005

DB2 400 is the database built in to OS/400.

Also see DB2 article at [Wikopedia http://en.wikipedia.org/wiki/DB2]

Data Base Access

It is normally accessed directly from a high level language such as SQL, or a Data Base Tool like Query.

New files may be added via

Adding a new file is like adding a new program, only conceptually more simple minded. We use a structured language to define the layout, and if logical file include what contents in what sequence, then we compile the object.

The 400 comes with various commands that permit us to dump or display the contents of files various ways.

Features of DB2

Compared to how files could be structured and accessed on prior IBM and other platforms, DB2 had several revolutionary features that added to the potential programming power of the 400.

Some DB2 capabilities, that we take for granted today on the 400, may have been available on S/38 but not on S/36 SSP.

  • DB2 defines data at the system level
    • This minimizes / eliminates data redundancy
    • Any number of different 400 languages and database tools can access the same file layout, without needing definition within that software
  • DB2 supports
    • Data Sharing
    • Referential Integrity
    • Triggers
    • Stored Procedures

Terminology Navigation

External Definition

Before the invention of this data base reality, we could only use Internal Definition of files. That means each and every program had to have its own layout of a file, and any dumps of the file showed all the data contigous, not breaking it up into meaningful fields. Forget about being able to access the data with programs like SQL.

With Internal Definition, each program only needed to define the fields it was going to use, which meant there might not be any one place to go for the complete layout of a file.

With External Definition, part of the DB2 file structure is the whole story on the file and its field layout, which can be accessed by any programming language in the IBM family.

Internal Definition is still supported, and we can use it in a program to break an External Definition field down into smaller sub-fields such as through a Data Structure.

Internal Definition

Prior to External Definition, tthe Traditional way to define files was by describing them within Programs.

Each program would have line for line record layout.

This ran risks of mistakes by too many cooks, and was a more tedious way to program, except via /COPY layout from some library of layouts.

If there was a change needed in file layout, like adding another field, we had to change it in every program, and compile all of them. Even though most programs not using THAT new field, there was the issue of conflict with definition of size of file.

20-30 % of COBOL code was this stuff, with a lesser impact on RPG

External Advantages

By having Data Definition as part of the file itself, in addition to the Dta Records, each program need only identify the file, and the layout gets sucked into the program at compile time.

Move or copy an object, and its Descriptive Part moves along with the Data Records.