VII. Начальная установка базы данных

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

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

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

В этой главе описываются связи таблиц ИСЗ и даются рекомендации для выбора внешних ключей и правил определения для обеспечения последовательности и полезности..

Зависимости базы данных

На рисунке I дана диаграмма, показывающая зависимости для главных таблиц, представленные прямоугольниками. Сплошная линия, соединяющая таблицы, показывает обязательную зависимость, то есть, данные должны быть сначала введены в подчиненную таблицу. Пунктирная линия отражает дополнительную зависимость. Таблицы программ (pgmtbl), иммунизаций (immtbl) и текстов (testtbl), присутствуют на рисунке, несмотря на то, что не показаны зависимости от них. Эти три таблицы удовлетворяют зависимости в данных контактов. В таблице I описаны таблицы и причины существования всех зависимостей.

Рисунок. 1 &ndash Диаграмма зависимостей для основных таблиц

Таблица I &ndash Описания таблиц и их зависимостей

Таблица	Описание и зависимости
citytbl	Зоны обслуживания пациентов, могутсодержать регион в здравоохранении (cr) или район (cd)
codetbl	Коды с соответствующими им метками
depttbl	Отделения, которые могут существовать в учреждении (df), где обслуживаются пациенты
disttbl	Участки
drugtbl	Лекарства, выписанные пациентам, которые могут быть распределены по названию поставщика (ds) и у которых может быть классификация лекарств (dk) и код элемента "drugclass" (класс лекарств)
factbl	Учреждения обслуживающие или направляющие пациентов, которые живут в данной зоне обслуживания (fc)
fldtbl	Поля, на которые ссылается программа "Ввод данных исследования", и у которых должны быть текстовые метки (fk)
immtbl	Тип иммунизации и связанный с ней план иммунизации
pgmtbl	Связанные с диагнозом программы укрепления здоровья
prvtbl	Медицинские работники "основного" медицинского учреждения (pf), у которых могут быть специализации (ps) и которые принимают или направляют пациентов
regtbl	Регионы в здравоохранении
roletbl	Роли пользователей, которые определяют прикладные программы, вводимые в меню каждого пользователя
spectbl	Специализация медицинского работника
suplrtbl	Поставщики, включая поставщиков лекарств
testtbl	Диагностические процедуры
usrtbl	Пользователи, которые могут войти в ИСЗ и которые должны иметь присвоенную роль (ur) и учреждение (uf)
wardtbl	Отделения в медицинском учреждении (wf), куда госпитализируются пациенты

Роли (roletbl), зоны обслуживания (citytbl), учреждения (factbl), и начальный контролирующий пользователь (usrtbl) должны быть введены в указанной последовательности до того, как пользователям может быть дан доступ к любой программе, работающей с контактами, такой как программа "Госпитализации, выписки и переводы". Хотя в начале таблицы не должны бытьзаполнены, в них должны быть введены учреждения, использующие сервер. Так как ввод не возможен без первоначально определенного пользователя, тов системе всегда существует специальный пользователь с именем "administrator" и паролем "sysadmin". Кроме того,если система клонирована, то существует еще один пользователь с именем "admin". У этих пользователей очень ограниченное меню, которое не может быть изменено. Пароли к этим счетам должен меняться сразу после установки системы..

Выбор внешних ключей

Внешние ключитребуются для многих таблиц базы данных. Эти ключи вводятся в поля форм для идентификации объектов базы данных. Например, в таблице, определяющей учреждение, есть десятизначный "Код учреждения". В общем, рекомендовано использовать код, который официально используется официальными органами здравоохранения, такими как Министерство здравоохранения. Тем не менее, есть и другие соображения:

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

Выбор идентификатора пациента

Необходимо специально рассмотреть внешний ключ, являющийся идентификатором пациента. Для стран, не имеющих "Персонального номера в здравоохранении" (ПНЗ), необходимо выбрать его заменитель. Как только страна разработает систему ПНЗ, база данных должна быть обновлена. Следуйте следующим инструкциям для выбора заменителя ПНЗ. Идентификатор должен быть:

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

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

Правила ввода данных

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

Есть еще одно важно соображение, наложенное ИСЗ, по поводу числовых данных: не разницы между нулем и пустым полем. То есть введенное нулевое значение может быть спутано с отсутствием ввода.

Некоторое число правил должно быть соблюдено при вводе текста.

Избегайте пунктуации, если не ясно, где должны быть вставлены знаки пунктуации. Например, в английском языке в свободном тексте принято ставить точку в конце предложения. Использование точки в имени лица &ndash плохая идея.
Избегайте использования заглавных букв, если это не обусловлено принятым соглашением между пользователями ИСЗ. Например, в английском языке в свободном тексте предложение начинается с заглавной буквы. Хотя в английском и фамилии и имена также начинаются с заглавной буквы, эта практика может привести к тому, что многие запросы не пройдут, так как некоторые элементы могут быть написаны с маленькой буквы, например, "вон" и "де".
Избегайте изменения кодирования клавиатуры. В странах, использующих два алфавита, либо используйте цифры, либо национальный алфавит.
Никогда не используйте два последовательных пробела или дефиса.
Избегайте апострофов и кавычек. В любом случае в большинстве полей для ввода эти символы запрещены.
Вводите текст ясно, но с наименьшим числом слов или букв. Имена медицинских работников, учреждений, зон обслуживания, региона, илирайона должны быть коротки, ясны и уникальны. Короткий текст может легчеформатироваться в формах ввода и отчетах.
Избегайте неясных сокращений, лучше разработайте и используйте список стандартных сокращений, особенно доля больших часто используемых фраз.
Избегайте ввода необязательного текста, когда другие обязательные для ввода поля дают те же данные. Ввод необязательного текста увеличит размер базы данных.

Текст должен просматриваться для выявления и исправления плохой работы и исправления неправильных данных. Например, если имя или описание какого-то кода постоянно переносится или обрывается, то такое название должно быть сокращено.