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

Основные понятия теории реляционных баз данных. Технология и модели "клиент-сервер". Применение CASE-средств для информационного моделирования в системах обработки данных. Использование слоя RPC для распределенной обработки данных на платформе Windows NT.

Рубрика Программирование, компьютеры и кибернетика
Вид дипломная работа
Язык русский
Дата добавления 19.06.2011
Размер файла 462,9 K

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

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

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

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

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

2.5 Блокировать все кэшируемые данные

В InterBase 4.0 предусмотрена специальная технология, которая называется обновлением кэша. Используя это средство, приложение IDAPI может идентифицировать диапазон интересующих его записей и регистрирует это на сервере. Когда в записи из этого диапазона происходит изменение (например, параллельно работающий пользователь модифицирует запись), сервер инициирует событие, которое уведомляет клиентское приложение с помощью механизмов уведомления о событиях - InterBase 4.0 Event Alerters. Клиентское приложение получает это событие и может либо игнорировать его, либо запросить изменение записей в данном диапазоне.

InterBase 4.0 допускает использование для хранения данных и работы с ними нескольких национальных наборов символов. Для всех строковых операций и операций с объектами BLOB поддерживаются как 8-битовые, так и 16-битовые наборы. Заданный по умолчанию набор символов и порядок сравнения можно определить для базы данных в целом. Сравнение можно также определить с помощью предложения Order By в операторе Select. Для спецификации символов национальных алфавитов можно использовать строковые литералы с префиксом имени набора символов. В стандартный комплект поставки включена поддержка кодовой таблицы ANSI 1251, являющейся стандартом при работе с русским языком в среде Windows.

2.6 Выбор средств разработки

В качестве CASE-средства использован программный продукт ERWin 2.5 фирмы Logic Works. ERwin - средство разработки структуры базы данных. ERwin сочетает графический интерфейс Windows, инструменты для построения ER-диаграмм, редакторы для создания логического и физического описания модели данных и прозрачную поддержку ведущих реляционных СУБД и настольных баз данных. С помощью ERwin можно создавать или проводить обратное проектирование (реинжиниринг) баз данных.

Предыдущие версии ERwin - 1.5 и 2.1 - завоевали все возможные призы среди программ своего класса, в том числе DBMS Readers' Choice в 1992, 1993, 1994, 1995 годах, Software Development Productivity Award 1993, Data Based Advisor Readers' choice 1992 и 1994. Текущая версия продукта - 2.6.

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

Для написания клиентской части приложений использована среда разработчика Borland Delphi C/S 2.01. Delphi относится к средствам быстрой разработки приложений (RAD - Rapid Applications Development). Определяющим фактором при выборе Delphi в качестве средства разработки клиентской части является наличие большой библиотеки объектов для быстрого построения приложений, работающих с базами данных. Кроме того, Delphi поддерживает интерфейс PVCS, что позволяет вести параллельную разработку проекта несколькими программистами.

Для разработки процессов, функционирующих на стороне сервера использована среде разработки Microsoft Visual C 4.2 из пакета Microsoft Developer Studio. Эта среда сочетает в себе мощь языка C++, удобные средства отладки программ и навигации по тексту. Кроме того, она позволяет использовать в программах все возможности операционной системы (RPC, RAS, TAPI, сервисы Windows NT).

2.7 Организация взаимодействия между серверами

Выбор модели распределенной базы данных

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

Модель взаимодействия

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

Процесс-клиент (сервер 1)

Среда передачи данных

Процесс-сервер (сервер 2)

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

Для организации обмена информацией в общем случае необходимо разработать протокол этого обмена, что само по себе является достаточно сложной задачей. Кроме того, необходимо реализовать поддержку сервисом различных транспортных протоколов (TCP/IP, NetBIOS, IPX/SPX), что выливается в многократное дублирование программного кода. Для решения этой задачи использован слой вызова удаленных процедур Microsoft RPC (Microsoft Remote Procedure Call).

2.8 Использование слоя RPC для распределенной обработки данных на платформе Windows NT

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

Слой Microsoft RPC - только часть стандарта среды для распределенных вычислений, названной OSF (Open Software Foundation), разработанной группой компаний для определения компонентов сетевой среды, которая поддерживает распределенные вычисления.

2.9 Компоненты Microsoft RPC

Microsoft RPC включает следующие основные компоненты:

Компилятор MIDL (Microsoft IDL)

Библиотеки времени выполнения и заголовочные файлы.

Модули транспортного интерфейса

Сервис разрешения имен

Сервис поддержки конечной точки

В модели PRC можно формально определить интерфейс для удаленной процедуры, используя язык, специально разработанный для этой цели. Этот язык - IDL (Interface Definition Language - язык определения интерфейсов). Диалект языка, реализованный фирмой Microsoft, назван MIDL (Microsoft IDL).

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

2.10 Механизм работы RPC

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

Рис. 2.2 - Механизм работы RPC.

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

Запрашивает необходимые параметры из адресного пространства клиента.

Переводит параметры в стандартную форму представления данных в сети (NDR - standard network data representation)

Вызывает необходимые функции из библиотеки времени выполнения RPC для отсылки запроса с параметрами на сервер.

Заглушка сервера выполняет следующие шаги:

Библиотека времени выполнения RPC принимает запрос и вызывает процедуру заглушки сервера

Заглушка сервера принимает параметра из буфера и конвертирует их из формата NDR в формат, процедуры сервера.

Заглушка вызывает необходимую процедуру на сервере.

Удаленная процедура выполняется, генерирует выходные параметры и возвращаемое значение. Когда процедура завершена, следующие шаги возвращают данные клиенту:

Удаленная процедура возвращает данные заглушке сервера

Заглушка сервера конвертирует возвращаемые параметры в формат NDR и возвращает их функции библиотеки времени выполнения RPC

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

Клиент завершает процесс принятием данных из сети и их возвратом вызывающей функции:

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

Заглушка клиента конвертирует данные из формата NDR в формат, используемый клиентским приложением

Приложение клиента продолжает свою работу.

Для Microsoft Windows и Windows NT библиотеки времени выполнения используются двумя путями: как статическая библиотека, линкуемая в приложение; и библиотека, реализованная как DLL.

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

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

2.11 Организация логического канала передачи данных

Другой компонент модели - среда передачи данных может быть реализована несколькими способами. В простейшем случае она может быть построена на базе асинхронных каналов связи с использованием протоколов PPP (Point to Point Protocol), а также на базе существующих сетей X.25. На системный сервис можно также возложить ответственность за установление логического канала между серверами.

В случае каналов X.25 для установления соединения используется специальная каналообразующая аппаратура (коммутаторы X.25).

Решением начального уровня может служить удаленный доступ по протоколу PPP (Point to Point Protocol). Организация удаленного доступа по асинхронным каналам связи по протоколу PPP рассмотрена ниже.

Организация доступа удаленных пользователей

Необходимость удаленного доступа

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

Использование слоя RAS для удаленного доступа на платформе Windows NT

На платформе Windows NT задача удаленного доступа по протоколу PPP решается с помощью сервера RAS (Remote Access Server - сервер удаленного доступа). Сервер RAS - это процесс, который принимает и обрабатывает запросы клиентов на подключение через асинхронные линии и передачу данных. Схема взаимодействия удаленного клиента с сервером RAS приведена на рис. 2.3.

Рис. 2.3 - Схема удаленного доступа с использованием RAS

В качестве транспортного протокола могут использоваться протоколы TCP/IP, IPX/SPX, NetBIOS. Подключение клиента через сервер удаленного доступа абсолютно прозрачно, т.е. клиент может работать с удаленными серверами так, как если бы он находился в локальной сети.

В системе Windows NT существует программный интерфейс приложений (Application Program Interface), который позволяет установить логический канал с удаленной сетью по асинхронному соединению. Он носит название RAS API (Remote Access Service API).

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

Win32 RAS позволяет RAS-клиенту установить соединение, получить информацию о существующих соединениях и завершить соединение. Связь осуществляется по протоколам PPP или SLIP. В качестве транспортного протокола могут быть использованы стеки TCP/IP, IPX/SPX и NetBIOS.

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

Обеспечение информационной безопасности при удаленном доступе

Учитывая то, что информация на серверах баз данных носит коммерческий характер, особую роль играет вопрос её защиты от несанкционированного доступа. Система Windows NT имеет сертификат соответствия уровню безопасности C2 Министерства обороны США. Данный уровень безопасности предполагает обязательную идентификацию пользователей системы для определения прав доступа к отдельным ресурсам системы. Удаленный вход в сеть также требует соответствующих привилегий, кроме того, все попытки удаленного доступа обязательно фиксируются в журнале событий. В систему Windows NT встроена возможность шифрования трафика в каналах передачи данных, таким образом злоумышленник, имеющий возможность перехвата данных в каналах связи, не получает доступа к жизненно важным данным (пароли и имена пользователей, финансовая информация).

Одним из способов ограничения доступа удаленных пользователей к ресурсам сети является использования так называемых серверов-барьеров (FireWalls) на стыке внутренней и внешней (какой в данном случае является удаленный пользователь) сетей. В данном случае можно гибко регулировать права удаленного пользователя на доступ к отдельным компьютерам в сети. Кроме того, серверы-барьеры скрывают топологию сети от внешнего пользователя. На платформе Windows NT функции сервера-барьера выполняет продукт Microsoft Proxy Server. Одним из побочных эффектов использования этого класса продуктов является экономия IP-адресов.

Проектирование структуры базы данных

Построим информационную модель системы расчета с абонентами.

В ходе исследования существующей схемы расчетов были выявлены следующие основные сущности:

Клиент (абонент, владелец телефона)

Услуга

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

Начисление

Телефонный разговор, подлежащий повременной тарификации

Начисление за повременные разговоры (за один день)

Оплата

Категория клиента

Проведенные расчеты

IDEF1X-диаграмма взаимодействия между этими сущностями представлена в Приложении 6.

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

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

Клиент (владелец телефона)

Услуга

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

Начисление

Постоянное начисление

Категория клиента

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

Рис. 2.4 - Структура данных для поддержки механизма регистрации изменений

Суть данной модели такова:

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

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

Сущность однозначно идентифицируется своим внешним ключом и актуальной датой.

Дочерние таблицы ссылаются на сущность по её внешнему ключу.

При смене состояния внешний ключ не меняется.

Целостность данных обеспечивается с помощью триггеров на сервере.

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

Картотека абонентов

Начисления

Повременный учет

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

SQL-скрипт для генерации базы данных представлен в Приложении 1.

Схема репликации данных

Тиражирование данных в системе построено по схеме с одним сервером подписки (центральный сервер) и множеством серверов репликации (районы).

Рис. 2.5 - Организация репликации данных

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

Рис. 2.6 - Подробная схема репликации данных

Схема репликации приведена на рис. 2.6. Рассмотрим процесс передачи изменений подробнее:

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

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

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

Сервер подписки принимает измененную запись и модифицирует соответствующим образом таблицу на своей стороне.

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

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

При передаче изменений коммуникационным сервисом используется протокол двухфазной фиксации транзакций (Two-phase commit transactions), что позволяет застраховаться от ошибок.

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

Проектирование коммуникационного сервера

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

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

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

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

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

Учитывая разнородность сети необходимо обеспечить возможность подключения пользователей по нескольким протоколам: TCP/IP, Named Pipes, IPX/SPX, NetBIOS.

Архитектура коммуникационного сервера

Учитывая специфику платформы Windows NT коммуникационный сервер построен по архитектуре системного сервиса (System Service). Для разработки коммуникационного сервера применялась среда разработчика Microsoft Developer Studio 4.2/Visual C++ Enterprise Edition.

Архитектура сервера представлена в Приложении 2.

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

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

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

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

void TaskProc(void) - основной поток - реализует необходимую функциональность.

void Terminate(void) - функция для принудительного останова задачи (например при останове сервера)

Информация о пользовательских задачах хранится в реестре Windows NT

(ключ HKEY_LOCAL_MACHINE\SOFTWARE\Svyazinform\CommService\Tasks, рис. 2.7).

Рис. 2.7 - Конфигурация задач коммуникационного сервера в реестре Windows NT

база данные клиент сервер удаленный

Ядро cервера построено по многопоточной архитектуре и включает в себя следующие модули:

Модуль инициализации - основная точка входа сервиса - регистрирует сервис в диспетчере сервисов.

Модуль управления сервисом - реализует функции запуска и останова сервера.

Планировщик задач - осуществляет запуск пользовательских задач в заданное время.

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

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

Вспомогательное программное обеспечение

Для установки коммуникационного сервиса разработана программа, регистрирующая сервис в системе и создающая необходимые ключи в реестре Windows NT. Исходный код программы представлен в Приложении 4.

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

Для удаленного конфигурирования пользовательских задач разработано клиентское приложение «Менеджер задач коммуникационного сервера».

Данная программа позволяет управлять списком пользовательских задач (именами модулей и временем запуска). Главное окно программы представлено на рис. 2.8.

Рис. 2.8 - Главное окно программы конфигурирования коммуникационного сервера

Разработка программы велась с помощью пакета Microsoft Visual C++ 4.2. Механизм реализации этой программы выходит за рамки данного дипломного проекта.

3. Технико-экономическое обоснование

Целью дипломного проекта было создание информационной системы для автоматизации расчетов с абонентами АО «Связьинформ» РМ.

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

План выполнения дипломного проекта

В соответствие с темой дипломного проекта определяются этапы НИР и их содержание. Этапы НИР необходимо максимально детализировать.

Табица 3.1 - Этапы НИР

№ n/n

Этап и содержание работы

Длительность цикла, дн.

Трудоемкость в % от общей трудоемкости

Исполнитель

1

2

3

4

5

1

Постановка задачи и составление технического задания

5

3,1

И1, Р, Д

2

Составление плана и календарного графика работы

1

0,7

Д, Р

3

Подбор и изучение технической документации и литературы

14

10,55

Д, Р

4

Написание вводной части и литературного обзора

5

4,35

Д

5

Информационное моделирование системы

28

20,25

Д, Р

6

Разработка коммуникационного сервера

12

6,28

Д

7

Отладка коммуникационного сервера

18

8,35

Д, Р

1

2

3

4

5

8

Написание теоретической части работы

15

14,07

Д, Р

9

Выводы по теоретической части проекта

2

2,1

Д, Р

10

Подбор данных и расчет экономической части проекта

4

2,85

Д, К1

11

Анализ проделанной работы

2

1,65

Д

12

Составление пояснительной записки к дипломному проекту

12

8,4

Д

13

Оформление графической части работы

12

10,75

Д

14

Оформление приложений к дипломному проекту

5

3,025

Д

15

Сдача работы на отзыв руководителю

2

1,65

Д

16

Сдача работы на рецензирование

2

1,2

Д

17

Сдача дипломного проекта на кафедру

1

0,725

Д

ИТОГО:

140

100

Примечание: Д-дипломник;

И1-инженер-консультант

Р-руководитель

К1-консультант по экономической части

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

3.1 Расчет ожидаемой продолжительности выполнения работ и их дисперсий

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

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

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

Т max-максимальное время выполнения работы при наиболее неблагоприятных условиях её выполнения;

Одновременно с расчетом величины Тож. Определяют дисперсию (разброс) по формуле:

Дисперсия определяет степень неопределенности выполнения работы за ожидаемое время Тож.

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

Табила 3.2 - Продолжительность работ

№ n/n

Этап и содержание работы

Tmin

Tн.в.

Tmax

Tож

Di

1

2

3

4

5

6

7

1

Постановка задачи и составление технического задания

3

5

7

5

0,44

2

Составление плана и календарного графика работы

1

1

2

1,167

0,03

3

Подбор и изучение технической документации и литературы

12

14

16

14

0,44

4

Написание вводной части и литературного обзора

3

5

7

5

0,44

5

Информационное моделирование системы

26

28

29

27,8

0,25

6

Разработка коммуникационного сервера

11

12

14

12,2

0,25

1

2

3

4

5

6

7

7

Отладка коммуникационного сервера

16

18

20

18

0,44

8

Написание теоретической части работы

13

15

17

15

0,44

9

Выводы по теоретической части проекта

1

2

2

1,8

0,027

10

Подбор данных и расчет экономической части проекта

3

4

6

4,2

0,25

11

Анализ проделанной работы

1

2

2

1,8

0,27

12

Составление пояснительной записки к дипломному проекту

10

12

14

12

0,44

13

Оформление графической части работы

11

12

13

12

0,44

14

Оформление приложений к дипломному проекту

4

5

5

4,8

0,027

15

Сдача работы на отзыв руководителю

2

2

3

2,2

0,027

16

Сдача работы на рецензирование

1

2

3

2

0,11

17

Сдача дипломного проекта на кафедру

1

1

1

1

0

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

3.2 Построение ленточного графика выполнения работы

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

Продолжительность каждой работы Tn определяется по формуле:

гдеTi- трудоемкость работ (чел./дн.)

Ci- численность исполнителей (чел.)

Таблица 3.3 - Ленточный график выполнения работ

№ n/n

Этап и содержание работы

Трудоемкость (чел./дн.)

Численность (чел.)

Длит-ть работы (дн.)

1

2

3

4

5

1

Постановка задачи и составление технического задания

5

3

1,67

2

Составление плана и календарного графика работы

1

2

0,5

3

Подбор и изучение технической документации и литературы

14

2

7

4

Написание вводной части и литературного обзора

5

1

5

5

Информационное моделирование системы

28

2

14

6

Разработка коммуникационного сервера

12

1

12

7

Отладка коммуникационного сервера

18

2

9

8

Написание теоретической части работы

15

2

7,5

9

Выводы по теоретической части проекта

2

2

1

10

Подбор данных и расчет экономической части проекта

4

2

2

11

Анализ проделанной работы

2

1

2

12

Составление пояснительной записки к дипломному проекту

12

1

12

13

Оформление графической части работы

12

1

12

14

Оформление приложений к дипломному проекту

5

1

5

15

Сдача работы на отзыв руководителю

2

1

2

16

Сдача работы на рецензирование

2

1

2

17

Сдача дипломного проекта на кафедру

1

1

1

ИТОГО:

140

94,67

3.3 Определение плановой себестоимости НИР

Целью расчета себестоимости НИР является экономически обоснованной определение величины затрат на её выполнение. В плановую себестоимость включают все затраты, связанные с выполнением работы, независимо от источника финансирования. Определение затрат производится путем составления затрат на НИР.

Смета затрат на НИР должна быть представлена по следующим статьям калькуляции:

Материалы, покупные изделия и полуфабрикаты;

Спецоборудование для научных исследований;

Расходы на силовую электроэнергию.

Основная заработная плата производственного персонала;

Отчисления на социальное страхование;

Косвенные (накладные) расходы отдела(кафедры);

Производственные командировки;

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

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

Общеуниверситетские косвенные расходы;

Расходы на научно-техническую информацию;

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

Отчисления в пенсионный фонд;

Отчисления в фонд занятости;

Отчисления на медицинское страхование;

Затраты на эксплуатацию оборудования (амортизацию).

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

Табица 3.4 - Стоимость покупных изделий

Изделие

Количество

Цена за единицу, руб

Сумма, руб

Дискета 3.5''

1

5500

5500

Ватман

5

5000

25000

Бумага

1

30000

30000

ИТОГО:

60500

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

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

В качестве базы для расчета заработной платы принимается месячный оклад кандидата наук в размере 345000 руб. (13 разряд), что составляет в пересчете на 1 учебный час работы при 800-часовой годовой нагрузке:

(345000 * 12) / 800 = 5175 (руб./час)

Руководство дипломным проектированием оценивается преподавателем в 6 учебных часов. Таким образом, получим основную заработную плату производственного персонала в размере:

5175 * 26 = 134550 (руб.)

Отчисление на социальное страхование. По условию договора составляют 5,4% от заработной платы (п.4). Сумма расходов по статье 7265 руб.

Косвенные (накладные) расходы кафедры условиями договора не предусмотрены.

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

Контрагентные работы не проводились, расходы отсутствуют.

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

Общевузовские расходы. По условиям договора берутся 15% от заработной платы (от п.4) и составляют 20183 руб.

Расходы на научно-техническую информацию отсутствуют.

Расходы на зарубежные лицензии и патенты отсутствуют.

Отчисления в пенсионный фонд. Данные расходы берутся в размере 1% от основной заработной платы производственного персонала (п.4) и составляют 1345 руб.

Отчисления в фонд занятости. Расходы по данной статье 2% от основной заработной платы производственного персонала (п.4) или 2691 руб.

Отчисления на медицинское страхование. На эти нужды отчисляется 3,6% от основной заработной платы производственного персонала (п.4) или 4844 руб.

Затраты на эксплуатацию оборудования (амортизацию). В процессе работы над проектом использовались персональный компьютер IBM PC Pentium 133 и принтер. Отчисления на амортизацию данной техники составляют 3200 руб. за 1 час работы и составляют при 300-часовой эксплуатации компьютера и 5-часовой принтера

3200 * (300 + 5) = 976000 руб.

Результаты калькуляции по статьям сведены в таблицу

Табица 3.5 - Калькуляция по статьям расходов

Статья расходов

Сумма, руб.

Материалы, покупные изделия и полуфабрикаты

60500

Основная заработная плата производственного персонала

134550

Отчисления на социальное страхование (5,4% от зарплаты)

7265

Отчисления в фонд занятости (2% от зарплаты)

2691

Отчисления на медицинское страхование (3,6 % от зарплаты)

4844

Налог на содержание МВД (1% от минимальной заработной платы)

835

Общеуниверситетские косвенные расходы (15% от зарплаты)

20183

Отчисления в пенсионный фонд (1% от зарплаты)

1345

Затраты на эксплуатацию оборудования (амортизацию)

976000

ИТОГО:

1207213

Заключение

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

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

Отдельная глава посвящена технико-экономическому обоснованию данного дипломного проекта.

Список литературы

1. Borland InterBase Workgroup Server. API Guide. - Borland International Inc, 1995 - 330 c.

2. Borland InterBase Workgroup Server. DataDefinition Guide. - Borland International Inc, 1995 - 212 c.

3. Borland InterBase Workgroup Server. Language Reference. - Borland International Inc, 1995 - 234 c.

4. Borland InterBase Workgroup Server. Programmer's Guide. - Borland International Inc, 1995 - 340 c.

5. Microsoft Online Documentation: Win32 Programmers Reference.

6. R.Barker "CASE* Method - Entity Relationship Modelling". - Oracle Inc., 1990 - 243 c.

7. Биллиг В.А., Мусикаев И.Х. «Visual C++ 4. Книга для программистов». - М.: Издательский отдел «Русская редакция» ТОО «Channel Trading Ltd.», 1996. - 352 с. ил.

8. Галатенко В. «Информационная безопасность - обзор основных положений: Ч1»: - Информационный бюллетень Jet Info №1/1996.

9. Галатенко В. «Информационная безопасность - обзор основных положений: Ч2»: - Информационный бюллетень Jet Info №2/1996.

10. Галатенко В. «Информационная безопасность - обзор основных положений: Ч3»: - Информационный бюллетень Jet Info №3/1996.

11. Грабер Мартин. “Введение в SQL”. Пер. с англ. - М.: Издательство “ЛОРИ”, 1996. - 375 с.

12. Зубанов Ф. «Windows NT - выбор «профи»». - М.: Издательский отдел «Русская редакция» ТОО «Channel Trading Ltd.», 1996. - 392 с.

13. Кастер Х. «Основы Windows NT и NTFS». Пер. с англ. - М: Издательский отдел «Русская редакция» ТОО «Channel Trading Ltd.», 1996. - 440 с.

14. Ладыженский Глеб. «СУБД - коротко о главном»: - Информационный бюллетень Jet Info №3-5/1995.

15. Ларин Л.С., Челдаева Л.А., Гуськова Н.Д."Технико-экономическое обоснование дипломных проектов", Саранск, 1983, 100 с.

16. «Решения Microsoft» - Вып. 4. - М: АООТ «Типография Новости», 1996. 124 с.

17. «Решения Microsoft» - Вып. 5. - М: АООТ «Типография Новости», 1997. 132 с.

18. Рихтер Дж.. «Windows для профессионалов (Программирование в Win32 API для Windows 95 и Windows NT)». Пер. с англ. - М: Издательский отдел «Русская редакция» ТОО «Channel Trading Ltd.», 1995. - 720 с.

19. Паппас К., Мюррей У.. «Visual C++. Руководство для профессионалов»: пер. с англ. - Спб.: BHV - Санкт-Петербург, 1996. - 912 с.

20. «Сетевые средства Windows NT»: Пер. с англ. - СПб.: BHV - Санкт-Петербург, 1996 - 496 с.

21. Фролов А.В., Фролов Г.В. «Microsoft Visual C++ и MFC». - М: Диалог-МИФИ, 1996 - 288 с.

22. Фролов А.В., Фролов Г.В. «Программирование для Windows NT: Ч2». - М: Диалог-МИФИ, 1997 - 271 с.

23. Янг М. «Mastering Microsoft Visual C++». Пер. с англ.- К.: ВЕК+, М.: ЭНТРОП, 1997. - 704 с.

Приложение 1

SQL-скрипт для генерации базы данных

CREATE GENERATOR genUslPropsKeys;

CREATE GENERATOR genUslProps;

CREATE GENERATOR genPhonesRegions;

CREATE GENERATOR genPhonesStations;

CREATE GENERATOR genPhonesStreets;

CREATE GENERATOR genPhonesBanks;

CREATE GENERATOR genTalksPay;

CREATE GENERATOR genTalks;

CREATE GENERATOR genNach;

CREATE GENERATOR genNachBillings;

CREATE GENERATOR genNachBillDates;

CREATE GENERATOR genNachConstUsl;

CREATE GENERATOR genUslDivisions;

CREATE GENERATOR genUslLgots;

CREATE GENERATOR genUslsKeys;

CREATE GENERATOR genUsls;

CREATE GENERATOR genUslCatKeys;

CREATE GENERATOR genUslCat;

CREATE GENERATOR genPhones;

CREATE GENERATOR genPhonesOwnersKeys;

CREATE GENERATOR genPhonesOwners;

CREATE GENERATOR genSysSettings;

CREATE GENERATOR genPhonesKeys;

CREATE GENERATOR genPlat;

CREATE GENERATOR genPhonesPostStations;

CREATE GENERATOR genSysLog;

CREATE GENERATOR genUslTypes;

CREATE GENERATOR genUslDivisionsKeys;

CREATE DOMAIN CALLTIME_TYPE INTEGER NOT NULL;

CREATE DOMAIN CURR_TYPE FLOAT DEFAULT 0 NOT NULL;

CREATE DOMAIN DATE_TYPE DATE NOT NULL;

CREATE DOMAIN DESCR_TYPE CHAR(32);

CREATE DOMAIN PHONE_TYPE CHAR(7) NOT NULL;

CREATE DOMAIN PROCENT_TYPE FLOAT DEFAULT 100 NOT NULL

CHECK (VALUE BETWEEN 0 AND 300);

CREATE TABLE Nach (

Code INTEGER NOT NULL,

Owner INTEGER NOT NULL,

Usl INTEGER NOT NULL,

Phone INTEGER,

UslSum CURR_TYPE,

NachDate DATE_TYPE,

BillDate DATE_TYPE

);

ALTER TABLE Nach

ADD CONSTRAINT XPKNach PRIMARY KEY (Code);

CREATE TABLE NachBillDates (

Code INTEGER NOT NULL,

BillingDate INTEGER NOT NULL

);

ALTER TABLE NachBillDates

ADD CONSTRAINT XPKBillDates PRIMARY KEY (Code);

CREATE TABLE NachBillings (

Code INTEGER NOT NULL,

Division INTEGER NOT NULL,

Owner INTEGER NOT NULL,

BillDateCode INTEGER NOT NULL

);

ALTER TABLE NachBillings

ADD CONSTRAINT XPKNachBillings PRIMARY KEY (Code);

CREATE TABLE NachConstUsl (

Code INTEGER NOT NULL,

Owner INTEGER NOT NULL,

Usl INTEGER NOT NULL,

Phone INTEGER NOT NULL,

UslSum CURR_TYPE,

BegDate DATE_TYPE,

EndDate DATE_TYPE

);

ALTER TABLE NachConstUsl

ADD CONSTRAINT XPKNachConstUsl PRIMARY KEY (Code);

CREATE TABLE Phones (

Code INTEGER NOT NULL,

Street INTEGER NOT NULL,

Owner INTEGER NOT NULL,

PKey INTEGER NOT NULL,

Comment DESCR_TYPE,

PhoneNmb PHONE_TYPE,

InstallDate DATE_TYPE,

RemoveDate DATE_TYPE,

BegDate DATE_TYPE,

EndDate DATE_TYPE

);

ALTER TABLE Phones

ADD CONSTRAINT XPKPhones PRIMARY KEY (Code);

CREATE TRIGGER Phones_BUH FOR Phones

BEFORE UPDATE POSITION 0

AS

BEGIN

/* Изменение BegDate */

IF (new.BegDate <> old.BegDate) THEN

BEGIN

IF (new.BegDate < old.BegDate) THEN

BEGIN

/* Расширение BegDate */

UPDATE Phones

SET EndDate = new.BegDate

WHERE ((new.BegDate BETWEEN BegDate AND EndDate) AND (PKey = new.PKey));

END

ELSE

BEGIN

/* Сужение BegDate */

UPDATE Phones

SET EndDate = new.BegDate

WHERE ((EndDate = old.BegDate) AND (PKey = new.PKey));

END

END

/* Изменение EndDate */

IF (new.EndDate <> old.EndDate) THEN

BEGIN

IF (new.EndDate > old.EndDate) THEN

BEGIN

/* Расширение EndDate */

UPDATE Phones

SET BegDate = new.EndDate

WHERE ((new.EndDate BETWEEN BegDate AND EndDate) AND (PKey = new.PKey));

END

ELSE

BEGIN

/* Сужение EndDate */

UPDATE Phones

SET BegDate = new.EndDate

WHERE ((BegDate = old.EndDate) AND (PKey = new.PKey));

END

END

/* Сборка мусора */

DELETE FROM Phones

WHERE ((BegDate >= new.BegDate) AND (EndDate <= new.EndDate) AND (PKey = new.PKey) AND (Code <> new.Code));

END ^

CREATE TRIGGER Phones_BIH FOR Phones

BEFORE INSERT POSITION 0

AS

BEGIN

DELETE FROM Phones

WHERE ((BegDate >= new.BegDate) AND (EndDate <= new.EndDate) AND (PKey = new.PKey));

UPDATE Phones

SET BegDate = new.EndDate

WHERE ((new.EndDate BETWEEN BegDate AND EndDate) AND (PKey = new.PKey));

UPDATE Phones

SET EndDate = new.BegDate

WHERE ((new.BegDate BETWEEN BegDate AND EndDate) AND (PKey = new.PKey));

END ^

CREATE TRIGGER Phones_BDH FOR Phones

BEFORE DELETE POSITION 0

AS

BEGIN

UPDATE Phones

SET EndDate = old.EndDate

WHERE ((EndDate = old.BegDate) AND (PKey = old.PKey));

END ^

CREATE TABLE PhonesBanks (

Code INTEGER NOT NULL,

Name1 DESCR_TYPE,

PMFO CHAR(12) NOT NULL,

Name2 DESCR_TYPE,

ELMFO CHAR(12) NOT NULL,

PlatCount SMALLINT NOT NULL,

Acc1 CHAR(12) NOT NULL,

Acc2 CHAR(12) NOT NULL

);

CREATE INDEX XIEPhonesBanksName ON PhonesBanks

(

Name1,

Name2

);

ALTER TABLE PhonesBanks

ADD CONSTRAINT XPKPhonesBanks PRIMARY KEY (Code);

CREATE TABLE PhonesKeys (

Code INTEGER NOT NULL

);

ALTER TABLE PhonesKeys

ADD CONSTRAINT XPKPhonesKeys PRIMARY KEY (Code);

CREATE TABLE PhonesOwners (

Code INTEGER NOT NULL,

PKey INTEGER NOT NULL,

Name1 DESCR_TYPE,

Name2 DESCR_TYPE,

Category INTEGER NOT NULL,

Bank INTEGER,

Street INTEGER NOT NULL,

PostStation INTEGER,

House CHAR(5),

Corpus CHAR(3),

Flat CHAR(3),

Account CHAR(5),

RS CHAR(9),

INN CHAR(13),

Nmb_Dogov CHAR(6),

Date_Dogov DATE,

BegDate DATE_TYPE,

EndDate DATE_TYPE

);

ALTER TABLE PhonesOwners

ADD CONSTRAINT XPKPhonesOwners PRIMARY KEY (Code);

CREATE TRIGGER PhonesOwners_BUH FOR PhonesOwners

BEFORE UPDATE POSITION 0

AS

BEGIN

/* Изменение BegDate */

IF (new.BegDate <> old.BegDate) THEN

BEGIN

IF (new.BegDate < old.BegDate) THEN

BEGIN

/* Расширение BegDate */

UPDATE PhonesOwners

SET EndDate = new.BegDate

WHERE ((new.BegDate BETWEEN BegDate AND EndDate) AND (PKey = new.PKey));

END

ELSE

BEGIN

/* Сужение BegDate */

UPDATE PhonesOwners

SET EndDate = new.BegDate

WHERE ((EndDate = old.BegDate) AND (PKey = new.PKey));

END

END

/* Изменение EndDate */

IF (new.EndDate <> old.EndDate) THEN

BEGIN

IF (new.EndDate > old.EndDate) THEN

BEGIN

/* Расширение EndDate */

UPDATE PhonesOwners

SET BegDate = new.EndDate

WHERE ((new.EndDate BETWEEN BegDate AND EndDate) AND (PKey = new.PKey));

END

ELSE

BEGIN

/* Сужение EndDate */

UPDATE PhonesOwners

SET BegDate = new.EndDate

WHERE ((BegDate = old.EndDate) AND (PKey = new.PKey));

END

END

/* Сборка мусора */

DELETE FROM PhonesOwners

WHERE ((BegDate >= new.BegDate) AND (EndDate <= new.EndDate) AND (PKey = new.PKey) AND (Code <> new.Code));

END ^

CREATE TRIGGER PhonesOwners_BIH FOR PhonesOwners

BEFORE INSERT POSITION 0

AS

BEGIN

DELETE FROM PhonesOwners

WHERE ((BegDate >= new.BegDate) AND (EndDate <= new.EndDate) AND (PKey = new.PKey));

UPDATE PhonesOwners

SET BegDate = new.EndDate

WHERE ((new.EndDate BETWEEN BegDate AND EndDate) AND (PKey = new.PKey));

UPDATE PhonesOwners

SET EndDate = new.BegDate

WHERE ((new.BegDate BETWEEN BegDate AND EndDate) AND (PKey = new.PKey));

END ^

CREATE TRIGGER PhonesOwners_BDH FOR PhonesOwners

BEFORE DELETE POSITION 0

AS

BEGIN

UPDATE PhonesOwners

SET EndDate = old.EndDate

WHERE ((EndDate = old.BegDate) AND (PKey = old.PKey));

END ^

CREATE TABLE PhonesOwnersKeys (

Code INTEGER NOT NULL,

InRest CURR_TYPE,

OutRest CURR_TYPE,

NDolg INTEGER NOT NULL

);

ALTER TABLE PhonesOwnersKeys

ADD CONSTRAINT XPKPhonesOwnersKeys PRIMARY KEY (Code);

CREATE TABLE PhonesPostStations (

Code INTEGER NOT NULL,

Name DESCR_TYPE,

Region INTEGER NOT NULL,

PostIndex CHAR(6) NOT NULL,

PostNmb CHAR(6) NOT NULL

);

CREATE UNIQUE INDEX XAKPhonesPostStationsIndex ON PhonesPostStations

(

PostIndex

);

CREATE UNIQUE INDEX XAKPhonesPostStationsPostNmb ON PhonesPostStations

(

PostNmb

);

CREATE INDEX XIEPhonesPostStationsName ON PhonesPostStations

(

Name

);

ALTER TABLE PhonesPostStations

ADD CONSTRAINT XPKPhonesPostStations PRIMARY KEY (Code);

CREATE TABLE PhonesRegions (

Code INTEGER NOT NULL,

Name DESCR_TYPE NOT NULL

);

CREATE INDEX XIEPhonesRegionsName ON PhonesRegions

(

Name

);

ALTER TABLE PhonesRegions

ADD CONSTRAINT XPKPhonesRegions PRIMARY KEY (Code);

CREATE TABLE PhonesStations (

Code INTEGER NOT NULL,

Region INTEGER NOT NULL,

Name DESCR_TYPE NOT NULL

);

CREATE INDEX XIEPhonesStationsName ON PhonesStations

(

Name

);

ALTER TABLE PhonesStations

ADD CONSTRAINT XPKPhonesStations PRIMARY KEY (Code);

CREATE TABLE PhonesStreets (

Code INTEGER NOT NULL,

Station INTEGER NOT NULL,

Region INTEGER NOT NULL,

Name DESCR_TYPE

);

CREATE INDEX XIEPhonesStreetsName ON PhonesStreets

(

Name

);

ALTER TABLE PhonesStreets

ADD CONSTRAINT XPKPhonesStreets PRIMARY KEY (Code);

CREATE TABLE Plat (

Code INTEGER NOT NULL,

Owner INTEGER NOT NULL,

ToUsl INTEGER,

PlatDate DATE_TYPE,

PlatType INTEGER NOT NULL,

DocNmb CHAR(12) NOT NULL

);

ALTER TABLE Plat

ADD CONSTRAINT XPKPlat PRIMARY KEY (Code);

CREATE TABLE SysLog (

Code INTEGER NOT NULL,

TableName CHAR(16) NOT NULL,

OpType INTEGER NOT NULL,

NewData CHAR(64) NOT NULL,

OpDate DATE NOT NULL

);

ALTER TABLE SysLog

ADD CONSTRAINT XPKSysLog PRIMARY KEY (Code);

CREATE TABLE SysSettings (

Code INTEGER NOT NULL,

TimeTalksUsl INTEGER NOT NULL,

NullOwner INTEGER NOT NULL

);

ALTER TABLE SysSettings

ADD CONSTRAINT XPKSysSettings PRIMARY KEY (Code);

CREATE TABLE Talks (

Code INTEGER NOT NULL,

DayCode INTEGER NOT NULL,

Phone INTEGER NOT NULL,

ToPhone INTEGER NOT NULL,

CallTime CALLTIME_TYPE,

PhoneNmb PHONE_TYPE,

HowLong INTEGER NOT NULL,

ToPhoneNmb PHONE_TYPE,

Calculated SMALLINT NOT NULL,

CallDate DATE_TYPE

);

CREATE INDEX XAK1TalksCallDate ON Talks

(

CallDate

);

ALTER TABLE Talks

ADD CONSTRAINT XPKTalks PRIMARY KEY (Code);

CREATE TABLE TalksPay (

Code INTEGER NOT NULL,

Phone INTEGER NOT NULL,

TotalSum CURR_TYPE,

TotalLgotTime CALLTIME_TYPE,

TotalFullTime CALLTIME_TYPE,

TotalTime COMPUTED BY (TotalLgotTime+TotalFullTime),

CallDate DATE_TYPE

);

ALTER TABLE TalksPay

ADD CONSTRAINT XPKTalksPay PRIMARY KEY (Code);

CREATE TABLE UslCat (

Code INTEGER NOT NULL,

PKey INTEGER NOT NULL,

Name DESCR_TYPE,

Parent INTEGER NOT NULL,

BegDate DATE_TYPE,

EndDate DATE_TYPE

);

CREATE INDEX XIEUslCatName ON UslCat

(

Name

);

CREATE INDEX XIEUslCatParent ON UslCat

(

Parent

);

ALTER TABLE UslCat

ADD CONSTRAINT XPKUslCat PRIMARY KEY (Code);

CREATE TRIGGER UslCat_BUH FOR UslCat

BEFORE UPDATE POSITION 0

AS

BEGIN

/* Изменение BegDate */

IF (new.BegDate <> old.BegDate) THEN

BEGIN

IF (new.BegDate < old.BegDate) THEN

BEGIN

/* Расширение BegDate */

UPDATE UslCat

SET EndDate = new.BegDate

WHERE ((new.BegDate BETWEEN BegDate AND EndDate) AND (PKey = new.PKey));

END

ELSE

BEGIN

/* Сужение BegDate */

UPDATE UslCat

SET EndDate = new.BegDate

WHERE ((EndDate = old.BegDate) AND (PKey = new.PKey));

END

END

/* Изменение EndDate */

IF (new.EndDate <> old.EndDate) THEN

BEGIN

IF (new.EndDate > old.EndDate) THEN

BEGIN

/* Расширение EndDate */

UPDATE UslCat

SET BegDate = new.EndDate

WHERE ((new.EndDate BETWEEN BegDate AND EndDate) AND (PKey = new.PKey));

END

ELSE

BEGIN

/* Сужение EndDate */

UPDATE UslCat

SET BegDate = new.EndDate

WHERE ((BegDate = old.EndDate) AND (PKey = new.PKey));

END

END

/* Сборка мусора */

DELETE FROM UslCat

WHERE ((BegDate >= new.BegDate) AND (EndDate <= new.EndDate) AND (PKey = new.PKey) AND (Code <> new.Code));

END ^

CREATE TRIGGER UslCat_BIH FOR UslCat

BEFORE INSERT POSITION 0

AS

BEGIN

DELETE FROM UslCat

WHERE ((BegDate >= new.BegDate) AND (EndDate <= new.EndDate) AND (PKey = new.PKey));

UPDATE UslCat

SET BegDate = new.EndDate

WHERE ((new.EndDate BETWEEN BegDate AND EndDate) AND (PKey = new.PKey));

UPDATE UslCat

SET EndDate = new.BegDate

WHERE ((new.BegDate BETWEEN BegDate AND EndDate) AND (PKey = new.PKey));

END ^

CREATE TRIGGER UslCat_BDH FOR UslCat

BEFORE DELETE POSITION 0

AS

BEGIN

UPDATE UslCat

SET EndDate = old.EndDate

WHERE ((EndDate = old.BegDate) AND (PKey = old.PKey));

END ^

CREATE TABLE UslCatKeys (

Code INTEGER NOT NULL

);

ALTER TABLE UslCatKeys

ADD CONSTRAINT XPKUslCatKeys PRIMARY KEY (Code);

CREATE TABLE UslDivisions (

Code INTEGER NOT NULL,

Name DESCR_TYPE,

PKey INTEGER NOT NULL,

Parent INTEGER NOT NULL,

BegDate DATE_TYPE,

EndDate DATE_TYPE

);

CREATE INDEX XIEUslDivisionsname ON UslDivisions

(

Name

);

CREATE INDEX XIEUslDivisionsParent ON UslDivisions

(

Parent

);

ALTER TABLE UslDivisions

ADD CONSTRAINT XPKUslDivisions PRIMARY KEY (Code);

CREATE TRIGGER UslDivisions_BUH FOR UslDivisions

BEFORE UPDATE POSITION 0

AS

BEGIN

/* Изменение BegDate */

IF (new.BegDate <> old.BegDate) THEN

BEGIN

IF (new.BegDate < old.BegDate) THEN

BEGIN

/* Расширение BegDate */

UPDATE UslDivisions

SET EndDate = new.BegDate

WHERE ((new.BegDate BETWEEN BegDate AND EndDate) AND (PKey = new.PKey));

END

ELSE

BEGIN

/* Сужение BegDate */

UPDATE UslDivisions

SET EndDate = new.BegDate

WHERE ((EndDate = old.BegDate) AND (PKey = new.PKey));

END

END

/* Изменение EndDate */

IF (new.EndDate <> old.EndDate) THEN

BEGIN

IF (new.EndDate > old.EndDate) THEN

BEGIN

/* Расширение EndDate */

UPDATE UslDivisions

SET BegDate = new.EndDate

WHERE ((new.EndDate BETWEEN BegDate AND EndDate) AND (PKey = new.PKey));

END

ELSE

BEGIN

/* Сужение EndDate */

UPDATE UslDivisions

SET BegDate = new.EndDate

WHERE ((BegDate = old.EndDate) AND (PKey = new.PKey));

END

END

/* Сборка мусора */

DELETE FROM UslDivisions

WHERE ((BegDate >= new.BegDate) AND (EndDate <= new.EndDate) AND (PKey = new.PKey) AND (Code <> new.Code));

END ^

CREATE TRIGGER UslDivisions_BIH FOR UslDivisions

BEFORE INSERT POSITION 0

AS

BEGIN

DELETE FROM UslDivisions

WHERE ((BegDate >= new.BegDate) AND (EndDate <= new.EndDate) AND (PKey = new.PKey));

UPDATE UslDivisions

SET BegDate = new.EndDate

WHERE ((new.EndDate BETWEEN BegDate AND EndDate) AND (PKey = new.PKey));

UPDATE UslDivisions

SET EndDate = new.BegDate

WHERE ((new.BegDate BETWEEN BegDate AND EndDate) AND (PKey = new.PKey));

END ^

CREATE TRIGGER UslDivisions_BDH FOR UslDivisions

BEFORE DELETE POSITION 0

AS

BEGIN

UPDATE UslDivisions

SET EndDate = old.EndDate

WHERE ((EndDate = old.BegDate) AND (PKey = old.PKey));

END ^

CREATE TABLE UslDivisionsKeys (

Code INTEGER NOT NULL

);

ALTER TABLE UslDivisionsKeys

ADD CONSTRAINT XPKUslDivisionsKeys PRIMARY KEY (Code);

CREATE TABLE UslLgots (

Code INTEGER NOT NULL,

Category INTEGER NOT NULL,

Property INTEGER,

Tax CURR_TYPE,

Usl INTEGER NOT NULL,

NachCoeff INTEGER NOT NULL,

Nalog INTEGER NOT NULL,

BegDate INTEGER NOT NULL,

Info INTEGER NOT NULL,

EndDate INTEGER NOT NULL

);

ALTER TABLE UslLgots

ADD CONSTRAINT XPKUslLgots PRIMARY KEY (Code);

CREATE TABLE UslProps (

Code INTEGER NOT NULL,

PKey INTEGER NOT NULL,

Tag INTEGER NOT NULL,

ValInteger INTEGER,

ValFloat FLOAT,

BegDate DATE_TYPE,

EndDate DATE_TYPE

);

ALTER TABLE UslProps

ADD CONSTRAINT XPKUslProps PRIMARY KEY (Code);

CREATE TRIGGER UslProps_BUH FOR UslProps

BEFORE UPDATE POSITION 0

AS

BEGIN

/* Изменение BegDate */

IF (new.BegDate <> old.BegDate) THEN

BEGIN

IF (new.BegDate < old.BegDate) THEN

BEGIN

/* Расширение BegDate */

UPDATE UslProps

SET EndDate = new.BegDate

WHERE ((new.BegDate BETWEEN BegDate AND EndDate) AND (PKey = new.PKey));

END

ELSE

BEGIN

/* Сужение BegDate */

UPDATE UslProps

SET EndDate = new.BegDate

WHERE ((EndDate = old.BegDate) AND (PKey = new.PKey));

END

END

/* Изменение EndDate */

IF (new.EndDate <> old.EndDate) THEN

BEGIN

IF (new.EndDate > old.EndDate) THEN

BEGIN

/* Расширение EndDate */

UPDATE UslProps

SET BegDate = new.EndDate

WHERE ((new.EndDate BETWEEN BegDate AND EndDate) AND (PKey = new.PKey));

END

ELSE

BEGIN

/* Сужение EndDate */

UPDATE UslProps

SET BegDate = new.EndDate

WHERE ((BegDate = old.EndDate) AND (PKey = new.PKey));

END

END

/* Сборка мусора */

DELETE FROM UslProps

WHERE ((BegDate >= new.BegDate) AND (EndDate <= new.EndDate) AND (PKey = new.PKey) AND (Code <> new.Code));

END ^

CREATE TRIGGER UslProps_BIH FOR UslProps

BEFORE INSERT POSITION 0

AS

BEGIN

DELETE FROM UslProps

WHERE ((BegDate >= new.BegDate) AND (EndDate <= new.EndDate) AND (PKey = new.PKey));


Подобные документы

  • Модели информационного процесса обработки данных. Классификация баз данных. Сеть архитектуры и технология клиент-сервер. Создание запросов к реляционным базам данных на SQL. Работа с электронными таблицами MS Excel: форматирование данных, вычисления.

    контрольная работа [17,8 K], добавлен 17.01.2010

  • Определение базы данных и банков данных. Компоненты банка данных. Основные требования к технологии интегрированного хранения и обработки данных. Система управления и модели организации доступа к базам данных. Разработка приложений и администрирование.

    презентация [17,1 K], добавлен 19.08.2013

  • Обработка распределенных данных и запросов. Многопотоковые и многосерверные архитектуры. Основные типы параллелелизма при обработке запросов. Структура компонентов поддержки удаленного доступа. Доступ к базам данных в двухзвенных моделях клиент-сервер.

    презентация [123,1 K], добавлен 19.08.2013

  • Определение понятия CASE-технологий. Использование комплексного инструментария ER/Studio для создания логической и физической модели данных, генерирования баз данных на платформе СУБД Access. Процедура добавления атрибутов и сущностей, создания связей.

    контрольная работа [2,2 M], добавлен 21.12.2011

  • Основные объекты СУБД Microsoft Access. Формирование запросов на выборку. Основные протоколы обмена в компьютерных сетях. Использование и применение архитектуры клиент-сервер или файл-сервер. Основы реляционных БД. Наиболее известные модели данных.

    курсовая работа [1,3 M], добавлен 13.01.2014

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

    курсовая работа [2,0 M], добавлен 20.01.2013

  • Представление данных в памяти компьютера. Обобщенные структуры и модели данных. Методы доступа к информации. Физическая организация системы управления базами данных, структура сервера. Архитектура "клиент-сервер". Создание базы данных с помощью "Денвер".

    курсовая работа [770,3 K], добавлен 17.11.2014

  • Преимущества распределенных система обработки данных. Классификация интегрированных технологий. Модели реализации технологии "клиент-сервер". Мониторы обработки транзакций. Глобальные вычислительные и информационные сети. Виды доступа к глобальным сетям.

    презентация [2,1 M], добавлен 20.11.2013

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

    реферат [130,9 K], добавлен 28.09.2014

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

    реферат [1,0 M], добавлен 23.09.2014

Работы в архивах красиво оформлены согласно требованиям ВУЗов и содержат рисунки, диаграммы, формулы и т.д.
PPT, PPTX и PDF-файлы представлены только в архивах.
Рекомендуем скачать работу.