Сервер, как правило, обладает существенно большей вычислительной мощностью, чем клиенты, перенос "интеллекта" с клиента на сервер повышает быстродействие системы. Кроме того, система проще масштабируется – легче и дешевле заменить сервер на более мощный, чем десятки рабочих станций. Но самое главное, что система становится более устойчивой и более защищенной. При доступе к базам InterBase всегда происходит авторизация пользователя, а поскольку пароли хранятся в специальной базе данных InterBase, взломать ее снаружи чрезвычайно трудно. Кроме того, триггеры, сигнализаторы событий, процедуры, UDF (определяемые пользователем функции), механизмы поддержки целостности данных и разграничения доступа в InterBase хранятся непосредственно в базе данных и работают независимо от способа доступа к данным (из приложения, из ISQL).
Способность быстро обрабатывать большое количество различных запросов — безусловно, одна из важнейших характеристик InterBase.
Наиболее эффективным средством при создании приложений клиент/сервер в VisualFoxPro является совместное использование удаленных представлений и сквозных запросов. Так как удаленные представления создаются очень просто и поддерживают возможность добавления и модификации данных, их используют для редактирования и выборки данных. Для выполнения специфических задач управления данными на сервере базы данных, таких как создание таблиц, хранимых процедур и их выполнение, используются сквозные запросы.
Мировая практика показывает, что скоростные качества различных типов серверов отличаются не слишком значительно — гораздо большее значение приобретает правильное построение структуры базы данных, поскольку в зависимости от структуры можно получить разницу во времени выполнения запросов на порядки, тогда как разница во времени выполнения по аналогичным запросам на разных SQL-серверах составляет не более десятков процентов.
Кроме того, скорость работы СУБД реально может зависеть от некоторых принципиальных моментов. Так, в частности, InterBase обладает значительными преимуществами в случае реализации информационных систем, где больший процент составляют запросы на чтение информации (например, запросы на составление отчетов по всей базе данных). Механизм множественного поколения записей, позволяет производить длинные запросы в реальном времени при полном отсутствии блокировок. Для конкретной системы это означает отсутствие каких-либо проблем при длительных запросах, сделанных одновременно с различных клиентских мест. Более того, этот механизм позволяет проводить моментальный снимок (snapshot) всей базы данных, даже если выполнение такого запроса занимает значительное количество времени.
Как уже упоминалось, InterBase, в отличие от многих других SQL-серверов, пакует хранимые данные. Это означает, в частности, что реальные размеры файла базы данных могут оказаться в несколько раз меньше, чем при использовании других SQL-серверов.
Для создания приложений, взаимодействующих с базами данных InterBase, можно выбрать различные средства разработки в зависимости от реализуемой задачи. Для разработки клиентского приложения с использованием InterBase в данном проекте применяется СУБД Microsoft Visual FoxPro 5.0.
Использование персональных СУБД позволяет не только эффективно организовать работу с бизнес - правилами, но и поддержать независимую работу клиентского приложения за счет наличия собственных форматов хранения данных.
Доступ к серверу баз данных InterBase осуществляется через ODBC драйверы. Как правило, разработчики используют данные средства для ознакомления с технологией «клиент/сервер», поскольку языковые возможности этих инструментов для работы с серверами баз данных ограничены и поддерживают язык SQL в качестве дополнительных возможностей, интегрированных в язык самой среды разработки. Это позволяет разработчикам использовать привычные языковые конструкции при написании приложений, постепенно изучая и внедряя в процесс разработки язык запросов SQL.
Чтобы БД адекватно отражала предметную область необходимо хорошо представлять все нюансы предметной области и уметь это отобразить в БД. Перед проектированием надо хорошо разобраться, как функционирует предметная область (см. выше). Описание предметной области можно сделать естественным путем и неоднозначно, поэтому применяют формализованные средства. Чтобы спроектировать структуру БД необходима информация о предметной области, которая не зависит от СУБД, которая будет использоваться.
Спроектировать логические структуры БД это значит:
1) определить все информационные единицы, тип, характеристики, длину поля;
2) определить связи между ними;
3) задать их имена.
Все данные об основных средствах целесообразно представить в виде нескольких таблиц. При этом существует разделение информации на следующие типы:
1) основная информация для ведения учета основных средств;
2) справочная информация;
3) вспомогательная информация, предназначенная для составления необходимых отчетов.
Для каждой группы информации создается собственная структура данных. При описании таких структур приняты следующие обозначения типов данных:
С - символьные поля, N - числовые поля D - поля дат.
Для хранения основной информации для учета основных средств создана БД OSI и с ее помощью эффективно реализуется часть функций учета.
В справочниках (табл. 2.2 - 2.10) хранится та информация, которая является условно-постоянной: данные о группах ОС, нормах износа, подразделениях и т.п.
Справочники
Таблица 2.2 Структура данных справочника счетов SCHET.dbf
| Название полей | Тип данных | Количество символов | Назначение полей |
| 1 | 2 | 3 | 4 |
| NUM_CSHET | C | 3 | Номер счета |
| NAME | C | 80 | Наименование счета |
| TYPE | C | 4 | Тип счета |
| OSTATOK | C | 5 | Тип сальдо |
| ANALITIC | C | 1 | Аналитический счет |
Таблица 2.3 Структура данных справочника материально-ответственных лиц SPRMOL.dbf
| Название полей | Тип данных | Количество символов | Назначение полей |
| 1 | 2 | 3 | 4 |
| TAB_NUM | C | 5 | Табельный номер |
| SURNAME | C | 15 | Фамилия |
| FIRST_NAME | C | 12 | Имя |
| SCND_NAME | C | 15 | Отчество |
| KOD_PODR | C | 3 | Код подразделения |
| TELEFON | С | 10 | Телефон |
| NAIM_PODR | С | 25 | Наименование подразделения |
Таблица 2.4 Структура данных справочника подразделений SPR_PODR.dbf
| Название полей | Тип данных | Количество символов | Назначение полей |
| 1 | 2 | 3 | 4 |
| KOD_PODR | C | 3 | Код подразделения |
| КОD_MAIN | С | 3 | Основной код |
| NAME | С | 20 | Наименование подразделения |
Таблица 2.5 Структура данных справочника групп ОС SPR_GR_OS.dbf
| Название полей | Тип данных | Количество символов | Назначение полей |
| 1 | 2 | 3 | 4 |
| KOD | N | 3.0 | Код подразделения |
| NAME | С | 80 | Наименование |
Таблица 2.6 Структура данных справочника норм износа SPR_NORM_IZN.dbf
| Название полей | Тип данных | Количество символов | Назначение полей |
| 1 | 2 | 3 | 4 |
| SHIFR_NACH_IZN | N | 5 | Шифр нормы |
| NAME | С | 80 | Название нормы |
| N | N | 4.1 | Годовая норма износа для ОС |
Таблица 2.7 Структура данных справочника видов операций spr_v_op.dbf
| Название полей | Тип данных | Количество символов | Назначение полей |
| 1 | 2 | 3 | 4 |
| ID | N | 1 | Код операции |
| NAME | C | 20 | Наименование операции |
Таблица 2.8 Структура данных БД OSI .dbf
| Название полей | Тип данных | Количество символов | Назначение полей |
| 1 | 2 | 3 | 4 |
| TAB_NUM | C | 5 | Табельный номер |
| SURNAME | C | 15 | Фамилия |
| FIRST_NAME | C | 12 | Имя |
| SCND_NAME | C | 15 | Отчество |
| KOD_PODR | C | 3 | Код подразделения |
| TELEFON | С | 10 | Телефон |
| NAIM_PODR | С | 25 | Наименование подразделения |
| IN К | N | 6,0 | Номер инвентарной карточки |
| IN 0 | N | 6,0 | Инвентарный № объекта |
| NAME | С | 23,0 | Наименование объекта |
| DATE IN | D | 8,0 | Дата приобретения объекта |
| DATE V | D | 8,0 | Дата ввода в эксплуатацию |
| JARVIP | С | 4,0 | Дата выпуска объекта |
| DATE PER | D | 8,0 | Дата перемещения |
| DATES | D | 8,0 | Дата списания |
| АКТ IN | С | 4,0 | № акта приобретения |
| АКТ V | С | 4,0 | № акта ввода в эксплуатацию |
| АКТ PER | С | 4,0 | Ns акта перемещения |
| АКТ S | С | 4,0 | № акта списания |
| KOL | N | 6,0 | Количество |
| BALS | N | 10,2 | Балансовая стоимость |
| OST STOIM | N | 10.2 | Остаточная стоимость |
| IZNOSP | N | 10,2 | Износ на момент поступления ОС |
| SHIFR NACH IZN | N | 5,0 | Код начисления износа |
| NACH IZNOS | N | 10,2 | Начисленный износ |
| GNORMAIZ | N | 4,1 | Годовая норма износа |
| KODPODR1 | С | 3.0 | Код подразделения старый (на момент поступления) |
| KODPODR2 | С | 3,0 | Код подразделения новый (на момент перемещения) |
| STATUS | С | 15,0 | Статус ОС |
| GRUPPA | N | 3.0 | Группа ОС |
| VID OS | N | 1.0 | ВидОС |
| TAB N MOL | С | 5,0 | Табельный номер МОЛ |
| DEBIZN | С | 3,0 | Дебет начисления износа |
| KRED IZN | С | 3,0 | Кредит начисления износа |
| DEBVVOD | С | 3,0 | Дебет на ввод |
| KRED VVOD | С | 3,0 | Кредит на ввод |
| DEB SPIS | С | 3,0 | Дебет списания |
| KREDSPIS | С | 3,0 | Кредит списания |
| AN VVOD | С | 3,0 | Аналитика на ввод |
| AN SPIS | С | 3,0 | Аналитика на списание |
| AN IZN | С | 3,0 | Аналитика на износ |
Таблица 2.9 Структура данных БД Book .dbf