Previously called Microsoft code name “Oslo”, SQL Server Modeling is a forthcoming set of technologies (presently in CTP) for solving problems around modeling data in your applications. SQL Server Modeling (or SSMod) enables you to describe your models, store them, and edit them. This represents a full life cycle for your models and the system simply becomes a runtime to consume the data contained in the models. Let’s see how this would work in a simple example.

As you may already know, “Oslo” is a Microsoft effort to make it easier to build data-driven applications. “Oslo” consists of three major pieces:
* A modeling language: ”M”
* A modeling and data visualization tool: “Quadrant”
* A repository: a SQL Server database
This paper is the view of “Oslo” from a data perspective. The components most important to an enterprise and databases, “M” and the repository, will be discussed first; we’ll take the data visualization tool just introduced in the “Oslo” May CTP, “Quadrant”, for a spin towards the end of the paper.

This article summarizes experience of applying Incrementally agile discipline to database development, reducing up-front design work to just-in-time work that matched to 2 week development iterations.

The normal forms defined in relational database theory represent guidelines for record design. The guidelines corresponding to first through fifth normal forms are presented here, in terms that do not require an understanding of relational theory. The design guidelines are meaningful even if one is not using a relational database system. We present the guidelines without referring to the concepts of the relational model in order to emphasize their generality, and also to make them easier to understand.

In the second of two articles, the authors describe how to develop business patterns based on business functions, data, and business components, and show how these can be used to engineer software systems.

No list of mistakes is ever going to be exhaustive. People (myself included) do a lot of really stupid things, at times, in the name of "getting it done." This list simply reflects the database design mistakes that are currently on my mind, or in some cases, constantly on my mind.

Project documentation is often one of the necessary evils in delivering a software product. But imagine being able to generate your documentation at the click of a button. In this installment of Automation for the people , automation expert Paul Duvall explains how you can use open source tools to automate the generation of Unified Modeling Language (UML) diagrams, build figures, entity-relationship diagrams (ERDs), and even user documentation.

A fascinating discussion of five common database design errors which persist in spite of the fact that the unfortunate consequences of their use is so widely known. It is a needy reminder to anyone who has to design databases.

This article offers a step by step approach to transform a UML object-oriented class model in a purely relational database.

Relational and dimensional modeling are often used separately, but they can be successfully incorporated into a single design when needed. Doing so starts with a normalized relational model and then adds dimensional constructs, primarily at the physical level. The result is a single model that can provide the strengths of its parent models fairly well: it represents entities and relationships with the precision of the traditional relational model, and it processes dimensionally filtered, fact-aggregated queries with speed approaching that of the traditional dimensional model. Real-world experience was the motivation for this analysis: on three separate data warehousing projects where I worked as programmer, architect, and manager, respectively, I found a consistent pattern of data/database behavior that lent itself far more to a hybrid combination of dimensional and relational modeling than to either one alone. This article discusses the hybrid design and provides a fully functional reference implementation.