FAQ

DATPROF is a solution which can used either on permise or in the cloud. If you can connect to databases with the JDBC connector you can mask or subset it. Because the data while masking is not extracted from the database into our software, our software has to connect to the databases to do the processing. Your data remains in the database domain(s) and never traverses the network.

You can find the pricing information on https://www.datprof.com/pricing/. After you’ve filled in the form you receive the pricing information in your inbox.

No, it’s not.

With the help of DATPROF Privacy we’re able to mask data and we’re able to synthetically generate test data. We’ve got several built in masking rules in DATPROF Privacy and several synthetic test data generators or seed lists. So you’re able to generate new social security numbers, bank accounts or give new first names based upon for example seed lists. Also it’s possible to generate synthetic data from scratch.

Yes, we can! With the ‘Generate’ module in DATPROF Privacy you can generate synthetic data from scratch.

We support several flat file types, for example Comma Separated Values (CSV), Fixed Length (FL), Recursive Fixed Length (RFL) and Extensible Markup Language (XML).

We support all major database technologies. We have native support for Oracle, Microsoft SQL Server, DB2 iSeries, DB2 LUW, Postgress, EDB, MySQL and MariaDB. If you want more information about the version check our docs.

There are two options, one is you could export the data to a database we do support, execute the masking or subsetting process and then import it back into the database. We’ve done this in several occasions and works out perfectly. The other option is ask us politely what the effort should be to develop your database technology.

Yes you can. With the help of our scheduler inside DATPROF Runtime you’re able to schedule all your runs. You could also use the REST API in DATPROF Runtime to make the test data runs part of your CI/CD pipeline if needed. With our API you’re able to automate nearly everything. For more information about the AP check out our docs.

Yes we do. This has always been one of our major efforts. We want to mask or subset test data over all your different systems. This is a necessity.

We wanted to make sure that you can develop once and deploy multiple times. So every app you develop in DATPROF Privacy or DATPROF Subset, you only develop once. Afterwards you deploy these apps in DATPROF Runtime and you can execute them over and over again.

Data models change over time. So when these changes occur you need to adapt to these changes. With our synchronization wizard you’re able to easily adapt to new data models and within a few clicks your DATPROF app is ready to go.

How do you select a database? Well that’s pretty easy, you’ll need the connection address plus credentials. Then you’ll select the database you want to mask or anonymize. After you selected the database for masking you’ll also need to insert the metadata.

After you have entered the connection credentials you want to import the metadata. The metadata describes the characteristics of the data(base), for example you’ll find information about table names, column names, sizing, data types etc. On import the foreign keys found in the metadata are valuable for DATPROF Privacy and DATPROF Subset.

Sometimes foreign keys are not stored as part of the metadata of the database. So we also are able to import the metadata stored in a table or with a script before we start a masking process. If all these options don’t resolve the need for metadata, we are also able to update the tool with additional relationships. These will only be known within the tool used and are in no way transported into the database itself.

The metadata for helping the data masking process within DATPROF Privacy. The metadata enables you to put masking functions on tables and columns easily.

After the metadata is imported the tool can present the tables and columns to you for developing data masking functions. These functions can be made by selecting any given table and within this table by selecting one or more columns you want to put a particular data masking function on. You are than able to select this masking option by right-mouse-click or clicking the function button. A variety of functions are available enabling you to fulfill all your anonymization needs.

After adding these functions to columns, you can also easily edit these functions. If a function should cover more than one column, you can easily edit the function and add more columns to a function. For example if you want to shuffle first name, it might be interesting to shuffle gender accordingly. Thus keeping the relation between the first name and the recorded gender.

Changes in a database model do appear. So when you create a template with DATPROF Privacy it is important that service and support for these kind of changes are kept to a bare minimum. For this purpose the synchronize metadata button was created. Within the project setting screen of DATPROF privacy, you are able to synchronize the meta data model. It searches for differences between the meta data saved within the template and the meta data as present within the connected database. As an user of DATPROF Privacy you are able to accept or discard these changes.

After finishing the synchronization, the template can be updated and executed. The only thing to keep in mind is, when some new tables or columns are introduced, those might contain privacy sensitive data which should be masked. If that is the case you can create new or edit existing functions as needed.

With DATPROF Privacy there are two ways to start a data masking process, directly from the DATPROF Privacy application. The second way of starting a masking process is by DATPROF Runtime. With DATPROF Runtime any created template of DATPROF Privacy can be scheduled and executed. For example to be able to start the data masking process during the night.

The process can be monitored with the logging within DATPROF Privacy. So if a run failed, you are able to see where the run failed to execute and solve the problem at hand.