IBM Support

Definition of a Relational Database

Troubleshooting


Problem

This document provides the definition of a relational database.

Resolving The Problem

Short definition: A file is not relational if it is a multi-format logical file or an internally described file.

Long definition and discussion: This document defines how the system determines whether a file is considered to be a relational data base file and the guidelines for this determination. Effectively, any file which is not supported on IBM® OS/400® via SQL requests has a value of DBXREL='N' in the QADBXREF system cross-reference file indicating that the file is not relational.

DBXREL Field in QADBXREF

The only documented values are Y and N. The value will be set to Y unless the file falls into one of the following tests:

o The file is a logical file which is not an SQL view, and the file is a multiple format logical file.

o The file is a physical file which is not an SQL table, and the file is a program-described file (for example, not externally described).

Essentially, the term relational in regards to the system cross-reference files on OS/400 means:

"A relational database is a database that is perceived by the user as a collection of normalized relations of assorted degrees."

Various sources list Ted Codd's "12 rules for determining whether a DBM is relational," which was published in Computerworld, October, 1985.

The summarized rules are:

Rule Zero: For any system claimed to be relational, that system must be able to manage data entirely through its relational capabilities.

1.The information rule: All information is represented at the logical level by values in tables.
2.Guaranteed Access Rule: Each (atomic) piece of data is accessible by the combination of table name, primary key value, and column name.
3.Null support: The DBMS systematically supports a distinct null placeholder, regardless of data type.
4.A catalog: The database description is contained in user-accessible tables.
5.Comprehensive data sub-language: Must have a text-based language that supports base table and view definitions, data manipulation, integrity constraints, and transaction boundaries.
6.Updateable views: All views that are theoretically updateable must be updateable.
7.Set-at-a-time Insert, Update, Delete: The DML must support these operations.
8.Physical Data Independence: Applications must still work even when changes are made to (internal) data storage or access methods.
9.Logical Data Independence: Applications must still work even when changes of any kind (for example, adding a column to a base table) are made that theoretically should not impair the application.
10.Integrity Independence: The DBMS must support the definition and enforcement of entity integrity (primary keys) and referential integrity (foreign keys).
11.Distribution Independence: Users should not be aware of whether or not a database is distributed.
12.Nonsubversion: Alternate methods of accessing the data should not be able to bypass integrity constraints.

[{"Type":"MASTER","Line of Business":{"code":"LOB57","label":"Power"},"Business Unit":{"code":"BU058","label":"IBM Infrastructure w\/TPS"},"Product":{"code":"SWG60","label":"IBM i"},"Platform":[{"code":"PF012","label":"IBM i"}],"Version":"6.1.0"}]

Historical Number

8053217

Document Information

Modified date:
18 December 2019

UID

nas8N1010226