Функционална зависимост и релационни бази данни

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

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

Информация> формализация> данни

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

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

Функционална зависимост: "правилното решение = програма (програмист)" и условието: "непрекъсната кореспонденция с проблема" са валидни в повечето случаи, но само заедно. Но това не е математическата основа, която се използва при създаването на бази данни.

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

Данни, файлове и бази данни

Начинът, по който се съхраняват данните, отдавна е незначителен: дали е RAM или външно устройство. Хардуерният компонент е достигнал стабилен темп на развитие и осигурява добро качество в големи обеми.

Основните опции за съхранение, които се различават при използването на данни:

• файлове;
• база данни.

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

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

Личен опит и колективно разузнаване

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

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

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

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

• солидна Oracle;
• взискателен MS SQL Server;
• популярна MySQL.

- отлични релационни бази данни с добра репутация, лесни за употреба, бързо в умели ръце. Използването им спестява време и елиминира нуждата от писане на обикновени листове с допълнителен код.

Характеристики на програмирането и данните

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

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

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

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

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

DB: проста зависимост на данните

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

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

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

• "Идентифициране на обекти";
• "Премахване на резервирането";
• "Фиксиране на взаимоотношенията";
• - За да се гарантира надеждността.

- елементарна нужда да се използва базата данни и да се изгради модел за данни за определена задача.

Нарушаване на някоя от тези понятия - ниска ефективност на алгоритъма, бавно извличане на данни, загуба на данни и други проблеми.

Функционална зависимост: логика и значение

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

Не е задължително, но не боли да представлява функционалната зависимост като:

F (х1, х2, hellip-, xN) = (у1, у2, hellip-, yN).

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

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

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

За добрия стар Excel

Когато компютърът се показа на положителната страна, светът веднага се раздели на програмисти и потребители. Като правило първата употреба:

• PHP, Perl, jаvascript, C ++, Delphi.
• MySQL, Oracle, MS SQL Server, Visual FoxPro.

Вторият:

• Word.
• Excel.

Някои потребители успяват да правят самостоятелно (без помощта на програмисти) в базата данни на Word - истинска глупост.

Опитът на потребителите в Excel за създаване на бази данни е практичен и интересен. Важно е, че Excel сам по себе си е функционален, цветен и практичен.

Една таблична идея дефинира понятието за функционална зависимост визуално и достъпно, но има нюанси за всяка база данни. Всеки има свое "лице", но всичко от Excel до Oracle се манипулира от прости квадрати, т.е. таблици.

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

Каква е функционалната зависимост, с какво, къде, whyhellip- е очевидно само за автора или за колективното.

За това къде вървят взаимоотношенията

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

Няма значение колко красива функционална зависимост в контекста на математиката:

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

Можете да излезете с голямо разнообразие от отношения. Това е математика с логика, и е строго! Информацията е собствена математика, специална. В него е възможно да се говори за формалност само с много голямо минус.

Можете да се формализира работата на отдел персонал, пише ACS за добив на нефт или на производството на мляко, хляб, да направите избор в огромна база от Google, Yandex и Rambler, но резултатът винаги ще бъде статичен, и всеки момент от времето е същото!

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

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

За струните и обектите

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

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

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

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

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