мову COBOL; Традиційні мови програмування PL/I і COBOL, що послужили основою для даного прикладу, все ще широко використовуються в програмному забезпеченні, встановленому на багатьох підприємствах.). Звичайно, цей приклад повністю гіпотетічен і мало схожий на реальні системи, оскільки в ньому навмисне виключені багато не відносяться до справи деталі.
Розглянутий тут приклад потребує пояснень.
. На концептуальному рівні база даних містить інформацію про тип сутності з ім'ям EMPLOYEE (службовець). Кожен екземпляр суті EMPLOYEE включає атрибути номера службовця EMPLOYEE_NUMBER (шестеро символів), номери відділу DEPARTMENT_NUMBER (чотири символи) і зарплати службовця SALARY (п`ять десяткових цифр).
. На внутрішньому рівні службовці представлені типом збереженої записи STORED_EMP, довжина якої становить 20 байтів. Запис STORED_EMP містить чотири збережених поля: шестібайтовий префікс (можливо, що містить керуючу інформацію, таку як прапорці або покажчики) і три поля даних, що відповідають трьом властивостям сутності, яка представляє службовця. Крім того, записи STORED_EMP індексовані по полю ОМР # за допомогою індексу ЕМРХ.
. Користувач, що застосовує мову PL/I, має справу з відповідним зовнішнім поданням бази даних. У ньому кожен співробітник представлений записом на мові PL/I, що містить два поля (номери відділів даному користувачеві не вимагаються, тому в поданні вони опущені). Тип запису визначений за допомогою звичайної структури, відповідної правилами мови PL/I.
. Аналогічно, користувач, що застосовує мову COBOL, має справу з власним зовнішнім поданням бази даних, в якому кожен співробітник представлений записом на мові COBOL, що містить, знову ж таки, два поля (в даному випадку опущений розмір окладу). Тип запису визначений за допомогою звичайного опису на мові COBOL відповідно до прийнятих в ньому стандартними правилами.
Зверніть увагу, що в кожному випадку відповідні елементи даних можуть мати різні імена. Наприклад, до номеру співробітника звертаються як до полю ОМР # в поданні для мови PL/I і як до поля EMPNO. У поданні для мови COBOL. Цей же атрибут в концептуальному уявленні має ім'я EMPLOYEE_NUMBER, а під
внутрішньому представленні - ім'я ОМР #. Звичайно, в системі повинні бути відомі всі ці відповідності. Наприклад, відомо, що поле EMPNO У поданні для мови COBOL утворене з концептуального поля EMPLOYEE_NUMBER, яке, у свою чергу, відповідає збереженому полю ОМР # ВО внутрішньому поданні. Такі відповідності, або відображення (mapping), на рис. 1.2 явно не показані.
У даному випадку не має особливого значення, чи є розглянута система реляційної або який-небудь інший. Однак було б корисно коротко розповісти, як ці три рівні архітектури зазвичай реалізуються саме в реляційних системах.
По-перше, концептуальний рівень в такій системі безумовно буде реляційним в тому сенсі, що видимі на цьому рівні об'єкти є реляційними таблицями, а використовувані оператори - реляційними операторами (включаючи оператори вибірки рядків і стовпців).
По-друге, кожне зовнішнє уявлення, як правило, також буде реляційним або достатньо близьким до нього. Наприклад, оголошення записів в PL/I і COBOL, представлені на рис. 1.2, спрощено можна вважати аналогами оголошень таблиць в реляційної системі.
Примітка. Слід мати на увазі, що термін зовнішнє уявлення (часто-просто подання) в реляційному контексті має, на жаль, досить специфічний сенс, який неповністю збігається зі змістом, приписаним йому в цій главі.
По-третє, внутрішній рівень не буде реляційних, оскільки об'єкти на цьому рівні не будуть реляційними (збереженими) таблицями; навпаки, вони будуть об'єктами такого ж типу, як і що знаходяться на внутрішньому рівні об'єкти якої іншої системи (збережені записи, покажчики, індекси, хешірованние значення тощо). Насправді реляційна модель як така не дозволяє дізнатися нічого суттєвого про внутрішньому рівні. Вона, як уже зазначалося, має відношення лише до того, як сприймає базу даних користувач.
Тепер перейдемо до більш детального дослідження трьох рівнів архітектури, починаючи із зовнішнього рівня. На рис. 1.3 показані основні компоненти архітектури та їх взаємозв'язок.
Малюнок 1.3 - Детальна схема архітектури системи баз даних
1.2 Зовнішній рівень
Зовнішній рівень - це індивідуальний рівень користувача. Як було сказано раніше, користувач може бути прикладним програмістом або кінцевим користувачем з будь-яким рівнем професійної підготовки. Особливе місце серед користувачів займає адміністратор бази даних (АБД). На відміну від решти користувачів, АБД цікавлять т...
