Oracle Designer

In terms of skills, software designers were expected to think out database structures in entity relationship models and functional decomposition models, then transform those models into database definitions and modules (the screens and reports). Software developers were then expected to elaborate the database definitions and modules to create working code. Finally the day to day running of the system was expected to be carried out by database administrators, who had detailed knowledge of the database internals.

Oracle Designer/Developer divided software development into data and applications, which were viewed at three levels of abstraction; Modelling, Design and implementation. This gives a 2x3 matrix of views which was visible throughout the product's lifecycle:

1. Entity Relationship Model. This is a high level abstraction of the database structure. Used primarily to generate the database design.
2. Database design. This is a representation of the tables, views, constraints of the database, with additional annotations. To illustrate the difference with the above; where an entity relationship model would show a relationship between two entities, the Database design would include additional columns for a foreign key, the foreign key constraint and an index over the foreign key columns. All of these could be generated from the entity relationship model, ensuring consistent naming and traceability. The names of tables and columns in many Oracle production databases in use today are due to the use of Oracle Designer. Later versions of the tool allowed specification of most of the internals of the Oracle database such as tablespaces and files.
3. Database Definition Language (DDL) generation from the Database design.
4. Function model. This is a function decomposition model, where each function contains a description and a CRUD matrix against the Entity Relationship model.
5. Modules. This modelled the screens, reports and other application components. Mostly used for screens, because of the availability of code generation for Oracle (Developer) Forms. It was common for
6. Application code. This consisted mostly of Oracle Forms, Oracle Reports, Stored procedures for the Oracle Database. Initially code was not stored in the Oracle Designer Repository, but in later versions developers were encouraged to add code to the repository, which was merged during code-generation. The client-server architecture of Oracle's Developer product was typical of the 1990s; PC computers running Oracle Forms and Reports that communicated with an Oracle Database over a network protocol called SQL*NET.

This structure was simpler than the software development processes that came before and was a better fit to the available technology. It was also simpler and led to a higher level of code generation than competing methodologies of the time such as IBM's Rational Unified Process.

Oracle Designer was initially based around a database that held design models, called a repository, not to be confused with a modern GIT repository ( A dictionary definition of a repository is a safe central place where things are stored). Later the Oracle Designer Repository included models and code, but always stored in an Oracle Database.

The tools that made up Oracle Designer each had their view on the repository, with which to create and edit models, generate more detailed models, generate code or inspect the quality of a model. For example specification designers were expected to indicate which data elements a function would use, so that the person designing the database structure could verify there were no unused data elements. Another example is the generation of a database definition from an entity relationship model, which eventually would be used to generate table creation scripts. Early users of Oracle Designer tended to focus on modelling and generating the database structures and often neglected the function model and modules.

Initially the Oracle Designer user interface was developed using Oracle Forms and Oracle Reports. This was a character mode user interface that was typically used in terminal sessions or MS-Dos, with a GUI diagram editor that ran on Unix X-Windows terminals only. When graphical user interfaces became easily available on the Windows 3.1 and Windows 95 operating systems in the mid 1990s, a stopgap version was released in Forms 4.0 but quickly shelved and redeveloped in C++ as a Windows only program with sophisticated diagramming tools.

By the time Oracle Designer became obsolete it encompassed code generation of Oracle Forms, Oracle Reports, Database triggers, Stored Database Procedures. It would be commonplace for large portions of a systems code to be generated in this fashion, with developers working around the code generators to add custom code at predetermined lifecycle events.

Oracle Designer/Developer was aimed at development of administrative systems that were mainly used internally by enterprises. Many applications appearing in the 2000s required customers to perform some form of self-service data entry. The architecture of Oracle Developer was not well suited to the needs and technologies of the internet because it would have required users on the internet to install some kind of application and then directly connect to a database. Although later versions of Oracle Developer included an application server, it required a java based plug-in to be installed in the users-browser which placed high demands on end-users browsers. This posed a challenge for organisations with a fleet of older computers and was impractical for customer-facing applications. Eventually enterprises moved to other development tools which supported HTTP/HTML form based transactions, removing the need for the associated Oracle Designer.

After introducing systems for internal business processes in the 70's to the 90's, enterprises started to place more emphasis on integration between systems. Internet technologies such as HTTP, SOAP and Web-services became industry standards for data-exchange, but Oracle Developer's architecture made it hard to activate part of an application from an external source.

From 2000 onwards, graphical user interfaces and usability became a major factor in adopting newer development stacks. Oracle Developer was intended for, and very good at administrative applications that are used for data entry by enterprise employees. New users had to be trained how to use certain key-combinations in order to user the applications. For example each screen had a query and insert mode which allowed users to find and manipulate thinly veiled database records. Screens tended to resemble a collection of spreadsheet-like tables with a menu structure. Expectations of system user-friendliness increased in the 2000s and eventually outweighed the development productivity advantages of generating these types of applications.