Н. 3. Елманова, C++Builder 3.0, архитектура "клиент/сервер" и Internet
растеризующие конкретный экземпляр данной сущности, - дата посещения, цель посещения, статус (первичное или повторное это посещение), диагноз. При проектировании данных желательно создать также уникальный первичный ключ (номер талона). Это более удобно, чем использование комбинации первичных ключей сущностей "Врач" и "Пациент", так как визитов одного и того же пациента к одному и тому же врачу может быть несколько (рис. 4.2).
•k' Logic Woiks ERwin/ERX - JMEDRUS.ER1 • : <Mam Subiect Aiea> / Displaj.1 ]
3» Ffc   ModelMart   Edit   lasks   Client   Server   Option   Window   Help
ГЛп|х
,Jj9jj<J
±j  Logical Model   _^j
±
<^Я
>-+
Посещение:
Номер талона
Номер медкарты (FK)
Табельный номер врача (FK)
Дата визита
Статус
Цель посещения
Диагноз
Пациент
--0
Номер мвдкарты/2
ФИО пациента Дата рождения Адрес пациента Пол пациента Группа инвалидности
-.'                                     •№••>: ...li,;:	=*(-•:'-••••;'    • .'':: р1''.* ••:.;: •,-::";.#||
	Г*  B'2'TJ й • ч • ч i ч|
	
:QRACLE
Рис. 4.2. Первый вариант модели данных - выделяем сущности "врач" и "пациент"
Учитывая возможную повторяемость значений атрибутов, характеризующих диагноз, цель посещения, статус, создадим соответствующие до-_ полнительные сущности, выполняющие роль справочников (вспомним 6 том, что модель данных должна удовлетворять первой нормальной форме).
Далее рассмотрим сущность "врач". Очевидно, в поликлинике может быть несколько врачей, имеющих одну и ту же специальность; поэтому имеет смысл выделить понятие "специальность" в отдельную сущность и связать ее посредством внешнего ключа с сущностью "врач". В результате получим модель данных, похожую на изображенную на рис. 4.3.
64
О проектировании данных
1 Logic Woiks ERmn/ERX - [MEDORA.ER1" : <Main Subject Aiea> / Displayll
——————————————1-1°1х
5$ File   ModelMart    Edit    Tasks   Client    Server    Option   Window   Help	_(Я| х|
'.p^iHl '•! PJ ^firbi ei(frl4:'«Bl E3|        G S| «| S(±|'|Loaical Model    H
'"        "	'"     ]С1Ш(~ВЕШ     '
(inherit Parent
Врач-:
Посещение
Табельный номер
Код специальности (FK)
Ставка
Категория
ФИО
Фото
Номер талона
Код статуса (FK)
Код диагноза (FK)
Код цели посещения (FK)
Номер иедкарты (FK)
ТаВепьный номер врача (FK)
Дата визита
Пациент:::
k в & i
И! Ч. Ч  ;-:
К:
Номер мед карты/2
ФИО пациента Дата рождения Адрес пациента Пол пациента Группа инвалидности
V
Специальность врача Код специапьносги/2
Наименование специальности
Дизгноз№:
jReady
Рис. 4.3. Модель данных после нормализации
Возникает вопрос: а как быть с остальными атрибутами этой сущности? Ведь очевидно, что атрибуты "ставка" и "категория" тоже повторяются. Однако атрибут "категория" - это обычно целое число, и поэтому нет смысла выносить его в отдельный справочник. Что касается атрибута "ставка", ха-эактеризующего продолжительность рабочего времени, то это обычно дроб-м>е число (например, 1.25). В принципе можно было бы вынести его в отдельный справочник, но из соображений разумной достаточности в данном 1римере мы этого делать не будем (нормализуя модель, можно дойти до гакого состояния, когда выполнение запросов к таблицам окажется весьма уштельным из-за их большого числа).
ТепёрУьГрассмотрим сущность "пациент". Исходя из требования атомар--юсти атрибутов, следует обдумать, является ли таковым адрес пациента. Этметим, что ответ на этот вопрос неоднозначен. Если, например, речь
65