Zyski:
- Umiejętność wyjaśniania koncepcyjnych, logicznych i fizycznych modeli danych oraz koncepcji normalizacji oraz tworzenia projektów relacji jednostka-relacja przy wsparciu sztucznej inteligencji
- Możliwość tworzenia słownika danych, reguł biznesowych i relacji między tabelami za pomocą ustrukturyzowanych podpowiedzi i weryfikowania ich w porównaniu z rzeczywistym systemem
- Możliwość krytycznej oceny sugestii schematów generowanych przez sztuczną inteligencję pod kątem integralności, osobliwości i zgodności z regułami biznesowymi.
System informacyjny to zasadniczo struktura utrzymująca porządek w danych. Modelowanie danych to zadanie zaprojektowania faktów biznesowych (klient, zamówienie, produkt, faktura) i ich wzajemnych powiązań w ustrukturyzowany sposób. Dobry model danych jest podstawą dokładnego raportowania, szybkich zapytań i spójnych danych; Zły model to źródło lat niekonsekwencji i powtarzalnych prac korygujących. W większości przypadków specjalista MIS nie koduje modelu od zera, ale sprawdza, czy model jest zgodny z regułami biznesowymi i tłumaczy model pomiędzy jednostką biznesową a działem IT.
Modelowanie danych przebiega na trzech poziomach abstrakcji. Model pojęciowy (angielski konceptualny) to najwyższy poziom: jakie główne byty istnieją i jak są ze sobą powiązane? „Klient składa zamówienie, zamówienie obejmuje produkt.” Nie ma żadnych szczegółów technicznych. Model logiczny definiuje atrybuty (pola), klucze i typy relacji każdej jednostki; ale nadal nie jest powiązany z konkretnym produktem bazodanowym. Model fizyczny (angielski fizyczny) to konkretna wersja tabel, typów danych i indeksów w określonej bazie danych (np. SQL Server, PostgreSQL). Te trzy poziomy są coraz bardziej szczegółowymi wersjami tej samej idei.
Relacja encji i klucze
Podstawowym językiem modelu danych jest model Entity-Relationship (ER). Encja może być traktowana jako tabela: Klient, Zamówienie. Atrybutem jest kolumna tabeli: nazwa, adres e-mail, kwota. Relacja to sposób, w jaki podmioty są ze sobą powiązane: klient może mieć wiele zamówień (relacja jeden do wielu).
Istnieją dwie kluczowe koncepcje. Klucz podstawowy to pole, które jednoznacznie identyfikuje każdy wiersz w tabeli; na przykład IDKlienta. Klucz obcy to pole w jednej tabeli, które wskazuje na klucz podstawowy innej tabeli; Identyfikator klienta w tabeli zamówień łączy zamówienie klienta. Połączenia te zapewniają integralność referencyjną: nie można złożyć zamówienia dla klienta, który nie istnieje.
Wskazówka: gdy sztuczna inteligencja generuje wersję roboczą ER, łatwiej jest jawnie zażądać klucza podstawowego dla każdej tabeli i klucza obcego dla każdej relacji. Ale zweryfikuj każdy klucz obcy sugerowany przez model pod kątem rzeczywistej reguły biznesowej: czasami relacja, o której myślisz, że jest „jeden do wielu”, jest w rzeczywistości „wiele do wielu”.
Normalizacja: zapobieganie nawrotom
Normalizacja to proces zmniejszania nadmiarowości i zachowania integralności poprzez podzielenie danych na logiczne tabele. Celem jest przechowywanie tych samych informacji w jednym miejscu. Przykładowo, zamiast wpisywać wielokrotnie adres klienta w każdym wierszu zamówienia, zapiszesz adres raz w tabeli Klienci i połączysz go z kluczem obcym z zamówienia. Dzięki temu, gdy zmieni się adres, zaktualizujesz go w jednym miejscu; W przeciwnym razie setki zamówień będą miały różne adresy. Nazywa się to anomalią aktualizacji.
Przeciwieństwem normalizacji jest denormalizacja: celowe zezwolenie na pewne powtórzenia ze względu na szybkość raportowania. W systemach biznesowych (operacyjna baza danych) generalnie preferowana jest normalizacja, a w systemach raportowych (hurtownia danych) często preferowana jest denormalizacja. Zatem „normalizacja nie zawsze jest dobra”; Decyzja jest podejmowana zgodnie z celem.
Słownik danych: wspólny język
Słownik danych to dokument definiujący znaczenie każdego pola, jego typ, ograniczenia i reguły biznesowe. Co oznacza pole „status”? Jakie wartości może przyjmować (Oczekujące, Zatwierdzone, Anulowane)? Czy jest to obowiązkowe? Bez tego dokumentu to samo pole będzie różnie interpretowane przez różne zespoły, a raport będzie zniekształcony. Słownik danych jest językiem organizacji i jednym z najcenniejszych osiągnięć specjalistów MIS. Sztuczna inteligencja może szybko wyodrębnić wstępny projekt słownika danych z istniejącej struktury tabeli; Ale dopiero jednostka korzystająca z tych danych weryfikuje prawdziwe znaczenie biznesowe każdego pola.
Trzy mini etui: w liczbach
Przypadek 1 — Koszt powtórzenia. W firmie dystrybucyjnej adres klienta był prowadzony oddzielnie zarówno w tabeli zamówień, jak i na fakturach. Kiedy klient się przeprowadził, adres został zaktualizowany tylko w jednej tabeli; 1400 faktur poszło na stary adres i otrzymało zwrot pieniędzy. Jeżeli adres zostałby znormalizowany w jednej tabeli, wystarczyłaby pojedyncza aktualizacja. Projekt rekultywacji kosztował 2 tygodnie.
Przypadek 2 — Zły typ relacji. Ekspert MIS w instytucji edukacyjnej uznał relację (jeden do wielu) „Uczeń należy do klasy” w modelu generowanym przez sztuczną inteligencję. Jednakże studenci mogli zapisać się na więcej niż jedno zajęcia fakultatywne; W rzeczywistości relacja była typu wiele do wielu i wymagana była tabela pośrednia (rekord). Błąd wyszedł na jaw w terenie, gdy uczeń nie zapisał się do klasy drugiej. Gdyby sugestia AI została potwierdzona, zostałaby wyłapana od początku.
Przypadek 3 — Wartość słownika danych. Ustalono, że pole „policy_status” w firmie ubezpieczeniowej było różnie interpretowane przez 5 różnych zespołów, dlatego ten sam KPI dał w raportach 3 różne wyniki. Dzięki opracowaniu słownika danych opartego na sztucznej inteligencji i osiągnięciu jednolitego porozumienia z jednostką biznesową wyeliminowano niespójności w raportach, a czas miesięcznych spotkań uzgadniających został skrócony o 60%.
Słaba podpowiedź/silna podpowiedź
Słaba zachęta:
Zaprojektuj bazę danych e-commerce.
Potężny monit:
Twoja rola: Jesteś doświadczonym modelarzem danych. STRUKTUJ LOGICZNY model danych zgodnie z poniższymi regułami biznesowymi. Zasady: - Dla każdej jednostki: pola, klucz podstawowy, pola wymagane. - Dla każdej relacji: typ (jeden do wielu / wiele do wielu) i klucz obcy. - Zaproponuj tabelę pośrednią w relacjach wiele do wielu. - Normalizuj do trzeciej postaci normalnej; Jeśli zalecasz celową denormalizację, napisz uzasadnienie.- Oznacz [WYMAGANE POTWIERDZENIE] każdą regułę biznesową, której nie jesteś pewien.Reguły biznesowe:- Klient może złożyć wiele zamówień.- Zamówienie zawiera wiele produktów; Jeden produkt występuje w wielu zamówieniach.- Produkty mają kategorie.[inne zasady...]
Potężny monit wyjaśnia poziom modelu (logiczny), zasady kluczy i relacji, cel normalizacji i punkty wymagające potwierdzenia.
Cztery szablony do kopiowania
1) Projekt słownika danych:
Zarys słownika danych wynika z definicji tabeli. Dla każdego pola: nazwa, typ, czy jest obowiązkowe, możliwe wartości, znaczenie biznesowe (etykieta[PREZENTACJA] jeśli jest to przewidywanie). Tabela: [DDL lub lista pól]
2) Przegląd normalizacji:
Czy istnieje ryzyko zduplikowania danych, nieprawidłowości w aktualizacji i możliwości normalizacji w poniższej strukturze tabeli? Dla każdego ustalenia zapisz, jaką formę normalną narusza i swoją sugestię. Struktura: [tekst]
3) Projekt ER z reguły biznesowej:
Przetłumacz poniższe reguły biznesowe na encje, atrybuty i relacje. Określ typ każdej relacji (1-1, 1-N, N-N), a jeśli N-N, zaproponuj tabelę pośrednią. Zaznacz niejednoznaczne zasady. Zasady: [tekst]
4) Pytania weryfikujące typ relacji:
Dla każdej relacji w poniższym modelu danych wygeneruj pytanie biznesowe typu „tak/nie”, które sprawdzi poprawność jego typu (np. „Czy student może być zapisany na więcej niż jedno zajęcia w tym samym czasie?”). Modelka: [tekst]
Tabela porównawcza: Poziomy modelu
funkcja
koncepcyjny
logiczne
fizyczne
Szczegół
przynajmniej
średni
większość
klucz/relacja
Główne aktywa
Zdefiniowano klucze
Zawiera indeks/typ
Zależy od bazy danych
nie
nie
Tak
grupa docelowa
jednostka biznesowa
analityk
Programista/DBA
Wkład sztucznej inteligencji
projekt
mocny przeciąg
Wersja robocza, potwierdzenie DBA
Typowe błędy
- Myślenie o relacji wiele do wielu jak o relacji jeden do wielu. Jest to najczęstszy błąd modelowania; Jeśli tabela pośrednia zostanie zapomniana, system nie będzie w stanie zachować aktualnego stanu.
- Umieszczenie wszystkiego w jednej tabeli. Zebranie wszystkich pól w jednej tabeli ze względu na „prostotę” powoduje powielanie i anomalie w aktualizacji.
- Nie pisanie słownika danych. Ten sam KPI daje inne rezultaty, gdy w głowie pozostaje znaczenie pól.
- Ślepe zaufanie zaleceniom AI dotyczącym typów danych i ograniczeń. Model może sugerować „wystarczająco duży” obszar; Rzeczywiste limity określa reguła biznesowa (np. TR ID 11 cyfr).
- Absolutyzująca normalizacja. Nadmierna normalizacja w warstwie raportowania spowalnia zapytanie; Cel różni się w zależności od kontekstu.
Uwaga: sztuczna inteligencja może tworzyć modele, które wyglądają ładnie, ale naruszają zasady biznesowe. Do każdej relacji sugerowanej przez model pytanie „czy naprawdę tak jest?” Zadaj pytanie biznesowe. Model danych jest szkieletem systemu; Złamanie szkieletu jest bardzo trudne do późniejszego naprawienia.
Podsumowując
Modelowanie danych to proces strukturyzacji faktów biznesowych za pomocą jednostek, atrybutów i relacji, który przebiega na poziomie koncepcyjnym, logicznym i fizycznym. Klucze podstawowe i obce zapewniają integralność referencyjną; Normalizacja ogranicza powtórzenia, ale denormalizacja jest również uzasadniona w zależności od celu. Słownik danych jest powszechnym językiem organizacji. Sztuczna inteligencja zapewnia znaczną szybkość tworzenia wersji roboczych ER, słowników danych i przeglądów normalizacyjnych; jednakże typy relacji, typy danych i semantyka biznesowa muszą zostać potwierdzone w odniesieniu do rzeczywistej reguły biznesowej. To, że model wygląda dobrze, nie znaczy, że jest dobry.
Zadanie aplikacji
Rozważmy „system wypożyczeń bibliotecznych”: członkowie, książki, zapisy wypożyczeń. (1) Przygotuj projekt modelu logicznego za pomocą potężnego podpowiedzi. (2) Przetestuj rodzaj każdej relacji sugerowanej przez model (w szczególności „czy członek może mieć więcej niż jeden egzemplarz tej samej książki?”), zadając pytanie biznesowe. (3) Znajdź przynajmniej jedną relację wiele do wielu i zdefiniuj tabelę pośrednią. (4) Zapisz linie słownika danych dla co najmniej 4 pól (nazwa, typ, obowiązkowe, znaczenie biznesowe). (5) Podkreśl wiązanie, które model mógł dopasować, i wyjaśnij, w jaki sposób można to zweryfikować.
lista kontrolna
- [ ] Zdefiniowano klucz podstawowy każdej tabeli.
- [ ] Sprawdziłem rodzaj każdej relacji z pytaniem biznesowym.
- [ ] Zdefiniowałem tabelę pośrednią dla relacji wiele do wielu.
- [ ] Znormalizowałem lub uzasadniłem denormalizację zduplikowanych danych.
- [ ] Napisałem wiersz słownika danych dla pól krytycznych.
- [ ] Potwierdziłem sugestie dotyczące typu danych/ograniczeń AI względem reguły biznesowej.