Курсовая работа: Разработка программного обеспечения по управлению базой данных "График учета рабочего времени на шахте"

*;;;;;o;;;;;;o;;;;;;o;;;;;.;;.;;.;;.;;.;;.;;.;;.;;.;;;.;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;.;;.;;.;;.;;.;;.;;.;;.;;;;;o;;;;;;o;;;;;;o;;;;;.;;;;;;;;;;;;;;;;;;;.;;;;;;;;;;;;;;;;;;;.;;.;;.;;.;;.;;.;;.;;.;;.;;;.;;;;;;;;;;;;;;;;;;;.;;.;;.;;.;;.;;.;;.;;.;;.;;;.;;.;;.;;.;;.;;.;;.;;.;;.;;;.;;.;;.;;.;;.;;.;;.;;.;;.;;;.;;.;;.;;.;;.;;.;;.;;.;;.;;;.;;.;;.;;.;;.;;.;;.;;.;;.;;;.;;.;;.;;.;;.;;.;;.;;.;;.;;;.;;;;;;;;;;;;;;;;;;;.;;.;;.;;.;;.;;.;;.;;.;;.;;;;;o;;;;;;o;;;;;;o;;;;;;;.;;.;;.;;.;;.;;.;;.;;.;;;.;;.;;.;;.;;.;;.;;.;;.;;.;;;.;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;.;;.;;.;;.;;.;;.;;.;;.;;.;;;.;;.;;.;;.;;.;;.;;.;;.;;.;;;;;o;;;;;;;;;;;;;;;;;Министерство образования и науки

Республики Казахстан

Карагандинский государственный технический университет

КУРСОВАЯ РАБОТА

по дисциплине Разработка баз данных

Тема: Разработка программного обеспечения по управлению базой данных «График учета рабочего времени на шахте им. Т. Кузембаева

2009

Содержание

Введение

Задание

1. Выбор СУБД

2. Концептуальная модель

3. Логическая модель данных

4. Нормализация отношений

5. Основная часть

6. SQL – запросы

7. Интерфейс программы

8. Отчеты

Заключение

Список используемых источников

Введение

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

обеспечивать получение общих и/или детализированных отчетов по итогам работы;

позволять легко определять тенденции изменения важнейших показателей;

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

выполнять точный и полный анализ данных.

Современные СУБД в основном являются приложениями Windows, так как данная среда позволяет более полно использовать возможности персональной ЭВМ, нежели среда DOS. Снижение стоимости высокопроизводительных ПК обусловил не только широкий переход к среде Windows, где разработчик программного обеспечения может в меньше степени заботиться о распределении ресурсов, но также сделал программное обеспечение ПК в целом и СУБД в частности менее критичными к аппаратным ресурсам ЭВМ.

Среди наиболее ярких представителей систем управления базами данных можно отметить: Lotus Approach, Microsoft Access, Borland dBase, Borland Paradox, Microsoft Visual FoxPro, Microsoft Visual Basic, а также баз данных Microsoft SQL Server и Oracle, используемые в приложениях, построенных по технологии «клиент-сервер». Фактически, у любой современной СУБД существует аналог, выпускаемый другой компанией, имеющий аналогичную область применения и возможности, любое приложение способно работать со многими форматами представления данных, осуществлять экспорт и импорт данных благодаря наличию большого числа конвертеров. Общепринятыми, также, являются технологи, позволяющие использовать возможности других приложений, например, текстовых процессоров, пакетов построения графиков и т.п., и встроенные версии языков высокого уровня (чаще – диалекты SQL и/или VBA) и средства визуального программирования интерфейсов разрабатываемых приложений. Поэтому уже не имеет существенного значения, на каком языке и на основе какого пакета написано конкретное приложение, и какой формат данных в нем используется. Более того, стандартом «де-факто» стала «быстрая разработка приложений» или RAD (от английского Rapid Application Development), основанная на широко декларируемом в литературе «открытом подходе», то есть необходимость и возможность использования различных прикладных программ и технологий для разработки более гибких и мощных систем обработки данных. Поэтому в одном ряду с «классическими» СУБД все чаще упоминаются языки программирования Visual Basic 4.0 и Visual C++, которые позволяют быстро создавать необходимые компоненты приложений, критичные по скорости работы, которые трудно, а иногда невозможно разработать средствами «классических» СУБД. Современный подход к управлению базами данных подразумевает также широкое использование технологии «клиент-сервер».

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

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

Задание

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

Программный продукт должен:

Хранить информацию о рабочих цеха.

Хранить информацию о государственных праздниках

Сохранять и загружать сгенерированные графики

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

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

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

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

Выходить на работу в выходной день в первую смену могут только рабочие, имеющие статус «Вентиляторщик, работающий в выходные»

Дежурить (ходить не в первую смену) могут только рабочие, имеющие статус «Дежурный»

Остальные рабочие выходят только в первую смену по будним и не праздничным дням

Выделить визуально рабочих со статусом статус «Вентиляторщик, работающий в выходные» и «Вентиляторщик, не работающий в выходные»

Каждый день в каждую смену должен выходить хотя бы один рабочий

Желательное максимальное количество рабочих дней без выходных – 5

После четвертой смены нельзя выходить сразу в первую

Одному рабочему нежелательно дежурить только в третью и четвертую смены (т.к. выход в эти смены более высоко оплачивается). Необходимо распределить такие дежурства более равномерно

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

После четвертой смены желательно предусмотреть два выходных

1. Выбор СУБД

Разработка проекта проводится в Borland Delphi. В качестве СУБД был выбран MS Access как пакет MS Office, который в настоящее время сильно распространен на территории нашего государства. В связи с тем что приложение разрабатывается для нужд стороннего лица, то целесообразно применять MS Access в качестве СУБД, что несомненно облегчит понимание приложения пользователем. Данный выбор позволит избежать проблем, которые бы возникли при развертывании MS SQL сервера. MS SQL требует администрирования (нужно выполнять какие то административные действия, типа резервного копирования и т. п., когда для Access нужно просто скопировать файл), которое на предприятии не будет проводиться, и сервер оно на много тяжелее в использовании, для обычных пользователей.

Для работы с базами данных в Delphi есть несколько наборов компонентов. Так как Microsoft встроила в свои продукты разработки технологию доступа к данным ADO (Active Data Objects), для реализации настоящего приложения используются компоненты с закладки ADO. Работа с базами данных Access идет через специальную надстройку DAO, которая устанавливается на компьютер вместе с Office, либо как отдельная установка. Для доступа к базам данных MS Access используется ADO драйвер «Microsoft Jet 4.0 OLE DB Provider».

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

К областям применения Microsoft Access можно отнести следующие:

в малом бизнесе (бухгалтерский учет, ввод заказов, ведение информации о клиентах, ведение информации о деловых контактах);

в работе по контракту (разработка внутриотраслевых приложений, разработка межотраслевых приложений);

в крупных корпорациях (приложения для рабочих групп, системы обработки информации);

в качестве персональной СУБД (справочник по адресам, ведение инвестиционного портфеля, поваренная книга, каталоги книг, пластинок, видеофильмов и т. п.).

Рассмотрим основные определения, связанные с разработкой баз данных. Краткий словарь терминов приведен в приложении 1.

База данных (БД, data base, DB) – совокупность взаимосвязанных данных, используемых под управлением СУБД.

В самом общем смысле база данных – это набор записей и файлов, организованных специальным образом.

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

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

Основные функции СУБД следующие:

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

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

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

2. Концептуальная модель

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

Концептуальная модель (англ. conceptual model) — это определённое множество понятий и связей между ними, являющихся смысловой структурой рассматриваемой предметной области.

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

3. Логическая модель

Логическая модель данных отражает логические связи между сущностями базы данных. Ниже представлена логическая модель базы данных «График учета рабочего времени на шахте им. Т. Кузембаева в цехе «Автоматика» ».

Информацию о рабочих цеха содержит таблица «Рабочие», содержащая следующие атрибуты:

«ID» - уникальный идентификатор рабочего, выполняющий роль первичного ключа (счетчик);

«WokerName» - ФИО рабочего (текстовый);

«TabNumber» - табельный номар рабочего (числовой)

«LinkProfession» - код профессии рабочего (числовой), является вторичным ключом поля «ID» таблицы «Профессия»;

«LinkStatus» - код статуса рабочего (числовой), является вторичным ключом поля «ID» таблицы «Статус»;

Информацию о профессии рабочего хранится в таблице «Профессия», содержащая следующие атрибуты:

«ID» - уникальный идентификатор профессии, выполняющий роль первичного ключа (счетчик);

«NameProfession» - название профессии (текстовый);

Информацию о статусе рабочего хранится в таблице «Статус», содержащая следующие атрибуты:

«ID» - уникальный идентификатор статуса, выполняющий роль первичного ключа (счетчик);

«NameStatus» - название статуса (текстовый);

Информацию об отпусках рабочих содержит таблица «Отпуски», содержащая следующие атрибуты:

«ID» - уникальный идентификатор рабочего, выполняющий роль первичного ключа (счетчик);

«LinkWoker» - код ФИО рабочего (числовой), является вторичным ключом поля «ID» таблицы «Рабочие»;

«DateBegin» - дата начала отпуска (дата/время)

«Length» - продолжительность отпуска (числовой);

Информацию о сохраненных графиках содержит таблица «Сохраненные_ графики», содержащая следующие атрибуты:

«ID» - уникальный идентификатор сохранения, выполняющий роль первичного ключа (счетчик);

«NameGraphic» - название сохраненного графика (текстовый);

«DateOfSave» - дата сохранения графика (дата/время);

«LinkMonthNum» - код месяца сохраненного графика (числовой), является вторичным ключом поля «ID» таблицы «Месяцы»;

«YearNum» - год сохраненного графика (числовой);

Информацию о графиках содержит таблица «Графики», содержащая следующие атрибуты:

«ID» - уникальный идентификатор графика, выполняющий роль первичного ключа (счетчик);

«LinkSaveID» - код номера сохранения графика (числовой), является вторичным ключом поля «ID» таблицы «Сохраненные графики»;

«DateOfCell» - дата ячейки (дата/время);

«LinkWoker» - код ФИО рабочего (числовой), является вторичным ключом поля «ID» таблицы «Рабочие»;

«LinkTypeOfDay» - код типа дня (числовой), является вторичным ключом поля «ID» таблицы «Типы_дней»;

Информацию о месяце сохраненного графика хранится в таблице «Месяцы», содержащая следующие атрибуты:

«ID» - уникальный идентификатор месяца, выполняющий роль первичного ключа (счетчик);

«MonthName» - название месяца (текстовый);

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

«ID» - уникальный идентификатор выходного дня, выполняющий роль первичного ключа (счетчик);

«DateCelebrate» - дата выходного дня (дата/время);

«LinkName» - код названия выходного дня в связи с праздником (числовой), является вторичным ключом поля «ID» таблицы «Праздники»;

Информацию названии государственных праздниках хранится в таблице «Праздники», содержащая следующие атрибуты:

«ID» - уникальный идентификатор праздника, выполняющий роль первичного ключа (счетчик);

«Title» - название государственного праздника (текстовый);

Наглядно связь между таблицами изображена на Рисунке 3.1

Разработка программного обеспечения по управлению базой данных "График учета рабочего времени на шахте"

Рисунок 3.1 – Связи между таблицами БД «График учета рабочего времени на шахте им. Т. Кузембаева в цехе «Автоматика» »

4. Нормализация отношений

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

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

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

Таблица содержит нуль или более записей.

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

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

Обычно выделяют шесть нормальных форм:

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

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

Третья нормальная форма (3NF). Таблица находится в третьей нормальной форме, если она находится во второй нормальной форме, и при этом любой её неключевой атрибут функционально зависит только от первичного ключа.

Нормальная форма Бойса-Кодда (BCNF)Таблица находится в BCNF, если она находится в третьей нормальной форме, и при этом отсутствуют функциональные зависимости атрибутов первичного ключа от неключевых атрибутов. Данная нормальная форма — это модификация третьей нормальной формы. Таблица может находиться в 3NF, но не в BCNF, только в одном случае: если она имеет, помимо первичного ключа, ещё по крайней мере один составной возможный ключ, и по крайней мере один из атрибутов таблицы входит и в первичный, и в возможный ключи. Такое бывает достаточно редко, в остальном 3NF и BCNF эквивалентны.

Четвёртая нормальная форма (4NF).Таблица находится в 4NF, если она находится в BCNF и не содержит нетривиальных многозначных зависимостей. Многозначная зависимость не является функциональной, она существует в том случае, когда из факта, что в таблице содержится некоторая строка X, следует, что в таблице обязательно существует некоторая определённая строка Y.

Пятая нормальная форма (5NF).Таблица находится в 5NF, если она находится в 4NF и любая многозначная зависимость соединения в ней является тривиальной.

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

Сущность «Сохраненные_графики» имеет следующие атрибуты:

ID, NameGraphic, DateOfSave, LinkMonthNum, YearNum.

Сущность «Рабочие» имеет следующие атрибуты: ID, WokerName, TabNumber, LinkProfession, LinkStatus.

Сущность «Выходные» имеет атрибуты: ID, DateCelebrate, LinkName.

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

5. Основная часть

Разработка программного обеспечения по управлению базой данных "График учета рабочего времени на шахте"

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

6.SQL запросы

Для базы данных «График учета рабочего времени на шахте им. Т. Кузембаева в цехе «Автоматика» » выполнены следующие запросы:

Подсчет количества записей в таблице

Function SQL_CountRows(table:string;Connection:TADOConnection):integer;

var

str:_Recordset;

request:string;

begin

request := 'SELECT COUNT(ID) FROM ' + table;

STR := Connection.Execute(request);

result := integer(str.Fields.Item[0].Value);

end;

где table – передаваемый в функцию параметр – название таблицы;

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

request := 'SELECT LinkWoker, DateBegin, Length FROM ОТПУСКИ';

STR := ADOConnection1.Execute(request);

Получение значений атрибутов из таблицы «Рабочие», для заполнения массива, хранящего эти значения для последующих вычислений

request := 'SELECT WokerName, LinkStatus, TabNumber FROM РАБОЧИЕ';

STR := ADOConnection1.Execute(request);

Пометка выходных дней в массиве дней месяца из таблицы, в которой хранятся данные о выходных днях «Выходные».

with sql_CreateQuery(ADOConnection1) do begin

SQL.Text := 'SELECT DateCelebrate FROM Выходные WHERE DateCelebrate BETWEEN :Date1 and :Date2';

with Parameters do begin

ParseSQL(SQL.Text, true);

ParamValues['Date1'] := Date1;

ParamValues['Date2'] := Date2;

end;

Open;

while not(EOF) do begin

MonthInfo[DayOfTheMonth(TDateTime(FieldValues['DateCelebrate']))] := DayCelebrate;

next;

end;

Close;

Free;

end;

Сохранение названия сохраненного графика, даты сохранения в таблицу «Сохраненные_графики».

procedure SaveToSavedGraphic(NameBD:string; DateOfSave:TDateTime; MonthNum, YearNum:integer);

begin

with sql_CreateQuery(ADOConnection1) do begin

SQL.Text := 'INSERT INTO Сохраненные_графики (NameGraphic, DateOfSave, LinkMonthNum, YearNum) VALUES(:p1, :p2, :p3, :p4)';

with parameters do begin

ParseSQL(SQL.Text, true);

ParamValues['p1'] := NameBD;

ParamValues['p2'] := DateOfSave;

ParamValues['p3'] := MonthNum;

ParamValues['p4'] := YearNum;

end;

ExecSQL();

Close;

Free;

end;

Процедура сохранения самого графика в таблицу «Графики», с указанием ID сохранения в таблице «Сохраненные_графики».

procedure SaveToGraphic(IDNum, LinkWoker, LinkTypeOfDay:integer; DateOfCell:TDateTime);

begin

with sql_CreateQuery(ADOConnection1) do begin

SQL.Text := 'INSERT INTO Графики (LinkSaveId, LinkWoker, LinkTypeOfDay, DateOfCell) VALUES(:p1, :p2, :p3, :p4)';

with parameters do begin

ParseSQL(SQL.Text, true);

ParamValues['p1'] := IDNum;

ParamValues['p2'] := LinkWoker + 1;

ParamValues['p3'] := LinkTypeOfDay;

ParamValues['p4'] := DateOfCell;

end;

ExecSQL();

Close;

Free;

end;

Получение ID последней добавленной в таблицу строки.

function GetLastID(conn:TADOConnection):integer;

begin

result := 0;

with sql_CreateQuery(conn) do begin

SQL.Text := 'SELECT @@IDENTITY';

Open();

if Not (eof) then begin

result := Fields.Fields[0].Value;

end;

Close();

Free;

end;

request := 'CREATE TABLE Профессия ' + '( ' +

ID IDENTITY (1, 1) CONSTRAINT PK_Profession_ID PRIMARY KEY, '+

nameProfession CHAR(255) NOT NULL UNIQUE '+ ')';

Conn.Execute(request);

request := 'CREATE TABLE Статус ' + '( ' +

' ID IDENTITY (1, 1) CONSTRAINT PK_Profession_ID PRIMARY KEY, ' +

nameStatus CHAR(255) NOT NULL UNIQUE '+ ')';

Conn.Execute(request);

request := 'CREATE TABLE Рабочие ' +'( ' +

' ID IDENTITY (1, 1) CONSTRAINT PK_Woker_ID PRIMARY KEY, ' +

' WokerName CHAR(128) NOT NULL , ' +

' TabNumber INTEGER , ' +

' LinkProfession INTEGER not null CONSTRAINT LINK_Profession_ID ' +

' REFERENCES Профессия(ID) , ' +

' LinkStatus INTEGER not null CONSTRAINT LINK_Status_ID ' +

' REFERENCES Статус(ID)' + ')';

Conn.Execute(request);

request := 'CREATE TABLE Отпуски ' + '( ' +

' ID IDENTITY (1, 1) CONSTRAINT PK_Holidays_ID PRIMARY KEY , ' +

' LinkWoker INTEGER not null CONSTRAINT LINK_Woker_ID ' +

' REFERENCES Рабочие(ID) , ' +

' DateBegin Date , ' +

' Length INTEGER ' + ')';

Conn.Execute(request);

request := 'CREATE TABLE Типы_дней ' + '( ' +

' ID INTEGER UNIQUE, ' +

' NameOfType CHAR(128) ' + ')';

Conn.Execute(request);

request := 'CREATE TABLE Месяцы ' + '( ' +

' ID INTEGER UNIQUE, ' +

' MonthName CHAR(128) ' + ')';

Conn.Execute(request);

request := 'CREATE TABLE Сохраненные_графики ' + '( ' +

' ID IDENTITY (1, 1) CONSTRAINT PK_SavedGraphic_ID PRIMARY KEY , ' +

' NameGraphic CHAR(128) , ' +

' DateOfSave DATE , ' +

' LinkMonthNum INTEGER not null CONSTRAINT LINK_Month_ID ' +

' REFERENCES Месяцы(ID) , ' +

' YearNum CHAR(128) ' + ')';

Conn.Execute(request);

request := 'CREATE TABLE Графики ' + '( ' +

' ID IDENTITY (1, 1) CONSTRAINT PK_Graphic_ID PRIMARY KEY, ' +

' LinkSaveID INTEGER not null CONSTRAINT LINK_SavedGraphics_ID ' +

' REFERENCES Сохраненные_графики(ID) , ' +

' DateOfCell DATE , ' +

' LinkWoker INTEGER not null CONSTRAINT LINK_Woker_IDN ' +

' REFERENCES Рабочие(ID) , ' +

' LinkTypeOfDay INTEGER not null CONSTRAINT LINK_TypeOfDay_ID ' +

' REFERENCES Типы_дней(ID) ' + ')';

Conn.Execute(request);

request := 'CREATE TABLE Праздники ' + '( ' +

' ID IDENTITY (1, 1) CONSTRAINT PK_Celebrate_ID PRIMARY KEY , ' +

' Title CHAR(128) ' + ')';

Conn.Execute(request);

request := 'CREATE TABLE Выходные ' + '( ' +

' ID IDENTITY (1, 1) CONSTRAINT PK_DateCelebrate_ID PRIMARY KEY , ' +

' DateCelebrate DATE , ' +

' LinkName INTEGER not null CONSTRAINT LINK_HOL_ID' +

' REFERENCES Праздники(ID) ' + ')';

Conn.Execute(request);

//---------------------------------Заполнение полей значениями------------------

request := 'INSERT INTO Месяцы(ID, MonthName)'+

' VALUES (0, ''Январь '')';

Conn.Execute(request);

request := 'INSERT INTO Месяцы(ID, MonthName)'+

' VALUES (1, ''Февраль '')';

Conn.Execute(request);

request := 'INSERT INTO Месяцы(ID, MonthName)'+

' VALUES (2, ''Март '')' ;

Conn.Execute(request);

request := 'INSERT INTO Месяцы(ID, MonthName)'+

' VALUES (3, ''Апрель '')';

Conn.Execute(request);

request := 'INSERT INTO Месяцы(ID, MonthName)'+

' VALUES (4, ''Май '')';

Conn.Execute(request);

request := 'INSERT INTO Месяцы(ID, MonthName)'+

' VALUES (5, ''Июнь '')';

Conn.Execute(request);

request := 'INSERT INTO Месяцы(ID, MonthName)'+

' VALUES (6, ''Июль '')';

Conn.Execute(request);

request := 'INSERT INTO Месяцы(ID, MonthName)'+

' VALUES (7, ''Август '')';

Conn.Execute(request);

request := 'INSERT INTO Месяцы(ID, MonthName)'+

' VALUES (8, ''Сентябрь '')';

Conn.Execute(request);

request := 'INSERT INTO Месяцы(ID, MonthName)'+

' VALUES (9, ''Октябрь '')';

Conn.Execute(request);

request := 'INSERT INTO Месяцы(ID, MonthName)'+

' VALUES (10, ''Ноябрь '')';

Conn.Execute(request);

request := 'INSERT INTO Месяцы(ID, MonthName)'+

' VALUES (11, ''Декабрь '')';

Conn.Execute(request);

//------------------------------------------------------------------------------------/

request := 'INSERT INTO Типы_дней(ID, NameOfType)'+

' VALUES (0, ''Смена1 '')';

Conn.Execute(request);

request := 'INSERT INTO Типы_дней(ID, NameOfType)'+

' VALUES (1, ''Смена2 '')';

Conn.Execute(request);

request := 'INSERT INTO Типы_дней(ID, NameOfType)'+

' VALUES (2, ''Смена3 '')';

Conn.Execute(request);

request := 'INSERT INTO Типы_дней(ID, NameOfType)'+

' VALUES (3, ''Смена4 '')';

Conn.Execute(request);

request := 'INSERT INTO Типы_дней(ID, NameOfType)'+

' VALUES (4, ''Нерабочий день '')';

Conn.Execute(request);

request := 'INSERT INTO Типы_дней(ID, NameOfType)'+

' VALUES (5, ''Отпуск '')';

Conn.Execute(request);

//------------------------------------------------------------------------------------/

request := 'INSERT INTO Профессия(ID, NameProfession)'+

' VALUES (1, ''ПЭС '')';

Conn.Execute(request);

request := 'INSERT INTO Профессия(ID, NameProfession)'+

' VALUES (2, ''ДЭС '')';

Conn.Execute(request);

//------------------------------------------------------------------------------------/

request := 'INSERT INTO Статус(ID, NameStatus)'+

' VALUES (1, ''Вентиляторщик, работающий в выходные '')';

Conn.Execute(request);

request := 'INSERT INTO Статус(ID, NameStatus)'+

' VALUES (2, ''Вентиляторщик, не работающий в выходные '')';

Conn.Execute(request);

request := 'INSERT INTO Статус(ID, NameStatus)'+

' VALUES (3, ''Дежурный '')';

Conn.Execute(request);

request := 'INSERT INTO Статус(ID, NameStatus)'+

' VALUES (4, ''Рабочий'')';

Conn.Execute(request);

//------------------------------------------------------------------------------------/