Дані звично асоціюються з програмуванням і в сучасному інформаційному світі представляються в трьох логічно еквівалентних варіантах: дані, описані і використовувані в програмі на мові програмування; дані в системах баз даних; дані в розподілених інформаційних системах. Сучасне програмування тільки першого варіанту формалізації інформації надало відносну свободу. Другі два варіанти – це в тій чи іншій мірі достовірні форми надання інформації та взаємозв’язків між її складовими.
Дані минулого і сьогодення
Принципова позиція мов програмування – точний опис даних і алгоритмів. Комп’ютери не «представляють» жодних шансів невизначеності: є те, над чим проводиться дію, і є команда, яка вчиняє цю дію.
Сучасна концепція ґрунтується на значно більш високому підставі: є цей, а яким саме воно буде, визначається у місці його використання. У будь-якому випадку в момент використання дане автоматично перевіряється і перетворюється в потрібний тип. Сучасний програміст не зобов’язаний піклуватися про попереднє їх описі і дотриманні сумісності типів в алгоритмі.
Процес переходу:
- від типізованих даних та обов’язкового їх опису перед використанням;
- до нетипизированным даними і свободу від будь-яких зобов’язань щодо їх опису і використання.
По суті, можна визнати відносне послаблення вимог формалізації – воно доступне тільки в середовищі сучасних засобів програмування. У момент виконання тип кожного даного фіксований, а послідовність команд чітко визначена.
Типи і моделювання
Математика і фізика, торговельне справа і виробництво, економіка та інші сфери, де застосовуються числа, завжди оперували даними і не надавали ніякого значення поняттю типу. Те, що числа можуть бути цілими і дробовими, не мало особливого значення.
Кожна конкретна формула або конкретна дія могли дати ціле, нескінченний дріб, дійсне чи комплексне число. Досі є такі чудеса розуму, як нескінченно мала і нескінченно велика величина. Причому у цих чудес навіть властивості є.
У програмуванні досі немає ніякої свободи. Все має бути строго формалізоване. Поняття даних – це, перш за все, тип:
- integer;
- boolean;
- char;
- string і так далі.
Найменування типів можуть відрізнятися в різних мовах програмування, але завжди є ціле або дійсне число, логічне значення, символ, рядок. Залишилися ще релікти і специфічні ідеї: ціле без знака, код, байт, слово, подвійне слово, рядок фіксованої довжини.
Поняття даних у системи даних не має ніякої волі. Мова SQL – «міжнародний» (є діалект для кожної сучасної бази даних) – не терпить ніяких неточностей не тільки даних, але і в sql-запитах. Помилка в запиті – гарантія відсутності результату. Про порушення описів говорити зовсім не доводиться.
Моделювання інформаційних процесів та уявлень даних є єдиним вірним способом побудувати таку структуру, яку можна розвивати і адаптувати до умов, що змінюються.
Динаміка вихідного
Природна інформація – це безперервна зміна. Дати формальний опис та поняття моделі даних в конкретній предметній галузі означає вирішити три завдання:
- визначити, що таке тут дані;
- формалізувати взаємозв’язки між ними;
- сформулювати процеси зміни даних і взаємозв’язків.
Приклад сукупності даних простого алгоритму на JavaScript – зменшена копія моделі навіть найсоліднішою системи управління базами.
Просто у другому випадку експерти і фахівці, проектуючи структури даних, таблиці та взаємозв’язку, зазвичай не бачать (реально важко охопити великий обсяг природної інформації) суть речей, і виходить громіздка, неразвиваемая сукупність нагромаджень даних, в той час як у предметній області вихідна інформація циркулює вільно і легко.
Статика можливого
Звичайна практика JavaScript – код, підключений до сторіночці, та функції, призначені подій на її тегах. При будь-якому положенні речей теги сторінки визначають дані, які приймає, змінює чи створює цей веб-ресурс.
Якщо уважно сконцентрувати код обробників на події, а не на коді сторінки в цілому – це найкращий вихід із ситуації. Ідеально, коли код не вводить нове дане або не фіксує доступне, а орієнтується на те, що саме він має в конкретний момент часу.
По суті, якщо дати визначення поняття “дані” як мінімально статичного опису вихідної інформації і наслідувати йому, то це значить мати шанси на успіх.
Щодо баз даних все набагато складніше. Будь JavaScript код – це «забезпечення» сторінки функціоналом. Будь-яка база даних – це сукупність таблиць, зв’язків між ними, збережених процедур, запитів і функціональності, доступною ззовні.
Статика – біда будь-якого алгоритму. Сучасне поняття даних – це статика: число, рядок, символ і так далі. При обробці або при запису в таблицю бази даних все виходить гарно. Але коли вихідне набуває інший вимір або сенс? Варіант один: міняти табличку, але можуть відразу посипатися зв’язку і запити.
Статика і об’єкти
Визначення поняття “дані” як об’єкта кардинально змінює ситуацію. Об’єкт має власну структуру. Тут можна застосовувати будь-які описи будь-яких змінних. Ролі не зіграє. Об’єкт має методи, через які дані доступні. Оскільки всі використовується в сфері програмування, тобто три базових методу: читати, писати, редагувати. Можна додати ще порівнювати, шукати, клонувати та ін.
Предметна область на кожне дане накладає спектр властивостей. Таким чином виходить, що поняття даних трансформується в якусь опис, який може бути змінено динамічно. Статика всередині об’єкта дає динаміку за його межами.
Змінюючи комбінацію статичних описателей всередині об’єкта, можна не турбуватися за динаміку його відносин з іншими об’єктами.
Програмування і подання даних
Що таке дані? Суспільна свідомість вже звикло до інформаційних технологій, працює в хмарах і має контейнери у віртуальних просторах. Тепер у питаннях інформації та її використання компетентні не тільки професійні програмісти і користувачі, але і обивателі.
Однак що таке програмування? Донині громадська думка дає наступне визначення даного поняття та його концепцій:
- Інформація і дані – це базові поняття, які використовуються в інформатиці.
- Дані являють собою певним чином одержані та зафіксовані спостереження щодо навколишньої дійсності.
- Вони бувають прості та складні (структури), первинні та вторинні.
- База даних – це сукупність самостійних матеріалів, представлених в систематизованої формі так, щоб вони були знайдені, змінені і використані.
Наскільки це об’єктивно? Авторитетні автори вважають, що так. Реальна практика схиляється до того, що кожна предметна область визначать свою правильну систему даних і дає всі можливості побудувати хорошу динамічну модель.
Нерідкі випадки, коли замовник (споживач) нав’язує програмісту (проектувальнику бази даних) власну думку, як і що робити. З точки зору програмування всяке бажання замовника можна виконати гранично точно.
Потрібен Oracle для вирішення задачі складання кошторисів на обслуговування сільського водопроводу (на селі 21 будова) – добре. Потрібен MySQL для організації системи стеження за поштовими відправленнями за всім поштовим відділенням Росії – теж все буде працювати.
Завжди можна скласти будь-який алгоритм і забезпечити доступ до будь-якого подання інформації в межах того визначення поняття, яке встановлює розробник системи управління базами або мови програмування. Питання в іншому: як це зробити мінімальними витратами максимальної динаміки?
Бази даних, приклади
Проста база створюється без моделі. Основні поняття даних і зв’язку невеликі, функціонал дуже простий. Наприклад, для вищого навчального закладу необхідні:
- таблиця викладачів;
- таблиця груп (ключ і номер групи);
- загальна таблиця студентів (використовуються ключі груп).
Декан бажає знати успішність по викладачах. Таблиця викладачів має поля:
- прізвище;
- ім’я;
- по батькові;
- номер курованої групи.
Таблиця студентів має поля:
- прізвище;
- ім’я;
- по батькові;
- дата народження;
- середній бал (з усіх предметів);
- номер групи.
Варіантів вибірки може бути як мінімум два: через ім’я викладача можна вийти на номер групи і подивитися всіх студентів і їх середні бали або прізвища викладача та прізвища студента можна подивитися середній бал останнього.
Навіть у такому простому варіанті гарантовані проблеми і доведеться щось міняти. Ситуація: викладач захворів, місяць його заміщує інший, значить, курирує дві групи. Передбачено лише одне поле під одним номером групи в таблиці викладачів.
Для вирішення проблеми потрібно додавати дублююче полі. А якщо два захворіють, то додавати три поля. Так таблиця викладачів починає рости на порожньому місці.
Є ще один варіант: замінити цифрове поле ключа групи на символьне. Тоді доведеться щоразу при вибірці перетворювати рядок у послідовність ключів, і один sql-запит перетвориться на кілька.
Більш перспективний приклад – не робити таблиці, а зробити об’єкти. Тоді викладач – це об’єкт, і у нього може бути кілька своїх підшефних груп. Але це завжди один об’єкт. У об’єкта викладач є унікальний ключ, але може бути кілька своїх підшефних груп. У групи є також унікальний ключ. У студента теж.
Всі три позиції не тільки доступні в межах поставленої задачі, але і можуть розвиватися далі.
Об’єктно-орієнтовані бази
Лідери інформаційної галузі пропонують класичні реляційні бази даних. Вони перевірені життям, працюють, безпечні, надійні і, у разі проблем, що дозволяють відновити інформацію.
Об’єктно-орієнтовані бази даних (ООБД) почали розроблятися ще в середині 1980-х і, на думку авторитетних авторів, перспективні донині. Але поки що, крім фундаментальних теорій і концептуальних положень, немає жодної ООБД, що досягла такого ж рейтингу і поширення, як MySQL, MS SQL Server або Oracle у всіх його різноманітних втіленнях.
Але що робити, якщо визначення, поняття даних, види, атрибути, класи, ієрархії пропонує розробник, рейтинг якої недостатній для створення спільноти програмістів, які сповідують менталітет даної ООБД? Доведеться сподіватися на свої сили.
У середовищі линуксоидов створено понад тридцяти варіантів ООБД. Але де гарантія, що створена база даних не вимагає більшої функціональності? Середовище Windows не відрізняється великими гарантіями в цій області.
Об’єктно-орієнтований варіант вирішення
Однак рішення все ж є. На прикладі MySQL можна показати, як стандартні реляційні таблиці перетворюються в об’єктно-орієнтовану модель розв’язуваної задачі.
Тут немає бази даних, але є середовище для формування власної системи об’єктів. Потужності MySQL використовуються тільки як реляційна пам’ять для таблиць з інформаційних рядків. Логіку використання визначає сам розробник. Зокрема, є таблиця is_cache. У ній усього кілька основних полів:
- owner_code;
- session_code;
- h_code;
- a_surprise;
- a_contents.
Інші поля несуть в собі службові функції. Дана таблиця стоїть на вході будь-якого запиту і фіксує його надходження. Що відпрацює модель бази даних, визначає її розробник. Що поміститься в полі змісту (a_contents), визначають об’єкти моделі, створеної розробником.
У такої ідеї є чотири моменти: звернення, сесія звернення, код історії звернень і конкретний зміст. Що таке звернення, яка система об’єктів повинна бути побудована – визначає розробник. Що розуміти під сесією (процесом роботи) – визначає розробник. Код історії – це можливість відкату за зверненнями.
Таблиці тут не мають ніякого відношення до предметної області. Є контролер звернень (is_cache), є протоколювання (is_customs), є історія звернень (is_histories). Інші таблиці визначаються розв’язуваної завданням.
По суті, таке рішення пропонує створювати власну ООБД на базі побудованої моделі бази даних предметної області розв’язуваної задачі. Тут є величезний плюс – це власне поняття даних, власна модель їх подання та взаємозв’язків між ними. Тут є фундамент – відмінна реляційна база даних. Тут не буде проблем щось шукати і щось недопонимать.
Модель: система об’єктів + СУБД
Змінити що-небудь в інформаційних технологіях практично неможливо. До реальної інформаційної революції ще далеко. Професійна свідомість розробників програмного забезпечення не збирається змінювати класичним традиціям. Але вихід із ситуації все ж таки є.
Використовуючи надійні сучасні системи управління базами даних як підстави для створення середовища існування власної моделі, можна досягти помітного успіху.
Будувати подання або модель даних доведеться в будь-якому випадку для розв’язання поставленої задачі, але треба це робити правильно: нехай це буде система об’єктів, а хороша СУБД – середовищем її існування.
