Сущности (службы основных данных)
Сущности — это объекты, содержащиеся в моделях Master Data Services. Каждая сущность содержит элементы, которые являются строками основных данных, которыми можно управлять.
Необходимо число сущностей
Модели могут содержать множество сущностей, которым нужно управлять. В каждой сущности должны объединяться схожие данные. Например, сущность может быть предназначена для всех корпоративных учетных записей или для главного списка сотрудников.
Как правило, существует одна или несколько центральных сущностей, важных для бизнеса, с которыми связаны другие объекты модели. Например, в модели «Продукт» можно иметь центральную сущность с названием «Продукт», с которой будут связаны другие сущности, такие как «Подкатегория» и «Категория». Однако нет необходимости в центральной сущности. В зависимости от потребностей можно иметь несколько сущностей, которые должны рассматриваться как равные по важности.
Связь сущностей с другими объектами модели
Сущность можно рассматривать как таблицу, содержащую основные данные, в которой строки представляют элементы, а столбцы — атрибуты.
Сущность заполняется перечнем основных данных, которыми нужно управлять.
Сущности могут использоваться для построения производных иерархий, которые являются многоуровневыми и основанными на нескольких сущностях. Дополнительные сведения см. в разделе «Производные иерархии» (службы Master Data Services).
Сущности также могут содержать явные иерархии (неоднородные структуры на основе одной сущности) и коллекции (одноразовые комбинации подмножеств элементов). Дополнительные сведения см. в разделе «Явные иерархии» (службы Master Data Services) и коллекции (службы Master Data Services).
Использование сущностей в качестве ограниченных списков
Когда пользователи назначают атрибуты элементам в сущности, можно предоставить им выбор из ограниченного списка значений. Для этого используйте сущность для заполнения списка значений атрибута. Такой атрибут называется атрибутом на основе домена. Дополнительные сведения см. в разделе «Атрибуты на основе домена» (службы Master Data Services).
Базовые сущности
Базовая сущность является отправной точкой для пользователей при навигации по объектам в модели. Базовая сущность определяет макет экрана, когда пользователь открывает функциональную область Обозреватель и щелкает пункт Обозреватель на панели меню. Чтобы указать сущность в качестве базовой, необходимо перейти к функциональной области Администрирование системы . На странице Представление модели перетащите сущность из дерева с правой стороны на имя модели в дереве с левой стороны.
Безопасность сущности
Можно дать пользователям разрешения на сущность, которая включает связанные объекты модели. Дополнительные сведения см. в разделе «Разрешения сущностей» (службы Master Data Services).
Примеры сущности
В следующих примерах сущность имеет атрибуты: Name, Code, Subcategory, StandardCost, ListPrice и FilePhoto. Эти атрибуты описывают элементы. Каждый элемент представлен отдельной строкой значений атрибута.
В следующем примере сущность «Продукт» является центральной. Сущность «Подкатегория» является атрибутом на основе домена сущности «Продукт». Сущность «Категория» является атрибутом на основе домена сущности «Подкатегория». StandardCost и ListPrice — это атрибуты в свободной форме сущности Product, а FilePhoto — это файловый атрибут сущности Product.
Это пример на основе пользовательского интерфейса Master Data Manager. Иерархическая древовидная структура показывает отношения между сущностями и атрибутами на основе домена. Она предназначена для отображения отношений, а не для демонстрации уровней важности.
Связанные задачи
Описание задачи | Раздел |
---|---|
Создание новой сущности. | Создание сущности (службы Master Data Services) |
Изменение имени существующей сущности. | Изменение сущности (службы Master Data Services) |
Удаление существующей сущности. | Удаление сущности (службы Master Data Services) |
Назначение разрешения сущностям. | Назначение разрешений объекта модели (службы Master Data Services) |
См. также
- Модели (службы Master Data Services)
- Участники (службы Master Data Services)
- Атрибуты (службы Master Data Services)
Основы проектирования баз данных
Качество проектирования базы данных может влиять на работу с ней. С хорошо спроектированной базой данных легче работать, легче писать к ней запросы. И в данном руководстве мы рассмотрим основные принципы проектирования баз данных.
Для качественного проектирования базы данных существуют различные методики, различные последовательности шагов или этапов, которые во многом похожи. И в целом мы можем выделить следующие этапы:
- Выделение сущностей и их атрибутов, которые будут храниться в базе данных, и формирование по ним таблиц. Атомизация сложных атрибутов на более простые.
- Определение уникальных идентификаторов (первичных ключей) объектов, которые хранятся в строках таблицы
- Определение отношений между таблицами с помощью внешних ключей
- Нормализация базы данных
На первом этапе происходит выделение сущностей. Сущность (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), будем опираться на эти знания.
Достоинствами данной модели являются
· Использование естественного языка.
Сущность XE «Сущность» это собирательное понятие, некоторая абстракция реально существующего объекта, процесса, явления или некоторого представления об объекте, информацию о котором требуется хранить в базе данных.
Необходимо различать такие понятия, как тип сущности и экземпляр сущности. Понятие тип сущности относится к набору однородных личностей, предметов, событий или идей, выступающих как целое. Экземпляр сущности относится к конкретной вещи в наборе. Например, типом сущности может быть ГОРОД , а экземпляром – Москва, Киев и т.д. Предполагается, что гарантировано отличие экземпляров одного типа сущности друг от друга. Данное требование вполне аналогично требованию отсутствия в таблице тождественных строк. В дальнейшем, однако, там, где это не может вызвать неоднозначного прочтения, мы не будем различать типы и экземпляры, а будем просто использовать термин «сущность». Принято выражать (именовать) сущность существительным или существительным с характеризующим его прилагательным (СТУДЕНТ, ДЕКАНАТ, ВЫПУСКАЮЩАЯ КАФЕДРА и др.).
Выделяют три вида сущностей: стержневая, ассоциативная (ассоциация) и характеристическая (характеристика). Кроме этого во множестве ассоциативных сущностей также определяют подмножество обозначений. Дадим теперь определение видам сущностей.
Стержневая сущность XE «Стержневая сущность» .
Стержневая (сильная) XE «Сильная сущность» сущность – независящая от других сущность. Стержневая сущность не может быть ассоциацией, характеристикой или обозначением (см. ниже).
Ассоциативная сущность XE «Ассоциативная сущность» (или ассоциация) выражает собой связь «многие ко многим» между двумя сущностями. Является вполне самостоятельной сущностью. Например, между сущностями МУЖЧИНА и ЖЕНЩИНА существует ассоциативная связь, выражаемая ассоциативной сущностью БРАК.
Характеристическую сущность XE «Характеристическая сущность» еще называют слабой сущностью. Она связана с более сильной сущностью связями «один ко многим» и «один к одному». Характеристическая сущность описывает или уточняет другую сущность. Она полностью зависит от нее и исчезает с исчезновением последней. Например, сущность Зарплата является характеристикой конкретных работников предприятия и не может в таком контексте существовать самостоятельно – при удалении экземпляра сущности Работника должны быть удалены и экземпляры сущности Зарплата, связанные с удаляемым работником.
Обозначение XE «Обозначение» это такая сущность, с которой другие сущности связаны по принципу «многие к одному» или «один к одному». Обозначение, в отличие характеристики является самостоятельной сущностью. Например, сущность Факультет обозначает принадлежность студента к данному подразделению института, но является вполне самостоятельной.
Любой фрагмент предметной области может быть представлен некоторым набором сущностей и связями между ними. Например, рассматривая предметную область ФАКУЛЬТЕТ можно выделить следующие основные сущности: СТУДЕНТ, КАФЕДРА, СПЕЦИАЛЬНОСТЬ, ДЕКАНАТ, ГРУППА, ПРЕПОДАВАТЕЛЬ, ЭКЗАМЕН . На первом этапе создания ER -модели данных следует выделить все сущности, которые предполагается описывать исходя из постановки задачи. Лишний раз подчеркнем, что сущностью может быть не только некоторый материальный объект, но и некоторый процесс, например ЭКЗАМЕН, ЛЕКЦИЯ . Сущностью может быть и некоторая количественная и качественные характеристики объекта: УЧЕНОЕ ЗВАНИЕ, СТАЖ и др. Все в действительности зависит от постановки задачи и от нашего анализа предметной области.
Основные понятия
Рассмотрим другие важные понятия, используемые при построении ER -модели. Мы ввели уже понятие сущности. Остановимся на трех других Понятиях: атрибут сущности, ключ, связь.
Система диаграмм
Следует заметить, что в настоящее время разработано несколько различных графических методов представления диаграмм в модели «сущность — связь». Рассмотрим один из возможных подходов, в основе которого лежат диаграммы Чена.
Таблица 1.6. Обозначения для ER- модели
Так на диаграмме изображается сущность, отличная от сильной сущности, без уточнения ее типа.
Атрибут сущности. Вместо имени атрибута можно указать многоточие «…», что будет обозначать группу атрибутов.
Атрибут сущности, являющийся первичным ключом.
Обозначает связь, между двумя сущностями.
Ассоциативная сущность (связь «многие ко многим»).
Обозначение сущности вида «характеристика».
Показывает сущность вида «обозначение».
Прямая линия указывает на связь между сущностями, либо соединяет сущность и атрибут. Линия со стрелкой указывает направленную связь.
Правила порождения
И так ER -диаграммы построены. Следующий этап проектирования – перенести диаграммы на язык таблиц конкретной СУБД. Можно сказать, что ER -диаграммы порождают реляционную базу данных. Оказывается процесс порождения можно легко формализовать, довести до автоматизма. Прежде всего, заметим, что почти всегда есть взаимнооднозначное соответствие между сущностью и таблицей. При этом атрибуты сущности переходят в атрибуты (столбцы) таблицы, а первичный ключ сущности переходит в первичный ключ таблицы. В Таблице 1.7 представлены правила соответствия бинарных связей сущностей и соответствующих элементов реляционной базы данных.
Таблица 1.7.Правила соответствия
Тип бинарной связи
Элементы реляционной базы данных
Связь «один к одному», характеристики
Для каждой сущности строится своя таблица. Связь между таблицами «один к одному».
Связь «один к одному», характеристики
Строится одна таблица, структура которой состоит из атрибутов обеих сущностей. В качестве первичного ключа берется ключ одной из сущностей.
Связь «один к одному», характеристики
При построении связи на основе двух таблиц мы вынуждены допустить, что значение внешнего ключа может быть равно NULL . Если исключить эту возможность, то такую связь следует строить на основе трех таблиц. Одна таблица является таблицей – посредником. Она содержит первичные ключи двух других таблиц.
Связь «один ко многим», характеристики
Каждой сущности ставится в соответствие таблица. Связи между таблицами имеет тип «один ко многим» и строится на основе первичного ключа первой таблицы.
Связь «один ко многим», характеристики
Обычно такой тип связи строится на основе трех таблиц (пар. 2, Один ко многим). Таблица посредник содержит внешний ключ, соответствующий первичному ключу первой таблицы и внешний ключ, соответствующий первичному ключу второй таблицы.
Связь «многие ко многим», характеристики
Любая связь такого типа строится на основе трех таблиц (см. пар. 2, Многие ко многим).
Правила порождения позволят легко перейти от логической модели данных к физической модели.
Заканчивая рассматривать ER -модель, заметим, что при тщательном анализе предметной области, на предмет выявления сущностей, при переходе к реляционной базе данных дополнительная нормализация таблиц, скорее всего не понадобится. Зависимости внутри таблицы часто означают, что мы в одной таблице пытаемся вместить несколько сущностей.
О диаграммных техниках, используемых при построении информационных систем
Функциональные диаграммы
Функциональное моделирование основывается на техниках SADT XE » SADT » и IDEF XE » IDEF » . SADT была предложена Дугласом Россом в середине 1960-х годов. Военно-воздушные силы США использовали методику SADT в своей программе ICAM XE » ICAM » ( Integrated Computer Aided Manufacturing – интеграция компьютерных и промышленных технологий) и назвали ее IDEF В рамках технологии SADT было разработано несколько графических языков моделирования:
■ IDEF 0 – для документирования процессов производства и отображения информации об использовании ресурсов на каждом из этапов проектирования систем.
■ IDEF 1 – для документирования информации о производственном окружении систем.
■ IDEF 2 – для отображения поведения систем во времени.
■ IDEF 3 – для моделирования бизнес процессов.
■ IDEF4 – объектно-ориентированное моделирование.
■ IDEF 5 – моделирование наиболее общих (онтологических) закономерностей системы.
Методология IDEF — SADT представляет собой совокупность методов, правил и процедур, предназначенных для построения функциональной модели какой-либо предметной области. Центральным понятием этой методологии является понятие функции XE «Функция» . Иногда используют и другие термины: деятельность или процесс. Под функцией понимается некоторое действие или набор действий, которые имеют определенную цель и приводят к конкретным результатам. Определенная функция на диаграмме обозначается прямоугольником. На диаграмме используются также стрелки, которые обеспечивают связь между различными функциями (обеспечивают интерфейсы), связывая их в конечном итоге в единую систему, моделирующую предметную область. В диаграммах используются стрелки четырех видов, их называют интерфейсными дугами:
■ 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 XE » 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 существует одиннадцать типов диаграмм. Каждая из диаграмм призвана конкретизировать различные представления о рассматриваемой системе. Перечислим типы диаграмм:
■ Диаграммы вариантов использования.
Остановимся только на одном типе диаграммы – диаграмме классов, который непосредственно можно применить при разработке структуры баз данных. Данный вид диаграмм должен содержать набор классов, анализируемой предметной области, связи между ними, а также возможные ограничения и комментарии.
Классом XE «Класс» в языке UML будем называть именованное описание множества однородных объектов, имеющие одинаковые атрибуты, операции XE «Операции» , отношения с другими объектами и семантику.
Атрибут класса XE «Атрибут класса» — именованное свойство класса, описывающее множество значений, которые принимают экземпляры этого свойства.
Операцией класса XE «Операция класса» будем называть именованную услугу, которую можно запросить у любого экземпляра данного класса.
Между классами в диаграмме могут существовать связи трех типов: зависимости, обобщения и ассоциации.
Определение зависимости XE «Зависимости» .
Связь между двумя классами называю зависимостью, если изменение в спецификации одного класса может повлиять на поведение другого класса.
Определение обобщения XE «Обобщения» .
Обобщением называется связь между классами, когда один из классов является частным случаем второго.
Общий класс при наследовании называется родителем, предком или суперклассом XE «Суперкласс» , а частный класс – потомком. Например, при анализе такой системы как школа, можно выделить суперкласс Человек, в который будут входить такие классы – потомки, как учителя, административные работники школы, ученики, родители учеников. В дальнейшем класс учителей можно рассматривать как суперкласс по отношению к обычным учителям и классным руководителям.
Определение ассоциации XE «Ассоциации» .
Ассоциация показывает, что между объектами одного класса существует некоторая связь с объектами другого класса. Допускается, что класс может быть связан сам с собой. Кроме этого в связи могут участвовать более двух классов.
Ассоциативная связь может характеристики:
■ Роли связи XE «Роли связи» . Для каждого класса, участвующего в ассоциативной связи могут быть указаны роли. Например, для связи между классами Учителя и Ученики можно указать роли: обучающий и обучаемый.
■ Кратность связи XE «Кратность связи» . Кратность определяет, сколько объектов данного класса может или должно участвовать в данной связи. Например, кратность 0..1 говорит, что не все экземпляры класса могут участвовать в данной связи, но в каждом экземпляре связи может участвовать только один объект класса.
■ Агрегация XE «Агрегация» . Если в ассоциативной связи один из классов выступает в роли «целого», а второй в роли «части целого», то такой типа связь называется агрегатной связью. В ней один из классов играет главную, а другой (другие) подчиненную роль. Сильная агрегатная связь называется композицией XE «Композиция» . При такой связи уничтожении главного класса приводит к уничтожению подчиненного класса.
В диаграммах классов могут также указываться ограничения, которые затем должны поддерживаться в базах данных. Ограничения могут выражаться предложениями на естественном языке, но могут записываться на специальном языке OCL XE » OCL » ( Object Constraint Language – язык объектных ограничений). Язык OCL является подмножеством языка UML . Это формальный язык, который позволяет выразить логику ограничений, накладываемых на отдельные элементы диаграмм.
Рис. 1.24. пример простейшей UML -диаграммы
На Рис. 1.24 представлена простейшая UML -диаграмма, на которой изображено три класса: Студенты, Оценки, Предметы. Связь между всеми тремя между всеми тремя классами носит ассоциативную природу. Обратите внимание на значок . Он означает, что налицо агрегатной связи – оценка ставится конкретному студенту и неотъемлемо принадлежит ему. Более того, данный тип агрегации, несомненно, является композитной (закрашенный ромб), так как оценки не могут существовать без конкретного студента. У каждой связи указывается его имя, но роли связи я не указываю, так в данном случае это не добавляет ясности в диаграмму, а скорее затруднит ее чтение. Обратим внимание, что у каждого класса указываются не только атрибуты, но операции (или методы). Разумеется, диаграмма может не вместить все атрибуты и операции.
[1] Разумеется, читатель должен понимать, что речь идет о классе (наборе) сущностей.
Понятие ER-модели. Понятие сущности (entity). Атрибуты. Виды атрибутов
При проектировании базы данных и разработке программного продукта наиболее важной проблемой есть проблема взаимодействия разработчика с заказчиком. Задача разработчика – наиболее точно воссоздать пожелания заказчика при разработке программного продукта управления базой данных. Основная проблема, которую нужно решить разработчику – правильное построение базы данных, а точнее схемы (структуры) базы данных.
Кроме того, разработчик дополнительно встречается с другими трудностями, к которым можно отнести:
- поиск эффективных алгоритмов;
- подбор надлежащих структур данных;
- отладка и тестирование сложного кода;
- дизайн и удобство интерфейса приложения.
В процессе разработки программного обеспечения, управляющего базой данных, разработчик должен подробно выучить требования заказчика. База данных должна быть разработана таким образом, чтобы она была понятной, наиболее точно отображала решаемую проблему и не содержала избыточности в данных.
Чтобы облегчить процесс разработки (проектирования) базы данных, используются так называемые семантические модели данных. Для разных видов баз данных наиболее известной есть ER-модель данных (Entity-Relationship model).
2. Что такое ER-модель (Entity-relationship model)? Для чего нужно разрабатывать ER-модель?
ER-модель (Entity-relationship model или Entity-relationship diagram) – это семантическая модель данных, которая предназначена для упрощения процесса проектирования базы данных. Из ER-модели могут быть порождены все виды баз данных: реляционные, иерархические, сетевые, объектные. В основе ER-модели лежат понятия «сущность», «связь» и «атрибут».
Для больших баз данных построение ER-модели позволяет избежать ошибок проектирования, которые чрезвычайно сложно исправлять, в особенности, если база данных уже эксплуатируется или на стадии тестирования. Ошибки в разработке структуры базы данных могут привести к переделке кода программного обеспечения управляющего этой базой данных. В результате время, средства и человеческие ресурсы будут использованы неэффективно.
ER-модель – это представление базы данных в виде наглядных графических диаграмм. ER-модель визуализирует процесс, который определяет некоторую предметную область. Диаграмма «сущность»-«связь» – это диаграмма, которая представляет в графическом виде сущности, атрибуты и связи.
ER-модель – это только концептуальный уровень моделирования. ER-модель не содержит деталей реализации. Для той же самой ER-модели детали ее реализации могут отличаться.
3. Что такое сущность в базе данных? Примеры
Сущность в базе данных – это любой объект в базе данных, который можно выделить исходя из сути предметной области для которой разрабатывается эта база данных. Разработчик базы данных должен уметь правильно определять сущности.
Пример 1. В базе данных книжного магазина можно выделить следующие сущности:
- книга;
- поставщик;
- размещение в магазине.
Пример 2. В базе данных учета учебного процесса некоторого учебного заведения можно выделить следующие сущности:
- студенты (ученики);
- преподаватели;
- группы;
- дисциплины, которые изучаются.
4. Какие существуют разновидности типов сущностей? Обозначение типов сущностей в ER-модели
В модели «сущность»-«связь» различают две разновидности типов сущностей:
- слабый тип. Этот тип сущности есть зависимым от сильной сущности;
- сильный тип. Это самостоятельный тип сущности, который ни от кого не зависит.
На рисунке 1 изображены обозначения слабого и сильного типа сущности в ER-модели.
Рис. 1. Обозначение сильного и слабого типов сущности
5. Для чего предназначены атрибуты? Виды атрибутов. Обозначение атрибутов на ER-модели
Каждый тип сущности имеет определенный набор атрибутов. Атрибуты предназначены для описания конкретной сущности.
Различают следующие виды атрибутов:
- простые атрибуты. Это атрибуты, которые могут быть частью составных атрибутов. Эти атрибуты состоят из одного компонента. Например, к простым атрибутам можно отнести: код книги в библиотеке или курс обучения студента в учебном заведении;
- составные атрибуты. Это атрибуты, которые состоят из нескольких простых атрибутов. Например, адрес проживания может содержать название страны, населенного пункта, улицы, номера дома;
- однозначные атрибуты. Это атрибуты, которые содержат только одно единственное значение для некоторой сущности. Например, атрибут «Номер зачетной книги» для типа сущности «Студент» есть однозначным, так как студент может иметь только один номер зачетной книги (одно значение);
- многозначные атрибуты. Это атрибуты, которые могут содержать несколько значений. Например, многозначный атрибут «Номер телефона» для сущности «Студент», так как студент может иметь несколько номеров телефона (домашний, мобильный и т.д.);
- произвольные атрибуты. Это атрибуты, значение которых формируется на основе значений других атрибутов. Например, текущий курс обучения студента можно вычислить на основе разности текущего года обучения и года поступления студента в учебное заведение (если студент не имел проблем с учебой и хорошо учил дисциплину «Организация баз данных и знаний»).
На ER-диаграмме атрибуты обозначаются так, как изображено на рисунке 2. Как видно из рисунка, любой атрибут обозначается в виде эллипса с названием внутри эллипса. Если атрибут есть первичным ключом, то его название подчеркивают.
Рисунок 2. Представление атрибутов на диаграммах ER-модели
6. Как типы сущностей и атрибуты ER-модели реализуются в реальных базах данных и управляемых ими программах?
При разработке программ управления базами данных, типы сущностей и их атрибуты можно представлять по разному при этом придерживаясь нескольких подходов:
- выбрать в качестве источника данных известную технологию (например Microsoft SQL Server, Oracle Database, Microsoft Access, Microsoft ODBC Data Source и т.п.), которая уже исследована, протестирована, стандартизирована и имеет огромный набор средств управления базой данных;
- разработать собственный формат базы данных и реализовать методы ее обработки, а взаимодействие с известными источниками данных реализовать в виде специальных команд наподобие Импорт/Экспорт. В этом случае придется собственноручно программировать всю рутинную работу по ведению и обеспечению надежной работы базы данных;
- реализовать объединение двух вышеприведенных подходов. Современные средства разработки программного обеспечения имеют мощный набор библиотек для обработки сложных наборов и визуализации данных в них (коллекции, массивы, компоненты визуализации и т.п.).
Если база данных реализуется в известных реляционных СУБД (например Microsoft Access, Microsoft SQL Server и т.п.), то типы сущностей представляются таблицами. Атрибуты из ER-модели соответствуют полям таблицы. Одна запись в таблице базы данных представляет один экземпляр сущности.
Каждый вид атрибута реализуется следующим образом:
- простой атрибут или однозначный атрибут может быть представлен доступным набором базовых типов, которые есть в любом языке программирования. Например, целочисленные атрибуты представляются типом int , integer , uint и т.д.; атрибуты содержащие дробную часть могут быть представлены типом float , double ; строчные атрибуты типом string и т.д.;
- составной атрибут – это объект, который включает в себя несколько вложенных простых атрибутов. Например, в СУБД Microsoft Access составной атрибут некоторой таблицы может формироваться на основе набора простых типов (полей). В языках программирования объединение полей реализуется структурами или классами;
- многозначный атрибут может быть реализован массивом или коллекцией простых или составных атрибутов;
- произвольный атрибут реализуется дополнительным полем, которое вычисляется при обращении к таблице. Такое поле называется вычислительным полем (calculated field) и формируется на основе других полей таблицы;
- атрибут, который есть первичным ключом может быть целочисленным, строчным или иного порядкового типа. В этом случае, значение каждой ячейки таблицы, которая соответствует первичному ключу, есть уникальным. Наиболее часто, в качестве первичного ключа выступает целый тип ( int , integer ).
Если база данных реализована в уникальном формате, то типы сущностей удобнее всего представлять в виде классов или структур. Атрибуты сущности реализуются в виде полей (внутренних данных) класса. Методы класса реализуют необходимую обработку полей класса (атрибутов). Взаимодействие (связь) между классами реализуется с помощью специально разработанных интерфейсов с использованием известных шаблонов проектирования.
7. Пример фрагмента ER-модели для типа сущности «Студент»
Приведенный пример демонстрирует фрагмент ER-модели для типа сущности «Студент».
Рисунок 3. Фрагмент ER-модели для типа сущности «Студент»
На вышеприведенном рисунке объявляются следующие атрибуты, которые в СУБД (программе) могут иметь следующие типы:
- атрибут Первичный ключ – есть уникальным целочисленным значением которое формируется автоматически. В СУБД это есть поле-счетчик;
- атрибут Год вступления – простой атрибут, который можно реализовать целочисленным значением ( int , integer );
- атрибут Номер телефона – многозначный атрибут, который может быть реализован как массив или коллекция и т.п.;
- атрибут Номер зачетной книжки – простой атрибут, который можно реализовать как строку символов, поскольку номер зачетной книжки кроме цифр может содержать и буквы;
- атрибут Страна , Город , Улица , Номер дома – это атрибуты, которые образуют составной атрибут Адрес . Все эти атрибуты могут быть строчного (текстового) типа ( string , Text );
- атрибут Фамилия , Имя , Отчество – это простые атрибуты, которые являются частью составного атрибута Имя студента . Все эти атрибуты могут быть строчного (текстового) типа ( string , Text );
- атрибут День рождения – простой атрибут типа Дата ( DateTime );
- атрибут Возраст студента – вычисляемое поле, которое определяется как разность текущей (системной) даты и значения атрибута День рождения .
Связанные темы
- Подтипы сущностей. Супертип. Пример. Преимущества и недостатки применения подтипов сущностей
- Понятие связи в ER-модели. Мощность связи. Типы связей. Примеры