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

ФЕДЕРАЛЬНОЕ АГЕНТСТВО ЖЕЛЕЗНОДОРОЖНОГО ТРАНСПОРТА

СМОЛЕНСКИЙ ФИЛИАЛ

ФЕДЕРАЛЬНОГО ГОСУДАРСТВЕННОГО БЮДЖЕТНОГО ОБРАЗОВАТЕЛЬНОГО УЧРЕЖДЕНИЯ

ВЫСШЕГО ПРОФЕССИОНАЛЬНОГО ОБРАЗОВАНИЯ

«МОСКОВСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ ПУТЕЙ СООБЩЕНИЯ»

Базы данных

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

2015 г.



Введение

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

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

Данными в базе данных могут быть числовые величины, строки.

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

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

1. Теоретические основы систем баз данных

1.1 Основные определения теории БД

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

- иерархическая,

- сетевая,

- реляционная,

- объектно-ориентированная,

- объектно-реляционная.

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

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

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

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

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

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

Самое широкое применение нашли реляционные модели данных.

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

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

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

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

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

Существует три разновидности связей между таблицами базы данных:

? «один-ко-многим»,

? «один-к-одному»,

? «многие-ко-многим».

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

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

Отношение «один-к-одному» имеет место, когда одной записи в родительской таблице соответствует одна запись в дочерней таблице.

Отношение «многие-ко-многим» имеет место, когда:

а) записи в родительской таблице может соответствовать больше одной записи в дочерней таблице;

б) записи в дочерней таблице может соответствовать больше одной записи в родительской таблице.

1.2 Основные определения теории БД

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

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

Логическая организация представляет собой модель структуры всей совокупности данных (ориентирована на человека). По сути, это способ объединения данных в записи, это «взгляд» на данные с точки зрения их использования в прикладных программах. Логическая организация БД - это представление пользователя о той предметной области, информация о которой должна хранится в базе данных. Результатом логического проектирования является концептуальная схема БД (это логическая модель предметной области). Эта модель отражает три вида информации: сведения об объектах предметной области, сведения о свойствах объектов, сведения об отношениях между объектами. Такая модель не зависит от: физической среды (типа ЭВМ), операционной системы, СУБД.

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

1.3Распределённые БД

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

1) простота использования системы;

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

3) высокая степень эффективности.

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

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

Подобная архитектура использовалась в первых версиях СУБД DB2, Oracle, Ingres.

Использование архитектуры «клиент-сервер» предполагает наличие некоторого количества компьютеров, объединенных в сеть, один из которых выполняет особые управляющие функции (является сервером сети). Так, архитектура «клиент-сервер» разделяет функции приложения пользователя (называемого клиентом) и сервера. Приложение-клиент формирует запрос к серверу, на котором расположена БД, на структурном языке запросов SQL (Structured Query Languague), являющемся промышленным стандартом в мире реляционных БД. Удаленный сервер принимает запрос и переадресует его SQL-серверу БД. В результате работа построена следующим образом: база данных в виде набора файлов находится на жестком диске специально выделенного компьютера (сервера сети), СУБД располагается также на сервере сети, существует локальная сеть, состоящая из клиентских компьютеров, на каждом из которых установлено клиентское приложение для работы с БД. На каждом из клиентских компьютеров пользователи имеют возможность запустить приложение. Используя предоставляемый приложением пользовательский интерфейс, он инициирует обращение к СУБД, расположенной на сервере, для запроса к информации. Для общения используется специальный язык запросов SQL, т.е. по сети от клиента к серверу передается лишь текст запроса.

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

Приложение, используя пользовательский интерфейс, отображает результат выполнения запросов.

В архитектуре «клиент-сервер» используются так называемые «удаленные» СУБД.

К разряду промышленных СУБД принадлежат Oracle, Gupta, Informix, Sybase, MS SQL Server, DB2, InterBase и ряд других

По сравнению с архитектурой «файл-сервер» можно выделить следующие преимущества:

- существенное уменьшение сетевого трафика;

- уменьшение сложности клиентских приложений (большая часть нагрузки ложится на серверную часть);

- повышение целостности и безопасности БД.

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



1.4 Современные Базы данных

Современные СУБД можно разделить на следующие группы:

- Устаревшие: Paradox, Clarion.

- dBase-подобные: dBase, FoxBASE, Fox-plus, Clipper

- Локальные: Access

- SQL серверы: Ms SQL Server, Oracle, InterBase/Firebird/Yaffil, IBM DB2, MySQL, также Informix, Btrieve, Sybase

Группа реляционных СУБД представлена на рынке программных продуктов очень широко. Это, например, такие системы, как Paradox, R:base, Clarion, однако доминирующее положение занимает семейство так называемых dBASE-подобных СУБД, родоначальником которого является СУБД dBASEII, предложенная фирмой Ashton-Tate в начале 80-ых годов. В настоящее время широко распространено новое поколение популярных пакетов: dBASEIV, FoxPro и Clipper-5.

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

В настоящее время скорость работы таких программ не уступает скорости программ, сгенерированных компилятором. Бесспорным преимуществом интерпретаторов для программиста является удобство в разработке и отладке программных продуктов, а также при освоении языка. Из вышеперечисленных СУБД dBASE и FoxProявляются интерпретаторами, а Clipper - компилятором.

СУБД FoxPro(фирмы Fox Software)обладает исключительно высокими скоростными характеристиками и в этом отношении заметно выделяется среди других интерпретирующих систем. Сравнительно с dBASEIY ее скорость в несколько раз выше и не уступает скорости систем-компиляторов. Практически по всем показателям Fox-программыработают значительно быстрее Clipper-программ.

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

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

В Access присутствует язык VisualBasic, позволяющий создавать массивы, свои типы данных. С помощью оле-технологий позволяет контролировать работу приложений. Работа с базой в Access осуществляется через окно контейнера БД. Также встроен язык SQL.

В Access поддерживается два способа создания БД (БД - совокупность взаимосвязанных таблиц):

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

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

SQL Server 2000 --семейство продуктов, разработанных для хранения данных в больших системах, осуществляющих обработку информации, и обслуживания коммерческих Web-узлов. SQLServer 2000 прост и удобен в использовании, он широко применяется как в сложных системах, с которыми работают сотни пользователей, так и в малом бизнесе. Он популярен также у отдельных пользователей, которым нужен надежный и удобный сервер БД. В состав SQL Server2000 входят две основные службы, предназначенные для новой платформы Microsoft .NET и систем с традиционной двухуровневой клиент-серверной архитектурой. Первая служба, SQL Server-- это высокопроизводительное реляционное ядро БД, обеспечивающее прекрасную масштабируемость систем, созданных на его основе. Вторая --SQL Server 2000 Analysis Services -- предоставляет множество средств анализа данных, которые размещаются в специальных хранилищах и киосках данных и используются системами принятия решений.

Сервер Oracle позволяет хранить очень большие объемы информации и предоставляет пользователямбыстрый доступ к этим данным.

Oracle отличается от SQLсервер тем, что поддерживает продвинутые аппаратные конфигурации (1000 процессоров). SQL сервер не поддерживает сложныеконфигурации.

Помимо ОС пользователи могут поставить отдельные программы дополнительно: средства работы с видео данными, WWW-сервер, средства поддержки систем масштаба предприятия, средства обработки пространственных данных, имеет систему контекст, средства оперативно-аналитической обработки данных (DLAP).

Сервер БД Oracle часто называют ядром БД Oracle. Процедурные компоненты сервера обеспечивают обработку запросов на языке PL/SQL и поддерживают хранимые процедуры, триггеры БД, пакеты хранимых процедур и функций. Средства распределенной обработки (дают возможность пользователю работать с информацией, находящейся в удаленных базах);

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

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



1.5 Элементы приложения информационных систем

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

Рис. 1.1. Многозвенная архитектура приложений БД

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

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

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

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

Таким образом, многозвенное приложение БД состоит из (рис. 1.1):

· "тонких" клиентских приложений, обеспечивающих лишь передачу, представление, редактирование и простейшую обработку данных;

· одного или нескольких звеньев ПО промежуточного слоя (сервер приложений), которые могут функционировать как на одном компьютере, так и распределенно -- в локальной сети;

· сервера БД (Oralce, Sybase, MS SQL, InterBase и т. д.), поддерживающего функционирование базы данных и обрабатывающего запросы.

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

· "тонкие" клиенты;

· сервер приложений;

· сервер БД.

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

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

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

2. Практическая часть

2.1 Информационно-логическая модель

база данные запрос информационный

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

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

В нашем случае предметной областью является учёт инвентаризационного оборудования в колледже.

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

- Тип оборудования

- Оборудование

- Подразделение

- Приход оборудования

- Перемещение оборудования

- Списание оборудования

- Инвентаризация

Определим связи между сущностями:

Установим связи между объектами и определим структуру данных.

Структура БД

Определим таблицы нашей базы данных:

Теблица S_ type - хранит данные о типах оборудования;

Таблица s_oborud - хранит данные об оборудовании;

Таблица prihod - хранит данные о поступлениях оборудования;

Таблица rashod- хранит данные о перемещения оборудования;

Таблица spisanie - хранит данные о списании оборудования;

Таблица invent - хранит данные о проводимых инвентаризациях;

Таблица users - хранит данные о пользователях;

Таблица users_level- хранит данные о павах доступа пользователей;

Используя клиент PL/SQl developer с помощью следующего скрипта создадим перечисленные таблицы:

spool rz.log

prompt

prompt Creating table S_TYPE

prompt =====================

prompt

create table INVENT.S_TYPE

(

ID_TYPE NUMBER not null,

NAME_TYPE VARCHAR2(40)

)

tablespace USERS

pctfree 10

initrans 1

maxtrans 255

storage

(

initial 64K

next 1M

minextents 1

maxextents unlimited

);

alter table INVENT.S_TYPE

add constraint S_TYPE_PK1 primary key (ID_TYPE)

using index

tablespace USERS

pctfree 10

initrans 2

maxtrans 255

storage

(

initial 64K

next 1M

minextents 1

maxextents unlimited

);

Prompt

prompt Creating table S_OBORUD

prompt =======================

prompt

create table INVENT.S_OBORUD

(

ID_OBORUD NUMBER not null,

OBORUD VARCHAR2(40),

ID_TYPE NUMBER

)

tablespace USERS

pctfree 10

initrans 1

maxtrans 255

storage

(

initial 64K

next 1M

minextents 1

maxextents unlimited

);

alter table INVENT.S_OBORUD

add constraint S_OBORUD_PK1 primary key (ID_OBORUD)

using index

tablespace USERS

pctfree 10

initrans 2

maxtrans 255

storage

(

initial 64K

next 1M

minextents 1

maxextents unlimited

);

alter table INVENT.S_OBORUD

add constraint S_OBORUD_FK1 foreign key (ID_TYPE)

references INVENT.S_TYPE (ID_TYPE);

prompt

prompt Creating table INVENT

prompt =====================

prompt

create table INVENT.INVENT

(

ID_INVENT NUMBER not null,

DATE_INVENT DATE,

ID_OBORUD NUMBER,

KOL_F NUMBER,

FIO VARCHAR2(40)

)

tablespace USERS

pctfree 10

initrans 1

maxtrans 255

storage

(

initial 64K

next 1M

minextents 1

maxextents unlimited

);

alter table INVENT.INVENT

add constraint INVENT_PK1 primary key (ID_INVENT)

using index

tablespace USERS

pctfree 10

initrans 2

maxtrans 255

storage

(

initial 64K

next 1M

minextents 1

maxextents unlimited

);

alter table INVENT.INVENT

add constraint INVENT_FK1 foreign key (ID_OBORUD)

references INVENT.S_OBORUD (ID_OBORUD);

prompt

prompt Creating table PRIHOD

prompt =====================

prompt

create table INVENT.PRIHOD

(

ID_PRIHOD NUMBER not null,

DATE_P DATE,

NOM_NAKL NUMBER,

PRICE NUMBER,

ID_OBORUD NUMBER

)

tablespace USERS

pctfree 10

initrans 1

maxtrans 255

storage

(

initial 64K

next 1M

minextents 1

maxextents unlimited

);

alter table INVENT.PRIHOD

add constraint PRIHOD_PK1 primary key (ID_PRIHOD)

using index

tablespace USERS

pctfree 10

initrans 2

maxtrans 255

storage

(

initial 64K

next 1M

minextents 1

maxextents unlimited

);

alter table INVENT.PRIHOD

add constraint PRIHOD_FK1 foreign key (ID_OBORUD)

references INVENT.S_OBORUD (ID_OBORUD);

prompt

prompt Creating table S_KABINET

prompt ========================

prompt

create table INVENT.S_KABINET

(

ID_KABINET NUMBER not null,

KABINET VARCHAR2(40),

MOL VARCHAR2(40)

)

tablespace USERS

pctfree 10

initrans 1

maxtrans 255

storage

(

initial 64K

next 1M

minextents 1

maxextents unlimited

);

alter table INVENT.S_KABINET

add constraint S_KABINET_PK1 primary key (ID_KABINET)

using index

tablespace USERS

pctfree 10

initrans 2

maxtrans 255

storage

(

initial 64K

next 1M

minextents 1

maxextents unlimited

);

Prompt

prompt Creating table RASHOD

prompt =====================

prompt

create table INVENT.RASHOD

(

ID_RASHOD NUMBER not null,

ID_PRIHOD NUMBER,

DATE_R DATE,

ID_KABINET NUMBER

)

tablespace USERS

pctfree 10

initrans 1

maxtrans 255

storage

(

initial 64K

next 1M

minextents 1

maxextents unlimited

);

alter table INVENT.RASHOD

add constraint RASHOD_PK1 primary key (ID_RASHOD)

using index

tablespace USERS

pctfree 10

initrans 2

maxtrans 255

storage

(

initial 64K

next 1M

minextents 1

maxextents unlimited

);

alter table INVENT.RASHOD

add constraint RASHOD_FK1 foreign key (ID_PRIHOD)

references INVENT.PRIHOD (ID_PRIHOD);

alter table INVENT.RASHOD

add constraint RASHOD_FK2 foreign key (ID_KABINET)

references INVENT.S_KABINET (ID_KABINET);

prompt

prompt Creating table SPISANIE

prompt =======================

prompt

create table INVENT.SPISANIE

(

ID_SPISANIE NUMBER not null,

ID_PRIHOD NUMBER,

DATE_SP DATE,

PRIM VARCHAR2(40)

)

tablespace USERS

pctfree 10

initrans 1

maxtrans 255

storage

(

initial 64K

next 1M

minextents 1

maxextents unlimited

);

alter table INVENT.SPISANIE

add constraint SPISANIE_PK1 primary key (ID_SPISANIE)

using index

tablespace USERS

pctfree 10

initrans 2

maxtrans 255

storage

(

initial 64K

next 1M

minextents 1

maxextents unlimited

);

alter table INVENT.SPISANIE

add constraint SPISANIE_FK1 foreign key (ID_PRIHOD)

references INVENT.PRIHOD (ID_PRIHOD);

prompt

prompt Creating table USERS

prompt ====================

prompt

create table INVENT.USERS

(

ID_USER NUMBER not null,

LOGIN VARCHAR2(10),

FIO VARCHAR2(40),

PASS VARCHAR2(10)

)

tablespace USERS

pctfree 10

initrans 1

maxtrans 255

storage

(

initial 64K

next 1M

minextents 1

maxextents unlimited

);

alter table INVENT.USERS

add constraint USERS_PK1 primary key (ID_USER)

using index

tablespace USERS

pctfree 10

initrans 2

maxtrans 255

storage

(

initial 64K

next 1M

minextents 1

maxextents unlimited

);

Prompt

prompt Creating table USERS_LEVEL

prompt ==========================

prompt

create table INVENT.USERS_LEVEL

(

ID_USER NUMBER,

SPRAV NUMBER(1),

REP NUMBER(1)

)

tablespace USERS

pctfree 10

initrans 1

maxtrans 255

storage

(

initial 64K

next 1M

minextents 1

maxextents unlimited

);

alter table INVENT.USERS_LEVEL

add constraint USERS_LEVEL_PK1 foreign key (ID_USER)

references INVENT.USERS (ID_USER);

spool off

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

prompt Loading S_TYPE...

insert into S_TYPE (ID_TYPE, NAME_TYPE)

values (1, 'компьютеры');

insert into S_TYPE (ID_TYPE, NAME_TYPE)

values (2, 'ноутбуки');

insert into S_TYPE (ID_TYPE, NAME_TYPE)

values (3, 'оргтехника');

commit;

prompt 3 records loaded

prompt Loading S_OBORUD...

insert into S_OBORUD (ID_OBORUD, OBORUD, ID_TYPE)

values (1, 'Компьютер с монитором', 1);

insert into S_OBORUD (ID_OBORUD, OBORUD, ID_TYPE)

values (2, 'НОутбук Acer', 2);

insert into S_OBORUD (ID_OBORUD, OBORUD, ID_TYPE)

values (3, 'Принтер Laser Jet', 3);

insert into S_OBORUD (ID_OBORUD, OBORUD, ID_TYPE)

values (4, 'Компьютер Lenova', 1);

insert into S_OBORUD (ID_OBORUD, OBORUD, ID_TYPE)

values (5, 'Ноутбук HP Laser Jet', 2);

insert into S_OBORUD (ID_OBORUD, OBORUD, ID_TYPE)

values (6, 'Компьютер ASUS', 1);

insert into S_OBORUD (ID_OBORUD, OBORUD, ID_TYPE)

values (7, 'Компьютер ', 1);

commit;

prompt 7 records loaded

prompt Loading INVENT...

insert into INVENT (ID_INVENT, DATE_INVENT, ID_OBORUD, KOL_F, FIO)

values (1, to_date('11-02-2015', 'dd-mm-yyyy'), 2, 12, 'Иванова');

commit;

prompt 1 records loaded

prompt Loading PRIHOD...

insert into PRIHOD (ID_PRIHOD, DATE_P, NOM_NAKL, PRICE, ID_OBORUD)

values (1, to_date('05-02-2015', 'dd-mm-yyyy'), 125, 15000, 1);

insert into PRIHOD (ID_PRIHOD, DATE_P, NOM_NAKL, PRICE, ID_OBORUD)

values (2, to_date('05-02-2015', 'dd-mm-yyyy'), 456, 25000, 2);

insert into PRIHOD (ID_PRIHOD, DATE_P, NOM_NAKL, PRICE, ID_OBORUD)

values (3, to_date('05-02-2015', 'dd-mm-yyyy'), 48731, 15000, 3);

insert into PRIHOD (ID_PRIHOD, DATE_P, NOM_NAKL, PRICE, ID_OBORUD)

values (4, to_date('05-02-2015', 'dd-mm-yyyy'), 1121, 18000, 4);

insert into PRIHOD (ID_PRIHOD, DATE_P, NOM_NAKL, PRICE, ID_OBORUD)

values (5, to_date('05-02-2015', 'dd-mm-yyyy'), 233, 15000, 5);

insert into PRIHOD (ID_PRIHOD, DATE_P, NOM_NAKL, PRICE, ID_OBORUD)

values (6, to_date('05-02-2015', 'dd-mm-yyyy'), 125, 15000, 6);

insert into PRIHOD (ID_PRIHOD, DATE_P, NOM_NAKL, PRICE, ID_OBORUD)

values (7, to_date('05-02-2015', 'dd-mm-yyyy'), 125, 15000, 7);

commit;

prompt 7 records loaded

prompt Loading S_KABINET...

insert into S_KABINET (ID_KABINET, KABINET, MOL)

values (1, 'Кабинет информатики', 'Иванова Анна');

insert into S_KABINET (ID_KABINET, KABINET, MOL)

values (2, 'Учебный класс 1', 'Петров А.В.');

insert into S_KABINET (ID_KABINET, KABINET, MOL)

values (3, 'Учебный класс 2', 'Шульгин Ш.А.');

insert into S_KABINET (ID_KABINET, KABINET, MOL)

values (4, 'Склад', 'Сидоров А.П,');

commit;

prompt 4 records loaded

prompt Loading RASHOD...

insert into RASHOD (ID_RASHOD, ID_PRIHOD, DATE_R, ID_KABINET)

values (3, 4, to_date('18-02-2015', 'dd-mm-yyyy'), 3);

insert into RASHOD (ID_RASHOD, ID_PRIHOD, DATE_R, ID_KABINET)

values (1, 2, to_date('01-02-2015', 'dd-mm-yyyy'), 1);

insert into RASHOD (ID_RASHOD, ID_PRIHOD, DATE_R, ID_KABINET)

values (2, 3, to_date('19-02-2015', 'dd-mm-yyyy'), 4);

insert into RASHOD (ID_RASHOD, ID_PRIHOD, DATE_R, ID_KABINET)

values (5, null, null, null);

insert into RASHOD (ID_RASHOD, ID_PRIHOD, DATE_R, ID_KABINET)

values (4, 7, to_date('04-02-2015', 'dd-mm-yyyy'), 1);

commit;

prompt 5 records loaded

prompt Loading SPISANIE...

insert into SPISANIE (ID_SPISANIE, ID_PRIHOD, DATE_SP, PRIM)

values (0, 5, to_date('20-02-2015', 'dd-mm-yyyy'), null);

insert into SPISANIE (ID_SPISANIE, ID_PRIHOD, DATE_SP, PRIM)

values (1, 4, to_date('20-02-2015', 'dd-mm-yyyy'), null);

insert into SPISANIE (ID_SPISANIE, ID_PRIHOD, DATE_SP, PRIM)

values (2, null, null, null);

insert into SPISANIE (ID_SPISANIE, ID_PRIHOD, DATE_SP, PRIM)

values (3, null, null, null);

commit;

prompt 4 records loaded

prompt Loading USERS...

insert into USERS (ID_USER, LOGIN, FIO, PASS)

values (1, 'admin', 'Администратор', '0');

insert into USERS (ID_USER, LOGIN, FIO, PASS)

values (2, 'master', 'Мастер', '1');

insert into USERS (ID_USER, LOGIN, FIO, PASS)

values (3, 'nach', 'Начальник', '2');

commit;

prompt 3 records loaded

prompt Loading USERS_LEVEL...

insert into USERS_LEVEL (ID_USER, SPRAV, REP)

values (1, 1, 1);

insert into USERS_LEVEL (ID_USER, SPRAV, REP)

values (2, 1, null);

insert into USERS_LEVEL (ID_USER, SPRAV, REP)

values (3, 1, 1);

commit;

prompt 3 records loaded

prompt Enabling foreign key constraints for S_OBORUD...

alter table S_OBORUD enable constraint S_OBORUD_FK1;

prompt Enabling foreign key constraints for INVENT...

alter table INVENT enable constraint INVENT_FK1;

prompt Enabling foreign key constraints for PRIHOD...

alter table PRIHOD enable constraint PRIHOD_FK1;

prompt Enabling foreign key constraints for RASHOD...

alter table RASHOD enable constraint RASHOD_FK1;

alter table RASHOD enable constraint RASHOD_FK2;

prompt Enabling foreign key constraints for SPISANIE...

alter table SPISANIE enable constraint SPISANIE_FK1;

prompt Enabling foreign key constraints for USERS_LEVEL...

alter table USERS_LEVEL enable constraint USERS_LEVEL_PK1;

set feedback on

set define on

prompt Done.

2.2 Интерфейс

Представим элементы интерфейса нашего приложения.

Структура меню определяется удобством работы с огромным объёмом информации. Поэтому мы сгруппируем меню следующем образом:

- Справочники

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

- списки оборудования;

- кабинеты;

- Документы

- Приход

- Расход

- Списание

- Инвентаризация;

- Отчёты

- остатки на складе

- Остатки по подразделениям

- итоги инвентаризации

- Управление

- Пользователь

- Доступ

- Управление

- Выход

Программа имеет интуитивно-понятный интерфейс, элементы которого представлены ниже.

Рис. 2.2. Окно авторизации



Рис. 2.3. Главная форма

Рис. 2.4. Справочники



Рис. 2.5. Приход

Рис. 2.6. Перемещение



Рис. 2.7. Списание

Рис. 2.8. Инвентаризация



Рис. 2.9. Отчёты

Рис. 2.9. Модуль управления (Пользователи)



Рис. 2.10. Модуль управления (Доступ)

Рис. 2.11. Списание оборудования



Рис. 2.12. Перемещение оборудования

Для формирования отчётов используются следующие запросы:

1) Остатки на складе

select * from invent.prihod t where id_prihod not in (select id_prihod from invent.rashod where date_r<=:d) and t.date_p<=:d and id_prihod not in (select id_prihod from invent.spisanie where date_sp<=:d)

2) Остатки по подразделениям

select * from invent.rashod t where t.date_r<=:d and id_prihod not in (select id_prihod from invent.spisanie where date_sp<=:d)

3) Итоги инвентаризации

select plan.oborud, nvl(kol_p,0) as kol_p, nvl(kol_f, 0) as kol_f, nvl(kol_p,0)-nvl(kol_f,0) as it from (select oborud, count(*) as kol_p from invent.prihod t left join invent.s_oborud f on f.id_oborud=t.id_oborud where

t.date_p<=:d and id_prihod not in (select id_prihod from invent.spisanie where date_sp<=:d) group by oborud

) plan left join (select oborud, kol_f from invent.invent t left join invent.s_oborud f on f.id_oborud=t.id_oborud where t.date_invent=:d

) fact on fact.oborud=plan.oborud

Листинг программы представлен в приложении 1.



Заключение

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

1. Экономит время;

2. Проста при эксплуатации;

3. Уменьшает физическую нагрузку.

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

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



Приложение 1

Листинг программы

unit frm_main;

interface

uses

Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,

Dialogs, Menus;

type

Tfrmmain = class(TForm)

MainMenu1: TMainMenu;

Cghfdjxybrb1: TMenuItem;

N1: TMenuItem;

N2: TMenuItem;

N3: TMenuItem;

N4: TMenuItem;

N5: TMenuItem;

N6: TMenuItem;

N7: TMenuItem;

N8: TMenuItem;

procedure FormShow(Sender: TObject);

procedure FormClose(Sender: TObject; var Action: TCloseAction);

procedure Cghfdjxybrb1Click(Sender: TObject);

procedure N2Click(Sender: TObject);

procedure N3Click(Sender: TObject);

procedure N5Click(Sender: TObject);

procedure N4Click(Sender: TObject);

procedure FormCreate(Sender: TObject);

procedure N7Click(Sender: TObject);

procedure N6Click(Sender: TObject);

procedure N8Click(Sender: TObject);

private

{ Private declarations }

public

{ Public declarations }

ip, host, comp:string;

end;

var

frmmain: Tfrmmain;

implementation

uses frmlogin, dmora, Unit5, Unit4, frmsprav, Unit2, Unit3, frm_rep, Unit6,

Unit8;

{$R *.dfm}

procedure Tfrmmain.FormShow(Sender: TObject);

begin

frm_login.Showmodal;

frmmain.Caption:= frmmain.Caption+' ';

if dm.quserid_user.Value=3 then

begin

N7.Visible:=True;

end;

end;

procedure Tfrmmain.FormClose(Sender: TObject; var Action: TCloseAction);

begin

if MessageDlg('Закрыть приложение ?', mtConfirmation,

[mbYes, mbNo], 0) = mrYes then

begin

dm.Free;

Action := caFree

end

else

Action := caNone;

end;

procedure Tfrmmain.Cghfdjxybrb1Click(Sender: TObject);

begin

if not assigned (frm_sprav) then

frm_sprav:=tfrm_sprav.Create(application)

else frm_sprav.Show;

end;

procedure Tfrmmain.N2Click(Sender: TObject);

begin

if not assigned (prihod) then

prihod:=tprihod.Create(application)

else prihod.Show;

end;

procedure Tfrmmain.N3Click(Sender: TObject);

begin

if not assigned (rashod) then

rashod:=trashod.Create(application)

else rashod.Show;

end;

procedure Tfrmmain.N5Click(Sender: TObject);

begin

if not assigned (spis) then

spis:=tspis.Create(application)

else spis.Show;

end;

procedure Tfrmmain.N4Click(Sender: TObject);

begin

if not assigned (inv) then

inv:=tinv.Create(application)

else inv.Show;

end;

procedure Tfrmmain.FormCreate(Sender: TObject);

var f1:textfile;

i, idcomp:integer;

begin

WindowState := wsMaximized;

AssignFile(F1, ExtractFilePath(Application.ExeName)+'\host.txt');

Reset(F1);

for i:=0 to 0 do

ReadLn(F1, ip);

for i:=2 to 2 do

ReadLn(F1, comp);

Self.WindowState := wsMaximized;

// dm := dm.Create(Application);

with dm do

Begin

OraSession1.ConnectString := ip;

OraSession1.Options.Net := true;

OraSession1.Connect;

dm.Users.Active:=true;

dm.qUser.Active:=true;

dm.s_type.Active:=true;

dm.s_kabinet.Active:=true;

dm.prihod.Active:=true;

dm.rashod.Active:=true;

dm.spis.Active:=True;

dm.Qprihod_for_spis.Active:=True;

dm.qprihod.Active:=true;

dm.invent.Active:=True;

end;

end;

procedure Tfrmmain.N7Click(Sender: TObject);

begin

if not assigned (form8) then

form8:=tform8.Create(application)

else form8.Show;

end;

procedure Tfrmmain.N6Click(Sender: TObject);

begin

if not assigned (zapr) then

zapr:=tzapr.Create(application)

else zapr.Show;

end;

procedure Tfrmmain.N8Click(Sender: TObject);

begin

close;

end;

end.

unit Unit8;

interface

uses

Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,

Dialogs, cxStyles, dxSkinsCore, dxSkinBlack, dxSkinBlue, dxSkinCaramel,

dxSkinCoffee, dxSkinDarkSide, dxSkinGlassOceans, dxSkiniMaginary,

dxSkinLilian, dxSkinLiquidSky, dxSkinLondonLiquidSky, dxSkinMcSkin,

dxSkinMoneyTwins, dxSkinOffice2007Black, dxSkinOffice2007Blue,

dxSkinOffice2007Green, dxSkinOffice2007Pink, dxSkinOffice2007Silver,

dxSkinPumpkin, dxSkinSilver, dxSkinSpringTime, dxSkinStardust,

dxSkinSummer2008, dxSkinsDefaultPainters, dxSkinValentine,

dxSkinXmas2008Blue, dxSkinscxPCPainter, cxCustomData, cxGraphics,

cxFilter, cxData, cxDataStorage, cxEdit, DB, cxDBData, cxMaskEdit,

cxCheckBox, cxGridLevel, cxGridCustomTableView, cxGridTableView,

cxGridDBTableView, cxClasses, cxControls, cxGridCustomView, cxGrid,

ComCtrls;

type

TForm8 = class(TForm)

PageControl1: TPageControl;

TabSheet1: TTabSheet;

TabSheet2: TTabSheet;

cxGrid2: TcxGrid;

cxGridDBTableView2: TcxGridDBTableView;

cxGridDBColumn8: TcxGridDBColumn;

cxGridDBColumn9: TcxGridDBColumn;

cxGridDBColumn10: TcxGridDBColumn;

cxGridDBColumn11: TcxGridDBColumn;

cxGridDBColumn12: TcxGridDBColumn;

cxGridDBColumn13: TcxGridDBColumn;

cxGridDBColumn14: TcxGridDBColumn;

cxGridLevel2: TcxGridLevel;

cxGrid1: TcxGrid;

cxGridDBTableView1: TcxGridDBTableView;

cxGridDBColumn1: TcxGridDBColumn;

cxGridDBColumn2: TcxGridDBColumn;

cxGridDBColumn3: TcxGridDBColumn;

cxGridDBColumn4: TcxGridDBColumn;

cxGridDBColumn5: TcxGridDBColumn;

cxGridDBColumn6: TcxGridDBColumn;

cxGridDBColumn7: TcxGridDBColumn;

cxGridLevel1: TcxGridLevel;

private

{ Private declarations }

public

{ Public declarations }

end;

var

Form8: TForm8;

implementation

{$R *.dfm}

end.

unit Unit1;

interface

uses

Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,

Dialogs, cxGraphics, dxSkinsCore, dxSkinBlack, dxSkinBlue, dxSkinCaramel,

dxSkinCoffee, dxSkinDarkSide, dxSkinGlassOceans, dxSkiniMaginary,

dxSkinLilian, dxSkinLiquidSky, dxSkinLondonLiquidSky, dxSkinMcSkin,

dxSkinMoneyTwins, dxSkinOffice2007Black, dxSkinOffice2007Blue,

dxSkinOffice2007Green, dxSkinOffice2007Pink, dxSkinOffice2007Silver,

dxSkinPumpkin, dxSkinSilver, dxSkinSpringTime, dxSkinStardust,

dxSkinSummer2008, dxSkinsDefaultPainters, dxSkinValentine,

dxSkinXmas2008Blue, cxDBEdit, cxLabel, cxDropDownEdit, cxCalendar,

cxControls, cxContainer, cxEdit, cxTextEdit, cxMaskEdit, cxLookupEdit,

cxDBLookupEdit, cxDBLookupComboBox, Menus, cxLookAndFeelPainters,

StdCtrls, cxButtons;

type

Tins = class(TForm)

cxDBLookupComboBox1: TcxDBLookupComboBox;

cxDBDateEdit1: TcxDBDateEdit;

cxDBLookupComboBox2: TcxDBLookupComboBox;

cxLabel1: TcxLabel;

cxLabel2: TcxLabel;

cxLabel3: TcxLabel;

cxDBTextEdit1: TcxDBTextEdit;

cxLabel4: TcxLabel;

cxButton1: TcxButton;

cxButton2: TcxButton;

procedure cxButton1Click(Sender: TObject);

procedure cxButton2Click(Sender: TObject);

private

{ Private declarations }

public

{ Public declarations }

end;

var

ins: Tins;

implementation

uses dmora;

{$R *.dfm}

procedure Tins.cxButton1Click(Sender: TObject);

begin

dm.rashod.cancel;

close;

end;

procedure Tins.cxButton2Click(Sender: TObject);

begin

dm.rashod.post;

close;

end;

end.

unit frmlogin;

interface

uses

Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,

Dialogs, StdCtrls, sButton, sEdit, DBCtrls, sDBLookupComboBox;

type

Tfrm_login = class(TForm)

edit1: TsDBLookupComboBox;

lbl1: TLabel;

lbl2: TLabel;

Edit2: TsEdit;

sButton1: TsButton;

sButton2: TsButton;

procedure sButton1Click(Sender: TObject);

procedure sButton2Click(Sender: TObject);

private

{ Private declarations }

public

{ Public declarations }

end;

var

frm_login: Tfrm_login;

implementation

uses dmora;

{$R *.dfm}

procedure Tfrm_login.sButton1Click(Sender: TObject);

begin

dm.QUser.Active:=false;

dm.QUser.Params.parambyname('us').value:=edit1.Text;

dm.QUser.Active:=true;

if (dm.QUser.RecordCount>0) and (edit2.Text=dm.QUserpass.Value) then

frm_login.Close

else

begin

Edit2.Text:='';

showmessage('Неверно ввели логин/пароль!');

end;

end;

procedure Tfrm_login.sButton2Click(Sender: TObject);

begin

application.Terminate;

end;

end.

unit Unit6;

interface

uses

Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,

Dialogs, cxStyles, dxSkinsCore, dxSkinBlack, dxSkinBlue, dxSkinCaramel,

dxSkinCoffee, dxSkinDarkSide, dxSkinGlassOceans, dxSkiniMaginary,

dxSkinLilian, dxSkinLiquidSky, dxSkinLondonLiquidSky, dxSkinMcSkin,

dxSkinMoneyTwins, dxSkinOffice2007Black, dxSkinOffice2007Blue,

dxSkinOffice2007Green, dxSkinOffice2007Pink, dxSkinOffice2007Silver,

dxSkinPumpkin, dxSkinSilver, dxSkinSpringTime, dxSkinStardust,

dxSkinSummer2008, dxSkinsDefaultPainters, dxSkinValentine,

dxSkinXmas2008Blue, dxSkinscxPCPainter, cxCustomData, cxGraphics,

cxFilter, cxData, cxDataStorage, cxEdit, DB, cxDBData, cxMaskEdit, Menus,

cxLookAndFeelPainters, StdCtrls, cxButtons, cxLabel, cxContainer,

cxTextEdit, cxDropDownEdit, cxCalendar, cxGridLevel,

cxGridCustomTableView, cxGridTableView, cxGridDBTableView, cxClasses,

cxControls, cxGridCustomView, cxGrid, ComCtrls, ExtCtrls;

type

Tzapr = class(TForm)

Panel1: TPanel;

PageControl1: TPageControl;

TabSheet1: TTabSheet;

TabSheet2: TTabSheet;

TabSheet3: TTabSheet;

cxDateEdit1: TcxDateEdit;

cxLabel1: TcxLabel;

cxButton1: TcxButton;

cxGrid8: TcxGrid;

cxGridDBTableView7: TcxGridDBTableView;

cxGridDBColumn54: TcxGridDBColumn;

cxGridDBColumn53: TcxGridDBColumn;

cxGridDBTableView7Column1: TcxGridDBColumn;

cxGridDBTableView7Column2: TcxGridDBColumn;

cxGridDBTableView7Column3: TcxGridDBColumn;

cxGridDBTableView7Column4: TcxGridDBColumn;

cxGridDBTableView7Column5: TcxGridDBColumn;

cxGridLevel7: TcxGridLevel;

cxGrid1: TcxGrid;

cxGridDBTableView1: TcxGridDBTableView;

cxGridDBColumn1: TcxGridDBColumn;

cxGridDBColumn2: TcxGridDBColumn;

cxGridDBColumn3: TcxGridDBColumn;

cxGridDBColumn4: TcxGridDBColumn;

cxGridDBColumn5: TcxGridDBColumn;

cxGridDBColumn6: TcxGridDBColumn;

cxGridLevel1: TcxGridLevel;

cxGrid2: TcxGrid;

cxGridDBTableView2: TcxGridDBTableView;

cxGridDBColumn7: TcxGridDBColumn;

cxGridDBColumn8: TcxGridDBColumn;

cxGridDBColumn9: TcxGridDBColumn;

cxGridDBColumn10: TcxGridDBColumn;

cxGridDBColumn11: TcxGridDBColumn;

cxGridDBColumn12: TcxGridDBColumn;

cxGridLevel2: TcxGridLevel;

cxGridDBTableView2Column1: TcxGridDBColumn;

procedure cxButton1Click(Sender: TObject);

private

{ Private declarations }

public

{ Public declarations }

end;

var

zapr: Tzapr;

implementation

uses dmora;

{$R *.dfm}

procedure Tzapr.cxButton1Click(Sender: TObject);

begin

dm.q1.params.parambyname('d').value:=cxDateEdit1.Date;

dm.q1.active:=false;

dm.q1.active:=true;

dm.q2.params.parambyname('d').value:=cxDateEdit1.Date;

dm.q2.active:=false;

dm.q2.active:=true;

dm.q3.params.parambyname('d').value:=cxDateEdit1.Date;

dm.q3.active:=false;

dm.q3.active:=true;

end;

end.

unit dmora;

interface

uses

SysUtils, Classes, DB, Ora, DBAccess, MemDS, OraSmart, sSkinManager,

Menus, cxStyles, cxExtEditRepositoryItems, cxEdit, cxDBEditRepository,

cxGridCustomPopupMenu, cxGridPopupMenu;

type

Tdm = class(TDataModule)

orasession1: TOraSession;

cxEditRepository1: TcxEditRepository;

fld_users: TcxEditRepositoryLookupComboBoxItem;

cxStyleRepository2: TcxStyleRepository;

cxStyle1: TcxStyle;

cxStyle2: TcxStyle;

cxsel: TcxStyle;

cxStyle4: TcxStyle;

cxhead: TcxStyle;

cxStyle5: TcxStyle;

cxStyle6: TcxStyle;

cxStyle7: TcxStyle;

cxStyle8: TcxStyle;

cxStyle9: TcxStyle;

cxStyle10: TcxStyle;

cxStyle3: TcxStyle;

cxStyle31: TcxStyle;

cxStyle11: TcxStyle;

Users: TOraTable;

dUsers: TOraDataSource;

quser: TOraQuery;

dquser: TOraDataSource;

quserID_USER: TFloatField;

quserLOGIN: TStringField;

quserFIO: TStringField;

quserPASS: TStringField;

s_type: TOraQuery;

ds_type: TOraDataSource;

s_kabinet: TOraQuery;

ds_kabinet: TOraDataSource;

prihod: TOraQuery;

dprihod: TOraDataSource;

rashod: TOraQuery;

drashod: TOraDataSource;

s_typeID_TYPE: TFloatField;

s_typeNAME_TYPE: TStringField;

invent: TOraQuery;

dinvent: TOraDataSource;

spis: TOraQuery;

dspis: TOraDataSource;

fld_type: TcxEditRepositoryLookupComboBoxItem;

fld_prihod: TcxEditRepositoryLookupComboBoxItem;

fld_kabinet: TcxEditRepositoryLookupComboBoxItem;

Qprihod: TOraQuery;

dQprihod: TOraDataSource;

fld_Qprihod: TcxEditRepositoryLookupComboBoxItem;

rashod_m: TOraQuery;

drashod_m: TOraDataSource;

prihod_m: TOraQuery;

dprihod_m: TOraDataSource;

rashod_mM: TFloatField;

prihod_mM: TFloatField;

spis_m: TOraQuery;

dspis_m: TOraDataSource;

spis_mM: TFloatField;

Q1: TOraQuery;

dq1: TOraDataSource;

Qprihod_for_spis: TOraQuery;

dQprihod_for_spis: TOraDataSource;

fld_prihod_for_spis: TcxEditRepositoryLookupComboBoxItem;

Q2: TOraQuery;

dQ2: TOraDataSource;

s_oborud: TOraQuery;

ds_oborud: TOraDataSource;

fld_oborud: TcxEditRepositoryLookupComboBoxItem;

Q3: TOraQuery;

dQ3: TOraDataSource;

users_level: TOraQuery;

dusers_level: TOraDataSource;

procedure rashodAfterPost(DataSet: TDataSet);

procedure prihodAfterInsert(DataSet: TDataSet);

procedure rashodAfterInsert(DataSet: TDataSet);

procedure spisAfterInsert(DataSet: TDataSet);

procedure DataModuleCreate(Sender: TObject);

private

{ Private declarations }

public

{ Public declarations }

end;

var

dm: Tdm;

implementation

{$R *.dfm}

procedure Tdm.rashodAfterPost(DataSet: TDataSet);

begin

dm.Qprihod.Active:=false;

dm.Qprihod.Active:=true;

dm.Qprihod_for_spis.Active:=false;

dm.Qprihod_for_spis.Active:=true;

end;

procedure Tdm.prihodAfterInsert(DataSet: TDataSet);

begin

dm.prihod_m.active:=false;

dm.prihod_m.active:=true;

dm.prihod.FieldByName('id_prihod').asfloat:=(dm.prihod_Mm.Value);

end;

procedure Tdm.rashodAfterInsert(DataSet: TDataSet);

begin

dm.rashod_m.active:=false;

dm.rashod_m.active:=true;

dm.rashod.FieldByName('id_rashod').asfloat:=dm.rashod_mM.Value;

end;

procedure Tdm.spisAfterInsert(DataSet: TDataSet);

begin

dm.spis_m.active:=false;

dm.spis_m.active:=true;

dm.spis.FieldByName('id_spisanie').asfloat:=(dm.spis_mm.Value);

end;

procedure Tdm.DataModuleCreate(Sender: TObject);

begin

end;

end.

program Project1;

uses

Forms,

frm_main in 'frm_main.pas' {frmmain},

frmlogin in 'frmlogin.pas' {frm_login},

Unit2 in 'Unit2.pas' {prihod},

frmsprav in 'frmsprav.pas' {frm_sprav},

Unit3 in 'Unit3.pas' {rashod},

Unit4 in 'Unit4.pas' {inv},

Unit5 in 'Unit5.pas' {spis},

Unit6 in 'Unit6.pas' {zapr},

frm_rep in 'frm_rep.pas' {rep},

dmora in 'dmora.pas' {dm: TDataModule},

Unit1 in 'Unit1.pas' {ins},

Unit7 in 'Unit7.pas' {ins_spips},

Unit8 in 'Unit8.pas' {Form8};

{$R *.res}

begin

Application.Initialize;

Application.CreateForm(Tdm, dm);

Application.CreateForm(Tfrmmain, frmmain);

Application.CreateForm(Tfrm_login, frm_login);

Application.Run;

end.

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