упця, адреса, найменування купленого товару, дата розрахунку
Інформаційна система повинна відповідати на наступні запити:
- загальна сума представлена ??постачальнику за певний товар
- загальна сума сплачена покупцем за товар
кількість оплачених квитанцій по постачальникам на певну дату
кількість оплачених квитанцій покупцями на певну дату
найменування товару, що поставляється певним постачальником
Аналіз вимог.
Функціональність - інформаційна система повинна забезпечувати зберігання необхідно інформації про товари, датах поставки певного товару, датах реалізації товарів, інформацію про постачальників і покупців; проводити пошук інформації за запитами користувача; надавати можливість редагування та оновлення інформації.
Зручність - система повинна забезпечувати простий і зрозумілий користувачеві алгоритм оновлення та редагування інформації, а також організацію запитів для отримання інформації. Обробка інформації повинна бути швидкою, своєчасною, достовірною та коректною.
Надійність - забезпечення збереження даних при збої комп'ютера, можливість обробки даних незалежно від збоїв у роботі системи.
Продуктивність - підвищення продуктивності роботи магазину в цілому за рахунок подання електронних форм представлення інформації.
Можливість підтримки - забезпечення користувачу можливості встановлювати свою послідовність обробки даних.
Реалізація - використання системи передбачає ефективне використання ресурсів комп'ютера і не вимагає новітнього апаратного забезпечення.
Інтерфейс - підтримка зрозумілого інтерфейсу системи для забезпечення простоти роботи різних категорій користувачів.
Модель прецедентів
Опис прецедентів для баз даних допомагає правильно спроектувати базу даних і розробити функціонально працює додаток.
Виконавець, завдання, прецеденти.
Виділяються виконавці, які виконують певні завдання при взаємодії з системою. Для кожної виділеної завдання визначається прецедент, що задовольняє потребам окремого виконавця. (Таблиця 1.2.)
Таблиця 1.2.- Виконавці, завдання, прецеденти
ИсполнительЗадачиПрецедентыОператорРедактирует і оновлює данниеРедактірованіе і оновлення даннихПользовательСоздает заріс даннихСозданіе запиту і отримання ответаІС «Розрахунок покупцями і постачальниками» Автоматичне збереження даннихСохраненіе даних
Про результатами аналізу прецедентів повинна бути передбачена розробка відповідних форм з необхідними елементами управління.
Розглянута база даних досить зростання, тому і запропоновані сценарії дій теж досить прості. Насправді ж кількість прецедентів значно більше і сценарій дій складніше.
1.4 Проектування бази даних
При проектуванні баз даних у багатьох випадках доцільніше використовувати метод «сутність - зв'язок», потім від ER - діаграм переходять до відносин.
Процес проектування бази даних є ітераційним - допускає повернення до попередніх етапів для перегляду раніше прийнятих рішень і включає наступні етапи:
Виділення сутностей і зв'язків між ними
Побудова ER - діаграм
Формування набору попередніх відносин із зазначенням первинного ключа для кожного відносини з використанням ER - діаграм
Додавання неключових атрибутів у відносини
Приведення попередніх відносин до нормальної форми Бойса - Кодда
Перегляд ER - діаграм.
Застосуємо метод «сутність - зв'язок» до проектування БД «Розрахунок з покупцями і постачальниками».
Перший етап - виділення сутностей і зв'язків між ними. Виділимо наступні сутності: Товар (ключ - код товару), Постачальник (ключ - код постачальника), Покупець (ключ - код покупця), Розрахунок з постачальником (ключ - номер квитанції), Розрахунок з покупцем (ключ - номер квитанції).
Виділимо зв'язку між сутностями.
Розрахунок з постачальником поставляти товари
Розрахунок з покупцем КУПУЄ Товар
Розрахунок з постачальником ЗДІЙСНЮЄТЬСЯ ПО поставлені товари
Розрахунок з покупцем ЗДІЙСНЮЄТЬСЯ ПО куплений товар
Другий етап - побудова діаграм ER- типу з урахуванням всіх сутностей і зв'язків між ними.
Зв'язок пост...
