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

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

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

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

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

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

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

Совет

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вместо того чтобы создать одно поле 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, неэффективно. Легко вообра­зить таблицу с сотнями похожих записей, бесполезно расходующих дисковое пространство и повторяющих одни и те же значения снова и снова. Но эта неприятность — мелочь, по сравнению с затратами на обновление подобной информации и возможностью возникнове­ния противоречивости данных. Что произойдет, если вы на основании новых научных дан­ных решите изменить сведения о средней продолжительности жизни слона? В соответствии с имеющимся проектом таблицы вам нужно изменить все записи с одними и теми же данными.

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

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

Проблема возникает, потому что не вся информация в таблице Pets (домашние живот­ные) связана между собой. Для того чтобы понять — почему, нужно погрузиться поглубже в анализ БД.

Как правило, таблица в БД хранит один объект. В таблице Pets — это домашние питом­цы. Каждое поле в таблице — это порция данных об этом объекте.

Рис. 2.23. Теперь относящаяся к животным информация хранится в одном месте, без дублирования. Потребуется чуть-чуть больше времени для получения всей необходимой вам информации о животном — например, для того чтобы выяснить продолжительность жизни Беатрис, вам придется проверить запись Elephant (слон) в таблице AnimalTypes, но в итоге проект стал более логичным

В таблице Pets все поля, такие как Name (имя), Animal (вид животного) и Weight (вес), имеют смысл. Они описывают конкретную особь. Поля же LifeSpan (продолжительность жизни), Temperament (характер) и Diet (рацион) не совсем уместны. Они не описывают

конкретного домашнего питомца. В них содержатся стандарты для животных этого вида. Другими словами, эти поля основываются не на вашем животном (как должны были бы) — они основываются на биологическом виде животного. Единственный способ решения про­блемы — создание двух таблиц: Pets и AnimalTypes (виды животных) (рис. 2.23).

Нужен опыт для поиска полей, не связанных с другими полями. В некоторых случаях дробление таблицы на все более мелкие части не стоит затраченных усилий. Теоретически вы можете извлечь информацию об адресе (содержащую такие поля, как Street, City, Country, PostalCode) из таблицы Customers и поместить ее в таблицу Addresses (адреса). Но два клиента проживают по одному адресу довольно редко, поэтому эта дополнительная работа вряд ли окупится. Мы рассмотрим способы определения связей между таблицами, такими как Pets и AnimalTypes, в главе 5.

Совет

Многие специалисты по проектированию БД считают лучшим методом планирования БД — применение учетных карточек (index cards). Для этого запишите все различные типы информа­ции, необходимые для вашей БД. Затем отложите учетную карточку для каждой таблицы, ко­торую планируете использовать. Наконец, возьмите поля из черновика и записывайте их по очереди на соответствующую учетную карточку до тех пор, пока они не разделятся на четкие связанные группы.

Правило 5. Избегайте избыточной информации

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

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

Примечание

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

Далее перечислены еще несколько примеров избыточной информации.

• Поля Age (возраст) и DateOfBirth (дата рождения) (в таблице People). Обычно вы включаете только поле DateOfBirth. Если же у вас их два, то в поле Age содержится избыточная информация. Но если у вас только поле Age, то вы в опасности — если вы не сможете отслеживать дни рождения и тщательно редактировать каждую запись, ваши данные скоро станут некорректными.

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

равные 10%, и сохраните измененные цены в вашей БД, вас ждет много работы в случае снижения скидки до 9%.

Правило 6. Включайте поле Код

Как вы уже знаете, программа Access автоматически создает поле Код (ID), когда вы разра­батываете таблицу в Режиме таблицы, и назначает его первичным ключом вашей таблицы. Но даже теперь, когда вы изучили Конструктор, все равно вставляйте поле Код во все ваши таблицы. Убедитесь, что в нем используется тип данных Счетчик, в этом случае Access ав­томатически заполнит его числами и отведет ему роль первичного ключа.

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

Примечание

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