База данных учета сотрудников корпорации

Размещено на http://www.allbest.ru/

КУРСОВОЙ ПРОЕКТ

по дисциплине

«Базы данных»

на тему: «База данных учета сотрудников корпорации»

Содержание

• Введение
• 1 Системный анализ предметной области
• 2 Инфологическое моделирование
• 2.1 Выявление сущностей инфологической модели
• 2.2 Связи между сущностями инфологической модели
• 3 Даталогическое проектирование базы данных
• 3.1 Нормализация базы данных
• 3.2 Построение таблиц базы данных
• 4 Физическое проектирование базы данных
• 5 Реализация базы данных
• 6 Создание интерфейса приложения
• Заключение
• Список использованных источников
• Приложение А Листинг SQL-запросов
• Приложении Б Листинг программных кодов

Введение

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

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

Основные типы СУБД различаются по стратегиям, которые используются ими, для того чтобы удовлетворить запросы к базе данных. Типы базы данных называются согласно стратегии, которую они используют. Известны реляционные, иерархические и сетевые базы данных. В современных профессиональных СУБД реализуются реляционные базы данных.

Цель данной курсовой работы: реализовать базу данных для учета сотрудников корпорации.

Задачами, которые следует решить для раскрытия выбранной темы, являются:

- сбор документов для описания предметной области;

- отбор документов - источников для создания базы данных (этап системного анализа предметной области);

- выявление сущностей инфологической модели и моделирование связей между ними (этап инфологического моделирования);

- построение набора таблиц базы данных и нормализация базы (этап даталогического проектирования);

- описание внешних моделей в терминах выбранной СУБД (этап даталогического проектирования);

- выбор схемы размещения данных, определение числа и типа индексов (этап физического моделирования);

- реализация базы данных и организация запросов в выбранной СУБД (этап реализации базы данных);

- реализация программного интерфейса к базе данных (этап создания интерфейса приложения).

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

1 Системный анализ предметной области

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

1. Системный анализ и словесное описание информационных объектов предметной области.

2. Инфологическое моделирование - частично формализованное описание объектов предметной области в терминах некоторой семантической модели, например, в терминах ER-модели (модель «сущность-связь»).

3. Даталогическое или логическое моделирование БД - описание БД в терминах принятой даталогической модели данных.

4. Физическое проектирование БД - выбор эффективного размещения БД на внешних носителях для обеспечения наиболее эффективной работы приложения.

На первом этапе нужно провести подробное словесное описание объектов предметной области и реальных связей, которые присутствуют между описываемыми объектами.

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

Функциональный подход реализует принцип движения «от задач» и применяется тогда, когда заранее известны функции некоторой группы лиц и комплексов задач, для обслуживания информационных потребностей которых создается рассматриваемая СУБД. В этом случае можно четко выделить минимальный необходимый набор объектов предметной области, которые должны быть описаны.

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

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

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

- данные о подразделениях корпорации;

- данные об офисах корпорации;

- данные о профсоюзах;

- данные о сотрудниках;

- данные о детях сотрудников.

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

- положения о подразделениях;

- положения о профсоюзах;

- личные дела сотрудников;

- бухгалтерские накладные и ведомости.

2 Инфологическое моделирование

Инфологическая модель применяется на втором этапе проектирования БД, то есть после словесного описания предметной области.

Инфологическая модель должна включать такое формализованное описание предметной области, которое легко будет «читаться» не только специалистами по базам данных. И это описание должно быть настолько емким, чтобы можно было оценить глубину и корректность проработки проекта БД, и конечно, оно не должно быть привязано к конкретной СУБД. Выбор СУБД - это отдельная задача, для корректного ее решения необходимо иметь проект, который не привязан ни к какой конкретной СУБД.

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

Инфологическое моделирование - это частично формализованное описание объектов предметной области в терминах некоторой семантической модели, например, в терминах модели «сущность-связь», или ER-модели (Entity Relationship). Эта модель в наибольшей степени согласуется с концепцией объектно-ориентированного проектирования, которая в настоящий момент, несомненно, является базовой для разработки сложных программных систем.

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

Между сущностями могут быть установлены связи - бинарные ассоциации, показывающие, каким образом сущности соотносятся или взаимодействуют между собой. Связь может существовать между двумя разными сущностями или между сущностью и ей же самой (рекурсивная связь). Связи делятся на три типа по множественности: один-к-одному (1:1), один-ко-многим (1:М), многие-ко-многим (М:М). Связь «один-к-одному» (1:1) означает, что один экземпляр одной сущности связан только с одним экземпляром другой сущности, а связь «многие-ко-многим» (М:М) означает, что один экземпляр первой сущности может быть связан с несколькими экземплярами второй сущности, и наоборот, один экземпляр второй сущности может быть связан с несколькими экземплярами первой сущности. Связь «один-ко-многим» 1:М означает, что один экземпляр сущности, расположенный слева по связи, может быть связан с несколькими экземплярами сущности, расположенными справа по связи.

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

2.1 Выявление сущностей инфологической модели

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

На основании изучения предметной области выделим следующие сущности модели «сущность-связь»: «Подразделения», «Офисы», «Профсоюзы», «Сотрудники», «Дети» (см. рисунки 1 - 5).

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

Подразделения
КодПодразделения
НаименованиеПодразделения
РуководительОтдела
Кол-воСотрудников

Рисунок 1 - Определение сущности «Подразделения» в модели ER

Офисы
КодОфиса
НаименованиеОфиса
ПодразделенийВОфисе
СпециализацияОфиса Глава ЮридическийАдрес Факс Телефон

Рисунок 2 - Определение сущности «Офисы» в модели ER

Профсоюзы
КодПрофсоюза
ПрофсоюзныйЛидер
СоциальныеГарантииЧленамПрофсоюза
СобранияКомитета
ЕжемесячныйПрофсоюзныйВзнос_руб

Рисунок 3 - Определение сущности «Профсоюзы» в модели ER

Сотрудники
КодСотрудника
Фамилия
Имя Отчество ДатаРождения Пол ДомашнийАдрес ДомашнийТелефон СемейноеПоложение СведенияОбОбразовании СтажРаботы_лет РабочийТелефон ТелефонДляВнутреннейСвязи Специальность НомерПриказа Оклад_руб

Рисунок 4 - Определение сущности «Сотрудники» в модели ER

Дети
КодРебенка
ФИОРебенка
ДатаРождения
МестоУчебы

Рисунок 5 - Определение сущности «Дети» в модели ER

2.2 Связи между сущностями инфологической модели

Установим связи между сущностями. Будем считать для простоты все связи обязательными. Между выделенными сущностями можно выделить следующие связи:

1. «Офисы» - «Подразделения» (связь 1:М).

2. «Профсоюзы» - «Подразделения» (связь 1:М).

3. «Подразделения» - «Сотрудники» (связь 1:М).

4. «Сотрудники» - «Дети» (связь 1:М).

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

Рисунок 6 - Моделирование связей между сущностями предметной области

3 Даталогическое проектирование базы данных

Следующий этап проектирования - построение даталогической модели. В рассматриваемом случае задача этого типа - преобразование ER-диаграммы в реляционную схему.

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

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

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

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

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

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

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

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

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

3.1 Нормализация базы данных

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

Правило 4. Если степень бинарной связи равна 1:M и класс принадлежности M-связной сущности является обязательным, то достаточным является использование двух таблиц (по одной на каждую сущность), при условии, что ключ каждой сущности служит в качестве первичного ключа для соответствующей таблицы. Помимо этого, ключ 1-связной сущности должен быть добавлен как атрибут в таблицу, отводимую n-связной сущности.

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

1. После реализации первого шага каждая простая сущность превращается в таблицу с тем же именем. Таким образом, имеем следующие таблицы: «Подразделения», «Офисы», «Профсоюзы», «Сотрудники», «Дети».

2. Каждый атрибут становится столбцом с тем же именем. Столбцы, соответствующие необязательным атрибутам, могут содержать неопределенные значения; столбцы, соответствующие обязательным атрибутам, - не могут. 3. Компоненты уникальных идентификаторов сущностей превращаются в первичные ключи соответствующих отношений.

4. Связи «многие-к-одному» становятся внешними ключами. Необходимо преобразовать связи во внешние ключи. На стороне «многие» в отношение согласно правилу 4 должен быть добавлен как внешний ключ первичный ключ отношения со стороны «один». Например, в отношение «Дети» должен быть добавлен для связи с отношением «Сотрудник» внешний ключ «Код сотрудника» из отношения «Сотрудник», где он является первичным ключом.

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

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

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

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

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

«Подразделения» - содержит по одной строке для каждого из подразделений;

«Офисы» - содержит по одной строке для каждого офиса;

«Профсоюзы» - содержит по одной строке для каждого из профсоюзов;

«Сотрудники» - содержит по одной строке для каждого из сотрудников;

«Дети» - содержит по одной строке для каждого из детей.

Все таблицы базы данных находятся в третьей нормальной форме:

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

- первичные ключи однозначно определяют запись и неизбыточны, все поля каждой из таблиц зависят от ее первичного ключа (2НФ);

- значение любого поля, не входящего в первичный ключ, не зависит от значения другого поля, тоже не входящего в первичный ключ (3НФ).

Структура БД представлена на рисунке 7.

Рисунок 7 - Структура базы данных

3.2 Построение таблиц базы данных

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

Выбор остановим на реляционной СУБД MS Access.

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

Рисунок 8 - Таблица «Сотрудники» в режиме конструктора

4 Физическое проектирование базы данных

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

- выбор способа организации базы данных (физические модели баз данных);

- разработку спецификации внутренней схемы средствами модели данных ее внутреннего уровня;

- описание отображения концептуальной схемы во внутреннюю.

Важно заметить, что в отличие от ранних СУБД, многие современные системы не предоставляют разработчику какого-либо выбора на этой стадии. Реально к вопросам проектирования физической модели можно отнести выбор схемы размещения данных (разделение по файлам или тип RAID-массива) и определение числа и типа индексов (например, кластеризованный или некластеризованный в случае MS SQL Server). Способ хранения базы данных определяется механизмами СУБД автоматически «по умолчанию» на основе спецификаций концептуальной схемы базы данных, и внутренняя схема в явном виде в таких системах не используется.

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

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

Поля «Код офиса» и «КодПрофсоюза» таблицы «Подразделения»», «Код подразделения» таблицы «Сотрудники», «Код сотрудника» таблицы «Дети» являются внешними ключами, на них может быть установлено свойство Индексированное поле - Да (Совпадения допускаются).

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

5 Реализация базы данных

база данные запрос инфологический

Обычная технология разработки приложений для баз данных с использованием систем программирования, не являющихся системами управления базами данных (СУБД), заключается в том, что собственно база данных (таблицы, связи между ними) создается при помощи интегрированной среды одной из СУБД, а интерфейс и код управления данными - при помощи Visual-системы программирования. Для создания приложений СУБД MS Access можно воспользоваться, например, средствами Visual Basic.

В Visual Basic с помощью надстройки Visual Data Manager была создана база данных sotr.mdb, состоящая из 5 таблиц: «Подразделения», «Офисы», «Профсоюзы», «Сотрудники», «Дети» (см. рисунок 9).

В Visual Basic запросы с помощью надстройки Visual Data Manager можно создавать вручную, записывая команду на языке SQL в специальном окне менеджера SQL Statement, либо путем автоматического построения с помощью Query Builder. С помощью SQL Statement было создано несколько запросов: «детей у сотрудников», «зарплата», «кол-во сотрудников в офисе», «сотрудники женщины», «сотрудники мужчины». (см. рисунок 9).



Рисунок 9 - Создание БД с помощью Visual Data Manager

6 Создание интерфейса приложения

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

Visual Basic позволяет создать автоматически форму с элементом управления Data и кнопками управления записями через Visual Data Manager с помощью дизайнера форм базы данных Data Form Designer.

После создания в Visual Basic проекта Проект1.vbp, из всех таблиц и запросов БД с помощью Data Form Designer были построены и отредактированы формы (см. рисунок 10). Список всех форм проекта - на рисунке 11.



Рисунок 10 - Форма «Альбомы» БД, созданная с помощью Data Form Designer

Рисунок 11 - Список всех форм проекта MyProject.vbp

Вручную была создана frmз_ЗАПРОСЫ - форма для вывода результатов запроса в таблицу и записи в файл текста самого запроса и результат его выполнения (см. рисунок 12). В дальнейшем этот текст можно вывести на печать и при необходимости легко преобразовать, например, в файл электронных таблиц.



Рисунок 12 - Форма для запросов frmInquiry проекта MyProject.vbp

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

Для проектирования и управления отчетами в Visual Basic имеются специальный объект DataReport и инструментальное средство Data Report Designer (Конструктор отчетов).

С помощью Data Report Designer были созданы два отчета: «Зарплата»» на основе запроса Зарплата (см. рисунок 13) и «Сотрудники+Дети» на основе таблиц Сотрудники и Дети (см. рисунок 14).



Рисунок 13 - Отчет «Зарплата», созданный с помощью Data Report Designer

Рисунок 14 - Отчет «Сотрудники+Дети», созданный с помощью Data Report Designer

Работа приложения начинается с главной кнопочной формы - Form1.frm. Через этот главный интерфейс приложения начинается работа в среде приложения, осуществляется выбор того или иного компонента приложения, представленного некоторой подчиненной кнопочной формой, и обеспечивается обращение к нужным объектам компонента - формам, запросам, отчетам.

Меню команд главной формы создается в режиме проектирования с помощью редактора меню Menu Editor.

На главной форме расположены кнопки «Офисы», «Подразделения», «Профсоюзы», «Сотрудники», «Дети сотрудников», для перехода к соответствующим формам.

На главной форме расположено меню, состоящее из следующих команд: «Запросы», включает в себя «Выполнение запроса», «Дети сотрудников», «Сотрудников в офисе», «Сотрудники женщины», «Сотрудники мужчины», «зарплата»; «Отчеты», включает в себя «Отчет по зарплате», «Отчет по сотрудникам»; «О программе».

Вид главной формы представлен на рисунке 15.



Рисунок 15 - Главная форма БД «MyCD»

Заключение

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

База данных содержит следующую информацию:

- данные о подразделениях корпорации;

- данные об офисах корпорации;

- данные о профсоюзах;

- данные о сотрудниках;

- данные о детях сотрудников.

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

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

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

Меню команд главной формы включает в себя команды: «Запросы», «Отчеты», «О программе».

При помощи базы данных будет удобно вести учет сотрудников корпорации.

Список использованных источников

1. Браун С. Visual Basic 6: Учебный курс. - СПб.: «Питер», 2002. - 576 с.

2. Голицина О.Л. Базы данных: Учебное пособие. - М.: «ФОРУМ: ИНФРА-М», 2003. - 352 с.

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

4. Карпова Т.С. Базы данных: модели, разработка, реализация. - СПб.: «Питер», 2002. - 304 с.

5. Хомоненко А.Д. Базы данных: Учебник для вузов. - М.: «Корона», 2000. - 421 с.

Приложение А

Листинг SQL-запросов

1. Детей у сотрудников

SELECT Сотрудники.КодСотрудника, Сотрудники.Фамилия, Сотрудники.Имя, Сотрудники.Отчество, Count(Дети.КодРебенка) AS [Count-КодРебенка]

FROM Сотрудники INNER JOIN Дети ON Сотрудники.КодСотрудника=Дети.КодСотрудника

GROUP BY Сотрудники.КодСотрудника, Сотрудники.Фамилия, Сотрудники.Имя, Сотрудники.Отчество;

2. Зарплата

SELECT Сотрудники.КодСотрудника, Сотрудники.Фамилия, Сотрудники.Имя, Сотрудники.Отчество, Сотрудники.НомерПриказа, Сотрудники.Оклад_руб, [Сотрудники]![Оклад_руб]+[Сотрудники]![СтажРаботы_лет]*500-[Профсоюзы]![ЕжемесячныйПрофсоюзныйВзнос_руб] AS Зарплата, [Зарплата]-[Зарплата]*0.13 AS [ЗарплатаСВычетомНалогов]

FROM Профсоюзы INNER JOIN (Подразделения INNER JOIN Сотрудники ON Подразделения.КодПодразделения = Сотрудники.КодПодразделения) ON Профсоюзы.КодПрофсоюза = Подразделения.КодПрофсоюза;

3. Кол-во сотрудников в офисе

SELECT Офисы.КодОфиса, Офисы.НаименованиеОфиса, Офисы.Глава, Офисы.СпециализацияОфиса, Count(Сотрудники.КодСотрудника) AS [Count-КодСотрудника]

FROM (Офисы INNER JOIN Подразделения ON Офисы.КодОфиса = Подразделения.КодОфиса) INNER JOIN Сотрудники ON Подразделения.КодПодразделения = Сотрудники.КодПодразделения

GROUP BY Офисы.КодОфиса, Офисы.НаименованиеОфиса, Офисы.Глава, Офисы.СпециализацияОфиса;

4. Сотрудники женщины

SELECT Сотрудники.Фамилия, Сотрудники.Имя, Сотрудники.Отчество

FROM Сотрудники

WHERE (((Сотрудники.Пол)="ж"));

5. Сотрудники мужчины

SELECT Сотрудники.Фамилия, Сотрудники.Имя, Сотрудники.Отчество

FROM Сотрудники

WHERE (((Сотрудники.Пол)="м"));

Приложении Б

Листинг программных кодов

1. Главная форма

Private Sub Command1_Click()

frmСотрудники.Show

End Sub

Private Sub Command2_Click()

frmДети.Show

End Sub

Private Sub Command3_Click()

frmОфисы.Show

End Sub

Private Sub Command4_Click()

frmПодразделения.Show

End Sub

Private Sub Command5_Click()

frmПрофсоюзы.Show

End Sub

Private Sub Command6_Click()

Unload Me

End Sub

Private Sub mnnuZarp_Click()

frmЗАПРОСзарплата.Show

End Sub

Private Sub mnuAftor_Click()

inf = MsgBox("Выполнила Сидешева Марина, ДФД-32", vbInformation, "О программе")

End Sub

Private Sub mnuDetsotr_Click()

frmЗАПРОСдетей.Show

End Sub

Private Sub mnuExit_Click()

Unload Me

End Sub

Private Sub mnuJen_Click()

frmЗАПРОСжен.Show

End Sub

Private Sub mnuMyj_Click()

frmЗАПРОСмуж.Show

End Sub

Private Sub mnuot4et1_Click()

Продолжение Приложения Б

ЗАРПЛАТА.Show

End Sub

Private Sub mnuot4et2_Click()

СОТРУДНИКИ_ДЕТИ.Show

End Sub

Private Sub mnuSotrvof_Click()

frmЗАПРОСсколько.Show

End Sub

Private Sub mnuVipzap_Click()

frmз_ЗАПРОСЫ.Show

End Sub

DataReportFriendExchange.Show

End Sub

Private Sub mnuSongs_Click()

frmGroupAlbumSong.Show

End Sub

Private Sub mnuStructureOfGroup_Click()

frmGroupParticipants.Show

End Sub

2. Форма «Дети»

Private Sub cmdAdd_Click()

Data2.Recordset.AddNew

End Sub

Private Sub cmdDelete_Click()

'this may produce an error if you delete the last

'record or the only record in the recordset

Data2.Recordset.Delete

Data2.Recordset.MoveNext

End Sub

Private Sub cmdRefresh_Click()

'this is really only needed for multi user apps

Data2.Refresh

End Sub

Private Sub cmdUpdate_Click()

Data2.UpdateRecord

Data2.Recordset.Bookmark = Data1.Recordset.LastModified

End Sub

Private Sub cmdClose_Click()

Unload Me

End Sub

Private Sub Data2_Error(DataErr As Integer, Response As Integer)

'This is where you would put error handling code

Продолжение Приложения Б

'If you want to ignore errors, comment out the next line

'If you want to trap them, add code here to handle them

MsgBox "Data error event hit err:" & Error$(DataErr)

Response = 0 'throw away the error

End Sub

Private Sub Data2_Reposition()

Screen.MousePointer = vbDefault

On Error Resume Next

'This will display the current record position

'for dynasets and snapshots

Data2.Caption = "Ребенок: " & (Data2.Recordset.AbsolutePosition + 1)

'for the table object you must set the index property when

'the recordset gets created and use the following line

'Data2.Caption = "Ребенок: " & (Data2.Recordset.RecordCount * (Data2.Recordset.PercentPosition * 0.01)) + 1

End Sub

Private Sub Data2_Validate(Action As Integer, Save As Integer)

'This is where you put validation code

'This event gets called when the following actions occur

Select Case Action

Case vbDataActionMoveFirst

Case vbDataActionMovePrevious

Case vbDataActionMoveNext

Case vbDataActionMoveLast

Case vbDataActionAddNew

Case vbDataActionUpdate

Case vbDataActionDelete

Case vbDataActionFind

Case vbDataActionBookmark

Case vbDataActionClose

End Select

End Sub

Продолжение Приложения Б

End Sub

Private Sub Data1_Validate(Action As Integer, Save As Integer)

'This is where you put validation code

'This event gets called when the following actions occur

Select Case Action

Case vbDataActionMoveFirst

Case vbDataActionMovePrevious

Case vbDataActionMoveNext

Case vbDataActionMoveLast

Case vbDataActionAddNew

Case vbDataActionUpdate

Case vbDataActionDelete

Case vbDataActionFind

Case vbDataActionBookmark

Case vbDataActionClose

Продолжение Приложения Б

End Select

End Sub

3. Форма «Запросы»

Private Sub cmdCreate_Click()

fileN = "C:\POEZDA\" & "ЗАПРОС" & Day(Date) & Month(Data) & Hour(Time) & Minute(Time) & ".txt"

Open fileN For Output As #1

Print #1, "Запрос " & " от " & Str(Date)

Print #1, "______________________________________________________________"

Print #1,

Print #1, txtInquiry.Text

Print #1, "______________________________________________________________"

Data11.Recordset.MoveLast

colCount = Data11.Recordset.Fields.Count

recCount = Data11.Recordset.RecordCount

Data11.Recordset.MoveFirst

For i = 0 To colCount - 1

Print #1, Data11.Recordset.Fields(i).Name; ": ";

Next

Print #1,

For j = 0 To recCount - 1

For i = 0 To colCount - 1

Print #1, Data11.Recordset.Fields(i).Value; " ";

Next

Data11.Recordset.MoveNext

Print #1,

Next

Close #1

End Sub

Private Sub cmdInquiry_Click()

Data11.RecordSource = txtInquiry.Text

Data11.Refresh

End Sub

Private Sub Command1_Click()

Unload Me

End Sub

4. Количество детей у сотрудника

Private Sub cmdClose_Click()

Unload Me

End Sub

Private Sub Data6_Error(DataErr As Integer, Response As Integer)

'This is where you would put error handling code

'If you want to ignore errors, comment out the next line

'If you want to trap them, add code here to handle them

Продолжение Приложения Б

MsgBox "Data error event hit err:" & Error$(DataErr)

Response = 0 'throw away the error

End Sub

Private Sub Data6_Reposition()

Screen.MousePointer = vbDefault

On Error Resume Next

'This will display the current record position

'for dynasets and snapshots

Data6.Caption = "Дети сотрудника: " & (Data6.Recordset.AbsolutePosition + 1)

'for the table object you must set the index property when

'the recordset gets created and use the following line

'Data6.Caption = "Дети сотрудника: " & (Data6.Recordset.RecordCount * (Data6.Recordset.PercentPosition * 0.01)) + 1

End Sub

Private Sub Data6_Validate(Action As Integer, Save As Integer)

'This is where you put validation code

'This event gets called when the following actions occur

Select Case Action

Case vbDataActionMoveFirst

Case vbDataActionMovePrevious

Case vbDataActionMoveNext

Case vbDataActionMoveLast

Case vbDataActionAddNew

Case vbDataActionUpdate

Case vbDataActionDelete

Case vbDataActionFind

Case vbDataActionBookmark

Case vbDataActionClose

End Select

End Sub

5.Все сотрудники женского пола

Private Sub cmdClose_Click()

Unload Me

End Sub

Private Sub Data10_Error(DataErr As Integer, Response As Integer)

'This is where you would put error handling code

'If you want to ignore errors, comment out the next line

'If you want to trap them, add code here to handle them

MsgBox "Data error event hit err:" & Error$(DataErr)

Response = 0 'throw away the error

End Sub

Private Sub Data10_Reposition()

Screen.MousePointer = vbDefault

On Error Resume Next

'This will display the current record position

Продолжение Приложения Б

'for dynasets and snapshots

Data10.Caption = "Сотрудник-женщина: " & (Data10.Recordset.AbsolutePosition + 1)

'for the table object you must set the index property when

'the recordset gets created and use the following line

'Data10.Caption = "Сотрудник-женщина: " & (Data10.Recordset.RecordCount * (Data10.Recordset.PercentPosition * 0.01)) + 1

End Sub

Private Sub Data10_Validate(Action As Integer, Save As Integer)

'This is where you put validation code

'This event gets called when the following actions occur

Select Case Action

Case vbDataActionMoveFirst

Case vbDataActionMovePrevious

Case vbDataActionMoveNext

Case vbDataActionMoveLast

Case vbDataActionAddNew

Case vbDataActionUpdate

Case vbDataActionDelete

Case vbDataActionFind

Case vbDataActionBookmark

Case vbDataActionClose

End Select

End Sub

Размещено на Allbest.ru