47336 (665764), страница 2
Текст из файла (страница 2)
Але і в цей період з'являлися любителі, які всупереч здоровому глузду розробляли власні СУБД, використовуючи стандартні мови програмування. Це був тупиковий варіант, тому що подальший розвиток показав, що перенести дані з нестандартних форматів в нові СУБД було набагато важче, а в деяких випадках вимагало таких трудовитрат, що легше було б все розробити наново, але дані все одно треба було переносити на нову перспективнішу СУБД. І це теж було результатом недооцінки тих функцій, які повинна була виконувати СУБД.
Особливості цього етапу наступні:
Всі СУБД були розраховані на створення БД в основному з монопольним доступом. І це зрозуміло. Комп'ютер персональний, він не був приєднаний до мережі, і база даних на нім створювалася для роботи одного користувача. У окремих випадках передбачалася послідовна робота декількох користувачів, наприклад, спочатку оператор, який вводив бухгалтерські документи, а потім головбуха, який визначав проводки, відповідні первинним документам.
Більшість СУБД мали розвинений і зручний призначений для користувача інтерфейс. У більшості існував інтерактивний режим роботи з БД як в рамках опису БД, так і в рамках проектування запитів. Крім того, більшість СУБД пропонували розвинений і зручний інструментарій для розробки готових застосувань без програмування. Інструментальне середовище складалося з готових елементів додатку у вигляді шаблонів екранних форм, звітів, етикеток (Labels), графічних конструкторів запитів, які досить просто могли бути зібрані в єдиний комплекс.
У всіх настільних СУБД підтримувався тільки зовнішній рівень представлення реляційної моделі, тобто тільки зовнішній табличний вигляд структур даних.
За наявності високорівневих мов маніпулювання даними типу реляційної алгебри і SQL в настільних СУБД підтримувалися низькорівневі мови маніпулювання даними на рівні окремих рядків таблиць.
У настільних СУБД були відсутні засоби підтримки посилальної і структурної цілісності бази даних. Ці функції повинні були виконувати додатки, проте незначність засобів розробки додатків іноді не дозволяла це зробити, і в цьому випадку ці функції повинні були виконуватися користувачем, вимагаючи від нього додаткового контролю при введенні і зміні інформації, що зберігається в БД.
Наявність монопольного режиму роботи фактично привела до звироднілості функцій адміністрування БД і у зв'язку з цим — до відсутності інструментальних засобів адміністрування БД.
І, нарешті, остання і зараз вельми позитивна особливість — це порівняно скромні вимоги до апаратного забезпечення з боку настільних СУБД. Цілком працездатні застосування, розроблені, наприклад, на Clipper, працювали на РС 286.
В принципі, їх навіть важко назвати повноцінними СУБД. Яскраві представники цього сімейства — дуже СУБД Dbase (DbaseIII+, DBASEIV), що широко використалися до недавнього часу, FoxPro, Clipper, Paradox.
Розподілені бази даних
Добре відомо, що історія розвивається по спіралі, тому після процесу "персоналізації" почався зворотний процес — інтеграція. Множиться кількість локальних мереж, все більше інформації передається між комп'ютерами, гостро встає завдання узгодженості даних, що зберігаються і обробляються в різних місцях, але логічно один з одним зв'язаних, виникають завдання, пов'язані з паралельною обробкою транзакцій, — послідовностей операцій над БД, що переводять її з одного несуперечливого стану в інший несуперечливий стан. Успішне вирішення цих завдань приводить до появи розподілених баз даних, що зберігають всі переваги настільних СУБД і в той же час дозволяють організувати паралельну обробку інформації і підтримку цілісності БД.
Особливості даного етапу:
Практично всі сучасні СУБД забезпечують підтримку повної реляційної моделі, а саме:
Про структурну цілісність — допустимими є тільки дані, представлені у вигляді стосунків реляційної моделі;
Про мовну цілісність, тобто мов маніпулювання даними високого рівня (в основному SQL);
Про посилальну цілісність, контролю за дотриманням посилальної цілісності протягом всього часу функціонування системи, і гарантій неможливості з боку СУБД порушити ці обмеження.
Більшість сучасних СУБД розраховані на багато платформну архітектуру, тобто вони можуть працювати на комп'ютерах з різною архітектурою і під різними операційними системами, при цьому для користувачів доступ до даних, керованих СУБД на різних платформах, практично невиразний.
Необхідність підтримки багато користувацької роботи з базою даних і можливість децентралізованого зберігання даних зажадали розвитку засобів адміністрування БД з реалізацією загальної концепції засобів захисту даних.
Потреба в нових реалізаціях викликала створення серйозних теоретичних праць по оптимізації реалізацій розподіленій БД і роботі з розподіленими транзакціями і запитами з впровадженням отриманих результатів в комерційні СУБД.
Для того, щоб не втратити клієнтів, які раніше працювали на настільних СУБД, практично всі сучасні СУБД мають засоби підключення клієнтських застосувань, розроблених з використанням настільних СУБД, і засобу експорту даних з форматів настільних СУБД другого етапу розвитку.
Саме до цього етапу можна віднести розробку ряду стандартів в рамках мов опису і маніпулювання даними починаючи з SQL89, SQL92, SQL99 і технологій по обміну даними між різними СУБД, до яких можна віднести і протокол ODBC (Open DataBase Connectivity), запропонований фірмою Microsoft.
Саме до цього етапу можна віднести початок робіт, пов'язаних з концепцією об'єктно-орієнтованих БД, — ООБД. Представниками СУБД, що відносяться до другого етапу, можна рахувати MS Access 97 і всі сучасні сервери баз даних Oracle7.3,Oracle 8.4 MS SQL6.5, MS SQL7.0, System 10, System 11, Informix, DB2, SQL Base і інші сучасні сервери баз даних, яких зараз налічується декілька десятків.
Перспективи розвитку систем управління базами даних
Цей етап характеризується появою нової технології доступу до даних — Інтернет. Основна відмінність цього підходу від технології клієнт-сервер полягає в тому, що відпадає необхідність використання спеціалізованого клієнтського програмного забезпечення. Для роботи з видаленою базою даних використовується стандартний браузер Інтернету, наприклад Microsoft Internet Explorer або Netscape Navigator, і для кінцевого користувача процес звернення до даних відбувається аналогічно ковзанню по Усесвітній Павутині. При цьому вбудований в завантажені користувачем HTML-сторінки код, написаний зазвичай на мові Java, Java-script, Perl і інших, відстежує всі дії користувача і транслює їх в низькорівневі SQL-запроси до бази даних, виконуючи, таким чином, ту роботу, якій в технології клієнт-сервер займається клієнтська програма. Зручність даного підходу привела до того, що він почав використовуватися не тільки для видаленого доступу до баз даних, але і для користувачів локальної мережі підприємства. Прості завдання обробки даних, не пов'язані з складними алгоритмами, що вимагають узгодженої зміни даних в багатьох взаємозв'язаних об'єктах, досить просто і ефективно можуть бути побудовані по даній архітектурі. В цьому випадку для підключення нового користувача до можливості використовувати дане завдання не потрібна установка додаткового клієнтського програмного забезпечення. Проте алгоритмічно складні завдання рекомендується реалізовувати в архітектурі "клієнт-сервер" з розробкою спеціального клієнтського програмного забезпечення.
У кожного з вище перелічених підходів до роботи з даними є свої достоїнства і свої недоліки, які і визначають сферу застосування того або іншого методу, і в даний час всі підходи широко використовуються.
1960-ті рр. розробка перших БД. CODASYL — мережева модель даних та одночасно незалежна розробка ієрархічної БД фірмою North American Rockwell, яка пізніше узята за основу IMS — власної розробки IBM.
1970-ті рр. наукове обґрунтування Едгаром Ф. Коддом основ реляційної моделі, котра на качану зацікавила лише наукові кола. Вперше цю модель було використано у БД Ingres (Берклі) та System R(IBM), що булі лише дослідними прототипами, анонсованими протягом 1976 долі.
1980-ті рр. поява перших комерційних версій реляційних БД Oracle та DB2. Реляційні БД починають успішно витісняти мережеві та ієрархічні. Дослідження децентралізованих (розподілених) систем БД, проте сморід не відіграють особливої ролі на ринку БД.
1990-ті рр. увага науковців спрямовується у сторону об'єктно-орієнтованих БД, які знайшли застосування у деру чергу в тихий областях, де використовуються комплексні дані: інженерні, мультимедійні БД.
2000-ні рр. головним нововведенням є підтримка та застосування XML у БД. Розробники комерційних БД, які панували на ринку у 1990-их рр., отримують все більшу конкуренцію зі сторони руху відкритого програмного забезпечення. Реакцією на це стає поява безкоштовних версій комерційних БД.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
