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.
Identifiers aren't locators, and they aren't pointers or links either. They are a logical concept in a relational database, and, unlike the more traditional methods of accessing data, don't derive from the way that data gets stored. Identifiers uniquely identify members of the set, and it should be possible to validate and verify them. Celko somehow involves watches and taxi cabs to illustrate the point.
For application developers focusing on the needs of their code, rather than worrying about the complexities of data representation, the Entity Framework’s abstractions are essential. But eventually a database needs to be created, and this article shows how it’s done.
This article presents how a Strategic Model is developed for rapid delivery of Enterprise Architecture. It also shows how project plans and associated project maps can be derived from a data model to manage the rapid delivery of priority business activities and processes into production as systems. These project plan and project map derivation concepts have not previously been used in data modeling.
This article discusses the different types and uses of data models what they are good for, what the differences are between them. The author then analyzes the needs of an integration architecture and the special requirements it puts on a data model.