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 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 Onilad via Flickr
Developers routinely use data models for defining database structure. This is beneficial, but it uses only part of data modeling’s power. Data models not only capture data structure, but they also express the potential for computation. Traversals of models can provide blueprints for resolving use cases, phrasing SQL queries, and assessing quality.
Continue reading Traversal of Data Models
I’m proficient with ERwin and recently had the opportunity to try ER/Studio. I must say that I was impressed. ER/Studio is the best data modeling tool that I’ve seen to date. My experiments did not cover every aspect. But I did look at enough features to form a clear opinion.
Continue reading Comments on ER/Studio
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
picture by Rudolf Vicek via Flickr
Generally the most pressing problems for software development concern quality, time to market, and cost. If you define referential integrity (RI) in your software you can improve all three of these items. RI improves quality by ensuring that data references truly exist and cannot be dangling. RI also reduces development time and lowers cost as it takes much less effort to define RI than to program the equivalent application code.
Continue reading Do Use Referential Integrity
picture by Theen Moy via Flickr
Many organizations today outsource software development. You, the customer, specify your requirements and the vendor is supposed to build software that meets your requirements. But requirements are not sufficient as a specification. With this common scenario, you have no control over the quality of the software being built. Furthermore, you have no visibility into the software’s structure. You can improve this situation by adding a data model and a database design to your specifications.
Continue reading Do Not Outsource the Data Model and the DB Design