5. Стадии проектирования базы данных для реализации в сурбд ms access

Студенту для реализации предложено такое задание:

Разработать БД Microsoft Access, которая содержит информацию о запасных частях автомобилей на складах автопредприятия. В БД предусматривается отображение информации в виде 3-х таблиц с установлением отношений связи 1-1 (один к одному) или 1- (один ко многим). В таблицах должны быть следующие данные:

номер склада, его площадь, заведующий, узел автомобиля (мотор, кузов, електрооборудование, рулевое управление и т.п.), марка автомобиля, марка детали по каталогу, количество, дата поступления на склад, закупочная цена, поставщик.

Применительно к заданной предметной области выполнить в СУБД MS ACCESS следующие операции:

1. Проектирование БД и таблиц (разбиение исходных данных по таблицам, нормализация , определение имен, типов и размеров полей, приведение расчетных формул, добавление ключевых полей, связывание таблиц, перечисление необходимых форм, отчетов, запросов). Выполняется в тетради и согласовывается с преподавателем.

2. Создание таблиц (ввод структуры таблиц).

3. Корректировка структуры таблиц.

4. Создание форм для занесения данных в базу.

5. Заполнение данными таблиц (не менее 20 строк в главной таблице). Ввод и редактирование записей, просмотр базы.

6. Поиск и замена данных, установка фильтров, сортировка.

7. Создание и выполнение запросов (по заданию преподавателя).

8. Создание отчетов по запросам.

9. Создание отчета по практике.

Реляционная база данных, которая реализуется средствами СУРБД MS ACCESS, заполняется информацией, структурированной в соответствии с заданием, и представляется пользователю в виде таблицы (набора таблиц). В MS ACCESS все объекты, входящие в базу данных , сохраняются в виде единого файла, имеющего расширение mdb.

Для рассматриваемой задачи дадим имена: базе - “Склад” и файлу, ее содержащему, Склад.mdb. В ACCESS-базу могут входить разнородные объекты, используемые для хранения и представления информации: таблицы, запросы, формы, отчеты, модули и макросы. Каждый объект имеет уникальное для данной базы имя.

Таблица - набор записей базы данных, представленных в виде таблицы.

Запрос - набор сведений для выбора из базы информации, соответствующей какому-либо условию.

Форма – специальный бланк с полями таблицы, служащий ля ее заполнения. Маска-форма позволит ограничить объем информации, доступной пользователю и представить ее в требуемом виде.

Отчет - выбранная и оформленная для печати информация.

Макрос - соответствующим образом оформленная последовательность действий, часто повторяющихся при работе с данной базой данных.

Модуль - собственная процедура обработки информации, написанная на языке ACCCESS BASIC.

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

• Внутри таблицы назначаются только уникальные имена полей. Максимальная длина имени - 64 символа, включая пробелы. Алфавит – любой. Запрещенные символы: ”!” , “ . “ , “[“ , “]”. Имя поля не может начинаться с пробела.

• Тип данных может быть выбран только из стандартного набора:

  • Счетчик

  • Текстовый

  • поле Memo

  • Числовой

  • Дата/Время

  • Денежный

  • Логический

  • Поле объектов OLE

Математические операции могут выполняться только над числовыми полями и их разновидностью – денежными. Данные денежного содержания (стоимость, зарплата, различные платежи, налоги, пеня) следует выбирать с денежным типом с двумя разрядами после десятичной точки (для копеек). Номера телефонов, номерные знаки автомобилей, телефонные коды городов, различные названия определяют как поля текстового типа.

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

Проектирование базы данных начинается с определения её структуры, которая должна быть эффективной:

• обеспечить быстрый доступ к данным;

• исключить ненужное повторение данных , что, помимо лишних трудозатрат, может вызвать увеличение ошибок при вводе;

• обеспечить целостность данных: изменение одних данных должно вызывать изменение связанных с ними данных.

Разработка структуры БД состоит из нескольких этапов:

1. Простое перечисление характеристик объекта (генеральный список полей);

2. Определение макетов главной и подчиненной таблиц, имеющих уникальные имена в базе. Кодорование информации.

3. Задание первичных ключей. Определение связей между таблицами.

4. Нормализация. Обеспечение целостности данных.

I этап проектирования уже выполнен постановщиком задачи, хотя студент вправе дополнить предложенный генеральный список полей по своему усмотрению.

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

• номер склада, его площадь, заведующий;

• узел автомобиля, марка автомобиля, марка детали по каталогу, количество, дата поступления на склад, закупочная цена;

• поставщик.

В первую группу добавим телефон склада, в третью – телефон поставщика. Заметим, что марки деталей по каталогу не повторятся ни для каких типов авто, поэтому считаем эти данные уникальными и предполагаем сделать поле с такими значениями - полем первичного ключа для второй таблицы. Тип данных – текстовый и совпадения не допускаются. Во вторую группу следует добавить ссылку на место хранения детали, т.е. указать номер склада. В первой группе не повторяются номера складов, поэтому именно эти данные и будут полем первичного ключа. Поскольку это номер склада, то тип данных – числовой, целое. В третьей группе поставщики не должны повторяться, т.к. фактически предполагается ведение справочника поставщиков, но названия фирм разнообразием не отличаются, часты повторы, поэтому удобнее присвоить каждому поставщику код и уже его использовать в качестве первичного ключа и для ссылки в других таблицах. Тип таких данных сделаем счетчиком. Такие рассуждения привели к следующей структуре таблиц:

Таблица «Склады»

Данные	Имя поля	Тип поля
номер склада	Номер_склада	Числовой
площадь	Площадь	Числовой
заведующий	Заведующий	Текст
телефон	Телефон	Текст

Таблица «Детали»

Данные	Имя поля	Тип поля
узел автомобиля	Узел_авто	Текст
марка автомобиля	Марка_авто	Текст
марка детали по каталогу	Каталожный_номер	Текст
номер склада	Номер_склада	Числовой
количество	Количество	Числовой
дата поступления на склад	Дата_поступления	Дата/время
поставщик	Код_поставщика	Числовой
закупочная цена	Закупочная_цена	Денежный

Таблица «Поставщики»

Данные	Имя поля	Тип поля
код поставщика	Код_поставщика	Числовой
поставщик	Наименование	Числовой
телефон	Телефон	Текст

III этап. Связь между таблицами поддерживается при помощи совпадающих полей. Типы совпадающих полей должны быть одинаковыми, кроме полей типа Счетчик. Если таблицы будут пополняться и в главной таблице связываемое поле типа Счетчик, то в таком случае поле в подчиненной таблице должен быть типа Числовой. Совпадать должны значения, но не названия полей, хотя удобнее для разработчика, когда и названия совпадают тоже. Для числовых полей должны совпадать размеры поля. Главной будет таблица «Детали», а «Склады» и «Поставщики» – подчиненными. В подчиненную таблицу можно будет занести только ту информацию, которая относится к уже заданному объекту в главной таблице. Рассмотрим все ключевые поля, которые были введены в таблицы. В главной таблице («Детали») поле первичного ключа - Каталожный_номер, поле Код_поставщика – вторичный ключ для подчиненной таблицы «Поставщики», поле Номер_склада - вторичный ключ для подчиненной таблицы «Склады». Таким образом, таблицы можно связать следующим образом:

таблица «Детали» с таблицей «Поставщики» по полю Код_поставщика с соотношением «один ко многим», т.к. один поставщик может поставлять детали разного ассортимента;

таблица «Детали» с таблицей «Склады» по полю Номер_склада с соотношением «один ко многим», т.к. на одном складе хранятся различные детали.

IV этап. Разработанные таблицы следует проверить на соответствие законам нормализации. В нашем примере спроектированная база отвечает всем нормальным формам. (Предлагается проверить студенту).

К разработанным таблицам следует добавить формы для ввода исходной информации (заполнении базы), предполагаемые запросы и отчеты по ним. Все вместе это образует структуру базы. В процессе создания и эксплуатации базы могут вноситься дополнения и уточнения (новые таблицы и запросы), изменяться названия полей, добавляться или удаляться поля в таблицы, т.е. процесс проектирования базы данных предполагает возможность многократного возврата и повторения отдельных этапов до тех пор, пока поставленная задача не будет решена. На этом проектирование базы в нашем примере в первом приближении будем считать завершенным и приступим к этапу реализации в MS ACCESS.