незалежність відданих
Незалежність від даних може бути реалізована на двох рівнях: фізичному і логічному [1.3], [1.4]. Однак на даному етапі нас цікавить тільки фізична незалежність. Тому неуточнений термін незалежність від даних ми поки будемо розуміти лише як фізичну незалежність від даних. (Необхідно відзначити, що термін незалежність від даних не зовсім підходящий - він не відображає досить точно сутність того, що відбувається. Але оскільки традиційно використовується саме цей термін, підемо загальним правилом.)
Найпростіше розібратися в понятті незалежності від даних на прикладі тієї ситуації, коли незалежність від даних відсутня. Додатки, реалізовані в старих системах (дореляціонние, або створені до появи систем баз даних), в тій чи
іншій мірі залежні від даних. Це означає, що спосіб організації даних у вторинній
пам'яті і спосіб доступу до них диктуються вимогами програми. Більш того, відомості про організацію даних і способі доступу до них вбудовані в саму логіку і програмний код програми. Наприклад, припустимо, що в деякому додатку використовується файл EMPLOYEE (див. Рис. 1.4). Виходячи з міркувань продуктивності вирішено, що цей файл слід проіндексувати полю "ім'я службовця" (див. Додаток Г). У старих системах в цьому додатку враховувалося б, що такий індекс існує і що послідовність записів у файлі визначена цим індексом. На основі таких відомостей була б побудована вся внутрішня структура програми. Зокрема, обраний спосіб реалізації процедур доступу і обробки виняткових ситуацій в значній мірі залежав би від особливостей інтерфейсу, що надається програмами управління даними.
Додатки, подібні описаному в цьому прикладі, називаються залежними від даних, так як неможливо змінити фізичне уявлення (тобто спосіб фізичного розміщення даних у вторинній пам'яті) або метод доступу (тобто конкретний спосіб доступу до даних), не змінивши самого додатки (можливо, досить радикально). Наприклад, неможливо замінити індексований файл в нашому прикладі хешірованного файлом, що не внісши в додаток значних змін. Більш того, зміни в подібних випадках підлягають ті частини програми, які взаємодіють з програмами управління даними. Труднощі, що виникають при цьому, не мають ніякого відношення до проблеми, для вирішення якої було написано цю програму; це труднощі, породжувані використовуваної структурою інтерфейсу управління даними.
Однак для системи баз даних вкрай небажано, щоб додаток залежало від даних, і на те є щонайменше дві причини, описані нижче.
1. Для різних додатків потрібні різні уявлення одних і тих же даних.
Наприклад, припустимо, що до переходу до інтегрованої бази даних перед прийняття мало два додатки, А і В. Кожне з них працювало з власним файлом, що містить поле "залишок коштів на рахунку замовника". Припустимо
також, що додаток А записує значення цього поля в десятковому форматі,
а додаток В - в довічним. Ці два файли все ще можна інтегрувати, а су щества надмірність усунути, якщо в СУБД є можливість виконати всі необхідні перетворення між форматом представлення даних (формат уявлення може бути десятковим, двійковим або будь-яким іншим) і форма тому, необхідним для застосування. Наприклад, якщо прийнято рішення зберігати
значення цього поля в десятковому форматі, то кожне звернення до додатка В
зажадає прямого або зворотного перетворення значень з десяткового фор мату в двійковий.
Це досить простий приклад відмінностей, які можуть існувати в системі баз даних між формою представлення даних в додатку і формою їх фізичного зберігання. Багато інші можливі відмінності будуть розглянуті нижче.
2. Адміністратор бази даних повинен мати певні можливості (залежачи щие від застосовуваної СУБД) зі зміни фізичного представлення або методу доступу до даних в разі зміни вимог, причому без необхід мости модифікувати існуючі програми. Наприклад, до бази даних можуть бути додані нові види даних, на підприємстві можуть бути прийняті нові стандарти, можуть бути змінені пріоритети додатків (а отже, і
Таким чином, забезпечення незалежності від даних - найважливіша мета створення систем баз даних. Незалежність від даних можна визначити як несприйнятливість додатків до змін у фізичному поданні даних і в методах доступу до них, а це означає, що розглядаються програми не залежать від будь-яких конкретних способів фізичного представлення інформації або обраних методів доступу до них. У розділі 2 буде описана архітектура систем баз даних, що забезпечує основу для досягнення цієї мети. Однак перш за все розглянемо більш детально деякі приклади тих видів змін, у виконанні яких може виникнути необхідність і до яких, отже, повинні бути несприйнятливі додатки.
Почнемо з визначення трьох нових термінів: збережене поле, збережена запис і зберігається файл (рис. 1.6).
■ збережених поле - це найменша одиниця даних, що зберігаються. Типова база даних містить безліч екземплярів (occurence, або instance) кожного з декількох описаних в ній типів збережених полів. Наприклад, база даних, яка містить інформацію про деталі, може включати тип зберігається поля з име ньому "номер деталі" і для кожного описаного в базі даних виду деталі (гвинти, шарніра, ковпака і т.д.) буде існувати окремий екземпляр цього бережи мого поля.
Примітка. На практиці часто опускають кваліфікатори тип і екземпляр, вважаючи, що точний сенс зрозумілий з контексту. Хоча й існує невелика ймовірність плутанини, це зручна практика, і ми будемо їй час від часу слідувати. (Таке примітка відноситься також до збережених записів, мова про які піде в наступному абзаці.)
■ Збережена запис - це набір взаємопов'язаних збережених полів. І знову ми раз Ліча для них тип і екземпляр. В даному випадку екземпляр зберігається записи зі варто з групи пов'язаних примірників збережених полів. Наприклад, екземпляр зберігається записи в базі даних деталей складається з примірників кожного з сле дмуть збережених полів: "номер деталі", "назва деталі", "колір деталі" і "вага деталі". Ми говоримо, що база даних містить безліч екземплярів бережи мій записи типу "деталь" (знову ж таки, по одному екземпляру для кожної конкурують ної деталі).
■ Нарешті, зберігається файл - це набір усіх існуючих зараз ек земпляров збережених записів одного і того ж типу. (Для спрощення предполага ється, що будь-який заданий зберігається файл може містити збережені записи
тільки одного типу. Це спрощення не зробить істотного впливу на наступні міркування.)
У сучасних системах, відмінних від баз даних, логічна (з точки зору розробника додатку) запис зазвичай збігається з відповідною зберігається записом. Як було показано вище, в базах даних це зовсім не обов'язково, оскільки в будь-який момент може знадобитися внести зміни в структуру зберігання даних (тобто в збережені поля, записи, файли), в той час як структура даних з точки зору програми повинна залишитися незмінною. Наприклад, поле SALARY У файлі EMPLOYEE ДЛЯ ЕКОНОМІЇ пам'яті може бути збережено у двійковому форматі, а в додатку, написаному на мові COBOL, це поле може розглядатися в якості символьного рядка. Надалі з якихось причин може знадобитися змінити двійкову форму подання цього поля на десяткову, зберігши для додатка можливість обробляти поле в символьному форматі.
Мал. 1.6. Збережені поля, записи і файли
Як стверджувалося раніше, такі відмінності (що вимагають перетворення типу даних деякого поля при кожному зверненні до нього) є досить незначними.
Однак, в принципі, різниця між тими даними, до яких отримує доступ додаток, і тими, які зберігаються в базі насправді, може бути досить значною. Розвиваючи цю думку, перерахуємо ті аспекти структур зберігання даних в базах, які можуть зазнавати змін. Новомосковсктелю пропонується самостійно подумати над тим, що повинна зробити СУБД для забезпечення несприйнятливості додатки до таких змін (і чи завжди можна домогтися подібної несприйнятливості).
■ Подання числових даних
Числове поле може зберігатися у внутрішній арифметичної формі (наприклад, в упакованому десятковому форматі) або у вигляді символьного рядка. У кожному разі АБД повинен визначити, чи слід застосовувати числа з фіксованою або плаваючою точкою, вибрати відповідне підставу системи числення (наприклад, двійкову або десяткову систему), точність (кількість цифр у внутрішньому поданні числа), а якщо це число з фіксованою точкою, то визначити величину дробової частини (кількість цифр після точки, що розділяє цілу і дробову частини числа). Кожен з цих параметрів може бути змінений з метою підвищення продуктивності, при введенні нового стандарту або з деяких інших причин.
■ Подання символьних даних
Поле в форматі символьного рядка може зберігатися з використанням будь-якого з існуючих наборів кодувань символів (наприклад ASCII, EBCDIC, Unicode).
■ Одиниці виміру для числових даних
Одиниці виміру числових полів можуть бути змінені, наприклад, дюйми можуть бути перетворені в сантиметри в ході впровадження метричної системи одиниць.
У деяких ситуаціях може знадобитися представляти збережені дані у вигляді кодованих значень. Зокрема, поле "колір деталі", яке представлене в додатку як символьний рядок ( "червоний", "блакитний", "зелений"), може зберігатися у вигляді десяткового цифри відповідно до деякої таблицею перекодування, наприклад 1 = "червоний", 2 = "блакитний" і т.д.
Що використовується додатком логічне поле зазвичай дійсно відповідає деякому певному збереженому полю (хоча, як було показано вище, можуть існувати відмінності в типі даних, яка застосовується кодуванні і т.д.). В цьому випадку процес матеріалізації (materialization), тобто процес побудови примірника логічного поля з відповідного примірника зберігається поля і його передачі з додатком, називається прямим. Однак іноді логічне поле може не мати відповідного еквівалентного зберігається поля, а його значення буде матеріалізуватися за допомогою деяких обчислень, виконуваних над набором з декількох екземплярів збережених полів. Наприклад, значення логічного поля "загальна кількість" можна визначити шляхом підсумовування декількох збережених значень поля "кількість". У подібному випадку процес матеріалізації називається непрямим.
Структура збережених записів Дві існуючі збережені записи можна об'єднати в одну. Наприклад, збережені записи
можна представити у формі:
Такі зміни можуть виконуватися, коли в систему баз даних вводяться нові додатки. При цьому передбачається, що логічна запис програми складається з певного підмножини полів відповідної інформації, що зберігається записи, тобто деякі поля збереженої записи "невидимі" для розглянутого додатки.
І навпаки, одна збережена запис може бути розділена на дві. Скористаємося записами з попереднього прикладу. Тоді збережену запис
можна розбити на дві:
Такий поділ дозволяє перемістити рідко використовуються частини вихідної записи в інше місце, наприклад, на більш повільне пристрій. При цьому неявно передбачається, що логічна запис для програми може містити поля з кількох окремих збережених записів, тобто логічна запис включає будь-які з цих збережених записів як власні підмножини.
■ Структура збережених файлів
Певний зберігається файл може фізично зберігатися в пам'яті різними способами (див. Додаток Г). Наприклад, його можна розмістити на одному томі зовнішнього накопичувача (скажімо, на одному диску) або розподілити за кількома томами пристроїв (можливо, різних типів). Він може або бути фізично впорядкованим відповідно до значень деякого зберігається поля, або бути упорядкованим будь-яким іншим способом, наприклад за допомогою одного або декількох індексів або вбудованих ланцюжків покажчиків, або ж доступ до його записів може бути організований за методом хешування. Збережені записи можуть бути фізично об'єднані в блоки (з розміщенням декількох збережених записів в одному фізичному записи). Але жоден з цих факторів не повинен якимось чином впливати на додаток (за винятком, безумовно, швидкості його виконання).
Цим ми обмежимо перелік тих характеристик структури зберігання даних, які можуть зазнавати змін. Тут серед усього іншого передбачається, що база даних може рости і розвиватися, не впливаючи на додатки. Насправді, можливість розвитку бази даних без порушення логічної структури існуючих додатків є одним з найбільш важливих стимулів для забезпечення незалежності від даних. Наприклад, можна було б розширити існуючий
тип збереженої записи, додавши нові збережені поля, які зазвичай представляють додаткову інформацію про деяких можливих типах сутностей (скажімо, до інформації, що зберігається записи "деталь" можна додати поле "ціна за штуку"). Такі нові поля будуть невидимі для існуючих додатків. Точно так само можна додати нові типи збережених записів (а отже, нові збережені файли), не змінюючи існуючих додатків. Подібні записи зазвичай представляють собою нові типи сутностей (наприклад, до бази даних "деталі" можна додати тип запису "постачальник"). Ці зміни також будуть непомітні для існуючих додатків.
Тепер легко зрозуміти, що незалежність від даних-ще одна з причин, за якими слід відокремити модель даних від її реалізації, як уже було показано в кінці розділу 1.3. Важливо також зазначити, що незалежність від даних можна забезпечити, не досягнувши належною мірою відділення моделі даних від її реалізації. Недостатнє розділення моделі і її реалізації є широко поширеним недоліком сучасних систем, що використовують мову SQL (що особливо засмучує).
Примітка. Останнє зауваження (щодо використовують мову SQL сучасних систем) зовсім не означає, що в подібних системах абсолютно не забезпечена незалежність від даних. Воно лише вказує, що ці системи забезпечують незалежність від даних в значно меншій мірі, ніж теоретично можливо в реляційних сістемах4. Іншими словами, незалежність від даних - поняття відносне. Різні системи забезпечують її в різній мірі або не забезпечують взагалі. Системи, що базуються на мові SQL, більш розвинені в цьому напрямку, ніж старі системи, але, як буде показано в наступних розділах, всі вони ще далекі від досконалості.