• Гідрологія і Гідрометрія
• Господарське право
• Економіка будівництва
• Економіка природокористування
• Економічна теорія
• Земельне право
• Історія України
• Кримінально виконавче право
• Медична радіологія
• Методи аналізу
• Міжнародне приватне право
• Міжнародний маркетинг
• Основи екології
• Предмет Політологія
• Соціальне страхування
• Технічні засоби організації дорожнього руху
• Товарознавство продовольчих товарів

ПРОЕКТУВАННЯ БАЗ ДАНИХ

12.1 Інформаційні бази. Основні підходи в організації інформаційних баз

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

В даний час склалися наступні основні підходи до побудови інформаційної бази:

1 Проектування файлу як відображення змісту окремого документа.

2 Проектування файлів для окремих задач.

3 Проектування файлів для комплексів задач, що розв'язуються або окремих підсистем автоматизованих систем управління проектами (АСУП).

4 Проектування бази даних.

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

- файли створюються з документів, що вже існують у системі керування;

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

- досить легко внести зміни в окремі файли.

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

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

Проектування файлів для окремих задач має наступні переваги:

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

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

У той же час таке проектування має ряд недоліків:

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

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

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

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

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

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

До переваг підходу, заснованого на концепції АБД, відносяться:

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

- вірогідність та несуперечність інформації, що зберігається та видається;

- санкціонований доступ до даних;

- можливість адаптації інформаційної моделі до змін предметної області об'єкта;

- видача інформації у формі, обумовленої користувачем;

- однократне введення первинних даних з наступним комплексним використанням;

- значне скорочення надмірності збережених даних тощо.

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

12.2 Трьохрівнева структура БД

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

Під час аналізу БД використовують три рівні представлення предметної області: зовнішній, концептуальний і внутрішній.

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

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

- перелік типів записів, з яких складаються файли БД;

- структура кожного типу запису (перелік полів та їхні типи даних);

- зв'язки між файлами.

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

Розглянута трьохрівнева структура БД представлена на рис. 12.1.

Рисунок 12.1 – Трьохрівнева структура БД

12.3 Реляційна модель даних

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

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

Основні поняття реляційних БД

У БД таблиці розміщуються у файлах. Кожна таблиця відповідає одному інформаційному об’єкту предметної області. Наприклад, якщо за предметну область обрати виробничу фірму, то можна відокремити наступні інформаційні об’єкти:

- вироби, які випускає фірма – інформаційний об’єкт ВИРОБИ;

- замовники, з якими працює фірма – інформаційний об’єкт ЗАМОВНИКИ;

- постачальники комплектуючих, необхідних для виробу продукції – інформаційний об’єкт ПОСТАЧАЛЬНИКИ, тощо.

Кожен рядок таблиці містить інформацію про конкретний екземпляр об'єкту. Для наведеного прикладу екземпляром об’єкту ВИРОБ є конкретний вид продукції (шафа, стіл, тощо). Об’єкт має певні характеристики, які цікавлять розробника БД з точки зору тих задач, які вирішуватимуться за допомогою БД в майбутньому, такі характеристики мають назву атрибутів. Для інформаційного об’єкту ВИРОБ такими характеристиками є: НАЗВА ВИРОБУ, ЦІНА ВИРОБУ, тощо. Кожному атрибутові у таблиці відповідає стовпчик або поле таблиці. Набір значень атрибутів (полів) для одного екземпляру об’єкта називається записом або кортежем. Надалі будемо використовувати як синоніми наступні терміни:

- таблиця, файл, відношення;

- рядок, запис, кортеж;

- стовпчик, атрибут, поле.

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

- порядок проходження елементів у відношенні не має значення, у той час як записи у файлі розташовані один за одним у визначеному порядку;

- у відношенні всі елементи повинні бути різними, а у файлі окремі записи можуть повторюватися.

Прикладом найпростішого відношення може служити довідник виробів, у якому представлені код та найменування виробу, а також норма витрати стали на його виготовлення (табл. 12.1).

Кількість стовпців у відношенні називається ступенем, а поточна кількість записів – потужністю. У приведеному вище прикладі ступінь відносини – 3, а потужність – 4.

Таблиця 12.1 – Довідник виробів

Ключі та індекси

Для того, щоб можна було працювати з даними БД, користувач повинен мати змогу знайти один екземпляр певного інформаційного об’єкту серед множини екземплярів, інформація про які міститься у таблиці. Тому для однозначної ідентифікації конкретного екземпляру об’єкту (запису таблиці) використовують певне поле, або кілька полів, які мають назву ключових полів, просто ключа або первинного ключа. Ключ може складатися з одного поля – простий ключ (поле НАЙМЕНУВАННЯ ВИРОБУ для об’єкту ВИРІБ), або з кількох полів – складений ключ (НАЗВА ВИРОБУ + ДАТА ПОСТАЧАННЯ для об’єкту ПОСТАЧАННЯ). Кожна таблиця повинна мати первинний ключ.

Зауваження:Головною рисою ключа є те, що його значення (значення ключового поля) для конкретного екземпляру повинно бути унікальним. Наприклад, якщо для об’єкту ВИРІБ використовується ключове поле НАЗВА ВИРОБУ, то у відповідній таблиці повинен бути тільки один запис, у полі Назва виробу якого стоїть значення Стіл, тільки один зі значенням Шафа, тощо. У випадку використання складених ключів унікальною повинна бути комбінація значень полів ключа, а значення окремих ключів могуть повторюватися.

Вторинний ключ встановлюється в полях, які часто використовуються під час пошуку, виборці або сортуванні даних (поле ЦІНА для об’єкта ВИРІБ).

Швидкість пошуку та сортування таблиці можна збільшити у сотні разів, якщо створити для таблиці індекс – внутрішню таблицю, що має два стовпця:

- значення виразу, що об’єднує всі поля, за якими здійснюється пошук (кілька полів індексу);

- місце положення кожного запису в початковій таблиці.

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

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

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

Читайте також:

1. Active-HDL як сучасна система автоматизованого проектування ВІС.
2. VII. Етап проектування
3. VII. Етап проектування
4. Автоматизація проектування напівзамовлених ВІС.
5. Аналіз паралельного інтерейсу з DSP-процесорами: запис даних в ЦАП, що під’єднаний до адресного простору пам’яті
6. Аналіз паралельного інтерфейсу з DSP-процесорами: читання даних з АЦП, що під’єднаний до адресного простору пам’яті
7. Аналіз статистичних даних про склад та плинність кадрів, які обіймали керівні
8. Аналіз та інтерпретація одержаних даних
9. Архіватори даних.
10. Архітектура баз даних
11. Аудит розрахунків за відшкодуванням завданих збитків
12. Бази даних АС ДЗК

Переглядів: 1296