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

     Примечание

     Объекты OLE DB создаются и функционируют  так же, как и другие объекты  СОМ. Каждому объекту соответствует  идентификатор класса CLSID, хранящийся в системном реестре. Для создания объекта используется метод CoCreateinstance и соответствующая фабрика класса. Объекту соответствует набор интерфейсов, к методам которых можно обращаться после создания объекта.

     В результате приложение обращается не прямо к источнику данных, а  к объекту OLE DB, который "умеет" представить данные (например, из файла электронной почты) в виде таблицы БД или результата выполнения запроса SQL.

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

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

     Так как технология ADO основана на стандартных  интерфейсах СОМ, которые являются системным механизмом Windows, это сокращает общий объем работающего программного кода и позволяет распространять приложения БД без вспомогательных программ и библиотек. [8]

     Примечание 

     Нижеследующее описание спецификации OLE DB представлено в соответствии с официальной  терминологией Microsoft для данной предметной области.

     Спецификация OLE DB различает следующие типы объектов, которые будут рассмотрены ниже.

• Перечислитель (Enumerator) выполняет поиск источников данных или других перечислителей. Используется для обеспечения функционирования провайдеров ADO.
• Объект-источник данных (Data Source Object) представляет хранилище данных.
• Сессия (Session) объединяет совокупность объектов, обращающихся к одному хранилищу данных.
• Транзакция (Transaction) инкапсулирует механизм выполнения транзакции.
• Команда (Command) содержит текст команды и обеспечивает ее выполнение. Командой может быть запрос SQL, обращение к таблице БД и т.д.
• Набор рядов (Rowset) представляет собой совокупность строк данных, являющихся результатом выполнения команды ADO.
• Объект-ошибка (Error) содержит информацию об исключительной ситуации.

 

ЧАСТЬ 2. ПРАКТИЧЕСКАЯ ЧАСТЬ

2.1. Нормализация базы данных

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

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

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

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

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

     После нормализации базы данных получаем следующие  таблицы.[1]

Рис. 2.1. Таблицы базы данных «Путевки»

 

2.2. Расчет базы данных

     Основной  единицей хранения данных в SQL Server является страница. В SQL Server 2000 размер страницы составляет 8 кб. Другими словами, в базах данных SQL Server 2000 содержится 128 страниц на 1 Мб.

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

     Страницы  содержат строки данных (кроме данных типа text, ntext и image, которые хранятся в отдельных страницах). Данные размещаются на странице последовательно и начинаются сразу же после заголовка. В конце страницы расположена таблица смещений строк. Она содержит по одному элементу для каждой строки, размещенной на границе; в каждом элементе записано, как далеко первый байт строки расположен от начала страницы. Как показано на рис. 2.2, последовательность элементов таблицы смещений строк является обратной относительно последовательности строк страницы.

     Экстенты  представляют собой единицу выделения  памяти для таблиц и индексов. Размер экстента составляет восемь последовательных страниц, или 64 кб. Другими словами, в базах данных SQL Server 2000 приходится 16 экстентов на 1 Мб.[1]

 

     

Рис. 2.2. Строки данных и элементы таблицы смешения строк на странице 

     Для повышения эффективности выделения  памяти, SQL Server 2000 не выделяет для таблиц с небольшим объемом данных целые экстенты. В SQL Server 2000 имеется два типа экстентов:

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

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

     Рассмотрим  необходимые таблицы: