Разработка базы данных поликлиники
Дипломная работа - Компьютеры, программирование
Другие дипломы по предмету Компьютеры, программирование
щности и атрибуты, ключевые атрибуты в модели представлены в сущности, над чертой. Внешние ключи (мигрирующие атрибуты из родительской сущности) обозначаются как (FK - ForeignKey) [2].Логический уровень означает прямое отображение фактов из реальной жизни. Они именуются на естественном языке, с любыми разделителями слов (пробелы, запятые и т.д.). На логическом уровне не рассматривается использование конкретной СУБД, не определяются типы данных (например, целое или вещественное число) и не определяются индексы для таблиц[2].
Суррогатный ключ - это дополнительное служебное поле, добавленное к уже имеющимся информационным полям таблицы, единственное предназначение которого - служить первичным ключом [4].
Главное достоинство суррогатного ключа состоит в том, что он никогда не изменяется, поскольку не является информативным полем таблицы (не несёт никакой информации об описываемом записью объекте) [4].
При использовании суррогатных ключей не следует озадачивать пользователя вводом значений, которые не несут для него никакой информации. Они генерируются автоматически независимо от пользователя [1].
Введем суррогатные ключи для сущностей Пациент, Сотрудники, Диагноз и Анализ, кроме того, атрибуты Ф.И.О. пациента и Ф.И.О. врача разделим на три атрибута (фамилия, имя, отчество) каждый и сгруппируем их в составные альтернативные ключи. Так же альтернативными ключами сделаем атрибуты название поставщика и название игры. Альтернативные ключи (AK - AlternativeKey) служат для ускорения поиска по базе данных.
врач реляционный амбулаторный программный
3.5 Физический уровень модели данных
Модель данных на физическом уровне отличается от модели данных на логическом уровне тем, что она полностью ориентирована на выбранную СУБД, т.е. в отличие от логической модели, в которой не имеет значения, какой конкретно тип данных имеет атрибут, в физической модели данных важно описать информацию о конкретных физических объектах - таблицах, полях, индексах, процедурах и т.д. [2]. Для СУБД PostgreSQL характерно то, что все объекты базы данных, должны иметь англоязычное наименование.
В ходе проектирования физического уровня была получена модель, представленная на рисунке 3.1.
Рисунок 3.1 - Модель данных на физическом уровне
3.6 Проектирование представлений, последовательностей, триггеров, хранимых процедур
3.6.1 Последовательности
При использовании суррогатных ключей не следует озадачивать пользователя вводом значений, которые не несут для него никакой информации. Эти поля в среде СУБД PostgreSQL заполняются автоматически с помощью, так называемых последовательностей (Sequences).
Список последовательностей:_accounts - последовательность для суррогатного ключа таблицы Accounts_vendor - последовательность для суррогатного ключа таблицы Vendor_reteil - последовательность для суррогатного ключа таблицы Reteil_consignment - последовательность для суррогатного ключа таблицы Consignment
3.6.2 Триггеры
Триггер - это хранимая процедура особого типа, которую пользователь не вызывает непосредственно, а исполнение которой обусловлено наступлением определенного события (действием) - по сути добавлением INSERT или удалением DELETE строки в заданной таблице, или модификации UPDATE данных в определенном столбце заданной таблицы реляционной базы данных. Триггеры применяются для обеспечения целостности данных и реализации сложной бизнес-логики. Триггер запускается сервером автоматически при попытке изменения данных в таблице, с которой он связан. Все производимые им модификации данных рассматриваются как выполняемые в транзакции, в которой выполнено действие, вызвавшее срабатывание триггера [4].
В среде PostgreSQL код триггера содержит только событие для срабатывания и вызов триггерной функции, в которой содержится вся логика триггера.
Разработанные триггеры представлены в таблице 3.3.
Таблица 3.3. Описание разработанных триггеров
Название триггераСоответствующая триггерная функцияСобытие для срабатывания триггераОписаниеconsigment_datе_checkcons_datеДо вставки или до измененияТриггер для таблицы Сonsigment.goods_date_checkgoods_datecheckДо вставки или до измененияТриггер для таблицы Goods.reteil_date_checkret_date_checkДо вставки или до измененияТриггер для таблицы Reteil.goods_update_from_consiggoods_worksПосле вставкиТриггер для таблицы Goods.reteil_dateSendingdateSendingПосле вставкиТриггер для таблицы Reteil.reteil_update_countreteil_worksДо вставкиТриггер для таблицы Reteil.user_summ_discountuser_sum_discountПосле вставкиТриггер для таблицы Reteil.
3.6.3 Представления
В отличие от обычных таблиц реляционной БД, представление не является самостоятельной частью набора данных, хранящегося в базе. Содержимое представления динамически вычисляется на основании данных, находящихся в реальных таблицах. Изменение данных в реальной таблице БД немедленно отражается в содержимом всех представлений, построенных на основании этой таблицы.
Разработанные представления описаны в таблице 3.4.
Таблица 3.4. Описание разработанных представлений
НазваниеОписание задачиВыходные параметрыВывод врачей, которые находятся на больничномName, count_at_storehouse date_of_last_reteil (
4. Результат разработки
.1 Реализация функций ПО
Большинство функций приложения построено на объектной модели. В данной модели можно выделить несколько уровней:
уровень данных
уровень бизнес-логики
уровень приложения
Для проектируемого ПО выбрана арх