ЧОУ СПО «Анапский индустриальный техникум»

СПЕЦИАЛЬНОСТЬ 230105

ОЦЕНКА_______________________

Дата___________________________

НА ТЕМУ: «Разработка и создание удаленной базы данных для автоматизации учета и отчетности в гостиничном комплексе “Ирина” на основе клиент-серверных технологий InterBase»

Анапа, 2008

Содержание

• Введение
• Глава1 Основные подходы к проектированию удаленных баз данных
• 1.1 Основные понятия теории реляционных баз данных
• 1.2 Сервер базы данных
• 1.2.1 Технология и модели "клиент-сервер"
• Глава 2 Технологии, исползуемые в работе
• Глава 3 Реализация модели учета доходов Магазина и продаваемого товара»
• 3 Постановка задачи

3.1 Общие технические характеристики технологии InterBase

• ЗАКЛЮЧЕНИЕ
• Список используемой литературы
• ПРИЛОЖЕНИЯ
• Схема данных
• Экранные формы
• Листинги программы

Введение

Дипломная работа посвящена разработке и созданию удаленной базы данных на основе клиент-серверных технологий InterBase c использование визуальной среды Delphi 7 на языке программирование Object Pascal для автоматизации учета и отчетности в гостиничном комплексе “Ирина”. На сегодняшний момент широко распространена сфера гостиничного, но бумажная работа не позволять так быстро и эффективно работать в этой сфере бизнеса т.к замедляет существенно снижает эффективность работы путем процесса обработки информации без автоматизации учета и отчетности.

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

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

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

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

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

Глава 1 «Основные подходы к проектированию удаленных баз данных»

1.1 Основные понятия теории реляционных баз данных

В узком смысле слова, база данных - это некоторый набор данных, необходимых для работы (актуальные данные). Данные - это отражение объектов реального мира. В традиционной терминологии объекты реального мира, сведения о которых хранятся в базе данных, называются сущностями - entities, а их актуальные признаки - атрибутами (attributes). Каждый признак конкретного объекта есть значение атрибута.

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

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

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

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

Самыми распространенными на сегодняшний день являются реляционные СУБД. Они стали фактическим промышленным стандартом. Кратко рассмотрим реляционную модель данных, не вникая в ее детали.

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

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

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

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

Так как строки в таблице не упорядочены, невозможно выбрать строку по ее позиции. Кроме того, привязка к номеру строки некорректна в многопользовательских СУБД. Любая таблица имеет один или несколько столбцов, значения в которых однозначно идентифицируют каждую ее строку. Такой столбец (или комбинация столбцов) называется первичным ключом (primary key). Если таблица удовлетворяет этому требованию, она называется отношением (relation).

Взаимосвязь таблиц является важнейшим элементом реляционной модели данных. Она поддерживается внешними ключами (foreign key).

Таблицы невозможно хранить и обрабатывать, если в базе данных отсутствуют "данные о данных", например, описатели таблиц, столбцов и т.д. Их называют обычно метаданными. Метаданные также представлены в табличной форме и хранятся в словаре данных (data dictionary).

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

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

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

Существует несколько типов ограничений целостности. Требуется, например, чтобы значения в столбце таблицы выбирались только из соответствующего домена. На практике учитывают и более сложные ограничения целостности, например, целостность по ссылкам (referential integrity). Ее суть заключается в том, что внешний ключ не может быть указателем на несуществующую строку в таблице. Ограничения целостности реализуются с помощью специальных средств, таких как привила (rules), триггеры (triggers) и домены (domains).

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

Появление и развития этого языка как средства описания доступа к базе данных связано с созданием теории реляционных баз данных. Прообраз языка SQL возник в 1970 году в рамках научно-исследовательского проекта System/R, работа над которым велась в лаборатории Санта-Тереза фирмы IBM. Ныне SQL - это стандарт интерфейса с реляционными СУБД. Популярность его настолько велика, что разработчики нереляционных СУБД (например, Adabas или Betrieve), снабжают свои системы SQL-интерфейсом.

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

SQL не является языком программирования в традиционном представлении. На нем пишутся не программы, а запросы к базе данных. Поэтому SQL - декларативный язык. Это означает, что с его помощью можно сформулировать, что необходимо получить, но нельзя указать, как это следует сделать. В частности, в отличие от процедурных языков программирования (Си, Паскаль, Ада), в языке SQL отсутствуют такие операторы, как if...then...else, for, while, хотя следует указать, что в расширении SQL для хранимых процедур и триггеров (SQL/PTL - SQL/Procedure And Trigger Language) они присутствуют.

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

Ниже в таб. 1 перечислены наиболее важные операторы, которые входят в стандарт ANSI/ISO SQL.

Таблица 1

Основные операторы языка SQL

Синтаксис оператора	Выполняемое действие
SELECT	Выбрать данные из базы данных
INSERT	Вставить данные в таблицу
DELETE	Удалить данные из таблицы
UPDATE	Изменить данные в таблице
GRANT	Передать права на действие над объектом
REVOKE	Отобрать права на действие над объектом
COMMIT	Подтвердить транзакцию
ROLLBACK	Откатить транзакцию
CREATE	Создать объект базы данных
DROP	Удалить объект базы данных

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

Каждый столбец в любой таблице хранит данные определенных типов. Различают базовые типы данных - строки символов фиксированной длины, целые и вещественные числа, и дополнительные типы данных - строки символов переменной длины, денежные единицы, дату и время, логические данные (два значения - "ИСТИНА" и "ЛОЖЬ"). В языке SQL можно использовать числовые, строковые, символьные константы и константы типа "дата" и "время".

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

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

Если же был предварительно создан индекс по столбцам, входящим у условие WHERE запроса, то время поиска в таблице будет сокращено до минимума. Индекс создается оператором SQL CREATE INDEX (СОЗДАТЬ ИНДЕКС).

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

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

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

1.2 Сервер базы данных

1.2.1 Технология и модели "клиент-сервер"

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

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

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

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

В настоящее время фактическим стандартом для многопользовательских СУБД, стала архитектура "клиент-сервер".

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

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

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

компонент представления, реализующий функции первой группы;

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

компонент доступа к информационным ресурсам, поддерживающий функции третьей группы;

протокол взаимодействия.

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

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

модель файлового сервера (File Server - FS);

модель доступа к удаленным данным (Remote Data Access - RDA);

модель севера базы данных (DataBase Server - DBS);

модель сервера приложений (Application Server - AS).

FS-модель является базовой для локальных сетей персональных компьютеров. В соответствии с этой моделью один из компьютеров в сети считается файловым сервером и предоставляет услуги по обработке файлов другим компьютерам. Файловый сервер работает под управлением сетевой операционной системы (например, Novell NetWare) и играет роль компонента доступа к информационным ресурсам (то есть к файлам). На других компьютерах в сети функционирует приложение, в кодах которого совмещены компонент представления и прикладной компонент. Протокол обмена представляет собой набор низкоуровневых вызовов, обеспечивающих приложению доступ к файловой системе на файл-сервере.

FS-модель послужила фундаментом для расширения возможностей персональных СУБД в направлении поддержки многопользовательского режима.

Рис.1.1. Модель файлового сервера

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

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

Более технологичная RDA-модель существенно отличается от FS-модели характером компонента доступа к информационным ресурсам. Это, как правило, SQL-сервер. В RDA-модели коды компонента представления и прикладного компонента совмещены и выполняются на компьютере-клиенте. Последний поддерживает как функции ввода и отображения данных, так и чисто прикладные функции. Доступ к информационным ресурсам обеспечивается либо операторами специального языка (языка SQL, если речь идет о базах данных) или вызовами функций специальной библиотеки (если имеется соответствующий интерфейс прикладного программирования - API).

Рис 2.2. Модель доступа к удаленным данным

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

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

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

Основное достоинство RDA-модели заключается в унификации интерфейса "клиент-сервер" в виде языка SQL. Действительно, взаимодействие прикладного компонента с ядром СУБД невозможно без стандартизованного средства общения. Запросы, направляемые программой ядру, должны быть понятны обеим сторонам. Для этого их следует сформулировать на специальном языке. Но в СУБД уже существует язык SQL, о котором речь шла выше. Поэтому было бы целесообразно использовать его не только в качестве средства доступа к данным, но и как стандарта общения клиента и сервера.

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

Наряду с RDA-моделью все большую популярность приобретает перспективная DBS-модель. Последняя реализована в некоторых реляционных СУБД (Informix, Ingres, Sybase, Oracle, InterBase). Ее основу составляет механизм хранимых процедур - средство программирования SQL-сервера. Процедуры хранятся в словаре базы данных, разделяются между несколькими клиентами и выполняются на том же компьютере, где функционирует SQL-сервер. Язык, на котором разрабатываются хранимые процедуры (SQL/PTL), представляет собой процедурное расширение языка запросов SQL и уникален для каждой конкретной СУБД.

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

Рис.1.3. Модель сервера баз данных

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

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

Рис.1.4. Модель сервера приложений

RDA- и DBS-модели опираются на двухзвенную схему разделения функций. В RDA-модели прикладные функции приданы программе-клиенту, в DBS-модели ответственность за их выполнение берет на себя ядро СУБД. В первом случае прикладной компонент сливается с компонентом представления, во втором - интегрируется в компонент доступа к информационным ресурсам. В AS-модели реализована трехзвенная схема разделения функций, где прикладной компонент выделен как важнейший изолированный элемент приложения, для его определения используются универсальные механизмы многозадачной операционной системы, и стандартизованы интерфейсы с двумя другими компонентами. AS-модель является фундаментом для мониторов обработки транзакций (Transaction Processing Monitors - TPM), или, проще, мониторов транзакций, которые выделяются как особый вид программного обеспечения.

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

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

Проблемы, возникающие в модели "один-к-одному", решаются в архитектуре систем с выделенным сервером, способным обрабатывать запросы от многих клиентов. Сервер единственный обладает монополией на управление данными и взаимодействует одновременно со многими клиентами. Логически каждый клиент связан с сервером отдельной нитью (thread) или потоком, по которому пересылаются запросы. Такая архитектура получила название многопотоковой (multi-threaded).

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

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

В некоторых системах эта проблема решается заменой выделенного сервера на диспетчер или виртуальный сервер (virtual server), который теряет право монопольно распоряжаться данными, выполняя только функции диспетчеризации запросов к актуальным серверам. Таким образом, в архитектуру системы добавляется новый слой, который размещается между клиентом и сервером, что увеличивает трату ресурсов на поддержку баланса загрузки (load balancing) и ограничивает возможности управления взаимодействием "клиент-сервер". Во-первых, становится невозможным направить запрос от конкретного клиента конкретному серверу, во-вторых, серверы становятся равноправными - невозможно устанавливать приоритеты для обслуживания запросов.

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

• Глава 2 Технологии, исползуемые в работе

Данная база данных гостиничного комплекса “Ирина” основана на клиент-серверной технологии InterBase v 6.5.

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

Borland InterBase Workgroup Server - сервер реляционных баз данных, оптимизированный для реализации технологии upsizing (укрупнения) многопользовательских приложений. Технология upsizing предполагает переход от многопользовательских приложений, построенных по традиционной файл-серверной модели (таких, как приложения на FoxPro, Clipper, dBASE, Paradox) к приложениям с архитектурой клиент - сервер.

InterBase - сервер, традиционно доступен на всех основных UNIX-платформах (IBM, Sun, HP), оптимизирован для использования на Novell NetWare и Windows NT и обладает рядом функций, обязательных для современного SQL-сервера баз данных.

К таким функциям относятся наличие хранимых процедур, расширенная поддержка триггеров, декларативная ссылочная целостность и т.д. Эти функции соответствуют стандарту ANSI/ISO SQL92 или, где возможно, проекту SQL3.

Важной особенностью новой версии является поддержка технологии C/S Express. Это особенно полезно при использовании InterBase 6.5 в качестве upsizing средства, т.к. позволяет сохранить привычную навигационную нотацию файл-серверной модели при переходе к архитектуре C/S.

Архитектура ядра InterBase

Borland InterBase Workgroup Server обладает рядом свойств, позволяющих решать задачи оперативной обработки транзакций и обеспечивать режим поддержки принятия решений. Среди таких свойств важнейшие являются технология многоверсионности (Versioning Engine), поддержка распределенных баз данных и наличие нестандартных типов данных.

Многоверсионное ядро

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

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

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

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

Распределенные базы данных

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

Сложные типы данных

Помимо общепринятых типов данных, таких как алфавитно-цифровая информация, даты и т.д., InterBase обладает возможностью работы с неструктурированными данными, сохраняя их в виде объектов типа BLOB (Binary Large Objects - большие двоичные объекты). В виде BLOB может быть сохранена любая двоичная информация: изображения, оцифрованный звук, исполняемые модули программ. Особенностью реализации BLOB в InterBase является сегментированный доступ к ним, что позволяет увеличить производительность прикладных систем.

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

Таблица и перебор индекса

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

Позволяя открывать курсоры для таблиц и индексов без использования операторов SQL, InterBase с помощью многопользовательской среды "клиент-сервер" обеспечивает производительность, "близкую к производительности локального персонального приложения". Это означает, что когда курсор открывается для таблицы, то записи возвращаются в естественном порядке, а когда он открывается для индекса, то они возвращаются в отсортированном порядке.

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

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

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

Общие требования к разрабатываемой системе автоматизации:

1. Удобство и просто выполнения основных функций учёта расходов и товара;

2. Надежность выполнения основных функций учёта;

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

Автоматизация учёта продаж и товара:

Учёт в рыночном комплексе заключается в учёте при продаже различного товара с составлением различных отчетных форм и запросов.

Общие требования к разработке подсистемы учета:

1. Продажа товара клиенту;

2. Расходы клиента по дате продажи;

3. Формирование информации о товаре;

4. Формирование информации о стоимости;

5. Существующий товар;

Особенности ведения учёта в организации-заказчике:

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

2. Возможность изменения данных;

3. Быстрое получение информации (поиск);

4. В любой момент времени необходимо иметь возможность добавить или удалить товар.

Автоматизация учёта заполнения.

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

Структура автоматизированной системы учета данной базы создана в InterBase 6.5, а её обработчик Delphi 7 на языке программирования Object Pascal :

- база данных (kodak.gdb),

- обработчик базы данных (KODAK.exe).

Для удобства работы с базой данных ее формы раскрываются на весь экран и независимо от разрешения монитора пользователя подстраиваются под разрешения 800х600 для этого в программе использовался специально написанная функция. Со страницы Standart был помещён объект TmainMenu, который позволяет поместить главное меню в программу и этим помогает создать наглядность программы и понятный интуитивный интерфейс.

База в формате InterBase - это один или несколько файлов со всеми данными. Информация хранится в отдельном файле с расширением gdb. Версии ниже 6-го IB ограничивают размер файла ниже 2-4 Гб, в версии выше 6-й база может занимать <=32 Гб. Этого размера вполне достаточно для автоматизации деятельности какого-либо среднего предприятия. При необходимости файл базы можно разбить на несколько. На физическом уровне gdb-файл представляет собой набор страниц определённого размера. Таким образом, можно сказать, что размер базы всегда кратен размеру страницы. Размер страницы задаётся при создании базы и не может быть изменён в течение её жизни.

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

3.1 Общие технические характеристики технологии InterBase

Целостность:

Декларативный первичный ключ

Декларативный вторичный ключ

Домены и контроль полей

Триггеры:

· Неограниченное число триггеров на одно действие с записью

· Срабатывание при вставке, изменении и удалении записи

· Включение и выключение триггеров во время работы

· Выполнение в случайном или указанном порядке

· Каскадное срабатывание триггеров

Хранимые процедуры :

· поддержка полного синтаксиса SQL

· обработка ошибок и исключительных ситуаций

· возможность выдачи результата в виде набора записей (select)

· рекурсивные вызовы до 1000 уровней вложенности

Конкурентный доступ к данным :

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

· Отсутствие блокировок по чтению

Уровни изоляции данных: чтение подтвержденных данных, воспоизводимое чтение и стабильность таблиц..

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

Общие возможности:

· Резервирование данных без остановки сервера (backup)

· Немедленное автоматическое восстановление базы данных при сбоях

· Неограниченное число подсоединяемых баз данных

· Автоматическое управление двухфазным завершением транзакций

· Оптимальное хранение символьной информации (упаковка и сжатие) и BLOb-полей

Типы данных:

· Символьные (фиксированной и произвольной длины): до 32Кб на поле

· Целочисленные (короткое и длинное целое)

· Вещественные: простой и двойной точности

· Дата/Время: от 1 Января 100 года до 11 декабря 5491 года

· Многомерные массивы: до 16 измерений на одно поле

BLOB: неограниченная длина, возможность определения пользовательских подтипов

Импорт и экспорт ASCII данных

Фильтры BLOB для сжатия или преобразования данных BLOB

Ограничения базы данных:

Максимальное количество записей в одной таблице: 2 миллиарда

Максимальный размер таблицы: ограничивается ресурсами системы

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

Количество активных пользователей: ограничивается ресурсами системы

Количество таблиц в базе данных: 64K

Количество индексов в базе данных: 64K

Максимальный размер записи (не включая BLOB: 64Kb)

Требования к системе:

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

Сетевой протокол: для всех платформ TCP/IP, другие протоколы в зависимости от конкретной платформы.

ЗАКЛЮЧЕНИЕ

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

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

Наиболее существенные преимущества разработанной АС:

1. Поддержка наиболее распространенных сетевых операционных систем (Windows XP, Windows 2000, Windows ME); “прозрачная” переносимость между платформами;

2. Основана на клиент-серверной технологии, что резко уменьшает загрузку сети, и увеличивает производительность труда менеджеров гостиничного комплекса;

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

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

5. Данная программа - является базой для последующего модифицирования и наращивания функций.

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

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

· Начало работы.

· Заполнение таблицы классов номеров и соответствующих им номеров

· Регистрация клиента.

· Добавление расходов к клиентам.

· Изменение данных.

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

· Просмотр отчетов по продажам и товару.

· Окончание работы.

Список используемой литературы

1. Хаббард Дж. Автоматизированное проектирование баз данных. - М.: Мир, 1984. - 294 с.

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

3. Фаронов В. «Delphi 7» - Санкт-Петербург, Питер, 2002 год.

4. Хансен Д., Хансен Г. «Базы данных. Разработка и управление» - Москва, Бином, 2000 год.

5. Чекалов А. «Базы данных: от проектирования до разработки приложений» - Москва, 2003г.

6. Мартин Грубер «Понимание SQL», Издательство Феникс, 1998 г, Москва

7. В.А.Жигалов, Е.Г.Соколова «IntеrBase:Технология построения интерфейсов к базам данных» Москва, 2000г.

ПРИЛОЖЕНИЯ

Схема данных

Экранные формы

Рис 1. Форма с параметрами подключения для последующего соединения с базой

Рис 2. Форма для заполнения списка товаров



Рис 3 Форма для заполнения типов товаров, а также их видов и марок

Рис 4. Форма кассового модуля

Рис 5.Форма выбора и продажи товара

Рис 6. Форма проданного товара с учетом его количества, времени его продажи, и кем он был продан

Рис 7. Отчет по продажам

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

SQL скрипт для создания базы данных на InterBase:

CREATE DATABASE 'KODAK.GDB' ;

CREATE TABLE "TOVAR" /*создание таблицы товаров */

(

"ID_TOVAR" INTEGER NOT NULL,

"VID" INTEGER NOT NULL,

"TYPE_T" INTEGER,

"MARKA" INTEGER NOT NULL,

"NAIM" VARCHAR(150) NOT NULL,

"MODEL" VARCHAR(20),

"XARAKTER" VARCHAR(50),

"STOIMOST" FLOAT NOT NULL,

CONSTRAINT "PK_TOVAR" PRIMARY KEY ("ID_TOVAR"), /* первичный ключ */

CONSTRAINT "TOVAR_NAIM" UNIQUE ("NAIM") /* уникальное поле */

);

ALTER TABLE "TOVAR" ADD CONSTRAINT "FK_TOVAR_1" FOREIGN KEY ("VID") REFERENCES VID_TOVARA ("ID_VID") ON UPDATE CASCADE ON DELETE CASCADE;

ALTER TABLE "TOVAR" ADD CONSTRAINT "FK_TOVAR_2" FOREIGN KEY ("TYPE_T") REFERENCES TYPES ("ID_TYPE") ON UPDATE CASCADE ON DELETE CASCADE;

ALTER TABLE "TOVAR" ADD CONSTRAINT "FK_TOVAR_3" FOREIGN KEY ("MARKA") REFERENCES MARKS ("ID_MARKA") ON UPDATE CASCADE ON DELETE CASCADE;

CREATE TABLE "KASSA" /*создание таблицы касса */

(

"ID_KASSA" INTEGER NOT NULL,

"DATA" DATE NOT NULL,

"VREMA" TIME NOT NULL,

"PRINATO" FLOAT NOT NULL,

"SDACHA" FLOAT NOT NULL,

"PRIB" FLOAT NOT NULL,

"RABOT" INTEGER NOT NULL,

CONSTRAINT "PK_KASSA" PRIMARY KEY ("ID_KASSA")

);

ALTER TABLE "KASSA" ADD CONSTRAINT "FK_KASSA_1" FOREIGN KEY ("RABOT") REFERENCES RABOTNIKI ("ID_RAB") ON UPDATE CASCADE ON DELETE CASCADE;

CREATE TABLE "PRODAJA" /*создание таблицы продажа*/

(

"ID_PRODAJA" INTEGER NOT NULL,

"DATA" DATE NOT NULL,

"VREMA" TIME NOT NULL,

"TOVAR" INTEGER NOT NULL,

"KOL_VO" FLOAT NOT NULL,

"SUMMA" FLOAT NOT NULL,

CONSTRAINT "PK_PRODAJA" PRIMARY KEY ("ID_PRODAJA")/* первичный ключ */

CREATE TABLE "MARKS" /*создание таблицы марка */

(

"ID_MARKA" INTEGER NOT NULL,

"NAIM" VARCHAR(50) NOT NULL,

"VID" INTEGER NOT NULL,

CONSTRAINT "MARKA_NAIM" UNIQUE ("NAIM"), /* уникальное поле */

CONSTRAINT "PK_MARKS" PRIMARY KEY ("ID_MARKA") /* первичный ключ */

CREATE TABLE "TYPES" /*создание таблицы тип */

(

"ID_TYPE" INTEGER NOT NULL,

"NAIM" VARCHAR(50) NOT NULL,

"VID" INTEGER NOT NULL,

CONSTRAINT "PK_TYPES" PRIMARY KEY ("ID_TYPE"), /* первичный ключ */

CONSTRAINT "TYPE_NAIM" UNIQUE ("NAIM")); /* уникальное поле */

CREATE TABLE "RABOTNIKI" /*создание таблицы работники */

(

"ID_RAB" INTEGER NOT NULL,

"POLZ" VARCHAR(30),

"PASS" VARCHAR(30),

"FIO" VARCHAR(50),

CONSTRAINT "PK_RABOTNIKI" PRIMARY KEY ("ID_RAB")/* первичный ключ */

);

CREATE TABLE "PRODANOE" /*создание таблицы проданое */

(

"ID_PRODAN" INTEGER NOT NULL,

"DATA" DATE NOT NULL,

"NAIM" VARCHAR(150),

"KOL_VO" FLOAT NOT NULL,

"SUMMA" FLOAT NOT NULL,

"VREMA" TIME NOT NULL,

"RABOT" INTEGER NOT NULL,

CONSTRAINT "PK_PRODANOE" PRIMARY KEY ("ID_PRODAN")/* первичный ключ */

);

ALTER TABLE "PRODANOE" ADD CONSTRAINT "FK_PRODANOE_1" FOREIGN KEY ("RABOT") REFERENCES RABOTNIKI ("ID_RAB") ON UPDATE CASCADE ON DELETE CASCADE;

CREATE TABLE "VID_TOVARA" /*создание таблицы вид товара */

(

"ID_VID" INTEGER NOT NULL,

"NAIM" VARCHAR(50) NOT NULL,

CONSTRAINT "PK_VID_TOVARA" PRIMARY KEY ("ID_VID"),

CONSTRAINT "VID_TOVARA_NAIM" UNIQUE ("NAIM") /* уникальное поле */

);

Cоздание внешних ключей и ограничения ссылочной целостности:

ALTER TABLE "KASSA" ADD CONSTRAINT "FK_KASSA_1" FOREIGN KEY ("RABOT") REFERENCES RABOTNIKI ("ID_RAB") ON UPDATE CASCADE ON DELETE CASCADE;

ALTER TABLE "PRODANOE" ADD CONSTRAINT "FK_PRODANOE_1" FOREIGN KEY ("RABOT") REFERENCES RABOTNIKI ("ID_RAB") ON UPDATE CASCADE ON DELETE CASCADE;

ALTER TABLE "TOVAR" ADD CONSTRAINT "FK_TOVAR_1" FOREIGN KEY ("VID") REFERENCES VID_TOVARA ("ID_VID") ON UPDATE CASCADE ON DELETE CASCADE;

ALTER TABLE "TOVAR" ADD CONSTRAINT "FK_TOVAR_2" FOREIGN KEY ("TYPE_T") REFERENCES TYPES ("ID_TYPE") ON UPDATE CASCADE ON DELETE CASCADE;

ALTER TABLE "TOVAR" ADD CONSTRAINT "FK_TOVAR_3" FOREIGN KEY ("MARKA") REFERENCES MARKS ("ID_MARKA") ON UPDATE CASCADE ON DELETE CASCADE;

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

CREATE GENERATOR "GEN_KASSA_ID";

CREATE GENERATOR "GEN_MARKS_ID";

CREATE GENERATOR "GEN_PRODAJA_ID";

CREATE GENERATOR "GEN_PRODANOE_ID";

CREATE GENERATOR "GEN_TOVAR_ID";

CREATE GENERATOR "GEN_TYPES_ID";

CREATE GENERATOR "GEN_VID_TOVARA_ID";

Исходный код обработчика базы данных:

Модуль main:

object frmMain: TfrmMain

Left = 283

Top = 184

BorderIcons = [biSystemMenu]

BorderStyle = bsSingle

ClientHeight = 250

ClientWidth = 453

Color = clBtnFace

Font.Charset = DEFAULT_CHARSET

Font.Color = clWindowText

Font.Height = -11

Font.Name = 'MS Sans Serif'

Font.Style = []

FormStyle = fsStayOnTop

OldCreateOrder = False

OnClose = FormClose

PixelsPerInch = 96

TextHeight = 13

object GroupBox1: TGroupBox

Left = 0

Top = 0

Width = 233

Height = 249

Caption = #1054#1089#1085#1086#1074#1085#1099#1077' '#1086#1087#1077#1088#1072#1094#1080#1080':'

Font.Charset = DEFAULT_CHARSET

Font.Color = clWindowText

Font.Height = -19

Font.Name = 'MS Sans Serif'

Font.Style = []

ParentFont = False

TabOrder = 0

object spT: TSpeedButton

Left = 8

Top = 32

Width = 217

Height = 49

Caption = #1058#1054#1042#1040#1056#1067

Enabled = False

Flat = True

Font.Charset = DEFAULT_CHARSET

Font.Color = clWindowText

Font.Height = -19

Font.Name = 'MS Sans Serif'

Font.Style = []

ParentFont = False

OnClick = spTClick

end

object spP: TSpeedButton

Left = 8

Top = 81