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

На этом этапе не обязательно досконально знать о возможностях и функциях 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.

Содержание раздела