Система за управление на бази данни (СУБД): класификация, дефиниция и функции

Данните винаги са структура и съдържание, синтаксис и семантика. В контекста на базите данни това са таблици, връзки между таблици, заявки и техните резултати. Не може да се каже, че основната идея релационни бази данни

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

Основна функционалност на СУБД

Базите данни ви позволяват да представяте набори от данни чрез система от таблици, да указвате връзките между таблиците, да определяте необходимите запитвания, формата на желаните резултати и да предоставяте две възможности за работа:

• се промени;
• само за четене.

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

Форматът, протоколът и общият алгоритъм за използване на базата данни са винаги известни, въпреки че съществуващата система за класификация на DBMS показва голямо разнообразие от концепции и възможности за внедряване.

Концепции на системите за управление на данните

Основната концепция, която, разбира се, е лидер от момента на раждане и се подобрява до днес, е основата за проектирането на системи за управление на бази данни - отношения на отношенията. Базата данни представлява набор от таблици и връзки между тях. Беше така, така е, но няма да е твърде дълго.

Други модели с данни:

• йерархична;
• мрежи;
• ER-модел (същност-комуникация);
• обектно-ориентирана;
• обектно-релационни и др.

Те имат свои собствени ниши, но във всяка от тях лъжат основните относителни отношения. Всъщност различните понятия на данните, организирани в системите за данни, са безспорно очевидни: всички данни винаги имат смисъл.

Как да отразим значението в официалния модел на компютърна база данни? Ако се съди по няколко имена на модели на бази данни, специален проблем не е тук, но все пак "чисти релационни отношения" са най-много, че нито е практическо приложение на това как се нарича задачата за обработка на решение, какво прилагателно да се прилага за името на своята база данни - това няма значение, важно е, че проблемът се решава.

Класификация на системите за управление на данните

Най-основната категория, която има важно практическо значение: приложимостта на системата за решаване на проблема. Тук можете да разделите всички СУБД в четири основни групи:

• модел на данните;
• разпределение;
• начини на достъп;
• ниво на универсалност.

Това е обща класификация на съвременните СУБД.

Концепцията за разпространението е важна, въпреки че от семантична гледна точка няма значение как се разпространява базата данни, важно е тя да има правилния вариант за достъп.

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

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

Функционалност на DBMS

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

Функционалността на задачата и очакваното решение могат да определят ясни изисквания. По-специално, изборът на СУБД (класификация по данни):

• представяне на данни (видео, аудио, текст, различни комбинации);
• структуриране / формализация (структурирана, неструктурирана);
• характер / източник (йерархична, релационна, мрежа);
• формат и място за съхранение (локално, разпределено);
• (един, много).

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

Големи СУБД и комплексни връзки

Съвременното ниво на информация за СУБД (класификация по значение и отговорност):

• Терабайтови данни (един голям файл, много малки файлове);
• мегабайти (няколко файла, описващи една база данни и съдържащите се в нея данни).

Но важността и отговорността тук винаги са чудесни не само в първия случай. Има много отговорни проекти, когато малка част от информацията е отговорна за вземането на отговорни решения.

Обикновено първият критерий се определя като безусловен лидер на Oracle, а вторият - MySQL. Те имат много общо, но много от кардиналните различия. Когато възникне проблем при свързването на уеб ресурс към базата данни на Oracle, без да се използват собствени инструменти и технологии, възникват много въпроси. Едно сложно свързване не е необичайно, често е само условие за постигане на решение.

По-малкото проблеми с доставянето на данни възникват, когато се намират в локална мрежа на MS SQL Server, към която връзката е достъпна чрез няколко хардуерни рутера.

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

Сигурност на достъпа и съхранението на данни

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

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

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

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

• има смисъл да се използва (е безопасно, надеждно, винаги налично);
• не може да се използва (всичко е контролирано от разработчика на СУБД).

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

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

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

Социален аспект на СУБД

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

Когато имаше локални мрежи и бази данни, разположени на сървъра, а DBMS осигуриха достъп на много потребители, всичко беше изключително просто: архитектурата на файловия сървър е много практична, днес има:

• файлов сървър;
• клиент-сървър;
• вградена база данни.

Три страни от една и съща монета. Няма значение къде е базата данни, не е важно кой DBMS е избран. Важно е, че данни и код, те се използват, трябва да е мобилен и на разположение, но не напускат периметъра на общата сигурност под строг защита не само на технологичните фактори (атаки, заплахи, разрушителна за смущения), но от поведението точка по отношение на персонала, които разработват кода или използват данните.

Релационни отношения: перспективи

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

Релационната концепция все още има силни позиции и никоя друга архитектура или идея няма да допусне нищо. Но това е толкова вярно за нейната история: таблицата е връзката между данните, а връзката между таблиците също е връзка? Защо трябва да има заглавие в таблицата и ако няма данни, няма таблица? Защо таблицата винаги е правоъгълна, а данните в нея са строго тип и размер?

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

Ако приложите абстракция, към който толкова дълго е модерен обектно-ориентираното програмиране, релационни отношения, се оказва много обещаващо следващата стъпка: в базата данни, в която има значение на масата, или просто да се има предвид, но ако таблицата е, това, което ще бъде и дали линията там или колони и как те ще бъдат взаимосвързани на неговото ниво - въпросът за приложението. Всичко е свързано с всички данни и таблици - също въпрос на обхвата на приложение, а не от компетентността на разработчика на вземане на базата данни или кода го използва.