Why on earth, if you have a large database, would you want a small version of it? Well, the simple answer is that by giving small subset copies of large production databases to your developers, testers and training teams you will save a lot of money. In addition, you will be providing better facilities. To put it bluntly, developers, testers and trainers do not want to work on full size databases - it just slows things down. All they really want is a smaller version of the large system which they do not have to share with anyone else.
How hard can it be to take a full sized database and make a smaller version of it? It is surprisingly hard actually. There are a considerable number of complications. It is not possible to just take 10% of each table to get a 10% size database. The data in one table would not be related to the data in the other tables. It would not be referentially correct.
A tour into PL/SQL hell is the usual term for the process of manually creating a database subset. For example, if you took 10% of the INVOICE table at random you cannot just take 10% of the CUSTOMER table - the customers would not match the invoices. The rows extracted for the INVOICE table have to be used to find the appropriate rows in the CUSTOMER table. But customers will need addresses from the ADDRESS table and addresses need postcodes from the POSTCODE table & etc. Manually extracting data quickly becomes a tiresome and time consuming procedure - even for simple schemas.
DataBee solves the problem - it has been designed specifically to create referentially correct subsets of large production Oracle databases. DataBee can take an initial set of rows and find each row in the other database tables required to support those rows. It will extract the rows from the source database and it will load them into the destination schema in a fully automatic and hands free manner.