Прибуток:
- Здатність пояснювати концептуальні, логічні та фізичні моделі даних і концепції нормалізації та створювати чернетки зв’язків сутності за допомогою штучного інтелекту
- Можливість створювати словник даних, бізнес-правила та зв’язки таблиць зі структурованими підказками та перевіряти їх у реальній системі
- Здатність критично оцінювати пропозиції схем, згенеровані ШІ, з точки зору цілісності, унікальності та відповідності бізнес-правилам.
Інформаційна система, по суті, є структурою, яка зберігає дані впорядкованими. Моделювання даних — це завдання проектування фактів бізнесу (клієнт, замовлення, продукт, рахунок-фактура) та їх зв’язку один з одним у структурований спосіб. Хороша модель даних є основою точного звітування, швидких запитів і узгоджених даних; Погана модель є джерелом років непослідовності та постійної роботи з виправлення. У більшості випадків фахівець з MIS не кодує модель з нуля, а перевіряє, чи модель відповідає бізнес-правилам, і транслює модель між бізнес-підрозділом і ІТ.
Моделювання даних відбувається на трьох рівнях абстракції. Концептуальна модель (англ. conceptual) — найвищий рівень: які основні сутності існують і як вони пов’язані? «Клієнт розміщує замовлення, замовлення містить товар». Технічні деталі відсутні. Логічна модель визначає атрибути (поля), ключі та типи зв’язків кожної сутності; але він все ще не прив’язаний до конкретного продукту бази даних. Фізична модель (англ. physical) — це конкретна версія таблиць, типів даних та індексів у певній базі даних (наприклад, SQL Server, PostgreSQL). Ці три рівні є дедалі детальнішими версіями однієї ідеї.
Сутність-Зв'язок і ключі
Основною мовою моделі даних є модель Entity-Relationship (ER). Сутність можна розглядати як таблицю: клієнт, замовлення. Атрибутом є стовпець таблиці: ім'я, email, сума. Відносини — це спосіб зв’язку між сутностями: клієнт може мати багато замовлень (зв’язок «один до багатьох»).
Є дві важливі ключові концепції. Первинний ключ — це поле, яке однозначно ідентифікує кожен рядок у таблиці; наприклад CustomerID. Зовнішній ключ — це поле в одній таблиці, яке вказує на первинний ключ іншої таблиці; Ідентифікатор клієнта в таблиці замовлень пов’язує замовлення клієнта. Ці з’єднання забезпечують посилальну цілісність: замовлення не можна розмістити для клієнта, якого не існує.
Порада. Коли ШІ створює чернетку ER, це полегшує явний запит первинного ключа для кожної таблиці та зовнішнього ключа для кожного зв’язку. Але перевірте кожен зовнішній ключ, запропонований моделлю, на відповідність фактичному бізнес-правилу: іноді зв’язок, який ви вважаєте «один-до-багатьох», насправді є «багато-до-багатьох».
Нормалізація: запобігання рецидивам
Нормалізація - це процес зменшення надмірності та збереження цілісності шляхом поділу даних на логічні таблиці. Мета — зберігати однакову інформацію в одному місці. Наприклад, замість того, щоб знову і знову вводити адресу клієнта в кожному рядку замовлення, ви зберігаєте адресу один раз у таблиці «Клієнт» і пов’язуєте її із зовнішнім ключем із замовлення. Таким чином, коли адреса змінюється, ви оновлюєте її в одному місці; Інакше сотні замовлень матимуть різні адреси. Це називається аномалією оновлення.
Протилежністю нормалізації є денормалізація: навмисно допускається певне повторення заради швидкості звітування. У бізнес-системах (операційна база даних) зазвичай перевага віддається нормалізації, а в системах звітності (сховищі даних) часто перевага віддається денормалізації. Тож «нормалізація — це не завжди добре»; Рішення приймається відповідно до мети.
Словник даних: загальна мова
Словник даних — це документ, який визначає значення кожного поля, його тип, обмеження та бізнес-правила. Що означає поле «статус»? Які значення він може приймати (Очікує, Затверджено, Скасовано)? Це обов'язково? Без цього документа те саме поле буде інтерпретуватися різними командами по-різному, а звіт буде спотвореним. Словник даних є лінгва франка організації та одним із найцінніших результатів професіонала MIS. AI може швидко витягти вихідний чернетку словника даних із існуючої структури таблиці; Але лише одиниця, яка використовує ці дані, перевіряє справжній бізнес-сенс кожного поля.
Три міні-кейси: у цифрах
Випадок 1 — Вартість повторення. У дистриб’юторській компанії адреса клієнта зберігалася окремо в таблицях замовлень і рахунків-фактур. Коли клієнт переїжджав, адреса оновлювалася лише в одній таблиці; 1400 рахунків-фактур пішли на стару адресу і отримали відшкодування. Якби адреса була нормалізована в одній таблиці, одного оновлення було б достатньо. Проект рекультивації коштував 2 тижні.
Випадок 2 — Неправильний тип стосунків. Експерт MIS в освітньому закладі визнав зв’язок (один-до-багатьох) «Учень належить до класу» в моделі, згенерованій AI. Проте учні могли записатися більше ніж на один факультативний курс; Відношення насправді було «багато-до-багатьох», і була потрібна проміжна таблиця (Record). Помилку виявили на місцях, коли учень не зарахувався до другого класу. Якби припущення штучного інтелекту було підтверджено, воно було б підхоплено з самого початку.
Випадок 3 — Значення словника даних. Було визначено, що поле "policy_status" у страховій компанії по-різному інтерпретувалося 5 різними командами, тому той самий KPI давав 3 різні результати у звітах. Завдяки створенню словника даних на основі штучного інтелекту та досягненню єдиної угоди з бізнес-підрозділом було усунуто неузгодженість звітів, а час щомісячної звірки скорочено на 60%.
Слабка підказка / Сильна підказка
Слабка підказка:
Створіть базу даних електронної комерції.
Потужна підказка:
Ваша роль: Ви досвідчений модельєр даних. СКЛАДІТЬ ЛОГІЧНУ модель даних відповідно до наступних бізнес-правил. Правила:- Для кожної сутності: поля, первинний ключ, обов’язкові поля.- Для кожного зв’язку: тип (один-до-багатьох / багато-до-багатьох) і зовнішній ключ.- Запропонуйте проміжну таблицю у зв’язках «багато-до-багатьох».- Нормалізуйте до 3-ї нормальної форми; Якщо ви рекомендуєте навмисну денормалізацію, напишіть обґрунтування.- Позначте [ПОТРІБНО ПІДТВЕРДЖЕННЯ] будь-яке бізнес-правило, у якому ви не впевнені. Бізнес-правила:- Клієнт може розмістити кілька замовлень.- Замовлення містить кілька продуктів; Один продукт зустрічається в багатьох замовленнях.- Продукти мають категорії.[інші правила...]
Потужна підказка пояснює рівень моделі (логічний), правила ключа та зв’язку, ціль нормалізації та пункти, які потребують підтвердження.
Чотири шаблони, які можна копіювати
1) Чернетка словника даних:
Структура словника даних випливає з визначення таблиці. Для кожного поля: ім’я, тип, чи є воно обов’язковим, можливі значення, комерційне значення (мітка [ПРЕДБАЧЕННЯ], якщо це передбачення). Таблиця: [DDL або список полів]
2) Огляд нормалізації:
Чи існує ризик дублювання даних, аномалій оновлення та можливості нормалізації в структурі таблиці нижче? Для кожного висновку запишіть, яку нормальну форму він порушує, і свою пропозицію. Структура: [текст]
3) Чернетка ER із бізнес-правила:
Переведіть наведені нижче бізнес-правила в сутності, атрибути та зв’язки. Вкажіть тип кожного зв’язку (1-1, 1-N, N-N) і, якщо N-N, запропонуйте проміжну таблицю. Позначте неоднозначні правила. Правила: [текст]
4) Питання перевірки типу відносин:
Для кожного зв’язку в наведеній нижче моделі даних створіть бізнес-запитання «так/ні», яке перевірить правильність його типу (наприклад, «Чи може студент бути зарахований до кількох класів одночасно?»). Модель: [текст]
Порівняльна таблиця: рівні моделі
функція
концептуальний
логічний
фізичний
Деталь
принаймні
середній
більшість
ключ/відношення
Основні засоби
Ключі визначені
Включаючи індекс/тип
Залежить від бази даних
немає
немає
так
цільова аудиторія
господарська одиниця
аналітик
Розробник/DBA
Внесок ШІ
проект
сильний протяг
Чернетка, підтвердження DBA
Поширені помилки
- Розглядаючи зв’язок «багато до багатьох» як «один до багатьох». Це найпоширеніша помилка моделювання; Якщо проміжну таблицю забути, система не може зберегти фактичний стан.
- Розмістити все в одній таблиці. Збирання всіх полів в одній таблиці задля «простоти» призводить до дублювання та аномалій оновлення.
- Не написання словника даних. Один і той же KPI дає різні результати, якщо значення полів залишається в голові.
- Сліпо довіряти рекомендаціям AI щодо типів даних і обмежень. Модель може запропонувати «досить велику» область; Бізнес-правило визначає фактичні обмеження (наприклад, TR ID 11 цифр).
- Абсолютизуюча нормалізація. Надмірна нормалізація на рівні звітності уповільнює запит; Мета залежить від контексту.
Застереження: штучний інтелект може створювати моделі, які виглядають красиво, але порушують бізнес-правила. Для кожного зв'язку, запропонованого моделлю, питання "чи справді це так?" Задайте ділове питання. Модель даних є скелетом системи; Перелом кістяка потім дуже важко вилікувати.
Підсумовуючи
Моделювання даних — це процес структурування бізнес-фактів за допомогою сутностей, атрибутів і зв’язків, який відбувається на концептуальному, логічному та фізичному рівнях. Первинний і зовнішній ключі забезпечують посилальну цілісність; Нормалізація зменшує повторення, але денормалізація також є правомірною залежно від мети. Словник даних є загальною мовою організації. AI забезпечує значну швидкість у створенні чернеток ER, словників даних і переглядів нормалізації; однак типи зв’язків, типи даних і бізнес-семантика повинні бути підтверджені фактичним бізнес-правилом. Те, що модель виглядає добре, не означає, що вона правильна.
Аплікаційне завдання
Розглянемо «систему бібліотечної оренди»: учасники, книги, записи про оренду. (1) Майте чернетку логічної моделі, створену потужною підказкою. (2) Перевірте тип кожного зв’язку, який пропонує модель (зокрема, «чи може учасник мати більше одного примірника однієї книги?») за допомогою ділового запитання. (3) Знайти принаймні одне відношення «багато до багатьох» і визначити проміжну таблицю. (4) Напишіть рядки словника даних принаймні для 4 полів (ім’я, тип, обов’язкове, ділове значення). (5) Виділіть обмеження, яке може відповідати моделі, і поясніть, як ви це перевірите.
контрольний список
- [ ] Визначається первинний ключ кожної таблиці.
- [ ] Я перевірив тип кожного зв’язку з діловим запитанням.
- [ ] Я визначив проміжну таблицю для зв’язків «багато до багатьох».
- [ ] Я нормалізував або обґрунтував денормалізацію повторюваних даних.
- [ ] Я написав рядок словника даних для критичних полів.
- [ ] Я підтвердив пропозиції типу даних/обмеження ШІ щодо бізнес-правила.