ВОПРОСЫ К ЭКЗАМЕНУ ПО ДИСЦИПЛИНЕ «СИСТЕМНЫЙ АНАЛИЗ»

1. Краткая история создания и развития методологий ССА и П ИУС.

Наука системного аналізу, як і будь-яка інша, ставить за мету дослідження нових зв'язків і
відносин об'єктів і явищ. Проте, основною її проблематикою є дослідження зв'язків і відносин так, щоб
об'єкти, що вивчаються, стали б більш керованими, більш дослідженими, а "розкритий" в результаті їх
вивчення механізм взаємодії цих об'єктів - більш застосовним до інших об'єктів і явищ. Завдання і
принципи системного підходу не залежать від природи об'єктів і явищ.
Епоха зародження основ системного аналізу найчастіше характеризувалася розглядом систем
фізичного або філософського (гносеологічного) походження.
Системний аналіз - сукупність понять, методів, процедур і технологій для вивчення, опису,
реалізації явищ і процесів різної природи і характеру, міждисциплінарних проблем; це сукупність
загальних законів, методів, прийомів дослідження таких систем. Системний аналіз - методологія
дослідження складних, часто не цілком визначених проблем теорії і практики.
Строго кажучи, розрізняють три галузі науки, що вивчає системи:
1. системологію (теорію систем) яка вивчає теоретичні аспекти і використовує теоретичні
методи (теорія інформації, теорія вірогідності, теорія ігор і ін.);
2. системний аналіз (методологію, теорію і практику дослідження систем), що досліджує
методологічні, а часто і практичні аспекти і використовує практичні методи (математична статистика,
дослідження операцій, програмування і ін.);
3. системотехніку (практику і технологію проектування і дослідження систем).
Спільним у всіх цих гілок є системний підхід, системний принцип дослідження - розгляд
сукупності, що вивчається, не як простої суми складових (лінійно взаємодіючих об'єктів), а як
сукупності нелінійних і багаторівневих взаємодіючих об'єктів.
Системний аналіз тісно пов'язаний з синергетикою. Синергетика - міждисциплінарна наука, що
досліджує загальні ідеї, методи і закономірності організації (зміни структури, її просторово-часового
ускладнення) різних об'єктів і процесів, інваріанти (незмінна суть) цих процесів. "Синергетичний" в
перекладі означає "сумісний, такий, що злагоджено діє". Це теорія виникнення нових якісних
властивостей, структур на макроскопічному рівні. Системний аналіз тісно пов'язаний і з філософією.
Філософія дає загальні методи змістовного аналізу, а системний аналіз - загальні методи формального,
міжпредметного аналізу предметних областей, виявлення і опису, вивчення їх системних інваріантів.

2. 3 NF И три шага нормализации отношений в БД.

В нормалізованої ERD об'єкти розглядаються як відношення, що мають бути приведені до
вигляду не нижче третьої нормальної форми (3NF).
Перша нормальна форма.
Атрибут мусить мати тільки одне значення, що відповідає одному екземпляру об'єкта в даний
час. Не допускається присутність повторюваних груп. Аналітик має створити новий об'єкт, який має
зв'язок ступеня 1:m з вихідним об'єктом для того, щоб вилучити ці групи даних. Ім'я атрибута має бути
сингулярним. Повторюваність імен атрибутів у більшості випадків свідчить про наявність у моделі
помилкових об'єктів.
Друга нормальна форма.
Значення атрибутів мають бути залежними від повного унікального ідентифікатора. Ті атрибути,
значення яких залежать тільки від частини унікального ідентифікатора, повинні бути вилучені з моделі.
Такі атрибути звичайно мають на увазі відсутній, але зв'язаний відношенням об'єкт.
Третя нормальна форма.
Атрибути не мають бути залежними від інших атрибутів, які не є потенційними
ідентифікаторами для об'єкта. У випадку присутності таких атрибутів у моделі, вони повинні бути
вилучені. Таким чином, тут не має бути транзитивних зв’язків між атрибутами.

3. Структура методологии SSADM и документации по технологическому

процессу проектирования.
Аналіз вимог є в більшості методологій першою фазою (за винятком SSADM, де присутня
нульова необов'язкова фаза "Аналіз можливості реалізації") розробки системи, якою уточнюються
вимоги замовника, а потім вони формалізуються і документуються.
Этапы разработки ИТ-системы по SSADM
Стадия 0. Оценивание реализуемости (необязательно).
Стадия 1. Предпроектное исследование.
Стадия 2. Выбор варианта автоматизации.
Стадия 3. Разработка технического задания.
Стадия 4. Выбор варианта технической реализации.
Стадия 5. Разработка логического проекта.
Стадия 6. Физическое проектирование.
Серед усієї різноманітності засобів вирішення даних задач у методологіях структурного аналізу
найбільш часто й ефективно застосовуються:
- DFD (Data Flow Diagrams) - діаграми потоків даних спільно зі словниками даних і
специфікаціями процесів або міні-специфікаціями ;
- ERD (Entity - Relationship Diagrams) - діаграми “сутність - зв'язок”. Всі вони містять графічні і
текстові засоби моделювання : перші - для зручності демонстрування основних компонентів моделі,
другі - для забезпечення точного визначення її компонентів і зв'язків.
Логічна DFD показує зовнішні стосовно системи джерела і рядки (адресати) даних, ідентифікує
логічні функції (процеси) і групи елементів даних, які зв'язують одну функцію з іншою (потоки), а
також ідентифікує сховища даних, до яких здійснюється доступ. Структури потоків даних і визначення
їхніх компонентів зберігаються й аналізуються в словнику даних. Кожна логічна функція (процес) може
бути деталізована за допомогою DFD нижнього рівня; коли подальша деталізація перестає бути
корисною, переходять до вираження логіки функцій за допомогою специфікацій процесу
(мініспецифікацій). Вміст кожного сховища також зберігають у словнику даних, модель даних
сховища розкривається за допомогою ERD. Перераховані засоби, зв`язок яких показаний на рис. 1.1,
дають повний опис системи незалежно від того, чи є вона існуючою або розроблювальною з нуля. У
такий спосіб строїться логічна функціональна специфікація - докладний опис того, що має робити
система, звільнене на скільки це можливо від розгляду шляхів її реалізації. Це дає проектувальнику
чітке уявлення про кінцеві результати, яких варто досягти.
Результати моделювання потоків даних концентруються в таких продуктах методики:
- ієрархічний комплект діаграм (DFD);
- документи “Опис елементарного процесу”;
- документи “Опис зовнішнього об'єкта”;
- документи “Опис вхід-вихід”.
Це базовий комплект документації відносно моделі потоків даних.
Документування ERD. Складання документації на ERD - процес, який протікає на всьому
протязі проектування. Документація забезпечує підтримку вірогідності ERD. По закінченні ERD
системи, що проектується, буде складатися з остаточної ERD і заповнених описів об'єктів, атрибутів і
згрупованих доменів.

4. Проблема нормализации. 1NF и 2NF.

Нормальна форма — властивість відношення в реляційній моделі даних, що характеризує
його з точки зору надмірності, яка потенційно може призвести до логічно помилкових результатів
вибірки або зміни даних. Нормальна форма визначається як сукупність вимог, яким має
задовольняти відношення.
Перша нормальна форма.
Атрибут мусить мати тільки одне значення, що відповідає одному екземпляру об'єкта в даний
час. Не допускається присутність повторюваних груп. Аналітик має створити новий об'єкт, який має
зв'язок ступеня 1:m з вихідним об'єктом для того, щоб вилучити ці групи даних. Ім'я атрибута має бути
сингулярним. Повторюваність імен атрибутів у більшості випадків свідчить про наявність у моделі
помилкових об'єктів.
Друга нормальна форма.
Значення атрибутів мають бути залежними від повного унікального ідентифікатора. Ті атрибути,
значення яких залежать тільки від частини унікального ідентифікатора, повинні бути вилучені з моделі.
Такі атрибути звичайно мають на увазі відсутній, але зв'язаний відношенням об'єкт.

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

информационно - управляющих систем.
Процес проектування складних ІКС вимагає великих витрат часу, людських і матеріальних
ресурсів. У той самий час за відсутністю
стандартизованої технології проектування немає ніяких гарантій створення ефективної або
навіть просто працездатної ІКС. Це пояснюється тим, що якість результатів проектування в цьому
випадку в основному визначається особистим досвідом, знаннями і превагами розроблювачів, а також
має місце неповторюваність результатів, відсутність спадкоємності, трудність сприйняття і розуміння
концепцій розробки різними колективами проектувальників. Таким чином, з огляду на масштаби робіт
із проектування ІКС, для подолання зазначених недоліків необхідна стандартизована й
уніфікована технологія проектування ІКС.
 Основна мета стандартизації технології проектування складних ІКС полягає в створенні
методології та підбору інструментаря, що дозволяють підвищити ефективність процесів проектування,
формалізувати проектні процедури, регламентувати послідовність етапів проектування і здійснювати
постійний контроль за якістю результатів

6. Ключи. Функциональная и полная функциональная зависимость атрибутов.

Функциональная зависимость — это связь, которая может возникнуть между сущностями,
хранящимися в базе данных. Если сущность A функционально определяет сущность B, то такую
зависимость принято обозначать следующим образом:
A→B
здесь
A – детерминант отношения;
B – зависимая часть.

Полная функциональная зависимость между двумя атрибутами — это случай, когда между
двумя атрибутами A и B является прямая (A→B) и обратная (B→A) зависимость. При полной
функциональной зависимости одному значению атрибута A соответствует только одно значение
атрибута B. И, наоборот, одному значению атрибута. B соответствует значение атрибута A. Полная
функциональная зависимость между двумя атрибутами A и B обозначается A↔B.

7. Структурная модель SSADM. Основные модули и их назначение.

Каркас SSADM описывается структурной моделью, основными элементами которой, в
зависимости от уровня иерархии, являются модуль, стадия, этап или задача. Данная модель
состоит из набора иерархических схем, описывающих модули, стадии и этапы. В каждой схеме
четко определены соответствующие действия. Каждому модулю соответствует часть
структурной модели, покрывающая свой отрезок жизненного цикла SSADM, под которым
понимается процесс проектирования от инициирующего документа до окончания физического
проектирования системы.
В состав модели входят следующие модули:
• Модуль FS (Feasibility Study) анализа реализуемости
Цели:
установить может ли предполагаемая информационная система удовлетворить
специфические коммерческие требования организации;
установить для проектируемой информационной системы коммерческие предпосылки,
обеспечить возможность решения вопроса о достаточности ресурсов для проведения детальных
исследований, определить правильность стратегии разработки;
обеспечить руководству проекта возможности по выбору из множества технических и
бизнес - вариантов и подбору проекта, подходящего для реализации выбранного варианта.
• Модуль RA (Requirements Analysis) анализа требований
Цели:
 определить назначение системы;
 определить способ интеграции компонент информационной технологии с другими
элементами системы;
 сформировать мнение о себестоимости и прибыльности системы в целом;
 подтвердить возможность длительной эксплуатации системы;
 удовлетворить требования пользователей.
• Модуль RS (Requirements Specification) спецификации требований
Цель:
Представить организации-пользователю на рассмотрение «Спецификацию
требований», определяющую масштабы системы, соответствующее обеспечение и критерии
оценки приемлемости проектных решений, а также обеспечить возможность согласованной
разработки спецификации логической системы группой проектировщиков. Жизненно важным
является то, что «Спецификация требований» содержит соответствующий текущему моменту
времени полный набор требований, определенных при непосредственном участии пользователя
и согласованных с ним.

• Модуль LS (Logical System Specification) спецификации логической структуры

Цели:
обеспечить управление выбором технических средств, чтобы предложить наилучший в
денежном выражении вариант по отношению к имеющимся требованиям;
обеспечить группу физического проектирования, не зависящей от приложения
непроцедурной детализированной спецификацией требуемого функционального наполнения
системы, которая была бы соответствующим образом документирована и содержала
объективные оценки.
• Модуль PD (Physical Design) физического проектирования заключается в определении
физической среды системы, обеспечении соответствия процессов их спецификациям и
определении типа спецификаций для программ.
Процедуры физического проектирования предназначаются для использования совместно
со специальными руководствами по применению аппаратных и программных средств,
получаемых от поставщиков.
Совокупность этих модулей реализует полный цикл проектирования ИУС, который
называется жизненным циклом SSADM.

8. Реляционный анализ данных. Основные понятия и определения.

У рамках методу об'єкти ідентифікуються за допомогою логічного моделювання даних. Така
сама задача вирішується, якщо це необхідно, з використанням методу реляційного аналізу даних.
С помощью этого метода нормализуются структуры ввода-вывода, а результаты
распространяются на логическую модель данных, что приводит к улучшению обеих моделей.
Проверяется их правильность по отношению к растущему набору определений функции. Повышение
достоверности логической] модели данных и структур ввода-вывода уменьшает сложность задачи и
позволяет] заранее обнаружить потенциальные проблемы.
У рамках нашого курсу, ми використовуємо цей метод для ідентифікації об’єктів та зв’язків у
ERD. Також, при аналізі форм та документів, використовуваних у документопотоках системи, корисно
використовувати саме цей метод. Розглядаючи реляційний аналіз даних потрібно загадати, що
аналітик зобов'язаний особливу увагу приділити питанням визначення ролей елементів аналізованої
системи, (зокрема людей і організацій), вибрати назви об'єктів таким чином, щоб вони коротко і
водночас повно відбивали сутність об'єктів, які ідентифікуються, а потім описати їх відповідно до
вимог використовуваного методу. Це допомагає використовувати цей метод ефективніше.
Понятия: атрибуты, связи, таблицы, кортежи (строки таблиц), домен (Наиболее правильной
интуитивной трактовкой понятия домена является понимание домена как допустимого
потенциального множества значений данного типа.)?
9. Основные методы SSADM.
Основними методами SSADM є:
 Моделювання логічних даних
 Моделювання потоку даних
  Моделювання подій сутностей
Моделювання логічних даних - це процес виявлення, моделювання та документування
вимог до даних проектованої системи. В результаті виходить модель даних, яка містить сутності
(речі, про які бізнесу необхідно записувати інформацію), атрибути і зв’язки між об’єктами.
Моделювання потоку даних можна описати як процес ідентифікації, моделювання та
документування того, як дані переміщуються в інформаційній системі. Моделювання потоку даних
досліджує процеси (дії, які перетворюють дані з однієї форми в іншу), сховища даних (області
зберігання даних), зовнішні сутності (які відправляють дані в систему або отримують дані з
системи) і потоки даних.
Моделювання подій сутностей визначають як дволанцюжковий процес: моделювання
поведінки сутностей, ідентифікація, моделювання та документування подій, які впливають на
кожну сутність і послідовність (або історію життя) в якому відбуваються ці події, і моделювання
подій, проектуючи для кожної події процес координації історій життя сутностей.

10. Виды логических моделей данных и структура документации по ЛМД.

Існуюча або розроблювальною з нуля . Розроблювана система з 0 конкретизується за
допомогою логічної структури даних. Існуюча система описується і виходячи з неї
переглядаються структури даних на предмет видалення з відповідних описів конкретики
фізичної реалізації в існуючому системному середовищі, а також видалення даних
непотрібних для нової системи даних.
При логічному моделюванні даних об'єктами розгляди для аналітика є найбільш важливі з
погляду предметної чи області проектованої системи предмети і поняття. При цьому аналітик
повинний ідентифікувати головні атрибути (описатели властивостей) цих об'єктів, як частина
їхнього визначення.
До класичних способів побудови логічної структури відносять ієрархічну, мережеву та
реляційну моделі.
Ієрархічна модель запропонована в 1964 р. в СУБД IMS/360 фірми IBM. Модель
передбачає впорядкування даних за принципом ієрархії:
всі одиниці даних класифікуються за рівнями ієрархії;
до найвищого рівня ієрархії входить лише один елемент;
зв'язки встановлюються лише між елементами сусідніх рівнів з підпорядкуванням від
вищого до нижчого;
кожен елемент нижчого рівня пов'язується лише з одним елементом вищого рівня;
елемент початкового рівня ієрархії не може підпорядковуватися жодним іншим одиницям;
елементи останнього рівня ієрархії не мають підпорядкованих елементів даних.
Ієрархічна модель дозволяє використання лише зв'язків типу 1:1 та 1:N. Схема зв'язків між
даними в ієрархічній моделі може бути зображена у вигляді деревовидного графу.
Мережева модель запроваджена в 1969 р. за пропозицією і концепцією Data Base Task
Group (DBTG) і реалізована в однойменній СУБД. Мережеву структуру розглядають як
узагальнення ієрархічної за рахунок зняття обмежень на класифікацію одиниць даних та
встановлення зв'язків між ними. Ця модель розглядає всі елементи даних як рівноцінні та дозволяє
визначення довільної кількості зв'язків довільного характеру. Описати схему зв'язків можна у
вигляді мережевого графа.
Реляційна модель – запропонована в 1971 р. Е. Коддом (E. Codd) в якості однієї з
альтернатив у розв'язанні проблем створення та опрацювання баз даних великих об'ємів.
Принциповим моментом реляційної моделі є застосування табличного способу подання даних.
Таблиця в свою чергу є зовнішнім зображенням відношення (relation) засобу поєднання значень з
кількох множин. Перевагами реляційної моделі є:
простота та природність табличної форми зображення даних;
незалежність методів та процедур опрацювання від обсягів баз даних;
можливість визначення зв'язків між даними через самі дані;
наявність теоретичного обґрунтування методів та технологій роботи з реляційними базами
даних.
На сьогодні більшість технологій та систем управління базами даних реалізовані на основі
реляційної моделі.
Результаты анализа документируются в виде логической модели данных (ЛМД) состоит из:
• схемы, т.е. логической структуры данных (ЛСД);
• соответствующей документации по описанию объектов, связей, атрибутов.
По закінченні ERD системи, що проектується, буде складатися з остаточної ERD і
заповнених описів об'єктів, атрибутів і згрупованих доменів.

11. Основные философские концепции и три вида моделирования данных.

https://coderlessons.com/tutorials/bolshie-dannye-i-analitika/teoriia-khraneniia-dannykh/6-
chto-takoe-modelirovanie-dannykh#3
При переходе от требований к реальной базе данных, которая будет использоваться для
информационной системы, создаются три различных типа моделей данных.[2] Требования к
данным изначально записываются как концептуальная модель данных который, по сути,
представляет собой набор технологических независимых спецификаций данных и используется
для обсуждения начальных требований с заинтересованными сторонами. В концептуальная
модель затем переводится в логическая модель данных, который документирует структуры
данных, которые могут быть реализованы в базах данных. Для реализации одной концептуальной
модели данных может потребоваться несколько логических моделей данных. Последний шаг в
моделировании данных - преобразование логической модели данных в физическая модель
данных который организует данные в таблицы и учитывает сведения о доступе,
производительности и хранении. Моделирование данных определяет не только элементы данных,
но также их структуры и отношения между ними.
Концептуальная схема: описывает семантику домена (объем модели). Например, это может
быть модель области интересов организации или отрасли. Он состоит из классов сущностей,
представляющих виды важных вещей в предметной области, и утверждений взаимосвязей об
ассоциациях между парами классов сущностей. Концептуальная схема определяет виды фактов
или предположений, которые могут быть выражены с помощью модели. В этом смысле он
определяет разрешенные выражения на искусственном «языке» с областью действия, которая
ограничена областью действия модели. Проще говоря, концептуальная схема - это первый шаг в
организации требований к данным.
Логическая схема: описывает структуру некоторой области информации. Он состоит из
описаний (например) таблиц, столбцов, объектно-ориентированных классов и тегов XML.
Логическая схема и концептуальная схема иногда реализуются как одно и то же.[2]
Физическая схема: описывает физические средства, используемые для хранения данных.
Это касается разделов, процессоров, табличные пространства, и тому подобное.

12. Ключи, их типы и использование при логическом моделировании данных.

У рамках методу об'єкти ідентифікуються за допомогою логічного моделювання даних.
Така сама задача вирішується, якщо це необхідно, з використанням методу реляційного аналізу
даних.
Коли аналітик при аналізі системи вводить нове "ім'я" чи "ключ", то вони мають бути
поняттями, які користувач зможе чітко відрізнити від інших понять схожого типу, тобто об'єктів.
Ці ключі мають ідентифікувати групи даних, які необхідно виділити в системі.
Атрибут може бути або описовим (тобто звичайним дескриптором сутності), або входити
до складу унікального ідентифікатора (первинного ключа). Унікальний ідентифікатор - це чи
атрибут сукупність атрибутів і/чи зв'язків, призначена для унікальної ідентифікації кожного
екземпляра даного типу сутності. У випадку повної ідентифікації кожен екземпляр даного типу
сутності цілком ідентифікується своїми власними ключовими атрибутами.
Атрибути, що визначають первинний ключ, розміщаються нагорі списку і виділяються
підкресленням.\
Кожна сутність повинна володіти хоча б одним можливим ключем. Можливий ключ
сутності - це один чи кілька атрибутів, чиї значення однозначно визначають кожен екземпляр
сутності. При існуванні декількох можливих ключів один з них позначається як первинний ключ, а
інші - як альтернативні ключі.
Первичный ключ (primary key - PK) - это атрибут или группа атрибутов, однозначно
идентифицирующая экземпляр сущности. Атрибуты первичного ключа на схеме модели БД не
требуют специального обозначения - это те атрибуты, которые находятся в списке атрибутов выше
горизонтальной линии. Правильный выбор РК может оказать значительное влияние на
эффективность будущей ИС. В одной сущности могут оказаться несколько атрибутов или наборов
атрибутов, претендующих на роль первичного ключа. Такие претенденты
называются потенциальными ключами (candidate key - CK).
Ключи могут быть сложными, т.е. содержать несколько атрибутов. Сложные первичные
ключи не требуют специального обозначения – это список атрибутов выше горизонтальной линии.
Альтернативный ключ (Alternate Key) - это потенциальный ключ, не ставший первичным.
Внешние ключи (Foreign Key) создаются автоматически, когда связь соединяет сущности:
связь образует ссылку на атрибуты первичного ключа в родительской сущности, и эти атрибуты
образуют внешний ключ в дочерней сущности (миграция атрибутов ключа). Атрибуты внешнего
ключа, обозначаются символом (FK) после своего имени (см. рис. 4).
 13. Суть метода реляционного анализа данных и его роль в SSADM.
У рамках методу об'єкти ідентифікуються за допомогою логічного моделювання даних.
Така сама задача вирішується, якщо це необхідно, з використанням методу реляційного аналізу
даних.
С помощью этого метода нормализуются структуры ввода-вывода, а результаты
распространяются на логическую модель данных, что приводит к улучшению обеих моделей.
Проверяется их правильность по отношению к растущему набору определений функции.
Повышение достоверности логической] модели данных и структур ввода-вывода уменьшает
сложность задачи и позволяет] заранее обнаружить потенциальные проблемы.
У рамках нашого курсу, ми використовуємо цей метод для ідентифікації об’єктів та зв’язків
у ERD. Також, при аналізі форм та документів, використовуваних у документопотоках системи,
корисно використовувати саме цей метод. Розглядаючи реляційний аналіз даних потрібно
загадати, що аналітик зобов'язаний особливу увагу приділити питанням визначення ролей
елементів аналізованої системи, (зокрема людей і організацій), вибрати назви об'єктів таким
чином, щоб вони коротко і водночас повно відбивали сутність об'єктів, які ідентифікуються, а
потім описати їх відповідно до вимог використовуваного методу. Це допомагає використовувати
цей метод ефективніше.
Технологія SSADM дає змогу розглядати проект у 3 проекціях: «дані» — «подія», «події» —
«задачі» та «дані» — «задачі». Реляційний аналіз даних допомогає розглядати проект у проєкціі
«дані» — «задачі».

14. Понятия мобильности и обязательности связи.

Обов’язковість
Ця характеристика визначає тип зв'язку за ознакою обов'язковості. Зв'язок визначається як
обов'язковий, якщо участь об'єкта в ньому обов'язкова, тобто екземпляр об'єкта не може існувати
без наявності елементів зв'язку. Зв'язок визначається як необов'язковий, якщо участь об'єкта в
ньому необов'язкова, тобто екземпляр об'єкта може існувати і без наявності елементів зв'язку.
Для зображення на схемі обов'язкових зв'язків використовується суцільна лінія. Вона
показує, що екземпляр об'єкта на даному кінці завжди повинен асоціюватися з екземпляром об'єкта
на іншому кінці зв'язку.
Необов'язкові зв'язки зображуються у вигляді пунктирної лінії, яка показує, що екземпляр
об'єкта на даному кінці необов'язково зв'язувати з екземпляром об'єкта на іншому кінці зв'язку.
Мобільні та немобільні об'єкти
У деяких випадках екземпляр предметного об'єкта може бути співвіднесений екземпляру
цільового об'єкта, а згодом вони можуть бути рознесені і перший екземпляр співвідноситься
іншому екземпляру цільового об'єкта. Такий цільовий об'єкт називається мобільним. Якщо це не
дозволяється за якимись причинами, то цільовий об'єкт називається немобільним. Наприклад,
компресорний цех завжди буде у складі компресорної станції. З іншого боку, хоча компресорна
станція має знаходитися в одному і тільки в одному ЛПУ, організаційна структура може бути
реорганізована, а в цьому випадку компресорна станція переміщується із одного ЛПУ в інше.
 В обов'язкових зв'язках цільові об'єкти завжди мають бути немобільними. У кожному
необов'язковому зв'язку цільовий об'єкт потенційно мобільний.

15. Суть метода определения функций и его роль в SSADM.

Визначення функції системи - це перший, найбільш важкий і важливий момент системного
аналізу.
Виявлення функції системи - складний, творчий процес. Цей процес включає в себе п'ять
основних кроків:
Вибір об'єкта системного аналізу. Основними методами, застосовуваними на цьому етапі
системної процедури, є методи неформальних дискусій, ділові ігри, формальні процедури вибору.
Побудова ієрархії функцій. Об'єкт, обраний на першому кроці, розглядається як система і,
отже, для нього повинна бути виявлена функція. Вже згадана система завжди є частиною більшої
системи, яка, як будь-яка система, має свою функцію. У свою чергу, ця велика система є частина
системи більш високого рівня з відповідною їй функцією. Отже, можна побудувати і дослідити
ієрархію функцій. Такий процес носить назву «розширення функції системи». Розширення функції
необхідно здійснювати для будь-якого об'єкта дослідження, незалежно від його типу і розміру.
Побудова ієрархії функцій допомагає оцінити перспективи розвитку досліджуваної системи як
частини більш загальної системи.
Вибір функції. Необхідно прагнути до вибору функції на якомога більш високому рівні, так
як це скорочує число обмежень, що накладаються на систему, і дозволяє отримати додатковий
ефект від можливості перерозподілу ресурсів в системі.
Виявлення мінімального числа обмежень. На цьому кроці необхідно виявити всі
обмеження, які закладаються системою більш високого рівня на реалізацію функції, обраної на
кроці 3. Такі обмеження завжди існують, так як, незалежно від обраного рівня функції, система, що
реалізує її, є частиною системи більш високого рівня.
Виділення функціональних компонентів. Мета цього кроку полягає в тому, щоб виявити
відносно незалежні компоненти. Повна незалежність таких компонент неможлива - в іншому
випадку система перестає існувати як ціле. Виділення функціональних компонент виробляється у
великих складних системах для спрощення системного дослідження і можливості проводити
роботу паралельно декількома групами. Виділення і аналіз функціональних компонент
проводиться з урахуванням функції всієї системи. Кожна функціональна компонента розглядається
як система і може бути повністю описана за допомогою конструктивного визначення системи.
Метод визначення функцій відіграє значну роль у SSADM, адже SSADM – структурна
методологія, сутність якої декомпозувати систему на окремі части. Метод визначення функцій
дозволяє визначити, на які функції можливо розбити систему.
Выделение функций применяется, например, при анализе требований и логическом
проектировании.

16. Понятия группы исключающих связей и рекурсии.

Групи виключних зв'язків
 Якщо участь екземпляра об'єкта в одному зв'язку забороняє його участь в інших зв'язках, те
це означає наявність у схемі групи виключних зв’язків. Усі зв'язки, що входять у таку групу,
повинні мати спільний предметний об'єкт і однакову характеристику ступіню. На момент розгляду
для будьякого екземпляра спільного об'єкта може існувати тільки один зв'язок із групи. На ERD
така група зв'язків зображується у вигляді дуги. Дуги рисуються біля відповідного об'єкта та
відносяться до тих зв'язків, лінії яких перетнуті цими дугами. Якщо необхідно, зв'язки можна
переупорядковувати, щоб уникнути розривів дуг і плутанини. Об'єкт може брати участь у
декількох різних групах. У зв’язку з цим на ERD різні дуги можуть бути довільним образом
позначені. Однак, кінці ліній зв'язку не повинні брати участь більш ніж у одній групі, що гарантує
ясність і упорядкованість ERD.

Рекурсивні зв'язки
Існує дві основні ситуації , в яких зручно зображувати об'єкт зв'язаним із самим собою,
тобто з рекурсивним зв'язком.
Ієрархія представляє структури, властиві організаційному керуванню на підприємствах.
Така структура зображена на рис. 3.6 та описується такими твердженнями: “Кожний менеджер
може бути відповідальним за одного чи більше менеджерів”.
В цьому спрощеному зображенні обидва кінця лінії зв’язку мають бути необов’язковими.
Це дозволяє головному менеджеру не звітувати перед іншими менеджерами, а молодшим — бути
підлеглими тільки одному менеджеру (див. рис. 3.6, а). Ця ситуація може бути зображена у
вигляді, що представлений на рис. 3.6, б, де рекурсія - це петля зі ступенем 1:m.

Мережа характеризується наявністю зв'язків типу m:n і найбільш часто виникає при описі
технології виробничих процесів. Будь-яка підмножина складальних одиниць тут може входити до
складу інших підмножин як їхня частина і може сама складатися з інших підмножин. Це показано
на рис. 3.8,

Обидва кінці лінії зв'язку повинні бути необов'язковими, тому що є остаточні продукти, що
не є складальними одиницями, і є елементарні підмножини, що не мають у своєму складі
складальних одиниць. Тут базове позначення для рекурсії - петля, що характеризується ступенем
зв'язку m:n. Зв'язки такого типу необхідно розкривати шляхом заміни їх на два зв'язки типу 1:m, як
це показано на рис. 3.8, б.

Найменш загальним є тип зв'язку є зв'язок ступеня 1:1. Звичайно цей вид зв'язку
використовується для відображення можливості заміни екземпляра об'єкта (наприклад, один
стандартний елемент може бути замінений іншим, якщо першого немає на складі). У цьому
випадку, якщо один з кінців зв'язку не входить у виключну групу обидва кінці зв'язку мають бути
необов'язковими.

17. Взаимосвязь методов на стадиях «Анализ требований» и «Спецификация

требований»
 Аналіз вимог дуже тісно пов'язаний з іншими етапами проектування.
Основною вихідною інформацією процесу проектування системи є інформаційні вимоги,
які включають обмеження, що існують в організації, елементи даних і засоби опрацювання даних.
Необхідні аналітику елементи даних і їхні зв'язки важко одержати з аналізу тільки
основних принципів комерційної або іншої діяльності організації, оскільки між окремими
організаціями є занадто багато розходжень. Основні принципи забезпечують побудову схеми
лише в самому загальному вигляді, у той час як інформація, що надається користувачами, які
знаходяться на всіх рівнях організації, дасть можливість цю схему деталізувати. Елементи даних
і їхній зв'язок, що будуть уточнюватися на наступних етапах проектування бази даних, мають
бути визначені під час загального аналізу вимог.
Тому проблема полягає у встановленні порозуміння з користувачами з метою розробки
попереднього загального уявлення про дані і засоби їхнього опрацювання, що забезпечить
надійність результатів на наступних етапах проектування. Таке загальне уявлення може бути
вироблено тільки разом із користувачами під час загального аналізу вимог.
Результатом виявлення вимог є реєстр вимог.
Способи представлення вимог
Документація, в якій використовується чітко структурована і акуратно використовувана
природна мова.
Графічні моделі, що ілюструють процеси трансформації стану системи і їх зміни,
взаємодії даних, атак же логічні потоки, класи об'єктів і відношення між ними.
Формальні специфікації, де вимоги визначені за допомогою математично точних,
формальних логічних мов.
Для того, щоб підвищити рівень інформативності вимог, усунути взаємні суперечності і
добитися виконання їх інших основних характеристик, здійснюється перехід від повністю
неформалізованих текстів до частково регламентованих текстів, класифікація, побудова
моделей, прототипування.
Найпопулярнішим і вельми ефективним способом підвищення інформативності вимог є
оформлення їх у вигляді варіантів використання (use case).
Опис нефункціональних вимог зазвичай здійснюється у формі, близькій до вільного
формату опису варіанту використання. Рекомендується концентрувати нефункціональні вимоги
в документі, що описує варіант використання в усіх випадках, коли це можливо. У випадку, якщо
нефункціональні вимоги носять загальний характер і не можуть бути прив'язані до конкретного
прецеденту – вони виносяться в документ «Додаткова специфікація».
Висновок: У цілому, взаємозв’язок між цьома двома етапами полягає в тому, що
специфікація уявляє собою етап, у якому вимоги представлені у виді «письмових вимог», тобто
розформованих по різним категоріям вимог, і цей етап був можливий завдяки етапам виявлення
та аналізу вимог.

18. Правила формирования фразы – описателя связи.

Ця фраза завжди описує зв'язок від кінця, що примикає до предметного об'єкта. Таким
чином, якщо дивитися на зв'язок з іншого кінця, то цільовий об'єкт стане предметним і зв'язок буде
описуватися іншою фразою. Фрази складаються так, щоб точно і ясно описати значення і зміст
появи зв'язків на схемі. Фраза є частиною визначення об'єкта, що примикає до даного кінця зв’язку

Вибір фрази здійснюється таким чином, щоб одержуване в результаті твердження читалося
правильно, коли перед нею йдуть слова "має бути" 133 (випадок обов'язкового кінця лінії зв'язку)
чи слова "може бути" (випадок необов'язкового кінця зв'язку) .Така дисципліна складання фраз
істотно підвищує зрозумілість схем. Кожна лінія зв'язку має бути придатною для читання з обох
кінців як ясне, однозначне твердження. Твердження зв'язку включає в свій склад її обов’язковість,
значення і ступінь.
Його конструкція має такий вигляд:
слово "кожен", за яким прямує;
ім'я предметного об'єкта, за яким прямує;
слова "має бути" чи "може бути", за якими прямує;
фраза-описувач зв'язку, за якою прямує;
слова "один і тільки один" чи "один чи більш", за якими прямує;
ім'я цільового об'єкта.
В множині ім'я об'єкта використовується, якщо зв'язок має ступінь "багато". Ступінь
"багато" читається як "один чи більше", а ступінь "один" як "один і тільки один". Вираз "один і
тільки один" переважніше, ніж просте слово "один", тому що не породжує двозначності в фразах.
 Фрази, що описують лінії зв'язку, здобувають особливу важливість там, де має місце кілька
зв'язків між двома об'єктами:

19. Взаимосвязь методов в SSADM на стадии «Логическая спецификация

системы».

20. Понятия информационного объекта, связи и степени связи.

Об'єкт – це будь-яке конкретне чи абстрактне поняття, що вважається істотним і важливим
для системного середовища, яке аналізується чи проектується. Кожному об'єкту привласнюється
унікальне ім'я. Прикладами об'єктів у поданій на рис.3.1 ERD для підсистеми “Оперативно-
диспетчерське управління” є "Добові дані за АГНКС" (AGNKS DAY), "Довідник АГНКС"
(AGNKS), "Оперативні повідомлення" (CEH NEIGHBO). На схемах об'єкти зображуються у
вигляді прямокутників із закругленими кутами (далі будемо називати їх комірками), що містять
усередині власні імена.
Зв'язки є бінарними в тому розумінні, що вони завжди асоціюються тільки з двома
об'єктами, або з одним об'єктом , зв'язаним із самим собою. У такий спосіб усі, виникаючі в
процесі побудови моделі ситуації, мають бути зведені до цих двох випадків. Зв'язок завжди
асоціюється з подіями, що відбуваються в об'єктах, які зв'язуються. Він представляється на схемах
або у вигляді лінії, що з'єднує два об'єкти, або у вигляді петлі, що з'єднує об'єкт із самим собою
Кожний із двох кінців лінії, що зображує зв'язок, описується такими характеристиками:
 - ступінь, тобто вказівка на те скільки (один або багато) екземплярів об'єкта на цьому кінці
зв'язку може асоціюватися з екземпляром об'єкта на іншому кінці;
- обов’язковість, тобто вказівка на те, чи кожен екземпляр об'єкта на даному кінці зв'язку
має завжди асоціюватися з екземпляром об'єкта на іншому кінці;
- фраза-описувач зв'язку, тобто змістовний опис характеру зв'язку від об'єкта, що примикає
до даного кінця лінії зв'язку.
Є три основні типи ступеня:
- один до одного; коли з одним екземпляром об'єкта асоціюється один екземпляр іншого
об'єкта;
- один до багатьох; коли з одним екземпляром об'єкта асоціюється один чи більше
екземплярів іншого об'єкта;
- багато до багатьох; коли з одним або більше екземплярів об'єкта асоціюється один або
більше екземплярів іншого об'єкта. Для представлення на схемі поняття "багато" на відповідному
кінці лінії зв'язку зображується розгалуження у вигляді так званої воронячої лапки (crow's foot). Її
поява на кінці лінії означає , що один або більше екземплярів об'єкта на цьому кінці можуть
асоціюватися з одним екземпляром об'єкта на іншому. Якщо реальна множина екземплярів відома і
постійна, то це може бути відображено на схемі довільним позначенням. Для кожного зв'язку
аналітик має з'ясувати, на який момент часу вона мусить відображувати ситуацію, щоб точно
вказати ступінь кожного кінця на множині ліній зв'язку.
21. Виды логических моделей данных и их использование на различных
стадиях.
Логическая модель данных системы которая существует и ЛМД проектируемой
По закінченні ERD системи, що проектується, буде складатися з остаточної ERD і
заповнених описів об'єктів, атрибутів і згрупованих доменів.
При розробці ERD існуючого системного оточення важливо, щоб доповнення до "Описів
об'єктів", які містять основні характеристики для кожного об'єкта, а також зв'язки і головні
атрибути до них, реєструвалися в міру виявлення цієї інформації. Будь-яка інша потрібна
інформація, якщо вона відноситься до необхідної системи аналогічним чином, має вноситися в цю
документацію або реєструватися в "Каталозі вимог".
ERD необхідної системи будується шляхом модифікації та розширення відповідної ERD
існуючого системного оточення, виходячи з інформації про вимоги до нової системи, які
обумовлені обраною структурою проектованої системи та розміщені в "Каталог вимог".
При логічному моделюванні даних об'єктами розгляди для аналітика є найбільш важливі з
погляду предметної чи області проектованої системи предмети і поняття. При цьому аналітик
повинний ідентифікувати головні атрибути (описатели властивостей) цих об'єктів, як частина
їхнього визначення.
До класичних способів побудови логічної структури відносять ієрархічну, мережеву та
реляційну моделі.
Ієрархічна модель запропонована в 1964 р. в СУБД IMS/360 фірми IBM. Модель
передбачає впорядкування даних за принципом ієрархії:
всі одиниці даних класифікуються за рівнями ієрархії;
 до найвищого рівня ієрархії входить лише один елемент;
зв'язки встановлюються лише між елементами сусідніх рівнів з підпорядкуванням від
вищого до нижчого;
кожен елемент нижчого рівня пов'язується лише з одним елементом вищого рівня;
елемент початкового рівня ієрархії не може підпорядковуватися жодним іншим одиницям;
елементи останнього рівня ієрархії не мають підпорядкованих елементів даних.
Ієрархічна модель дозволяє використання лише зв'язків типу 1:1 та 1:N. Схема зв'язків між
даними в ієрархічній моделі може бути зображена у вигляді деревовидного графу.
Мережева модель запроваджена в 1969 р. за пропозицією і концепцією Data Base Task
Group (DBTG) і реалізована в однойменній СУБД. Мережеву структуру розглядають як
узагальнення ієрархічної за рахунок зняття обмежень на класифікацію одиниць даних та
встановлення зв'язків між ними. Ця модель розглядає всі елементи даних як рівноцінні та дозволяє
визначення довільної кількості зв'язків довільного характеру. Описати схему зв'язків можна у
вигляді мережевого графа.
Реляційна модель – запропонована в 1971 р. Е. Коддом (E. Codd) в якості однієї з
альтернатив у розв'язанні проблем створення та опрацювання баз даних великих об'ємів.
Принциповим моментом реляційної моделі є застосування табличного способу подання даних.
Таблиця в свою чергу є зовнішнім зображенням відношення (relation) засобу поєднання значень з
кількох множин. Перевагами реляційної моделі є:
простота та природність табличної форми зображення даних;
незалежність методів та процедур опрацювання від обсягів баз даних;
можливість визначення зв'язків між даними через самі дані;
наявність теоретичного обґрунтування методів та технологій роботи з реляційними базами
даних.
На сьогодні більшість технологій та систем управління базами даних реалізовані на основі
реляційної моделі.
Результаты анализа документируются в виде логической модели данных (ЛМД) состоит из:
• схемы, т.е. логической структуры данных (ЛСД);
• соответствующей документации по описанию объектов, связей, атрибутов.
По закінченні ERD системи, що проектується, буде складатися з остаточної ERD і
заповнених описів об'єктів, атрибутів і згрупованих доменів.

22. Взаимосвязь МПД и ЛМД.

Метод моделювання потоків даних (МПД) використовується на стадіях аналізу вимог і
складання специфікацій вимог. Він не призначений для детального опису функціонування системи.
За допомогою даного методу здійснюється моделювання і аналіз інформаційних потоків між
процедурами обробки даних на структурно-функціональному рівні опису процесу функціонування
існуючої або проектованої системи.
Логічне моделювання даних (ЛМД) – візуальне уявлення структур даних, їх атрибутів та
бізнес-правил. Логічна модель представляє дані таким чином, щоб вони легко сприймалися бізнес-
користувачами. Проектування при цьому вільно від вимог платформи і мови реалізації або способу
подальшого використання даних.
Моделювання потоків даних відбувається паралельно з логічним моделюванням даних, так
як обидві моделі повинні бути узгоджені між собою.
На першій стадії SSADM-технології МПД існуючої системи розвивається паралельно з
ЛМД існуючого системної середовища, а на третій стадії паралельно з ЛМД необхідної системи.
Тут аналітик повинен упевнитися, що дані, які асоційовані з об'єктами, зображеними на
ЛМД, містяться в МПД в сховищах даних з відповідними вхідними потоками.

23. Моделирование потоков данных. Назначение и использование в технологии

проектирования. Связь с другими методами.
Метод моделювання потоків даних (МПД) використовується на стадіях аналізу вимог і
складання специфікацій вимог. Він не призначений для детального опису функціонування системи.
За допомогою даного методу здійснюється моделювання і аналіз інформаційних потоків між
процедурами обробки даних на структурно-функціональному рівні опису процесу функціонування
існуючої або проектованої системи.
Метод моделювання потоків даних використовується на стадіях «Аналіз вимог» та
«Складання специфікацій вимог».
Головна мета методу – отримати вихідні дані для ідентифікації подій і функцій
проектованої системи. Тому схеми потоків даних формуються так, щоб по них можна було легко
ідентифікувати функції системи. МПД верхнього рівня зазвичай відображає призначені для
користувача уявлення про функціональну структуру системи, а в міру деталізації на наступних
рівнях, схеми потоків даних стають для проектованої системи компонентами шуканого
функціонального розбиття.
Суть моделювання потоків даних при проектуванні складних інформаційно-керуючих
систем (ІКС) – це створення так званих діаграм потоків даних (Data Flow Diagram – DFD). DFD
відображає ІКС з точки зору переміщення даних в системі.
Результати моделювання потоків даних концентруються в таких продуктах методики:
ієрархічний комплект діаграм (DFD);
документи "Опис елементарного процесу";
документи "Опис зовнішнього об'єкта";
документи "Опис вхід-вихід".
Моделювання потоків даних відбувається паралельно з логічним моделюванням даних
(ЛМД), так як обидві моделі повинні бути узгоджені між собою.

24. Состав ЛМД СС.

МД існуючого системного середовища (ЛМД СС) є детальним описом даних, що
використовуються цим середовищем і створюваних в ній. Рівень деталізації цієї моделі повинен
відповідати рівню поточної фізичної та логічної моделей потоків даних.
 При логічному моделюванні даних існуючого системного середовища об'єктами розгляду є
найбільш важливі з точки зору предметної області предмети і поняття. При цьому аналітик
повинен ідентифікувати головні
атрибути цих об'єктів.
Детальність опису досягається за рахунок оформлення спеціальної документації у вигляді
комплекту стандартних форм, який складається з:
форм опису об'єктів;
опису зв'язків;
форм опису атрибутів (частина каталогу даних);
форм опису згрупованих доменів (частина "Каталогу даних") і додається до відповідної
логічної структурі даних.
Результати аналізу документуються у вигляді логічної моделі даних, яка складається з:
схеми, тобто логічної структури даних (ЛСД);
відповідної документації по опису об'єктів, зв'язків, атрибутів.

25. Состав МПД на разных стадиях проектирования.

Проектування системи на основі методу потокових діаграм складається з таких етапів:
1) розробка діаграм потоків даних – створюються діаграми потоків даних, які
відображають границю між системою й зовнішнім світом, також зв’язки між даними й процесами
усередині системи;
2) одержання списків елементів даних – визначаються списки елементів даних, що
зберігаються в кожному накопичувачі, наявному в DFD;
3) визначення структур даних – аналіз сутностей і зв’язків даних на третьому етапі
дозволяє визначити їхню логічну структуру;
4) визначення моделі даних – отримана інформація представляється у вигляді двовимірних
таблиць, що є результатом четвертого етапу;
5) деталізація діаграм потоків даних – виробляється уточнення DFD на основі аналізу й
упорядкування сутностей і зв’язків, зробленого на попередніх етапах;
6) поділ одержаної моделі на процеси й дані – визначаються процедурні одиниці,
які характеризуються входом і виходом, і є компонентами розроблювальної системи;

7) остаточна деталізація одержаної моделі – докладна специфікація процедурних одиниць

виробляється на сьомому етапі.
Специфікації визначають:

o місце процедурної одиниці в системі;

o фрагменти таблиці даних, до яких має доступ процедурна одиниця;

o вихідні (у тому числі й екранні) форми процедурної одиниці.

Одержані в такий спосіб специфікації і є вихідним матеріалом для програмістів при
розробці програмних компонентів системи.
 За умов достатнього рівня автоматизації методу на кожному з етапів можуть
використовуватися засоби контролю коректності побудованих моделей. Розробка подібних
засобів не тільки полегшує працю системних аналітиків, але й дозволяє знизити ймовірність
появи помилок на ранніх етапах розробки.

26. Цели логического моделирования данных, состав и структура ЛМД.

Логічне моделювання даних призначено для побудови точної інформаційної моделі вимог
до всієї проектованої системі в цілому або до окремих її частин. Логічне моделювання даних
пронизує всю технологію проектування SSADM і при цьому відбувається поступова
трансформація виду вимог від уявлення в категоріях предметної області системи до подання в
термінах системного функціонування.
Результати аналізу документуються у вигляді логічної моделі даних (ЛМД) складається з:
o схеми, тобто логічної структури даних (ЛСД);
o відповідної документації по опису об'єктів, зв'язків, атрибутів.
ЛСД є формалізованим відображенням структури інформації, використовуваної в системі, і
описують різні типи зв'язку, які існують або можуть існувати між об'єктами. Кожен об'єкт в ЛСД
зображується як деяка осередок, а зв'язок - як лінія, що з'єднує об'єкти.
Логічне моделювання даних в SSADM орієнтоване на проектування комп'ютерних систем.
Разом з цим, можливість зміни рівня деталізації розгляду дозволяє використовувати даний метод
для задоволення інших потреб, включаючи створення моделей для підтримки стратегічних
досліджень, моделювання вимог до інформаційного обміну в системах, що не включають до свого
складу комп'ютери і бази даних, а також як засіб спілкування при аналізі складних структур. ЛМД
є також важливим елементом адміністрування даних, так як за своєю суттю вона надає посилання
між смисловим змістом і значеннями даних, які в ній описані, і зрозуміла всім зацікавленим
особам.

27. Понятия и обозначения, используемые при синтезе МПД.

Суть моделювання потоків даних при проектуванні складних інформаційно керуючих
систем – це створення так званих діаграм потоків даних (DFD). DFD нотація складається з
наступних елементів:

o Процес, тобто функція або послідовність дій, які потрібно зробити, щоб дані
були оброблені. У назвах процесів прийнято використовувати дієслова.
o Зовнішні сутності – це будь-які об'єкти, які не входять до самої
системи, але є для неї джерелом інформації або одержувачами будь-
якої інформації з системи після обробки даних. Це може бути людина, зовнішня
система, будь-які носії інформації і сховища даних.
o Сховище даних – внутрішнє сховище даних для процесів в системі.
Дані, що надійшли перед обробкою, і результат після обробки, а також проміжні
значення повинні десь зберігатися. Це і є бази даних, таблиці або будь-який інший варіант
організації та зберігання даних. Тут зберігаються дані про клієнтів, заявки клієнтів,
видаткові накладні та будь-які інші дані, які надійшли в систему або є результатом обробки
процесів.
o Потік даних. В нотації відображається у вигляді стрілок, які показують, яка
інформація входить, а яка виходить з того чи іншого блоку на діаграмі.

28. ЛМПД, назначение и роль в процессе проектирования.

ЛМПД – логическая модель потоков данных
Цель построения такой модели состоит в устранении дублирования в обработке и хранении
данных, а также перегруппировке в соответствии с требованиями пользователей к низовым
процессам функциональных областей. ЛМПД создается на базе МПД СС путем выполнения
особых процедур.
Эти действия состоят в следующем:

• рационализация хранилищ данных;

• рационализация низовых процессов;

• перегруппировка низовых процессов;

• проверка ЛМПД на содержательность и полноту.

Все или некоторые из этих действий могут повторяться, если это необходимо, для того,
чтобы обеспечить логическую полноту и содержательность результирующей модели/
https://studfile.net/preview/3021742/page:28/
29. Правила построения СПД.
СПД – сети передачи данных
На украинском – МПД (мережі передачі даних)
Основою для створення мережі передачі даних є первинна мережа, яка являє собою
сукупність мережевих вузлів, мережевих станцій і ліній передачі, що утворить мережу типових
каналів передачі та типових групових трактів.
Каналом передачі називається сукупність технічних засобів і середовища поширення, що
забезпечує передачу сигналів електрозв'язку або в певній смузі частот, або з певною швидкістю
між двома станціями або вузлами. Канал з нормованими параметрами називається типовим.
Груповий тракт - це сукупність технічних засобів, що забезпечує передачу сигналів
електрозв'язку або в смузі частот, або зі швидкістю передачі нормованої групи каналів. Якщо
параметри групового тракту нормовані, то тракт називається типовим. Групові тракти будуються
на основі ліній передачі.
Лінія передачі первинної мережі - це сукупність фізичних ланцюгів, лінійних трактів
однотипних і різнотипних систем передачі, що мають спільні середу поширення, лінійні споруди і
пристрої їх обслуговування. Лінії передачі розрізняються залежно від первинної мережі, до яких
вони належать, і від середовища поширення. В даний час найбільшого поширення набули
радіорелейні, тропосферних, провідні та супутникові лінії передачі.
 Мережевим вузлом (МВ) первинної мережі називається комплекс технічних засобів, що
забезпечує:
організацію і транзит типових групових трактів і типових каналів передачі первинної
мережі;
перемикання зазначених трактів і каналів, що належать різним лініям передачі;
надання необхідного числа каналів і групових трактів для утворення вторинних мереж.
Мережеві станції первинної мережі забезпечують організацію типових каналів і трактів,
надання їх для утворення вторинних мереж і з'єднання каналів і групових трактів різних вторинних
мереж між собою.
Первинні мережі підрозділяються на місцеві, внутрішні, зонові і магістральні.
Частина первинної мережі, обмежена територією міста або сільського району, називається
місцевої первинною мережею.
Внутрішньозонова первинна мережа - це частина первинної мережі, обмежена територією,
що збігається з зоною нумерації, і забезпечує з'єднання між собою типових групових трактів і
типових каналів передачі різних місцевих первинних мереж цієї зони. Зона нумерації, як правило,
збігається з адміністративними кордонами області.
Сукупність внутризонової первинної та місцевих первинних мереж на території, що
збігається з зоною нумерації, утворює зонову первинну мережу.
Частина первинної мережі, що з'єднує між собою типові групові
тракти, а також типові канали передачі внутрішньозонових первинних мереж на всій
території країни, утворює магістральну первинну мережу.
Мережевим вузлам і лініям передачі присвоюються найменування відповідно до того, якій
первинній мережі вони належать.
Важливим поняттям, що належить до первинних мереж, є система передачі, під якою
розуміється сукупність лінійного тракту, типових групових трактів і каналів передачі первинної
мережі. Система передачі включає станції системи передачі і середу поширення.
У системах передачі з частотним поділом каналів (ЧПК) для передачі сигналів по кожному
з каналів виділяється певна смуга частот.
Системи передачі, в яких для передачі сигналів по кожному з каналів в лінійному тракті
відводяться певні інтервали часу, називаються системами з тимчасовим поділом каналів (ТПК).
На сучасному етапі в магістральних первинних мережах більшого поширення мають
системи з частотним поділом каналів. Системи з тимчасовим поділом впроваджуються переважно
в місцевих первинних мережах.
Основними характеристиками первинних мереж незалежно від використовуваних систем
передачі є:
структура, що визначає взаємне розташування мережевих вузлів
станцій і ліній передачі без урахування їх положення на місцевості;
топологія - структура з урахуванням реального стану на місцевості;
потужність, яка визначається числом типових каналів або сумарною шириною спектра
частот всіх каналів зв'язку в лінії передачі;
 живучість, яка визначає стійкість ліній передачі і вузлів первинної мережі до пошкоджень.
Стійкість від пошкоджень визначається технічною надійністю обладнання, стійкістю від
стихійних лих і рядом інших факторів.

30. Основные виды ЛМД, цели их разработки и использования.

Основними типами логічних моделей даних є: ієрархічна, мережева і реляційна.
Ієрархічна модель даних дозволяє будувати бази даних з деревовидною структурою. У них
кожен вузол містить свій тип даних (сутність). На верхньому рівні дерева в цій моделі є один вузол -
корінь, на наступному рівні розташовуються вузли, пов'язані з цим коренем, потім вузли, пов'язані з
вузлами попереднього рівня, і т.д., причому кожен вузол може мати тільки одного предка (Рисунок -1).
Такі бази підтримують відношення типу «один до багатьох».
Пошук даних в ієрархічній системі завжди починається з кореня. Потім проводиться спуск з
одного рівня на інший, поки не буде досягнутий шуканий рівень. Переміщуватися між пунктами від
одного запису до іншого здійснюються за допомогою посилань.
Основні переваги ієрархічної моделі - простота опису ієрархічних структур реального світу і
швидке виконання запитів, відповідних структурі даних. Однак такі моделі часто містять надлишкові
дані і погано пристосовані для подання взаємозв'язків типу «багато до
багатьох». Крім того, не завжди зручно кожен раз починати пошук потрібних даних з кореня, а
іншого способу переміщення по базі в ієрархічних структурах немає. Ієрархічні системи - найстаріше
покоління систем баз даних, вони розроблялися для великих ЕОМ

Мережева модель даних ґрунтується також на графічному поданні взаємозв'язків об'єктів. Однак
тут крім вертикальних зв'язків існують і горизонтальні, тобто допускається підпорядкованість одного
об'єкта багатьом об'єктам. Таким чином, на відміну від ієрархічних, мережеві моделі підтримують
взаємозв'язок типу «багато до багатьох». Кожен породжений елемент в них може мати більше одного
предка (Рисунок - 2)
 Однак мережеві системи досить складні і вимагають солідного програмного забезпечення. У
них, так само як і в ієрархічних системах, перехід від запису до запису проводиться за вставленим в
кожен запис посиланням. Свого часу вони були досить популярні і застосовувалися для міні-
комп'ютерів і великих ЕОМ.