Take a seat, we're talking about data modeling
Was anyone waiting for a post about data modeling? No? Anyone?
Well, youāre getting one anyway, fuck it, here goes.
Let me begin by saying that despite how it may look, with its STEMy vibes and prevalence in computer science, that data modeling is not actually very high tech. (Hell, I can do it, this should tell you everything you need to know about it.)
The definition of a data model is
āan abstract model that organizes elements of data and standardizes how they relate to one another and to the properties of real-world entities.ā
In practice, that means whenever you simplify a thing by abstracting all of its moving parts down to certain properties to gain better understanding of it, you are creating a data model. And humans do this all the time, naturally. The world is quite literally made of things that have properties and relate to each other, and the way the human mind conceptualizes these things is, at heart, by building data models. Data models are quite literally the very stuff of common sense.
In other words, you may not know how to make a data model right now, but your brain does.
Because we do this all the time without thinking about it though, people tend to not really get much practice considering about how it works and why. We understand things, but we donāt really dig down into the abstraction of how we understand them. We know things, but usually donāt ask questions about the underlying structure of that knowledge. When you start making data models on purpose however, youāre forced to think about how you think. And thatās why I love it.
Ideal Chair, or the part where we talk about Plato (I am so sorry)
Plato? You mean...
Yeah, yeah, we all know the god-damn cave allegory, like me you were probably beaten halfway to death with it in various classes all throughout high school and university. Entry level philosophy shit. But it wouldnāt be such a mainstay of the Western Philosophy 101 curriculum if it wasnāt occasionally useful, so watch me use it in this data modelling course. (If you somehow, ironically, managed to live under a rock all this time, hereās a primer on Platoās Allegory Of The Cave).
(Like most of the stuff I will end up mentioning in this post, thereās a lot more to say about it than Iām going into, but Iām a functional analyst and not a philosopher so donāt come for me, ok?)
Platoās whole shtick was that the whole world and all its sensory experiences are but shadows and interpretations, that any thing we can actually touch and perceive is only a cast-off from an Ideal, a more True and Real concept of the thing that encompasses the purest essence of all its properties and qualities. The reason for why a chair for example can look a myriad of different ways and still be instantly understood as a chair, Plato reasoned, is because there is a shadow of Ideal Chair-ness in every material chair that exists.
Now, philosophy has come a long way in the near 2400 years since Plato, but the reason people continue to find this idea poignant is because in some way it rings true.
Why do we know a chair when we see one?
What does a 13th century BC Egyptian stool have in common with, for example, the Capitello by Gufram?
Egyptian stool
Capitello lounge chair
Ehm... Youā¦ can sit on both?
Now tell me you looked at this image and didnāt think āchairā.
ā¦ So, you see, if you give it a moment of thought, odds are youāll look at Platoās cave allegory and think, hmm, maybe there is something to it. (Cue a small army of dead philosophers rolling in their graves)
That something, ladies and gentlemen, isā¦ a data model.
Remember how I said in the intro that your brain knows how to make data models even if you donāt? Yeah. Your brain is an *expert* data modeler. Your brain has built an abstract model of āchair-nessā, its properties and relations, that it refers to when qualifying things it perceives, in organic interaction with myriads of other such conceptual models. Most functional analysts can only dream of being as good at data modeling as a moderately functional human brain.
Data models are abstractions that help us understand the world -they also help us explain things to others. Specifically in the context of my job as a functional analyst, data models help us explain things to computers. More specifically still -a data model gives a developer a blueprint for how to build a computerās āunderstandingā of what things will exist in a system, what defines them, what can be known about them, and how those things should relate to each other.
There are different types of data modelling in IT, from conceptual data models to logical data models and physical data models, whichā¦ weāll get to. Letās get back to some stuff thatās not too computer-y first.
Chairs and the Data Model as Art
There is a famous piece of conceptual art, that you may or may not know about. Itās called One And Three Chairs by Joseph Kosuth, and created quite a bit of consternation when it was first exposed in 1965.
It consists of three objects, placed against a wall: A chair, with on its left, an enlarged picture of that same chair in that very location, and on its right, the English dictionary definition of the word āchairā. The artwork looks different wherever it gets exposed, as the chair and the picture are not an intrinsic part of the piece, but rather chosen and set up ad hoc according to an installation manual provided by the artist.
Thereās a lot to say about this piece -itās not quite Duchampās Fountain, but it certainly got enough people yelling about modern art, even in its day. Iām going to set aside discussion of its artistic merit however to talk about what it can teach us about data models.
The artwork, in the case of One And Three Chairs, is not actually whatās on display. The artwork is the combination of instructions that leads to a recognizable yet different setup in every place it is exposed -the concept of it. (Conceptual art, right?)
Kosuth played with that nebulous organic answer our brains have to the question āWhat is a chairā -making the viewer question the relation between the thing, its image, and its definition, and in that way it is an interesting illustration of what we discussed in the previous section. But Kosuthās piece does not really reckon with general epistemology of chairs.
It defines what counts as a chair very clearly in the context of the artwork. It defines what is a valid image of a chair too, in that context. It defines what elements need to be present and how they must relate to one another for the artwork to be a valid rendition of One And Three Chairs.
You see where this is going:
the artwork is a kind of data model.
As such, rather than get lost in the surface questions its visual seems to ask, it is more interesting to look at it as an example of a data model in action. Every time One And Three Chairs gets exposed, viewers get to see an instance of its data model. You can think of an instance is a concrete example of an abstract piece of information, likeā¦ a shadow cast by one of Platoās Ideals.
In my experience, the relationship between instance and model is somehow simultaneously clear-cut and confusing. Sometimes, the concrete situation precedes and informs the model (for example when our brain starts figuring out what a chair is), sometimes the concrete situation is created from a model (such as an art piece like Kosuthās Chairs), and sometimes the model acts as a kind of intermediary between those two -for example when a business wants to build or implement an IT solution for a certain purpose, and a data model is created to abstract the concrete business need, which is then refined further and further until it becomes concrete again, only in a software context.
Thatās what I mentioned earlier, about those ālevelsā of data modeling in IT. The transition from conceptual data model to logical data model to physical data model is an exercise in abstraction and concretization both.
You start off with a conceptual model thatās fairly legible without any tech knowledge, a high-level representation of a concrete situation or need. This gets honed into a logical model that on one hand is more abstract (further removed from the concrete real world situation) and on the other hand more concrete (closer to the structure of the required IT solution), without already fully pinning the solution down. A final step is then to refine that further into a physical model, which is an abstraction of the concrete structure of the specific software build or implementation.
(The practice is that the delineation between these different kinds of data models is very much not set in stone, every analyst and developer and project team and business kinda wings it their own way, and I have yet to work on a project where all of these were both present and fully up-to-date by the end of the project.)
So, in conclusion; data modeling really is more of an art than a science, despite what some might have you believe.
....
I guess thatās it for a first post about data models on thisā¦ vaguely data model themed blog?
