База данни

База данни (БД, също база от данни) представлява колекция от логически свързани данни в конкретна предметна област, които са структурирани по определен начин. В първоначалния смисъл на понятието, използван в компютърната индустрия, базата от данни се състои от записи, подредени систематично, така че компютърна програма да може да извлича информация по зададени критерии. Например БД може да се използват в моделирането на хотелските системи, за да се проверява дали има налични свободни стаи в даден хотел.
Поддръжката на база от данни се осъществява от т.нар. система за управление на бази от данни (СУБД).
Система за управление на бази данни е компютърно приложение (софтуер) създадено за комуникация между потребителя, други приложения, както и други БД, с цел да се сравнят и анализират данни. Общото специфично предназначение на СУБД е да позволи определянето, създаването, заявки, актуализацията и администрирането на бази данни. Добре известни СУБД включват 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 в сравнение с комерсиално достъпните релационни СУБД.
Представянето на термина база данни съвпада с възможността за директен достъп до паметта (дискове и барабани) от средата на шейсетте години. Терминът представлява контраст с лентово-базираните системи в миналото, като позволява споделена интерактивна употреба, вместо дневна пакетна обработка на масив от данни. Оксфордският английски речник цитира доклад на Корпорацията за системно развитие от 1962 г. като първият, който използва термина „база данни“ в специфично технически смисъл.
Докато компютрите израстват в скорост и възможности се появяват много бази данни с общо предназначение; до средата на шейсетте години доста от тях вече са с търговско предназначение. Интересът започва да расте и Чарлс Бакман, автор на такъв продукт, Интегрирано хранилище за данни (Integrated Data Store), основава „Database Task Group“ в CODASYL, групата отговорна за създаването и стандартизацията на COBOL. През 1971 г. Database Task Group представя стандарта си, който най-общо става познат като „CODASYL подход“ и скоро множество търговски продукти, базирани на този продукт стъпват на пазара.
CODASYL подходът разчита на „ръчното“ управление на свързани данни, които са формирани в голяма мрежа. Апликациите могат да намерят записи по един от трите метода:
По-късно системите прибавят B-дървета, за да осигурят алтернативни пътища за достъп. Много CODASYL бази данни също прибавят много ясен език за заявки. В крайна сметка, CODASYL е много сложна и изисква значително обучение и усилие за да се развият полезни апликации.
IBM също представят своя СУБД през 1966, позната като Information Management System (IMS). IMS е софтуер, разработен за програмата Аполо на System/360. IMS като цяло е сходен като понятие с CODASYL, но използва стриктна йерархия за моделът си на управление на данни, вместо мрежовият модел на CODASYL. По-късно и двете системи стават известни като навигационни бази данни, поради начинът на достъп до данните, и презентацията на Бакман, с която през 1973 печели награда Туринг, се казва Програмистът като навигатор. IMS се класифицира като йерархична база данни. IDMS и Syncom System’s TOTAL се класифицират като мрежови бази данни. IMS все още е в употреба.
Едгар Код работи в 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).
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 г. и печели популярност за проектиране на база данни, тъй като подчертава по-добре като описание данните, отколкото по-ранния релационния модел. По-късно конструкцията на потребителския интерфейс се допълва към конструкцията на моделираните данни за релационния модел и разликите между двата модела вече са станали без значение.
1980 г. е годината, в която официално се въвеждат настолните компютри. Те дават възможност на своите потребители да работят с електронни таблици като Lotus 1-2-3 и софтуер за база данни като dBASE. Базата данни dBASE е лека и лесно разбираема от всеки потребител. Уейн Ратлиф (C. Wayne Ratliff) създателят на dBASE заявява: „dBASE е различна от програмите като BASIC, C, FORTRAN и COBOL. В нея много от „мръсната“ работа е свършена. Манипулирането на данните се извършва от dBASE, вместо от потребителя и така той може да се концентрира върху това, което иска да направи, а не да се налага да извършва трудните манипулации по отваряне, четене и затваряне на файлове и заделяне на пространство за тези файлове, с които много често се получават обърквания и грешки“. dBase е един от най-продаваните софтуери от 1980 г. до началото на 1990 г.
През 1990 г. заедно с появата на обектно-ориентираното програмиране видяхме растеж в това как се промени и работата с различни бази данни. Програмисти и дизайнери започват да използват данните в техните бази данни като обекти. Така вече може да се каже, че ако данните на едно лице са били в база данни, атрибутите на това лице, като адрес, телефонен номер и възраст вече се счита, че принадлежат към този човек (обект), вместо да са външни данни в таблици. Това дава възможност за отношенията между данните да бъдат отношения на обектите и техните атрибути, а не на отделните полета на таблици от бази данни. Терминът „обектно-релационна импеданс разминаване“, описва неудобството на обмяна на данни между обекти в програмирането и таблиците от бази данни. Обектни бази данни и обектно-релационни бази данни са опит да се разреши този проблем чрез осигуряване на обектно-ориентиран език (понякога като разширения на SQL), така че програмистите да могат да го използват като алтернатива на чистия релационен език SQL. От страна на програмирането, библиотеки известни като обектно-релационно насочени (ORMs) са опит за решаване на същия проблем.
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).
Един от начините да се класифицират бази данни включва вида на съдържанието им например: библиографска, текстови документи, статистически или мултимедийни обекти. Друг начин е чрез тяхната област на приложение например: счетоводство, музикални композиции, филми, банково дело, производство или застраховка. Третият начин е чрез някои технически аспект, като структурата от базата данни или тип интерфейс. Този раздел изброява някои от приложните бази данни, използвани за характеризиране на различни им видове.
Първата задача пред един дизайнер на бази данни е да произведе концептуален модел на данните, който отразява структурата на информацията, която ще се проведе в базата данни. Един общ подход към това е да се разработи модел на обектни взаимовръзки, често с помощта на инструменти за рисуване. Друг популярен подход е Unified Modeling Language. Един успешен модел на данните акуратно ще отрази възможното състояние на външния свят, който е обект на моделирането: например ако хората могат да имат повече от един телефонен номер моделът ще позволи на тази информация да бъде съхранена. Проектирането на добър концептуален модел на данните изисква добро разбиране на областта на приложение; обикновено е свързано със задаването на сериозни въпроси за нещата, които представляват интерес за дадена организация, като например „може ли клиентът да бъде едновременно и доставчик?“ или „ако даден продукт се продава с два различни вида опаковки, това един и същ продукт ли е или различни продукти?“ или „ако самолет лети от Ню Йорк до Дубай през Франкфурт, това един полет ли е или два (или може би дори три)?“. Отговорите на тези въпроси създават дефиниции на терминологията, използвана за обектите (клиенти, продукти, полети, самолетни сегменти) и техните взаимовръзки и атрибути.
Производството на концептуалния модел на данни понякога включва входни данни от бизнес процесите или анализи на работния процес в организацията. Това може да помогне да се установи каква точно информация е необходима в базата данни и кое е ненужно. Например може да помогне в решаването дали базата данни трябва да съдържа исторически данни освен актуалните данни.
След като е произведен концептуален модел на данните, от който потребителите са доволни, следващият етап е това да се превърне в схема, която имплементира съответните структури от данни в базата данни. Този процес често се нарича логически дизайн на база данни и на изхода имаме логически модел на данни, изразен под формата на схема. Докато концептуалния модел на данни е (поне на теория) независим от избора на технология на базата данни, то логическия модел на данните ще бъде изразен по правилата на конкретната технология на системата за управление на базата данни. (Термините модел на данните и модел на базата данни често се използват взаимозаменяемо, но в тази статия използваме модел на данните за проектирането на специфична база данни, а модел база данни за нотация в моделирането, използвана за изразяването на този дизайн.)
Най-популярният модел на база данни с общо предназначение е релационният модел или по-точно казано релационният модел, представен чрез езика SQL. Процесът на създаване на логически дизайн на база данни, с помощта на този модел, използва методичен подход, известен като нормализиране. Целта на нормализирането е да гарантира, че всеки елементарен „факт“ е записан само на едно място, така че вмъкването, обновяването и изтриването на данни автоматично да поддържа съответствието на системата.
Заключителният етап от проектирането на база данни е да се вземат решения, които се отразяват на работата, скалируемостта, възстановяването, сигурността и други такива. Това често се нарича физически дизайн на база данни. Основната цел през този етап е независимостта на данните, което означава, че решенията, взети за целите на оптимизация на производителността трябва да са невидими за крайните потребители и приложения. Физическият дизайн се дължи главно на изисквания за изпълнение и изисква добро познаване на очакваната натовареност и използваните модели, както и дълбоко познаване на функциите, предлагани от избраната система за управление на база данни.
Друг аспект от физическия дизайн на база данни е сигурността. Той включва както дефиниране на контрол за достъпа до обектите в базата данни, така и дефиниране на нивата на сигурност и методите за самите данни.
Моделът на база данни е вид модел на данните, който определя логическата структура на базата данни и фундаментално определя по какъв начин данните да се съхраняват, организират и манипулират. Най-популярният пример за модел на баз данни е релационния модел (или SQL доближаване до релационния), който използва таблично-базиран формат.
Често срещаните логически модели на данни за бази данни включват:
Обектно-взаимосвързаните бази данни комбинират двете свързани структури.
Физическият модел на данните включва:
Други модели включват:
Специализираните модели са оптимизирани за частни видове данни:
Системата за управление на дадена база данни осигурява три гледни точки на данните в базата:
Докато обикновено има само един концептуален (или логически) и физически (или вътрешен) изглед на данните може да има произволен брой различни външни изгледа. Това позволява на потребителите да виждат информацията от базата данни в един по бизнес-ориентиран начин а не от техническа и технологична гледна точка. Например финансовият отдел на дадена компания се нуждае от информация за плащането на всички служители като част от разходите на компанията, но не се нуждае от детайли относно служителите, които са обект на интерес за отдела човешки ресурси. По тази причина различните департаменти се нуждаят от различни изгледи на базата данни на компанията.
Архитектурата на база данни на три нива се отнася до концепцията за независимост на данните, която е една от най-големите първоначално движещи сили на релационния модел. Идеята е, че промените направени на определено ниво не се отразяват на изгледа на по-високо ниво. Например промените на вътрешното ниво не засягат програмни приложения, написани с помощта на интерфейси от концептуалното ниво, което намалява влиянието на физическите промени с цел подобряване на производителността.
Концептуалният изглед осигурява ниво на заобикаляне между вътрешен и външен изглед. От една страна той осигурява общ изглед на базата данни, независим от различните структури на външните изгледи, а от друга страна извлича детайли за това как данните се съхраняват и управляват (вътрешно ниво). По принцип всяко ниво дори всеки външен изглед може да се представи чрез различните модели на данни. На практика обикновено дадена система за управление на бази данни използва същият модел на данни за външното и концептуалното ниво (например релационният модел). Вътрешното ниво, което е скрито в СУБД и разчита на нейните имплементации, изисква различно ниво на детайлност и използва собствени видове структурни данни.
Разделянето на външни, концептуални и вътрешни нива е една от главните характеристики на имплементирането на релационния модел на бази данни, който доминира в XXI век.
Езиците за бази данни са езици със специално предназначение, които правят едно или повече от следните неща:
Езиците за бази данни са специфични за определен модел на данни. По-известните примери включват:
Даден език за бази данни може също да включва свойства като:
Поради изключителната важност на технологията база данни за гладкото протичане на един бизнес процес, системите за бази данни включват сложни механизми за постигане на необходимото бързодействие, сигурност и достъпност, и позволяват администраторите на бази данни да контролират тези функции.
Хранилището на базите данни е като контейнер при физическото представяне на една база. То представлява вътрешното(физическо) ниво в архитектурата на базата. Съдържа цялата необходима информация (напр. метаданни, „данни за данните“, и вътрешни структури на данните), за да се възпроизведе концептуалното и външното ниво от вътрешното ниво, когато е необходимо. Поставянето на данни за постоянно съхранение е основната отговорност на ядрото на базата данни, познато още като „ядро за съхранение“. Въпреки че обикновеният достъп е чрез СУБД през операционната система (и често се използва файловата система на операционната система като медиатори за слоя за съхранение), свойствата на хранилището и конфигурацията са изключително важни за ефективното функциониране на СУБД, и по този причина са тясно поддържани от администраторите на бази данни. СУБД, когато е в процес на работа, винаги има своя база данни преминавайки през няколко етапа на съхранение (напр. локално и външно съхранение). Данните от базата данни и необходимата допълнителна информация, възможно в най-големи количества, се кодират в битове. Данните обикновено се намират в хранилището в структури, като изглеждат напълно различно от начина, по който данните изглеждат в концептуалните и външни нива, но по начин, който се опитва да оптимизира (възможно най-добрият) тези нива на реконструкция, когато е необходимо от потребителите и програмите, също така за изчисляване на допълнителни типове необходима информация от базата (напр. когато правим заявки към базата).
Някои СУБД поддържат спецификация за това какво символно кодиране е използвано при кодирането за съхранение на данните, по този начин много кодирания могат да се използват в една и съща база данни.
Различни база данни структури за съхранение на ниско ниво се използват от оперативната памет за сериализиране на модела, така че да може да бъде записан на носител по избор. Техники като индексиране могат да се използват за подобряване на бързодействието. Стандартното съхранение е ред-ориентирано, но също така има и колона-ориентирани и корелационни бази данни.
Често излишъка на памет се използва за увеличаване на бързодействието. Типичен пример е запазването на резултатните база данни обекти, които често се състоят от необходимите външни обекти или резултати от заявките. Запазването на такива обекти спестява големите изчисления, необходими за тях всеки път. Недостатъците на резултатните база данни обекти са излишните ресурси при актуализиране, за да се синхронизират с тяхната основна информация в базата, и изразходваната допълнителна памет.
Понякога базата използва повече памет при копирането на обектите си (с едно или повече копия), за да се подобри достъпността (общо за подобряване на бързодействието от едновременния многократен достъп на крайния потребител до един и същ база данни обект, и за подобряване на устойчивостта в случай на частично прекъсване на съответната база данни). Актуализацията на копирания обект е необходимо да бъде синхронизирана през копията на обекта. В много случаи цялата база се копира.
Сигурността на базата данни е свързана с всички възможни аспекти на защита на съдържанието на базата, нейните собственици и потребители. Тя варира от защита от преднамерени неоторизирани потребители до непреднамерени достъпи до базата данни от неоторизирани единици (напр. човек или компютърна програма).
Контролът на достъп до базата данни е свързан с контролирането на това, на кой (човек или определена компютърна програма) е разрешен достъп до информацията. Тя може да включва конкретни обекти (напр. типове записи, специфични записи, структури от данни), определени изчисления върху определени обекти (напр. видове заявки или конкретни заявки) или използване на специфични пътеки за достъп до първите (напр. използване на специфични символи или други структури от данни за достъп до информацията). Контролът върху достъпа до базата данни се определя от специален оторизиран (от собственика на базата данни) персонал, който използва защитени СУБД интерфейси за защита.
Това може да се управлява директно на индивидуална основа или чрез възлагане на частни лица и даване на предимства на групи или (в най-сложните модели) чрез възлагане на лица и групи да управляват, на които след това им се предоставят съответните права. Сигурността на данните предотвратява неоторизирани потребители да гледат или променят базата данни. Използвайки пароли, потребителите имат достъп до цялата база или до части от нея, наречени „подсхеми“. Например, една база данни за служители може да включва цялата информация за всеки служител, като на определени оторизирани потребители може да е разрешено да виждат само информацията за заплатите, на други може да имат достъп само до информация за работата и медицински данни. Ако СУБД осигурява начин за интерактивно влизане и актуализиране на базата, както и за заявки, се дава възможност за достъп до личните данни.
Сигурността на данните като цяло е свързана със защитата на специални парчета от данни, както физическа (т.е. от корупция или унищожаване, или изтриване; напр. виж. физическа сигурност), така и свързана с дещифрирането им, или части с важна информация (напр. като се гледа в поредицата от битове, в която се съдържат заключени валидни номера на кредитни карти; напр. виж. криптиране на данни).
Промяната и достъпът до записите са свързани с атрибутите: какво е променено и кога е променено. Услугите за записите при достъп дават възможност за съдебна проверка на базата данни на по-късен етап, запазвайки информация за събитията на достъп и промяна. Понякога се използва приложение за запаметяване на промените, повече отколкото това да се върши от самата база данни. Може да бъде направен мониторинг, за откриване на нарушения на сигурността.
Трансакциите към базата данни могат да се използват за представяне на някакво ниво на устойчивост при отказ и целостта на данните при възстановяване след злоупотреба. Една база данни трансакция е единица работа, обикновено се капсулират редица операции върху базата данни (напр. четене на база данни обект, писане, блокиране и т.н.), абстракция поддържана в база данни, както и в други системи. Всяка трансакция има добре дефинирани граници по отношение на това коя програма/изпълнение на код да бъде включена в нея (дефинира се от системен администратор чрез специални команди).
Акронимът АСИД описва някои идеални свойства на база данни трансакцията: Всеобхватност, Последователност, Независимост и Стабилност.
База данни вдигната с една СУБД не е преносима към друга СУБД (т.е. другата СУБД не може да я стартира). Въпреки това в някои ситуации е желателно да се премести, да се мигрира базата данни от една СУБД към друга. Причините са преди всичко икономически (различните СУБД може да имат различни общи разходи за притежание), функционални и оперативни (различните СУБД може да имат различни възможности). Миграцията включва трансформацията на базата данни от един тип СУБД към друг. Трансформацията трябва да запази (ако е възможно) свързаното с базата данни приложение (т.е. всички свързани приложни програми) непокътнато. По този начин, концептуалното и външното архитектурни нива на базата данни трябва да се запазят при трансформацията. Може и да се изиска също и някои аспекти от вътрешното ниво да се запазят. Комплексната или голяма миграция на базата данни може да сложен и скъпоструващ (преди време) проект сам по себе си, когато трябва да се вземе решение за миграция. Въпреки че, може да съществуват инструменти за подобряване на миграцията между характерни СУБД. Обикновено СУБД представител предоставят инструменти за подобряване на импортирането на базите данни от други популярни СУБД.
След проектирането на база данни за дадено приложение, следващият етап е създаването на базата данни. Обикновено за тази цел може да се използва подходяща СУБД с общо предназначение. СУБД дава възможност необходимите потребителски интерфейси да се използват от системните администратори, за да определят необходимата структура на данните за приложението в СУБД, съответният модел на данните. Други потребителски интерфейси се използват за селектиране на необходимите СУБД параметри (свързани със сигурността, с разпределение на съхранението и т.н.).
Когато базата данни е готова (всички структури на данните и другите необходими компоненти са определени) е обикновено пълна с първоначалната информация на приложението (инициализация на база данни, която обикновено е отделен проект; в много случаи с помощта на специализираните СУБД интерфейси, които поддържат частично вмъкване) преди да стане работещо. В някои случаи базата данни става функционираща докато още не е пълна с информацията на приложението, като данните се натрупват в процеса на работа.
След като базата е създадена, инициализирана и напълнена е необходимо да се поддържа. Може да наложи промяна на различните база данни параметри, както и оптимизация на базата данни, за подобряване на бързодействието; структурите на данните на приложението могат да се променят или да бъдат добавяни, нови сходни приложни програми могат да бъдат написани, за да се добави функционалност на приложението и т.н.
Понякога се изисква да се върне базата в предишен етап (по много причини, напр. в случаите, когато базата данни е повредена вследствие на софтуерна грешка или е актуализирана с грешни данни). За да се постигне архивирането периодично или постоянно се прави резервно копие на данните, като всяко желано състояние на базата данни (т.е. стойностите на нейните данни и тяхното вмъкване в структурата от данни на базата) се пази в отделни архивни файлове (съществуват много техники, за да се направи това ефективно). Когато това състояние е необходимо, т.е. когато се решава от системните администратори да върнат базата данни към това състояние (напр. чрез определяне на това състояние, като желана точка в момент, когато базата данни е в това състояние), тези файлове се използват за възстановяване на състоянието.
Статичните методи за анализ при верифициране на софтуера могат да се прилагат също и в сценария на езика на заявките. В частност, при Абстрактното тълкуване структурата се разширява до областта на езика на заявката за релационните база данни, като начин за подпомагане на техниките за приближаване на звука. Семантиката на езика на заявките може да бъде настроена според подходящи абстракции на конкретна област от данни. Абстракцията на релационната база данни има много интересни приложения, в частност, за сигурността, като например прецизен контрол на достъпа, водни знаци и т.н.
Други характеристики на СУБД може да включват:
Съществуват няколко вида БД.
Проектът за първата система за бази от данни е бил започнат с цел управлението на данните за програмата Аполо на НАСА. Данните били организирани йерархично, в съответствие с директорийната организация на данните във файловите системи. С времето били забелязани редица проблеми, които възникват при използването на данни организирани по този начин. Например един от основните проблеми е необходимостта от повтаряне на една и съща информация на различни нива. За това в днешни дни този тип организация почти не се използва.
Йерархичния модел организира информацията като структурира повтарящите се групи в нея. Йерархичната БД се състои от подредено множество последователности или по-точно от множество екземпляри на един и същи тип дърво. Зависимите една от друга поредици от данни се разглеждат като самостоятелни единици. Използването им става чрез търсещ ключ на по-горно ниво.
Самата концепция за БД възниква през 60-те години с реализацията на IMS, продукт на IBM, осигуряващ управлението на данни организирани в йерархии.
Мрежовият модел на базите от данни е измислен от Чарлс Бейчман. През 1973 г. той получава награда на Тюринг за него.
Мрежовият модел е възникнал като мярка за справяне с проблемите на йерархичния модел. Той предоставя възможност за установяване на връзки от тип 1-N между различните нива на йерархията. Връзките могат да съществуват без никакви ограничения. За да се открият определени данни в база организирана по този начин е необходимо да се познава целия път на достъп до тях. Поради тази причина информационните системи използващи мрежови бази са зависими от структурата на данните в тях.
(Релационни идва от английски Relation – връзка, зависимост)
През 1970 г., когато системите базирани на йерархичния и мрежовия модел са били в разгара на развитието си, Едгард Франк Код публикува статия, в която предлага разнородните данни да се съхраняват в таблици, което ще позволи да се установят връзки между тях. В днешно време този модел е масово разпространен, но през 1970 г. тази идея е смятана за интелектуален куриоз. Смятало се, че тези таблици не биха могли да бъдат ефективно управлявани от компютър. Този скептицизъм не успял да спре проучванията на Е. Ф. Код. Един от първите прототипи на система за управление на релационни бази от данни (СУРБД) е бил създаден в лабораториите на IBM.
От 80-те години насам, тази идея се развила и била приета в индустрията. През 1987 г. езикът за заявки към БД, SQL, е стандартизиран. В днешно време релационният модел е най-масово използваният в системите за управление на бази от данни.
Обектно – ориентираните бази от данни (OODB) съхраняват обекти. Тези обекти могат да бъдат лесно намирани и споделени.
OODB осигуряват възможност за съхраняване на сложни типове от данни като изображения, аудио, видео, текст и др., без да е необходимо те да се трансформират в сложни структури от данни за да бъдат съхранени в БД.
Стремежът при OODB е да се разширят ограничените типове от данни, характерни за традиционните модели на бази от данни, със специфични типове от данни.