47
Когда рекомендуется использовать MySQL:
• Распределенные операции: поддержка репликации MySQL делает его
отличным выбором для распределенных настроек баз данных.
• Веб-сайты и веб-приложения. MySQL поддерживает множество веб-
сайтов и приложений в Интернете. Это во многом благодаря тому, как
легко установить и настроить базу данных MySQL, а также ее общей
скорости и масштабируемости в долгосрочной перспективе.
• Ожидаемый рост в будущем: поддержка репликации MySQL может
помочь в горизонтальном масштабировании. Кроме того, это
относительно простой процесс обновления до коммерческого продукта
MySQL, такого как MySQL Cluster, который поддерживает
автоматическое разбиение, еще один процесс горизонтального
масштабирования.
Когда не рекомендуется использовать MySQL:
• Строгое соответствие стандарты SQL: поскольку MySQL не пытается
реализовать полный стандарт SQL, этот инструмент не полностью
совместим с SQL.
• Параллелизм и большие объемы данных. Хотя MySQL в целом хорошо
работает с операциями с интенсивным чтением, одновременное чтение
и запись может быть проблематичным.
СУБД PostgreSQL
СУБД PostgreSQL, также известная как Postgres, называет себя «самой
совершенной в мире реляционной базой данных с открытым исходным кодом».
Она был создана с целью обеспечения высокой расширяемости и соответствия
стандартам. PostgreSQL – это объектно-реляционная база данных. Это означает,
что, хотя это в первую очередь реляционная база данных, она также включает в
себя такие функции, как наследование таблиц и перегрузка функций, которые
чаще связаны с объектными базами данных.
Postgres способен эффективно обрабатывать несколько задач
одновременно, это свойство известно как параллелизм. Это достигается без
блокировок чтения благодаря реализации Multiversion Concurrency Control
48
(MVCC), которая обеспечивает атомарность, согласованность, изоляцию и
долговечность своих транзакций, также известных как соответствие ACID.
PostgreSQL не так широко распространена, как MySQL, но все еще
существует ряд сторонних инструментов и библиотек, предназначенных для
упрощения работы с PostgreSQL, включая pgAdmin и Postbird.
Преимущества PostgreSQL:
• Соответствие стандарту SQL: PostgreSQL в большей степени, чем
MySQL, стремится к строгому соблюдению стандартов SQL. Согласно
официальной документации PostgreSQL, PostgreSQL поддерживает 160
из 179 функций, необходимых для полного соответствия требованиям
SQL.
• Открытый исходный код: полностью открытый исходный код.
Сообщество разработчиков Postgres поддерживает и вносит свой вклад
в многочисленные онлайн-ресурсы, которые описывают, как работать с
СУБД, включая официальную документацию, PostgreSQL wiki и
различные онлайн-форумы.
• Расширяемость: пользователи могут расширять PostgreSQL
программным способом и на лету благодаря его работе на основе
каталога и использованию динамической загрузки. Можно указать файл
объектного кода, например разделяемую библиотеку, и PostgreSQL
будет загружать его по мере необходимости.
Недостатки PostgreSQL:
• Производительность памяти: для каждого нового клиентского
соединения PostgreSQL разветвляет новый процесс. Каждому новому
процессу выделяется около 10 МБ памяти, что может быстро
расходовать пямять для баз данных с большим количеством соединений.
Соответственно, для простых операций с интенсивным чтением
PostgreSQL обычно менее производителен, чем другие РСУБД, такие
как MySQL.
• Популярность: хотя PostgreSQL и широко использовался в последние
годы, исторически отставал от MySQL по популярности. Одним из
следствий этого является то, что все еще остается меньше сторонних
49
инструментов, которые могут помочь в управлении базой данных
PostgreSQL. Аналогично, не так много администраторов баз данных с
опытом управления базой данных Postgres по сравнению с теми, кто
имеет опыт работы с MySQL.
Когда рекомендуется использовать PostgreSQL:
• Целостность данных: PostgreSQL полностью совместим с ACID с 2001
года и реализует мультиверсионный контроль, чтобы обеспечить
согласованность данных, что делает его хорошим выбором СУБД, когда
целостность данных имеет решающее значение.
• Интеграция с другими инструментами: PostgreSQL совместим с
широким спектром языков программирования и платформ.
• Сложные операции: Postgres поддерживает планы запросов, которые
могут использовать несколько процессоров, чтобы отвечать на запросы
с большей скоростью. Это, в сочетании с его сильной поддержкой
нескольких одновременно работающих писателей, делает его отличным
выбором для сложных операций, таких как хранение данных и
обработка онлайн-транзакций.
Когда не рекомендуется использовать PostgreSQL:
• Требуется высокая скорость работы: в ущерб скорости PostgreSQL был
разработан с учетом расширяемости и совместимости. Если для проекта
требуются быстрые операции чтения, PostgreSQL может оказаться не
лучшим выбором для СУБД.
• Простые настройки: из-за большого набора функций и строгой
приверженности стандартному SQL Postgres может быть излишним для
простых настроек базы данных. Для операций с интенсивным чтением,
где требуется скорость, MySQL обычно является более практичным
выбором.
• Сложная репликация. Хотя PostgreSQL действительно обеспечивает
надежную поддержку репликации, это все еще относительно новая
функция. Репликация – более зрелая функция в MySQL, и многие
пользователи считают, что репликация MySQL проще в реализации,
50
особенно для тех, у кого нет необходимых баз данных и опыта
системного администрирования.
В таблице 1.5 представлено сравнение СУБД.
Таблица 1.5
Сравнение СУБД
Параметр
Microsoft SQL Server
MySQL
PostgreSQL
Модель первичной
базы данных
Реляционная СУБД
Реляционная СУБД
Реляционная СУБД
Вторичные базы
данных моделей
Хранилище
документов
Граф СУБД
Хранилище документов
Хранилище
документов
Разработчик
Microsoft
Oracle
Группа глобального
развития PostgreSQL
Лицензия
Коммерческая,
условно бесплатная
Открытый исходный код
Открытый исходный
код
Только на основе
облака
нет
нет
нет
Язык реализации
C ++
C и C ++
С
Серверные
операционные
системы
Linux
Windows
FreeBSD
Linux
OS X
Solaris
Windows
FreeBSD
HP-UX
Linux
NetBSD
OpenBSD
OS X
Solaris
Юникс
Windows
Схема данных
да
да
да
Типизация
да
да
да
Поддержка XML
да
да
да
Вторичные
индексы
да
да
да
SQL
да
да
да
API и другие
методы доступа
OLE DB
Табличный поток
данных (TDS)
ADO.NET
JDBC
ODBC
Собственный нативный
API
ADO.NET
JDBC
ODBC
нативная библиотека
C
потоковый API для
больших объектов
ADO.NET
JDBC
ODBC
Поддерживаемые
языки
программирования
C#
C++
Delphi
Go
Java
Ada
C
C#
C++
D
.Net
C
C++
Delphi
Java
51
JavaScript (Node.js)
PHP
Python
R
Ruby
Visual Basic
Delphi
Eiffel
Erlang
Haskell
Java
JavaScript (Node.js)
Objective-C
OCaml
Perl
PHP
Python
Ruby
Scheme
Tcl
JavaScript (Node.js)
Perl
PHP
Python
Tcl
Серверные
скрипты
Языки Transact
SQL,.NET, R, Python
и (с SQL Server
2019) Java
да
пользовательские
функции
Триггеры
да
да
да
Методы разбиения
таблицы могут быть
распределены по
нескольким файлам
(горизонтальное
разбиение); осколок
через федерацию
горизонтальное
разбиение, разделение с
помощью MySQL
Cluster или MySQL
Fabric
разбиение по
диапазону, списку и
(начиная с
PostgreSQL 11) по
хешу
Методы
репликации
Есть, но в
зависимости от
версии SQL-Server
Master-Master
репликации
Мастер-раб репликация
Master-Slave
репликация
Концепции
согласованности
Немедленная
последовательность
Немедленная
последовательность
Немедленная
последовательность
Внешние ключи
да
да
да
Концепции сделки
ACID
ACID
ACID
совпадение
да
да
да
долговечность
да
да
да
Возможности в
памяти
да
да
нет
Пользовательские
концепции
точные права
доступа согласно
стандарту SQL
пользователи с
детальной концепцией
авторизации
точные права
доступа согласно
стандарту SQL
Поскольку на предприятии уже имеется СУБД MS SQL Server 2008 R2, то
следует выбрать ее, поскольку она обладает преимуществами по сравнению со
своими бесплатными аналогами.
52
1.4.3. Обоснование проектных решений по техническому обеспечению
Разрабатываемая АИС обработки входящих документов ООО «Меркато»
будет иметь клиент-серверную архитектуру. «Клиент – сервер» – вычислительная
или сетевая архитектура, в которой задания или сетевая нагрузка распределены
между поставщиками услуг, называемыми серверами, и заказчиками услуг,
называемыми клиентами [10].
Поэтому нужно определеить параметры технических средств как для
клиентской, так и для серверной части АИС.
Требования к клиенту и серверу представлены в таблицах 1.6 и 1.7
Таблица 1.6
Требования к серверу
Операционная система
MS Windows Server 2003
СУБД
MS SQL Server 2008 R2
Процессор
Intel Core i5 3570 или AMD FX-6350
Оперативная память
4 GB RAM
Жесткий диск
System 60 GB
Data 60 GB
Сетевой интерфейс
Ethernet 100 Мбит/с
Таблица 1.7
Требования к клиенту
Операционная система
MS Windows 7 Home
.Net Framework
4.0
Процессор
Intel Pentium 1.86 Ghz
Оперативная память
2 GB RAM
Жесткий диск
System 20 GB
Data 20 GB
Сетевой интерфейс
Ethernet 100 Мбит/с
53
II ПРОЕКТНАЯ ЧАСТЬ
2.1. Разработка проекта автоматизации
2.1.1. Этапы жизненного цикла проекта автоматизации
Жизненный цикл проекта автоматизации (создания АИС) представляет
собой период времени, начинающийся с момента принятия решения о создании
программного продукта и заканчивающиеся в момент его полного изъятия из
эксплуатации.
Методология управления жизненным циклом проекта автоматизации
относится к структуре, которая используется для структурирования,
планирования и контроля процесса реализации проекта. Появилось большое
разнообразие таких методологий, каждая из которых имеет свои признанные
сильные и слабые стороны. Одна методология разработки системы не обязательно
подходит для использования всеми проектами.
Рассмотрим основные этапы жизненного цикла программного обеспечения
[4].
Этап 1. Планирование и анализ потребностей
Каждая модель жизненного цикла разработки программного обеспечения
начинается с анализа, в котором заинтересованные стороны процесса
обсудить требования к конечному продукту. Целью этого этапа является
подробное определение системных требований. Кроме того, необходимо
убедиться, что все участники процесса четко поняли задачи и как каждое
требование будет выполнено. Часто в обсуждении участвуют специалисты по
обеспечению качества, которые могут вмешиваться в процесс добавлениями даже
на этапе разработки, если это необходимо.
Этап 2. Проектирование архитектуры проекта
На втором этапе жизненного цикла разработки программного обеспечения
разработчики фактически проектируют архитектуру. Все различные технические
вопросы, которые могут возникнуть на этом этапе, обсуждаются всеми
заинтересованными сторонами, включая заказчика. Кроме того, здесь
определяются технологии, используемые в проекте, нагрузка на команду,
54
ограничения, сроки и бюджет. Наиболее подходящие проектные решения
принимаются в соответствии с установленными требованиями.
Этап 3. Разработка и программирование
После утверждения требований процесс переходит к следующему этапу –
фактическому развитию. Программисты начинают здесь с написания исходного
кода, имея в виду ранее определенные требования.Системные администраторы
настраивают программную среду, интерфейсные программисты разрабатывают
пользовательский интерфейс программы и логику ее взаимодействия с сервером.
Программирование само по себе предполагает четыре этапа
• разработка алгоритма;
• написание исходного кода;
• компиляция;
• тестирование и отладка.
Этап 4. Тестирование
Этап тестирования включает в себя процесс отладки. Все недостатки кода,
пропущенные во время разработки, обнаруживаются здесь, документируются и
передаются разработчикам для исправления. Процесс тестирования повторяется
до тех пор, пока все критические проблемы не будут устранены и рабочий процесс
программного обеспечения не станет стабильным.
Этап 5. Развертывание
Когда программа завершена и не имеет критических проблем – самое время
запустить ее для конечных пользователей. После выпуска новой версии
программы присоединяется команда технической поддержки.Этот отдел
обеспечивает обратную связь с пользователем; консультировать и поддерживать
пользователей во время эксплуатации. Кроме того, обновление выбранных
компонентов включено в этот этап, чтобы гарантировать, что программное
обеспечение обновлено и неуязвимо для нарушения безопасности.
Каждая из доступных методологий лучше всего подходит для конкретных
видов проектов, основанных на различных технических, организационных,
проектных и групповых соображениях. Рассмотрим существующие методологии
разработки системы:
55
• каскадная (водопадная) модель;
• итерационная;
• спиральная модель;
• V-модель;
• Agile-модель.
Каскадная (водопадная) модель
Водопад – это каскадная модель ЖЦ, в которой процесс разработки
выглядит как поток, шаг за шагом проходящий через фазы анализа,
проектирования, реализации, тестирования, внедрения и поддержки. Эта модель
ЖЦ включает в себя постепенное выполнение каждого этапа полностью. Этот
процесс строго задокументирован и предопределен функциями, ожидаемыми на
каждом этапе этой модели жизненного цикла разработки программного
обеспечения (рисунок 2.1).
Рис. 2.1. Водопадная модель
Преимущества и недостатки представлены в таблице 2.1.
Таблица 2.1
Преимущества и недостатки каскадной модели
ПРЕИМУЩЕСТВА
НЕДОСТАТКИ
Простой в использовании и понимании
Программное обеспечение готово только
после завершения последнего этапа
Простота управления благодаря своей
жесткости: каждый этап имеет
определенный результат и обзор процесса
Высокие риски и неопределенность
Этапы развития идут один за другим
Не лучший выбор для сложных и
объектно-ориентированных проектов
56
ПРЕИМУЩЕСТВА
НЕДОСТАТКИ
Идеально подходит для небольших или
средних проектов, где требования ясны и не
однозначны
Не подходит для долгосрочных проектов
Легко определить ключевые моменты в
цикле разработки
Прогресс этапа трудно измерить, пока он
еще находится в разработке
Легко классифицировать и расставить
приоритеты задач
Интеграция выполняется в самом конце,
что не дает возможности заранее
определить проблему
Варианты использования для модели Waterfall ЖЦ:
• требования точно задокументированы;
• определение продукта стабильно;
• стек технологий предопределен, что делает его не динамичным;
• нет двусмысленных требований;
• проект короткий по времени.
Итерационная модель ЖЦ
Модель Iterative ЖЦ не нуждается в полном списке требований до начала
проекта. Процесс разработки может начинаться с требований к функциональной
части, которые могут быть расширены позже. Процесс повторяется, что позволяет
создавать новые версии продукта для каждого цикла.
Каждая итерация (которая длится от двух до шести недель) включает
разработку отдельного компонента системы, и после этого этот компонент
добавляется к функционалу, разработанному ранее. Говоря с математической
терминологией, итерационная модель является реализацией метода
последовательного приближения; это означает постепенную близость к
запланированной форме конечного продукта (рисунок 2.2) [7].