Лекції на тему "Введення в теорію СУБД"
Перш ніж почати практикуватися в створенні моделей, проектуванні складної бази або в управлінні навороченій СУБД, потрібно збагатити себе хоча б мінімальними теоретичними навичками. Ще в давні часи, коли про базах даних тільки мріяли, хтось помітив, що без теорії немає практики.
ЩО ТАКЕ СУБД І З ЧИМ ЇЇ ЇДЯТЬ
Тим, хто вперше чує про базах даних, немає сенсу розповідати про моделях, свя-зях і т.п. Найперше, з чого потрібно почати розповідь, - базові визначення, за-отримавши які в свій арсенал, ти легко переварити все інше.
Потреба зберігання даних у вигляді деяких структур, тобто упорядкування ін-формації про деякі об'єкти навколишнього-ного світу, була відчутною для человечест-ва завжди. В цьому випадку під об'єктом поні-томиться або який-небудь предмет, або більш абстрактним поняттям (наприклад, процес виробництва чого-небудь).
Внесення об'єкта в базу - тільки півсправи. Його ще потрібно якось характеризувати, свя-мовити з ним певне значення. І тут потрібно ввести поняття "дане". Дане - це певний показник, що характеризують ющий об'єкт і наділяє його визначено-ним значенням. Причому не обов'язково, що-б об'єкт був визначений одним даними - їх може бути багато. Уяви, що ти маєш справу з хакерською структурою. Хакерство - це об'єкт. А ось дані - це вже хакерські ті-чення, стаж незаконної діяльності, кіль-кість написаних експлойтів і зламаний-них машин і т.п. Іншими словами, дані - це характеристики певного об'єкта. Саме це найбільше цікавить клиен-та, який звернувся до поки ще майбутньої БД.
Створити многомегабайтних файл з тоннами інформації (яка, до речі, цілком може бути надмірною) - це не вирішення пробле-ми. Людина любить комфорт, тому, щоб, наприклад, пробити інформацію на великого хакера, від клієнта потрібно надати тільки нік зломщика, і тоді вичерпну-щая інформація про кіберзлочинців стане зброєю справедливості. Організувати та-кую систему дуже непросто, пройшов не один десяток років, перш ніж окремі файли стали гідними базами даних (база даних в ini-файлі - це теж стильно - прим. Dr.). Тепер все стало набагато простіше благо-даруючи існуванню структурованих файлів - баз даних і різних моделей організації даних.
Власне, модель - це основа, на кото-рую спирається та чи інша база даних. В тій чи іншій моделі визначаються зв'язки між даними, типи даних, що вводяться, ме-тоди зберігання, управління і т.п. Зв'язок даних з прикладними програмами забезпечують-ється за допомогою СУБД або за допомогою систем управління базами даних.
Отже, СУБД - це сукупність мовних і програмних засобів, призначених для створення, ведення і спільного вико-вання БД багатьма користувачами. Іншими словами, за допомогою СУБД будь бажаю-щий (при наявності певних прав, ко-нечно) зможе звернутися до бази і дістати звідти потрібну йому інформацію.
Та чи інша СУБД залежить від моделі, ко-торая покладена в основу бази. У наш вре-мя стали найбільш поширеними дві моделі: реляційна (модель відносин) і об'єктно-орієнтована (модель об'єктивним тов). Про них і піде мова в цій статті.
Почнемо з реляційної моделі. У далекому 1969 році американський математик доктор Е.Ф. Кодд (Е.F. Codd) проаналізував сло-який жив на той час ситуацію по базах даних і прийшов до висновку, що справи кепські. У всіх були в той час моделях були суттєві недоліки: надмірність дан-них, складність обробки і відсутність без-пеки зберігання інформації і т.п. Після тяжких роздумів Кодд вирішив створити свою модель - реляционную. Для тих, хто злісно прогулював англійська, нагадаю, що relation перекладається як "відношення" або просто "таблиця". Геніальний лікар просто реалі-поклику зберігання даних в табличній формі, тобто організував такі "сховища" в ві-де логічних структур (фізичні методи зберігання можуть бути будь-якими). Тим самим Кодд зумів домогтися наочності представле-ня інформації та зручності її обробки. Завдяки досягненню цього генія для фор-мування таблиці даних стало досить виконати певний логічний запит, який підпорядковується законам булевої алгебри. Серед операторів маніпуляції даними су-ществуют мінімум три операції: вилучення рядків (SELECT), витяг стовпців (PRO-JECT) і об'єднання таблиць (JOIN). У резуль-таті цих дій ми отримуємо таблицю. І простий висновок з усього цього: результатом будь-якої операції в реляційної моделі є-ється об'єкт того ж роду, що й об'єкт, над ко-менту, котрим здійснювалося дію.
Це і є основна властивість опи-Сива моделі.
Крім базових знань, нам понад-бятся основні визначення, примі-німие до цієї моделі: тип даних, ат-рібут, кортеж, ставлення і привчає-ний ключ.
Тип даних - визначення, яке відповідає поняттю типу в мовах програмування. Іншими словами, для реляційної моделі можна отме-тить такі основні типи, як "цілі числа", "рядки", "символи", "числа з плаваючою комою", "дата" і "день-ги" (куди в наш час без грошей :)).
Атрибут - це стовпець у таблиці з даними. Наприклад, якщо на екрані є інформація про хакерські ті-ченіях, експлойтів і стаж діяль-ності, то всі ці стовпці є атрибутами.
Кортеж - рядок в таблиці з данни-ми. Таким чином, вичерпна інформація на певного хаке-ра є кортежем.
Ставлення - таблиця в цілому. Опі-сание типів даних, що застосовуються в табличці, називається заголовком відносини, а все інше (влас-но дані) - тілом відносини.
Первинний ключ - мінімальний на-бор атрибутів (стовпців), які бу-дуть визначати однозначну унікальних-ність кожного кортежу (рядка) в відно-шении (таблиці). При створенні бази слід дуже уважно поставитися до завдання первинного ключа - в нашому прикладі ника хакера буде недостаточ-но (раптом хто-небудь захоче взяти се-бе кличку свого кумира.)). Буває, що для аутентифікації вводиться до-виконавчими поле з порядковим но-мером, який буде однозначно раз-ним для кожного рядка. Але ніхто не забороняє обирати для первинного ключа два або три атрибути: все як ти побажаєш, аби ця дія б-ло логічно обгрунтованим (подібний ряд атрибутів буде називатися сос-тавной первинним ключем).
Щоб домогтися ефективного уп-ління базою, необхідно забезпе-чити зв'язаність даних. Простіше го--животворящою, потрібно вміти пов'язувати дві або більше таблиці в БД (якщо вони, конеч-но, там є). Для цього був придуманий так званий "зовнішній ключ", ко-торий є атрибут (або набір атрибутів) в одній табли-ці, що співпадає за типом з первинним ключем іншої. Але також слід соб-люду умова, згідно з яким кожне значення в стовпці одній таблетці-лиці має збігатися з будь-яким значенням в інший. Суть цього визна-ділення лови після мого роз'яснити-ня про можливі зв'язки даних.
В теорії СУБД виділяється три види зв'язків: один-до-одного, один-ко-многим і багато-до-багатьох. Розповім докладно про кожен вид.
1. Один -к-одному. Цей вид зв'язку застосовується в тому випадку, коли пер-первинних ключ однієї таблиці засилає-ся на ключ інший. Щоб було зрозуміліше, наведу приклад: припустимо, у нас є три таблиці хакерської БД. Перша - інформація про хакера: дата народження, стать (дівчата теж бувають хакерами;)) і ICQ. Друга - хакер-ські течії (тип течії, його складність ність і початкові капиталовлож-ня). Ну і третя - тип виходу в ін-тернет (технологія, швидкість доступу, оцінка безпеки). Всі ці табли-ці не можна звести в одну, так як в ре-док відсутності зв'язку між дан-ними про доступ в інтернет і про Хакерс-ких течіях (і не тільки про них) ми отримаємо плутанину. А при реалізації зв'язку у вигляді трьох різних таблиць (за допомогою первинного ключа - поряд-кового номера) забезпечується і ви-сокая швидкість обробки, і уперед-ченность даних.
2. Один - до - багатьох. Найбільш типова зв'язок. Реалізується при копіюванні первинного ключа однієї таблиці в дру-гую. В цьому випадку в другій таблиці цей ключик називається вже зовнішнім. Не зрозуміло? Тоді знову звернуся до прикладу. Візьмемо дві таблиці - з ін-формацією про хакера (таблиця "Хакери") і про відносини з характеристиками експлойтів, які він написав (таблиця "Експлойти"). По суті, вони пов'язані механізмом один-ко-многим. Действи-тельно, кожен хакер може бути авто-
ром кількох експлойтів (так часто і буває), але кожен експлойт може бути написаний одним і тільки одним ав-тором (навіть при спільній роботі в хак-групах певним експлойтів займається одна людина). Тут в якості зовнішнього ключа в таблиці "Експлойти" використовується нік хакера, а в якості первинного - назва експлойта. При цьому зовнішній ключ "нік хакера" є первинним ключиком в таблиці "Хакери", а сюди введений наме-ренно для зв'язку двох таблиць і організа-ції пошуку потрібної інформації. До речі, ставлення "Експлойти" зовсім не обо-ково буде складатися лише з одного атрибута - можна додати характерис-тики операційних систем, до яких застосовується експлойт, кількість цілей, тип (локаль-ний або віддалений) і т.п.
Ось, власне, і вся інформація про реляційної моделі. Щоб поди-тожіть цей розділ, скажу, що багато СУБД побудовані саме на її осно-ве. Я б із задоволенням розповів про булеву алгебру, на законах кото-рій заснована реляційна модель, але, на жаль, обсяги цієї статті не дозволять мені цього зробити.
А як же йдуть справи з інших-ми СУБД? До якої моделі принадле-жать вони? Насправді, крім реля-ної моделі існують і інші. Жодна з них на отримала особливого поширення, за винятком, по-даруй, об'єктно-орієнтованої, ко-торая з'явилася пізніше реляційної (тому її іноді називають Побудуй-ляціонному) і застосовується до цього дня.
Основна умова в реляційної моделі - це правило нормалізації. Всі значення таблиці повинні бути логічно неподільними, стовпці і рядки - неупорядкованими, і в відно-шении не повинно бути двох однаковий-вих кортежів. Подібна нормалізується-ція часто порушує природні ие-рархіческіе зв'язку між об'єктами, що вкрай незручно, тому розробники запропонували нову СУБД, а саме - об'єктно-орієнтовану. Суть такої парадигми в тому, що перед-Метн область згідно з нею представ-ляется у вигляді об'єктів, які сої-дінени в так звані класи. Кожен об'єкт в класі наділяється пасивними характеристиками або методами. Управління об'єктом мож-ли тільки через мають відно-шення до нього методи. Атрибути того чи іншого об'єкта можуть приймати одне з безлічі допустимих значень, а набір конкретних значень визначає поведінку об'єкта. Ба-дружність об'єктів з одним і тим же значенням атрибутів і методів визна-ділячи клас об'єкта.
Виходить, що теорія об'єктно-орієнтованої бази даних схожа на організацію будь-якого об'єктно-кричи ентірованного мови программірова-ня. Так воно і є. Будь-клас об'єк-тів може бути успадкований від дру-гого класу і може містити в собі всі його методи поряд з власними. Також дотримується правило інкапсу-ляции: міняти значення атрибутів об'єкта дозволяється тільки з по-міццю методів. І нарешті, полімор-Фізмен - це механізм перевизначення методів у успадкованого об'єкта.
Основна перевага ООБД в тому, що така база враховує поведенчес-кий аспект об'єкта, на відміну від ре-ляціонному СУБД, в якій між структурою і поведінкою є раз-рив. Правда, щоб реалізувати ООБД, будуть потрібні спеціальні мови програмування, що сильно ускладнює життя проектувальника :).
Щоб не допустити таких накладок, реляционную і об'єктно-орієнтований-ву СУБД спробували об'єднати. Яс-ве справу, що для цього треба було б розширювати стандарти і модернізує-ровать вже існуючі мови прог-раммірованія. Таким чином, великі фірми IBM і Oracle допрацювали свої СУБД додавши об'єктну надбудову над реляційним ядром системи.
Для кожної моделі БД суті ет свою мову управління. Для реля-ної моделі такою мовою є-ється SQL (Structured Query Language, або структурована мова запро-сов). Творці цієї мови стрімко-лись максимально наблизити своє дітище до людського (англійсько-му) мови і при цьому наповнити його логічним змістом.
Мова SQL істотно полегшує роботу тим, хто постійно має справу з реляційними СУБД. Строго кажучи, без цього структурованого мови багатьом нещасним довелося б пи-описати програму, наприклад, на С. Уяви: щоб повноцінно рабо тать з таблицею, спочатку необхідно створити цей об'єкт, потім запрограм-рмувати процедури звернення до неї (витяг і додавання рядків ). Для позбавлення від подібного гемор-рою розробники СУБД подбати-лись про створення мови SQL.
Все SQL-запити дуже схожі на логічні умови булевої алгебри (хто не прогулював матан, той мене зрозуміє :)). Ти сам в цьому переконаєшся, якщо подивишся на врізку з основ-ними командами мови.
Як вже було сказано, існують і інші види, крім реляційних. У част-ності, об'єктно-орієнтовані. Есте-ного, що для таких баз даних буде застосовуватися вже іншу мову запитів.
У більшості об'єктно-орієнтир-ванних баз даних існує простий графічний інтерфейс, дозволяю-щий користувачеві отримати доступ до об'єктів в навігаційному стилі. При цьому ігнорується принцип інкапсуля-ції: ніхто не заборонить тобі побачити нутрощі об'єктів безпосередньо. Але, як кажуть експерти, навігаційний стиль в ООБД - це в певному сенсі "крок назад" у порівнянні з мовами запитів в СУБД. І му-ве пошуки кращого мови зап-росів до ООБД йдуть до цих пір.
Основні мови звернень до БД все ж грунтуються на простому SQL-синтаксисі і мають свого роду розширення, яке застосовується до об'єктів. Прикладами таких мов служать ORION, Iris і O2 Reloop.
Як бачиш, не однієї реляційної-ної моделлю славиться ринок баз дан-них. У наш час розробники ста-раются розширювати свої програмні продукти різними нововведення-ми, додаючи об'єктно-орієнтований-ні надбудови в уже існуючий реляционное ядро СУБД. В доповнення до-ня до цього модифікується і мова запитів SQL. У SQL3 вже суті-ють специфічні методи для рабо-ти з ООБД, але їх реалізація поки ос-тавляет бажати кращого.
Для потреб звичайної людини (тобто тебе) цілком вистачить реляційної-них СУБД, які застосовуються повсюдно. Це і всенародно улюблений MySQL, і менш улюблений Access, і MSSQL. Подібних систем управ-ня маса, визначся і вибери ту, що тобі більше до вподоби. А зро-лать цей нелегкий вибір, як завжди, допоможе цей унікальний СПЕЦви-пуск;).
Які бувають бази даних? У більшості випадків рішення програмістів обмежуються двома типами: локальна і клієнт-серверна. У першому випадку виходить шампунь "все-в-одному". У другому ми поділяємо дані і клієнтську програму і отримуємо два рівня.
Однак вже досить давно існує ви-ділення третього рівнів-ня, і саме трехуров-невую модель все про-ходять. боячись її складності. У цій статті ми розглянемо кожну модель окремо з усіма їх переваж-ществами і недоліками.