Модели данных

---

6.1. Концепция баз данных

6.1.1. Независимость данных от обработки

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

Что же принято понимать под базой данных? Базу данных в общем случае можно определить как унифицированную совокупность хранимых и воспроизводимых данных, используемых в рамках организации (Engles R.A., 1972 г.). Однако понятие базы данных не основывается в настоящее время на единой концепции, скорее это целое семейство связанных между собой понятий из предметной области, программного и аппаратного обеспечения, анализа и моделирования данных и приложений.

По Дж.Мартину, база данных есть совокупность взаимосвязанных данных, совместно используемых несколькими приложениями и хранящимися с (минимальной) регулируемой избыточностью. Данные запоминаются таким образом, чтобы они, по мере возможности, не зависели от программ. Для обработки данных применяется общий управляющий метод доступа. Если базы данных не пересекаются по структуре, то говорят о системе баз данных.

Согласно материалам комитета КОДАСИЛ, база данных состоит из всех экземпляров записей, экземпляров наборов записей и областей, которые контролируются конкретной схемой. (Под схемой можно понимать карту всей логической структуры базы данных).

Для разработчика ИС существенным моментом при использовании концепции баз данных является то обстоятельство, что данные становятся определенным образом организованы, приобретают некую упорядоченность и внутреннюю структуру, а также то, что имеется некоторый набор унифицированных операций обработки данных и декларативных средств представления данных. К таким операциям следует отнести операции "Вставить" (Insert), "Добавить" (Add), "Удалить" (Delete) и ряд других. К декларативным средствам представления данных следует отнести языки определения данных. То есть использование данной концепции при создании ИС предполагает наличие языка определения данных и языка манипулирования данными, а также правил построения интерфейсов программ (приложений) с БД и пользователем.

Такое деление средств манипулирования данными и их представления является в определенной степени условным. Язык определения данных служит для описания логической структуры (схемы) БД, а в некоторых случаях и способов хранения и доступа к данным. Язык манипулирования данными предоставляет алгоритмические средства построения приложений для обработки сохраняемых в БД элементов данных.

6.1.2. Системы управления базами данных

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

На рис. 6.1 представлены основные функции СУБД.

Рис. 6.1 -  Основные функции СУБД

Системой управления базами данных (Data-base Management System) называется совокупность программных средств, необходимых для использования базы данных и предоставляющих разработчикам и пользователям множество различных представлений данных.

6.1.3. Понятие о модели данных

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

- Модель данных ограничивает возможность выбора СУБД, так как обычно отдельно взятая СУБД поддерживает определенную модель данных;

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

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

Таким образом, понятие модели данных является одним из фундаментальных понятий информатики, от которого во многом зависят механизмы реализации ИС как программно-аппаратного комплекса.

В самом общем случае модель данных – это логическое представление данных и совокупность операций над ними.

Модель данных (Data Model) есть логическая структура данных, которая представляет присущие этим данным свойства, не зависимые от аппаратного и программного обеспечения и не связанные с функционированием компьютера.

Можно рассмотреть несколько аспектов моделирования в обработке данных:

- информационное моделирование:

а) концептуальное моделирование (моделирование семантики предметной области);

б) логическое моделирование данных;

- физическое моделирование:

а) создание моделей доступа к данным;

б) оптимизация физической организации данных в аппаратной среде.

Физическая модель определяется особенностями устройств хранения информации и связи.

6.1.4. Концепция трех схем

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

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

Исследовательская группа по СУБД ANSI/X3/SPARC пришла к выводу, что для создания идеальной среды управления данными необходимо определение их с третьей, промежуточной точки зрения (концепция трех схем ANSI/X3/SPARC). Эта точка зрения (называемая концептуальной схемой) сводится к единообразному определению данных в рамках предметной области, не ориентированному на какое-либо конкретное использование их и не зависящему от того, как данные физически обрабатываются на компьютере (рис. 6.2).

Рис. 6.2 -  Концепция трех схем

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

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

6.1.5. Семантические модели данных

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

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

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

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

6.1.6.Ограниченность реляционной модели при проектировании баз данных

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

При использовании в проектировании ограниченность реляционной модели проявляется в следующих аспектах.

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

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

Хотя весь процесс проектирования происходит на основе учета зависимостей, реляционная модель не предоставляет какие-либо формализованные средства для представления этих зависимостей.

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

6.1.7. Общие принципы классификации СУБД

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

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

- документальные, которые ориентированы на хранение документов;

- документально-фактографические, которые обладают чертами и тех и других.

Так, СУБД CDS/ISIS в первую очередь ориентирована на поддержку работы с документом, который состоит из определенного числа рубрик, проиндексированных по тезаурусу ключевых слов. СУБД ADABAS хорошо подходит для организации фактографических БД, а СУБД ORACLE – для БД смешанного типа. Во избежание несуразностей с использованием определенной модели данных, БД, за редким исключением, целесообразно классифицировать по типу используемой модели в СУБД. Отметим, что классификация БД далеко не завершенная область исследований: попытки ввести новые типы БД продолжаются (активные, дедуктивные, нечеткие реляционные, графические БД и т.д.).

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

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

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

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

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

- на ЭВМ разной архитектуры с установленными на них различными операционными системами;

- в компьютерных сетях разных типов, работающих по различным протоколам;

- с различными графическими и символьными системами представления информации.

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

- поддержка логической модели данных (определение данных, оперирование данными);

- восстановление данных (транзакции, журнализация, контрольные точки);

- управление одновременным доступом;

- безопасность данных (права доступа);

- самостоятельная оптимизация выполнения операций;

- другие функции (администрирование, статистика, распределение данных и т.д.).

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

6.1.8. Основные задачи и этапы проектирования баз данных

Проектирование баз данных – процесс решения класса задач, связанных с созданием баз данных.

6.1.8.1. Основные задачи:

- обеспечение хранения в БД всей необходимой информации;

- обеспечение возможности получения данных по всем необходимым запросам;

- сокращение избыточности и дублирования данных;

- обеспечение целостности данных (правильности их содержания): исключение противоречий в содержании данных, исключение их потери и т.д.

6.1.8.2.Основные этапы проектирования баз данных

Концептуальное (инфологическое) проектирование – построение формализованной модели предметной области. Такая модель строится с использованием стандартных языковых средств, обычно графических, например ER-диаграмм. Модель строится без ориентации на какую-либо конкретную СУБД.

Основные элементы данной модели:

- описание объектов предметной области и связей между ними;

- описание информационных потребностей пользователей (описание основных запросов к БД);

- описание алгоритмических зависимостей между данными;

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

На этапе инфологического проектирования в ходе сбора информации о предметной области требуется выяснить:

- основные объекты предметной области (объекты, о которых должна храниться информация в БД);

- атрибуты объектов;

- связи между объектами;

- основные запросы к БД.

Логическое (даталогическое) проектирование – отображение инфологической модели на модель данных, используемую в конкретной СУБД, например на реляционную модель данных. Для реляционных СУБД даталогическая модель – набор таблиц, обычно с указанием ключевых полей, связей между таблицами. Если инфологическая модель построена в виде ER-диаграмм (или других формализованных средств), то даталогическое проектирование представляет собой построение таблиц по определённым формализованным правилам, а также нормализацию этих таблиц. Этот этап может быть в значительной степени автоматизирован.

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

Нормализация. Нормализованные отношения (таблицы) обладают лучшими свойствами для хранения и обновления данных. Сначала БД проверяется на первую нормальную форму (1НФ), затем на вторую (2НФ), 3-ю (3НФ), нормальную форму Бойса-Кодда (НФБКД), чётвертую (4НФ) и др. Если таблица не соответствует какой-либо нормальной форме, то выполняется её приведение к нормальной форме путём вертикального разбиения (проекция) на две или более таблиц.

6.2. Концептуальные модели предметной области

Концептуальная модель предметной области ИС описывает организацию всех данных ИС (независимо от места их расположения) на уровне понятий предметной области. Иначе такую модель называют семантической.

6.2.1. ER-модель в нотации Чена

Рассмотрим семантическую модель Entity-Relationship (Сущность-Связь). Эта модель – одна из наиболее популярных.

Модель Сущность-Связь (ER-модель) (англ. entity-relationship model (ERM) или англ. entity-relationship diagram (ERD)) — модель данных, позволяющая описывать концептуальные схемы. Предоставляет собой графическую нотацию, основанную на блоках и соединяющих их линиях, с помощью которых можно описывать объекты и отношения между ними какой-либо другой модели данных. В этом смысле ER-модель является мета-моделью данных, то есть средством описания моделей данных.

ER-модель удобна при прототипировании (проектировании) информационных систем, баз данных, архитектур компьютерных приложений, и других систем (далее, моделей). С её помощью можно выделить ключевые сущности, присутствующие в модели, и обозначить отношения, которые могут устанавливаться между этими сущностями.

ER-модель является одной из самых простых визуальных моделей данных (графических нотаций). Она позволяет обозначить структуру «крупными мазками», в общих чертах. Это общее описание структуры называется ER-диаграммой или онтологией выбранной предметной области (area of interest).

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

На основе ER-диаграммы можно построить логическую модель данных (например, в нотации IDEF1X) и далее более детальную физическую модель данных.

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

На использовании разных вариантов ER-модели основано большинство современных подходов к проектированию баз данных (главным образом, реляционных). Модель была предложена Питером Ченом (Peter Chen) в 1976 г. Моделирование предметной области базируется на использовании графических диаграмм, включающих небольшое число разнородных компонентов. Простота и наглядность представления концептуальных схем баз данных в ER-модели привели к ее широкому распространению в CASE-системах, поддерживающих автоматизированное проектирование реляционных баз данных.

Следует заметить, что в настоящее время разработано несколько различных графических методов представления диаграмм в модели «сущность – связь». Среди множества нотаций ER-моделей одна из наиболее развитых – Unified Modeling Language (Унифицированный язык моделирования), сокр. UML – применяется в CASE-средствах фирмы ORACLE.

Ниже рассмотрим один из возможных подходов, в основе которого лежат диаграммы Чена.

6.2.2. Основные понятия ER-модели

Модель «сущность – связь» (или ER-модель) представляет собой способ логического унифицированного представления данных некоторой предметной области. Хотя эта модель очень напоминает систему связанных друг с другом таблиц, в действительности это совершенно общее представление. Эта модель может быть преобразована к любой из существующих конкретных моделей данных: иерархической, сетевой, реляционной, объектной. Существенно, что ER-модель позволяет представлять только данные, но не действия, которые с ними могут производиться, поэтому она используется лишь для проектирования структуры хранимых данных.

Достоинствами данной модели являются:

- простота;

- наглядность;

- однозначность;

- использование естественного языка.

6.2.2.1. Понятие сущности. Типы сущностей

Сущность – это собирательное понятие, некоторая абстракция реально существующего объекта, процесса, явления или некоторого представления об объекте, информацию о котором требуется хранить в базе данных.

Необходимо различать такие понятия, как тип сущности и экземпляр сущности. Понятие тип сущности относится к набору однородных личностей, предметов, событий или идей, выступающих как целое. Экземпляр сущности относится к конкретной вещи в наборе. Например, типом сущности может быть ГОРОД, а экземпляром – Москва, Киев и т.д. Предполагается, что гарантировано отличие экземпляров одного типа сущности друг от друга. Данное требование вполне аналогично требованию отсутствия в таблице тождественных строк. В дальнейшем, однако, там, где это не может вызвать неоднозначного прочтения, мы не будем различать типы и экземпляры, а будем просто использовать термин «сущность». Принято выражать (именовать) сущность существительным или существительным с характеризующим его прилагательным (ТОВАР, ЗАКАЗ, КАТАЛОГ и др.).

В диаграммах ER-модели сущность представляется в виде прямоугольника, содержащего имя сущности. При этом имя сущности — это имя типа, а не некоторого конкретного экземпляра этого типа. (Хотя было бы правильнее всегда использовать термины тип сущности и экземпляр типа сущности, для избежания многословности (и, следуя традиции) в тех случаях, где это не приводит к двусмысленности, будем использовать термин сущность в значении типа сущности.)

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

6.2.2.2. Стержневая сущность

Стержневая (сильная) сущность – не зависящая от других сущность. Стержневая сущность не может быть ассоциацией, характеристикой или обозначением (см. ниже).

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

К слабым сущностям относятся ассоциации и характеристики.

6.2.2.3. Ассоциация

Ассоциативная сущность (или ассоциация) выражает собой связь «многие ко многим» между двумя сущностями. Является вполне самостоятельной сущностью. Например, между сущностями ТОВАР и КЛИЕНТ существует ассоциативная связь, выражаемая ассоциативной сущностью ЗАКАЗАННЫЙ _ТОВАР.

6.2.2.4. Характеристика

Характеристическую сущность еще называют слабой сущностью. Она связана с более сильной сущностью связями «один ко многим» и «один к одному». Характеристическая сущность описывает или уточняет другую сущность. Она полностью зависит от нее и исчезает с исчезновением последней. Например, сущность ЗАРПЛАТА является характеристикой конкретных работников предприятия и не может в таком контексте существовать самостоятельно – при удалении экземпляра сущности РАБОТНИК должны быть удалены и экземпляры сущности ЗАРПЛАТА, связанные с удаляемым работником.

6.2.2.5. Обозначение

Обозначение это такая сущность, с которой другие сущности связаны по принципу «многие к одному» или «один к одному». Обозначение, в отличие характеристики, является самостоятельной сущностью. Например, сущность ФАКУЛЬТЕТ обозначает принадлежность студента к данному подразделению института, но является вполне самостоятельной.

Любой фрагмент предметной области может быть представлен некоторым набором сущностей и связями между ними. Например, рассматривая предметную область ФАКУЛЬТЕТ можно выделить следующие основные сущности: СТУДЕНТ, КАФЕДРА, СПЕЦИАЛЬНОСТЬ, ДЕКАНАТ, ГРУППА, ПРЕПОДАВАТЕЛЬ, ЭКЗАМЕН. На первом этапе создания ER-модели данных следует выделить все сущности, которые предполагается описывать исходя из постановки задачи. Сущностью может быть не только некоторый материальный объект, но и некоторый процесс, например ЭКЗАМЕН, ЛЕКЦИЯ. Сущностью может быть и некоторая количественная и качественные характеристики объекта: УЧЕНОЕ ЗВАНИЕ, СТАЖ и др. Все в действительности зависит от постановки задачи и от нашего анализа предметной области.

6.2.2.6. Атрибут сущности

Атрибут сущности – свойство, характеризующее объект. Все атрибуты сущности должны иметь различные названия и обладать различным смыслом (трактовкой). Атрибут должен иметь только одно значение. Для хранения значения «20 кГ» следует завести два атрибута – ЕДИНИЦА_ИЗМЕРЕНИЯ и КОЛИЧЕСТВО.

6.2.2.7. Ключ

Ключ является уникальным идентификатором экземпляров сущности.

При определении типа сущности необходимо гарантировать, что каждый экземпляр сущности является отличимым от любого другого экземпляра той же сущности. Поскольку сущность является абстракцией реального или представляемого объекта внешнего мира, это требование нужно иметь в виду уже при выборе кандидата в типы сущности. Например, предположим, что проектируется база данных для поддержки работы книжного склада. На складе могут храниться произвольные части тиража любого издания любой книги. Может ли в этом случае индивидуальная книга являться прообразом типа сущности? Утверждается, что нет, поскольку отсутствует возможность различения книг одного издания. Для книжного склада прообразом типа сущности будет набор одноименных книг одного автора, вышедших в одном издании. Одним из атрибутов этого типа сущности будет число книг в наборе. Но когда книга поступает в библиотеку и ей присваивается уникальный библиотечный номер, она становится разумным прообразом типа сущности. Плохо устроены библиотеки, в которых не различаются индивидуальные книги (даже одноименные книги одного автора, вышедшие в одном издании).

Но при проектировании базы данных мало того, чтобы проектировщик убедился в правильном выборе типов сущности, гарантирующем различие экземпляров каждого типа сущности. Необходимо сообщить системе автоматизации проектирования БД, каким образом будут различаться эти экземпляры, т.е. сообщить, как конструируются уникальные идентификаторы  экземпляров каждого типа сущности. В ER-модели у экземпляра типа сущности не может быть назначаемого пользователем имени или назначаемого системой внешнего уникального идентификатора. Экземпляр типа сущности может идентифицироваться только своими индивидуальными характеристиками, а они представляются значениями атрибутов и экземплярами типов связи, связывающими данный экземпляр типа сущности с экземплярами других типов сущности или этого же типа сущности. Поэтому уникальным идентификатором сущности может быть атрибут, комбинация атрибутов, связь, комбинация связей или комбинация связей и атрибутов, уникально отличающая любой экземпляр сущности от других экземпляров сущности того же типа.

6.2.2.8. Связь

В ER-модели для представления схемы базы данных используются два равноправных понятия — сущность и связь.

Связь — это графически изображаемая ассоциация, устанавливаемая между двумя типами сущностей. Как и сущность, связь — это типовое понятие, все экземпляры обоих связываемых типов сущностей подчиняются устанавливаемым правилам связывания. Поэтому правильнее говорить о типе связи, устанавливаемой между типами сущности, и об экземплярах типа связи, устанавливаемых между экземплярами типа сущности. (Тем не менее, как и в случае типа сущности, мы будем часто использовать термин связь в значении типа связи) В рассматриваемом варианте ER-модели эта ассоциация всегда является бинарной и может существовать между двумя разными типами сущностей или между типом сущности и им же самим (рекурсивная связь). В любой связи выделяются два конца (в соответствии с существующей парой связываемых сущностей), на каждом из которых указываются имя конца связи, степень конца связи (сколько экземпляров данного типа сущности должно присутствовать в каждом экземпляре данного типа связи), обязательность связи (т.е. любой ли экземпляр данного типа сущности должен участвовать в некотором экземпляре данного типа связи).

В некоторых вариантах ER-модели конец связи называют ролью связи в данной сущности. Тогда можно говорить об имени роли, степени роли и обязательности роли связи в данной сущности.

Связь представляется в виде направленной или ненаправленной линии, соединяющей две сущности или ведущей от сущности к ней же самой.

Обязательный конец связи изображается сплошной линией, а необязательный — прерывистой линией.

Отметим, что связи в ER-модели играют роль, отличную от той, какую играют отношения в реляционной модели данных. В реляционной модели отношение (relation) — это единственная родовая структура данных. С помощью этого же механизма представляются «связанные» сущности (вспомните, например, про внешние ключи).

6.2.3. Нотация Чена для изображения ER-диаграмм

Множества сущностей изображаются в виде прямоугольников, множества отношений изображаются в виде ромбов. Если сущность участвует в отношении, они связаны линией. Если отношение не является обязательным, то линия пунктирная. Атрибуты изображаются в виде овалов и связываются линией с одним отношением или с одной сущностью.

Таблица 6.1 – Элементы нотации Чена для изображения ER-диаграмм

Изображение	Комментарий
	Так на диаграмме изображается сильная (стержневая) сущность
	Так на диаграмме изображается сущность, отличная от сильной сущности, без уточнения ее типа (ассоциация, характеристика, обозначение).
	Атрибут сущности. Вместо имени атрибута можно указать многоточие «…», что будет обозначать группу атрибутов.
	Атрибут сущности, являющийся первичным ключом
	Обозначает связь между двумя сущностями
	Ассоциативная сущность (связь «многие ко многим»)
	Обозначение сущности вида «характеристика»
	Показывает сущность вида «обозначение»
	Прямая линия указывает на связь между сущностями, либо соединяет сущность и атрибут. Линия со стрелкой указывает направленную связь.

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

Сущность и ее атрибуты соединяются ненаправленными дугами (рисунок 6.3).

Рис. 6.3 – Связь сущности и атрибутов, включая первичный ключ

Связи между сущностями могут быть 3-х типов:

Один – к одному. Этот тип связи означает, что каждому объекту первого вида соответствует не более одного объекта второго вида, и наоборот. Например: сотрудник может руководить только одним отделом, и у каждого отдела есть только один руководитель.

Один – ко многим. Этот тип связи означает, что каждому объекту первого вида может соответствовать более одного объекта второго вида, но каждому объекту второго вида соответствует не более одного объекта первого вида. Например: в каждом отделе может быть множество сотрудников, но каждый сотрудник работает только в одном отделе.
Многие – ко многим. Этот тип связи означает, что каждому объекту первого вида может соответствовать более одного объекта второго вида, и наоборот. Например: каждый счет может включать множество товаров, и каждый товар может входить в разные счета.

Ромб связи и прямоугольник сущности соединяются ненаправленными дугами в сторону "ко многим" и направленными в сторону "к одному" (рисунок 6.4).

Рис. 6.4 – Связь сущностей «один-ко-многим»

Связь может соединять сущность саму с собой, например (рисунок 6.5):

Рис. 6.5 – Связь сущностей самих с собой (рекурсивная)

Если связь соединяет две сущности, она называется бинарной. Связь может соединять более двух сущностей, например, связь, соединяющая три сущности, называется тернарной (рис. 6.6). Обратите внимание, что здесь «Заказ» – не сущность, а связь, как равноправный с сущностями элемент модели. Далее на уровне логических и, тем более, физических моделей реляционных БД «Заказ» превратится в реляционную таблицу.

Рис. 6.6 – Тернарная связь сущностей

На схеме слабые сущности обозначаются двойными линиями (рисунок 6.7).

Рис. 6.7 – Слабая сущность «Сотрудник» связана связью

«Работает» с сильной сущностью «Отдел»

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

Рис. 6.8 – Связи супертип-подтип между сущностями «Контрагент» и «Физ. лицо», «Юр. лицо»

Сущность "Контрагент" является надтипом (родительской категорией) для своих подтипов.

6.3. Логические модели данных

6.3.1. Получение реляционной схемы из ER-модели

Итак, ER-диаграммы построены. Следующий этап проектирования – перенести диаграммы на язык таблиц конкретной СУБД. Можно сказать, что ER-диаграммы порождают реляционную базу данных. Процесс порождения можно легко формализовать, довести до автоматизма. Прежде всего, заметим, что почти всегда есть взаимнооднозначное соответствие между сущностью ER-модели и таблицей. При этом атрибуты сущности переходят в атрибуты (колонки, столбцы) таблицы, а первичный ключ сущности переходит в первичный ключ таблицы. В таблице 6.2 представлены правила соответствия бинарных связей сущностей и соответствующих элементов реляционной базы данных.

Таблица 6.2 – Правила соответствия

Тип бинарной связи	Элементы реляционной базы данных
Связь «один к одному», характеристики (0,1) – (1,1) (1,1) – (0,1)	Для каждой сущности строится своя таблица. Связь между таблицами «один к одному».
Связь «один к одному», характеристики (1,1) – (1,1)	Строится одна таблица, структура которой состоит из атрибутов обеих сущностей. В качестве первичного ключа берется ключ одной из сущностей.
Связь «один к одному», характеристики (0,1) – (0,1)	При построении связи на основе двух таблиц мы вынуждены допустить, что значение внешнего ключа может быть равно NULL. Если исключить эту возможность, то такую связь следует строить на основе трех таблиц. Одна таблица является таблицей – посредником. Она содержит первичные ключи двух других таблиц.
Связь «один ко многим», характеристики (0,1) – (1,N) (1,1) – (1,N)	Каждой сущности ставится в соответствие таблица. Связи между таблицами имеет тип «один ко многим» и строится на основе первичного ключа первой таблицы.
Связь «один ко многим», характеристики (0,1) – (0,N) (1,1) – (0,N)	Обычно такой тип связи строится на основе трех таблиц (пар. 2, Один ко многим). Таблица посредник содержит внешний ключ, соответствующий первичному ключу первой таблицы и внешний ключ, соответствующий первичному ключу второй таблицы.
Связь «многие ко многим», характеристики (0,N) – (0,N) (1,N) – (1,N) (1,N) – (0,N) (0,N) – (1,N)	Любая связь такого типа строится на основе трех таблиц (см. пар. 2, Многие ко многим).

Правила порождения позволят легко перейти от ER-модели данных к логической и физической реляционным моделям.

Алгоритм перехода приведен ниже.

Шаг 1. Каждая простая сущность превращается в таблицу. Простая сущность – сущность, не являющаяся подтипом и не имеющая подтипов. Имя сущности становится именем таблицы.

Шаг 2. Каждый атрибут становится возможным столбцом с тем же именем; может выбираться более точный формат. Столбцы, соответствующие необязательным атрибутам, могут содержать неопределенные значения; столбцы, соответствующие обязательным атрибутам, – не могут.

Шаг 3. Компоненты уникального идентификатора сущности превращаются в первичный ключ таблицы. Если имеется несколько возможных уникальных идентификатора, выбирается наиболее используемый. Если в состав уникального идентификатора входят связи, к числу столбцов первичного ключа добавляется копия уникального идентификатора сущности, находящейся на дальнем конце связи (этот процесс может продолжаться рекурсивно). Для именования этих столбцов используются имена концов связей и/или имена сущностей.

Шаг 4. Связи многие-к-одному (и один-к-одному) становятся внешними ключами. Т.е. делается копия уникального идентификатора с конца связи "один", и соответствующие столбцы составляют внешний ключ. Необязательные связи соответствуют столбцам, допускающим неопределенные значения; обязательные связи – столбцам, не допускающим неопределенные значения.

Шаг 5. Индексы создаются для первичного ключа (уникальный индекс), внешних ключей и тех атрибутов, на которых предполагается в основном базировать запросы.

Шаг 6. Если в концептуальной схеме присутствовали подтипы, то возможны два способа:

а) все подтипы в одной таблице;

б) для каждого подтипа – отдельная таблица.

При применении способа (а) таблица создается для наиболее внешнего супертипа, а для подтипов могут создаваться представления. В таблицу добавляется по крайней мере один столбец, содержащий код ТИПА; он становится частью первичного ключа.

При использовании метода (б) для каждого подтипа первого уровня (для более нижних – представления) супертип воссоздается с помощью представления UNION (из всех таблиц подтипов выбираются общие столбцы – столбцы супертипа).

Таблица 6.3 – Способы хранения подтипов

Все в одной таблице	Отдельная таблица – на подтип
Преимущества
Все хранится вместе Легкий доступ к супертипу и подтипам Требуется меньше таблиц	Более ясны правила подтипов Программы работают только с нужными таблицами
Недостатки
Слишком общее решение Требуется дополнительная логика работы с разными наборами столбцов и разными ограничениями Потенциальное узкое место (в связи с блокировками) Столбцы подтипов должны быть необязательными В некоторых СУБД для хранения неопределенных значений требуется дополнительная память	Слишком много таблиц Смущающие столбцы в представлении UNION Потенциальная потеря производительности при работе через UNION Над супертипом невозможны модификации

Шаг 7. Имеется два способа работы при наличии исключающих связей:

а) общий домен;

б) явные внешние ключи.

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

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

Таблица 6.4 – Способы реализации исключающих связей

Общий домен	Явные внешние ключи
Преимущества
Нужно только два столбца	Условия соединения – явные
Недостатки
Оба дополнительных атрибута должны использоваться в соединениях	Слишком много столбцов

Альтернативные модели сущностей показаны на рисунках 6.19-6.21.

Рис. 6.19 – Вариант 1 (плохой)

Рис. 6.9 – Вариант 2 (существенно лучше, если подтипы действительно существуют)

Рис. 6.10 – Вариант 3 (применим при наличии осмысленного

супертипа D).

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

6.3.2. Построение логических реляционных моделей данных в стандарте IDEF1X

IDEF1X является методом для разработки реляционных баз данных и использует условный синтаксис, специально разработанный для удобного построения концептуальной схемы Основным преимуществом IDEF1X, по сравнению с другими многочисленными методами разработки реляционных баз данных, такими как ER и ENALIM является жесткая и строгая стандартизация моделирования. Установленные стандарты позволяют избежать различной трактовки построенной модели, которая несомненно является значительным недостатком ER-моделей.

Стандарт IDEF1X поддерживается, в частности, популярным программным средством AllFusion ERwin Data Modeler (ранее: ERwin), которое позволяет проектировать, документировать и сопровождать базы данных, хранилища данных и витрины данных (data marts). Создав наглядную модель базы данных, вы сможете оптимизировать структуру БД и добиться её полного соответствия требованиям и задачам организации. Визуальное моделирование повышает качество создаваемой базы данных, продуктивность и скорость её разработки. AllFusion ERwin Data Modeler (далее для краткости называемый ERwin) нужен компаниям, разрабатывающим и использующим базы данных, администраторам баз данных, системным аналитикам, проектировщикам БД, разработчикам, руководителям проектов:

- поддерживает прямое (создание БД на основе модели) и обратное (генерация модели по имеющейся базе данных) проектирование для 20 типов СУБД;

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

- поддерживает методологию структурного моделирования SADT и следующие нотации: IDEF1х, IE, Dimensional (последняя – для проектирования хранилищ данных);

- ERwin является стандартом де-факто;

- поддерживает 20 различных СУБД: настольные, реляционные и специализированные СУБД, предназначенные для создания хранилищ данных;

- интегрирован линейкой продуктов Computer Associates для поддержки всех стадий разработки ИС, CASE-средствами Oracle Designer, Rational Rose, средствами разработки и др.;

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

- возможна совместная работа группы проектировщиков с одними и теми же моделями (с помощью AllFusion Model Manager).

- позволяет переносить структуру БД (не сами данные!) из СУБД одного типа СУБД в другой;

- позволяет документировать структуру БД;

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

Для разработчиков ПО:

- позволяет получить точную и наглядную информацию, где хранятся данные и как получить к ним доступ.

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

Для администраторов баз данных:

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

- уменьшит число рутинных операций, облегчит и сократит работу.

Для руководителей:

- повышает гибкость и эффективность организации за счёт возможности быстрой адаптации базы данных к меняющимся потребностям рынка.

- использование профессиональных средств – фактор конкурентной борьбы.

Для руководителей проектов:

- ERwin поможет тщательно задокументировать структуру БД;

- позволит получить отчеты презентационного качества;

- через AllFusion Model Manager возможно эффективное управление ходом проектирования.

Для системных интеграторов:

- поддержка различных типов СУБД;

- поможет подстроиться под изменяющиеся требования заказчика.

6.3.3. Создание логической реляционной модели данных в ERWin

В ERWin используются две основных нотации создания моделей – IDEF1X (армия США и госучреждения, финансовые и промышленные кор­по­ра­ции), IE (промышленность).

Переключение между нотациями: Option / Preferences / Methodology

ERwin имеет несколько уровней отображения диаграммы:

- уровень сущностей

- уровень атрибутов

- уровень определений

- уровень первичных ключей

- уровень иконок

Переключение – через контекстное меню (ПЩ на свободном месте, пункт Display Level) или через кнопки палитры инструментов (первые 3 уровня)

Таблица 6.5 – Уровни отображения модели

Уровень отображения	Представление модели
Сушность (Entity)	Деталь
Атрибуты (Attribute)	Сотрудник
Первичный ключ (Primary Key)	Деталь Номер детали
Определение (Definition)	Деталь
Сущности с изображением иконок	$ счет

6.3.3.1. Ключи

Каждая сущность должна иметь, по крайней мере, один потенциальный ключ (поле или набор полей с уникальными значениями)

Первичный ключ (Primary key) – определяет экземпляр сущности уникальным образом.

Альтернативный ключ (Alternate Key) – потенциальный ключ, не ставший первичным. При генерации схемы БД по всем атрибутам альтернативного ключа генерируется уникальный индекс.

Можно вводить неуникальные индексы (допускаются совпадения). Атрибуты, участвующие в неуникальных индексах, называются инверсионные входы (Inversion Entries). Они не определяет экземпляр сущности уникальным образом, но используются для частого обращения к экземплярам сущности.

6.3.3.2. Домены

Домен – совокупность значений, из которых берутся значения атрибутов. Каждый атрибут может быть определен только на одном домене. На каждом домене может быть определено множество атрибутов.

Домен имеет уникальное имя и может использоваться как на логическом, так и на физическом уровне.

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

Пример: Домен "Возраст"

Логический уровень – атрибуты получат тип Number.

Физический уровень – колонкам будет присвоен тип INTEGER.

Редактирование доменов – команда Edit/Domain Dictionary.

6.3.3.3. Задание атрибутов модели

Создание новых атрибутов в модели – диалог Attribute Editor (рис. 6.11)

Рис. 6.11 –Создание атрибутов и задание их свойств

Здесь вкладки:

General – общие свойства атрибута;

Definition – описание атрибута;

Note примечание к атрибуту;

UDP – свойства, заданные пользователем.

Cвойства атрибута:

Primary Key – атрибут является первичным ключом;

Logical Only – определяет атрибут и домен только на уровне физической модели;

Requied – обязательный атрибут, требующий задания значения (свойство автоматически проставляется для первичных ключей).

6.3.3.4. Задание связей

В ERWin можно задавать идентифицирующие и неидентифицирующие связи.

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

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

Варианты реализации связей в логической модели показаны на рисунке 6.12-6.14. При задании связи ключ из главной (в примере из стержневой) таблицы мигрирует в зависимую (характеристическую) таблицу.

Рис. 6.12 – Идентифицирующая связь типа один-ко-многим между сущностями «Отдел» и «Сотрудник», ключи мигрируют

в состав ключевых полей

Рис. 6.13 – Неидентифицирующая связь типа один-ко-многим между

сущностями «Отдел» и «Сотрудник», ключи мигрируют в

состав описательных полей. Внешний ключ может

содержать значение NULL (связь необязательная)

Рис. 6.14 – Неидентифицирующая связь типа один-ко-многим между

сущностями «Отдел» и «Сотрудник», ключи мигрируют в

состав описательных полей. Внешний ключ имеет значение

NOT NULL (связь обязательная)

6.3.3.5. Связь многие-ко-многим

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

Рис. 6.15 – Связь типа многие-ко-многим в логической модели между

сущностями «Товар» и «Клиент», ключи не мигрируют

На уровне физической модели связь многие-ко-многим может быть обозначена (рис. 6.26), но реализуется она в виде промежуточной таблицы (рис. 6.27). В промежуточной таблице Товар_Клиент (такое название по умолчанию) можно хранить сведения о том, кто из клиентов какой из товаров заказывал.

Рис. 6.16 – Обозначение связь типа многие-ко-многим в физической

модели данных

Рис. 6.17 – Реализация связи типа многие-ко-многим в физической

модели данных в виде ассоциативной (в частности,

именующей) таблицы Товар_Клиент

Естественно, таблицу Товар_Клиент можно сразу ввести на уровне логической модели данных.

6.3.3.6. Типы сущностей и иерархия наследования

Связи определяют, является ли сущность независимой или зависимой. Зависимые сущности:

Характеристическая – зависимая дочерняя сущность, которая связана только с одной родительской и по смыслу хранит информацию о характеристиках родительской сущности.

Пример. Сущность Сотрудник имеет характеристику – Увлечения.

Ассоциативная – сущность, связанная с несколькими родительскими сущностями. Такая сущность содержит информацию о связях сущностей.

Пример. Таблица связи "Товар-Клиент" на рис 6.17. при дополнении ее атрибутами, например, Количество и Дата_Заказа.

Именующая – частный случай ассоциативной сущности, не имеющей собственных атрибутов (только атрибуты родительских сущностей, мигрирующих в качестве внешнего ключа)

Пример. Таблица связи "Товар-Клиент" на рис 6.17 только с внешними ключами.

Категориальная – дочерняя сущность в иерархии наследования.

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

В полной категории каждому экземпляру родового предка обязательно соответствует экземпляр в каком-либо потомке, т.е. каждый служащий обязательно является либо совместителем, либо консультантом, либо постоянным сотрудником.

В IDEF1X выделяют два типа иерархии категории (наследования): полная и неполная.

Полная категория означает, что отображены все возможные варианты сущностей-потомков.

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

Возможна также комбинация полной и неполной категорий.

Создание категориальной связи:

- установить курсор на кнопке категории в палитре инструментов выбрать категорию левой кнопкой мыши;

- щелкнуть сначала по родовому предку, потом – по потомку;

- для установления второй связи в иерархии категорий сначала щелкнуть по символу категории, потом по второму потомку.

Редактирование категории – щелкнуть правой кнопкой мыши по символу категории. В контекстном меню – пункт Subtype Relationship Editor. Указать дискриминатор категории (Discriminator Attribute Choice) (например – атрибут Тип в родовом предке) и тип категории – полная/неполная (Complete/Incomplete).

Стадии построения иерархии наследования:

а) Определение сущностей с общими (по определению) атрибутами

Пример 1: Постоянный сотрудник и Совместитель

Пример 2: Транзисторы низкочастотные, транзисторы высокочастотные

б) Перенос общих атрибутов в сущность – родовой предок

Пример 1: Постоянный сотрудник и Совместитель – > Сотрудник

Пример 2: Транзисторы низкочастотные, транзисторы высокочастотные -> транзистор

в) Создание неполной структуры категорий

Создается категориальная связь от новой сущности – родового предка – к старым сущностям – потомкам. Новая сущность дополняется атрибутом-дискриминатором категории – тип.

г) Создание полной структуры категорий

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

Пример 1: консультант

Пример 2: транзисторы сверхвысокочастотные.

д) Комбинация полной и неполной структур категорий

При необходимости создание иерархии категорий можно продолжить.

6.3.3.7. Пример создания модели

Схема данных информационной системы предприятия по изготовлению корпусной мебели включает в себя совокупность связанных таблиц, хранящих информацию о заказах, моделях, клиентах и др. Модель данных проектируемой системы разрабатывается с учетом предъявляемых к ней функциональных требований и состоит из следующих сущностей:

«Клиент», «Модели», «Заказ», «Позиции заказа», «Трудоемкость работ», «Материал», «Применяемый материал», «Тип материала», «Поставщик», «Скидки», «Сотрудники», «Должность».

Рассмотрим основные сущности системы подробнее.

Система должна обеспечивать регистрацию клиентов. Для этого создана таблица «Клиент», в которой указывается необходимая для регистрации информация (Наименование, Адрес, Телефон). Кроме того, в данную таблицу внесено поле, обозначающее статус клиента. Каждый клиент может иметь статус постоянного клиента, новичка, оптовика. Постоянным клиентам или оптовикам (заказывающим одновременно много однотипной мебели) могут быть предусмотрены определенные скидки. Информация о размерах скидки хранится в отдельной таблице «Скидки».

Основной функцией системы является обеспечение учета заказов. Для этого создана таблица «Заказ» и связанная с ней таблица «Позиции заказа». В таблице «Заказ» хранятся сведения о дате принятия заказа, дате исполнения, коде заказа (который одновременно является номером договора). В таблице «Позиции заказа» хранятся сведения о выбранных клиентом моделях мебели и их количестве.

Сущность «Заказ» используется для идентификации конкретного договора (заказа). Например, при неоднократном обращении клиента в фирму нет смысла хранить множество одинаковых записей о его наименовании или адресе.

Мебельному предприятию необходимо расширять свою деятельность и искать новые дизайнерские идеи. Для этого создана сущность «Модели», представляющая собой, по сути, электронный каталог мебели. В сущности «Материал» имеется поле «КодПоставщика», указывающее продавца конкретного материала. Необходимая информация о поставщиках хранится в отдельной таблице «Поставщик», связанной с таблицей «Материал» связью «один-ко-многим» (у одного поставщика может быть куплено много позиций материалов). В таблице «Поставщик» хранятся координаты поставщиков.

Схема данных информационной системы предприятия по изготовлению корпусной мебели включает в себя совокупность связанных таблиц (сущностей в логической представлении). Эти объекты перечислены в таблице 6.11.

Таблица 6.11 – Основные свойства и назначение таблиц (сущностей)

информационной системы предприятия

по изготовлению мебели

Название таблицы	Назначение	Основные хранимые данные
Заказ	Сведения о заказах	Код заказа, код клиента, сделавшего заказ, дата размещения и требуемая дата выполнения заказа, стоимость заказа и код сотрудника, принявшего заказ.
Клиент	Сведения о клиентах	Код клиента, его статус и наименование, адресные данные, телефон
Сотрудники	Сведения о сотрудниках предприятия	Код сотрудника, дата его рождения и дата приема на работу, код должности, Ф.И.О, адрес
Материал	Сведения о материалах, применяемых для изготовления какой-либо модели мебели	Код модели, код типа материала, его наименование, количество, единицы измерения, стоимость, код поставщика
Применяемый материал	Сведения о материалах, применяемых в модели	Количество материала в модели мебели
Поставщики	Сведения о поставщиках материалов	Код поставщика, название фирмы, ИНН, адрес и телефон
Позиции заказ	Сведения о включенных в заказ моделях мебели	Код заказа, код модели и ее количество
Должность	Справочник должностей, имеющихся на предприятии	Код должности, ее название
Скидки	Справочник имеющихся на предприятии скидок для клиентов	Код статуса, процент скидки, название статуса
Тип материала	Справочник по типам материалов, применяемых на предприятии	Код типа материала, его наименование
Модели	Справочник моделей мебели, изготавливаемых предприятием	Код модели, ее наименование и изображение
Трудоемкость работ	Справочник трудоемкости работ, выполняемых при изготовлении каждой модели мебели	Код модели, наименование трудоемкости, стоимость

На рисунке 6.18 показана логическая модель данных ИС предприятия на уровне сущностей и связей.

Рис.6.18 – Логическая модель данных уровня сущностей

На рисунке 6.29 показана логическая модель данных ИС предприятия в виде полной атрибутивной модели (сущности, связи, ключи, атрибуты).

Сущность Материалы является родовым предком (супертипом) для дочерних сущностей (подтипов) Конструкционные материалы и Отделочные материалы. Поле Категория является дискриминатором подтипов.

Рис. 6.19 – Логическая модель данных (полный атрибутивный уровень)

6.3.3.8. Денормализация в ERwin

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

Пример. Производные атрибуты, ведущие к нарушению первой НФ.

Сотрудник= {Таб номер, Фамилия, …, Код Должности}

Должность= {Код Должности, Название должности, Оклад}

Связь необязательная один ко многим

Денормализуем – будет работать быстрее

Сотрудник= {Таб номер, Фамилия, …, Должность, Оклад}

Должность= { Должность, Оклад}

Рис. 6.20 – Нормализованная модель данных

Рис. 6.21 – Денормализованная модель данных

Аномалии обновления: если меняется оклад по должности – нужно менять оклад у всех сотрудников. Решение: обновлять только в таблице «Должность», выбирать данные – только из таблицы «Сотрудник». Нужна процедура синхронизации таблиц (триггер). Ответственность за механизм поддержания целостности данных ложится на разработчика БД.

6.3.3.4. Создание физической модели данных

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

Различают два уровня физической модели

- трансформационная модель (Transformation Model);

- модель СУБД (DBMS Model).

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

Модель СУБД автоматически генерируется из трансформационной модели и является точным отражением системного каталога СУБД.

Пример физической модели показан на рис 6.22.

Рис. 6.22 – Фрагмент физической модели данных

6.4. Согласование моделей данных и моделей процессов

После разработки модели данных ее следует связать с моделью процес­сов. Такая связь гарантирует завершенность анализа, гарантирует, что есть источник данных (сущность) для всех потребностей данных (работа). Связи объектов способствуют согласованности, корректности и завершенности анализа.

Стрелки в модели процессов (BPwin) обозначают некоторую информа­цию, использующуюся в моделируемой системе. В ERwin на логическом уровне модели данных информация отображается в виде сущностей (соответствуют таблицам на физическом уровне), состоящих из атрибутов сущностей (соответствуют колонкам таблицы). Сущности состоят из сово­купности отдельных записей – экземпляров сущностей (соответствуют за­писям в таблице). К модели данных предъявляются определенные требова­ния (нормализация данных), которые призваны обеспечить компактность и непротиворечивость хранения данных. Основная идея нор­мализации данных – каждый факт должен храниться в одном месте. Это приводит к тому, что информация, которая моделируется в виде одной стрелки в модели процессов, может содержаться в нескольких сущностях и атрибутах в модели данных. Кроме того, на диаграмме модели процессов могут присутствовать различные стрелки, изображающие одни и те же дан­ные, но на разных этапах обработки (например, необработанные детали – обработанные детали – собранное изделие). Информация о таких стрелках находится в одних и тех же сущностях. Следовательно, одной и той же стрелке в модели процессов могут соответствовать несколько сущностей в модели данных и, наоборот, одной сущности может соответствовать не­сколько стрелок.

Стрелке в модели процессов может соответствовать отдельная сущность в модели данных. Так, стрелке "Части" на рис. 6.23 соответствует сущность "Часть", стрелке "Конечные продукты" – сущность "Продукт".

Информация о стрелке может содержаться только в нескольких атрибу­тах сущности. Разным атрибутам, одной и той же сущности могут соответ­ствовать разные стрелки. На рис. 6.24 стрелка "Новая часть" соответствует атрибутам "Номер части" и "Название части", стрелка "Наличное количе­ство" – атрибутам "Количество".

Рис. 6.23. Преобразование стрелки в сущность

Рис.6.24. Преобразование стрелки в атрибут

Работы в модели процессов могут создавать или изменять данные, кото­рые соответствуют входящим или выходящим стрелкам. Они могут воздей­ствовать как целиком на сущности (создавая или модифицируя экземпляры сущности, рис. 6.25), так и на отдельные атрибуты сущности (рис. 6.26).

Рис.6.25. Воздействие работы на сущность

BPwin позволяет связывать элементы модели данных, созданной с по­мощью ERwin, документировать влияние работ на данные и тем самым позволяет создать спецификации на права доступа к данным для каждого процесса (см. ниже).

Рис. 6.26. Воздействие работы на атрибут

2) Экспорт данных из ERwin в BPwin и связывание объектов модели данных со стрелками и работами

Первым шагом связывания модели данных и модели процессов является экспорт данных из ERwin в BPwin.

Основные способы связывания объектов модели данных и модели процессов:

1) Экспорт и импорт через файлы формата .EAX – .BPX.

2) Синхронизация моделей, хранящихся в репозитории ModelMart при помощи утилиты ModelMart Synchronizer.

Ниже будет рассмотрен первый способ связывания моделей. Для экспорта модели данных из ERwin в BPwin необходимо в ERwin от­крыть модель и выбрать пункт меню File/Bpwin/Export. В появившемся диалоге необходимо выбрать имя файла *.eax и нажать ОК.

Затем в BPwin нужно открыть модель процесса, выбрать в меню пункт FiIe/Import/Erwin (EAX)…, выбрать имя файла и нажать ОК. Появится про­токол импорта. Если закрыть диалог протокола, появляется диалог Irnport frorn EAX Verification. Для внесения данных в модель процесса следует щелкнуть по кнопке Accept Changes. Кнопка Review Changes вновь вызывает диалог протокола импорта, кнопка Cancel Changes отменяет им­порт.

После внесения данных в модель процессов можно связать сущности и атрибуты со стрелками. Правой кнопкой мыши нужно щелкнуть по стрелке и выбрать в контекстном меню Arrow Data.

Появляется закладка Arrow Data диалога Arrow Property.

Рис. 6.27 Закладка Arrow Data диалога Arrow Property

Для связывания атрибута со стрелкой достаточно щелкнуть по иконке выбора Д в иерархическом списке атрибутов. При этом сущность автома­тически связывается со стрелкой. Каждая стрелка в модели процессов мо­жет быть связана с несколькими атрибутами различных сущностей.

Кнопка Copy In позволяет копировать связанные данные из другой стрелки.

Кнопка Clear – все связи стрелки с данными.

Кнопка Migrate вызывает диалог Changes to Arrow Data Associations, в котором отображаются данные, мигрирующие от дочерних к родитель­ским стрелкам (для разветвляющихся и сливающихся стрелок). При мигра­ции возможны изменения связывания данных:

• Delelions – если данные связаны с родительской стрелкой, но не связа­ны с дочерней, связи с родительской стрелкой удаляются;

• Additions – если данные связаны с дочерней стрелкой и не связаны с родительской, добавляется связь с родительской стрелкой.

Для подтверждения изменений в диалоге Changes to Arrow Data Associations следует щелкнуть по кнопке Commit. Миграция возможна только в моделях IDEFO и DFD.

Как было указано выше, работы могут воздействовать на данные. Для документирования такого воздействия необходимо щелкнуть правой кноп­кой мыши по работе и выбрать пункт меню Data Usage Editor (рис. 6.28).

Рис. 6.28 Диалог Data Usage Editor для стрелок управления и входа

Рис. 6.29. Диалог BPwin Data Usage Editor для стрелки выхода

В появившемся диалоге Data Usage Editor в виде иерархического списка показываются все работы модели, стрелки, которые касаются работ, сущ­ности и атрибуты, которые были связаны со стрелками. В верхнем списке нужно щелкнуть по имени стрелки, с которой были связаны сущности и атрибуты, для задания ассоциации достаточно щелкнуть по окну jyjj в иерархическом списке.

Для сущностей задается ассоциация CRUD (Create, Read, Update, Delete), для атрибутов – IRUN (Insert, Read, Update, Nullify). Ассоциации CRUD и IRUN – это правила использования сущностей и атрибутов рабо­тами, т. e. то, что могут делать работы с входящими или исходящими дан­ными. Данные не могут использоваться работами произвольно. Стрелки входа представляют данные, которые работа преобразует в выход или по­требляет. Такие данные могут быть обновлены (Update) или удалены (Delete), но не могут быть созданы (Create). Данные, связанные со стрел­ками управления, могут быть только прочитаны (Read), но не могут быть изменены – процедуры и стратегии не могут изменяться в работе. Данные, связанные со стрелками выхода, могут быть обновлены (если им соответст­вуют данные стрелок входа), удалены (Delete) или созданы (Create). Для стрелок механизма ассоциации не устанавливаются.

Результат связывания объектов модели процессов можно отобразить в отчете Data Usage Report (меню Reports/Data Usage Report). Ниже приве­ден пример такого отчета.

Рис. 6.30 Отчет по связыванию

3. Создание сущностей и атрибутов BPwin и их экспорт в ERwin

Если в процессе связывания стрелок с объектами модели данных ока­жется, что каких-либо сущностей или атрибутов не хватает, их можно доба­вить прямо в BPwin, а затем экспортировать в ERwin.

Для редактирования сущностей и атрибутов следует выбрать пункт ме­ню Edit/Entity/Attribute Dictionary. Появляется диалог Entity and Attribute Dictionary (рис. 8).

Диалог Entity and Attribute Dictionary имеет два списка – в верхнем пока­зываются сущности, в нижнем – атрибуты. Для создания новой сущности следует в верхнем поле Entity задать имя сущности (на рис. 8 – "Чертеж") и щелкнуть по кнопке Add. Сущность будет добавлена в список. Если включить опцию BPwinonly, созданная сущность при экспорте не будет передана в ERwin. Кнопки Delete и Update служат соответственно для уда­ления и обновления сущности. Каждой сущности можно дать определение (кнопка Definition ofselected Entity).

Рис. 6.31 Диалог Entity and Attribute Dictionary

Список атрибутов отображается в нижнем окне. Полностью атрибуты создаются и редактируются аналогично.

После описания сущностей и атрибутов следует щелкнуть по кнопке Close.

Для экспорта данных в BPwin следует выбрать меню File/Export/ ERwin(BPX) и указать файл, в который будет выгружена информация о модели.

В ERwin следует выбрать меню BPwin/Import и указать файл BPX, в ко­торый была выгружена информация о модели.

Возникает диалог ERwin/BPwin Entity Sync Editor (рис. 9), в котором отображаются:

• сущности, имеющиеся в модели ERwin, но отсутствующие в ВРХ-файле (окно Unsynched ERwin Entity);

• сущности, имеющиеся в ВРХ-файле, но отсутствующие в модели ERwin (окно Unsynched BPwin Entity);

• сущности, имеющиеся в ВРХ-файле, и соответствующие им сущности в модели ERwin, а также действия по синхронизации, которые будут проводиться ERwin (окно ERwin Entity).

Рис. 6.32 Окно Import Differences Preview

В примере на рис. 6.32 сущность "Трудоемкость работ" будет импортирована из BPX-файла в модель ERwin.

После щелчка по кнопке Execute возникает диалог ERwin/BPwin Subject Sync Editor, который показывает имена работ, которые не соот­ветствуют подмножеству модели (Subject Area) в ERwin. Диалог ERwin/BPwin Subject Sync Editor имеет три окна:

Unsynched ERwin Subject Area – подмножество модели, имеющееся в ERwin, но отсутствующее в BPX- файле;

Unsynched BPwin Activity – работы, имеющиеся в ВРХ-файле, но не со­ответствующие подмножествам модели в ERwin.

ERwin Subject Area – работы, имеющиеся в ВРХ-файле, и соответствую­щие им подмножества модели в ERwin, а также действия по синхрониза­ции, которые будут проводиться ERwin.

Кнопками Import, Export и Ignore можно задать действия по синхрони­зации, которые будут проводиться ERwin. Опция Include Decomp указыва­ет, что все работы декомпозиции выбранной работы будут импортироваться в отдельные подмножества модели. Кнопка Unsync позволяет отменить связывание подмножеств модели и работ.

После щелчка по кнопке Execute запускается процесс импорта BPX-файла. После окончания процесса появляется диалог с протоколом импорта. После щелчка по кнопке OK импортированные сущности (в примере -сущность "Чертеж") и новые подмножества модели вносятся в модель дан­ных.

Импортированная сущность (на рис. 6.34 – сущность "Чертеж") не име­ет первичного ключа и не связана с другими сущностями. Назначение ат­рибутов первичным ключом и связывание сущностей можно провести только средствами ERWin; другими словами, сущности и атрибуты, создан­ные в BPwin и затем импортированные в ERWin, можно рассматривать как заготовку для создания полноценной модели данных, а не как готовую мо­дель.

Рис. 6.35 Модель данных после импорта сущности "Чертеж"