Проектування і реалізація бази даних інформаційної системи "Організація міжміських вантажних перевезень"

Таблиця 1.13 – Родо-видовий список елементів даних вхідних документів

Кожен із наведених родо-видових списків аналізують з метою вилучення з них елементів, що дублюються, омонімів, синонімів, елементів, які обчислюються. У словник даних включається підмножина даних, утворена перетином двох зазначених множин. Словник даних наведено в табл. 1.14.

 Таблиця 1.14 – Словник даних

1.2.2       Зведення зібраної інформації до вигляду, зручного для проектування.

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

              Виділяються 3 задачі:

1. Введення вхідних даних. Заповнення вхідних таблиць 1.1-1.5. У задачі використовуються дані каталогів і автомобільних довідників. Мета — заповнити табл. 1. 1 – 1. 5.

2. Введення оперативних даних про щоденні перевезення. У задачі використовуються дані табл. 1.1, 1.2, 1.4, 1.5 про найменування пункту призначення, державний номер автомобіля,дані про водіїв, вид вантажу та його обсяг. Мета — заповнення таблиці 1.6 даними про щоденні перевезення.

3. Видача результатної інформації. Ціль: формування і видача вихідних таблиць. 

Таблиця 1.15 – Таблиця зв’язку “Задача-дані” 

1.2.3       Формулювання вимог до БД             

Як зазначалося вище, забезпечення БД необхідними властивостями відбувається на різних етапах її проектування. Зведені воєдино вимоги до БД є стратегічним планом для системного аналітика. Такими вимогами є :

Функціональна повнота. Ця властивість БД забезпечується врахуванням інформаційних вимог усіх потенційних користувачів ІС й узгодженістю БД іншим вимогам.

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

Цілісність. Цілісність домену визначається параметрами, які задає розробник (це — ім'я поля, тип даних, ширина поля, точність числових полів і діапазон значень числових змінних, коли це можливо), а забезпечує її СУБД.

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

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

Відновлюваність. Найприйнятнішим варіантом забезпечення відновлюваності БД є введення спеціального пункту в меню "Сервіс". У ньому має бути два підпункти: "Копіювання в страхову директорію" та "Відновлення із страхової директорії".

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

Ефективність. Вона передбачає оптимальний вибір комплексу апаратно-технічних засобів, ОС, СУБД, побудову оптимальної логічної та фізичної моделей даних.

Розширюваність (відкритість) БД. Для цього потрібна оптимальна структура даних щодо незалежності логічного та фізичного їх подання.

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

Розроблення вимог до оброблення даних. Ці вимоги ґрунтуються інформаційними запитами потенційних користувачів ІС.

1.3      Концептуальне інфологічне проектування бази даних

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

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

             Найпридатнішим для практичного застосування є пер­ший метод. Він складається з двох етапів проектування БД: ідентифікації та моделювання локальних інформа­ційних структур БД у вигляді локальних ER-діаграм і побудови глобальної інформаційної моделі — глобальної ER-діаграми.

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

4

Рисунок 1.2 – Глобальна ER-діаграма

4

20

   1.3.2              Вимоги до технічного  та програмного забезпечення             

У даному разі можна зупинитися на варіанті комп'ютера Intel Core 2 DUO E4400 з оперативною пам'яттю ємністю 1024 Мбайт та зовнішньою пам'яттю ємністю близько 250 Гбайт, дисплеєм 19’ і принтером типу Canon Pixma MP1800.

1.3.3       Обмеження розробленої структури             

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

1.4             Проектування реалізації бази даних

На етапі формулювання СУБД-орієнтованої логічної структури, або даталогічної концептуальної моделі БД виконується перетворення інфологічної моделі ПС на даталогічну модель. Даталогічна модель – модель БД, яка представляє об'єкти проблемної сфери і їх взаємостосунків з вказівкою способів їх фізичного зберігання, тобто є СУБД -орієнтованою моделлю.