1.3 Архитектура бд

Понятие БД является одним из важнейших в теории БД и служит основой для понимания возможностей современных СУБД.

Национальный институт стандартизации США (ANSI) и комитет по планированию выпуска стандартов и технических условий (SPARC) определяют три различные модели данных в соответствии с уровнями абстракции: концептуальную (conceptual), внешнюю (external) и внутреннюю (internal). Эти традиционные модели данных необходимо расширить, добавив физическую (physical) модель данных, чтобы в этой классификации нашли отражение проблемы реализации, специфичные для СУБД во внутренней модели. К тому же, чтобы отразить представление данных со стороны проектировщика, необходимо явно выделить связь между внешней моделью данных и внутренней моделью.

Концептуальная модель

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

Концептуальная модель – основа для идентификации и описания основных объектов данных за исключением подробностей. Наиболее широко используемая концептуальная модель – модель «сущность-связь» (ER-модель), рассмотренная в п. 1.5.

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

Внутренняя модель

После выбора определенной СУБД концептуальная модель адаптируется к ней с помощью внутренней модели. Внутренняя модель (internal model) есть представление БД с точки зрения СУБД. Т.е. внутренняя модель требует, чтобы проектировщик привел свойства и ограничения концептуальной модели в соответствие с выбранной моделью реализации БД. Поскольку внутренняя модель зависит от существующего специфичного программного обеспечения БД, говорят, что она программно-зависима. Поэтому изменения в программном обеспечении СУБД потребуют изменений во внутренней модели.

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

Внешняя модель

Внешняя модель (external model) основана на внутренней модели и отражает представление конечного пользователя о конфигурации данных. Конечные пользователи – это люди, использующие прикладные программы. Они обычно оперируют приложениями в определенных подразделениях.

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

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

Использование внешних модулей дает следующие важные преимущества:

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

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

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

создание внешних моделей помогает обеспечить безопасность при проектировании БД. Гораздо труднее разрушить БД, если каждое подразделение работает только с ее подмножеством.

Внешняя модель зависит от СУБД, но не зависит от аппаратных средств, т.к. она проектируется для конкретной СУБД и не зависит от оборудования, на котором реализуется система в целом. Следовательно, при подключении и установке новых аппаратных средств спроектированные внешние схемы изменять не придется.