Релационен модел на данни
Интересно е да се отбележи, че през 1980 г. Дж. Д. Улман пише в своята монография "Принципи на системите за бази данни", че почти всички съществуващи търговски системи за бази данни са базирани или на мрежов, или на йерархичен модел на данни, но не и на релационен модел и "тази ситуация ще се промени бавно." Но още през 1985 г. ситуацията се промени драматично - релационните СУБД и SQL станаха много популярни. И в началото на 90-те релационните СУБД и езикът SQL на практика изместиха всичко останало от пазара на СУБД. Причината за тази драматична промяна беше разработването на ефективни, бързи и надеждни методи за съхранение и достъп до релационни данни.
Концепцията за релации и таблици
Нека дефинираме какво е релационна СУБД и как данните се представят в нея. За релационна СУБД се избира представяне въз основа на математическата концепция за "връзка". Много се доближава до познатото на всички ни понятие „маса“. На английски релацията се нарича "relation", оттук и името "relational DBMS" (ако наричате такива бази данни "relative", тогава това може да изкриви смисъла).
Разликата между таблица в обичайния за нас смисъл и концепцията за релация е, че в релацията няма ред - тя е най-общо казано неподреден набор от записи. Това, разбира се, не означава, че изобщо няма ред, той просто не е подчинен нито на програмиста, нито на администратора. Редът се определя не от релацията, а от специфичен избор от релацията. От същата релация мога да избирам данни във възходящ ред на заплата, в азбучен ред на фамилни имена и т.н.
В бъдеще все още ще използваме термина "таблица", а не "връзка", тъй като този термин е разбираем, познат и най-разпространеният език.достъпът до релационни бази данни - езикът SQL - използва този термин, въпреки че разбира под него "неподредени" таблици.
Изглед на база данни
Релационна база данни е колекция от информация, групирана в една или повече таблици. Една таблица може да бъде представена като двумерен масив или като набор от записи с еднаква (за дадена таблица) структура. Записите се наричат още редове. С други думи, таблицата се състои от редове и колони. Броят на колоните и записите за всяка таблица е теоретично неограничен, въпреки че естествено съществуват ограничения на практика. Почти невъзможно е да надхвърлите границите на добър сървър за бази данни - например сървърът за бази данни Infomix OnLine DSA позволява до 32 767 колони и до 8 милиарда записа във всяка таблица.
¦ ¦ ¦ ¦ ¦ стойност на този атрибут
¦ . ¦ за този запис
¦ L---------- колона (атрибут, поле)
L-------------- колона (атрибут, поле)
Фиг.6. Структура на таблицата (релации).
Всяка колона има определен тип, който е еднакъв за всеки запис в таблицата. Може да бъде цяло число, дата, текст и др. Наборът от възможни стойности за определена колона също се наричадомейн. Важно за релационния модел е изискването стойността на всеки атрибут да бъде атомарна, неделима. Например не можете да използвате масив от цели числа като стойност. Ако това правило не е изпълнено, тогава тази СУБД вече не може да се нарича релационна.
Всеки ред в таблицата описва определен отделен обект, полетата съдържат характеристики, стойности на определени характеристики на тези обекти. В таблица, която, както вече отбелязахме, е набор от записи, съдържа записи, които са комбинирани според някакъв атрибут.