Јединица 3 / 11

Моделирање података, речник података и архитектура података предузећа

Добици:

  • Способност да објасни концептуалне, логичке и физичке моделе података и концепте нормализације и да направи нацрте ентитет-однос уз подршку вештачке интелигенције
  • Способност израде нацрта речника података, пословних правила и односа табела са структурираним упитима и верификовање их у односу на стварни систем
  • Способност критичке процене предлога шема које је генерисала вештачка интелигенција у смислу интегритета, сингуларности и усклађености са пословним правилима.

Информациони систем је у суштини структура која одржава податке организованим. Моделирање података је задатак дизајнирања чињеница пословања (купац, поруџбина, производ, фактура) и њиховог међусобног односа на структурисан начин. Добар модел података је основа тачног извештавања, брзих упита и доследних података; Лош модел је извор година недоследности и понављајућих исправљачких радова. Већину времена, МИС професионалац не кодира модел од нуле, већ проверава да ли је модел у складу са пословним правилима и преводи модел између пословне јединице и ИТ-а.

Моделирање података се одвија на три нивоа апстракције. Концептуални модел (енглески концептуал) је највиши ниво: који главни ентитети постоје и како су повезани? „Купац наручује, поруџбина укључује производ.“ Нема техничких детаља. Логички модел дефинише атрибуте (поља), кључеве и типове односа сваког ентитета; али још увек није везан за одређени производ базе података. Физички модел (енглески физички) је конкретна верзија табела, типова података и индекса у одређеној бази података (нпр. СКЛ Сервер, ПостгреСКЛ). Ова три нивоа су све детаљније верзије исте идеје.

Ентитет-однос и кључеви

Основни језик модела података је модел ентитет-однос (ЕР). Ентитет се може замислити као табела: купац, налог. Атрибут је колона табеле: име, емаил, износ. Однос је начин на који су ентитети повезани: купац може имати много поруџбина (однос један-према-више).

Постоје два кључна критична концепта. Примарни кључ је поље које јединствено идентификује сваки ред у табели; на пример ЦустомерИД. Страни кључ је поље у једној табели које указује на примарни кључ друге табеле; ЦустомерИД у табели поруџбина повезује поруџбину која је то купца. Ове везе обезбеђују референтни интегритет: наруџбина се не може поставити за купца који не постоји.

Савет: Када АИ генерише ЕР нацрт, олакшава експлицитно тражење примарног кључа за сваку табелу и страног кључа за сваку релацију. Али проверите сваки страни кључ који је предложио модел у односу на стварно пословно правило: понекад је однос за који мислите да је „један према више“ заправо „више-према-више“.

Нормализација: Спречавање понављања

Нормализација је процес смањења редунданције и очувања интегритета поделом података у логичке табеле. Циљ је да исте информације буду на једном месту. На пример, уместо да куцате адресу купца изнова и изнова у сваки ред поруџбине, адресу задржавате једном у табели Купци и повезујете је са страним кључем из поруџбине. На овај начин, када се адреса промени, ажурирате је на једном месту; У супротном, стотине поруџбина ће имати различите адресе. Ово се зове аномалија ажурирања.

Супротност нормализацији је денормализација: намерно допуштање неког понављања ради брзине извештавања. У пословним системима (оперативна база података), нормализација је генерално пожељна, а у системима извештавања (складиште података), денормализација се често даје предност. Дакле, „нормализација није увек добра“; Одлука се доноси према намени.

Речник података: заједнички језик

Речник података је документ који дефинише шта свако поље значи, његов тип, ограничења и пословно правило. Шта значи поље „статус“? Које вредности може да поприми (На чекању, Одобрено, Отказано)? Да ли је то обавезно? Без овог документа, исто поље ће различито тумачити различити тимови и извештај ће бити искривљен. Речник података је лингуа франца организације и један од највреднијих производа МИС професионалаца. АИ може брзо издвојити почетни нацрт речника података из постојеће структуре табеле; Али само јединица која користи те податке потврђује право пословно значење сваког поља.

Три мини случаја: према бројевима

Случај 1 — Трошкови понављања. У дистрибутивном предузећу, адреса купца се чувала одвојено у табели наруџби и фактура. Када се клијент преселио, адреса је ажурирана у само једној табели; На стару адресу је отишло 1.400 рачуна и враћено им је. Ако је адреса нормализована у једној табели, једно ажурирање би било довољно. Пројекат санације коштао је 2 недеље.

Случај 2 — Погрешан тип везе. Стручњак МИС-а у образовној институцији је признао (један-према-више) однос „Ученик припада класи” у моделу генерисаном вештачком интелигенцијом. Међутим, ученици су могли да се упишу на више од једног изборног часа; Однос је заправо био много-према-више и била је потребна међутабела (запис). Грешка је откривена на терену када ученик није успео да се упише у други разред. Да је сугестија АИ била потврђена, била би ухваћена од почетка.

Случај 3 — Вредност речника података. Утврђено је да поље „полици_статус“ у осигуравајућем друштву различито тумачи 5 различитих тимова, па је исти КПИ дао 3 различита резултата у извештајима. Израдом речника података заснованог на вештачкој интелигенцији и постизањем јединственог договора са пословном јединицом, недоследност извештаја је елиминисана и време месечног састанка за усаглашавање смањено је за 60%.

Слаба порука / јака промпт

Слабо обавештење:

Дизајнирајте базу података за е-трговину.

Снажан упит:

Ваша улога: Ви сте искусан моделар података. НАПРАВИТЕ ЛОГИЧКИ модел података према следећим пословним правилима. Правила:- За сваки ентитет: поља, примарни кључ, обавезна поља.- За сваку релацију: тип (један-према-више/више-према-више) и страни кључ.- Предложите средњу табелу у односима много-према-више.- Нормализација форме до ; Ако препоручујете намерну денормализацију, напишите образложење.- Означите [ПОТРЕБНА ПОТВРДА] свако пословно правило у које нисте сигурни. Пословна правила:- Клијент може да пошаље више поруџбина.- Поруџбина садржи више производа; Један производ се јавља у више поруџбина.- Производи имају категорије.[друга правила...]

Моћни промпт појашњава ниво модела (логички), кључна правила и правила односа, циљ нормализације и тачке које захтевају потврду.

Четири шаблона за копирање

1) Нацрт речника података:

Нацрт речника података следи из дефиниције табеле. За свако поље: назив, тип, да ли је обавезно, могуће вредности, пословно значење (ознака[ПРЕДИКЦИЈА] ако је предвиђање). Табела: [ДДЛ или листа поља]

2) Преглед нормализације:

Да ли постоји ризик од дуплирања података, аномалије ажурирања и могућности за нормализацију у структури табеле испод? За сваки налаз напишите који нормални облик крши и ваш предлог. Структура: [текст]

3) ЕР нацрт из пословног правила:

Преведите следећа пословна правила у ентитете, атрибуте и односе. Наведите тип сваке везе (1-1, 1-Н, Н-Н) и ако Н-Н, предложите међутабелу. Означите двосмислена правила. Правила: [текст]

4) Питања за верификацију врсте везе:

За сваки однос у моделу података у наставку, генеришите пословно питање „да/не“ које ће тестирати исправност његовог типа (нпр. „Да ли ученик може бити уписан у више од једног разреда у исто време?“). Модел: [текст]

Упоредни графикон: Нивои модела

карактеристика

концептуални

логично

физички

Детаљ

барем

средње

већина

кључ/релација

Главна имовина

Дефинисани кључеви

Укључујући индекс/тип

Зависи од базе података

бр

бр

Да

циљна публика

пословна јединица

аналитичар

Програмер/ДБА

Допринос АИ

нацрт

јак нацрт

Нацрт, ДБА потврда

Уобичајене грешке

  • Размишљање о односу много-према-више као један-према-више. Ово је најчешћа грешка у моделирању; Ако је међутабела заборављена, систем не може задржати стварно стање.
  • Стављајући све у једну табелу. Окупљање свих поља у једној табели ради „једноставности“ производи дуплирање и аномалије ажурирања.
  • Не писати речник података. Исти КПИ даје различите резултате када значење поља остаје у уму.
  • Слепо веровати препоруци вештачке интелигенције о типовима података и ограничењима. Модел може предложити „довољно велико“ подручје; Пословно правило одређује стварна ограничења (нпр. ТР ИД 11 цифара).
  • Апсолутизирајућа нормализација. Претерана нормализација на слоју за извештавање успорава упит; Сврха варира у зависности од контекста.
Опрез: Вештачка интелигенција може да произведе моделе који лепо изгледају, али крше пословна правила. За сваку везу коју предложи модел поставља се питање "да ли је заиста овако?" Поставите пословно питање. Модел података је скелет система; Прелом скелета је веома тешко поправити касније.

Укратко

Моделирање података је процес структурирања пословних чињеница са ентитетима, атрибутима и односима и одвија се на концептуалном, логичком и физичком нивоу. Примарни и страни кључеви обезбеђују референтни интегритет; Нормализација смањује понављање, али је денормализација такође легитимна у зависности од сврхе. Речник података је заједнички језик организације. АИ обезбеђује значајну брзину у изради нацрта ЕР, речника података и прегледа нормализације; међутим, типови односа, типови података и пословна семантика морају бити потврђени у односу на стварно пословно правило. Само зато што модел изгледа добро не значи да је исправан.

Задатак апликације

Размотримо „систем библиотечке позајмице“: чланови, књиге, записи о позајмици. (1) Имајте нацрт логичког модела који производи моћна промпт. (2) Тестирајте тип сваког односа који модел предлаже (конкретно, „може ли члан имати више од једне копије исте књиге?“) пословним питањем. (3) Нађите барем једну везу више према много и дефинишите међутабелу. (4) Напишите редове речника података за најмање 4 поља (назив, тип, обавезно, пословно значење). (5) Истакните ограничење које је модел можда уклопио и објасните како бисте га верификовали.

контролна листа

  • [ ] Дефинисан је примарни кључ сваке табеле.
  • [ ] Проверио сам тип сваког односа са пословним питањем.
  • [ ] Дефинисао сам међутабелу за релације много-према-више.
  • [ ] Нормализовао сам или оправдао денормализацију дуплих података.
  • [ ] Написао сам линију речника података за критична поља.
  • [ ] Потврдио сам предлоге типа података/ограничења АИ у супротности са пословним правилом.