
- •Т_т Питання (бд) т_т
- •1. Інформація, дані, знання, аспекти роботи з даними. 1.1. Інформація, дані, знання
- •1.2. Аспекти роботи з даними
- •2. Поняття про інформаційні технології.
- •1.3. Поняття про інформаційні технології
- •3. Особливості та завдання іс.
- •1.4. Особливості та завдання іс Особливості інформаційних систем
- •Завдання інформаційних систем
- •4. Файлові інформаційні системи (фіс).
- •1.6. Файлові інформаційні системи (фіс)
- •5. Ідея скбд, відміни від фіс.
- •1.7. Ідея скбд, відміни від фіс
- •6. Визначення банку даних. Вимоги до БнД.
- •1.8. Визначення банку даних (БнД). Вимоги до БнД
- •7. Переваги централізації керування даними.
- •1.9. Переваги централізації керування даними
- •8. Життєвий цикл інженерного виробу.
- •2.1. Життєвий цикл інженерного виробу
- •9. Моделі життєвого циклу розробки іс (задачна модель, каскадна модель, спіральна модель).
- •2.2. Моделі життєвого циклу розробки іс
- •2.3. Задачна модель
- •2.4. Каскадна модель
- •2.5. Спіральна модель
- •10. Загальна технологія створення іс та ас.
- •2.6. Загальна технологія створення іс та ас
- •11. Основи побудови банків даних БнД.
- •2.7. Основи побудови банків даних БнД
- •Архітектура БнД
- •12. Підприємство як відкрита система. Метаболізм підприємства.
- •3.1. Підприємство як відкрита система. Метаболізм підприємства
- •13. Моделювання за допомогою діаграм потоків даних та подій (Data Flow Diagrams).
- •3.2. Моделювання за допомогою діаграм потоків даних та подій (Data Flow Diagrams)
- •Зовнішні сутності
- •Системи і підсистеми. Процеси
- •Накопичувачі даних
- •Потоки даних
- •Побудова ієрархії діаграм потоків даних Діаграма потоків даних dfd0
- •Діаграма потоків даних dfd1
- •Діаграма потоків даних dfd2
- •14. Матриці подій.
- •3.3. Матриці подій
- •15. Історичний розвиток технології sadt.
- •4.1. Історичний розвиток технології sadt
- •16. Склад функціональної моделі, ієрархія діаграм, типи зв’язків між функціями.
- •4.2. Склад функціональної моделі
- •4.3. Ієрархія діаграм
- •4.4. Типи зв'язків між функціями
- •(0) Тип випадкової зв'язності
- •(1) Тип логічної зв'язності
- •(2) Тип тимчасової зв'язності
- •(4) Тип комунікаційної зв'язності
- •(5) Тип послідовної зв'язності
- •(6) Тип функціональної зв'язності
- •17. Поняття моделі даних (мд). Сильно і слабкоструктуровані мд.
- •5.1. Поняття моделі даних (мд). Сильно і слабкоструктуровані мд
- •18. Модель «сутність-зв’язок».
- •5.2. Модель «Сутність - зв'язок»
- •19. Типи зв’язків.
- •5.3. Типи зв'язків
- •20. Степені зв’язку, залежність по коду.
- •5.4. Степені зв’язку, залежність по коду
- •Залежність за кодом
- •22. Композиція зв’язків.
- •5.6. Композиція зв'язків
- •23. Типи і підтипи (ролі).
- •5.7. Типи і підтипи
- •24. Поняття життєвого циклу об’єкта (екземпляр сутності). Початок, кінець, координація жц.
- •5.8. Поняття життєвого циклу об'єкта (екземпляр сутності). Початок, кінець, координація жц
- •25. Обмеження цілісності, бізнес-правила.
- •5.9. Обмеження цілісності. Бізнес-правила
- •Бізнес-правила
- •26. Локальні інфологічні моделі.
- •5.10. Локальні інфологічні моделі
- •27. Побудова глобальної інфологічної моделі.
- •5.11. Побудова глобальної інфологічної моделі
- •28. Базові поняття реляційних баз даних.
- •6.1. Базові поняття реляційних баз даних
- •Тип даних
- •Кортеж, відношення
- •Фундаментальні властивості відношень
- •29. Реляційна модель даних.
- •6.2. Реляційна модель даних
- •Цілісність сутності та посилань
- •Базисні засоби маніпулювання реляційними даними
- •30. Реляційна алгебра та її операції.
- •6.3. Реляційна алгебра та її операції
- •Загальна інтерпретація реляційних операцій
- •Замкнутість реляційної алгебри і операція перейменування Особливості теоретико-множинних операцій реляційної алгебри
- •Спеціальні реляційні операції
- •Операція обмеження
- •Операція взяття проекції
- •Операція з'єднання відношень
- •Операція поділу відношень
- •31. Реляційне числення на кортежах.
- •6.4. Реляційне числення на кортежах
- •Кортежні змінні та правильно побудовані формули
- •Цільові списки і вирази реляційного обчислення
- •32. Реляційне числення на доменах.
- •6.5. Реляційне числення на доменах
- •33. Аномалії та їх види.
- •7.2. Аномалії та їх види
- •Аномалія вставки (insert)
- •Аномалія оновлення (update)
- •Аномалія видалення (delete)
- •Перша нормальна форма
- •Друга нормальна форма
- •Третя нормальна форма
- •Нормальна форма Бойса-Кодда
- •Четверта нормальна форма
- •П'ята нормальна форма
- •36. Ієрархічна мд.
- •8.1. Ієрархічна мд
- •Ієрархічна структура даних
- •Операції над ієрархічною структурою
- •Вибирання даних
- •Маніпулювання даними
- •Переваги та недоліки ієрархічної моделі
- •37. Мережна мд.
- •8.2. Мережна мд
- •Мережна структура даних
- •Операції над мережною структурою
- •Переваги та недоліки мережної моделі
- •38. Визначення банку даних (БнД).
- •9.1. Визначення банку даних (БнД)
- •39. Вимоги до БнД.
- •9.2. Вимоги до БнД
- •40. БнД як автоматизована система. Види забезпечення.
- •9.3. БнД як автоматизована система. Види забезпечення
- •41. Архітектура БнД.
- •9.4. Архітектура БнД
- •42. Адміністратор бд і його функції.
- •9.5. Адміністратор бд і його функції
- •43. Довідник даних.
- •9.6. Довідник даних
- •45. Централізація і децентралізація процесів обробки даних.
- •9.8. Централізація і децентралізація процесів обробки даних
- •46. Історія, роль та значення мови sql.
- •10.1. Історія, роль та значення мови sql
- •47. Мови опису даних і маніпулювання даними.
- •10.2. Мови опису даних і маніпулювання даними
- •Мова визначення даних
- •Мова маніпулювання даними
- •Мова керування даними
- •48. Реляційні операції, як команди мови маніпулювання даними.
- •10.3. Реляційні операції, як команди мови маніпулювання даними
- •Операція вибірки (обмеження)
- •Операція проекції
- •Операція з'єднання
- •Операція об'єднання
- •Операція перетину
- •Операція різниці
- •Операція поділу
- •Операція декартового добутку
- •Оператор rename
- •49. Віртуальні атрибути і таблиці.
- •10.4. Віртуальні атрибути і таблиці
- •50. Приклади використання операторів Insert, Update та Delete.
- •10.5. Приклади використання операторів Insert, Update та Delete
- •Insert - вставка рядків у таблицю
- •Update - оновлення рядків у таблиці
- •Delete - видалення рядків в таблиці
- •51. Тригери та цілісність посилання.
- •13.1. Тригери та цілісність посилання
- •Доступ до старих і нових значень рядків
- •Тригери й транзакції
- •Вкладеність тригерів
- •Тригер для View
- •52. Збереженні процедури.
- •13.2. Збереженні процедури
- •53. Використання курсорів.
- •13.3. Використання курсорів
- •54. Usability, значення і міфи.
- •17.1. Usability, значення і міфи
- •55. Проблеми проектування інтерфейсів користувача (ік).
- •17.2. Проблеми проектування інтерфейсів користувача (ік)
- •Методологічні основи ік
- •Узагальнена структура інформації для проектування інтерфейсу ас:
- •Хто може проектувати ік
- •Нормативно-технічна база – стандарти ік
- •Стилі інтерфейсу
- •56. Вимоги до ік. Принципи реалізації інтерфейсу.
- •17.3. Вимоги до ік. Принципи реалізації інтерфейсу
- •57. Етапи проектування ік.
- •17.4. Етапи проектування ік
- •Аналіз діяльності користувача
- •Поопераційний аналіз ефективності ік
- •58. Методи і критерії оцінки ік.
- •17.5. Методи і критерії оцінки ік
- •Цілі та критерії оцінки користувацького інтерфейсу
- •10 Правил по проектуванню якісних ік (по David f. Kelly):
- •59. Структура зовнішньої пам’яті.
- •18.1. Структура зовнішньої пам’яті Особливості реляційних скбд
- •Набір базових структур
- •60. Зберігання таблиць.
- •18.2. Зберігання таблиць
- •61. Індекси та в-дерева.
- •18.3. Індекси та в-дерева
- •Інвертовані списки
15. Історичний розвиток технології sadt.
4.1. Історичний розвиток технології sadt
Structured Analysis and Design Technique (SADT) — методологія структурного аналізу і проектування, яка об'єднує процес моделювання, управління конфігурацією проекту, використання додаткових мовних засобів та керівництво проектом зі своєю графічною мовою.
Відома книга [5] присвячена методології SADT, яка в нотації авторів книги практично не відрізняється від нотації IDEF0. SADT виникла наприкінці 60-х років в ході революції, викликаної структурним програмуванням. Коли більшість фахівців билося над створенням програмного забезпечення, деякі намагалися вирішити більш складну задачу створення великомасштабних систем, що включають як людей і машини, так і програмне забезпечення, аналогічних системам, що застосовуються в телефонному зв'язку, промисловості, керуванні та контролі за озброєнням. У той час фахівці, які традиційно займалися створенням великомасштабних систем, стали усвідомлювати необхідність більшої впорядкованості. Таким чином, розробники почали формалізувати процес створення системи, розбиваючи його на наступні фази:
Аналіз - визначення того, що система буде робити.
Проектування - визначення підсистем та їх взаємодія.
Реалізація - розробка підсистем окремо.
Об'єднання - з'єднання підсистем в єдине ціле.
Тестування - перевірка роботи системи.
Установка - введення системи в дію.
Функціонування - використання системи.
Ця послідовність завжди виконувалася ітераційно, зокрема тому що система повністю ніколи не задовольняла вимогам користувачів, оскільки їх вимоги часто змінювалися. І, тим не менш, з цією моделлю створення системи, орієнтованої на керування, постійно виникали складності. Експлуатаційні витрати, що виникали після здачі системи, стали істотно перевищувати витрати на її створення та продовжували зростати з величезною швидкістю через низьку якість початково створеної системи. Деякі вважали, що зростання експлуатаційних витрат обумовлено характером помилок, допущених у процесі створення системи. Дослідження показали, що великий відсоток помилок у системі виник в процесі аналізу і проектування, набагато менше їх було допущено при реалізації та тестуванні, а ціна (часова і грошова) виявлення та виправлення помилок ставала вище на більш пізніх стадіях проекту. Наприклад, виправлення помилки на стадії проектування коштує в 2 рази, на стадії тестування - в 10 разів, а на стадії експлуатації системи - в 100 разів дорожче, ніж на стадії аналізу.
Традиційні підходи до створення систем приводили до виникнення багатьох проблем. Не було єдиного підходу. Залучення користувача до процесу розробки не контролювалося. Перевірка на узгодженість проводилася нерегулярно або взагалі відсутня. Результати одного етапу не узгоджувалися з результатами інших. Процес насилу піддавався оцінками, як якісним, так і кількісним. Стверджувалося, що коли творці систем користуються методологіями типу структурного програмування і проектування «зверху вниз», вони вирішують або не поставлені завдання, або погано поставлені, або добре поставлені, але неправильно поняті завдання. Крім того, помилки в створених системах ставали все менш доступні виявленню за допомогою апаратних засобів або програмного забезпечення, а найбільш катастрофічні помилки допускалися на ранніх етапах створення системи. Часто ці помилки були наслідком неповноти функціональних специфікацій або неузгодженості між специфікаціями і результатами проектування. Проектувальники знали, що складність систем зростає і що визначені вони часто дуже слабо. Зростання обсягу і складності систем є життєвою реалією. Цю передумову потрібно було прийняти як неминучу. Але помилкове визначення системи не є неминучим: воно - результат неадекватності методів створення систем. Незабаром була висунута теза: «вдосконалення методів аналізу є ключем до створення систем, ефективних за вартістю, продуктивністю і надійностю». Для вирішення ключових проблем традиційного створення систем широкого профілю потрібні нові методи, спеціально призначені для використання на ранніх стадіях процесу. Виходячи з цих переконань і виникло застосування SADT. Методи, подібні SADT, на початкових етапах створення системи дозволяли набагато краще зрозуміти та розглянуту проблему. А це скорочує витрати як на створення, так і на експлуатацію системи, а крім того, підвищує її надійність. SADT - це спосіб зменшити кількість дорогих помилок за рахунок структуризації на ранніх етапах створення системи, поліпшення контактів між користувачами та розробниками і згладжування переходу від аналізу до проектування.
Дуглас Т. Росс частину своїх теорій, що відносяться до методології та мови опису систем, назвав «Методологія структурного аналізу і проектування (SADT)». Початкова робота над SADT почалася в 1969 р. Перший її великий додаток було реалізовано в 1973 р. при розробці великого аерокосмічного проекту, коли вона була дещо переглянута співробітниками SofTech, Inc. У 1974 р. SADT була ще поліпшена і передана одній з найбільших європейських телефонних компаній. Поява SADT на ринку відбулося в 1975 р. після річного оформлення у вигляді продукту. До 1981 р. SADT вже використовували більш ніж в 50 компаніях при роботі більш ніж над 200 проектами, що включали понад 2000 людей і охоплювали дюжину проблемних областей, в тому числі телефонні мережі, аерокосмічне виробництво, управління і контроль, облік матеріально-технічних ресурсів та обробку даних. Її широке поширення в даний час в європейській, далекосхідній та американській аерокосмічній промисловості (під назвою IDEF0) дозволяє ці цифри суттєво збільшити. Таким чином, SADT виділяється серед сучасних методологій опису систем завдяки своєму широкому застосуванню. Чому SADT має таке широке застосування? По-перше, SADT - це єдина методологія, яка легко відображає такі системні характеристики, як управління, зворотній зв'язок і виконавці. Це пояснюється тим, що SADT спочатку виникла на базі проектування систем більш загального виду на відміну від інших структурних методів, які «виросли» з проектування програмного забезпечення. По-друге, SADT на доданок до концепцій, що існували в той час, і стандартам для створення систем мала розвинені процедури підтримки колективної роботи і мала переваги, пов'язані з її застосуванням на ранніх стадіях створення системи. Крім того, широке використання SADT показало, що її можна поєднувати з іншими структурними методами. Це досягається використанням графічних SADT-описів в якості схем, що пов'язують воєдино різні методи, застосовані для опису певних частин системи з різним рівнем деталізації. Таким чином, неадекватні специфікації систем того часу викликали створення графічної мови SADT, а її посилене використання перетворили SADT в закінчену методологію, здатну підвищити якість продуктів, що створюються на ранніх стадіях розвитку проекту. Отже, SADT починалася як мова опису функціонування систем загального вигляду, а в міру застосування її процедури опису систем були поліпшені та доповнені.