Лабораторная работа № 1

Основы работы в ms Access, создание таблиц

Цель занятий: получение практических навыков работы в среде СУБД MS Access, и в частности, с таблицами.

СУБД – система управления базами данных. В данном случае – это реляционная база данных, интегрированная в пакет MS Office (входит в состав только MS Office Profesional). Пакет MS Access соединяет в себе такие качества, как простота использования и практически неограниченные возможности манипулирования данными. Вы можете, ничего не зная о программировании и о теории баз данных, создать с помощью мастеров MS Access полнофункциональную базу данных для своих потребностей. А если Вы квалифицированный программист и знакомы с программированием на VBA (Visual Basic for Application), то Вы можете создавать приложения любой сложности и для любых потребностей, Access предоставляет для этого все возможности.

Рабочее задание

Создать базу данных для гипотетического торгового предприятия (маленького магазинчика). Назовем ее "Магазин" и сформулируем цели и задачи этой базы данных.

Цель – учет прихода и расхода товаров на складе магазина.

Задачи, решаемые базой:

• просмотр и редактирование текущего состояния склада;

• ввод и редактирование документов: приходных на склад и расходных со склада, с автоматическим обновлением остатков на складе;

• распечатка накладных на продажу товаров;

• формирование отчетов: об объемах закупок и продаж товаров, о текущем состоянии склада.

Для этого понадобится создать базу данных со следующей структурой:

• таблицы – для хранения информации о сотрудниках фирмы, о товарах, приходная ведомость, для учета покупок товаров, расходная ведомость для учета продажи товаров;

• запросы, позволяющие получать оперативные сведения о наличии товара на складе и других показателях фирмы;

• формы для заполнения данных в таблицы БД и получения оперативной информации;

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

Порядок выполнения работы Проектирование структуры базы данных

1. Определим сущности в нашей предметной области:

• товары на складе;

• документы на приход товаров на склад;

• документы на продажу товаров (расход со склада);

• поставщики товара.

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

Сущность	Атрибуты сущности
Товары на складе	Наименование товара Цена продажи (будет копироваться в документы на продажу) Количество
Документы на приход товаров на склад	Дата Номер документа Поставщик Наименование товара Цена покупки Количество Сумма (данный атрибут не будет храниться в базе, он каждый раз вычисляется)
Документы на продажу товаров	Дата Номер документа Покупатель (данный атрибут использовать не будем, т.к. продаем товар частным лицам) Наименование товара Цена продажи Количество Сумма (данный атрибут не будет храниться в базе, он каждый раз вычисляется)
Поставщики товара	Наименование поставщика Адрес Руководитель

3. Составим первый вариант схемы реляционной базы данных (рис. 1). Для этого создадим таблицы, руководствуясь принципами: одна сущность – одна таблица; часто повторяющимся текстовые данные (наименованиям товаров и поставщиков) закодируем, используя числовые коды вместо самого текста. Атрибуты сущностей станут полями (колонками) таблиц.

Рис. 1. Предварительная схема базы данных "Магазин"

Для каждой таблицы определим ключ. Ключ – это одно или группа полей, которые однозначно идентифицируют любую строку (запись) в таблице. Все значения ключа в таблице для каждой строки уникальны. Для таблицы "ТоварыНаСкладе" ключом будет поле "Код товара" (на схеме ключ выделен полужирным шрифтом) с типом данных счетчик, который автоматически назначает для поля целые числовые значения 1, 2, 3 и т.д. У таблиц "Покупки" и "Продажи" ключом может быть поле "Номер документа", при условии, что номера будут уникальны для каждой таблицы. Если мы захотим начинать нумерацию с начала каждого года, то ключом можно сделать группу из двух полей, например "Номер документа"+"Дата покупки". Однако это громоздко с точки зрения последующего установления связей по этим полям. Наилучшим вариантом будет добавить поле счетчик "Код документа" и использовать его как ключ таблицы.

Выявим недостатки предварительной схемы. Таблицы "Покупки" и "Продажи" предназначены для хранения информации о соответствующих документах. В данном варианте в одном документе может быть записан только один товар. Для ввода нескольких товаров придется для них продублировать информацию в колонке "Номер документа" и "Дата…". Кроме того колонка "Код документа", значение которого уникально, будет формально отражать уже код строки в таблице. Фактически, сущность таких документов состоит из двух подсущностей: заголовок документа и спецификация товаров по документу, связанных отношением один-ко-многим по полю "Код документа". Таким образом мы должны разделить каждую из таблиц "Покупки" и "Продажи" на две, в соответствии с наличием указанных подсущностей. В первой таблице останутся поля "Код документа", "Номер документа" и "Дата…", в во вторую перейдут: "Код документа", "Код товара", "Цена…" и "Количество". Поле "Код документа" необходимо, чтобы каждая строка товара ссылалась на конкретный документ. Ключом во второй таблице будет группа полей "Код документа"+"Код товара". Назовем таблиц, содержащие детальные строки о товарах: "ПокупкиДетальн" и "ПродажиДетальн".

Таким образом, мы пришли ко второму варианту схемы базы данных (рис. 2).

Рис. 2. Второй вариант схема базы данных "Магазин"

4. Нормализуем спроектированные таблицы.

Цель нормализации сводится к получению такого проекта базы данных, в котором каждый факт появляется лишь в одном месте, т.е. исключена избыточность информации. Это делается не столько с целью экономии памяти, сколько для исключения возможной противоречивости хранимых данных. Часть такой работы уже сделана на предыдущем этапе п. 3. Теперь же необходимо проверить, находится ли каждая из таблиц в первой, второй и третьей нормальной форме.

4.1. Для того чтобы таблица считалась нормализованной к первой нормальной форме, каждое из ее полей должно быть неделимым (атомарным) и таблица не должна содержать никаких повторяющихся групп полей. Нарушает 1-ю нормальную форму таблица "Поставщики", т.к. поля Адрес и Руководитель не атомарные и могут быть разделены на: город, улица и т.д., или фамилия, имя, отчество. Однако, если эти поля мы будем использовать только в справочных целях, а не для группировки данных в отчетах, например объемы закупок у поставщиков из разных городов, тогда формальным требованием атомарности в данном случае мы пренебрегаем.

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

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

Второй нормальной форме удовлетворяют все таблицы.

4.3. Для того чтобы таблица была приведена к третьей нормальной форме, нужно, чтобы она удовлетворяла второй нормальной форме и все неключевые поля полностью зависели от первичного ключа таблицы и не зависели друг от друга. Таким образом, к квалификации второй нормальной формы добавляется требование независимости каждого неключевого поля таблицы от других неключевых полей. Нужно исключить из таблицы также поля, которые можно вычислить по другим неключевым полям таблицы, например не следует иметь в таблице "ПокупкиДетальн" поле "Сумма", т.к. его можно вычислить как "Цена покупки"* "Количество".

В нашем случае третьей нормальной форме удовлетворяют все таблицы.