Основы проектирования баз данных
Качество проектирования базы данных может влиять на работу с ней. С хорошо спроектированной базой данных легче работать, легче писать к ней запросы. И в данном руководстве мы рассмотрим основные принципы проектирования баз данных.
Для качественного проектирования базы данных существуют различные методики, различные последовательности шагов или этапов, которые во многом похожи. И в целом мы можем выделить следующие этапы:
Выделение сущностей и их атрибутов, которые будут храниться в базе данных, и формирование по ним таблиц. Атомизация сложных атрибутов на более простые.
Определение уникальных идентификаторов (первичных ключей) объектов, которые хранятся в строках таблицы
Определение отношений между таблицами с помощью внешних ключей
Нормализация базы данных
На первом этапе происходит выделение сущностей. Сущность (entity) представляет тип объектов, которые должны храниться в базе данных. Каждая таблица в базе данных должна представлять одну сущность. Как правило, сущности соответствуют объектам из реального мира.
У каждой сущности определяют набор атрибутов. Атрибут представляет свойство, которое описывает некоторую характеристику объекта.
Каждый столбец должен хранить один атрибут сущности. А каждая строка представляет отдельный объект или экземпляр сущности.
Восходящий и нисходящий подходы
При проектировании базы данных на этапе выделения сущностей и их атрибутов мы можем использовать два подхода: восходящий и нисходящий.
Восходящий подход предусматривает выделение необходимых атрибутов, которые надо сохранить в бд. Затем выделенные атрибуты группируются в сущности, для которых впоследствии создается таблицы. Такой подход больше подходит для проектирования небольших баз данных с небольшим количеством атрибутов.
Например, нам дана следующая информация:
Какие данные из этой информации мы можем сохранить: имя студента, название курса, учебная должность преподавателя, имя преподавателя, электронный адрес студента.
Затем мы можем выполнить группировку по сущностям, к которым относятся эти данные:
Дата рождения студента
Электронный адрес студента
Так, те данные, которые имеются позволяют выделить три сущности: студент, преподаватель и курс. При этом мы вполне можем добавлять какие-то недостающие данные. Также следует отметить, что какие-то данные могут иметь отношение к разным сущностям. Например, курс хранит информацию о студенте, которые его посещает. А студент хранит информацию о посещаемом курсе. Подобная избыточность данных решается на последующих шагах проектирования в процессе нормализации базы данных.
Но подобных атрибутов может оказаться очень много: сотни и даже тысячи. И в этом случае более оптимальным будет нисходящий подход. Данный подход подразумевает выявление сущностей. Затем происходит анализ сущностей, выявляются связи между ними, а потом и атрибуты сущностей.
То есть в данном случае мы могли бы сразу определить, что нам надо хранить данные по студентам, курсам и преподавателям. Затем в рамках каждой сущности выявить атрибуты
Например, у сущности «Студент» мы могли бы выделить такие атрибуты, как имя студента, его адрес, телефон, рост, вес, год его рождения. В тоже время нам надо учитывать не вообще все свойства, которые в принципе могут быть у сущности «Студент», а только те, которые имеют значение в рамках описываемой системы. Вряд ли в данном случае играют роль такие свойства как рост или вес студента, поэтому мы можем их вычеркнуть из списка атрибутов при проектировании таблицы.
Иногда подходы комбинируются. Для описания разных частей системы могут использоваться разные подходы. А затем их результаты объединяются.
Атомизация атрибутов
При определении атрибутов происходит разделение сложных комплексных элементов на более простые. Так, в случае с именем студента мы можем его разбить на собственно имя и фамилию. Это позволит впоследствии выполнять операции с эти подэлементами отдельно, например, сортировать студентов только по фамилии.
То же самое касается адреса — мы можем сохранить весь адрес целиком, а можем разбить его на части — дом, улицу, город и т.д.
В то же время возможность разделения одного элемента на подэлементы не всегда может быть востребованной. В ряде задач это может быть просто не нужно. Выделять необходимо только те элементы, которые действительно нужны.
В соответствии с этим аспектом мы можем выделить у сущности «Студент» следующие атрибуты: имя студента, фамилия студента, год рождения, город, улица, дом, телефон.
Домен
Каждый атрибут имеет домен (domain). Домен представляет набор допустимых значений для одного или нескольких атрибутов. По сути домен определяет смысл и источник значений, которые могут иметь атрибуты.
Домены могут отличаться для разных атрибутов, но также несколько атрибутов могут иметь один домен.
Например, выше были определены атрибуты сущности Студент. Определим используемые домены:
Имя . Домен представляет все возможные имена, которые могут использоваться. Каждое имя представляет строку длиной максимум 20 символов (маловероятно, что нам могут встретиться имена свыше 20 символов).
Фамилия . Домен представляет все возможные фамилии, которые могут использоваться. Каждая фамилия представляет строку длиной максимум 20 символов.
Год рождения . Домен представляет все года рождения. Каждый год является числовым значением от 1950 до 2017.
Город . Домен представляет все города текущей страны. Каждый город представляет строку длиной максимум 50 символов.
Улица . Домен представляет все улицы текущей страны. Каждая улица представляет строку длиной максимум 50 символов.
Дом . Домен представляет все возможные номера домов. Каждый номер дома является числом от 1 до, скажем, 10000.
Телефон . Домен представляет все возможные телефонные номера. Каждый номер является строкой длиной в 11 символов.
Определяя домен, мы сразу видим, какие данные и каких типов будут хранить атрибуты. Какое-то другое значение, которое не соответствует домену, атрибут иметь не может.
В примере выше каждый атрибут имеет свой домен. Но, домены могут совпадать. Например, если бы сущность содержала бы следующие два атрибута: город рождения и город проживания, то домен бы совпадал и был бы одним и тем же для обоих атрибутов.
Определитель NULL
При определении атрибутов и их домена необходимо проанализировать, а может ли у атрибута отсутствовать значение. Определитель NULL позволяет задать отсутствие значения. Например, в примере выше у студента обязательно должно быть какое-либо имя, поэтому недопустима ситуация, когда у атрибута, который представляет имя, отсутствует значение.
В то же время студент может не иметь телефонного номера или в рамках системы телефон не обязателен. Поэтому на этапе проектирования таблицы можно указать, что данный атрибут позволяет значение NULL.
Как правило, большинство современных реляционных СУБД поддерживают определитель NULL и позволяют задать его допустимость для столбца таблицы.
Понятие 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-модели для типа сущности «Студент»
На вышеприведенном рисунке объявляются следующие атрибуты, которые в СУБД (программе) могут иметь следующие типы:
Что такое сущность в базе данных
Развитие вычислительной техники осуществлялось по двум основным направлениям:
- применение вычислительной техники для выполнения численных расчетов;
- использование средств вычислительной техники в информационных системах.
Информационная система – это совокупность программно-аппаратных средств, способов и людей, которые обеспечивают сбор, хранение, обработку и выдачу информации для решения поставленных задач. На ранних стадиях использования информационных систем применялась файловая модель обработки. В дальнейшем в информационных системах стали применяться базы данных. Базы данных являются современной формой организации, хранения и доступа к информации. Примерами крупных информационных систем являются банковские системы, системы заказов железнодорожных билетов и т.д.
База данных – это интегрированная совокупность структурированных и взаимосвязанных данных, организованная по определенным правилам, которые предусматривают общие принципы описания, хранения и обработки данных. Обычно база данных создается для предметной области.
Предметная область – это часть реального мира, подлежащая изучению с целью создания базы данных для автоматизации процесса управления.
Наборы принципов, которые определяют организацию логической структуры хранения данных в базе, называются моделями данных.
Существуют 4 основные модели данных – списки (плоские таблицы), реляционные базы данных, иерархические и сетевые структуры.
В течение многих лет преимущественно использовались плоские таблицы (плоские БД) типа списков в Excel. В настоящее время наибольшее распространение при разработке БД получили реляционные модели данных. Реляционная модель данных является совокупностью простейших двумерных таблиц – отношений (англ. relation),т.е. простейшая двумерная таблица определяется как отношение (множество однотипных записей объединенных одной темой).
От термина relation (отношение) происходит название реляционная модель данных. В реляционных БД используется несколько двумерных таблиц, в которых строки называются записями, а столбцы полями, между записями которых устанавливаются связи. Этот способ организации данных позволяет данные (записи) в одной таблице связывать с данными (записями) в других таблицах через уникальные идентификаторы (ключи) или ключевые поля.
Основные понятия реляционных БД: нормализация, связи и ключи
1. Принципы нормализации:
- В каждой таблице БД не должно быть повторяющихся полей;
- В каждой таблице должен быть уникальный идентификатор (первичный ключ);
- Каждому значению первичного ключа должна соответствовать достаточная информация о типе сущности или об объекте таблицы (например, информация об успеваемости, о группе или студентах);
- Изменение значений в полях таблицы не должно влиять на информацию в других полях (кроме изменений в полях ключа).
2. Виды логической связи.
Связь устанавливается между двумя общими полями (столбцами) двух таблиц. Существуют связи с отношением «один-к-одному», «один-ко-многим» и «многие-ко-многим».
Отношения, которые могут существовать между записями двух таблиц:
- один – к — одному, каждой записи из одной таблицы соответствует одна запись в другой таблице;
- один – ко — многим, каждой записи из одной таблицы соответствует несколько записей другой таблице;
- многие – к — одному, множеству записей из одной таблице соответствует одна запись в другой таблице;
- многие – ко — многим, множеству записей из одной таблицы соответствует несколько записей в другой таблице.
Тип отношения в создаваемой связи зависит от способа определения связываемых полей:
- Отношение «один-ко-многим» создается в том случае, когда только одно из полей является полем первичного ключа или уникального индекса.
- Отношение «один-к-одному» создается в том случае, когда оба связываемых поля являются ключевыми или имеют уникальные индексы.
- Отношение «многие-ко-многим» фактически является двумя отношениями «один-ко-многим» с третьей таблицей, первичный ключ которой состоит из полей внешнего ключа двух других таблиц
3. Ключи. Ключ – это столбец (может быть несколько столбцов), добавляемый к таблице и позволяющий установить связь с записями в другой таблице. Существуют ключи двух типов: первичные и вторичные или внешние.
Первичный ключ – это одно или несколько полей (столбцов), комбинация значений которых однозначно определяет каждую запись в таблице. Первичный ключ не допускает значений Null и всегда должен иметь уникальный индекс. Первичный ключ используется для связывания таблицы с внешними ключами в других таблицах.
Внешний (вторичный) ключ — это одно или несколько полей (столбцов) в таблице, содержащих ссылку на поле или поля первичного ключа в другой таблице. Внешний ключ определяет способ объединения таблиц.
Из двух логически связанных таблиц одну называют таблицей первичного ключа или главной таблицей, а другую таблицей вторичного (внешнего) ключа или подчиненной таблицей. СУБД позволяют сопоставить родственные записи из обеих таблиц и совместно вывести их в форме, отчете или запросе.
Существует три типа первичных ключей: ключевые поля счетчика (счетчик), простой ключ и составной ключ.
Поле счетчика (Тип данных «Счетчик»). Тип данных поля в базе данных, в котором для каждой добавляемой в таблицу записи в поле автоматически заносится уникальное числовое значение.
Простой ключ. Если поле содержит уникальные значения, такие как коды или инвентарные номера, то это поле можно определить как первичный ключ. В качестве ключа можно определить любое поле, содержащее данные, если это поле не содержит повторяющиеся значения или значения Null.
Составной ключ. В случаях, когда невозможно гарантировать уникальность значений каждого поля, существует возможность создать ключ, состоящий из нескольких полей. Чаще всего такая ситуация возникает для таблицы, используемой для связывания двух таблиц многие — ко — многим.
Необходимо еще раз отметить, что в поле первичного ключа должны быть только уникальные значения в каждой строке таблицы, т.е. совпадение не допускается, а в поле вторичного или внешнего ключа совпадение значений в строках таблицы допускается.
Если возникают затруднения с выбором подходящего типа первичного ключа, то в качеcтве ключа целесообразно выбрать поле счетчика.
Программы, которые предназначены для структурирования информации, размещения ее в таблицах и манипулирования данными называются системами управления базами данных (СУБД). Другими словами СУБД предназначены как для создания и ведения базы данных, так и для доступа к данным. В настоящее время насчитывается более 50 типов СУБД для персональных компьютеров. К наиболее распространенным типам СУБД относятся: MS SQL Server, Oracle, Informix, Sybase, MS Access и т. д.
Создание БД. Этапы проектирования
Создание БД начинается с проектирования.
Этапы проектирования БД:
- исследование предметной области;
- анализ данных (сущностей и их атрибутов);
- определение отношений между сущностями и определение первичных и вторичных (внешних) ключей.
В процессе проектирования определяется структура реляционной БД (состав таблиц, их структура и логические связи). Структура таблицы определяется составом столбцов, типом данных и размерами столбцов, ключами таблицы.
К базовым понятиями модели БД «сущность – связь» относятся: сущности, связи между ними и их атрибуты (свойства).
Сущность – любой конкретный или абстрактный объект в рассматриваемой предметной области. Сущности – это базовые типы информации, которые хранятся в БД (в реляционной БД каждой сущности назначается таблица). К сущностям могут относиться: студенты, клиенты, подразделения и т.д. Экземпляр сущности и тип сущности — это разные понятия. Понятие тип сущности относится к набору однородных личностей, предметов или событий, выступающих как целое (например, студент, клиент и т.д.). Экземпляр сущности относится, например, к конкретной личности в наборе. Типом сущности может быть студент, а экземпляром – Петров, Сидоров и т. д.
Атрибут – это свойство сущности в предметной области. Его наименование должно быть уникальным для конкретного типа сущности. Например, для сущности студент могут быть использованы следующие атрибуты: фамилия, имя, отчество, дата и место рождения, паспортные данные и т.д. В реляционной БД атрибуты хранятся в полях таблиц.
Связь – взаимосвязь между сущностями в предметной области. Связи представляют собой соединения между частями БД (в реляционной БД – это соединение между записями таблиц).
Сущности – это данные, которые классифицируются по типу, а связи показывают, как эти типы данных соотносятся один с другим. Если описать некоторую предметную область в терминах сущности – связь, то получим модель сущность — связь для этой БД.
Рассмотрим предметную область: Деканат (Успеваемость студентов).
В БД «Деканат» должны храниться данные о студентах, группах студентов, об оценках студентов по различным дисциплинам, о преподавателях, о стипендиях и т.д. Ограничимся данными о студентах, группах студентов и об оценках студентов по различным дисциплинам. Определим сущности, атрибуты сущностей и основные требования к функциям БД с ограниченными данными.
Основными предметно-значимыми сущностями БД «Деканат» являются: Студенты, Группы студентов, Дисциплины, Успеваемость.
Основные предметно-значимые атрибуты сущностей:
- студенты – фамилия, имя, отчество, пол, дата и место рождения, группа студентов;
- группы студентов – название, курс, семестр;
- дисциплины – название, количество часов;
- успеваемость – оценка, вид контроля.
Основные требования к функциям БД:
- выбрать успеваемость студента по дисциплинам с указанием общего количества часов и вида контроля;
- выбрать успеваемость студентов по группам и дисциплинам;
- выбрать дисциплины, изучаемые группой студентов на определенном курсе или определенном семестре.
Из анализа данных предметной области следует, что каждой сущности необходимо назначить простейшую двумерную таблицу (отношения). Далее необходимо установить логические связи между таблицами. Между таблицами Студенты и Успеваемость необходимо установить такую связь, чтобы каждой записи из таблицы Студенты соответствовало несколько записей в таблице Успеваемость, т.е. один – ко – многим, так как у каждого студента может быть несколько оценок.
Логическая связь между сущностями Группы – Студенты определена как один – ко – многим исходя из того, что в группе имеется много студентов, а каждый студент входит в состав одной группе. Логическая связь между сущностями Дисциплины – Успеваемость определена как один – ко – многим, потому что по каждой дисциплине может быть поставлено несколько оценок различным студентам.
На основе вышеизложенного составляем модель сущность – связь для БД «Деканат»
Рис. 1.
— стрелка является условным обозначением связи: один – ко – многим.
Для создания БД необходимо применить одну из известных СУБД, например СУБД Access.
Name already in use
syllabus / labworks / labwork1.md
- Go to file T
- Go to line L
- Copy path
- Copy permalink
1 contributor
Users who have contributed to this file
- Open with Desktop
- View raw
- Copy raw contents Copy raw contents
Copy raw contents
Copy raw contents
1. Инфологическое моделирование предметной области
Освоение методов инфологического моделирования при проектировании схемы данных для реляционной базы данных.
Инфологическое моделирование — способ разработки структуры базы данных, который опирается на семантику (смысл) данных. Входными данными является словесное описание предметной области, полученное от экспертов, выходными — формализованная модель, как правило, представленная в виде ER-диаграммы.
Общие понятия и принципы инфологического моделирования [1]
ER-диаграмма (Entity-Relationship diagram, диаграмма Сущность-Связь) описывает предметную область как набор сущностей, семантически связанных между собой.
Следует различать понятия «сущность» и «экземпляр сущности».
Сущность — набор однотипных объектов или фактов, о которых требуется хранить какую-либо информацию. Иными словами, сущность — все, что можно представить списком.
Сущности желательно именовать существительными единственного числа.
Примеры: «Товар» — множество всех товаров; «Клиент» — множество всех клиентов; «Покупка» — множество всех фактов покупки тем или иным покупателем того или иного товара.
Экземпляр сущности — один объект (факт) набора, один элемент списка.
Сущность определяет набор атрибутов — свойств, значения которых требуется хранить для каждого экземпляра.
Важнейшая черта атрибутов сущности — атомарность.
Атомарность данных (atomicity) — неделимость. Атомарные данные не представляют собой множества значений или списка значений. Атомарность данных — неоднозначная характеристика, и должна определяться с точки зрения семантики данных и предполагаемых методов работы с ними. [2] Так, атрибут «Габариты» сущности «Товар» может быть классифицирован как атомарный, если при работе с моделью будет иметь смысл использовать габариты товара только в совокупности (например, выводить на экран в спецификации), и не придется рассматривать ширину, глубину и высоту товара по отдельности (например, искать товар с шириной не более 1,5 метров). В противном случае атрибут «Габариты» будет неатомарным и требовать пересмотра модели.
Рассмотрим способы борьбы с неатомарностью.
- Атрибут может быть разбит на несколько атрибутов (в случае если атрибут представляет собой набор разных по смыслу значений). Пример:
| Nзач | ФИО |
|---|---|
| 123 | Иванов Иван Иванович |
- Атрибут может быть преобразован в атомарный путем пересмотра того, что будет экземпляром сущности (в случае если атрибут представляет собой список однотипных по смыслу значений, о которых не требуется хранить дополнительных сведений, и значение атрибута индивидуально у каждого экземпляра). Пример:
| Фамилия | Телефоны |
|---|---|
| Иванов | +7 (812) 1234567, +7 (812) 7654321 |
| Фамилия | Телефон |
|---|---|
| Иванов | +7 (812) 1234567 |
| Иванов | +7 (812) 7654321 |
В данном примере экземпляром сущности был человек, а атрибутами — его фамилия и номера телефонов. После преобразования экземпляром сущности стал факт того, что человек имеет тот или иной номер телефона, а атрибутами факта — фамилия человека и номер телефона.
- Атрибут может быть вынесен в отдельную сущность (в случае если атрибут представляет собой список одинаковых по смыслу значений, о которых требуется хранить дополнительные сведения, или значение атрибута может повторяться у нескольких экземпляров). Пример:
| Фильм | Актерский состав |
|---|---|
| Смысл жизни | Иванов (род. 1979-02-21), Петров (род. 1988-07-13) |
| Фильм |
|---|
| Смысл жизни |
| Фамилия актера | Дата рождения |
|---|---|
| Иванов | 1979-02-21 |
| Петров | 1988-07-13 |
В последнем случае вновь сформированная сущность будет связана с исходной.
Связи между сущностями проводятся в том случае, если экземпляры сущностей связаны друг с другом семантически. Экземпляры связей также несут информацию и устанавливают ассоциации между конкретными экземплярами сущностей. Сущность может быть связана сама с собой, в случае если между собой ассоциированы ее отдельные экземпляры.
Связи различаются по кратности (мощности): «один-к-одному», «один-ко-многим», «многие-ко-многим».
Тип связи определяется по отдельности на обоих ее концах. Чтобы определить тип связи на одном из концов, необходимо зафиксировать одиночный экземпляр одной из связанных сущностей и оценить, сколько экземпляров второй сущности с ним может быть логически связано: только один или несколько. Затем аналогичные действия производятся для другого конца связи.
Сущность «Сеанс» связана с сущностью «Билет» связью «один-ко-многим» (на один сеанс продается много билетов; один билет действителен только на один сеанс). Сущность «Группа» связана с сущностью «Студент» связью «один-ко-многим», которая обозначает, что студент учится в группе (в группе учится много студентов, студент может учиться только в одной группе). Сущность «Группа» связана с сущностью «Студент» связью «один-к-одному», которая обозначает, что студент является старостой группы (у группы только один староста, студент может быть старостой только одной группы).
Сущность «Водитель» связана с сущностью «Автобус» связью «многие-ко-многим» (один водитель может водить несколько автобусов, один автобус может управляться несколькими водителями).
Бывают ситуации, когда между сущностями есть несколько связей. Например, между сущностями «Группа» и «Студент», как показано в примерах выше.
В большинстве случаев, когда между сущностями существует единственная связь кратности «один-к-одному», данные сущности могут быть отождествлены с точки зрения данных и слиты в одну. Например, сущности «Товар» и «Товар на складе» могут быть отождествлены в том случае, если склад единственен, и одному товару соответствует ровно один факт его наличия на этом складе.
Для каждой сущности должен быть определен ключ.
Ключ сущности — минимальный набор атрибутов и связей, комбинация значений которых гарантированно уникальна для всех экземпляров данной сущности (иными словами, гарантированно различается у любых двух ее экземпляров). Ключ может быть естественным (т.е. быть продиктованным семантикой предметной области) или суррогатным (т.е. введенным в модель только из-за необходимости наличия ключа при неудобстве использования или неинтуитивности естественного ключа).
В лабораторной работе в академических целях предпочтение необходимо отдавать естественным ключам.
В случае, если ключ составляет одиночный атрибут, его значение не может повториться ни у одного экземпляра сущности. В случае, если ключ состоит из нескольких атрибутов, по отдельности значение каждого из них может совпадать у двух экземпляров, а требование уникальности накладывается на комбинацию их значений.
Нередки случаи, когда частью естественного ключа для сущности является связь (такая связь называется ключевой). Это значит, что два экземпляра данной сущности при совпадении значений остальных частей ключа будут гарантированно связаны с различными экземплярами второй сущности.
Пример: Ключ сущности «Этап проекта» будет составным: (атрибут «Номер этапа», связь с сущностью «Проект»). Так, номера этапов, ассоциированных с одним и тем же проектом, будут гарантированно различными, а если у двух этапов номера совпадают, то они гарантированно относятся к различным проектам.
Переход к реляционной модели
После составления ER-модели необходимо, руководствуясь нижеприведенным алгоритмом, перейти к реляционной модели той же самой предметной области. В дальнейшем в СУБД используется именно она.
Реляционная модель является менее абстрактной и уточняет некоторые детали, такие как домены для атрибутов, специфические для СУБД названия отношений и атрибутов, ограничения целостности и др.