2020-01-14
133
Таблица имеет нормальную форму область/ключ (НФОК), если любое ограничительное условие в таблице является следствием определений областей и ключей. Однако не был дан общий метод приведения таблицы к НФОК.
В качестве примера, рассмотрим структуру реляционной базы данных, описывающей "отношения" пациентов и докторов в произвольной клинике (область приложения примера выбрана из-за того, что в сертификационных тестах Oracle аналогичные примеры встречаются очень часто). Пусть существует некая клиника, основные характеристики которой описываются в таблице CLINICS, в данной клинике работают доктора, основные характеристики которых описывает таблица DOCTORS. Данные пациентов клиники хранятся в таблице PATIENTS. Взаимосвязи между таблицами представлены на рис.10. (Для упрощения предполагается, что у доктора может быть несколько пациентов, которые не являются пациентами других докторов, для реализации реальной картины, когда один пациент может относиться к нескольким разным докторам, между таблицами DOCTORS и PATIENTS необходимо включить дополнительную связывающую таблицу).
Рис. 2. Диаграмма, иллюстрирующая отношения таблиц АИС.
| № | Наименование столбца | Описание |
| Таблица CLINICS | ||
| 1 | CS_NNN | Индекс |
| 2 | CS_REG_NUMBER | Регистрационный номер |
| 3 | CS_CITY_NNN | Ссылка на справочник городов и регионов |
| 4 | CS_NAME | Наименование клиники |
| 5 | CS_ADDRESS | Адрес клиники |
| 6 | CS_PHONE_NUMBER | Номер телефона |
| 7 | CS_TYPE | Профиль клиники |
| Таблица DOCTORS | ||
| 1 | DC_NNN | Индекс |
| 2 | DC_NAME | Ф.И.О. доктора |
| 3 | DC_CS_NNN | Ссылка на таблицу CLINICS |
| 4 | DC_DIPLOM_NUMBER | Номер диплома |
| 5 | DC_SPECIALTY_NNN | Ссылка на справочник специальностей |
| 6 | DC_SHTAT_NNN | Ссылка на штатное расписание |
| 7 | DC_CALENDAR_NNN | Ссылка на расписание приема |
| Таблица PATIENTS | ||
| 1 | PT_NNN | Индекс |
| 2 | PT_REG_NUMBER | Регистрационный номер |
| 3 | PT_NAME | Ф.И.О. пациента |
| 4 | PT_ADDRESS | Адрес пациента |
| 5 | PT_POLIS_NUMBER | Номер полиса |
| 6 | PT_PHONE_NUMBER | Номер телефона |
| 7 | PT_BIRTHDATE | Дата рождения |
| 8 | PT_FIRST_VISIT | Дата первого визита |
| 9 | PT_LAST_VISIT | Дата последнего визита |
| 10 | PL_PT_NNN | Ссылка на таблицу платежей |
| Таблица PAYMENTS | ||
| PL_NNN | Индекс | |
| PL_ACCOUNT_NUMBER | Номер расчетного счета | |
| PL_PAY_NNN | Ссылка на таблицу расчетов | |
Представленная структура, конечно, не обладает функциональной полнотой с точки зрения проектирования АИС клиники, с ее помощью мы лишь рассмотрим различные типы отношений в реляционных СУБД.
Перед тем, как перейти к рассмотрению вопросов стандартизации и целостности данных в РСУБД несколько рекомендаций по выбору наименований таблиц и полей. Внимательно взглянув на описание таблиц можно заметить, что генерация наименований таблиц и столбцов подчиняется некоторой синтаксической конструкции, которая в общем виде может быть представлена следующим образом:
Для таблиц:
<Псевдоним АИС>_<Псевдоним модуля АИС>_:_<Псевдоним подмодуля>_<Имя таблицы>
Например, если бы мы разрабатывали АИС клиники c сокращенным названием CSL, то все таблицы входящие в данную систему было бы целесообразно называть
CSL_<имя модуля>_<имя таблицы>.
Для столбцов:
<Псевдоним таблицы>_<имя столбца>.
Например, как показано на рис.2. Регистрационный номер пациента храниться в поле PT_REG_NUMBER, таблицы PATIENTS, имеющий псевдоним PT.
Конечно, использование этих не хитрых правил не является обязательным, но позволяет значительно облегчить читаемость разработанной информационной структуру. Предположите, как было бы все, если бы поля таблиц назывались P111, P112 и т.п., а ведь такие вещи встречаются практически очень часто, например в FoxPro 2.6.
Перейдем к рассмотрению вопросов стандартизации и обеспечения ссылочной целостности реляционных таблиц.
