Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Dip-Othet-verst2.doc
Скачиваний:
2
Добавлен:
01.05.2025
Размер:
2.48 Mб
Скачать

1.11.1 Вывод

Для генерации отчетов был выбран FastReport 3.0. Основной причиной выбора данного продукта является легкость сопровождения, русская документация, опыт работы с подобными генераторами отчетов.

2 Специальная часть

2.1 Архитектура автоматизированной системы

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

Общая архитектура автоматизированной системы выглядит следующим образом:

Рисунок 2.1 - Общая архитектура программной среды

2.2 Выбор средства реализации уровня бд

Первое что следует объяснить, почему в качестве платформы для реализации не была выбрана 1С Предприятие 7.7.? Почему не доработать имеющуюся конфигурацию до требований необходимых заказчиком? Еще один фактор за 1С Предприятие 7.7. состоял в том, что в ней находились данные, которые требовались для работы программы. Для ответа на эти вопросы следует рассказать о платформе 1С Предприятие 7.7 и конфигурацию “Технический центр”.

Общая архитектура 1С состоит из двух звеньев.

  • клиент, для доступа к данным

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

Если рассматривать второе звено в контексте клиент серверной архитектуры, то это “Сервер”. Но в основе программного комплекса 1С Предприятие 7.7 dbf версии лежит не клиент серверная архитектура, а так называемая “share-dbf” технология.

Из архитектуры 1С следуют минусы данной технологии:

  • все вычисления проводятся на стороне клиента, из-за чего требования к клиенту значительно возрастает.

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

  • резко уменьшается масштабируемость данной технологии. Т.к. конфликты одновременного доступа к данным разрешает ОС а не специально предназначенный для этого сервер данных. В нашем случае ОС MS Windows 2003. Как показала практика, данная ОС не оптимально рассчитана на одновременный доступ к одним и тем же файлам открытым на запись/чтение разными пользователями/процессами. Часто сервер отвечает отказом в попытки сохранить или считать данные. Из за чего 1С клиент “падает”.

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

Основные требования к серверу СУБД следующие:

  • Масштабируемость

  • Надежность

  • Возможность реализации бизнес логики на стороне

  • Сложность реализации

  • Сложность администрирования

  • Стоимость

  • Познания автора в данной СУБД

  • FGAC

На выбор также повлияло обстоятельство, которое требовало реализовать FGAC (Fine Grained Access Control) детальный контроль доступа (будет тщательно рассмотрена далее по тексту). Задача стояла так, что некоторые пользователи могли совершать операции добавления, изменения, удаления, просмотра только своих данных, которые они создали.

Таблица 2.1 - Сравнительные характеристики СУБД серверов

Параметры \ СУБД

Oracle

MSSQL

MySQL

Масштабируемость

Отлично

Хорошо

Хорошо

Надежность

Отлично

Хорошо

Хорошо

Возможность реализации бизнес логики на стороне

Отлично

Хорошо

Плохо

Сложность реализации

Отлично

Хорошо

Плохо

Сложность администрирования

Плохо

Отлично

Хорошо

Стоимость

Есть бесплатная версия с ограничениями на 4 Гб данных, 1 процессор, 1 Гб оперативной памяти

Есть бесплатная версия с ограничениями на 2 Гб данных, 1 процессор, 1 Гб оперативной памяти

Относительно бесплатно (есть некоторые ограничения)

Познания автора

Хорошо

Плохо

Плохо

FGAC

Есть

Нет

Нет

Защищенность

Отлично

Хорошо

Хорошо

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

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

Выбор пал в сторону Oracle, по его отличным характеристикам и возможности использовать FGAC.

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]