CC BY
51
74
Автомобильный транспорт, вып. 34, 2014
УДК 656.073.28
СТРУКТУРА ІНФОРМАЦІЙНОЇ СИСТЕМИ ЗБОРУ ДАНИХ ПРО ПАРАМЕТРИ ВАНТАЖОПОТОКІВ У ВЕЛИКИХ МІСТАХ
Є.В. Нагорний, проф., д.т.н., В.С. Наумов, доц., д.т.н., О.С. Черепаха, асист., Харківський національний автомобільно-дорожній університет
Анотація. Проведено аналіз особливостей використання логістичних порталів у процесі транспортного обслуговування. Описано методику розв ’язання задачі збору вихідних даних про параметри вантажопотоків, основану на розробці спеціалізованої інформаційної системи з відкритим кодом.
Ключові слова: системи керування базами даних, параметри вантажопотоків, заявка, вантажовласник, атрибути відносин.
СТРУКТУРА ИНФОРМАЦИОННОЙ СИСТЕМЫ СБОРА ДАННЫХ О ПАРАМЕТРАХ ГРУЗОПОТОКОВ В КРУПНЫХ ГОРОДАХ
Е.В. Нагорный, проф., д.т.н., В.С. Наумов, доц., д.т.н., А.С. Черепаха, ассист., Харьковский национальный автомобильно-дорожный университет
Аннотация. Проведен анализ особенностей использования логистических порталов в процессе транспортного обслуживания. Описана методика решения задачи сбора исходных данных о параметрах грузопотоков, основанная на разработке специализированной информационной системы с открытым кодом.
Ключевые слова: системы управления базами данных, параметры грузопотоков, заявка, грузовладелец, атрибуты отношений.
STRUCTURE OF THE INFORMATION SYSTEM FOR DATA COLLECTION ON THE FREIGHT FLOW PARAMETERS IN CITIES
Ye. Nagornji, Prof., D. Sc. (Eng.), V. Naumov, Assoc. Prof., D. Sc. (Eng.),
A. Cherepakha, T. Asst.,
Kharkov National Automobile and Highway University
Abstract. The analysis of the specific use of logistics portals for transportation services has been implemented. A technique for solving the problem of the collection of baseline data on the characteristics offreight flows based on the development of specialized information system open source has been described.
Key words: database management system, freight flow parameters, application, freight owner, attributes relations.
Вступ
Однією з головних причин, що перешкоджають ефективному транспортному обслуговуванню, є несвоєчасне надання інформації про наявність у вантажовласників потреби в перевезенні партії вантажу, або надання такої
інформації в неповному обсязі. Загальноприйнятим й історично сформованим засобом надання організації, що обслуговує, даних про заявку на транспортне обслуговування є вербальний опис потреби - спілкування з оператором перевезень безпосереднє або за допомогою телефонного зв’язку. З по-
Автомобильный транспорт, вып. 34, 2014
75
явою Інтернет-технологій популярною (а пізніше - стандартною) формою надання інформації став опис потреби у вигляді електронного листа. Якщо вантажовласник користується послугами оператора перевезень на постійній основі, то заявка на перевезення партії вантажу заповнюється в електронному вигляді за формою, що надається клієнтам організацією, що їх обслуговує. Розвиток Інтернет і технологій, які сприяють збільшенню швидкості передачі даних, сприяло тому, що більша частина транспортних організацій, що мають власний сайт у мережі, надають клієнтам можливість заповнювати форми з описом заявки на транспортне обслуговування в онлайн-режимі.
Аналіз публікацій
Аналіз особливостей використання логістич-них Інтернет-порталів у процесі транспортного обслуговування, проведений в [1, 2], дозволив виділити такі недоліки:
- транспортні портали виконують функцію збору інформації про наявність потреб та пропозицію на ринку, не надаючи користувачам інструментів оптимізації транспортного процесу;
- інформація, що надається користувачами порталів, часто дублюється, що знижує ефективність пошуку і підвищує ризики отримання некоректних даних.
Необхідно також відзначити, що існуючі Інтернет-ресурси дозволяють здійснювати збір інформації про потреби у транспортному обслуговуванні при перевезенні вантажів у міжміському та міжнародному сполученні і не можуть бути використані для збору даних та їх аналізу при вивченні вантажопотоків у містах.
Проблематичним, з точки зору практичної реалізації, є включення в існуючі інформаційні системи аналітичних модулів, що дозволяють реалізовувати безперервний аналіз параметрів вантажопотоків. Причинами виникнення перешкод є комерційний характер діючих інформаційних систем і, як наслідок, закритий характер коду, що реалізує систему збору даних та їх обробки. Таким чином, для вирішення завдання збору вихідних даних про параметри вантажопотоків найбільш правильним, з точки зору практичної реалізації та подальшого розвитку системи, є варіант розробки спеціалізованої інформаційної
системи з відкритим кодом, а не розробка модулів для існуючих Інтернет-ресурсів.
На сьогодні стандартним рішенням для організації та зберігання великих обсягів струк-турованої інформації є використання систем управління базами даних. Існуючі різновиди баз даних (БД) налічують наразі близько 50 видів [3]. За моделлю даних БД діляться на ієрархічні, об’єктно-орієнтовані, мережеві, функціональні та реляційні. Найбільшого поширення при керуванні складними технологічними процесами набула реляційна модель зберігання даних і відповідні системи управління базами даних (СУБД). Реляційні моделі характеризуються простотою структури даних, зручним для користувача табличним поданням і можливістю використання формального апарату алгебри відносин і ре-ляційного числення для обробки даних [4]. СУБД реалізують реляційний принцип управління даними і поділяються на три групи:
- файл-серверні СУБД - файли даних розташовуються централізовано на файл-сервері, СУБД розташовується на кожному клієнтському комп’ютері (робочій станції), доступ СУБД до даних здійснюється через локальну мережу; найбільш поширеними файл-сервер-ними СУБД є Microsoft Access, Paradox, dBase, FoxPro і Visual FoxPro; такі системи набули широкого використання в локальних додатках, які використовують функції управління БД, в системах з низькою інтенсивністю обробки даних і низькими піковими навантаженнями на БД; на сьогодні файл-серверна технологія вважається застарілою, а її використання у великих інформаційних системах - недоліком [5];
- клієнт-серверні СУБД: розташовані на сервері разом з БД і здійснюють доступ до БД безпосередньо в монопольному режимі, при цьому всі клієнтські запити на обробку даних обробляються клієнт-серверною СУБД централізовано; найбільш поширеними клієнт-серверними СУБД є Oracle, Firebird, Interbase, IBM DB2, Informix, MS SQL Server, PostgreSQL і MySQL. Перевагою клієнт-серверних СУБД є потенційно більш низьке завантаження локальної мережі, зручність централізованого управління, зручність забезпечення таких важливих характеристик, як висока надійність, висока доступність і висока безпека;
76
Автомобильный транспорт, вып. 34, 2014
- вбудовані СУБД: система управління надається як складова частина деякого програмного продукту, не вимагаючи процедури самостійної установки. Найбільш поширеними вбудовуваними СУБД на сьогодні є OpenEdge, SQLite, BerkeleyDB, Firebird Embedded, Microsoft SQL Server Compact; вбудована СУБД призначена для локального зберігання даних своєї програми, але не розрахована на колективне використання в мережі; найчастіше реалізується у вигляді бібліотеки, яка підключається, при цьому доступ до даних з боку програми може відбуватися через SQL (Structured Query Language - структурована мова запитів) або через спеціальні програмні інтерфейси.
Мета і постановка задачі
Метою роботи є розробка структури інформаційної системи збору даних про параметри вантажопотоків у містах. Об’єктом дослідження є процес збору даних про параметри вантажопотоку у великих містах. Предметом
- використання програмного пакета EasyPHP DevServer 13.1 VC9, що включає до себе скрипкову мову програмування PHP, систему управління базами даних MySQL, веб-сервер Apache для розробки системи збору даних про параметри вантажопотоків у великих містах.
Для вирішення поставленого завдання визначили, що найбільш відповідними є клієнт -серверні СУБД, оскільки технологія файл-серверних систем є застарілою, а вбудовувані системи не призначені для колективного використання в мережі. При використанні СУБД MySQL можна отримати програмний доступ при використанні спеціальних функцій PHP.
Визначення структури інформаційної системи збору даних
Найкращим варіантом при розробці системи збору даних про параметри вантажопотоків є використання нересурсномістких СУБД, таких як PostgreSQL або MySQL, для роботи з якими необхідні спеціальні бібліотеки функцій. З урахуванням наведених аргументів, для розробки системи збору даних про параметри вантажопотоків у великих містах використано програмний пакет EasyPHP DevServer 13.1 VC9, що включає скриптову мову програмування PHP, систему управлін-
ня базами даних MySQL, веб-сервер Apache та інші інструменти. PHP є мовою програмування, яка інтенсивно використовується для розробки веб-програм, які на сьогодні підтримується переважною більшістю хостинг-провайдерів і є одним з лідерів серед мов програмування, що застосовуються для створення динамічних веб-сайтів [6]. Реляційна модель БД орієнтована на організацію даних у вигляді двовимірних таблиць. Кожна реляційна таблиця є двовимірним масивом і має ряд властивостей.
Очевидно, що кожному рядку в реакційній таблиці БД, яка містить інформацію про заявки на транспортне обслуговування, відповідає окрема заявка, а у стовпцях таблиці відображаються параметри заявок. Таким чином, якщо і - номер заявки, a j - номер стовпця, що містить j-ту характеристику, то кортеж <і, Pj>, де pj - значення j-ro параметра для і-ої заявки, є елементом таблиці даних. При проектуванні БД необхідним етапом, що забезпечує швидкість доступу до даних, є проведення процедури нормалізації - перетворення відносин бази даних до виду, відповідного нормальним формам [7]. У літературі виділяється 8 видів нормальних форм, [8]:
- перша нормальна форма (1NF);
- друга нормальна форма (2NF);
- третя нормальна форма (3NF);
- нормальна форма Бойса-Кодда (BCNF);
- четверта нормальна форма (4NF);
- п’ята нормальна форма (5NF);
- доменно-ключова нормальна форма (DKNF);
- шоста нормальна форма (6NF).
Аналіз практичного досвіду роботи транспортних підприємств, які обслуговують вантажовласників у межах міста, дозволив виділити основні параметри, що характеризують заявку на перевезення партії вантажу, і привести їх до третьої нормальної форми.
Атрибути для відносин, що описують заявки на перевезення вантажів у межах міста (табл. 1), в такому випадку матимуть вигляд:
- Pi - код заявки (порядковий номер у потоці);
- р2 - найменування товару;
- р3 - клас вантажу;
- р4 - тип необхідного автомобіля;
- р5 - обсяг партії вантажу, кг;
- р6 - дата і час відвантаження;
Автомобильный транспорт, вып. 34, 2014
77
- р7 - код вантажовідправника;
- р8 - код вантажоодержувача.
Таблиця 1 Відношення, які описують параметри заявок на транспортне обслуговування
Атрибутика заявок
р1 р2 р3 р4 р5 рб р7 р8
1 Побутова хімія 2 фургон 20 кг 2.06.13 16:00 1 4
2 Продукти харчування 2 термо- фургон 70 кг 1.06.13 12:00 1 5
3 Вироби з металу 1 бортовий 90 кг 5.06.13 13:00 2 6
4 Вироби з пластику 3 бортовий 40 кг 3.06.13 15:00 3 7
Подання даних про параметри заявки може бути проведене шляхом виділення двох таблиць (табл. 2, 3), для заявки p і для вантажовласників r, з такими атрибутами:
- r1 - код вантажовласника;
- r2 - найменування вантажовласника;
- r3 - адреса вантажовласника;
- r4 - абсциса вантажовласника;
- r5 - ордината вантажовласника.
Атрибут r1 виділений для подальшого опису моделі множини вантажовласників на ринку транспортних послуг. Потенційний ключ у відношенні, що описує вантажовласників, є складовим - це пара атрибутів {r1, r2}, оскільки ім’я вантажовласника також є унікальним, як і його код.
Таблиця 2 Відношення, які описують параметри вантажовласників
Атрибутика вантажовласника
п r2 r3 r4 Гз
1 ПАТ «Алекс» вул. Харьківська, 2 5 4
2 ПАТ «Метал М» вул. Темна, 9 3 2
3 ВАТ «Принк» вул. Леніна, 3 1 1
4 ВАТ «Борт» вул. Перемоги, 5 2 6
5 ПП «Мельник» пр. Київський, 5 2 8
6 ПП «Витязь» вул. Березки, 17 5 4
7 ВАТ «Слон» вул. Лугова, 1 4 9
Відношення в табл. 1 і 2 можуть нормалізуватися і далі. Так, для приведення до форми Бойса-Кодда можна виділити функціональні залежності атрибутів р3 (клас вантажу) від р2 (найменування товару), а також атрибута р4 (тип необхідного автомобіля) від р2. Визначення складових первинних ключів на базі
цих залежностей і подальше розбиття відношення в табл. 1 на три таблиці ускладнює структури бази даних, а також може призвести до зберігання в БД надлишкових даних.
У [7] вказується, що при роботі з даними, що мають високий рівень звернень, не рекомендується проводити глибоку нормалізацію, оскільки це може призвести до зайвого завантаження СУБД і, як наслідок, до зниження швидкодії інформаційної системи. Розроблена БД реалізована в базі requests, де наведені в табл. 1 і 2 відносини описані у відповідних таблицях requests і freightowners, при створенні яких використані імена полів, відображені в табл. 3 та 4. Додатково в таблиці requests введений атрибут р9 - час надходження заявки, значення якого задається програмно при реєстрації заявки і приймається рівним поточному системному часу. Атрибут р9 використовується при обробці параметрів потоку заявок для розрахунку значень інтервалів надходження заявок.
Таблиця 3 Кодування атрибутів відносин v таблиці requests
Атрибут Поле в таблиці БД Найменування
р\ code код заявки
р2 cargoname найменування товару
ръ cargotype клас вантажу
р4 vehicletype тип необхідного автомобиля
рз volume обсяг партії вантажу, кг
р6 unloadtime дата і час відвантаження
р7 sendercode код вантажовідправника
р8 ownercode код вантажоодержувача
р flowtime час надходження
Таблиця 4 Кодування атрибутів відносин v таблиці freightowners
Атрибут Поле в таблиці БД Найменування
r1 code код вантажовласника
r2 name найменування вантажовласника
r3 address адреса вантажовласника
r4 x абсциса вантажовласника
r5 y ордината вантажовласника
78
Автомобильный транспорт, вып. 34, 2014
Процедура додавання заявки в таблицю requests, а також аналогічна процедура додавання вантажовласника здійснюються при обробці даних, введених користувачем системи збору даних у спеціальному модулі.
Висновки
Для вирішення задачі збору вихідних даних про параметри вантажопотоків у великих містах найбільш правильним, з точки зору практичної реалізації та подальшого розвитку системи обслуговування вантажовласників, є варіант розробки структури інформаційної системи з відкритим кодом. Запропонована структура збору даних, що описує параметри вантажопотоків, та її реалізація у вигляді системи збору інформації дозволяють отримати швидкий доступ до даних для їх аналізу і подальшої розробки організаційно - технологічних заходів з удосконалення процесів обслуговування вантажовласників.
Література
1. Наумов В.С. Використання логістичних порталів у процесі транспортно-експедиторського обслуговування / В.С. Наумов, А.М. Гордієвич // Логістика промислових регіонів: матеріали V Міжнародної науково-практичної конференції. - До-
нецьк: ЛОНДОН-XXI, 2013. - С. 131133.
2. Наумов В.С. Платформа KASSETTS как
инструмент планирования транспортных процессов / В.С. Наумов, Б.В. Гуш-чак // Автомобильный транспорт: сб. науч. тр. - 2011. - Вып. 24. - C. 268-273.
3. Когаловский М.Р. Энциклопедия техноло-
гий баз данных / М.Р. Когаловский. -М.: Финансы и статистика, 2002. - 800 с.
4. Система управления базами данных. -
http://ru.wikipedia.org/wiki.
5. Кузнецов С.Д. Основы баз данных /
С.Д. Кузнецов. - М.: БИНОМ, 2007. -484 с.
6. Котеров Д. PHP. В подлиннике / Д. Коте-
ров, А. Костарев. - С.Пб.: «БХВ-
Петербург», 2005. - 1120 с.
7. Никсон Р. PHP, MySQL и JavaScript /
Р. Никсон. - С.Пб.: Питер, 2012. - 496 с.
8. Дейт К.Дж. Введение в системы баз дан-
ных / Дейт К.Дж. - М.: Вильямс, 2005. -1328 с.
Рецензент: П.Ф. Горбачов, професор, д.т.н., ХНАДУ.
Стаття надійшла до редакції 7 квітня 2014 р.
