Re: Normalization by Composing, not just Decomposing

"Laconic2" <laconic2_at_comcast.net> wrote in message news:j4ydnTr4kfSPVOfdRVn-hw_at_comcast.com...
> Your original question started me thinking in a new direction. While
others
> and I would like to keep the word "normalization" reserved for a
relatively
> specific concept, there's no reason why we can't start with individual
data
> values or variables, and compose our way up to schemas.
>
> But first, I want to suggest that you can analyze a body of data values
> (which I'll just call "items"), back to entities without regard to
> relations as such.
>
> The following are assumptions of mine, although some of them can be
derived
> from some minimal set of assumptions. You may agree or disagree.
>
> Every (instance of a) data value specifies an attribute.

I honestly don't have any idea what this means. When you say "instance of a data value", do you mean a specific physical representation? An appearance or specific encoding? 7 is a value - how does that figure into the above?

I really don't know what "specifies an attribute" means. An attribute typically "has" a name and a type.

> Every attribute has a domain, which is the set of values that can specify
> the attribute.

"Specify" is again confusing. An attribute is of a specific type (domain), and therefore something (we'll remain deliberately vague here) "with" that attribute will "have" a value chosen from the set designated by the type (domain), subject also to additional constraints.

> Every attribute describes either a relationship or an entity.

1. What's the difference between a relationship and an entity?
2. Can an attribute "describe" more than one? For example, an attribute called Name of type CHARACTER (unlimited length) - can that attribute be used by multiple "things"?

> Every relationship associates two or more entities.

Association meaning any relationship at all? Since a relationship can have attributes, and entities can have attributes, what's the difference?

> The entities are discovered from the underlying ontology of some subject
> matter.

Oh how I loathe the word "ontology" - much like "methdology", it's been absconded with and sorely molested.

> Notice that, in the above, I've said nothing about columns, rows, tables,
> schemas, tuples or relations. Or for that matter about databases, files,
> lists, or the like. It's just a body of data consiting of values.
>
> Now we can proceed to the question of composition.

But you already have - for example, you've described the composition of relationships, and something about their attributes. What separates that level of composition from the one you're about to describe below?

> We can compose lists,
> fields, records, files, columns, rows, tables. Take your pick, or go
> consult the oracle at Delphi. The question is, when does it make sense
to
> compose data into a structure, and when does the composition do more harm
> than good?

Your basic definitions are of course the building blocks of other things, but the above needs some solidification. I would say it makes sense to compose data into a structure when that structure it what you want - in order to specify what you want, you need some sort of query or specification language, along with rules for how scalars are referenced by propositions (or something like them), and how those propositions and scalars are composed with others to build something else (e.g. the structure you're looking for, or something along the path to it).

• Eric