Форма входа

Наша реклама

Помогите сайту просмотрите рекламу

Поиск

Календарь

«  Апрель 2024  »
ПнВтСрЧтПтСбВс
1234567
891011121314
15161718192021
22232425262728
2930

Наш опрос

Оцените мой сайт
Всего ответов: 122

Статистика


Онлайн всего: 1
Гостей: 1
Пользователей: 0




Суббота, 20.04.2024, 14:54
Приветствую Вас Гость | RSS
Скорая помощь для студентов
Главная | Регистрация | Вход
ЭТАПЫ ПРОЕКТИРОВАНИЯ БАЗ ДАННЫХ


ЛЕКЦИЯ #3. ЭТАПЫ ПРОЕКТИРОВАНИЯ БАЗ ДАННЫХ

ПРОЕКТИРОВАНИЕ БАЗ ДАННЫХ

Создание информационных систем (ИС) является сложной и плохо формализуемой задачей, требующей детальных знаний о работе автоматизируемой предметной области. При этом никто в организации не знает как она работает в той мере подробности, которая необходима для создания ИС. Поэтому для описания работы предприятия необходимо построить его адекватную модель, содержащую в себе знания всех участников бизнес-процессов организации.
Реализацию сложных проектов по созданию ИС принято разбивать на стадии анализа, проектирования, кодирования, тестирования и сопровождения. Известно, что исправление ошибок, допущенных на предыдущей стадии, обходится примерно в 10 раз дороже, чем на текущей, следовательно, наиболее критическими являются первые стадии проекта – анализа и проектирования.
Около 90% всех современных ИС требуют решения целого комплекса задач по хранению данных. В современных условиях, когда объемы обрабатываемых данных высоки и продолжают стремительно возрастать, решение таких задач немыслимо без использования технологий баз данных. Исходная информация для работы системы и результаты ее работы сохраняются в БД, таким образом, создание базы данных выходит на первый план на начальном этапе создания информационной системы.
При создании БД ИС наиболее важными являются задачи, связанные с созданием правильной логической структуры данных, обеспечивающей решение всего набора требуемых задач. Под правильной логической структурой в данном случае понимается структура, созданная с учетом особенностей организации хранения данных, используемых при решении требуемых задач. По словам Г.Буча, база данных, разработанная без учета того, как она в дальнейшем будет использоваться, оказывается, как правило, неуклюжей и неэффективной. Создание правильной логической структуры предусматривает комплексный анализ всех факторов, влияющих на формирование и обработку данных.
Таким образом, проектирование является важнейшей стадией при создании БД, т.к. именно на этом этапе принимаются очень важные стратегические решения, влияющие на весь процесс создания эффективной БД. Разработка эффективной БД является достаточно сложной задачей, т.к. зачастую к ней предъявляется много противоречивых требований. Задача проектировщика состоит в учете всех требований с целью создания оптимальной БД.
Дэйт утверждает, что при проектировании любой базы данных нужно дать ответ на следующий вопрос: «Какие структуры данных и соответствующие им операторы должна поддерживать система?». Выбор той или иной структуры данных или модели связан с особенностями, присущими данной системе и выбранной стратегии ее построения. Зачастую решающим фактором здесь является опыт проектировщика и его практические навыки при создании подобных систем. Тем не менее, при создании новой системы на этапе проектирования предстоит выбрать ту модель, которая наиболее подходит для реализации данной задачи.
При проектировании структуры БД разработчик (проектировщик) часто сталкивается с «сухими» фактами, предоставляемыми заказчиком. Например, заказчик предоставляет проектировщику только формы документов, используемых в работе. Этого явно не достаточно, т.к. не ясны цели проектирования. При простом переносе данных форм в БД неизбежно возникнет ряд проблем, устранение которых повлечет за собой необходимость в перепроектировании структуры всей БД.
Процесс разработки БД можно разбить на несколько этапов:
  • Исследование предметной области
  • Создание инфологической модели
  • Создание даталогической модели
  • Создание физической модели

ИССЛЕДОВАНИЕ ПРЕДМЕТНОЙ ОБЛАСТИ

Исследование предметной области необходимо проводить в целом для разрабатываемой системы, частью которой является и БД. При этом модель данных может быть создана только в случае, если выявлены все объекты системы, логика их взаимодействия, потоки передаваемой информации. База данных является хранилищем передаваемых данных, которые используются системой при работе. Можно сказать, что БД – это фундамент системы, а следовательно к ее созданию нужно подходить очень серьезно. Очень много ошибок при создании БД происходят по причине недостаточной продуманности ее структуры и некачественного выполнения этапа проектирования, который начинается с исследования предметной области.
Создание системы необходимо начинать c исследования процессов, происходящих в предметной области и используемых ими данных. При этом очень важно определить рамки системы и перечень выполняемых ей функций. Подобный анализ желательно проводить с участием экспертов предметной области и консультантов. При этом работа сводится к поэтапному выделению объектов, значимых функций системы, информационных потоков и системы их взаимосвязей. Целью подобного исследования является выделение значимых функций для разрабатываемой системы, их согласование, описание в терминах понятных как разработчику, так и будущему пользователю. На этом этапе важно понять смысловое значение данных, обрабатываемых в системе, отделить ключевые понятия предметной области от маловажных и вообще несущественных для рассматриваемого случая.
Очень важно на этапе проектирования достичь взаимопонимания как между разработчиками системы, так и между экспертами предметной области, заказчиками и т.д., так как каждый имеет свое видение проекта. Точки зрения участников разработки по определенным проблемам могут совпадать, однако формы их представления быть различными, что ведет к осложнению совместной работы над одним проектом. Важным инструментом в данном случае является использование единой нотации – системы обозначений, правил описания процессов, объектов, явлений и их взаимосвязи, позволяющее всем участникам проекта «говорить на одном языке». Причем, как отмечает Г.Буч, комплексность подхода и использование единой нотации очень важно, не только на этапе моделирования предметной области, но и на последующих этапах разработки программной системы.
Результатом проведения исследования предметной области должен стать перечень системных требований, спецификаций, бизнес процессов, информационных потоков и их описание. Очень часто для этого применяются стандартные способы описания предметной области с использованием моделей DFD, SADT, UML.

ИНФОЛОГИЧЕСКОЕ МОДЕЛИРОВАНИЕ

Инфологическая модель создается по результатам проведения исследований предметной области. Инфологическая модель представляет собой описание будущей базы данных, представленное с помощью естественного языка, формул, графиков, диаграмм, таблиц и других средств, понятных как разработчикам БД, так и обычным пользователям. Назначение такой модели состоит в адекватном описании процессов, информационных потоков, функций системы с помощью общедоступного и понятного языка, что делает возможным привлечение экспертов предметной области, консультантов, пользователей для обсуждения модели и внесения исправлений. В данном случае под созданием инфологической модели будем понимать именно ее создание для БД. В общем случае, инфологическая модель может создаваться для любой проектируемой системы и представляет ее описание (в общем случае в произвольной форме).
Создание инфологической модели является естественным продолжением исследований предметной области, но в отличие от него является представлением БД с точки зрения проектировщика (разработчика). Наглядность представления такой модели позволяет экспертам предметной области оценить ее точность и внести исправления. От правильности модели зависит успех дальнейшей разработки.
Инфологическую модель можно представить в виде словесного описания, однако наиболее наглядным является использование специальных графических нотаций, разработанных для проведения подобного рода моделирования.
Важно отметить, что создаваемая на этом этапе модель полностью не зависит от физической реализации будущей системы. В случае с БД это означает, что совершенно не важно где физически будут храниться данные: на бумаге, в памяти компьютера и кто или что эти данные будет обрабатывать. В этом случае, когда структуры данных не зависят от их физической реализации, а моделируются исходя из их смыслового назначения, моделирование называется семантическим.
Существует несколько способов описания инфологической модели, однако, в настоящее время одним из наиболее широко распространенных подходов, применяемых при инфологическом моделировании, является подход, основанный на применении диаграмм «сущность-связь» (ER – Entity Relationship). При рассмотрении последующих примеров будем использовать одну из самых распространенных в рамках ER моделей нотацию IDEF1X. Данный стандарт был разработан в 1993 г. Национальным институтом стандартизации и технологий и является федеральным стандартом обработки информации (США), описывающим семантику и синтаксис языка, правила и технологии для разработки логической модели данных.
Для построения инфологической модели важно знать элементы этой модели. Базовыми элементами модели сущность-связь являются сущности.
Сущность по форме представляет собой только некоторое реального описание объекта, точнее набор описаний его значимых признаков-атрибутов. Конкретный набор значений атрибутов объекта будет называться экземпляром сущности.

 
Рис. 1. Сущность и экземпляр сущности
Как видно из рис. 1, понятие «сущность» – означает форму информации, ее смысл. Понятие «элемент сущности» – отражает содержание.
Так, без наличия описания информации (т.е. сущности) будет трудно понять содержание следующей информации
 
ИВАНОВ
СЕРГЕЙ
АЛЕКСАНДРОВИЧ
М
15.07.1945
ХОЛОСТ
...

Это может быть как описанием объекта «сотрудник предприятия», так и описанием объекта «покупатель», или чем-то иным.
Поэтому, процесс выделения сущностей из автоматизируемой предметной области и их описание является ключевым для создания любых структур данных.
В качестве сущности может быть выбран не только объект, но и явление, процесс, трансформация, действие.
Если автоматизируется какой-либо процесс, то необходимо указать свойства этого процесса, объекты участвующие в этом процессе.
Пример. При автоматизации процесса покупки товаров (сущность «Покупка товаров») необходимо указать:
  •  какой товар необходимо купить (сущность «Товар»);
  • у кого его необходимо купить (сущность «Продавец»);
  •  другие признаки операции покупка товара, такие как «количество», «цена», «сумма» и пр.
Отсюда следует, что сущности, выделенные из предметной области могут быть связанными между собой. Одна сущность может ссылаться на другую и даже быть признаком другой сущности более высокого уровня (так, сущность «сотрудник» может быть элементом или необходимым атрибутом сущности «организация»).
Понятие «связь» между сущностями представляет собой наличие какой-либо зависимости, ассоциации между сущностями – т.е. наличие информационной или логической связи между объектами автоматизируемой предметной области.
Существует множество видов сущностей и связей между ними.
Рассмотрим понятие их более подробно:
Итак, сущность – это реальный или воображаемый объект реального мира, имеющий существенное значение для рассматриваемой предметной области, информацию о котором необходимо хранить в БД. В некоторых случаях сущностью может являться событие, процесс или явление, имеющие место в реальном мире.
Фактически каждая сущность представляет собой множество подобных индивидуальных объектов, именуемых экземплярами. Имя сущности дается по имени ее экземпляра. Каждый экземпляр сущности индивидуален и должен отличаться от других экземпляров. Это отличие выражается в наличии у каждого экземпляра сущности уникальных свойств, называемых атрибутами.
Примерами сущностей могут быть Товар, Клиент, Покупатель. Наименование товара «Кирпич» является экземпляром сущности товар. Один и тот же объект реального мира может являться экземпляром нескольких сущностей. Так Иванов И.И. может быть как клиентом, так и покупателем, а также являться сотрудником фирмы.
Согласно нотации IDEF1X сущности изображаются в виде прямоугольников, как это показано на рис. 2.

 Рис. 2. Пример изображения сущностей на ER диаграмме
Процесс выделения сущностей из автоматизируемой предметной области и их описание является ключевым для создания любых структур данных.
В качестве сущности может быть выбран не только объект, но и явление, процесс, действие.
Если автоматизируется какой-либо процесс, то необходимо указать свойства этого процесса, объекты участвующие в нем.
Например, при автоматизации процесса покупки товаров необходимо указать:
  •  какой товар необходимо купить (сущность «Товар»);
  •  у кого его необходимо купить (сущность «Продавец»);
  •  другие признаки: «Количество», «Цена», «Сумма» и пр. (сущность «Покупка товаров»).
Отсюда следует, что сущности, выделенные из предметной области могут быть связанными между собой. Одна сущность может ссылаться на другую и даже быть признаком другой сущности более высокого уровня (так, сущности «Товар» и «Продавец» могут быть элементами или необходимыми атрибутами сущности «Покупка товаров», сущность «Сотрудник» – элементом или необходимым атрибутом сущности «Организация»).
Понятие связь между сущностями представляет собой наличие какой-либо зависимости, ассоциации между сущностями – т.е. наличие информационной или логической связи между объектами автоматизируемой предметной области.
Ключевым моментом в методологии IDEF1X является взаимосвязь или отношения в которых находятся сущности. Форма взаимодействия одной сущности с другими является важной ее характеристикой. Различают два основных вида взаимодействия. Сущность является независимой если каждый ее экземпляр может быть однозначно идентифицирован без установления связей с другой сущностью. Сущность является зависимой (дочерней), если уникальная идентификация ее экземпляров возможна только путем установления связи с другой сущностью.
Например, сущности «Отдел» и «Сотрудник» являются независимыми, если предположить, что сотрудник может работать в организации, не числясь ни в одном отделе. Примером зависимой сущности может являться сущность «Заказ» в паре сущностей «Клиент»-«Заказ». Информация о заказе не имеет смысла без информации о клиенте его разместившем.
Согласно нотации IDEF1X независимые сущности изображаются в виде обычных прямоугольников, зависимые – в виде прямоугольников со скругленными углами, как это показано на рис.38. При нанесении на ER диаграмму сущности, необходимо руководствоваться следующими требованиями:
  •  сущность должна иметь наименование с четким смысловым значением и именоваться существительным в единственном числе.
  •  сущность должна обладать уникальным в пределах модели именем, имеющим четкое смысловое значение, выраженное в виде существительного в единственном числе, которое записывается над прямоугольником;
  •  именование сущности обычно производится по имени ее экземпляра, а единственное число облегчает в дальнейшем чтение модели.
 
Рис. …. Пример изображения связей между сущностями в нотации IDEF1X
Сущность «Заказ» на рис.38 изображена в виде прямоугольника со скругленными углами, т.к. является зависимой от клиента. Зависимость эта обусловлена тем, что экземпляр сущности «Заказ» не может существовать, если не указан клиент, его разместивший. «Заказ» в свою очередь, может являться независимой по отношению к сущности «Состав заказа», содержащей информацию о наименованиях, количестве и стоимости заказанных товаров или услуг. В этом случае сущности «Заказ» и «Состав заказа» являются зависимыми и изображаются в виде прямоугольников со скругленными углами, сущность «Клиент», является независимой и изображается в виде обычного прямоугольника.
 
Рис. …. Изображение зависимых сущностей «Заказ» и «Состав заказа»
Таким образом, если сущность имеет несколько отношений с другими сущностями и при этом хотя бы в одном случае является зависимой, она изображается как зависимая.
Атрибут сущности – это именованная характеристика, являющаяся некоторым свойством сущности, значимым для рассматриваемой предметной области. Наименование атрибута должно быть выражено существительным в единственном числе и быть уникальным в пределах БД. Примерами атрибутов могут являться «Номер клиента», «Имя клиента», «Номер заказа», «Дата заказа» и др. На ER диаграмме атрибуты помещаются внутри прямоугольника. В этом случае название сущности размещается за пределами прямоугольника. Ключевые атрибуты помещаются в списке атрибутов первыми и отделяются от неключевых горизонтальной линией (рис….).
 
Рис. …. Отображение атрибутов сущности на ER диаграмме
На этапе инфологического моделирования мы скорее имеем дело с признаками сущности. Признак – это обобщенная характеристика сущности, позволяющая описать ее свойства не вдаваясь в подробности. На этапе инфологического моделирования признаки выступают в роли атрибутов. На этом этапе от разработчика не требуется проводить глубокий анализ сущности с целью выяснения всех ее атрибутов и их характеристик. Достаточно просто установить, что сущность обладает определенным набором признаков, которые необходимо выделить. В дальнейшем, при создании даталогической модели, признаки трансформируются в атрибуты, или наборы атрибутов, в зависимости от их сложности.
Ключ сущности – это атрибут или набор атрибутов, значения которых однозначно идентифицируют экземпляр сущности. При инфологическом моделировании необходимо говорить о ключевых признаках. Таким образом, для идентификации сущности необходимо выделить ключевой признак.
Ключ сущности может быть сложным (составным), состоящим из нескольких атрибутов или признаков. При этом комбинация значений атрибутов, входящих в ключ, должна быть уникальной в пределах сущности. Выбор первичного ключа является очень важной и зачастую непростой задачей, от решения которой может зависеть эффективность будущей БД. Сложность выбора обусловлена тем, что, во-первых, значение ключевого атрибута должно быть уникальным в пределах сущности, а во-вторых, в одной сущности может существовать несколько атрибутов или их наборов, подходящих на роль ключа сущности. Такие атрибуты (наборы атрибутов) называются потенциальными ключами (кандидатами). Один атрибут или набор атрибутов из числа кандидатов должен быть выбран в качестве первичного ключа. При этом он должен удовлетворять следующим требованиям:
  • уникальности – два экземпляра сущности не должны иметь одинаковых значений возможного ключа;
  • компактности – составной ключ не должен содержать ни одного атрибута, удаление которого не приводило бы к утрате уникальности;
  • значимости – атрибут ключа не должен быть пустым;
  • постоянства – значение атрибутов ключа не должно меняться в течение всего времени существования экземпляра сущности.
Если существует несколько кандидатов на роль первичного ключа, предпочтение следует отдавать более простому (содержащему меньшее количество атрибутов) ключу. Ключи, входящие в список кандидатов, но не ставшие первичными называются альтернативными ключами. На ER диаграмме такие атрибуты помечаются символами (AK) после имени атрибута.
На рис. изображена сущность «Контрагент», в качестве потенциальных ключей которой можно выделить:
1. «Код контрагента» (АК1.1);
2. «Наименование контрагента» (АК2.1) + «Телефон» (АК2.2);
3. «Город контрагента» (АК3.1)+ «Адрес контрагента» (АК3.2).
 
Рис. …. Альтернативные ключи сущности «Контрагент»
Если учесть очень маленькую вероятность существования двух контрагентов с одинаковыми наименованиями и телефонами или расположенных в городах с одинаковыми названиями и по одинаковым адресам, то второй и третий варианты подойдут на роль первичного ключа, однако, существует еще первый вариант, который проще по составу чем второй и третий – «Код контрагента». Это «синтетический» атрибут (см. понятие суррогатного ключа в занятии 1), т.к. не имеет прямого отношения к сущности «Контрагент», ведь не существует единого классификатора всех контрагентов, в котором каждому из них соответствует свой уникальный номер. «Код контрагента» в данном случае – это номер, присвоенный ему в пределах данной организации. С точки зрения теории баз данных использование атрибута «Код контрагента» в качестве ключевого неправильно, так как он не в состоянии обеспечить уникальности экземпляров сущности, ведь можно ввести дважды данные об одном и том же контрагенте, присвоив им при этом разные коды. При этом сущность окажется не только избыточной, но также может произойти нарушение целостности информации в БД вследствие использования в связанных с контрагентом сущностях информации об одном и том же контрагенте, ссылаясь на него при этом по разным номерам. Иллюстрация такого случая приведена на рис.3.7. Видно, что всего было оформлено 3 заказа Контрагентом 1. Но, так как в списке контрагентов ему соответствуют коды 1 и 3, то в одном случае заказ был оформлен Контрагентом с кодом 1, а во втором – с кодом 3. С точки зрения СУБД Контрагент 1 с кодом 1 и Контрагент 1 с кодом 3 являются разными экземплярами. Если не исправить данное положение, то со временем это приведет к серьезным трудностям в обработке информации БД, связанной с получением итоговых сведений.
 
Рис. … Пример нарушения целостности информации базы данных
Тем не менее, на практике, в силу особенностей реализации технологий реляционных СУБД, используется именно такой подход, при котором очень часто в качестве первичного ключа сущности используется именно суррогатный ключ (код или номер), а контроль целостности информации и избыточность остаются либо «на совести» пользователя, от которого требуется повышенное внимание при добавлении информации в БД, либо «на совести» программиста, реализующего различные блокировки.
Следующим важным понятием в методе «сущность-связь» является понятие отношения между сущностями.
Отношение (связь) – это некоторая ассоциация (логическое соотношение) между двумя сущностями, предполагающая зависимость между атрибутами этих сущностей. Связи позволяют по одной сущности находить другие сущности, связанные с ней. Название связи обычно представляется глаголом или глагольной фразой (отглагольным существительным), которая выражает некоторое ограничение или бизнес-правило и облегчает чтение диаграммы. Изображенная на рис. связь позволяет определить какие именно заказы разместил клиент и какой именно сотрудник оформил заказ. Глагольные фразы облегчают понимание смысла связи и могут быть созданы как для прямого, так и для обратного чтения связи. Так, в примере, представленном на рис. связь между сущностями «Клиент» и «Заказ» может быть прочитана следующим образом: Клиент размещает Заказ, Заказ размещается Клиентом. Обычно достаточно создания одной глагольной фразы для чтения связи в направлении от независимой сущности к зависимой, исключением являются связи типа многие-ко-многим, при которых для лучшего понимания типа связи желательно создание двух глагольных фраз.
 
Пример изображения связи на ER диаграмме
На этапе инфологического моделирования используют идентифицирующие и неидентифицирующие связи. Выше было сказано о том, что существуют зависимые и независимые сущности. Тип связи между двумя сущностями определяет какая из них является зависимой (дочерней), а какая – независимой (родительской). Идентифицирующая связь устанавливается между родительской и дочерней сущностями и означает, что каждому экземпляру дочерней сущности должен соответствовать хотя бы один экземпляр родительской. При этом дочерняя сущность не может существовать «вне рамок» родительской. На ER диаграммах идентифицирующая связь показывается в виде сплошной линии. Точка на линии ставится со стороны дочерней сущности (рис.43). Неидентифицирующая связь устанавливается между двумя независимыми сущностями и означает, что каждый экземпляр дочерней сущности может быть идентифицирован без использования экземпляра родительской сущности. На ER диаграммах неидентифицирующая связь показывается в виде пунктирной линии (рис.44).
Пусть даны две сущности «Материал» и «Единица измерения». Если предположить, что при учете материалов в БД можно не указывать единицу измерения данного материала, то сущности «Материал» и «Единица измерения» являются независимыми, а связь между ними – неидентифицирующей (рис.44).
 
Пример неидентифицирующей связи между сущностями
Связь между сущностями обеспечивается за счет миграции атрибутов родительской сущности в дочернюю. Миграция – перенос атрибутов одной сущности в другую для установления связи между ними. Мигрировавший атрибут называется внешним ключом и помечается на ER диаграмме символами (FK) (Foreign Key). Мигрировавший атрибут или группа атрибутов могут быть помещены в состав первичного ключа сущности или в состав неключевых атрибутов в зависимости от типа связи между сущностями. При этом действуют следующие правила:
  • если сущности связаны идентифицирующей связью, то все ключевые атрибуты родительской сущности мигрируют в состав первичного ключа дочерней сущности (рис.40);
  • если сущности связаны неидентифицирующей связью, то все ключевые атрибуты родительской сущности мигрируют в состав неключевых атрибутов дочерней сущности (рис.44).
  • При этом возможны два варианта отношений:
  • Допускаются пустые значения внешних ключей в дочерней сущности (знак ромба на неидентифицирующей связи со стороны независимой сущности).
  • Пустые значения внешних ключей в дочерней сущности не допускаются (отсутствие знака ромба со стороны независимой сущности).
Каждая связь, независимо от того, является ли она идентифицирующей
или нет обладает мощностью. Мощность связи (cardinality) – характеристи-
ка связи между сущностями, предназначенная для обозначения отношения
числа экземпляров родительской сущности к числу экземпляров дочерней.
Существует четыре различных типа мощности (рис.45):
1. Одному экземпляру родительской сущности соответствуют 0, 1 или много экземпляров дочерней сущности. Не помечается дополнительным значком на диаграмме.
2. Одному экземпляру родительской сущности соответствуют 1 или много экземпляров дочерней сущности (исключено нулевое значение). На диаграмме помечается значком P.
3. Одному экземпляру родительской сущности соответствуют 0 или 1 экземпляр дочерней сущности (исключены множественные значения). На диаграмме помечается значком Z.
4. Одному экземпляру родительской сущности соответствует заранее заданное число экземпляров дочерней сущности. На диаграмме помечается цифрой.
 
Обозначение мощности в нотации IDEF1X
Существует еще одна, не вошедшая в приведенный выше перечень, мощность связи – многие-ко-многим. Такая связь возможна только на логическом уровне представления модели и означает, что каждому экземпляру родительской сущности может соответствовать несколько экземпляров дочерней, а каждому экземпляру дочерней – несколько экземпляров родительской. В этом случае понятия «родительская» и «дочерняя» применимы к обоим связываемым сущностям. На диаграмме такая связь обозначается сплошной линией с двумя точками на концах. Обе сущности, участвующие в связи обозначаются как независимые. Пример такой связи приведен на рис.46. В данном случае, в отгрузку могут быть включены несколько товаров, в то же время один товар может участвовать в нескольких отгрузках.
Особой разновидностью связей является категориальная связь, используемая для описания структур, в которых сущность является типом (категорией) другой сущности. При этом родительская сущность (родовой предок) содержит общие свойства, присущие дочерним (категориальным) сущностям. Категориальную связь, называемую иногда иерархией наследования создают тогда, когда несколько сущностей имеют общие по смыслу атрибуты, либо когда сущности имеют общие по смыслу связи, либо когда это диктуется бизнес-правилами. Для каждой категории можно указать дискриминатор – атрибут родового предка, который показывает, как отличить одну категориальную сущность от другой.
 
Пример связи «многие-ко-многим»
В качестве примера рассмотрим следующий случай: допустим, известно, что при оформлении операций, связанных с перемещением товарно-материальных ценностей в организации используется два вида накладных: приходная и расходная. В данном случае сущность «Накладная» является родительской, так как объединяет общие для обеих сущностей атрибуты, а сущности «Приходная» и «Расходная» содержат информацию об особенностях накладных каждого вида. Дискриминатором в данном случае будет вид накладной (рис.47).
Категориальные связи делятся на два типа – полные и неполные. Если экземпляру родового предка соответствует экземпляр в каком-либо потомке, то связь является полной, на ER диаграмме изображается с помощью дискриминатора (рис.47). Если категория еще не выстроена полностью и в родовом предке есть экземпляры, для которых нет соответствующих экземпляров в потомках, категория является неполной, на ER диаграмме изображается с помощью дискриминатора (рис.47). Возможны иерархии наследования, в которых присутствуют и полные и неполные категории. При этом сущности, в одном случае являющиеся потомками, могут одновременно являться предками по отношению к другим связям.
В примере, изображенном на рис.47 первая категориальная связь (вид накладной) является полной, т.к. существует только два вида накладных: приходная и расходная. Тип расходной накладной является неполной категориальной связью, т.к. предполагается, что сюда включены еще не все сущности данной категории (например отгрузка материалов на сторону или списание материалов). Отсутствие сущности на диаграмме может быть обусловлено тем, что еще не выявлено ее существование в рамках данной модели, не установлен ее тип или ее существование внутри модели нежелательно.
 
Пример полной и неполной категориальной связи

ДАТАЛОГИЧЕСКОЕ ПРОЕКТИРОВАНИЕ

При даталогическом моделировании используется инфологическая модель предметной области. При этом основной задачей даталогического моделирования является описание свойств понятий предметной области, их взаимосвязь и ограничения, накладываемые на данные. Даталогическая модель является начальным прототипом создаваемой базы данных. Все понятия, выделенные при исследовании предметной области и их взаимосвязи в дальнейшем будут отображены в конкретные структуры какой-либо конкретной базы данных.
Результатом создания даталогической модели является модель, созданная с учетом выбранной модели данных, полученная путем преобразования инфологической модели с учетом определенных правил.
Итак, даталогическая модель отражает структуру БД с учетом особенностей модели данных. Т.к. на сегодняшний день наиболее популярной является реляционная модель данных, рассмотрим правила преобразования инфологической модели в реляционную даталогическую.
Переход к даталогической модели сводится к изменению тех отношений между сущностями, которые существуют только на логическом уровне. Это прежде всего отношения типа многие-ко-многим и иерархия наследования.
Для преобразования отношения типа многие-ко-многим необходимо создать третью сущность, в качестве первичного ключа которой будут выступать ключевые атрибуты сущностей, связанных отношением многие-ко-многим. Имя новой сущности выбирается исходя из ее смыслового значения, а неключевые атрибуты могут мигрировать из одной из связанных сущностей или быть добавлены отдельно.
Например, в случае, изображенном на рис. …, преобразование связи многие-ко-многим, существующей в инфологической модели, приводит к созданию третьей сущности, в которую копируются ключевые атрибуты сущностей «Материал» и «Расход материала».
 
Рис. …. Фрагмент инфологической модели, содержащей связь многие-ко-многим
Между исходными сущностями и связующей устанавливаются идентифицирующие связи «один-ко-многим». Результат операции приведен на рис. ….
На рис. … видно, что в третьей сущности представлена информация, отражающая состав израсходованных материалов. Следовательно, логично будет назвать сущность «Состав расхода материалов», а поскольку необходимо хранение информации о количестве и цене израсходованных материалов, следует ввести в состав сущности «Состав расхода материалов» атрибуты «Количество» и «Цена».
 
Рис. …. Фрагмент даталогической модели, полученной в результате преобразования связи «многие-ко-многим»
В случае использования категориальной связи, преобразование необходимо проводить одним из трех возможных путей:
1. Для каждой сущности иерархии наследования инфологической модели создается соответствующая сущность в даталогической модели. При этом происходит перенос атрибутов сущности ИМД в соответствующую сущность ДМД. Категориальная связь между сущностями заменяется отношением «многие-ко-многим».
2. Все атрибуты сущностей потомков переносятся в состав атрибутов сущности предка. При этом в ДМД включается только сущность предок, содержащая все возможные атрибуты своих потомков.
3. Все атрибуты сущности предка переносятся в состав всех атрибутов сущностей потомков. Связь между сущностями разрывается, а в ДМД включаются независимые друг от друга сущности, получившиеся в результате переноса.
Предположим, в ИМД существует категориальная связь, изображенная на рис.54.
В данном случае видно, что сотрудник может быть как постоянным работником, так и совместителем или консультантом. Различие между ними заключается в типе сотрудника, что отражено на диаграмме с помощью дискриминанта «Тип». Сущности «Постоянный сотрудник», «Совместитель», «Консультант» являются зависимыми от сущности «Сотрудник», поэтому на диаграмме изображены в виде прямоугольников со скругленными углами, а их ключевыми атрибутами являются ключевые атрибуты родительской сущности «Сотрудник».
Для перехода к ДМД необходимо воспользоваться одним из трех перечисленных выше способов.
 
Рис. … Пример категориальной связи инфологической модели данных
Если применить первый способ преобразования, получим результат, изображенный на рис.55. В результате мы получили четыре сущности, связанные отношениями «многие-ко-многим» с сущностью «Сотрудник». Видно, что в данном случае «Постоянный сотрудник» и «Сотрудник» являются полностью идентичными, т.к. «Постоянный сотрудник» не содержит дополнительных атрибутов, отличающих его от «Сотрудника».
 
Рис. … Результат преобразования категориальной связи первым способом
Следовательно, сущность «Постоянный сотрудник» можно удалить. Кроме этого, очевидно, что преобразование подобного рода целесообразно проводить тогда, когда родовые потомки отличаются от своего предка большим количеством признаков.
Если применить второй способ преобразования к модели, изображенной на рис. …, получим результат, изображенный на рис. ….
В данном случае все атрибуты

Copyright MyCorp © 2024