Системи за управление на релационни бази данни: преглед на базите данни, примери

Система за управление на релационни бази данни СУБД по същество не е нищо повече от компютъризирана система, която ви позволява да съхранявате данни. Потребителите имат възможност да извършват няколко вида операции с данните в базата данни или да управляват нейната структура. СУБД се класифицират според структурата.

История на развитието

RDBMS релационната база данни е изобретена в началото на 70-те години на миналия век от E. Ф. Код, млад софтуерен учен от IBM. В специална статия, посветена на СУБД, той предлага да се премине от съхраняване на данни в йерархични структури към организирането им в таблици с редове и колони.

През 60-те години на миналия век в новите мейнфрейм компютри в света, много от които бяха IBM System 360, се съхраняваше огромно количество данни. Това беше проблем за по-нататъшното развитие на цифровите технологии. Изчисленията на мейнфрейм компютрите бяха скъпи, често струваха стотици долари на минута. Значителна част от тези разходи са свързани със сложността на управлението на база данни (БД).

През 1973 г. лабораторията в Сан Хосе, сега Алмаден, започва да разработва програма, наречена System R (релационна), за прилагане на теорията на релациите чрез т.нар. промишлена реализация. Това качество се е превърнало в определящо за това кои СУБД се наричат релационни. Резултатът беше революционна нова система за съхранение, един от крайъгълните камъни на успеха на IBM.

Дон Чембърлин и Рей Бойс изобретяват SQL за структурирани данни, който се използва най-широко днес. Патриша Селинджър е разработила оптимизатор, базиран на разходите, който прави работата с релационни бази данни по-рентабилна и ефективна. Реймънд Лори изобретява компилатор, който запазва процедури за заявки към бази данни за бъдеща употреба.

През 1983 г. IBM представи второто си семейство релационни бази данни DB2 за управление на данни. Днес DB2 все още генерира милиарди транзакции всеки ден, което го прави най-успешният софтуерен продукт на IBM. Според Арвинд Кришна, генерален мениджър на IBM Information Management, DB2 продължава да бъде лидер в иновативния софтуер за релационни бази данни (RDBMS).

Д-р Код, известен на колегите си като Тед, получава стипендия на IBM през 1976 г., а през 1981 г. му е присъдена наградата "Тюринг" на Асоциацията за компютърни машини за приноса му в разработването на СУБД.

Принципи на създаване

Всяка таблица, наричана също връзка в релационна база данни на СУБД, съдържа една или повече категории данни в атрибутни колони. Всеки ред се нарича запис или кортеж и съдържа уникална инстанция на данни или ключ за категориите, зададени от колоните. Таблицата има уникален първичен ключ, който идентифицира информацията в нея. Връзката между таблиците се установява чрез използване на чужди ключове, които се позовават на първичните ключове на друга таблица.

Например типична релационна база данни RDBMS за бизнес поръчки има таблица, която описва клиента, с колони за име, адрес, телефонен номер и друга информация. Следващата поръчка е: продукт, клиент, дата, продажна цена и т.н. Потребителят на RDB получава изглед на базата данни според своите нужди. Например мениджър на клон може да желае да прегледа или отчете всички клиенти, които са закупили стоки след определена дата. Специалистът по финансови услуги в същото дружество получава отчет за фактурите, които трябва да бъдат платени, от същите таблици.

Условия и видове

Релационните СУБД включват таблици, които съдържат редове и колони. Когато създавате RDB, определяте област от възможни стойности в колона с данни и допълнителни ограничения, които могат да се прилагат към тази стойност. Например един клиентски домейн може да позволява до 10 възможни имена, но можете да го ограничите само до три от тези клиентски имена в една таблица. Две ограничения са свързани с целостта на данните и с първичните и външните ключове. Целостта на обекта гарантира, че първичният ключ е уникален и че стойността му не е нула. Референциалната цялост изисква всяка стойност в колона с чужд ключ да се намира в първичния ключ на таблицата, от която произхожда.

Съществуват редица категории бази данни, вариращи от обикновени плоски файлове, които не са свързани с NoSQL, до по-нови графични бази данни, които се считат за още по-релационни от стандартните бази данни. Базата данни с плосък файл се състои от една таблица, която няма връзки, обикновено текстови файлове. Тя позволява на потребителите да определят атрибути на данни, като колони и типове, в релационни СУБД.

Алтернативни структури

NoSQL базата данни е алтернатива на RDBMS, която е особено полезна да работите с с големи разпределени масиви от данни.

Графовата база данни надхвърля традиционните модели на релационни данни, базирани на колони и редове. NoSQL има възли и ребра, които представят връзките между отношенията на данните и откриват нови връзки между тях. Базите данни, базирани на графики, са по-сложни от СУБД и затова тяхното използване включва механизми за откриване на измами или уеб препоръки.

Примери за релационни СУБД

SQLite е популярна SQL база данни с отворен код. Той може да съхранява цялата база данни в един файл. Най-важното предимство, което предоставя, е, че всички данни могат да се съхраняват локално, без да се свързват със сървър. SQLite стана популярен като база данни в мобилни телефони, PDA, MP3 плейъри, декодери и други електронни джаджи.

MySQL е друга популярна SQL релационна СУБД с отворен код. Обикновено се прилага за уеб приложения и често се използва с PHP. Основните му предимства са лесната употреба, достъпността и надеждността. Някои от недостатъците му са, че страда от ниска производителност при увеличаване на мащаба, че разработката с отворен код изостава, откакто Oracle пое контрола над MySQL, и че не включва някои разширени функции.

PostgreSQL е модел на релационна база данни SQL с отворен код, който не се контролира от нито една корпорация. Обикновено се използва за разработване на уеб приложения. PostgreSQL е проста, надеждна и достъпна, с голяма общност от разработчици. Има допълнителни функции под формата на поддръжка на чужди ключове, които не изискват сложна конфигурация. Основният ѝ недостатък е, че е по-бавна от други бази данни, като например MySQL. Освен това тя е по-малко популярна от MySQL, което затруднява хостовете или доставчиците на услуги, които предлагат управляеми екземпляри на PostgreSQL.

Система за управление на RDBMS

СУБД е система за управление на релационни бази данни, разработена от EF Codd от IBM, която може да създава, модифицира и администрира СУБД. Много от съществуващите днес бази данни са продължение на този стар модел. Съхранените данни се обработват с помощта на релационни оператори в СУБД.

SQL се използва като език за заявки към бази данни - това е логическа група данни. Тя съдържа набор от свързани таблици и индексни пространства. Базата данни обикновено съдържа всички данни, свързани с едно приложение или свързана група. Може да бъде например база данни за заплати или инвентар.

Разликата между СУБД и обикновена СУБД

СУБД съхранява данни като файлове, докато СУБД съхранява данни като таблица. СУБД ви позволява да нормализирате данните, но СУБД запазва връзката между данните, съхранявани в нейните таблици. Конвенционалната СУБД не осигурява връзка. Той просто съхранява данните на своя файл. СУБД има структуриран подход, който поддържа разпределена СУБД, за разлика от конвенционалната система за управление на бази данни. СУБД е насочена към широк спектър от приложения, като функциите ѝ позволяват да се използва в цял свят.

Характеристики на СУБД:

1. Във функциите на СУБД е включена обща реализация на колони, както и многопотребителски достъп.
2. Потенциалът на този модел на релационна СУБД е повече от оправдан от днешните приложения.
3. По-добра сигурност се осигурява чрез създаването на таблици.
4. Някои таблици могат да бъдат защитени от системата.
5. Потребителите могат да задават бариери за достъп до съдържанието. Това е много полезно в компании, където мениджърът може да решава какви данни да споделя със служителите и клиентите. По този начин може да се установи индивидуално ниво на защита на данните.
6. Осигуряване на бъдещи изисквания, тъй като нови данни могат лесно да се добавят към съществуващите таблици и да се съгласуват с наличното преди това съдържание. Това е функция, която не е налична в никоя друга база данни с плосък файл.

Таблица на структурата

Таблицата е логическа структура, състояща се от редове и колони. Редовете нямат фиксиран ред, така че при извличане на данни може да се наложи те да бъдат сортирани. Редът на колоните се задава, когато администраторът на базата данни създава таблицата. В пресечната точка на всяка колона и ред се намира специфичен елемент от данни, наречен стойност, или по-точно атомна стойност. Името на дадена таблица се дава чрез класификатор от високо ниво на потребителския идентификатор на собственика, последван от името на таблицата, например TEST.DEPT или PROD.DEPT.

Съществуват няколко вида таблици:

1. Basic, който се създава и съдържа постоянни данни.
2. Временно, където се съхраняват междинните резултати от заявката.

Елементи на таблицата:

1. Колоните имат подреден набор: DEPTNO, DEPTNAME, MGR и ADMK DEPT. Всички те трябва да са от един и същи тип данни.
2. Редове - всеки съдържа данни за един отдел.
3. Стойности в пресечната точка на колоната и реда. Например PLANNING е стойността на колоната DEPT NAME в реда за отдел B01.

Индексът е подреден набор от указатели към редовете на дадена таблица. За разлика от редовете на таблицата, които не са в определен ред, индексът на DB2 трябва винаги да поддържа ред.

Индексът се използва за две цели:

1. Подобряване на скоростта на извличане на стойностите на данните.
2. За уникалност.

Чрез създаване на индекс по име на служител можете да извличате данни за този служител по-бързо, отколкото чрез сканиране на цялата таблица. Освен това, създавайки я, DB2 ще гарантира, че всяка стойност е уникална. Създаването на индекс автоматично създава индексно пространство, набор от данни, който го съдържа.

Първични ключове

Ключ е една или няколко колони, идентифицирани като такива, когато се създават в дефиницията за референтна цялост. Една таблица има само един първичен ключ, тъй като тя дефинира същност. Има изисквания за това:

1. Тя трябва да има стойност, т.е. да не е нулева.
2. Тя трябва да има уникален индекс.
3. В една таблица може да има повече от един уникален ключ.
4. Чужд ключ е външен ключ, посочен в ограничението за референтна цялост, така че съществуването му зависи от първичен или родителски ключ.

Моделът на мрежовата база данни

Тази база данни позволява записите да имат множество родителски и дъщерни формати, като могат да се визуализират като мрежова структура. За разлика от тях йерархичният елемент на релационна СУБД има няколко деца и един родител. Мрежовият модел всъщност е много подобен на йерархичния модел, тъй като е негово подмножество. Вместо да използва един родител, мрежовият модел използва теорията на множествата, за да осигури йерархия, подобна на дърво. Изключението е, че подчинените таблици могат да имат повече от един родител.

Предимства на мрежовата база данни:

1. Концептуално прости и лесни за разработване.
2. Достъпът до данни е по-прост и по-гъвкав по отношение на йерархичния модел и не позволява съществуването на член без родител.
3. Може да обработва сложни данни благодарение на връзката "много към много". Това позволява по-естествено моделиране на връзките между записите или обектите в релационна СУБД, за разлика от йерархичната.
4. Благодарение на гъвкавостта му е по-лесно да се навигира и да се намира информация в мрежовата база данни.
5. Тази структура изолира програмите за управление от сложните физически данни.

Обектно-ориентирана система

В обектно-ориентираната база данни всички данни са обекти. Те могат да бъдат свързани помежду си чрез връзката "е част от", за да представят по-големите съставни елементи.

Например данни, описващи превозно средство, могат да се съхраняват като съставна Част от определен двигател, шаси, скоростна кутия, кормилна уредба и т.н.". Класовете на обектите могат да образуват йерархия, в която отделните обекти наследяват свойства от. Например всички обекти от клас "моторно превозно средство" ще имат двигател (камион, автомобил или самолет). По подобен начин двигателите също са обекти за данни, а атрибутът на двигателя на даден превозно средство Ще бъде препратка към конкретен обект на двигателя.

Мултимедийни бази данни, които съхраняват глас, музика и видео заедно с традиционната текстова информация, служат като основа за разглеждане на данните като обекти. като например обектно-ориентирани бази данни стават все по-важни, тъй като тяхната структура е най-гъвкавата и адаптивна. Същото важи и за бази данни с изображения, снимки или карти. Бъдещето на технологиите за бази данни обикновено се вижда като интеграция на релационни и обектно-ориентирани модели.

Процесът на проектиране

Проектирането на бази данни е по-скоро изкуство, отколкото наука, така че като потребител ще трябва да се вземат много решения. Базите данни обикновено са персонализирани за конкретно приложение. Няма две еднакви потребителски приложения и следователно няма две еднакви бази данни. В насоките обикновено се посочва какво не трябва да се прави, въпреки че изборът в крайна сметка зависи от дизайнера.

Алгоритъм за проектиране:

1. Определяне на предназначението на базата данни за анализ на изискванията.
2. Събиране на изисквания. Събиране на данни, организиране на таблици и определяне на първични ключове.
3. Изберете една или повече колони като така наречения първичен ключ за идентифициране на редове.
4. Създаване на връзка между таблици. Силата на релационната база данни се крие във връзката между таблиците. Най-важният аспект при разработването на СУБД е да се определят връзките между тях.
5. Избиране на необходимия тип данни за определена колона. Обикновено типовете данни съдържат: цели числа, низ (или текст), дата, час, двоичен код, колекция, напр. изброяване и набор.
6. Усъвършенстване на дизайна чрез добавяне на повече колони.
7. Създаване на нова таблица за незадължителни данни, като се използва връзка едно към едно.
8. Разделяне на голяма таблица на две по-малки таблици.
9. Прилагане на правила за нормализация, за да се провери дали базата данни е структурно стабилна и оптимална.
10. Индексът може да бъде дефиниран за една колона, за набор от колони, наречен съставен индекс, или за част от колона, наречена частичен индекс. В една таблица може да се създаде повече от един индекс. Например, ако често търсите клиент, като използвате името на клиента или телефонния номер, можете да ускорите търсенето, като създадете индекс въз основа на колоната "Име на клиента" и телефонния номер.
11. Повечето бази данни автоматично изграждат индекс въз основа на първичния ключ.

Създаване на база данни Access

Когато използвате релационната база данни на Access, не можете просто да започнете процес на въвеждане на данни. Необходимо е да се приложи дизайн на СУБД чрез разделяне на информационен блок на поредица от таблици. Те се свързват с помощта на релационни съюзи, когато полето на една таблица съвпада с полето на друга таблица.

Алгоритъм за създаване на БД:

1. Предварително дефиниране на данните и съставяне на списък Желани полета (части от информация), използващи различни типове данни.
2. Премахване на ненужните полета. Не съхранявайте една и съща информация на повече от едно място. в случай на Когато можете да Изчисляване на едно поле с помощта на друго, запазване на едно.
3. Организиране на полетата. Оформете ги според описанието им, така че всяка група да се превърне в таблица.
4. Добавяне на кодови таблици със съкращения.
5. Включване на таблица с имена и двубуквени кодове в базата данни.
6. Изберете първичния ключ.
7. Таблици за връзки.

По този начин може да се обобщи, че основните предимства на СУБД са, че те позволяват на потребителите просто да класифицират и съхраняват данни, лесно се разширяват и не зависят от физическата организация. След като бъде създадена първоначалната база данни, може да се добави нова категория данни, без да се променят всички съществуващи приложения.