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

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

Основна функционалност на базата данни

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

само за четене.

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

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

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


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

йерархична;

мрежа;

ER-модел (същност - комуникация);

обектно-ориентирани;

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

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

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

модел на данни;

разклоняване;

режими на достъп;

ниво на универсалност.

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

Функционалност на СУБД

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

представяне на данни (видео, аудио, текст, различни комбинации);

структуриране /формализиране (структурирано, неструктурирано);

природа /източник (йерархична, релационна, мрежова);

формат и място за съхранение (местно, разпределено);

потребители (една, много).

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

Големи бази данни и комплексно свързване

Текущото ниво на информационна база данни (класификация по значимост и отговорност):

терабайта информация (един голям файл, много малки файлове);

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

Но значението и отговорността тук винаги са големи, не само в първия случай. Има много отговорни проекти, в които малки количества информация вземат решения.
Обикновено първият критерий определя като абсолютен лидер на Oracle, а вторият - MySQL. Те имат много общи черти, но имат много кардинални различия. Когато става въпрос за комбиниране на уеб ресурс с база данни на Oracle без използване на собствени инструменти и технологии, има много проблеми. Трудно е да се свърже - дълго време не е необичайно и често е просто условие за постигане на решение. По-малко проблеми с доставката на данни възникват, когато те се намират в локална мрежа на сървър на MS SQL Server, към който се предлага връзка чрез няколко хардуерни маршрутизатора. Всъщност на практика всички компоненти са важни: архитектура на СУБД, класификация на СУБД по функции, гъвкавост на връзката и честотна лента на комуникационните канали.

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

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

има смисъл да се използва (безопасно, сигурно, винаги има всичко);

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

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

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

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

файлов сървър; ]

клиентски сървър;

вградена база данни.

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

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

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