Описание физической модели данных

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

К вопросам организации данных относятся:

· выбор типа записи – единицы обмена в операциях ввода-вывода;

· выбор способа размещения записей в файле и, возможно, метода оптимизации размещения;

· выбор способа адресации и метода доступа к записям.

Стадия физического проектирования БД в общем случае включает:

· выбор способа организации БД;

· разработку спецификации внутренней схемы;

· описание отображения концептуальной схемы во внутреннюю.

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

· выбор схемы размещения данных (разделение по файлам или тип RAID-массива);

· определение числа и типа индексов.

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

Физическая модель данных, как правило, создается на основе даталогической, поэтому каждому объекту логической модели соответствует объект физической модели (хотя соответствие может быть неоднозначным). В физической модели данных сущности даталогической модели данных соответствует таблица, экземпляру сущности – строка в таблице, а атрибуту – колонка таблицы. Кроме перечисленных выше объектов, физическая модель может содержать объекты, тип которых зависит от СУБД: индексы, представления, последовательности, триггеры, процедуры и т.п. Если в даталогической модели данных не имеет большого значения, какой конкретно тип данных у атрибута, то в физической важно описать всю информацию о конкретных объектах.

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

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

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

· удовлетворение требования ссылочной целостности (referential integrity, RI), т.е. в случае принятия решения о поддержки ссылочной целостности встроенными средствами СУБД должны быть наложены ограничения ссылочной целостности на таблицы, исходя из бизнес-правил ссылочной целостности предметной области;

· удовлетворение (частично) требования независимости представления данных для конечного пользователя от характера физического хранения данных.

На первом этапе в рамках требований реляционной модели создаются объекты хранения данных, соответствующие сущностям и взаимосвязям логической модели данных - таблицы, индексы, представления и т.д.

Рисунок 2.3 – Физическая модель

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

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

Заключение

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

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