Разработка СУБД "Записная книжка руководителя"

Разработка СУБД "Записная книжка руководителя"

1 ПОСТАНОВКА ЗАДАЧИ

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

В целом, база данных «Записная книжка руководителя» должна:

1) обеспечивать возможность запрашивать, отыскивать, изменять и систематизировать информацию о сотрудниках, заданиях и отделах в БД;

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

3) содержать систему помощи, необходимую справочную информацию и информацию о программе;

4) содержать необходимые запросы и формы для обработки хранимой информации;

5) обеспечивать защиту от несанкционированного доступа (использовать пароли и защиту на уровне пользователей);

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

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

1.2 Основные составные компоненты проектируемой БД

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

1) информация о сотрудниках;

2) информация о заданиях;

3) информация об отделах.

2 ОПИСАНИЕ ПРЕДМЕТНОЙ ОБЛАСТИ

База данных «Записная книжка руководителя» нам нужна для удобства слежения за выполнением задания разными сотрудниками. Каждый руководитель имеет свою записную книжку, которая необходима ему для записи заданий, которые он выдает своим сотрудникам и для оценки выполнения этих заданий. В ней он указывает данные о сотрудниках его предприятия: фамилия, имя, отчество сотрудника, домашний адрес, контактный телефон (телефон может быть как домашним, так и мобильным, т.е. включает в себя 13 символов), также отдел, в котором он работает (включает в себя участок и цех (цех обозначается аббревиатурой)), обязательно указывает занимаемую должность сотрудника. Каждому сотруднику руководитель выдает задание и заносит сведения о нем, такие как: какое задание выдано, дата выдачи (которое должно вводиться не раньше сегодняшнего числа), дата выполнения задания (ограничения такие же как и у даты выдачи) и оценка выполнения задания (оценка ставиться по пятибалльной системе). Причем за одним сотрудником может быть закреплено несколько заданий и одно задание могут выполнять несколько сотрудников. По этой базе данных мы можем сделать запрос о том, кто какое задание выполнил и на какую оценку или найти сотрудников, которые занимают одну должность. Также в базе существует архивация данных. Архивация происходит по ФИО сотрудника.

3 ОПИСАНИЕ СХЕМЫ ОБЪЕКТ-ОТНОШЕНИЕ

Исходя из моей предметной области, я выделила следующие объекты: «Сотрудники», «Отдел», «Должность», «Задание». Каждый объект имеет некоторые свойства. Объект «Сотрудники» имеет свойства: «ФИО», «Адрес», «Телефон»; Объект «Отдел» имеет свойства: «участок», «цех»; У «Должности» есть свойство: «название должности»; У объекта «Задание» свойство: «наименование задания».

Выделим необходимые отношения между объектами исходя из схемы объект-отношение, представленной на рисунке 3.1:

1. СОТРУДНИКИ относятся к ОТДЕЛУ;

2. СОТРУДНИКИ имеют ДОЛЖНОСТЬ;

3. СОТРУДНИКИ выполняют ЗАДАНИЯ.

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

Рисунок 3.1 - Схема объект-отношение

Большое количество разработанных к настоящему времени разнообразных СУБД связано с существованием различных моделей данных. При проектировании БД мы сталкиваемся с задачей выбора наиболее подходящей модели данных для конкретной предметной области.

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

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

Любая модель должна обеспечивать такие операции над БД:

- поиск указанного элемента базы;

- переход от одних данных к другим;

- движение по записям;

- поиск записи;

- удаление записи;

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

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

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

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

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

Рисунок 4.1 - Пример иерархической модели данных для проектируемой БД

Корневыми являются тип Сотрудники, который в свою очередь имеет свои подчиненные типы. Сотрудники имеет такие подчиненные типы как Отдел, Должность и Задание. К достоинствам ИМД относят эффективное использование памяти ЭВМ и неплохие показатели времени выполнения основных операций над данными. А именно: поиск указанного экземпляра БД, переход от одного дерева к другому, переход от одной записи к другой внутри дерева, вставка новой записи в указанную позицию, удаление текущей записи. ИМД удобна для работы с иерархически упорядоченной информацией. Недостатком ИМД является ее громоздкость для обработки информации с достаточно сложными логическими связями, а также сложность понимания для обычного пользователя.

Сетевая модель позволяет отображать разнообразные взаимосвязи элементов данных в виде произвольного графа, обобщая тем самым ИМД.

СМД состоит из набора записей и набора соответствующих связей. В отличие от ИМД в СМД запись-потомок может иметь произвольное число записей-предков (сводных родителей).

Схема СМД для данной БД показана на рисунке 4.2. Типы связей здесь обозначены надписями на соединяющих типы записей линиях.

Рисунок 4.2 - Сетевая модель данных

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

Поэтому недостатком СМД является высокая сложность и жесткость схемы БД, построенной на ее основе, а также сложность для понимания и выполнения обработки информации в БД обычным пользователем. Кроме того, в СМД ослаблен контроль целостности связей вследствие допустимости установления произвольных связей между записями. Таким образом, для разработанной в пункте 3 схемы объект-отношение данную модель данных применять нежелательно.

Достоинством СМД является возможность эффективной реализации по показателям затрат памяти и оперативности. В сравнении с ИМД сетевая модель предоставляет большие возможности в смысле допустимости образования произвольных связей.

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

В общем случае можно считать, что реляционная БД включает одну или несколько таблиц, объединенных смысловым содержанием, а также процедурами контроля целостности и обработки информации в интересах решения некоторой прикладной задачи. Например, при использовании СУБД Microsoft Access в файле БД наряду с таблицами хранятся и другие объекты базы: запросы, отчеты, формы, макросы и модули.

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

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

Переход от схемы объект - отношение к реляционной модели данных осуществляется следующим образом: все объекты схемы объект - отношение это определенные таблицы название полей которых являются свойствами объектов, если отношение имеет свойства то оно также является таблицей в полученной реляционной модели данных

Для проектируемой базы данных реляционная модель представлена на рисунке 4.3.

Рисунок 4.3 - Реляционная модель данных

Таким образом, после рассмотрения приведенных выше моделей данных для разработанной в пункте 3 схемы объект-отношение была выбрана РМД, которая проста и понятна для пользователя и отвечает требованиям изучаемого курса.

Программа Microsoft Access 2000 является реляционной СУБД, которая может функционировать под управлением операционных систем Windows 95/98/Me, Windows NT, Windows XP, и позволяет реализовать поставленную цель. Обеспечивает удобство работы пользователя: имеется возможность создания пользовательских интерфейсов при использовании Visual Basic для приложений, автоматизация разработки различных объектов. Для построения и выполнения запросной функции в Access 2000 очень удобным и доступным является язык запросов по образцу QBE, поддерживаемый мощным интерфейсом пользователя, а также встроенный язык запросов SQL, который является удобным языком управления базами данных.

Программа Microsoft Access 2000 имеет небольшой объем вспомогательного программного обеспечения, вследствие чего предъявляет меньше требований к памяти, чем программы Microsoft Access поздних версий. Кроме того, для проектирования требуемой БД нет необходимости в использовании возможностей более поздних программ Office или других фирм производителей. Вполне достаточно средств, предоставляемых пользователю Microsoft Access 2000.

6 ОПИСАНИЕ КОНЦЕПТУАЛЬНОЙ МОДЕЛИ РЕЛЯЦИОННОЙ

БАЗЫ ДАННЫХ

6.1 Схема данных

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

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

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

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

Таблица находится во второй нормальной форме (2НФ), если она удовлетворяет определению 1НФ и все ее поля, не входящие в первичный ключ, связаны полной функциональной зависимостью с первичным ключом.

Рисунок 6.2 - Таблица данных в 1НФ

Рисунок 6.3 - Функциональные зависимости для 1НФ

Рисунок 6.4 - Таблицы данных во 2НФ

После представления таблиц во 2НФ, представим шапки таблиц в 3НФ:

Сотрудники

Должность

О заданиях

Задания

Отдел

Рисунок 6.5 - Таблицы данных в 3НФ

6.2 Описание и обоснование полей таблиц

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

Таблица «Сотрудники» (таблица 6.2.1):

1. #КС

-Ключ: первичный ключ;

-Счетчик;

-Длинное целое[3];

-Совпадение не допускаются, так как это первичный ключ, он считает записи в таблице.

2. ФИО

- Текстовое[50];

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

- Пустых строк нет, так как не может быть предприятие без названия;

- Совпадения допускаются, так как у разных сотрудников могут быть одинаковые ФИО;

3. Адрес

- Текстовое[25];

- Обязательное поле, так как у каждого сотрудника есть свой адрес;

-Совпадения допускаются, так как разные сотрудники могут проживать по одному адресу;

4. Телефон

-Текстовое[7];

-Поле не обязательное, так как сотрудник может не иметь телефона;

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

5. Отдел

-Тип длинное целое[2];

-Обязательное поле, так как каждый сотрудник работает в отделе;

-Совпадения допускаются, так как несколько сотрудников работают в одном отделе;

-Подстановка: из таблицы «Отдел», поле «#КО»;

-Внешний ключ.

6. Должность

-Тип длинное целое[2];

-Обязательное поле, так как каждый сотрудник должен иметь свою должность;

-Совпадения допускаются, так как несколько сотрудников могут иметь одну должность;

-Подстановка: из таблицы «Должности», поле «#КД»;

-Внешний ключ.

Таблица 6.2.1 «Сотрудники»

Таблица «Задания» (таблица 6.2.2):

1. #КЗ

-Ключ: первичный ключ;

-Счетчик;

-Длинное целое[3];

-Совпадение не допускаются, так как это первичный ключ, он считает записи в таблице.

2. Задание

- Текстовое[50];

- Обязательное поле, так как это основное поле таблицы;

- Пустых строк нет, так как задание должно иметь текст;

- Совпадения не допускаются, так как записи о двух одинаковых заданиях не нужны.

Таблица 6.2.2 «Задания»

Таблица «Отдел» (таблица 6.2.3):

1. #КО

-Ключ: первичный ключ;

-Счетчик;

-Длинное целое[3];

-Совпадение не допускаются, так как это первичный ключ, он считает записи в таблице.

2. Участок

- Текстовое[3];

- Обязательное поле, так как участок должен иметь название;

- Совпадения не допускаются, так как разные участки должны иметь разные имена.

3. Цех

- Текстовый[3];

- Обязательное поле, так как цех должен иметь название

- Совпадения не допускаются, так как разные цеха должны иметь разные названия.

Таблица 6.2.3 «Отдел»

Таблица «Должности» (таблица 6.2.4):

1. #КД

-Ключ: первичный ключ;

-Счетчик;

-Длинное целое[3];

-Совпадение не допускаются, так как это первичный ключ, он считает записи в таблице.

2. Должность

- Текстовое[20];

- Обязательное поле, так как это основное поле таблицы;

- Пустых строк нет, так как поле не может иметь пустое название;

- Совпадения не допускаются, так как разные должности должны иметь разные названия.

Таблица 6.2.4 «Изделие»

Таблица «О заданиях» (таблица 6.2.5):

1. Сотрудник

-Тип длинное целое[2];

-Обязательное поле, так как каждый задание должно выполняться сотрудником;

-Совпадения допускаются, так как несколько сотрудников могут выполнять одно задание;

-Подстановка: из таблицы «Сотрудники», поле «#КС»;

-Внешний ключ.

2. Задание

-Тип длинное целое[2];

-Обязательное поле, так как каждый сотрудник должен выполнять задание;

-Совпадения допускаются, так как несколько сотрудников могут выполнять одно задание;

-Подстановка: из таблицы «Задания», поле «#КЗ»;

-Внешний ключ.

3. Дата выдачи

-Тип дата[10];

- Обязательное поле, так как задание должно иметь дату выдачи;

-Совпадения допускаются, так как разные задания могут выдаваться в один день;

- Маска: 00.00.0000;

-Значение по умолчанию =Date();

- Условие на значения =Date() так как задание должно иметь текущую дату выдачи.

4. Дата выполнения

-Тип дата[10];

- Не обязательное поле, так как задание может выдаваться без срока выполнения;

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

- Маска: 00.00.0000;

- Значение по умолчанию =Date()

- Условие на значения >=Date()and>(дата выдачи), так как задание не может быть выполнено раньше, чем выдано.

5. Оценка

-Тип длинное целое[1];

-Поле не обязательное, так как задание может быть не выполнено на текущий момент;

-Совпадения допускаются, так как задания могут выполняться на одну оценку;

-Подстановка: используется фиксированный набор значений;

Таблица 6.2.5 «О заданиях»

Результатом проведенной работы является база данных «Записная книжка руководителя» в СУБД Microsoft Access, имеющая удобный пользовательский интерфейс, предназначенный для работы различных групп пользователей.

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

Разработанная база данных может иметь широкое применение. Ее могут использовать прикладные программисты, учебные заведения, студенты, проходящие курс по сходной тематике. Особенно рекомендуется использовать БД статистическим организациям: исчезнет необходимость в многотомных бумажных картотеках, в утомительной ручной работе над разработкой статистических данных. Также, данную базу может использовать каждый руководитель для удобства записи данных о заданиях и сотрудниках. Кроме того, компьютер может вести поиск и изменять данные гораздо быстрее человека и лучше выполнять механическую работу.

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

Хомоненко А. Д., Цыганкова В. М., Мальцев М. Г. Базы данных: Учебник для высших учебных заведений / Под ред. проф. А. Д. Хомоненко. - Издание второе, дополненное и переработанное - СПб.: КОРОНА принт, 2002.

Дейт К. Дж. Введение в системы баз данных, 6-е издание: Пер. с англ. - К.; М.; СПб.: Издательский дом «Вильямс», 2000.

Пасько В. Access 97 - К.: Издательская группа BHV, 2000. - 368с.

Дейт К., Дж. Введение в системы баз данных, 6-е издание - К.; М.; СПб.: Из-дательский дом “Вильямс”, 2000.

Бекаревич Ю.Б., Пушкина Н.В. MS Access 2000 за 30 занятий. - СПб.: БХВ-Петербург, 2001. - 512 с.: ил.

Методические указания по оформлению студенческих работ/ Сост.: Л.А.Белозерский и др. - Донецк: ДГИИИ, 2000г.

Приложение Б

РУКОВОДСТВО ПОЛЬЗОВАТЕЛЯ

Б.1 Общие сведения

Разработанная БД предназначена для предоставления пользователю всей необходимой информации для автоматизации производительной деятельности промышленного предприятия.

Данная БД имеет удобный графический интерфейс. При запуске программы, появляется главное меню, содержащее все пункты, необходимые для работы с приложением. При необходимости добавить, просмотреть или изменить информацию нужно выбрать помощью клавиш управления курсором или <Tab> необходимую кнопку с названием формы, и нажать <Enter> или открыть форму кликом мыши.

Для запуска программы требуется запустить файл «Записная книжка руководителя.mdb» в СУБД MS Access.

Б.2 Ввод, удаление, добавление и редактирование данных

Ввод данных осуществляется в формах с помощью клавиатуры. Для ввода данных необходимо выделить указателем мыши необходимое поле или перейти на него с помощью клавиш управления курсором или <Tab>, и ввести данные. Аналогичным образом осуществляется редактирование данных.

Добавление данных осуществляется в формах так же, как и во всех БД.

На удаление записей пользователи «Гость» не имеют права. Удалять записи из таблиц или форм могут только пользователи «Adminstrator» и «Руководитель», используя соответствующие клавиши в формах.

Б.3 Просмотр отчетов

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

Б.4 Использование справочной информации и выход из программы

Справочная информация в БД. В целом для осуществления необходимых действий требуется читать надписи на кнопках или рядом с ними и нажимать на эти кнопки.

Приложение В

ЛИСТИНГИ ПРОГРАММНЫХ МОДУЛЕЙ

Private Sub Кнопка2_Click()

On Error GoTo Err_Кнопка2_Click

Dim stDocName As String

Dim stLinkCriteria As String

Dim a As Long

stDocName = ChrW(1075) & ChrW(1083) & ChrW(1072) & ChrW(1074) & ChrW(1085) & ChrW(1072) & ChrW(1103)

If Список0.Value = "Администратор" Then

If Поле4.Value = "admin" Then

DoCmd.Close

DoCmd.OpenForm stDocName, , , stLinkCriteria

Form_Главная.Надпись27.Caption = "Администратор"

DoCmd.RunCommand acCmdWindowUnhide

Else: a = MsgBox("Введен неверный пароль")

End If

Else

If Список0.Value = "Руководитель" Then

If Поле4.Value = "ruk" Then

DoCmd.Close

DoCmd.OpenForm stDocName, , , stLinkCriteria

Form_Главная.надпись27.Caption = "Руководитель"

Else: a = MsgBox("Введен неверный пароль")

End If

Else

If Список0.Value = "Гость" Then

DoCmd.Close

DoCmd.OpenForm stDocName, , , stLinkCriteria

Form_Главная.надпись27 = "Гость"

Form_Главная.кнопка5.Enabled = False

End If

End If

End If