Этапы проектирования баз данных: от инфологической модели до схемы хранения

От инфологической модели до схемы хранения

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

Из каких этапов складывается проектирование

Весь процесс создания базы данных принято разбивать на пять последовательных этапов:

1. Инфологическое проектирование базы данных.
2. Формулировка требований к операционной обстановке, в которой предстоит работать информационной системе.
3. Выбор СУБД и прочего программного обеспечения.
4. Логическое проектирование базы данных.
5. Физическое проектирование базы данных.

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

Инфологическое проектирование

Первый этап — самый «человеческий». Здесь разработчик ещё не думает о конкретной СУБД или структуре хранения, а сосредотачивается на том, как устроена сама предметная область.

Такая модель описывает не только структуру, но и динамику предметной области, а также характер информационных потребностей пользователей. Иными словами, она фиксирует типы объектов, связанные с ними ограничения целостности и те процессы, которые переводят предметную область из одного состояния в другое.

Три подхода к построению модели

Подступиться к инфологической модели можно тремя разными способами:

• Функциональный подход («от задач»). Его применяют, когда заранее известны функции комплекса задач или круг лиц, чьи информационные потребности предстоит обслуживать. Отталкиваются здесь именно от того, что система должна делать.
• Предметный подход. Он уместен, когда есть ясное представление о самой предметной области и о видах хранимой информации, но структура будущих запросов пока не определена.
• Метод «сущность-связь». По сути, это сочетание двух предыдущих подходов, вобравшее их сильные стороны. Именно на нём мы остановимся подробнее.

Локальные представления

Проектирование по методу «сущность-связь» стартует с моделирования предметной области. Разработчик дробит её на несколько отдельных участков, и каждый такой участок должен содержать достаточно сведений, чтобы обслужить запросы конкретной группы пользователей или решить отдельную задачу. Сначала каждое локальное представление моделируют по отдельности, а затем все они объединяются в единое целое.

На то, каким получится локальное представление, влияет масштаб предметной области. Обычно её разбивают так, чтобы в каждую область попадало примерно шесть-семь сущностей, а сама она соответствовала отдельному внешнему приложению. Такой размер удобно охватить взглядом и не запутаться в связях.

Атрибуты сущностей

Для каждой сущности определяют её атрибуты. Их принято делить на несколько пар по разным признакам:

• описательные и идентифицирующие — одни просто характеризуют объект, другие помогают его опознать;
• простые и составные — единое значение против нескольких объединённых;
• основные и производные — хранимые напрямую против вычисляемых из других;
• однозначные и многозначные — одно значение против набора значений.

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

Связи внутри представления

После атрибутов очередь доходит до связей внутри локального представления. Каждую связь характеризуют именем, обязательностью (обязательная или факультативная), степенью и типом — 1:1, 1:М либо М:М.

Отдельного внимания заслуживает степень связи — она показывает, сколько сущностей охвачено данной связью. Скажем, связь между отделом и работающими в нём сотрудниками будет бинарной, ведь в ней участвуют две сущности. А вот связь ЭКЗАМЕН, соединяющая дисциплину, студента и преподавателя, — уже тернарная, поскольку в неё вовлечены сразу три сущности.

Объединение локальных представлений

Когда все локальные представления готовы, их сводят воедино. При объединении важно отыскать и устранить любые противоречия между ними. Если противоречие всплывает, приходится возвращаться назад — к этапу моделирования локальных представлений — и вносить правки. Только согласованная общая модель годится для дальнейшей работы.

Определение требований к операционной обстановке

Второй этап переводит разговор из плоскости логики в плоскость «железа» и системного окружения. Здесь оценивают, какие вычислительные ресурсы понадобятся системе для нормальной работы.

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

Выбор СУБД и другого программного обеспечения

Третий этап во многом задаёт рамки всему последующему проектированию — ведь выбранная СУБД напрямую влияет на то, как будет устроена база.

На практике разработчики опираются на такой набор критериев:

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

Взвесив все эти факторы, выбирают систему, которая лучше всего отвечает задачам проекта и его бюджету.

Логическое проектирование базы данных

На четвёртом этапе абстрактная инфологическая модель обретает конкретную логическую форму.

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

Физическое проектирование базы данных

Заключительный, пятый этап отвечает на вопрос, как именно данные разместятся в памяти.

Физическое проектирование — это отображение логической структуры базы данных в структуру хранения. На этом этапе решают, как разместить данные в памяти, и подбирают эффективные методы доступа к разным компонентам базы.

Итогом становится схема хранения, также записанная на языке определения данных (DDL). Но физическим проектированием дело не ограничивается: один из важнейших моментов здесь — разработка средств защиты базы данных. Их принято делить на два направления:

• защита от сбоев — реализуется через резервное копирование, которое позволяет восстановить данные после аварии;
• защита от несанкционированного доступа — обеспечивается тем, что каждому пользователю выдаётся соответствующее право доступа к данным.

Пять этапов удобно держать в голове как единую цепочку «от смысла к хранению». Сначала инфологическое проектирование отвечает на вопрос «что и о чём мы храним», причём метод «сущность-связь» помогает описать это через сущности, атрибуты и связи. Затем определяют операционную обстановку — «на чём это будет работать». Выбор СУБД задаёт рамки — «в какой системе». Логическое проектирование переводит модель в схемы на языке DDL — «как это устроено логически». И наконец, физическое проектирование решает, «где и как данные лягут в память», добавляя защиту от сбоев и от чужих рук. Пропуск любого звена рано или поздно обернётся переделками, поэтому двигаться стоит строго по порядку.