Функціональна залежність і реляційні бази даних

Інформація завжди мала адекватний динамічний інтерес. Розвиток мов програмування реляційних баз даних та інформаційних технологій кардинально змінило зміст і структуру інтересу. Склалася певна сувора система уявлень. Формалізація, точна математика і бінарні відносини стали успішною і, стрімко розвивається, областю знань і досвіду. Природний світ інформації не змінив своєї динаміки і, розвиваючи зміст і структуру, піднявся на нову висоту. Він має плавні форми, що і в природі немає нічого «прямокутного» . Інформація, безумовно, піддається формалізації, але у неї є динаміка, змінюються не тільки дані і алгоритми їх обробки, змінюються самі завдання і області їх застосування.

Інформація > формалізація дані

Інформація, перетворюється в дані (модель даних, інформаційна структура бази даних) так, як це бачить програміст. Немає ніякої гарантії, що це бачення правильно, але якщо його програма вирішує поставлену задачу, значить дані були представлені можливо належним чином. Питання про те, наскільки була правильно формалізована інформація – питання часу. Досі поняття динаміки (самоадаптации до мінливих умов використання) – лише мрія програмування. Функціональна залежність: «правильне рішення = програма (програміст)» і умова: «безперервне відповідність завданню» дійсні у більшості випадків, але тільки спільно. Але це не та математична основа, яка застосовується при створенні баз даних.


Пряме твердження: природна і безперервна динаміка інформації та алгоритмів рішення задач завжди. А реляційні бази даних це бінарні відносини + сувора математика + точні формальні конструкції, +

Дані, файли і бази даних

Як зберігаються дані вже давно неважливо: чи то оперативна пам'ять або зовнішнє пристрій. Апаратна складова досягла впевнених темпів розвитку і забезпечує гарну якість у великих обсягах. Основні варіанти зберігання, відрізняються варіантами використання даних: файли; бази даних. Перше віддано на відкуп програмісту (що записувати, в якому форматі, як це робити, як читати), друге відразу приносить необхідність пізнання простий функціональної залежності. Швидкість вибірки і запису інформації при роботі з файлами (розумного розміру, а не астрономічного) дуже швидка, а швидкість аналогічних операцій з базою даних може деколи бути помітно повільної.

Особистий досвід і колективний розум

В історії були спроби вийти за досягнуті межі, але донині панують реляційні бази даних. Накопичений великий теоретичний потенціал, практика застосування обширна, а розробники - висококваліфіковані. Поняття функціональної залежності розробники баз даних нав'язують програмісту, навіть якщо той не має наміру використовувати багатий математично-логічний досвід побудови складних інформаційних структур, процесів роботи з ними, вибірки і запису інформації. Навіть у найпростішому випадку програміст залежить від логіки бази даних, яку він вибрав для роботи. Немає бажання слідувати канонам, можна використовувати файли, вийде багато файлів і багато особистого досвіду. Буде витрачено багато особистого часу і завдання буде вирішено за тривалий час.
Якими б складними не здавалися приклади функціональної залежності, зовсім не обов'язково занурюватися в глибини сенсу і логіки. Часто слід визнати, що колективний розум зумів створити відмінні бази даних, різного розміру і функціональності: солідний Oracle; вимогливий MS SQL Server ; популярний MySQL. – прекрасні реляційні бази даних з хорошою репутацією, зручні у використанні, швидкі в умілих руках. Їх застосування економить час і позбавляє від необхідності писати чергові простирадла допоміжного коду.

Особливості програмування та даних

У програмування з давніх пір хвороба щось постійно переписувати, повторювати працю попередників, щоб щось адаптувати до нової інформації, завдання або умовами її використання. Особливість функціональної залежності в тому, що, як і в програмуванні, помилка може коштувати дуже дорого. Завдання рідко буває простою. Зазвичай, в ході формалізації інформації, що виходить складне уявлення даних. Зазвичай виділяються їх елементи, потім вони ув'язуються ключами в певні відносини, потім налагоджуються алгоритми формування таблиць, запитів, алгоритми вибірки інформації. Часто велике значення має прив'язка до кодування. Не всі бази даних пропонують мобільні рішення, часто можна зіткнутися з тим, як чудово налаштований MySQL, на якому лежить десяток баз даних, відмінно і стабільно працюючий, змушує розробника робити одинадцяту базу подібної до тих, які вже є. Бувають випадки, коли загальний хостинг обмежує функціональність PHP і це накладає відбиток на програмування доступу до бази даних. У сучасному програмуванні відповідальність за алгоритм програми еквівалентна відповідальності за створення моделі даних. Все повинно працювати, але не завжди слід занурюватися в нетрі теорії.

БД: проста залежність даних

Передусім, поняття БД - це та база даних як система управління базами даних (наприклад, MySQL), так і певна інформаційна структура, що відображає дані завдання і зв'язку між ними. Одна база MySQL «тримає» на собі скільки завгодно інформаційних структур за різними сферами застосування. Одна база Oracle, може забезпечувати інформаційні процеси великої компанії або банку, контролювати питання безпеки і збереження даних на найвищому рівні, розташовуючись на безлічі комп'ютерів, що знаходяться на різній відстані, в різних інструментальних середовищах.
Прийнято вважати, що відношення є основне в реляційній моделі. Елементарне відношення - це безліч стовпчиків з іменами і рядків зі значеннями. Класичний «прямокутник» (таблиця) – просте і ефективне досягнення прогресу. Складності і функціональна залежність бази даних починаються, коли «прямокутники» починають вступати у відносини один з одним. Ім'я кожної колонки в кожній таблиці повинно бути унікальним в контексті завдання. Одне і те ж цей не може бути у двох таблицях. Знати зміст понять: «визначити сутності»; «виключити надмірність»; «зафіксувати взаємозв'язку»; «забезпечити достовірність». - елементарна необхідність для використання бази даних і побудови моделі даних для конкретної задачі. Порушення кожного з цих понять – низька ефективність алгоритму, повільна вибірка даних, втрата даних, і інші неприємності.

Функціональна залежність: логіка і сенс

Можна не читати про кортежі відносин, про те, що функція – це відповідність безлічі аргументів безлічі значень, а функція – це не тільки формула або графік, але може бути задана безліччю значень – таблицею. Не обов'язково, але зовсім не завадить представляти функціональну залежність: F(x1 x2 , xN) = (y1 y2 , yN). Але обов'язково розуміти, що на вході – таблиця, на виході теж таблиця або конкретне рішення. Зазвичай функціональна залежність встановлює логіку зв'язків між таблицями, запитами, привілеями, тригерами, збереженими процедурами та іншими моментами (компонентами) бази даних. Зазвичай, таблиці перетворюються одна в одну, потім в результат. Але використання функціональної залежності не обмежується тільки такою ідеєю. Програміст сам будує своє уявлення картини даних, моделі предметної області, інформаційної структури неважливо, як це іменувати, але якщо воно працює на конкретній базі даних, воно повинно будуватися за її логікою, враховувати її зміст і діалект мови, що використовується, як правило, SQL. Можна стверджувати, що властивості функціональних залежностей бази даних доступні через діалект мови SQL. Але набагато важливіше розуміти: після всіх перипетій розвитку, не так багато баз даних вижило, але діалектів цієї мови багато і особливостей внутрішніх конструкцій в базах теж.

Про старий добрий Excel

Коли комп'ютер показав себе з позитивного боку, світ відразу розділився на програмістів і користувачів. Як правило, перші використовують: PHP, Perl, jаvascript, C++, Delphi. MySQL, Oracle, MS SQL Server, Visual FoxPro. Другі: Word. Excel. Деякі користувачі умудряют робити самостійно (без допомоги програмістів) в Word бази даних - реальний нонсенс. Досвід роботи користувачів в Excel по створенню баз даних - практичний і цікавий. Важливо те, що Excel, сам по собі, функціональний, барвистий і практичний. Таблична ідея, визначила поняття функціональної залежності наочно і доступно, але нюанси є в кожної бази даних. У кожної своє «обличчя», але все Excel до Oracle маніпулюють простими квадратами, тобто таблицями. Якщо врахувати, що Excel – це зовсім не база даних, але багато юзери (не програмісти) його саме так використовують, а Oracle – це складний і потужний досягнення великого колективу розробників саме в області баз даних, то стає природним визнати – база даних це уявлення конкретного програміста (колективу) про конкретної задачі і її рішення. Що таке функціональна залежність, з чим, куди, чому вочевидь лише автору або колективу.

Про те, куди реляційні відношення йдуть

Науково-технічний прогрес - дуже болісна процедура, а місцями жорстока. Якщо згадати з чого починалися бази даних, що таке *.dbf, як таврували кібернетику, потім полюбили інформатику і стали влаштовувати перешкоди переміщенню високих технологій на рівні країн, стає ясно чому реляційні бази даних так живучі і гарні. Чому класичний стиль програмування по сей день живе, а об'єктно-орієнтоване програмування просто цінується, але ще не панує. Як би не була прекрасна функціональна залежність у контексті математики: Це не бінарні відносини, точніше, це привід переосмислити ідею встановлювати відносини між безліччю атрибутів, досліджувати зв'язку «один до багатьох», «багато до одного», «багато до багатьох» або «багато взагалі, а одні зокрема». Варіантів відносин можна придумати безліч. Це математика з логікою, і вона сувора! Інформація - це своя математика, особлива. В ній про формальності можна говорити лише з дуже великим мінусом. Можна формалізувати роботу відділу кадрів, написати АСУ для видобутку нафти або виробництва молока, хліба, зробити вибірку у величезній базі гугла, яндекса або рамблера, але результат буде завжди статичний і кожен момент часу однаковий! Якщо функціональна залежність = сувора логіка і математика = основа для баз даних, то про яку динаміці можна вести мову. Будь-яке рішення буде формальним, будь-яка формальна модель даних + чіткий алгоритм = точне і однозначне рішення. Інформація та область застосування програми змінюються завжди. Вибірка пошукової системи на одній і тій же пошуковій фразі не може бути однієї і тієї ж через годину чи через дві і, однозначно, через день - якщо пошукова фраза відноситься до галузі інформації, якій кількість сайтів, ресурсів, знань, інших елементів безперервно змінюється.

Про рядках і об'єктах

Навіть якщо програма чисто математична та її база даних навіть не мислить про динаміку, всі завжди є рядки . А у рядки є довга. І нескінченної вона бути не може. Вона не може бути навіть змінної, тільки умовно-змінної. Крім усього іншого, будь-яка база даних своїм математичним і бінарним-бюрократичним апаратом накладає масу формальностей, а це швидкість+якість вибірки й обробки інформації. А якщо ті чи інші поля в базі даних числа, особливо речові то обмеження додадуться: розрядність числа, наявність літери "е", формат подання - коротше скрізь і завжди маємо важливі властивості функціональних залежностей бази даних: рядки умовно-змінної довжини з масою бінарних формальностей і строгих математичних обмежень. Якщо змінити тон і прислухатися до пульсу динаміки, то все можна розписати на об'єкти. У першому наближенні ім'я колонки в таблиці - це об'єкт, список імен - теж об'єкт, коротше таблиця - це об'єкт шапки і в ньому імена колонок в шапці. І шапки може зовсім не бути Але в таблиці можуть бути рядки. І в рядку можуть бути значення. І чому їх завжди має бути однакова кількість. Повна квадратна таблиця - це випадковість, причому в більшості випадків, приватна. Якщо представити всі конструкції в базі даних об'єктами, то, бути може, не доведеться вибудовувати суворі бінарні відносини. В цьому є природний і реальний сенс хоча б тому, що це за об'єктивною (однозначно не математичної) логіки відображає динаміку інформації та середовища, в якому існують задачі.