Mid-eighties. I was studying Computer Science. Little did I know back then that this thing called "The Relational Data Model" (RDM) would become huge in the IT-industry. The topic was still hot in academia at that time. My luck was that I liked those courses. Predicate Logic, Set Theory, Database Design, SQL. I aced them all. It was no surprise then, that I ended up working with Oracle software right after I graduated from university. To me it all made sense. A lot of sense, having been given the proper background the previous five years. All I had to do at that point was learn (train-on-the-job) this thing called SQLForms (and SQLReport), and off I was, building great client-server applications.
In the nineties I've seen a big influx of "professionals" that did not have the proper background. Jobless historians, foresters and psychologists, to name just a few I've personally seen, entered the IT-industry in-mass. I'm not saying this was a bad thing. It was a necessary thing. There was simply way too much work to be done with SQL databases and user interfaces. Rebuilding old IT systems that were based on hierarchical or network databases. And many of these people did a good enough job. Some of them excelled and became really good at it. And a few might have been better off looking for a job in another industry. Experiencing this time-period was eye-opening for me: if you like working with databases and doing application development, and have been given the proper education, you're king.
Those were the nineties. Happy days.
By then, for academia the RDM was fully researched and not that interesting anymore. This became visible by the students they started delivering to the job-market in the new millenium. The job-market started being flooded by developers (most notably Java), that did not have any proper education anymore about the RDM. And the weird thing? They were somehow proud of it too.
That, I've never understood.
Anyway, where am I getting at? Basically this. If you're in charge of architecting data-centric solutions, IT-systems that are founded on relational database designs, and implemented in SQL DBMS's, know that there exists proper background knowledge for this. Educate yourself in predicate logic and set theory. And how these two disciplines can be applied in the activity of designing databases. I tried to contribute in this area with the book I co-authored with the late Lex de Haan: Applied Mathematics for Database Professionals. The book is basically a brain-dump of that part of the knowledge I was offered in the eighties and still use today. On a regular basis. I kid you not.
Other authors have been contributing too. Books from Chris Date, Hugh Darwen and Fabian Pascal are certainly worthwhile too if you want to get more in-depth background knowledge on the Relational Data Model. Fabian Pascal has just recently (self) published a new book. You can find it here. He is the owner of the "Database Debunkings" website. I became aware of this website around 2001 I think. And have always enjoyed the many small articles that he has published over there. The modus operandi of Fabian is that he spots a misconception, out there on the web, and then basically debunks it. Over the years a wealth of content has been produced by him on www.dbdebunk.com. A selection of these articles have now been updated, categorized and published as an ebook. Some of the categories I find particularly interesting are, misconceptions, and Fabian's debunkings of them, about:
Checkout www.dbdebunk.com. And if you like the content over there, you will most certainly like his new ebook too.
Toon
In the nineties I've seen a big influx of "professionals" that did not have the proper background. Jobless historians, foresters and psychologists, to name just a few I've personally seen, entered the IT-industry in-mass. I'm not saying this was a bad thing. It was a necessary thing. There was simply way too much work to be done with SQL databases and user interfaces. Rebuilding old IT systems that were based on hierarchical or network databases. And many of these people did a good enough job. Some of them excelled and became really good at it. And a few might have been better off looking for a job in another industry. Experiencing this time-period was eye-opening for me: if you like working with databases and doing application development, and have been given the proper education, you're king.
Those were the nineties. Happy days.
That, I've never understood.
Anyway, where am I getting at? Basically this. If you're in charge of architecting data-centric solutions, IT-systems that are founded on relational database designs, and implemented in SQL DBMS's, know that there exists proper background knowledge for this. Educate yourself in predicate logic and set theory. And how these two disciplines can be applied in the activity of designing databases. I tried to contribute in this area with the book I co-authored with the late Lex de Haan: Applied Mathematics for Database Professionals. The book is basically a brain-dump of that part of the knowledge I was offered in the eighties and still use today. On a regular basis. I kid you not.
Other authors have been contributing too. Books from Chris Date, Hugh Darwen and Fabian Pascal are certainly worthwhile too if you want to get more in-depth background knowledge on the Relational Data Model. Fabian Pascal has just recently (self) published a new book. You can find it here. He is the owner of the "Database Debunkings" website. I became aware of this website around 2001 I think. And have always enjoyed the many small articles that he has published over there. The modus operandi of Fabian is that he spots a misconception, out there on the web, and then basically debunks it. Over the years a wealth of content has been produced by him on www.dbdebunk.com. A selection of these articles have now been updated, categorized and published as an ebook. Some of the categories I find particularly interesting are, misconceptions, and Fabian's debunkings of them, about:
- Data integrity
- Data models
- Database and application-specific functions
- Entity supertype-subtypes
- Keys (natural, primary, surrogate)
Checkout www.dbdebunk.com. And if you like the content over there, you will most certainly like his new ebook too.
Toon