Что такое запись базовой таблицы. Введение в базы данных и Microsoft Access
Пример. Требуется создать запрос на обновление, после выполнения которого в таблице СОТРУДНИКИ будут увеличены на 20% оклады сотрудников, принятых на работу до 01.01.2000.
При заполнении бланка запроса включаем в него поля Оклад иДата назначения из таблицы СОТРУДНИКИ.
Для поля Оклад в строкеОбновление вводим правило обновления:[Оклад] * 1,2
Для поля Дата назначения в строкеУсловие отбора вводим условие:< 01.01.2000 (рис. 44).
В результате выполнения этого запроса в таблице СОТРУДНИКИ будут изменены значения в поле Оклад в тех записях таблицы, для которых значение в полеДата назначения меньше 01.01.2000.
Рис. 44. Создание запроса на обновление записей базовых таблиц.
Запрос на создание таблицы создает новуюбазовую таблицу (имена базовых таблиц указаны на вкладкеТаблицы в окне базы данных) на основе всех или части данных из одной или нескольких таблиц. Запрос на создание таблицы полезен для выполнения следующих действий:
Создание таблицы для экспорта в другую базу данных Microsoft Access. Например, требуется создать таблицу, содержащую несколько полей из таблицы СОТРУДНИКИ, а затем экспортировать эту таблицу в базу данных, используемую отделом кадров.
Создание резервной копии таблицы.
Создание архивной таблицы, содержащей старые записи. Например, можно создать таблицу, сохраняющую все старые заказы, прежде чем удалить их из текущей таблицы.
Создание запроса на создание новой таблицы
Пример. Требуется создать запрос на создание новой базовой таблицы АДРЕСА_СОТРУДНИКОВ, которая должна содержать поля Фамилия ,Имя ,Отчество из таблицы СОТРУДНИКИ и поляАдрес ,Телефон из таблицы ЛИЧНЫЕ ДАННЫЕ.
При заполнении бланка запроса включаем в него требуемые поля из таблиц СОТРУДНИКИ и ЛИЧНЫЕ ДАННЫЕ (рис. 45). Нажав кнопку Тип запроса , выбираемСоздание таблицы и вводим в диалоговом окне имя новой таблицы АДРЕСА_СОТРУДНИКОВ.
Выполнив запрос, переключаемся на вкладку Таблицы в окнеБаза данных . Можем убедиться в том, что в списке таблиц базы данных появилась новая базовая таблица с именем АДРЕСА_СОТРУДНИКОВ.
Рис. 45. Создание запроса на создание новой базовой таблицы.
Итак, что же представляет собой пакет инсталляции для 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, весьма велик. И вполне естественно, что в рамках статьи невозможно рассмотреть все из них. Многие из таблиц, не упоминавшихся здесь, будут рассмотрены в следующих статьях, при рассмотрении более узких тем.
Анализ технологии создания таблиц
Основным элементом БД является таблица. Таблицы - это основной объект базы данных, в котором хранятся все данные, имеющиеся в базе, а также структура базы (поля, их типы, свойства).
Строки таблицы БД называются записями. Запись -- это место хранения отдельного элемента информации. Каждая запись состоит из одного или нескольких полей. Поля соответствуют столбцам таблицы. Поля должны быть определены как конкретный тип данных: текст, дата или время, число или какой-либо иной тип.
Первым этапом создания БД является ее структуры, т.е. определение количества и типа полей. Вторым этапом является ввод и редактирование записей в таблицу. Бд считается созданной, даже если она пустая.
Поля таблицы просто определяют ее структуру и групповые свойства данных, записываемых в ячейках. Рассмотрим основные свойства БД:
Имя поля - определяет как надо обращаться в данным поля)имена используются как заголовки таблиц)
Тип поля - определяет тип данных, которые могут содержаться в данном поле (текстовые, числовые, дата и т.д.)
Размер поля - определяет предельную длину данных, которые могут размещаться в поле
Формат поля - способ форматирования данных в ячейках.
Типы таблиц и ключей в реляционных базах данных
Реляционные базы данных характеризуются наличием некоторых типов таблиц и ключей, позволяющих определить связи между таблицами. Для того чтобы понять принципы разработки реляционных баз данных, требуется дать определения различных типов реляционных ключей и таблиц:
Базовая таблица. В реляционной базе данных базовой таблицей называется таблица, которая включает один или несколько столбцов свойств объекта и содержит первичный ключ, который однозначно определяет этот объект. Более того, базовая таблица должна содержать первичный ключ. Базовые таблицы часто называют первичными, поскольку они имеют первичный ключ.
Промежуточная таблица. Таблица, не являющаяся базовой (т.к. она не объединяет свойства объекта или не содержит поле первичного ключа), которая используется для обеспечения связей между другими таблицами, называется таблицей отношений. Ключевые поля в таблицах отнощений должны быть внешними ключами, вязанными с первичными ключами базовой таблицы. Проще говоря, таблица отношений состоит только из внешних ключей и не содержит независимых элементов таблиц.
Первичный ключ. Первичный ключ состоит из набора значений, которые однозначно определяют запись базовой таблицы. Любому значению первичного ключа должна соответствовать одна и только одна строка таблицы. Первичный ключ включает одно поле в том случае, если это поле не содержит повторяющихся значений.
Составные ключи. Если для выполнения условий, накладываемых на значения первичного ключа, заданный ключ включает несколько полей таблицы, то тогда он называется составным.
Внешние ключи. Внешний ключ -это столбец, значения которого соответствуют значениям первичного ключа другой связанной таблицы.
База данных (БД) - структурированный организованный набор данных, описывающих характеристики какой-либо физической или виртуальной системы.
База данных - это организованная структура, предназначенная для хранения информации.
СУБД - инструментальное программное обеспечение, предназначенное для организации ведения БД.
Основным элементом БД является таблица.
Столбцы таблицы БД называются полями , а строки - записями. Первым этапом создания таблицы БД является задание ее структуры, т.е. определение количества и типа полей. Вторым этапом является ввод и редактирование записей в таблицу. БД считается созданной, даже если она пустая. Поля таблицы просто определяют ее структуру и групповые свойства данных, записываемых в ячейках.
Основные свойства полей БД.
Имя поля - определяет как надо обращаться к данным поля (имена используются как заголовки таблиц).
Тип данных (Data Type). Тип данных определяется значениями, которые предполагается вводить в поле, и операциями, которые будут выполняется с этими значениями. В Access допускается использование девяти типов данных. Список возможных типов данных вызывается нажатием кнопки списка при выборе типа данных каждого поля:
Текстовы й (Техt) - тип данных по умолчанию. Текст или цифры, не участвующие в расчетах. Число символов в поле не должно превышать 255.
Поле МЕМО (Меmо). Длительный текст, например, некоторое описание или примечание. Максимальная длина 64 000 символов
Числовой (Number). Числовые данные, используемые в математических вычислениях
Денежный (Currency). Денежные значения и числовые данные, используемые в расчетах
Дата/время (Data/Time). Значения даты или времени, относящиеся к годам с 100 по 9999 включительно. Длина поля 8 байт
Счетчик (AutoNumber). Тип данных поля, в которое для каждой новой записи автоматически вводятся уникальные целые, последовательно возрастающие (на 1), или случайные числа.
Логический (Yes/No). Логические данные, которые могут иметь одно из двух возможных значений Да/Нет
Мастер подстановок.. .(Lookup Wizard...). Выбор этого типа данных запускает мастера подстановок. Мастер строит для поля список значений на основе полей из другой таблицы. Значения в такое поле будут вводиться из одного из полей списка. Соответственно, фактически тип данных поля определяется типом данных поля списка. Возможно также определение поля со списком постоянных значений. Общие свойства поля Общие свойства задаются для каждого поля на вкладке Общие (General) и зависят от выбранного типа данных. Для отображения свойств поля необходимо установить курсор на строке соответствующего поля:
Размер поля (FieldSize) задает максимальный размер данных, сохраняемых.
15. Типы таблиц и ключей в реляционных базах данных. Индексы. Взаимосвязи таблиц. Обеспечение целостности данных.
Реляционные базы данных характеризуются наличием некоторых типов таблиц и ключей, позволяющих определить отношения между таблицами.
В реляционной базе данных базовой таблицей называется таблица, которая включает один или несколько столбцов свойств объекта и содержит первичный ключ, который однозначно определяет этот объект. Более того, базовая таблица должна содержать первичный ключ. Базовые таблицы часто называют первичными, поскольку они имеют первичный ключ. Промежуточная таблица. Таблица, не являющаяся базовой (т. к. она не объединяет свойства объекта или не содержит поле первичного ключа), которая используется для обеспечения связей между другими таблицами, называется таблицей отношений.
Первичный ключ. Первичный ключ состоит из набора значений, которые однозначно определяют запись базовой таблицы. Любому значению первичного ключа должна соответствовать одна и только одна строка таблицы. Первичный ключ включает одно поле только в том случае, если это поле не содержит повторяющихся значений.
Составные ключи . Если для выполнения условий, накладываемых на значения первичного ключа, заданный ключ включает несколько полей таблицы, то тогда он называется составным.
Внешние ключи. Внешний ключ - это столбец, значения которого соответствуют значениям первичного ключа другой связанной таблицы.
Индексы
Индекс (index) представляет собой список позиций записей, который показывает порядок их следования. Для ключевого поля автоматически строится индекс.
Взаимосвязи таблиц
При создании в Access схемы данных в ней определяются и запоминаются связи между таблицами.
Виды связей
Одно-многозначные (1:М) или одно-однозначные (1:1) связи. Схема данных прежде всего ориентирована на работу с таблицами, отвечающими требованиям нормализации, между которыми могут быть установлены одно-многозначные (1:М) или одно-однозначные (1:1) связи, для которых может автоматически поддерживаться связная целостность. Access выявляет отношение один-ко-многим между записями главной таблицы к подчиненной. В этом случае можно задать автоматическое поддержание целостности связей.
Отношение многие-ко-многим. Отношение многие-ко-многим предполагает, что каждой записи в одной таблице соответствует несколько записей в другой. При этом каждая сторона отношения выглядит как отношение один-ко-многим. Однако если рассматривать взаимосвязь таблиц с двух сторон, становится очевидным, что ни одна из таблиц не может быть главной и для их связывания необходима третья таблица.
Обеспечение целостности данных
Для связей типа 1:1 и 1:М можно задать параметр обеспечения связной целостности данных, а также автоматическое каскадное обновление и удаление связанных записей. Обеспечение связной целостности данных означает, что Access при корректировке базы данных обеспечивает для связанных таблиц контроль за соблюдением следующих условий:
1. В подчиненную таблицу не может быть добавлена запись с несуществующим в главной таблице значением ключа связи;
2. В главной таблице нельзя удалить запись, если не удалены связанные с ней записи в подчиненной таблице;
3. Изменение значений ключа связи в записи главной таблицы невозможно, если в подчиненной таблице имеются связанные с ней записи.
При попытке пользователя нарушить эти условия в операциях добавления и удаления записей или обновления ключевых данных в связанных таблицах Access выводит соответствующее сообщение и не допускает выполнения операции.
Access не позволяет установить параметр целостности для связи таблиц, если ранее введенные в таблицы данные не отвечают требованиям целостности.
1. Создать новый запрос, включив в него таблицы, содержащие записи, которые следует обновить.
2. В режиме Конструктор нажать кнопку Тип запроса Обновление.
3. Включить в бланк запроса поля, которые нужно обновить, а также поля, для которых нужно определить условие отбора.
4. Для полей, которые нужно обновить, в ячейку Обновление ввести выражение или значение, которое должно быть использовано для изменения полей.
5. Для полей, по которым нужно выполнить отбор обновляемых записей, ввести условия отбора.
6. Для обновления записей нажать кнопку Запуск на панели инструментов.
Пример. Требуется создать запрос на обновление, после выполнения которого в таблице СОТРУДНИКИ будут увеличены на 20% оклады сотрудников, принятых на работу до 01.01.2000.
При заполнении бланка запроса включаем в него поля Оклад и Дата назначения из таблицы СОТРУДНИКИ.
Для поля Оклад в строке Обновление вводим правило обновления: [Оклад] * 1,2
Для поля Дата назначения в строке Условие отбора вводим условие: < 01.01.2000 (рис. 44).
В результате выполнения этого запроса в таблице СОТРУДНИКИ будут изменены значения в поле Оклад в тех записях таблицы, для которых значение в поле Дата назначения меньше 01.01.2000.
Рис. 44. Создание запроса на обновление записей базовых таблиц
Запрос на создание таблицы создает новую базовую таблицу (имена базовых таблиц указаны на вкладке Таблицы в окне базы данных) на основе всех или части данных из одной или нескольких таблиц. Запрос на создание таблицы полезен для выполнения следующих действий:
- Создание таблицы для экспорта в другую базу данных Microsoft Access. Например, требуется создать таблицу, содержащую несколько полей из таблицы СОТРУДНИКИ, а затем экспортировать эту таблицу в базу данных, используемую отделом кадров.
- Создание резервной копии таблицы.
- Создание архивной таблицы, содержащей старые записи. Например, можно создать таблицу, сохраняющую все старые заказы, прежде чем удалить их из текущей таблицы.
Создание запроса на создание новой таблицы
1. Создать новый запрос, включив в него таблицы, содержащие записи, которые следует включить во вновь создаваемую таблицу.
2. В режиме Конструктор нажать кнопку Тип запроса на панели инструментов и выбрать Создание таблицы . Будет открыто диалоговое окно Создание таблицы .
3. В поле Имя таблицы ввести имя таблицы, которую необходимо создать.
4. Выбрать переключатель В текущей базе данных
, чтобы поместить таблицу в открытую в данный момент базу данных, или переключатель В другой базе данных
и ввести имя базы данных, в которую требуется поместить новую таблицу. Нажать кнопку
5. Включить в бланк запроса поля, которые нужно поместить в новую таблицу.
6. Для полей, по которым нужно выполнить отбор записей, ввести условия отбора.
7. Для запуска процедуры создания таблицы нажать кнопку Запуск на панели инструментов.
8. Результат выполнения запроса – новая таблица, имя которой появляется на вкладке Таблицы в окне базы данных.
Пример. Требуется создать запрос на создание новой базовой таблицы АДРЕСА_СОТРУДНИКОВ, которая должна содержать поля Фамилия, Имя, Отчество из таблицы СОТРУДНИКИ и поля Адрес, Телефон из таблицы ЛИЧНЫЕ ДАННЫЕ.
При заполнении бланка запроса включаем в него требуемые поля из таблиц СОТРУДНИКИ и ЛИЧНЫЕ ДАННЫЕ (рис. 45). Нажав кнопкуТип запроса , выбираем Создание таблицы и вводим в диалоговом окне имя новой таблицы АДРЕСА_СОТРУДНИКОВ.
Выполнив запрос, переключаемся на вкладку Таблицы в окне База данных . Можем убедиться в том, что в списке таблиц базы данных появилась новая базовая таблица с именем АДРЕСА_СОТРУДНИКОВ.
Рис. 45. Создание запроса на создание новой базовой таблицы