C, PHP, VB, .NET

Имаме таблица, в която ще съхраняваме потребителски имена и пароли. Искаме да направим така, че СУБД да валидира данните, които се въвеждат в базата от данни. Например искаме имената да са съставени само от малки букви и цифри, от 4 до 32 символа, а паролите да са от 6 до 64 символа, като задължително има поне една малка, поне една главна буква и поне една цифра. Дадената таблица е следната: Прочети още…

.

Задачата е дадена за заминаващите на бригада през 2015 г. Задачата от основното второ контролно през 2015 г. ще бъде формулирана в същия дух. Прочети още…

.

Вече знаете за Декартовото произведение на таблици и как то се осъществява с JOIN операция без ON условие. Това е случаят, когато всеки елемент от едната релация се свърже с всеки елемент от другата. Бележи се с C = A x B. Операцията „релационно деление“ e обратната операция на Декартовото произведение – можем да кажем, че A = C ÷ B, както и B = C ÷ A. Прочети още…

.

На представената ER диаграма е показан фрагмент от база от данни за лечебните процедури, които се прилагат върху пациентите в клиника. За всеки пациент (Patient) се пази EГН и име. За леченията (Threatment) пазим уникален идентификационен номер и цена. За докторите (Doctor) пазим уникален идентификационен номер и име. Всяка лечебна процедура (Procedure) е извършена в точно определено време и в точно определен номер на стая. Прочети още…

.

На представената ER диаграма е моделирана база от данни за прожекциите на филми в различни кина. Всяко кино (Theater, за които пазим уникален номер, уникални име и град в който се намира) има по няколко зали (Screen, за които пазим номер на залата и тип – един от три възможни: normal, deluxe и VIP), които правят прожекции (Show, за които пазим време на излъчване на прожекциите и брой на зрители, които са си закупили билети) на определени филми (Movie, за които пазим уникален номер, уникално име, година и държава, в която са снимани). Специално отбелязваме, че номера на зала (screen.no) НЕ е първичен ключ – този номер отбелязва зала 1, 2, 3 и т.н. във всяко кино и не е уникален идентификатор за зала в системата. Прочети още…

.

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

.

Шеста нормална форма (6НФ) е предложена през 1990 г. от Кристофър Дейт с цел да бъдат разрешени проблеми с дублиране на информация при т.нар. „времеви масиви с информация“ (temporal data). Става въпрос за таблици, в които записваме информация за настоящи и предишни варианти на дадени записи. Нека например разгледаме следната таблица: Прочети още…

.

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

.

Предишните нормални форми имаха строги и ясни правила. В общи линии с нарастване на практическия опит спазването им става интуитивно. А в практиката дори несъзнателно започваме да спазваме едно съвсем просто (но погрешно!) правило: „да има възможно най-малко на брой таблици, като същевременно с това да няма повторение на информация“. Това правило обикновено води до добре нормализирана база от данни. А защо все пак е погрешно? Прочети още…

.

Продължавам статията свързана с примери за нормализация. Бяхме стигнали до 3НФ. Следващата нормална форма, която можем да приемем за междинна между 3-та и 4-та, е нормалната форма на Бойс-Код. Нека разгледаме следната таблица: Прочети още…

.