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

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

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

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

Чтобы добиться такого результата, используются общепринятые этапы проектирования (концептуальное, логическое и физическое проектирование).

В данном эссе рассмотрим основные проблемы, усложняющие проектирование баз данных на конкретных этапах.

Модели построения БД

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

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

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

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

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

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

Проблемы проектирования баз данных

Концептуальное проектирование баз данных

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

Исходя из вышеперечисленного выделим сложности данного этапа.

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

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

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

На данном этапе, полученная концептуальная модель БД (полученная на предыдущем этапе) уточняется и преобразуется в логическую модель данных. Логическая модель должна учитывать наиболее подходящую модель системы управления БД (реляционная, иерархическая, объектно-ориентированная, сетевая) и инструментальные средства программного характера. Нередко связан с внесением поправок в концептуальную модель.

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

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

Данный этап является заключительным и здесь принимаются решения

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

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

Заключение

Создание БД – итерационный процесс (имеет начало, но не имеет конца, так как постоянно требует правок, уточнений и изменений).

Важную роль в процессе проектирования БД играет задача четкого определения: где и как будет использоваться БД, так как от этого будут зависеть последующие этапы проектирования.

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

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