Історiя розвитку баз даних
На тему: Історiя розвитку баз даних
У iсторiї обчислювальної технiки можна прослiдкувати розвиток двох основних областей її використання. Перша область — застосування обчислювальної технiки для виконання чисельних розрахункiв, якi дуже довго або взагалi неможливо проводити уручну. Розвиток цiєї областi сприяв iнтенсифiкацiї методiв чисельного вирiшення складних математичних завдань, появi мов програмування, орiєнтованих на зручний запис чисельних алгоритмiв, становленню зворотного зв'язку з розробниками нової архiтектури ЕОМ. Характерною особливiстю даної сфери застосування обчислювальної технiки є наявнiсть складних алгоритмiв обробки, якi застосовуються до простих по структурi даним, об'єм яких порiвняно невеликий.
комплексом, що забезпечує виконання наступних функцiй:
надiйне зберiгання iнформацiї в пам'ятi комп'ютера;
виконання специфiчних для даного застосування перетворень iнформацiї i обчислень;
Зазвичай такi системи мають справу з великими об'ємами iнформацiї, що має достатньо складну структуру. Класичними прикладами iнформацiйних систем є банкiвськi системи, автоматизованi системи управлiння пiдприємствами, системи резервування авiацiйних або залiзничних квиткiв, мiсць в готелях i так далi
Говорити про надiйне i довготривале зберiгання iнформацiї можна тiльки за наявностi пристроїв, що запам'ятовують, зберiгають iнформацiю пiсля виключення електричного живлення. Оперативна (основна) пам'ять комп'ютерiв цiєю властивiстю зазвичай не володiє. У перших комп'ютерах використовувалися два види пристроїв зовнiшньої пам'ятi — магнiтнi стрiчки i барабани. Ємкiсть магнiтних стрiчок була достатньо велика, але по своїй фiзичнiй природi вони забезпечували послiдовний доступ до даних. Магнiтнi ж барабани (вони щонайближче до сучасним магнiтним дискам з фiксованими головками) давали можливiсть довiльного доступу до даних, але мали обмежений об'єм iнформацiї, що зберiгалася.
в зовнiшнiй пам'ятi (наприклад, на послiдовнiй магнiтнiй стрiчцi), що забезпечує ефективне виконання цiєї програми. Проте в iнформацiйних системах сукупнiсть взаємозв'язаних iнформацiйних об'єктiв фактично вiдображає модель об'єктiв реального миру. А потреба користувачiв в iнформацiї, адекватно тiєї, що вiдображає стан реальних об'єктiв, вимагає порiвняно швидкої реакцiї системи на їх запити. І в цьому випадку наявнiсть порiвняльна повiльних пристроїв зберiгання даних, до яких вiдносяться магнiтнi стрiчки i барабани, було недостатнiм.
Можна припустити, що саме вимоги нечислових застосувань викликали появу знiмних магнiтних дискiв з рухомими головками, що з'явилося революцiєю в iсторiї обчислювальної технiки. Цi пристрої зовнiшньої пам'ятi володiли iстотно бiльшою ємкiстю, чим магнiтнi барабани, забезпечували задовiльну швидкiсть доступу до даних в режимi довiльної вибiрки, а можливiсть змiни дискового пакету на пристрої дозволяла мати практично необмежений архiв даних.
З появою магнiтних дискiв почалася iсторiя систем управлiння даними в зовнiшнiй пам'ятi. До цього кожна прикладна програма, якою потрiбно було зберiгати данi в зовнiшнiй пам'ятi, сама визначала розташування кожної порцiї даних на магнiтнiй стрiчцi або барабанi i виконувала обмiни мiж оперативною пам'яттю i пристроями зовнiшньої пам'ятi за допомогою програмно-апаратних засобiв низького рiвня (машинних команд або викликiв вiдповiдних програм операцiйної системи). Такий режим роботи не дозволяє або дуже утрудняє пiдтримка на одному зовнiшньому носiєвi декiлькох архiвiв iнформацiї, що довго тривало зберiгається. Крiм того, кожнiй прикладнiй програмi доводилося вирiшувати проблеми iменування частин даних i структуризацiї даних в зовнiшнiй пам'ятi.
Файли i файловi системи
Важливим кроком в розвитку саме iнформацiйних систем з'явився перехiд до використання централiзованих систем управлiння файлами. З погляду прикладної програми, файл — це iменована область зовнiшньої пам'ятi, в яку можна записувати i з якої можна прочитувати данi. Правила iменування файлiв, спосiб доступу до даних, що зберiгаються у файлi, i структура цих даних залежать вiд конкретної системи управлiння файлами i, можливо вiд типу файлу. Система управлiння файлами бере на себе розподiл зовнiшньої пам'ятi, вiдображення iмен файлiв у вiдповiднi адреси в зовнiшнiй пам'ятi i забезпечення доступу до даних.
Конкретнi моделi файлiв, використовуванi в системi управлiння файлами, ми розглянемо далi, коли перейдемо до фiзичних способiв органiзацiї баз даних, а на цьому етапi нам досить знати, що користувачi бачать файл як лiнiйну послiдовнiсть записiв i можуть виконати над ним ряд стандартних операцiй:
2. вiдкрити ранiше створений файл;
4. записати у файл на мiсце поточного запису нову, додати новий запис в кiнець файлу.
У рiзних файлових системах цi операцiї могли декiлька вiдрiзнятися, але загальний сенс їх був саме таким. Головне, що слiд зазначити, це те, що структура запису файлу була вiдома тiльки програмi, яка з ним працювала, система управлiння файлами не знала її. І тому для того, щоб витягувати деяку iнформацiю з файлу, необхiдно було точно знати структуру запису файлу з точнiстю до бiта. Кожна програма, що працює з файлом, повинна була мати у себе усерединi структуру даних, вiдповiдну структурi цього файлу. Тому при змiнi структури файлу потрiбно було змiнювати структуру програми, а це вимагало нової компiляцiї, тобто процесу перекладу програми у виконуванi машиннi коди. Така ситуацiї характеризувалася як залежнiсть програм вiд даних. Для iнформацiйних систем характерною є наявнiсть великого числа рiзних користувачiв (програм), кожен з яких має свої специфiчнi алгоритми обробки iнформацiї, що зберiгається в одних i тих же файлах. Змiна структури файлу, яке було необхiдне для однiєї програми, вимагала виправлення i перекомпiляцiї i додаткового налагодження решти всiх програм, що працюють з цим же файлом. Це було першим iстотним недолiком файлових систем, який з'явився поштовхом до створення нових систем зберiгання i управлiння iнформацiєю.
Далi, оскiльки файловi системи є загальним сховищем файлiв, що належать, взагалi кажучи, рiзним користувачам, системи управлiння файлами повиннi забезпечувати авторизацiю доступу до файлiв. У загальному виглядi пiдхiд полягає в тому, що по вiдношенню до кожного зареєстрованого користувача даної обчислювальної системи для кожного iснуючого файлу указуються дiї, якi дозволенi або забороненi даному користувачевi. У бiльшостi сучасних систем управлiння файлами застосовується пiдхiд до захисту файлiв, вперше реалiзований в ОС UNIX. У цiй ОС кожному зареєстрованому користувачевi вiдповiдає пара цiлочисельних iдентифiкаторiв: iдентифiкатор групи, до якої вiдноситься цей користувач, i його власний iдентифiкатор в групi. При кожному файлi зберiгається повний iдентифiкатор користувача, який створив цей файл, i фiксується, якi дiї з файлом може проводити його творець, якi дiї з файлом доступнi для iнших користувачiв тiєї ж групи i що можуть робити з файлом користувачi iнших груп. Адмiнiстрування режимом доступу до файлу в основному виконується його творцем-власником. Для безлiчi файлiв, що вiдображають iнформацiйну модель однiєї наочної областi, такий децентралiзований принцип управлiння доступом викликав додатковi труднощi. І вiдсутнiсть централiзованих методiв управлiння доступом до iнформацiї послужила ще однiєю причиною розробки СУБД.
Наступною причиною стала необхiднiсть забезпечення ефективної паралельної роботи багатьох користувачiв з одними i тими ж файлами. У загальному випадку системи управлiння файлами забезпечували режим багато користувацького доступу. Якщо операцiйна система пiдтримує багато користувацький режим, цiлком реальна ситуацiя, коли два або бiльш за користувача одночасно намагаються працювати з одним i тим же файлом. Якщо всi користувачi збираються тiльки читати файл, нiчого страшного не вiдбудеться. Але якщо хоч би один з них змiнюватиме файл, для коректної роботи цих користувачiв потрiбна взаємна синхронiзацiя їх дiй по вiдношенню до файлу.
У системах управлiння файлами зазвичай застосовувався наступний пiдхiд. У операцiї вiдкриття файлу (першiй i обов'язковiй операцiї, з якою повинен починатися сеанс роботи з файлом) серед iнших параметрiв указувався режим роботи (читання або змiна). Якщо до моменту виконання цiєї операцiї деяким призначеним для користувача процесом PR1 файл був вже вiдкритий iншим процесом PR2 в режимi змiни, то залежно вiд особливостей системи процесу PR1 або повiдомлялося про неможливiсть вiдкриття файлу, або вiн блокувався до тих пiр, поки в процесi PR2 не виконувалася операцiя закриття файлу.
При подiбному способi органiзацiї одночасна робота декiлькох користувачiв, пов'язана з модифiкацiєю даних у файлi, або взагалi не реалiзовувалася, або була дуже сповiльнена.
згодом Системами Управлiння Базами Даних (СУБД), а самi сховища iнформацiї, якi працювали пiд управлiнням даних систем, називалися базами або банками даних (БД i БНД).
Перший етап - бази даних на великих ЕОМ
Історiя розвитку СУБД налiчує бiльше 30 рокiв. У 1968 роцi була введена в експлуатацiю перша промислова СУБД система IMS фiрми IBM. У 1975 роцi з'явився перший стандарт асоцiацiї по мовах систем обробки даних — Conference of Data System Languages (CODASYL), який визначив ряд фундаментальних понять в теорiї систем баз даних, якi i до цих пiр є основоположними для мережевої моделi даних.
моделi i реляцiйної алгебри престижну премiю Тюрiнга Американської асоцiацiї по обчислювальнiй технiцi.
Менше двох десяткiв рокiв пройшли з цiєї митi, але стрiмкий розвиток обчислювальної технiки, змiна її принциповiй ролi в життя суспiльства, бум персональних ЕОМ, що обрушився, i, нарештi, появу могутнiх робочих станцiй i мереж ЕОМ вплинула також i на розвиток технологiї баз даних. Можна видiлити чотири етапи в розвитку даного напряму в обробцi даних. Проте необхiдно вiдмiтити, що все ж таки немає жорстких тимчасових обмежень в цих етапах: вони плавно переходять один в iншiй i навiть спiвiснують паралельно, але проте видiлення цих етапiв дозволить чiткiше охарактеризувати окремi стадiї розвитку технологiї баз даних, пiдкреслити особливостi, специфiчнi для конкретного етапу.
Packard).
Бази даних зберiгалися в зовнiшнiй пам'ятi центральної ЕОМ, користувачами цих баз даних були завдання, що запускаються в основному в пакетному режимi. Інтерактивний режим доступу забезпечувався за допомогою консольних термiналiв, якi не володiли власними обчислювальними ресурсами (процесором, зовнiшньою пам'яттю) i служили тiльки пристроями введення-виводу для центральної ЕОМ. Програми доступу до БД писалися на рiзних мовах i запускалися як звичайнi числовi програми. Могутнi операцiйнi системи забезпечували можливiсть умовно паралельного виконання всiєї безлiчi завдань. Цi системи можна було вiднести до систем розподiленого доступу, тому що база даних була централiзованою, зберiгалася на пристроях зовнiшньої пам'ятi однiєї центральної ЕОМ, а доступ до неї пiдтримувався вiд багатьох користувачiв-завдань.
Особливостi цього етапу розвитку виражаються в наступному:
Всi СУБД базуються на могутнiх мультипрограмних операцiйних системах (MVS, SVM, RTE, OSRV, RSX, UNIX), тому в основному пiдтримується робота з централiзованою базою даних в режимi розподiленого доступу.
Функцiї управлiння розподiлом ресурсiв в основному здiйснюються операцiйною системою (ОС).
Значна роль вiдводиться адмiнiструванню даних.
Проводяться серйознi роботи по обґрунтуванню i формалiзацiї реляцiйної моделi даних, i була створена перша система (System R), що реалiзовує iдеологiю реляцiйної моделi даних.
Проводяться теоретичнi роботи по оптимiзацiї запитiв i управлiнню розподiленим доступом до централiзованої БД, було введено поняття транзакцiї.
Результати наукових дослiджень вiдкрито обговорюються у пресi, йде могутнiй потiк загальнодоступних публiкацiй, що стосуються всiх аспектiв теорiї i практики баз даних, i результати теоретичних дослiджень активно упроваджуються в комерцiйнi СУБД.
Епоха персональних комп'ютерiв
Персональнi комп'ютери нестримно увiрвалися в наше життя i буквально перевернули наше уявлення про мiсце i роль обчислювальної технiки в життi суспiльства. Тепер комп'ютери стали ближчими i доступнiше кожному користувачевi. Зник благоговiйний страх рядових користувачiв перед незрозумiлими i складними мовами програмування. З'явилася безлiч програм, призначених для роботи непiдготовлених користувачiв. Цi програми були простi у використаннi i iнтуїтивно зрозумiлi: це перш за все рiзнi редактори текстiв, електроннi таблицi та iншi. Простими i зрозумiлими сталi операцiї копiювання файлiв i перенесення iнформацiї з одного комп'ютера на iншiй, роздрукування текстiв, таблиць i iнших документiв. Системнi програмiсти були вiдсунутi на другий план. Кожен користувач мiг себе вiдчути повним господарем цього могутнього i зручного пристрою, що дозволяє автоматизувати багато аспектiв дiяльностi. І, звичайно, це позначилося i на роботi з базами даних. З'явилися програми, якi називалися системами управлiння базами даних i дозволяли зберiгати значнi об'єми iнформацiї, вони мали зручний iнтерфейс для заповнення даних, вбудованi засоби для генерацiї рiзних звiтiв. Цi програми дозволяли автоматизувати багато облiкових функцiй, якi ранiше велися уручну. Постiйне зниження цiн на персональнi комп'ютери зробило їх доступними не тiльки для органiзацiй i фiрм, але i для окремих користувачiв. Комп'ютери стали iнструментом для ведення документацiї i власних облiкових функцiй. Це все зiграло як позитивну, так i негативну роль в областi розвитку баз даних. Простота, що здається, i доступнiсть персональних комп'ютерiв i їх програмного забезпечення породила безлiч дилетантiв. Цi розробники, вважаючи себе за знавцiв, почали проектувати недовговiчнi бази даних, якi не враховували багатьох особливостей об'єктiв реального миру. Багато було створено систем-одноднiвок, якi не вiдповiдали законам розвитку i взаємозв'язку реальних об'єктiв. Проте доступнiсть персональних комп'ютерiв змусила користувачiв з багатьох галузей знань, якi ранiше не застосовували обчислювальну технiку в своїй дiяльностi, звернутися до них. І попит на розвиненi зручнi програми обробки даних примушував постачальникiв програмного забезпечення поставляти все новi системи, якi прийнято називати настiльними (desktop) СУБД. Значна конкуренцiя серед постачальникiв примушувала удосконалювати цi системи, пропонуючи новi можливостi, покращуючи iнтерфейс i швидкодiю систем, знижуючи їх вартiсть. Наявнiсть на ринку великого числа СУБД, що виконують схожi функцiї, зажадало розробки методiв експорту-iмпорту даних для цих систем i вiдкриття форматiв зберiгання даних.
Але i в цей перiод з'являлися любителi, якi всупереч здоровому глузду розробляли власнi СУБД, використовуючи стандартнi мови програмування. Це був тупиковий варiант, тому що подальший розвиток показав, що перенести данi з нестандартних форматiв в новi СУБД було набагато важче, а в деяких випадках вимагало таких трудовитрат, що легше було б все розробити наново, але данi все одно треба було переносити на нову перспективнiшу СУБД. І це теж було результатом недооцiнки тих функцiй, якi повинна була виконувати СУБД.
Особливостi цього етапу наступнi:
Всi СУБД були розрахованi на створення БД в основному з монопольним доступом. І це зрозумiло. Комп'ютер персональний, вiн не був приєднаний до мережi, i база даних на нiм створювалася для роботи одного користувача. У окремих випадках передбачалася послiдовна робота декiлькох користувачiв, наприклад, спочатку оператор, який вводив бухгалтерськi документи, а потiм головбуха, який визначав проводки, вiдповiднi первинним документам.
бiльшiсть СУБД пропонували розвинений i зручний iнструментарiй для розробки готових застосувань без програмування. Інструментальне середовище складалося з готових елементiв додатку у виглядi шаблонiв екранних форм, звiтiв, етикеток (Labels), графiчних конструкторiв запитiв, якi досить просто могли бути зiбранi в єдиний комплекс.
За наявностi високорiвневих мов манiпулювання даними типу реляцiйної алгебри i SQL в настiльних СУБД пiдтримувалися низькорiвневi мови манiпулювання даними на рiвнi окремих рядкiв таблиць.
У настiльних СУБД були вiдсутнi засоби пiдтримки посилальної i структурної цiлiсностi бази даних. Цi функцiї повиннi були виконувати додатки, проте незначнiсть засобiв розробки додаткiв iнодi не дозволяла це зробити, i в цьому випадку цi функцiї повиннi були виконуватися користувачем, вимагаючи вiд нього додаткового контролю при введеннi i змiнi iнформацiї, що зберiгається в БД.
І, нарештi, остання i зараз вельми позитивна особливiсть — це порiвняно скромнi вимоги до апаратного забезпечення з боку настiльних СУБД. Цiлком працездатнi застосування, розробленi, наприклад, на Clipper, працювали на РС 286.
В принципi, їх навiть важко назвати повноцiнними СУБД. Яскравi представники цього сiмейства — дуже СУБД Dbase (DbaseIII+, DBASEIV), що широко використалися до недавнього часу, FoxPro, Clipper, Paradox.
Розподiленi бази даних
Добре вiдомо, що iсторiя розвивається по спiралi, тому пiсля процесу "персоналiзацiї" почався зворотний процес — iнтеграцiя. Множиться кiлькiсть локальних мереж, все бiльше iнформацiї передається мiж комп'ютерами, гостро встає завдання узгодженостi даних, що зберiгаються i обробляються в рiзних мiсцях, але логiчно один з одним зв'язаних, виникають завдання, пов'язанi з паралельною обробкою транзакцiй, — послiдовностей операцiй над БД, що переводять її з одного несуперечливого стану в iнший несуперечливий стан. Успiшне вирiшення цих завдань приводить до появи розподiлених баз даних, що зберiгають всi переваги настiльних СУБД i в той же час дозволяють органiзувати паралельну обробку iнформацiї i пiдтримку цiлiсностi БД.
Про структурну цiлiснiсть — допустимими є тiльки данi, представленi у виглядi стосункiв реляцiйної моделi;
Про мовну цiлiснiсть, тобто мов манiпулювання даними високого рiвня (в основному SQL);
Про посилальну цiлiснiсть, контролю за дотриманням посилальної цiлiсностi протягом всього часу функцiонування системи, i гарантiй неможливостi з боку СУБД порушити цi обмеження.
Бiльшiсть сучасних СУБД розрахованi на багато платформну архiтектуру, тобто вони можуть працювати на комп'ютерах з рiзною архiтектурою i пiд рiзними операцiйними системами, при цьому для користувачiв доступ до даних, керованих СУБД на рiзних платформах, практично невиразний.
Необхiднiсть пiдтримки багато користувацької роботи з базою даних i можливiсть децентралiзованого зберiгання даних зажадали розвитку засобiв адмiнiстрування БД з реалiзацiєю загальної концепцiї засобiв захисту даних.
Потреба в нових реалiзацiях викликала створення серйозних теоретичних праць по оптимiзацiї реалiзацiй розподiленiй БД i роботi з розподiленими транзакцiями i запитами з впровадженням отриманих результатiв в комерцiйнi СУБД.
Для того, щоб не втратити клiєнтiв, якi ранiше працювали на настiльних СУБД, практично всi сучаснi СУБД мають засоби пiдключення клiєнтських застосувань, розроблених з використанням настiльних СУБД, i засобу експорту даних з форматiв настiльних СУБД другого етапу розвитку.
i протокол ODBC (Open DataBase Connectivity), запропонований фiрмою Microsoft.
Саме до цього етапу можна вiднести початок робiт, пов'язаних з концепцiєю об'єктно-орiєнтованих БД, — ООБД. Представниками СУБД, що вiдносяться до другого етапу, можна рахувати MS Access 97 i всi сучаснi сервери баз даних Oracle7. 3,Oracle 8. 4 MS SQL6. 5, MS SQL7. 0, System 10, System 11, Informix, DB2, SQL Base i iншi сучаснi сервери баз даних, яких зараз налiчується декiлька десяткiв.
Перспективи розвитку систем управлiння базами даних
Цей етап характеризується появою нової технологiї доступу до даних — Інтернет. Основна вiдмiннiсть цього пiдходу вiд технологiї клiєнт-сервер полягає в тому, що вiдпадає необхiднiсть використання спецiалiзованого клiєнтського програмного забезпечення. Для роботи з видаленою базою даних використовується стандартний браузер Інтернету, наприклад Microsoft Internet Explorer або Netscape Navigator, i для кiнцевого користувача процес звернення до даних вiдбувається аналогiчно ковзанню по Усесвiтнiй Павутинi. При цьому вбудований в завантаженi користувачем HTML-сторiнки код, написаний зазвичай на мовi Java, Java-script, Perl i iнших, вiдстежує всi дiї користувача i транслює їх в низькорiвневi SQL-запроси до бази даних, виконуючи, таким чином, ту роботу, якiй в технологiї клiєнт-сервер займається клiєнтська програма. Зручнiсть даного пiдходу привела до того, що вiн почав використовуватися не тiльки для видаленого доступу до баз даних, але i для користувачiв локальної мережi пiдприємства. Простi завдання обробки даних, не пов'язанi з складними алгоритмами, що вимагають узгодженої змiни даних в багатьох взаємозв'язаних об'єктах, досить просто i ефективно можуть бути побудованi по данiй архiтектурi. В цьому випадку для пiдключення нового користувача до можливостi використовувати дане завдання не потрiбна установка додаткового клiєнтського програмного забезпечення. Проте алгоритмiчно складнi завдання рекомендується реалiзовувати в архiтектурi "клiєнт-сервер" з розробкою спецiального клiєнтського програмного забезпечення.
У кожного з вище перелiчених пiдходiв до роботи з даними є свої достоїнства i свої недолiки, якi i визначають сферу застосування того або iншого методу, i в даний час всi пiдходи широко використовуються.
1960-тi рр. розробка перших БД. CODASYL — мережева модель даних та одночасно незалежна розробка iєрархiчної БД фiрмою North American Rockwell, яка пiзнiше узята за основу IMS — власної розробки IBM.
1970-тi рр. наукове обґрунтування Едгаром Ф. Коддом основ реляцiйної моделi, котра на качану зацiкавила лише науковi кола. Вперше цю модель було використано у БД Ingres (Берклi) та System R(IBM), що булi лише дослiдними прототипами, анонсованими протягом 1976 долi.
1980-тi рр. поява перших комерцiйних версiй реляцiйних БД Oracle та DB2. Реляцiйнi БД починають успiшно витiсняти мережевi та iєрархiчнi. Дослiдження децентралiзованих (розподiлених) систем БД, проте сморiд не вiдiграють особливої ролi на ринку БД.
2000-нi рр. головним нововведенням є пiдтримка та застосування XML у БД. Розробники комерцiйних БД, якi панували на ринку у 1990-их рр., отримують все бiльшу конкуренцiю зi сторони руху вiдкритого програмного забезпечення. Реакцiєю на це стає поява безкоштовних версiй комерцiйних БД.
|
