4. Структуровані схеми/діаграми

Наступні елементи використовуються в структурному підході:

Модуль

Це активний компонент програми, тобто процедура або функція (або обидві)

Малюнок 7.5.1. Приклад модуля.

Виклик

Виклик - це дія, почата модулем, який є підмодулем.

Малюнок 7.5.2. Виклик модуля іншим модулем.

Модуль бібліотеки

Це - готова процедура або функція, яка використовується в системі.

Малюнок 7.5.3. Приклад модуля бібліотеки.

Дані

Це - відношення в базі даних, файлі або змінних в програмі.

Малюнок 7.5.4. Дані.

Прапори потоку даних

Виклик пов'язаний з потоком даних від модуля запиту до викликаного модуля і навпаки. Перший відповідає параметрам вводу, останній - параметрам виводу.

Малюнок 7.5.5. Прапори потоку даних.

Малюнок 7.5.6. Використання даних.

Структурні діаграми відформатовані зверху-вниз, тобто модулі запиту вище викликаних модулів.

Структурні діаграми являються специфікацією блок-схем даних.

Високорівневий модуль, який є джерелом даних, викликає модуль нижчого рівня, який є одержувачем даних.

Малюнок 7.5.7. Структурні діаграми проти DFD.

5. Складова організації даних

Будь-яке застосування повинне зберігати дані, отже проектування носія - необхідний елемент проекту.

Дані зберігаються в:

• файлах;

• базі даних (зв'язаній, об’єктно-орієнтованій або іншій).

Специфічні елементи даних у формі об'єктів або оригіналі можуть бути збережені в одній з форм:

• у одному зв'язному файлі;

• у окремому файлі для кожного типу об'єктів.

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

Особливості і характеристики баз даних

Найпростіший метод зберігання даних - зберігати їх на магнітному або оптичному диску. На жаль, збереження їх у формі файлу небезпечне і незручне у використанні.

Таким чином, файлові системи замінені базами даних. База даних - системи, розроблені для зберігання, доступу і управління даними.

База даних характерна постійним зберіганням, обмеженим об'ємом і хорошою організацією.

Постійність

Постійність означає, що дані повинні бути завжди у базі даних. База даних не може бути розробленана в пам'яті, оскільки дані можуть бути втрачені, коли виключається живлення. Хорошим носієм може бути жорсткий диск, папір, магнітний або оптичний диск.

Обмеження баз даних

База даних не може містити всіх можливих даних. Вони пов'язані з деякою моделлю дійсності. Прийнята модель, спроектована проектувальником, визначає дані, збережені в базі даних.

Послідовність бази даних

База даних повинна: бути сумісною з дійсністю, ефективною, забезпечувати цілісність, багатократний доступ і операційну обробку, масштабованість, розподіл даних і каскадних рішень. База даних повинна дозволяти операції на даному рівні мови (наприклад. SQL, OQL).

Зв'язок з реальністю

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

Приклад реалізації

Проект бази даних потрібно робити з урахуванням того, що база даних повинна ілюструвати фрагмент дійсності. Деяка гіпотетична база даних може бути розроблена і працювати, але вона може не знайти ніякого застосування. Щоб побудувати базу даних, яка представляє фрагмент дійсності, повинна бути добре визначена область проблем і запропоновані відповідні моделі.

Контроль копіювання даних

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

Складена модель даних

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

Доступність даних

Можуть бути бази даних, які забезпечують доступ кому завгодно і у будь-який час. Проте, це не особливість, рекомендована для будь-якої бази даних, зокрема коли користувачі багато разів запрошують дані. Таким чином, доступом до баз даних потрібно управляти, а також необхідний відповідний проект структури і доступу.

Безпека даних

Бази даних присутні в багатьох установах; вони підтримують і беруть участь в багатьох видах справ. Вони зберігають фінансову інформацію, тотожність, операції і т.д. отже, вони повинні бути захищені. Хороша база даних повинна мати механізми перевірки, дозволу, конфіденційності, цілісності і доступності.

Критерії відбору системи управління базами даних (СУБД)

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

Найважливіші критерії відбору СУБД:

• Продуктивність

Продуктивність описує швидкість реакції на запити і кількість обслуговуваних завдань.

• Масштабованість

Масштабованість позначає зміну роботи системи при збільшенні кількості користувачів і даних. Це також описує можливість адаптування системи і можливості розширення системи в умовах високого робочого навантаження.

• Функціональність

Функціональність описує, які функції є доступними в системі. Вони можуть бути функціями користувача, адміністратора і функціями проектувальника. Часто брак відповідних функцій призводить до потреби покупки нових інструментів і збільшує вартість.

• Узгодження із стандартами

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

• Зручність і простота використання

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

• Надійність

Надійність позначає частоту відмов. Чим вище надійність - тим вище вартість.

Таким чином, повинно бути виконано балансування надійності (або потреба зупинки роботи) і витрат.

• Підтримка

Підтримка описує рівень обслуговування і допомоги, забезпечений виробниками. Підтримка - дуже важлива характеристика. Вища вартість системи, яка добре підтримана виробником, коштує цього і гарантує стійкість роботи.

• Середовище розробки

Середовище розробки описує, на яких апаратних засобах і програмному забезпеченні система працюватиме.

• Вартість

У вартість системи включені покупка, встановлення і експлуатація.

Реляційна база даних

Найзагальніші бази даних на ринку - реляційні бази даних.

Не дивлячись на їх популярність і загальне використання реляційні бази даних мають деякі незручності. Вони можуть бути і повинні бути відмічені на етапах аналізу і проектування, зокрема в об'єктно-орієнтованому підході.

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

На мал. 7.6.1. об'єктно-орієнтовану зразкову і реліционную модель показують для однієй системи. Об'єктно-орієнтована модель виразніша.

Малюнок 7.6.1. Неузгодженість об'єктно-орієнтованої зразкової і реліционной моделі.

Незручність в застосуванні реляційної моделі - також неузгодженість інтерфейсу доступу (наприклад, до SQL) і до мови програмування (наприклад, C++). Цю неузгодженість називають неузгодженістю імпедансу.

Незручність реляційної моделі також полягає у тому, що вона не може бути легко розширена, і що немає ніякого систематичного підходу до методів.