Что представляет собой трехуровневая архитектура субд кратко

Обновлено: 07.07.2024

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

Описание структуры данных на любом уровне называется схемой.

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

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

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

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

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

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

Что такое трехуровневая архитектура?

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

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

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

Подробное описание трех уровней

Уровень представления

На уровне представления обеспечивается взаимодействие с пользователем приложения — это пользовательский интерфейс и уровень обмена данными. Его основное предназначение состоит в отображении информации и получении информации от пользователя. Этот уровень может работать в веб-браузере или как графический пользовательский интерфейс компьютерного или мобильного приложения. Уровни представления веб-приложений обычно разрабатываются с помощью HTML, CSS и JavaScript. Компьютерные и мобильные приложения могут быть написаны на любом языке в зависимости от платформы.

Уровень приложений

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

Как правило, уровень приложения разрабатывается с помощью Python, Java, Perl, PHP или Ruby и взаимодействует с уровнем данных посредством вызовов API.

Уровень данных

Уровень данных, который также называется уровнем базы данных, уровнем доступа к данным или базовым уровнем, предназначен для хранения и управления информацией, обработанной приложением. Его роль может выполнять реляционная система управления базами данных, такая как PostgreSQL, MySQL, MariaDB, Oracle, DB2, Informix или Microsoft SQL Server, либо сервер базы данных NoSQL, такой как Cassandra, CouchDB или MongoDB.

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

Слои и уровни

В контексте трехуровневой архитектуры термины уровень (tier) и слой (layer) часто используются как взаимозаменяемые, однако это не совсем справедливо.

Эта разница имеет важное значение, поскольку слои не позволяют получить те преимущества, которые дает разделение по уровням.

Преимущества трехуровневой архитектуры

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

Другие преимущества (по сравнению с одноуровневой и двухуровневой архитектурой):

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

Трехуровневое приложение в веб-разработке

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

Другие многоуровневые архитектуры

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

Двухуровневая архитектура

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

N-уровневая архитектура

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

Трехуровневая архитектура и IBM Cloud

IBM Cloud предлагает продукты и услуги, помогающие модернизировать устаревшие трехуровневые приложения в процессе перехода в облако.

1. Архитектура базы данных. Физическая и логическая независимость

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

В процессе научных исследований, посвященных тому, как именно должна быть устроена СУБД, предлагались различные способы реализации. Самым жизнеспособным из них оказалась предложенная американским комитетом по стандартизации ANSI (American National Standards Institute) трехуровневая система организации БД, изображенная на рис. 2.1.

1978 год – появился стандарт, который принял коммитет ANSI/SPARC, который фиксирует разделение между логическим и физическим представлением данных. В часности, была предложена 3-х уровневая модель данных, т.е. обобщенная структура.

Рис. 1 - Трехуровневая модель системы управления базой данных, предложенная ANSI

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

Эта архитектура позволяет обеспечить логическую (между уровнями 1 и 2) и физическую (между уровнями 2 и 3) независимость при работе с данными. Логическая независимость предполагает возможность изменения одного приложения без корректировки других приложений, работающих с этой же базой данных. Физическая независимость предполагает возможность переноса хранимой информации с одних носителей на другие при сохранении работоспособности всех приложений, работающих с данной базой данных. Это именно то, чего не хватало при использовании файловых систем. Выделение концептуального уровня позволило разработать аппарат централизованного управления базой данных.

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

Введение 3-уровневой архитектуры БД позволило отделить пользовательское представление БД, от её физического представления. На пользовательском уровне невозможно внести изменения в структуру хранения данных, т.е. обращение никак не зависит от структуры БД. Кроме этого, администратор, внося изменения в уже существующую БД, не тревожит пользователя.

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

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

Внешний уровень – определяет пользовательские представления данных.

На певом этапе всегда разрабатывают концептуальную модель (схему). Она делает отражение внутреннего уровня на внешний.

Главное назначение трёхуровневой архитектуры – это обеспечение независимости от данных (внутеннего образа хранение от отображения). Независимость от данных бывает 2-х типов:

- логическая – это полная защищенность внешних схем от изменений, которые вносятся в концептуальную схему;

- физическая – это защищенность концептуальной схемы, от изменений, которые вносятся во внутреннюю схему.

2. Этапы жизненного цикла СУБД

Рис. 2 - Жизненный цикл баз данных

Последовательность задач, которые необходимо рассмотреть на первом этапе.

(План выполнения работ)

- Сформулировать перечень вопросов, которые будут решены при испльзовании новой ИС.

- Выяснить технические возможности для эксплуатации базы данных.

- Выбрать ИС, которая будет разрабатываться (обосновать с учетом предыдущих пунктов).

После этого уже можно выполнять этап проектирование.

В часности, это –– водопадный подход.

Основные действия, выполняемые на каждом этапе жизненного цикла СУБД:

1) Планирование разработки БД. На этом этапе рассматривают самые эффективные методики.

2) Определение требований к системе. Диапазон действия БД, состав пользователей, области применения.

3) Сбор и анализ требований пользователей.

4) Проектирование БД. Проведение концептуального, логического и физического проектирование БД.

5) Реализация БД. Создание структуры данных, интерфейса пользователя и т.д., т.е. ПО.

7) Конвертирование и загрузка данных. Этот этап для новых БД не существенно, а для переделанных – очень важно (например, смена ОС).

8) Эксплуатация и сопровождение. Для всех БД актуален. Администрирование. Доработка концептуальной схемы.

2.1. Жизненный цикл базы данных

ЖЦБД включает в себя следующие основные этапы:

- планирование разработки базы данных;

- определение требований к системе;

- сбор и анализ требований пользователей;

- проектирование базы данных (концептуальное, логическое, физическое);

- разработка приложений (проектирование транзакций; проектирование пользовательского интерфейса);

- эксплуатация и сопровождение (а: анализ функционирования и поддержка исходного кода БД, б: адаптация, модернизация и поддержка переработанных вариантов).

Здесь представлен перечень основных этапов ЖЦБД. Естественно, что конкретное наполнение каждого этапа в значительной степени зависит от сложности разрабатваемого продукта.

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

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

2.2. Планирование разработки базы данных

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

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

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

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

Вторая часть – проверка операционной осуществимости — выяснение наличия экспертов и персонала, необходимых для работы БД.

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

- целесообразность совместного использования данных разными отделами;

- величина риска, связанного с реализацией системы базы данных;

- ожидаемая выгода от внедрения подлежащих созданию приложений;

- время окупаемости внедренной БД;

- влияние системы управления БД на реализацию долговременных планов организации.

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

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

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

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

На данном этапе необходимо определить диапазон действия приложения базы данных, состав его пользователей и области применения.

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

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

2.4. Сбор и анализ требований пользователей

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

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

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

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

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

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

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

2.5. Проектирование базы данных

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

Основными целями проектирования базы данных являются:

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

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

- разработка предварительного варианта проекта, структура которого позволяет удовлетворить требования, предъявляемые к производительности системы.

В создании БД как модели ПрО (предметной области) выделяют:

- объектную (предметную) систему, представляющую фрагмент реального мира;

- информационную систему, описывающую некоторую объектную систему;

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

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

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

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

Существует два основных подхода к проектированию систем баз данных: "нисходящий" и "восходящий".

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

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

Нисходящий подход демонстрируется в концепции модели "сущность-связь" (Entity - Relationship model – ER-модель) - cамой популярной технологии высокоуровнего моделирования данных, предложенной Ченом.

Помимо "нисходящего" и "восходящего" подходов, для проектирования баз данных могут применяться другие подходы, являющиеся некоторыми комбинациями указанных.

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

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

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

- Выделение ключевых атрибутов.

- Спецификация связей между объектами. Удаление избыточных связей.

- Анализ и добавление не ключевых атрибутов.

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

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

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

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

3. Особенности проектирования СУБД и модели данных

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

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

2) Исключение ненужного повторения данных, которое может явится причиной ошибок при вводе.

3) Обеспечение целостности данных таким образом, что бы при изменении одних объектов автоматически происходило соответствующее изменение связанных с ним объектом.

Можно выделить 2 подхода к проектированию реляционной БД (основаны на нисходящем и восходящем подходах).

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

2) Второй подход основан на концептуальной модели данных. После создания концептуальной модели можно механически провести преобразование в реляционную модель. При этом гарантируется получение нормализованной реляционной модели. Это – нисходящий подход к проектированию. При таком подходе следует создать концептуальную схему в виде набора объектов и связей между ними.

4. Избыточность данных в БД

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

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

Архитектура СУБД. Архитектура баз данных. Логическая структура СУБД. Описание данных в базе данных. Базы данных схема данных

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

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

Число уровней описания зависит от реализации сервера баз данных или от реализации СУБД. Существует одноуровневая система управления базами данных. Двух уровневая СУБД и трехуровневая СУБД. Рассматривать одноуровневые и двухуровневые СУБД нет смысла, поскольку в настоящее время используются в основном трехуровневые системы. Системы с трехуровневым описанием данных имеют три уровня абстракции, на которых можно осуществляется взаимодействие с базой данных. И так, перейдем к делу.

Трехуровневая архитектура баз данных. Три уровня абстракции описания данных.

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

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

Для наглядности можете посмотреть на рисунок, на нем продемонстрирована структура трехуровневой СУБД:

Структура базы данных

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

Базы данных. Схема данных. Независимость уровней от данных.

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

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

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

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

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

Внешний уровень абстракции. Внешняя схема данных. Внешнее представление базы данных.

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

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

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

Концептуальная схема данных. Концептуальное представление базы данных.

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

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

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

Внутренний уровень абстракции. Внешняя схема данных. Внутреннее представление базы данных.

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

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

Любая внутренняя схема данных обязательно хранит в себе:

То, как должно быть распределено дисковое пространство для хранения данных и индексы
Информацию о сохраненных записях
Сведения о уже имеющихся записях
Сведения о способах шифрования и сжатия данных

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

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

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

В процессе научных исследований, посвященных тому, как именно должна быть устроена СУБД, предлагались различные способы реализации. Самым жизнеспособным из них оказалась предложенная американским комитетом по стандартизации ANSI (AmericanNationalStandardsInstitute) трехуровневая система организации БД, изображенная на рис. 1:

Рис. 1. Трехуровневая модель системы управления базой данных, предложенная ANSI

Архитектура включает три уровня: внутренний, концептуальный и внешний. В общих чертах они представляют собой следующее:

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

Внешний - наиболее близок к пользователям, т.е. он связан со способами представления данных для отдельных пользователей.

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

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

2. Концептуальный уровень — центральное управляющее звено, здесь база данных представлена в наиболее общем виде, который объединяет данные, используемые всеми приложениями, работающими с данной базой данных. Фактически концептуальный уровень отражает обобщенную модель предметной области (объектов реального мира), для которой создавалась база данных. Как любая модель, концептуальная модель отражает только существенные, с точки зрения обработки, особенности объектов реального мира. Концептуальная схема - это определение концептуального представления. В большинстве существующих систем концептуальная схема в действительности представляет собой немного больше, чем простое объединение всех отдельных внешних схем с дополнительными средствами безопасности и правилами обеспечения целостности.

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

9. Реляционная модель базы данных.

Теоретической основой этой модели стала теория отношений, основу которой заложили два логика — американец Чарльз Содерс Пирс (1839-1914) и немец Эрнст Шредер (1841-1902). В руководствах по теории отношений было показано, что множество отношений замкнуто относительно некоторых специальных операций, то есть образует вместе с этими операциями абстрактную алгебру. Это важнейшее свойство отношений было использовано в реляционной модели для разработки языка манипулирования данными, связанного с исходной алгеброй. Американский математик Э. Ф. Кодд в 1970 году впервые сформулировал основные понятия и ограничения реляционной модели, ограничив набор операций в ней семью основными и одной дополнительной операцией.

Основной структурой данных в модели является отношение, именно поэтому модель получила название реляционной (от английского relation — отношение).

Любые данные, используемые в программировании, имеют свои типы данных.

Реляционная модель требует, чтобы типы используемых данных были простыми.

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

Простые типы данных.

Структурированные типы данных.

Ссылочные типы данных.

Простые, или атомарные, типы данных не обладают внутренней структурой. Данные такого типа называют скалярами. К простым типам данных относятся следующие типы: Логический, Строковый, Численный[2] .

Различные языки программирования могут расширять и уточнять этот список, добавляя такие типы как:

Читайте также: