Home > Blog > Data-orientation vs. Document-orientation 3: Putting it back together again

Data-orientation vs. Document-orientation 3: Putting it back together again

Posted by jimcarls on September 27, 2011

Previously, we've shown that an "all-in-one" spreadsheet approach to documenting FF&E specifications is cumbersome and hard to keep updated, In the second segment of this series, we looked at how designers naturally turned to a more "data-oriented" two-part approach that was also a step towards a more efficient way to organize data.  That method, called "normalization" by your local Nick Burns types, is fairly strict deconstruction of data into "tables" similar to filing cabinets, each holding either a specific type of unique data (like "rooms" or "vendors") or a type of relationship (like "objects in rooms"). Below, we will finish the deconstruction process and then put it back together, but this time, without having to repeat data.

The last segment ended with a metaphor for the way that a "document" is created by database software: stapled sheets of translucent paper that were pulled from file drawers for an FF&E object, its product specifications and the related vendors — stacked so the whole "picture" of an FF&E object could be seen.  I hope that example was relatively easy to visualize.  Now, let's talk about how the usage of an object in a room is represented in a "normalized" set of data.

Here's something to think about: When truly normalized, a sheet from the room drawer would only have information about that room's base characteristics (name, budget, room count, etc.), but not the actual items in the room. Why? Because it's in the Official Room Drawer and each sheet in it must define just a room, not another list. So where does our list of room contents go? That turns out to be very simple but requires that we truly think in terms of data and their relationships: How are objects related to rooms? How are rooms related to objects? 

Answer: Rooms can point to the objects used in them.  But wait, can't objects also point to the rooms in which they are used?  This isn't as silly as it might sound, because objects can be used in more than one room.  So, one relationship can be used to produce a list of all that goes into a room (as our original examples did), but the other can be used to produce a list of the rooms into which an object needs to go.  Aren't both equally useful?  Aha! Now we are asking "data-oriented" questions!

So despite our first inclination to think that the list of objects in a room is part of the room sheet itself, it can't work that way because the relationship is actually an equal one, not the "parent-child" type of a manufacturing vendor to its products:  Rooms can own multiple objects and objects can "own" multiple rooms.

So (bear with me) we need a "Usage" Drawer containing sheets for each "occurrence" of a specific object in a specific room and the quantity needed for that usage. Each sheet only contains a reference to one room (Room ID), a reference to an object (Tag) and the quantity needed in that usage (location). The resulting table tabulating our sheets would look more like this (again, with each sheet from our new Usage Drawer equal to one row in the table):


Now, here's something interesting: We already showed you this in the first entry of this series. After we had color-coded the "repetitive" columns in the huge "flat" spreadsheet to show those that really belonged to the room, object or vendor data, we were left with a small set of columns that were not color-coded.  These columns represented the truly unique data in that spreadsheet, because a list of rooms and what goes in them (and how many) will only have one entry for each combination of location and object. 

So, our file cabinet of sheets recording "usages" is the heart of the data structure, pointing outward to rooms (that point to areas pointing to the project they are in, which points to the client of the project) and to objects (that point to specs pointing to vendors).  Changing the "usage" of an object in a room really means either 1) changing the room to which we point (moving the object), 2) changing the object to which we point (replacing it with a different object), 3) changing the quantity used in the room or 4) deleting it (trashing the usage sheet but not the object itself).  Just to be sure we understand this:  If you enter (actually, select) a different Room ID on the usage list, you are pointing to a different room — not "changing" the Room ID — therefore you are moving the object.  If you enter a different object Tag, you are pointing to a different object — not "changing" the Tag — and are replacing the object with another one.  This is "data oriented" thinking:  the Room ID and the Tag only truly exist in the room list and the object list, respectively — on any other list, they are pointers into the list of rooms and the list of objects.  These pointers are only changed by pointing to something else (or not pointing to anything at all).

Okay...we realize that many of you are shaking your heads right now and thinking "What is this, Deconstructivism for anal-retentive design über-nerds?  Why would we want to scurry from one file cabinet to another looking up information? What do you mean, 'one usage per sheet?' Aren't our jobs hard enough?

And decades ago you would be right to ask this, because no matter how efficient it may be to keep the data for something in just one special filing cabinet for that type of something, it would be simply inhuman to force people to use a system where they have to look up information every time they want to produce a document.

Which is why we use a computer to do it quickly and automatically:


This screenshot of a database display (the FF&E Worksheet grid from FF&EZ) looks a lot like the original "flat" spreadsheet shown in the first segment of this series.  Like that spreadsheet, its columns can be sorted (although much more easily) and it displays a lot of detail about the data, including items that repeat from one room to another.  However, like the simpler "usage" spreadsheet shown further above, this display really only contains three pieces of data: the location (Room ID), the object being used (its Tag) and the quantity used in the selected room.  Everything else is assembled on the screen just like our "stapled sheets of paper" metaphor.  The process is even more obvious if we were to color code the project book sheet from the earlier blog entry, showing how the database software assembles this report for us, instead of our having to create it manually:


By now, having endured more information about databases than you ever wanted, you should be able to guess that the spreadsheet-like display of the FF&E Worksheet and the project book "document" shown here are both produced from the same data sources.  If you were to change something on the Specification Screen where this piece of artwork is defined, both the FF&E Worksheet and this report would show that change the next time you viewed them.  Of even more interest is the "Auto-calculated" section, in which not just total quantities are shown, but the "Locations" in which this object is used. Since the software defines the relationships in the database between rooms, objects and specs, it can automatically link to the four numbers that are needed to do quantity and extended price calculations:

  1. The room type count (room mix)
  2. The quantity of an object used in a room
  3. The quantity of a product used in an object
  4. The unit cost (and/or price) of a product

Thus, with a properly set up database automatically pulling these numbers and multiplying them as needed, we never have to do any math ourselves.  This is a good thing, yes?

In future posts, I will add some practical examples of how database management software can allow you to do much more than simply produce specifications.

Bookmark and Share