прямки СУБД, які орієнтовано, але постійно присутні в оперативній пам'яті БД. Це напрямок грунтується на припущення, що на стільки великий, що дозволить, не турбується про буферизації. (Пака ця робота знаходиться в стадії розвитку). br/>
3. Управління транзакціями.
Транзакція - це послідовність операцій над БД, розглянута СУБД як єдине ціле. При виконанні транзакція може бути або успішно завершена, і СУБД зафіксує вироблені зміни у зовнішній пам'яті, або, наприклад, при збої в апаратної частини ПК, ні одного з змін не відіб'ється в БД. Поняття транзакція необхідно для підтримки логічної цілісності БД. Таким чином, підтримка механізму транзакції є обов'язковою умовою навіть однокористувальницьких СУБД. (Якщо така система заслуговує СУБД). Але поняття транзакція набагато більш важливо багато користувач СУБД, то властивість, то кожна транзакція починається при цілісному стані БД і залишає цей стан цілісне після свого завершення, робить дуже зручним, використання поняття транзакція як одиниці активності користувача по відношенню БД. При відповідному управлінні Управляти транзакціями з боку СУБД кожним використанням може в принципі відчувати себе єдиним користувачем СУБД. Управління транзакції багатокористувацької СУБД пов'язані важливі поняття серіалізация транзакції і серіального плану виконання суміші транзакції. Під стерилізацією виконанні паралельно серіалізация розуміють такий порядок планування їх робіт при якої сумарний ефект суміші транзакції еквівалентний ефекту їх деякого послідовного управління. Серіальний план виконання суміші транзакції це такий план, який призводить до серіалізация транзакції. Що якщо вдається домогтися дійсного серіального виконання суміші транзакції, то для кожного користувача з ініціативи, якої освічена транзакція присутність інших транзакцій буде непомітно (якщо не вважати деякого уповільнення роботи порівняно з одно користуванням режимом). Існує кілька базових алгоритмів серіалізация транзакції. Централізованих СУБД найбільш поширені алгоритми, засновані на синхронізації захоплення об'єктів БД. При використанні будь-якого алгоритму можлива ситуація конфлікту між двома або більш транзакціями з доступу об'єкта БД. У цьому випадку для підтримки серіалізация необхідні, виконувати відкат однієї чи більше транзакції. Це один з випадків, коли користувач багатокористувацької СУБД може реально (і досить неприємно) відчути присутність у системі транзакції інших користувачів. br/>
4. Архітектура СУБД.
Три рівня архітектури. p> Архітектура ANSI/SPARC включає три рівні: внутрішній, концептуальний і зовнішній. У загальних рисах вони є наступними:
- Внутрішній рівень-це рівень, найбільш близький до фізичній зберіганню, тобто пов'язаний зі способами збереження інформації на фізичних пристроях зберігання.
- Зовнішній рівень найбільш близький до користувачів, тобто він пов'язаний зі способами подання даних для окремих користувачів. p> - Концептуальний рівень-це В«проміжнийВ» рівень між двома першими. br/>
Зовнішній рівень (індивідуальні уявлення користувачів).
Концептуальний рівень (узагальнене уявлення користувачів).
Внутрішній рівень (подання до
пам'яті). br/>
Якщо зовнішній рівень з індивідуальними уявленнями користувачів, то концептуальний рівень пов'язаний з узагальненим поданням користувачів. Інакше кажучи, може бути декілька зовнішніх уявлень, кожне з яких складається з більш-менш абстрактного подання певної частини БД, і може бути тільки одне концептуальне уявлення, що складається з абстрактного уявлення БД в цілому. p> Зовнішній рівень-це індивідуальний рівень користувача. Користувач може бути прикладним програмістом або кінцевим користувачем з будь-яким рівнем професійної підготовки. Особливе місце серед користувачів займає адміністратор БД. (На відміну від інших користувачів його цікавить також концептуальний і внутрішній рівень.)
У кожного користувача є своя мова спілкування.
- Для прикладного програміста це або один з поширених мов програмування, такий як C, COBOL або PL/1, або спеціальний мову розглянутої системи. Такі оригінальні мови називають (неформально!) мовами четвертого покоління на тій підставі, що машинний код, мова асемблера і такі мови, як COBOL, можна вважати мовами трьох перших В«поколіньВ», а оригінальні мови модернізовані в порівнянні з мовами третього покоління так само, як мови третього покоління поліпшені в порівнянні з мовою асемблера.
- Для кінцевого користувача це або спеціальний мова запитів, або мова спеціального призначення, можливо, заснований на формах і меню, створений спеціально з урахуванням вимог і підтримуваний деякими оперативним додатком.
Хоча з точки зору архітектури зручно розрізняти...
