Понятие «базы данных». Основные компоненты базы данных.

Понятие «базы данных». Основные компоненты базы данных.

Архитектура системы баз данных.

Архитектура системы базы данных

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

Информационная архитектура

Что такое информационная архитектура?

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

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

Архитектурные уровни

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

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

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

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

Мобильные приложения

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

Функциональная архитектура

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

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

1. поддержку предусмотренных уровней представления данных

2. (концептуальный, внутренний и внешний уровни в терминах архитектуры ANSI/X3/SPARC) и междууровневых отображений данных, ·

3. управление средой хранения данных и методы доступа к ним; · управления транзакциями;

4. поддержку функций администратора системы;

5. физическую и логическую целостность базы данных;

6. разграничение доступа к данным в системе базы данных;

7. интерактивные пользовательские интерфейсы и интерфейсы прикладного программирования, и др.

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

Как уже отмечалось, важное место в функциональной архитектуре системы базы данных занимают механизмы поддержки различных уровней представления данных, в соответствии с архитектурной моделью ANSI/X3/SPARC, иначе говоря, механизмы уровней информационной архитектуры. Эти механизмы обладают внутренними и, возможно, внешними интерфейсами. Внутренние интерфейсы обеспечивают взаимодействие механизмов данного уровня с другими функциональными компонентами системы, а внешние (если они существуют) - с пользователями и/или с системным персоналом. Через эти интерфейсы механизмы уровней получают и передают команды, сигналы обратной связи и данные.

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

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

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

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

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

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

Табл. C: ПРОЕКТ

Номер_ работника	ИД_проекта	Фамилия	Назв_проекта	Описание_ проекта	Продукт
	БРЖ	Иванов	Биржа	<blob>	программа
	ДОК	Петров	Документы	<blob>	программа
	УПР	Сидоров	Управление	<blob>	адм.меры

В этой таблице возникает следующая проблема. Атрибуты Назв_проекта, Описание_проекта и Продукт относятся к проекту как сущности и, следовательно, зависят от атрибутаИД_проекта (являющегося частью первичного ключа), но не от атрибута Номер_работника. Следовательно, они являются частично зависимыми от составного первичного ключа. То же самое можно сказать и об атрибуте Фамилия, который зависит от атрибута Номер_работника, но не зависит от атрибута ИД_проекта. Для нормализации этой таблицы (приведения ее в 2НФ) удалим из нее атрибуты Номер_работника и Фамилия и создадим другую таблицу (назовем ее РАБОТНИК_В_ПРОЕКТЕ), которая будет содержать только эти два атрибута, и они же будут составлять ее первичный ключ.

Табл. D: ПРОЕКТ

ИД_проекта	Номер_ руководителя	Телефон	Назв_ проекта	Описание_ проекта	Продукт
БРЖ		2-21	Биржа	<blob>	программа
ДОК		2-43	Документы	<blob>	программа
УПР		2-56	Управление	<blob>	адм.меры

Для нормализации этой таблицы (приведения ее в 3НФ) удалим атрибут Телефон, изменим Номер_руководителя на Руководитель и сделаем атрибут Руководитель внешним ключом, ссылающимся на атрибут Номер_работника (первичный ключ) в таблице РАБОТНИКИ. После этого таблицы ПРОЕКТ и РАБОТНИКИ будут выглядеть следующим образом:

Табл. E: ПРОЕКТ

ИД_проекта	Руководитель	Назв_ проекта	Описание_ проекта	Продукт
БРЖ		Биржа	<blob>	программа
ДОК		Документы	<blob>	программа
УПР		Управление	<blob>	адм.меры

Табл. F: РАБОТНИКИ

Номер_ работника	Фамилия	Имя	Отчество	Номер_ отдела	Код_ профес	Телефон	Зарплата
	Иванов	Иван	Иванович		инж	2-69
	Петров	Петр	Петрович		мндж	2-56
	Сидоров	Иван	Петрович		мндж	2-45

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

Понятие «базы данных». Основные компоненты базы данных.