Проведение исследований является важной частью любого научного изыскания, которое часто сопровождается накоплением большого количества данных, хранящихся на материальных или цифровых носителях. Однако вследствие разнородности поступающей информации конечная форма представления результатов исследования может быть далека от оптимальной, чему способствует оторванность биостатистика от дизайна базы данных, особенно если привлекаются сторонние специалисты.

Вместе с тем, ответственный подход к проведению исследования ещё до его начала снижает вероятность ошибок, упрощает анализ данных и обеспечивает получение качественных и надёжных результатов.

Следование простым принципам, изложенным в настоящей статье, поможет как при формировании базы данных исследования, так и во время проведения статистической обработки.

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

Исходные данные могут быть разнородны по формату, структуре и способу представления содержания, поэтому их непосредственное использование для анализа невозможно. Если изначально данные регистрируются на бумажных носителях, то они переводятся в электронный вид, в ином случае агрегируются в одном месте, модифицируются и лишь затем могут быть сведены в единообразную базу данных (БД) исследования.

Извлечение, трансформация и загрузка консолидированных данных в БД может быть описана в рамках ETL-процесса (extract → transform → load). ETL следует по возможности автоматизировать и строго регламентировать, чтобы обеспечить воспроизводимость операций.

Полученная БД будет использоваться для статистического анализа, поэтому при разработке её дизайна необходимо учитывать формат файла, структуру хранимых данных, типы и диапазоны вводимых значений.

Для представления данных в электронном виде, как правило, используются офисные табличные редакторы, хотя могут применяться и системы управления базами данных. Наиболее распространены следующие форматы:

Файлы CSV («comma separated values»), TSV («tab separated values») и аналогичные форматы с текстовым разделителем — наиболее простой и поэтому практически лишённый как преимуществ, так и недостатков формат. Нет необходимости иметь специальную программу для чтения, может быть отредактирован как в Notepad, так и в MS Word или Libre Office. Возможна путаница при чтении без дополнительных настроек, так как разделителем целой и дробной части числа в русскоязычных странах является запятая, которая также выступает в качестве разделителя для CSV по умолчанию.

Файлы XLS/XLSX, ODF — генерируются соответствующими табличными процессорами. Имеют мощные дополнительные возможности обработки, форматирования и представления данных, позволяют сохранять разные наборы данных в одном файле на так называемых «листах», однако вследствие разнообразия существующего программного обеспечения имеется вероятность того, что пользователи с иным офисным пакетом не смогут получить корректный доступ к указанным дополнительным функциям. Кроме того, вследствие автоматического форматирования (которое в случае MS Excel невозможно отключить), есть возможность некорректной интерпретации вводимых данных, что для русскоязычного сообщества особенно актуально в плане преобразования чисел в даты. Так как в операционной системе Windows для региона «Россия» в качестве десятичного разделителя используется запятая, в ячейке с установленным по умолчанию форматом «Общий» MS Excel превращает значение «10.2» в дату «10. фев». Эта проблема определённым образом касается и англоязычных пользователей, что выливается в весьма курьёзные случаи. Так, в 2020 году Комитет по номенклатуре генов (HGNC) внёс изменения в названия 27 человеческих генов, что было вызвано автоматическим форматированием MS Excel — гены «MARCH1» и «SEPT9», например, преобразовывались в даты «1 марта» и «9 сентября». Поэтому исследователю необходимо проявлять внимательность, предварительно выставляя формат данных, либо используя средства проверки данных.

Кроме того, табличные процессоры могут испытывать определённые трудности при работе с большими файлами, количество наблюдений в которых превышает несколько миллионов. Тем не менее, несмотря на указанные проблемы и на то, что MS Excel распространяется на коммерческой основе, подавляющее большинство результатов сохраняется именно в этом формате.

Файлы баз данных (SQLite, MySQL, MS Access) — имеют наибольшие возможности в плане корректного хранения и представления результатов, однако, как правило, требуют для создания и использования определённой квалификации.

Удобным может быть приобщение к результатам исследования также пояснительной записки, описывающей структуру данных или содержащей иную важную для исследователя информацию, что облегчает возврат к работе спустя некоторое время.

Рассматривая структуру двумерных таблиц, можно выделить два формата, которые используются для представления содержимого: длинный и широкий. Широкий формат использует для хранения переменных отдельные колонки (одна колонка соответствует одной переменной), в то время как длинный формат предполагает выделение для переменных и наблюдений как минимум двух столбцов (например, наименование параметра и его значение), сопровождаемых уникальным идентификатором. Впрочем, в некоторых случаях может быть удобно частичное использование обоих способов (рис. 1).

Наибольшую распространённость имеет широкий формат, который используется для представления данных визитов, когда каждый из показателей регистрируется для одного пациента один раз, в то время как длинный может быть полезен, если неизвестно, сколько раз будет необходимо осуществить ввод. Например, при записи сопутствующей терапии рекомендуется отдать предпочтение длинному формату, так как нельзя ожидать, что все пациенты будут принимать одинаковое количество лекарственных препаратов.

Структурирование данные облегчает их последующую консолидацию (соединение таблиц) и очистку. Под очисткой (англ. tidying), то есть приведением данных к так называемому «опрятному» виду, подразумевается не столько удаление какой-либо информации, сколько преобразование их к некоторому стандартному состоянию.

Определение «опрятным данным» наиболее полно даёт Jeff Leek в работе с одноимённым названием [1]. Так, в наборе (таблице) опрятных данных:

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

Размещение переменных в столбцах, а наблюдений в строках не является обязательным, но, так как количество наблюдений, как правило, превышает количество изучаемых показателей, проще работать с таблицей, растянутой вертикально, а не горизонтально. Кроме того, в табличном редакторе MS Excel существует ограничение на количество столбцов и строк — 16384 и 1048576 соответственно, что в большинстве исследований будет достаточным, однако в некоторых случая способно привести к потере данных [2].

В случае использования нескольких наборов данных или одного набора, разделённого на части (файлы), особое внимание следует уделить идентификаторам — в простейшем случае порядковым номерам, однозначно идентифицирующим субъект исследования. Если исследование выполняется одним исполнителем, то создание идентификаторов с единой логикой не представляется сложным, но результаты, как правило, собираются из нескольких источников, каждый из которых для идентификации может использовать свою систему. При регистрации образцов в лаборатории им присваиваются собственные номера, сквозные в рамках учётного журнала, порядковые за отчётный период и так далее. Следует отметить, что, если исследуемые образцы в рамках одной и той же лаборатории анализируются структурными подразделениями последовательно, в каждом из подразделений могут также применяться разные идентификаторы. Кроме того, некоторые приборы могут пользоваться собственной системой кодирования образцов, основанной на предустановленных принципах и иногда защищённой от изменения во избежание фальсификации и фабрикации данных. При использовании данных от аналогичных структур (например, в случае многоцентровых исследований), идентификаторы клинических баз могут иметь сопоставимую систему кодирования, быть уникальны в пределах собственного центра, но совпадать друг с другом. Хорошей практикой будет фиксация таких промежуточных идентификаторов в отдельном файле, что может помочь в дальнейшем для уточнения данных или в случае проверки надзорными органами. Не требуется упоминать о том, что корректное сопоставление идентификаторов является критически важным при введении результатов в базу данных.

В простейшем случае идентификатором может выступать порядковый номер субъекта исследования, что, как было упомянуто выше, иногда трудно реализуемо или сопряжено со сложностями. Кроме того, иногда удобно кодировать в идентификаторе дополнительную информацию: номер исследовательского центра (идентификатор «2–10» соответствует десятому пациенту, зарегистрированному во второй клинической базе), группу («О-1» или «К-1» могут соответствовать первому пациенту из опытной или контрольной группы соответственно), номер визита пациента к врачу («Д10-2» — визит второго пациента на десятый день исследования), номер истории болезни («C001@0000» — первый пациент контрольной группы, номер истории болезни 0000) и прочее.

При использовании офисных табличных редакторов необходимо избегать некоторых плохих практик организации данных:

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

Вследствие непредсказуемого поведения следует также избегать в заголовках использования пробелов и специальных символов — косой черты, вопросительных и восклицательных знаков, символов процента и амперсанда, двоеточия, скобок и прочих. Для визуального разделения слов в заголовке предпочтительно использовать чередование прописных и строчных букв (так называемый PascalCase или camelCase — «GlucoseBlood» или «glucoseBlood» соответственно), символа нижнего подчеркивания («glucose_blood») или точки («glucose.blood»). Не рекомендуется использовать kebab-case (glucose-blood) и Train-Case (Glucose-Blood), которые как минимум будут преобразованы к точечной нотации или вызовут ошибку.

Кроме предотвращения ошибок, связанных с импортом, именование столбцов при осмысленном подходе поможет значительно облегчить последующую обработку данных. Очевидно, что названия должны кратко, но полно отражать значение показателя: столбцы «g1» и «g2» для исследователя могут означать многое, но быть полностью бессмысленными для коллег (а спустя некоторое время и для самого исследователя). Например, «glucose_1h» и «glucose_2h» ненамного длиннее, но нативно подсказывают, что показатели могут соответствовать уровням глюкозы спустя 1 и 2 часа от какой-то временной точки. Если существуют несколько источников данных или иных группирующих факторов (различные биологические среды, ткани или точки отсчёта) целесообразно использование более сложных названий, например «blood.glucose», «blood.cholesterol» или «blood.albumin». Обратите внимание, что при таком подходе стоит придерживаться иерархичности: первое место занимает наиболее общая или представляющая наибольший интерес характеристика. Так, если объектом исследования является липидный состав липопротеиновых комплексов крови, то есть в каждом из комплексов (высокой, низкой и очень низкой плотности) происходит определение содержания холестерола, фосфатидилхолина, фосфатидилэтаноламина и прочих фосфолипидов, названия показателей могут быть следующие: «HD.CHS», «HD.PCH», «HD.PEA», «LD.CHS», «LD.PCH» и далее. Однако, если объектом исследования является непосредственно содержание холестерола в различных формах, в том числе и общего холестерола, более логично вынести определяемое вещество на первое место: «cholesterol.HD», «cholesterol.LD», «cholesterol.VLD» и «cholesterol.total».

Дубликаты наблюдений (строк). Примитивная ошибка, возникающая при повторном введении данных для субъекта исследования. Без использования идентификаторов выявляется крайне трудно. В случае использования нескольких наборов данных и объединения их по идентификаторам приводит к дублированию строк в итоговой таблице (см. рис. 3).

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

Некорректное представление отсутствующих наблюдений (строк). При исследовании динамики показателя во времени он многократно измеряется через некоторые интервалы. Однако по непредсказуемым причинам не все из испытуемых могут посетить врача-исследователя или некоторые из подопытных животных могут в промежутках между исследованиями погибнуть; в таком случае пропущенными данными становится не один из неудавшихся анализов, а вся строка, отвечающая за это наблюдение. Перед исследователем возникает дилемма: оставить отведённую выбывшему субъекту строку без результатов или же удалить её полностью (см. рис. 4).

Возникшая неоднозначность не является проблемой, но требует отдельного внимания. Если исследователь примет решения не вносить в базу данных пустую строку, соответствующую пропущенному наблюдению, при анализе следует особенно тщательно проверить соответствие идентификаторов наблюдений в различные периоды друг другу — иначе, согласно приведённому на рис. 4 примеру, результатам пациента 2 во второй день будут сопоставлены данные пациента 3, а данные пациента 3, в свою очередь «исчезнут». Как правило, трансформации подобного рода производятся инструментом анализа данных автоматически и широко внедрены, но не будет лишним заранее знать, способно ли ваше программное обеспечение на подобные манипуляции.

Если исследователь введёт в базу данных пустую строку каких-либо дополнительных действий не потребуется, однако в случае большого количества наблюдений (сотни, тысячи и десятки тысяч) навигация по такой базе может быть затруднительной. Универсального совета по разрешению подобных ситуаций не существует, однако следует заметить, что нужно заранее быть готовым к такому развитию событий, когда регистрация отсутствующих наблюдений в виде пустых строк будет невозможна — в случае незапланированных визитов или досрочного завершения исследования вследствие каких-либо причин. Кроме того, умение использовать идентификаторы при соединении данных двух таблиц упростит ситуации, когда одному субъекту соответствует несколько наблюдений — например при учёте данных анамнеза или регистрации нежелательных явлений.

Использование специализированных средств управления базами данных избавляет от ошибок подобного рода, однако, требует дополнительного обучения для начала работы.

Хорошей практикой является выделение в отдельный текстовый файл описания процедуры очистки, чтобы при необходимости спустя некоторое время можно было без особых усилий её повторить или воспроизвести на ином, но имеющем сходную структуру наборе результатов.

Кроме упомянутой выше необходимости приведения базы данных в «опрятный» вид, наиболее распространёнными причинами для очистки данных является небрежность в работе и некорректное или ошибочное применение программного обеспечения, используемого для формирования базы результатов исследования.

Переменные в базе данных могут подвергаться различным проверкам:

Упомянув проблемы, сопряжённые с использованием офисных табличных редакторов, нельзя не отметить, что многие из них содержат функции, предназначенные для валидации данных и предотвращения ошибок ввода. Например, MS Excel позволяет задать проверку данных и ограничить вводимые данные по следующим параметрам:

Кроме того, задаются дополнительные условия: включение или невключение в диапазон, равенство или неравенство указанному значению, что может быть удобно, если результаты методики испытания или сам определяемый параметр имеет некоторый допустимый интервал — например температура тела, удельная плотность мочи или рабочий диапазон прибора.

При попытке же ввода некорректного значения пользователь увидит предупреждение, текст которого также может быть предварительно установлен, и содержать инструкции и пояснения. Существует возможность установки подсказки, отображаемой при наведении на ячейку, в которой могут быть размещены дополнительные сведения, такие как полное название параметра, единицы измерения или расшифровка закодированных значений. При применении функции проверки данных на уже введённых значениях есть возможность графически выделить ячейки, содержание которых проверку не проходит. К сожалению, следует также отметить, что проверка данных в MS Excel работает только при их ручном введении с клавиатуры, в случае вставки из буфера обмена заданные ограничения игнорируются.

Описанный инструмент проверки данных характерен для табличных редакторов, однако, если есть квалифицированные специалисты, то может быть реализован и на других платформах, вплоть до создания отдельных программ (скриптов R, SPSS и пр.), определяющих валидность данных.

Корректная БД обеспечивает удобную обработку (экспорт, тестирование статистических гипотез, представление результатов в форме таблиц и графиков), выполняемую специализированным программным обеспечением. Последовательность действий пользователя в ходе анализа данных, или инструкции анализа данных, могут быть сохранены в различных форматах, зависящих от инструмента, предпочитаемого исследователем (Statistica [3] использует файлы с расширением *.sta, SPSS [4] — *.sav, скрипты R [5] — *.R и так далее). Полученные результаты фиксируются в структурированной форме в виде итогового отчёта, служащего для подготовки научных статей или отчёта о проведении клинического исследования. Написание итогового отчёта является заключительным этапом процедуры анализа данных.

Таким образом общая схема извлечения, трансформации, выгрузки, анализа и интерпретации данных в исследовании может быть представлена следующим образом (рис. 5).

Виртуальное рабочее пространство исследователя представлено следующими компонентами:

После создания итогового отчёта работа исследователя не завершается, так как все полученные данные и созданные документы должны быть помещены в архив и зарезервированы. Более того, хорошей практикой будет постоянное резервное копирование всей информации, касающейся исследования на всём его протяжении.

Рекомендации по целостности данных были сформулированы в 2016 году FDA [6], впоследствии дополнены EMA [7] и описываются 10 принципами, закодированными в акрониме ALCOA++, согласно которым данные должны быть:

Без специализированного программного обеспечения для управления данными принципы ALCOA++ достаточно сложно реализовать, а следование им может принести больше проблем, чем преимуществ. В качестве компромиссного решения можно использовать системы управления версиями — программы, позволяющие фиксировать и отслеживать изменения, происходящие с данными, будь то текстовые документы, электронные таблицы или изображения.

Наиболее распространён в настоящее время Git [8], который имеет открытый исходный код, бесплатен и представлен на различных операционных системах. Git отслеживает заданную директорию в файловой системе персонального компьютера и при редактировании содержащихся в ней документов фиксирует информацию о произошедших изменениях так, чтобы спустя некоторое время была возможность вернутся к сохранённым версиям. Git поддерживает «ветвление» версий, когда, предположим, исследователь кардинальным образом перерабатывает отчёт, сохраняя его параллельно исходному варианту, а не заменяя. Оценив результат, пользователь может объединить ветви, либо же удалить ненужные.

Немаловажно, что изменения на локальном компьютере могут быть синхронизированы с удалённым сервером в Интернет и распространены среди иных авторизованных пользователей. Существует большое количество сервисов, предоставляющих как частные, так и публичные сервера для этих целей, также возможно использование и собственного сервера. Работа посредством Git позволяет получить доступ к свежей версии данных из любой точки мира как непосредственно самому исследователю, так любому из его коллег или статистику. Кроме того, хранение копий в нескольких местах создаёт дополнительную страховку на случай утери документов, что может произойти абсолютно случайным образом и вне зависимости от желания исследователя (поломка компьютера, повреждение данных вредоносными программами, кража устройства).

В завершение хотелось бы привести поговорку: «garbage in, garbage out» (мусор на входе, мусор на выходе), которая подразумевает, что невозможно получить качественный результат при использовании некачественных данных. Применение описанных выше подходов значительно снизит вероятность ошибок и обеспечит быстрый и комфортный анализ.

ДОПОЛНИТЕЛЬНАЯ ИНФОРМАЦИЯ ADDITIONAL INFORMATIONКонфликт интересовАвтор заявляет об отсутствии конфликта интересов. Conflict of interestsThe author declares no conflict of interest.ФинансированиеРабота выполнялась без спонсорской поддержки. FinancingThe work was carried out without sponsorship.