НЕЗАЛЕЖНІСТЬ віддаємо

Незалежність від даних може бути реалізована на двох рівнях: фізичному і логічному [13], [14] Проте на даному етапі нас цікавить тільки фізична незалежність Тому неуточнений термін незалежність від даних ми поки будемо розуміти лише як фізичну незалежність від даних (Необхідно відзначити, що термін незалежність від даних не зовсім підходящий – він не відображає досить точно сутність що відбувається Але оскільки традиційно використовується саме цей термін, підемо загальним правилом)

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

іншій мірі залежні від даних Це означає, що спосіб організації даних у вторинній

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

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

Однак для системи баз даних вкрай небажано, щоб додаток залежало від даних, і на те є щонайменше дві причини, описані нижче

1 Для різних додатків потрібні різні уявлення одних і тих же даних

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

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

а додаток В – у довічним Ці два файли все ще можна інтегрувати, а су ществу надмірність усунути, якщо в СУБД є можливість виконати всі необхідні перетворення між форматом представлення даних (формат подання може бути десятковим, двійковим або будь-яким іншим) і форма тому, необхідним для програми Наприклад, якщо прийнято рішення зберігати

значення цього поля в десятковому форматі, то кожне звернення до додатка В

потребують прямого або зворотного перетворення значень з десяткового фор мату в двійковий

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

2 Адміністратор бази даних повинен мати певні можливості (залежачи щие від застосовуваної СУБД) по зміні фізичного представлення або методу доступу до даних у випадку зміни вимог, причому без необхід мости модифікувати існуючі програми Наприклад, до бази даних можуть бути додані нові види даних, на підприємстві можуть бути прийняті нові стандарти, можуть бути змінені пріоритети додатків (а отже, і

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

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

Почнемо з визначення трьох нових термінів: збережене поле, збережена запис і бережене файл (Рис 16)

■&nbsp&nbsp&nbsp&nbsp Збережене поле – Це найменша одиниця збережених даних Типова база даних містить безліч примірників (Occurence, або instance) кожного з декількох описаних у ній типів збережених полів Наприклад, база даних, що містить інформацію про деталі, може включати тип зберігається поля з име ньому номер деталі і для кожного описаного в базі даних виду деталі (гвинта, шарніра, ковпака і тд) буде існувати окремий екземпляр цього храни мого поля

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

■&nbsp&nbsp&nbsp&nbsp Збережена запис – Це набір взаємоповязаних збережених полів І знову ми раз Ліча для них тип і екземпляр В даному випадку примірник збереженої записи зі стоїть з групи повязаних примірників збережених полів Наприклад, примірник зберігається записи в базі даних деталей складається з екземплярів кожного з сле дмуть збережених полів: номер деталі , назва деталі , колір деталі і вага деталі. Ми говоримо, що база даних містить безліч екземплярів храни мій записи типу Деталь (Знову ж, по одному примірнику для кожної конкурують ної деталі)

■ Нарешті, бережене файл – Це набір всіх існуючих зараз ек земпляров збережених записів одного і того ж типу (Для спрощення предполага ється, що будь-який заданий бережене файл може містити збережені записи

тільки одного типу Це спрощення не зробить істотного впливу на наступні міркування)

У сучасних системах, відмінних від баз даних, логічна (З точки зору розробника додатки) запис зазвичай збігається з відповідною збереженої записом Як було показано вище, в базах даних це зовсім не обовязково, оскільки в будь-який момент може знадобитися внести зміни в структуру зберігання даних (тобто в збережені поля, записи, файли), в той час як структура даних з точки зору програми повинна залишитися незмінною Наприклад, поле SALARY У файлі EMPLOYEE ДЛЯ ЕКОНОМІЇ памяті може бути збережено у двійковому форматі, а в додатку, написаному на мові COBOL, це поле може розглядатися в якості символьного рядка Надалі з якихось причин може знадобитися змінити двійкову форму подання цього поля на десяткову, зберігши для програми можливість обробляти поле в символьному форматі

Рис 16 Збережені поля, записи та файли

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

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

■&nbsp&nbsp&nbsp&nbsp Подання числових даних

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

■&nbsp&nbsp&nbsp&nbsp Подання символьних даних

Поле у ​​форматі символьного рядка може зберігатися з використанням будь-якого з існуючих наборів кодувань символів (наприклад ASCII, EBCDIC, Unicode)

■&nbsp&nbsp&nbsp&nbsp Одиниці виміру для числових даних

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

■&nbsp&nbsp&nbsp&nbsp Кодування даних

У деяких ситуаціях може знадобитися представляти збережені дані у вигляді кодованих значень Зокрема, поле колір деталі, яке представлене в додатку як символьний рядок (червоний, Блакитний, зелений), може зберігатися у вигляді десяткового цифри відповідно до деякої таблицею перекодування, наприклад 1 = червоний, 2 = блакитний і тд

■&nbsp&nbsp&nbsp&nbsp Матеріалізація даних

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

Структура збережених записів Дві існуючі збережені записи можна обєднати в одну Наприклад, збережені записи

можна представити у формі:

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

І навпаки, одна збережена запис може бути розділена на дві Скористаємося записами з попереднього прикладу Тоді збережену запис

можна розбити на дві:

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

■&nbsp&nbsp&nbsp&nbsp Структура збережених файлів

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

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

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

Тепер легко зрозуміти, що незалежність від даних-ще одна з причин, по яких слід відокремити модель даних від її реалізації, як вже було показано в кінці розділу 13 Важливо також відзначити, що незалежність від даних не можна забезпечити, не досягнувши належною мірою відділення моделі даних від її реалізації Недостатнє розділення моделі та її реалізації є широко поширеним недоліком сучасних систем, що використовують мову SQL (що особливо засмучує)

Примітка Останнє примітка (щодо використовують мову SQL сучасних систем) зовсім не означає, що в подібних системах абсолютно не забезпечена незалежність від даних Воно лише вказує, що ці системи забезпечують незалежність від даних в значно меншому ступені, ніж теоретично можливо в реляційних сістемах4 Іншими словами, незалежність від даних – поняття відносне Різні системи забезпечують її в різній мірі або не забезпечують взагалі Системи, що базуються на мові SQL, більш розвинені в цьому напрямку, ніж старі системи, але, як буде показано в наступних розділах, всі вони ще далекі від досконалості

Джерело: Дейт К Дж, Введення в системи баз даних, 8-е видання: Пер з англ – М: Видавничий дім «Вільямс», 2005 – 1328 с: Ил – Парал тит англ

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*