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
A diffuse relationship is one of a group of similar relationships, which broadly apply to entities in a model. We can show them explicitly, but such an approach can become verbose and obscure the deeper content of a model. We coined the term “diffuse relationship” as we haven’t seen this phenomenon named by others.
Continue reading Diffuse Relationships
A symmetric relationship is a self-relationship with the same multiplicity and role name on each end. Symmetric relationships are acceptable for conceptual models. But they are problematic for logical and physical models – you should rework the model to eliminate them.
Continue reading Beware of Symmetric Relationships
In a blog last year we discussed database archaeology, which is another name for database reverse engineering. Reverse engineering is the inverse to normal development. We start with an application and work backwards to understand the software and infer its content.
This month we’ll take a further look at database reverse engineering, from the perspective of a simple case study. We’ll reverse engineer the database beneath WordPress and populated with a snapshot of the data for this website. The case study illustrates mechanics and the kinds of insights that reverse engineering can provide.
Continue reading A Database Reverse Engineering Case Study
picture by mab7752722 via Flickr
Once you’ve created a data model, how do you document it? You need to deliver the model’s content to others – to business sponsors, other developers, and posterity for purposes that you may not envision. This article looks at options for documenting data models and their trade-offs.
Continue reading Documenting a Data Model
picture by Kanban Tool via Flickr
I’ve been practicing agile database techniques for about twenty years now. My use of agile techniques didn’t start as an explicit plan. Rather it evolved over time as I was working on consulting projects. It made sense to look for ways of working faster and better and with greater customer interaction.
I can think of at least three kinds of agile database techniques.
- For data modeling.
- For data warehouse development.
- For database reverse engineering.
Continue reading Agile Techniques Are Helpful with Databases
picture by londonbonsaipurple via Flickr
Here is a follow-on to our blog from several months ago on “Ten Reasons Why Developers Ignore Data Models”. Paraphrasing, reader Lawrence Hecht asked via Twitter if there is any way to tell from a schema if the developers had used a data model.
Continue reading Ten Reasons Why Developers Ignore Data Models — Revisited
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