Самоучитель Microsoft Access 2013

Глава 1 
Ответы 
1.
Да. 
2.
Для более удобного и быстрого выполнения часто используемых команд. 
3.
Главная
(Home), 
Создание
(Create), 
Внешние данные
(External Data) и 
Работа 
с базами данных 
(Database Tools). 
4.
Область навигации. 
5.
Да. 
6.
Переместить на кнопку курсор. 
7.
Нет. 
8.
Таблицы, запросы, формы, отчеты, макросы и модули. 
9.
Составом полей. 
10.
Для однозначной идентификации каждой записи таблицы. 
11.
Отношениями записей типа "один-к-одному" (1 : 1) и "один-ко-многим" (1 : M). 
12.
Для связи двух таблиц с помощью одинакового поля в них. 
13.
Отслеживать изменение имен таблиц, полей, запросов, элементов управления 
и др. и выполнять их автозамену в зависимых объектах. 
14.
Нет. 
15.
accdb
. 
16.
accde
. 
17.
Да. 
18.
Блокировка может осуществляться на обоих уровнях. 
19.
ODBC. 
20.
Для публикации и совместного использования на страницах SharePoint Server 
с помощью Internet Explorer. 
21.
Режим конструктора. 
22.
Internet Explorer не ниже 8-й версии. 
23.
Да. 
24.
SharePoint Server 2013, установленный в сети организации или предостав-
ляемый в облаке Office 365. 
25.
На SQL Server 2012, определенном в SharePoint Server 2013. 

---

ГЛ А В А
2 
Проектирование
реляционной базы данных 
База данных Access является 
реляционной базой данных
. Такая база данных состоит 
из взаимосвязанных реляционных таблиц. На этапе проектирования базы данных 
для выбранной предметной области
должна быть определена 
логическая структу-
ра базы данных
. Проект логической структуры БД устанавливает состав реляцион-
ных таблиц, их структуру и логические связи между таблицами. При формирова-
нии структуры каждой таблицы определяется совокупность полей (столбцов), для 
каждого из которых определяется тип, размер данных и другие свойства. Для таб-
лицы должен быть указан уникальный ключ, который может состоять из одного 
или нескольких полей. 
При проектировании базы данных, отвечающей требованиям нормализации, между 
таблицами определяются логические связи с типом отношений "один-ко-многим" 
(1 : М). Такие связи позволят осуществлять в Access автоматическое поддержание 
связной целостности и непротиворечивости данных в базе. 
Этапы проектирования и создания
базы данных 
Для проектирования базы данных необходимо располагать описанием выбранной 
предметной области, которое должно охватывать реальные объекты и процессы, 
определять все необходимые источники информации для обеспечения предпола-
гаемых запросов пользователя и решаемых в приложении задач. 
Определение состава и структуры данных, которые должны быть загружены в базу 
данных, осуществляется на основе анализа предметной области. Структура данных 
предметной области может отображаться 
информационно-логической моделью 
(ИЛМ). Если при построении такой модели обеспечены требования нормализации 
данных и она, соответственно, представлена в каноническом виде, далее легко оп-
ределяется проект логической структуры нормализованной базы данных. На основе 
канонической модели можно создать реляционную базу без дублирования данных. 
К разработке модели данных предметной области существуют два подхода. 
В первом подходе (аналитическом или процессном) сначала формулируются ос-

---

62 
Глава 2 
новные задачи, для решения которых строится база, выявляются информационные 
потребности задач приложения пользователя, и, соответственно, определяются со-
став и структура информационных объектов модели, а также связи между ними. 
При втором подходе (интуитивном) сразу устанавливаются типовые информацион-
ные объекты предметной области и их взаимосвязи. Наиболее рационально сочета-
ние обоих подходов. Это связано с тем, что на начальном этапе, как правило, нет 
исчерпывающих сведений обо всех задачах. Использование такой технологии тем 
более оправдано, что гибкие средства создания реляционной базы данных позво-
ляют на любом этапе разработки внести изменения в базу данных и модифициро-
вать ее структуру без ущерба для введенных ранее данных. 
Этапы проектирования и создания базы данных Access иллюстрирует схема, приве-
денная на рис. 2.1. 
В процессе разработки 
канонической модели данных 
предметной области для про-
ектирования реляционной базы данных необходимо выделить
информационные 
объекты 
(ИО), соответствующие требованиям нормализации данных, и определить 
связи между ИО с типом отношений 1 : М. 
Построение
модели данных
предметной
области
ИЛМ
Документы
предметной
области
Определение
структуры
реляционной
базы данных
ИЛМ
Проект структуры
базы данных
Конструирование
таблиц базы
данных Access
Пустые таблицы
базы данных
Access
Проект структуры
таблиц базы данных
Создание схемы
данных в Access
Связи таблиц
базы данных
Таблицы базы
данных
Access
Схема данных
в Access
К
К
М
М
Ввод данных
в таблицы
(создание
записей)
Исходные данные
Записи в таблицах
П
Р
О
Е
К
Т
С
О
З
Д
А
Н
И
Е
Рис. 2.1.
Этапы проектирования и создания базы данных Access 

---

Проектирование реляционной базы данных 
63 
При определении проекта логической структуры реляционной базы данных каждый 
информационный объект канонической модели предметной области адекватно ото-
бражается реляционной таблицей, а связям между двумя информационными объек-
тами соответствуют логические связи между парой соответствующих таблиц.
Такие связи устанавливаются по уникальному ключу главной таблицы. Во второй 
таблице, которая является подчиненной, поле связи может быть либо частью ее 
уникального ключа, либо не входить в состав ключа вовсе. 
В процессе создания базы данных на компьютере сначала осуществляется конст-
руирование ее таблиц
средствами Access. Для поддержания целостности данных в 
каждой таблице определяется ключевое поле и правила проверки значений данных 
в полях. Далее создается схема данных, в которой устанавливаются логические свя-
зи таблиц. В схеме данных базы могут быть заданы параметры поддержания связ-
ной целостности данных. 
Связная
целостность данных
означает, что в базе данных установлены и корректно 
поддерживаются взаимосвязи между записями разных таблиц при загрузке, добав-
лении и удалении записей в связанных таблицах, а также при изменении значений 
ключевых полей. При обеспечении связной целостности в подчиненной таблице не 
может существовать запись, для которой отсутствует связанная запись в главной 
таблице. 
После формирования в Access схемы данных можно приступать к вводу данных
в базу — 
загрузке
c документов предметной области, являющихся источниками 
данных. В практических приложениях пользователя обычно не используется ввод 
непосредственно в таблицы, а применяются специально создаваемые экранные 
формы, играющие роль интерфейса пользователя. Фактически новый документ
готовится (заполняется) на компьютере и сохраняется в базе данных. 
Проектирование базы данных, основанное на построении нормализованной модели 
данных предметной области, позволяет легко получить логическую структуру ре-
ляционной базы данных Access, в которой автоматически поддерживается целост-
ность и непротиворечивость данных. 
Построение
информационно-логической модели данных 
Информационно-логическая модель (ИЛМ) отображает данные предметной облас-
ти в виде совокупности информационных объектов (ИО) и связей между ними. Эта 
модель представляет данные, подлежащие хранению в базе данных. Каждый ин-
формационный объект в модели данных должен иметь уникальное имя. 
Информационные объекты 
Информационный объект
— это информационное описание некоторой сущности 
предметной области: реального объекта, процесса, явления или события. Информа-
ционный объект является совокупностью логически взаимосвязанных реквизитов, 

---

64 
Глава 2 
представляющих качественные и количественные характеристики сущности. При-
мерами сущностей являются: товар, поставщик, заказчик, поставка, отгрузка, со-
трудник, отдел, студент, преподаватель, кафедра и т. п. 
Информационный объект имеет множество реализаций — 
экземпляров объекта
. 
Например, каждый экземпляр информационного объекта 
ТОВАР
содержит значения 
реквизитов по товару определенного наименования. Экземпляр объекта должен 
однозначно определяться среди всего множества экземпляров, т. е. идентифициро-
ваться значением 
уникального (первичного)
ключа 
информационного объекта. Уни-
кальность ключа означает, что любое значение ключа не может повториться в ка-
ком-либо другом экземпляре объекта. 
Простой ключ
состоит из одного реквизита. 
Составной ключ
— из нескольких реквизитов. Таким образом, реквизиты инфор-
мационного объекта подразделяются на ключевые и описательные, которые явля-
ются функционально зависимыми от ключа. 
Функциональные зависимости реквизитов 
Информационные объекты могут быть выделены на основе описания предметной 
области путем определения 
функциональных зависимостей между реквизитами
предметной области. Функциональная зависимость реквизитов информационного 
объекта устанавливает соответствие значений ключевых (определяющих) и неклю-
чевых (определяемых) реквизитов. 
Необходимость установления функциональных зависимостей связана с требовани-
ем баз данных по однозначной определяемости любых данных для их размещения 
и доступа к ним. Например, для однозначной и полной определяемости реквизита 
количество
в поставке товара нужно указать, 
что
поставляется, — т. е. товар (его 
идентификатор), и нужно указать, 
кем
поставляется, — т. е. указать поставщика 
(его идентификатор). Если возможны поставки одного товара поставщиком в раз-
ные сроки, то нужно также указать, 
когда
осуществляется поставка, — т. е. принять 
срок поставки, как показатель, тоже участвующий в идентификации поставки. 
Если не будет выявлена полная функциональная зависимость, реквизит 
количество
поставки останется не определенным однозначно. Так, если в функциональных за-
висимостях количества поставки не определен срок поставки, то нельзя отличить 
друг от друга несколько поставок одного и того же товара одним и тем же постав-
щиком, но в разные сроки. В этом случае имеет место неполная идентификация по-
ставки на этапе проектирования. После реализации проекта это приведет к возмож-
ности загрузки в базу данных сведений о количестве только по одной поставке 
(первой введенной), т. к. для одного значения идентификатора 
Код товара +
Код 
поставщика
, т. е. одного товара и одного поставщика, может быть введено только 
одно значение количества поставляемого. Наглядная иллюстрация этой ситуации, 
когда срок поставки не указан как ключевой (определяющий поставку), представ-
лена в табл. 2.1. 
З
АМЕЧАНИЕ
При выявлении функциональных зависимостей реквизитов не рассматриваются 
арифметические зависимости (например, стоимость от количества), поскольку уста-
навливается только функциональная зависимость, определяющая логические связи 
описательных и ключевых реквизитов. 

---

Проектирование реляционной базы данных 
65 
Таблица 2.1.
Пример идентификации поставок товаров 
Реквизит 
Код 
товара 
Код 
поставщика 
Срок
поставки 
Количество 
поставки 
Результат
в базе 
данных 
Роль в функцио-
нальной зависи-
мости 
Ключевой Ключевой
Зависимый
Идентификатор поставки 
Поставка 1 
Т1 
П1 
Февраль 
10 
Введена 
Поставка 2 
Т1 
П1 
Апрель 
20 
Не введена 
При графическом изображении модели данных каждый информационный объект 
представляется прямоугольником с обозначением его имени и идентификатора — 
ключа. Пример такого изображения для информационных объектов 
ТОВАР
и 
ПОСТАВКА
показан на рис. 2.2. Здесь 
KOД_Т
(код товара) — простой ключ объекта 
ТОВАР
, а 
KOД_T 
+ 
KПОСТ
(код поставщика) + 
СРОКП
(срок поставки) — составной ключ 
объекта 
ПОСТАВКА
. 
ТОВАР
КОД_Т
ПОСТАВКА
КОД_Т + КПОСТ + СРОКП
Рис. 2.2.
Пример графического изображения информационных объектов
с простым и составным ключами 
Требования нормализации 
Реквизиты каждого информационного объекта канонической модели данных долж-
ны отвечать требованиям, соответствующим 
третьей нормальной форме
реляци-
онной модели данных:
информационный объект должен содержать уникальный идентификатор — 
ключ; 
все описательные реквизиты должны быть взаимонезависимы, т. е. между ними 
не должно быть функциональных зависимостей; 
все реквизиты, входящие в составной ключ, также должны быть взаимонезави-
симы; 
каждый описательный реквизит должен 
функционально полно
зависеть от ключа, 
т. е. каждому значению ключа должно соответствовать только одно значе- 
ние описательного реквизита, а при составном ключе описательные рекви- 
зиты должны зависеть целиком от всей совокупности реквизитов, образующих 
ключ; 
каждый описательный реквизит должен зависеть от ключа 
нетранзитивно
, т. е. 
не должен зависеть через другой промежуточный реквизит. 

---

66