Бізнес–правила
- це правила й обмеження, що діють у ПО
відносно основних понять інформаційної
структури (сутностей, атрибутів і зв'язків).
Виділяються бізнес правила, що мають
відносини до атрибутів однієї сутності
(унікальність атрибутів, ідентифікація
сутності, спеціальні правила), до зв'язків
між сутностями (факультативність закінчення
зв'язку, потужність закінчень зв'язку
(1:1, 1:n, m:n), ступінь зв'язку).
Інформаційно–довідкові
задачі (на відміну від прикладних
задач) — це ті задачі, які вибирають
деяку підмножину даних з інформаційної
моделі ПО.
Далі
предметна область описується із
вказівкою сутностей їхніх атрибутів,
зв'язків і діючих бізнес-правил. Опис
інформаційно–довідкових задач приводиться
окремо.
У результаті
аналізу ПО були визначені наступні
сутності, їх атрибути та зв’язки:
2.3.1 Сутність «Користувач»
Сутність
використовується для збереження особистої
інформації користувача.
Атрибути:
- Електронна
адреса
- Пароль,
зашифрований із закритим ключем (алгоритм
md5)
- Номер телефону
- Ім’я
- Прізвище
- Дата народження
- Стать
- Місце народження
- Логін Skype
- Уподобання
- Місто проживання
- Тип користувача
- Фото користувача
- Стан підтвердження
електронної адреси
- Стан підтвердження
номеру телефона
Зв’язки:
- У користувача
може бути вказане одне місце народження
- У користувача
може бути вказана одна адреса проживання
- Для користувача
обов’язково повинен бути визначений
тип користувача
- Для користувача
може бути визначена його фотографія
- Для користувача
можуть бути визначенні оподобання, місця
та ін.
Бізнес-правила:
- Унікально
ідентифікується електронною адресою
або номером телефону
2.3.2 Сутність «Тип користувача»
Тип
користувача – сутність-класифікатор,
яка використовується для визначення
можливостей та прав користувачів.
Атрибути:
Зв’язки:
- Тип користувача
– обов’язковий атрибут кожного користувача
.
Бізнес-правила:
- Унікально
ідентифікується назвою типу користувача
2.3.3 Сутність «Відношення»
Відношення
– сутність, яка створена для
того, щоб об’єднувати пари користувачів
за їх бажанням відповідно до можливих
типів відношень із сутності «Тип
відношення»
Атрибути:
- Стан підтвердження
відношення
Зв’язки:
- Перший
користувач відношення – один зі елементів
сутності «Користувач»
- Другий
користувач відношення (не може співпадати
із першим) – один зі елементів сутності
«Користувач»
- Тип відношення
повинен вибиратися із сутності «Тип відношення»
і визначати відношення першого користувача
до другого, а не навпаки
Бізнес-правила:
- Унікально
ідентифікується трьома значеннями: перший
користувач, другий користувач та тип
відношення.
2.3.4 Сутність «Тип відношення»
Тип
відношення – сутність-класифікатор,
яка визначає, в яких відносинах
знаходяться пари користувачів
Атрибути:
Зв’язки:
- Пара користувачів
може перебувати тільки у одному із визначених
видів відношень, наприклад, пара користувачів
не може мати одночасно відношення друг
і недруг, тому що вони суперечливі
Бізнес-правила:
- Унікально
ідентифікується назвою типу відношення
2.3.5 Сутність «Країна»
Країна
– сутність-класифікатор, яка використовується
для ідентифікації звязку користувача
з однією з країн світу.
Атрибути
Зв’язки:
- Для одного
користувача може бути визначена тільки
одна країна народження та одна країна
поточного проживання
Бізнес-правила:
- Унікально
ідентифікується назвою країни
2.3.6 Сутність «Місто»
Місто
– сутність-класифікатор, яка найбільш
точно характеризує місце народження
та місце перебування користувача
Атрибути:
Зв’язки:
- Місто
обов’язково повинно відноситись до певної
країни;
- Для одного
користувача може бути визначений тільки
одне місто проживання і одне рідне місто.
Бізнес-правила:
- Унікально
ідентифікується назвою країни в якій
знаходиться та назвою міста.
2.3.7 Сутність «Структура повідомлення»
Сутруктура
повідомлення – використовується для
збереження повідомлень надісланих від
одного користувача іншому
Атрибути:
- Текст повідомлення
- Дата та
час надсилання
Зв’язки:
- Інформаційний
ресурс – файл, який додається до повідомлення
Бізнес-правила:
- Всі атрибути є обов’язковими, але не
унікальними
2.3.8 Сутність «Повідомлення»
Сутність
повідомлення використовується для
збереження повідомлень надісланих
від одного користувача, який не встановлений
як «недруг» іншому
Атрибути:
- Структура
повідомлення
- Стан підтвердження
читання
Зв’язки:
- Адресант
– користувач, який надсилає повідомлення
(не може співпадати з користувачем, який
встановлений як «недруг» адресату)
- Адресат
– користувач, який отримує повідомлення
(не може співпадати з адресантом, тобто
самому собі не можна слати повідомлення)
Бізнес-правила:
- Всі атрибути є обов’язковими, але не
унікальними.
2.3.9 Сутність «Медіафайл»
Медіафайл
– сутність, яка використовується для
збереження інформації про файли, завантажені
користувачами.
Атрибути:
- URL адреса
файлу
- Назва файлу
Зв’язки:
- Обов’язково
повинен бути визначений один автор файлу
із сутності «Користувач»
- Обов’язково
для кожного файлу повинен бути визначений
тип інформаційного ресурсу із переліку
типів файлів сутності «Тип медіафайлу»
Бізнес-правила:
- Унікально ідентифікується назвою файлу,
типом файлу та зв’язком із користувачем.
2.3.10 Сутність «Тип медіафайлу»
Тип
медіафайлу – сутність-класифікатор,
яка створена для того, щоб система могла
розрізняти файли, які завантажив користувач
відповідно до їх типу.
Атрибути:
Зв’язки:
- Для одного
файлу обов’язково повинен бути визначений
один тип файлу.
Бізнес-правила:
- Унікально
ідентифікується назвою типу файлу
2.3.11 Сутність «Новини»
Новини
– сутність, яка використовується
для надання можливості користувачам
створювати розширені публічні повідомлення
на своїй сторінці у вигляді новин.
Атрибути:
- Назва новини
- Текст новини
- Дата та
час публікації
Зв’язки:
- Автором
новини може бути тільки один із існуючих
користувачів
Бізнес-правила:
- Унікально
ідентифікується парою значень: користувач-автор
новини та час публікації новини.
2.3.12 Сутність «Налаштування
приватності»
Налаштування
приватності – сутність, яка використовується
для обмеження доступу до інформації користувача.
Атрибути:
- Хто може
надсилати повідомлення
- Хто може
переглядати інформаційні ресурси
- Хто бачить
основну інформацію на сторінці
- Хто може
запрошуати в додатки
- Хто може
залишати повідомлення на «стіні»
- Хто може
переглядати фото зі мною
- Хто може
переглядати список моїх аудиозаписів
Зв’язки:
- Для одного
користувача може бути визначений лише
один набір налаштувань.
Бізнес-правила:
- Всі атрибути
є обов’язковими, але не унікальними.
3. КОНЦЕПТУАЛЬНЕ МОДЕЛЮВАННЯ ПРЕДМЕТНОЇ
ОБЛАСТІ
3.1. Теоретичні
положення концептуального моделювання
Концептуальне проектування бази даних.
Процес створення моделі використовуваної
на підприємстві інформації, незалежної
від будь-яких фізичних аспектів її уявлення.
Перший етап процесу проектування
бази даних називається концептуальним проектуванням бази
даних. Він полягає в створенні концептуальної
моделі даних для аналізованої частини
підприємства. Ця модель даних створюється
на основі інформації, записаної в специфікаціях
вимог користувачів. Концептуальне проектування
бази даних абсолютно не залежить від
таких подробиць її реалізації, як тип
вибраної цільової СУБД, набір створюваних
прикладних програм, використовувані
мови програмування, тип вибраної обчислювальної
платформи, а також від будь-яких інших
особливостей фізичної реалізації. На
чолі 14 представлене поетапне практичне
керівництво по виконанню концептуального
проектування бази даних. При розробці
концептуальна модель даних постійно
піддається тестуванню і перевірці на
відповідність вимогам користувачів.
Створена концептуальна модель даних
підприємства є джерелом інформації для
етапу логічного проектування бази даних.
Властивостями концептуальної
моделі є наступні.
- Це основа однозначного розуміння
ПО всіма зацікавленими особами. У розробку
складної системи баз даних включається
великий колектив: експерти, системні
аналітики, проектувальники, розроблювачі,
ті, хто займається впровадженням і супроводом.
Всі вони повинні однозначно розуміти,
що ж собою представляє ПО, що автоматизується,
у який зміст використовуваних понять,
як вони взаємозалежні між собою, які всілякі
обмеження в ПО мають місце, які вимоги
висуваються до різних функціональних
компонентів ПО й т.д. Все це повинна забезпечувати
концептуальна модель. Це та єдина платформа,
що дозволяє всім розмовляти на одній
й тіж мові й однаково розуміти один одного.
- Вона включає тільки концептуально
релевантні аспекти ПО, крім, таким чином,
БУДЬ-ЯКИХ аспектів зовнішнього або внутрішнього
представлення даних. Це означає, по перше,
що концептуальна модель жодним чином
не повинна фіксувати конкретні потреби
окремих груп користувачів або додатків.
Вона повинна фіксувати, що собою представляє
ПО в цілому, а не з погляду інтересів або
потреб користувачів. Вона повинна інтегрувати
думки, погляди й інтереси окремих користувачів,
але саме інтегрувати, для одержання цілісної
картини, а не виражати їхні конкретні
погляди, побажання думки. По-друге, у концептуальній
моделі ПО ні яким чином не повинні відбиватися
які-небудь аспекти майбутньої реалізації
БД у комп'ютерному середовищі. Усе, що
пов'язане з такими поняттями, як способи
зберігання, методи доступу, ефективність
виконання, оптимізація й т.д. перебувають
за межами концептуальної моделі.
- Це засіб визначення припустимої
еволюції БД. У процесі експлуатації БД
може розвиватися, однак цей розвиток
може вироблятися тільки в тих межах, які
припустимі з погляду концептуальної
моделі. Розвиток бази даних, що вимагає
змін у концептуальній схемі, означає
ні що інше, як переосмислювання ПО й завдань
автоматизації й побудови на цій основі
нової концептуальної моделі ПО.
- Забезпечення незалежності
даних. Наявність концептуальної моделі,
яка не залежить від зовнішнього представлення
користувачами ПО, та різними аспектами
реалізації БД є надійна основа вирішення
задач досягнення логічної та фізичної
незалежності програм від даних.
- Централізоване адміністрування.
Саме через концептуальну схему здійснюється
адміністрування базами даних.
- Стійкість. Концептуальна схема
жодним чином не повинна змінюватися на
догоду вимог тих або інших користувачів
або вимог зберігання даних. Будучи моделлю
ПО, вона повинна змінюватися тільки в
тому випадку, коли входить у суперечність
із нею.