Методичка БД V.3.0 light (docx)

4.ПРИМЕР ВЫПОЛНЕНИЯ КОНТРОЛЬНОГО ЗАДАНИЯ (ЛАБОРАТОРНОЙ РАБОТЫ)

ПО ПРОЕКТИРОВАНИЮ И СОЗДАНИЮ БАЗЫ ДАННЫХ

Приведем пример выполнения контрольного задания по проектированию и созданию базы данных.

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

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

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

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

Заполним матрицу отношений типов объектов (таблица 4.1). Представленный в таблице 4.1 вариант матрицы отношений яв-

ляется окончательным, т.е. в ней представлены только прямые зависимости типа “один ко многим”. Знаки “+”, соответствующие косвенным зависимостям, которые могли присутствовать в промежуточном варианте матрицы отношений, были удалены.

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

Построим согласно матрице отношений схему структуры предметной области и представим ее на рисунке 4.1.

19

Таблица 4.1 - Матрица отношений типов объектов предметной области “Учет производства продукции”

Позиция

отчета

Рисунок 2.1 - Схема структуры предметной области “Учет производства продукции”

20

Выше на схеме изображены родительские типы объектов, ниже – дочерние.

Все отношения между типами объектов, представленные на рисунке 4.1 на схеме структуры предметной области, имеют вид “один ко многим”. Одной товарной группе соответствуют многие виды продукции. Одной бригадой составляется много отчетов. Один отчет может включать много позиций. Один и тот же вид пр о- дукции может быть произведен множество раз.

Отношение между типами объектов “Рабочий” и “Бригада” имеет вид “многие ко многим”, т.к. один и тот же рабочий может в разное время работать в разных бригадах, а одна бригада состоит из многих рабочих. Отношение между типами объектов “Рабочий” и “Бригада” является существенным и должно быть отображено на схеме структуры предметной области. Чтобы сделать это, в структуре предметной области выделяется еще один тип объектов – “Назначение в бригаду” и отношение типа “многие ко многим” между типами объектов “Рабочий” и “Бригада” отображается при помощи двух отношений типа “один ко многим”, а именно: отношения между типами объектов “Рабочий” и “Назначение…”, а также отношения между типами объектов “Бригада” и “Назначение…”.

Аналогично отображается существенная связь типа “многие ко многим” между типами объектов “Разряд” и “Рабочий”. “Разряд” связывается с “Присвоением…” и “Рабочий” связывается с “Присвоением”, причем каждая из этих связей имеет вид “один ко многим”.

Определим набор таблиц базы данных. Каждому объекту предметной области будет соответствовать линейная таблица, т.е. база данных будет состоять из девяти таблиц: Разряды, Рабочие, Бригады, ТоварныеГруппы, ВидыПродукции, Отчеты, Назначения, Присвоение, ПозицииОтчетов. Обратите внимание: в именах таблиц отсутствуют пробелы между словами. СУБД (в частности MS Access) могут позволять использовать пробелы в именах, однако делать это нежелательно с точки зрения последующего использования имен в формулах и выражениях.

Составим словарь имен. Результаты этого шага проектирования базы данных представим в таблице 4.2.

Обратите внимание: слова в словаре имен отсортированы по алфавиту, благодаря чему нужное слово и соответствующее ему сокращение находятся быстрее.

21

Таблица 4.2 - Словарь имен базы данных “Учет производства продукции”

Определим состав, типы и размеры полей для каждой из таблиц базы данных. При назначении полям системных имен обратимся к сокращениям, принятым в словаре имен. Состав, типы полей, их системные имена и размеры приведены в таблице 4.3.

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

ской.

При формировании системных имен с использованием сокращений из словаря между частями системного имени не ставится пробел. Возможен такой вариант формирования системных имен, при котором части системного имени разделены знаком подчеркивания. В этом случае имена полей таблицы “ВидыПродукции” выглядели бы следующим образом: Код_Вид, Ном_Гр, Наим_Вид, Ед_Изм, Норм_Врем.

22

Таблица 4.3 - Состав полей таблиц базы данных “Учет производства продукции”

Создадим каждую из таблиц базы данных “Учет производства продукции” в СУБД Microsoft Access в режиме конструктора.

23

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

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

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

После того как создание структуры таблиц будет завершено, следует установить связи между ними. Для этого необходимо добавить все таблицы базы на схему данных и установить связи путем перетаскивания поля из одной таблицы в это же поле в другой таблице. При установлении связей программой предлагается обеспечить целостность данных, каскадное обновление и каскадное удаление. Рекомендуется включить опции обеспечения целостности и каскадного обновления.

На рисунке 4.2 представлена схема данных базы “Учет производства продукции”.

Далее создаются поля со списками. Поля со списками позволяют облегчить пользователю базы процесс ввода данных. Поля со списками имеет смысл создать для тех полей, рядом с которыми на схеме данных стоит символ бесконечности, соответствующий части “ко многим” отношения “один ко многим”.

Следующий шаг – создание форм. Создадим для каждой из таблиц при помощи мастера форм по одной форме “в один столбец” и по одной ленточной форме. Возможно создание форм с наличием подчиненных. Такие формы могут быть созданы на основе двух или более таблиц, связанных между собой.

Для обеспечения более удобного ввода и просмотра данных создадим ряд форм с наличием подчиненных: Рабочие / Назначения, Присвоение; Бригады / Отчеты; Отчеты / ПозицииОтчетов. На рисунке 4.3 в качестве примера представлена первая из перечисленных форм с наличием подчиненных.

По завершении разработки форм необходимо заполнить таблицы. Обеспечение целостности данных требует, чтобы сначала заполнялись родительские таблицы, затем дочерние.

В таблицах 4.4 – 4.12 представлены исходные данные базы “Учет производства продукции”.

24

25

Рисунок 4.2 – Схема данных базы “Учет производства продукции”

Таблица 4.7 - Таблица “Рабочие”

27

Таблица 4.11 - Таблица "ПозицииОтчетов"

28