I've included a brief paragraph after eac h rule describing the extent
to which I believe Fileman satisifies Codd's rules. Comments?
Dr. E. F. Codd's 12 rules
for defining a fully relational database
Note that based on these rules there is no fully relational database
management system available today. In particular, rules 6, 9, 10, 11
and 12 are difficult to satisfy.
0. Foundation Rule
A relational database management system must manage its stored data
using only its relational capabilities.
Fileman fails this criterion because data retrieval and update is
possible using direct global a access.
1. Information Rule
All information in the database should be represented in one and only
one way - as values in a table.
Fileman satisfies this criterion, though tables may correspond eithr to
top-level files or (nested) subfiles joined with the appropriate key.
An alternate view is to treet subentries as objects.
2. Guaranteed Access Rule
Each and every datum (atomic value) is guaranteed to be logically
accessible by resorting to a combination of table name, primary key
value and column name.
Fileman satisfies this criterion.
3. Systematic Treatment of Null Values
Null values (distinct from empty character string or a string of blank
characters and distinct from zero or any other number) are supported in
the fully relational DBMS for representing missing information in a
systematic way, independent of data type.
This is open to interpretation. Fileman does not distinguish between
nulls and non-valued fields, but a field may be non-valued independent
of its data type.
4. Dynamic On-line Catalog Based on the Relational Model
The database description is represented at the logical level in the
same way as ordinary data, so authorized users can apply the same
relational language to its interrogation as they apply to regular data.
Fileman comes close to satisfying this rule. Unfortunately, the data
dictionary is not a true file, and cannot be manipulated using the same
tools (APIs) as other files. Therefore, it fails.
5. Comprehensive Data Sublanguage Rule
A relational system may support several languages and various modes of
terminal use. However, there must be at least one language whose
statements are expressible, per some well-defined syntax, as character
strings and whose ability to support all of the following is
comprehensible:
data definition
view definition
data manipulation (interactive and by program)
integrity constraints
authorization
transaction boundaries (begin, commit, and rollback).
Fileman provides some, but not all, of these features. the DBS API is
not an independent language, but comes close to being a relational data
manipulation language for Fileman. Views are defined via screens, and
screens do not conflict with update (LAYGO). In many (most?) cases,
integrity constraints can be defined through Fileman, but it is often
necesary to resort to writing code by hand (screens, input transforms,
etc.). There is comprehensive support for authorization, but no
transactions.
6. View Updating Rule
All views that are theoretically updateable are also updateable by the
system.
Fileman meets this criterion (see above).
7. High-level Insert, Update, and Delete
The capability of handling a base relation or a derived relation as a
single operand applies nor only to the retrieval of data but also to
the insertion, update, and deletion of data.
Fileman meets theis criterion by virtue of the DBS API. Classic Fileman
does not meet this criterion.
8. Physical Data Independence
Application programs and terminal activities remain logically
unimpaired whenever any changes are made in either storage
representation or access methods.
Fileman satisified this criterion by virtue of platform independence.
9. Logical Data Independence
Application programs and terminal activities remain logically
unimpaired when information preserving changes of any kind that
theoretically permit unimpairment are made to the base tables.
I'm not sure about this one, but I think it probably does not satisfy
this critertion.
10. Integrity Independence
Integrity constraints specific to a particular relational database must
be definable in the relational data sublanguage and storable in the
catalog, not in the application programs.
Fileman clearly does not satisfy this criterion, at least in its
present form.
11. Distribution Independence
The data manipulation sublanguage of a relational DBMS must enable
application programs and terminal activities to remain logically
unimpaired whether and whenever data are physically centralized or
distributed.
This is debatable, but Fileman probably inherits distribution
independence from the global subsystem, and so does satisfy this
criterion.
12. Nonsubversion Rule
If a relational system has or supports a low-level
(single-record-at-a-time) language, that low-level language cannot be
used to subvert or bypass the integrity rules or constraints expressed
in the higher-level (multiple-records-at-a-time) relational language.
Fileman pointedly fails to meet this criterion, but a possibled future
version might disallow direct global access, thus preventing this type
of subversion.
--------------------------------------------------------------------------------
REFERENCES
Codd, E. (1985). "Is Your DBMS Really Relational?" and "Does Your DBMS
Run By the Rules?" ComputerWorld, October 14 and October 21.
Elmasri, R., & Navathe, S. (1994). Fundamentals of Database Systems.
2nd ed. Redwood City, CA: The Benjamin/Cummings Publishing Co. pp. 283
285.
===
Gregory Woodhouse <[EMAIL PROTECTED]>
"It is foolish to answer a question that
you do not understand."
--G. Polya ("How to Solve It")
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Hardhats-members mailing list
Hardhats-members@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hardhats-members
