Access 2000. Проектирование баз данных

Вием П. С

(

ля

Дубнов П. Ю.

Access 2 0 0 0 Проектирование баз данных

Москва, 2000

ББК 32.973.26-018.2 Д79 Д79

Дубнов П. Ю. Access 2000. Проектирование баз данных. - М.: ДМК, 2000. - 272 с : ил. ISBN 5-89818-091-5 В книге рассматривается широкий круг вопросов, связанных с использо­ ванием программной среды Access 2000, которая является составной час­ тью пакета Office 2000 и предназначена для создания банка данных. Предлагается формализованный подход к определению структуры тех­ нико-экономических показателей, посредством которых описываются лю­ бые процессы управления, и на основе этого подхода дается обоснование выбора первичных файлов (таблиц) в базах данных. Детально обсуждаются вопросы создания интегрированной базы данных в среде Access 2000: формирование БД с нуля, конвертирование в программ­ ную среду баз данных, созданных в ином программном окружении - Clarion, FoxPro. Представлены возможности формирования разнообразных запросов к ин­ тегрированной базе данных Access 2000 с использованием языка SQL и мак­ росов. Книга может быть полезна специалистам, занимающимся практической разработкой банков данных и приложений на их основе, а также студентам соответствующих специальностей. ББК 32.973.26-018.2

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

ISBN 5-89818-091-5

© Дубнов П. Ю., 2000 ©ДМК, 2000

Содержание Введение

9

Глава I Постановка проблемы

11

Режимы функционирования банка данных в производственных условиях

11

Пользовательские запросы к банку данных

12

Проблемы, связанные с выбором СУБД Вопросы, рассмотренные в настоящей книге

12 15

Резюме

15

Глава II Предпроектная структуризация информации

16

Состав информации

17

Что понимать под структуризацией информации

17

Показатели Необходимость структуризации Технология структуризации Пример структуризации данных

Проектирование логической структуры.бозы данных Распределение полей по файлам Файлы и связи между ними

Резюме

18 19 20 21

23 24 24

26

Глава III Создание таблиц новой базы данных

27

Варианты создания таблиц

27

Формирование таблицы в режиме ввода Ввод данных

29 29

Access 2000

4 Создание таблицы в режиме конструктора

31

Окно конструктора таблиц Типы данных и их свойства Свойства полей Установка значений свойств Input Mask и Format

31 32 35 35

Создание и использование полей подстановки

41

Подстановка в режиме конструктора таблиц Подстановка в режиме таблицы

Организация связей между таблицами Создание связей между таблицами Вложенные таблицы данных Мастер печати связей

Резюме

42 45

46 46 50 52

54

Глава IV Создание форм новой базы д а н н ы х

55

Использование автоформы

56

Создание формы с помощью мастера форм

58

Работа в режиме конструктора

64

Заголовок формы Командные кнопки

66 69

Начальная форма при открытии базы данных или приложения

75

Построение запросов для отбора нужных данных

75

Ввод и корректировка данных

79

Использование гиперссылок

82

Access и географические карты Поиск карты Установка гиперссылок в базе данных Установка гиперссылки из карты в базу данных

Резюме

82 83 84 86

90

Глава V Создание отчетов новой базы д а н н ы х

91

Использование функции автоотчета

92

Включение подчиненного отчета

92

Группировка записей

95

Содержание Статическая копия отчета Инструменты для работы с копией Преимущества использования Создание статической копии отчета Резюме'

5 99 100 100 101 103

Глава V I Создание страниц доступа к д а н н ы м

105

Свойства страниц доступа к данным

105

Страницы доступа к сгруппированным данным

107

Использование страниц доступа к данным Страница доступа к данным: вводданных Создание и открытие страницы доступа к данным Создание страницы доступа к данным в режиме автостраницы Создание страницы доступа к данным с помощью мастера страниц Создание страницы доступа к данным в режиме конструктора Открытие страницы доступа к данным в окне базы данных Открытие страницы доступа к данным в Internet Explorer Передача страницы доступа к данным по электронной почте Экспорт страницы доступа к данным в существующую базу данных Список полей Сводная таблица Создание сводной таблицы для страницы доступа к данным Резюме

108 108 108 108 109 114 1 17 1 18 118 119 1 19 119 120 121

Глава V I I Конвертирование баз д а н н ы х из других программных сред

123

Процесс конвертирования баз данных

124

Импорт базы данных БД ЧЭС

126

Первый этап: импорт данных из среды Clarion в dBase Второй этап: импорт данных из dBase в Access 2000 Импорт файлов Импорт базы данных Контроль ЧС Первый этап: импорт данных из FoxPro в Access 97 Второй этап: импорт данных из Access 97 в Access 2000 Резюме

126 127 128 135 136 139 140

6

Access 2000

Глава V I I I Общие вопросы программирования в Access .... 141 С р а в н и т е л ь н а я х а р а к т е р и с т и к а языков п р о г р а м м и р о в а н и я в Access Язык SQL Макросы Процедуры VBA

141 141 142 143

В ы б о р языка п р о г р а м м и р о в а н и я

144

Резюме

145

Глава IX Программирование на я з ы к е SQL

146

Типы запросов

146

Запросы на выборку

148

Простые запросы Представление запроса на языке SQL Запросы с использованием групповых операций Запросы с дополнительными условиями Запросы с параметрами Запросы с участием нескольких связанных таблиц Пояснения к инструкции SQL Создание объединенной выборки Пример сложного запроса Запрос на создание таблицы Запрос на добавление записей в таблицу

148 151 153 156 165 167 169 173 1 74 174 1 76

Запрос на удаление записей

179

Удаление дублирующихся записей

181

Запрос на поиск повторяющихся записей Удаление повторяющихся записей Ввод нового поля Запрос на обновление записей И снова - запрос на добавление Перекрестный запрос Построение перекрестного запроса с использованием мастера Ввод условий отбора записей в конструкторе запросов

181 183 185 186 187 190 191 195

Содержание

'

Работа со средой Access 2000 без ее инсталляции

197

Резюме

202

Глава X Программирование с использованием макросов

205

Функции макросов

205

Использование макросов для обработки событий

206

Понятие события Последовательности событий Автоматический перевод фокуса при помощи макроса

206 207 213

Использование макроса при выполнении сложного запроса

215

Резюме

217

Глава X I Программирование с помощью процедур V B A Основные положения VBA Ьазовые термины Окно модуля Основные элементы Переменные Константы Аргументы Типы процедур и их элементы Процедуры Sub Функции Элементы процедур Просмотр объектов Управление выполнением программы Программирование приложений с помощью VBA

219 219 220 221 223 223 223 224 226 226 227 227 228 230 23-1

Предупреждение дублирования записей при их вводе из формы ... 232 Обработка ошибок выполнения Функция создаваемой программы Логическая конструкция If...Then...Else

234 237 238

8

Access 2000 Проверка завершенной процедуры

239

Установка на последнюю запись при открытии формы

243

Удаление записи с установкой на последнюю запись

246

Резюме

250

Глава XII Д р у г и е возможности Access 2 0 0 0

251

Установка Access 2000

251

Условное форматирование Пример условного форматирования

255 255

Буфер обмена Новое содержание Новые возможности для работы

258 259 259

Автоисправление имен

260

Функции автоисправления имен Ограничения на использование функции Использование функции

260 260 261

Разделение базы данных

262

Сжатие базы данных при ее закрытии

263

Конвертирование базы данных Конвертирование из Access 97 (95) в Access 2000 Конвертирование из Access 2000 в Access 97 (95)

264 264 265

Резюме

266

Алфавитный указатель

268

Введение Автоматизированные банки данных уже давно стали неотъемлемой частью прак­ тически всех компьютерных систем управления на любом уровне - от отрасли до отдельного предприятия. Однако проектирование и создание баз данных (БД) до сих пор остается, за редким исключением, не технической задачей, а творческим процессом, который скорее сродни искусству, нежели науке. Это утверждение может показаться не­ сколько странным: ведь разработка и исследование баз данных ведутся более 30 лет. Однако, как нам кажется, такой парадокс вполне объясним. За прошедшие годы неизмеримо вырос уровень потребительских качеств систем управления базами данных (СУБД): разнообразие поддерживаемых функций, удобный для пользо­ вателя интерфейс, сопряжение с программными продуктами - в частности, с дру­ гими СУБД, возможности для работы в сети и т.д. Но изменения почти не коснулись того, что раньше называлось логическими структурами баз данных. Это формы, в которых пользователь представляет и хра­ нит свою информацию в БД. А ведь именно от них в немалой степени зависит удобство работы пользователя с базой данных: формулировка запроса, простота поиска данных, форма выдачи итоговой информации и другие операции. В совре­ менных БД могут использоваться более или менее удачные структуры, но почти никогда мы не найдем обоснованного ответа на вопрос, почему для конкретной базы данных была выбрана именно такая форма. Однако к настоящему времени накоплен значительный опыт проектирования банков данных, предназначенных для управления производством. Это позволяет сделать процесс создания БД значительно более формализованным. (Правда, поле для субъективных решений, а значит, и для индивидуального творчества, все рав­ но остается, но его можно существенно сузить.) Итак, речь идет об информации, которая формируется и накапливается в ком­ пьютерных банках данных. В условиях реальной производственной деятельности это понятие употребляется в двух различных значениях: а информация, прежде хранившаяся на бумажных носителях и внесенная в новый банк данных, который создавался на основе какой-либо СУБД. Сюда же следует отнести и сведения, связанные с текущим производствен­ ным процессом. Они вводятся в банк данных в реальном масштабе времени; • банк данных, который был создан ранее и используется до сих пор. Постепенно разница между двумя названными типами данных стирается. С одной стороны, неизбежно появляется новая информация, которую надо структурировать

10

Введение

и организовать в банке данных, и создаются новые СУБД, более удобные, чем прежние. С другой стороны, ранее накопленные сведения продолжают храниться в банке данных, который наверняка никто никогда не будет перестраивать. Обыч­ но самое простое решение проблемы - конвертировать старые данные в новую СУБД, объединяя информационные массивы и решая возникающие при этом проблемы. В результате возникает новый банк данных, куда входят разные БД 1 . Все они имеют один формат данных (например, для Access это mdb), но сохраня­ ют прежнюю структуру первичных файлов, таблиц и т.д. Иными словами, данные остаются в значительной мере разнородными, что осложняет дальнейшую работу с ними. Поэтому после конвертации или интеграции разнородных баз данных в еди­ ную программную среду пользователю потребуется дополнительное (иногда спе­ циальное) программное обеспечение, чтобы обслуживать полученную БД. До сих пор в специальной литературе рассматривалась только одна сторона за­ дачи - создание новых баз данных. О том, как конвертировать собранную инфор­ мацию в программную среду новой СУБД, написано значительно меньше. Нако­ нец, мало внимания уделялось другой важной проблеме: какой должна быть единая программная среда и почему. Книга, которую вы держите в руках, призвана в какой-то степени ответить на перечисленные вопросы. Этим обусловлена и ее структура: • в главе 1 проблемы, анализируемые в книге, подробно рассматриваются на конкретных примерах. Кроме того, в данной главе объясняется, почему для решения стоящих перед пользователем проблем необходима именно про­ граммная среда Access 2000; • глава 2 посвящена методическим аспектам вопроса - разработке такой струк­ туры данных, которая не будет зависеть от программной среды; • в главах 3-6 говорится о создании базы данных в программной среде Access 2000. Поскольку эта среда содержит элементы, которых не было в предыду­ щих версиях Access, приводятся необходимые пояснения; • в главе 7 изучаются вопросы, связанные с конвертированием баз данных из других СУБД в Access 2000; • в главах 8-11 рассматривается программирование в объединенном банке дан­ ных и его различные варианты: программирование на языках SQL и Visual Basic, а также с использованием макросов; • глава 12 содержит информацию о тех дополнениях, которые были внесены в Access 2000, но не применялись при работе с описанными в книге базами данных. 1

В современной научной литературе понятия «база данных» и «банк данных» часто смешиваются. Тра­ диционно эти термины определялись следующим образом. База данных понималась как набор свя­ занных таблиц, запросов, форм, отчетов, макросов и модулей. Так, в среде Access база данных пред­ ставляет собой единый файл с расширением mdb. Банк данных рассматривался как совокупность различных баз данных и программ по их обслуживанию. Однако, если база данных включает такие объекты, как форма, отчет, запрос, модуль и др., то в нее входят также программы создания и обслу­ живания объектов. Тогда под банком данных следует, видимо, понимать множество баз данных в еди­ ном формате (скажем, в том же mdb), и набор программ, позволяющих работать с этими данными.

Глава I Постановка проблемы •

Режимы функционирования банка данных в производственных условиях

•

Пользовательские запросы к банку данных

Сегодня никого нельзя удивить понятием «компьютерный автоматизированный банк данных». Это так же обычно, как передача сообщений по факсу или заказ билетов по телефону. Существует бесчисленное множество функционирующих банков данных, однако далеко не все они удобны в эксплуатации. Пользователю, работающему с банком данных, необходимо «умение» последнего быстро, гиб­ ко и в требуемой форме организовать и выдать информацию в ответ на любой запрос. В этой книге подробно рассказывается обо всех проблемах, с которыми может встретиться разработчик баз и банков данных: начиная с логической структури­ зации и заканчивая написанием сложных макрокоманд. Особое внимание уделе­ но вопросам интеграции разнородных баз данных в единый эффективно функци­ онирующий информационный банк. Все решения показаны на примере реальной базы данных по чрезвычайным ситуациям, о содержимом и структуре которой рассказано в начале главы 2.

Режимы функционирования банка данных в производственных условиях Как правило, предусматриваются следующие режимы функционирования банка данных: • режим начальной загрузки, в котором исходная информация, содержащая­ ся в банке данных, вводится в соответствующие структуры БД; • режим корректировки, в котором осуществляется обновление, добавление и удаление информации, находящейся в банке данных;

10

Введение

и организовать в банке данных, и создаются новые СУБД, более удобные, чем прежние. С другой стороны, ранее накопленные сведения продолжают храниться в банке данных, который наверняка никто никогда не будет перестраивать. Обыч­ но самое простое решение проблемы - конвертировать старые данные в новую СУБД, объединяя информационные массивы и решая возникающие при этом проблемы. В результате возникает новый банк данных, куда входят разные БД 1 . Все они имеют один формат данных (например, для Access это . mdb), но сохраня­ ют прежнюю структуру первичных файлов, таблиц и т.д. Иными словами, данные остаются в значительной мере разнородными, что осложняет дальнейшую работу с ними. Поэтому после конвертации или интеграции разнородных баз данных в еди­ ную программную среду пользователю потребуется дополнительное (иногда спе­ циальное) программное обеспечение, чтобы обслуживать полученную БД. До сих пор в специальной литературе рассматривалась только одна сторона за­ дачи - создание новых баз данных. О том, как конвертировать собранную инфор­ мацию в программную среду новой СУБД, написано значительно меньше. Нако­ нец, мало внимания уделялось другой важной проблеме: какой должна быть единая программная среда и почему. Книга, которую вы держите в руках, призвана в какой-то степени ответить на перечисленные вопросы. Этим обусловлена и ее структура: Q в главе 1 проблемы, анализируемые в книге, подробно рассматриваются на конкретных примерах. Кроме того, в данной главе объясняется, почему для решения стоящих перед пользователем проблем необходима именно про­ граммная среда Access 2000; • глава 2 посвящена методическим аспектам вопроса - разработке такой струк­ туры данных, которая не будет зависеть от программной среды; • в главах 3-6 говорится о создании базы данных в программной среде Access 2000. Поскольку эта среда содержит элементы, которых не было в предыду­ щих версиях Access, приводятся необходимые пояснения; • в главе 7 изучаются вопросы, связанные с конвертированием баз данных из других СУБД в Access 2000; • в главах 8-11 рассматривается программирование в объединенном банке дан­ ных и его различные варианты: программирование на языках SQL и Visual Basic, а также с использованием макросов; • глава 12 содержит информацию о тех дополнениях, которые были внесены в Access 2000, но не применялись при работе с описанными в книге базами данных. 1

В современной научной литературе понятия «база данных» и «банк данных» часто смешинаются. Тра­ диционно эти термины определялись следующим образом. База данных понималась как набор свя­ занных таблиц, запросов, форм, отчетов, макросов и модулей. Так, в среде Access база данных пред­ ставляет собой единый файл с расширением mdb. Банк данных рассматривался как совокупность различных баз данных и программ но их обслуживанию. Однако, если база данных включает такие объекты, как форма, отчет, запрос, модуль и др., то в нее входят также программы создания и обслу­ живания объектов. Тогда под банком данных следует, видимо, понимать множество баз данных в еди­ ном формате (скажем, в том же mdb), и набор программ, позволяющих работать с этими данными.

Глава I Постановка проблемы •

Режимы функционирования банка данных в производственных условиях

•

Пользовательские запросы к банку данных

Сегодня никого нельзя удивить понятием «компьютерный автоматизированный банк данных». Это так же обычно, как передача сообщений по факсу или заказ билетов по телефону. Существует бесчисленное множество функционирующих банков данных, однако далеко не все они удобны в эксплуатации. Пользователю, работающему с банком данных, необходимо «умение» последнего быстро, гиб­ ко и в требуемой форме организовать и выдать информацию в ответ на любой запрос. В этой книге подробно рассказывается обо всех проблемах, с которыми может встретиться разработчик баз и банков данных: начиная с логической структури­ зации и заканчивая написанием сложных макрокоманд. Особое внимание уделе­ но вопросам интеграции разнородных баз данных в единый эффективно функци­ онирующий информационный банк. Все решения показаны на примере реальной базы данных по чрезвычайным ситуациям, о содержимом и структуре которой рассказано в начале главы 2.

Режимы функционирования банка данных в производственных условиях Как правило, предусматриваются следующие режимы функционирования банка данных: • режим начальной загрузки, в котором исходная информация, содержащая­ ся в банке данных, вводится в соответствующие структуры БД; • режим корректировки, в котором осуществляется обновление, добавление и удаление информации, находящейся в банке данных;

12

Постановка проблемы

Q режим диалога, в котором пользователи обращаются к банку данных и про­ изводится обработка запросов. Такие запросы могут предусматривать: - только выдачу пользователю информации о тех или иных параметрах про­ цесса. Эта информация в требуемом формате содержится в банке данных; - решение поставленной задачи с использованием сведений, находящихся в банке данных; О режим реорганизации и анализа, в котором выполняются операции, непо­ средственно связанные с поддержанием банка данных в рабочем состоянии; - реорганизация структур БД; - копирование и восстановление БД; - анализ статистических данных, связанных с функционированием инфор­ мационного фонда.

Пользовательские запросы к банку данных Из всех перечисленных выше для пользователя наиболее важен режим диалога, а все остальные носят служебный, вспомогательный характер. Режим диалога по­ зволяет формировать самые различные запросы и является первым и необходи­ мым шагом к аналитической обработке информации. Конечно, нельзя заранее предусмотреть все возможные варианты запросов. Ниже перечислены лишь самые характерные типы запросов пользователя к бан­ ку данных в порядке возрастания сложности: • запросы на обработку данных, связанных с одной таблицей (выборка, уда­ ление, корректировка и ввод данных); О запросы на групповую обработку данных (сумма, среднее значение и т.д.), связанных с одной таблицей; • запросы, при которых условием отбора записи является полное значение поля; • запросы, при которых условием отбора записи является неполное значение поля; • запросы с несколькими условиями отбора записей в разных полях; • запросы с несколькими условиями отбора записей в одном поле; • запросы с заданием параметров; Q запросы на создание объединенной выборки из нескольких разнородных таблиц и т.д. Как уже говорилось, наличие в банке разнородных баз данных несколько услож­ няет работу. Подробнее этот вопрос рассматривается ниже.

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

Пользовательские запросы к банку данных

13

а для упорядоченного накопления и хранения поступающей информации при­ ходится разрабатывать новые базы данных. Логично, что вы будете оцени­ вать различные СУБД именно с этой точки зрения. Здесь не требуется осо­ бых комментариев; • история использования компьютерных банков данных в СССР и в постсо­ ветской России насчитывает около 30 лет, за которые сменилось несколько поколений СУБД. Можно увлеченно спорить о том, насколько рациональ­ ным был этот процесс и какова эффективность той или иной конкретной СУБД. Однако важнее другое - хороши или плохи были эти системы, но в них аккумулировано значительное количество информации, которая ис­ пользуется в практических целях. Ясно, что с каждым годом объем таких данных возрастает. Системы управления непрерывно совершенствуются. Мировой опыт показы­ вает, что поколения СУБД сменяются примерно каждые 5 лет. Естественно, все более актуальным становится вопрос конвертирования данных, то есть перевода их в новую программную среду без потери информации. Решая, какую СУБД выбрать, обязательно учитывайте ее возможности конвертирования; они не менее ва.^ны, чем удобство разработки БД в данной программной среде. Обоим названным условиям удовлетворяет СУБД Access. Правда, на сегодняш­ нем рынке много и других программных продуктов, успешно используемых в ка­ честве платформы для банка данных. Поэтому ниже сформулированы те крите­ рии, на основании которых следует выбирать СУБД, и оценки Access по этим показателям: • количество ключевых (дескрипторных) полей, поддерживаемых в СУБД. В Access ограничения на эту величину отсутствуют; • ограничение на длину поля. В Access данное ограничение составляет 255 байт для текстовых полей и до 255 байт - для числовых, в зависимости от типа поля; • разнообразие типов обрабатываемых полей. В Access имеются поля, содержащие текстовый и числовой типы данных. Эти типы, в свою очередь, представлены разными вариантами; • дизайнерские возможности системы. Наличие в Access Мастеров и Конструкторов позволяет достаточно быстро создавать таблицы, формы, отчеты, запросы. Добавление диаграмм в формы и отчеты, быстрая настройка программы и анализ ее быстродействия, ис­ пользование архивариуса, возможность импорта и экспорта файлов, работа с гиперссылками и применение технологии OLE внутри пакета Microsoft Office; • требования к уровню подготовки проектировщика и пользователя БД. Минимальные. Некоторые программные навыки нужны лишь в том случае, если придется использовать Visual Basic; • язык программирования, операционная среда, сетевые возможности, требу­ емые ресурсы. Язык запросов SQL, Visual Basic, операционная система Windows 95/98 или Windows NT. При полной установке потребуется 16 Мбайт оперативной

14

• Q •

•

•

•

• •

Q

Постановка проблемы

памяти и около 120 Мбайт памяти на жестком диске. Система Access обла­ дает всеми современными сетевыми возможностями; язык представления данных, обработка символьной информации. Имеются; поддерживаемые структуры и форматы данных. В Access поддерживаются реляционные структуры данных; простота освоения системы, наличие русской версии документации. Первичное освоение займет всего несколько дней. Имеется русифицирован­ ная версия Access в составе пакета Microsoft Office; а также русифицирован­ ная документация для пользователей различных уровней подготовки; поддерживаемый системой математический аппарат. В Access он достаточно развит и включает операторы, функции, логические выражения и т.д.; поддерживаемые системой возможности обработки и представления графи­ ческой информации. В Access поддерживаются операции с диаграммами. Поскольку эта СУБД встроена в пакет Microsoft Office, то пользователь может работать и с други­ ми графическими объектами, входящими в состав данного пакета; возможности взаимодействия с другими пакетами прикладных программ (текстовыми редакторами, электронными таблицами, геоинформационны­ ми системами (ГИС) и другими). В рамках пакета Microsoft Office 97 можно работать с Word и Excel; возможности корректировки файлов, содержащих данные. В Access это очень просто сделать; наличие русифицированной и достаточно подробной справочной системы, а также файлов Help (Помощь). Такая справочная система есть, и она доступна из любого режима в любой момент; разнообразие и гибкость формируемых запросов на предоставление данных. Система Access отвечает этому условию.

Наверное, приведенные выше оценки не дают оснований утверждать, что Access идеальная СУБД. Однако безупречных СУБД вообще не существует. Например, давайте сравним Access с такой системой, как Oracle. Последняя - СУБД гораздо более высокого класса, значительно превосходящая Access по своим возможнос­ тям. Но такие преимущества имеют и оборотную сторону: Oracle громоздка, слож­ на в освоении и требует для своего функционирования специальных, особо мощных технических средств. Область применения Oracle - создание гигантских центра­ лизованных информационных систем. По-видимому, время их массового исполь­ зования в России еще не наступило. В то же время Access является весьма гибкой и универсальной системой, предъяв­ ляющей достаточно умеренные требования к техническому обеспечению. Поэто­ му на сегодняшнем этапе эта СУБД удобна для работы практически на всех иерар­ хических уровнях управления производством - от отрасли в целом до отдельного предприятия.

Пользовательские запросы к банку данных

15

Вопросы, рассмотренные в настоящей книге Приведенные выше оценки относятся к версии Access 97. В настоящее время на рынке появилась новая версия этой СУБД - Access 2000, обладающая более ши­ рокими возможностями. Поэтому при изложении материала автор учитывал: • наличие в версии Access 2000 новых элементов по сравнению с Access 97; • особенности, обусловленные использованием разнородных баз данных. В той или иной степени специфика обеих версий Access проявляется на всех этапах работы: от создания первичных таблиц до формирования запросов и ис­ пользования элементов программирования. Можно было или сосредоточиться лишь на том, чем отличаются друг от друга два варианта программы (тогда мате­ риал неизбежно был бы изложен отрывочно и непоследовательно), или рассмат­ ривать весь процесс создания и использования банка данных от начала и до конца в каждой из версий, по ходу описания комментируя различия между ними. Хотя во втором случае неизбежны повторы и в какой-то мере дублирование уже имею­ щейся литературы, для читателя такой вариант удобнее. Все необходимые сведе­ ния приводятся в одной книге, и пользователю не придется, забыв какую-то ме­ лочь, «буксовать» из-за этого в своей повседневной практике. Чтобы пользователю было легче работать с этой книгой, материал изложен сле­ дующим образом. Все методические рекомендации по структуризации показателей и проектиро­ ванию логических структур БД применимы к любой версии Access. В книге описывается процесс создания новых баз данных в программной среде Access 2000. Отличия этой версии от версии Access 97 специально оговариваются. Что касается конвертирования БД, созданных в других программных средах, то сначала речь пойдет о «переводе» в Access 97, а затем в Access 2000. Кроме того, будут подробно рассмотрены те дополнительные возможности конвертации, ко­ торые появились в Access 2000 по сравнению с Access 97.

Резюме 1. Параллельно с разработкой баз данных в новых, современных СУБД се­ годня используется множество банков данных, построенных на основе программного аппарата морально и технически устаревших СУБД. На­ копленная в них информация представляет большую ценность, но пере­ водить эти БД в новую программную среду никто никогда не будет. По­ этому очень важной становится проблема конвертации данных с тем, чтобы они обрабатывались совместно с новыми СУБД в рамках единого банка данных. 2. В качестве базовой СУБД для интеграции разнородных СУБД в такой банк данных на сегодняшнем этапе предлагается Access 2000. 3. Целью настоящей книги является обсуждение методических и практических вопросов, связанных с разработкой интегрированного банка данных.

Глава II Предпроектная структуризация информации •

Состав информации

•

Что понимать под структуризацией информации

•

Проектирование логической структуры базы данных

Эффективность работы банка данных во многом зависит от того, как структу­ рирована накапливаемая в ней информация. В этом разделе как раз и говорится обо всех проблемах, связанных с определением логической структуры данных. В настоящей книге будут рассматриваться в основном примеры из определен­ ной предметной области - тематической сферы, к которой относится обрабаты­ ваемая информация. Речь пойдет о чрезвычайных ситуациях (ЧС), происходив­ ших в действительности; о работах, связанных с ликвидацией последствий ЧС и, в частности, об используемых при этом контрольно-измерительных приборах. Автор опирался на информацию, которая содержится в банках данных Министер­ ства Р Ф по делам гражданской обороны, чрезвычайных ситуаций и ликвидации последствий стихийных бедствий (МЧС России), Госкомитета Р Ф по охране окружающей среды (Госкомэкологии России) и Федерального агентства прави­ тельственной связи и информации (ФАПСИ). Создание объединенного банка таких данных не завершено, и состав включаемых в него БД в дальнейшем будет расширяться. Полученная информация используется преимущественно в анали­ тических целях: сбор статистических сведений, выявление тенденций, оценка по­ следствий ЧС, выработка рекомендаций по их предотвращению и т.д.

Состав информации

17

Состав информации Наиболее динамичной частью информации, на примере которой рассказывается о возможности Access 2000, являются данные о различных чрезвычайных ситуа­ циях. Прежде всего это: • непосредственные сведения о ЧС (вид ЧС, дата и место происшествия, объект, на котором произошла катастрофа); • характеристика ЧС; • количество пострадавших, в том числе погибших; а предварительные оценки материального ущерба в стоимостном и натураль­ ном выражении; • влияние ЧС на жизнедеятельность местного населения, на окружающую среду и функционирование отраслей народного хозяйства; • возможность или невозможность ликвидации последствий ЧС на месте, ориентировочные сроки такой ликвидации; Q типы и количество единиц оборудования, число специалистов, необходимых для ликвидации последствий ЧС; • характер и примерные объемы выполняемых работ. Менее динамичная часть информации - данные о контрольно-измерительных приборах, которые используются при ликвидации последствий ЧС. Постоянная часть информации - словари понятий, встречающихся в книге. Описываемый банк данных состоит из следующих разделов: • база данных, разрабатываемая в среде СУБД Access 2000; • база данных, разработанная ранее в среде Clarion 3.0; • база данных, разработанная ранее в среде FoxPro 2.5. Две последние БД конвертируются в Access 2000, и дальнейшая работа с ними рассматривается именно в этой единой программной среде. Отметим, что из-за разнообразия и неформализованное™ информации, кото­ рая относится к предметной области, такие сведения значительно труднее обра­ батывать, чем данные, связанные с большинством производственных процессов. Примеры, подтверждающие это положение, будут приведены ниже.

Что понимать под структуризацией информации Как правило, банк данных аккумулирует сведения, относящиеся к определенной предметной области, то есть определенной совокупности объектов. Объектом мо­ жет быть что угодно: предмет, понятие, территория, процесс, явление, фраза, связ­ ный текстовый фрагмент и т.п. Любая информация, которая накапливается в банках данных, так или иначе относится к одному из двух основных типов. По характеру объектов, образующих предметную область, эти типы условно можно назвать так: • фактографическая информация, то есть данные, которые описывают конк­ ретные факты. Такие сведения имеют количественное или логическое выра­ жение. В настоящей книге основное внимание будет уделено работе именно с этим типом данных;

18

Предпроектная структуризация информации

• библиографическая информация, то есть данные, которые очень трудно, а по­ рой и невозможно строго классифицировать: художественная и юридичес­ кая литература, газетно-журнальные тексты и т.д Итак, речь идет о предварительной структуризации информации - особом этапе работы, который должен предшествовать проектированию базы данных. Сама по себе эта идея далеко не нова. Еще в начале 70-х годов усилиями в пер­ вую очередь Е.Кодда и К.Дейта была разработана теория информационных от­ ношений и моделей данных, рассматривавшая, в частности, проблемы опти­ мальной структуры баз данных. Появление этих теоретических работ было обусловлено двумя причинами. Во-первых, СУБД, которые тогда использова­ лись, были несовершенны. Во-вторых, существовали различные типы моделей данных: иерархическая, сетевая, реляционная. Разработчикам приходилось не просто обоснованно выбирать определенную модель данных, но и уметь рабо­ тать в рамках этой модели даже с несвойственными ей видами информацион­ ных отношений (например, в сетевой модели данных использовать иерархичес­ кие структуры). Сегодня практически единственным типом моделей данных являются реляци­ онные модели. Современные СУБД имеют значительно больше возможностей для реализации различных информационных отношений между элементами данных. Видимо, поэтому иногда кажется, что проблема рационального представления ин­ формации в базе данных потеряла актуальность. С точки зрения автора, это иллюзия. Вопрос о структуризации данных по-пре­ жнему важен, меняется лишь технология его решения. Ниже предлагается один из возможных способов структуризации данных.

Показатели Рассмотрим утверждение, которое, согласно нашей классификации, принадле­ жит к классу фактографической информации. Например, «объем капитальных вложений равен 2,5 млн. руб.» или «стоимость «Мерседеса» больше, чем сто­ имость «Жигулей». Для этого класса данных под показателем понимается еди­ ница информации, которая включает ряд реквизитов -признаков и единственный реквизит-основание. Каждый реквизит-признак является мельчайшей недели­ мой информационной единицей и отражает какой-либо атрибут (свойство) объекта. Например, в энергетике такими реквизитами-признаками являются мощности, электростанции, линии электропередач, организации, расход топли­ ва и т.д. Любой объект характеризуется перечнем свойств, которые выражаются через реквизиты. Реквизит состоит из имени и значения. Именем реквизита будет название ка­ кой-либо качественной (наименование, местонахождение) или количественной характеристики объекта, явления, процесса (объем, размер и т.д.). Значение реквизита представляет собой элемент данных, например: мощность (реквизит) - 500 МВт (его значение), электростанция (реквизит) - Красноярская ГЭС (значение), линия электропередач (реквизит) - Экибастуз-Центр (значе­ ние), расход топлива (реквизит) - 350 тонн (значение).

Что понимать под структуризацией информации

19

Совокупность реквизитов-признаков образует наименование показателя, а рек­ визит-основание представляет количественное или логическое значение пока­ зателя. Например, для приведенного выше показателя (мощность Красноярс­ кой ГЭС) реквизит-основание - 500 МВт. Очевидно, каждый реквизит-основание описывается одной фразой. В данном случае эта фраза выглядит так. «уста­ новленная мощность Красноярской ГЭС в 1998 году равна 500 МВт». (Это не значит, что вся база данных состоит из единственного предложения - такой случай представляется исключительным упрощением!) В следующем разделе бу­ дет показано, что реквизиты-признаки, в свою очередь, делятся на ряд категорий. В общем случае ни один из реквизитов-признаков не может считаться обя­ зательным. Характерной особенностью показателя является то, что он содер­ жит определенный минимум информации, достаточный для создания доку­ мента. Ни один из перечисленных выше реквизитов, взятый в отдельности, не позволяет сформировать документ, а вот показатель может быть выдан в каче­ стве справки при ответе на какой-либо запрос - скажем, о мощности Красно­ ярской ГЭС. Верно и обратное - информационную совокупность любой слож­ ности (отчет и т.д.) можно представить как определенную группу различных показателей. Из сказанного ясно, зачем нужна предварительная структуризация информа­ ции пользователям, работающим с конкретной базой данных в конкретной пред­ метной области. Им необходима возможность формировать по единым правилам разнообразные запросы п получать на них ответы. (Примеры таких запросов и от­ ветов будут приведены в главе 9.) Отсюда, между прочим, следует, что структури­ зация данных имеет свои разумные пределы. Разработчик банка данных, разбив исходную информацию на ряд категорий-реквизитов, уверен, что дальше делить данный реквизит не имеет смысла, потому что такие запросы пользователя мало­ вероятны. Можно и остановиться. Однако, если впоследствии пользователю дей­ ствительно потребуется задать специфический запрос, сделать это будет гораздо сложнее. Подобные варианты тоже будут рассмотрены ниже. Поэтому искусство разработчика состоит, в частности, в том, чтобы определить требуемую «золотую середину».

Необходимость структуризации В качестве примера в книге будет рассматриваться информация о фактически происшедших ЧС. Эти сведения могут поступать в виде сообщений по различ­ ным информационным каналам: •

по телефону из соответствующих региональных структур (телефонограм­ мы). В этом случае информация «вручную» вводится в БД; • по телефонному каналу связи, когда информация автоматически вводит­ ся в БД; • по почте. Данные вводятся в БД «вручную». Информация поступает в самой различной форме, например, в таком произволь­ ном виде (реальное сообщение): «На ж/д станции Ангасолка Восточно-Сибирской

20

Предпроектная структуризация информации

железной дороги (ВСЖД) в ночь с 23 на 24.03.99 г. допущен сход двух нефтена­ ливных цистерн по 60 тонн каждая, с разливом сырой нефти в одной из цистерн от 30 до 40 тонн. Произошло самовоспламенение. Основная часть нефти разли­ лась на северной части балластной призмы в кювете с четной стороны, примыка­ ющей к горе, и в кармане водоотводной канавы объемом 3 х 4 х 3,5 м. Кроме того, разлитая нефть выгорела на ж/д полотне площадью 230 х 9 м. На другой стороне ж/д полотна (на откосе) площадью 30 х 50 м происходило сжигание нефти под контролем пожарного надзора ВСЖД. Нефть застыла на снежном покрове двумя рукавами длиной по 100 метров и шириной 0,5 до 1 метра. Дополнительно выяв­ лено еще два очага загрязнения площадью 5 х 2 и 5 х Юм. Привлечено к очистке рельефа местности от нефти 70 человек. Выдано предписание о ликвидации заг­ рязнения с решением вопроса утилизации нефти. После проведения работ по за­ чистке загрязненной территории провести ее обследование комиссионно.» (Имеется в виду, что обследование должно проводиться комиссией.) Можно включать подобные сведения в БД в том виде, в каком они пришли. Такое решение вполне приемлемо, но только на начальном этапе. Рано или поздно поступившую информацию придется обрабатывать, а иметь дело с такими «сы­ рыми» данными довольно трудно. Конечно, можно регламентировать форму входных сообщений так, чтобы со­ держащиеся в них сведения были структурированы. Этот способ используется довольно широко, но он не гарантирует четкой формализации исходных данных. Дело в том, что первичное заполнение стандартных бланков производят рядовые сотрудники на местах, поэтому неизбежна значительная доля субъективизма. Это приводит к необходимости централизованной структуризации показателей при разработке и формировании банка данных.

Технология структуризации Проведенные исследования показали, что обычно в обязательный минимум рек­ визитов-признаков входят следующие: • П - процесс - основное наименование деятельности органа управления (опе­ рация, состояние). Это суть показателя (расход, остатки, поставка, капиталь­ ные вложения, мощность, ущерб и т.д.); • Ф - формальная характеристика, то есть выраженный в наименовании спо­ соб расчета показателя (доля, темп роста, отклонение, сумма, прирост, сред­ нее и средневзвешенное значения и т.п.), который может быть как относи­ тельным, так и абсолютным и тесно связан с процессом (иногда задан в нем неявно); Q О - объект, предмет операции; то, над чем она производится (материалы, изделия, полуфабрикаты, строительная продукция и т.д.); • Е - единица измерения; • С - субъект (тот, кто производит действия над объектом). Если, например, объект (О) - продукция, а основное наименование деятельности (П) - про­ изводство, то в роли субъекта (С) может выступать, например, предприя­ тие, отрасль и т.д.;

Что понимать под структуризацией информации

21

• •

В - время (дата, период); Ф - функция управления (проектное, прогнозное или фактическое значе­ ние, норматив и т.п.). Естественно, все многообразие реальных признаков не укладывается в приве­ денный краткий перечень. Поэтому каждый из названных реквизитов допуска­ ет практически неограниченное количество любых категорий-уточнений, кото­ рые должны удовлетворять единственному условию - они должны представлять собой списки, состоящие из однородных терминов. Обычно уточняются следу­ ющие вопросы: О где? - в этом случае список уточнений характеризует место действия; • как? - список уточнений характеризует обстоятельства действия; Q какой? - список уточнений характеризует свойство. Сформированные таким образом списки при проектировании банка данных рассматриваются как словари. По сути, цель структуризации - создание слова­ рей. При последующей разработке логической структуры БД они служат как бы осями координат, в которых организуется, «раскладывается» реальная инфор­ мация. Эти соображения, как уже говорилось, определяют ту границу, до которой име­ ет смысл проводить структуризацию. Если выясняется, что какие-то словосочета­ ния слишком индивидуальны, уникальны и не поддаются классификации, их не следует включать в словари. В приведенном выше сообщении это формулировки типа «на северной части балластной призмы в кювете с четной стороны, примыка­ ющей к горе, и в кармане водоотводной канавы»; «на другой стороне ж/д полотна (на откосе)». Для таких данных надо использовать специальные поля примеча­ ний, прикрепленных к соответствующей конкретной записи. При простой структуре исходной информации первый этап структуризации выделение основных реквизитов-признаков - можно пропустить и сразу формиро­ вать словари. Однако учтите, что о простоте или сложности структуры исходной информации нельзя говорить вообще - это понятие имеет смысл только с одной точки зрения: легко ли будет пользователю получать ответы на запросы к БД. Поэтому прежде чем приступать к анализу первичной информации, подумайте: кто будет работать с проектируемой базой данных, какие сведения понадобятся пользователю и какими будут его запросы. В этом требовании нет ничего нового - это одно из классических положений проектирования баз данных. Но уже на начальных стадиях, при введении некоторой формализации в структуры данных, вы убедитесь, насколько важно следовать этому правилу.

Пример структуризации данных Рассмотрим практический пример. Вы занимаетесь структуризацией информа­ ции при проектировании базы данных по контрольно-измерительным приборам, которые выпускаются различными фирмами. Это довольно простая БД, и каждая запись в ней выглядит так: «Прибор (название), с номером модели (номер), произведенный в (год) году фирмой (название), которая находится в стране (название) по адресу (приводится

22

Предпроектная структуризация информации

адрес) и имеет филиал по адресу (приводится адрес), предназначенный для (це­ левое назначение), имеющий характеристики (перечень технических характерис­ тик), включенный в каталог под номером (номер в каталоге) и обслуживаемый менеджером (данные о менеджере), имеет цену (приводится цена)». Конечно, фраза громоздкая и не слишком гладкая. Поэтому ее стоит разбить на более прос­ тые фрагменты. Любой пользователь, заказчик или разработчик базы данных лег­ ко может внести в нее необходимые изменения. Ниже будет показано, как это де­ лается. Итак, информация о приборах включает следующие пункты: • •

• • •

• • • • Q •

О (объект) - название прибора; У (уточнение сведений об объекте) - номер модели. Если при анализе сооб­ щения возникает необходимость в нескольких уточнениях, то им можно присвоить номера; У (уточнение сведений об объекте) - год выпуска прибора; У (уточнение сведений об объекте) - номер прибора по каталогу; У (уточнение сведений об объекте) - характеристика прибора, содержащая данные о его функциях, портативности, технических особенностях, весе, точ­ ности, способе питания, диапазоне измерений, совместимости с другими приборами; С (субъект) - название фирмы, производящей прибор; У (уточнение сведений о субъекте) - страна, в которой находится фирма; У (уточнение сведений о субъекте) - адрес фирмы; У (уточнение сведений о субъекте) - адрес филиала или дочерней фирмы; если такая есть; У (уточнение сведений о субъекте) - данные о менеджерах фирмы (фами­ лия, имя, отчество и адрес); Р (реквизит-основание) - цена прибора.

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

Проектирование логической структуры базы данных

23

В нашем примере можно сразу выделить те признаки, по которым следует ожи­ дать частого обращения к базе данных: • название прибора; • название фирмы, производящей прибор; • страна, в которой находится фирма; • адрес фирмы; • адрес филиала или дочерней фирмы; • данные о менеджерах фирмы - фамилия, имя, отчество и адрес; • номер модели; • год выпуска прибора; а номер прибора по каталогу; • цена прибора; • функциональное назначение прибора; • вес прибора; • категория прибора (переносной, портативный и т.п.); • характеристика прибора. Параметры, которые для пользователя второстепенны, остаются в общем тек­ сте раздела. Возьмем пример посложнее, который представлен в разделе «Необходимость структуризации». Здесь описание включает не одну, а несколько фраз, и анализ, подобный предыдущему, надо провести отдельно для каждой из них. В результате мы получим следующий набор признаков: • П (показатели) - «выявлено», «выдано», «сжигание» и др.; • Ol (объект) - источники загрязнения (нефтеналивные цистерны); • 0 2 (объект) - загрязняющие вещества (нефть); • ОЗ (объект) - объекты загрязнения (рельеф местности); • 0 4 (объект) - документы (предписание о ликвидации последствий аварии); • У1 (уточнение места действия 1) - железнодорожные станции (Ангасолка); • У2 (уточнение места действия 2) - железные дороги (Восточно-Сибирская); • УЗ (обстоятельство действия 1) - под контролем комиссии; • П (примечания) - как уже говорилось, в этих полях должны содержаться данные - уточнения, специфичные для конкретных сообщений. Ясно, что по мере накопления новых сообщений будут появляться и новые рек­ визиты, а количество параметров, указанных в скобках, также будет расти.

Проектирование логической структуры базы данных Итак, мы определили состав дескрипторов, то есть ключевых полей для поиска, по которым чаще всего (по нашему прогнозу) будут формироваться запросы к базе Данных. Теперь начнем разработку логической структуры БД. Под логической структурой понимается та совокупность файлов, содержащихся в них полей и свя­ зей между файлами, которую «видит» пользовательская программа, обрабатыва­ ющая базу данных.

24

Предпроектная структуризация информации

Распределение полей по файлам В предыдущем разделе мы постарались объяснить, почему и как необходимо вы­ делять дескрипторные поля, по которым ожидаются запросы со стороны пользо­ вателя. Мы исходили из того, что каждому такому полю должен соответствовать словарь. Если вы в этом еще сомневаетесь, вспомните, что между элементами информации существуют различные типы отношений: $тя%

>п_Примеч= ^ Generation —-•

GUID

zl

Кодф>фны _^ Название фи| Код страны Адрес — Адрес 2 •*•[

Код фирмы Фамилия Имя Адрес

ffij

(3-

ьеп_Припечс 5_GeriPrahon 5_GUID zi

•ё

i

Ы Рис 2 1

26

Предпроектная структуризация информации

Резюме 1. Безусловный прогресс, достигнутый в развитии программных средсл и СУБД и расширении их функциональных возможностей, не устранил проб­ лему обоснованности выбора структур баз данных - от продуманности этих структур во многом зависит эффективность работы с БД. 2. Основным элементом фактографической информации является показатель Он, в свою очередь, состоит из множества реквизитов-признаков и един­ ственного реквизита-основания. 3. Для того чтобы формировать по единым правилам разнообразные пользова­ тельские запросы к БД и получать на них ответы, перед проектированием конкретных баз данных необходимо провести структуризацию информации 4. В главе предлагается и иллюстрируется на конкретном примере технология такой структуризации и - па се основе - последующего проектирования ло­ гической структуры БД.

Глава Создание таблиц новой базы д а н н ы х • Варианты создания таблиц • Формирование таблицы в режиме ввода • Создание таблицы в режиме конструктора G Создание и использование полей подстановки • Организация связей между таблицами Как уже было сказано в главе 2, разработка новой базы данных Контрольно-из­ мерительные приборы производится в программной среде Access 2000. Формирование БД в Access состоит из ряда последовательных этапов, опи­ сываемых ниже. Первый этап этого процесса - создание таблиц. Таблицы в Ac­ cess являются теми первичными, исходными файлами, на основе которых в дальнейшем строится все здание базы данных. Access 2000, как и предыдущие версии, предоставляет пользователю несколько разных вариантов построения таблиц. Порядок создания всех таблиц одинаков и не зависит от их названия и кон­ кретного содержания. Мы рассмотрим этот процесс на примере таблицы Страны.

Варианты создания таблиц Формирование таблицы начинается с того, что вы открываете окно базы данных в нем выбираете пункт Tables (Таблицы) раздела Objects (Объекты), как пока­ зано на рис. 3.1. н

28

Создание таблиц новой базы данных

мз

Н Microsofl Access File Edii" View Insert Tools Window hHp d b 5 : Database Щореп ^Design

ДМе>

E j

Create table by using wizard

®J

Create table by entering data

П

Name AutoCorrtrrt Log

•П

Менеджер

•П

Назначение

• Г"|

Приборы, представленные на рынке2

• Г")

Страны

•П

Типы приборов

•П

Фирмы

Рис 3 / Обычно дальше следует щелкнуть по кнопке jtjew | на панели окна БД. В дна логовом окне New Table (Новая таблица), показанном на рис. 3.2, представлены все возможные способы создания таблицы: • • О Q Q

Datasheet View (Режим таблицы); Design View (Режим конструктора); Table Wizard (Мастер таблиц); Import Table (Импорт таблиц); Link Table (Связь с таблицами)

1Ш

New Table

Create a new table in Datasheet view

Design View Table Wizard Import Table Link Table

OK

Рис 3 2

Cancel

29

формирование таблицы в режиме ввода

Последние два варианта создания таблиц - импорт таблиц и связь с таблица.„ _ рассматриваются в том разделе главы 7, который посвящен объединению разнородных баз данных.

формирование таблицы в режиме ввода Войти в этот режим можно двумя способами: либо выберите пункт Datasheet View (Режим ввода) в окне New Table (см. рис. 3.2) и щелкните по кнопке ОК, in6o выберите опцию Create a table by entering data (Создать таблицу путем вво­ да данных) в окне базы данных (см. рис 3 1). В результате на экране появится таблица, готовая к вводу информации (см рис. 3.3).

Щ]

Ы Miciotoil Access •* •* FIIP

Edit

View

Insert

Format

Record:.

Tools

Window

• Table! : Table FlQldl

Record: j < | *-\ [

nr

Flold2

1

Fleld3

£j

Help

Flold4

FloldS

• HFi* 3

• I • ' ! • * ! of 21

Рис 3 3

Ввод данных Чтобы осуществить ввод данных, сначала надо заменить имеющиеся заголовки столбцов на новые названия, а затем уже ввести сведения в поля таблицы. Рас­ смотрим эту операцию на примере создания таблицы Страны. Заменим имена полей Field 1 и Field2 на Код и Страна. Для этого дважды щелк­ ните мышью в ячейке с именем соответствующего поля, а затем введите нужные значения. Записав первые данные (см. рис. 3.4), попробуйте выйти из созданной таблицы (кнопка _J*J B правом верхнем углу). Сначала Access 2000 спросит вас, На До ли сохранять произведенные в таблице изменения (если вы не хотите этого

30

Создание таблиц новой базы данных 1 В Microsoft Access - [Та... В 1 Э ЕЭ1

J ы -1 в J а ? ( ; П File Edit View Insert Format № Records Tools Window Help

-|i9|

!

x) |,

Код страны |Страна| 1 Россия 2 США 3 Германия *J Record: l< | < | |

>!•'!•
pe

Field Properties General

Description

zl

Lookup

Рис 3 7

В разделе Field Name (Имя поля) следует указать имена полей - те самые, ко­ торые в предыдущем разделе вводились в заголовки столбцов таблицы. Ситуация с первичным кодом совершенно аналогична. Чтобы начать работу с разделом Data type (Тип данных), надо щелкнуть мы­ шью в его пределах. Как только это произойдет, в его правой части возникнет стрелка прокрутки. Щелкните по ней, и появится список типов данных, которЫ1' поддерживаются в Access 2000 (см. рис. 3.8). Характеристика типов данных при­ водится в следующем разделе этой главы. Сведения о типах данных, полей и их свойствах являются в Access 2000 базовы ми и непосредственно используются при создании таблицы в режиме конструктора

Типы данных и их свойства Типы данных, поддерживаемые системой Access 2000 (см. их перечень на рис. 3 8) приведены ниже вместе со своими основными характеристиками:

33

Создание таблицы в режиме конструктора Ш Microsoft A c c e s s

I File

Edit

View

Insert

Tools

Window

Help

Т а Ы е З : Table Data Type

Field Name

Text Me-mo Number Field General

Lookip

ШЕ

I Description I -.

zi

ui renc't AutoNumber \ es/No OLE Object H perlmk Loolup Wizard

Рис 3 8

• Text (Текстовый) - символьные данные или сочетание символьных и циф­ ровых данных. К этому типу относятся также цифровые данные, которые не требуют вычислений над ними (например, номер телефона). Длина поля по умолчанию составляет 255 символов, но можно задать меньший размер. Место для невведенных данных в пределах объявленного размера не резер­ вируется; • Memo (Мемо-поля) - текстовые данные либо сочетание текстовых и циф­ ровых данных, имеющих большой объем. Длина поля - до 65 535 символов; • Number (Числовой) - числовые данные, используемые в математических опе­ рациях. Длина поля может составлять 1, 2, 4 бита, 8 и даже 16 байт (в по­ следнем случае в свойстве Fieldsize (Размер поля) нужно выбрать опцию Replication (Репликация) 1 ); • Date/Time (Дата/Время) - формат данных о дате и времени для периода с 100 до 9999 года. Длина поля - 8 байт; • Currency (Денежный) - значения денежных единиц и числовые данные, ис­ пользуемые в математических операциях. Эти данные должны иметь фик­ сированное число знаков до и после запятой. Длина поля - 8 байт; О AutoNumber (Автоматическая нумерация) - уникальная последователь­ ность чисел, начинающаяся с единицы, или случайная последовательность, которую создает Access 2000 при добавлении новой записи в таблицу. Эта последовательность представляет собой первичный код, который очень ва­ жен в Access 2000, он не может корректироваться пользователем и доступен икация ~ копирование базы данных сразу на несколько компьютеров Если установлен режим ликации, то после обновления информации в двух или нескольких копиях можно синхронно внеэти изменения во все остальные базы данных 2 ~ 119

34

Создание таблиц новой базы данных

только системе. Если вы удалите какую-либо запись, то будет удалено н .,,. ответствующее значение первичного кода. Длина поля для данных эьц., типа составляет 4 бита (или 16 байт, если в свойстве Fieldsize устаиов.i, M режим Replication); • Yes/No (Да/Нет) - логический тип данных. Поле может принимать лишь одно из двух значений: Да или Нет. Длина поля - 1 бит; • OLE Object1 - обменный тип данных для хранения таких объектов, как т.и1 лицы Microsoft Excel, документы Microsoft Word, графические и звуковые файлы, другие двоичные данные, включенные в таблицы Access 2000 и щ связанные с ними; Q Hyperlink (Гиперссылки) - текстовые данные или сочетания текстовых и циф­ ровых данных, которые используются в качестве адресов гиперссылок. Ад­ рес гиперссылки может состоять из трех частей: - отображаемый текст - текст, который появляется па экране; - адрес - путь к файлу или странице доступа к данным; - субадрес - положение данных внутри файла или на странице. •

Длина каждой из этих частей поля гиперссылки не превышает 2048 символик. Lookup Wizard (Выбор данных) - тип данных, позволяющих создать поля для выбора значений из другой таблицы или списка. Щелкнув по пункп' Lookup Wizard, вы запускаете мастер преобразования поля. Когда он закон­ чит работу, Access 2000 запомнит выбранное значение. Обычно длина этого поля составляет 4 бита.

Как видите, типы данных очень разнообразны. Прежде чем вы начнете опреде­ лять и вводить их, обязательно ответьте себе на ряд вопросов: • какие данные вы хотите ввести в конкретное поле. Например, нельзя сохра­ нить текстовую информацию в поле с числовым типом данных; • какая длина поля вам необходима для сохранения данных и работы с ними; Q какие операции будут производиться с данными в этом поле. Например, Access 2000 позволяет суммировать данные в числовом и денежном форма­ тах, но не делает этого в текстовом или в формате OLE Object; • собираетесь ли вы сортировать или индексировать данные. Имейте в виду, что в формате OLE Object нельзя делать ни того, ни другого; • будете ли вы применять групповые записи в формах или запросах. Поля формата OLE Object нельзя использовать для группировки записей; • как вы собираетесь сортировать данные в поле. В текстовом поле числа рас­ сматриваются как строки символов (1, 10, 100, 2, 20, 200 и т.д.), поэтому многие форматы дат могут сортироваться неправильно; для них следует ис­ пользовать формат Date/Time (Дата/Время), а не цифровые значения. Что­ бы сортировать числа как цифровые значения, необходимо применять чис­ ловой или денежный форматы. 1

Object Linking and Embedding (Связывание и внедрение объектов) - спецификация фирмы Micro­ soft, устанавливающая правила взаимодействия приложений, которые участвуют в подготовке и ре­ дактировании составных документов. OLE предусматривает два механизма передачи и использова­ ния объектов в составном документе: связывание и внедрение.

Создание таблицы в режиме конструктора

35

Свойства полей п \ccess 2000 предусмотрены два свойства полей: Format (Формат) и Input Mask Мпска ввода). Обе опции позволяют задавать формат, в котором данные вводят­ ся в таблицу. Свойство Format (Формат) рекомендуется применять при последовательном • оде данных в таблицу. Например, если для поля типа Date/Time вы установили наченне свойства Format равным Medium date (Средний формат времени), то все значения дат при их последовательном вводе будут иметь следующий вид: 12-Jan96 (12-Янв-96). Если пользователь будет вводить в базу данных значения дат в лю(j0M другом формате (скажем, в виде 01/12/96), при запоминании записи Access 7000 все равно преобразует ее в формат Medium date. Свойство Format проявляется лишь при отображении значения, но не при его запоминании. Пока введенные данные не появились на экране, невозможно про­ верить, в каком формате они были введены. Предположим, вы непременно хотите отобразить данные именно в том формате, в котором они вводились. Тогда вам не следует применять свойство Format. В заключение отметим, что оно использует­ ся в полях числового и денежного типа, Date/Time, AutoNumber и Yes/No (Да/ Нет). Свойство Format не определено для полей текстового типа, полей Memo и шперссылок, хотя в принципе такая настройка возможна. Свойство Input Mask (Маска ввода) целесообразно при отображении литераль­ ных (символьных) констант, а также при вводе данных в пустые графы (бланки, таблицы и т.д.) - например, если все номера телефонов в списке имеют один фор­ мат. Использование маски ввода обеспечит сохранение информации в определен­ ном формате. Таким образом, вы всегда сможете установить, в каком виде будут вводиться данные в каждый документ. Предположим, надо, чтобы все вводимые данные о кодах и телефонах городов области содержали одинаковое количество знаков. Перед вводом предварительно задайте свойство Input Mask, и в каж­ дый документ (таблицу) будет помещено необходимое число символов. Если вы зададите одновременно оба свойства, произойдет следующее: Access бу­ дет применять Input Mask при добавлении или редактировании данных, a Format при отображении сохраненной записи.

Установка значений свойств Input Mask и Format lenepb давайте рассмотрим установку значений свойств Input Mask (Маска вво­ да) и Format (Формат) на конкретном примере. Откроем таблицу Страны в ре­ жиме конструктора.

Свойство Input Mask тооы задать свойство Input Mask в поле Код страны, выберите соответствую­ щую строку, как показано на рис. 3.9. Ьсли щелкнуть в ее пределах, то в нее можно вводить значения вручную. Если же е -чкнуть по кнопке _^J, запустится Input Mask Wizard (Мастер маски ввода). ^начале установим маску ввода вручную. Введем значение 0L>L в строку Input ask (см. р И С 3.10). Начиная со следующей вводимой записи и до тех пор, пока 2'

36

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

шш

Н Microsoft Access

\П - | @

* 4a 6*

File Edit View Insert

йг

Tools Window Help

Table2: Table I

Field Name ID Код страны Страна

Data Type AutuNumber Text Text

[

Oescnphon

ME

zl Geneial

Щ

Lookup | 50

Field Size Form at Input Mask Caption Default Value Validation Rule Validation Text

.^^ш Ш ^ H ^ H ЩЩ

Required Allow Zero Length

V es Ho

^1

Indexed Unicode Compression

Рис 3 9

маска ввода не будет снова изменена, коды стран будут задаваться в том виде, ко­ торый показан на рис. 3.11. Это происходит в соответствии с правилами настрой­ ки форматов, приведенными выше (раздел «Свойства полей»). (Мы не обсужда­ ем сейчас вопрос о смысле такой установки, а просто рассматриваем возможности маски ввода.) Правда, при переходе из режима конструктора в режим просмотра таблицы (см. соответственно рис. 3.10 и 3.11) Access 2000 предупреждает о возможных опасно­ стях. Сообщение, показанное на рис. 3.12, гласит: Data integrity rules have been changed; existing data may not be valid for the new rules. This process may take a long time. Do you want the existing data to be tested with the new rules? (Условия целос­ тности данных изменены, существующие данные могут противоречить новым ус­ ловиям. Процесс может быть длительным. Хотите ли вы проверить существую­ щие данные в новых условиях?) Вряд ли у вас есть основания отказываться от подобной проверки, поэтому са­ мым правильным решением будет ответ Yes. Если вы захотите воспользоваться помощью мастера маски ввода и щелкнете по кнопке ^ J , то система предложит вам запомнить форму: Must save table first. Save now? (Сначала надо сохранить форму. Сохранить ее сейчас?). После этого появш ся окно мастера (см. рис. 3.13). Открывшееся окно предлагает вам выбрать Input Mask (Маску ввода) в соотвс i ствии с заданным свойством Data Look (Формат данных). Чтобы проверить рабо i > •

37

Создание таблицы в режиме конструктора

ПШШ

В Microsoft Access

|•

-J У

. L4 v

I File Edit View Inset t Ipols Vfemdow Help

HnR I -

Tablel : Table

Description

Data Type AutoNumt'F

Field Name 9 ID • Код страны

Text

jj Field Propei ties General j Looljjp Field Size

50

Foi ri iat Input Mask

01 >L

Caption

1

Detault Value Validation Rule Validation Text Required Allow Zero Length

"™J

Yes No ves (No Duplicates)

Indexed Unicode Compression

Ves

»«*;»*» • г , - з . -

Рис. 3.10 1 В Miciosoft Access

^ - У File

Edit

^mdovo

•

# El ^ Vie'"

Insert

* l^i lr Format

H B

В I

-o

>„>

'

Records

Tools

Help

Tablel : Table ID

•

ШЩ | Код страны |

Страна

1 1

Россия

2 2

США

3 3

Германия

12 7 г J

Индия

13 5кЕ

Пакистан

(AutoNumber) _ | _

Record

и | < ||

6

• | м | > Ч of 6

i j

1

•!

Рис. 31 1 ^ Ыски ввода, введите данные в поле Try It (Проверка). Значения свойства Input as k подробно рассматривались выше. Здесь мы еще раз кратко перечислим их: J General Date (Общий формат даты); Q Long Date (Длинный формат даты);

38

Создание таблиц новой базы данных Microsoft A c c e s s

]\

Data i n t e g r i t y rules h a v e b e e n changed; existing d a t a m a y not be valid for t h e new rules. —

This process may take a long time. Do you want the existing data to be tested with the new rules? Mo

Cancel

Рис 3 12 Input M a s k W i z a r d Which input mask matches how you want data to look?

To see n o v a selected mask worts, use the Tt / It box. To change the Input Mask list, click the Edit List button. Input Mask:

Data Look.

Password Short Time Medium Time Long Time Short Date Medium t'ate

Try It:

Edit List

—

о is:,:.: 0.13333 03 12 00 09/27/1069 27-сен-6

|

Finish

Рис 3 14

в поле Place-holder character (Вид метки) с помощью стрелки прокрутки. Выбран­ ные вами метки вводятся автоматически по мере ввода символов. Использовав все возможности коррекции масок, которыми располагает мастер, вы получите не ме­ нее разнообразные и экзотические маски, чем те, что пользователь создает вручную. Проверить, как введены данные, можно, указав их в поле проверки Try It и за­ тем ще н