Re: 1 NF

From: Sampo Syreeni <>
Date: Wed, 28 Feb 2007 21:55:49 +0200
Message-ID: <>

On 2007-02-28, frebe wrote:

> Is this the common opinion at comp.databases.theory too?

That's something I'm not qualified to guess. I wonder who would be.

> If yes, how is it possible at apply 1NF at all, in that case?

One can still apply 1NF if one considers each instance of an abstract datatype to be a properly encapsulated blackbox, drawn from a certain domain and having certain operations. That way, any internal structure is hidden and the relational model only concerns itself with atomic values drawn from the domain; as far as the RM goes, every domain is just a set like any other. The operations/methods in no way affect the relational formalism. They only affect what can be done with an instance once is has been extracted from a relation.

Still, I'd argue good design dictates that all of that internal structure should be exposed somewhere in the database in fully normalized, relational form. It's just that that shouldn't stop us from referring to entire, complex objects as the values of an attribute, as long as we make sure that such references are always handled on par with the atomic values drawn from other domains. I.e. we must make sure that no such reference pollutes the RM with nest/unnest operations or like complications.

> Does a blob containing an image violates 1NF? Wouldn't the correct way
> to model images be something like this:
> pixels(imageid, x, y, color)

Sorta. First, you should note that "color" is usually represented by the red, green and blue intensities in some proper coordinates. That means it's already a complex object. If your argument against arrays is valid, then you can't have a color attribute; you must have the red, green and blue values instead.

Second, yes, I'd say there has to be something *like* this in the database if we're to take full advantage of the power of the relational model. But of course there are many ways of modeling sets of images. We might have different ways of representing color, different coordinate systems, different means of breaking up the collection (e.g. a relvar for each image vs. your representation), and so on.

In any case, it should be possible for an attribute value to refer to the entire image, and preferably in a systematic fashion. From this viewpoint, the best representation would probably involve a single relvar per picture with the attributes (x, y, r, g, b), with attributes of type "image" referring to one of the image relvars.

> Does it exists any attempts to implement a relational database that
> would be able to handle images like this, in an efficient way?

I'm not aware of any, but as far as I can see, there is nothing in the relational model that would stop this from happening, either. (My own thoughts on the matter currently live at .)

Sampo Syreeni, aka decoy -, tel:+358-50-5756111
student/math+cs/helsinki university,
openpgp: 050985C2/025E D175 ABE5 027C 9494 EEB0 E090 8BA9 0509 85C2
Received on Wed Feb 28 2007 - 20:55:49 CET

Original text of this message