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.

Database normalization is a process by which an existing schema is modified to bring its component tables into compliance with a series of progressive normal forms. The goal of database normalization is to ensure that every non-key column in every table is directly dependent on the key, the whole key and nothing but the key and with this goal come benefits in the form of reduced redundancies, fewer anomalies, and improved efficiencies. While normalization is not the be-all and end-all of good design, a normalized schema provides a good starting point for further development.This article will take a practical look at database normalization, focusing on the first three of seven generally recognized normal forms.