Re: the relational model of data objects *and* program objects

Kenneth Downs wrote:
> Tony Andrews wrote:
>
> > Kenneth Downs wrote:
> >> The relational model is permanently hobbled by normalization.
> > Normalization
> >> provides an astoundingly simple and powerful way to pursue
> > conformance, but
> >> it has nothing to offer in the area of *completeness*. A
normalized
> >> database is required to be incomplete, to be missing data that is
> > valuable
> >> to the computer's human masters, data that would serve them well
by
> > its
> >> existence and which causes confusion and expense by its absence.
> >
> > Please explain: how does normalization require a database to be
> > incomplete, missing data? If you mean the relationships between
data
> > in tables/relations, then that is what referential integrity
> > constraints are for!
>
> A column like extended=price*qty violates 3rd normal form and "does
not
> belong", hence my comment later in my post that pure database
theorists
> will throw away data to preserve a theory.

"Extended" isn't data. It's a function, or calculation. "Throwing it away" is meaningless, since it can be produced at will. Why the need to "store it in a column," when it needn't have a "physical location" at all? I'm very confused.

> A useful database will contain data that goes beyond normalization
into
> automation.

So beyond normalization lies automation?

Much code code implements functions, queries, and constraints that are better stated declaratively, probably in a database (or at least they're statements to be applied to a database).

> What interested me in the OP was my own question: what theory
> guides the definition, generation, and protection of automoated data?

I think there are many. Unfortunately, the interesting ones were developed and discussed decades ago, before the demand for programming drove explosions of languages, "framework", and semi-trained developers.

• erk