набор постоянных или взаимосвязанных объектов.

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

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

Предназначение Access

По сути, Access — это всего лишь инструмент, как молоток или, скажем, отвертка. Его использование, конечно же, делает наш труд, а следовательно, и нашу жизнь немного легче. Но стоит забыть, для чего он нужен и как им пользоваться, и тут же можно запросто получить по рукам. Поэтому помните, что и база данных должна служить для выполнения четко оговоренных задач — лишь при этом условии она поможет повысить эффективность вашей работы вне зависимости от того, о каком виде деятельности идет речь.

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

Определение цели использования

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

Итак, если вместо того, чтобы сваливать все объекты в одну кучу, вы примете решение о планировании базы данных, следует составить и записать небольшой план. Не стоит уделять ему чрезмерного внимания и тратить много сил, достаточно и одного предложения, например такого: «Хранение и анализ данных о состоянии шелковичных червей в предверии похолодания». По окончании планирования первичную задачу, возможно, понадобится слегка изменить, но сама цель останется неизменной — наметить основу базы данных.

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

В поисках данных

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

Предварительное планирование на бумаге

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

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

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

Рис. 4.1. Это еще не база данных, но начало уже положено!

Список первоочередных данных

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

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

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

Рис. 4.2. Уже существующий дневник может стать подспорьем при планировании базы данных

Планирование таблиц

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

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

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

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

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

Рис. 4.3. В базе данных Access могут храниться фотографии

Растения	Каталоги
Имя	Название
Латинское имя	Адрес
Тип	Специализация
Заметки
Фотография

На данном этапе Access не применяется, а мы пока что решаем, какие еще таблицы и поля следует создать. Более подробно о формировании таблиц рассказывается в главе 5, «Создание первых таблиц».

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

Поздравляем! Вы сделали первые шаги на пути организации данных. Немалая часть книги посвящена разделению данных на отдельные таблицы — этот процесс называется нормализацией или упорядочением. Пока что не стоит забивать голову лишними деталями. По мере изучения Access станет понятным, что планирование базы данных зависит в первую очередь от целесообразности выполняемых действий.

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

правило 1 — разделяйте данные на наименьшие однотипные элементы; правило 2 — не храните два элемента в одном месте; правило 3 — указывайте уникальные характеристики каждого элемента базы данных.

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

Правило 1

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

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

Зачем же нужно разделять даже адрес? Дело в том, что работать с различными блоками данных в одном поле крайне неудобно. Предположим, вам понадобилась информация из определенного каталога, однако вспомнить его название никак не удается. Вы лишь припомнили, что издательство, выпустившее каталог, находится в Ленинградской области. Если запись о Ленинградской области содержится где-то посередине поля, между записями о Москве и России, найти ее будет непросто. С другой стороны, если создать отдельное поле для Ленинградской области, нужную запись останется поискать лишь в нем. Итак, изменяем таблицу каталога следующим образом.

Каталоги

Имя

Улица

Город

Область

Почтовый индекс

Страна

Специализация

Правило 2

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

Растения	Типы
Имя	Тип
Латинское имя
Заметки
Фотография

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

Правило 3

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

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

Для уникального определения каждой записи следует использовать хранящуюся в ней информацию. Одно или больше полей данных могут изначально быть уникальными для каждой записи. Такой тип первичного ключа называется натуральным. Можно добавить поле типа данных с автоматической нумерацией. Использование этого типа данных позволяет Access автоматически вводить последовательное значение для каждой записи. Например, значение первой записи первичного ключа будет равно 1, второй — 2, третьей — 3 и т.д. Такой тип ключа считается искусственным.

На рис. 4.4 схематически показано различие между указанными типами ключей.

Рис. 4.4. Натуральные и искусственные ключи

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

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

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

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

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

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

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

растения — имя, латинское имя (ПК), заметки, фотография; каталоги — имя (ПК), улица, город, область, почтовый индекс, страна, специализация; типы — тип (ПК), описание.

Интересно, каким образом таблица растений «узнает» о том, какой тип к какому растению относится или в каком каталоге содержатся сведения о семенах моркови? Это возможно лишь при наличии связей. Взаимосвязь — это, как понятно из названия, связь между таблицами. Принцип взаимосвязи можно сформулировать с помощью такой фразы: «Каждый каталог содержит информацию о многих растениях» или такой: «Каждое растение обладает типом». Более подробно о связях рассказывается в главе 6, «Использование взаимосвязей».

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

Рис. 4.5. Первичные и внешние ключи

Для иллюстрации метода работы взаимосвязанных таблиц следует добавить необходимые внешние ключи к созданным таблицам.

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

растения — имя, латинское имя (ПК), заметки, фотография, номер типа (ВК); типы — тип (ПК), описание.

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

растения — имя, латинское имя (ПК), заметки, фотография, номер типа (ВК), имя каталога (ВК); каталоги — имя (ПК), улица, город, область, почтовый индекс, страна, специализация.

Обратите внимание на тот факт, что полю внешних ключей не назначаются имена полей соответствующих первичных ключей. Объясняется это тем, что имена полей не должны совпадать. В таблице каталогов содержится поле Имя, а в таблице растений — поле ИмяКаталога; взаимодействие этих ключей автоматически обеспечивает Access.

Итак, на данный момент содержимое таблиц выглядит следующим образом:

растения — имя, латинское имя (ПК), заметки, фотография, номер типа (ВК), имя каталога (ВК); типы —тип (ПК), описание; каталоги — имя (ПК), улица, город, область, почтовый индекс, страна, специализация.

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

Планирование возможных вариантов форм

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

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

Для ввода, удаления и изменения данных рекомендуется применять формы. Хотя эти операции можно выполнять непосредственно в таблицах, не стоит рисковать. Более тoro, нужно запретить пользователям доступ к таблицам, на основе которых создаются формы.

Мы все еще продолжаем делать наброски с помощью ручки и бумаги, поэтому пока что не следует создавать формы в Access. Когда таблицы готовы, можно переходить к разработке прототипа форм с помощью специального мастера, о котором речь пойдет в главе 8, «Создание и использование форм данных».

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

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

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

Формы, показанные на рис. 4.6, предоставляют нам массу возможностей. Правда, они созданы самой Access, поэтому, пока мы еще не научились это делать, можно обойтись ручкой и бумагой.

Рис. 4.6. Формы могут быть основаны на нескольких таблицах

Кроме таких форм нам для обновления таблицы типов может понадобиться простая форма ввода данных (рис. 4.7).

Рис. 4.7. Форма, используемая для обновления таблицы типов

Информация о формах и подформах содержится в главе 8, «Создание и использование форм данных», и в главе 13, «Настройка форм».

Планирование возможных вариантов отчетов

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

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

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

Приятное впечатление всегда производит отчет с картинками - он очень пригодится на этапе планирования.

При желании сведения, аналогичные указанным на рис. 4.8, можно распечатать для всех растений, отсортированных по их латинским именами. Этот отчет будет помещен в папку с аналогичными документами. Отчет, представленный на рис 4 9 понадобится для планирования процесса разбивки сада на участки. Много полезной информации о работе с отчетами содержится в главе 9, «Печать информации с помощью отчетов» и в главе 14, «Настройка отчетов».

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

Рис.4.9. Этот отчет понадобится при разбивке сада на участки

Подведем итоги...

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

В этой главе рассказывалось о том, как:

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