Партнерка на США и Канаду по недвижимости, выплаты в крипто

30% recurring commission
Выплаты в USDT
Вывод каждую неделю
Комиссия до 5 лет за каждого referral

Министерство образования и науки Украины

Севастопольский национальный технический университет

Кафедра

Информационных систем

ПОЯСНИТЕЛЬНАЯ ЗАПИСКА

к курсовому проекту по дисциплине «Организация баз данных»

на тему «База данных для отдела кадров УРиЭБ ГАО “Черноморнефтегаз”»

Выполнили:

ст. гр. И-44д

Руководитель проекта:

Севастополь

2005

Содержание

Введение. 3

1 Постановка задачи. 4

2 Проектирование реляционной базы данных. Ошибка! Закладка не определена.

3 Целостность данных. 11

3.1 Список потенциальных пользователей. Ошибка! Закладка не определена.

3.2 Порядок циркуляции информации. 15

3.3 Потоки данных. Ошибка! Закладка не определена.

3.4 Целостность базы данных. Ошибка! Закладка не определена.

3.5 Организация секретности. Ошибка! Закладка не определена.

3.6 Операции модификации. Ошибка! Закладка не определена.

4 Обоснование выбора языка программирования. 20

5 Технические условия применения программы.. 22

6 Структура программного обеспечения. 23

7 Возможности развития. 25

Заключение. Ошибка! Закладка не определена.

Ошибка! Закладка не определена.

Руководство пользователя. Ошибка! Закладка не определена.

Введение

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

НЕ нашли? Не то? Что вы ищете?

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

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

Для реализации поставленной задачи выбрана среда объектно-ориентированного программирования С++ Builder 6.

1 Постановка задачи

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

Курсовое проектирование включает следующие этапы:

I. Процесс проектирования базы данных.

1. Инфологическое проектирование

1.1 Анализ предметной области (ПО).

1.2 Определение информационных потребностей пользователя.

2. Датологическое проектирование

2.1 Проектирование логической БД:

а) построение внешней модели;

б) построение концептуальной модели;

2.2 Проектирование физической БД:

а) построение внутренней модели;

II. Разработка программного обеспечения БД

III. Защита данных:

1. Разграничение доступа

IV. Разработка интерфейса.

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

Предполагаемые этапы проектирования представлены на рисунке 1.1.

ПО+ИПП

Исходные Инфологическое

данные проектирование

----

Проектирование внешней модели

Внутренняя модель

Схема логической БД

Схема физической БД

Рисунок 1.1 – Этапы проектирования базы данных

2 Инфологическое проектирование

2.1 Анализ предметной области

База данных разрабатывается для отдела кадров предприятия УРиЭБ ГАО «Черноморнефтегаз». Данная организация является структурным производственным подразделением государственного акционерного общества «Черноморнефтегаз», которое относится к одному из самых крупных предприятий по нахождению и добыче нефти и газа. Все структурные единицы данной организации предоставляют большое количество рабочих мест. В связи с этим в отделе кадров возникают сложности в работе с большим количеством информации. Именно для того, чтобы облегчить работу сотрудников данного отдела и реализуется данная база данных. Удобный интерфейс позволит обрабатывать и просматривать информацию даже тем работникам, которые имеют опыт работы с ЭВМ на низком уровне.

2.2 Определение информационных потребностей пользователя.

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

5 групп потенциальных пользователей:

- системный администратор;

- начальник отдела кадров;

- работники отдела кадров;

- бухгалтерия;

- прочие работники предприятия.

Необходимая информация:

а) сведения о работниках предприятия (ФИО, паспортные данные, дата рождения, семейное положение и тд.);

б) список приказов с выговорами и благодарностями;

в) список отпусков;

г) вакантные места на различные специальности;

д) структура разделения специальностей на предприятии.

3 Датологическое проектирование

3.1 Проектирование логической базы данных

3.1.1 Построение внешней модели

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

В основу модели положены следующие допущения:

а) один работник может иметь несколько выговоров;

б) один работник может иметь несколько благодарностей;

в) один работник может взять несколько отпусков;

г) за работником закрепляется только одна специальность;

д) несколько работников могут обладать одной специальностью;

е) одна группа включает в себя несколько специальностей;

Имеется общая структура проектируемой базы данных (Рисунок 3.1.1).

Рисунок 3.1.1 – Общая структура БД

Каждое отношение состоит из атрибутов.

1) Работник (Идентификационный код(ID), ФИО, Дата рождения, паспортные данные, семейное положение, количество детей, стаж, дата приема, номер специальности);

2) Специальность (Номер специальности, Название, количество рабочих мест, количество занятых рабочих мест, номер группы);

3) Группы (Номер группы, Название);

4) Отпуска (Порядковый номер, номер приказа, ID, ФИО, количество дней, дата начала, дата окончания);

5) Выговоры (Порядковый номер, номер приказа, ID, ФИО, причина, мера наказания);

6) Благодарности (Порядковый номер, номер приказа, ID, ФИО, причина, мера поощрения).

Для рассмотрения взаимодействия объектов и связей в приложении А представлена ER-диаграмма.

3.1.2 Построение концептуальной модели

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

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

В нашем случае первая нормальная форма будет иметь вид:

Работник (Идентификационный код(ID), ФИО, Дата рождения, паспортные данные, семейное положение, количество детей, стаж, дата приема, номер специальности);

Специальность (Номер специальности, Название, количество рабочих мест, количество занятых рабочих мест, номер группы);

Группы (Номер группы, Название);

Отпуска (Порядковый номер, номер приказа, ID, ФИО, количество дней, дата начала, дата окончания);

Выговоры (Порядковый номер, номер приказа, ID, ФИО, причина, мера наказания);

Благодарности (Порядковый номер, номер приказа, ID, ФИО, причина, мера поощрения).

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

Отношение R находится в 3НФ в том и только в том случае, если находится в 2НФ, и каждый неключевой атрибут не является транзитивно зависимым от какого-либо ключа R. Таблицы базы данных для отдела кадров УРи ЭБ удовлетворяют условию.

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

Целостность данных.

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

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

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

Значение первичных ключей должно быть всегда определено.

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

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

Выделяют три группы правил целостности:

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

2. Целостность по ссылкам. Значение внешнего ключа должно либо:

быть равным значению первичного ключа цели;

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

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

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

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

Номер группы

Название

Группы

Номер специальности

Название

Количество рабочих мест

Количество занятых рабочих мест

Номер группы

Специальность

Работник

Отпуска Выговоры Благодарности

Рисунок 3.1.2 – Реляционная база данных.

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

3.2 Список потенциальных пользователей

Исходя из предметной области, список потенциальных пользователей состоит из 5-ти элементов:

- системный администратор;

- начальник отдела кадров;

- работники отдела кадров;

- бухгалтерия;

- прочие работники предприятия.

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

2. Начальник отдела кадров имеет следующие возможности:

- занесение данных;

- обновление данных;

- вставка записей;

- удаление информации;

- поиск необходимой информации.

3. Работники отдела кадров имеют доступ только к просмотру информации. Вносить коррективы и изменения в таблицы они не могут.

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

5. Остальные работники имеют доступ только к таблице работник и отпуска.

Рисунок 3.2 – Возможная системная организация проекта

3.3 Проектирование физической базы данных

Физическое проектирование базы данных связано с фактической реализацией БД. Оно определяет рациональный выбор структуры хранения данных и методов доступа к ним. Для реализации данной базы данных выбрана стандартная платформа InterBase. Разграничение доступа и интерфейс программы реализованы на языке С++ Builder 6.

3.3.1 Иерархическая структура разграничения доступа между всеми пользователями базы данных

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

Системный администратор

Прочие отделы

Отдел кадров

Начальник отдела кадров

Бухгалтерия Работники отдела кадров

Прочие работники предприятия

Рисунок 3.3.1 - Иерархическая структура разграничения доступа между всеми пользователями базы данных

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

3.3.2 Потоки данных

Структурная схема потоков данных представлена на рисунке 3.3.2

Рисунок 3.3.2 - Структурная схема потоков данных.

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

3.3.3 Информационные расчёты

Длина логической записи j-ого файла байт

байт

Объем памяти, необходимый для размещения информационного фонда

байт

Приращение информационного фонда

байт в год

Время заполнения информационного фонда

лет

Количество обращений к логическим записям в день

при добавлении

при удалении

при просмотре

N=5+3+20=28 обращений

Время резервного копирования

Средний объем данных, предоставляемый пользователю во время выполнения i - ого запроса

байт

3.3.4 Организация секретности

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

Для доступа на тот или иной уровень необходимо выбрать в окне логин и ввести соответствующий пароль. На рисунке 3.3.4.1 представлен окно входа в программу на примере пользователя – системного администратора.

Рисунок 3.3.4.1 – Окно входа в программу на примере пользователя - системного администратора.

Пароли для всех пользователей хранятся в базе в таблице user. Они находятся в незакодированном виде. Таблица user изображена на рисунке 3.3.4.2.

Рисунок 3.3.4.2 – таблица user.

3.3.5 Определение необходимых операций, выполняемых над базой.

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

4 Обоснование выбора языка программирования

Система объектно-ориентированного программирования C++ Builder 6 производства корпорации Borland предназначена для операционных систем Windows 98, Windows 2000 и более поздних версий Windows. Интегрированная среда C++ Builder 6 обеспечивает высокую скорость визуальной разработки, продуктивность повторно используемых компонент в сочетании с мощью языковых средств C++, усовершенствованными инструментами и разномасштабными средствами доступа к базам данных.

C++ Builder 6 обеспечивает высокое быстродействии при компиляции и сборке 32 - разрядных приложений для современных операционных систем Windows, включая OLE взаимодействие клиент-сервер. Результирующие программы хорошо оптимизированы по скорости исполнения и затратам памяти.

C++ Builder 6 имеет стандартный набор инструментов(компонентов) для соединения с базой и работы с ней:

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

- компонент Interbase.

- компонет Mysql.

Так имеет возможность работать с разными языками, файлами и базами:

Как и перечисленные выше, так и

BCDEMOS,

dBASE Files,

DBDEMOS,

Excel Files,

dBASE,

Базы данных MS Access,

MS Access Database,

Файлы Excel,

BenchAccess91;

Система объектно-ориентированного программирования C++ Buider 6 является мощным и производительным средством для создания баз данных и обеспечивает высокую скорость визуальной разработки приложений информационных систем, избавляя разработчика от лишних затрат рабочего времени.

5 Технические условия применения программы

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

- ЭВМ типа IBM PC;

- наличие 25 Мбайт свободного места на жестком диске;

- процессор – Pentium 333;

- оперативная память – 32 Мбайт;

- операционная система – Windows 98

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

6 Структура программного обеспечения

Системная структура программы отображает взаимодействие окон (иерархию окон) программы. Системная структура программы представлена на рисунке 6.1.

Рисунок 6.1 - Системная структура программы

Клиентская часть состоит из 3-х модулей:

Unit1:

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

Unit2:

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

Unit3:

Третий модуль реализует непосредственную связь со стандартной платформой InterBase, а также возможность реализовывать запросы на SQL.

Unit4:

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

Unit5:

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

Unit6:

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

Текст программы приведён в приложении Б.

Интерфейс пользователя приведен в приложении В.

7 Возможности развития

В дальнейшем данный проект можно развить до применения его ко всему ГАО «Черноморнефтегаз», т. е. сделать универсальную базу данных для всех структурных единиц организации. Для этого необходимо реализовать систему клиент-сервер, а также осуществить доступ в Internet. Возникнут новые классы пользователей с правами доступа, отличающимися от имеющихся. Поэтому в модификацию программного обеспечения войдет реализация назначения прав доступа новым группам пользователей. Возможно также будет применить кодирование информации для лучшего сохранения конфиденциальной информации, поскольку для возможного более высокого уровня развития данной базы данных необходима улучшенная система защиты данных от несанкционированного доступа, и присекание утечки информации за пределы организации.

Заключение

В данном курсовом проекте была разработана база данных для отдела кадров УРиЭБ ГАО «Черноморнефтегаз». Это реализовалось путем поэтапного проектирования логической и физической моделей и непосредственной реализацией при помощи стандартной платформы InterBase. Для реализации эргономичного интерфейса был выбран язык C++ Buider 6.

Библиографический список

1. Мартин Дж. Организация баз данных в вычислительных системах. – М.: Мир, 1978. – 615с.

2. Ульман Дж. Основы систем баз данных. – М.: Финансы и статистика, 1983. – 334с.

3. Карпова данных. - СПб.: Питер,2002.-304с.:ил.

Текст программы.

Unit1.cpp

#include <vcl. h>

#pragma hdrstop

#include "Unit1.h"

#include "Unit2.h"

#include "Unit3.h"

#include "Unit4.h"

#include "Unit5.h"

#include "Unit6.h"

#include <StrUtils. hpp>

//#pragm package(smart_init)

#pragma resource "*.dfm"

TForm1 *Form1;

__fastcall TForm1::TForm1(TComponent* Owner)

: TForm(Owner)

{

el=5;

}

void __fastcall TForm1::PageControl1Change(TObject *Sender)

{

switch(PageControl1->ActivePageIndex)

{

case 0:{curr=ds_otpysk;break;};

case 1:{curr=ds_blag;break;};

case 2:{curr=ds_vugovor;break;};

}

dbnav->DataSource=curr;

RefreshEl(this);

}

void __fastcall TForm1::otpyskAfterPost(TDataSet *DataSet)

{

dbnav->DataSource->DataSet->Refresh();

}

void __fastcall TForm1::FormCreate(TObject *Sender)

{

TfrmLogin *frm;

frm=new TfrmLogin(this);

AnsiString name;

if (frm->Execute(&name))

{

//ShowMessage(sec. el[0]+" " +sec. right[0]);

}

else Application->Terminate();

pagecontrol->ActivePageIndex=sec. tabn;

curr=ds_otpysk;

dbnav->DataSource=curr;

PageControl1->ActivePageIndex=0;

RefreshEl(this);

}

void __fastcall TForm1::N4Click(TObject *Sender)

{

Form2->ShowModal();

}

void __fastcall TForm1::SQL1Click(TObject *Sender)

{

Form3->ShowModal();

}

void TForm1::RefreshEl(TObject *Sender)

{

for (int i=0;i<Form1->ComponentCount;i++)

{

if (String(Form1->Components[i]->ClassName())=="TIBTable")

{

for (int j=0;j<=el;j++)

if (sec. el[j]==Form1->Components[i]->Name)

if (sec. right[j]=="r")

{

TIBTable *t;

t=(TIBTable*)Form1->Components[i];

t->Active=false;

t->ReadOnly=true;

t->Active=true;

}

else if (sec. right[j]=="h")

{

TIBTable *t;

t=(TIBTable*)Form1->Components[i];

t->Active=false;

}

else if (String(Form1->Components[i]->ClassName())=="TDBNavigator")

{

TDBNavigator *t;

t=(TDBNavigator*)Form1->Components[i];

for (int j=0;j<=el;j++)

if (AnsiContainsText(t->DataSource->Name, sec. el[j]))

if (sec. right[j]=="r")

t->Visible=true;

else if (sec. right[j]=="h")

t->Visible=false;

}

this->Refresh();

}

void __fastcall TForm1::Button1Click(TObject *Sender)

{

TfrmQuery *frm;

frm=new TfrmQuery(this);

AnsiString sql;

sql="SELECT \"RAB\".\"FIO\",\"RAB\".\"data_priem\",\"RAB\".\"data_rozhd\",\"SPECIALNOST\".\"NAZV\" FROM \"RAB\",\"SPECIALNOST\" WHERE \"RAB\".\"N_SPEC\"=\"SPECIALNOST\".\"N_SPEC\"";

frm->Execute(sql);

}

void __fastcall TForm1::pagecontrolChanging(TObject *Sender,

bool &AllowChange)

{

AllowChange=false;

}

void __fastcall TForm1::Button2Click(TObject *Sender)

{

TfrmQuery *frm;

frm=new TfrmQuery(this);

AnsiString sql;

sql="SELECT * from \"OTPYSK\"";

frm->Execute(sql);

}

void __fastcall TForm1::Button3Click(TObject *Sender)

{

TfrmQuery *frm;

frm=new TfrmQuery(this);

AnsiString sql;

sql="select \"RAB\".\"FIO\",\"VUGOVOR\".* FROM \"VUGOVOR\",\"RAB\" WHERE \"RAB\".\"ID\"=\"VUGOVOR\".\"ID\"";

frm->Execute(sql);

}

void __fastcall TForm1::Button4Click(TObject *Sender)

{

TfrmQuery *frm;

frm=new TfrmQuery(this);

AnsiString sql;

sql="select \"RAB\".\"FIO\",\"BLAG\".* FROM \"BLAG\",\"RAB\" WHERE \"RAB\".\"ID\"=\"BLAG\".\"ID\"";

frm->Execute(sql);

}

void __fastcall TForm1::Button5Click(TObject *Sender)

{

TfrmQuery *frm;

frm=new TfrmQuery(this);

AnsiString sql;

sql="SELECT * from \"OTPYSK\"";

frm->Execute(sql);

}

void __fastcall TForm1::Button7Click(TObject *Sender)

{

TfrmQuery *frm;

frm=new TfrmQuery(this);

AnsiString sql;

sql="SELECT * from \"OTPYSK\"";

frm->Execute(sql);

}

void __fastcall TForm1::Button8Click(TObject *Sender)

{

TfrmQuery *frm;

frm=new TfrmQuery(this);

AnsiString sql;

sql="select \"RAB\".\"FIO\",\"BLAG\".* FROM \"BLAG\",\"RAB\" WHERE \"RAB\".\"ID\"=\"BLAG\".\"ID\"";

frm->Execute(sql);

}

void __fastcall TForm1::BitBtn1Click(TObject *Sender)

{

frmReport->QuickRep1->Preview();

}

void __fastcall TForm1::N2Click(TObject *Sender)

{

Application->Terminate();

}

Unit2.cpp

#ifndef Unit2H

#define Unit2H

#include <Classes. hpp>

#include <Controls. hpp>

#include <StdCtrls. hpp>

#include <Forms. hpp>

#include <ComCtrls. hpp>

#include <DB. hpp>

#include <DBCtrls. hpp>

#include <DBGrids. hpp>

#include <ExtCtrls. hpp>

#include <Grids. hpp>

#include <IBCustomDataSet. hpp>

#include <IBTable. hpp>

class TForm2 : public TForm

{

__published: // IDE-managed Components

TPageControl *PageControl1;

TTabSheet *TabSheet1;

TDBGrid *DBGrid1;

TTabSheet *TabSheet3;

TDBGrid *DBGrid2;

TPanel *Panel1;

TDBNavigator *dbnav;

TIBTable *specialnost;

TIBTable *gruppu;

TDataSource *ds_specialnost;

TDataSource *ds_gruppu;

TIntegerField *specialnostN_SPEC;

TIBStringField *specialnostNAZV;

TIntegerField *specialnostRAB_MEST;

TIntegerField *specialnostZANRAB_MEST;

TIntegerField *specialnostN_GR;

TPanel *Panel2;

TDBLookupComboBox *DBLookupComboBox1;

TIntegerField *gruppuN_GR;

TIBStringField *gruppuNAME;

TLabel *Label1;

void __fastcall PageControl1Change(TObject *Sender);

void __fastcall FormCreate(TObject *Sender);

void __fastcall specialnostAfterPost(TDataSet *DataSet);

void __fastcall PageControl1Changing(TObject *Sender,

bool &AllowChange);

private: // User declarations

struct access

{

AnsiString el[6];

AnsiString right[6];

int tabn;

};

public: // User declarations

__fastcall TForm2(TComponent* Owner);

TDataSource *curr;

int el;

void RefreshEl(TObject *Sender);

};

extern PACKAGE TForm2 *Form2;

#endif

Unit3.cpp

#ifndef Unit3H

#define Unit3H

#include <Classes. hpp>

#include <Controls. hpp>

#include <StdCtrls. hpp>

#include <Forms. hpp>

#include <DB. hpp>

#include <DBGrids. hpp>

#include <ExtCtrls. hpp>

#include <Grids. hpp>

#include <IBCustomDataSet. hpp>

class TForm3 : public TForm

{

__published: // IDE-managed Components

TMemo *txtSql;

TPanel *Panel2;

TButton *Button1;

TGroupBox *GroupBox1;

TDBGrid *DBGrid1;

TIBDataSet *sql;

TDataSource *ds_sql;

void __fastcall Button1Click(TObject *Sender);

private: // User declarations

public: // User declarations

__fastcall TForm3(TComponent* Owner);

};

extern PACKAGE TForm3 *Form3;

#endif

Unit4.cpp

#ifndef Unit4H

#define Unit4H

#include <vcl\System. hpp>

#include <vcl\Windows. hpp>

#include <vcl\SysUtils. hpp>

#include <vcl\Classes. hpp>

#include <vcl\Graphics. hpp>

#include <vcl\StdCtrls. hpp>

#include <vcl\Forms. hpp>

#include <vcl\Controls. hpp>

#include <vcl\Buttons. hpp>

#include <vcl\ExtCtrls. hpp>

class TfrmLogin : public TForm

{

__published:

TBevel *Bevel1;

TLabel *Label1;

TComboBox *list;

TEdit *txtPass;

TLabel *Label2;

TButton *OKBtn;

TButton *CancelBtn;

private:

public:

virtual __fastcall TfrmLogin(TComponent* AOwner);

bool Execute(AnsiString *type);

};

extern PACKAGE TfrmLogin *frmLogin;

#endif

Unit5.cpp

#ifndef Unit5H

#define Unit5H

#include <vcl\System. hpp>

#include <vcl\Windows. hpp>

#include <vcl\SysUtils. hpp>

#include <vcl\Classes. hpp>

#include <vcl\Graphics. hpp>

#include <vcl\StdCtrls. hpp>

#include <vcl\Forms. hpp>

#include <vcl\Controls. hpp>

#include <vcl\Buttons. hpp>

#include <vcl\ExtCtrls. hpp>

#include <DBGrids. hpp>

#include <Grids. hpp>

#include <DB. hpp>

#include <IBCustomDataSet. hpp>

class TfrmQuery : public TForm

{

__published:

TButton *OKBtn;

TButton *CancelBtn;

TDBGrid *DBGrid1;

TIBDataSet *query;

TDataSource *ds_query;

private:

public:

virtual __fastcall TfrmQuery(TComponent* AOwner);

bool Execute(AnsiString strSql);

};

extern PACKAGE TfrmQuery *frmQuery;

#endif

Unit6.cpp

#ifndef Unit6H

#define Unit6H

#include <Classes. hpp>

#include <Controls. hpp>

#include <StdCtrls. hpp>

#include <Forms. hpp>

#include <ExtCtrls. hpp>

#include <QuickRpt. hpp>

#include <QRCtrls. hpp>

class TfrmReport : public TForm

{

__published: // IDE-managed Components

TQuickRep *QuickRep1;

TQRBand *QRBand1;

TQRLabel *QRLabel1;

TQRDBText *QRDBText1;

TQRDBText *QRDBText3;

TQRLabel *QRLabel2;

TQRSubDetail *QRSubDetail1;

TQRDBText *QRDBText2;

TQRBand *QRBand2;

TQRSubDetail *QRSubDetail2;

TQRLabel *QRLabel3;

TQRDBText *QRDBText4;

TQRDBText *QRDBText5;

TQRDBText *QRDBText6;

private: // User declarations

public: // User declarations

__fastcall TfrmReport(TComponent* Owner);

};

extern PACKAGE TfrmReport *frmReport;

#endif

Интерфейс пользователя.

Шаг 1. Авторизация программы. Служит для определения доступа пользователя к базе данных. Существует пять видов пользователей, для каждого из которых определен свой пароль:

· системный администратор;

· начальник отдела кадров;

· работники отдела кадров;

· бухгалтерия;

· прочие работники предприятия.

1 – Окно авторизации программы

Шаг 2. Работа с самой БД

Назначение различных компонентов основной формы программы изображены на рисунке Б.2.

2 – Основная форма программы

Шаг 3. Выполнение быстрых запросов. На рисунке Б.3 представлен пример выполнения быстрого запроса – выдача списка сотрудников предприятия.

3 – Быстрый запрос.

Шаг 4. Просмотр справочной информации.

Шаг 4.1 Просмотр вакантных мест на различных специальностях. Просмотр принадлежности специальности к определенному структурному подразделению. На рисунке Б.4 представлено окно справочника.