Печалби:
- Способност за обяснение на концептуални, логически и физически модели на данни и концепции за нормализиране и създаване на чернови на обекти-връзки с подкрепата на изкуствен интелект
- Възможност за съставяне на речник на данни, бизнес правило и връзки на таблици със структурирани подкани и проверката им спрямо реалната система
- Способност за критична оценка на предложенията за схеми, генерирани от изкуствен интелект, по отношение на целостта, уникалността и съответствието с бизнес правилата.
Информационната система по същество е структура, която поддържа организирани данни. Моделирането на данни е задача за проектиране на фактите за даден бизнес (клиент, поръчка, продукт, фактура) и тяхната връзка помежду си по структуриран начин. Добрият модел на данни е в основата на точното отчитане, бързите заявки и последователните данни; Лошият модел е източник на години на непоследователност и повтаряща се корекция. През повечето време специалистът по MIS не кодира модела от нулата, а проверява дали моделът отговаря на бизнес правилата и превежда модела между бизнес единицата и ИТ.
Моделирането на данни протича на три нива на абстракция. Концептуалният модел (на английски концептуален) е най-високото ниво: какви основни единици съществуват и как са свързани? „Клиентът прави поръчка, поръчката включва продукта.“ Няма технически подробности. Логическият модел дефинира атрибутите (полетата), ключовете и типовете релации на всеки обект; но все още не е свързан с конкретен продукт за база данни. Физическият модел (на английски физически) е конкретната версия на таблиците, типовете данни и индексите в конкретна база данни (напр. SQL Server, PostgreSQL). Тези три нива са все по-подробни версии на една и съща идея.
Обект-връзка и ключове
Основният език на модела на данните е моделът Entity-Relationship (ER). Субектът може да се разглежда като таблица: клиент, поръчка. Атрибутът е колоната на таблицата: име, имейл, сума. Връзката е начинът, по който обектите са свързани: клиентът може да има много поръчки (връзка „един към много“).
Има две критични ключови концепции. Първичен ключ е полето, което уникално идентифицира всеки ред в таблица; например CustomerID. Външен ключ е поле в една таблица, което сочи към първичния ключ на друга таблица; Идентификаторът на клиента в таблицата с поръчки свързва поръчката на клиента. Тези връзки гарантират референтна цялост: не може да се направи поръчка за клиент, който не съществува.
Съвет: Когато AI генерира ER чернова, това улеснява изричното изискване на първичния ключ за всяка таблица и външния ключ за всяка връзка. Но проверете всеки външен ключ, предложен от модела спрямо действителното бизнес правило: понякога връзката, която смятате, че е „един към много“, всъщност е „много към много“.
Нормализиране: Предотвратяване на рецидив
Нормализацията е процес на намаляване на излишъка и запазване на целостта чрез разделяне на данните в логически таблици. Целта е една и съща информация да се съхранява на едно място. Например, вместо да въвеждате адреса на клиента отново и отново във всеки ред за поръчка, вие запазвате адреса веднъж в таблицата на клиента и го свързвате с външен ключ от поръчката. По този начин, когато адресът се промени, вие го актуализирате на едно място; В противен случай стотици поръчки ще имат различни адреси. Това се нарича аномалия при актуализиране.
Обратното на нормализирането е денормализирането: умишлено допускане на известно повторение в името на скоростта на отчитане. В бизнес системите (оперативна база данни) обикновено се предпочита нормализирането, а в системите за отчети (складове за данни) често се предпочита денормализирането. Така че „нормализирането не винаги е добро“; Решението се взема според целта.
Речник на данни: общ език
Речникът на данните е документ, който определя какво означава всяко поле, неговия тип, ограничения и бизнес правило. Какво означава полето "статус"? Какви стойности може да приема (Чакащо, Одобрено, Отменено)? Задължително ли е? Без този документ едно и също поле ще бъде интерпретирано по различен начин от различни екипи и отчетът ще бъде изкривен. Речникът на данните е lingua franca на организацията и един от най-ценните резултати на MIS професионалистите. AI може бързо да извлече първоначална чернова на речника на данните от съществуващата структура на таблицата; Но само единицата, използваща тези данни, проверява истинското бизнес значение на всяко поле.
Три мини калъфа: с числата
Случай 1 — Цената на повторението. В дистрибуторска компания адресът на клиента се съхраняваше отделно в таблиците с поръчки и фактури. Когато клиент се премести, адресът се актуализира само в една таблица; 1400 фактури отидоха на стария адрес и бяха възстановени. Ако адресът беше нормализиран в една таблица, една актуализация би била достатъчна. Проектът за саниране струва 2 седмици.
Случай 2 — Грешен тип връзка. Експерт по MIS в образователна институция призна връзката (един към много) „Ученикът принадлежи към клас“ в модела, генериран от AI. Въпреки това учениците могат да се запишат в повече от една избираема паралелка; Връзката всъщност беше много към много и беше необходима междинна таблица (Запис). Грешката беше открита на терен, когато ученик не успя да се запише във втори клас. Ако предложението на AI беше потвърдено, то щеше да бъде уловено от самото начало.
Случай 3 — Стойност на речника на данните. Установено е, че полето „policy_status“ в застрахователна компания е интерпретирано по различен начин от 5 различни екипа, така че един и същ KPI дава 3 различни резултата в отчетите. Чрез съставянето на базиран на изкуствен интелект речник на данни и постигането на единно споразумение с бизнес единицата, несъответствието в отчетите беше елиминирано и времето за месечна среща за съгласуване беше намалено с 60%.
Слаба подкана / Силна подкана
Слаба подкана:
Проектирайте база данни за електронна търговия.
Мощна подкана:
Вашата роля: Вие сте опитен моделиращ данни. СЪЗДАДЕТЕ ЛОГИЧЕН модел на данни съгласно следните бизнес правила. Правила: - За всеки обект: полета, първичен ключ, задължителни полета. - За всяка връзка: тип (един към много / много към много) и външен ключ. - Предложете междинна таблица в отношенията много към много. - Нормализиране до 3-та нормална форма; Ако препоръчвате умишлена денормализация, напишете обосновката.- Маркирайте [ИЗИСКВА СЕ ПОТВЪРЖДЕНИЕ] всяко бизнес правило, за което не сте сигурни. Бизнес правила:- Клиентът може да прави няколко поръчки.- Една поръчка съдържа множество продукти; Един продукт се среща в много поръчки.- Продуктите имат категории.[други правила...]
Мощната подкана изяснява нивото на модела (логически), ключовете и правилата за връзка, целта за нормализиране и точките, изискващи потвърждение.
Четири копируеми шаблона
1) Чернова на речника на данните:
Очертание на речник на данни следва от дефиницията на таблицата. За всяко поле: име, тип, задължително ли е, възможни стойности, бизнес значение (етикет [ПРЕДВИД] ако е прогноза). Таблица: [DDL или списък с полета]
2) Преглед на нормализиране:
Има ли някакъв риск от дублиране на данни, аномалия при актуализиране и възможност за нормализиране в структурата на таблицата по-долу? За всяка констатация запишете коя нормална форма нарушава и вашето предложение. Структура: [текст]
3) ER чернова от бизнес правило:
Преведете следните бизнес правила в обекти, атрибути и взаимоотношения. Посочете типа на всяка връзка (1-1, 1-N, N-N) и ако N-N, предложете междинна таблица. Маркирайте двусмислени правила. Правила: [текст]
4) Въпроси за проверка на типа връзка:
За всяка връзка в модела на данни по-долу генерирайте бизнес въпрос „да/не“, който ще тества коректността на неговия тип (напр. „Може ли ученик да бъде записан в повече от един клас едновременно?“). Модел: [текст]
Сравнителна таблица: Нива на модела
функция
концептуален
логично
физически
детайл
поне
среден
повечето
ключ/връзка
Основни активи
Дефинирани ключове
Включително индекс/тип
Зависи от базата данни
не
не
да
целева аудитория
бизнес единица
анализатор
Разработчик/DBA
Принос на AI
проект
силно течение
Чернова, потвърждение от DBA
Често срещани грешки
- Мислете за връзката много към много като едно към много. Това е най-честата грешка при моделиране; Ако междинната таблица е забравена, системата не може да запази действителното състояние.
- Поставяне на всичко в една маса. Събирането на всички полета в една таблица в името на "простотата" води до дублиране и аномалии при актуализиране.
- Без писане на речник с данни. Един и същ KPI дава различни резултати, когато значението на полетата остава в съзнанието.
- Сляпо доверие на препоръките на AI за типове данни и ограничения. Моделът може да предложи "достатъчно голяма" площ; Бизнес правилото определя действителните лимити (напр. TR ID 11 цифри).
- Абсолютизираща нормализация. Прекомерната нормализация на отчетния слой забавя заявката; Целта варира в зависимост от контекста.
Внимание: Изкуственият интелект може да създаде модели, които изглеждат добре, но нарушават бизнес правилата. За всяка връзка, предложена от модела, въпросът "наистина ли е така?" Задайте бизнес въпрос. Моделът на данните е скелетът на системата; Счупване на скелета е много трудно да се възстанови по-късно.
В обобщение
Моделирането на данни е процес на структуриране на бизнес факти с обекти, атрибути и връзки и протича на концептуално, логическо и физическо ниво. Първичните и външните ключове осигуряват референтна цялост; Нормализирането намалява повторението, но денормализирането също е легитимно в зависимост от целта. Речникът на данните е общият език на организацията. AI осигурява значителна скорост при изготвянето на ER чернови, речници на данни и прегледи за нормализиране; типовете релации, типовете данни и бизнес семантиката обаче трябва да бъдат потвърдени спрямо действителното бизнес правило. Това, че моделът изглежда добре, не означава, че е правилен.
Задача за приложение
Помислете за „библиотечна система за заемане“: членове, книги, записи за заем. (1) Имате чернова на логически модел, създадена от мощната подкана. (2) Тествайте вида на всяка връзка, предложена от модела (по-конкретно, „може ли член да има повече от едно копие на една и съща книга?“) с бизнес въпрос. (3) Намерете поне една връзка много към много и дефинирайте междинна таблица. (4) Напишете редове от речник на данни за поне 4 полета (име, тип, задължително, бизнес значение). (5) Маркирайте ограничение, което моделът може да е наложил, и обяснете как бихте го проверили.
контролен списък
- [ ] Първичният ключ на всяка таблица е дефиниран.
- [ ] Проверих типа на всяка връзка с бизнес въпроса.
- [ ] Дефинирах междинна таблица за релации много към много.
- [ ] Нормализирах или оправдах денормализирането на дублирани данни.
- [ ] Написах ред от речник на данни за критични полета.
- [ ] Потвърдих предложенията за тип данни/ограничение на AI спрямо бизнес правилото.