![]() Главная страница Случайная страница КАТЕГОРИИ: АвтомобилиАстрономияБиологияГеографияДом и садДругие языкиДругоеИнформатикаИсторияКультураЛитератураЛогикаМатематикаМедицинаМеталлургияМеханикаОбразованиеОхрана трудаПедагогикаПолитикаПравоПсихологияРелигияРиторикаСоциологияСпортСтроительствоТехнологияТуризмФизикаФилософияФинансыХимияЧерчениеЭкологияЭкономикаЭлектроника |
Устранение проблем, возникающих при создании ключей
Вы создали свою первую таблицу, и вам, конечно же, не терпится занести в нее данные, тем более что 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 м2, а во второй раз — как однокомнатная с площадью 30, 4 м2. Очевидно, что одну из этих квартир следует удалить. Разберитесь — какую именно. Совет Для удаления записи в таблице, находящейся в режиме просмотра, выделите ее, нажав кнопку выделения строки таблицы в левой части бланка. Вся строка после этого будет выделена рамкой. Нажмите клавишу < Delete>. Правильно ответьте на запрос системы (рис. 1.30). 1.9. Устранение связи " многие-ко-многим" В качестве примера рассмотрим функционирование фирмы " Столица" (см. вариант 1 в приложении 1). Особенностью работы этой фирмы является посредническая деятельность — стыковка поставщиков товаров и покупателей. Один поставщик связан с несколькими покупателями. Один покупатель, в свою очередь, связан с несколькими поставщиками. По понятным причинам поставщик " не знает" покупателя и наоборот. Вот вам предпосылка создания связи " многие-ко-многим" между двумя таблицами: поставщики и покупатели (рис. 1.31). Как мы уже знаем, реляционная модель не позволяет непосредственно реализовать связь типа " многие-ко-многим". Кроме этого, штрих-код товара (рис. 1.32), являясь его однозначной идентификацией, не может быть назначен в качестве первичного ключа. В случае если через какое-то время будет закуплена еще одна партия такого же товара, то в таблице поставщиков по-явится строчка, имеющая идентичный штрих-код. Аналогичная ситуация возможна и с покупателем, который приобретет такой же товар из другой партии. И еще одна проблема: один клиент практически никогда не покупает всю партию целиком и перед фирмой встает проблема учета остатка товара. Все эти проблемы (реляционной модели и алгоритма) легко решаются добавлением двух промежуточных таблиц: " Поставленные товары" и " Проданные товары". На рис. 1.33 показан фрагмент схемы данных превращения связи " многие-ко-многим" в несколько связей " один-ко-многим" с добавлением этих промежуточных таблиц. Преобразование связи " многие-ко-многим" в несколько связей " один-ко-многим" и " многие-к-одному" можно сделать следующим образом. Вместо того чтобы рассматривать множество поставщиков, поставляющих товары многим клиентам, будем рассматривать одного поставщика и множество поставляемых им товаров (" один-ко-многим"). Далее будем рассматривать деление товара одной партии на множество частей, подлежащих продаже (" один-ко-многим"). В результате получим множество товаров, приобретаемых одним покупателем (" многие-к-одному"). Появление таблицы " Проданные товары" позволяет решить внутреннюю проблему учета остатков товара в фирме " Столица".
|