The process of normalizing data necessarily includes some discussion of the concept of “atomicity.” An item of data is considered “atomic” if it cannot be decomposed into smaller pieces of meaningful data. But this concept is a bit fluid, since the achievement of atomicity changes with respect to how the data is actually used. Here’s an example: I live at 1150 Morrow Road. I’m going to consider that a single unit of data, which will be stored in a field called ‘address.’  Seems simple enough, but it’s obvious that this data might not be considered atomic. After all, the house number – 1150 – is meaningful without the street name. And if there is also a Morrow Avenue, well, then there’s another useful piece of information. So should be break this down into the fields of HouseNumber, RoadName, and RoadType? And if you do that, can we assume that the house number is always a number? What about 21B Baker Street? Or 2015½ Blanch Drive? That last was actually my address when I lived in a carriage house above a garage behind the main house. Unless you’re a delivery service or political party, separating the house number from the street name gains little (if any) advantage, but does create unnecessary complexity, since that data is virtually always concatenated. Part of software engineering is becoming a domain expert in whatever field you are working in today. And it is that domain expertise that will be your guide to data atomicity.

So now we come to those little holes that assisting in tearing sheets of stamps into individual stamps. Although less common than they once were, these perforations are significant to most collectors, and differences in the number of holes per centimeter can mean different varieties of an individual stamp. Generally, stamps have 4 sides, and usually all 4 have the same perforation. Sometimes, stamps have no perforations along one or more edges (as in booklet panes or in coil stamps). And sometimes the horizontal perforation may be different than the vertical perforation (often the case stamps printed on a rotary press versus a flat plate press).

So I decided that I would use 4 fields for perforations: Top, Bottom, Left, and Right. I knew when I did this that I was going to have to account for triangular stamps, but since Israel did not have any (that I knew of), I could put it off, knowing that I had all the compound perforations covered. Until a couple of things happened: Countries started printing stamps in many shapes, including pentagons, hexagons, and hearts. The second is that in more than 10 years, having separate fields for each edge did not turn out to be useful. But they did make ToString() functions more difficult to create. So the first change was to go back to a single field for Perforations. This actually reflects how stamps are described in catalogs and sold in auctions. And on the rare occasion when a stamp has compound perfs, the actual perfs are used in a string (e.g. TB: 13½ L:13¼ R:13¾).

So, technically, this data is not in the first normal form. Or, then again, technically, it is.