kazminaviktoriya1
В профиль
Выход
![](data:image/svg+xml,<svg xmlns="http://www.w3.org/2000/svg" width="42" height="42"><rect fill-opacity="0"/></svg>)
Добавить аккаунт
Спринт 5/16: Моделирование данных → Тема 2/4: Проектирование баз данных → Урок 3/6
Переход от логической ER-модели к физической
Вы уже знаете, что такое ER-модель данных, какие уровни у неё есть, как графически представить логическую ER-модель данных. Как вы помните, за логическим уровнем ER-модели следует физический. В этом уроке вы узнаете, как переходить от логической модели данных к физической, на какие шаги делится этот процесс и кто им занимается.
Если вам кажется, что при прохождении урока вы запутались или устали, сделайте паузу и вернитесь к нему позже. Материал окончательно уложится в голове, когда вы выполните домашнее задание.
Физическая ER-модель — это описание того, как с помощью определённой технологии разработать логическую ER-модель. Как вы помните, цель физического уровня ER-модели — описать структуру будущей базы данных.
Для одной логической ER-модели можно составить несколько физических. Всё зависит от выбора конкретной СУБД. В будущей базе данных сущности рассматриваются как таблицы, а атрибуты сущностей — как поля таблиц.
Кто составляет физическую модель
Целевая аудитория моделей физического уровня — архитекторы баз данных и программисты. Именно они отвечают за реализацию модели в конкретной СУБД. Как правило, эти члены команды разработки и занимаются созданием физической модели, а системный аналитик им помогает.
В процессе моделирования системный аналитик определяет данные, которые нужны приложению, и создаёт ER-диаграммы логического уровня, отображающие представление бизнеса о данных. Но эти модели не учитывают детали реализации. После того как команда определилась с форматом хранения данных, из логических моделей создают физические. Это позволяет визуализировать, что нужно СУБД для формирования базы данных.
Как перейти от логической ER-модели к физической
Логическую ER-модель можно перевести в физическую за пять шагов. Для этого нужно:
- Шаг 1. Преобразовать сущности в таблицы.
- Шаг 2. Преобразовать атрибуты в поля.
- Шаг 3. Добавить первичные ключи.
- Шаг 4. Добавить внешние ключи.
- Шаг 5. Добавить системные таблицы и поля.
Рассмотрим, как это работает на примере логической ER-модели CRM-системы фитнес-центра (она знакома вам из урока по нормализации).
Шаг 1. Преобразовать сущности в таблицы
На этом этапе все сущности в логической ER-диаграмме нужно изменить так, чтобы отобразить на диаграмме структуру файлов (если выбор в пользу файлового хранилища) или таблицы, которые будут использоваться для хранения данных.
Обычно команды разработки придерживаются строгих договорённостей по поводу имён для таблиц и полей или файлов. В ER-модели физического уровня будут использоваться имена, которые получат компоненты уже реальной базы данных (диаграмма отображает то, что должно содержаться в БД).
Например, в СУБД PostgreSQL, с которой вы познакомитесь поближе в следующем уроке, названия можно добавить только на английском языке, поэтому сущность «посетитель» из ER-диаграммы логического уровня в физической модели будет отображаться как
client, а атрибут «номер клубной карты» как cl_card_number.
Существуют различные типы данных с полями, чьи названия могут отличаться в разных СУБД.
Шаг 2. Преобразовать атрибуты в поля
Атрибуты сущностей нужно преобразовать в поля (столбцы в файлах или таблицах) и добавить к ним на диаграмме метаданные, например тип данных (
integer, date и так далее), длину поля ((3), (6) и прочие) и допустимое значение (ограничения) — фиксированный список возможных значений для определённого столбца (например NULL или NOT NULL). Метаданные — это описание любой структуры данных или «данные о данных». Подробнее о них вы узнаете в следующем уроке.Так будет выглядеть физическая модель после того, как атрибуты преобразовали в поля, к которым добавили метаданные.
Шаг 3. Добавить первичные ключи
Теперь в физическую модель нужно добавить первичные ключи (primary key). Для физического уровня ER-моделей первичный ключ — это поле (или набор полей) таблицы, значения которого уникальны для каждой записи.
Первичные ключи делятся на два вида:
- Естественный ключ (бизнес-ключ) — уникально определяющий сущность набор полей (например, номер СНИЛС).
- Суррогатный ключ — автоматически сгенерированное поле (например, порядковый номер), не связанное с информационным содержанием записи.
Вы уже знаете, что первичные ключи могут быть простыми и составными. Естественные и суррогатные ключи — это, скорее, другое «измерение» первичного ключа, но они также могут быть простыми и составными.
Без первичного ключа не обходится ни одна таблица физической модели. Чтобы создать его на физическом уровне, можно преобразовать в естественные первичные ключи атрибуты, которые составляли первичный ключ в логической модели. Например, номер клубной карты может быть естественным ключом для таблицы
client, если каждая запись клиента (посетителя) в таблице будет содержать уникальное значение в поле cl_card_number. Если в логической модели первичный ключ не выделялся (как для сущности «тренировки посетителя» —
client_training), в физическую модель для этой таблицы нужно добавить суррогатный ключ, например поле cl_tr_id. Это поле ничего не значит для предметной области, которая рассматривается в моделях более высокого уровня (концептуальном и логическом), но на физическом уровне оно обеспечивает уникальность каждой записи будущей базы данных.В физической модели данных первичные ключи обоих видов отображаются одинаково — аббревиатурой PK — primary key.
Шаг 4. Добавить внешние ключи
Отношения в логической модели показывают, что пары сущностей связаны друг с другом, задача этого этапа — указать, как связи будут поддерживаться с технической точки зрения. Например, в реляционной базе данных связь между двумя таблицами поддерживается внешним ключом (foreign key).
Внешний ключ — это поле (поля) первичного ключа из одной таблицы, которое повторяется в другой (связанной) таблице, чтобы обеспечить общее поле между этими таблицами.
В общем поле содержатся одинаковые для обеих таблиц значения. Рассмотрим таблицы с именами
client и tariff, которые нужно связать друг с другом в физической модели. Для этого поле первичного ключа из tariff (tariff_number) нужно включить в таблицу client. Теперь, если нужно узнать о тарифе посетителя, при просмотре данных о посетителе можно использовать значение tariff_number, чтобы найти нужную информацию в таблице со всеми тарифами.В физической модели поля первичного ключа из родительских таблиц (связь «один и только один») копируются и помещаются в дочерние (связь «ноль и более») и обозначаются как внешние ключи (аббревиатурой FK — foreign key).
Шаг 5. Добавить системные таблицы и поля
В физическую модель данных можно добавлять компоненты, отображающие особые потребности реализации. Например, чтобы контролировать корректность значений, вводимых в поля адреса таблицы
manager, может потребоваться внешний справочник (библиотека проверочных значений) с перечнем адресов. Для этого в физическую модель нужно добавить таблицу address, обозначив её поля и связи с другими таблицами.
Готово, вы восхитительны! Теперь у вас на руках физическая ER-модель данных.
Она визуализирует все параметры, которые нужны для создания базы данных приложения. Системный аналитик может передать её дальше — разработчикам, которые и займутся созданием базы данных.
Подведём итоги
Перевести логическую модель данных в физическую можно за пять шагов:
- Шаг 1. Преобразовать сущности в таблицы.
- Шаг 2. Преобразовать атрибуты в поля.
- Шаг 3. Добавить первичные ключи.
- Шаг 4. Добавить внешние ключи.
- Шаг 5. Добавить системные таблицы и поля.
Первичные ключи бывают двух видов: естественные и суррогатные. Естественные имеют значение для предметной области, а суррогатные имеют значение только на уровне реализации и не относятся к атрибутам сущностей логического уровня.
Внешний ключ — это первичный ключ одной таблицы, который повторяется в другой таблице, чтобы обеспечить связанность между ними.
