Transformation

Having a conceptual information model of the business information in your company is a great asset. This guarantees steady investment of IT efforts since it is implementation independent. Since IT changes technology every few years the only real long lived asset should be the information model.

However the IT needs to do it's bit and how to support their database and software developers. Similar to the repository based diagram we can create a representation of this information towards a certain implementation technology.

Whether you need to create a optimal normal form database without any redundancy, or have the need for a UML class diagram or event a data warehouse dimensional model, FCO-IM in al it's richness can perform transformations on the repository to generate a implementation specific platform model. (Off course losing some meaning in one way or the other, but this is because the lack of expressive power in other modelling methods.)

Relational Model (GLR)

Transforming a conceptual model into a relational model doesn't yet mean there's information lost, information is simply altered but with the same syntactic meaning. The transformation algorithms use the so called GLR (Group Lexicalize Reduce).

Group

Grouping is simply based upon facts which have a role played by a Label and a unique role played by a Object. This makes them candidates for becoming a column (fact) in a table (object) with a domain (label). Below a diagram snippet which would propose the 'Emergency Exits' as a groupable entity.
The SQL DDL representation for this diagram snippet would be:

  CREATE TABLE FLOOR (
  EMERGENCY_EXITS EXITS_NO
  )

Note that only part of diagram is displayed and we'll notice a difference for this example as more is explained further on.

Lexicalize

Lexicalizing is necessary to create a actual DDL statement. Since every attribute in a table must be of a certain data type or domain every Role in the model must be played by a Label. This has serious consequences from a diagram perspective. Note the roles from the Room example which are marked with a 'L' to be candidates for Lexicalization.
Roles with number 1, 4, 7, 8, and 9 all aren't played by Labels but by other Objects and therefor are candidates to be Lexicalized for Relational purposes.

Note that the example diagram is to be different if also Reducing considered, this is explained in the next paragraph.

Reduce

Reducing is basically the collapsing of Objects into facts if all roles they contain together are uniquely identifying the Object. Consider the (R) marks in the following diagram for Floor and Room.

GLR

Performing the Group, Lexicalize and Reduce in a single transformation would render our model into a ER model. Below is a diagram after the GLR proposals are performed:
The ER model can be exported into SQL DDL which will extend the earlier mentioned Floor table in the following:

  CREATE TABLE FLOOR (
   FLOOR_NO FLOOR_NO NOT NULL,
   EXITS_NO EXITS_NO NOT NULL,

   CONSTRAINT PK_FLOOR PRIMARY KEY (FLOOR_NO)
  );

Other conversions

Besides ER there are lots of other implementation specific modelling environments. For instance UML, Data Warehouse, and XML Schemas.

All these implementation models can be transformed from FCO-IM conceptual models. The case-tool already has build in conversions for ER and has export plugins for Oracle, Ms Sql Server, Interbase/Firebird, MsAccess and many more.

For conversions towards other tools external conversion tools are available which work together with the case-tool to provide a wider range of platforms to export to.

The StarBridge tool allows IT personnel to convert the FCO-IM repository into a Data Warehouse model maintaining full expressions which automatically document the new dimensional models. This is a powerful tool which has a nine step decision path which leads automatically to the desired dimensional model.