FILE ORGANIZATION
SEQUENTIAL
Records are sorted in the order that they will
be processed.
LINKED LIST
Records are stored in arbitrary order.
Processing sequence is determined by
physical address pointers to next record.
INDEXED
Indexed Sequential files are sorted in order
for batch processing with block indexes to
locate the block for a given key. Block
processing is done by scanning the block
for the desired record.
Indexed Nonsequential records are stored in
any order. A full (inverted) index locates
each record (rather than block).
Sequential Indexes are extracted location
arrays
that connect key values to
addresses.
They must be processed as
sequential files.
Tree indexes are segmented indexes that
permit revision of segments (rather than
whole indexes) to be revised when data are
added or deleted.
HASHED
Records are stored in a location determined
by a hashing algorithm.
This avoids
accessing DASD for an index, but spreads
records out across a primary storage area
making sequential processing difficult.
INDEXES
PRIMARY KEY INDEXES
These indexes maintain record integrity by
assuring that no duplicate index values are
allowed. They are normally used only for
primary keys.
CREATE UNIQUE INDEX PRODINDEX ON PRODUCT
(PRODUCT_NO);
NONKEY INDEXES
These allow efficient access to files using
nonkey data values to locate a record. The
index permits locating the proper record
without sequentially searching the file.
CREATE
INDEX
(DESCRIPTION);
DESCRIP
ON
PRODUCT
CLUSTERING INDEXES
These indexes determine the physical storage
sequence for data in the file. There can
be only one clustering index for a file.
CREATE
INDEX
DESCRIP
(DESCRIPTION) CLUSTER;
ON
PRODUCT
INTEGRITY
REFERENTIAL INTEGRITY
This assures that foreign key values refer to
valid instances of a primary key in an
associated "parent" file.
INSERTION RULES assure that new records in
dependent files refer to valid key values.
Rules may deny creation of records without
a valid parent or permit creation of the
record with a null foreign key value.
DELETION RULES control the deletion of "parent"
records that have dependent "child"
records. Choices include
1. Restrict:
disallow the requested
deletion if there are dependent children.
2. Nullify: change the foreign key value
in the dependent records to null values and
delete the "parent".
3. Cascade:
delete the "parent" record
and all dependent "child" records as well.
Referential integrity is enforced either by
transaction discipline rules in application
programs or by rules built into the database
itself.
The second procedure is more
reliable, but not built into less sophisticated
DBMS products.
DENORMALIZATION
It is good design practice to fully normalize
files for conceptual design purposes.
Sometimes these fully normalized files
produce inefficient processing. Database
administrators may chose to denormalize
some to these relations selectively to
improve processing.
Some examples of
likely denormalizations are
Entities with 1:1 relationships. It may be
wise to combine these into a single table.
M:N
relationships with non-key attributes
(gerunds). Extracting attributes from one
entity into another requires a join that
accesses the link file and the associated
entity. It may be worth violating 2NF or
3NF rules to duplicate commonly needed
attribute values in the link file or even
in the "parent" entity.
Reference data. These are 1:M relationships
in which the 1 side is a lookup table for
indicator keys in the "many" file.
If
these lookups are not used in many files
and there are not many instances of the
"many" entity for each "one" occurrence,
it may be a good idea to move the reference
attributes to the parent file and violate
3NF.