Базы данных

Любой из нас, начиная с раннего детства, многократно сталкивался с "базами данных". Это - всевозможные справочники (например, телефонный), энциклопедии и т. п. Записная книжка - это тоже "база данных", которая есть у каждого из нас.

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

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

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

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

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

Табличные базы данных

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

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

Поле базы данных - это столбец таблицы, содержащий значения определенного свойства.

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

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

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

Ключевое поле - это поле, значение которого од нозначно определяет запись в таблице.

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

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

• счетчик - целые числа, которые задаются автоматически при вводе записей. Эти числа не могут быть изменены пользователем;
• текстовый - тексты, содержащие до 255 символов;
• числовой - числа;
• дата/время - дата или время;
• денежный - числа в денежном формате;
• логический - значения Истина (Да) или Ложь (Нет);
• гиперссылка - ссылки на информационный ресурс в Интернете (например, Web-сайт).

Поле каждого типа имеет свой набор свойств. Наиболее важными свойствами полей являются:

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

Рассмотрим, например, базу данных "Компьютер", которая содержит перечень объектов (компьютеров), каждый из которых имеет имя (название). В качестве характеристик (свойств) можно рассмотреть тип установленного процессора и объем оперативной памяти. Поля Название и Тип процессора являются текстовыми, Оперативная память - числовым, а поле № п/п - счетчиком (табл. 3.1).

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

Таблица 3.1. Табличная база данных

№ п/п Название Тип процессора Оперативная память (Мбайт) 1 Compaq Celeron 64 2 Dell Pentium III 128 3 IBM Pentium 4 256

Вопросы для размышления

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

2. Поля каких типов полей могут присутствовать в базе данных?

3. Чем отличается ключевое поле от остальных полей?

Пример. Требуется создать запрос на обновление, после выполнения которого в таблице СОТРУДНИКИ будут увеличены на 20% оклады сотрудников, принятых на работу до 01.01.2000.

При заполнении бланка запроса включаем в него поля Оклад иДата назначения из таблицы СОТРУДНИКИ.

Для поля Оклад в строкеОбновление вводим правило обновления:[Оклад] * 1,2

Для поля Дата назначения в строкеУсловие отбора вводим условие:< 01.01.2000 (рис. 44).

В результате выполнения этого запроса в таблице СОТРУДНИКИ будут изменены значения в поле Оклад в тех записях таблицы, для которых значение в полеДата назначения меньше 01.01.2000.

Рис. 44. Создание запроса на обновление записей базовых таблиц.

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

Создание таблицы для экспорта в другую базу данных Microsoft Access. Например, требуется создать таблицу, содержащую несколько полей из таблицы СОТРУДНИКИ, а затем экспортировать эту таблицу в базу данных, используемую отделом кадров.

Создание резервной копии таблицы.

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

Создание запроса на создание новой таблицы

Пример. Требуется создать запрос на создание новой базовой таблицы АДРЕСА_СОТРУДНИКОВ, которая должна содержать поля Фамилия ,Имя ,Отчество из таблицы СОТРУДНИКИ и поляАдрес ,Телефон из таблицы ЛИЧНЫЕ ДАННЫЕ.

При заполнении бланка запроса включаем в него требуемые поля из таблиц СОТРУДНИКИ и ЛИЧНЫЕ ДАННЫЕ (рис. 45). Нажав кнопку Тип запроса , выбираемСоздание таблицы и вводим в диалоговом окне имя новой таблицы АДРЕСА_СОТРУДНИКОВ.

Выполнив запрос, переключаемся на вкладку Таблицы в окнеБаза данных . Можем убедиться в том, что в списке таблиц базы данных появилась новая базовая таблица с именем АДРЕСА_СОТРУДНИКОВ.

Рис. 45. Создание запроса на создание новой базовой таблицы.

2.4. Работа с запросами. Запросы на выборку

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

Если запрос подготовлен и сохранен в базе данных, то для выполнения запроса следует открыть панель Запросы в окне База данных (рис. 30), выбрать запрос и открыть его двойным щелчком на значке запроса – откроется результирующая таблица, соответствующая данному запросу.

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

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

Упорядочение записей в результирующей таблице. Если необходимо, чтобы дан­ные, отобранные в результате работы запроса, были упорядочены по какому-либо полю, применяют сортировку . В нижней части бланка имеется специ­альная строка Сортировка . При щелчке на этой строке появляется раскры­вающийся список, в котором можно выбрать метод сортировки: по возрастанию или по убыванию . В результирующей таблице данные будут отсортированы по тому полю, для которого задан порядок сортировки. На рисунке 32 задана сортировка по полю Фамилия .

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

Рис. 32. Задание условий сортировки записей и показа полей в результирующей таблице запроса.

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

Простые запросы на выборку

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

Критерий отбора записей	Запись условия отбора
Значение в поле начинается с символа ";А";, остальные символы могут быть любыми
Значение в числовом поле  = 60
Значение в текстовом поле НЕ равно ";Ontario";
Значения в поле типа дата в диапазоне от 1.12.96 до 15.12.96	BETWEEN 1.12.96 AND 15.12.96
Значение в числовом поле в диапазоне от 10 до 100	BETWEEN 10 AND 100
Значение в текстовом поле равно ";инженер"; или ";бухгалтер";	";инженер"; OR ";бухгалтер";
Значение в поле логического типа равно TRUE (истина)

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

Например, в случае записи условий отбора так, как показано на рисунке 33, будут отбираться те записи из таблицы СОТРУДНИКИ, для которых значение в поле КодСотрудника больше 4 и при этом значение в поле Оклад меньше 3000.

Рис. 33. Пример записи условий отбора в запросе.

В случае записи условий отбора так, как показано на рисунке 34, будут отбираться записи из таблицы СОТРУДНИКИ, для которых значение в поле КодСотрудника больше 4, или записи, для которых значение в поле Оклад меньше 3000, а также записи, для которых справедливы оба условия отбора.

Рис. 34. Пример записи условий отбора в запросе.

Вычисления в запросах на выборку

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

Для создания такого поля вместо имени поля записывается формула в следующем формате:

Имя поля: выражение

где выражение – формула для вычисления нужного значения.

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

Действия могут быть:

арифметические: + (сложение), - (вычитание), * (умножение), / (деление), ^ (возведение в степень)

логические: And (логическое умножение), Or (логическое сложение), Not (логическое отрицание)

сравнения: > (больше), >= (больше либо равно), (не равно)

соединения текстовых цепочек: & (например: [Фамилия] & "; "; & [Имя] )

На рисунке 35 показан пример запроса с вычисляемым полем Налог . При конструировании запроса в заголовке поля записывается формула Налог: [Оклад]*0,13 .

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

Чтобы вводить формулу было удобнее, можно нажать на клавиатуре  Shift  +  F2  . Открывается диалоговое окно Область ввода для ввода формулы (рис. 36).

Рис. 36. Диалоговое окно Область ввода .

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

Рис. 37. Окно Построитель выражений .

Запросы с параметром

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

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

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

BETWEEN [Введите нижнюю границу] AND [Введите верхнюю границу]

Например,

BETWEEN [Введите нижнюю дату] AND [Введите верхнюю дату]

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

2.5. Итоговые запросы и запросы на изменение данных

Итоговый запрос – это запрос, в котором выводятся результаты статистических расчетов по какой-либо группе записей из одной или нескольких таблиц. Можно находить сумму (функция Sum ), среднее значение (функция Avg ), наибольшее значение (функция Max ) или наименьшее значение (функция Min ), количество знаний в группе (функция Count ).

Процедура создания итогового запроса похожа на процедуру создания запроса на выборку. При выполнении такого запроса требуется группировать записи по совпадающим значениям в каком-либо поле таблицы. Для выполнения группировки записей нужно щелкнуть по кнопке Групповые операции
на панели инструментов. В бланке запроса по образцу появляется дополнительная строка Групповая операция . В тех полях, по которым проводится группировка, надо установить функцию Группировка . В тех полях, где проводится итоговые операции, нужно в строке Групповая операция раскрыть список и выбрать одну из функций (Sum , Avg , Max , Min , Count и т. д.)

Пример. Таблица содержит данные о должностях и размерах окладов (рис. 40):

Рис. 40. Таблица СОТРУДНИКИ.

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

Рис. 41. Создание итогового запроса.

Результатом выполнения запроса будет следующая таблица (рис. 42):

Рис. 42. Результат выполнения итогового запроса.

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

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

Создание запроса на удаление записей таблицы

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

При заполнении бланка запроса перетаскиваем символ « * » в строку Поле первого столбца, включаем в бланк также поле Дата назначения . Для поля Дата назначения в строке Условие отбора вводим условие: >01.01.2000 (рис. 43).

В результате выполнения этого запроса из таблицы СОТРУДНИКИ будут удалены те записи таблицы, для которых значение в поле Дата назначения больше 01.01.2000.

Рис. 43. Создание запроса на удаление записей из таблицы.

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

Создание запроса на обновление записей таблицы

Пример. Требуется создать запрос на обновление, после выполнения которого в таблице СОТРУДНИКИ будут увеличены на 20% оклады сотрудников, принятых на работу до 01.01.2000.

При заполнении бланка запроса включаем в него поля Оклад и Дата назначения из таблицы СОТРУДНИКИ.

Для поля Оклад в строке Обновление вводим правило обновления: [Оклад] * 1,2

Для поля Дата назначения в строке Условие отбора вводим условие: (рис. 44).

В результате выполнения этого запроса в таблице СОТРУДНИКИ будут изменены значения в поле Оклад в тех записях таблицы, для которых значение в поле Дата назначения меньше 01.01.2000.

Рис. 44. Создание запроса на обновление записей базовых таблиц.

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

Создание таблицы для экспорта в другую базу данных Microsoft Access. Например, требуется создать таблицу, содержащую несколько полей из таблицы СОТРУДНИКИ, а затем экспортировать эту таблицу в базу данных, используемую отделом кадров.

Создание резервной копии таблицы.

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

Создание запроса на создание новой таблицы

Пример. Требуется создать запрос на создание новой базовой таблицы АДРЕСА_СОТРУДНИКОВ, которая должна содержать поля Фамилия , Имя , Отчество из таблицы СОТРУДНИКИ и поля Адрес , Телефон из таблицы ЛИЧНЫЕ ДАННЫЕ.

При заполнении бланка запроса включаем в него требуемые поля из таблиц СОТРУДНИКИ и ЛИЧНЫЕ ДАННЫЕ (рис. 45). Нажав кнопку Тип запроса , выбираем Создание таблицы и вводим в диалоговом окне имя новой таблицы АДРЕСА_СОТРУДНИКОВ.

Выполнив запрос, переключаемся на вкладку Таблицы в окне База данных . Можем убедиться в том, что в списке таблиц базы данных появилась новая базовая таблица с именем АДРЕСА_СОТРУДНИКОВ.

Рис. 45. Создание запроса на создание новой базовой таблицы.

2.6. Работа с отчетами

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

Средства автоматического проектирования отчетов реализованы автоотчетами (База данных Создать Новый отчет Автоотчет в столбец ). Кроме автоотчетов «в столбец» существуют «ленточные» автоотчеты (рис. 46, 47). В режиме Автоотчет можно создать только такой отчет, в котором выводятся все поля и записи из базовой таблицы или запроса .

Рис. 46. Автоотчет «в столбец».

Рис. 47. Автоотчет «ленточный».

Средством автоматизированного создания отчетов является Мастер отчетов (запускается двойным щелчком на значке Создание отчета с помощью мастера в окне База данных .

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

Редактирование структуры отчета выполняют в режиме Конструктор (рис. 48).Отчет, кроме разделов заголовка, примечания и данных, содержит также разделы верхнего и нижнего колонтитулов. Эти разделы необходимы для печати служебной информации, например номеров страниц.

Рис. 48. Вид отчёта в режиме Конструктор .

2.7. Вопросы для самоконтроля

Какие объекты БД Microsoft Access используются для хранения данных?

Какие объекты БД Microsoft Access используются для отбора данных из базовых таблиц в соответствии с какими-либо критериями отбора?

Чем результирующая таблица запроса отличается от базовой таблицы БД Microsoft Access?

Каково назначение экранных форм БД Microsoft Access?

Какие объекты БД Microsoft Access используются для вывода данных из таблиц или запросов на печать?

Каково назначение страниц доступа к данным?

Для чего используются макросы и модули БД Microsoft Access?

Укажите основные свойства полей таблицы реляционной БД.

Какого типа данные может содержать таблица БД Microsoft Access? Охарактеризуйте основные типы данных: текстовый, числовой, дата/время, счетчик, логический, MEMO, OLE.

Итак, что же представляет собой пакет инсталляции для Windows Installer? Обычно инсталляционные пакеты хранятся в файлах с расширением .msi и представляют собой реляционную базу данных, хранящую всю логику и данные, необходимые для правильной установки программного продукта. А доступом к этим данным управляет непосредственно Windows Installer. То есть, как и любая другая база данных, пакет инсталляции состоит из множества связанных друг с другом таблиц. Так как база данных является реляционной, таблицы связываются с помощью первичных и внешних ключей. Это обеспечивает эффективный способ управления процессом инсталляции и позволяет пользователям с легкостью приспосабливать сложное приложение или даже группу приложений к своим нуждам. Таблицы базы данных отражают общую схему приложения, включающую:

доступные опции приложения;

компоненты;

связи между опциями и компонентами;

необходимые записи в реестре Windows;

пользовательский интерфейс приложения. Для создания базы данных необходимо заполнить таблицы данными о приложении и о процессе инсталляции. Это можно сделать вручную, используя утилиту ORCA , поставляемую фирмой Microsoft в составе Windows Installer SDK . Кстати, эта утилита может очень помочь в изучении структуры базы данных пакета инсталляции. Но заполнение таблиц вручную - достаточно трудоемкий процесс даже для инсталляций умеренного размера. И это неудивительно, если учесть, что база данных любого пакета инсталляции включает как минимум 87 таблиц!

ПРИМЕЧАНИЕ Справедливости ради надо сказать, что реально инсталлятор обычно использует только порядка 30-35 из них.

Поэтому гораздо проще и удобнее использовать пакеты для создания инсталляторов. К ним относятся, например Visual Studio Installer, Wise Installer, InstallShield Developer и некоторые другие, не столь широко известные пакеты. Кстати, многие пакеты создания инсталляторов включают в базу данных свои дополнительные таблицы, например, в пакетах, созданных с помощью InstallShield Developer количество таблиц достигает 113! При этом никто не запрещает нам, как разработчикам, определять и добавлять свои таблицы, дополняя тем самым модель данных Windows Installer.

ПРИМЕЧАНИЕ Вышесказанное справедливо для Windows Installer версии 2.0, который позволяет распространять и устанавливать приложения для новой перспективной платформы Microsoft -.NET Framework.

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

В базе данных пакета инсталляции можно выделить семь основных групп:

базовые таблицы;

файловые таблицы;

таблицы записей в реестре Windows;

системные таблицы;

таблицы поиска;

таблицы информации о программе;

таблицы процесса инсталляции;

Базовые таблицы

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

Рисунок 1. Структура группы Базовые таблицы

ПРИМЕЧАНИЕ На этой и на последующих диаграммах черный круг, соединенный с белым ромбом обозначает отношение один-ко-многим между первичным ключом в первой таблице и внешним ключом во второй.

Таким образом, мы видим, что эта группа состоит из 11 связанных таблиц. Ниже приведены их краткие описания:

Имя таблицы	Краткое описание
Feature	Содержит список всех функций программного продукта
Condition	Содержит условия определяющие порядок установки каждой функции, описанной в таблице Feature 1
FeatureComponents	Связывает функции с компонентами, иными словами - эта таблица определяет, какой функции принадлежит компонент 2
Component	Содержит список всех компонентов приложения
Directory	Содержит список всех каталогов, необходимых для инсталляции
PublishComponent	Содержит список функций и компонентов, публикуемых для использования в других приложениях
Assembly	Задает установки для сборок.NET Framework CLR и Win32
AssemblyName	Задает схему для именования сборок.NET Framework CLR и Win32
Complus	Содержит информацию, необходимую для установки приложений COM+
IsolatedComponent	Связывает компонент, заданный в столбце Component_Application (обычно .exe ) с компонентом, заданным в столбце Component_Shared (обычно .dll )
Upgrade	Содержит информацию для значительных обновлений программного продукта 3

ПРИМЕЧАНИЕ

1. Если в таблице Condition нет условия для функции из таблицы Feature - это значит, что функция будет установлена в любом случае.

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

3. Я не буду останавливаться на обновлениях, так как эта тема заслуживает отдельной статьи.

Файловые таблицы

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

ПРИМЕЧАНИЕ Такие пакеты как InstallShield Developer и Wise Installer позволяют не придерживаться такого жесткого порядка заполнения таблиц. Но рекомендуется все-таки тщательно продумать структуру пакета инсталляции перед тем, как начать заполнять базу данных.

Структура этой группы показана на рисунке 2.

Рисунок 2. Структура группы Файловые таблицы

Эта группа состоит из 15 таблиц. Их краткое описание дано ниже.

Имя таблицы	Краткое описание
File	В этой таблице перечислены файлы, входящие в инсталляцию. Так как файлы привязаны к компонентам, их использующим, эта таблица связана с таблицей Component
RemoveFile	В этой таблице содержится список файлов, которые необходимо удалить при выполнении операции RemoveFiles
Font	Эта таблица содержит список файлов шрифтов, которые необходимо зарегистрировать в системе
SelfReg	Эта таблица содержит список саморегистрирующихся модулей (то есть библиотек динамической компоновки, экспортирующих функции DllRegisterServer и DllUnregisterServer ). Installer не регистрирует EXE -файлы
Media	Эта таблица описывает набор дисков инсталляции
BindImage	Эта таблица содержит информацию о привязках исполняемых файлов или DLL 1
MoveFile	Эта таблица содержит список файлов, которые нужно перенести или скопировать во время инсталляции из исходного каталога в заданный каталог
DuplicateFile	Эта таблица содержит список файлов, которые необходимо продублировать при инсталляции: либо в другой каталог с тем же именем, что и исходный файл, либо в тот же каталог, но с другим именем
IniFile	В этой таблице содержится информация для создания .ini -файлов, необходимых приложению. Эти файлы создаются, если содержащий их компонент выбран для инсталляции в локальном режиме или с источника инсталляции
RemoveIniFile	Эта таблица содержит информацию, которую необходимо удалить из .ini -файлов при инсталляции приложения
Environment	Эта таблица используется для задания переменных окружения 2
Icon	Эта таблица хранит файлы иконок. Каждая иконка этой таблицы во время инсталляции копируется в отдельный файл на диске 3
FileSFPCatalog	Эта таблица используется системой Windows File Protection в ОС Windows Me
SFPCatalog	Эта таблица также используется системой Windows File Protection в ОС Windows Me
MsiFileHash	Эта таблица хранит 128-разрядное хэш-значение для исходных файлов в пакете инсталляции 4

ПРИМЕЧАНИЕ

1. Для получения более подробной информации о привязках смотрите описание функции Windows API BindImageEx

2. В операционных системах Windows95/98 в этой таблице также хранится список изменений в файле autoexec.bat

3. Таблица Icon используется при публикации программных продуктов

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

Таблицы записей в реестре Windows

Эта группа содержит таблицы, описывающие различные виды информации в реестре Windows. Структура группы показана на рисунке 3.

Рисунок 3. Структура группы таблиц Записи в реестре Windows.

Внимательный читатель, конечно же, заметил, что на рисунке присутствуют таблицы из других групп, такие, как Component , Feature и File . Эти таблицы включены сюда для того, чтобы более ясно показать логику работы этой группы. Кроме того, здесь присутствуют таблицы, уже упоминавшиеся в других группах, но здесь играющие немного другую роль (это таблицы SelfReg и Environment ).

Таким образом, эта группа включает 11 таблиц, краткое описание которых дано ниже:

Имя таблицы	Краткое описание
Extension	Эта таблица содержит список расширений файлов, используемых устанавливаемой программой, вместе с привязанными к этим расширениям функциями и компонентами
Verb	Эта таблица связывает информацию о командах, связанных с расширениями файлов из предыдущей таблицы. Наличие этих таблиц в связке с таблицей Feature позволяет реализовать возможность публикации приложения
TypeLib	Эта таблица содержит записи, необходимые для регистрации библиотек типов 1
MIME	Эта таблица связывает типы MIME c CLSID или расширением файла. Это позволяет связать таблицы MIME и Feature , и обеспечить еще один путь для публикации приложения
SelfReg	Смотрите описание в группе Файловые операции 2
Class	Эта таблица содержит информацию, необходимую для работы COM-серверов
ProgId	Эта таблица содержит информацию о ProgID для COM-серверов
AppId	Эта таблица используется для конфигурирования DCOM-серверов
Environment	Смотрите описание в группе Файловые таблицы 3
Registry	Эта таблица содержит всю прочую информацию, не вошедшую в другие таблицы. Это может быть пользовательская информация, данные, установки по умолчанию и т.д.
RemoveRegistry	Эта таблица содержит информацию о записях в реестре, которые нужно удалить при инсталляции приложения

ПРИМЕЧАНИЕ

1. При публикации приложения никаких записей о библиотеках типов не делается. Запись производится только в момент установки компонента, связанного с библиотекой.

2. Использование саморегистрации в Windows Installer НЕ РЕКОМЕНДУЕТСЯ и включено только для обеспечения обратной совместимости с предыдущими технологиями установки программ. Вместо этого рекомендуется заполнить соответствующие таблицы нужной информацией, аналогичной той, что прописывает нужный модуль при вызове его функции DllRegisterServer .

3. Эта таблица включена в данную группу, так как в операционных системах Windows NT / 2000 / XP данные из нее пишутся в реестр.

СОВЕТ При заполнении этой группы нужно попытаться сделать таблицу Registry как можно компактней, поместив как можно больше информации в другие, более специфичные таблицы. Это делается, потому что Installer не может выделить различные типы реестровых записей в таблице Registry и, следовательно, не может использовать внутреннюю логику для задействования всех своих возможностей, например - публикации или установки по требованию. Кроме того, такой способ организации данных поможет уменьшить риск записи лишней информации о COM-серверах.

Системные таблицы

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

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

Итак, эта группа состоит из 5 таблиц, краткое описание которых дано ниже:

Имя таблицы	Краткое описание
_Tables	Хранит имена всех таблиц инсталляционной базы данных, включая созданные автором пакета для личных целей (например, для использования в своих операциях). Эта таблица доступна только на чтение
_Columns	Хранит информацию обо всех столбцах в таблицах инсталляционной базы данных. Но временные столбцы в этой таблице не хранятся. Как и предыдущая таблица, доступна только на чтение
_Streams	Содержит потоки данных OLE. Эта таблица временная и создается только при выполнении определенных SQL-запросов, например, при выполнении функции MsiRecordReadStream
_Storages	Содержит хранилища данных OLE. Эта таблица также временная и создается только при выполнении определенных SQL-запросов, например, при выполнении функции MsiRecordSetStream
_Validation	Эта таблица содержит информацию о столбцах в таблицах базы данных, включая их имена и диапазоны допустимых значений, а также другую важную для базы данных информацию. Используется только при проверке целостности базы данных

Таблицы поиска

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

Компонент, которому принадлежит нужный файл, определяется через связь между таблицами File и Component . Installer определяет подчиненность файла через таблицу компонентов, потому что каждый файл связан с одним компонентом. Местоположение компонента определяется по внешнему ключу в таблице Component , указывающему на таблицу Directory .

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

Группа таблиц поиска состоит из 7 таблиц, описание которых дано ниже:

Имя таблицы	Краткое описание
Signature	Содержит информацию, уникальным образом описывающую некоторый файл 1
RegLocator	Эта таблица содержит информацию, необходимую для поиска файлов или каталогов по записям в реестре
IniLocator	Эта таблица используется для поиска .ini -файлов. Эти файлы должны быть расположены в корневом каталоге Windows
CompLocator	Эта таблица используется для поиска файлов или каталогов с использованием конфигурационных данных Windows Installer
DrLocator	Эта таблица используется для поиска по дереву каталогов
AppSearch	Эта таблица содержит список свойств, которые должны быть установлены, если нужный файл или каталог с заданной сигнатурой найден
CCPSearch	Эта таблица содержит список сигнатур файлов, из которых хотя бы один должен быть установлен на пользовательском компьютере. Таблица используется при обновлении программ

ПРИМЕЧАНИЕ

1. Формально по документации Microsoft таблица Signature не относится к группе таблиц поиска. Но так как она нигде, кроме поиска, не используется, я позволил себе внести ее в эту группу.

Таблицы информации о программе

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

Состоит эта группа из пяти таблиц:

Имя таблицы	Краткое описание
Property	В этой таблице хранятся все свойства 1 пакета инсталляции
Binary	В этой таблице хранятся двоичные данные для иконок, растров и т.п. Также здесь хранятся данные для пользовательских операций
Error	Эта таблица используется для поиска шаблонов форматирования при обработке ошибок. Installer имеет свой собственный механизм обработки ошибок
Shortcut	Здесь хранится вся информация, необходимая для создания файловых ярлыков
ReserveCost	Эта таблица содержит информацию о необходимом дисковом пространстве для каждого компонента приложения

ПРИМЕЧАНИЕ

1. Свойство - это глобальная переменная, которая используется Microsoft Windows Installer во время инсталляции.

Таблицы процесса инсталляции

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

ПРИМЕЧАНИЕ Тема операций в Windows Installer обширна и ей будет посвящена одна из следующих статей.

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

Имя таблицы	Краткое описание
InstallUISequence	INSTALL полный или сокращенный базовый или отключен 1
InstallExecuteSequence	Эта таблица содержит операции, выполняемые при активизации высокоуровневой операции INSTALL 1, 2
AdminUISequence	Эта таблица содержит операции, выполняемые при активизации высокоуровневой операции ADMIN и уровне пользовательского интерфейса - полный или сокращенный . Installer пропускает операции из этой таблицы, если уровень пользовательского интерфейса установлен в базовый или отключен 3
AdminExecuteSequence	Эта таблица содержит операции, выполняемые при активизации высокоуровневой операции ADMIN 2, 3
AdvtUISequence	Installer не использует эту таблицу. Она должна быть удалена из базы данных или быть пустой
AdvtExecuteSequence	Эта таблица содержит операции, выполняемые при активизации высокоуровневой операции ADVERTISE 4

ПРИМЕЧАНИЕ

1. Все операции в последовательности инсталляции, вплоть до InstallValidate InstallUISequence . Все операции от InstallValidate InstallExecuteSequence LaunchConditions , CostInitialize , CostFinalize и ExecuteAction .

2. Все пользовательские операции, выполняемые в этой последовательности, при необходимости использования пользовательского интерфейса должны пользоваться функцией API MsiProcessMessage , вместо диалогов из таблицы Dialog .

3. Все операции в последовательности инсталляции, вплоть до InstallValidate и диалогов выхода, помещаются в таблицу AdminUISequence . Все операции от InstallValidate и до конца инсталляции - в таблицу AdminExecuteSequence . Так как последняя таблица может использоваться независимо от первой (например, если пользовательский интерфейс отключен), она включает все операции инициализации, такие как LaunchConditions , CostInitialize , CostFinalize и ExecuteAction .

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

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

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

Следующая группа таблиц расширяет возможности инсталлятора по манипулированию файлами и каталогами в процессе инсталляции.

ПРИМЕЧАНИЕ

1. Хотя Installer и создает при инсталляции каталоги по мере необходимости, они удаляются, если не содержат файлов. Каталоги, перечисленные в таблице CreateFolder , не удаляются до тех пор, пока не будет удален связанный с ними компонент.

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

Последнее слово о таблицах

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