Модель хранения данных
Модели данных служат для проектирования структуры постоянных хранилищ данных, используемых системой. Они бывают двух типов:
Логическая и
Физическая.
Более подробно модели данных изучаются в рамках дисциплины «Базы данных». Здесь они будут рассмотрены кратко, в объеме, необходимом для проектирования программной системы.
В логической модели данных отображаются ключевые сущности и взаимосвязи, относящиеся к важнейшей информации, которую приложению необходимо хранить в базе данных. Она связана с моделью классов, которые используются при проектировании программы. Логическая модель отражает ключевые логические сущности и их взаимосвязи, необходимые для соблюдения требований системы к постоянному хранению данных в соответствии с общей архитектурой приложения. В теории баз данных логическую модель еще называют моделью «сущность – связь» или ER-диаграммой (от Entity – сущность и Relationships – связь).
Модель содержит совокупность сущностей, представленных в виде прямоугольников, внутри которых записывается название. Сущности связываются между собой линиями (отношениями), которые сопровождаются надписями, указывающими тип отношения: один к одному, один ко многим или многие ко многим. Типы связей и отношений иллюстрирует рисунок 6.3. На нем числом указано конкретное (начальное) значение отношения, а звездочкой – любое (много).
Рис. 6.3
Сущности могут иметь набор атрибутов (признаков объекта), одним из которых является, так называемый, ключ. Обычно связи между сущностями осуществляются по этому ключу. Он имеет одинаковые значения в каждой из них. Пример такой связи приведен на рисунке 6.4.
Рис. 6.4
В дальнейшем мы придем к тому, что каждая сущность в наиболее распространенном типе баз данных, реляционной базе, представляется некоторой таблицей. База в целом является совокупностью этих таблиц.
Пример логической модели данных для объекта «Клинические записи» приведен ниже на рис. 6.5.
Рис.6.5
Модель показывает, что клинические записи включают (агрегируют) ряд блоков. При этом «минимальный набор данных» и «план лечения» могут быть включены в каждую клиническую запись в единственном экземпляре, а блоки «результаты анализов», «предписания врача», «ход лечения» могут повторяться неограниченное число раз.
Архив состоит из множества клинических записей (агрегирует клинические записи), но может быть и пустым.
Поскольку пациент может предварительно проходить лечение в других учреждениях, или несколько раз проходить лечение в центре, появляются дополнительные разновидности (подклассы) клинических записей: внешние, старые внутренние, новые внутренние.
Физическая модель данных состоит из подробных макетов таблиц базы данных и их взаимосвязей, созданных на основе логической модели. Таблицы в ней содержат параметры столбцов, а также ключи и индексы.
На приведенном ниже рисунке 6.6 изображен основной подход, основанный на использовании классов модели проектирования в качестве источника информации для логического проектирования баз данных. Он позволяет создать первоначальную физическую модель данных. На нем также изображен альтернативный подход, основанный на использовании отдельной логической модели данных.
Рис. 6.6
На рисунке представлены в качестве действующих лиц два проектировщика базы данных (Database Designer) и неявно один проектировщик программного обеспечения (Designer). Первый может самостоятельно разрабатывать логическую модель данных и преобразовывать ее в физическую (как показано на рисунке справа).
Проектировщик, в свою очередь, анализирует классы объектов и преобразует результаты анализа в структуру классов (как показано на рисунке слева). Разработчик базы данных (изображенный внизу) сотрудничает с проектировщиком системы и создает таблицы базы на основе структуры классов. При этом получают оптимальный результат.
На следующем рисунке (6.7) представлен фрагмент модели базы данных — две таблицы, соответствующие классам «пациент» и «минимальный набор данных» (см. рисунок для объекта «Клинические записи» логической модели ). Связь между ними обязательная, поскольку «минимальный набор данных не может существовать без «пациента».
Рис.6.7 Фрагмент модели базы данных
На диаграммах указываются дополнительные характеристики таблиц и столбцов:
Ограничения, которые определяют допустимые значения данных в столбце или операции над данными:
(ключ (PK,FK) – ограничение, определяющее тип ключа и его столбец;
проверка (Check) – ограничение, определяющее правило контроля данных;
уникальность (Unique) – ограничение, определяющее, что в столбце содержатся неповторяющиеся данные);
триггер – программа, выполняющая при определенных условиях предписанные действия с базой данных;
тип данных и пр.