Литература

1. Microsoft Office Access 2003. Шаг за шагом. Официальный учебный курс, 2007

2. Аблязов В.И., Редько С.Г. Проектирование баз данных в среде Microsoft Office Access 2003. Методические указания по выполнению лабораторных работ. 2010г. 49 с.

3. Кошелев В.Е. Access 2007. Эффективное использование. М. Изд. Бином – 592 с

4. Аблязов В.И., Тисенко В.Н. Методология разработки документов в технических проектах. Учебное пособие. СПб, Изд. Политехнического ун-та, 2008 г. 135 с. http://www.twirpx.com/file/66499/

Приложение

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

Каждая исходная (не вспомогательная) таблица в реляционной базе данных должна иметь хотя бы одно поле (столбец), значения в котором однозначно идентифицируют каждую ее запись (строку). Такое поле называется полем первичного ключа, ключевым полем илипервичным ключом(primary key). Это полеобязательно для заполнения. В нём каждая запись уникальна, то естьповторения значений в этом поле не допускаются. Поэтому ключевым полем не может выступать, например, фамилия, т.к. она может быть одинаковой у разных людей.

Первичным ключом может назначаться, например, Табельный_номер в таблице Сотрудники; Номер_договора в таблице Договоры; Номер_автомобиля в таблице Автомобили. В качестве ключевого поля может выступать любое произвольное неповторяющееся текстовое буквосочетание, например, Запись_1, Запись_2 и т.д.

СУБД Accessпри формировании любой новой таблицы автоматически формирует поле счетчика (1, 2, 3 …), которое автоматически можно назначать в качестве ключевого поля. Однако, при назначении счетчика ключевым полем, функциональная принадлежность данного ключевого поля к таблице не становится явной. Поэтому в учебной БДцелесообразнообозначение ключевого поля делать функционально привязанным к содержанию таблицы. Например, в таблице Ученики ключевым полем назначать Код_ученика, заполняя его строки, например: Уч_1, Уч_2 и т.д.; в таблице Эксперименты ключевым полем назначать Код_эксперимента, заполняя его: Экспер_1, Экспер_2 и т.д.

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

Рекомендации по формированию структуры БД в Access

1. Каждая таблица должна характеризовать определенную функциональную нагрузку (предмет, тему, объект).

2. Формирование структуры новой БД целесообразно начинать с тех подсистем (таблиц), в которых происходит регулярное добавление информации в связи с протеканием текущих процессов во времени. То есть, с тех подсистем, которые в определенные моменты времени фиксируют действие, изменение, состояние, движение. Именно эти «жизненные» подсистемы в БД Access определяют основной «скелет» структуры базы данных и формирование необходимых в ней связей.

3. Для каждого существенного типа сведений следует создать отдельное поле. Например, в таблице Заказчики это могут быть поля: название_компании, адрес, город, страна, номер_телефона. В каждом поле данные должны быть только одного типа.

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

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

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

7. Такие характеристики, как: возраст, опыт работы, время работы на рынке, стаж, время проведения эксперимента и т.п., следует указывать в исходных таблицах в формате дата/время (например, 23.05.2010 или 14.06.2010 14:53.), а не в числовом формате, а чтобы исключить необходимость ежедневного (ежеминутного) ручного обновления этих данных.

8. Использование счетчиков в качестве ключевых полей допустимо, но не позволяет сделать наглядным функциональную принадлежность ключевого поля к таблице. Особенно в тех случаях, когда в одной таблице присутствуют несколько внешних ключевых полей из разных таблиц в формате счетчиков, что приводит к существенным неудобствам понимания взаимодействия информации в БД и влечет за собой появление ошибок. Поэтому в значениях ключевого поля (или в дополнительном поле) в учебной БД целесообразно использовать, функционально-смысловые по отношению к таблице (текстовые) обозначения. Например, в ключевом поле таблицы «Сотрудники» обозначения: «Сотр_1», «Сотр_2», и т.д.; в ключевом поле таблицы «Поступление_товаров»: «Пост_1», «Пост _2», и т.д.

9. Наименование внешних ключевых полей в родительской таблице следует делать одинаковыми с названиями этих же (по содержанию) полей в связанных дочерних таблицах.

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

11. В исходных таблицах БД не следует приводить данные, значения которых можно получить только в результате вычисления (суммы, произведения и т.п.) или логических выражений. Например, не следует включать поля, содержащие произведение значений полей, содержащих «Цену» и «Количество» каких то товаров. Подобные вычисления следует реализовывать только в запросах.

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

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

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

15. В исходных таблицах не следует приводить лишних необоснованных записей. В частности, не следует включать в исходную таблицу (ИТ) «Клиенты» людей, которые в других ИТ нигде не упоминаются. Не следует включать в ИТ «Товары» те товары, которые ни разу не поступали.

2