Logical data models are not specific to a database. At a high level, they describe things about which an organization wants to collect data and the relationships among these things. They are organized hierarchically and contain objects such as packages, entities, attributes, and other relationship objects.
Logical data models can be transformed into physical data models or UML models, and they can also be generated from physical data models or UML models. You can use these transformation features to propagate UML model designs throughout the data model life cycle. You can also generate logical data models from existing physical data models, so that you can reuse existing database designs.
These models are database-specific models that represents relational data objects (for example, tables, columns, primary keys, and foreign keys) and their relationships. For some database targets, you can also add storage objects to your physical data model such as table spaces and buffer pools.
Physical data models can be transformed into logical data models, or they can be generated from logical data models. After you have completed your physical data model design, you can generate DDL statements from the model which can then be deployed to a database server.
In addition to the use of these two data model types, you can also enforce naming standards and best practices by using data model analysis.
In addition to the four data model types described above, you can use the mapping editor to generate mapping models, which describe and map relationships among a variety of data sources. Mapping models can be used to generate scripts that you can use to transform and filter data from mapping model compliant sources to mapping model compliant targets. Mapping models can also be exported as CSV files so that you can communicate mapping model information to other team members.