МАРК РЕГНЕРУС ДОСЛІДЖЕННЯ: Наскільки відрізняються діти, які виросли в одностатевих союзах
РЕЗОЛЮЦІЯ: Громадського обговорення навчальної програми статевого виховання ЧОМУ ФОНД ОЛЕНИ ПІНЧУК І МОЗ УКРАЇНИ ПРОПАГУЮТЬ "СЕКСУАЛЬНІ УРОКИ" ЕКЗИСТЕНЦІЙНО-ПСИХОЛОГІЧНІ ОСНОВИ ПОРУШЕННЯ СТАТЕВОЇ ІДЕНТИЧНОСТІ ПІДЛІТКІВ Батьківський, громадянський рух в Україні закликає МОН зупинити тотальну сексуалізацію дітей і підлітків Відкрите звернення Міністру освіти й науки України - Гриневич Лілії Михайлівні Представництво українського жіноцтва в ООН: низький рівень культури спілкування в соціальних мережах Гендерна антидискримінаційна експертиза може зробити нас моральними рабами ЛІВИЙ МАРКСИЗМ У НОВИХ ПІДРУЧНИКАХ ДЛЯ ШКОЛЯРІВ ВІДКРИТА ЗАЯВА на підтримку позиції Ганни Турчинової та права кожної людини на свободу думки, світогляду та вираження поглядів Контакти
Тлумачний словник |
|
|||||||
Етапи розвитку СБД
Історія розвитку СУБД налічує більше 40 років. У 1968 році була введена в експлуатацію перша промислова СУБД система IMS фірми IBM. У 1975 році з’явився перший стандарт асоціації по мовам систем обробки даних – Conference of Data System Languages (CODASYL), який визначив ряд фундаментальних понять в теорії систем баз даних. У подальший розвиток теорії баз даних великий внесок був зроблений американським математиком Едгаром Франком Коддом, який є творцем реляційної моделі даних. Прийнято вважати, що реляційний підхід до організації баз даних був закладений в кінці 1960-х рр. Едгаром Коддом. В останні десятиліття цей підхід є найбільш поширеним. Перевагою реляційного підходу прийнято рахувати наступні властивості: реляційний підхід грунтується на невеликому числі інтуїтивно зрозумілих абстракцій, на основі яких можливо просте моделювання найбільш поширених наочних областей; ці абстракції можуть бути точно і формально визначені; теоретичним базисом реляційного підходу до організації баз даних слугує простий і могутній математичний апарат теорії множин і математичної логіки; реляційний підхід забезпечує можливість ненавігаційного маніпулювання даними без необхідності знання конкретної фізичної організації баз даних в зовнішній пам’яті. Переваги реляційного підходу та розвиток методів і алгоритмів організації та управління реляційними базами даних привели до того, що до кінця 80-х років реляційні системи зайняли на світовому ринку СУБД домінуюче положення. У 1981 році Е. Ф. Кодд одержав за створення реляційної моделі і реляційної алгебри престижну премію Т'юринга Американської асоціації по обчислювальній техніці. Виділяють чотири етапи в розвитку систем управління базами даних. Перший етап – бази даних на великих ЕОМ Перший етап розвитку СУБД пов’язаний з організацією баз даних на великих машинах типу IBM 360/370, ЄС-ЕОМ і МІНІ-ЕОМ типу PDP11 (фірми Digital Equipment Corporation – DEC), різних моделях HP (фірми Hewlett Packard). Особливості цього етапу розвитку виражаються в наступному: - Всі СУБД базуються на могутніх мультипрограмних операційних системах (MVS, SVM, RTE, OSRV, RSX, UNIX), тому в основному підтримується робота з централізованою базою даних в режимі розподіленого доступу. - Значна роль відводиться адмініструванню даних. - Проводяться серйозні роботи по обгрунтуванню та формалізації реляційної моделі даних, в цей час була створена перша система (System R), що реалізовує ідеологію реляційної моделі даних. - Проводяться теоретичні роботи по оптимізації запитів і управлінню розподіленим доступом до централізованої БД, було введене поняття транзакції. - З’являються перші мови високого рівня для роботи з реляційною моделлю даних. Проте відсутні стандарти для цих мов. Другий етап – епоха персональних комп’ютерів Особливості цього етапу наступні: - Всі СУБД були розраховані на створення БД в основному з монопольним доступом. І це зрозуміло. Комп’ютер персональний, він не був приєднаний до мережі, і база даних на ньому створювалася для роботи одного користувача. У окремих випадках передбачалася послідовна робота декількох користувачів, наприклад, спочатку оператор, який вводив бухгалтерські документи, а потім головбух, який визначав проводки. - Більшість СУБД мали розвинений і зручний призначений для користувача інтерфейс. В більшості випадків існував інтерактивний режим роботи з БД, як в рамках опису БД, так і в рамках проектування запитів. Крім того, більшість СУБД пропонували розвинений і зручний інструментарії для розробки готових додатків без програмування. Інструментальне середовище складалося з готових елементів додатку у вигляді шаблонів екранних форм, звітів, графічних конструкторів запитів, які досить просто могли бути зібрані в єдиний комплекс. - У всіх настільних СУБД підтримувався тільки зовнішній рівень представлення реляційної моделі, тобто тільки зовнішній табличний вигляд структур даних. - У настільних СУБД були відсутні засоби підтримки посилальної і структурної цілісності бази даних. Ці функції повинні були виконувати додатки, проте незначність засобів розробки додатків іноді не дозволяла це зробити, і в цьому випадку ці функції повинні були виконуватися користувачем, вимагаючи від нього додаткового контролю при введенні і зміні інформації, що зберігається в БД. - Наявність монопольного режиму роботи фактично привела до знищення функцій адміністрування БД і у зв’язку з цим – до відсутності інструментальних засобів адміністрування БД. - Остання і вельми позитивна особливість – це порівняно скромні вимоги до апаратного забезпечення з боку настільних СУБД. Яскраві представники цього сімейства це СУБД dBase (dBase III+, dBase IV), FoxPro, Clipper, Paradox, які дуже широко використалися до недавнього часу. Третій етап – розподілені бази даних Особливості даного етапу: - Практично всі сучасні СУБД забезпечують підтримку повної реляційної моделі, а саме: o структурної цілісності – допустимими є тільки дані, представлені у вигляді відносин реляційної моделі; o мовної цілісності, тобто мов маніпулювання даними високого рівня (в основному SQL); o посилальної цілісності – контроль за дотриманням посилальної цілісності протягом всього часу функціонування системи, і гарантій неможливості з боку СУБД порушити ці обмеження. - Більшість сучасних СУБД розрахована на багатоплатформену архітектуру, тобто вони можуть працювати на комп’ютерах з різною архітектурою і під різними операційними системами. - Необхідність підтримки розрахованої на багатьох користувачів роботи з базою даних і можливість децентралізованого зберігання даних зажадали розвитку засобів адміністрування БД з реалізацією загальної концепції засобів захисту даних. - Для того, щоб не втратити клієнтів, які раніше працювали на настільних СУБД, практично всі сучасні СУБД мають засоби підключення клієнтських додатків, розроблених з використанням настільних СУБД, і засобу експорту даних з форматів настільних СУБД другого етапу розвитку. - До цього етапу можна віднести розробку ряду стандартів в рамках мов опису та маніпулювання даними (SQL89, SQL92, SQL99) і технологій по обміну даними між різними СУБД, до яких можна віднести і протокол ODBC (Open DataBase Connectivity), запропонований фірмою Microsoft. Саме до цього етапу можна віднести початок робіт, пов’язаних з концепцією об’єктно-орієнтованих БД – ООБД. Представниками СУБД, що відноситься до цьогоетапу, можна рахувати MS Access, сучасні сервери баз даних Огас1е, MS SQL 6.5, MS SQL 7.0, System 10, Informix DB2, SQL Base і інші сервери баз даних, яких зараз налічується декілька десятків. Четвертий етап - перспективи розвитку систем управління базами даних Цей етап характеризується появою нової технології доступу до даних – інтранет. Основна відмінність цього підходу від технології клієнт-сервер полягає в тому, що відпадає необхідність використання спеціалізованого клієнтського програмного забезпечення. Для роботи з видаленою базою даних використовується стандартний броузер Internet, наприклад Microsoft Internet Explorer, і для кінцевого користувача процес звернення до даних відбувається аналогічно навігації по Всесвітній Павутині. При цьому вбудований в HTML-сторінку код, написаний звичайно на мовах Java, Java-script, Perl і інших, відстежує всі дії користувача та транслює їх в низькорівневі SQL-запити до бази даних, виконуючи, таким чином, ту роботу, якої в технології клієнт-сервер займається клієнтська програма. Зручність даного підходу привела до того, що він став використовуватися не тільки для видаленого доступу до баз даних, але і для користувачів локальної мережі підприємства. Прості завдання обробки даних, не пов’язані з складними алгоритмами, що вимагають узгодженої зміни даних в багатьох взаємозв’язаних об’єктах, досить просто та ефективно можуть бути побудовані за даною архітектурою. В цьому випадку для підключення нового користувача до можливості використовувати дане завдання не потрібна установка додаткового клієнтського програмного забезпечення. Проте алгоритмічно складні завдання рекомендується реалізовувати в архітектурі клієнт-сервер з розробкою спеціального клієнтського програмного забезпечення.
Читайте також:
|
||||||||
|