Ответы:
В список chl, который фокусируется на откровенных ошибках обработки данных, я бы добавил проверки на более тонкие ошибки, чтобы решить следующие вопросы и проблемы (приведенные в произвольном порядке и, конечно, неполные):
Предполагая целостность базы данных, являются ли данные разумными? Они примерно соответствуют ожиданиям или обычным моделям, или они удивят кого-то, знакомого с подобными данными?
Являются ли данные внутренне согласованными? Например, если одно поле должно быть суммой двух других, не так ли?
Насколько полны данные? Являются ли они тем, что было указано на этапе планирования сбора данных? Есть ли дополнительные данные, которые не были запланированы? Если так, то почему они там?
Большинство анализов неявно или явно моделируют данные экономным образом и включают возможность отклонения от общего описания. Каждая такая модель предлагает свой особый способ идентификации выбросов - данные, которые значительно отличаются от общего описания. Были ли предприняты попытки определить и понять выбросы на каждом этапе исследования и анализа?
Во многих случаях аналитик может вводить в анализ дополнительные данные для проверки качества и анализа. Например, многие наборы данных в естественных и социальных науках, а также в бизнесе включают (по крайней мере неявно) информацию о местоположении: идентификаторы регионов переписи; названия стран, штатов, округов; почтовые индексы клиента; и так далее. Даже если - возможно, особенно если - пространственная корреляция не является элементом EDA или моделирования, аналитик может объединить данные с географическими представлениями местоположений и сопоставить их для поиска закономерностей и выбросов.
Одной из самых коварных ошибок, которые могут проникнуть в анализ, является потеря данных. При извлечении полей, суммировании данных, переформатировании наборов данных и т. Д., Если один или два элемента отбрасываются из большого набора данных, часто нечего помечать. Но иногда что-то важное теряется, к крайнему смущению, если оно когда-либо обнаруживается. Простые проверки - такие как сравнение до и после подсчета и итоговых данных - должны проводиться регулярно для защиты от таких вещей.
Еще одна коварная ошибка связана с преобразованием типов в цифровых вычислениях. Например, недавно мне пришлось создать ключ (для сопоставления двух файлов данных) из поля с плавающей запятой. Программное обеспечение (Stata) импортировало поле как число с плавающей запятой одинарной точности в одном файле, но по какой-либо причине как число с плавающей запятой двойной точности в другом файле. В большинстве случаев значения совпадают, но в некоторых случаях из-за разного округления они не совпадают. Некоторые данные были потеряны в результате. Я поймал это только из-за применения (6). В общем случае стоит проверить согласованность типов данных поля: целочисленные значения или числа с плавающей запятой, длины строк и т. Д.
Если на каком-либо этапе анализа используется электронная таблица , ожидайте худшего. Проблема в том, что даже случайное нажатие клавиши может незаметно повредить данные. Когда результаты критически важны, стоит продолжать идти вперед и назад - экспортировать в электронную таблицу, выполнять анализ, импортировать обратно и систематически сравнивать - чтобы убедиться, что ничего плохого не произошло.
Всякий раз, когда база данных обновляется, стоит сделать паузу и выполнить систематические, полные сравнения со старой, чтобы убедиться, что в процессе ничего не было потеряно, изменено или повреждено.
На более высоком уровне всякий раз, когда выполняется оценка (например, регрессия, PCA и т. Д.), Может быть целесообразно выполнить ее, используя другой метод, для проверки чувствительности или даже возможных ошибок в коде. Например, следуйте регрессии OLS с помощью некоторой формы надежной регрессии и сравните коэффициенты. Для получения важных результатов может быть удобно получать ответы, используя две (или более) разные программные платформы.
Возможно, лучший вид общей «проверки согласованности», которую может выполнить каждый, - это наметить все, рано и часто.
Я полагаю, что это связано с какой-либо формой контроля качества целостности данных , и, в частности, с тем, что вы регулярно проверяете, не повреждена ли ваша рабочая база данных (из-за ошибки во время передачи, копирования или после обновления или проверки работоспособности). Это также может означать обеспечение двойной проверки ваших промежуточных вычислений (либо вручную, либо с помощью дополнительного кода или макросов в статистическом программном обеспечении).
Другая информация может быть найдена здесь: справочное руководство ICH E6 (R1) о Руководстве по надлежащей клинической практике от EMEA, Руководство по надлежащей клинической лабораторной практике или инструментарий исследователя клинических исследований .
добавить к другим хорошим моментам
При использовании Excel я всегда генерирую номер дела в качестве первого столбца для каждой строки, затем он копируется в последний столбец. Excel, кажется, очень рад отсортировать только несколько столбцов за раз, что приводит к хаосу, если вы не будете осторожны, чтобы выбрать их все. Вы можете даже не знать, что это произошло. Возможность проверить, что номера случаев совпадают в первом и последнем столбцах строки, является полезной предосторожностью.
Я всегда рассматриваю выбросы.
Для критической работы рекомендуется двойной ввод данных отдельными людьми.
При вводе данных из бумажных документов рекомендуется использовать ссылочный идентификатор, чтобы иметь возможность обратиться к точному документу и строке, из которой получена запись, нумерация форм ввода данных помогает в этом.
Редактировать - еще один пункт - я знаю, что редактирование электронных таблиц чревато проблемами, но с ними гораздо проще очистить ввод данных. Тем не менее, я также сохраняю исходную неотредактированную версию, так что любые изменения могут быть проверены или в худшем случае восстановлены.