* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Download Often times developers will use a simple, single
Survey
Document related concepts
Extensible Storage Engine 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
Open Database Connectivity wikipedia , lookup
Relational model wikipedia , lookup
Versant Object Database wikipedia , lookup
Microsoft Jet Database Engine wikipedia , lookup
Clusterpoint wikipedia , lookup
Database model 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.