Download Often times developers will use a simple, single

Survey
yes no Was this document useful for you?
   Thank you for your participation!

* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project

Document related concepts

IMDb wikipedia , lookup

Extensible Storage Engine wikipedia , lookup

SQL wikipedia , lookup

Microsoft SQL Server wikipedia , lookup

Entity–attribute–value model wikipedia , lookup

Ingres (database) wikipedia , lookup

Microsoft Access wikipedia , lookup

Functional Database Model wikipedia , lookup

Concurrency control wikipedia , lookup

Database wikipedia , lookup

Open Database Connectivity wikipedia , lookup

PL/SQL wikipedia , lookup

Relational model wikipedia , lookup

Versant Object Database wikipedia , lookup

Microsoft Jet Database Engine wikipedia , lookup

Clusterpoint wikipedia , lookup

Database model wikipedia , lookup

ContactPoint wikipedia , lookup

Oracle Database wikipedia , lookup

Transcript
Often times developers will use a simple, single-user database, like Microsoft’s Access, to
understand the target system better. However, eventually these databases have to be tested in a
multi-user database environment like Oracle 9i. The following presents the sequence to follow
in order to migrate the schemas (and test data if desired) to the target environment. The example
uses the Belgium Chocolate Company database solution obtained in the FIS Analysis course.
First, launch Oracle’s Migration Workbench (OMW) program. (This can be downloaded from:
http://otn.oracle.com/tech/migration/workbench/content.html along with the database plugins for
Microsoft’s Access and SQL Server ).
Select the default repository, or logon to another repository using standard Oracle login
procedures. You should then see:
Under Action, select Capture source database:
This will launch a the Capture Wizard:
Select Next.
As indicated, run the appropriate msaccess_exporter for your version of Access. Here I will
run the omwb2000.mde from the indicated directory.
Which results in:
Select, or browse to (…) the target MDB file, in this case BCC.mdb, then select OK.
This, interestingly enough, creates an XML document that reflects the schema of the underlying
Access database. Select Exit. Going back to the OMWB, select the XML file created.
Select Next. The next screen (step) permits a mapping from Access datatypes to Oracle
datatypes:
Select Next.
Select Next, to create the Oracle Model.
Select Next after choosing the appropriate Oracle version for your system. The following
summary is provided:
Select Finish. The Source Model is then captured, reporting messages, warnings and errors
along the way. REVIEW THESE MESSAGES!
Select OK.
Select Yes.
Select Next.
Enter appropriate username, password, host, port and SID for your system. I will be
system/####@local.dns using port 1521 and my local host: joelaptop.sba.Oakland.edu.
Select Next.
Select Next.
If you wish to bring along the data, as well as the schema, do so, and select next.
Select the Schema objects for your purposes, and select Next. You should see a Summary:
Select Finish. The actual migration runs, with general messages, warnings, and errors. REVIEW
BEFORE PROCEEDING! For example, see the following dialog box.
You may receive error messages, in which case follow the choices in the dialog box(es).
If you were building a front-end using Access against the migrated Oracle database, then you
would complete this step, after setting up an ODBC connection to the Access database.
Otherwise, you may choose to Cancel, as was done for this example.
Select OK to proceed.
Select OK. It is prudent to generate and view Migration Reports.
One can also generate the scripts used for migration for viewing.
This step is optional but can be insightful into the migration process.
If all has gone well, the schema (and data, if chosen) is (are) available in the targeted Oracle
database. The default user is the name of the migrated database, here BCC, with a default
password of oracle, which should be changed immediately upon migration completion. The
following shows the standard SQL*Plus connection to the migrated database:
The following is the DBA’s view of the migrated database.
The user should verify the data and schema against the original MDB file.