Принципи проектування

Матеріал з Фізмат Вікіпедії
Перейти до: навігація, пошук

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

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

В процесі проектування виконуються технічні та економічні розрахунки, схеми, графіки, пояснювальні записки, кошториси, калькуляції та описи.

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


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

Широко відомі етапи проектування баз даних (БД) з'явилися в процесі розробки все більш складних Інформаційних Систем (ІС), які повинні були розглядати потреби не одного користувача, але великих груп і колективів. Одна така інтегрована БД створювалася для вирішення багатьох завдань, кожна з яких використовувала тільки "свою" частину даних, зазвичай, перетинає з частинами, що використовуються в інших завданнях. Тому найголовнішими методами проектування стали методи виключення надмірності в даних. Ці методи зв'язувалися з іншими засобами забезпечення логічної цілісності даних.

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

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


За ідеєю - класична методологія проектування

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

1. збір відомостей про ПрО (аналіз потреб та опис ПрО з використанням так званих "процесного" або up, "usage perspective" підходу і "непроцессного" або isp, "information structure perspective" підходу);

2. вибір мови представлення т.зв. "семантичної" моделі для фіксації відомостей про ПрО, їх подальшого аналізу та синтезу моделі БД;

3. аналіз зібраних відомостей про ПрО: класифікація, формалізація та інтеграція структурних елементів опису ПрО, формалізація як структурних, так і процедурних обмежень цілісності елементів у майбутній моделі ПрО, визначення динаміки примірників об'єктів ПрО;

4. синтез концептуальної моделі БД: проектування цілісної концептуальної схеми БД на обраною мовою семантичного моделювання;

5. вибір конкретної моделі даних і СУБД для реалізації БД;

6. проектування логічної схеми БД для вибраної СУБД (називається також "проектування реалізації");

7. розробка фізичної структури БД ( "фізичної" або "внутрішньої" схеми, вона ж - "схема розміщення"), включаючи розміщення БД по вузлах;

8. розробка технології і процедур початкового створення та заповнення БД;

9. розробка технології і процедур супроводження БД;

10. розробка універсальних програм доступу до БД і відповідних інтерфейсів користувачів;

11. інформаційне забезпечення розробки конкретних програм обробки даних: забезпечення метаінформації, даними контрольних прикладів та ін;

12. отримання зворотнього зв'язку від розробників прикладних програм і користувачів Інформаційної Системи (ІС) про повноту та ефективності організації БД;

13. тестування БД, її розвиток і поліпшення (налагодження) її структури.

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

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


За методологією - майстерня інструментів проектування БД

Проектування й по предметній спрямованості, інтегрованої і, звичайно, великий за розміром БД стало складним завданням.

Наявність цілісної методології проектування дозволило подбати про "швець-проектувальник" і почати шити йому чоботи у вигляді систем автоматизації проектування БД. Цьому сприяло наявність технологічного досвіду в організації та комп'ютерної підтримки систем розробки програмного забезпечення і, з іншого боку, використання активних інтегрованих словників-довідників даних (dd / d, data dictionary / directory).

Так виникли системи case (computer aided system engineering) - системи для структурного проектування БД і пов'язаних з ними ІС, орієнтовані на моделі даних, реалізовані в різних СУБД. Найбільшу популярність отримали case-системи для реляційних СУБД з sql-моделями даних, а dd / d перейменувався в case-репозиторій проектованої ІС.

На цьому шляху виникло два основних напрямки розвитку case-систем і технологій проектування: case-системи для проектування власне БД (або т. н. upper-case) та інтегровані інструменти, що дозволяють проектувати і БД, і розробляти використовують їх прикладні програми. Важливо відзначити, що і upper-case в загальному випадку мають багато засобів для опису функцій обробки інформації (при використанні процесного підходу до збору й аналізу відомостей про ПрО) та збереження цих описів в репозиторії. Це підтверджує положення про сильну зв'язок проекту БД та проекту ІС, що базується на цій БД. Разом з тим, цей зв'язок не абсолютна в Киеве, і принцип відділення БД від програм зберігається.

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

Таке зрощення має декілька проявів, наприклад, case-репозиторій підтримується засобами "рідний", але єдиною СУБД, генерація прикладних програм проводиться "рідними" інструментами розробки цієї ж СУБД, але тільки ними. Для таких інтегрованих case-систем відображення концептуальної моделі БД в логічну схему часто робиться також тільки для визначеної СУБД.

Останній факт пов'язаний з ще одним завданням, яка може ставитися при проектуванні БД: проектування переносимої БД, яка може бути реалізована на платформах різних типів комп'ютерів, операційних систем, СУБД і навіть моделей даних, і, при необхідності, переноситься з однієї платформи на іншу.

З урахуванням сказаного, класична Майстерня проектувальника БД включає сукупність класичних структурних методів проектування, набір відповідних інструментів моделювання, реалізації, завантаження і супроводження БД, а також "каскадну" організаційну схему виконання цих робіт за принципом "зверху вниз ".


Принципи проектування:

1. Мінімізація надлишковості, без втрати даних.

2. Аномалії вставки, видалення і оновлення є проблемами, що виникають при вставці, видаленні або оновленні даних «дефектних» або неправильно спроектованих таблиць.

3. Уникнення структур, що допускають велике число порожніх значень.


Оцінка спроектованих відношень:

Якщо розглянути відношення, які отримуються при проектуванні бази даних, то можна зробити наступні висновки:

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

2. Атрибути кожного з відношень не можуть бути знайдені в іншому відношенні або знайдені при об’єднанні декількох відношень, тому надлишковість відсутня.

3. Відношення можуть підтримувати запити, які передбачаються реалізовувати в програмі.

4. Адекватність інформації стану предметної області.


Корисна інформація:

Проектування
Відношення