Добивки:
- Способност да се објаснат концептуални, логички и физички модели на податоци и концепти за нормализација и да се произведуваат нацрти за врска со ентитетите со поддршка на вештачка интелигенција
- Способност за изготвување речник на податоци, деловни правила и односи со табели со структурирани потсетници и нивна проверка во однос на реалниот систем
- Способност критички да се проценат предлозите за шеми генерирани од вештачката интелигенција во однос на интегритетот, посебноста и усогласеноста со деловните правила.
Информацискиот систем во суштина е структура која ги одржува податоците организирани. Моделирањето на податоците е задача да се дизајнираат фактите на бизнисот (клиент, нарачка, производ, фактура) и нивниот однос меѓу себе на структуриран начин. Добриот модел на податоци е основа за точно известување, брзи прашања и конзистентни податоци; Лошиот модел е извор на години на недоследност и повторлива работа за корекција. Поголемиот дел од времето, професионалецот за MIS не го шифрира моделот од нула, туку потврдува дека моделот е во согласност со деловните правила и го преведува моделот помеѓу деловната единица и ИТ.
Моделирањето на податоците се одвива на три нивоа на апстракција. Концептуалниот модел (англиски концептуален) е највисоко ниво: кои главни ентитети постојат и како се поврзани? „Клиентот поставува нарачка, нарачката го вклучува производот“. Нема технички детали. Логичкиот модел ги дефинира атрибутите (полињата), клучевите и типовите на врски на секој ентитет; но сè уште не е врзан за одреден производ од базата на податоци. Физичкиот модел (англиски физички) е конкретна верзија на табелите, типовите на податоци и индексите во одредена база на податоци (на пр. SQL Server, PostgreSQL). Овие три нивоа се сè подетални верзии на истата идеја.
Ентитет-однос и клучеви
Основниот јазик на моделот на податоци е моделот Entity-Relationship (ER). Ентитетот може да се смета како табела: Клиент, Нарачка. Атрибутот е колоната на табелата: име, е-пошта, износ. Односот е начинот на кој ентитетите се поврзани: клиентот може да има многу нарачки (однос еден-на-многу).
Постојат два критични клучни концепти. Примарен клуч е полето кое уникатно го идентификува секој ред во табелата; на пример CustomerID. Странски клуч е поле во една табела што укажува на примарниот клуч од друга табела; CustomerID во табелата за нарачки поврзува која е нарачката на клиентот. Овие врски обезбедуваат референцијален интегритет: не може да се направи нарачка за клиент што не постои.
Совет: кога вештачката интелигенција генерира нацрт на ЕР, полесно е експлицитно да се побара примарниот клуч за секоја табела и странскиот клуч за секоја врска. Но, проверете го секој странски клуч предложен од моделот во однос на вистинското деловно правило: понекогаш врската што мислите дека е „еден-на-многу“ е всушност „многу-на-многу“.
Нормализација: Спречување на повторување
Нормализацијата е процес на намалување на вишокот и зачувување на интегритетот со делење на податоците во логички табели. Целта е да се задржат истите информации на едно место. На пример, наместо да ја пишувате адресата на клиентот одново и одново во секоја линија за нарачка, ја задржувате адресата еднаш во табелата Клиент и ја поврзувате со странски клуч од нарачката. На овој начин, кога адресата се менува, ја ажурирате на едно место; Во спротивно, стотици нарачки ќе имаат различни адреси. Ова се нарекува аномалија на ажурирање.
Спротивно на нормализацијата е денормализацијата: намерно дозволување на одредено повторување заради брзината на известување. Во деловните системи (оперативна база на податоци), генерално се претпочита нормализацијата, а во системите за известување (складиште на податоци), често се претпочита денормализација. Значи „нормализацијата не е секогаш добра“; Одлуката се носи според намената.
Речник на податоци: заеднички јазик
Речник на податоци е документ кој дефинира што значи секое поле, неговиот тип, ограничувања и деловно правило. Што значи полето „статус“? Кои вредности може да ги земе (не чека, одобрено, откажано)? Дали е тоа задолжително? Без овој документ, истото поле ќе се толкува различно од различни тимови и извештајот ќе биде искривен. Речникот со податоци е лингва франка на организацијата и еден од највредните резултати на професионалниот MIS. Вештачката интелигенција може брзо да извлече нацрт на почетниот речник на податоци од постоечката структура на табелата; Но, само единицата што ги користи тие податоци го потврдува вистинското деловно значење на секое поле.
Три мини случаи: според бројките
Случај 1 - Трошоците за повторување. Во дистрибутивната компанија, адресата на клиентот се чуваше посебно и во табелите за нарачки и во фактури. Кога клиентот се преселил, адресата се ажурирала само во една табела; 1.400 фактури отишле на стара адреса и биле вратени. Ако адресата е нормализирана во една табела, едно ажурирање би било доволно. Проектот за санација чинеше 2 недели.
Случај 2 - Погрешен тип на врска. Експерт за МИС во образовна институција ја призна врската (еден на многу) „Ученикот припаѓа на класа“ во моделот генериран со вештачка интелигенција. Сепак, учениците можеа да се запишат во повеќе од една изборна паралелка; Врската всушност беше многу-на-многу и беше потребна средна табела (Запис). Грешката била откриена на терен кога ученик не успеал да се запише во второ одделение. Ако предлогот на вештачката интелигенција беше потврден, ќе беше фатен од самиот почеток.
Случај 3 — Речник на вредноста на податоците. Утврдено е дека полето „policy_status“ во осигурителна компанија различно се толкува од 5 различни тимови, па така истиот KPI дал 3 различни резултати во извештаите. Со изготвување на речник на податоци напојуван со вештачка интелигенција и постигнување единствен договор со деловната единица, беше елиминирана недоследноста на извештаите, а времето на месечните состаноци за усогласување беше намалено за 60%.
Слаба навестување / Силен навестување
Слаба навестување:
Дизајнирајте база на податоци за е-трговија.
Моќен потсетник:
Вашата улога: Вие сте искусен моделар на податоци. НАСТАВЕТЕ ЛОГИЧКИ модел на податоци според следниве деловни правила. Правила:- За секој ентитет: полиња, примарен клуч, потребни полиња.- За секоја врска: тип (еден-на-многу / многу-на-многу) и странски клуч.- Предложете средна табела во многу-до-многу односи.- Нормализирајте ја до 3-та форма; Ако препорачувате намерна денормализација, напишете го образложението.- Обележете го секое деловно правило за кое не сте сигурни. Деловни правила: - Клиентот може да направи повеќе нарачки.- Нарачката содржи повеќе производи; Еден производ се јавува во многу нарачки.- Производите имаат категории.[други правила...]
Моќниот промпт го разјаснува нивото на моделот (логично), клучните и правилата за врска, целта за нормализација и точките за кои е потребна потврда.
Четири шаблони за копирање
1) Нацрт речник на податоци:
Преглед на речник на податоци следи од дефиницијата на табелата. За секое поле: име, тип, дали е задолжително, можни вредности, деловно значење (етикета[ПРЕДВИДУВАЊЕ] ако е предвидување). Табела: [ДДЛ или список со полиња]
2) Преглед на нормализација:
Дали постои ризик од дупликат податоци, аномалија на ажурирање и можност за нормализирање во структурата на табелата подолу? За секој наод запишете која нормална форма ја нарушува и вашиот предлог. Структура: [текст]
3) нацрт на ER од деловното правило:
Преведете ги следните деловни правила во ентитети, атрибути и односи. Наведете го типот на секоја врска (1-1, 1-N, N-N) и ако N-N, предложете средна табела. Обележете двосмислени правила. Правила: [текст]
4) Прашања за проверка на типот на врската:
За секоја врска во моделот на податоци подолу, генерирајте „да/не“ деловно прашање што ќе ја тестира точноста на неговиот тип (на пр. „Дали студент може да се запише во повеќе од една паралелка истовремено?“). Модел: [текст]
Табела за споредување: Нивоа на модел
карактеристика
концептуален
логично
физички
Детал
барем
средно
повеќето
клуч/врска
Главни средства
Дефинирани копчиња
Вклучувајќи индекс/тип
Зависи од базата на податоци
бр
бр
Да
целна публика
деловна единица
аналитичар
Програмер/DBA
Придонес на ВИ
нацрт
силен нацрт
Нацрт, потврда за DBA
Вообичаени грешки
- Размислувајќи за врската многу-на-многу како еден-на-многу. Ова е најчестата грешка при моделирање; Ако се заборави средната табела, системот не може да ја задржи вистинската состојба.
- Ставајќи сè во една маса. Собирањето на сите полиња во една табела заради „едноставност“ предизвикува дуплирање и аномалии на ажурирање.
- Не пишување речник на податоци. Истиот KPI дава различни резултати кога значењето на полињата останува во умот.
- Слепо верувајќи во препораките на ВИ за типови на податоци и ограничувања. Моделот може да предложи „доволно голема“ површина; Деловното правило ги одредува вистинските граници (на пр. TR ID 11 цифри).
- Апсолутизирачка нормализација. Прекумерната нормализација на слојот за известување го успорува барањето; Целта варира во зависност од контекстот.
Внимание: Вештачката интелигенција може да произведе модели кои изгледаат убаво, но ги прекршуваат деловните правила. За секоја врска предложена од манекенката се поставува прашањето „дали е навистина вака?“ Поставете деловно прашање. Моделот на податоци е скелетот на системот; Фрактурата на скелетот е многу тешко да се поправи подоцна.
Сумирано
Моделирањето на податоци е процес на структурирање на деловните факти со ентитети, атрибути и врски и продолжува на концептуално, логично и физичко ниво. Примарните и странските клучеви обезбедуваат референцијален интегритет; Нормализацијата го намалува повторувањето, но и денормализацијата е легитимна во зависност од целта. Речникот со податоци е заеднички јазик на организацијата. Вештачката интелигенција обезбедува значителна брзина во производството на нацрти на ЕР, речници со податоци и прегледи за нормализација; сепак, типовите на врски, типовите на податоци и деловната семантика мора да се потврдат во однос на вистинското деловно правило. Само затоа што моделот изгледа добро не значи дека е исправен.
Задача за апликација
Размислете за „систем за позајмување библиотеки“: членови, книги, евиденција за заем. (1) Имајте нацрт на логички модел произведен од моќниот промпт. (2) Тестирајте го типот на секоја врска што ја предлага моделот (конкретно, „може ли член да има повеќе од еден примерок од истата книга?“) со деловно прашање. (3) Најдете барем една врска многу-на-многу и дефинирајте средна табела. (4) Напишете линии на речник на податоци за најмалку 4 полиња (име, тип, задолжително, деловно значење). (5) Означете го ограничувањето што можеби го има поставено моделот и објаснете како би го потврдиле.
листа за проверка
- [ ] Примарниот клуч на секоја табела е дефиниран.
- [ ] Го потврдив типот на секоја врска со деловното прашање.
- [ ] Дефинирав средна табела за врски многу-до-многу.
- [ ] Ја нормализирав или оправдав денормализацијата на дупликатите податоци.
- [ ] Напишав линија за речник на податоци за критичните полиња.
- [ ] Ги потврдив предлозите за тип на податоци/ограничувања на вештачката интелигенција против деловните правила.