База данни: Разлика между версии

Изтрито е съдържание Добавено е съдържание
м интервал
м Правопис без подробно четене.
Ред 3:
Поддръжката на база от данни се осъществява от т.нар. [[Система за управление на бази от данни]] (СУБД).
 
Система за управление на бази данни е компютърно приложение ([[софтуер]]) създадено за комуникация между потребителя, други приложения, както и други БД, с цел да се сравнят и анализират данни. Общото специфично предназначение на СУБД е да позволи определянето, създаването, заявки, актуализацията и администрирането на бази данни. Добре известни СУБД включват MySQL, PostgreSQL, Microsoft SQL Server, Oracle, Sybase, SAP HANA, и IBM DB2. Бази данни не са съвместими с различните СУБД, за това различните СУБД работят със стандартни като SQL и ODBC или JDBC, за да позволи на всяко приложение да работи с различни СУБД, а така и с различни БД. Управлението на БД често се избира от модела им, които те подкрепят. Най-използвани системи от бази данни от 1980 г. насам са всички поддържани релационния модели на езика SQL. Често срещано е СУБД да се нарича само „база данни“.
 
== Преглед и терминология ==
Ред 41:
Двата главни ранни модела на навигационни данни са [[Йерархична база данни|йерархичният модел]], олицетворен от IMS системата на [[IBM]], и моделът [[CODASIL]] (мрежови модел), приложен в много продукти като IDMS.
 
Релационният модел, първо предложен през 1970 от [[Едгар Код|Едгар Ф. Код]], който се отделя от традицията си като настоява, че апликациите трябва да търсят данни по тяхното съдържание, а не чрез следване на връзки. Релационния модел използва таблици, всяка използвана за различен тип единица. Чак в средата на осемдесетте хардуерът става достатъчно мощен за да позволи широката употреба бана релационни системи (СУБД плюс апликации). В началото на деветдесетте, релационните системи доминират всички широкомащабни приложения за обработка на данни и до 2015 г. те остават доминиращи. IBM DB2, [[Oracle бази данни|Oracle]], [[MySQL]], и [[Microsoft SQL Server]] са доминиращите СУБД. Доминиращият програмен език за базите данни, стандартизиран SQL за релационния модел, е повлиял на езиците на базите данни за други модели бази данни.
 
Обектно ориентираните бази данни са разработени през осемдесетте, за да се надмогне неудобството на обектно релационните импеданс несъответствия, което довежда до появяването на термина „пост-релационен“ и също развитието на хибрида обектно-релационни бази данни.
Ред 66:
В този труд, той описва нова система за съхранение и работа с големи бази данни. Вместо данните да се съхраняват в някакъв вид свързан списък от записи със свободна форма като в CODASYL, идеята на Код е да използва „таблица“ от записи с фиксирана дължина, като всяка таблица се използва за различен тип обект. Система от свързани списъци би бил много нефункционален, когато в него се складират „непълни“ бази данни, в които част от данните за който и да е запис може да останат празни. Релационният модел разрешава това, като разделя данните на серия нормализирани таблици (или връзки), като незадължителните данни се изваждат от главната таблица там, където ще заемат място само ако има нужда. Данните може свободно да се прибавят, изтриват или променят в тези таблици, като СУБД прави каквато поддръжка е нужна, за да покаже таблица на апликацията/потребителя.
 
Релационният модел също така позволява на съдържанието на базата данни да се развива без да има нужда постоянно да се пренаписват връзките и указателите. Релационната част идва от това, че обекти се свързват с други обекти чрез връзки, които се наричат едно-към-много, като модел за управление (мрежа). По този начин, релационният модел може да показва и йерархичен и навигационен модел, както и естествения тубуларентабуларен модел, като позволява чисто или съставно моделиране в рамките на тези три модела, както изисква апликацията.
 
Например, честа употреба на система на база данни е да проследява информация за потребители, тяхното име, информация за вход в системата, различни адреси и телефонни номера. В навигационния модел всички тези данни ще бъдат записани в един запис и непотребните обекти просто няма да се запишат в базата данни. В релационния модел, данните ще бъдат нормализирани в потребителска таблица, адресна таблица и таблица с телефонни номера (например). Записите ще бъдат създадени в тези незадължителни таблици само ако се запише адрес или телефонен номер.
Ред 122:
* „Облачни“ бази данни, разчитат на интернет технологията за базите данни тип „облак“. Тези бази данни и повечето от техните СУБД се използват дистанционно, „в облака“, докато неговите приложения са разработени от програмисти и по-късно поддържани и използвани от (чрез приложения) крайните потребители през уеб браузър и Oтворени API.
* Складови бази данни архивират данните от оперативни бази данни често от външни източници, като например проучващи пазара фирми. Складовите бази данни се превръщат в основен източник на данни използвани от мениджъри на фирми, както и крайни потребители, които нямат достъп до оперативните им данни. Например, данните за продажбите може да бъдат обобщени с ежеседмични суми и превърнати във вътрешен продуктов код (баркод), за да може да се сравнява с данни от агенцията ACNielsen, проучваща маркетинговия пазар в САЩ. Някой основни и съществени компоненти за съхраняване на данни включват извличане, анализиране, „разбиване“ на данните, трансформиране, зареждане и управление на данните, така че да ги направят достъпни за по-нататъшна употреба.
* Дедуктивна база данни комбинира логиката на програмиране с релационна база даниданни, например като се използва езика за писане Datalog.
* Разпределена база данни е такава, в която и данните и СУБД са разпределени между много компютри.
* Документно ориентирана база данни е предназначена за съхранение, извличане и управление на документно ориентирана, или полу структурирана,полуструктурирана информация. Документно ориентирани бази данни са една от основните категории на NoSQL бази данни.
* Вградена система от база данни е СУБД, която е тясно интегрирана със софтурно приложение, което изисква достъп до съхраняваните данни по такъв начин, че СУБД е скрит от крайния потребител на приложението и изисква малка или никаква текущата поддръжка.
* Крайно потребителска база данни се състои от данни, създадени и управлявани от индивидуални крайни потребители. Примери за това са колекции от документи, електронни таблици, презентации, мултимедия и други файлове. Няколко продукти съществуват за да поддържат такива бази данни. Някои от тях са много по-просто, отколкото пълноправни СУБД, с по-елементарна функционалност на СУБД.
* Обединена система от бази данни се състои от няколко отделни бази данни, всяка със своите СУБД. Тя се състои от една база данни, състояща се от множество обединени СУБД, които могът да бъдат различни типове и ги предоставя с един интегриран концептуален интерфейс.
* Понякога терминът „множествена база данни“ се използва като синоним на обединена база данни, макар че той може да се отнася до по-малко интегрирана (например без СУБД) група от бази данни, които си сътрудничътсътрудничат в едно приложение. В този случай междинният интеграционен софтуер се използва за разпределение.
* Графична база данни е от вид NoSQL база данни, които използват графична структура с разклонения, въздействия и свойства, за да предостави и съхрани информация. Главната графична база данни, която може да съхрани всяка графика е различна от специфичните графични бази данни, като triplestores и базите данни от мрежата.
* Масив от СУБД е вид NoSQL СУБД, която позволява да се моделира, съхранява и извлича (обикновено големи) многомерни масиви като сателинисателитни снимки и симулация на климатични времена.
* Хипертекстова или хипермедийна бази данни са, такива бази данни където всяка дума или част от текст представлява обект, напрмернапример друга част от текст, статия, снимка или филм, които са хипервръзка към този обект. Хипертекстовите бази данни са особено полезни за организиране на големи количества от разнородния информация. Например, те са полезни за организиране на онлайн енциклопедии, където потребителите могат удобно да използват хипервръзките за да прескачат между страници в интернет, а не да ги търсят ръчно. По този начин World Wide Web(www) е една голяма хипертекстова база данни.
* Научна база данни (съкращение НБД, нбд или ?) е специален вид база данни за управление на информация, като предоставя средства за компютризирано събиране, организиране и извличане на знания. Също така предоставя колекция от данни, свързани с проблеми и техните решения, както и свързаният с тях опит.
* Мобилна база данни – те могътмогат да бъдат обработвани или синхронизирани от мобилни изчислителни устройства.
* Оперативна база данни съхранява подробни данни за дейността на дадена организация. Те обикновено обработва сравнително високи обеми от актуализации с помощта транзакции. Например клиентските бази данни, които съдържат контакти, кредити и демографска информация за даден бизнес клиент, данни на персонал, който съдържа информация, като заплати, бонуси, данни за умения за служителите, системи за планиране на ресурсите на предприятието, които записват информация за продукти, както и финансови бази данни, които да следят финансите на дадена организация, сделки между акаунти и други финансови зделки.
 
* Паралелна база данни имат за цел да се подобри ефективността чрез паралелизация на задачи като зареждане на данни, изграждане на индекси и оценяването на заявки. Главни паралелни СУБД архитектури, които са включени в базовите хардуерни архитектури са:
** '''Общата архитектурна памет''', където многожествомноожесттво процесори споделят една основна памет, както други съхранени данни.
** '''Споделена дискова архитектура''', където всеки процесор (обикновено състоящ се от множество процесори) има своя собствена памет, но всички процесори споделят помежду си съхранените данни.
** '''Несподеляща архитектура''', където всеки процесор има свое основна памет и съхранените данни на останалите.
Ред 151:
''Main article: [[Database design]]''
 
Първата задача пред един дизайнер на бази данни е да произведе концептуален модел на данните, който отразява структурата на информацията, която ще се проведе в базата данни. Един общ подход към това е да се разработи модел на обектни взаимовръзки, често с помощта на инструменти за рисуване. Друг популярен подход е [[Unified Modeling Language]]. Един успешен модел на данитеданните акуратно ще отрази възможното състояние на външния свят, който е обект на моделирането: например ако хората могат да имат повече от един телефонен номер моделът ще позволи на тази информация да бъде съхранена. Проектирането на добър концептиаленконцептуален модел на данните изисква добро разбиране на областта на приложение; обикновено е свързано със задаването на сериозни въпроси за нещата, които представляват интерес за дадена организация, като например „може ли клиентът да бъде едновременно и доставчик?“ или „ ако даден продукт се продава с два различни вида опаковки, това един и същ продукт ли е или различни продукти?“ или „ ако самолет лети от Ню Йорк до Дубай през Франкфурт, това един полет ли е или два (или може бидориби дори три)?“. Отговорите на тези въпроси създават дефиниции на терминологията, използвана за обектите (клиенти, продукти, полети, самолетни сегменти) и техните взаимовръзки и атрибути.
 
Производството на концептуалния модел на данни понякога включва входни данни от бизнес процесите или анализи на работния процес в организацията. Това може да помогне да се установи каква точно информация е необходима в базата данни и кое е ненужно. Например може да помогне в решаването дали базата данни трябва да съдържа исторически данни освен актуалните данни.
Ред 157:
След като е произведен концептуален модел на данните, от който потребителите са доволни, следващият етап е това да се превърне в схема, която имплементира съответните структури от данни в базата данни. Този процес често се нарича логически дизайн на база данни и на изхода имаме логически модел на данни, изразен под формата на схема. Докато концептуалния модел на данни е (поне на теория) независим от избора на технология на базата данни, то логическия модел на данните ще бъде изразен по правилата на конкретната технология на Системата за управление на базата данни. (Термините ''модел на данните'' и ''модел на базата данни'' често се използват взаимозаменяемо, но в тази статия използваме ''модел на данните'' за проектирането на специфична база данни, а ''модел база данни'' за нотация в моделирането, използвана за изразяването на този дизайн.)
 
Най-популярният модел на база данни с общо предназначение е релационният модел или по-точно казано релационният модел, представен чрез езика SQL. Процесът на създаване на логически дизайн на база данни, с помощта на този модел, използва методичен подход, известен като нормализиране. Целта на нормализирането е да гарантира, че всеки елементарен „факт“ е записамзаписан само на едно място, така че вмъкването, обновяването и изтриването на данни автоматично да поддържа съотвествието на системата. 
 
Заключителният етап от проектирането на база данни е да се вземат решения, които се отразяват на работата, скалируемостта, възстановяването, сигурността и други такива. Това често се нарича ''физически дизайн на база данни''. Основната цел през този етап е независимостта на данните, което означава, че решенията, взети за целите на оптимизация на производителността трябва да са невидими за крайните потребители и приложения. Физическият дизайн се дължи главно на изисквания за изпълнение и изисква добро познаване на очакваната натовареност и достъпваните модели, както и дълбоко познаване на функциите, предлагани от избраната Система за управление на база данни. 
Ред 196:
* Семантичен модел
* Съхраняване на съдържанието
* Съхраняване на събиятасъбитията
* Модел на динамичния ред
 
Ред 213:
Архитектурата на база данни на три нива се отнася до концепцията за ''независимост на данните'', която е една от най-големите първоначално движещи сили на релационния модел. Идеята е, че промените направени на определено ниво не се отразяват на изгледа на по-високо ниво. Например промените на вътрешното ниво не засягат програмни приложения, написани с помощта на интерфейси от концептуалното ниво, което намаля влиянието на физическите промени с цел подобряване на производителността.
 
Концептуалният изглед осигурява ниво на заобикаляне между вътрешен и външен изглед. От една страна той осигурява общ изглед на базата данни, независим от различните стрктуриструктури на външните изгледи, а от друга страна извлича детайли за това как данните се съхраняват и управляват (вътрешно ниво). По принцип всяко ниво дори всеки външен изглед може да се представи чрез различните модели на данни. На практика обикновено дадена Система за управление на бази данни използва същият модел на данни за външното и концептуалното ниво (например релационният модел). Вътрешното ниво, което е скрито в СУБД и разчита на нейните имплементации, изисква различно ниво на детайлност и използва собствени видове структурни данни.
 
Разделянето на ''външни'', ''концептуални'' и ''вътрешни'' нива е една от главните характеристики на имплементирането на релационния модел на бази данни, който доминира в 21 век.<sup>[[Database|[31]]]</sup>