Tag Archives: relational databases

Getting to Know Relations

I don’t really KNOW relational databases. I’ve hung around with them quite a bit but I have no real experience. I know there are things I don’t understand about them. As with anything I’m genuinely uncertain about, I don’t even know what it is I don’t understand. I am in unknown unknowns territory.

While getting my  Umbrello UML modelling tool working again, I tripped over this:
https://docs.kde.org/stable4/en/kdesdk/umbrello/uml-elements.html#entity-relationship-diagram

It was a bit of a surprise because:
a) entity-relationship diagrams aren’t part of UML and
b) the explanation of the ‘overlapping specialisation’ example didn’t make sense to me.

I now knew this was one of the things I didn’t understand, but the KDE document wasn’t helping me. I searched for a better explanation and it took me here:

http://www.tomjewett.com/dbdesign/dbdesign.php?page=subclass.php

It uses UML class diagrams to model relations. I think this might sort me out.

Concerns

I learned to write ‘computer code’ in the era of Structured Programming. In the last few months I have come to question how much science I was exposed to in my Computer Science education. I was taught facts and current best practice but that wasn’t enough.

I’d stopped writing code professionally by the time Software Engineering became trendy, so I skipped relational databases, object orientation and coding for the web before I decided to reconnect with software development via the Business Analysis, UML modelling and Scrum Agile, Product Owner route. I THINK I know what objects are now.

When I decided to do some coding again, I at first decided to learn Python but quickly jumped ship to Clojure. I’m finding the functional model new and exciting but also unfamiliar and strange. I’ve made a huge leap into the dark, from a direction that that the text books I’m reading weren’t expecting. This post represents me taking a breath of air.

I thought I had my head around ‘separation of concerns’ into code modules, in a world made of objects. An object is a model of a real-world entity in a software simulation of reality. It represents the state of an object’s data and via calls to its methods, implements message passing between objects. What functional programming texts have shown me is that OO also invented objects that had no equivalent in the real world. In the functional world, concerns are implemented in stateless functions and state is represented by the flow of change over data structures, outside the functions.

What I haven’t yet worked out is what the “logically discrete functions, interacting through well-defined interfaces” of ‘Top-Down Design’ and ‘Step-wise refinement’ were supposed to represent. Anything we liked, I suspect, because no-one else knew either. I feel now that I was equipped with excellent knowledge of woodworking tools and the idea of furniture without being shown any woodworking joints. At least I recognised at the time that I was clueless and stopped. Many didn’t. OK, I think I’m ready to carry on.