22.Логічна структура скбд oracle

Логічна структура бази даних ORACLE визначається:

• одним або декількома табличними просторами

• об'єктами схем  бази даних  (таблицями, оглядами, індексами,  кластерами,  послідовностями, збереженими процедурами)

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

23. Основні вимоги до реалізації систем архітектури “Клієнт-сервер”

Список з 12 критеріїв, якими слід керуватися при розробці програмних продуктів і технології надання сервісів клієнт-сервер.

1. Збереження автономності серверу. Клієнти повинні слідувати правилам, встановленими серверами; вони не повинні обмежувати доступність серверів (наприклад, шляхом блокування без необхідності надмірно великих об’ємів даних) і не повинні порушувати цілісність яких-небудь даних серверу.

2. Збереження автономності клієнта. Спосіб функціонування клієнта не повинен залежати від того, чи підключається він до віддаленого чи локального серверу бази даних; користувачі повинні бути ізольовані від аспектів, пов’язаних з місцеположенням даних.

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

4. Доступність специфічних засобів серверу. Клієнт може запитати деякі специфічні функції конкретного серверу для більш якісного виконання роботи. Ці функції повинні бути доступні.

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

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

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

8. Можливість локального прототипування. Віддаленість інформації не повинна перешкоджати можливості прототипування призначених для користувача додатків.

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

10. Повнота середовища розробки додатків. Крім перерахованих у п. 9 інструментів середовище розробки повинно також включати засоби для встановлення з’єднань через мережу і управління ними, доступу до сервісів глобального іменування і місцезнаходження даних і ін.

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

12. Проходження стандартам. Чим жорсткіше підтримуватимуться стандарти, тим менше виникатиме проблем з інтероперабельністю компонентів.