Focus on Quality

Data Warehouse Model Quality

picture by xianrendujia via Flickr

Data warehouses have a much different architecture and different business motivations than operational applications. For example, operational applications manage the day-to-day data needed to support the business. In contrast, data warehouse restructure operational data and place it in a format amenable to data mining and deep analysis. Operational applications rapidly read and write transactions with small amounts of data. In contrast, users only read data warehouses and can have extensive queries involving large data sets running for multiple minutes.

Continue reading Data Warehouse Model Quality

Focus on Quality

Operational Model Quality

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

data model

Ten Reasons Why Developers Ignore Data Models

picture by londonbonsaipurple via Flickr

Why do some developers think they can dive in and build a database application without first constructing a data model? They are violating the whole premise of software engineering which is to think before acting. Data modeling provides a means for focusing the mind and is necessary for a systematic, repeatable approach to development.

Continue reading Ten Reasons Why Developers Ignore Data Models

Database Design Errors

Miscellaneous Database Design Errors

picture by strange little woman on stream via Flickr

This is the third and final blog in a series about database design errors. The two previous blogs addressed primary key and foreign key errors as well as confusion with many-to-many relationships. Now let’s discuss several other design errors. Our coverage is clearly not complete, but these are common mistakes that are found in practice.

Continue reading Miscellaneous Database Design Errors

Database Design Errors

More Database Design Errors – Many-to-Many Relationships

picture by strange little woman on stream via Flickr

A many-to-many relationship is an intersection of two entities. A person may own stock in multiple companies. A company can have multiple stockholders. The combination of a person and a company stock has an attribute of the number of shares owned. A many-to-many relationship depends for its existence on the underlying entities.

Relational databases and SQL have robust support for many-to-many relationships. Referential integrity keeps relationships consistent with their underlying entities and SQL can efficiently combine them in queries. In contrast, programming languages lack support for keeping references consistent with referents and providing easy traversal. As a result programmers have to use workarounds to handle many-to-many relationships in their code. Sometimes they make the bad decision to contaminate a database with their programming representation.

Continue reading More Database Design Errors – Many-to-Many Relationships

Database Design Errors

Primary Key and Foreign Key Errors to Avoid

picture by strange little woman on stream via Flickr

Few IT applications are truly grass roots. Rather most new applications are intended to replace or complement existing applications. As a result, we often find ourselves working with legacy databases. This article is based on 50 legacy databases that we’ve studied over the years. In our experience about 20% of database designs are clean and problem free. The remainder have design errors. This blog discusses primary key and foreign key errors. Subsequent blogs will address other design errors.

Continue reading Primary Key and Foreign Key Errors to Avoid

building architecture

Why Doesn’t SOA Use Data Models?

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?

Traversal

Traversal of 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