modeling	Data modeling stands for us at the beginning of the design and development process. Creating a data model in the last phase of a project - e.g., by reverse engineering - and using it solely for documentation purposes bears two main inconveniences. On the one hand, such a data model becomes obsolete after a short time; on the other hand, it makes no use of powerful Computer Aided Software Engineering mechanisms. A data model should rather be created in the first project phase and used as a basis for the entire development process. This paradigm enables on the one hand a simplified description and a better understanding of complex realities and interdependencies. On the other hand, it supports the maintenance, changeability, and enhance ability of existing database structures considerably. Whenever possible, the data model should be used for code generation, which can encompass, beside "classic" object types, such as tables and views, also procedural objects - procedures, packages, or triggers - as well as synonyms, sequences, types, etc. Ideally, the complete database structure could be generated from the data model. Being the first step in the development chain, the data model should be the master: each change and each enhancement should be done first in the data model, then the code should be generated there from, and be implemented eventually in the database. A straightforward process with clear roles - the data model is the master, the database is the slave - leads to simplifying development and avoiding collisions and inconsistencies. The following example shows an excerpt of a data model built with CA-ERwin. The code generated from this data model - including further objects, generated by macros - is shown, also.