ОБУЧЕНИЕ ПРОЕКТИРОВАНИЮ РЕЛЯЦИОННЫХ БАЗ ДАННЫХ СТУДЕНТОВ НЕИНФОРМАЦИОННЫХ СПЕЦИАЛЬНОСТЕЙ

TEACHING OF RELATIONAL DATABASE DESIGNING FOR STUDENTS OF NON-INFORMATIONAL SPECIALTIES

Mikhail Zatsepin

Senior lecturer of the Department of Mathematical Modeling, Kuban State University,

Russia, Krasnodar

АННОТАЦИЯ

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

ABSTRACT

Peculiarities and teaching methodology of the Database designing in the subjects of Databases, Information technologies in branches and the like for the specialties not related to the training of specialists in information technologies are considered. The order of database designing including domain analysis, conceptual designing, logical designing is given. A detailed exemplary methodology for teaching of relational database designing is proposed. The exemplary content of the training on the stages of designing is given. The emphasises in the study of sections, the peculiarities connected to different designing variants, useful methodological guidelines that is helpful in the studying of the training content are indicated.

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

Keywords: database, data model, database designing, relational model, subject domain, conceptual designing, ER diagram, logical schema, primary key, foreign key, attribute.

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

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

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

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

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

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

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

1. выбирается модель данных и СУБД,

2. проверяется соответствие диаграммы заданному уровню нормализации (при необходимости нормализовать до заданного уровня можно уже при создании логической схемы) [1, с. 54].

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

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

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

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

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

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

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

После полной последовательности проектирования (которую можно оставить только в лекционном изложении) проводятся тренировки проектирования без создания ER-диаграммы – сразу создается логическая схема (именно так зачастую происходит на практике, если уже известна СУБД и, что модель реляционная). В таком варианте так же есть анализ предметной области, но после сразу приступают к созданию логической схемы –создаются таблицы и поля. Проверка кратностей связей проводится так же как и в 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. Knowledge Base of Relational and NoSQL Database Management Systems [Электронный ресурс]. – https://db-engines.com/en/ranking