УДК 004.652

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

Зацепин Михаил Николаевич – старший преподаватель кафедры Математического моделирования Кубанского государственного университета

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

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

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

Проектирование баз данных изучается как часть изучения баз данных в соответствующем курсе (Базы данных, Информационные технологии и т.п.). Обязательной предварительной подготовкой является изучение нескольких моделей данных, используемых в базах данных, и их краткая история. Кроме того, необходимыми будут знания основ реляционной модели: определения терминов отношение, кортеж, атрибут, домен атрибута, знание операций, интерпретации структуры данных. Также, необходимо будет предварительное изучение нормальных форм и навыки нормализации, как минимум, до 3НФ (3+НФ). Выбор именно реляционной модели для изучения обосновывается на основе статистики использования СУБД и моделей данных в них [4].

В преамбуле излагается классическая последовательность проектирования: Анализ предметной области, Концептуальное проектирование, Логическое проектирование, Физическое проектирование [3, с. 57]. Кратко излагается содержание: понятие предметной области, понятие концептуального проектирования (предполагает создание ER-диаграммы, но при этом не выбираются модель данных и СУБД), понятие логического проектирования (создание схемы базы данных с выбранными СУБД и моделью данных), понятие физического проектирования (создание собственно базы данных на основании логической модели с использованием командной строки или графической среды для СУБД).

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

Существует много вариантов понимания что такое ER-диаграмма: в современных CASE-средствах зачастую так называют логическую схему данных (и в состав средства может входить модуль, генерирующий SQL-код создания базы данных на основании такой "ER-диаграммы"). Существуют и различные трактовки синтаксиса ER-диаграмм – нотации. По мнению автора, необходимо давать классическую нотацию Чена: прямоугольные сущности, овальные атрибуты и связи в виде ромбов. При этом, достаточно ограничиться именно этими тремя элементами – т.е. не использовать различные вариации этих элементов: слабые сущности, составные атрибуты, идентифицирующие связи и т.д. Для объяснения необходимости таких диаграмм достаточно пояснить, что в больших проектах такой подход позволяет структурировать предметную область и выделить необходимые элементы из нее. В дальнейшем, после полного изучения и практики построения ER-диаграмм, можно сравнительно привести нотацию Мартина, включая "crow's foot", как переход к логической схеме [2, с. 70].

При построении ER-диаграммы берутся существительные из словаря и создаются сущности. При этом дается рекомендация именовать сущности существительными во множественном числе (еще одна подсказка при выборе). Следующим этапом является выбор атрибутов: необходимо объяснить – атрибуты выбираются на основании задания на проектирование и на основании логики работы базы ("какие атрибуты нужны для работы базы"). Что касается ключевых атрибутов – большинство авторов рекомендуют их указывать на ER-диаграмме, однако, это противоречит концепции диаграммы (выбор ключей зависит от модели данных), поэтому можно назначение первичных ключей можно делать в логической схеме. После этого создаются связи. Создание связей важно (и это объясняется) для определения связей на будущей логической схеме. Для этого же в связи указывается действие. Такой подход позволяет определить какие сущности непосредственно связаны (а не опосредованно). После создания первого варианта схемы проводится анализ кратности (кардинальности) связей между сущностями. Данный анализ позволяет обнаружить сущности, которые изначально были определены как связи. Такие сущности отсутствовали в словаре, потому что описывались глаголами, а не существительными, но при этом содержали акт действия. Так будет выглядеть схема, где Поставщики Поставляют Товары (Поставляют на первой схеме – связь). Практический прием анализа кратности связей состоит в следующем: берется один экземпляр первой сущности и определяется со сколькими экземплярами второй сущности он может быть связан (т.е. выполняет Действие). Затем берется один экземпляр второй сущности и так же определяется со сколькими экземплярами первой сущности он может быть связан. После этого полученные отношения кратности почленно перемножаются. В данном случае: один Поставщик Поставляет много Товаров (это 1:М) и один товар Поставляется разными Поставщиками (это М:1). Перемножив получаем М:М. Следовательно связь Поставляют следует заменить сущностью Поставки и создать новые связи между сущностями. Такой анализ следует проводить до тех пор, пока все связи не станут 1:М. В новые сущности так же требуется добавить атрибуты. После этого можно переходить к созданию логической схемы базы данных. Особо необходимо подчеркнуть о полной недопустимости в базе данных связей М:М, о том, что связь 1:1 означает, что сущности следует объединить (скорее всего), а все связи должны быть только 1:М. Допустимость в базе данных связи в исключительных (семантически обусловленных случаях) можно пояснить на примере ФЗ-152 (деперсонализация данных).

При создании логической схемы на основе ER-диаграммы базы данных необходимо выполнить ряд действий:

• выбрать СУБД,
• выбрать модель данных,
• проверить нормализацию данных (и выполнить при необходимости по заданному уровню нормализации) [1, с. 54].

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

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

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

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

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

При создании логической схемы следует показать две нотации – простую и расширенную (с дополнительными столбцами в таблице для указания типов данных и для указания ограничений – PK, FK, U и т.д.). На практике можно пользоваться простой нотацией (где выделяют каким-либо образом только первичные ключи, а типы данных и ограничения подразумеваются, но не записываются). Во всех таблицах выбираются или создаются первичные ключи. Здесь можно дополнительно рассказать о недостатках суррогатных ключей, составных ключей и ключей с нечисловыми типами данных (связь с индексацией). Особая задача – перенос связей. Здесь необходимо подчеркнуть, что связи на ER-диаграмме были между сущностями, а на логической схеме (и в базе данных) связываются поле с полем, и поля получают роли: родительское поле и поле Внешнего ключа. В качестве родительского подойдет любое уникальное поле (например, со свойством Unique, а не только первичный ключ), но на практике все-таки почти всегда это поле первичного ключа. Методически можно дать такую инструкцию: для создания внешнего ключа необходимо добавить в таблицу поле с точно таким же типом (название может не совпадать), что и у родительского поля ("скопировать" поле первичного ключа). Для того чтобы не путались куда добавлять поле (где будет внешний ключ) можно дать мнемоническое правило "внешний ключ там, где много". Т.е., из предыдущего примера: один Поставщик участвует в разных Поставках (М), но в одной Поставке участвует только один Поставщик – следовательно, внешний ключ в таблице Поставки. Т.к., в ER-диаграмме были убраны все связи М:М и 1:1 – проверять кратность связей предварительно не нужно (но указывать на схеме желательно, можно в терминах "1" и "М").

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

Конечная схема должна получиться такой, что незнакомый с ней человек мог бы по ней создать базу данных без какой-либо дополнительной информации (за исключением, возможно, уточнения типов данных и ограничений NOT NULL, DEFAULT, UNIQUE, CHECK). Это еще одно мнемоническое правило, которое нужно объяснять учащимся.

Кроме полной схемы проектирования следует также отрабатывать вариант, в котором этап создания ER-диаграммы отсутствует (на практике это часто встречается). В этом случае после анализа предметной области и создания задания на проектирование (или аналога) можно сразу приступать к созданию логической схемы данных: вместо сущностей и атрибутов будут сразу создаваться таблицы и поля. Анализ кратности связей проводится так же (таблицы рассматриваются как сущности). При обнаружении связи М:М между этими таблицами следует добавить таблицу ("соединительную"), в которой добавить поля внешних ключей для связи с каждой из таблиц (так же, как выше). При выборе первичного ключа в этой новой таблице сначала следует рассмотреть кандидатуру – составной ключ из полей внешних ключей. Зачатую эта пара становится хорошим первичным ключом. Выбор состоит в семантическом анализе: не помешает ли работе таблицы такой выбор – все пары значений станут уникальными. Т.о., при создании логической схемы сразу (без концептуального проектирования) задача будет сводиться к выбору сущностей и созданию таблиц, выбору атрибутов для таблиц, нормализации схемы (мнемоническое правило: "каждой сущности – свою таблицу"), созданию связей между таблицами (можно пояснить, что не связанные ни с чем таблицы в базе могут быть, но смысл в этом бывает редко), проверке связей (связываются самые близкие по смыслу работы базы сущности), проверке кратности связей ("1:1 объединяем, 1:М – внешний ключ где много, М:М разделяем таблицей").

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

Список литературы

1. Волк В. К. Базы данных. Проектирование, программирование, управление и администрирование: учебник / В. К. Волк. — Санкт-Петербург: Лань, 2020. — 244 с.
2. Нестеров, С. А.  Базы данных: учебник и практикум для вузов / С. А. Нестеров. — 2-е изд., перераб. и доп. — Москва : Издательство Юрайт, 2023. — 258 с. — (Высшее образование). — ISBN 978-5-534-18107-4. — Текст: электронный // Образовательная платформа Юрайт [сайт]. — URL: https://urait.ru/bcode/534292.
3. Советов, Б. Я.  Базы данных : учебник для вузов / Б. Я. Советов, В. В. Цехановский, В. Д. Чертовской. — 3-е изд., перераб. и доп. — Москва : Издательство Юрайт, 2023. — 420 с. — (Высшее образование). — ISBN 978-5-534-07217-4. — Текст : электронный // Образовательная платформа Юрайт [сайт]. — URL: https://urait.ru/bcode/510752.
4. https://db-engines.com/en/ranking.