Проектування баз даних – це послідовний процес адаптації доступних знань і інструментальних засобів для представлення та обробки інформації.
Реальна область застосування, конкретне завдання, опис вхідного інформаційного потоку і загальні уявлення про процес обробки інформації поетапно складаються в певне концептуальне уявлення про те, що таке база даних в конкретному випадку і як з нею працювати.
Сучасна база даних
Реляційні відношення лежать в основі будь-якої інформаційної моделі. Рішення від Oracle еквівалентні MySQL по суті, але вони кардинально різняться за багатьма аспектами. Проектування баз даних – це також питання безпеки, обсягу інформації та міри відповідальності за достовірність даних, але вони вторинні у контексті питання проектування ефективної, надійної і зручної в користуванні бази даних.
Таблиці Excel – нічим не відрізняються від Oracle та MySQL в контексті прямокутних (реляційні) конструкцій: стовпці та рядки = одна клітинка імені стовпця (поля) і індексу вибірки (рядок). Якщо не враховувати міру й обсяг ручної праці, то, завдяки розвиненим засобам об’єднання клітинок по вертикалі і горизонталі, Excel випереджає навіть Oracle!
Excel, за його основної ідеї, ніколи «не світить» динаміка, функціонал Oracle, і перенести щось з одного аркуша на інший «по залишках» він не може. Тут Oracle перспективніше, але її міркування з питань міграції великих обсягів інформації та об’єднання формалізованих позицій з різних джерел залишають бажати кращого. Тут MySQL перспективніше: вона не ставить перед собою глобальних завдань, але свою роботу виконує чудово.
Реляційні відношення зручні, практичні і напрацьовані інструментальні засоби, від приватних рішень рівня Excel до глобальних обсягів Oracle, використовуються повсюдно, затребувані і у них є, гарантовано забезпечене роботою, майбутнє.
Сучасна БД – це таблиці, рядки, стовпці, індекси, оточені повним функціоналом, розвиненими додатковими засобами, які враховують множинні операції, великі навантаження і величезні обсяги.
Знання і досвід сучасних систем управління базами даних (СУБД) враховують не тільки питання надійності роботи, достовірності даних, регламентації доступу і вирішення питань безпеки, але і дають можливість відстежувати негативний зовнішній вплив, аналізувати можливі атаки і спроби навмисного заподіяння шкоди.
Сучасна БД – надійний фундамент будь-якого веб-ресурсу та локального застосування, можливість міграції інформації, трансформації і передачі даних, перетин і об’єднання різних уявлень.
Єдина істотна умова: висока кваліфікація розробника. Виконати ефективне проектування реляційних баз даних доступно фахівця, а частіше колективу фахівців і експертів галузі застосування розв’язуваної задачі.
Область застосування, можливе рішення і перешкоди
Інформація циркулює скрізь. Багато проекти прямо пов’язані з інтернетом, але фактор наявності формального представлення даних тут не краще фактору невизначеності при створенні веб-ресурсу для сталеливарного заводу.
Розвиток і масовий інтерес до інтернет-магазинам не дає підстав та можливості перенести досвід створення одного магазину на створення іншого. Фактор комерційної таємниці створює безліч перешкод переносу знань, хоча, по суті, слід розділяти власне магазин програмних інструментів, створених для цього магазину.
Безумовно, замовник заплатив і код сайту – це його власність. Характерна риса сучасності: перенесення знань і напрацювань між однотипними завданнями і суміжними областями застосування – неможливий і це проблема.
Парсинг – широкий спектр додатків для систем управління базами даних. Насамперед – це сканування інформації з інтернету. Не менш важливо зіставляти інформацію, яка накопичується в базі даних, і запити відвідувачів веб-сторінок.
Аналіз ключових слів також пов’язаний з необхідністю сформувати оптимальне рішення, але проектування баз даних Access може виявитися перспективніше, ніж на MS SQL Server або Oracle.
Список джерел інформації може бути динамічним. Динаміка може бути властива таблиць бази даних джерела, імен полів таблиць і правилами звернення (запиту). Проектування реляційних баз даних з безлічі джерел однозначно змушує вести розробку від вихідних даних, а не від оптимальної організації інформації, що збирається.
Є два моменти, які притаманні будь-якій базі даних:
- орієнтація на наповнення, алгоритм динамічного формування бази даних в пріоритеті;
- орієнтація на використання, структура бази даних важливіше і на її базі будується алгоритм використання інформації.
В будь-якій області застосування існує формальна модель вхідного інформаційного потоку, модель зберігання інформації – власне конструкція бази даних і модель (алгоритм) використання даних.
Різні процедури та етапи проектування
Основи проектування баз даних зазвичай укладаються в три стадії. Різні фахівці по-різному називають етапи роботи, але, по суті, є три позиції:
- концептуальне планування;
- логічне проектування;
- технічне виконання.
Практика вносить свій внесок в усталені традиції. Якою б складною не була сфера застосування і розв’язувана задача. Завжди потрібен вибір правильного інструментарію. Наприклад, потрібно збирати інформацію від відвідувачів веб-ресурсу, але зіставляти її потрібно з даними з MS SQL Server. Веб-ресурс розміщений на хостингу, на базі FreeBSD (інтернет, сервер Apache), а MS SQL Server в іншому місті доступний за розподіленої мережі компанії.
У даному рішенні вимагає спочатку вирішити приватну завдання: налагодити обмін даними з внутрішнім сервером.
Технічне виконання спільного завдання в обов’язковому порядку вплине на початковий етап: рідко коли проектування баз даних вдається виконати з чистого аркуша. Навіть за відпрацьованою технології вирішення завдань, область застосування розвивається, завжди потрібно зробити щось інакше, ніж це передбачалося спочатку.
Останнім часом багато теоретики і практичні фахівці оперують сутностями, як особливими даними. Це абстракції, які дозволяють описати модель інформації на вході, в процесі обробки і в остаточному результаті – базі даних.
Уявлення про даних та сутності
Проектування БД через абстракції і сутності: можливість створити інформаційну картину, визначити типи даних і зв’язки між ними.
Зазвичай таке проектування моделі бази даних закінчується графічною моделлю, застосуванням MS Visio або образотворчих засобів обраної СУБД. У Access свій варіант формування інформаційної картини, у MySQL – свій, а деякі системи управління сайтами зовсім приховують базу даних, нав’язуючи розробнику модель даних через свої власні сутності – об’єкти розв’язуваної задачі.
Характерна риса багатьох систем управління сайтами (CMS) – вони роблять «заявку» на рівень більшої абстракції при описі інформаційної області розв’язуваної задачі. Реальна база даних прихована, CMS пропонує розробнику власне уявлення про інформаційну картину світу.
В результаті, етапи проектування баз даних зводяться до дотримання принципових вимог і виконання кроків запропонованих творцями конкретної CMS. Немає нічого поганого у використанні ідей баз даних та їх проектування від Symfony або Bitrix, Zend або Yii, але для розробника – це «тягар».
В ідеалі, засоби проектування баз даних мають бути обрано і застосовано індивідуально, без урахування стороннього думки, але із застосуванням накопиченого досвіду і знань.
Ідеально, коли розробник має сертифікат від Oracle, але цілком прийнятно, коли кваліфікація розробника включає в себе уявлення про інформаційні ідеях Oracle та практичні знання по застосуванню MySQL.
У складних проектах і розподіленій обробці інформації важлива не лише база даних, але й джерела інформації, уявлення про потреби споживачів.
Етапи або колектив: баланс пріоритетів
Вимога системності має саме безпосереднє значення. Основи проектування баз даних включають в себе також етапність робіт, моніторинг проміжних результатів, переосмислення кожного виконаного етапу на підставі виконання наступного виду робіт:
- системність;
- етапність;
- зворотній зв’язок з будь-якого моменту часу, до самої початкової позиції.
Ці положення абстрактні, але присутні в будь-теоретичної і практичної технології створення ефективної бази даних.
Ніяка технологія не розвивається сама по собі, її рухають вперед люди. Кваліфікація колективу розробників має важливе значення. Інформаційна модель бази даних – це не тільки каркас, але і інформаційні потоки.
Що пріоритетніше: красива графіка в представленні структури бази даних або точний опис інформаційних потоків в динаміці – питання не тільки поставленого завдання і області застосування, але і думка колективу розробників в динаміці.
Кадри вирішують все, але в контексті: концептуальне проектування бази даних вирішує всі кваліфікація. Всі люди унікальні, а в області інформаційних систем існують і розвиваються уявлення конкретних людей.
Важливо сформувати колектив розробників, а не міфічні етапи проектування баз даних, запропоновані авторитетним експертом. Авторитет цього фахівця сформувався на базі конкретних робіт, в конкретний час. Виконати роботу потрібно сьогодні, нове завдання, сучасне обладнання, свіжі технології, …
Можливий зворотний варіант. Є Excel і Access і «рясні» дані в цих форматах з давніх часів, коли ще був живий і здравствовал Windows for Workgoups. Частково залишилися дані dBase і Quattro. Сьогодні ці слова вже забулися, але інформація залишилася, вона затребувана і потребує витягу і формуванні нових уявлень.
Старе і нове: баланс знань
Хмарні технології не рівня тим баз даних, що робила компанія Ashton-Tate. Те що колись купила Oracle, ніяк не можна порівняти з тим, що вона робить сьогодні. Але в програмуванні з тих давніх 80-х років залишилися змінні, алгоритми, функції, цикли та умови. Хіба що поняття процедури кануло в лету, а так все як було у стародавні часи, так і залишилося.
Навіть сучасні ідеї об’єктно-орієнтованого програмування має у класичні синтаксичні і семантичні «кайдани» минулого століття.
Що робити – програмування інерційно, а формалізація інформації та проектування інформаційних баз даних – радше процес, ніж результат. Етапність роботи – обов’язкова умова досягнення результату. Але хто рахував кількість ітерацій з проміжних етапів мало не до початку робіт?
Інформація завжди динамічна, ніщо не стоїть на місці: особливо предметна область завдання та вимоги користувачів. Кожен виконаний етап робіт дозволяє на новому рівні оцінити вже зроблене і те, що належить зробити.
Розглядати проектування структури бази даних як завдання і отримати остаточний результат – безперспективно. Як тільки БД буде здана в експлуатацію, обов’язково з’явиться нова ідея, навіть якщо інструментом створення бази даних «простенький» Excel, а не фантастично потужний і багатогранний продукт Oracle, манипулирующий мільйонами транзакцій, сотнями тисяч одночасно працюючих користувачів і террабайтами інформації.
В пріоритеті не структура бази даних, а формування кваліфікованого колективу фахівців плюс обов’язкове вимоги більшої динамічності результату, щоб по завершенні робіт не треба було звертатися до розробників, хоча б пару місяців.
Послідовне розвиток та/або стрибки у висоту
Windows – не база даних, але в ній є реліквія – реєстр. Файл hosts – це просто ідентифікація IP-адрес локального комп’ютера і символічних імен. Але через цей файл утворюються інформаційні потоки з різних доменів або в різні СУБД.
Зрозуміти багатоликий Windows як робочий комп’ютер або сервер можна, але обгрунтувати логіку версій цього продукту не вийде ніяк. PHP теж не база даних, але аргументи розробників, чому за версією 5 відразу йде версія 7, не послідовні. PHP – це інструмент доступу до MySQL, його синтаксис визначає, як формувати запити та отримувати відповіді від бази даних за допомогою діалекту SQL.
Приклади несумісність сучасних інструментів програмування і забезпечення роботи баз даних в останні роки стали нормою речей, але це не найоригінальніше. Що буде за версією Windows 10? Які перспективи йдуть слідом за Oracle Database 12c?
Інформація розробника-автора: «Oracle Database 11g Express Edition (Oracle Database XE) – це СУБД початкового рівня, заснована на програмному коді СУБД Oracle Database 11g Release 2. Дана СУБД безкоштовна для розробки, розгортання та продажу, швидко завантажується і проста в адмініструванні».
Думку розробника-користувача: «У 2013 р. компанія Oracle випустила версію Oracle Database 12c (версія 12.1.0.1), основними перевагами якої стали зниження вартості зберігання, висока доступність даних, простота консолідації баз даних і захист доступу до інформації».
Реальна практика: об’єктивне, результативне та ефективне логічне проектування бази даних доступно тільки колективу кваліфікованих розробників. Отримати працюючий результат не складно, складно формалізувати вхідні потоки інформації і визначити оптимальний фундамент.
У світ плавних форм від точних прямокутників
З приходом у світ об’єктно-орієнтованого програмування, сериализация даних отримала друге дихання. Дійсно, все навколо – лише рядки, бажано невизначеної довжини. Числа і дати – теж рядка символів.
Міць і об’єктивність реляційних відносин – безперечна, але хіба динаміка колонок і рядків завдає шкоди їх репутації? Таблиця – це просто дані, які можуть мати шапку (список колонок) або не мати рядків. Нехай таблиця – це просто сукупність даних, не обов’язково іменована.
Сукупність може бути однорідною і в ній можна виявити дані різної структури. Принципово, однорідність даних свідчить про опрацювання області застосування. Розподіл даних за типами та видами – ознака системності та об’єктивного підходу, але допустити ймовірність динаміки структур все ж доцільно.
Якщо вивести проектування та створення бази даних за межі жорстких конструкцій і припустити, що таблиця – це сукупність рядків не обов’язково однотипних і схожих за семантикою один на одного, то проектування БД кардинально зміниться.
Предметом роботи стане не опис структури бази даних, а динаміка руху інформації. Етапи робіт розподіляться на три центру ваги:
- вхідний інформаційний потік;
- перетворення і рух інформації всередині бази даних;
- вибірка даних для використання.
Поняття структури таблиці відсутня. Немає ні рядків, ні стовпців. Є абстракція – це, визначеної структури задовольняє конкретній точці в алгоритмі. Якщо більш конкретно, то функція обробки інформації вимагає певну інформацію в конкретному обсязі.
Обов’язкова вимога рекурсивности всіх функцій обробки інформації та орієнтація на функції, а не на дані, дозволяє проектувати базу даних у динаміці накопиченої інформації та вхідного потоку даних, які використовуються за ініціативою користувача, процесу або іншої функції.
Фактично: прийшов сигнал на користування, отриманий запит на вибірку, спрацював тригер в додатку і вхідна інформація через те, що вже є, надала потрібне рішення.
Фундаментальні знання і жорсткі конструкції
Знання – прерогатива людини, програми – тягар комп’ютерів. Розробник має право застосовувати зна
ння так, як вважатиме за потрібне в конкретній ситуації. Звичайна людина використовує масу баз даних, не надаючи цьому значення. Як організовані бази даних в голові звичайного людини, ніхто не знає, але кожний знає, як він веде свої справи, де що записує, що знаходить, і коли потрібно використовує.
Результат роботи програміста – на рівні програмки на “Бэйсике”, яка через ODBC витягує дані з сайту інтернет-магазину, еквівалентний титулованому розробнику Oracle, який робить запит на вибірку даних авиционно-космічного салону «МАКС». Обидва результату «застигають» в статиці з моменту завершення роботи. Це не активні знання, якими користується людина, в цьому зберігається секрет створення системи проектування баз даних.
Алгоритм не може бути фіксованим. Все повинно бути визначено в динаміці. Послуги кваліфікованих розробників безсумнівні, але лежать вони зовсім не у витончених формах рішень Oracle, MySQL або обмеженого в можливостях Access. Інша таблиця Excel може забезпечити динамічний контент і не вимагати участі програміста більш менш пристойне час після завершення робіт.
Питання в тому, наскільки якісно формалізована динаміка області застосування, а не структура бази даних.
Живі рішення
Неможливо планувати роботу так, щоб прив’язати до задачі колектив професійних розробників. Не те щоб колектив образився, але це не правильний підхід.
Завдання на проектування бази даних має бути сформульована так, щоб розроблений функціонал самовдосконалювався, накопичував знання та при виконанні своїх обов’язків» відштовхувався не від коду, створеного фахівцями, а від знань, набутих за допомогою цього коду.
