Цель лекции: Изучить основы логического моделирования предметной области хранилища данных, нормальные формы отношений, процесс нормализации сущностей модели «сущность-связь». Изучить методы логического моделирования темпоральных данных.
Изучив материал настоящей лекции, Вы будете знать:
и научитесь
Для логического проектирования реляционных ХД применяются следующие методики:
Основным назначением информационных систем (ИС), в том числе и систем бизнес-аналитики, является оперативное обеспечение пользователя информацией о внешнем мире путем реализации вопросно-ответного отношения. Вопросно-ответные отношения, получая интерпретацию во внешнем мире (мире вне ИС), позволяют выделить для ИС определенный его фрагмент - предметную область, который будет воплощен в системе. Информация о внешнем мире представляется в ИС в форме данных. Это ограничивает возможности смысловой интерпретации информации и конкретизирует семантику ее представления в ИС. Совокупность этих выделенных данных для ИС образует логическую модель предметной области, описывающие ее состояние с определенной точностью.
Важно понимать, что логическая модель предметной области создаются на этапе анализа требований к ИС и не содержат предположений о технологии реализации ХД или БД.
Оперируя терминами «данные» и «вопросы», вопросно-ответное отношение можно представить в виде таблицы, столбцами которой являются элементы данных, а строками вопросы. Каждая ячейка такой таблицы имеет логическое значение 1, если вопрос использует этот элемент данных, или 0 в противном случае.
Понятие предметной области является одним из базовых понятий информатики и не имеет точного определения. Его использование в контексте ИС предполагает существование устойчивой во времени соотнесенности между именами, понятиями и определенными реалиями внешнего мира, не зависящей от самой ИС и ее круга пользователей. Таким образом, введение понятия предметной области ограничивает и делает обозримым пространство информационного поиска в ИС и позволяет выполнять запросы за конечное время.
Совокупность реалий (объектов) внешнего мира - объектов, о которых можно задавать вопросы, образует объектное ядро предметной области. Невозможно получить в ИС ответ на вопрос о том, что ей неизвестно.
Термин объект является первичным, неопределяемым понятием. Синонимами термина «объект» являются «реалия», «сущность», «вещь». Отметим, что термин «сущность» понимается далее несколько уже, как компонент определенной логической модели предметной области. Выделяемые в предметной области объекты превращаются аналитиками (а не проектировщиками) в сущности. При этом сущность предметной области понимается как результат абстрагирования реального объекта путем выделения и фиксации его свойств.
На Рис. 4.1 представлен один из подходов к классификации объектов предметной области.
Рис. 4.1. Классификация объектов предметной области
Примерами сущностей (с точки зрения логической модели предметной области) или объектов (с точки зрения внешнего мира по отношению к ИС) являются: студент, группа студентов, аудитория для занятий, время занятий и. т. д.
С объектами связано две проблемы - идентификация и адекватное описание. Для идентификации используют имя. При этом предполагается, что происходит отказ от его смысла, который присущ естественному языку. Используется только указательная функция имени. Имя - это прямой способ идентификации объекта. К косвенным способам идентификации объекта относят его свойства в их понимании как характеристики или признака.
Объекты взаимодействуют между собой через свои свойства, что порождает ситуации. Ситуации - это взаимосвязи, выражающие взаимоотношения между объектами. Ситуации в предметной области описываются посредством высказываний о предметной области с использованием исчисления высказываний и исчисления предикатов, т.е. формальной, математической логики. Например, высказывание «Программист, менеджер есть служащие компании» описывает отношение включения. Таким образом, вся информация об объектах и сущностях предметной области описывается с помощью утверждений на естественном языке. Методы математической логики позволяют формализовать эти утверждения и представить их в виде, пригодном для анализа.
Отметим, что в семантике естественных языков ситуация и взаимосвязь считаются почти синонимами. Ситуация содержит высказывание об объектах предметной области, которому можно приписать некоторую оценку истинности и представить в виде предиката после введения переменных. Таким образом, совокупность высказываний о предметной области можно трактовать как определение информационного пространства для ИС.
На Рис. 4.2 представлен один из подходов к классификации ситуаций в рамках предметной области.
Рис. 4.2. Классификация ситуаций предметной области
Различают статические и динамические ситуации. Примерами статических ситуаций являются такие ситуации, как «иметь цвет», «иметь возраст» и т.д. Примерами динамических ситуаций являются такие ситуации, как «создать механизм», «выпечь хлеб» и т.д. Обратите внимание на то, что ситуация также может представлять собой объект и обладать свойствами. Подобная коллизия порождает не однозначность при моделировании предметной области.
Приведенная выше классификация вводит в предметную область два важных аспекта - пространство и время, причем время понимается и как момент события, и как интервал между событиями. Предметная область существует в пространстве и во времени, т.е. ей присущи, как и реальному миру, временные и пространственные отношения и связи. Следует отличать реальное время внешнего мира и его отражение в ИС и в источниках информации. В ИС взаимосвязи, зависящие от времени, фиксируются только после их регистрации. Таким образом, предметная область в каждый конкретный момент времени представляет собой выделенную совокупность определенных объектов и ситуаций, называемую состоянием предметной области (или снимком).
Таким образом, предметная область - это целенаправленная первичная трансформация картины внешнего мира в некоторую умозрительную картину, определенная часть которой фиксируется в ИС в качестве алгоритмической модели фрагмента действительности.
Понятие предметной области было введено в начале 80-х годов прошлого века, когда учеными в области ИС была осознана необходимость использовать семантические модели для представления информации в ИС. Требования к ИС формируются средствами естественного языка, и информация в ИС представляется средствами особого языка с определенной семантикой. Такой подход впервые был представлен П. Ченом в 1976 году.
Примером классической предметной области для создания систем бизнес-аналитики, и, следовательно, для ХД является задача анализа продаж компании. В качестве объектов этой предметной области можно выделить следующие: «менеджер продаж», «товар», «склад», «офис продаж». «покупатель». В качестве ситуаций - «продать товар», «купить товар», «отгрузить товар со склада», «доставить товар».
ХД является предметно-ориентированной, интегрированной, постоянной во времени коллекцией исторических данных используемой различными группами пользователей для поддержки принятия решений или анализа данных. Информация в ИС, в том числе и в ХД, представляется в виде элементов данных (items). Одно из основных положений концепции ХД состоит в очистке, фильтрации, преобразования, суммировании и агрегации данных, а затем размещения их в некоторой структуре для обеспечения информационных потребностей пользователей. Определение такой структуры является одной из основных задач логического моделирования ХД.
Одним из первых задач проектировщика ХД является определение архитектуры данных. Архитектура данных - это принципы субъективного представления информации в виде данных в рамках модели предметной области. При построении архитектуры данных проектировщик ХД определяет элементы данных, их свойства и взаимосвязи между ними. Одним из ключевых моментов построения архитектуры данных является степень детализации информации при преобразовании ее в элементы данных. Процесс такого преобразования называют структуризацией данных.
Для данных OLTP систем решение вопросов, связанных с уровнем детализации данных не является столь важным, как в системах складирования данных. В БД OLTP систем данные обычно детально структурированы. Для представления данных в ХД проектировщик должен специально решить вопрос об уровне структуризации данных, исходя из требований к системе бизнес-информатики. Решение этого вопроса является важным, поскольку при агрегации и суммировании данных некоторые диапазоны данных из подающей OLTP системы могут быть не представлены в ХД. Например, ХД телекоммуникационной компании может содержать оплату за пользование телефоном, просуммированную по минутам, а подающая система хранит такие данные по секундам.
Уровень структуризации (детализации или гранулированности) данных (Data granularity) является одной из самых важных характеристик ХД. Уровень структуризации данных - это степень детализации хранимых данных, оптимальный с точки зрения решения информационно-аналитических задач в рамках предметной области ХД.
Грубо говоря, уровень структуризации данных определяет количество запросов, на которые можно получить ответы в системе бизнес-аналитики. Если в ХД поддерживается высокий уровень структуризации данных, то система поддерживает практических любой запрос в рамках предметной области ХД. В примере, приведенном выше, нельзя получить ответ на вопрос: сколько абонент Иванов А.А. заплатил за пять секунд разговора первого января 2009 года.
Поддержка высокого уровня структуризации данных приводит к необходимости хранить и сопровождать большие объемы данных, что может отрицательно сказываться на производительности системы бизнес-аналитики, в частности, на времени ответа на запрос. С другой стороны, низкий уровень структуризации данных приводит к тому, что система бизнес-аналитики может отвечать на строго ограниченный круг запросов. Поэтому, одной из задач проектировщика ХД на уровне логического моделирования является принятие решения об оптимальном уроне структуризации данных в ХД.
Структуризация данных предполагает разбиение всего набора данных на определенные классы с целью дальнейшей детализации внутри выделенного класса. Для ХД характерны три основных вида данных (класса):
Понятие предметной области используется практически при проектировании и разработке всех классов информационных систем с БД и ХД. Предметная область определяет ту часть реального мира, которая будет моделироваться и реализовываться в системе. Предметная область определяет наиболее общие вытекающие из ее семантики критерии и требования к системе.
Вопросы, с которыми пользователи обращаются к ХД, носят, как правило, стратегический и обобщающий характер, в отличие от вопросов к OLTP системам. Ответы на них предполагают агрегацию и суммирование данных по различным направлениям деятельности организации. Это требует от систем с ХД ориентации на конкретные предметные области деятельности организации. Предметные области в системах с ХД формируются в соответствии с направлениями деятельности организации. Чтобы определить список предметных областей для таких систем, необходимо определить основные виды деятельности организации. Например, продажи, производство, клиенты и т.д.
Для выделения предметных областей в ХД часто используется так называемая методика «правило 6W», а именно, ответы на вопросы когда (when), где (where), кто (who), что (what), почему (why) и как (hoW) по отношению к видам деятельности организации (интересы бизнеса). Например, при ответе на вопрос «кто» интересы бизнеса могут охватывать следующие объекты: «покупатели», «сотрудники», «поставщики», «менеджеры», «партнеры по бизнесу» и т. д.
После построения списка потенциальных предметных областей для систем с ХД, обычно выполняют их дальнейшую детализацию путем декомпозиции каждой предметной области. В результате может быть получен список предметных областей, наиболее полно представляющий деятельность организации. При этом важно определить взаимоотношения между выделенными предметными областями, что является важным для определения измерений при многомерном моделировании ХД.
Отметим, для решения задач анализа, и, следовательно, для разработки BI-систем, наиболее перспективным подходом для определения предметной области является изучение бизнес-процессов организации, а не функций, как в случае OLTP систем.
Рассмотрим метод моделирования «сущность-связь». Этот метод используется для представления предметной области в виде ее логической модели. Применение этого метода создает модель предметной области, не зависимую от реализации. Этот метод используется, как при моделировании предметных областей OLTP систем, так и при моделировании предметных областей BI-систем. Знание этого метода помогает проектировщику ХД быстрее установить логические связи между моделями БД OLTP систем масштаба организации и моделями ХД BI-систем. Применение этого метода к моделированию предметной области ХД носит вспомогательный характер.
Результатом моделирования методом «сущность-связь» или ER моделирования является ER модель. ER модель представляется с помощью ER диаграмм, которые являются графической нотацией для абстрагирования данных в виде сущностей, взаимосвязей и атрибутов. Таким образом, семантика предметной области представляется в ER модели в терминах субъективных средств описания - сущностей, атрибутов, идентификаторов сущностей, супертипов, подтипов и т.д.
Сущность предметной области является результатом абстрагирования реального объекта путем выделения и фиксации набора его свойств. Таким образом, сущность представляет класс объектов, который является результатом абстрагирования реального объекта. Как правило, они обозначаются именем существительным естественного языка.
Сущность описывается с помощью данных, именуемых свойствами или атрибутами (attributes) сущности. Как правило, атрибуты являются определениями в высказывании о сущности и обозначаются именами существительными естественного языка.
Сущности вступают в связи друг с другом через свои атрибуты. Каждая группа атрибутов, описывающих одно реальное проявление сущности, представляет собой экземпляр сущности (instance). Иными словами, экземпляры сущности - это реализации сущности, отличающиеся друг от друга и допускающие однозначную идентификацию. Именование сущности в единственном числе облегчает в дальнейшем чтение модели. Фактически имя сущности дается по имени ее экземпляра.
Одним из основных компьютерных способов распознавания сущностей в ИС является присвоение сущностям идентификаторов (Entity identifier). Часто идентификатор сущности называют ключом. Задача выбора идентификатора сущности является семантически субъективной задачей. Поскольку сущность определяется набором своих атрибутов, то для каждой сущности целесообразно выделить такое подмножество атрибутов, которое однозначно идентифицирует данную сущность.
Некоторые сущности имеют естественные идентификаторы. Например, естественным идентификатором счета-фактуры является его номер. Идентификаторы сущности могут быть составными - состоящими из нескольких атрибутов, и атомарными - состоящими из одного атрибута сущности.
Уникальный идентификатор сущности - это атрибут сущности, позволяющий отличать одну сущность от другой. Если сущность имеет несколько уникальных идентификаторов, так называемых возможных ключей, то проектировщик должен выбрать первичный ключ сущности.
Различают однозначные и многозначные атрибуты. Однозначными являются атрибуты, которые в пределах конкретного экземпляра сущности имеют только одно значение. В противном случае, они считаются многозначными.
Важным моментом изучения модели предметной области является выделение многозначных атрибутов сущности. Это связано с тем, что реляционная модель не поддерживает многозначных атрибутов, и они должны быть разрешены на последующих стадиях проектирования.
Каждый атрибут имеет домен (domain). Домен - это выражение, определяющее значения, разрешенные для данного атрибута. Иными словами, домен - это область значений атрибута. Для каждого атрибута сущности должен быть определен домен. На уровне логического моделирования данных назначение домена атрибуту носит общий характер. Например, атрибут текстовый, числовой, бинарный, дата или "не определен". В последнем случае, аналитик должен дать описание домена. На последующих стадиях тип домена конкретизируется, смысл понятия домена в физической модели ХД уже, чем его может понимать аналитик. Это связано с тем, что в рамках физической модели домен реализуется посредством механизма ограничения домена, СУБД не понимает неопределенных доменов.
Сущности не существуют отдельно друг от друга. Между ними имеются реальные отношения (Relationship), и они должны быть отражены в модели предметной области. При выделении отношений акцент делается на фиксацию связей и их характеристик. Отношение (связь) представляет собой соединение (взаимоотношение) между двумя или более сущностями. Каждая связь реализуется через значения атрибутов сущностей. Обычно связь обозначается глаголом. Каждая связь также должна иметь свой уникальный идентификатор связи.
В реляционной модели отношения реализуются только через ограничение целостности по внешнему ключу. Поэтому проектировщик реляционного ХД должен контролировать, чтобы связь между сущностями осуществлялась через точно указанные атрибуты, которые будут определять уникальный ключ связи. Выбор ключей сущностей - одно из важнейших проектных решений, которое предстоит сделать проектировщику при переходе к физической модели базы данных.
Связи характеризуются степенью связи и классом принадлежности сущности к связи. Степень (мощность) связи - это отношение числа сущностей, участвующих в образовании связи. Например, «один-к-одному», «один-ко-многим», «многие-ко-многим». На уровне логической модели допускается неопределенная или неразрешенная связь. Класс принадлежности сущности - это характер участия сущности в связи. Различают обязательные и необязательные классы принадлежности сущности к связи. Обязательным является такой класс принадлежности, когда экземпляры сущности участвуют в установлении связи в обязательном порядке. В противном случае сущность принадлежит к необязательному классу принадлежности. Для необязательного класса принадлежности сущности степень связи может быть равна нулю, т.е. экземпляр сущности можно связать с 0, 1 или несколькими экземплярами другой сущности. Для обязательного класса принадлежности степень связи не может равняться нулю.
Отношения, связывающие сущность саму с собой, называются рефлексивными. Типичным примером рефлексивных отношений является определение структуры подчиненности в отношении «Сотрудники». Рефлексивные отношения чаще всего отражают иерархические отношения внутри структуры данных.
С точки зрения отношений различают слабые сущности (weak). Слабые сущности - это сущности, которые не могут присутствовать в базе данных, пока не существует связанного с ней экземпляра другой сущности. Примером такой сущности является заказ, который не может существовать без клиента. Слабые сущности имеют обязательный класс принадлежности, и степень связи такой сущности не может равняться нулю. Связь «Заказ-Клиент» является обязательной.
Выявление слабых сущностей и связанных с ними обязательных отношений необходимо для обеспечения целостности и согласованности данных. Так, например, неизвестному клиенту невозможно приписать заказ.
Иногда выделенная сущность несет в себе отношение включения или отношение часть-целое. При этом существует некоторый атрибут, значения которого порождают разбиение множества экземпляров сущности на непересекающиеся подмножества - категории сущности. Категории сущности называют подтипами и выделяют в подчиненную в рамках отношения сущность, которая является категорией исходной сущности. Из исходной сущности выделяются общие для полученных категорий атрибуты, и таким образом выделяется сущность, которая становится супертипом. Выделенной сущности-супертипу обычно оставляют наименование исходной сущности, хотя ее семантический смысл меняется.
Супертип с порожденными им подтипами является примером так называемой составной сущности. Составная сущность является логической конструкцией модели для представления набора сущностей и связей между ними как единого целого.
Пример: Сущность Автомобиль можно разбить на следующие подтипы: автомобили с приводом на два колеса, автомобили с приводом на четыре колеса, автомобили с переключаемым приводом.
Для проектировщика важно знать, что все экземпляры сущности-супертипа относятся только к одному из ее подтипов. Наличие в модели подтипов и супертипов усложняют проектирование и создают определенные трудности в реализации. Поэтому важно на ранней стадии проектирования установить, является ли наличие супертипов в модели необходимым.
Для этого необходимо предпринять следующие действия:
Типичной формой документирования логической модели предметной области при ER моделировании являются диаграммы «сущность-связь» или ER-диаграммы (Entity Relationship Diagram). ER-диаграмма позволяет графически представить все элементы логической модели согласно простым, интуитивно понятным, но строго определенным правилам - нотациям.
Для создания ER диаграмм обычно используют одну из двух наиболее распространенных нотаций:
Построение ER-диаграмм, как правило, ведется с использованием CASE-средств.
В данной лекции во всех примерах, если это не оговорено особо, будет использоваться нотация SAP Sybase PowerDesigner.
Сущность на ER-диаграмме представляется прямоугольником с именем в верхней части (Рис. 4.3). В прямоугольнике перечисляются атрибуты сущности.
Рис. 4.3. Представление сущности «Продажи» на ER- диаграмме
Каждый экземпляр сущности должен быть уникален и отличаться от других атрибутов. Одним из основных компьютерных способов распознавания сущностей в ИС является присвоение сущностям идентификаторов (entity identifier). Поскольку сущность определяется набором своих атрибутов, то для каждой сущности целесообразно выделить такое подмножество атрибутов, которое однозначно идентифицирует данную сущность. Часто идентификатор сущности называют первичным ключом (primary key).
Первичный ключ (primary key) - это атрибут или группа атрибутов, однозначно идентифицирующая экземпляр сущности. Атрибуты первичного ключа на диаграмме не требуют специального обозначения - это те атрибуты, которые находятся в списке атрибутов выше горизонтальной линии (рис. 4.4.).
Выбор первичного ключа может оказаться непростой задачей, решение которой в состоянии повлиять на эффективность будущей ИС. В одной сущности могут оказаться несколько атрибутов или наборов атрибутов, претендующих на роль первичного ключа. Такие претенденты называются потенциальными ключами (candidate key).
Ключи могут быть сложными, т.е. содержащими несколько атрибутов. Сложные первичные ключи не требуют специального обозначения - это список атрибутов выше горизонтальной линии.
Рассмотрим кандидатов на первичный ключ сущности «Продажи». Здесь можно выделить следующие потенциальные ключи: Дата продажи, Товар (идентификатор товара), Покупатель (идентификатор покупателя), Магазин (идентификатор магазина).
Для того чтобы стать первичным, потенциальный ключ должен удовлетворять ряду требований.
Уникальность. Два экземпляра не должны иметь одинаковых значений возможного ключа.
Компактность. Сложный возможный ключ не должен содержать ни одного атрибута, удаление которого не приводило бы к утрате уникальности.
Атрибуты ключа не должны содержать нулевых значений.
Значение атрибутов ключа не должно меняться в течение всего времени существования экземпляра сущности.
Каждая сущность должна иметь, по крайней мере, один потенциальный ключ. Многие сущности имеют только один потенциальный ключ. Такой ключ становится первичным. Некоторые сущности могут иметь более одного возможного ключа. Тогда один из них становится первичным, а остальные - альтернативными ключами. Альтернативный ключ (Alternate Key) - это потенциальный ключ, не ставший первичным.
Некоторые сущности имеют естественные (натуральные) ключи. Например, естественным идентификатором счета-фактуры является его номер. В противном случае проектировщик может создать суррогатный ключ (Surrogate Key) - атрибут, значение которого создается искусственно и не имеет отношения к предметной области. При моделировании структур данных для ХД суррогатные ключи во многих ситуациях являются более предпочтительными.
Домены назначаются аналитиками и фиксируются в специальном документе - словаре данных (Data Dictionary). При создании логической модели домены могут быть специфицированы в сущностях на ER-диаграмме.
Каждый атрибут имеет домен. Домен можно определить как абстрактный атрибут, на основе которого можно создавать обычные атрибуты, при этом создаваемые атрибуты будут иметь все свойства домена-прародителя. Каждый атрибут может быть определен только на одном домене, но на каждом домене может быть определено множество атрибутов. В понятие домена входит не только тип данных, но и область значений данных.
На уровне логического моделирования данных назначение домена атрибуту носит общий характер. Например, атрибут текстовый, числовой, бинарный, дата или "не определен". В последнем случае, аналитик должен дать описание домена. На последующих стадиях тип домена конкретизируется, смысл понятия домена в физической модели ХД уже, чем его может понимать аналитик. Это связано с тем, что в рамках физической модели домен реализуется посредством механизма ограничения домена, СУБД не понимает неопределенных доменов.
Отношение (связь) сущностей на ER-диаграмме изображается линией, соединяющей эти сущности. Отношение читается вдоль линии либо слева направо, либо справа налево. На Рис. 4.4 представлено следующее отношение: продажа каждого товара должна быть зарегистрирована строке чека.
Рис. 4.4. Представление отношения между двумя сущностями на ER-диаграмме
При выделении связей акцент делается на выявление их характеристик. Связь представляет собой взаимоотношение между двумя или более сущностями. Каждая связь реализуется через значения атрибутов сущностей, При создании связи в одной из сущностей, называемой дочерней сущностью, создается новый атрибут, называемый внешним ключом (Foreign Key) (сравните Рис. 4.3 и Рис. 4.4).
Связь является логическим соотношением между сущностями. Каждая связь должна именоваться глаголом или глагольной фразой Имя связи (Verb Phrase) - фраза, характеризующая отношение между родительской и дочерней сущностями. Имя связи выражает некоторое ограничение или бизнес-правило и облегчает чтение диаграммы.
Существуют различные типы связей: идентифицирующую связь (identifying relationship) «один ко многим», связь «многие ко многим» и неидентифицирующую связь (non-identifying relationship) "один ко многим". С типами связей связывают и различные типы сущностей.
Различают два типа сущностей зависимые (Dependent entity) и независимые (Independent entity). Тип сущности определяется ее связью с другими сущностями. Идентифицирующая связь устанавливается между независимой (родительский конец связи) и зависимой (дочерний конец связи) сущностями.
Экземпляр зависимой сущности определяется только через отношение к родительской сущности. При установлении идентифицирующей связи (на рисунке непрерывная линия) атрибуты первичного ключа родительской сущности автоматически переносятся в состав первичного ключа дочерней сущности (непрерывная линия). Эта операция дополнения атрибутов дочерней сущности при создании связи называется миграцией атрибутов. В дочерней сущности такой атрибут считается как внешним ключом.
Связь «многие ко многим» (many-to-many relationship) может быть создана только на уровне логической модели. Магазин продает много товаров. Товар может продаваться в нескольких магазинах. Связь «многие ко многим» должна именоваться двумя фразами - в обе стороны.
Как было указано выше, связи определяют, является ли сущность независимой или зависимой. Различают несколько типов зависимых сущностей:
Более подробно изучить метод моделирования «Сущность-связь» можно по учебным пособиям.
Различают 3 подуровня логического уровня модели данных, отличающиеся по глубине представления информации о данных:
Диаграмма «сущность-связь» (ER-диаграмма) включает сущности и взаимосвязи, отражающие основные бизнес-правила предметной области, в нее включаются основные сущности и связи между ними, которые удовлетворяют основным требованиям, предъявляемым к ИС. Диаграмма сущность-связь может включать связи "многие ко многим" и не включать описание ключей. Как правило, ER-диаграммы используется для презентаций и обсуждения структуры данных с экспертами предметной области.
Модель данных, основанная на ключах, - более подробное представление данных. Она включает описание всех сущностей и первичных ключей и предназначена для представления структуры данных и ключей, которые соответствуют предметной области.
Полная атрибутивная модель - наиболее детальное представление структуры данных: представляет данные в третьей нормальной форме и включает все сущности, атрибуты и связи.
Рассмотрим теперь процесс нормализации данных, который сопровождает создание полной атрибутивной модели.
Нормализация - процесс проверки и реорганизации сущностей и атрибутов с целью удовлетворения требований к реляционной модели данных. Нормализация позволяет быть уверенным, что каждый атрибут определен для своей сущности, значительно сократить объем памяти для хранения информации и устранить аномалии в организации хранения данных. В результате проведения нормализации должна быть создана структура данных, при которой информация о каждом факте хранится только в одном месте.
Процесс нормализации сводится к последовательному приведению структуры данных к нормальным формам - формализованным требованиям к организации данных. Известно 6 нормальных форм:
На практике обычно ограничиваются приведением данных к третьей нормальной форме В данном подразделе будут достаточно кратко рассмотрены первые три нормальные формы и, в качестве иллюстрации, четвертая нормальная форма. Для углубленного изучения нормализации следует рекомендовать книгу Дейт К. Дж. Введение в системы баз данных. Пер. с англ. 6-е изд. – К.: Диалектика, 1998.
Нормальные формы основаны на понятии функциональной зависимости (в дальнейшем будет использоваться термин "зависимость"). Приведем формальное определение для функциональной зависимости.
Функциональная зависимость (FD). Атрибут B сущности E функционально зависит от атрибута A сущности E тогда и только тогда, когда каждое значение A в E связало с ним точно одно значение B в E, т. е. A однозначно определяет B.
Полная функциональная зависимость. Атрибут B сущности E полностью функционально зависит от ряда атрибутов A сущности E тогда и только тогда, когда B функционально зависит от A и не зависит ни от какого подмножества атрибутов A.
Функциональные зависимости определяются бизнес-правилами предметной области. Так, если оклад сотрудника определяется только должностью, то атрибут Оклад зависит от атрибута Должность; если оклад зависит еще, например, от стажа, то такой зависимости нет. В нижеследующих примерах будем считать для определенности, что такая зависимость есть.
Рассмотрим нормальные формы.
Первая нормальная форма (1NF). Сущность находится в первой нормальной форме тогда и только тогда, когда все атрибуты содержат атомарные значения.
Среди атрибутов не должно встречаться повторяющихся групп, т. е. несколько значений для каждого экземпляра. Атрибуты сущности «Сотрудник» Телефон и Хобби могут представлять повторяющиеся группы и тем самым нарушать требования первой нормальной формы. Сотрудник может иметь несколько телефонов или иметь несколько увлечений (рыбалка, охота, плавание). Добавление в сущность несколько атрибутов для представления значений повторяющейся группы не является решением, проблемы, поскольку в большинстве случаем нельзя заранее точно определить сколько таких значений может быть.
Нарушением требований нормализации является хранение в одном атрибуте разных по смыслу значений (атомарности). Атрибут Дата зачисления или увольнения сущности «Сотрудник» хранит информацию, как о зачислении, так и об увольнении сотрудника. Если хранится только одно значение, то невозможно понять, какая именно дата внесена. Если внести атрибут-признак типа даты, тип можно будет определить, но останется возможность хранения только одной даты для каждого сотрудника.
Для приведения сущности к первой нормальной форме следует:
Вторая нормальная форма (2NF). Сущность находится во второй нормальной форме, если она находится в первой нормальной форме, и каждый неключевой атрибут полностью зависит от первичного ключа (не должно быть зависимости от части ключа). Вторая нормальная форма имеет смысл только для сущностей, имеющих сложный первичный ключ.
Предположим, сущность «Проект» содержит информацию о проекте, которым руководит сотрудник, причем информация содержится как непосредственно о проекте, так и о руководителе проекта. Атрибуты Фамилия, Имя, Отчество и Должность зависят только от атрибута Табельный номер руководителя, но вовсе не от Наименования проекта. Другими словами, имеется зависимость только от части ключа.
Для приведения сущности ко второй нормальной форме следует:
Вторая нормальная форма позволяет избежать следующих аномалий при выполнении операций:
Третья нормальная форма (3NF). Сущность находится в третьей нормальной форме, если она находится во второй нормальной форме и никакой не ключевой атрибут не зависит от другого не ключевого атрибута (не должно быть взаимозависимости между не ключевыми атрибутами).
Пусть сущность «Сотрудник» находится во второй нормальной форме (имеется только один атрибут первичного ключа, поэтому не может быть зависимости не ключевых атрибутов от части ключа), но не ключевой атрибут Оклад зависит от другого не ключевого атрибута - Должности.
Для приведения сущности к третьей нормальной форме следует:
В третьей нормальной форме каждый атрибут сущности зависит от ключа, от всего ключа целиком и ни от чего другого, кроме как от ключа.
Третья нормальная форма также позволяет избежать ряда аномалий:
Четвертая нормальная форма (4NF) требует отсутствия многозначных зависимостей между атрибутами.
Например, преподаватель читает лекции по нескольким предметам и курирует несколько групп студентов. Одна группа студентов может изучать несколько предметов, одному предмету могут обучаться несколько групп студентов. Имеется многозначная зависимость между атрибутами Предмет и Группа. При этом возможна аномалия: если у преподавателя появляется новая группа, приходится добавлять несколько записей, по числу читаемых предметов.
Для приведения сущности к четвертой нормальной форме следует создать новую сущность и перенести атрибуты с многозначной зависимостью в разные сущности. Связь между новыми сущностями при этом устанавливать нельзя, поскольку в результате миграции атрибутов внешних ключей атрибуты с многозначной зависимостью вновь окажутся в одной сущности.
ХД всегда содержит данные с типом «дата» или «время». Такие данные называются темпоральными или временными. Далее будем говорить о реляционной модели данных и ее темпоральных расширениях. Следует отметить, что данные в компьютерных системах, так или иначе, связаны с различными событиями, интервалами времени. Рассмотрим подробней представление темпоральных данных в БД.
Что же такое темпоральные данные? В очень широком смысле - это произвольные данные, которые явно или неявно связаны с определенными датами или промежутками времени. Под такое определение попадают почти любые данные и информация. Например, даже если нет явной зависимости от времени для какого-нибудь факта или события, то все равно для него имеется неявная зависимость от времени, так как когда-то нам (или системе) стало известно, что такой факт существует. Кроме того, есть вероятность, что в будущем факт будет пересмотрен, или на условия его использования будут наложены определенные ограничения; поэтому нельзя уже будет рассматривать его как некоторую абсолютную истину, верную во всех ситуациях и в любой момент времени.
В темпоральных БД хранятся данные, изменяющиеся с течением времени. С другой стороны, многие понимают, что в SQL отсутствует адекватная и эффективная поддержка работы с темпоральными БД. В реляционной БД может сохраняться информация о событиях и интервалах времени, соответствующих различным представлениям и связям. Если обработкой подобных данных занимается сам пользователь, то используемый тип времени можно назвать временем, определяемым пользователем. Его отличительным признаком служит отсутствие интерпретации со стороны СУБД, так как обработка данных, связанных со временем, полностью возлагается на пользователя. Фактически, все современные СУБД обеспечивают поддержку подобной разновидности времени, например, с помощью введения специальных типов данных DATA или TIMESTAMP.
В общем случае можно выделить два вида данных для представления времени: время фиксации определенного события или факта и время выполнения какого-либо действия или операции.
Если рассматривать данные, представленные в БД, как некоторое отражение текущего состояния действительности для моделируемого мира, то каждая запись может восприниматься как некоторый факт, который является истинным в определенный момент или интервал времени. При переходе к темпоральной БД для каждого факта можно указать тот промежуток времени, когда этот факт являлся истинным в моделируемом мире, представленном в БД. Поэтому подобное представление времени, когда с данными связывается промежуток времени их актуальности (с точки зрения моделируемого мира), называется временем фиксации факта (valid time). Его значения можно сравнить с показаниями часов моделируемого мира. Поскольку довольно часто в БД отражается именно реальный мир, могут быть заданы соотношения между значениями времени реального мира и представленной в БД моделью. Отметим, что значениями данного типа времени могут быть моменты времени как в прошлом, так и в будущем. Кроме того, эти значения могут изменяться, то есть истинность факта в определенные моменты времени может приниматься или отклоняться.
Другим типом времени, который рассматривается в темпоральных БД, является время операции или транзакционное время. В любой СУБД каждой записи БД можно сопоставить тот промежуток времени, когда данная запись была представлена в БД, т.е. промежуток времени между моментами добавления записи и ее удаления из базы данных. При этом отметим, что операция обновления, которая действительно вносит изменения в запись, понимается как составная операция удаления старой записи и добавления новой. Очевидно, что значения времени операции не могут относиться к будущему.
Таким образом, момент времени, когда факт актуализируется в БД, является временем выполнения операции. Время операции может быть связано с любой сущностью БД, а не только с фактами. Хотя все сущности могут быть связаны с временем операции, проектировщик может решить не рассматривать временной аспект для некоторых сущностей БД. Например, время размещения набора экземпляров сущности в БД за одну операцию вставки (интервал времени) может и не учитываться в модели данных. Время операции, которое отражает время изменения состояния объектов БД или приложений, записывается как значение атрибута сущности БД.
Чтобы ответить на вопрос, как соотносятся между собою время фиксации факта и время выполнения операции, рассмотрим следующий пример. Пусть имеется таблица БД, в которой хранится информация о текущей зарплате сотрудника организации (Табл. 4.1).
| Сотрудник | Отдел | Зарплата |
|---|---|---|
| Прохоров А.И. | ОВИР | 15000 |
| Соловьева М.Е. | ОВИР | 15000 |
| Амосова Е.С. | ОВИР | 6000 |
При наличии поддержки времени фиксации мы могли бы в любой момент сказать, какая у сотрудника была зарплата за произвольный период времени (Табл. 4.2). Таким образом, данные о зарплате могут быть представлены как последовательность изменяющихся во времени значений.
| Сотрудник | Отдел | Зарплата | Время фиксации факта |
|---|---|---|---|
| Прохоров А.И. | ОВИР | 15000 | с 1 июня 2018 |
| Соловьева М.Е. | ОВИР | 15000 | с 1 июня 2018 |
| Амосова Е.С. | ОВИР | 12000 | С 1 января 2018 по 30 июня 2018 |
| Амосова Е.С. | ОВИР | 12000 | с 1 июня 2018 |
При наличии поддержки времени операции мы могли бы сказать, в какой момент в таблицу были внесены изменения (Табл. 4.3).
| Сотрудник | Отдел | Зарплата | Время операции |
|---|---|---|---|
| Прохоров А.И. | ОВИР | 15000 | с 1 июня 2018 |
| Соловьева М.Е. | ОВИР | 15000 | с 1 июня 2018 |
| Амосова Е.С. | ОВИР | 12000 | с 1 января 2018 по 30 июня 2018 |
| Амосова Е.С. | ОВИР | 12000 | с 1 июня 2018 |
Теперь предположим, что для таблицы поддерживается как время фиксации факта, так и время операции (Табл. 4.4). Тогда в случае, если неправильно введенные данные были впоследствии исправлены, можно будет точно сказать, когда это было сделано. Кроме того, информация о подобных изменениях необходима, так как некорректные данные могли бы быть уже использованы в каких-нибудь отчетах. Поэтому в данном случае требуется поддержка времени операции. При обновлении значений в системе интервал времени также обновляется, поэтому можно просмотреть список изменений в БД.
| Сотрудник | Зарплата | Время фиксации факта | Время операции |
|---|---|---|---|
| Прохоров А.И. | 15000 | с 1 июня 2008 | с 1 июня 2018 |
| Соловьева М.Е. | 15000 | с 1 июня 2008 | с 1 июня 2018 |
| Амосова Е.С. | 12000 | С 1 января 2008 по 30 июня 2008 | с 1 января 2018 по 30 июня 2018 |
| Амосова Е.С. | 12000 | с 1 июня 2008 | с 1 июня 2018 |
Говоря о типах времени, введем понятие о гранулярности времени. Гранулярность времени показывает, насколько близкие моменты на оси времени все еще будут отличимыми друг от друга. Например, возможно, что для данных о заработной плате сотрудника достаточно использования времени фиксации факта разбиения по дням, а для времени операции может быть использовано разбиение по секундам, если в СУБД возможна более частая фиксация транзакций.
В общем случае с каждым типом времени может быть еще связан некоторый календарь, который определяет диапазоны значений, гранулярность, соответствия и преобразования между моментами времени для различных осей времени.
Выше при обсуждении времени фиксации факта, говорилось, что существует некоторый интервал, в котором определенный факт являлся истинным. Это так называемое интервальное представление. Однако можно рассматривать отдельный момент времени и все факты, которые были истинны в этот конкретный момент (точечное представление). Здесь говорится о представлении времени с точки зрения пользователя, то есть тех условных моделях, в рамках которых могут формулироваться запросы и возвращаться их результаты. При использовании любого из этих представлений истинность фактов не меняется, но в случае точечного представления мы получаем срез всех фактов на какой-то конкретный момент времени, а для интервального представления нас интересует определенный факт и периоды его истинности. Если говорить об обычной реляционной модели, то она опирается на точечное представление для актуального состояния данных.
И со временем фиксации факта, и со временем операции связывается домен «Время», который может быть, как дискретным, так и непрерывным. Для представления времени в БД обычно используется домен с конечными и дискретными значениями. Предполагается, что значения времени в домене упорядочены.
Моделирование темпоральных данных использует совокупность методов моделирования для создания моделей временных и исторических данных. Модель темпоральных данных - это модель данных, которая состоит из элементов данных и внутренних структур, отражающих изменения элементов модели во времени, фиксируя те моменты времени, когда эти изменения происходят. Будем называть модель битемпоральной, если в ней присутствуют время операции и время фиксации факта.
Моделирование темпоральных данных является сложной задачей для ИС, основанных на реляционных БД. Во-первых, такие данные не очень удобно представлять в двумерной реляционной модели. Обработка темпоральных данных требует использования критериев поиска по диапазону, что приводит к использованию соединений таблиц (строятся на основе неравенств). Производительность выполнения таких соединений является проблемой в реляционных БД. Во-вторых, для темпоральных данных часто требуется соединять таблицы на основе перекрытия диапазонов дат. В SQL нет операции, позволяющей непосредственно задать такое соединение.
Приведем пример темпоральных данных (Таблица 4.5). Пусть требуется отлеживать динамику цен на некоторые товары. Цены на товары в любой момент времени могут измениться, поэтому необходимо хранить действительный диапазон дат по каждой цене и по каждому товару.
Просматривая таблицу легко найти, когда, какая цена на данный товар действовала, а также увидеть, что в период с 26.12.2000 по 01.01.2001 цена на данный товар не была установлена. В рассматриваемом примере цена товара обладает характеристикой, которая называется действительностью по дате, т.е. цена на товар действительна только в определенный период времени. При проектировании темпоральных моделей данных необходимо учитывать подобные характеристики данных.
| № | Дата начала действия новой цены | Дата окончания действия цены | Цена, руб. |
|---|---|---|---|
| 1 | 01.01.2000 | 15.06.2017 | 2000 |
| 2 | 16.06.2000 | 25.12.2017 | 1998 |
| 3 | 01.01.2001 | 31.12.2018 | 1800 |
| 4 | 01.01.2002 | 25.03.2019 | 1802 |
| 5 | 26.03.2002 | 30.09.2019 | 1700 |
| 6 | 01.10.2002 | 12.11.2019 | 1750 |
| 7 | 13.11.2002 | 31.12.2019 | 1850 |
| 8 | 01.01.2003 | 1900 |
Таким образом, темпоральная модель данных отличается от традиционных моделей данных наличием одного существенного элемента - времени. Для представления времени в темпоральной модели данных используются так называемые временные метки (time stamp). Временные метки - это атрибуты, которые связаны с фиксацией показаний времени, например даты события, такого, как продажа конкретного товара. Исследование временных меток предметной области является одной из самых главных задач при моделировании временных данных, потому, что временные метки могут иметь несколько значений, т.е. неоднозначную интерпретацию в рамках предметной области.
При моделировании временных данных обычно используют следующие интерпретации временных меток:
Темпоральные данные в ХД будут представлены колонками таблиц с типом дата/время. Поскольку интерпретация временных меток в рамках предметной области может быть различной, то каждая из таких интерпретаций порождает свой собственный домен в реляционной базе данных. Анализ данных часто использует операции поиска и выборки на соединениях таблиц. Если в таких операциях соединения будут использоваться временные метки, то их домены должны совпадать. Поэтому проектировщик ХД должен очень внимательно определить временные метки ХД, т.е. изучить их интерпретацию и соответствующим образом определить для каждой метки свой домен. Проектировщик фиксирует интерпретацию временных меток ХД в метаданных, о которых речь пойдет дальше.
Существует два основных типа временных меток - моментные временные метки или временная метка события (Instant timestamp) и временные метки диапазона или интервальные временные метки (Interval timestamp).
Моментная временная метка - это временная метка с одним значением, которое представляет момент времени. Такие метки используются для представления в ХД объектов, изменяющихся во времени, таких, как операции или события хозяйственной деятельности. Моментные временные метки используются для фиксации изменения значений данных, извлекаемых из оперативных систем и затем сохраняемых в ХД.
Интервальные временные метки представляют собой период времени или диапазон и содержат обычно два значения: начала и окончания периода или длины интервала. Такие временные метки используются обычно для моделирования состояния объекта и его поведения во времени. В случае, если длина интервала является фиксированной, например, день или месяц, то для представления интервальной временной метки может быть использовано одно значение.
На Рис. 4.5 показаны примеры определения сущностей с моментной временной меткой (Сущность_1) и интервальными временными метками (Сущность_2).
Рис. 4.5. Определение сущностей с моментными и интервальными временными метками
Необходимость учитывать в модели данных элемент времени ставит перед проектировщиком ХД следующие задачи:
Для моделирования темпоральных данных предметной области необходимо расширить модель введением в нее темпоральных (временных) сущностей или отношений. Такое расширение может быть сделано различными способами.
В настоящее время при создании темпоральной модели данных наиболее широко используются следующие подходы:
Модель, основанная на таблицах моментальных снимков. Подход к моделированию темпоральных данных, основанный на накоплении моментальных снимков, состоит в сборе снимков фрагмента предметной области и накоплении таких снимков в различных фрагментах БД или другой БД как истории жизни данных предметной области. Например, если снимки фиксируются в конце дня, то совокупность собранных за период снимков будут представлять ежедневное изменение картины данных предметной области, поддерживаемой в БД.
Таблица реляционной БД, представляющая моментальные снимки называется таблицей моментального снимка (Snapshot Table). Рассмотрим пример такой таблицы (Табл. 4.7). Временные метки в ней отсутствуют. Можно добавить в такую таблицу временную метку со временем, определенным пользователем. Эта таблица представляет экземпляры сущности предметной области так, как они существуют в данный момент времени. Операция обновления таблицы реляционной БД является деструктивной - никакой истории изменения данных во времени не поддерживается. В Табл. 4.7 показано содержание таблицы моментального снимка (Empl) до и после обновления.
| До обновления | ||
| Сотрудник (Name) | Отдел (Dept) | Зарплата (Sal) |
|---|---|---|
| Прохоров А.И. | ОВИР | 15000 |
| Соловьева М.Е. | ОВИР | 15000 |
| Амосова Е.С. | ОВИР | 6000 |
| После обновления | ||
| Сотрудник (Name) | Отдел (Dept) | Зарплата (Sal) |
| Прохоров А.И. | ОВИР | 15000 |
| Соловьева М.Е. | ОВИР | 15000 |
| Амосова Е.С. | ОВИР | 11500 |
Метод кумулятивных снимков применяется и вне рамок моделирования темпоральных данных. Он прост и понятен, однако имеет ряд недостатков. Первый недостаток - это избыточность данных, которая возникает в результате периодической перезагрузки данных из источника данных. При этом объем ХД быстро растет. Чтобы устранить этот недостаток, часто применяют агрегирование данных с суммированием показателей или введение версий снимков.
Вторым недостатком такого подхода является возможная потеря информации. Это связано с проблемой синхронизации изменений состояния данных в источниках данных и моментом фиксации снимка в ХД. Проблема отражения смены состояний данных предметной области в ХД является одной из самых сложных задач, которые должен решить проектировщик ХД. В рамках подхода, основанного на накоплении снимков, бывает достаточно трудно решить такую задачу. Например, если данные нужно фиксировать ежесекундно, то объем данных в ХД так быстро будет расти, что проект создания ХД станет непомерно дорогим. Такие ситуации могут встретиться в предметных областях, связанных с аудитом биржевых операций.
Модель, основанная на таблицах событий. Разработка непрерывной исторической модели ставит своей целью создание модели данных, которая отражает историю изменения данных в ХД. Это модель сложнее, чем модель кумулятивных снимков, в том числе и с точки зрения ее интерпретации. Несмотря на это, непрерывная историческая модель является более релевантной для анализа временных рядов параметров предметной области.
Подход к моделированию темпоральных данных, основанный на фиксации событий предметной области, состоит в добавлении временной метки фиксации события (факта) как атрибута экземпляра сущности предметной области и отражении момента времени в таблице БД как истории жизни данных предметной области. Например, учет оплаты счетов покупателем.
Таблица реляционной БД, представляющая события предметной области называется таблицей событий (Event Table). Рассмотрим пример такой таблицы учета оплаты счетов клиентом (Табл. 4.8). Событие для сущности предметной области «Счет» состоит с создании экземпляра сущности, содержащего данные о том, что в такое-то время покупатель оплатил счет на определенную сумму денег. Временная метка в этой таблице фиксирует время оплаты счета покупателем, т.е. представляет время фиксации факта оплаты счета. Проектировщик может добавить в такую таблицу временную метку со временем, определенным пользователем. Данные таблицы поддерживают, в частности, историю оплаты счетов конкретным покупателем. Обновление данных этой таблицы не производится, поскольку эта таблица предназначена для накопления данных (только операции добавления).
| Номер счета | Покупатель | Сумма оплаты | Дата оплаты |
|---|---|---|---|
| 1001 | Иванов А.И. | 1000 | 12.01.20109 |
| 1003 | Петров Е.С. | 25000 | 17.11.2018 |
| 1006 | Васильева Е.К. | 300 | 23.02.2019 |
Таблицы событий используются, как правило, для представления данных, по которым должен быть подведен итог, т.е. выполнена операция суммирования для различных периодов времени.
Модель, основанная на таблицах состояния. Подход к моделированию темпоральных данных, основанный на фиксации состояний предметной области, состоит в добавлении временных меток для фиксации начала и завершения определенного состояния как атрибутов экземпляра сущности предметной области экземпляров сущности, и отражении моментов времени начала и завершения определенного состояния сущности в таблице БД как истории жизни данных предметной области. Например, учет оплаты счетов покупателем.
Таблица реляционной БД, представляющая состояние объектов предметной области называется таблицей состояния (State Table). Под состоянием понимаются объекты, которые существуют в определенный период времени. Пример таблицы состояния (Empl) приведен в Табл. 4.9. Кортежи таблицы данные о зарплате сотрудников организации с указанием периода времени, когда установленная заплата выплачивается, т. е. состояние экземпляра сущности «Сотрудник» сохраняется. Пара временных меток «Время назначения» и «Время отмены» определяет период времени, в течение которого кортеж таблицы имеет смысл. Значение FOREVER равно наибольшему значению времени, принятому в системе.
| Сотрудник (Name) | Отдел (Dept) | Зарплата (Sal) | Время назначения (SDate) | Время отмены (EDate) |
|---|---|---|---|---|
| Прохоров А.И. | ОВИР | 15000 | 01.06.2018 | FOREVER |
| Соловьева М.Е. | ОВИР | 15000 | 01.06.2018 | FOREVER |
| Амосова Е.С. | ОВИР | 10000 | 01.01.2018 | 30.05.2008 |
| Амосова Е.С. | ОВИР | 12000 | 01.06.2018 | FOREVER |
Так же, как и таблицы событий, таблицы состояния используются для хранения данных, по которым должен быть подведен итог, т.е. выполнена операция суммирования для различных периодов времени. Заметим, что в таблице событий суммирование проводится по одному периоду времени, в то время, как в таблице состояния заданный период может перекрываться с периодами, определенных сущностей, и, следовательно, при агрегации данных, возможно, придется проводить разбиение заданного периода на несколько периодов с учетом имеющего место быть перекрытия периодов кортежей.
Учет временных зависимостей предметной области. Рассмотрим пример БД о видеофильмах («Фильм»), записанных на определенных студиях («Студия») под управлением конкретных менеджеров («Директор») с участием определенных актеров («Актер»). Фрагмент логической структуры (ER-модели), связывающих указанные выше сущности, приведен на Рис. 4.6. Данная ER-модель является статической - она не учитывает никаких исторических аспектов существования студии или время работы определенного менеджера над определенной картиной.
Рис. 4.6. ER модель БД о видеофильмах без учета временных зависимостей
Предположим, что поставлена задача - построить историческую модель для приведенной ER модели с помощью методов темпорального моделирования данных. Нужно рассмотреть временные зависимости сущностей предметной области и внести их в статическую ER модель. Временной зависимостью будем называть функциональную зависимость значений атрибутов сущностей предметной области от времени.
Для учета временных зависимостей проектировщику необходимо добавить в приведенную статическую структуру временные метки. При этом следует решить следующие задачи:
При решении этих задач взаимоотношения между сущностями временно не принимаются во внимание. Предположим, что в нашем примере заказчику не интересна история взаимоотношения актеров и менеджеров (директоров) фильмов, а также история участия актеров в различных фильмах. Тогда для сущности, описывающей актеров, временное моделирование данных не будет выполняться.
Далее, пусть заказчику интересна история состояния студии или периоды занятости менеджера фильмов. Тогда, естественно, моделировать временное поведение сущностей, описывающих студии и менеджеров, с помощью фиксации состояния их атрибутов.
Предположим, что заказчика интересует история существования фильма в прокате. Тогда было бы разумно выполнить временное моделирование сущности, описывающей фильм, с помощью фиксации событий, связанных с фильмом.
Например, одним из бизнес-приложений, необходимым для заказчика, будет «Прокат видеофильмов». Клиенты оплачивают пользование видеокассетой в течение определенного времени и дней. Приложение ведет учет предоставления клиентам таких услуг. Результат темпорального моделирования на ER модели показан на Рис. 4.8 ниже.
Рис. 4.7. Добавление временных меток в сущности статической ER модели
Таким образом, основным приемом логического моделирования темпоральных данных предметной области является добавление временных меток в сущности предметной области. Добавление временных меток в сущности логической модели позволяет зафиксировать в модели поведение некоторых атрибутов сущности во времени. Такие атрибуты сущности отражают временные зависимости атрибутов.
Классы временных зависимостей атрибутов (нормализация модели). После добавления временных меток в сущности логической модели одной из главных задач проектировщика становится определение атрибутов сущности, которые участвуют во временной зависимости. Одним из приемов решения такой задачи в рамках реляционной модели данных является нормализации временных зависимостей или построение классов временных зависимостей (Volatility Classes).
Классом временной зависимости называется группа атрибутов сущности, которые совместно изменяют свои значения с течением времени. Ответ на вопрос о том, сколько атрибутов должно попадать в класс, не является однозначным. Классы с небольшим кардинальным числом атрибутов с одной стороны не выгодны с практической точки зрения, а объединение в класс значительного числа независимо меняющихся во времени атрибутов приводит к увеличению избыточности хранения с другой стороны. Хорошим практическим критерием будет являться сложность сопровождения этих классов в ХД.
На практике проектировщики темпоральных моделей данных используют следующие два основные класса:
Класс не зависимых от времени атрибутов образуют те атрибуты, которые либо не зависят от времени, либо для которых принято решение, не хранить историю их временного поведения. Этот класс всегда не пуст, поскольку предполагается, что ключ сущности составляют атрибуты, которые не зависят от временных отношений сущности в предметной области.
Атрибуты этого класса помещаются в новую сущность, которая представляет часть первоначальной сущности. Эта новая сущность будет являться как бы корнем в иерархии временных отношений со всеми зависимыми от времени сущностями, полученными из первоначальной сущности. С этой точки зрения история поведения сущности во времени может быть промоделирована с помощью зависимых сущностей.
Например, для сущности «Директор» атрибуты Табельный номер, его Фамилия, Адрес и Телефон являются кандидатами для помещения к класс не зависимых от времени атрибутов. Понятно, что в этом случае предполагается, что директор не будет менять свою фамилию, и нас не интересует история его места жительства.
Для сущности «Фильм» такой класс может состоять из атрибутов Инвентарный номер фильма, Название фильма и Года выпуска фильма.
Класс зависимых от времени атрибутов образуют те атрибуты сущности, которые меняются синхронно во времени. Таких классов у сущности может быть несколько. Каждый такой класс должен быть вынесен в отдельную сущность.
Например, для сущности «Директор» фильма класс зависимых от времени атрибутов будет составлять интервальная временная метка и Зарплата директора. Такой класс будет единственным у первоначальной сущности. При этом будет моделироваться, как уже решил проектировщик, история состояния атрибута Зарплата. На Рис. 4.8 ниже показана историческая модель для сущности «Директор» фильма.
Рис. 4.8. Темпоральная логическая модель для сущности «Директор» фильма
Для сущности «Фильм» могут быть идентифицированы два класса зависимых от времени атрибутов, поскольку значения атрибутов Бюджет фильма и Сборы за прокат имеют независимое друг от друга поведение во времени. Более того, поскольку значение атрибута Бюджет изменяется не слишком часто, то для временного моделирования его поведения целесообразно использовать модель состояния и интервальную временную метку. Значение атрибута Сборы за прокат будет меняться при каждой записи данных в ХД, и, следовательно, нужно отображать это событие с помощью моментной временной метки. Полученная логическая модель исторического поведения сущности «Фильм» приведена на Рис. 4.9 ниже.
Рис. 4.9. Темпоральная логическая модель для сущности «Фильм»
Проведя исследования исходной логической модели на предмет учета поведения сущностей во времени, проектировщик ХД должен ответить на вопрос, учтены ли все темпоральные данные, которые требуются хранить в ХД (если нет, то построить соответствующие сущности логической модели).
Решение этой задачи обычно связано с поиском сущностей для представления событий и операций хозяйственной деятельности, которые являются важными для решения задач анализа данных в ХД, но не поддерживаются в рамках исходной ER модели данных подающих OLTP систем. Эта задача является достаточно сложной и требует всестороннего изучения предметной области с точки зрения анализа данных.
Так, в нашем примере мы не рассматривали ряд вопросов, связанных с участием актеров в фильмах. Конечных пользователей могут заинтересовать ряд вопросов, которые связаны с сущностью «Актер»:
Если на первые два вопроса пользователь может получить ответы на существующей структуре данных ER модели (см. Рис, 4.7), то для ответов на два других логическая модель должна быть дополнена информацией о гонорарах актера в фильмах и показателем, который измеряет популярность актера. Потребуются ли для представления такой информации дополнительные атрибуты или сущности, решает проектировщик ХД.
Таким образом, нормализация темпоральной логической модели основывается на выделении классов зависимых от времени атрибутов и вынесении их в отдельные сущности предметной области.
Теперь мы готовы приступить к построению логической темпоральной модели.
Применение метода моделирования «Сущность-связь» помогает проектировщикам создать логическую модель предметной области, не зависимую от программно-аппаратной реализации. Этот метод используется, как при моделировании предметных областей OLTP, систем, так и при моделировании предметных областей BI-систем. Знание этого метода помогает быстрее установить логические связи между моделями БД OLTP систем масштаба организации и моделями ХД BI-систем.
Независимо от выбранной нотации, действия проектировщика ХД при ER моделировании сводятся к следующему алгоритму.
Для каждой сущности предметной области базы данных необходимо:
Для каждой связи между сущностями необходимо:
Рассмотренный подход к моделированию темпоральных данных является расширением модели «Сущность-связь» за счет учета временных зависимостей определенных атрибутов сущностей предметной области.
При таком подходе проектировщик выполняет следующую последовательность действий:
В результате применения темпорального моделирования проектировщик создает логическую модель предметной области с учетом временных зависимостей в данных и не зависимую от программно-аппаратной реализации. Этот метод используется, как при моделировании предметных областей OLTP, систем, так и при моделировании предметных областей BI-систем.
Для получения официальных документов о завершении программы дополнительного профессионального образования (удостоверения о повышении квалификации, дипломов о профессиональной переподготовке и MBA) необходимо предоставить:
Внимание! Вы можете не заказывать доставку бумажной версии официального документы, а скачать его в электронном виде и распечатать самостоятельно. Информация о выданном документе в течение 1 месяца загружается в Федеральную информационную систему «Федеральный реестр сведений о документах об образовании и (или) о квалификации, документах об обучении» - ФИС ФРДО.
Доступ на новый сайт осуществляется с использованием адреса электронной почты, который был указан вами при регистрации на "старом". Мы постарались перенести все ваши данные с прежнего ресурса, однако не исключена вероятность потери части информации.
При возникновении проблемы со входом, воспользуйтесь функцией сброса пароля
Если вы обнаружите несоответствия, пожалуйста, сообщите нам.