CaseTalk supports Fully Communication Oriented Information Modeling (FCO-IM). This method evolved in the early 90's as a continuation on a previous developed method called NIAM. It focuses on the problem domain and not the implementation domain.
The method FCO-IM is focused on capturing the communication by domain experts (the business) on their data using natural language and real examples. This guarantees the domain experts are always able to validate the information model at any point in time. Since it focuses on the universe of discourse it is called an information model.
"An information model provides formalism to the description of a problem domain without constraining how that description is mapped to an actual implementation in software. There may be many mappings of the information model. Such mappings are called data models, irrespective of whether they are object models (e.g. using UML), entity relationship models or XML schemas." ~ source:wikipedia
Conceptual Model
A conceptual model is usually a high level model where various concepts from the world of the mind, or the real world, are presented without touching implementation details. It serves a purpose to mentally scope the range of the data model, and outline the broad relations between concepts. It is somewhat on the same level as the information model, but far less formal or detailed. Although sometimes usefull to the business it is usually just used as a way of graphically communicating the broad scope of concepts of interest from the problem domain with the domain experts. From CaseTalk a list of concepts can be extracted from an information model. CaseTalk has a more formalised method of information modeling, without implementation details either. In that respect the fact oriented modeling community calls this approach also conceptual modeling. Yet remember it is used in slightly different context. (See also: Zachman Article.)
"The term conceptual model is normal. It could mean "a model of concept" or it could mean "a model that is conceptual." A distinction can be made between what models are and what models are models of. With the exception of iconic models, such as a scale model of Winchester Cathedral, most models are concepts. But they are, mostly, intended to be models of real world states of affairs. A conceptual model's primary objective is to convey the fundamental principles and basic functionality of the system which it represents. Also, a conceptual model must be developed in such a way as to provide an easily understood system interpretation for the models users." ~ source:wikipedia
Data Model
Once facts are captures and additonal constraints are placed, CaseTalk is able to transform an information model into a data model. A data model can then be used directly for implementation, or transferred to other more implementation focused tools. The typical realm of data modeling tools such as Powerdesigner, ER/Studio, ERwin, etc. CaseTalk supports model transformations towards messaging implementation through xml, software development through uml classes, and database development using conceptual, logical and physical data models.
"A data model explicitly determines the structure of data. Data models are specified in a data modeling notation, which is often graphical in form. A data model can sometimes be referred to as a data structure, especially in the context of programming languages. Data models are often complemented by function models, especially in the context of enterprise models. Data models describe the structure, manipulation and integrity aspects of the data stored in data management systems such as relational databases." ~ source:wikipedia
Logical, Physical Model
Different data models have different technical requirements for the implementation that they serve or represent. When a data model is build to serve a database implementation, usually a designated tool is used. Traditionally these offer a form of conceptual modeling, logical modeling and physical modeling. With these three layers tools attempt to offer a way of working to come from high level, to a more detailed level, to an implementation level of database systems.
Dimensional Model
For data warehouses data us retrieved from various source systems and converted using Extract Transform and Load methods. The final target database where all temporal data is gathered requires a dimensional model. A dimensional model again can be build using different methodologies. Using the BridgeToolset such a dimensional model can be transformed out of an information model. Also various integrated data warehouse generators are available skipping any modeling by simply mapping source system to target system.
"Dimensional modeling always uses the concepts of facts (measures), and dimensions (context). Facts are typically (but not always) numeric values that can be aggregated, and dimensions are groups of hierarchies and descriptors that define the facts. For example, sales amount is a fact; timestamp, product, register#, store#, etc. are elements of dimensions. Dimensional models are built by business process area, e.g. store sales, inventory, claims, etc. Because the different business process areas share some but not all dimensions, efficiency in design, operation, and consistency, is achieved using conformed dimensions, i.e. using one copy of the shared dimension across subject areas. Dimensional modeling is oriented around understandability and performance." ~ source:wikipedia
Canonical Model
CaseTalk supports multiple independent universes of discourse while simultaneously supporting the re-use of common facts across these universes. This allows the information models to transcend even the relatively simple domains of application silos and their implementation specific data models. To support the integration of application domains on a technical level the canonical model is introduced. This is simply the integration of implemented data models of various applications. CaseTalk allows the analysts to model these domains on the level of information models either by modeling pieces of various domains, or by merging them from existing information models.
"A canonical model is a design pattern used to communicate between different data formats. A form of enterprise application integration, it is intended to reduce costs and standardize on agreed data definitions associated with integrating business systems. Often the term canonical model is used interchangeably with integration strategy and often entails a move to a message-based integration methodology. A typical migration from point-to-point canonical data model, an enterprise design pattern which provides common data naming, definition and values within a generalized data framework." ~ source:wikipedia
Technology Agnostic
To be able to model the communication of the domain experts and aligning the various universes of discourse, integrating them on a high level, without concerns of implementation layers, allows analysts and architects to build a consistent set of terms, definitions and rules across the enterprise from high level business all the way through the implementation models.
Capturing that knowledge, transform it into data models, and bring the domain experts knowledge and language into the realm of implementation makes the method of FCO-IM and the tool CaseTalk very valueable. These information models are technology agnostic and therefor outlive the latest trends, newest implementation and organisation changes.
For a graphical representation of the model dependencies, read more here.
