овані й більш прикладними проблемами. Розглянемо трохи більш докладно (але без технічних деталей) істота деяких з цих питань і те, яким чином вони вирішуються в найбільш розвинених комерційних продуктах.
Використання мультипроцесорних організацій
Вже досить давно розвинені комерційні СУБД грунтуються на архітектурі «клієнт-сервер». При цій організації найбільш трудомісткі операції над базами даних виконуються на виділеному комп'ютері-сервері, який повинен бути досить потужним і володіти відповідним набором ресурсів основної та зовнішньої пам'яті. До пори серверна частина СУБД володіла простий організацією: запити, що надходять з клієнтських частин системи, оброблялися послідовно з невеликий оптимізацією для поєднання процесорної роботи з роботою пристроїв зовнішньої пам'яті. Однак з появою на ринку мультипроцесорних симетричних апаратних архітектур, виробники СУБД були змушені переглянути організацію своїх серверів, допустивши в них внутрішню паралельність. Природно, це вимагає дуже грунтовного перепроектування системи з її суттєвим ускладненням. Зауважимо, що в більшості випадків компанії пішли на це після появи в ОС UNIX механізму «легковагих» процесів (threads).
Про серйозність цієї роботи говорить той факт, що, наприклад, в компанії Informix було утворено новий підрозділ, що займається виключно питаннями розпаралелювання роботи серверів.
Інтеграція
Щоб переконати нових потенційних користувачів використовувати нові продукти, компанії-виробники повинні забезпечити вирішення проблеми використання старих баз даних. У принципі ця проблема є приватним видом проблеми включення у відкриті системи компонентів, які не були на це розраховані з самого початку. У більшості випадків пропоновані рішення грунтуються на використанні індустріальних стандартів розподілених об'єктних систем (наприклад, стандарту CORBA, розробленого OMG). Тим не менш, виробники СУБД змушені вирішувати численні проблеми для входження їх систем в нові інтегровані середовища.
Бази складних об'єктів, реляційна модель з відмовою від першої нормальної форми
Одним з основних положень реляційної моделі даних є вимога нормалізаціїии відносин: поля кортежів можуть містити лише атомарні значення. Для традиційних додатків реляційних СУБД - банківських систем, систем резервування тощо- Це зовсім не обмеження, а навіть перевага, що дозволяє проектувати економні по пам'яті БД з гранично зрозумілою структурою. Запити з сполуками в таких системах порівняно рідкісні, для динамічної підтримки цілісності використовуються відповідні кошти SQL. Однак з появою ефективних реляційних СУБД їх стали намагатися використовувати і в менш традиційних прикладних системах - САПР, системи штучного інтелекту і т.д. Такі системи зазвичай оперують зі складно структурованими об'єктами, для реконструкції яких з плоских таблиць реляційної БД доводиться виконувати запити, майже завжди вимагають з'єднання відносин. Відповідно до вимог розробників нетрадиційних додатків з'явився напрям досліджень баз складних об'єктів. Це дуже велика область досліджень, в якій порушуються питання моделей даних, структур даних, мов запитів, управління транзакціями, журналізації і т.д. Багато в чому ця область стикається з областю об'єктно-орієнтованих БД.
Активні бази даних
За визнач...
