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

Data modeling techniques are used in several ways -- domain data modeling (analysis), logical data modeling (detailed analysis), architectural data modeling, and physical data modeling (design). It is perfectly fine to use data models for several purposes, or different types of models for a similar purpose. For example, you can use data models, CRC models, UML class diagrams, and ORM diagrams for domain modeling; as Agile Modeling (AM) suggests, know Multiple Models so that you can and Apply the Right Artifact(s) for the situation. In this article I discuss a agile/evolutionary approach to data modeling.

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.

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.

Over the last few years we've developed a number of techniques that allow a database design to evolve as an application develops. This is a very important capability for agile methodologies. The techniques rely on applying continuous integration and automated refactoring to database development, together with a close collaboration between DBAs and application developers. The techniques work in both pre-production and released systems.

This paper describes how data professionals can take an evolutionary approach to software development, showing how techniques such as Agile Modeling, Test-Driven Development (TDD), database refactoring, and performance tuning work together on an agile project.

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.

This book excerpt develops the classes needed to implement functionality for a sample application. The chapter covers object-relational mapping, how to install HSQLDB, database design, writing a Data Definition Language (DDL) script using Ant, and setting up and understanding more advanced areas of Hibernate.

There are many challenges in systems integration for architects and developers, and the industry has focused on XML, Web services, and SOA for solving integration problems by concentrating on communication protocols, particularly in regard to adding advanced features that support message flow in complex network topologies. However, this concentration on communication protocols has taken the focus away from the problem of integrating data. Flexible models for combining data across disparate systems are essential for successful integration. These models are expressed in XML schema (XSD) in Web service–based systems, and instances of the model are represented as XML transmitted in SOAP messages. In our work on the architecture of the MSDN TechNet Publishing System (MTPS) we addressed three pitfalls. We’ll look at what those pitfalls are and our solutions to them in the context of a more general problem, that of integrating customer information.

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.