Независимость данных. Трехуровневая модель описания данных.
Независимость данных и программ
Данные должны быть отделены от исполняемых программ по следующим причинам:
• обеспечение возможности доступа к данным нескольких различных программ;
• программы живут и умирают, а данные остаются...
С этими понятиями связан термин DDL (Data Definition Language) — часть языка, которая работает
с определениями данных, то есть управляет метаданными. Язык описания данных, не зависящий от языка программирования (DDL)
Модель описания данных CODASYL (англ. COnference on DAta SYstems Language — Конференция по языкам систем обработки данных, 1975):
• Внешние схемы (подсхемы) определяют структуру данных, видимую в приложениях. Данные сильно
отличаются от их представления в БД. Они могут быть по-разному сформированы, отсортированы.
Внешняя часть очень часто смешивается с логикой работы приложения
• Концептуальная (логическая) схема определяет структуру данных, видимую СУБД
• Схема хранения (физическая схема) определяет размещение данных и пути доступа к данным
• Обеспечивает независимость данных
[Нигде не написано все же про определение независимости данных. Предлагаю вытянуть следующее, тем более что в (быдло-)источниках, в которых я смотрел, определения более-менее совпадают:
В технологиях баз данных одной из ключевых концепций является концепция независимости данных. Различают логическую и физическую независимость данных.
Обеспечение логической независимости данных означает способность СУБД предоставлять администратору системы базы данных определенную степень свободы вариации логического представления базы данных без необходимости соответствующей модификации приложений и пользовательских запросов.
Под физической независимостью данных понимается способность СУБД предоставлять администратору системы базы данных некоторую свободу модификации способов организации базы данных в среде хранения, не вызывая необходимости внесения соответствующих изменений в логическое ее представление. Благодаря этому можно вносить изменения в организацию хранимых данных, производить настройку системы с целью повышения ее производительности и эффективности использования ресурсов памяти для хранения базы данных, не затрагивая созданных прикладных программ, использующих базу данных.
ВФ]
• Трехуровневая модель:
– Внешняя схема (описывает структуры данных, предоставляемые приложению)
– Концептуальная схема (описывает полную логическую структуру хранимых данных) (например, типы данных, числа строки, агрегаты, ограничения целостности и т.п.)
– Схема хранения (описывает представление концептуальной схемы на носителях данных)
• Никогда не была полностью реализована, но полезна как система понятий
• В реальных системах схемы могут быть совмещены
Основные функции субд. Архитектуры приложений, использующих субд.
• Управление логической структурой данных, абстракция.
Это требование главным образом связано с удобством управления БД. Человек не должен задумываться над особенностями физической реализации. Главный смысл абстракции — освободить человеческий разум от обдумывания лишних деталей, тем самым позволив сосредоточиться ему на самой проблеме (разработке БД).
• Независимость данных и программ
• Безопасность данных и разграничение доступа к данным (защита от несанкционированного доступа)
• Целостность данных (integrity)
Проблема, рассматриваемая в этом пункте, есть проверка на корректность данных.
• Высокоуровневые языки запросов, ad hoc запросы
Высокоуровневый язык запросов обеспечивает простоту разработки приложений, так же как и независимость данных, в силу чего изменения низкоуровневых деталей доступа не требуют от пользователя переработки его приложений.
• Конкурентный доступ к общим (разделяемым) данным
Конкурентный доступ к данным даёт большую скорость обмена данными и более простые клиентские приложения.
• Согласованность (consistency) и устойчивость при отказах
Проблема, рассматриваемая в этом пункте, есть проверка на согласованность данных, даже при наличии отказов при выполнении операции.
Очень важно отличать целостность БД от согласованности. Целостность есть совокупность правил, которые ни при каких обстоятельствах не могут быть нарушены, например: зарплата не может быть минусовой, адрес не может состоять из одной буквы, не может быть двух человек в одной стране с одинаковым ИНН.
Согласованность есть некоторое состояние, при осуществлении некоторой операции согласованность может нарушаться, но по её завершении БД должна вернуться в согласованное состояние. Например, пусть БД остаётся в согласованном состоянии, если баланс счёта (при пере воде денег с одного на другой) сохраняется. Тогда в процессе выполнения операции на некоторое время баланс может нарушиться, но после выполнения либо оно должно быть восстановлено (если произошла ошибка при переводе), либо должны быть переведены деньги с сохранением общего баланса.
• Сложные структуры данных
Клиент-сервер (1965) - процесс(ы) СУБД принимают и выполняют запросы прикладных программ. Сервер необходим для поддержки конкурентного доступа к разделяемым данным. Потенциально обеспечиваются все основные функции СУБД в полном объеме. Поддерживается всеми большими СУБД.
Однопользовательские/встроенные СУБД (1975) - ограниченный набор функций СУБД для изолированных приложений. Основной чертой таких систем является непереносимость. Компоненты БД выполняются в процессах приложений (как подпрограммы). Ограниченный набор функций БД (не может быть обеспечен разделяемый доступ, безопасность и отказоустойчивость). Производительность невысока. Чаще всего – однопользовательские системы. Встраивание приложений в БД (MS Access). Полезны в составе распределенных систем.
Многоуровневые архитектуры (мониторы транзакций, серверы приложений) - часть функций СУБД выполняет сервер приложений, приложения могут использовать несколько независимых СУБД. Приложения взаимодействуют с СУБД через «средний слой». Часть функций СУБД выполняется средним слоем. Мониторы транзакций, серверы приложений. Примеры: IBM CICS (1967), BEA Tuxedo, BEA WebLogic.
Я сюда запосчу картинку из Молинки:
(далее материал из интернетов)
Принцип многоуровневой архитектуры, который заключается в реализации двух основных принципов:
- минимизация функциональности клиентских компонентов, оставляющая за клиентом только функции пользовательского интерфейса; максимальное упрощение и унификация клиентского программного обеспечения;
- освобождение сервера БД от несвойственных ему функций.
На практике эти принципы реализуются введением в систему дополнительного звена — сервера приложений.
Такие архитектуры более разумно распределяют модули обработки данных, которые в этом случае выполняются на одном или нескольких отдельных серверах. Эти программные модули выполняют функции сервера для интерфейсов с пользователями и клиента — для серверов баз данных. Кроме того, различные серверы приложений могут взаимодействовать между собой для более точного разделения системы на функциональные блоки, выполняющие определенные роли.
Вообще говоря, термин ``многоуровневые архитектуры'' не предполагает какого-либо определенного принципа построения системы. Данное понятие применяется для характеристики любых архитектур, расширяющих схему клиент-серверного взаимодействия путем введения дополнительных промежуточных компонентов. Отдельно следует отметить многоуровневые системы на основе менеджеров транзакций (модель ТМ), которые позволяют одному серверу приложений одновременно обмениваться данными с несколькими серверами баз данных, что наиболее важно с точки зрения построения распределенной информационной системы, предназначенной для интеграции информационных ресурсов. Менеджер транзакций — это приложение, с помощью которого можно согласовать работу различных компонентов информационной системы.
Основные задачи, для решения которых применяется многоуровневый подход, обычно сводятся к следующим:
- повышение производительности системы за счет переноса части функциональности на аппаратно выделенные сервера приложений;
- повышение структурированности программных систем за счет реализации компонентов в виде независимых модулей (объектов), допускающих повторное использование; обеспечение возможности комплектации готовой системы из таких модулей;
- потребность в интеграции различных приложений в едином интерфейсе -- формирование доступа ко всем ресурсам и программным средствам через единую точку входа (портал).
- Централизованная бизнес-логика. Как мы уже знаем, бизнес-логикой называют некоторые правила обработки данных. Например, удаляя запись из одной таблицы, требуется удалить связанные с ней записи других таблиц. В обычных файл-серверных или клиент-серверных приложениях, часть бизнес-логики ложилась на клиентское приложение. При необходимости изменения каких-то правил, приходилось переделывать клиентское приложение, затем тратить усилия на его распространение на клиентские ПК. Теперь же эта бизнес-логика хранится на уровне сервера приложений, и при ее изменении клиенты сразу получают возможность работать по новым правилам.
- Архитектура "тонкого" клиента. Как известно, для получения данных из БД приложения используют один из механизмов доступа к данным - BDE, ADO, ODBC, IBX, dbExpress и т.п. Все это приводит к тому, что на ПК каждого клиента приходится устанавливать и настраивать соответствующие драйверы, а это сильно усложняет процесс распространения приложения. В многозвенной архитектуре механизмы доступа к данным располагаются на сервере приложений. Только там нужно устанавливать эти драйверы (например, BDE). Клиентские же машины не нуждаются в них, за что и называются "тонкими".
- Модель "портфеля" (briefcase model). Модель "портфеля" подразумевает возможность отложенной обработки данных. Представьте, что вам в выходные дни требуется проделать какую-то работу с данными. При использовании файл-серверной или клиент-серверной модели, вам для этой работы придется прибыть в офис, иначе вы не сможете получить доступа к данным. В многоуровневой модели вы можете сохранить на переносном ПК все необходимые вам данные в виде локального файла. Дома вы сможете загрузить этот файл, и провести необходимую работу с данными. Затем, прибыв в офис, вы сможете перенести эти изменения в реальную базу данных.
- Снижение трафика сети. За счет возможности отложенной обработки данных значительно снижается нагрузка на сеть.