Просмотр исходного текста страницы СПАСОИ (10) - Лекция №1 - Распределённые системы обработки данных

== Распределённые системы обработки данных ==

Распределённая система обработки данных (РСОД):
* если её данные и/или программы располагаются на разных узлах системы;
* если система обеспечивает прозрачный доступ к этим данным. Незаметно для клиента, он не видит подзапросов, а только результат;
* эта система устойчива к потере связности.

=== Пример модели РСОД ===

Два филиала.

[[Файл:10semSPASOIl1pic1.png|700px]]

В Санкт-Петербурге сидит оператор, выполняет запрос: "Найти клиентов банка, у которых остаток на счёте в Санкт-Петербурге остаток на счёте не меньше 2000, а в Москве - не менее 1000".

Этот запрос на языке SQL поступает на сервер БД №2 и там оптимизируется: выделяются подзапросы:
# к серверу БД №1: найти клиентов, у которых остаток на счёте не меньшее 1000, и которые имеют счёт в Санкт-Петербурге. Запрос выполняется на сервере БД №1 и результат возвращается на сервер БД №2;
# сервер БД №2 формирует и выполняет: из полученного на предыдущем шаге множества найти клиентов, у которых остаток на счёте в Санкт-Петербурге составляет не меньше 2000. Подзапрос выполняется, и результаты возвращаются на исходную рабочую станцию.

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

=== Подходы к проектированию автоматизированных систем ===

Есть несколько:
* структурный:
** общая задача декомпозируется по иерархии сверху вниз на более простые. Используются диаграммы потоков данных (DFD);
** используются реляционные базы данных;
** при обработке записей БД применяется процедурный язык (C, C++ и прочие). SQL не является процедурным. Возникает проблема ''импеданса'', которая решается ''курсором'';
* объектно-ориентированный:
** с самого начала выделяются классы (объекты);
** используются объектно-ориентированные БД;
** при обработке записей применяется объектно-ориентированное программирование.

Преимущества и недостатки:
* при ООП, по существу, предметную область можно представить в виде сцены, а объекты выступают в качестве актёров на этой сцене. Всё очень наглядно. Число объектов резко сокращается по сравнению со структурным;
* при структурном же подходе, при усложнении предметной области, БД становится необозримой;
* некоторые предметные области сложно представить в виде объектов и связей между ними. Например, медицина, экономика - там данные плохо структурированы;
* для ОО БД нет такой стройной теории, как для реляционных;

В общем, мы будем рассматривать структурный подход.

=== Модели проектирования ===

В структурном подходе к проектированию РСОД используются две модели:
* каскадная - в настоящее время не используется;
* спиральная - используется сейчас.

==== Каскадная модель ====

Проектирование происходит поэтапно.

{| class="wikitable"
 ! № !! Этап !! Результат реализации
 |- align="center"
 | 1 || выявление потребностей конечных пользователей || style="text-align:left;" | функциональный граф предметной области
 |- align="center"
 | 2 || концептуальное проектирование || style="text-align:left;" | инфологическая схема БД, спецификация прикладных задач
 |- align="center"
 | 3 || выбор архитектуры || style="text-align:left;" | выбирается модель доступа к данным, комплекс технических средств, общесистемное ПО и прочее
 |- align="center"
 | 4 || логическое проектирование || style="text-align:left;" | отражение инфологической схемы в конкретной СУБД - даталогическая схема БД, пишется исходный код программ
 |- align="center"
 | 5 || отладка || style="text-align:left;" | сборка на стенде, пилотный проект
 |- align="center"
 | 6 || внедрение и сопровождение || style="text-align:left;" | эксплуатация системы, выявление и устранение ошибок, модернизация системы. Модернизация замыкает все этапы в цикл - всё начинается вновь с первого этапа
|}

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

===== Краткое описание этапов проектирования =====

====== Выявление потребностей конечных пользователей ======

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

Пример графа:

[[Файл:10semSPASOIl1pic2.png|500px]]

{{Формула|f=d_{22} = f_2(d_{12}, d_{21}) = f_2(f_1(d_{11}), d_{21})}}

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

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

====== Концептуальное проектирование ======

Пример инфологической схемы:

[[Файл:10semSPASOIl1pic3.png|500px]]

Пунктиром показаны синтетические ключи.

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

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

{{Forward|l=СПАСОИ (10) - Лекция №2 - Спиральная модель}}

[[Категория:Структурное проектирование АСОИ (10 семестр)]]
[[Категория:Конспекты лекций и семинаров]]