It is common in most green field development projects to have some type of data modelling tool (e.g. ERWin, SQL Modeller, Toad Data Modeller) in use...
It is common in most green field development projects to have some type of data modelling tool (e.g. ERWin, SQL Modeller, Toad Data Modeller) in use. These tools are often used up to the point of production deployment. It is quite common for data model management practices to lapse or fail after this point. It is not uncommon for data models to be managed on an ongoing basis by adhoc development scripts. This approach can be inefficient and error prone. I have found the Oracle SQL Modeller tool to be valuable in the way that it can be used to manage data model versions and to generate DDL scripts which migrate one model (e.g. production data model) to match another (e.g. UAT data model). An example is outlined below.
Consider the scenario where you have a new version of a data model in UAT that needs to be deployed to Production. Figure one below illustrates an example production schema (Demo_V1) for a student database, while figure two illustrates a UAT schema (Demo_V2).
You will notice that the UAT model has additional objects relative to the Production model.
In a normal development cycle, scripts would need to be prepared to migrate model V1 to model V2. This can be achieved in Oracle SQL Modeller using the Tools->Compare/Merge Models option.
Figure three below illustrates the output of the model comparison process.
Clicking on the DDL Preview button illustrated in figure three above facilitates the viewing of the SQL DDL code which will migrated model V1 to model V2. This is illustrated in figure four below.
With reference to figure 4 above, it can been seen how running the script in figure four against the production database (V1) would alter it to match the UAT database (V2).
Considering the above example, it is easy to see how Oracle Data Modeller in conjunction with good version control tools and processes can be used to migrate data models/environments in an efficient and risk free manner.
By Stavros Mothonaios, Senior Software Developer
In today's market, finding the correct person to fill contract Oracle positions is a major challenge for businesses. Finding a candidate with the required professional and technical skills to undertake a fixed-term, highly specialized and technical job is almost impossible.
If you are in the process of rolling out systems into new channels (e.g. a mobile presence), migrating toward a cloud-based deployment or integrating with a new partner, you should give consideration to how your systems are integrated. An effective integration infrastructure facilitates business agility, simplifies on premise and in-cloud integration and reduces operating costs.
Streamlining the process of migrating from OWB to ODI.
Background: Many Oracle customers currently use the Oracle Warehouse Builder (OWB) product as part of their data warehouse environment. Oracle noted in an OWB Statement of Direction that the current release of OWB (11.2) is the terminal release of the product and that no future releases are envisages. Furthermore, future database releases beyond Oracle Database 12c Release 1 will not be certified with OWB 11.2. On this basis, OWB customers need to identify a strategy and approach to migrate from OWB.
Background: In my previous blog entry: http://www.metalogic.ie/news/9/46/Best-Practice-Code-Organisation-and-Management-for-Oracle-ADF-Applications/d,ML_V2_News_Detail I described some initial considerations when starting a new Oracle ADF project, particularly in relation to ADF modules structure. Another consideration, when starting new ADF projects is that of building the project. In this blog I would like to explain one possible way to approach the application build process.
Using the Oracle Advanced Analytics Database Option can introduce analytic capability into existing Oracle solutions, delivering significant benefits with minimal time, cost and effort.
Recent trends in business intelligence and analytics has seen a shift in interest
Most Oracle ADF project codebases require reorganisation during their lifetime. Getting the structure correct at project outset can save significant effort and pain in the longer term.
A questions that often arises in enterprise software development environments is one of "how do we track requirements, change requests and software bugs. Additionally, how do we track source code to requirements, change requests and software bugs and track issues to software releases? Finally, how do we track time and effort against issues".
There are a number of questions that commonly arise in relation to Oracle database licensing.