Тема 5. Управление данными в субд. Концепции и архитектура субд. Представление пользователя Организация баз данных Лекция №5. Концепции и архитектура субд

В рамках данной лекции рассматриваются нижеследующие вопросы:

• Концепции СУБД.

• Компоненты баз данных: данные, программное обеспечение, оборудование, персонал.

• Цикл жизни базы данных.

• Архитектура СУБД.

• Словарь данных. Языки ЯОД и ЯМД: назначение и функции.

• Индексирование и доступ к данным.

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

• Архитектуры файловый сервер, удаленный доступ, «клиент-сервер», сервер базы данных, сервер приложений;

• Функциональные возможности современных СУБД на примере SQL Server.

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

в системе решаются задачи, использующие эти данные совместно. То есть, если ОС разделяет ресурсы между пользователями, то СУБД разделяет данные между пользователями.

Другими словами это означает, что в рамках СУБД:

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

• содержатся метаданные, описывающие элементыданных и их взаимосвязи;

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

СУБД различаются по модели данных, которую они поддерживают. Существуют:

• иерархические СУБД (HDBMS), в которых связи между объектамипредставляются в видедревовидных структур, где связь является строгой иерархиейродитель-потомки и указывается с помощью логического адреса;

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

• реляционные СУБД (RDBMS), в которых связи между объектамипредставляются и с помощьютабличныхструктур таким же образом, как иобъекты, и при этомассоциативно (по значению атрибутов) ;

• объектно-реляционные СУБД (ОРСУБД), или Object-Relational DBMS (ORDBMS), которые для отображения связей между данными используют и объектный, и реляционный подход.

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

Описание логической организации данных при реализации в реляционной СУБД осуществляется на высокоуровневомдекларативном(непроцедурном) языкеописания данных (ЯОД ), или Data Definition Language (DDL).

Процесс проектирования, реализации и поддержания системы базы данных называется жизненным циклом базы данных.

Классическими этапами проектирования и разработки БД являются:

• сбор сведений о предметной области - анализ потребностей и описание предметной области с использованием "процессного" подхода ("usage perspective") и "непроцессного" подхода ("information structure perspective");

• выбор языка представления модели предметной области для построения модели БД на уровне понятий (концептуальной модели);

• анализ собранных сведений о предметной области: определение структурных элементов описанияпредметной области, структурных и процедурныхограничений целостностиобъектов в будущей модели предметной области, определение динамики экземпляров объектов предметной области;

• построение схемы БД;

• выбор конкретной модели данных и СУБД для реализации БД;

• проектирование логической схемы БД;

• разработка физической структуры БД: "физической" или "внутренней" схемы, "схемы размещения" для распределенной БД ;

• разработка технологии и процедур начального создания и заполнения БД;

• разработка технологии и процедур сопровождения БД;

• разработка пользовательских интерфейсов для доступа к БД;

• информационная поддержка, обеспечение метаинформации, контрольные примеры и пр.;

• получение обратной связи от разработчиков прикладных программ и пользователей о полноте и эффективности использования БД;

• тестирование БД, ее развитие.

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

Трехуровневая архитектура модели данных комитета ANSI/SPARC

Комитет планирования стандартов (SPARC) Национального института стандартов США (ANSI) в 1978 году предложил трехуровневую архитектуру для построения модели данных. В ней определены 3 уровня: внешний, концептуальный и. внутренний. Внутренний уровень – это уровеньмоделей, отображающих физический уровень реализации базы данных, близкий к структурам физического хранения и осуществления доступа к ним. Этот уровень ориентирован наразработчиков и проектировщиковфизической БД, конкретно определяющих физические устройства для хранения данных и способы доступа к ним. Прикладные и конечные пользователи, в общем, могут не заниматься этим уровнем. Для них предназначен внешний уровень (внешняя схема) - уровень модели БД, на котором задаются представления данных отдельных пользователей или пользовательских групп (различных прикладных задач, решаемых в рамках СУБД. Каждая группа пользователей по-своему «видит» структурную организацию данных в БД для решения своих задач. Каждое такое представление пользователя о данных содержит описание элементов данных и связей между ними. Совокупность таких пользовательских представлений данных образует внешний уровень 3-х уровневой модели. Концептуальная модель служит для представленияпонятийилиобъектовпредметной области и используется для определения логической схемы базы данных. Формирование осуществляется на основе анализа совокупности представлений пользователей. Результатом концептуального проектирования является концептуальная схема -интегрированноепредставление будущих объектов БД и связей между ними.

Достоинством такого 3-х уровневого построения является:

• независимость внутренней физической модели от логической и возможность отображения однойи той желогическоймодели на несколькоразличных физических моделей (в конечном счете - СУБД);

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

Традиционно компонентами базы данных, кроме собственно данных, называют: программное обеспечение (ПО),оборудование,персонал.

В ПО выделяются 2 части: СУБД и прикладное ПО, реализованное или функционирующее на основе СУБД.

СУБД являет собой системноепрограммное обеспечение, предназначенное для:

• организации определения, наполнения, хранения, доступа, редактирования, восстановления данных;

• ведения словаря /справочника данных;

• защиты данных и обеспечения их целостности;

• поддержки работы пользователей в многопользовательском режиме;

• осуществления запросов к БД;

• разработки приложений баз данных .

Компоненты современных СУБД

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

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

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

• трехзвеннаямодель (three-tiermodel) построения клиент-серверной системы, в которой имеется промежуточное звено между компьютером-клиентом и компьютером-сервером двухзвенной модели и обычно функционирует в качестве монитора обработки транзакций, посредника запросов к объектам или сервера приложений;

• многозвенная,или N-звенная, модель (N-tiermodel) построения клиент-сервернойсистемы (обозначаемая иногда как client/multiple middleware/multiple servers), которая использует разделение вычислительной нагрузки между несколькими серверами приложений и позволяет увеличить число возможных клиентских мест по сравнению с двухзвенной моделью.

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

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

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

• презентационную (presentation), ориентированную на взаимодействие с пользователем и тесно связанную с пользовательским интерфейсом;

• прикладную (application), ориентированную на реализацию бизнес-логики;

• управления данными (data), ориентированную на реализацию всей совокупности функций, связанных с управлением данными.

Звенья могут реализовывать эти части в нескольких вариантах:

клиент			сервер
presentation	application		data
presentation			application	data
		сервер приложения
presentation		application	data

Варианты реализации определяют архитектуры, называемые соответственно «толстым/тонким клиентом», «тонким/толстым сервером», трехзвенной архитектурой.

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

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

Использование в широкой практике сети Internet и ее служб (e-mail, http, ftp, telnet и т.д.) повлияли на технологию создания корпоративных информационных систем, обусловив появление корпоративных сетей предприятия, получивших название Intranet. По сути дела, информационная Intranet-система- это корпоративная система, в которой используются методы и средства Internet. В свою очередь это повлекло необходимость включения в состав функциональности СУБД поддержку работы с языками гипертекстовой разметки документов HTML и XML и языками сценариев.

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

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

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

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

Они выполняют следующие функции:

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

• Представлениепостоянно изменяющегосясостоянияпредприятия (а не просто ведение журнала транзакций).

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

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

Хранилище данных(data warehouse, DW) является собой большую предметно-ориентированную корпоративную базу данных, предназначенную для подготовки отчётов, анализа бизнес-процессов иподдержки принятия решений(DSS). В отличие от оперативных баз данных в хранилищах разрешен доступ к даннымтолько для чтения.

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

Хранилище данных выполняет:

• Объединение данных из разнородныхисточников данных в единуюоднородную структуру.

• Поддержку организации данных в виде многомерных структур («кубов») с целью эффективности запросов к ним.

• Хранение преобразованных данных, допустимых, согласованных, консолидированных и отформатированных для анализа.

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

• Периодическоеобновление новыми данными транзакций.

Оперативный анализ данных(Online Analytical Processing, OLAP) для поддержки принятия решений. Исходные данные для анализа представляются в виде многомерных кубов, которые можно различным образом «разрезать» для получения визуализируемых отчётов и предоставления их пользователю (лицу, принимающему решение). Многомерные данные поступают из хранилищ данных, в том числе и хранилищ оперативных данных, поступающих в реальном времени.

Интеллектуальный анализ данных (data mining), или «добыча» данных. Это технология предназначена для анализахранилищданных и основывается на методахискусственного интеллекта(ИИ) и инструментахподдержки принятия решений. Ее задачами являются нахождениетрендови коммерческиполезных зависимостей,обнаружение знанийв базах данных. Другими словами она осуществляет обнаружениескрытойинформации, неожиданных зависимостей и моделей вимеющейсябазе данных, которая вявной форме в базе данных не представлена, но при выявлении может оказаться полезной для прогнозирования. Обычно такая служба содержит

• Набор стандартных алгоритмов интеллектуального анализа данных.

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

• Язык интеллектуального анализа данных (расширение SQL), который можно использовать для управления моделями интеллектуального анализа данных и для создания сложных прогнозирующих запросов.

Распределенность баз данных и реализация в сети, в том числе в сети Интернет, также определяет наличие в составе ПО СУБД специализированных компонентов. Ниже приведены некоторые из них.

Служба сервера отчетов- осуществляет обработку, хранение и доставку отчетов.

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

Служба отчетов(Reporting Services) обеспечивает средства создания корпоративных отчетов с поддержкой веб-интерфейса, которые позволяют включать в отчеты данные изразличных источников, публиковать отчеты в разнообразных форматах.

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

Обмен сообщениями в обычном диалоге.

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

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

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

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

Для баз данных, развертываемых в сети Интернет, которые должны поддерживать системы с высоким уровнем доступности, появилось определение «федерация серверов баз данных», которая позволяет распределить нагрузку на группу серверов,горизонтальным секционированиемданных базы SQL Server. Такие серверы управляются независимо друг от друга, но сообщаются между собой для обработки запросов к базе данных от приложений. Такая взаимодействующая группа серверов называетсяфедерацией.

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

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

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

Расширение возможностей происходит и на уровне поддерживаемых типов данных. Появились типы «пространственных» данных geometry и geography. Например, тип данныхgeographyиспользуется для хранения эллиптических данных, таких какGPS координатышироты и долготы, единицей измерения которых обычно является метр. При работе с таким типом учитывается как планарная модель (или модель плоской Земли), так и эллиптическая модель, или модель круглой Земли, координаты указываются в градусах долготы и широты.

Основная литература

Учебник / Учебное пособие	Раздел	Страницы
1. Карпова Т.С. Базы данных: модели, разработка, реализация. - СПб.: Питер, 2001.- 304 с.; ил. СПб.:Корона-Век, 2007.-736с.	Главы 1,2, 10, 14	10-30, 198-215, 286-294
2. Хомоненко А.Д, Цыганков В.М., Мальцев М.Г. Базы данных: Учебник для высших учебных заведений / под ред. проф. Хомоненко А.Д., 6-ое изд. – М.:Бином-Пресс;	Гл. 1,2 4, 9	9-38, 109-142, 242-270

Дополнительная литература

Учебник / Учебное пособие	Раздел	Страницы
1. Коннолли Т., Бегг К., Страчан А. Базы данных: проектирование, реализация и сопровождение. Теория и практика, 2-е изд.: Пер. с англ. - М.: Издательский дом “Вильямс”,. 2001. – 1120 с.: ил.	1.1 - 1.4, 2.1 – 2.3, 19.1 – 19.6, 20.1 – 20.7	39-56, 73-87, 608-631
2. Дейт К. Дж. Введение в системы баз данных, 6-е издание: Пер. с англ. – К.;М.; СПб.: Издательский дом “Вильямс”,. 1999. – 848 с.: ил. (7-е и 8-е издание).	1.2 – 1.3, 21.3 – 21.7, 2.1-2.5,	16-23, 37-44, 08-631
3. http://msdn.microsoft.com/ru-ru/library