Устранение проблем, возникающих при создании ключей

Вы создали свою первую таблицу, и вам, конечно же, не терпится занести в нее данные, тем более что MS Access без труда позволяет это сделать. Не то-

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

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

1. Сделайте активной вторую страницу вкладки с названием Создан ие ленты главного окна Microsoft Access 2007. Щелкните по пиктограмме 1 Мас­тер запросов. Появится окно (рис. 1.26).

2. Выберите пункт Повторяющиеся записи и нажмите кнопку OK.

3. Появится список таблиц базы данных. Выберите в нем таблицу flat и на­жмите кнопку Далее.

4. В появившемся диалоговом окне Поиск повторяющихся записей занеси­те в окно Поля с повторами три поля: street, house, flat, используя кнопку [IT] (рис. 1.27).

Осталось удалить из таблицы flat пять квартир, которые занесены по два раза. Для этого вернитесь в окно базы данных Real Estate, удалите запрос, который называется " Поиск повторений для flat", и начните все с самого на­чала. Как ни странно — это самый быстрый путь к цели. Выполните пункты с первого по четвертый, а в пятом пункте вместо кнопки Готово нажмите кнопку Далее. Вам будет дана возможность выбрать дополнительные поля, которые будут отображены вместе с повторяющимися значениями. Советую вам выбрать все поля, нажав кнопку [» ]. После этого нажмите кнопку Гото­во и на экране появятся все записи, которые дублируют друг друга по со­ставному ключу (рис. 1.29).

На рис. 1.29 хорошо видны ошибки, которые сделал наборщик информации. Посмотрите на первые две строчки. Квартира номер 1, находящаяся в доме 48, расположенном на улице со ссылочным номером 45, один раз занесена

как двухкомнатная с площадью 42, 4 м², а во второй раз — как однокомнатная с площадью 30, 4 м². Очевидно, что одну из этих квартир следует удалить. Разберитесь — какую именно.

Совет

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

1.9. Устранение связи " многие-ко-многим"

В качестве примера рассмотрим функционирование фирмы " Столица" (см. вариант 1 в приложении 1). Особенностью работы этой фирмы является по­средническая деятельность — стыковка поставщиков товаров и покупателей.

Один поставщик связан с несколькими покупателями. Один покупатель, в свою очередь, связан с несколькими поставщиками. По понятным причинам поставщик " не знает" покупателя и наоборот. Вот вам предпосылка создания связи " многие-ко-многим" между двумя таблицами: поставщики и покупате­ли (рис. 1.31).

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

Все эти проблемы (реляционной модели и алгоритма) легко решаются добав­лением двух промежуточных таблиц: " Поставленные товары" и " Проданные

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

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

Появление таблицы " Проданные товары" позволяет решить внутреннюю проблему учета остатков товара в фирме " Столица".