Фон
Я наблюдаю за вводом данных из первичной литературы в базу данных . Процесс ввода данных подвержен ошибкам, особенно потому, что пользователи должны интерпретировать экспериментальный дизайн, извлекать данные из графиков и таблиц и преобразовывать результаты в стандартизированные единицы.
Данные вводятся в базу данных MySQL через веб-интерфейс. Более 10 000 точек данных из> 20 переменных,> 100 видов и> 500 цитат были включены до сих пор. Мне нужно проверить качество не только переменных данных, но и данных, содержащихся в таблицах поиска, таких как виды, связанные с каждой точкой данных, место проведения исследования и т. Д.
Ввод данных продолжается, поэтому QA / QC необходимо будет выполнять периодически. Данные еще не были обнародованы, но мы планируем выпустить их в ближайшие несколько месяцев.
В настоящее время мой QA / QC включает в себя три этапа:
- второй пользователь проверяет каждую точку данных.
- визуально проверять гистограмму каждой переменной на наличие выбросов.
- пользователи сообщают о сомнительных данных после получения ложных результатов.
Вопросов
- Существуют ли рекомендации, которые я могу использовать для разработки надежной процедуры QA / QC для этой базы данных?
- Первый шаг самый трудоемкий; Есть ли что-нибудь, что я могу сделать, чтобы сделать это более эффективным?
источник
Ответы:
Этот ответ фокусируется на втором вопросе, но в процессе будет получен частичный ответ на первый вопрос (руководящие принципы для процедуры ОК / КК).
Безусловно, лучшее, что вы можете сделать, это проверить качество данных во время попытки ввода. Пользовательские проверки и отчеты являются трудоемкими и поэтому должны быть зарезервированы для дальнейшего процесса, насколько это практически возможно.
Вот некоторые принципы, руководящие указания и предложения, основанные на обширном опыте (с проектированием и созданием многих баз данных, сопоставимых с вашей базой данных и значительно превышающих ее). Они не правила; вам не нужно следовать им, чтобы быть успешным и эффективным; но все они здесь по уважительным причинам, и вам следует подумать об отклонении от них.
Отдельный ввод данных от всех интеллектуально требовательных действий . Не просите операторов ввода данных одновременно что-либо проверять, что-либо подсчитывать и т. Д. Ограничьте их работу созданием машиночитаемого факсимиле данных, не более того. В частности, этот принцип подразумевает, что формы ввода данных должны отражать формат, в котором вы изначально получали данные, а не формат, в котором вы планируете хранить данные. Позднее преобразование одного формата в другой сравнительно легко, но это подверженный ошибкам процесс, который пытается преобразовать на лету при вводе данных.
Создайте журнал аудита данных : всякий раз, когда с данными что-то делается, начиная с этапа ввода данных, документируйте это и записывайте процедуру таким образом, чтобы можно было легко вернуться и проверить, что пошло не так (потому что что-то пойдет не так). Рассмотрите возможность заполнения полей для отметок времени, идентификаторов операторов ввода данных, идентификаторов источников для исходных данных (таких как отчеты и номера их страниц) и т. Д. Хранение обходится дешево, но время для обнаружения ошибки стоит дорого.
Автоматизировать все. Предположим, что любой шаг должен быть переделан (в самое неподходящее время, согласно закону Мерфи), и планируйте соответственно. Не пытайтесь сэкономить время, выполнив несколько «простых шагов» вручную.
В частности, создайте поддержку для ввода данных : создайте внешний интерфейс для каждой таблицы (даже электронная таблица может сработать), который обеспечивает ясный, простой и унифицированный способ ввода данных. В то же время внешний интерфейс должен обеспечивать ваш бизнес rules: «то есть он должен выполнять столько простых проверок достоверности, сколько может. (Например, pH должен быть между 0 и 14; число должно быть положительным.) В идеале, используйте СУБД для обеспечения проверки реляционной целостности (например, каждый вид, связанный с измерением, действительно существует в базе данных).
Постоянно пересчитывайте вещи и проверяйте, что точно подсчитано . Например, если предполагается, что исследование измеряет признаки 10 видов, убедитесь (как только будет завершен ввод данных), что 10 видов действительно представлены. Хотя проверка подсчетов проста и неинформативна, она отлично подходит для обнаружения дублированных и пропущенных данных.
Если данные являются ценными и важными, рассмотрите возможность самостоятельного двойного ввода всего набора данных . Это означает, что каждый элемент будет вводиться в разное время двумя разными не взаимодействующими людьми. Это отличный способ поймать опечатки, пропущенные данные и так далее. Перекрестная проверка может быть полностью автоматизирована. Это быстрее, лучше при обнаружении ошибок и более эффективно, чем 100% ручная двойная проверка. (Запись данных «люди» может включать такие устройства, как сканеры с OCR.)
Используйте СУБД для хранения и управления данными. Электронные таблицы отлично подходят для поддержки ввода данных, но выведите свои данные из электронных таблиц или текстовых файлов и в реальную базу данных как можно скорее. Это предотвращает все виды коварных ошибок, одновременно добавляя поддержку автоматических проверок целостности данных. Если вам необходимо, используйте свое статистическое программное обеспечение для хранения данных и управления ими, но серьезно подумайте об использовании выделенной СУБД: она будет работать лучше.
После того, как все данные введены и автоматически проверены, нарисуйте картинки : создайте отсортированные таблицы, гистограммы, диаграммы рассеяния и т. Д. И просмотрите их все. Они легко автоматизируются с помощью любого полноценного статистического пакета.
Не просите людей выполнять повторяющиеся задачи, которые может выполнять компьютер . Компьютер гораздо быстрее и надежнее в этом. Привыкайте писать (и документировать) маленькие сценарии и небольшие программы, чтобы выполнить любую задачу, которая не может быть выполнена немедленно. Они станут частью вашего контрольного журнала и позволят легко переделать работу. Используйте любую платформу, которая вам удобна и подходит для этой задачи. (В течение многих лет, в зависимости от того, что было доступно, я использовал широкий спектр таких платформ, и все они были эффективны по-своему, начиная от программ на C и Fortran и заканчивая скриптами AWK и SED, скриптами VBA для Excel и Word и пользовательскими программы, написанные для систем реляционных баз данных, ГИС и платформ статистического анализа, таких как R и Stata.)
Если вы будете следовать большинству этих рекомендаций, примерно 50% -80% работы по вводу данных в базу данных будет составлением базы данных и написанием вспомогательных сценариев. Весьма необычно получить 90% за счет такого проекта и быть выполненным менее чем на 50%, но все же завершить в срок: после того, как все настроено и протестировано, ввод данных и проверка могут быть удивительно эффективными.
источник
DataOne предоставляет полезный набор рекомендаций по управлению данными, которые можно фильтровать по тегам. Лучшие практики, помеченные как «качество», можно найти по адресу http://www.dataone.org/best-practices/quality , повторяя и расширяя многие замечания, высказанные @whuber. Вот список затронутых тем (в алфавитном порядке):
источник