Выделите грубые ошибки сущности бд

Основные сведения

Термин «реляционный» означает «основанный на отношениях». Реляционная база данных состоит из сущностей (таблиц), находящихся в некотором отношении друг с другом. Название произошло от английского слова relation—отношение.
Проектирование базы данных состоит из двух основных фаз: логического и физического моделирования.
Во время логического моделирования вы собираете требования и разрабатываете модель базы данных, не зависящую от конкретной СУБД (системы управления реляционными базами данных). Это похоже на то, как если бы вы создавали чертежи вашего дома. Вы могли бы продумать и начертить все: где будет кухня, спальни, гостиная. Но это все на бумаге и в макетах.
Во время физического моделирования вы создаете модель, оптимизированную для конкретного приложения и СУБД. Именно эта модель реализуется на практике. Если вернуться к дому из предыдущего абзаца, на этом этапе вам придется строить где-нибудь дом — таскать бревна, кирпичи…

Процесс проектирования базы данных состоит из следующих этапов:

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

Первые 5 этапов образуют фазу логического проектирования, а остальные два — фазу физического моделирования.

Логическая фаза

Логическая фаза состоит из нескольких этапов. Далее они все рассмотрены.

Сбор требований

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

Определение сущностей

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

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

Сущности состоят из атрибутов (столбцов таблицы) и записей (строк в таблице).

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

Любая таблица имеет следующие характеристики:

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

На этом этапе вам необходимо выявить все категории информации (сущности), которые будут храниться в базе данных.

Определение атрибутов

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

Для каждого атрибута определяется тип данных, их размер, допустимые значения и любые другие правила. К их числу относятся правила обязательности заполнения, изменяемости и уникальности.
Правило обязательности заполнения определяет, является ли атрибут обязательной частью сущности. Если атрибут является необязательной частью сущности, то он может принимать NULL-значение, иначе — нет.
Также вы должны определить, является ли атрибут изменяемым. Значения некоторых атрибутов не могут измениться после создания записи.
И, наконец, вам нужно определить, является ли атрибут уникальным. Если это так, то значения атрибута не могут повторяться.

Ключи

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

Возможный ключ

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

Первичные ключи

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

Альтернативные ключи

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

Внешние ключи

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

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

Определение связей между сущностями

Реляционные базы данных позволяют объединять информацию, принадлежащую разным сущностям.
Отношение — это ситуация, при которой одна сущность ссылается на первичный ключ второй сущности. Как, например, сущности Дом и Хозяин на предыдущем рисунке.
Отношения определяются в процессе проектирования базы. Для этого следует проанализировать сущности и выявить логические связи, существующие между ними.
Тип отношения определяет количество записей сущности, связанных с записью другой сущности. Отношения делятся на три основных типа, о которых рассказано далее.

Один-к-одному

Каждой записи первой сущности соответствует только одна запись из второй сущности. А каждой записи второй сущности соответствует только одна запись из первой сущности. Например, есть две сущности: Люди и Свидетельства о рождении. И у одного человека может быть только одно свидетельство о рождении.

Один-ко-многим

Каждой записи первой сущности могут соответствовать несколько записей из второй сущности. Однако каждой записи второй сущности соответствует только одна запись из первой сущности. Например, есть две сущности: Заказ и Позиция заказа. И в одном заказе может быть много товаров.

Многие-ко-многим

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

• Обязательное отношение означает, что для каждой записи из первой сущности непременно должны присутствовать связанные записи во второй сущности.
• Необязательное отношение означает, что для записи из первой сущности может и не существовать записи во второй сущности.

Нормализация

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

Первая нормальная форма

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

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

Вторая нормальная форма

Таблица во второй нормальной форме содержит только те данные, которые к ней относятся. Значения не ключевых атрибутов сущности зависят от первичного ключа. Если более точно, то атрибуты зависят от первичного ключа, от всего первичного ключа и только от первичного ключа.
Для соответствия второй нормальной форме сущности должны быть в первой нормальной форме.
Например, у сущности Дом на рисунке есть атрибут Цена литра бензина, который не имеет ничего общего с домами. Этот атрибут удаляется (или вы можете перенести его в другую сущность). А также мы переносим атрибут Мэр в отдельную сущность — этот атрибут зависит от города, где находится дом, а не от дома.
На рисунке изображена сущность Дом во второй нормальной форме (Сущность Дом, приведенная ко второй нормальной форме).

Третья нормальная форма

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

Ограничения

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

Хранимые процедуры

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

ПРИМЕЧАНИЕ
Хранимые процедуры находятся в базе данных и выполняются на сервере базы данных. Как правило, они быстрее операторов SQL, поскольку хранятся в компилированном виде.

Целостность данных

Организовав данные в таблицы и определив связи между ними, можно считать, что была создана модель, правильным образом отражающая бизнес-среду. Теперь нужно обеспечить, чтобы данные, вводимые в базу, давали правильное представление о состоянии дела. Иными словами, нужно обеспечить выполнение деловых правил и поддержку целостности (integrity) базы данных.
Например, ваша компания занимается доставкой книг. Вы вряд ли примете заказ от неизвестного клиента, ведь тогда вы даже не сможете доставить заказ. Отсюда бизнес-правило: заказы принимаются только от клиентов, информация о которых есть в базе данных.
Корректность данных в реляционных базах обеспечивается набором правил. Правила целостности данных делятся на четыре категории.

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

Триггеры

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

Деловые правила

Деловые правила определяют ограничения, накладываемые на данные в соответствии с требованиями бизнеса (тех, для кого вы создаете базу). Деловые правила могут состоять из набора шагов, необходимых для выполнения определенной задачи, или же они могут быть просто проверками, которые контролируют правильность введенных данных. Деловые правила могут включать правила целостности данных. В отличие от других правил, их главная цель — обеспечить правильное ведение деловых операций.
Например, в компании «Очень крутые парни» может быть так принято, что закупаются для служебных нужд только белые, синие и черные автомобили.
Тогда деловое правило для атрибута Цвет автомобиля сущности Служебные автомобили будет гласить, что автомобиль может быть только белым, синим или черным.
Большинство СУБД предоставляют средства:

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

Все эти возможности можно применять для реализации деловых правил в базе данных.

Физическая модель

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

Денормализация

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

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

Создание базы данных и таблиц

Последнее обновление: 02.07.2017

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

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

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

2. Определение уникальных идентификаторов (первичных ключей) объектов, которые хранятся в строках таблицы

3. Определение отношений между таблицами с помощью внешних ключей

4. Нормализация базы данных

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

У каждой сущности определяют набор атрибутов. Атрибут представляет свойство, которое описывает некоторую характеристику объекта.

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

Восходящий и нисходящий подходы

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

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

Например, нам дана следующая информация:

Том посещает курс по математике, который преподает профессор Смит.
Сэм посещает курс по математике, которые преподает профессор Смит.
Том посещает курс по языку JavaScript, который преподает ассистент Адамс.
Боб посещает курс по алгоритмам, который преподает ассистент Адамс.
Сэм имеет следующие электронный адрес sam@gmail.com и телефон +1235768789.

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

Затем мы можем выполнить группировку по сущностям, к которым относятся эти данные:

Так, те данные, которые имеются позволяют выделить три сущности: студент, преподаватель и курс. При этом мы вполне можем добавлять какие-то
недостающие данные. Также следует отметить, что какие-то данные могут иметь отношение к разным сущностям. Например, курс хранит информацию о
студенте, которые его посещает. А студент хранит информацию о посещаемом курсе. Подобная избыточность данных решается на последующих шагах проектирования в процессе
нормализации базы данных.

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

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

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

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

Атомизация атрибутов

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

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

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

В соответствии с этим аспектом мы можем выделить у сущности «Студент» следующие атрибуты: имя студента, фамилия студента, год рождения, город,
улица, дом, телефон.

Домен

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

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

Например, выше были определены атрибуты сущности Студент. Определим используемые домены:

• Имя. Домен представляет все возможные имена, которые могут использоваться. Каждое имя представляет строку длиной максимум 20 символов (маловероятно, что нам могут встретиться имена свыше 20 символов).

• Фамилия. Домен представляет все возможные фамилии, которые могут использоваться. Каждая фамилия представляет строку длиной максимум 20 символов.

• Год рождения. Домен представляет все года рождения. Каждый год является числовым значением от 1950 до 2017.

• Город. Домен представляет все города текущей страны. Каждый город представляет строку длиной максимум 50 символов.

• Улица. Домен представляет все улицы текущей страны. Каждая улица представляет строку длиной максимум 50 символов.

• Дом. Домен представляет все возможные номера домов. Каждый номер дома является числом от 1 до, скажем, 10000.

• Телефон. Домен представляет все возможные телефонные номера. Каждый номер является строкой длиной в 11 символов.

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

В примере выше каждый атрибут имеет свой домен. Но, домены могут совпадать.
Например, если бы сущность содержала бы следующие два атрибута: город рождения и город проживания, то домен бы совпадал и был бы одним и тем же для обоих атрибутов.

Определитель NULL

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

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

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

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

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

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

·           
Простота

·           
Наглядность.

·           
Однозначность.

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

Определение

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

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

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

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

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

Ассоциация.

Ассоциативная сущность (или ассоциация) выражает собой связь «многие
ко многим» между двумя сущностями. Является вполне самостоятельной сущностью.
Например, между сущностями МУЖЧИНА и ЖЕНЩИНА существует ассоциативная связь,
выражаемая ассоциативной сущностью БРАК.

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

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

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

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

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

Основные понятия

Рассмотрим другие важные
понятия, используемые при построении ER-модели. Мы ввели уже понятие сущности.  Остановимся на трех других Понятиях: атрибут
сущности, ключ, связь.

Система диаграмм

Следует заметить, что в
настоящее время разработано несколько различных 
графических методов представления диаграмм в модели «сущность — связь».
Рассмотрим   один из возможных подходов,
в основе которого лежат диаграммы Чена. 

Таблица 1.6. Обозначения для
ER-модели

Правила порождения

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

Таблица 1.7.Правила соответствия

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

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

 О
диаграммных техниках, используемых при построении информационных систем

Функциональные
диаграммы

Функциональное моделирование
основывается на техниках SADT и IDEF.
SADT была предложена
Дугласом Россом в середине 1960-х годов. 
Военно-воздушные силы США использовали методику SADT в своей программе ICAM (Integrated Computer Aided Manufacturing – интеграция компьютерных
и промышленных технологий) и назвали ее IDEF В рамках технологии SADT было разработано несколько графических языков моделирования:

■          
IDEF0
– для документирования процессов производства и отображения информации об использовании
ресурсов на каждом из этапов проектирования систем.

■          
IDEF1
– для документирования информации о производственном окружении систем.

■          
IDEF2
– для отображения поведения систем во времени.

■          
IDEF3
– для моделирования бизнес процессов.

■          
IDEF4
– объектно-ориентированное моделирование.

■          
IDEF5
– моделирование наиболее общих (онтологических) закономерностей системы.

Методология IDEF—SADT представляет собой совокупность методов, правил и процедур,
предназначенных для построения функциональной модели  какой-либо предметной области. Центральным
понятием  этой методологии является
понятие функции. Иногда
используют и другие термины: деятельность или процесс. Под функцией понимается
некоторое действие или набор действий, которые имеют определенную цель и
приводят к конкретным результатам. Определенная функция на диаграмме
обозначается прямоугольником. На диаграмме используются также стрелки, которые
обеспечивают связь между различными функциями (обеспечивают интерфейсы),
связывая их в конечном итоге  в единую
систему, моделирующую предметную область. 
В диаграммах используются стрелки четырех видов, их называют
интерфейсными дугами:

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

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

■          
C
(Control) – ограничения
данной функции (все, что ограничивает функцию). Стрелка входит в прямоугольник
сверху.

■          
M
(Mechanism) – механизм,
используемый в данной функции. Стрелка входит снизу в прямоугольник — функцию.

На Рис. 1.15 представлен общий вид фрагмента диаграммы, изображенной
по методологии SADT. 

Рис. 1.15.  Общий вид
функциональной диаграммы           

Рис. 1.18. Диаграмма SADT, полученная из общей диаграммы (см. Рис. 1.17) посредством детализации

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

■          
Случайная связность.

■          
Логическая связность. Обусловлена тем, что
функции или данные относятся к одному классу.

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

■          
Процедурная связность. Тип связности возникает,
когда функции выполняются в одной и той же части процесса. 

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

■          
Последовательная связность. Возникает, когда
выход (выходная дуга) одной функции является одновременно входными данными для
другой функции.

■          
Функциональная связность. Связность возникает,
когда одна функция воздействует на другую через интерфейсные дуги управления
(на Рис. 1.18 блок 1 воздействует на
остальные блоки как раз через дуги управления).

Диаграммы потоков
данных

В основе данной методологии
лежит метод диаграмм потоков данных (DFD — Data Flow Diagram). Данные диаграммы призваны описывать процессы
преобразования информации от ее ввода в систему до выдачи пользователю. Как и
для диаграмм SADT здесь
мы также имеем дело с целой иерархией диаграмм, в которой диаграммы нижнего
уровня детализируют диаграммы верхнего уровня. Диаграммы верхнего уровня
определяют основные процессы и подсистемы информационной системы с внешними
входами и выходами. Далее путем декомпозиции диаграммы детализируются. В
результате возникает иерархия диаграмм, на самом нижнем уровне которой описаны
элементарные процессы.  Основными
компонентами диаграмм DFD являются:

■          
Внешние сущности.

■          
Системы и подсистемы.

■          
Процессы.

■          
Накопители данных.

■          
Потоки данных.

Рис. 1.19. Внешняя сущность в потоковых диаграммах

Внешняя сущность представляет
собой физическое лицо или предмет являющийся источником или приемником информации.
Объект, который мы обозначаем как внешняя сущность, является внешним по
отношению к анализируемой предметной области и анализу не подвергается. Это
может быть клиент какой-либо службы (если анализируется вся службы) и оператор,
работающий с информационной системой (если анализу подвергается только
функционирование ИС). Внешняя сущность обознается квадратом (см. Рис. 1.19), несколько приподнятым над
плоскостью  диаграммы. 

Рис. 1.20. Обозначение подсистемы в потоковой диаграмме

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

Рис. 1.21. Обозначение процесса в потоковой диаграмме

Процесс в модели DFD представляет собой
некоторое преобразование входного потока данных в выходной. Под процессом можно
понимать и оператора ЭВМ и программу, и работу целого отдела. На диаграмме
процесс изображается как подсистема в виде прямоугольника (см. Рис. 1.21).  Номер
процесса является его идентификатором и состоит из номера процесса или
подсистемы верхнего уровня и собственно номера процесса. Имя процесса должно
содержать глагол в неопределенной форме 
и четко определять, что данный процесс делает. Наконец в имени процесса
должен быть обозначен объект, который и реализует данный процесс.

Рис. 1.22. Накопитель в потоковой диаграмме

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

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

Рис. 1.23. Пример потоковой диаграммы, описывающей некоторые
процессы подсистемы «Абонент»

UML диаграммы

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

■          
Абстрагирование – отбрасывание тех элементов
системы, которые не существенны с точки зрения рассматриваемой модели.

■          
Многомодельность – любая достаточно сложная
система не может быть полностью описана только одной моделью.

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

Всего в языке UML существует одиннадцать типов
диаграмм. Каждая из диаграмм призвана конкретизировать различные представления
о рассматриваемой системе. Перечислим типы диаграмм:

■          
Диаграммы вариантов использования.

■          
Диаграммы классов.

■          
Диаграммы поведения.

■          
Диаграммы состояний.

■          
Диаграммы деятельности.

■          
Диаграммы взаимодействия.

■          
Диаграммы последовательности.

■          
Диаграммы кооперации.

■          
Диаграммы реализации.

■          
Диаграммы компонентов.

■          
Диаграммы развертывания.

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

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

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

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

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

Определение зависимости.

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

Определение обобщения.

Обобщением называется связь между классами, когда один из классов
является частным случаем второго.

Общий класс при наследовании
называется родителем, предком или суперклассом, а частный класс – потомком.
Например, при анализе такой системы как школа, можно выделить  суперкласс Человек,  в который будут
входить такие классы – потомки, как  
учителя, административные работники школы, ученики, родители учеников. В
дальнейшем класс учителей можно рассматривать как суперкласс по отношению к
обычным учителям и классным руководителям.

Определение ассоциации.

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

Ассоциативная связь может
характеристики:

■          
Имя связи.

■          
Роли
связи.
Для каждого класса, участвующего в ассоциативной связи могут быть указаны роли.
Например, для связи между классами Учителя и Ученики можно указать роли:
обучающий и обучаемый.

■          
Кратность
связи.
Кратность определяет, сколько объектов данного класса может или должно
участвовать в данной связи. Например, кратность 0..1 говорит, что не все
экземпляры класса могут участвовать в данной связи,  но в каждом экземпляре связи может
участвовать только один объект класса.

■          
Агрегация.
Если в ассоциативной связи один из классов выступает в роли «целого», а второй
в роли «части целого», то  такой типа
связь называется агрегатной связью. В ней один из классов играет главную, а
другой (другие) подчиненную роль. Сильная агрегатная связь называется композицией.  При такой связи уничтожении главного класса
приводит к уничтожению подчиненного класса.

В диаграммах классов могут
также указываться ограничения, которые затем должны поддерживаться в базах
данных. Ограничения могут выражаться предложениями на естественном языке, но
могут записываться на специальном языке OCL (Object Constraint Language – язык объектных ограничений). Язык OCL является подмножеством
языка UML. Это
формальный язык, который позволяет выразить логику ограничений, накладываемых
на отдельные элементы диаграмм.

Рис. 1.24. пример простейшей UML-диаграммы

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