Access 2002: Самоучитель Дубнов Павел
• П (показатели) – «выявлено», «выдано», «сжигание» и др.;
• О1 (объект) – источники загрязнения (нефтеналивные цистерны);
• О2 (объект) – загрязняющие вещества (нефть);
• О3 (объект) – объекты загрязнения (рельеф местности);
• О4 (объект) – документы (предписание о ликвидации последствий аварии);
• У1 (уточнение места действия 1) – железнодорожные станции (Ангасолка);
• У2 (уточнение места действия 2) – железные дороги (Восточно-Сибирская);
• У3 (обстоятельство действия 1) – под контролем комиссии;
• П (примечания) – как уже говорилось, в этих полях должны содержаться данные – уточнения, специфичные для конкретных сообщений.
Таким образом, по мере накопления новых сообщений будут появляться и новые реквизиты, а количество параметров, указанных в скобках, тоже будет расти.
Проектирование логической структуры базы данных
Итак, мы определили состав дескрипторов, то есть ключевых полей для поиска, по которым чаще всего (по нашему прогнозу) будут формироваться запросы к базе данных. Теперь начнем разработку логической структуры БД. Под логической структурой понимается та совокупность файлов, содержащихся в них полей и связей между файлами, которую «видит» пользовательская программа, обрабатывающая базу данных.
Распределение полей по файлам
В предыдущем разделе мы постарались объяснить, почему и как необходимо выделять дескрипторные поля, по которым ожидаются запросы со стороны пользователя. Мы исходили из того, что каждому такому полю должен соответствовать словарь. Если вы в этом еще сомневаетесь, вспомните, что между элементами информации существуют различные типы отношений: «один-к-одному», «один-ко-многим», «многие-ко-многим». Очевидно, когда между какими-то элементами информации (полями) существует отношение «один-к-одному», они жестко и однозначно взаимосвязаны. В таком случае достаточно иметь один словарь на всю эту группу. Но тогда она должна находиться в одном файле, потому что иначе отношение «один-к-одному» не будет реализовано без применения каких-либо дополнительных средств. Как видите, логика довольно проста. Теперь у нас есть критерий для распределения полей по файлам: в одном файле следует размещать те поля, которые связаны между собой отношением «один-к-одному». Файлы, объединяющие такие группы полей, будут находиться друг с другом в отношении «один-ко-многим» и составят иерархическую структуру. Отметим, что файлы, находящиеся в отношениях типа «многие-ко-многим», не должны быть непосредственно взаимосвязанными. Обобщим сказанное в табл. 2.1.
В этой таблице символы Х и и обозначают соответственно стороны «многие» и «один» в отношениях между реквизитами.
Файлы и связи между ними
Из табл. 2.1 видно: чтобы формировать файлы, следует сгруппировать в них поля, представляющие реквизиты-признаки, находящиеся друг с другом, как сказано выше, в отношении «один-к-одному». Таким образом, будут созданы следующие файлы:
• Страны (содержит поле Название страны);
• Приборы (содержит поля Номер модели, Категория, Год выпуска, Характеристика, Номер по каталогу, Цена, Вес);
• Фирмы (содержит поля Название фирмы, Адрес фирмы, Адрес филиала);
• Менеджер (содержит поле Данные о менеджере);
• Назначение (содержит поле Назначение прибора);
• Типы приборов (содержит поле Название прибора).
Мы перечислили здесь основные – так сказать, «титульные» – поля, составляющие каркас конкретной таблицы. В нее могут также входить вспомогательные поля: Примечания, Адрес и др. Соединив эти файлы связями типа «один-ко-многим», мы получим логическую структуру базы данных, условный вид которой показан на рис. 2.1. О практической реализации таких связей речь пойдет в конце следующей главы.
Рис. 2.1
Резюме
1. Безусловный прогресс, достигнутый в развитии программных средств СУБД и расширении их функциональных возможностей, не устранил проблему обоснованности выбора структур баз данных – от продуманности этих структур во многом зависит эффективность работы с базами данных (БД).
2. Основным элементом фактографической информации является показатель. Он, в свою очередь, состоит из множества реквизитов-признаков и единственного реквизита-основания.
3. Для того чтобы формировать по единым правилам разнообразные пользовательские запросы к БД и получать на них ответы, перед проектированием конкретных баз данных необходимо провести структуризацию информации.
4. В настоящей главе предлагается и иллюстрируется на конкретном примере технология такой структуризации и – на ее основе – последующего проектирования логической структуры БД.
Глава 3
Создание таблиц новой базы данных
Как уже было сказано в главе 2, разработка новой базы данных «Контрольно-измерительные приборы» производится в программной среде Access 2002.
Формирование БД в Access состоит из ряда последовательных этапов, описываемых ниже. Первый этап этого процесса – создание таблиц. Таблицы в Access являются теми первичными, исходными файлами, на основе которых в дальнейшем строится все здание базы данных. Access 2002, как и предыдущие версии, предоставляет пользователю несколько разных вариантов построения таблиц, а также возможность применения дополнительных аналитических табличных структур.
Порядок создания всех таблиц одинаков и не зависит от их названия и конкретного содержания. Мы рассмотрим этот процесс на примере таблицы Страны.
Варианты создания таблиц
Формирование таблицы начинается с того, что вы открываете окно базы данных и в нем выбираете пункт Таблицы в разделе Объекты – рис. 3.1.
Рис. 3.1
Дальше следует щелкнуть по кнопке
на панели окна БД. В диалоговом окне Новая таблица, показанном на рис. 3.2, представлены все возможные параметры создания таблицы:
Рис. 3.2
• Режим таблицы;
• Конструктор;
• Мастер таблиц;
• Импорт таблиц;
• Связь с таблицами.
Последние два варианта создания таблиц – импорт таблиц и связь с таблицами – рассматриваются в том разделе главы 7, который посвящен объединению разнородных баз данных.
Формирование таблицы в режиме ввода
Войти в этот режим можно двумя способами: либо выбрав пункт Режим таблицы в окне Новая таблица (см. рис. 3.2) и щелкнув по кнопке ОК, либо выбрав опцию Создание таблицы путем ввода данных в окне базы данных (см. рис. 3.1). В результате на экране появится таблица, готовая к вводу информации (рис. 3.3).
Рис. 3.3
Ввод данных
Чтобы осуществить ввод данных, сначала надо заменить имеющиеся заголовки столбцов, а затем уже ввести сведения в поля таблицы. Рассмотрим эту операцию на примере создания таблицы Страны.
Заменим имена полей Поле1 и Поле2 на Код и Страна. Для этого дважды щелкните мышью в ячейке с именем соответствующего поля, а затем введите нужные значения. Записав первые данные (см. рис. 3.4), попробуйте выйти из созданной таблицы (кнопка в правом верхнем углу). Сначала Access 2002 спросит вас, надо ли сохранять произведенные в таблице изменения (если вы не хотите этого делать, она вообще сотрется из памяти). Затем вам будет предложено назвать таблицу (или согласиться с предлагаемым именем, которое присваивается автоматически). Все таблицы программа называет именем Таблица с добавлением текущего номера.
Рис. 3.4
Когда все это будет сделано, вы получите предупреждение о том, что ключевые поля не заданы, как показано на рис. 3.5.
Рис. 3.5
Если вы отказываетесь установить ключевые поля и отвечаете Нет, программа запомнит таблицу в том виде, в каком она показана на рис. 3.4. Однако вопрос о ключевых полях все равно возникнет на следующем этапе работы – когда вы будете формировать связи между файлами, и уж тогда без ключевых полей система не справится с этой задачей. Если вы поддались на уговоры и сразу согласились создать первичный код, выбрав ответ Да, то программа сама сделает это. В результате таблица будет выглядеть так, как показано на рис. 3.6.
Рис. 3.6
Если вы выберете пункт Отмена, таблица вновь примет тот вид, который показан на рис. 3.4. Однако это промежуточное состояние, из которого все равно надо как-то выходить. Внимательно посмотрите на первичные коды, созданные системой в поле Код. Здесь они ничем не отличаются от кодов, созданных пользователем в поле Код страны. Но в общем случае коды, введенные в это поле, совсем не обязаны быть такими же упорядоченными, как коды поля Код, – таблица, показанная на рис. 3.6, представляет собой словарь, и коды могут периодически изменяться. Поэтому для надежного контроля за файлами в Access предусмотрен механизм системных первичных кодов. Иногда (как, например, сейчас) они вводятся только по желанию пользователя. В других случаях при отсутствии этих кодов ряд функций Access 2002 выполняться не будет.
Поэтому, если у пользователя нет каких-то серьезных причин отказываться от введения первичных кодов, желательно их все-таки создать.
Отметим, что в словарном файле совсем не обязательно ограничиваться тем минимумом полей, которые показаны в нашем примере. Это было сделано исключительно в методических целях. На практике количество полей в файле вообще не ограничивается, следует лишь соблюдать единственное требование: поля должны находиться в отношениях «один-к-одному».
Создание таблицы в режиме конструктора
Описанная в предыдущем разделе таблица создавалась, можно сказать, стихийно. Теперь мы будем придерживаться строгой последовательности действий, заблаговременно обосновывая все дальнейшие операции, задавая необходимые данные и их форматы.