Проектування різних типів звітів

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

Отримати доступ до редактора звітів можна через систему меню "Tools / Report Designer". Вибір цього пункту меню переводить розробника в режим настройки звітів з використанням шаблонів, які формуються на підставі сформованих звітів. Додавання нового звіту переводить розробника в режим настройки елементів звіту, де визначаються основні об'єкти і їх властивості. При цьому спочатку розробник повинен визначитися з найменуванням звіту і його типом: Logical (логічна модель), Physical (фізична модель), Logical / Physical (логіко-фізична модель).

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

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

Нижче області визначення імені та типу звіту розробнику пропонується, використовуючи закладку "Report Design", вибрати об'єкти (ліва область) і їх властивості (права область), а в закладці "Definition" розробник може дати змістовне опис формованого звіту, забезпечуючи повне розуміння суті формується звіту, оскільки настройки звіту, по суті, є шаблонами звітів для використання в безлічі моделей бази даних і правильне розуміння особливостей формованого звіту дозволяє правильно його використовувати (рис. 3.33).

Мал. 3.33. Діалогове вікно настройки елементів звіту

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

Наприклад, при необхідності публікації в звіті діаграми моделі розробнику необхідно вибрати в лівій області об'єкт "Subject Area" (робоча область) і в правій області вказати характеристику "Graphical Members", нижче рівня якої уточняти, які об'єкти діаграми потрібно відобразити в зображенні моделі, включаючи вказівка ​​сутностей, атрибутів, ключів, зв'язків і безлічі інших елементів.

Аналогічним чином розробник вказує необхідність використання в звіті відомостей про сутності, умовчаннях, зв'язках та інших об'єктах. Опис всіх виділених елементів моделі бази даних буде представлено в табличному вигляді, розділеному за типами об'єктів на окремі міні-звіти.

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

Мал. 334. Підготовлений набір звітів для формування і експорту

Після закінчення виконання звіту, що викликається з діалогового вікна налаштування звіту за допомогою кнопки "Run Report" (запустити звіт) або через контекстне меню звіту "Run" (запустити), розробник може його експортувати в текстові дані для використання в офісному засобі MS Excel або в формат HTML для відкриття в браузері (рис. 3.35).

Мал. 335. Приклад звіту але сутностей моделі

У разі формування звіту по діаграмі моделі бази даних генератором звітів формуються безпосередньо картинка моделі і в окремих елементах "Tabular" (списочно) і "Hierarchical" (ієрархічно) - опис використовуваних в діаграмах об'єктах: сутність, зв'язки, умовчання і т.д., - в залежності від того, які елементи були обрані розробником при налаштуванні звіту по діаграмі (рис. 3.36).

Мал. 336. Приклад звіту по діаграмі моделі бази даних

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

Інструментальні засоби виробника IBM є одними з найбільш повно опрацьованих з підтримки життєвого циклу розробки інформаційної системи, і бази даних не є винятком. Будучи частиною процесу розробки інформаційної системи, для баз даних в лінійці продуктів IBM реалізується інструментальне засіб моделювання і взаємодії з СУБД - IBM InfoSphere Data Architect. Пройшовши довгий шлях становлення, цей продукт став одним з найпотужніших інструментів по роботі з базами даних, забезпечуючи:

• • побудова логічної моделі бази даних;
• • побудова фізичної моделі бази даних йод велика кількість відомих на ринку СУБД;
• • інтеграцію з СУБД для управління обробкою даних;
• • трансформацію моделі в фізичну базу даних;
• • кодогенерацію на мові SQL структури бази даних для перенесення в СУБД.

Однак, на відміну від ERWin, в IBM InfoSphere Data Architect не передбачено механізму побудови звітів за моделями бази даних, але обумовлене его політикою розробки інструментарію в IBM, яка розглядає використання продукту тільки для вирішення необхідних функціональних завдань. Тому кошти документування, з урахуванням їх використання для різних інструментаріїв розробки інформаційної системи, виділяються в окремі інструменти та є надбудовами до засобів побудови інформаційних систем. Таким чином, якщо є необхідність в побудові стандартизованих звітів за моделями бази даних, то необхідно скористатися окремим програмним рішенням [1] .

Інструментальне засіб IBM InfoSphere Data Architect, як і безліч інших продуктів IBM, реалізовано па базі програмної платформи Eclipse і мови Java, що дозволяє об'єднувати їх в єдиний простір розробки, забезпечуючи швидкий перехід від одного засобу до іншого, а механізми імпорту / експорту надають розгорнуті можливості трансформації моделей для використання в середовищах, відмінних від середовища розробки, реалізуючи комплексний підхід до процесу розробки інформаційної системи. Поряд з цим інструментальні засоби IBM дозволяють розробляти моделі тільки для окремих етапів життєвого циклу розробки інформаційної системи, наприклад для моделювання і побудови бази даних, що і буде розглянуто в даному розділі.

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

Мал. 337. Визначення робочого простору для моделювання

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

Мал. 3.38. Розміщення сховища в файлової структурі операційної системи

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

Як і в безлічі продуктів IBM, для Data Architect реалізується область "перших кроків" розробника, яка пропонує доступ до безлічі довідкових і навчальних засобів по роботі з відповідним інструментом, серед яких інформація про продукт, відомості про процес моделювання, різні web-ресурси з практичними матеріалами по розробці моделі бази даних і посиланнями на професійні форуми, приклади та навчальні матеріали по окремих механізмів інструменту.

При вході в інструмент розробнику відкривається робочий простір, яке надає доступ до окремих механізмів роботи з проектом бази даних (рис. 3.39), представлених наступними областями:

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

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

Першим кроком розробника є створення проекту моделювання, в рамках якого буде представлятися безліч необхідних моделей і діаграм. Зазвичай, в одному проекті реалізується не більше однієї моделі бази даних, але за умови поділу інформаційної системи на кілька баз даних, в проекті може бути реалізовано кілька моделей, що відносяться до виділених баз даних. Як правило, бази даних не взаємодіють між собою, що й обумовлює необхідність побудови декількох моделей в одному проекті. Створення проекту логічної моделі бази даних (рис. 3.40), використовуючи пункт меню "File / New / Data Design Project" (Файл / Новий / Проект моделі даних), починають з визначення імені проекту і його фізичного і логічного розташування.

Мал. 339. Загальний вигляд робочого простору розробника

Фізичне розташування моделі бази даних за замовчуванням визначається в зазначеному для проекту робочому просторі, але розробник може визначити інший шлях розміщення проекту і тоді репозиторій проекту буде розміщений в іншому місці, а в репозиторії інструменту буде вказано посилання на місце розташування проекту. Також розробник може визначити логічне розташування проекту в уже створених інших проектах, визначивши робочий набір (working set) інструментів моделей, що призведе до додавання проекту до іншого проекту. Робиться це для того, щоб можна було використовувати ідентичні елементи моделей бази даних в різних проектах без їх перепроектування.

Мал. 3.40. Визначення параметрів проекту

В результаті буде створено дерево проекту (рис. 3.41), що надає розробнику можливості побудови різних компонентів, серед яких можна виділити:

- Data Diagrams (діаграми даних) - включає набір діаграм, реалізованих для всіх моделей бази даних;

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

SQL Scripts (SQL програми) - включає безліч програмних модулів на мові SQL, необхідних для реалізації в базі даних.

Мал. 3.41. Початкове дерево проекту

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

Створення моделі бази даних виконується через провідник проекту в розділі "Data Models" (моделі даних). Для цього необхідно викликати контекстне меню цього розділу (права кнопка миші) і вибрати пункт "New Logical Data Model" (в разі створення логічної моделі бази даних). Крім логічної моделі через дане контекстне меню розробник може створити фізичну модель бази даних, визначити глосарій найменувань для застосування в іменах об'єктів (сутності, атрибути), модель доменів (призначених для користувача типів даних), логічну і фізичну моделі для багатовимірного аналізу (сховища даних), налаштувати перетворення (трансформацію) моделей різних рівнів при переході від одного рівня до іншого.

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

Мал. 3.42. Фіксування розміщення й імені логічної моделі бази даних

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

Створивши модель бази даних, розробник специфицирует її, визначаючи базові характеристики (рис. 3.43) і опис створюваної моделі за наступними властивостями:

• • Name (найменування) - точне найменування моделі бази даних, певне при аналізі предметної області з виділенням інформаційної суті збережених у ній даних;
• • Location (розташування) - фізичне розміщення файлу сховища моделі бази даних, що має розширення "* .ldm";
• • Size (розмір) фактичний розмір сховища моделі бази даних на жорсткому диску;
• • Compress diagrams (стиснення діаграм) - ознака необхідності стискати, з метою скорочення розміру файлу сховища, створювані графічні діаграми моделі бази даних;
• • Last Modified (остання модифікація) - дата останнього коректування моделі бази даних;
• • Editable (редагована) - фіксований ознака можливості редагувати модель бази даних.

Мал. 3.43. Опис базових властивостей логічної моделі

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

Додатково до основних властивостей розробник має можливість вказати в розділі "Intellectual Property Information" (Відомості про інтелектуальні властивості) відомості про автора і власника моделі (рис. 3.44):

• - Author (автор) - вказуються особа або особи, які беруть участь в розробці створюваної моделі бази даних;
• - Company (організація) - вказується організація, де проводиться розробка моделі бази даних;
• - Version (версія) - вказується версія логічної моделі бази даних;
• - Copyright (авторське право) - вказуються організація, особа чи особи, які є власником моделі бази даних.

Мал. 3.44. Додаткові властивості логічної моделі бази даних

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

У розділі "Data Model Documentation" (документування моделі даних) розробником дається змістовне опис формованої моделі бази даних.

Моделювання призначених для користувача типів даних

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

Створення моделі типів даних реалізується через контекстне меню папки "Data Models" (Моделі даних) при виборі пункту "New / Domain Model" (Новий / Модель доменів). В результаті розробник, аналогічно створенню логічної моделі, повинен визначити розміщення і шаблон створюваної моделі і уточняти цю модель за додатковими властивостями, що визначає авторство і власника моделі.

Набір для користувача типів даних передбачає реалізацію трьох видів:

• • Atomic Domain (атомарний тип даних) - тип визначається встановленням додаткових обмежень на встановлений простий тип даних;
• • List Domain (списковий тип даних) тип визначає, крім стандартних обмежень па простий тип даних, вказівка ​​варіанти вибору, контроль яких повинен здійснюватися при введенні відомостей в поля таблиць такого типу;
• • Union Domain (об'єднаний тип даних) - тип являє собою об'єднання декількох простих типів даних в єдину структуру, формуючи агрегатний уявлення даних але атрибутам такого типу.

Опис властивостей кожного користувача типу даних виконується через область "Properties" (властивості), де групи властивостей розділені вертикально представленими закладками. Для створення нового типу даних (Domain) розробнику необхідно в області моделі доменів "Package ..." через контекстне меню, використовуючи пункт меню "Add Data Object" (додати об'єкт даних), вибрати створюваний вид домену (типу даних).

Вибравши створюваний домен, розробник визначає основні характеристики домену (рис. 3.45), вказуючи:

• - Name (найменування) - ім'я домену, за яким він буде використовуватися при його вказівці для опису атрибута сутності;
• - Base Туре (базовий тип даних) - тип даних, властивості якого використовуються в якості встановлених;
• - Length (довжина) - характеристика, яка використовується переважно для символьних типів даних і визначає кількість символів у рядку даних, що визначаються відповідним типом даних.

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

У разі зазначення обмежень (Constraint) для тина даних, в залежності від обраного базовою типу даних, розробнику пропонується визначити максимальні та мінімальні значення. Так, для символьних типів даних необхідно вказати обмеження по розмірності текстових рядків у вигляді точного розміру (Length) або мінімального і максимального значення. Для числових даних і дати розробником вказуються діапазони, в які повинні потрапляти зберігаються значення. При цьому можуть бути вказані діапазони, що не включають і включають кордону. Це дозволяє будувати досить точні обмеження на можливі значення, враховуючи максимальну кількість варіантів. Також розробником можуть бути визначені фіксовані значення, які повинні використовуватися при застосуванні атрибута відповідного типу. Визначення цих значень реалізується в закладці "Constraints" в рамках області "Enumeration Values".

Закладка "Data Privacy" дає розробнику можливість формалізувати певні значення (рис. 3.46) у відповідності з різними форматами даних і правилами використання.

Puc. 3.46. Область визначення формалізації значень

Серед параметрів формалізації значень можна виділити наступні:

• • Enforcement (правообладания) - можливість застосування порожніх значень для атрибута, специфікованого даним типом даних;
• • Privacy Policy Туре (персональний тип політики) - вид даних предметних областей, для яких визначені правила використання;
• • Privacy Policy (персональні політики) - правила формування значення.

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

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

Особливо виділяється об'єднаний тип даних, який формує сукупність безлічі типів даних, які формують можливе подання даних (рис. 3.47). Для специфікації цього типу даних розробником визначається не один базовий тип даних, а безліч типів, що реалізується переміщенням обраних типів даних з області "Available" (доступні) в область "Current" (вибрані) блоку характеристик "Member Types". При цьому в закладці "Constraints" (обмеження) ніякі додаткові характеристики, крім вказівки явно заданих можливих значень, розробником не можуть бути вказані.

Мал. 3.47. Базові властивості об'єднаного типу даних

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

Мал. 3.48. Визначення мінімального значення для дати

В результаті розробником може бути визначено досить велика кількість типів даних, які часто застосовуються в проектованої базі даних і не описані попередньо встановленими простими типами даних.

Дослідження документарного складу предметної області завжди було і залишається одним з найважливіших етапів в проектуванні баз даних.

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

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

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

• 1. Виділення складу документів, які використовуються в предметної області.
• 2. Виділення складу користувачів документів, розділяючи їх на споживачів, укладачів та наповнювачів, а також внутрішніх, зовнішніх і системних.
• 3. Формування схеми документообігу між користувачами документів, ілюструючи не тільки зв'язок користувачів через документи, а й спрямованість руху документів, з огляду на зовнішніх користувачів.
• 4. Виділення з документів складу атрибутів, специфікуючи їх але типам даних, використовуваного, змінності, смисловий навантаженості і т.д.
• 5. Створення на основі атрибутів атрибутивних сутностей.
• 6. Встановлення прямих і непрямих зв'язків між атрибутивними

сутностями.

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

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

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

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

Таблиця 4.1

Приклад виділених документів предметної області [1]

№ п / п	документ	Найменування / Опис
1	Д 1	Документ "Замовлення" Склад документа видається зазначенням на клієнта (організація або фізична особа), дату складання, перелік товарів, які клієнтом замовлені, із зазначенням ціни, кількості та вартості по кожній позиції і загальної вартості замовлення в числовому і символьному вираженні. Документ формується клієнтом в процесі наповнення "кошика" товарами і передасться оператору п менеджеру з продажу
2	Д 2	Документ "Вимога-накладна" Склад документа визначає перелік товарів, які повинні бути видані зі складу для відправки клієнтові, із зазначенням кількості. Формується менеджером зі збуту і передається на склад
3	дз	Документ "Товарний чек" Склад документа: вказівка ​​на клієнта; перелік замовлених товарів. вказівка ​​їх кількості, ціни і вартості; загальна вартість замовлення в числовому і символьному вираженні; дата і час формування; відповідальна особа; ознаки підтвердження (підпис) від відповідальної особи і клієнта. Документ формується бухгалтером п передається від менеджера з продажу клієнту
4	Д4	Документ "Рахунок" Склад документа містить відомості про організацію-клієнта, замовлених товарах із зазначенням кількості, ціни і вартості, загальної вартості замовлення в числовому і символьному вираженні, керівника і бухгалтера продавця, датою виставлення, терміні оплати. Документ формується бухгалтером і передається в організацію-клієнт
5	Д5	Документ "Рахунок-фактура"

№ п / п	документ	Найменування / Опис
6	Дб	Документ "Товарна накладна" <...>
7	Д7	Документ "Касовий чек" <...>

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

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

Таблиця 4.2

Приклад складу користувачів № Внутрішні 11 і й пол ьзоватсл ь зовнішній користувач 1 2 1 оператор Клієнт (фізична особа) 2 Менеджер з продажу Клієнт (організація) 3 Комірник 4 Бухгалтер 5 керівник

Для зручності подальшого використання покажчиків на відповідних користувачів, щоб не вказувати повні назви, кожному користувачеві привласнюється певний код, який формується з таблиці складу користувачів за кодами рядки і стовпці, де вказано потрібний користувач. Так, наприклад, для користувача "Комірник", що знаходиться в рядку з кодом "3" і стовпці з кодом "1", буде вказуватися код <3.1>, для користувача "Клієнт (організація)" - <2.2>. Обрамлення коду в кутові дужки обумовлено тим, що це дозволить однозначно виділити в будь-якому описі цей код, що не сплутавши його з іншими кодами або символами опису.

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

формування певних інформаційних потреб користувачів, розподіливши права доступу до документа.

Таблиця 43

Приклад розподілу прав доступу до документів № документ Користувач право доступу 1 Д 1 <1.2>, <2.2> З І У Ч П 2 <1.1>, <2.1> І Ч П 3 Д 2 <2.1> СІУЧП 4 <3.1> І Ч П 5 <4.1> Ч П 6 дз <2.1> Ч П 7 <1.2> ч 8 <4.1> З І У ч п 9 <5.1> і ч 10 Д4 <2.2> ч 11 <4.1> СІУЧП 12 <5.1> ич 13 <2.1>, <2.2> ч 14 Д5 <4.1> СІУЧП 15 <2.2> Ч 16 <5.1> ич ... ... ... ...

Для опису характер доступу можуть використовуватися такі символи:

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

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

Мал. 4.1. Приклад схеми документообігу

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

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

Таблиця 4.4

Опис атрибутів за документами

№ п / п	документ	№ п / п	Атрибут	Тип даних	опис
1	Д 1	1	Номер замовлення	З-Ч	Порядковий номер замовлення, що формується при його складанні, 11 рСДСТа В Л Я ється З І N1 віл ьно-ч ис - ловмм позначенням в форматі СС-ХИИ. де перші два символи позначають тип клієнта (фізична особа, організація), а останні три символи позначають порядковий числовий номер замовлення
		2	дата замовлення	Д	Дата, коли замовлення сформоване і відправлений на обробку оператору магазину
		3	клієнт	З	Прізвище, ім'я, по батькові фізичної особи або найменування організації, що роблять замовлення
		4	Номер товару	Ч	Порядковий номер товару в таблиці замовлених товарів
		5	товар	З	Найменування замовлених товарів
		6	кількість товару	ч	Кількість товару по кожній позиції, які замовив клієнт
		7	Ціна товару	ч	Грошовий вираз вартості одиниці товару з двома знаками після десяткової коми
		8	вартість товару	ч	Грошовий вираз вартості зазначеної кількості замовлених товарів із зазначенням двох знаків після десяткової коми. Обчислюється перем піхов ньому ціни товару і його кількості
		9	вартість замовлення	ч	Грошовий вираз вартості всіх замовлених товарів із зазначенням двох знаків після десяткової коми. Обчислюється підсумовуванням значень вартості товару але всіх позиціях замовлений! I их товарів
		10	символьна вартість замовлення	з	Грошовий вираз вартості замовлення, представлене символьної записом
...	...	...	...	...	...

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

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