picture by Chamblin1 via Flickr
I’m going to do something different this month and reflect on some observations of the IT industry. My comments will focus on database-related topics. This is a smattering of ideas that is not intended to be comprehensive. I’m hoping that this article will stimulate dialogue. I welcome comments on my opinions as well as your own insights.
Continue reading IT Reflections
picture by Sir.I via Flickr
We often perform database reverse engineering as part of our consulting work. We have found that it’s common for databases to contain derived data. Derived data is data that can be computed from other base data. Often, the storing of derived data is a mistake and it would have been better if developers instead computed on the fly.
Continue reading Be Careful with Derived Data
picture by xianrendujia via Flickr
Quality is an underappreciated aspect of data models. The purpose of a model is not just to capture the business requirements, but also to represent them well. A high quality model lessens the complexity of development, reduces the likelihood of bugs, and enhances the ability of a database to evolve. There are both qualitative and quantitative measures of quality.
This is the first of a two-part series. This blog discusses quality for day-to-day operational applications. Next month’s blog will discuss data warehouses.
Continue reading Operational Model Quality
picture by Santi Mendiola via Flickr
The short answer is that’s there’s no good reason.
SOA, the Service-Oriented Architecture, is a popular approach for organizing business functionality. From the literature it’s clear that SOA’s emphasis is on programming. That’s ironic given that most SOA services deal with the reading and writing of data. We seldom see SOA developers creating substantive data models. This is a flawed approach that needs correction.
Continue reading Why Doesn’t SOA Use Data Models?
picture by Alejandro via Flickr
Over the years we’ve seen a number of projects where application architects use a generic layer to hide a database. This is a common approach with object-oriented languages accessing a relational database. Application code accesses the layer which in turn accesses the database. The use of a generic layer can be a valuable technique, but it is overused. Some architects seem to be unaware that there are other possibilities.
Continue reading Be Wary of Generic Database Layers