Возникла такая ситуация. Есть крупная финансовая корпорация. В какой-то момент её руководители поняли, что их IT отдел не вполне справляется с поставленными задачами и решили выносить IT на outsourcing. Есть маленькая проблема – у корпорации есть база данных, на которой построены все приложения и сервисы, но эта база содержит ценную секретную информацию. Показывать эти данные сторонней компании очень рискованно. С другой стороны, проекты очень сложные и их практически невозможно реализовать, имея абсолютно «случайные данные». Другими словами, для реализации некоторых вещей для финансового моделирования, нужны данные, похожие на реальные. При этом этих данных должно быть много и сгенерировать их руками тоже не возможно.

Короче говоря, задача такая. Нужно как-то трансформировать данные из реальной базы данных в новую базу. При этом новые данные должны быть пригодными для разработки и тестирования софта. Но по этим данным должно быть невозможным получить какую-нибудь реальную осмысленную информацию. Как это сделать?

Я понимаю, что универсального подхода быть не может. Например, если база не находится в третьей нормальной форме, то не зная «логики» такую трансформацию сделать просто невозможно. Тем не менее, должны же быть какие-нибудь идеи, научные исследования, статьи?

Здравствуйте, De-Bill, Вы писали:

DB>Короче говоря, задача такая. Нужно как-то трансформировать данные из реальной базы данных в новую базу. При этом новые данные должны быть пригодными для разработки и тестирования софта. Но по этим данным должно быть невозможным получить какую-нибудь реальную осмысленную информацию. Как это сделать?

Может не совсем правильно понимаю, но имхо контекстной замены по строкам должно хватить..

По крайней мере все товары, имена, явки, пароли изменятся. CoolCompany -> VPupkin Inc., etc.

Что еще может быть. Числовые значения — тут надо знать ограничения накладываемые на них. В каждой таблице они могут быть свои естественно. Поэтому тут лучше смотреть по обстоятельствам. То же самое с датами.

А если еще там какие-то узкоспецифичные секретные BLOB-ы хранятся — то тут только руками с последующей проверкой имхо.

Не думаю, что возможна полная автоматизация процесса.

Здравствуйте, De-Bill, Вы писали:

DB>Короче говоря, задача такая. Нужно как-то трансформировать данные из реальной базы данных в новую базу. При этом новые данные должны быть пригодными для разработки и тестирования софта. Но по этим данным должно быть невозможным получить какую-нибудь реальную осмысленную информацию. Как это сделать?

DB>Я понимаю, что универсального подхода быть не может. Например, если база не находится в третьей нормальной форме, то не зная «логики» такую трансформацию сделать просто невозможно. Тем не менее, должны же быть какие-нибудь идеи, научные исследования, статьи?

К сожалению, без понимания специфики данных, хранящихся в СУБД, подобную операцию не произвести. Например, мы меняем в табличке Contragent все имена с реальных на Contragent001, Contragent002, ...
Но при этом в поле Comment в табличке Document есть строчка "Платеж Васе Пупкину за поставку грибов." И необходимо знать про это поле, и как-то реализовывать замену. Те же проблемы могут возникнуть с номерами счетов, договоров, кредитных карт, и так далее. Кроме того, необходимо понимать, какие еще дополнительные данные могут помочь косвенно идентифицировать секретную информацию (кстати, придется сначала определить, что именно хотите скрыть). Например, если известно, что фирма "Ромашка+" закупает только бананы определнного сорта, и больше никто их не покупает, и видна накладная с таким товаром, то косвенно опять-таки может произойти идентификация. Так что нужно менять описание товаров, их цены, и т.д. Так что решение подобной задачи требует существования ИИ

Здравствуйте, De-Bill, Вы писали:

DB>Возникла такая ситуация. Есть крупная финансовая корпорация. В какой-то момент её руководители поняли, что их IT отдел не вполне справляется с поставленными задачами и решили выносить IT на outsourcing. Есть маленькая проблема – у корпорации есть база данных, на которой построены все приложения и сервисы, но эта база содержит ценную секретную информацию. Показывать эти данные сторонней компании очень рискованно. С другой стороны, проекты очень сложные и их практически невозможно реализовать, имея абсолютно «случайные данные». Другими словами, для реализации некоторых вещей для финансового моделирования, нужны данные, похожие на реальные. При этом этих данных должно быть много и сгенерировать их руками тоже не возможно.

DB>Короче говоря, задача такая. Нужно как-то трансформировать данные из реальной базы данных в новую базу. При этом новые данные должны быть пригодными для разработки и тестирования софта. Но по этим данным должно быть невозможным получить какую-нибудь реальную осмысленную информацию. Как это сделать?

Сорри за офтоп.

Похоже вам придется разогнать один IT отдел и создать другой IT отдел, который будет заниматься шифрованием данных
А стоит ли овчинка выделки? Может просто оптимизировать работу IT отдела?

Здравствуйте, De-Bill, Вы писали:

DB>Короче говоря, задача такая. Нужно как-то трансформировать данные из реальной базы данных в новую базу. При этом новые данные должны быть пригодными для разработки и тестирования софта. Но по этим данным должно быть невозможным получить какую-нибудь реальную осмысленную информацию. Как это сделать?
Например для MSSQL сейчас MS выпускает Visual Studio for Database Professionals, которая помимо всего прочего умеет генерить левые данные для тестирования, на основе готового набора, соблюдая распределение, селективность, ect...

Здравствуйте, Mirrorer, Вы писали:

M>Здравствуйте, De-Bill, Вы писали:

DB>>Короче говоря, задача такая. Нужно как-то трансформировать данные из реальной базы данных в новую базу. При этом новые данные должны быть пригодными для разработки и тестирования софта. Но по этим данным должно быть невозможным получить какую-нибудь реальную осмысленную информацию. Как это сделать?

M>Может не совсем правильно понимаю, но имхо контекстной замены по строкам должно хватить..

M>По крайней мере все товары, имена, явки, пароли изменятся. CoolCompany -> VPupkin Inc., etc.

M>Что еще может быть. Числовые значения — тут надо знать ограничения накладываемые на них. В каждой таблице они могут быть свои естественно. Поэтому тут лучше смотреть по обстоятельствам. То же самое с датами.

M>А если еще там какие-то узкоспецифичные секретные BLOB-ы хранятся — то тут только руками с последующей проверкой имхо.

M>Не думаю, что возможна полная автоматизация процесса.
Можно изменять данные. Но это данные уже не будут стветствовать реальности.
Имхо выход один: ручками переделывать.