114 Частниц,

орієнтованої моделі передбачає передусім вибір моделі для БД і, відп₀. відно, вибір СКБД, що підтримує таку модель. Загалом стан реальної АІС відображається складною мережною моделлю, яка включає фраг­менти простих мережних та ієрархічних структур. СКБД реляціі иного типу на сьогодні є настільки популярними в підприємствах комерційної діяльності, що здебільшого не залишають розробникам БД права вибору типу моделі даних. Тому реальна даталогічна модель зводиться до г^ящйної;

<> швидкість оброблення інформації (перевага віддається більш високошвидкісним пакетам).

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

Кожна нова СКБД сумісна з попередніми версіями своїх, а іноді не тільки своїх пакетів, але, як правило, несумісна з попередніми версіями технічного забезпечення. Тому надмірне захоплення новинками проти­показане за наявності відсталої від потреб СКБД технічної бази.

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

5.5. Проектування реалізації бази даних

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

За суттю проектування реалізаціїБДпредставляє процес переходу

^{роздан^ us}

до даталогічної концептуальної моделі даних (іншими словами до СКБД-орієнтованої моделі).

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

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

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

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

В подальшому цей етап проектування служить переходом від одер­жаної концептуальної інфологічної моделі до даталогічної або СКБД-орієнтованої моделі даних 1С.

Графічно даталогічна модель є відображенням інфологічної. У ній тип сутності зображується у вигляді поіменованого прямокутника, кожна клітина якого відповідає атрибуту сутності. Ключ підкреслюється. •5В язки між записами відображають у вигляді спрямованих ліній з зазначенням типів зв'язку 1:1,1 :М, М:М. Дані перетину при зв'язку типу М:М вказуються поруч із лінією зв'язку. Наприклад, наведена на рис. ¹ -5.10 "а" і "б" даталогічна модель фрагмента БД обліку товарів і тари.

При формуванні даталогічної моделі даних, керуються такими ^евристичними правилами.

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

ТОВАР

Рис. 5.10. "а " Даталогічна модель фрагмента БД 1С обліку товарів і тари.

Рис. 5.10. "б" Даталогічна модель фрагмента БД 1С обліку товарів і тари.

жається у вигляді складної мережної моделі.

Правило 2. Від складної мережної моделі здійснюється перехід до простої мережної моделі. При цьому позбавляються зв'язків типу М.М. вводячи додатковий запис, який обов'язково містить ключі записів, що з'єднуються. На рис. 1.5.10 "б" наведена неоднорідна проста мережна модель, яка відповідає складній моделі на рис. 5.10 "а".

Правило 3. При усуненні "залежності від шляху" в ієрархічних фрагментах моделі даних у породжені записи включаються ключі

розділу.

117

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

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

СКЛАД

Рис. 5.11. Ієрархічна даталогічна модель фрагмента БД 1С

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

"Товар".

Після усунення "залежності від шляху", як це показано на рис. 1.5.12, ключ породженого запису "Товар" стає складним. Він складається з ключа породжувального запису "Склад" і коду товару на складі.

Якщо об'єкти породжених записів враховують у межах усієї БД, то Первинним ключем породженого запису стає його первинний атрибут, а первинний ключ породжувального запису надходить до породженого запису і стає зовнішнім ключем, необхідним для з'єднання записів за запитами до БД. Результатом усунення "залежності від шляху" є те, що feci записи в моделі даних стають індивідуальними (автономними), незалежними від породжувальних записів.

Правило 4. У мережевій моделі поняття "породжувальний" і "пород­жений" записи умовні, тому що точкою входу в ній може бути будь-який запис. Вважати записи породжувальними та породженими можна

Рис. 5.12. Ієрархічна даталогічна модель фрагмента БД 1С обліку товарів на складі супермаркету з незалежним записом

"Товар".

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

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

Приклад, який наведений на рис. 5.13, ілюструє просту мережну модель із залежним записом. Це фрагмент БД 1С обліку товарів на складі

ПОСТАЧАЛЬНИК

Рис. 5.13. Дапишгічт модель БД 1С обліку товарів на складі з залежним записом "Товар".

Рис. 5.14. Даталогічна модель БД 1С обліку товарів на складі з незалежним записом "Товар".

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

Запис "Товар" стане автономним, якщо включатиме ключі записів "Склад" та "Постачальник" або як зовнішні ключі, або як компоненти складного первинного ключа "Код постачальника" + "Код складу" + "Код товару". Рис. 5.14 ілюструє такий варіант ключа запису "Товар".

на складі з незалежним записом „Товар"

Правило 5. Фрагменти структури, що містять цикли та петлі, спро­щуються в залежності від виду зв'язку між типами сутностей. За наявності зв'язків типу М:М у циклі або в петлі вводиться додатковий запис із ключами записів, які з'єднуються.

Стосовно фрагмента БД 1С супермаркету даталогічна модель даних являє складну мережу (рис.5.15.).

Ця модель відповідає складній мережевій моделі даних, яку ³°бражено на рис. 5.15.

Атрибути "Код відділу 1" та "Код відділу^" належать домену "Код ^сУпермаркету" і визначають коди секцій менеджерів з реалізації та Менеджерів з поступлення товару.

Атрибути "Код менеджера 1" та "Код менеджера 2" належать домену Код менеджерів" і визначають коди менеджерів з реалізації та

PO30JL . ш

менеджерів з поступлення у відділах (секціях) супермаркету.

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

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

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

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

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

Кожна прикладна задача характеризується частотою виконання та кількістю звернень LRA (Logical records access - англ.) до логічних записів БД. Кількість LRA оцінюється за даними таблиці "Задача— Дані" та даними про частоту виконання кожної прикладної задачі.

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