Введення
При проектуванні програм з'ясовуються запити та побажання клієнта і визначається можливий підхід до вирішення завдання. Завдання аналізується. На основі цього аналізу реалізується конкретна модель в конкретній програмному середовищі. Результати кожного етапу проектування використовуються як вихідний матеріал наступного етапу.
Аналізується поточна організація підприємства, виділяються проблеми для вирішення, визначаються об'єкти відносини між ними, складається «ескіз» поточної організації підприємства, розробляється модель з урахуванням конкретних умов її функціонування.
База даних орієнтована на певну предметну область і організована на основі деякого підмножини даних. Можливості баз даних корисні в областях, пов'язаних з довготривалим управлінням інформацією, таких як електронні бібліотеки та сховища даних.
Попереднє планування, підготовка даних,
послідовність створення інформаційної моделі
При проектуванні системи обробки даних найбільше нас цікавить організація даних. Допомогти зрозуміти організацію даних покликана інформаційна модель.
Процес створення інформаційної моделі починається з визначення концептуальних вимог ряду користувачів. Концептуальні вимоги можуть визначатися і для деяких задач (програм), які найближчим часом реалізовувати не планується. Це може трохи підвищити трудомісткість роботи, проте допоможе найбільш повно врахувати всі нюанси функціональності, необхідної для розробляється системи, і знизить імовірність переробки надалі. Вимоги окремих користувачів повинні бути представлені в єдиному «узагальненому представленні». Остання називають концептуальною моделлю.
* Об'єкт - це абстракція безлічі предметів реального світу, що володіють однаковими характеристиками і законами поведінки. Об'єкт представляє собою типовий невизначений примірник такого безлічі.
Об'єкти об'єднуються в класи за загальними характеристиками. Наприклад, в пропозиції «Білий Дім є будівлею», «Білий Дім» представляє об'єкт, а «будинок» - клас. Класи позначаються абстрактними іменниками.
* Клас - це безліч предметів реального світу, пов'язаних спільністю структури і поведінкою.
Концептуальна модель представляє об'єкти та їх взаємозв'язку без вказування способів їх фізичного зберігання. Таким чином, концептуальна модель є, по суті, моделлю предметної області. При проектуванні концептуальної моделі всі зусилля розробника повинні бути спрямовані в основному на структурування даних і виявлення взаємозв'язків між ними без розгляду особливостей реалізації та питань ефективності обробки. Проектування концептуальної моделі засноване на аналізі вирішуються на цьому підприємстві завдань по обробці даних. Концептуальна модель включає описи об'єктів і їх взаємозв'язків, що представляють інтерес у розглянутій предметній області і виявляються в результаті аналізу даних. Маються на увазі дані, які використовуються як у вже розроблених прикладних програмах, так і в тих, які тільки будуть реалізовані.
Проектування концептуальної моделі бази даних:
Аналіз даних: збір основних даних (наприклад, об'єкти, зв'язки між об'єктами).
Визначимо початкові дані:
Заявки - що надходять від магазинів на певний період.
Договору - укладаються з постачальниками на певний вид товару.
Постачальники - організації або фізичні особи, з якими укладаються договори на поставку товару.
Замовники - в основному магазини, а також підприємства та організації, що подають замовлення на придбання того чи іншого товару.
Рахунки - ведуться на етапі укладання договору з постачальниками, а також із замовниками.
Накладні - створюються на підставі отримання замовлення про замовника, для відвантаження.
Довідки - отримання/видача різних довідок як замовникові так і постачальника.
Товар - присутній на підставі заявки і договору з постачальником.
Визначення взаємозв'язків.
Взаємозв'язок висловлює відображення або зв'язок між двома множинами даних. Розрізняють взаємозв'язку типу «один до одного», «один до багатьох» та «багато до багатьох».
Наприклад, якщо замовник робить замовлення на купівлю товару вперше, здійснюється первинна реєстрація його даних та відомостей про зроблене замовленні. Якщо ж замовник робить замовлення повторно, здійснюється реєстрація тільки даного замовлення. Незалежно від того, скільки разів даний замовник робив замовлення, він має унікальний ідентифікаційний номер (унікальний ключ замовлення). Інформація про кожного замовника включає найменування замовника, адреса, телефон, факс, прізвище, ім'я, по батькові, ознака юридичної особи і примітка. Таким чином, властивостями об'єкта Замовник є «унікальний ключ замовника», «найменування замовника».
Наступний що представляє для нас інтерес об'єкт - Товар. Цей об'єкт має властивості «унікальний ключ товару», «найменування товару».
Другий даний об'єкт - Постачальник. Його властивостями є «унікальний ключ постачальника», «найменування постачальника».
Третій даний об'єкт - Замовник. Його властивостями є «унікальний ключ замовника», «найменування замовника».
Взаємозв'язок «один до одного» (між двома типами об'єктів)
Припустимо, у певний момент часу один замовник може зробити тільки одне замовлення. У цьому випадку між об'єктами Замовник і Товар встановлюється взаємозв'язок «один до одного».
Взаємозв'язок «один до багатьох» (між двома типами об'єктів)
У певний момент часу один замовник може стати володарем багатьох продуктів, при цьому кілька замовників не можуть бути власниками одного товару (на умови якщо замовник не претендує на частину товару). Взаємозв'язок «один до багатьох» можна позначити за допомогою одинарної стрілки в напрямку до «одного» і подвійний стрілки в напрямку до «багатьох». У цьому випадку одного запису даних першого об'єкта (його часто називають батьківським або основним) буде відповідати кілька записів другого об'єкта (дочірнього або підлеглого). Взаємозв'язок «один до багатьох» дуже поширена при розробці реляційних баз даних. Як батьківського об'єкта часто виступає довідник, а в дочірньому зберігаються унікальні ключі для доступу до записів довідника. У нашому прикладі в якості такого довідника можна уявити об'єкт Замовник, в якому зберігаються відомості про всіх замовників. При зверненні до запису для певного замовника нам доступний список всіх покупок, які він зробив, і відомості про які зберігаються в об'єкті Товар.
Взаємозв'язок «один до одного» (між двома властивостями)
Ми припускаємо, що ключ (номер) магазину є його унікальним ідентифікатором, тобто він не змінюється і при подальших надходження замовлень від даного магазину. Якщо поряд з номером магазину в базі даних зберігається й інший його унікальний ідентифікатор (наприклад, адреса), то між такими двома унікальними ідентифікаторами існує взаємозв'язок «один до одного».
Взаємозв'язок «один до багатьох» (між двома властивостями)
Назва постачальника і його номер існують спільно. Постачальників з однаковими іменами може бути багато, але всі вони мають різні номери. Кожному постачальнику присвоюється унікальний номер. Це означає, що даному номеру постачальника відповідає тільки одне ім'я. Взаємозв'язок «один до багатьох» позначається подвійною стрілкою в напрямку до «одного» і подвійний стрілкою у напрямку до «багатьох».
Первісна схема даних.
Виділимо наступні об'єкти:
1. ТОВАР - (Т);
2. ЗАМОВНИК - (З);
3. ПОСТАЧАЛЬНИК - (П);
4. РАХУНКУ - (С);
5. ДОГОВІР - (Д);
6. НАКЛАДНІ - (Н).
Первісне графічне представлення концептуальної моделі
Завдання первинних і альтернативних ключів, визначення властивостей об'єктів
Для кожного об'єкта визначимо властивості, які будемо зберігати в БД. При цьому необхідно враховувати той факт, що при переході від логічної до фізичної моделі даних може відбутися усікання числа об'єктів. Насправді, як правило, значна кількість даних, необхідних користувачеві, може бути досить легко підраховано в момент виведення інформації. У той же час, у зв'язку зі зміною алгоритмів розрахунку або вихідних величин, деякі розрахункові показники доводиться записувати в БД, щоб гарантовано забезпечити фіксацію їх значень. Вибір показників, які обов'язково слід зберігати в БД, досить складний. Нечасто можна знайти однозначне рішення цієї проблеми, і в будь-якому випадку воно вимагає ретельного вивчення роботи підприємства і аналізу концептуальної моделі.
Властивості, що включаються до складу БД для даної моделі, наведено в табл.1.
Приведення моделі до необхідного 1 рівню нормальної форми
Приведення моделі до необхідному рівню нормальної форми є основою побудови реляційної БД. У процесі нормалізації елементи даних групуються в таблиці, що представляють об'єкти та їх взаємозв'язку. Теорія нормалізації заснована на тому, що певний набір таблиць володіє кращими властивостями при включенні, модифікації і видалення даних, ніж всі інші набори таблиць, за допомогою яких можуть бути представлені ті ж дані. Введення нормалізації відносин при розробці інформаційної моделі забезпечує мінімальний обсяг фізичної, тобто збережені на будь-якому носії БД і її максимальну швидкодію, що прямо відображається на якості функціонування інформаційної системи. Нормалізація інформаційної моделі виконується у декілька етапів.
Дані, представлені у вигляді двовимірної таблиці, є першою нормальною формою реляційної моделі даних. Перший етап нормалізації полягає в утворенні двовимірної таблиці, яка містить всі необхідні властивості інформаційної моделі, і у виділенні ключових властивостей. Очевидно, що отримана досить значна таблиця буде містити дуже різнорідну інформацію. У цьому випадку будуть спостерігатися аномалії включення, відновлення й видалення даних, тому що при виконанні цих дій нам доведеться приділити увагу даними (вводити або піклуватися про те, щоб вони не були стерті), які не мають до поточних дій ніякого відношення. Наприклад, може спостерігатися така парадоксальна ситуація.
Відношення задано в другій нормальній формі, якщо воно є відношенням в першій нормальній формі і кожне властивість, що не є первинним властивістю в цьому відношенні, повністю залежить від будь-якого можливого ключа цього відношення.
Якщо всі можливі ключі відносини містять по одній властивості, то це відношення задано в другій нормальній формі, тому що в цьому випадку всі властивості, які не є первинними, повністю залежать від можливих ключів. Якщо ключі складаються більш ніж з однієї властивості, відношення, задане в першій нормальній формі, може не бути ставленням у другій нормальній формі. Приведення відносин до другої нормальної форми полягає в забезпеченні повної функціональної залежності всіх властивостей від ключа за рахунок розбиття таблиці на декілька, в яких всі наявні властивості будуть мати повну функціональну залежність від ключа цієї таблиці. У процесі приведення моделі до другої нормальної форми в основному виключаються аномалії дублювання даних.
Відношення призначено в третій нормальній формі, якщо воно задано в другій нормальній формі і кожне властивість цього відношення, що не є первинним, не транзитивній залежить від кожного можливого ключа цього відношення.
Транзитивне залежність виявляє дублювання даних в одному відношенні. Якщо А, В і С - три властивості одного відносини і С залежить від В, а В від А, то говорять, що С транзитивній залежить від А. Перетворення в третю нормальну форму відбувається за рахунок розділення вихідного відносини на два.
Таблична з певними зв'язками, остаточна концептуальна модель.
Концептуальна модель переноситься потім в модель даних, сумісну з вибраної СУБД. Можливо, що відображені в концептуальної моделі взаємозв'язку між об'єктами виявляться згодом нереалізованим засобами вибраної СУБД. Це потребує зміни концептуальної моделі. Версія концептуальної моделі, яка може бути забезпечена певної БД, називається логічною моделлю.
Логічна модель відображає логічні зв'язки між елементами даних незалежно від їх змісту і середовища зберігання. Логічна модель даних може бути реляційної, ієрархічної або мережевий. Користувачам виділяються підмножини цієї логічної моделі, які називаються зовнішніми моделями, що відображають їхнє представлення про предметну область. Зовнішня модель відповідає уявленням, які користувачі отримують на основі логічної моделі, в той час як концептуальні вимоги відображають уявлення, які користувачі спочатку бажали мати і які лягли в основу розробки концептуальної моделі. Логічна модель відображається у фізичну пам'ять, таку, як диск, стрічка або який-небудь інший носій інформації.
Ієрархічна модель даних будується за принципом ієрархії типів об'єктів, тобто один тип об'єкта є головним, а інші, що знаходяться на нижчих рівнях ієрархії, - підлеглими. Між головним і підлеглими об'єктами встановлюється взаємозв'язок «один до багатьох». У той же час для кожного примірника головного об'єкта може бути кілька екземплярів підлеглих типів об'єктів. Взаємозв'язки між об'єктами нагадують взаємозв'язки в генеалогічному дереві за єдиним винятком: для кожного породженого (підлеглого) типу об'єкта може бути тільки один вихідний (головний) тип об'єкта.
Отже, отриману концептуальну модель, будемо вважати логіко-ієрархічної моделлю даних. Тому що на мою думку, більше перетворень не вийде. Кінцеву модель можна вважати закінченою.
Фізична модель, яка визначає розміщення даних, методи доступу та техніку індексування, називається внутрішньою моделлю системи.
Зовнішні моделі ніяк не пов'язані з типом фізичної пам'яті, в якій будуть зберігатися дані, і з методами доступу до цих даних. Це положення відображає перший рівень незалежності даних. З іншого боку, якщо концептуальна модель здатна враховувати розширення вимог до системи в майбутньому, то що вносяться до нього зміни не повинні впливати на існуючі зовнішні моделі. Це - другий рівень незалежності даних. Побудова логічної моделі обумовлено вимогами використовуваної СУБД. Тому при заміні СУБД вона також може змінитися.
З точки зору прикладного програмування незалежність даних визначається не технікою програмування, а його дисципліною, тобто для того щоб при будь-яку зміну системи уникнути перекомпіляції програми, рекомендується не визначати константи (постійні значення даних) у програмі. Краще рішення полягає в передачі програмі значень в якості параметрів.
Всі актуальні вимоги предметної області та адекватні їм «приховані» вимоги на стадії проектування повинні знайти своє відображення в концептуальній моделі. Звичайно, не можна передбачити всі можливі варіанти використання зміни бази даних. Але в більшості предметних областей такі основні дані, як об'єкти та їх взаємозв'язку, відносно стабільні. Змінюються тільки інформаційні вимоги, то є способи використання даних для отримання інформації.
Ступінь незалежності даних визначається ретельністю проектування бази даних. Всебічний аналіз об'єктів предметної області та їх взаємозв'язків мінімізує вплив зміни вимог до даних в одній програмі на інші програми. У цьому й полягає всеосяжна незалежність даних.
Основна відмінність між зазначеними вище трьома типами моделей даних (концептуальної, логічної та фізичної) складається в способах представлення взаємозв'язків між об'єктами. При проектуванні БД потрібно розрізняти взаємозв'язку між об'єктами, між властивостями одного об'єкта і між властивостями різних об'єктів.
У процесі проектування об'єкти перетворюються у відносини, властивості в поля таблиць, методи - в процедури, форми і т.д. (що і було зроблено). Правильно проведений об'єктно-орієнтований аналіз дозволяє значно полегшити роботу.
Одним з основних факторів, що впливають на продуктивність програм, які взаємодієютвуют з базою даних, є спосіб зберігання і доступу до даних. Зазвичай на додаток до спеціалізованих методів доступу в рамках зовнішньої моделі СУБД використовує декілька методів доступу внутрішньої моделі. Ми розглянемо (за умовою варіанти) індексного-послідовний метод доступу (ІМД).
Існує безліч індексних методів доступу, в основі яких лежить принцип створення окремого файлу або структури зі статей значень дійсного ключа. Стаття дійсного ключа називається статтею індексу, а весь файл дійсних ключів - індексом. Індексний файл значно менше власне бази даних, і, оскільки в оперативній пам'яті можуть перебувати багато хто з його статей, швидкість пошуку в ньому набагато вище.
У індексного-послідовного методі доступу індексний файл завжди впорядкований за так званого первинного ключа. Первинний ключ - головний атрибут фізичної запису. За його значенню ідентифікується фізична запис. До тих пір, поки це можливо, записи, зберігаються в одній логічній послідовності, що й індекс (звідси й назва "індексного-послідовний метод доступу").
Наведемо приклад таблиці індексів і їх зв'язку з наявними файлами даних, згідно варіанту.
Таблиця 4. Таблиця індексного файлу "ТОВАР" для індексних-послідовного методу доступу.
Примітка (Доходячи через індекси до файлу даних, за допомогою самого індексу зчитується найменування товару і далі вся інформація по полях знаходиться в записі, згідно таблиці ТОВАР).
