Нотации и средства, применяемые для построения концептуальной модели данных — студенческий портал

db_intro

Назад

Понятие базы данных

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

Система управления базами данных (СУБД) — это совокупность языковых и программных средств, которая осуществляет доступ к данным, позволяет их создавать, менять и удалять, обеспечивает безопасность данных и т.д. В общем СУБД — это система, позволяющая создавать базы данных и манипулировать сведениями из них. А осуществляет этот доступ к данным СУБД посредством специального языка — SQL.

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

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

Структурирование — это набор соглашений о способах представления данных.

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

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

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

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

Гибридные БД совмещают в себе возможности реляционных и объектно-ориентированных, поэтому их часто называют объектно-реляционными. Примером такой СУБД является Oracle, начиная с восьмой версии.

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

Реляционные базы данных, как мы уже знаем, состоят из таблиц. Каждая таблица состоит из столбцов (их называют полями или атрибутами) и строк (их называют записями или кортежами). Таблицы в реляционных базах данных обладают рядом свойств. Основными являются следующие:

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

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

Но это противоречит свойству атомарности (одно значение в одной ячейке), а в столбцах Темы и Сообщения у нас предполагается неограниченное количество значений. Значит, нашу таблицу надо разбить на три: Пользователи, Темы и Сообщения.
Наша таблица Пользователи удовлетворяет всем условиям. А вот таблицы Темы и Сообщения — нет. Ведь в таблице не может быть двух одинаковых строк, а где гарантия, что один пользователь не оставит два одинаковых сообщения, например:

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

Первичный ключ (сокращенно РК — primary key) — столбец, значения которого во всех строках различны. Первичные ключи могут быть логическими (естественными) и суррогатными (искусственными).

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

Кроме того, первичные ключи менять нельзя, а что если у пользователя сменится e-mail?

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

Последний нюанс. Предположим, у нас добавился новый пользователь, и зовут его тоже Вася:

Как мы узнаем, какой именно Вася оставил сообщения? Для этого поля автор в таблицах «Темы» и «Сообщения» мы сделаем также внешними ключами:

Наша база данных готова. Схематично ее можно представить так:

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

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

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

Атрибуты, характеризующие объект — в виде овала, а связи между объектами — ромбами.

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

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

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

Таким образом, поставка и покупка могут рассматриваться, как самостоятельные объекты:

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

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

Объем локальной области выбирается таким образом, чтобы в нее входило не более 6-7 объектов.

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

Преобразование концептуальной модели в реляционную состоит в следующем:

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

Итак, нам надо построить набор таблиц. Сделать это несложно, т.к. таблицы — это наши объекты, а поля таблиц — атрибуты объектов.

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

Таким образом, у нас определены таблицы, поля, первичные ключи (РК) и связи (FK).

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

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

Во-первых, для устранения избыточности данных. Например, в нашем примере для форума , мы оставили бы вот такую таблицу:

В поле Темы часто повторяются одни и те же названия.

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

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

Такая ситуация представляет собой аномалию удаления. Если мы решим поменять название темы, то нам придется просмотреть все строки и в каждой заменить старую тему на новую. Это так называемая аномалия модификации.

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

• 1НФ — первая нормальная форма
• 2НФ — вторая нормальная форма
• 3НФ — третья нормальная форма
• НФБК — нормальная форма Бойса-Кодда
• 4НФ — четвертая нормальная форма
• 5НФ — пятая нормальная форма

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

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

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

Надо сказать, что НФБК, 4НФ и 5НФ используются крайне редко. Поэтому и мы рассмотрим только первые три.

В нашей таблице Поставщики есть поле Адрес. Если наш магазин работает только с поставщиками из одного города, то значения поля Адрес можно считать атомарными, а саму таблицу — приведенной к 1НФ.

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

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

мы используем часть адреса), и для приведения таблицы к 1НФ нам надо выделить еще одно поле — Город:

Если мы собираемся, например, поздравлять наших покупателей с именинами (которые, как известно, завися от имени), то это поле пришлось бы разбить на три: Фамилию, Имя и Отчество.

Наш магазин этого делать не собирается, поэтому поле ФИО можно считать атомарным, а таблицу — приведенной к 1НФ.

Эта форма применяется к таблицам с составными ключами. Таблица, у которой первичный ключ включает только одно поле, всегда находится во 2НФ

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

В нашей базе данных две таблицы имеют составной ключ — Журнал покупок и Журнал поставок. Значение поля Количество зависит, как от Поставки (Покупки), так и от Товара. Значит, наши таблицы находятся во 2НФ.

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

Посмотрим теперь на таблицу Журнал поставок: поле Количество зависит от Наименования товара и от Даты поставки, но не зависит от того, кто поставил товар (поле Поставщика). Т.е. таблица не находится во 2НФ.

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

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

Посмотрим на нашу таблицу Товар. В ней есть поле Цена, но цены, как известно, имеют свойство меняться. Если мы будем их менять прямо здесь, то будет пропадать вся информация о предыдущих ценах. Чтобы не терять эту информацию, надо добавить поле Дата (когда изменилась цена). Тогда наша таблица будет выглядеть так:

Даже не прибегая к 3НФ видно, что такая таблица будет содержать избыточную информацию. Но посмотрим на ее поля: поля Наименование и Дата зависят от id товара, а поле Цена зависит также и от Даты. Т.е. таблица не находится в 3НФ.

Для устранения транзитивной зависимости необходимо провести «расщепление» объекта на два:

Все остальные таблицы нашей базы данных находятся в 3НФ.

Кстати, в таблице Товар можно было и не вводить поле id товара, а сделать первичным ключом поле Наименование, но как уже говорилось в третьем уроке суррогатные ключи все-таки предпочтительнее.

Подведем итог. Схема нашей базы данных после нормализации несколько изменилась и выглядит теперь так:

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

Источник: http://wiki.it-wiki.org.ua/doku.php/db_intro

ERD (OpenModelSphere) – концептуальная модель данных

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

Если БД в проекте не предусмотрена, то модель позволяет продумать передаваемые данные в виде структур, записей, массивов, файлов и прочего, показывая взаимодействие модулей. В отличие от IDEF1xможет быть менее детализированной и используется на этапе анализа и формирования требований к ПО.

При проектировании ПО может детализироватьсяв IDEF1x, если в проекте предусмотрена БД.

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

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

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

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

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

В CASE-средствахSilverrun или OpenModelSphere для концептуального моделирования данных (на стадии формирования требований) также используется один из вариантов нотации Чена.

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

Числа над линиями означают степень и обязательность связи. Связь работает в обе стороны, но читается по-разному.

Рис. 2.34. Обозначение сущностей и связей

В данном примере пара (0,N) означает, что физическое лицо может не иметь банковского счета (необязательная связь — 0) либо иметь много счетов (степень связи — N). Читаем в обратную сторону (1.1) — каждый банковский счет может принадлежать одному (обязательная связь) и только одному физическому лицу (степень связи — 1).

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

Рис. 2.35. Графическое представление сущности

Существуют следующие виды ключевых полей:

• Первичный/альтернативный.Сущность может иметь несколько идентификаторов. Один должен являться основным (первичным), а другие — альтернативными. Первичный идентификатор на диаграмме подчеркивается. Альтернативные идентификаторы предваряются символами для первого альтернативного идентификатора, для второго и т. д.

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

• Простой/составной (рис. 2.36): идентификатор, состоящий из одного атрибута, является простым, из нескольких атрибутов – составным. В реляционных БД не поддерживается составной, т.к. это подразумевает разделение одной ячейки на две.

Рис. 2.36. Составной идентификатор

• абсолютный/относительный, если все атрибуты, составляющие идентификатор, принадлежат сущности, то идентификатор является абсолютным. Если один или более атрибутов идентификатора принадлежат другой сущности, то идентификатор является относительным.

Когда первичный идентификатор является относительным, сущность определяется как зависимая сущность, поскольку ее идентификатор зависит от другой сущности. В примере на рис. 2.37 идентификатор сущности Строка-заказа является относительным.

Он включает идентификатор сущности Заказ, что показано на рисунке подчеркиванием 1,1.

Рис. 2.37. Относительный идентификатор

Как и сущности, связи могут иметь атрибуты. Пример на рис. 2.38 показывает атрибуты связи.

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

Оценка не является атрибутом студента или атрибутомкурса; она является атрибутом обеих этих сущностей. Это атрибут связи между студентом и курсом, которая в примере называется Регистрация.

Рис. 2.38. Связь с атрибутами

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

Точно так же для определения экземпляров связи между сущностями требуется идентификатор связи. Так, в примере на рис. 2.

38 идентификатором отношения Регистрация является идентификатор студента и номер курса, поскольку вместе они определяют конкретный экземпляр связи студентов и курсов.

В связи “супертип-подтип” (рис. 2.39) общие атрибуты типа определяются в сущности-супертипе, сущность-подтип наследует все атрибуты супертипа. Экземпляр подтипа существует только при условии существования определенного экземпляра супертипа. Подтип не имеет идентификатора (он импортирует его из супертипа).

Рис. 2.39. Связь “супертип-подтип”

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

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

Кроме баз данных ERDпозволяет моделировать просто имеющиеся данные в приложении и отражать их связи. Ниже пример диаграммы для программы-эмулятора движения робота Arduino. Диаграмма построена в программе OpenSphereModel.

Продолжим рассматривать пример о налоговой из DFD.

Концептуальная модель данных в виде ERD (рис. 2.42) строится исходя из следующих соображений:

• сущности могут быть распознаны как структуры данных в DFD. Чтобы рассматривать объект в качестве сущности, он должен обладать более чем одним атрибутом;

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

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

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

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

1. • модель системных процессов;
2. • архитектура ЭИС;
3. • модели данных приложений;
4. • модель пользовательского интерфейса.
5. На стадии реализации выполняются генерация SQL-предложений, определяющих структуру целевой БД (таблицы, индексы, ограничения целостности), и генерация кода приложений.

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

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

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

Рис. 2.42. Диаграмма “сущность-связь” (БИК — банковский идентификационный код)

МЕТОД БАРКЕРА

Одной из наиболее распространенных разновидностей нотации ERD является нотация, предложенная Ричардом Баркером, автором методов, используемых в технологии создания ПО фирмы Oracle. Данная нотация используется в CASE-средстве Oracle Designer.

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

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

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

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

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

Первый шаг моделирования — извлечение информации из интервью и выделение сущностей (рис. 2.18).

Рис. 2.18. Графическое изображение сущности в методе Баркера

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

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

Рис. 2.19. Диаграмма сущностей

Второй шаг моделирования — идентификация связей. Определение связи в методе Баркера несколько отличается о данного Ченом.

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

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

Имя каждой связи между двумя данными сущностями должно быть уникальным, но имена связей в модели не обязаны быть уникальными.

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

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

Степень и обязательность связи можно показать графически (рис. 2.20).

Рис. 2.20. Степень и обязательность связи

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

Рис. 2.21. Связь продавца с контрактом

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

Третий шаг моделирования — идентификация атрибутов.

Рис. 2.22. Диаграмма «сущность-связь» без атрибутов

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

Уникальный идентификатор — это атрибут или совокупность атрибутов и/или связей, предназначенная для уникальной идентификации каждого экземпляра данного типа сущности.

Рис. 2.23. Обязательный (помечен звездочкой) и необязательный (помечен кружком) атрибуты

Рис. 2.24. Виды идентификации: а — полная идентификация; б — идентификация посредством другой сущности

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

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

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

Рис. 2.25. Диаграмма «сущность-связь» с атрибутами

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

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

Рекурсивная связь: сущность может быть связана сама с собой (рис. 2.28).

Рис. 2.26. Супертипы и подтипы

Рис. 2.27. Взаимно исключающие связи

Рис. 2.28. Рекурсивная связь

Неперемещаемые (non-transferrable) связи: экземпляр сущности не может быть перенесен из одного экземпляра связи в другой (рис. 2.29).

Рис. 2.29. Неперемещаемая связь

Источник: https://cyberpedia.su/12xdf47.html

Концептуальная модель базы данных — диаграмма связи между объектами

Концептуальная модель базы данных это

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

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

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

Принятые определения в концептуальной базе данных

Для единообразия программирования баз данных введены следующие понятия для концептуальных баз данных:

1. Объект или сущность. Это фактическая вещь или объект (для людей) за которой пользователь (заказчик) хочет наблюдать. Например, Иванов Иван Иванович;
2. Атрибут это характеристика объекта, соответствующая его сущности. Например. Задаем себе вопрос: Какую информацию нужно хранить об Иванове Иване Ивановиче? Ответы на этот вопрос и будут атрибуты объекта Иванов Иван Иванович;
3. Третье понятие в проектировании концептуальной базы данных это связь или отношения между объектами.

Лексически более правильно говорить связь между объектами КБД и отношения между сущностями КБД (концептуальная база данных), но встретить можно самые различные сочетания сущности, объекта, связи и отношения (огрехи переводов).

Концептуальная модель базы данных условные обозначения

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

Диаграмма сущность/отношения (объект/связь) называют ER-диаграммой или EDR (entity-relationship diagram). Сама модель сущность-связь была предложена профессором Peter Pin-Shen Chen (Питер Чен) в 1976 году. Правила написания и условные обозначения  ER-диаграммы называют нотацией. Распространены две основные нотации ER-диаграмм:

• Нотация Питера Чена;
• Нотация  Gordon Everest (Гордона Эверста). Под назаванием Crow’s Foot  или Fork (вилка).

Обозначения ER-диаграммы по Питеру Чену

Чен предложил и это приняли следующие условные обозначения для ER-диаграмм:

• Сущность или объект обозначать прямоугольником;
• Отношения обозначать ромбом;
• Атрибуты объектов, обозначаются овалом;
• Если сущность связана с отношением, то их связь обозначается прямой линией со стрелкой. Необязательная связь обозначается пунктирной линией. Мощная связь обозначается двойной линией.

Каждый атрибут может быть связан с одним объектом (сущностью).

Нотация  Gordon Everest

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

Атрибуты не выделяются в отдельную фигуру, а вписываются в прямоугольник объекта именем существительным с уточняющим словом.

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

концептуальная модель базы данных ERD Fork

Дополнения

Атрибуты в ER диаграмме, могут иметь свои собственные атрибуты (композитный) атрибут.

Как нарисовать ER-диаграмму-советы

Простую ER диаграмму нарисовать достаточно просто.  Другое дело насыщенная, объемная ER диаграмма. Ниже приведены некоторые советы, которые помогут вам построить эффективные ER схемы:

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

©WebOnTo.ru

Другие статьи раздела: СУБД

Источник: https://webonto.ru/kontseptualnaya-model-bazyi-dannyih/

Нотации и средства, применяемые для построения концептуальной модели данных

Нотацию ER-диаграммы впервые ввел П. Чен (Chen), а далее она развивалась в работах Баркера.

Понятие 1

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

Свойства сущности:

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

Рассмотрим моделирование на примере фирмы, которая занимается продажей автомашин.

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

Важно сказать, что для администратора важными будут контракты, автомашины, продавцы и покупатели. Исходя из всᴇᴦο выше сказанного, мы приходим к выводу, что можно выделить 4 сущности (контракт, покупатель, продавец, автомашина), которые изобразим на диаграмме (рисунок 1).

Далее нужно идентифицировать связи.

Понятие 2

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

При создании связей каждому экземпляру однои̌ сущности (родительской сущности) соответствует произвольное (может быть нулевым) количество экземпляров второй сущности (сущности-потомка), а каждому экземпляру сущности-потомка соответствует только один экземпляр сущности-родителя. Отсюда следует, что, экземпляр сущности-потомка может существовать лишь при наличии родительской сущности.

Опишем связи остальных сущностей (рисунок 4).

Моделирование завершается идентификацией атрибутов.

Понятие 3

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

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

Атрибуты могут быть обязательными (обозначаются символом * ) или необязательными (символ circ ). Обязательный атрибут не может принимать неопределенное значение.

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

Дополнительный материал 1

Важно заметить, что каждая сущность должна иметь как минимум один возможный ключ.

Понятие 4

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

1. Если существует несколько возможных ключей, то один ᴎɜ них обозначают как первичный ключ, а остальные – как альтернативные.
2. Так модель данных, кроме основных конструкций, может состоять ᴎɜ дополнительных, которыми являются подтипы и супертипы (рисунок 7), взаимно исключающие связи (рисунок 8), рекурсивная связь (рисунок 9), неперемещаемые связи (рисунок 10).

Подход, который используется в CASE-средстве Vantage Team Builder

CASE-средство Vantage Team Builder использует один ᴎɜ вариантов нотации П. Чена. На ER-диаграммах сущность обозначают в виде прямоугольника, который содержит имя сущности (рисунок 11), а связь – в виде ромба, который связан линией с каждой ᴎɜ взаимодействующих сущностей. Степень связи показывают с помощью чисел над линиями.

Дополнительный материал 2

Необязательнои̌ связью (рисунок 12) могут быть связаны не всœе экземпляры сущности.

Дополнительный материал 3

В полнои̌ связи берут уе всœе экземпляры хотя бы однои̌ ᴎɜ сущностей.

Дополнительный материал 4

Обязательнои̌ связью описывается связь между «независимой» и «зависимой» сущностями.

• К примеру, если у каждого автомобиля есть по крайней мере один водитель, но не каждый служащий может управлять машинои̌, будет изображено следующим образом (рисунок 13):
• Приведем пример слабой связи (рисунок 14): номер (ключ) строки в документе не уникален и должен дополняться ключом документа.

Источник: http://referatwork.ru/info-lections-55/tech/view/411_notacii_i_sredstva_primenyaemye_dlya_postroeniya_konceptual_noy_modeli_dannyh

Основы баз данных. ER-модель (сущность-связь)

Сегодня речь пойдет о модели «сущность-связь», или entity-relationship model.

Теория

Модель “сущность-связь” (Entity-Relationship model  или ER – модель) представляет собой высокоуровневую концептуальную модель данных, кото­рая была разработана с целью упрощения задачи проектирова­ния структур баз данных.

Данная модель представляет собой набор концепций, которые описывают структуру БД в виде совокупности сущностей, атрибутов и связей.

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

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

Цель диаграмм “сущность-связь”   — это создать точное и полное отображение ре­альной предметной области (ПрО), используемое в дальнейшем в ка­честве источника информации для построения базы данных автоматизированных систем обработки информации (БД АСОИ).

Эта диаграмма или концептуальная модель ПрО должна отвечать сле­дующим тре­бованиям:

• Обеспечивать адекватное отображение ПрО;
• Представлять на языке, понятном, как будущим пользователям АСОИ, так и разработ­чикам БД;
• Содержать информацию о ПрО, достаточную для дальнейшего проек­тирова­ния БД (разработка логической и физической моделей);
• Гарантировать однозначную интерпретацию или толкование модели ПрО.

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

СУЩНОСТЬ– это множество объектов реального мира с одинаковыми свой­ствами. Сущ­ность характеризуется независимым существованием и может быть объектом с фи­зическим (или реальным) существова­нием или объектом с концептуальным (или абстрактным) существо­ванием.

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

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

, ин­формацию о которых необходимо хранить в БД.

Практика

ПРИМЕР. Предметная область “Заказ билетов в кинотеатре”. В кинотеатре показывают фильмы, билеты на которые можно купить в день показа или забронировать их заранее.

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

Кинопоказ состоит из Фильма, информация о котором так же хранится в БД.

• Для ПрО “Заказ билетов в кинотеатре” сущностями будут выступать следующие понятия:
• Кинопоказ
• Фильмы
• Зритель
• Билет
• Бронь
• Стоимость
• Графически сущности на диаграммах “сущность-связь” представляются в виде пря­моугольников:

АТРИБУТ — это  средство,  с  помощью  которого  определяются свойства сущности или связи.  Атрибут — это поименованная  характеристика сущности. Наименова­ние атрибута должно быть уникальным для кон­кретной сущности, но может быть одинаковым для разных сущностей.

1. Конкретный набор атрибутов для сущности определяется задачами,  в ко­торых они используются. Например, сущности ПрО “Заказ билетов в кинотеатре” можно описать с помощью следующей совокупности атрибутов:
2. Кинопоказ (Номер кинопоказа, Номер Фильма, Дата показа, Номер Стоимости);
3. Фильм (Номер фильма, Название, Продолжительность, Краткое описание);
4. Зритель (Номер зрителя, ФИО, дата рождения);
5. Билет (Номер зрителя, Номер кинопоказа, Стоимость билета);
6. Бронь (Номер зрителя, Номер кинопоказа, дата брони);
7. Стоимость (Номер стоимости, Номер кинопоказа, стоимость).
8. Графически изображение атрибутов сущности представляются в виде вы­носок, в ко­торых перечисляется список имен атрибутов. Например:

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

СВЯЗЬ – это отношение между  экземплярами двух (и более) разных сущностей. Механизм связей используется для того, чтобы опре­делить взаимоотноше­ния между сущностями в ПрО. Кроме этого, существуют отношения между атрибутами отдельной сущности (будут рассмотрены при построении логи­ческих моделей).

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

Наименование связи должно нести в себе определенный смысл, чтобы было легче разобраться в том, как соотносятся сущности. Например, взаимо­отношение между сущ­ностями Зритель и Билет можно определить как “Покупает”.

Показатель кардинальности связи (характеристика однозначности) обозначает степень взаимосвязи сущностей и описывает количество возможных связей для каждой из сущ­ностей-участниц:

• один-к-одному (1:1);
• один-ко-многим (1:N);
• многие-ко-многим (N:M).

Источник: https://secretsilent.ru/er-model-start/