3.1: Що таке база даних?

Last updated
Save as PDF

Page ID: 66398

$ \newcommand{\vecs}[1]{\overset { \scriptstyle \rightharpoonup} {\mathbf{#1}} } $ $ \newcommand{\vecd}[1]{\overset{-\!-\!\rightharpoonup}{\vphantom{a}\smash {#1}}} $$\newcommand{\id}{\mathrm{id}}$ $ \newcommand{\Span}{\mathrm{span}}$ $ \newcommand{\kernel}{\mathrm{null}\,}$ $ \newcommand{\range}{\mathrm{range}\,}$ $ \newcommand{\RealPart}{\mathrm{Re}}$ $ \newcommand{\ImaginaryPart}{\mathrm{Im}}$ $ \newcommand{\Argument}{\mathrm{Arg}}$ $ \newcommand{\norm}[1]{\| #1 \|}$ $ \newcommand{\inner}[2]{\langle #1, #2 \rangle}$ $ \newcommand{\Span}{\mathrm{span}}$ $\newcommand{\id}{\mathrm{id}}$ $ \newcommand{\Span}{\mathrm{span}}$ $ \newcommand{\kernel}{\mathrm{null}\,}$ $ \newcommand{\range}{\mathrm{range}\,}$ $ \newcommand{\RealPart}{\mathrm{Re}}$ $ \newcommand{\ImaginaryPart}{\mathrm{Im}}$ $ \newcommand{\Argument}{\mathrm{Arg}}$ $ \newcommand{\norm}[1]{\| #1 \|}$ $ \newcommand{\inner}[2]{\langle #1, #2 \rangle}$ $ \newcommand{\Span}{\mathrm{span}}$

Інтеграція даних з розрізнених джерел є основною проблемою в промисловості сьогодні. Дослідження 2008 року [BH08] показало, що інтеграція даних становить 40% бюджетів ІТ (інформаційних технологій), і що ринок програмного забезпечення для інтеграції даних становив 2,5 мільярда доларів у 2007 році і збільшується зі швидкістю понад 8% на рік. Іншими словами, це головна проблема; але що це таке?

База даних являє собою систему переплетення таблиць. Дані стають інформацією, коли вони зберігаються в заданому формуванні. Тобто цифри та букви нічого не означають, поки вони не будуть організовані, часто в систему переплетених таблиць. Організована система переплетення таблиць називається базою даних. Ось улюблений приклад:

$Знімок екрана 2021-01-11 о 4.38.57 PM.png$

(3.1) Ці дві таблиці блокуються за допомогою спеціального лівого стовпця, розмежованого вертикальною лінією; вона називається стовпцем ID. Стовпець ID першої таблиці називається «Співробітник», а стовпець ID другої таблиці називається «Відділ». Записи в стовпці ID (наприклад, 1, 2, 3 або 101, 102) схожі на мітки рядків; вони вказують цілий рядок таблиці, в якій вони знаходяться. Таким чином, кожна мітка рядка повинна бути унікальною (жодні два рядки в таблиці не можуть мати однакову мітку), щоб вона могла однозначно вказувати свій рядок.

Кожен стовпець ідентифікатора таблиці та набір унікальних ідентифікаторів, знайдених у ньому, є тим, що дозволяє переплетення, згадане вище. Дійсно, інші записи в різних таблицях можуть посилатися на рядки в даній таблиці, використовуючи її ID стовпець. Наприклад, кожен запис у стовпці WorkSin посилається на відділ для кожного співробітника; кожен запис у стовпці Mngr (менеджер) посилається на співробітника для кожного співробітника, а кожен запис у стовпці Secr (секретар) посилається на співробітника для кожного відділу. Управління всіма цими перехресними посиланнями є метою баз даних.

Озираючись назад на Eq. (3.1), можна помітити, що кожен стовпчик без ідентифікатора, знайдений в будь-якій таблиці, є посиланням на якийсь мітку. Деякі з них, а саме WorkSin, Mngr та Secr, є внутрішніми посиланнями, які часто називають зовнішніми ключами; вони посилаються на рядки (ключі) у стовпці ID деякої (зовнішньої) таблиці. Інші, а саме fName та DName, є зовнішніми посиланнями; вони посилаються на рядки або цілі числа, які також можна розглядати як мітки, значення яких відоме ширше. Внутрішні довідкові мітки можуть бути змінені до тих пір, поки зміна є послідовною - 1 може бути замінений на 1001 скрізь, не змінюючи значення, тоді як зовнішні довідкові етикетки, безумовно, не можуть! Зміна Рут на Брюса скрізь змінила б те, як люди розуміли дані.

Довідкова структура для даної бази даних - тобто як таблиці блокуються за допомогою зовнішніх ключів - говорить нам щось про те, яка інформація мала на меті зберігатися в ній. Візуалізувати опорну структуру для еквалайзера (3.1) можна графічно наступним чином:

$Знімок екрана 2021-01-11 о 4.45.29 PM.png$

Це свого роду «діаграма Хассе для бази даних», подібно до діаграм Хассе для попередніх замовлень у Зауваження 1.39. Як ви повинні читати його?

Дві таблиці з Eq. (3.1) представлені на графіку (3.2) двома чорними вузлами, які мають таку саму назву, як стовпці ID: Співробітник і Відділ. Існує ще один вузол, намальований білим, а не чорним, який представляє зовнішній еталонний тип рядків, таких як «Алан», «Альфа» та «Продажі». Стрілки на діаграмі представляють стовпці таблиць, що не мають ідентифікатора; вони вказують у напрямку відліку: WorkSin посилає співробітника до відділу.

Вправа 3.3.

Підрахуйте кількість стовпців без ідентифікаторів у еквалайзері (3.1). Підрахуйте кількість стрілок (зовнішніх ключів) в ур. (3.2). Їх повинно бути однакове число в даному випадку; чи це збіг? ♦

Діаграму в стилі Hasse, подібну до схеми в Eq. (3.2), можна назвати схемою бази даних; вона представляє, як організовується інформація, формування, в якому зберігаються дані. Для забезпечення цілісності даних до схеми можна додати правила, які іноді називають «бізнес-правилами». Якщо ці правила порушуються, то відомо, що введені дані не відповідають тому, як задумували розробники баз даних. Наприклад, дизайнери можуть виконувати правила, які говорять

• секретар кожного відділу повинен працювати в цьому відділі;

• керівник кожного співробітника повинен працювати в тому ж відділі, що і співробітник.

Роблячи це змінює схему, скажімо, від «EasySchema» (3.2) до «MySchema» нижче.

$Знімок екрана 2021-01-11 в 4.49.42 PM.png$

Іншими словами, різниця в тому, що EasySchema плюс обмеження дорівнює MySchema. Незабаром ми побачимо, що схеми баз даних є категоріями C, що самі дані задаються функтором C → Set, і що бази даних можуть бути зіставлені один з одним за допомогою функторів C → D. Іншими словами, існує відносно велике перекриття між теорією баз даних та теорією категорій. Це було опрацьовано в ряді робіт; див. Розділ 3.6. Він також був реалізований у робочому програмному забезпеченні під назвою FQL, що розшифровується як мова функціональних запитів. Ось приклад коду FQL для схеми, показаної вище:

$Знімок екрана 2021-01-11 в 4.51.04 PM.png$

Зв'язок між базами даних. Ми вже говорили, що бази даних призначені для зберігання інформації про щось. Але різні люди або організації можуть розглядати одну і ту ж річ по-різному. Наприклад, один банк зберігає свої фінансові записи за європейськими стандартами, а інший - за японськими стандартами. Якщо ці два банки об'єднаються в один, вони повинні мати можливість обмінюватися своїми даними, незважаючи на відмінності у формі схем баз даних.

Такі проблеми є величезними і заплутаними в цілому, адже бази даних часто містять сотні або тисячі переплетених таблиць. Більш того, ці проблеми виникають частіше, ніж просто тоді, коли компанії хочуть об'єднатися. Досить часто дана компанія щодня переміщує дані між базами даних. Причина в тому, що різні способи організації інформації зручні для різних цілей. Подібно до того, як ми упаковуємо одяг у валізу під час подорожей, але використовуємо шафу вдома, як правило, немає одного найкращого способу що-небудь організувати.

Теорія категорій передбачає математичний підхід до перекладу між цими різними організаційними формами. Тобто він формалізує свого роду автоматизований процес реорганізації, який називається міграцією даних, який приймає дані, які щільно вписуються в одну схему, і переміщує їх в іншу.

Ось простий випадок. Уявіть, що авіакомпанія має дві різні бази даних, можливо, створені в різний час, які містять приблизно однакові дані.

$Знімок екрана 2021-01-11 о 4.51.45 PM.png$

Схема А має більш детальну інформацію, ніж схема B - місце авіакомпанії може бути першого класу або економ-але вони приблизно однакові. Ми побачимо, що вони можуть бути з'єднані функтором, і що дані, що відповідають A, можуть бути перенесені через цей функтор до схеми B і навпаки.

Статистика на початку цього розділу показує, що подібного роду проблема - коли виникає в масштабі підприємства - продовжує виявлятися складною і дорогою. Якщо хтось намагається перемістити дані з вихідної схеми до цільової схеми, перенесені дані можуть не вписатися в цільову схему або не задовольнити деякі з її обмежень. Це відбувається напрочуд часто в світі бізнесу: ніч може бути витрачена на переміщення даних, а на ранок виявляється, що прибули зламані і непридатні для подальшого використання. Насправді, вважається, що більше половини проектів міграції баз даних зазнають невдачі.

У цьому розділі ми обговоримо теоретико-категорійний метод міграції даних. Використовуючи категорії та функтори, можна заздалегідь довести, що задана міграція даних не провалиться, тобто що результат гарантовано впишеться в цільову схему і задовольнить всі її обмеження.

Матеріал цього розділу потрапляє в суть теорії категорій: зокрема, ми обговорюємо категорії, функтори, природні перетворення, ад'юнкції, межі та коліміти. Насправді багато з цих ідей були присутні в обговоренні вище:

• Зображення схеми, наприклад, Eq. (3.4), зображують категорії C.

Екземпляри, наприклад, Eq. (3.1) є функторами від C до певної категорії під назвою Set.
Неявне відображення в еквалайзері (3.5), який приймає місця економ та першого класу в A до місць авіакомпанії в B, є функтором A → B.
Поняття міграції даних для переміщення даних між схемами формалізовано суміжними функторами.

Починаємо в Розділі 3.2 з визначення категорій і купи різних

різновиди прикладів. У розділі 3.3 ми повертаємо бази даних, зокрема їх екземпляри та карти між ними, шляхом обговорення функторів та природних перетворень. У розділі 3.4 ми обговорюємо міграцію даних за допомогою доповнень, які узагальнюють зв'язки Галуа, які ми ввели в Розділ 1.4. Нарешті, у розділі 3.5 ми даємо бонусний розділ про ліміти та обмеження. $^{1}$