Відповіді:
До списку chl, який зосереджується на відвертих помилках обробки даних, я б додав перевірки на тонкі помилки, щоб вирішити наступні питання (задані не в певному порядку та, звичайно, неповні):
Якщо припустити цілісність бази даних, чи дані обґрунтовані? Вони приблизно відповідають очікуванням або звичайним моделям, чи здивують когось, знайомого з подібними даними?
Чи дані є внутрішніми? Наприклад, якщо одне поле повинно бути сумою двох інших, це?
Наскільки повні дані? Чи є вони визначеними на етапі планування збору даних? Чи є додаткові дані, які не були заплановані? Якщо так, то чому вони там?
Більшість аналізів неявно або явно моделює дані в парсимонічний спосіб і включає можливість відхилення від загального опису. Кожна така модель пропонує свій особливий спосіб ідентифікації людей, що випадають, - дані, які значно відрізняються від загального опису. Чи були спроби виявити та зрозуміти людей, що переживають люди, на кожному етапі розвідки та аналізу?
У багатьох випадках аналітику можливо ввести додаткові дані в аналіз для перевірки якості та огляду. Наприклад, багато наборів даних у природничих та соціальних науках, а також у бізнесі включають (принаймні неявно) інформацію про місцезнаходження: ідентифікатори регіонів перепису; назви країн, штатів, графств; поштові індекси клієнтів; і так далі. Навіть якщо - можливо, особливо, якщо просторова кореляція не є елементом ЕДР чи моделювання, аналітик може приєднати дані до географічних уявлень місць та відобразити їх для пошуку шаблонів та переживань.
Однією з найбільш підступних помилок, яка може врізатися в аналіз, є втрата даних. Під час вилучення полів, узагальнення даних, переформатування наборів даних тощо, якщо один або два пункти випаде з великого набору даних, часто нічого не буде позначено. Але час від часу щось важливе втрачається, якщо хтось коли-небудь виявиться, вкрай збентежений. Прості перевірки - такі як порівняння до і після підрахунків і підсумків даних - повинні регулярно проводитись для захисту від таких речей.
Ще одна підступна помилка пов’язана з перетворенням типів у цифрових обчисленнях. Наприклад, нещодавно мені довелося побудувати ключ (для відповідності двох файлів даних) з поля з плаваючою точкою. Програмне забезпечення (Stata) імпортувало поле в якості одного поплавця точності в одному файлі, але, з будь-якої причини, як плавець з подвійною точністю в інший файл. Більшу частину часу значення відповідали, але, в деяких випадках, через різні округлення, вони не виконували. Деякі дані були втрачені в результаті. Я зловив це лише завдяки застосуванню (6). Загалом, платити потрібно перевіряти на відповідність типів даних поля: ints vs floats, довжина рядків тощо.
Якщо електронну таблицю коли-небудь використовуватимуть на будь-якому етапі аналізу, очікуйте гіршого. Проблема полягає в тому, що навіть бродяче натискання клавіш може непомітно пошкодити дані. Коли результати є критичними, варто продовжувати рух назад і назад - експортуйте в електронну таблицю, робіть аналіз, імпортуйте назад і систематично порівнюйте - щоб переконатися, що нічого не відбулося.
Щоразу, коли база даних оновлюється, варто робити паузу та проводити систематичні, повні зіставлення зі старою, щоб переконатися, що в процесі нічого не було втрачено, змінено чи пошкоджено.
На більш високому рівні, коли виконується оцінка (наприклад, регресія, PCA, будь-яка інша), це може бути доцільно виконувати за допомогою іншої методики для перевірки чутливості або навіть можливих помилок у коді. Наприклад, дотримуйтесь регресію OLS за допомогою якоїсь форми стійкої регресії та порівняйте коефіцієнти. Для важливих результатів може бути приємно отримати відповіді за допомогою двох (або більше) різних програмних платформ.
Мабуть, найкращий вид загальної "перевірки узгодженості", який кожен може виконати, - це графікувати все, рано і часто.
Я припускаю, що це пов'язане з якоюсь формою контролю якості щодо цілісності даних , а точніше, що ви регулярно перевіряєте, чи не працює ваша робоча база даних (через помилку під час передачі, копіювання або після оновлення чи перевірки правильності). Це також може означати, що ваше проміжне обчислення буде двічі перевірено (або вручну, або за допомогою додаткового коду чи макросів у вашому статистичному програмному забезпеченні).
Тут можна знайти іншу інформацію: довідник ICH E6 (R1) про Керівництво з належної клінічної практики від EMEA, Настанови щодо належної клінічної лабораторної практики чи інструментарій дослідників клінічних досліджень .
додати до інших хороших балів
Під час використання Excel я завжди генерую номер справи як перший стовпець для кожного рядка, після чого він копіюється в останній стовпчик. Excel, здається, дуже радий сортувати лише кілька стовпців одночасно, викликаючи хаос, якщо ви не обережно вибираєте їх усі. Можливо, ви навіть не знаєте, що це сталося. Можливість перевірити, чи збігаються номери регістрів у першому та останньому стовпцях рядка, є корисною обережністю.
Я завжди переглядаю людей, що вижили.
Подвійне введення даних окремими людьми рекомендується для критичної роботи.
Вводячи дані з паперових документів, корисно використовувати довідковий ідентифікатор, щоб мати змогу повернутись до точного документа та рядка, з якого отримано введення, нумерація форм введення даних.
Редагування - Ще один пункт - Я знаю, що редагування електронних таблиць загрожує проблемами, але очистити введення даних за допомогою них набагато простіше. Однак я також зберігаю оригінальну нередаговану версію, щоб будь-які зміни можна було перевірити або відновити в гіршому випадку.