Для изучения лекции потребуется программное обеспечение Erwin Data Modeler.
Пройдите по указанной ссылке и нажмите на кнопку Start Trial, заполните появившуюся форму. Обратите внимание, что адрес вашей электронной почты не должен быть от известного интернет-сервис провайдера или бесплатного сервиса (mail.ru, yandex.ru, google.com, ...) - используйте рабочий или личный почтовый домен.
Если у вас есть почта в домене образовательного учреждения, то можете запросить постоянную академическую версию.
В качестве альтернативы к ErWin Data Modeler вы можете использовать триал версию продукта Toad Data Modeler, а также бесплатную или триал версию SQL Power Architect (для Windows и iOS). Перечисленные инструменты предоставляют аналогичный функционал в части тех задач, которые разбираются в рамках курса.
Справочник для Toad Data Modeler - здесь.
В качестве альтернативного решения предлагается инструмент моделирования базы данных для создания диаграмм отношений сущностей, реляционных схем, звездообразных схем и операторов SQL DDL
1. Начало работы с Erwin Data Modeler
Мы переходим к этапу создания схемы данных (ER-диаграммы) в программном обеспечении. Я рекомендую использовать продукт компании Erwin —
Erwin Data Modeler. Скачать бесплатную версию, которой достаточно для нашего курса, можно с сайта erwin.com.
Это приложение решает широкий спектр задач: от проектирования бизнес-процессов до физической реализации базы данных. Мы задействуем лишь малую часть его возможностей, но некоторые из них будут очень полезны.
После установки и запуска появляется стартовое окно. Создаем новый проект:
File →
New. Нам предлагают выбрать тип модели.
•
Логический уровень: Стадия инфологического и даталогического проектирования. Предназначен только для отрисовки схемы, без привязки к конкретной СУБД.
•
Физический уровень: Детализация модели под конкретный сервер базы данных.
•
Смешанный режим (логический/физический): Самый удобный вариант. Он позволяет заточить схему под целевую СУБД.
Мы выбираем смешанный режим. Сразу появляется возможность выбрать конкретную базу данных (SQL Server, Oracle, PostgreSQL и др.). Главное преимущество Erwin Data Modeler в том, что он создает не просто картинку. За отрисованными сущностями и связями скрывается готовый код (
скрипт) для генерации таблиц и связей на языке той СУБД, которую вы выбрали. Это позволяет превратить визуальную схему в реальные объекты базы данных. Мы оставим выбор по умолчанию —
SQL Server.
Создается пустой холст. Ключевой элемент интерфейса — это переключение между логическим и физическим уровнями. На физическом уровне появляется возможность добавлять специфичные для СУБД компоненты: триггеры, хранимые процедуры, представления (view). Вся эта логика закладывается в модель и затем выгружается в итоговый код.
На логическом уровне основные инструменты для работы находятся в верхнем меню:
• Создание сущности (таблицы).
• Создание дискриминатора (отношения категоризации).
• Прорисовка связей: идентифицирующая, неидентифицирующая, «многие ко многим».
На физическом уровне инструмент «Дискриминатор» исчезает, но появляется возможность создавать
представления (Views).
2. Построение логической модели
Начнем проектирование на логическом уровне. Создадим первую сущность. Через правый клик по ней заходим в свойства атрибутов (
Attributes Properties). Список пока пуст.
Сущность «Студент»
Создадим новый атрибут. Для начала определим первичный ключ. Назовем поле Number (номер студенческого билета) и установим для него флаг
Primary Key. Поле переместится над горизонтальной чертой, что графически обозначает первичный ключ.
Теперь настроим свойства атрибута:
•
Тип данных (Data Type): Выбираем
Integer для целых чисел.
•
Домен (Domain): Это понятие отличается от типа данных.
Домен — это множество допустимых значений, определяющее бизнес-логику данных. Тип данных — это техническая характеристика для машины.
o
Пример: Атрибут «Имя» имеет тип данных «Строка» (Varchar). Но его домен — это множество легитимных имен, а не любая последовательность символов (например, пробелы или «ФФФФФФ»).
o
Другой пример: ИНН физлица. Тип данных — Integer. Домен — 12-значное целое число.
o По умолчанию для домена стоит значение
Default, что означает отсутствие ограничений, кроме типа данных. Мы можем уточнить домен или создать собственный (
New), например, для номеров проектов компании со сложной внутренней структурой.
Добавим остальные атрибуты для сущности «Студент»:
•
Name (Имя): Тип данных —
Varchar(18). Домен — строковый.
•
Date_of_Birth (Дата рождения): Тип данных —
Date. Домен — Datetime.
Категоризация (Дискриминатор)
Создадим еще три сущности. Две из них станут подкатегориями студента: «Бюджет» и «Плата». Выбираем на панели инструмент
Sub-Category (дискриминатор). Проводим линию от сущности «Студент» к подкатегориям. Система автоматически наследует первичный ключ (
Number) в дочерние сущности, помечая его как внешний ключ (
FK).
В свойствах дискриминатора (двойной клик по значку) можно выбрать
Complete (полное) или
Incomplete (неполное) разбиение. Для категорий «бюджетник/платник» это полное разбиение, так как студент не может не относиться ни к одной из них.
Добавим специфичные атрибуты:
• В сущность «Бюджет»:
Scholarship (Стипендия). Тип данных —
Money.
• В сущность «Плата»:
Tuition_fee (Плата за обучение). Тип данных —
Money.
Сущность «Курс»
Создадим сущность
«Курс». Одно лишь название курса не может быть первичным ключом, так как, например, «Матанализ» может читаться на разных курсах обучения. Поэтому создадим составной первичный ключ:
•
Name (Название): Тип данных —
Varchar(20). Отмечаем как Primary Key.
•
Level (Курс, на котором читается): Тип данных —
Integer. Отмечаем как Primary Key.
Добавим вторичный атрибут
Teacher (Преподаватель), но пока не будем его настраивать.
Сущность «Преподаватель»
Создадим эту сущность и добавим атрибуты:
•
Number (Табельный номер): Тип данных —
Integer. Первичный ключ.
•
Name (Имя): Тип данных —
Varchar.
•
Date_of_Birth (Дата рождения): Тип данных —
Date.
3. Установка связей
Вернемся к сущности «Курс». Атрибут
Teacher, который мы создали ранее как вторичный, нам теперь нужно связать с сущностью «Преподаватель». Удалим старый атрибут
Teacher. Выберем инструмент
Non-Identifying Relationship (неидентифицирующая связь). Проведем линию от сущности «Преподаватель» к сущности «Курс». В результате в таблице «Курс» появится поле
Number как внешний ключ.
Почему связь неидентифицирующая? Первичный ключ курса (
Name +
Level) однозначно определяет сущность. Преподаватель — это важная, но дополнительная характеристика, и его идентификатор не должен входить в состав первичного ключа сущности «Курс».
Теперь свяжем «Курс» и «Студент». Один студент посещает много курсов, и один курс посещает много студентов. Это отношение
«многие ко многим». Выбираем соответствующий инструмент и проводим связь. На логическом уровне она отображается линией с точками на обоих концах.
4. Переход на физический уровень
На этом логическое проектирование завершено. Нажимаем переключение на физический уровень. Внешне модель похожа, но появляется ключевое изменение: для поддержки связи «многие ко многим» автоматически сгенерирована новая,
ассоциативная таблица.
На логическом уровне было достаточно просто нарисовать связь. На физическом уровне для хранения такого отношения обязательно нужна третья таблица. В нашем случае она состоит только из внешних ключей (FK), которые вместе образуют составной первичный ключ:
•
Number (из сущности «Студент»).
•
Name и
Level (из сущности «Курс»).
Каждая строка этой таблицы будет уникальной парой «студент — курс», что и позволяет хранить информацию о посещении. При необходимости в эту ассоциативную таблицу можно добавлять собственные атрибуты, например, «Время начала пары».
На этом простом примере мы увидели, как модель на логическом уровне адаптируется для реализации на физическом уровне в конкретной СУБД.
Краткие итоги
Центральной идеей пройденного этапа становится демонстрация неразрывной связи между концептуальным проектированием структуры данных и его последующей технической реализацией. На первый план выходит понимание того, что профессиональное моделирование — это не просто рисование схем, а создание управляемой и наполненной смыслом архитектуры, готовой к воплощению в коде. Различие между логическим и физическим представлением начинает восприниматься не как формальность, а как два взгляда на одну сущность, каждый из которых решает свою задачу. Логический уровень позволяет абстрагироваться от технических деталей и сосредоточиться на бизнес-правилах: мы оперируем сущностями, атрибутами и связями в их чистом виде, не задумываясь о том, как именно они будут храниться. Переход на физический уровень эту магию раскрывает, показывая, как абстрактная связь «многие ко многим» материализуется в совершенно конкретную дополнительную таблицу, без которой невозможно обойтись в реальной базе данных.
Практическая работа в Erwin Data Modeler наглядно показывает ценность разделения понятий типа данных и домена. Если тип данных — это лишь техническая оболочка, сообщающая системе о характере хранимой информации, то домен становится инструментом наведения порядка на смысловом уровне. Именно через домены в модель закладываются нетривиальные ограничения предметной области, которые предотвращают появление формально корректного, но логически бессмысленного значения. Так, строка, являясь корректным типом для имени, не становится именем до тех пор, пока не пройдет через фильтр домена. Эта логика позволяет перенести часть проверок с уровня приложения на уровень модели данных, делая будущую систему более устойчивой к ошибкам.
Разбор категоризации и разных типов связей формирует навык принятия архитектурных решений. Выбор между идентифицирующей и неидентифицирующей связью перестает быть технической мелочью и превращается в осознанный акт определения зависимости: является ли внешний ключ неотъемлемой частью идентичности сущности или просто значимой характеристикой. Инструмент дискриминатора, в свою очередь, элегантно решает проблему наследования атрибутов, позволяя разделить общие свойства и уникальные характеристики для подтипов одной сущности. Все эти приемы, опробованные на примере учебной модели, складываются в универсальный алгоритм, применимый к задачам любой сложности — будь то проектирование базы для проката автомобилей или кинотеатра.
Мы переходим к созданию схемы данных в Erwin Data Modeler. Это мощное ПО, генерирующее по нарисованной схеме готовый SQL-код для конкретной СУБД.
Интерфейс и уровни проектирования
При создании нового проекта выбираем смешанный, логико-физический уровень. Логический уровень служит для отрисовки сущностей и связей без привязки к технологиям. Физический уровень позволяет добавить детали под целевую СУБД (триггеры, представления). На логическом уровне в панели инструментов доступны: создание сущностей, связей и дискриминатора. На физическом дискриминатора нет, но появляется инструмент для представлений (Views).
Создание сущностей и атрибутов
Создадим сущность «Студент». Через свойства атрибутов добавим поля. Первым создадим поле Number и отметим его как первичный ключ (Primary Key). Для него нужно выбрать тип данных (Integer) и, опционально, домен. Крайне важно различать эти понятия:
• Тип данных — это технический параметр (строка, число, дата).
• Домен — это смысловое ограничение, множество допустимых значений. Например, атрибут «Имя» имеет тип «Строка», но его домен — это легитимные имена, а не любой набор букв. Домен для ИНН — это 12-значное целое число.
Добавим остальные атрибуты студента: Name (Varchar(18)), Date_of_Birth (Date).
Категоризация (Дискриминатор)
Для разделения студентов на категории создадим сущности «Бюджет» и «Плата». Инструментом Sub-Category проводим связь от «Студента» к новым сущностям. Система автоматически копирует первичный ключ (Number) в дочерние таблицы. В свойствах дискриминатора ставим опцию Complete, так как студент обязательно относится к одной из категорий. Добавим в таблицы специфичные поля: Scholarship для бюджетников и Tuition_fee для платников с типом данных Money.
Установка разных типов связей
Создадим сущность «Курс» с составным первичным ключом: Name (Varchar) и Level (Integer). Одного названия недостаточно для уникальности, так как «Матанализ» читают на разных курсах.
Создадим сущность «Преподаватель» с первичным ключом Number (табельный номер).
1. Неидентифицирующая связь: Связываем «Преподавателя» и «Курс». Инструментом Non-Identifying Relationship ведем линию от преподавателя к курсу. В результате в таблице «Курс» появляется поле Number (преподавателя) как вторичный атрибут, а не часть первичного ключа. Это логично: сущность курса однозначно определяется названием и уровнем, а преподаватель — это важное, но не идентифицирующее свойство.
2. Связь «многие ко многим»: Связываем «Студента» и «Курс». Один студент ходит на много курсов, один курс посещает много студентов. Выбираем соответствующий инструмент.
Переход на физический уровень
Переключаемся на физический уровень. Модель внешне не меняется, но происходит важнейшая трансформация: для связи «многие ко многим» автоматически создается третья, ассоциативная таблица. Это техническая необходимость любой реляционной базы данных. Новая таблица состоит из внешних ключей (Number от Студента и Name + Level от Курса), которые вместе образуют ее составной первичный ключ. Именно здесь будут храниться комбинации, показывающие, какой студент на какой курс записан. При необходимости туда можно добавить и собственные атрибуты, например, «оценка» или «время занятия».
Таким образом, мы увидели, как модель адаптируется при переходе от логики к физической реализации.
1. Erwin Data Modeler генерирует не просто визуальную ER-диаграмму, а готовый SQL-код для развертывания базы данных на выбранной платформе.
2. Смешанный (логический/физический) режим позволяет проектировать модель без привязки к СУБД и сразу адаптировать ее под конкретный сервер.
3. Тип данных — это техническая характеристика (Integer, Varchar), а домен — это бизнес-ограничение, определяющее множество допустимых значений атрибута.
4. Графическое представление первичного ключа в Erwin — это перемещение атрибута над горизонтальной чертой внутри сущности.
5. При полном категориальном разбиении (Complete) каждый экземпляр родительской сущности обязательно должен принадлежать одной из подкатегорий.
6. Идентифицирующая связь делает внешний ключ частью составного первичного ключа дочерней таблицы, неидентифицирующая — добавляет его как вторичный атрибут.
7. На логическом уровне связь «многие ко многим» обозначается просто линией, но на физическом она обязательно требует создания третьей, ассоциативной таблицы.
8. При использовании дискриминатора дочерние сущности автоматически наследуют первичный ключ родителя в качестве внешнего ключа.
9. Инструмент представлений (Views) доступен только на физическом уровне модели и будет детально рассмотрен позже.
10. Ассоциативная таблица может содержать не только внешние ключи, но и собственные атрибуты, например, для описания свойств самой связи.
1. В чем ключевое преимущество использования Erwin Data Modeler по сравнению с простым рисованием схем в графическом редакторе?
2. Объясните разницу между логическим и физическим уровнями модели на примере связи «многие ко многим».
3. Что такое домен и чем он принципиально отличается от типа данных?
4. В какой ситуации для атрибута «Название курса» имеет смысл использовать домен, а не только тип данных Varchar?
5. Как визуально на логической схеме в Erwin отличить первичный ключ от неключевого атрибута?
6. Чем идентифицирующая связь отличается от неидентифицирующей? Приведите пример для связи «Аудитория» и «Корпус».
7. Какую роль выполняет инструмент «Дискриминатор» при проектировании категорий, и что означает опция «Complete»?
8. Почему нельзя напрямую, без изменений, перенести логическую схему со связью «многие ко многим» в реальную реляционную базу данных?
9. Из каких полей будет состоять первичный ключ ассоциативной таблицы, созданной для связи сущностей «Студент» и «Курс» в нашем примере?
10. Для чего может потребоваться создание пользовательского домена, например, для атрибута «Код договора»?
