База данни

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

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

Система за управление на бази данни е компютърно приложение (софтуер) създадено за комуникация между потребителя, други приложения, както и други БД, с цел да се сравнят и анализират данни. Общото специфично предназначение на СУБД е да позволи определянето, създаването, заявки, актуализацията и администрирането на бази данни. Добре известни СУБД включват MySQL, PostgreSQL, Microsoft SQL Server, Oracle, Sybase, SAP HANA, и IBM DB2. Бази данни не са съвместими с различните СУБД, за това различните СУБД работят със стандартни като SQL и ODBC или JDBC, за да позволи на всяко приложение да работи с различни СУБД, а така и с различни БД. Управлението на БД често се избира от модела им, които те подкрепят. Най-използвани системи от бази данни от 1980 г. насам са всички поддържани релационния модели на езика SQL. Често срещано е СУБД да се нарича само „база данни“.

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

Поради тясната връзка между тях, терминът „база данни“ често се използва за наименование и на двете – „база данни“ и „система за управление на база данни“, използвана за управлението ѝ.

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

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

Дефиниране на данни – Създаване, модифициране и премахване на дефинициите, които определят организацията на данните.
Промяна – Вмъкване, модификация и заличаване на актуалните данни.
Извличане – Предоставяне на информация във формата на пряко използваем или за по-нататъшна обработка от други приложения. Извлечените данни могат да се предоставят направо в същата форма, в която са били съхранени в базата данни или в нова форма, получена чрез промяна или комбиниране на съществуващи данни от базата данни.
Администриране – Регистриране и наблюдение на потребителите, налагане на сигурността на данните, наблюдение на изпълнението, запазвайки целостта на данните, които се занимават с едновременния контрол и възстановяване на информацията, която е била повредена от някакво събитие като например неочакван срив на системата.

И двете – базата данни и нейната система за управление съответстват на принципите на определен модел на базата данни. „Система база данни“ се отнася общо за модел на база данни, система за управление на база данни както и база данни.

Физически сървърите на базите данни са специализирани компютри, които притежават най-актуалните бази данни и работят само на СУБД и съответния софтуер. Сървърите на базите данни обикновено са многопроцесорни компютри с огромни памети и RAID дискови масиви, използвани за стабилно съхранение. RAID се използва за възстановяване на данни в случай, че един или повече хард дискове спрат да работят. Хардуер ускорителите за бази данни, свързани с един или повече сървъри чрез канал с висока скорост, се използват също в среди за обработка на трансакции с голям обем. Системите за управление на бази данни се намират в основата на повечето приложения за бази данни. СУБД могат да бъдат изградени около потребителско мултитаскинг ядро с вградена мрежова поддръжка, но модерните СУБД обикновено разчитат на стандартна операционна система за предоставяне на тези функции от бази данни преди началото на Structured Query Language(SQL). Възстановените дата бяха коренно различни, съкратени и хаотични, тъй като не е имало правилен метод за взимане и организиране в здрава структура.

Тъй като СУБД включват значителен икономически пазар, продавачите на компютри и системи за съхранение често вземат предвид изискванията на СУБД в техните планове за развитие.

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

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

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

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

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

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

Двата главни ранни модела на навигационни данни са йерархичният модел, олицетворен от IMS системата на IBM, и моделът CODASYL (мрежови модел), приложен в много продукти като IDMS.

Релационният модел, първо предложен през 1970 от Едгар Ф. Код, който се отделя от традицията си като настоява, че апликациите трябва да търсят данни по тяхното съдържание, а не чрез следване на връзки. Релационния модел използва таблици, всяка използвана за различен тип единица. Чак в средата на осемдесетте хардуерът става достатъчно мощен за да позволи широката употреба на релационни системи (СУБД плюс апликации). В началото на деветдесетте, релационните системи доминират всички широкомащабни приложения за обработка на данни и до 2015 г. те остават доминиращи. IBM DB2, Oracle, MySQL, и Microsoft SQL Server са доминиращите СУБД. Доминиращият програмен език за базите данни, стандартизиран SQL за релационния модел, е повлиял на езиците на базите данни за други модели бази данни.

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

Следващото поколение пост-релационни бази данни в края на 2000-те става известно като NoSQL бази данни, като представя бързо съхранение по клавишна стойност и документно-ориентирани бази данни. Състезаващо се „следващо поколение“ познато като NewSQL бази данни опитват нови имплементации които следват релационен/SQL модел докато се стремят да отговарят на високата продуктивност на NoSQL в сравнение с комерсиално достъпните релационни СУБД.

60-те години на XX век, навигационни СУБД

Представянето на термина база данни съвпада с възможността за директен достъп до паметта (дискове и барабани) от средата на шейсетте години. Терминът представлява контраст с лентово-базираните системи в миналото, като позволява споделена интерактивна употреба, вместо дневна пакетна обработка на масив от данни. Оксфордският английски речник цитира доклад на Корпорацията за системно развитие от 1962 г. като първият, който използва термина „база данни“ в специфично технически смисъл.

Докато компютрите израстват в скорост и възможности се появяват много бази данни с общо предназначение; до средата на шейсетте години доста от тях вече са с търговско предназначение. Интересът започва да расте и Чарлс Бакман, автор на такъв продукт, Интегрирано хранилище за данни (Integrated Data Store), основава „Database Task Group“ в CODASYL, групата отговорна за създаването и стандартизацията на COBOL. През 1971 г. Database Task Group представя стандарта си, който най-общо става познат като „CODASYL подход“ и скоро множество търговски продукти, базирани на този продукт стъпват на пазара.

CODASYL подходът разчита на „ръчното“ управление на свързани данни, които са формирани в голяма мрежа. Апликациите могат да намерят записи по един от трите метода:

Употребата на главен код (познат като CALC код, типично имплементиран от хеширане)
Управление на връзки (наречени сетове) от един запис към друг
Преглеждане на всички записи в последователен ред

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

IBM също представят своя СУБД през 1966, позната като Information Management System (IMS). IMS е софтуер, разработен за програмата Аполо на System/360. IMS като цяло е сходен като понятие с CODASYL, но използва стриктна йерархия за моделът си на управление на данни, вместо мрежовият модел на CODASYL. По-късно и двете системи стават известни като навигационни бази данни, поради начинът на достъп до данните, и презентацията на Бакман, с която през 1973 печели награда Туринг, се казва Програмистът като навигатор. IMS се класифицира като йерархична база данни. IDMS и Syncom System’s TOTAL се класифицират като мрежови бази данни. IMS все още е в употреба.

70-те години на XX век, релационни СУБД

Едгар Код работи в IBM в Сан Хосе, Калифорния, в един от техните клонове, който предимно е свързан с развитието на хард дискови системи. Той не е бил доволен с навигационния модел на CODASYL модела, и по-специално с липсата на „търсене“. През 1970 г. той написва серия трудове, които очертават нов начин на конструиране на базите данни, които впоследствие кулминират в Релационен Модел На Данни За Големи Споделени Хранилища на Данни.

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

Релационният модел също така позволява на съдържанието на базата данни да се развива без да има нужда постоянно да се пренаписват връзките и указателите. Релационната част идва от това, че обекти се свързват с други обекти чрез връзки, които се наричат едно-към-много, като модел за управление (мрежа). По този начин релационният модел може да показва и йерархичен и навигационен модел, както и естествения табуларен модел, като позволява чисто или съставно моделиране в рамките на тези три модела, както изисква апликацията.

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

Свързването на информацията обратно е ключа при тази система. В релационния модел, някакъв бит от информацията се използва като „ключ“, като тя показва към уникален запис. Когато се събира информация за потребител, информацията, която се съхранява в незадължителните таблици ще бъде намерена като се търси за този ключ. Например, името за вход в системата на потребител е уникално, адресите и телефонните номера на този потребител ще бъдат съхранени с името му като техен ключ. Това просто „ре-свързване“ на данни обратно в колекция е нещо, което традиционните програмни езици не могат да правят.

Точно както навигационните системи биха изисквали от програмите да повтарят едно и също действие за да събират записи, релационният модел ще изисква от тях да повтарят действие за да търсят информация за специфичен запис. Решението на Код за необходимото повтарящо се действие бил език, базиран на множества, предложение, което по-късно ще роди повсеместният SQL. Използвайки клон на математиката, известен като Релационен Калкулус, той демонстрира, че такъв тип система може да поддържа всички операции на нормалните бази данни (прибавяне, променяне и т.н.) както и да осигури проста система за намиране и връщане на множества от данни чрез една операция.

В Бъркли, Юджин Уонг и Майкъл Стоунбрейкър обръщат внимание на труда на Код. Те започват да развиват проект, познат като INGRES като използват финансиране, което вече е разпределено за проект с географска база данни. Започвайки през 1973 г. INGRES представя първите си тестови продукти, които като цяло са готови за повсеместно разпространение през 1979 г. INGRES е близка до System R по много неща, включително употребата на „език“ за достъп до данните, познат като QUEL. Във времето, INGRES започва да използва развиващия се SQL стандарт.

IBM също правят тестова имплементация на релационния модел, PRTV, както и продукционен такъв, Business System 12, и двете към момента са спрени. Honeywell написват MRDS за Multics, и има две нови приложения: Alphora Dataphor и Rel. Повечето други СУБД приложения, обикновено наречени релационни всъщност са SQL СУБД.

През седемдесетте години, Университетът в Мичиган започва развитието на MICRO Information Management System. MICRO се използва за управление на много големи множества от данни на Министерството на труда на САЩ, Агенцията за защита на околната среда на САЩ, изследователи от Университета на Алберта, университета в Мичиган, щатския университет Уейн. Системата остава в действие до 1998 г.

Интегриран подход

През 1970-те и 1980-те се правят опити да се конструират бази данни с интегриран хардуер и софтуер. Философията зад тях е, че такава интеграция ще осигури по-висока производителност на по-ниска цена. Примери за това са System/38 на IBM, ранната версия на Teradata, и машината за бази данни на Britton Lee, Inc.

Друг подход към поддръжката на хардуер за управление на бази данни е CAFS ускорителя на ICL, контролер на хардуерен диск с възможности за търсене, които могат да се програмират. В дългосрочен план, тези усилия са неуспешни като цяло, защото специализираните машини за бази данни не могат да догонят бързото развитие и прогрес на компютрите с общо предназначение. Така повечето системи бази данни в днешни дни са софтуерни системи, които работят на хардуер с общо предназначение, използвайки хранилища за данни на компютри с общо предназначение. Въпреки това тази идея все още се следва за някои апликации от компании като Netezza и Oracle (Exdata).

Късната част на 70-те на XX век, SQL СУБД

IBM започна работа по прототипна система вдъхновени от концепциите на Codd за System R от по ранните години на 1970-те. Първата и версия е била готова 1974/5 година и след това всяка система е започнала да работи с множество таблици, при които данните могат да се разделят така, че всички данни от крайния резултат (някои от които не са задължителни) не трябва да се съхраняват в едно голямо „парче“ памет. Следващи многопотребителски версии са тествани от клиенти през 1978 г. и 1979 г., по което време стандартизиран език за заявки – SQL – е бил добавени. Идеята на Codd е била да създадат приложима и превъзхождаща CODASYL системата, като по този начин те подбутват IBM да развият истинска продуктивна версия на System R, позната по късно като SQL/DS или Database 2/База данни 2 (DB2/БД2).

Системата Oracle на Лари Елисън, която е започнала от съвсем различна посока, но базирана на документацията за System R на IBM, побеждава на пазара IBM, когато пуска първата си версия от 1987 г.

Stonebreaker продължил да използва наученото от INGRES за разработването на нови база данни, наречени Postgres, които вече са познати като PostgreSQL. Те са били използвани предимно за глобално важни приложения (.org и .info домейн регистрите го използват като основна база данни, както и много големи компании и финансови институции).

В Швеция в средата на 1970-те в Университета в Упсала, по документациите на Codd за база данни, е била създадена и Mimer SQL. През 1984 г. този проект е консолидиран от независимо предприятие. И така в ранните години на 1980-те, Mimer въвежда по-добър трансфер на данни и така създава по-висока устойчивост на приложенията, идея която впоследствие се реализира от повечето други СУБД.

Друг модел за база данни, моделът на потребителския интерфейс, се появява през 1976 г. и печели популярност за проектиране на база данни, тъй като подчертава по-добре като описание данните, отколкото по-ранния релационния модел. По-късно конструкцията на потребителския интерфейс се допълва към конструкцията на моделираните данни за релационния модел и разликите между двата модела вече са станали без значение.

80-те, версии за настолни компютри

1980 г. е годината, в която официално се въвеждат настолните компютри. Те дават възможност на своите потребители да работят с електронни таблици като Lotus 1-2-3 и софтуер за база данни като dBASE. Базата данни dBASE е лека и лесно разбираема от всеки потребител. Уейн Ратлиф (C. Wayne Ratliff) създателят на dBASE заявява: „dBASE е различна от програмите като BASIC, C, FORTRAN и COBOL. В нея много от „мръсната“ работа е свършена. Манипулирането на данните се извършва от dBASE, вместо от потребителя и така той може да се концентрира върху това, което иска да направи, а не да се налага да извършва трудните манипулации по отваряне, четене и затваряне на файлове и заделяне на пространство за тези файлове, с които много често се получават обърквания и грешки“. dBase е един от най-продаваните софтуери от 1980 г. до началото на 1990 г.

1990 обектно ориентиране

През 1990 г. заедно с появата на обектно-ориентираното програмиране видяхме растеж в това как се промени и работата с различни бази данни. Програмисти и дизайнери започват да използват данните в техните бази данни като обекти. Така вече може да се каже, че ако данните на едно лице са били в база данни, атрибутите на това лице, като адрес, телефонен номер и възраст вече се счита, че принадлежат към този човек (обект), вместо да са външни данни в таблици. Това дава възможност за отношенията между данните да бъдат отношения на обектите и техните атрибути, а не на отделните полета на таблици от бази данни. Терминът „обектно-релационна импеданс разминаване“, описва неудобството на обмяна на данни между обекти в програмирането и таблиците от бази данни. Обектни бази данни и обектно-релационни бази данни са опит да се разреши този проблем чрез осигуряване на обектно-ориентиран език (понякога като разширения на SQL), така че програмистите да могат да го използват като алтернатива на чистия релационен език SQL. От страна на програмирането, библиотеки известни като обектно-релационно насочени (ORMs) са опит за решаване на същия проблем.

2000 г., NoSQL и NewSQL

XML бази данни са вид от структурирана документна база данни, която позволява заявки въз основа на атрибути на XML документи. Тя се използват най-често в компании, където XML е стандарт за оперативна съвместимост на данни тип машина-към-машина. Системата за управление на база данни XML, използва софтуери като MarkLogic и Oracle Berkeley DB XML, както и безплатният софтуер Clusterpoint Distributed XML/JSON Database. Всички те са корпоративни софтуерни платформи за бази данни и използват промишлен стандарт ACID за обработка на трансакции на данни, с преобладаващо използване от база данни и високото ниво на сигурност.

NoSQL бази данни често са много бързи, не изискват фиксирани схеми от таблици, избягват съвместни операции по съхраняване на денормализирани данни и са предназначени за хоризонтално мащабиране (хоризонтално мащабиране е когато се добавят повече сървъри или компютри към една база данни, докато вертикалните е да се добавя атрибути към тези сървъри). Най-популярните NoSQL системи включват MongoDB, Couchbase, Riak, Memcached, Redis, CouchDB, Hazelcast, Apache Cassandra и HBase, които са продукти с отворен код.

През последните години е имало голямо търсене на масово разпределящи бази данни, които работят предимно между дялове в системата, но според теоремата за СНД (Съвместимост на Наличните Дялове) не е възможно една разпределена на дялове система да гарантира едновременно последователност, достъпност и толерантност на дяловете. Такава система може да гарантира едновременно само две от условията, но не и трите. Поради тази причина много бази данни NoSQL използват това, което се нарича Евентуална Последователност, за да осигурят гарантирано достъпност и толеранс между дяловете, с намалено ниво на съдържание от данни.

NewSQL е клас от съвременните релационни бази данни, които има за цел да осигури същото мащабиране като на NoSQL системите за обработка на онлайн трансакции (четене и запис), докато все още използва SQL и поддържане на гаранциите на ACID за традиционна система за база данни. Такива бази данни включват ScaleBase, Clustrix, EnterpriseDB, MemSQL, NuoDB и VoltDB.

Технологията на бази данни е активна изследователска тема още от 1960 г. както в академичните среди, така и научноизследователските и развойни групи на компаниите (например IBM Research). Изследователската дейност включва теория и развиване на прототипи. Забележителните изследователски теми включват модели, концепция за атомна трансакция и свързаните с тях техники за контрол на едновременност, езици за заявки и методи за оптимизиране на заявки, RAID и други.

Областта на научните изследвания на базите данни има няколко специализирани научни списания (например, ACM Transactions on Database Systems-TODS, Data and Knowledge Engineering-DKE) и годишни конференции (например ACMSIGMOD, ACM PODS, VLDB, IEEE ICDE).

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

База данни с вътрешна паметта е такава намираща се в основната памет, но обикновено е подпомагана и от друга неучастваща памет. Базите данни с основната памет са по-бързи от дисковите бази данни и за това често се използват, където времето за реакция е от решаващо значение, като и в оборудването на телекомуникационни мрежа. SAP HANA платформата е най-използвана за бази данни във вътрешната памет. До май 2012 г. HANA е в състояние да се стартира по сървърите със 100TB основната памет снабдявани от IBM. Основателят на компанията заявява, че системата е достатъчно голяма, за да може да стартира 8-те от най-големите клиенти на SAP.
Активна база данни включва в себе си архитектура от събития, която може да отговаря на условия зададени както от вътрешната част на базата данни, така и от външна. Такава може да се използва за наблюдение за сигурност, алармиране, събиране на статистики и разрешение за достъп. Много бази данни предоставят активни функции за тях под формата на събития, които при изпълнение изпълняват дадена функция (примерно при достигане на нов рекорд и базата данни записва дадените рекорди в предназначеното за това място).
„Облачни“ бази данни, разчитат на интернет технологията за базите данни тип „облак“. Тези бази данни и повечето от техните СУБД се използват дистанционно, „в облака“, докато неговите приложения са разработени от програмисти и по-късно поддържани и използвани от (чрез приложения) крайните потребители през уеб браузър и Oтворени API.
Складови бази данни архивират данните от оперативни бази данни често от външни източници, като например проучващи пазара фирми. Складовите бази данни се превръщат в основен източник на данни използвани от мениджъри на фирми, както и крайни потребители, които нямат достъп до оперативните им данни. Например, данните за продажбите може да бъдат обобщени с ежеседмични суми и превърнати във вътрешен продуктов код (баркод), за да може да се сравнява с данни от агенцията ACNielsen, проучваща маркетинговия пазар в САЩ. Някои основни и съществени компоненти за съхраняване на данни включват извличане, анализиране, „разбиване“ на данните, трансформиране, зареждане и управление на данните, така че да ги направят достъпни за по-нататъшна употреба.
Дедуктивна база данни комбинира логиката на програмиране с релационна база данни, например като се използва езика за писане Datalog.
Разпределена база данни е такава, в която и данните и СУБД са разпределени между много компютри.
Документно ориентирана база данни е предназначена за съхранение, извличане и управление на документно ориентирана или полуструктурирана информация. Документно ориентирани бази данни са една от основните категории на NoSQL бази данни.
Вградена система от база данни е СУБД, която е тясно интегрирана със софтуерно приложение, което изисква достъп до съхраняваните данни по такъв начин, че СУБД е скрит от крайния потребител на приложението и изисква малка или никаква текущата поддръжка.
Крайно потребителска база данни се състои от данни, създадени и управлявани от индивидуални крайни потребители. Примери за това са колекции от документи, електронни таблици, презентации, мултимедия и други файлове. Няколко продукти съществуват за да поддържат такива бази данни. Някои от тях са много по-просто, отколкото пълноправни СУБД, с по-елементарна функционалност на СУБД.
Обединена система от бази данни се състои от няколко отделни бази данни, всяка със своите СУБД. Тя се състои от една база данни, състояща се от множество обединени СУБД, които могат да бъдат различни типове и ги предоставя с един интегриран концептуален интерфейс.
Понякога терминът „множествена база данни“ се използва като синоним на обединена база данни, макар че той може да се отнася до по-малко интегрирана (например без СУБД) група от бази данни, които си сътрудничат в едно приложение. В този случай междинният интеграционен софтуер се използва за разпределение.
Графична база данни е от вид NoSQL база данни, които използват графична структура с разклонения, въздействия и свойства, за да предостави и съхрани информация. Главната графична база данни, която може да съхрани всяка графика е различна от специфичните графични бази данни, като triplestores и базите данни от мрежата.
Масив от СУБД е вид NoSQL СУБД, която позволява да се моделира, съхранява и извлича (обикновено големи) многомерни масиви като сателитни снимки и симулация на климатични времена.
Хипертекстова или хипермедийна бази данни са, такива бази данни където всяка дума или част от текст представлява обект, например друга част от текст, статия, снимка или филм, които са хипервръзка към този обект. Хипертекстовите бази данни са особено полезни за организиране на големи количества от разнородния информация. Например, те са полезни за организиране на онлайн енциклопедии, където потребителите могат удобно да използват хипервръзките за да прескачат между страници в интернет, а не да ги търсят ръчно. По този начин World Wide Web(www) е една голяма хипертекстова база данни.
Научна база данни (съкращение НБД, нбд или ?) е специален вид база данни за управление на информация, като предоставя средства за компютризирано събиране, организиране и извличане на знания. Също така предоставя колекция от данни, свързани с проблеми и техните решения, както и свързаният с тях опит.
Мобилна база данни – те могат да бъдат обработвани или синхронизирани от мобилни изчислителни устройства.
Оперативна база данни съхранява подробни данни за дейността на дадена организация. Те обикновено обработва сравнително високи обеми от актуализации с помощта трансакции. Например клиентските бази данни, които съдържат контакти, кредити и демографска информация за даден бизнес клиент, данни на персонал, който съдържа информация, като заплати, бонуси, данни за умения за служителите, системи за планиране на ресурсите на предприятието, които записват информация за продукти, както и финансови бази данни, които да следят финансите на дадена организация, сделки между акаунти и други финансови сделки.

Паралелна база данни имат за цел да се подобри ефективността чрез паралелизация на задачи като зареждане на данни, изграждане на индекси и оценяването на заявки. Главни паралелни СУБД архитектури, които са включени в базовите хардуерни архитектури са:
- Общата архитектурна памет, където множество процесори споделят една основна памет, както други съхранени данни.
- Споделена дискова архитектура, където всеки процесор (обикновено състоящ се от множество процесори) има своя собствена памет, но всички процесори споделят помежду си съхранените данни.
- Несподеляща архитектура, където всеки процесор има свое основна памет и съхранените данни на останалите.

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

Първата задача пред един дизайнер на бази данни е да произведе концептуален модел на данните, който отразява структурата на информацията, която ще се проведе в базата данни. Един общ подход към това е да се разработи модел на обектни взаимовръзки, често с помощта на инструменти за рисуване. Друг популярен подход е Unified Modeling Language. Един успешен модел на данните акуратно ще отрази възможното състояние на външния свят, който е обект на моделирането: например ако хората могат да имат повече от един телефонен номер моделът ще позволи на тази информация да бъде съхранена. Проектирането на добър концептуален модел на данните изисква добро разбиране на областта на приложение; обикновено е свързано със задаването на сериозни въпроси за нещата, които представляват интерес за дадена организация, като например „може ли клиентът да бъде едновременно и доставчик?“ или „ако даден продукт се продава с два различни вида опаковки, това един и същ продукт ли е или различни продукти?“ или „ако самолет лети от Ню Йорк до Дубай през Франкфурт, това един полет ли е или два (или може би дори три)?“. Отговорите на тези въпроси създават дефиниции на терминологията, използвана за обектите (клиенти, продукти, полети, самолетни сегменти) и техните взаимовръзки и атрибути.

Производството на концептуалния модел на данни понякога включва входни данни от бизнес процесите или анализи на работния процес в организацията. Това може да помогне да се установи каква точно информация е необходима в базата данни и кое е ненужно. Например може да помогне в решаването дали базата данни трябва да съдържа исторически данни освен актуалните данни.

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

Най-популярният модел на база данни с общо предназначение е релационният модел или по-точно казано релационният модел, представен чрез езика SQL. Процесът на създаване на логически дизайн на база данни, с помощта на този модел, използва методичен подход, известен като нормализиране. Целта на нормализирането е да гарантира, че всеки елементарен „факт“ е записан само на едно място, така че вмъкването, обновяването и изтриването на данни автоматично да поддържа съответствието на системата.

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

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

Модели

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

Често срещаните логически модели на данни за бази данни включват:

Навигационни бази данни
- Йерархични бази данни
- Мрежов модел
- Графична база данни
Релационен модел
Модел на обектните взаимовръзки
- Засилен модел на обектните взаимовръзки
Обектен модел
Документен модел
Модел обект-атрибут-стойност
Схема звезда

Обектно-взаимосвързаните бази данни комбинират двете свързани структури.

Физическият модел на данните включва:

Обърнат индекс
Плосък файл

Други модели включват:

Асоциативен модел
Многомерен модел
Модел масив
Многостойностен модел

Специализираните модели са оптимизирани за частни видове данни:

XML база данни
Семантичен модел
Съхраняване на съдържанието
Съхраняване на събитията
Модел на динамичния ред

Външен, концептуален и вътрешен изглед

Системата за управление на дадена база данни осигурява три гледни точки на данните в базата:

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

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

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

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

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

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

Разделянето на външни, концептуални и вътрешни нива е една от главните характеристики на имплементирането на релационния модел на бази данни, който доминира в XXI век.

Езиците за бази данни са езици със специално предназначение, които правят едно или повече от следните неща:

Data definition language – дефинира типове данни и връзките между тях
Data manipulation language – изпълнява задачи като вмъкване, актуализиране или изтриване на дадени данни.
Query language – позволява търсенето на информация и информация, получена чрез изчисляване

Езиците за бази данни са специфични за определен модел на данни. По-известните примери включват:

SQL съчетава ролите на определение на данни, манипулиране на данни, както и заявка на определен език. Това е един от първите комерсиални езици за релационния модел, въпреки че се отклонява в някои отношения от релационния модел като описания от Codd (например редовете и колоните на таблицата могат да бъдат подредени). SQL стана стандарт на Американския национален институт по стандартизация (ANSI) през 1986 г. и на Международната организация по стандартизация (ISO) през 1987. Стандартите са били редовно подобрявани оттогава и се поддържат (с различна степен на съответствие) от всички основни комерсиални релационни Системи за управление на бази данни.

OQL е езиков стандарт за обектен модел (от Object Data Management Group). Той е повлиял на дизайна на някои от по-новите езици за заявки като JDOQL и EJB QL.
XQuery е стандартен XML език за заявки имплементиран от XML системи за бази данни като например MarkLogic и eXist, чрез релационни бази данни с XML способности като Oracle и DB2, а също и от XML процесори като Saxon.
SQL/XML комбинира XQuery със SQL.

Даден език за бази данни може също да включва свойства като:

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

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

Съхранение

Основна статия: Оперативна памет

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

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

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

Резултатни база данни обекти

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

Копиране на база данни

Понякога базата използва повече памет при копирането на обектите си (с едно или повече копия), за да се подобри достъпността (общо за подобряване на бързодействието от едновременния многократен достъп на крайния потребител до един и същ база данни обект, и за подобряване на устойчивостта в случай на частично прекъсване на съответната база данни). Актуализацията на копирания обект е необходимо да бъде синхронизирана през копията на обекта. В много случаи цялата база се копира.

Сигурност

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

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

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

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

Промяната и достъпът до записите са свързани с атрибутите: какво е променено и кога е променено. Услугите за записите при достъп дават възможност за съдебна проверка на базата данни на по-късен етап, запазвайки информация за събитията на достъп и промяна. Понякога се използва приложение за запаметяване на промените, повече отколкото това да се върши от самата база данни. Може да бъде направен мониторинг, за откриване на нарушения на сигурността.

Трансакции и синхронизиране

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

Акронимът АСИД описва някои идеални свойства на база данни трансакцията: Всеобхватност, Последователност, Независимост и Стабилност.

Миграция

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

Създаване, поддръжка и оптимизация

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

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

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

Архивиране и възстановяване

Основна статия: Архивиране

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

Статичен анализ

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

Други

Други характеристики на СУБД може да включват:

База данни записи

Графични компоненти за създаване на графики и таблици, особено в системата за съхранение на данни

Оптимизатор на заявките – извършва оптимизация на заявката за всяка заявка като избира най-ефективният план за заявка (частична подредба (дървовидна) от операции), който да се изпълни, за да се изчисли резултатът от заявката. Могат да бъдат специфични за даден сървър.

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

Съществуват няколко вида БД.

Йерархични бази от данни

Основна статия: Йерархични бази от данни

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

Йерархичния модел организира информацията като структурира повтарящите се групи в нея. Йерархичната БД се състои от подредено множество последователности или по-точно от множество екземпляри на един и същи тип дърво. Зависимите една от друга поредици от данни се разглеждат като самостоятелни единици. Използването им става чрез търсещ ключ на по-горно ниво.

Самата концепция за БД възниква през 60-те години с реализацията на IMS, продукт на IBM, осигуряващ управлението на данни организирани в йерархии.

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

Основна статия: Мрежови бази от данни

Мрежовият модел на базите от данни е измислен от Чарлс Бейчман. През 1973 г. той получава награда на Тюринг за него.

Мрежовият модел е възникнал като мярка за справяне с проблемите на йерархичния модел. Той предоставя възможност за установяване на връзки от тип 1-N между различните нива на йерархията. Връзките могат да съществуват без никакви ограничения. За да се открият определени данни в база организирана по този начин е необходимо да се познава целия път на достъп до тях. Поради тази причина информационните системи използващи мрежови бази са зависими от структурата на данните в тях.

Релационни бази от данни

Основна статия: Релационни бази от данни

(Релационни идва от английски Relation – връзка, зависимост)

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

От 80-те години насам, тази идея се развила и била приета в индустрията. През 1987 г. езикът за заявки към БД, SQL, е стандартизиран. В днешно време релационният модел е най-масово използваният в системите за управление на бази от данни.

Обектно ориентирани бази от данни

Обектно – ориентираните бази от данни (OODB) съхраняват обекти. Тези обекти могат да бъдат лесно намирани и споделени.

OODB осигуряват възможност за съхраняване на сложни типове от данни като изображения, аудио, видео, текст и др., без да е необходимо те да се трансформират в сложни структури от данни за да бъдат съхранени в БД.

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

„Database – Definition of database by Merriam-Webster“.merriam-webster.com.
„Update – Definition of update by Merriam-Webster“.merriam-webster.com.
„Retrieval – Definition of retrieval by Merriam-Webster“.merriam-webster.com.
„Administration – Definition of administration by Merriam-Webster“. merriam-webster.com.
„TOPDB Top Database index“. pypl.github.io.
„database, n“. OED Online. Oxford University Press. Юни 2013. Посетен на 12 юли 2013.
IBM Corporation. IBM Information Management System (IMS) 13 Transaction and Database Servers delivers high performance and low total cost of ownership. Посетен на 20 февруари 2014.
MICRO Information Management System (Version 5.0) Reference Manual, M.A. Kahn, D.L. Rumelhart, and B.L. Bronson, Institute of Labor and Industrial Relations (ILIR), University of Michigan and Wayne State University.
Interview with Wayne Ratliff. The FoxPro History. Посетен на 12 юли 2013.
Development of an object-oriented DBMS; Portland, Oregon, United States; Pages: 472 – 482; 1986; ISBN 0-89791-204-7
„Oracle Berkeley DB XML“ (PDF). Посетен на 10 март 2015.
„ACID Transactions, MarkLogic“. Посетен на 10 март 2015.
„Clusterpoint Database at a Glance“. Посетен на 10 март 2015.
„DB-Engines Ranking“. Януари 2013. Посетен на 22 януари 2013.
„TeleCommunication Systems Signs up as a Reseller of TimesTen; Mobile Operators and Carriers Gain Real-Time Platform for Location-Based Services“. Business Wire. 2002-06-24.
Graves, Steve. COTS Databases For Embedded Systems, Embedded Computing Design magazine, Януари 2007. Посетен на 13 август 2008.
Argumentation in Artificial Intelligence by Iyad Rahwan, Guillermo R. Simari
„OWL DL Semantics“. Посетен на 10 декември 2010.
itl.nist.gov (1993) Integration Definition for Information Modeling (IDEFIX). 21 декември 1993

Bachman, Charles W. (1973). The Programmer as Navigator.Communications of the ACM 16 (11): 653 – 658.doi:10.1145/355611.362534.
Beynon–Davies, Paul (2003). Database Systems (3rd ed.). Palgrave Macmillan. ISBN 978-1403916013
Chapple, Mike (2005). SQL Fundamentals.Databases. About.com. Архивирано от оригинала на 22 февруари 2009. Посетен на 28 януари 2009
Childs, David L. (1968). Description of a set-theoretic data structure. CONCOMP (Research in Conversational Use of Computers) Project. Technical Report 3. University of Michigan.
Childs, David L. (1968). "Feasibility of a set-theoretic data structure : a general structure based on a reconstituted definition" (PDF).CONCOMP (Research in Conversational Use of Computers) Project. Technical Report 6. University of Michigan
Chong, Raul F.; Wang, Xiaomei; Dang, Michael; Snow, Dwaine R. (2007). Introduction to DB2. Understanding DB2: Learning Visually with Examples (2nd ed.). ISBN 978-0131580183. Посетен на 17 март 2013
Codd, Edgar F. (1970). A Relational Model of Data for Large Shared Data Banks Communications of the ACM 13 (6): 377 – 387.
Date, C. J. (2003). An Introduction to Database Systems (8th ed.). Pearson. ISBN 978-0321197849.
Halder, Raju; Cortesi, Agostino. Abstract Interpretation of Database Query Languages COMPUTER LANGUAGES, SYSTEMS & STRUCTURES (Elsevier) 38 (2): 123 – 157.doi:10.1016/j.cl.2011.10.004. ISSN 1477 – 8424
Hershey, William; Easthope, Carol (1972). A set theoretic data structure and retrieval language. Spring Joint Computer Conference, Май 1972. ACM SIGIR Forum 7 (4). pp. 45 – 55.doi:10.1145/1095495.1095500.
Nelson, Anne Fulcher; Nelson, William Harris Morehead (2001).Building Electronic Commerce: With Web Database Constructions. Prentice Hall. ISBN 978-0201741308.
North, Ken. Sets, Data Models and Data Independence. Dr. Dobb's. Архивирано от оригинала на 24 октомври 2010.
Proctor, Seth. Exploring the Architecture of the NuoDB Database, Part 1. 12 юли 2013. Архивирано от оригинала на 15 юли 2013. Посетен на 12 юли 2013.
Tsitchizris, Dionysios C.; Lochovsky, Fred H. (1982). Data Models. Prentice–Hall. ISBN 978-0131964280
Ullman, Jeffrey; Widom, Jennifer (1997). A First Course in Database Systems. Prentice–Hall. ISBN 0138613370
Wagner, Michael (2010), SQL/XML:2006 – Evaluierung der Standardkonformität ausgewählter Datenbanksysteme, Diplomica Verlag, ISBN 978-3836696098