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

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

У результаті аналізу ПО були визначені наступні сутності, їх атрибути та зв’язки:

1. Сутність Клієнт

Короткий опис сутності. Список всіх клієнтів які зробили замовлення на даний момент або раніше

Атрибути. Сутність характеризується наступними атрибутами:

• код клієнта;
• Ім’я клієнта
• Прізвище клієнта
• По батькові клієнта
• Дата народження клієнта
• Телефон клієнта
• Адреса доставки
• Менеджер який веде клієнта
• Дата реєстрації клієнта в БД

 

Зв’язки. Сутність Клієнт має наступні зв’язки з іншими сутностями:

• «менеджер який веде клієнта» являється зовнішнім ключем на атрибут «код клієнта» сутності МЕНЕДЖЕР.

Бізнес–правила. Код клієнта є унікальним і обов’язковим.

2. Сутність Замовлення

Короткий опис сутності. Зберігаються всі замовлення клієнтів.

Атрибути. Сутність характеризується наступними атрибутами:

• Унікальний ID замовлення
• Дата замовлення
• Ідентифікатор товару
• Кількість товару
• Резервування кількості товару
• Ідентифікатор менеджера, який буде виконувати замовлення клієнта
• Ідентифікатор клієнта

 

Зв’язки. Сутність ЗАМОВЛЕННЯ має наступні зв’язки з іншими сутностями:

• «Ідентифікатор товару» являється зовнішнім ключем на атрибут «Унікальний ID товару» сутності ТОВАР.
• «Ідентифікатор менеджера» являється зовнішнім ключем на атрибут «Унікальний ID менеджера» сутності МЕНЕДЖЕР.
• «Ідентифікатор клієнта» являється зовнішнім ключем на атрибут «Унікальний ID клієнта» сутності КЛІЄНТ.

 

Бізнес–правила. Ідентифікатор замовлення є унікальним і обов’язковим.

 Ідентифікатор товару є ID товару.

3. Сутність Продаж

Короткий опис сутності. Зберігаються всі замовлення клієнтів.

Атрибути. Сутність характеризується наступними атрибутами:

• Унікальний ID продажу
• Ідентифікатор замовлення
• Дата продажу
• Ідентифікатор товару
• Кількість товару
• Ідентифікатор менеджера, який фактично виконує замовлення клієнта
• Ідентифікатор клієнта

 

Зв’язки. Сутність ЗАМОВЛЕННЯ має наступні зв’язки з іншими сутностями:

• «Ідентифікатор товару» являється зовнішнім ключем на атрибут «Унікальний ID товару» сутності ТОВАР.
• «Ідентифікатор менеджера» являється зовнішнім ключем на атрибут «Унікальний ID менеджера» сутності МЕНЕДЖЕР.
• «Ідентифікатор клієнта» являється зовнішнім ключем на атрибут «Унікальний ID клієнта» сутності КЛІЄНТ.

 

Бізнес–правила. Ідентифікатор замовлення є унікальним і обов’язковим.

 Ідентифікатор товару є ID товару.

 

4. Сутність Товар

Короткий опис сутності. Зберігаються всі товари.

Атрибути. Сутність характеризується наступними атрибутами:

• Унікальний ID товару
• Назва товару
• Артикул
• Країна-виробник
• Якість товару
• Кількість товару

 

Зв’язки. Сутність ТОВАР не має зв’язків.

Бізнес–правила. Унікальний ID товару є унікальним і обов’язковим.

 

 

5. Сутність Менеджер

Короткий опис сутності. Список всіх менеджерів які працюють в магазині або працювали коли-небудь раніше.

Атрибути. Сутність характеризується наступними атрибутами:

• Унікальний ID МЕНЕДЖЕРА
• Ім’я менеджера
• Прізвище менеджера
• По батькові менеджера
• Дата народження менеджера
• Стать менеджера
• Адреса менеджера
• Склад родини менеджера
• Дата прийому на роботу
• Дата завершення роботи

 

Бізнес–правила. • Унікальний ID МЕНЕДЖЕРА є унікальним і обов’язковим.

3. Концептуальне моделювання предметної області

1. Теоретичні положення концептуального моделювання

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

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

Властивостями концептуальної моделі є наступні:

• Це основа однозначного розуміння ПО всіма зацікавленими особами. У розробку складної системи баз даних включається великий колектив: експерти, системні аналітики, проектувальники, розроблювачі, ті, хто займається впровадженням і супроводом. Всі вони повинні однозначно розуміти, що ж собою представляє ПО, що автоматизується, у який зміст використовуваних понять, як вони взаємозалежні між собою, які всілякі обмеження в ПО мають місце, які вимоги висуваються до різних функціональних компонентів ПО і т.д. Все це повинна забезпечувати концептуальна модель. Це та єдина платформа, що дозволяє всім розмовляти на одній і тій же мові й однаково розуміти один одного.
• Вона включає тільки концептуально релевантні аспекти ПО, крім, таким чином, БУДЬ-ЯКИХ аспектів зовнішнього або внутрішнього представлення даних. Це означає, по перше, що концептуальна модель жодним чином не повинна фіксувати конкретні потреби окремих груп користувачів або додатків. Вона повинна фіксувати, що собою представляє ПО в цілому, а не з погляду інтересів або потреб користувачів. Вона повинна інтегрувати думки, погляди й інтереси окремих користувачів, але саме інтегрувати, для одержання цілісної картини, а не виражати їхні конкретні погляди, побажання думки. По-друге, у концептуальній моделі ПО ні яким чином не повинні відбиватися які-небудь аспекти майбутньої реалізації БД у комп'ютерному середовищі. Усе, що пов'язане з такими поняттями, як способи зберігання, методи доступу, ефективність виконання, оптимізація й т.д. перебувають за межами концептуальної моделі.
• Це засіб визначення припустимої еволюції БД. У процесі експлуатації БД може розвиватися, однак цей розвиток може вироблятися тільки в тих межах, які припустимі з погляду концептуальної моделі. Розвиток бази даних, що вимагає змін у концептуальній схемі, означає ні що інше, як переосмислювання ПО й завдань автоматизації й побудови на цій основі нової концептуальної моделі ПО.
•  Забезпечення незалежності даних. Наявність концептуальної моделі, яка не залежить від зовнішнього представлення користувачами ПО, та різними аспектами реалізації БД є надійна основа вирішення задач досягнення логічної та фізичної незалежності програм від даних.
•  Централізоване адміністрування. Саме через концептуальну схему здійснюється адміністрування базами даних.
•  Стійкість. Концептуальна схема жодним чином не повинна змінюватися на догоду вимог тих або інших користувачів  або вимог зберігання даних. Будучи моделлю ПО, вона повинна змінюватися тільки в тому випадку, коли входить у суперечність із нею.

 

 

• 3.2. Мова ER—моделювання ПО

          Мова ER-моделювання (Entity Relationship Modeling) — це мова визначення інформаційних потреб організації. Мова базується на концепції, відповідно до якої інформаційне забезпечення будь-якої предметної області представляється як сукупність взаємозалежних об'єктів. Процес моделювання полягає у виділенні сутностей ПО, установлення властивостей виділених сутностей і виявлення існуючих між ними зв'язків.

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

Розглянемо  коротко основні  властивості,  формальні позначення  й  визначення  сутностей, зв'язків, атрибутів.

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

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

•  ім'я;
•  ступінь/потужність;
•  факультативність — обов'язкова або факультативна.

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

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

 

Рис. Приклад зв'язку

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

При читанні зв'язку з обов'язкової сторони  перед її  ім'ям використовуються слова  "у всіх випадках" або "завжди"; для факультативної сторони використовуються слова "у загальному випадку" або "іноді". Ступінь "багато"  читається  як  "один або декілька", а ступінь "один" — "один і тільки один".

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

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

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

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

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

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

 

4. Логічне та фізичне проектування бази даних

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

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

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

1. Логічне проектування