Повна версія

Головна arrow Інформатика arrow ІНФОРМАЦІЙНІ ТЕХНОЛОГІЇ В ПРОФЕСІЙНІЙ ДІЯЛЬНОСТІ (АВТОМОБІЛЬНИЙ ТРАНСПОРТ)

  • Увеличить шрифт
  • Уменьшить шрифт


<<   ЗМІСТ   >>

ПОБУДОВА ІНФОРМАЦІЙНОЇ МОДЕЛІ

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

важливо

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

При відповіді на питання «що лежить в основі бізнесу даної організації?», Як правило, виявляються найбільш важливі для даного бізнесу або виробничого процесу компоненти.

Відповіді на друге питання «як це робиться?» Дозволяють отримати список основних бізнес-процесів, що відбуваються в організації.

Питання «де відбуваються дані процеси?» Більше відноситься до проблем та організації спільної роботи персоналу. Адже в разі, наприклад, великого обсягу операцій, які виконуються поза територією організації торговими агентами, доведеться враховувати проблеми синхронізації даних. При наявності філій вельми непростою проблемою є оптимальний вибір системи розподілених даних. Можна централізувати всю обробку даних, і філії будуть виконувати свої операції, користуючись можливостями телекомунікацій. Робота з даними в цьому випадку спрощується, але можуть виникнути перебої з-за втрати зв'язку.

Відповідь на питання «хто виконує ці процеси?» Дасть організаційна структура організації.

Важливо отримати і відповідь на питання «коли виконується ту чи іншу дію?». Це внесе ясність в частоту здійснюваних бізнес-процесів і дозволить правильно розставити акцепти в майбутній прикладній програмі.

Останнє запитання «чому ці дії виконуються?» Дозволяє визначити основні мотивації виробничої діяльності організації. Типові бізнес-завдання можуть бути представлені таким списком: досягнення найкращого співвідношення: «витрати - зручність для клієнтів»; забезпечення умов для успішної діяльності персоналу; отримання прийнятною прибутку; підвищення доходів при автоматизації обробки даних.

Відповіді на шість перелічених питань дозволяють підійти до головного моменту в постановці завдання - отримання інформаційної моделі організації. У найпростішому вигляді така модель може бути відображена у вигляді взаємозв'язків між бізнес-компонентами і бізнес-процесами. У практиці проектування інформаційних систем такі схеми отримали назву ER-діаграм {Entity-relationship diagram - ERD) - діаграми «сутність - зв'язок». ER-діаграми добре вписуються в методологію структурного аналізу і проектування інформаційних систем. Такі методології забезпечують строгий і наочний опис проектованої системи, яке починається з її загального огляду і потім деталізується, даючи можливість отримати різну ступінь деталізації об'єкта з різною кількістю рівнів.

Для проектування складних інформаційних моделей за допомогою ER-діаграм використовуються CASE-системи ( Computer-aided Software Engineering). Ці системи дозволяють проектувати інформаційні системи на підставі побудови у вигляді діаграм багаторівневих потоків даних, створювати на їх основі логічну і фізичну модель БД.

Відповідно до CASE-методологією модель системи визначається як ієрархія діаграм потоків даних (ДПД, або DFD), що описують асинхронний процес перетворення інформації від її введення в систему до видачі користувачеві. Діаграми верхніх рівнів ієрархії (контекстні діаграми) визначають основні процеси або підсистеми інформаційної системи (ІС) з зовнішніми входами і виходами. Вони деталізуються за допомогою діаграм нижнього рівня. Така декомпозиція триває, створюючи багаторівневу ієрархію діаграм до тих пір, поки не буде досягнутий такий рівень декомпозиції, на якому процеси стають елементарними і деталізувати їх далі неможливо.

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

  • • зовнішня сутність - матеріальний предмет або фізична особа, що представляє собою джерело або приймач інформації, наприклад, замовники, персонал, постачальники, клієнти, склад;
  • • система / підсистема; при побудові моделі складної інформаційної системи вона може бути представлена в найзагальнішому вигляді на так званої контекстної діаграмі у вигляді однієї системи як єдиного цілого або може бути декомпозирована на ряд підсистем;
  • • процес, який представляє собою перетворення вхідних потоків даних у вихідні відповідно до певного алгоритму; фізично процес може бути реалізований різними способами: це можуть бути підрозділ організації (відділ), яке виконує обробку вхідних документів і випуск звітів, програма, апаратно-реалізоване логічне пристрій і т.д .;
  • • накопичувач даних, що є абстрактним пристроєм для зберігання інформації, яку можна в будь-який момент помістити в накопичувач і через деякий час витягнути, причому способи приміщення і вилучення можуть бути будь-якими;
  • • потік даних, що визначає інформацію, передану через деякий з'єднання від джерела до приймача. Реальний потік даних може бути інформацією, переданої по кабелю між двома пристроями, що пересилаються поштою листами, магнітними стрічками або дискетами, які переносяться з одного комп'ютера на інший, і т.д.

Приклад побудови моделі потоку даних при плануванні технічного обслуговування (ТО) автомобілів наведено на рис. 1.17. Цей бізнес процес відбивається у вигляді кола і віднесений до першого рівня. Зовнішні по відношенню до цього процесу суті з необхідними даними зображені у вигляді прямокутників.

Модель потоку даних при плануванні технічного

Мал. 1.17. Модель потоку даних при плануванні технічного

обслуговування

Концептуальна модель транслюється потім в модель даних, сумісну з обраної СУБД. Можливо, що відображені в концептуальної моделі взаємозв'язку між об'єктами виявляться згодом нереалізованим засобами обраної СУБД. Це зажадає зміни концептуальної моделі.

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

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

Побудова на основі концептуальної моделі даних реляційної моделі проводиться відносно просто. Кожен об'єкт концептуальної моделі відбивається в одному відношенні, яке відображає уявлення користувача в зручному для нього табличному форматі. Простота відображення пов'язана з тим, що при розробці концептуальної моделі, як правило, використовується реляційний підхід. Приклад логічної моделі автоматизованого робочого місця (АРМ) диспетчера автотранспортної організації (АТО) наведено на рис. 1.18.

Логічна модель автоматизованого робочого місця диспетчера автотранспортної організації

Мал. 1.18. Логічна модель автоматизованого робочого місця диспетчера автотранспортної організації

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

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

важливо

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

Обмеження цілісності - це набір певних правил, які визначають допустимість даних і зв'язків між ними. Обмеження цілісності в більшості випадків залежать від особливостей предметної області. Наприклад, потужність двигуна серійного легкового автомобіля навряд чи може бути нижче 30 к.с. Обмеження цілісності можуть ставитися до різних об'єктів БД: атрибутам (полях), записів, відносинам, зв'язків між ними і т.п. Для полів, як правило, можуть використовуватися такі види обмежень:

  • • тип і формат поля автоматично допускають введення тільки даних певного типу. - вибір типу нуля Date в форматі ДД.ММ.ГГ дозволить користувачеві ввести тільки шість чисел, при цьому перша пара цифр не зможе перевищити в кращому випадку значення 31, а друга - 12;
  • • завдання діапазону значень, як правило, використовується для числових полів - діапазон допустимих значень може бути обмежений або з двох сторін (закритий діапазон), або з якоїсь однієї: верхньої або нижньої (відкритий діапазон);
  • • неприпустимість порожнього поля дозволяє уникнути появи в БД «нічийних» записів, в яких пропущені будь-які обов'язкові атрибути;
  • • завдання списку значень дає можливість уникнути зайвого різноманітності даних, якщо його можна обмежити. Наприклад, для вказівки типу кузова ми можемо обмежити фантазію користувача тільки загальноприйнятими назвами: седан, кабріолет і т.д .;
  • • перевірка на унікальність значення якогось нуля дозволяє уникнути записів-дублікатів; навряд чи буде зручно в довіднику клієнтів мати кілька записів для одного і того ж особи.

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

 
<<   ЗМІСТ   >>