Системи з базами даних

Вступ

Бази даних стали невід'ємною частиною нашого повсякденного життя. Тому обговорення баз даних у цьому розділі ми почнемо з вивчення деяких прикладів використання систем баз даних. У подальших міркуваннях будемо розглядати базу даних як деякий набір зв'язаних даних, а систему керування базами даних,чиСКБД (Database Management System — DBMS), як програмне забезпечення, що керує доступом до цієї бази даних. Більш строгі і точні визначення будуть викладені далі.

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

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

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

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

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

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

1.2. Традиційні файлові системи

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

· Розуміння проблем, які властиві файловим системам, може запобігтиїх повторення в СКБД. Інакше кажучи, варто врахувати досвід минулих помилок. Насправді, слово "помилки" у даному випадку звучить трохи зневажливо і не дає ніякого представлення про ту корисну роботу, що виконувалася протягом багатьох років. Проте воно дає зрозуміти, що існують і інші, більш ефективні способи керування даними.

· Знати принципи роботи файлових систем не тільки дуже корисно, але і необхідно при виконанні переходу від файлової системи до системи баз даних.

1.2.1. Підхід, який використовується у файлових системах БД

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

Файлові системи були першою спробою комп'ютеризувати відомі усім ручні картотеки. Подібна картотека (чи підшивка документів) у деякій організації могла містити всю зовнішню і внутрішню документацію, зв'язану з яким-небудь проектом, продуктом, задачею чи клієнтом. Звичайно таких папок буває дуже багато, вони позначаються і зберігаються в одному чи декількох шафах. З метою безпеки шафи можуть закриватися на замок чи знаходитися в приміщеннях, що охороняються. У кожного з нас є у будинку деяка подоба такої картотеки, що містить підшивки документів, що представляють собою рахунки, гарантійні талони, рецепти, страхові і банківські документи і т. і. Якщо нам знадобиться якась інформація, буде потрібно переглянути картотеку від початку до кінця, щоб знайти шукані зведення. Більш витончений підхід передбачає використання в такій системі деякого алгоритму індексування, що дозволяє прискорити пошук потрібних зведень. Наприклад, можна використовувати спеціальні роздільники чи окремі папки для різних логічно, зв'язаних типів об'єктів.

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

· Які з виставлених на продаж об'єктів із трьома спальнями мають сад і гараж?

· Які з квартир, що здаються в оренду, розташовані в межах трьох миль від центра міста?

· Яка середня ціна будинку?

· Яка середня орендна плата за квартиру з двома спальнями?

· Чому дорівнює загальна річна заробітна плата всіх співробітників?

· Яким був щомісячний оборот від продажів нерухомості торік?

· Яким був оборот минулого місяця в порівнянні з прогнозованими показниками в цьому місяці?

· Яким буде очікуваний щомісячний оборот у наступному фінансовому році?

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

Щоб зрозуміти основні принципи такого підходу, ми розглянемо його на прикладі навчального проекту DreamHome.

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

За допомогою співробітників відділу обробки даних (ОД) співробітники відділу реалізації створили інформаційну систему для керування даними про оренду нерухомості. Ця система складається з трьох показаних у табл. 1.1 - 1.3 файлів з даними про нерухомість (Property for Rent), власників (Owner) і орендарів (Renter). Для простоти викладу опустимо деталі, що відносяться до співробітників компанії, різним її відділенням і власникам нерухомості, що представляє собою юридичні особи.

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

оренду, то одним зі співробітників відділу реалізації заповнюється форма, показана на мал.1.2. У ній указуються всі необхідні зведення про орендаря й об'єкт, що здається в оренду, нерухомості. Ця форма передається у відділ контрактів, співробітники якого привласнюють договору номер і вносять додаткові зведення про оплату і тривалість оренди. За допомогою співробітників відділу ОД співробітники відділу контрактів створили для себе інформаційну систему обліку договорів про оренду. Ця система складається з трьох файлів, представлених у табл. 1.4 - 1.6. Файли містять зведення про договори (Lease), об'єктах нерухомості (Property for Rent) і орендарях (Renter), що багато в чому подібні з даними в інформаційній системі відділу реалізації.

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

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

Staff_Salary (Staff Number, First Name, Last Name, Address, Sex, Date of Birth, Salary, National Insurance Number, Branch Number)

У відділі кадрів також зберігається інформація про персонал, але вона представлена у файлі іншого формату:

Staff (Staff Number, First Name, Last Name, Address, Telephone Number, Position, Sex, Date of Birth, Salary, National Insurance Number, Branch Number)

Зовсім очевидно, що дуже велика кількість даних у відділах дублюється і це дуже характерно для будь-яких файлових систем. Перш ніж почати обговорення недоліків цього підходу, було б корисно познайомитися з термінологією, яка використовується у файлових системах. Файл є простим набором записів (record), що містять логічно зв'язані дані. Наприклад, файл Ргорerty_for_Rent зміст якого представлено в табл.1.1, містить шість записів, по однієї для кожного об'єкту, що здається в оренду, нерухомості. Кожен запис містить логічно зв'язаний набір з одного чи декількох полів (field), кожне з який представляє деяку характеристику об'єкту що моделюється. З табл.1.1 видно, що поля файлу Property_for_Rent представляють такі характеристики об'єктів, що здаються в оренду, як адреса, тип об'єкта і кількість кімнат.

Puc. 1.3. Схема обробки даних е-файловой системі

Файли відділу реалізації

Property_for_Rent (Property Number, Street, Area, City, Post Code; Property Type, Number of Rooms, Monthly Rent, Owner Number)

Owner (Owner Number, First Name, Last Name, Address Telephone Number)

Renter (Renter Number, First Name, Last Name, Address, Telephone Number, Preferred Type, Maximum Rent)

Файли відділу контрактів

Lease (Lease Number, Property Number, Renter Number, Monthly Rent, Payment Method, Deposit, Paid, Rent Start Date, Rent Finish Date, Duration)

Property_For_Rent (Property Number, Street, Area, City, Post Code, Monthly Rent)

Renter (Renter Number, First Name, Last Name, Address, Telephone Number)

1.2.2. Обмеження, властиві файловим системам

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

• Поділ і ізоляція даних.

• Дублювання даних.

• Залежність від даних.

• Несумісність файлів.

• Фіксовані запити/швидке збільшення кількості програм.

Поділ і ізоляція даних

Коли дані ізольовані в окремих файлах, доступ до них дуже ускладнений. Наприклад, для створення списку всіх будинків, що відповідають вимогам потенційних орендарів, попередньо потрібно, створити тимчасовий файл зі списком орендарів, що бажають орендувати нерухомість типу "будинок". Потім у файлі “Власність_В_Оренду” варто здійснити пошук об'єктів нерухомості типу “будинок” орендною платою нижче встановленого орендарем максимуму. Виконувати подібну обробку даних у файлових системах досить складно. Для витягу відповідної поставленим умовам інформації програміст повинний організувати синхронну обробку двох файлів. Труднощі істотно зростають, коли необхідно витягти дані з більш ніж двох файлів.

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

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

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

Залежність від даних

Як уже згадувалося вище, фізична структура і спосіб збереження записів файлів даних жорстко зафіксовані в коді програм. Це значить, що змінити існуючу структуру даних досить складно. Наприклад, збільшення у файлі “Власність_В_Оренду” довжини поля адреси з 40 до 41 символу здається зовсім незначною зміною його структури, але для втіленні цієї зміни буде потрібно, як мінімум, створити одноразову програму спеціального призначення (тобто програму, що виконується тільки один раз), що перетворить вже існуючий файл “Власність_В_Оренду” у новий формат. Вона повинна виконувати наступні дії:

· відкрити вихідний файл “Власність_В_Оренду” для читання;

· відкрити тимчасовий файл із новою структурою запису;

· читати запис з вихідного файлу, перетворити дані в новий формат і записати їх у тимчасовий файл. Ці дії варто виконати для всіх записів вихідного файлу;

· видалити вихідний файл “Власність_В_Оренду”;

· привласнити тимчасовому файлу ім'я “Власність_В_Оренду”.

Крім цього, всі програми, що звертаються до файлу “Власність_В_Оренду” повинні бути змінені з метою відповідності новій структурі файлу. Причому таких програм може бути дуже багато. Отже, програміст повинний колись виявити всі такі програми, а потім перевірити ще раз і змінити їх. Зверніть увагу, що багато програми можуть звертатися до файлу “Власність_В_Оренду” і при цьому взагалі не використовувати поле адреси. Ясно, що виконання всіх цих дій вимагає великих витрат часу і може з'явитися причиною появи помилок. Дана особливість файлових систем називається залежністю від програм і даних (program-data dependence).

Несумісність форматів файлів

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

Фіксовані запити/швидке збільшення кількості програм

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

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

Усі перераховані вище обмеження файлових систем є наслідком двох факторів.

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

2. Крім програм не передбачено ніяких інших інструментів доступу до данихі їх обробки.

Для підвищення ефективності роботи необхідно використовувати новий підхід, а саме базу даних (database) і систему керування базами даних, чи СКБД (Database Management System — DBMS). У цьому розділі представлене більш формальне визначення цих термінів, а також розглянуті компоненти середовища СКБД.

Дата добавления: 2014-01-07