Создание базы данных «Сервисный центр по ремонту и обслуживанию офисной техники» с использованием средств Microsoft Access

Создание таблиц

Работа в  Access начинается с определения реляционных таблиц и их полей, которые будут содержать данные.

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

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

       назначение базы данных;

       необходимые таблицы и поля;

       необходимые связи между таблицами;

       указания, как избежать излишних данных;

       указание, как убедиться в согласованности данных.

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

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

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

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

       максимизацию скорости и эффективности вашей базы данных;

       обеспечение того, что одинаковые данные никогда не будут помещены более  чем одно поле;

       экономию дискового пространства путем избежания излишних данных;

       обеспечение согласованности  и единообразия данных, будь то входные или выходные данные;

       создание дизайна, который гораздо более удобен, чем таковой с ненормализованными данными, для поддержания и управления;

       создание механизма для поисков по условию  в запросах, формах или отчетах.

Об этом нужно помнить при создании базы данных.

Структура таблицы и типы данных

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

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

В Access используются три способа создания таблиц: путём ввода данных, с помощью Конструктора таблиц и с помощью Мастера создания таблиц. Для каждого из этих способов существует специальный ярлык новых объектов в списке таблиц (рис. 1).

    Рис.1

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

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

    Рис.2

• В окне Конструктора таблиц в столбец Имя поля вести имена полей создаваемой таблицы.

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

• В столбце описание можно ввести описание данного поля.

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

• После описания всех полей будущей таблицы нажать кнопку Закрыть.

• На вопрос Сохранить изменения макета или структуры таблицы, нажать кнопку Да.

• В окне Сохранить как в поле Имя таблицы ввести имя создаваемой таблицы и нажать кнопку ОК.

• В ответ на сообщение Ключевые поля не заданы и вопрос Создать ключевые поля сейчас? нажмите кнопку Да если ключевое поле необходимо, или кнопку Нет если такового не требуется

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

Рис.3

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

Описание бизнес-процесса при помощи методологии структурного анализа и проектирования (SADT)

Методология SADT позволяет описывать в виде древовидной функциональной модели бизнес-процесс любой сложности. Основная идея методологии SADT очень проста: сначала весь бизнес- процесс описывается в целом (без подробностей) посредством контекстной диаграммы, которая представляется в виде прямоугольного блока с текстом, отражающим основную цель описываемого бизнес-процесса. Кроме основной цели, контекстная диаграмма включает описание внешнего воздействия на бизнес-процесс в терминах входа; (объекты, потребляемые или изменяемые бизнес-процессом, например сырье), выхода (основной результат бизнес-процесса), управления (нормы, правила, законы и т.д., которыми руководствуются, например, исполнители процесса) и механизмов или ресурсов. Входы, выходы, управление и ресурсы отображаются на диаграммах в виде дуг с обозначающим их текстом.

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

Рис.4  Контекстная диаграмма бизнес-процесса по ремонту техники ремонтной мастерской

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

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

На рис. 5 представлен результат декомпозиции контекстной диаграммы, показанной на рис. 4

Рис.5

Из представленной схемы видно, что основными процессами, выполняемы­ми в мастерской, являются прием изделия в ремонт, ремонт изделия (с сохра­нением информации о ремонте), выдача из ремонта и, наконец, подготовка отчетов о произведенных ремонтах. Прием в ремонт и выдачу отремонтированных изделий осуществляет менеджер (дуги, помеченные словом «менеджер»). Ремонт изделий выполняет специалист по ремонту (дуга, помеченная как «Специалист по ремонту»). Входом блока «Принять изделие в ремонт» являются неисправные изделия; в качестве управления используются некоторые правила (инструкции). Выходом этого блока (итогом работы) являются зарегистрированные (принятые в ремонт) из­делия. Поскольку при регистрации изделия менеджер использует информаци­онную систему (для разработки которой и создается описание бизнес-процес­са), то в таблицы базы данных он заносит регистрационную информацию.

Зарегистрированные изделия поступают на вход блока «Ремонтировать из­делие», выход которого используется в качестве входов блоков «Сохранить данные о ремонте» и «Выдать изделие из ремонта». Менеджер вносит результаты ремонта в базу данных и выдает изделие клиенту, сдавшему изделие в ре­монт.

Формирование отчетов о ремонтах (в соответствии с инструкциями компа­нии) осуществляет менеджер (блок «Подготовить отчеты по ремонтам»).

Как видно на рис. 5, дуги могут разветвляться. Например, «Инструкции, бизнес правила», в частности, могут включать «Систему кодирования неисправ­ностей и ремонта», которая используется при сохранении данных о ремонте.