Access 2007

ваши сообщения электронной почты. Access хранит файлы, вставленные в поле типа Вложение как часть вашей таблицы, встроенную в файл вашей БД.

Тип данных Вложение хорошо подходит для вставки в запись изображения, короткого звукового файла или документа из другого приложения пакета Office, такого как Word или Excel. Вы можете создать таблицу People (люди) с изображением каждого человека, включенного в список контактов, или каталог изделий с изображением товаров, которые вы пролаете. В этом случае у данных типа Вложение — очевидные преимущества, поскольку они хранятся в файле вашей БД, и вы никогда не потеряете их след.

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

Предупреждение

Дважды подумайте, прежде чем связываться с вложенными файлами. Как вы уже знаете, объем, который может занимать БД Access, ограничен двумя гигабайтами. Если вы начнете сохранять большие файлы в ваших таблицах, то можете просто превысить его. Лучше хранить большие документы в отдельных файлах, а затем записывать имя файла в текстовое поле или поле с типом данных Гиперссылка (Hyperlink).

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

На листе данных поле с типом данных Вложение легко узнать, т. к. рядом с ним расположена пиктограмма скрепки (рис. 2.17).

Рис. 2.17. Вложения помечаются пиктограммой скрепки и числом в скобках, сообщающим о количестве вложенных файлов. В данном примере все значения в поле Picture с типом данных Вложение пустые за исключением Count Chocula, у которого оно равно двум

91

Для вложения файла или просмотра списка вложенных файлов дважды щелкните кнопкой мыши пиктограмму скрепки. Вы увидите диалоговое окно Вложения (Attachments) — рис.2.18.

Рис. 2.18. В диалоговом окне Вложения показаны все файлы, связанные с вашим полем

Далее перечислены действия, которые можно выполнить с помощью окна Вложения (Attachments).

■Вставить новый вложенный файл. Щелкните мышью кнопку Добавить (Add). Затем найдите и укажите новый файл и нажмите кнопку ОК. Вы увидите новый файл в конце списка файлов.

■Удалить вложение файла. Выберите в списке нужный файл и щелкните мышью кнопку Удалить (Remove).

Сохранить копию вложенного файла. Выберите нужный вложенный файл, щелкните мышью кнопку Сохранить как (Save As) и затем укажите место на вашем компьютере для сохранения копии. Или щелкните мышью кнопку Сохранить все (Save All) для сохранения копий всех вложенных в это поле файлов. Если вы меняете данные копии, содержимое вложенного файла в вашей БД не меняется.

■Редактировать и просматривать вложенный файл. Выберите вложенный файл и щелкните мышью кнопку Открыть (Open). Программа Access скопирует вложенный файл во временную папку па вашем компьютере, ту, в которой сохраняется кэшируемая интернетинформация. Если вы сохраняете файл, Access отслеживает изменения, автоматически обновляет вложенный файл и затем удаляет временный файл. Если вы закроете окно Вложения (Attachments) до того, как закрыли файл, то Access предупреждает о том, что ваши корректировки не будут отражены в вашей БД. На рис. 2.19 показано, что происходит.

Ксожалению, у типа данных Вложение мало параметров управления. Далее перечислены некоторые ограничения этого типа данных.

■Вы не можете ограничить количество разрешенных вложений файлов в поле типа Вложение. У всех полей этого типа практически нет ограничения на количество вложенных файлов (хотя вы не можете вложить два файла с одним и тем же именем).

Вы также не можете ограничить типы файлов, предназначенных для вложения. Вы не можете ограничить и размер файлов, предназначенных для вложения.

92

Рис. 2.19. Вверху: в данном примере файл "The Story of the Count.doc" все еще открыт.

Если вы продолжите, то все изменения, которые вы вносите (или любые изменения, которые вы внесли к данному моменту и не сохранили), не будут отражены в БД.

Внизу: если программа Access замечает, что вы сохраняли ваш файл с тех пор, как открыли его впервые, она спрашивает вас о том, хотите ли вы обновить БД последней сохраненной версией файла. (Для того чтобы избежать подобных треволнений, вкладывайте только те файлы, которые вы не собираетесь редактировать.)

Счетчик

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

Примечание

У каждой таблицы может быть не более одного поля Счетчик.

Обычно поле типа Счетчик выглядит как последовательность чисел — Access стремится дать первой записи значение 1, второй записи значение 2 и т. д. Но истина не так проста. Иногда программа Access пропускает числа. Такой пропуск возможен, когда несколько пользователей одновременно работают с БД, или когда вы начинаете вставлять новую запись, а затем отменяете это действие, нажав клавишу <Esc>. Вы также можете удалить существующую запись, в этом случае Access никогда повторно не использует значение типа Счетчик из удаленной записи. В итоге, если вы вставляете новую запись и видите, что ей присвоено значение типа Счетчик, равное 401, то не можете с уверенностью сказать, что в таблице уже есть 400 записей. Реальное их количество, возможно, меньше.

Бесспорно, значение Счетчик не отображает ничего реального, и, возможно, вы не захотите тратить много времени на его рассмотрение. Единственная задача поля с типом данных Счетчик — гарантировать наличие у каждой записи вашей таблицы уникального указателя. Обычно ваше поле типа Счетчик служит также и первичным ключом для вашей таблицы, как объясняется в разд. "Первичный ключ " далее в этой главе.

93

Применение поля типа Счетчик без раскрытия реального размера вашей таблицы

У значений Счетчик есть маленький недостаток: они предоставляют сведения о количестве записей в таблице. Быть может, вы не хотите, чтобы клиент знал, что ваша торговая марка, новая компания, торгующая скульптурными фигурками из масла в духе народных ремесел (Better Butter Sculptures), "не одурачила" и 12 заказчиков. Поэтому вас смутит необходимость признаться ему в том, что его номер, ID, всего 6.

Лучше всего начать отсчет с большего числа. Вы можете обмануть программу Access, заставив генерировать числа типа Счетчик, начиная с заданного минимума. Например, вместо создания номеров клиентов 1, 2 и 3 вы можете создать ID-значения 11001, 11002, 11003. Такой подход также гарантирует наличие у ваших идентификаторов одинакового количества цифр и позволяет разделить ID в разных таблицах, начиная их формирование с различных минимальных значений. К сожалению, для того чтобы реализовать эту хитрость, вам надо обмануть Access с помощью специально разработанного запроса, который вы увидите в разд. "Получение начальных значений типа Счетчик, отличных от 1" главы 8.

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

■Случайное значение типа Счетчик. Для того чтобы воспользоваться случайными числами, измените свойство поля Новые значения (New Values) со значения Последовательные (Increment) на значение Случайные (Randome). Теперь вы получите длинные номера для каждой записи, такие как 212125691, 1671255778 и -1388883525. Вы можете использовать случайные числа типа Счетчик для формирования значений, которые другие люди не смогут угадать. (Например, если у вас есть таблица Orders (заказы), в которой применяются случайные числа в поле OrderlD (идентификатор заказа), их можно использовать как подтверждающие номера (confirmation numbers).) Но в мире Access случайные числа типа Счетчик применяются редко.

■Коды репликации. Коды репликаций (Replication ID) — это длинные непонятные коды, например, 38A94E7B-2F95-4E7D-8AF1-DB5B35F9700C, гарантированно уникальные с точки зрения теории вероятностей. Для их применения измените значение свойства Размер поля с Длинного целого на Код репликации. Этот вариант действительно используется только в одном случае — если у вас есть отдельные копии БД и вам в будущем придется объединить данные из них. В следующем разделе объясняется этот сценарий.

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

Применение типа Код репликации

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

94

Программа Access предлагает вам другую возможность — Код репликации. Код репликации

— странное творение — очень длинный идентификатор (всего 16 байтов), представленный строкой цифр и букв, которая выглядит примерно следующим образом:

38A94E7B-2F95-4E7D-8AF1-DB5B35F9700C

Такой идентификатор — более громоздкий по сравнению с обычным целым числом. Помимо всего прочего, гораздо легче поблагодарить кого-либо за отправку заказа Order 4657, чем заказа Order 38A94E7B-2F95-4E7D-8AF1-DB5B35F9700C. Другими словами, если значение типа Счетчик применяется для отслеживания и бухгалтерского учета, Код репликации использовать для этой цели не стоит.

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

главе 19.)

Примечание

Код репликации также называют GUID (globally unique identifier, глобально уникальный идентификатор). В теории вероятность того, что два GUID идентичны, равна 1/2128, величина достаточно маленькая для того, чтобы вы могли заставить работать один биллион сотрудников, создающих не более одного биллиона GUID в год, и все же быть уверенным в отсутствии дубликатов в течение десятилетия или двух. На практике реальным ограничением служит качество используемого в программе Access генератора случайных чисел.

На рис. 2.20 показана таблица, в которой используются коды репликаций.

Рис. 2.20. В таблице FictionalCharacters показаны 10 записей, каждая с уникальным с вероятностной точки зрения значением типа Счетчик

95

Первичный ключ

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

На профессиональном уровне.

Как Access предотвращает дублирование записей

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

Чистоплюйство БД общеизвестно, они не терпят такого рода мусора.

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

В таблице Employees (сотрудники) номер социального обеспечения (Social Security number) мог бы служить первичным ключом. Этот метод хорошо работает, поскольку, когда вы вставляете новую запись, Access может проверить наличие дублирования, пробежав список этих номеров, что гораздо быстрее, чем просмотр целой таблицы.

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

К сожалению, как раз так и не следует делать — в конце концов, есть масса адресных книг с двумя ШонамиСмитами (Sean Smith).

Лучше всего вставить новую порцию данных. Вы можете пометить каждого человека в вашем списке контактов с помощью уникального ID-номера. Самое лучшее, что вы можете сделать, — дать возможность программе Access создать такой номер для вас (и быть уверенным в том, что ни у каких двух людей из списка не будет одинаковых номеров) и больше не думать об этом. В этом случае, если у вас есть два Шона Смита, у каждого из них будет свой ID. И даже если Феррис Вил (чертово колесо) Симпсон решит сменить имя, ID останется прежним.

Именно так действует программа Access, когда вы создаете таблицу в Режиме таблицы. Рассмотрим таблицу Dolls, созданную в главе 1. В ней есть поле, названное Код (ID) и автоматически заполняемое Access. Вы не можете вставить в таблицу значение поля Код или изменить значение в имеющейся записи. Программа Access полностью контролирует это поле, гарантируя уникальный номер для каждой куклы-болванчика. Такой подход в большинстве

96

случаев — как раз то, что вам нужно, поэтому не пытайтесь изменить его или удалить поле Код.

Но есть одно исключение. Если вы создаете таблицу в Конструкторе, выбрав на ленте Создание → Таблицы →Конструктор таблиц (Create → Tables → Table Design), Access считает, что вы знаете, что делаете, и не создает для вас поле Код. Вы должны вставить поле Код (или что-то подобное).

Создание поля для вашего собственного первичного ключа

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

1.Создайте новое поле, вставив его имя в столбец Имя поля (Field Name).

Для автоматической генерации значений лучше всего подходит имя Код (ID). Некоторые пользователи предпочитают более информативное имя (например, BobbleheadID, CustomerlD и т. д.), но это необязательно.

2.В столбце Тип данных (Data Type) выберите тип данных Счетчик (Currency).

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

3.Щелкните поле правой кнопкой мыши и выберите команду Ключевое поле (Primary Key).

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

Примечание

Если вы хотите включить в первичный ключ несколько полей, вам придется использовать несколько иной подход. Сначала щелкните кнопкой мыши отступ на странице рядом с именем поля, а затем переместите мышь с нажатой кнопкой, чтобы выделить несколько полей. Затем нажмите и удерживайте нажатой клавишу <Shift> и щелкните правой кнопкой выделенные поля. Теперь можно выбрать команду Ключевое поле (Primary Key).

На профессиональном уровне. Почему так важна уникальность

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

Для того чтобы понять, в чем проблема, представьте, что вы создали программу для редактирования таблицы Dolls. Эта программа начинает с извлечения списка всех ваших кукол-болванчиков, включенных в таблицу. Она выводит на экран этот список для своего пользователя и предлагает ему внести изменения. В этом вся загвоздка — если произведена корректировка, программа должна иметь возможность внести изменения в соответствующую запись в БД.

97

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

Шесть правил проектирования БД

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

Увы, нет рецепта создания идеальной БД. Но ряд рекомендаций может направить вас в нужное русло. В этом разделе вы познакомитесь с наиболее важными из них.

Совет

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

Правило 1. Выбирайте подходящие имена полей

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

Далее приведено несколько советов.

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

■Пользуйтесь заглавными буквами. Нельзя сказать, что это "железное" правило, но большинство приверженцев Access делают заглавной первую букву каждого слова (называют этот прием CamelCase (контур верблюда)) и затем сливают слова вместе для формирования имени поля. Примерами могут быть UnitsInStock (единиц на складе) и

DateOfExpiration (годен до).

Избегайте пробелов. В программе Access разрешается в именах полей применять пробелы, но они могут вызывать проблемы. В языке SQL (Structured Query Language, язык структурированных запросов) (язык для работы с БД, которым вы будете пользоваться для поиска данных) пробелы запрещены. Это означает, что вам придется использовать квадратные скобки при упоминании имен полей, содержащих пробелы (например, [Number Of Guests] ), а это быстро надоест. Если без пробелов не обойтись, рассмотрите возможность их замены знаком подчеркивания (_).

■Будьте последовательны. Вы можете выбрать одно из двух имен поля ProductPrice (цена_товара) и ProductPrice. Любой выбор вполне оправдан. Однако не следует смешивать оба подхода к заданию имен в одной БД, т. к. это верный шаг к созданию путаницы

98

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

■Не включайте в имя поля имя таблицы. Если у вас есть поле Country (страна) в таблице Customers, совершенно ясно, что вы имеете в виду страну (Country), в которой живет клиент. Имя поля CustomerCountry было бы избыточным.

■Не используйте для имени поля слово "Name". Помимо того, что это труднопроизносимое имя, слово "Name" — ключевое в программе Access. Вместо него применяйте такие имена, как ProductName, CategoryName, ClassName и т. д. (Это как раз тот случай, когда следует нарушить правило о включении имени таблицы в имя поля.)

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

Правило 2. Разбивайте ваши данные

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

Рис. 2.21. Данный пример демонстрирует правильный способ разделения данных (вверху) в таблице Contacts (контакты) и неверный способ (внизу). Учтите, что технически все еще возможно разделить данные позже

— теоретически сведения об уличном адресе можно разделить на StreetNumber (номер дома), StreetName (название улицы) и StreetType (тип улицы). Но такой подход создает массу сложностей, не давая ничего взамен, поэтому гуру БД редко соглашаются на дополнительные неприятности

99

Вместо того чтобы создать одно поле Name в таблице о контактах, гораздо разумнее вставить два поля: FirstName (имя) и LastName (фамилия).

Существует множество оснований для разделения информации на отдельные поля. Прежде всего, это устраняет некоторые типы ошибок. В поле Name имя можно ввести несколькими разными способами (например, "Фамилия, Имя" или "Имя Фамилия"). Разбиение имени устраняет эти проблемы, способные создать затруднения при попытке использовать данные в автоматизированной задаче какого-либо вида (например, объединение сообщений электронной почты). Но гораздо важнее то, что значительно легче работать с данными, которые разделены на маленькие порции. После разделения поля Name на поля FirstName и LastName вы можете сортировать и искать информацию, основываясь на одной порции этой информации, чего нельзя было бы сделать в противном случае. Аналогично следует разделить сведения об адресе на несколько столбцов, таких как Street (улица), City (город), State (штат) и Country (страна) — в этом случае вы гораздо легче найдете всех, кто живет в Нантуките (Nantucket).

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

Правило 3. Храните все детали в одном месте

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

(PurchasePrice).

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

Правило 4. Избегайте дублирования данных

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

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

100