This article explains an application development approach advocated by many proponents of agile application development that can cause future problems for developers, while potentially sacrificing the integrity and reusability of the data.

This paper presents an approach to enterprise data architecture that doesn’t require total buy-in by top management but can still deliver on the basic goal: improving the quality of shared data.

Just as a transformation is required to convert an entity/relationship model into a relational database design, so is one required to convert an entity/relationship model into an object-oriented design. This may involve an automated process of attaching class names to role names, as well as manual efforts to add UML design adornments such as navigation and composition (and, of course, behavior). Because the meaning of the models is different, should the notations be different? There are strong arguments for making it so, but these articles attempted to show that this is not required for the models to make sense. Whatever notation is used, precise, semantically clear models can be produced. To do so is worthwhile, regardless of the particular experiences of the modeler.

Modeling the blueprint for MDM is a key differentiator and the difference between success and failure among major initiatives.

This article explores the ways hierarchical structures can be used to significantly increase data value and its utilization.

This is a proposal how to name and describe data models, where we relate to the various rows in Zachman Framework.

Here we explain how the new hierarchyID data type in SQL Server 2008 helps solve some of the problems in modeling and querying hierarchical information.

This article explains how companies create and standardize their common business language – terms, definitions, and related metrics – to prevent “metrics confusion,” accelerate deployment and maintenance of enterprise information systems, and increase focus on analyzing and decision making instead of collecting, debating, and reworking numbers. The result is improved quality of enterprise information systems and greater efficiencies in the deployment, maintenance, and consumption of information.

Fixed structured data keeps businesses running day in and day out. But supporting only fixed data is also extremely limiting to structured data processing. There is no reason that highly principled structured data processing has to be limited to static data structures. Dynamic data structures enable a new set of powerful, unlimited data processing opportunities. As an example, it would be very useful to have a highly flexible and principled hierarchical data processor to support dynamic structured data processing automatically. This article presents an example of such a dynamic structured data processing application and how it operates.

Reference data has many definitions. The one that I use is the following: "Reference data is any kind of data that is used solely to categorize other data found in a database, or solely for relating data in a database to information beyond the boundaries of the enterprise."

In practice, this means that reference data is nearly always “code tables.” These are tables that typically have a code column and a description column, and probably fewer than 200 records – in fact, they typically have fewer than 20. Another feature of reference data tables is that the data in them does not change very often. All of these characteristics tend to combine in the minds of data management professionals to generate the conclusion that reference data tables are unimportant and have no special management needs. There is, for instance, much greater interest in the (relatively) gargantuan master data cousins of reference data tables, such as Customer and Product. Yet, as we will see, it is impossible to deal with tables like Customer and Product without effective governance over reference data.