Работа торгового склада (стр. 6 из 7)

Следовательно, имеем:

Iзап = (614400 – 307200 – 0,178)/17,28 = 17777 дней.

5. Время резервного копирования определяется промежутками времени, в которые поступает порция данных порядка 20% первоначального объёма БД

(3.6)

Следовательно, резервное копирование следует проводить каждые:

Tp=0.2*0.178/17.28=0,2 дня или через каждые 4.8 часов.

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

(3.7)

где

- количество обращений к записям j -го типа в i -м запросе.

В базе - три типа записей:

J=1 - Integer – 3 поле

J=2 - Date – 1 поле

J=3 - Varchar – 7 полей

J=4 - Numeric – 1 поле

Следовательно, имеем:

=12.

7. Интенсивность обращений к информационному фонду

(3.8)

где

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

При среднем количестве запросов вывода информации равном 0, и запросов ввода равном 100. Имеем частоту выполнения запросов:

=100+20=120 зап/день.

Следовательно, имеем интенсивность обращений к информационному фонду:

=12*120=1440.

2 СЕТЕВАЯ СТРУКТУРА ОРГАНИЗАЦИИ БАЗ ДАННЫХ

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

В основе лежит возможность осуществления связи между удалёнными компьютерами по:

- линиям телефонной связи;

- воздушным радиолиниям;

- спутниковой связи.

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

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

- загруженность линий связи;

- загруженность клиентского терминала;

- общая неустойчивость системы.

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

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

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

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

В данной структуре априори известно, что сервер хранит базы данных и выполняет запросы, поступающие от клиентских терминалов из локальной сети. Либо выполняет запросы от удалённых клиентских терминалов, через всемирную сеть Интернет. Эти терминалы могут быть расположены по всему миру (например, базы данных авиакомпании «Америка ОнЛайн»). Причём интернет-порталом не обязательно должен быть сервер баз данных.

Удалённые

терминалы

Интернет

Сервер

Рабочие

станции

Рис.1 Сетевая организация баз данных корпоративных клиентов

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

В случае нашего курсового проекта на машине-сервере должен быть развернут InterBaseServer. А программным обеспечением осуществляющим отправку посылок и отображения результатов запросов является программа Storage.

В системе разработана система аккаунтов. То есть каждый отдельный пользователь имеет свои права и полномочия. Наиболее широкие возможности имеет администратор системы. Он может выполнять все возможные операции над базами данных, с использованием структурированного языка запросов (SQL).

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

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

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

3 ОТКАЗЫ И ВОССТАНОВЛЕНИЕ

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

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

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

С помощью подтверждения транзакций реализуется система каскадных взаимодействий между таблицами через FK(ForeignKey – Удалённый ключ). Существует два типа каскадных взаимодействий:

Onupdate – по изменению поля.

Ondelete – по удалению поля.

Когда выставлено взаимодействие onupdate, при изменении содержимого поля в главной таблице изменяется содержимое поля в подчинённой.

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

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

Если в главной таблице «Товары» изменить содержимое поля «Товар» - «Сахар» на «Рафинад», то изменения onupdate в подчинённой таблице «Отпуск_товаров_со_склада» вступит в силу лишь после подтверждения транзакции. В проекте не реализован тип взаимодействия ondelete за отсутствием необходимости удаления данных из подчинённых таблиц, так как априори известно, что в базе информация должна постоянно накапливаться, а удаляться содержимое полей ни в одной таблице не будет.

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