Вимога - деяка функція, що повинна бути включена в створювану систему.

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

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

Зібрана на цьому етапі інформація може бути погано структурована і включати деякі неформальні заяви користувачів, що згодом буде потрібно перетворити і представити у виді більш чітко сформульованих вимог. Ця мета досягається за допомогою методів складання специфікацій вимог, до числа яких відносяться, наприклад, технологія структурного аналізу і проектування (Structured Analysis and Design - SAD), діаграми потоків даних (Data Flow Diagrams— DFD) і графіки "вхід-процес-вихід" (Hierarchical Input Process Output — HIPO), доповнені відповідною документацією. Як буде показано нижче, для одержання гарантій того, що складений набір вимог є повним і несуперечливим, можуть використовуватися CASE-інструменти, призначені для автоматизованого проектування і створення програм.

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

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

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

Основними цілями проектування бази даних є:

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

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

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

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

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

Більш придатною стратегією проектування складних баз даних є використання спадного підходу. Починається цей підхід з розробки моделей даних, що містять трохи високорівневих сутностей і зв'язків, потім робота продовжується у виді серії спадних уточнень низькорівневих сутностей, зв'язків і стосовних до них атрибутів. Спадний підхід демонструється в концепції моделі "сутність-зв'язок". У цьому випадку робота починається з ідентифікації сутностей і зв'язків між ними, що цікавлять дану організацію найбільшою мірою. Наприклад, спочатку можна було б ідентифікувати сутності Owner (Власник) і Property (Об'єкт нерухомості), потім установити між ними зв'язок Owner_Owns (Володіє) Property і лише після цього визначити зв'язані з ними атрибути — наприклад, Owner (OwnerNo, Name, Address) і Property (PropertyNo, Address).

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