Стаття введення в бази даних

Введення в Бази даних

Деякий час тому ми з Громом обговорили ряд цікавих, на наш погляд, напрямків інформатики, які чомусь досі не отримали висвітлення на форумі. Одне з таких напрямків Системи Управління Базами Даних (СУБД).
Оскільки відкривати порожню тему не хотілося б, почати вирішили з статей, які проливають світло на цей предмет. Перша з них (і, сподіваюся, не остання) пропонується на суд Новомосковсктелей.
З приводу стилю викладу зауважу наступне. Я не ставив перед собою завдання зробити миттєвий знімок поточного стану СУБД. Замість цього була зроблена спроба показати коротку передісторію розвитку методів і засобів обробки даних, яка в результаті призвела до появи СУБД. Найчастіше зрозуміти, чому предмет саме такий, набагато простіше, простеживши його еволюцію. Тому на початку наведено невеликий історичний огляд подій, кожне з яких, на мій погляд, зіграло свою роль, нехай і побічно, в появі СУБД. По-перше, на мій погляд, це просто цікаво. По-друге, СУБД виникли не на порожньому місці. Їх поява неминучий результат вирішення завдань, які змінювалися разом з обчислювальними машинами.
Заздалегідь прошу вибачення у тих, хто вважатиме статтю стомлюючої і малоінформативною. У мої плани не входило написання короткої енциклопедичної статті (гадаю, в них і так не бракує). Швидше це узагальнення процесу, частина якого протікала на моїх очах.
Частина викладеного матеріалу заснована на моєму особистому досвіді і почерпнутих з цього досвіду судженнях (думаю, далеко не бездоганних). Тому буду радий будь-якої конструктивної критики, доповнень і виправлень (по суті питання).

З давніх часів перед людством стояли завдання, які вимагали дедалі більших обсягів обчислень. Природно, з часом більшість з них знаходило рішення. Ще в античні часи деякі області математики були настільки розвинені, що освічена людина тих років за рівнем знань навряд чи поступався нинішньому випускнику школи.
Поява власності на землю зажадало визначення способів обчислення площі ділянок, що привело до зародження геометрії. Досягнення Евкліда, Піфагора та інших грецьких вчених в цьому напрямку загальновідомі.
Розвиток торгівлі також ставило все нові завдання. Крім обліку товарів і грошових сум, з'явилися і більш складні проблеми. Купцям доводилося робити все більш далекі подорожі, а для цього потрібні були кошти навігації. Астрономи давнину на подив майстерно справлялися і з цим завданням. Природно, все в кінцевому підсумку зводилося до розрахунків, і чим точніше вони були, тим успішніше вирішувалися нагальні завдання.
Не секрет, що обчислювальні здатності більшості з нас досить обмежені. Навіть скласти в розумі вартість декількох дрібних покупок і підрахувати суму здачі не так вже просто, а вже про розрахунок орбіти планети або координат зірки і говорити не доводиться. Тому поряд з розвитком теорії кращі уми билися і над проблемою автоматизації обчислень. Але тут, на жаль, прогрес йшов набагато повільніше.
Більше тисячі років єдиним помічником людини в обчисленнях були різні різновиди рахунок. Мало змінившись, дійшли вони і до нашого часу.
Геніальні Паскаль, Лейбніц, Беббідж і інші намагалися побудувати автоматичні машини для обчислень. На жаль, техніка того часу дозволяла будувати тільки механічні пристрої. Механічні рахункові машини були занадто повільні, дороги і ненадійні для масового застосування, тому особливого поширення не отримали. Винятком, мабуть, став старий добрий арифмометр на прізвисько Залізний Фелікс, який не так давно ще вірою і правдою служив конторським службовцем. Але і він став доступний відносно недавно (промислове виробництво арифмометрів було розпочато в 1822 р).
Спроби використовувати електричні вузли в рахункових машинах зробили їх більш досконалий, і спеціалізовані електромеханічні пристрої мали успіх в деяких випадках (наприклад, табулятори Холлерита для обробки статистичних даних вельми успішно застосовувалися при перепису населення США).
Але все ж дійсно універсальні автоматичні обчислювальні пристрої комп'ютери вдалося створити тільки на основі електронних вузлів. Для їх появи були потрібні дві основні умови: наявність відповідної елементної бази та концепція зберігається програми. І те, і інше з'явилося тільки в 40-х роках XX століття.

Перші застосування перших комп'ютерів.

Більшість робіт з розробки комп'ютерів вироблялося на замовлення військових і на їхні гроші. Природно, що і в числі завдань, що вирішуються на перших комп'ютерах, превалювали розрахунки для військових, а саме: розрахунки таблиць для розрахунку наведення далекобійних знарядь, траєкторій ракет, моделювання ланцюгових реакцій ядерного розпаду, аеродинамічні розрахунки і т.п.
Накладали свої обмеження на характер вирішуваних завдань і архітектурні особливості комп'ютерів тих років: якщо лампові схеми давали щодо високу швидкодію (десятки-сотні тисяч операцій в секунду), то запам'ятовують пристрої мали вкрай невисоку ємність в одиниці-десятки кілослов і обмежена швидкодія. Робилися вони або на ртутних лініях затримки (мізерна ємність), або на електронно-променевих трубках (більш висока ємність при високій ціні близько 1.000 доларів і малої надійності термін служби близько місяця, що надзвичайно здорожувало використання комп'ютерів з великим об'ємом оперативної пам'яті).
Характеристики периферійних пристроїв теж не вражали уяву. Досить популярні були низькошвидкісні перфокарточная і перфоленточние пристрої введення / виводу. Були також накопичувачі на магнітній стрічці і магнітних барабанах. Всі ці носії інформації, виключаючи останній варіант, робили можливої ​​послідовну обробку даних, але були непридатні для вибірки їх в довільному порядку. Магнітні ж барабани мали занадто малу ємність, хоча і забезпечували довільний доступ до даних.

Поява комерційних комп'ютерів.

Організація даних на зовнішніх носіях.

Нечисельна обробка даних зажадала приділити більше уваги структурування інформації, що зберігається. Еволюція структурування даних виглядала приблизно так.

Системи управління базами даних (СКБД)

Недоліки, властиві традиційним файлів, стримували подальший розвиток інформаційних систем. Виникла потреба в інструментальних засобах, більш адекватних важливість справ. Такими засобами з'явилися СУБД.
У створенні СУБД брало участь багато фірм, відомих і не дуже. Кожен виробник мав власну точку зору на те, яким повинен бути ідеальний продукт. В результаті виникло безліч СУБД, нічого спільного не мали один з одним. У міру використання СУБД одні ідеї отримували розвиток, запозичувалися один у одного, інші, навпаки, відмирали.
Досить швидко виявилося, що, незважаючи на зовнішні відмінності між системами, переважна більшість з них можна віднести до трьох видів: ієрархічним, мережевим і реляційних СУБД. Розглянемо коротко особливості кожного з видів.

В основі ієрархічних СУБД лежить досить проста модель даних, яку можна уявити собі у вигляді дерева ациклического орієнтованого графа особливого виду.
Дерево складається з вершин, кожна з яких, крім однієї, має єдину батьківську вершину і кілька (в тому числі жодної) дочірніх.
Вершина, яка не має батьківської, називається коренем дерева. Вершини, які не мають дочірніх, називаються листям. Решта вершини є гілками.
Ієрархічні бази даних найбільш придатні для моделювання структур, за своєю природою є ієрархічними. Як приклади можна привести військові підрозділи або складні механізми, що складаються з більш простих вузлів, які в свою чергу теж можна піддати декомпозиції.
Проте існує значна кількість структур, які не зводяться до простої ієрархії. Наприклад, всім відоме генеалогічне дерево, яке насправді не є деревом в строгому сенсі, оскільки у більшості людей по два батька. Про більш складних структурах і говорити не доводиться.
Ієрархічні СУБД швидко пройшли пік популярності, яка обумовлювалася їх простотою у використанні і ранньою появою на ринку, коли основні конкуренти ще не дозріли для комерційного використання. Потім їх численні недоліки зробили їх неконкурентоспроможними, і в даний час ієрархічна модель представляє виключно історичний інтерес.

Реляційні СУБД є зараз найпоширенішими. Їх реалізації існують на всіх мало-мальськи придатних для цього платформах (від персональних комп'ютерів до мейнфреймів), для всіх операційних систем і для всіх застосувань від найпростіших продуктів, призначених для ведення картотек індивідуального користування, до найскладніших розподілених багатокористувацьких систем.
Незважаючи на таке строкате розмаїття, всі ці СУБД мають в основі загальну основу реляційну модель даних, розроблену Коддом в 70-х роках XX століття. На вигляд ця модель досить проста: база даних виглядає як простий набір взаємозв'язаних таблиць. Але за зовнішньою простотою криється потужний і в той же час витончений математичний апарат реляційної алгебри, яка в свою чергу базується на цілому ряді математичних дисциплін, серед яких логіка, обчислення предикатів, теорія множин
Чималу роль в успіху реляційних СУБД відіграє також мову SQL, розроблений спеціально для запитів до реляційних БД. Це досить простий і в той же час виразний мову, за допомогою якого можна виконувати досить витончені запити до бази.

Зрозуміло, що передують СУБД також мали мови опису даних (МОД) і мови маніпулювання даними (ЯМД). SQL об'єднав в собі обидві ці функції. Але найпривабливішою його особливістю, особливо для користувачів-непрофесіоналів в програмуванні, є те, що можна будувати запити на основі непроцедурного підмножини SQL. Це означає, що у формулюванні запиту вказується, що повинно міститися в результаті, а не як його отримати. Є, правда, і процедурні елементи мови, наприклад, оператори організації розгалуження і циклів, але їх застосування часто вдається уникнути. При роботі ж з мережевими БД програміст був змушений використовувати навігаційні процедури, відволікаючись при цьому від рішення самого завдання.

Даний огляд був задуманий як вступна частина невеликого циклу статей, присвяченого сучасним СУБД і їх програмування. Він ні в якій мері не претендує на повноту і / або глибину дослідження питання, його єдина мета дати Новомосковсктелю уявлення про те, чому реляційні СУБД домінують на сьогоднішній день в інформаційних системах, і про еволюційний шлях, який їм довелося пройти.
Подальші статті, якщо їм судилося побачити світ, будуть присвячені окремим аспектам реляційних баз даних.