Sposoby udostępniania bazy danych programu Access. Rozproszone bazy danych. Udostępnianie danych za pomocą folderów sieciowych

• Tłumaczenie

Bazy danych są używane wszędzie, w tym w większości projektów w świecie tworzenia stron internetowych. Wszystko, od najprostszych blogów i katalogów po poważne projekty społecznościowe. Niezależnie od złożoności witryny i powiązanej bazy danych, każda z nich wymaga starannego zaprojektowania, aby działała wydajnie i niezawodnie.


W tym artykule omówimy podstawy tworzenia dobrego planu bazy danych, niezależnie od jego ostatecznego celu. Wszystkie opcje projektowania bazy danych mają zestaw standardowych reguł i najlepszych praktyk, których należy przestrzegać. Pomogą one w organizacji bazy danych i sprawią, że będzie ona współdziałać z witryną w inteligentniejszy i wydajniejszy sposób.

Jaka funkcjonalność jest wymagana od bazy danych

Pierwszą metodą stosowaną w planowaniu jest zwykła burza mózgów, robienie notatek na papierze lub w inny sposób, w zależności od tego, co ma być przechowywane w bazie danych i czego wymaga strona. Staraj się nie myśleć o konkretnych polach, tabelach, które będą używane w konkretnym przypadku – wszystkie konkretne punkty zostaną przez Ciebie rozważone później. Twoim celem na tym etapie jest uzyskanie ogólnego i pełnego obrazu struktury bazy danych, który następnie dopracujesz i uszczegółowisz. Często może być trudniej dodać elementy do planu później niż na początkowym etapie.

Zdjęcie: binaryape

Odsuń się od bazy danych. Spróbuj zastanowić się, czego będzie wymagać strona? Na przykład, jeśli chcesz stworzyć witrynę, która łączy ludzi, możesz od razu zacząć myśleć o danych, które będą przechowywać użytkownicy. Zapomnij o tym, zachowaj na później. Lepiej napisać, że użytkownicy i informacje o nich powinny być przechowywane w bazie danych. Co jeszcze? Co użytkownicy będą robić w Twojej witrynie? Czy będą publikować nagrania, przesyłać pliki, zdjęcia, pisać do siebie wiadomości? Dlatego baza danych musi przechowywać wszystkie te informacje: rekordy, pliki, zdjęcia, wiadomości itp.
Jak użytkownicy będą wchodzić w interakcję z Twoją witryną? Czy będą musieli wyszukiwać na przykład swoje ulubione przepisy, uzyskiwać dostęp do postów udostępnianych przez konkretną społeczność, wyszukiwać produkty lub wyświetlać listę ostatnio oglądanych i zakupionych produktów? Baza danych powinna mieć możliwość przechowywania receptur, „zamkniętych” rekordów dostępnych dla określonego kręgu użytkowników, informacji o produktach, a także możliwość powiązania konkretnego produktu i użytkownika.

Definiowanie wymaganych tabel i pól

Następnym krokiem jest określenie, które tabele i pola będą wymagane w bazie danych. To jest sedno rozwoju i najtrudniejsza jego część. Korzystanie z właściwych metod łączenia tabel, definiowanie struktury danych w każdej tabeli, identyfikacja potrzeby rozproszenia tych danych w różnych tabelach – wszystkie te problemy pojawiają się w bezpośrednim projektowaniu bazy danych. Teraz musisz zdefiniować listę oczywiście potrzebnych tabel i pól, tak aby była jak najbardziej szczegółowa. W trakcie tego procesu niektóre elementy można przebudować lub zreorganizować w celu poprawy wydajności i bezpieczeństwa bazy danych.

Użyj narzędzia do modelowania danych

Teraz, gdy wiesz, co witryna będzie musiała zrobić, nadszedł czas, aby określić, jakie konkretne informacje będą musiały być przechowywane. Narzędzie do projektowania baz danych byłoby tutaj bardzo odpowiednie, zwłaszcza z możliwością tworzenia wizualnych modeli baz danych, na przykład MySQL Workbench lub . Gliffy to doskonałe darmowe narzędzie online do tworzenia różnych schematów blokowych i modeli baz danych.

Jest też bardziej znane, moim zdaniem, wysokiej jakości narzędzie - Microsoft Visio (tylko Windows, cena 249,99 USD). Ale nie obawiaj się, istnieją tańsze alternatywy, z których wiele to projekty typu open source, w tym dwa wymienione powyżej.
Zapoznaj się z popularnymi konwencjami graficznymi i standardowymi elementami wizualnymi wymaganymi do utworzenia modelu bazy danych i zacznij planować z wyprzedzeniem za pomocą schematów blokowych i diagramów. Pozwoli to uniknąć błędów logicznych przed utworzeniem jakiejkolwiek konkretnej bazy danych.

Grupowanie i rozdzielanie danych

Jeśli chodzi o pola, ważne jest również, aby wiedzieć, kiedy grupować określoną część danych, a kiedy nie. Dobrym sposobem na określenie, jakie informacje powinny znajdować się w jednym polu lub na odwrót, jest rozważenie, czy będzie konieczna zmiana jakiejkolwiek jego części? Na przykład, czy musisz przechowywać adres w 1) ulicy, 2) mieście, 3) stanie, 4) kod pocztowy, 5) kraj?
Czy jest to integralna część funkcjonalności serwisu (być może użytkownicy lub administratorzy chcą szukać innych użytkowników według adresu lub stanu), czy tylko zwiększenie przestrzeni dyskowej bazy danych? Jeśli nie jest to takie ważne, po co ładować bazę danych, aby zmienić 5 pól, skoro można zaktualizować tylko jedno pole znakowe. Wygodniej może być pobrać te dane z formularza HTML, w którym pola są oddzielone, a przed dodaniem adresu do bazy danych połączyć wartości z odpowiednich pól w jedną linię.
To tylko jeden przykład, ale zawsze miej świadomość najefektywniejszych sposobów organizowania pól tabeli, kiedy je łączyć, a kiedy oddzielać, aby zachować funkcjonalność witryny.

Normalizacja bazy danych

Normalizacja to zestaw wytycznych zaprojektowanych w celu wydajniejszego organizowania przechowywania informacji. Wspomnieliśmy już o kilku ważnych podstawowych praktykach, które są zawarte w najpopularniejszych normalnych formularzach. Istnieje pięć normalnych form. Przydałoby się zapoznać się z tymi normalnymi formularzami i opracować bazy danych zgodnie z ich wymaganiami.
Normalizacja bazy danych to duży temat, ale zrozumienie jej podstaw może ci ogromnie pomóc. Aby mieć ogólne pojęcie o każdej normalnej formie i ogólnie o normalizacji, nie zapomnij rzucić okiem na

W swojej najbardziej ogólnej formie baza danych jest zdefiniowana jako zbiór powiązanych informacji. Z tej definicji wynika ważna cecha bazy, która polega na tym, że baza zawiera nie tylko same dane, ale także relacje między nimi. Jedną z głównych idei bazy danych jest wspólne przechowywanie danych wraz z ich opisami. Dzięki temu przechowywane dane stają się „otwarte”, zrozumiałe dla dowolnej liczby aplikacji współpracujących z bazą danych. Dzięki temu baza danych jest niezależnym zasobem informacji, który może być ponownie wykorzystany przez różne aplikacje, pozostając od nich niezależnym.

Oprócz opisu danych, wyjaśnienia ich znaczenia i struktury, baza obsługuje pewne ograniczenia nałożone na te dane, np. określa typ danych, ich wymiar itp.

W ten sposób, Baza danych jest pewnym zasobem informacyjnym danych strukturalnych, przeznaczonym do wielozadaniowego, wielokrotnego użytku w określonych obszarach tematycznych.

Bazy danych działają pod kontrolą systemów zarządzania bazami danych (DBMS), które są definiowane jako zbiór języków i programów wymaganych do pracy z bazą danych. DBMS umożliwia tworzenie baz danych, wprowadzanie i zmianę w nich informacji oraz dostęp do tych informacji. Schemat organizacji wsparcia oprogramowania i informacji w przypadku korzystania z DBMS będzie zasadniczo inny (rys. 2.5).

Aplikacje poprzez DBMS uzyskują dostęp do danych przechowywanych w jednej lub kilku bazach danych. Jednocześnie organizacja kompleksu programowo-informacyjnego nie jest już determinowana przez oprogramowanie, ale przez wsparcie informacyjne. Dane są niezależne od aplikacji, aplikacje z kolei mogą korzystać z dowolnych danych zawartych w bazie danych. DBMS utrzymuje integralność danych, warunkuje ich współdzielenie przez różne programy i różnych użytkowników oraz w pewnym stopniu zapewnia bezpieczeństwo informacji.

Ryż. 2.5. Schemat organizacji oprogramowania i wsparcia informacyjnego

Korzystanie z subd

Wykonuje również najważniejsze procedury informacyjne na danych zawartych w bazie danych, na żądanie użytkownika lub na polecenie otrzymane z aplikacji.

DBMS typu kompilator tworzy aplikacje współpracujące bezpośrednio z bazami danych. Jednocześnie sam DBMS jako osobne narzędzie programowe podczas pracy z danymi jest faktycznie nieobecny.

To, co faktycznie dzieje się w czasie kompilacji, to scalanie silnika bazy danych i aplikacji (Rysunek 2-6).

Ryż. 2.6. Schemat połączenia rdzenia bazy danych i aplikacji

Obecnie aplikacje tworzone są z reguły przez wykwalifikowanych programistów. Jednocześnie projektowanie struktur baz danych jest niemożliwe bez udziału ekonomistów - ekspertów w danej dziedzinie, ponieważ możliwości informacyjne bazy danych są w dużej mierze zdeterminowane jakością jej projektu.

Elementy bazy danych

Baza danych to system, tj. składa się z pewnej liczby elementów i relacji między nimi (ryc. 2.7)

Ryż. 2.7. Jednostki strukturalne bazy danych

Najmniejszym z nich jest element danych, który w niektórych przypadkach nazywany jest również polem lub atrybutem i odpowiada jednemu atrybutowi. Tak więc element danych jest najmniejszą znaczącą semantycznie nazwaną jednostką danych. Element danych jest określony przez następujące cechy: imię i nazwisko (imię i nazwisko, data urodzenia, nazwa firmy), typ (znak, cyfra, kalendarz), długość (maksymalna możliwa liczba znaków - 15 bajtów) oraz dokładność (liczba miejsc po przecinku dla danych liczbowych).

Elementy danych są zorganizowane w rekordy zwane krotkami. Rekord generalnie odpowiada wskaźnikowi i zawiera dane dotyczące jednego z jednorodnych obiektów, na przykład jednego konta, jednego pracownika itp. W niektórych przypadkach stosuje się pojęcie agregatu danych, który zajmuje pozycję pośrednią między elementem danych a rekordem. Agregacja danych może być prosta (składająca się tylko z elementów danych) lub złożona (składająca się z elementów i prostych agregacji danych).

Zbiór rekordów tego samego typu nazywany jest zbiorem bazy danych (lub tabelą). Należy zauważyć, że zbiór bazy danych nie zawsze odpowiada zbiorowi fizycznemu. W niektórych przypadkach informacje o zbiorach bazy danych są zawarte w kilku zbiorach fizycznych i odwrotnie, kilka zbiorów baz danych może znajdować się w jednym zbiorze fizycznym.

Baza danych jest zatem zbiorem powiązanych ze sobą plików bazy danych.

Znaczenie powyższych terminów można wyjaśnić na schemacie (ryc. 2.8).

Element danych zawiera jeden atrybut, w tym przypadku nazwę miasta - Moskwa. Agregat danych składa się z kilku atrybutów traktowanych jako całość. Rekord składa się z jednego lub więcej elementów danych i zawiera informacje o jednym obiekcie, w podanym przykładzie, o jednym przedsiębiorstwie. Zbiór rekordów tego samego typu tworzy plik bazy danych, na rysunku jest to plik z informacjami o przedsiębiorstwach. Zbiór takich plików, połączonych w taki czy inny sposób, stanowi bazę danych. Schemat przedstawia trzy powiązane ze sobą pliki informacji w następujący sposób: przedsiębiorstwa są obsługiwane przez banki, mają w nich otwarte rachunki. Jeśli nie ma połączenia między plikami, ich kolekcja nie może być uważana za bazę danych.

Ryż.2.8. Przykład relacji jednostek strukturalnych bazy danych

Cykl życia bazy danych

Jak każdy system, baza danych ma swój cykl życia, czyli konsekwentny rozwój systemu w czasie. Wyróżnia się następujące główne etapy cyklu życia.

Planowanie. Jego celem jest zdefiniowanie i analiza wymagań dla tworzonej bazy danych. Jednocześnie brane są pod uwagę różne widoki danych w zależności od wykonywanych funkcji, określone wymagania dla bazy danych są określane w zależności od typów zapytań, ilości przeglądanych plików bazy danych, trybu pracy z tą bazą danych itp. .

Projekt bazy danych. Na podstawie analizy potrzeb użytkowników i integracji tych potrzeb tworzony jest model domeny. W oparciu o ten model budowana jest logiczna struktura bazy danych, skoncentrowana na konkretnym DBMS. Ostatnim krokiem jest analiza i ocena możliwości bazy danych pod kątem zaspokojenia potrzeb różnych grup użytkowników.

Materializacja bazy danych. Celem tego etapu cyklu życia jest wypełnienie i załadowanie bazy danych za pomocą narzędzi DBMS. Przewiduje to następujące prace: przygotowanie danych; transfer informacji wejściowych z dokumentów na nośniki maszynowe; przekształcenie istniejących plików danych według specjalnie zaprojektowanej struktury uzyskanej w poprzednim etapie.

Działanie bazy danych. Celami tego etapu cyklu życia są: zapewnienie wdrożenia i ciągłej pracy bazy danych; bezpieczeństwo danych w przypadku awarii systemu komputerowego i innych sytuacji awaryjnych; analiza funkcjonowania systemu bazodanowego pod kątem jego wydajności i wydajności. Kryterium oceny bazy danych jest system wskaźników ilościowych i jakościowych. Wskaźnikami ilościowymi są: czas odpowiedzi na zgłoszenie, wykorzystana pamięć zewnętrzna i RAM, niezawodność i inne koszty (aktualizacja bazy danych, tworzenie, reorganizacja, restrukturyzacja). Wskaźnikami jakościowymi są elastyczność, adaptacyjność, dynamika, odzyskiwalność, zdolność do zachowania integralności danych itp.

Rozwój i doskonalenie bazy danych. W trakcie działania bazy danych pojawiają się nowe zadania, których rozwiązanie wiąże się z pojawieniem się nowych elementów danych i relacji między nimi, co prowadzi do konieczności stworzenia modyfikowalnej bazy danych. W takim przypadku należy rozróżnić reorganizację i restrukturyzację bazy danych. Pierwszy związany jest ze zmianą wartości danych, tj. doskonalenie systemu informatycznego wpływa pozytywnie na rozwój bazy danych, jej modyfikację. Restrukturyzacja polega na zmianie przesunięć strukturalnych, co pociąga za sobą stworzenie prawie nowej bazy danych.

Projekt bazy danych

Wśród etapów cyklu życia bazy danych duże znaczenie ma etap projektowania. Wynika to z faktu, że jakość bazy danych w dużej mierze decyduje o jakości całego systemu informatycznego. Ponadto na tym etapie ma miejsce najbardziej aktywna interakcja między programistami a ekspertami w danym obszarze i powstają podstawowe idee dotyczące przedmiotu, które będą stanowić podstawę EIS. W konsekwencji projekt ma charakter badawczy, dotyka problemów związanych nie tylko z określeniem obszaru tematycznego i tworzeniem jego modelu, ale także z zasadami konstruowania struktur logicznych.

Projekt bazy danych przechodzi przez kilka etapów. Zwyczajowo wyróżnia się etapy projektowania koncepcyjnego, logicznego i fizycznego, chociaż czasami są one nazywane inaczej, a w niektórych przypadkach niektóre z nich są faktycznie nieobecne.

Na Pierwszy etap tworzony jest koncepcyjny lub informacyjny model danych z obszaru tematycznego. Charakteryzuje się tym, że nie zależy od cech konkretnego DBMS. Opisuje główne obiekty obszaru tematycznego, ich właściwości i relacje między nimi. Możliwe jest opisanie tematu językiem naturalnym, jednak dla większej dokładności, jasności i prostoty dalszego projektowania stosuje się sformalizowane narzędzia. Tak więc opis sporządzony za pomocą języka naturalnego, wzorów matematycznych, tabel, wykresów i innych środków zrozumiałych dla każdego, kto zajmuje się projektowaniem baz danych, nazywa się koncepcyjny model danych.

Istnieje wiele podejść do budowania konceptualnego modelu danych: modele grafowe, sieci semantyczne, model relacji encji itp. Najpopularniejszym z nich jest model relacji podmiot-relacja ( ER-model, z angielskiego. podmiot- relacja). ER-model został zaproponowany przez amerykańskiego naukowca Petera Ping Shen Chen w 1976 roku. Do tej pory opracowano kilka jego odmian, ale wszystkie oparte są na diagramach graficznych zaproponowanych przez Chena.

Model encji-relacji jest przedstawiony graficznie w postaci ER-diagram, który składa się ze zbioru zestawów wartości opisujących właściwości jednostki i relacji (podmiot - relacja Schematy).

Zalety tego modelu to:

łatwość formalizacji

łatwość zrozumienia;

opis za pomocą środków graficznych;

widoczność obrazu różnego rodzaju połączeń;

łatwość konwersji do schematu bazy danych obsługiwanego przez niektóre DBMS.

Głównymi składnikami modelu encja-relacja to encja, atrybuty i relacje (rysunek 2.9).

Ryż.2.9. ER -diagram

Istota (podmiot) - jakiś rzeczywisty lub wyimaginowany obiekt, który jest istotny dla rozważanego obszaru, o którym informacje mają być przechowywane. Każda jednostka musi mieć pewne właściwości: mieć unikalną nazwę i jeden lub więcej atrybutów, które jednoznacznie identyfikują każde wystąpienie jednostki. Atrybut – dowolna cecha podmiotu, która jest istotna dla rozważanego obszaru tematycznego. Ma na celu określenie, identyfikację, klasyfikację, kwantyfikację lub wyrażenie stanu jednostki.

Połączenie (relacja) - nazwany związek między dwoma podmiotami, istotny dla rozpatrywanego obszaru.

Relacji jest nadawana nazwa, a nazwa każdej relacji między dwiema jednostkami musi być unikalna.

Model koncepcyjny tworzony jest na podstawie wywiadów i ankiet ekspertów – specjalistów z danej dziedziny i musi spełniać szereg wymagań:

powinien być niezależny od konkretnego DBMS;

powinien być zrozumiały zarówno dla twórców systemu informatycznego, jak i specjalistów z danej dziedziny;

powinien zminimalizować wysiłek związany z dalszym projektowaniem. Oznacza to, że jego struktury muszą być łatwo przekonwertowane na struktury modelu logicznego;

powinna istnieć w formie czytelnej dla komputera, gdy tylko jest to możliwe. W takim przypadku będzie odpowiedni do zautomatyzowanego projektowania baz danych.

Tak więc celem modelowania koncepcyjnego jest stworzenie dokładnej i kompletnej reprezentacji obszaru tematycznego, tj. zdefiniować obiekty, ich właściwości i relacje między obiektami (tj. relacje).

Na drugi etap projekt, tworzony jest model logiczny lub datalogiczny. Taki model nie jest już budowany pod kątem obiektów i relacji, ale pod kątem konkretnego DBMS, w którym baza ma być używana. Ten model jest również nazywany schematem bazy danych.

Obecnie znane są trzy logiczne modele danych (nazywane również modelami klasycznymi lub wspaniałymi), a mianowicie hierarchiczny, sieciowy i relacyjny.

Hierarchiczne i sieciowe modele danych zaczęły być stosowane w systemach zarządzania bazami danych na początku lat sześćdziesiątych. Na początku lat 70. zaproponował relacyjny model danych.

Głównymi elementami każdego z tych modeli są przedmioty i relacje między nimi, a cechą wyróżniającą jest różnica w sposobach przedstawiania relacji między przedmiotami.

Trzeci etap- projekt fizyczny. Jej wynikiem jest model fizyczny, który zawiera opis bazy danych pod kątem jej fizycznej struktury. Model fizyczny obejmuje wybór nośników pamięci, określenie sposobu umieszczenia bazy danych i jej komponentów na tych nośnikach, opisanie możliwości i celowości kompresji danych oraz optymalizację dostępu do danych na poziomie fizycznym.

Jeśli więc model koncepcyjny jest niezależny od SZBD, a być może nawet od modelu danych, a model logiczny zależy od konkretnego SZBD, to fizyczny zależy nie tylko od SZBD, ale także od technicznego i częściowo systemu. oprogramowanie.

Obecny etap rozwoju systemów informatycznych wprowadza pewne zmiany w klasycznym schemacie projektowania baz danych:

na etapie projektowania koncepcyjnego szeroko stosowane są metody graficzne;

nowe metodologie sprawiają, że dość łatwo jest przełożyć model koncepcyjny na model logiczny dla różnych DBMS. W niektórych przypadkach przejście od modelu konceptualnego do logicznego może być zautomatyzowane lub nawet całkowicie automatyczne;

nowoczesne DBMS i inne oprogramowanie pozwalają znacznie uprościć fizyczną organizację bazy danych. Dlatego etap projektowania fizycznego jest obecnie znacznie skrócony, a czasem prawie całkowicie zautomatyzowany.

Rodzaje logicznych modeli danych

Jak wspomniano powyżej, główne typy logicznych modeli danych to: hierarchiczny, sieciowy i relacyjny.

Hierarchiczny model danych pozwala na budowanie baz danych o strukturze drzewiastej. W nich każdy węzeł zawiera swój własny typ danych (encja). Na najwyższym poziomie drzewa w tym modelu znajduje się jeden węzeł - korzeń, na kolejnym poziomie znajdują się węzły powiązane z tym korzeniem, następnie węzły powiązane z węzłami poprzedniego poziomu itd., a każdy węzeł może mieć tylko jeden przodek (ryc. 2.10). Takie bazy danych obsługują relację jeden-do-wielu.

Wyszukiwanie danych w systemie hierarchicznym zawsze zaczyna się od korzenia. Następnie zejście odbywa się z jednego poziomu na drugi, aż do osiągnięcia pożądanego poziomu. Poruszanie się po systemie od jednego rekordu do drugiego odbywa się za pomocą linków.

Główne zalety modelu hierarchicznego to prostota opisu struktur hierarchicznych świata rzeczywistego oraz szybkie wykonywanie zapytań odpowiadających strukturze danych. Jednak takie modele często zawierają nadmiarowe dane i są słabo przystosowane do reprezentowania relacji wiele-do-wielu. Ponadto nie zawsze wygodnie jest za każdym razem rozpocząć wyszukiwanie potrzebnych danych od korzenia i nie ma innego sposobu na poruszanie się po bazie danych w strukturach hierarchicznych. Systemy hierarchiczne są najstarszą generacją systemów bazodanowych, zostały opracowane dla komputerów typu mainframe.

Ryż. 2.10. Hierarchiczna struktura modelu bazy danych

model danych sieciowych opiera się również na graficznej reprezentacji relacji między obiektami. Jednak tutaj oprócz połączeń pionowych występują również połączenia poziome, czyli tzw. dozwolone jest podporządkowanie jednego obiektu wielu obiektom. W ten sposób, w przeciwieństwie do hierarchicznych modeli sieciowych, obsługują relacje wiele-do-wielu. Każdy element podrzędny w nich może mieć więcej niż jednego rodzica (rysunek 2.11).

Ryż. 2.11. Struktura sieciowa modelu bazy danych

Jednak systemy sieciowe są dość złożone i wymagają solidnego oprogramowania. W nich, podobnie jak w systemach hierarchicznych, przejście od rekordu do rekordu odbywa się według linków umieszczonych w każdym rekordzie. Kiedyś były dość popularne i były używane do minikomputerów i dużych komputerów.

Model organizacji relacyjnej bazy danych jest obecnie najpopularniejsza. Wynika to z faktu, że występowanie podstawowych mankamentów modeli hierarchicznych i sieciowych doprowadziło do nieefektywności ich wykorzystania we współczesnych warunkach. Możliwości modelu relacyjnego pozwoliły przezwyciężyć te niedociągnięcia i opisać struktury hierarchiczne i sieciowe.

Relacyjna baza danych to baza danych, która jest postrzegana przez użytkownika jako zbiór tabel. Prezentacja danych w postaci tabel jest dość spójna z tradycyjnymi „niekomputerowymi” technologiami przetwarzania informacji, jest jasna i zrozumiała dla większości użytkowników. Tabele relacyjnych baz danych można przeglądać na ekranie komputera lub drukować. Zauważamy również, że relacyjny model danych najlepiej pasuje do struktury informacji ekonomicznej.

Podstawowe pojęcia dotyczące relacyjnych baz danych

Relacyjny model danych, opracowany przez E. Codda w latach 70., opiera się na matematycznej teorii relacji i opiera się na systemie pojęć algebry relacyjnej, z których najważniejsze to tabela (relacja), wiersz (krotka), kolumna (atrybut), zawartość kolumny (domena), klucz podstawowy, klucz obcy.

W modelu relacyjnym dane są reprezentowane w postaci połączonych ze sobą tabel. Każda tabela składa się z wierszy (rekordów tego samego typu lub krotek) i kolumn (pól lub atrybutów) i ma unikalną nazwę w bazie danych. Słowo „tego samego typu” oznacza, że ​​wszystkie rekordy mają ten sam zestaw atrybutów lub pól, chociaż każdy atrybut może przyjąć własną wartość dla każdego rekordu. Każda kolumna tabeli ma niepowtarzalną nazwę swojej tabeli. Kolumny są ułożone w tabeli zgodnie z kolejnością, w jakiej pojawiają się ich nazwy podczas tworzenia tabeli. Każdy atrybut może przyjąć podzbiór wartości z określonego obszaru (domeny). W przeciwieństwie do kolumn wiersze nie mają nazw, ich kolejność w tabeli nie jest zdefiniowana, a ich liczba nie jest ograniczona.

Wyjaśnijmy powyższe pojęcia na przykładzie modelu relacyjnej bazy danych zawierającej informacje o pracownikach danej firmy. Rozważ tabelę z danymi dotyczącymi pracowników firmy (Tabela 2.6).

Tabela 2.6

Personel

Numer personelu	Nazwisko I.O.	Kod działu	Telefon służbowy
	PETROV A.V.
	ROMANENKO ST.
	STEPANOVA I.S.

Widać, że wszystkie trzy wpisy mają te same atrybuty, ale przyjmują różne wartości. Tak więc dla rekordu nr 1 atrybut „liczba personelu” przyjmuje wartość 008976, a dla rekordu nr 2 – 008980 itd. Wartości niektórych atrybutów dla różnych rekordów mogą być takie same, na przykład rekordy nr 1 i nr 2 mają tę samą wartość atrybutu „kod działu”. Jednak każda tabela musi mieć atrybut (lub zestaw atrybutów), którego wartość nigdy się nie powtarza i jednoznacznie identyfikuje każdy wiersz w tabeli. Jest to konieczne, aby podczas pracy z bazą danych było możliwe odróżnienie jednego rekordu od drugiego. Takie atrybuty nazywane są unikalnymi. Unikalny atrybut tabeli lub zestaw jej unikalnych atrybutów nazywa się główny klucz lub kluczowe pole. W tej tabeli kluczem jest atrybut numeru personelu.

W przypadku, gdy rekord jest jednoznacznie określony przez wartości kilku pól (lub zestaw unikalnych atrybutów), istnieje klucz złożony (powiązany).

W niektórych przypadkach atrybut może nie mieć żadnego znaczenia: na przykład pracownik nr 3 nie ma telefonu służbowego, a odpowiedni atrybut nie jest wypełniony. W tym przypadku mówi się, że atrybut ma wartość pustą. Klucz nie może być pusty.

Prostej kolekcji tabel nie można uznać za bazę danych, jeśli nie ma między nimi zdefiniowanych relacji. W relacyjnych bazach danych relacje wskazują zgodność między rekordami w dwóch tabelach. Rozważ drugą tabelę zawierającą informacje o działach (Tabela 2.7)

Tabela 2.7

Pomiędzy dwiema przedstawionymi tabelami można ustalić relację „PRACOWNIK – pracuje w – DZIAŁ”. Chcąc uzyskać informacje o dziale, w którym pracuje pracownik nr 2 należy wziąć wartość atrybutu Kod działu w tabeli PRACOWNICY i znaleźć odpowiedni kod w tabeli DZIAŁY. W ten sposób zostaną scalone dwa rekordy z różnych tabel.

ROMANENKO ST.

DZIAŁ PERSONALNY

Widać, że relacja między dwiema tabelami jest ustalana na podstawie dopasowania wartości atrybutów dwóch tabel, w naszym przypadku jest to atrybut „kod działu” tabeli „STAFF” i „kod " atrybut tabeli "DZIAŁY". Takie atrybuty nazywają się atrybuty połączenia. Atrybut relacji w jednej tabeli musi być kluczem. W powyższym przykładzie atrybut „kod” jest kluczem dla tabeli „DZIAŁY”. Gdyby tak nie było, a kody działów w tej tabeli byłyby powtórzone, nie byłoby możliwe określenie, do którego działu odnosi się w pierwszy stół. Drugi atrybut linku, w tym przypadku „kod działu” tabeli PRACOWNICY, nazywa się klucz obcy, ponieważ odnosi się do klucza innej (zewnętrznej) tabeli (ryc. 2.12).

Tabela 2 klucz podstawowy

Bazy postrelacyjne

Jak już wspomniano, relacyjne bazy danych składają się z połączonych ze sobą dwuwymiarowych tabel. Dlatego podczas projektowania relacyjnej bazy danych wszystkie informacje są dzielone na wiele dwuwymiarowych tablic. W niektórych przypadkach tabela odpowiada zestawowi rzeczywistych obiektów, takich jak „działy”, „pracownicy”, „konta” itp. Ale czasami, gdy masz do czynienia z informacjami hierarchicznymi, musisz „rozłożyć” ten sam obiekt na kilka tabel.

Przykładem mogą być dokumenty wielowierszowe, takie jak faktura. Każdy z tych dokumentów posiada wspólne szczegóły, takie jak numer, data, nazwa dostawcy i odbiorcy. W tabeli „Faktury” takie dane tworzą jeden rekord. Faktura jest jednak dokumentem wielowierszowym, a każda linia zawierająca nazwę produktu, jego ilość, cenę, ilość również będzie wymagała osobnego rekordu. Dlatego konieczne jest utworzenie dodatkowej tabeli „Wiersze faktur” powiązanej z poprzednią. Dane każdej faktury będą zawarte w jednym rekordzie pierwszej tabeli oraz w jednym lub kilku rekordach drugiego.

Takie podejście ma szereg wad. Po pierwsze, zwiększa się liczba tabel i relacji między nimi, co w skali całej bazy danych prowadzi do wolniejszego wykonywania zapytań. Po drugie, nie bierze się pod uwagę hierarchii i logicznej jedności tabel. W tym przykładzie tabelę Invoice Lines można uznać za podrzędną względem tabeli Invoices, ponieważ nie może ona istnieć bez niej. I tylko w jedności te dwie tabele opisują tak zwany obiekt biznesowy - odpowiednik prawdziwego dokumentu. Podział obiektów biznesowych na wiele tabel komplikuje strukturę bazy danych i utrudnia użytkownikom zrozumienie.

LINIE FAKTURY

FAKTURY

Te niedociągnięcia są przezwyciężane w postrelacyjnym modelu danych, który w istocie jest rozwinięciem modelu relacyjnego z tą różnicą, że znosi ograniczenie atomowości (niepodzielności) atrybutów.

Ograniczenie niepodzielności atrybutu oznacza, że ​​w relacyjnej bazie danych atrybut (pole) każdego rekordu może zawierać tylko jedną wartość. Wręcz przeciwnie, w modelu postrelacyjnym pole może zawierać kilka wartości lub nawet całą tabelę. W ten sposób staje się możliwe „osadzenie” jednego stołu w drugim.

Pozwala to na wydajniejsze działanie na obiektach biznesowych, z których każdy staje się logicznie spójny, reprezentowany przez tylko jeden rekord.

Według twórców postrelacyjnych DBMS, szybkość wykonywania w nich zapytań wzrasta nawet 20-krotnie w porównaniu z relacyjnym DBMS. Jednak przejście od wszechobecnych relacyjnych baz danych do baz postrelacyjnych wiąże się ze znacznymi kosztami i nadal jest ograniczone.

Magazyn danych

Hurtownia danych to system zaprojektowany w celu udostępnienia jednej przestrzeni informacyjnej na potrzeby analizy i optymalizacji prowadzonej działalności.

Działalność każdego podmiotu gospodarczego wiąże się z wykorzystywaniem i przetwarzaniem informacji, która jest najważniejszym zasobem gospodarczym dla osiągania wysokich wyników ekonomicznych. Cechą EIS jest jednak konieczność przetwarzania dwóch rodzajów danych, a mianowicie operacyjnych i analitycznych. Dlatego w procesie funkcjonowania EIS należy rozwiązać dwie klasy zadań:

zapewnienie codziennej pracy przedsiębiorstwa w zakresie wprowadzania i przetwarzania informacji;

organizacja hurtowni informacji na potrzeby kompleksowej, wielowymiarowej analizy i badania danych w celu identyfikacji trendów rozwojowych, przewidywania warunków, oceny i zarządzania ryzykiem itp. i ostatecznie w celu ułatwienia podejmowania decyzji.

Zadania pierwszej klasy - automatyzacja działań operacyjnych - są całkowicie rozwiązane OLTr-systemy (online transakcyjny proces­ ing - szybkie przetwarzanie transakcji), które obejmują zautomatyzowane systemy bankowe, systemy księgowe itp. OLAP- systemy (online Analityczny Przetwarzanie - operacyjne przetwarzanie analityczne), które są zbudowane na technologii hurtowni danych i są przeznaczone do zagregowanej analizy dużych ilości danych. Systemy te są integralną częścią systemów decyzyjnych lub systemów zarządzania klasy. środkowy I najlepszy zarządzać­ ment, tych. systemy przeznaczone dla użytkowników średniego i wyższego szczebla zarządzania firmą.

Charakterystykę porównawczą wykorzystania danych w operacyjnych i analitycznych systemach przetwarzania przedstawiono w tabeli. 2.8.

Tabela 2.8

Charakterystyka operacyjnych i analitycznych systemów informatycznych

Nieruchomościdane	System
	przetwarzanie operacyjne	przetwarzanie analityczne
Cel, powód	Wyszukiwanie operacyjne, proste rodzaje przetwarzania	Przetwarzanie analityczne, prognozowanie, modelowanie
Poziom agregacji	Szczegółowe dane	Zagregowane dane
Czas przechowywania	Kilka miesięcy do roku	Kilkadziesiąt lat lub więcej
Częstotliwość aktualizacji	Wysoka. Aktualizacja w małych porcjach	Niski. Aktualizowanie w dużych porcjach, nawet do kilku milionów rekordów jednocześnie
Kryterium efektywność	Liczba transakcji na jednostkę czasu	Szybkość złożonych zapytań i przejrzystość struktury pamięci dla użytkowników

Tym samym nowoczesny EIS jest systemem opartym na współdzieleniu transakcyjnym OLTP- systemy i przechowywanie danych (Dane Hala magazynowa).

Termin „hurtownia danych” stał się popularny w latach 90. XX wieku. Zgodnie z definicją Williama Inmona, który jest twórcą tej technologii, hurtownia danych (DW) jest specyficznym dla domeny, zintegrowanym, niezmiennym, wspierającym historię zbiorem danych zorganizowanym w celu wspomagania decyzji.

Istotnymi cechami hurtowni danych są:

orientacja na temat, tj. w hurtowni danych umieszczane są tylko te informacje, które mogą być przydatne do obsługi systemów analitycznych;

obsługa danych historycznych, co decyduje o tym, że analiza wymaga informacji gromadzonych przez długi czas;

integracja w jednym repozytorium wyodrębnionych wcześniej danych pochodzących z różnych źródeł oraz ich weryfikacja, koordynacja i redukcja do jednego formatu;

Agregacja, która zapewnia jednoczesne przechowywanie danych zagregowanych i pierwotnych w bazie danych, dzięki czemu wnioski o wyznaczenie wartości sumarycznych są odpowiednio szybko realizowane.

Hurtownia danych jest więc wyspecjalizowaną bazą danych, która gromadzi, integruje i akumuluje informacje niezbędne menedżerom do przygotowania decyzji zarządczych; np. w sektorze bankowym są to informacje o klientach banku, sprawach kredytowych, stopach procentowych, kursach walut, notowaniach giełdowych, stanie portfela inwestycyjnego, dniach pracy oddziałów itp.

W związku z tym hurtownia danych jest przeznaczona nie tyle do wprowadzania informacji, co do ich szybkiego wyszukiwania i analizy. Dlatego systemy oparte na hurtowniach danych mają architekturę bazy danych, która zapewnia szybkie wykonywanie zapytań dla ogromnych ilości informacji. Wyróżnia je odmienna konstrukcja interfejsu użytkownika, reprezentująca specjalne sposoby wyszukiwania informacji, jej uogólniania i pogłębiania szczegółów.

Obecnie rozwijane są takie repozytoria, w których nie tylko gromadzone są dane, ale także przewidziana jest możliwość ich zmiany: umieszczania funkcji analitycznych, dokonywania korekt zarządczych, uzupełniania brakujących danych.

System zarządzania hurtownią danych składa się z kilku bloków funkcjonalnych.

Baza danych. To rdzeń całego systemu. Podstawową różnicą pomiędzy bazą danych hurtowni jest jej przemyślana struktura, która charakteryzuje się optymalnym składem podmiotów specyficznych dla branży finansowej oraz strukturą i zestawem atrybutów danych podmiotów, w efekcie czego struktura baza hurtowni jest zoptymalizowana pod kątem szybkiego ładowania i szybkiego wyszukiwania danych, a nie szybkiej realizacji transakcji.

Narzędzia do konfiguracji bazy danych i zarządzania metadanymi. Narzędzia te mają na celu dostosowanie modelu informacyjnego hurtowni danych podczas wdrożenia i zmianę tego modelu w trakcie pracy, aby stopniowo rozszerzać funkcjonalność hurtowni danych. Ponadto, dla maksymalnej elastyczności i możliwości dostosowania hurtowni danych, baza danych powinna przechowywać metadane jako oddzielne informacje. (metadane) - dane o danych. Metadane obejmują informacje o danych fizycznych, procesach technicznych i biznesowych, regułach i strukturze danych. Pełnią zatem rolę księgi informacyjnej zawierającej informacje o źródłach danych pierwotnych, algorytmach przetwarzania, którym poddane zostały dane wyjściowe, opisie struktur danych i ich relacji itp.

Technologia zbierania danych. Niespójność i niespójność danych, fragmentacja i izolacja źródeł, różnica w metodach przechowywania danych, brak dostępu do danych z niektórych źródeł nie pozwalają na pełne wykorzystanie tych danych. W związku z tym potrzebna jest specjalna technologia zbierania danych, która zapewni regularne i nieprzerwane odbieranie danych z różnych źródeł, w szczególności z oddziałów zdalnych, dodatkowych biur i innych systemów informatycznych, a także pozwoli zamienić całą gamę danych gromadzonych przez bank w wartościowe informacje dla biznes. Technologia ta obejmuje formaty danych, technologię generowania, reguły biznesowe regulujące ekstrakcję danych ze źródeł zewnętrznych, dystrybucję metadanych (informacji referencyjnych) i wiele innych.

Do zbierania danych stosuje się dwa podejścia: ETL- systemowy i korporacyjny standardowy format wymiany danych. Pierwszy sposób zbierania danych – wykorzystanie narzędzi ETL (Wyciąg, Transforma), specjalne systemy do wydobywania danych z innych baz, przekształcania ich zgodnie z zasadami opisanymi w tym systemie i ładowania ich do pamięci. Drugim podejściem jest użycie standardowego formatu do zbierania danych i opracowanie procedur przesyłania danych po stronie źródłowej. Pozwala to na zbieranie jednorodnych danych z heterogenicznych systemów, decentralizację rozwoju procedur wczytywania danych, dostarczając rozwiązanie tego problemu specjalistom posiadającym wiedzę o systemie źródłowym.

System czyszczenia i ładowania danych. System ten zapewnia kontrolę danych wejściowych, automatyczną korekcję błędów, eliminację powielania i błędnych wartości, doprowadzenie danych do jednolitych standardów, ładowanie dużych tablic danych oraz wielopoziomowe logowanie.

Aparatura do wykonywania obliczeń. Specjalna aparatura do wykonywania obliczeń zapewnia:

agregacja danych - obliczanie wskaźników uogólnionych, na przykład obliczanie salda miesięcznego, kwartalnego i rocznego;

konsolidacja danych - sumowanie danych wzdłuż hierarchii organizacyjnej, np. obliczanie skonsolidowanego bilansu banku;

obliczanie wskaźników pochodnych, takich jak faktyczne wykonanie budżetu, płynność, marża itp.

Interfejsy użytkownika i raporty. Hurtownia danych, gromadząca cenne informacje, powinna zapewnić jej maksymalne wykorzystanie przez pracowników. W tym celu posiada specjalne interfejsy użytkownika przeznaczone do szybkiej akwizycji danych oraz zaawansowaną technologię tworzenia i wydawania raportów.

Interfejsy do systemów zewnętrznych. Hurtownia danych dostarcza informacje do zewnętrznych systemów analitycznych i generatorów raportów. W tym celu stosowane są branżowe standardy dostępu do danych.

Architekturę systemu zarządzania hurtownią danych przedstawiono na ryc. 2.15.

Ryż. 2.15. Architektura systemu zarządzania pamięcią masową

Dane są ładowane do magazynu z operacyjnych systemów przetwarzania danych oraz ze źródeł zewnętrznych, na przykład z oficjalnych raportów przedsiębiorstw i banków, wyników obrotu giełdowego itp. Podczas ładowania danych do pamięci sprawdzana jest integralność, porównywalność, kompletność załadowanych danych, a także dokonywana jest ich niezbędna transformacja i transformacja.

Hurtownia danych skierowana jest do kierownictwa wyższego i średniego szczebla firmy odpowiedzialnego za podejmowanie decyzji i rozwój biznesu. Są to szefowie działów strukturalnych, finansowych i klienckich, a także działów marketingu, działu analiz i planowania np. działu raportowania, księgowości ogólnej, skarbu, działu analitycznego, działu marketingu itp.

Hurtownia danych oparta jest na koncepcji wielowymiarowej przestrzeni informacyjnej, czyli hipersześcianu (sześcianu wielowymiarowego). Wartości przechowywane w komórkach tej kostki i zwane faktami są wskaźnikami ilościowymi charakteryzującymi działalność firmy. W szczególności mogą to być dane o obrotach i saldach na rachunkach, strukturze wydatków i dochodów, stanie i przepływie środków itp. Wymiary sześcianu, które tworzą jedną z jego ścian, to zbiór danych tego samego typu, przeznaczonych do opisu faktów, np. oddziałów, towarów, dostawców, klientów, walut itp., czyli odpowiadają za opisanie cech jakościowych firmy. Dane są agregowane według wymiarów kostki, więc elementy wymiaru są zwykle grupowane w struktury hierarchiczne, na przykład gałęzie są często grupowane według terytorium, klienci według branży, daty według tygodni, miesięcy, kwartałów i lat. Każda komórka tej kostki „odpowiada” za określony zestaw wartości za poszczególne jej wymiary, np. obroty kont bilansowych na dzień, kwartał, rok w kontekście oddziałów.

Obecnie najszerzej stosowane są trzy typy modeli danych wykorzystywane w budowaniu hurtowni danych: wielowymiarowe, relacyjne i kombinowane.

Do model wielowymiarowy Cechą charakterystyczną jest wykorzystanie nierelacyjnych baz danych przestrzennych w postaci hipersześcianów, które zapewniają wielowymiarowe przechowywanie, przetwarzanie i prezentację danych. Główną zaletą modelu wielowymiarowego jest szybkość wyszukiwania danych. Dane znajdują się na przecięciu wymiarów hipersześcianu. Aby je wyszukać, nie trzeba organizować relacji między tabelami, jak to ma miejsce w relacyjnym DBMS. Dzięki temu średni czas odpowiedzi na złożone (nieuregulowane) zapytanie w modelu wielowymiarowym jest o 1-2 rzędy wielkości niższy niż w modelu relacyjnym.

Jednak hipersześcian wymaga dużej ilości miejsca na dysku, ponieważ wstępnie rezerwuje miejsce na wszystkie możliwe dane, ilość ta gwałtownie wzrasta wraz z wysokim stopniem granulacji danych i pojawiają się trudności z modyfikacją danych, ponieważ dodanie kolejnego wymiaru wymaga całkowitej restrukturyzacji hipersześcian.

Dlatego wskazane jest stosowanie wielowymiarowego modelu DW, gdy jego objętość jest niewielka (nie więcej niż 10-20 gigabajtów), a hipersześcian ma stabilny w czasie zestaw wymiarów.

Za pomocą model relacyjny wielowymiarową strukturę hurtowni danych realizują tabele relacyjne, zarówno ze standardowymi układami danych, takimi jak „gwiazda” i „płatek śniegu”, jak i z bardziej złożonymi szablonami SQL-upraszanie. Hurtownie danych zbudowane w oparciu o model relacyjny są w stanie przechowywać ogromne ilości informacji, ale przegrywają z modelami wielowymiarowymi szybkością wykonywania zapytań. W modelu relacyjnym hipersześcian jest emulowany przez DBMS na poziomie logicznym.

W ciągu ostatnich kilku lat zaczęli używać połączone hurtownie danych, w którym relacyjny DBMS jest połączony z całym zestawem wielowymiarowych. Relacyjna baza danych w tym przypadku jest centralnym repozytorium i pozwala gromadzić ogromne ilości informacji. Dane wymagane przez konkretne aplikacje analityczne są alokowane z centralnego repozytorium do wielowymiarowych baz danych. Każda wielowymiarowa baza danych przechowuje informacje dotyczące jednego z obszarów działalności (rys. 2.16).

Ryż. 2.16. Połączona logika hurtowni danych

Targi danych

Jedną z możliwości wdrożenia hurtowni danych w praktyce jest budowanie data martów (Dane targi). Czasami określa się je również mianem data martów. Data mart to tematyczny zbiór danych, który ma określoną organizację. Treść data martów z reguły ma na celu rozwiązywanie pewnego zakresu jednorodnych zadań z jednego lub więcej powiązanych obszarów tematycznych lub wykonywanie określonych funkcji biznesowych lub dla określonych działów. Na przykład jedna wizytówka służy do rozwiązywania problemów związanych z analizą usług kredytowych bankowych, a druga służy do analizy działań banku na giełdzie.

W związku z tym data mart to stosunkowo niewielka i wyspecjalizowana hurtownia danych zawierająca tylko dane specyficzne dla danego tematu i przeznaczona do użytku przez określoną jednostkę funkcjonalną. Tak więc data marty zorientowane na funkcje to struktury danych, które zapewniają rozwiązania analityczne w określonym obszarze funkcjonalnym lub dziale firmy, takie jak zarządzanie rentownością, analiza rynku, analiza zasobów, analiza przepływów pieniężnych, analiza bazy klientów, badania rynku, aktywa i pasywa zarządzanie itp. Tym samym data marty można uznać za małe magazyny tematyczne, które są tworzone w celu dostarczania informacji do zadań analitycznych poszczególnych działów zarządzania firmy.

Organizacja danych w gablocie jest zdeterminowana potrzebą zapewnienia najbardziej optymalnych środków do analizy danych z określonego obszaru tematycznego.

Bazy danych i hurtownie danych bardzo się od siebie różnią. Hurtownia danych tworzona jest w celu rozwiązywania problemów korporacyjnych występujących w korporacyjnym systemie informacyjnym. Zazwyczaj hurtownie danych są tworzone i pozyskiwane przez organizacje posiadające centralną sprawozdawczość, takie jak klasyczne organizacje informatyczne, takie jak bank. Hurtownia danych jest tworzona wysiłkiem całej korporacji.

Data mart jest zaprojektowany tak, aby spełniał potrzeby określonego, jednorodnego zestawu zadań. Dlatego jedna firma może mieć wiele różnych baz danych, z których każdy ma swój własny wygląd i sposób działania.

Kolejną różnicą jest ziarnistość danych, ponieważ baza danych zawiera już zagregowane dane. W hurtowni danych wręcz przeciwnie, są najbardziej szczegółowe dane.

Ponieważ poziom integracji w zbiorczych bazach danych jest wyższy niż w hurtowniach, granulacji zbiorczej bazy danych nie można łatwo rozłożyć na granularność hurtowni. Ale zawsze możesz iść w przeciwnym kierunku i agregować poszczególne dane w uogólnione wskaźniki.

W przeciwieństwie do hurtowni, data mart zawiera tylko niewielką ilość informacji historycznych, które są związane tylko z krótkim okresem czasu i mają znaczenie dopiero w momencie, gdy spełnia wymagania rozwiązania problemu. Bazy danych można traktować jako logicznie lub fizycznie odseparowane podzbiory hurtowni danych. Na ryc. 2.17 pokazuje relacje między data martami a hurtownią danych na przykładzie sektora bankowego.

Bazy danych są zazwyczaj hostowane w technologii warstwowej, która jest optymalna dla elastyczności analizy, ale nieoptymalna dla dużych ilości danych.

Struktura data martów skupia się również na wielowymiarowej organizacji danych w postaci kostki. Jednak ich budowa, ze względu na ograniczony zakres informacyjny, odpowiadający potrzebom jednego obszaru funkcjonalnego, jest znacznie prostsza i bardziej opłacalna.

Ryż. 2.17. Związek między data mart a hurtownią danych

Istnieją dwa rodzaje data martów - zależne i niezależne. Zależna baza danych to ten, którego źródłem jest magazyn danych. źródło niezależny magazyn danych jest środowiskiem podstawowych aplikacji. Zależne magazyny danych są stabilne i mają solidną architekturę. Niezależne bazy danych są niestabilne i mają niestabilną architekturę, przynajmniej podczas przesyłania danych.

Należy zauważyć, że marty danych są idealnym rozwiązaniem najbardziej znaczącego konfliktu w projektowaniu hurtowni danych - wydajności lub elastyczności. Ogólnie rzecz biorąc, im bardziej ustandaryzowany i elastyczny jest model hurtowni danych, tym mniej produktywny jest w odpowiadaniu na zapytania. Wynika to z faktu, że zgłoszenia wchodzące do standardowo zaprojektowanego systemu wymagają znacznie więcej operacji wstępnych niż w optymalnie zaprojektowanym systemie. Kierując wszystkie żądania użytkowników do hurtowni danych, utrzymując elastyczny model hurtowni danych, programiści mogą osiągnąć elastyczność i długoterminową stabilność struktury hurtowni, a także optymalną wydajność dla żądań użytkowników.

Dane, które już znajdą się w sklepie, można rozdzielić między wiele baz danych, aby uzyskać do nich dostęp za pomocą zapytań użytkowników. Te zbiorcze bazy danych mogą przybierać różne formy, od baz danych klient-serwer po bazy danych dla komputerów stacjonarnych, OLAP- kostki, a nawet dynamiczne arkusze kalkulacyjne. Wybór narzędzi do zapytań użytkowników może być szeroki i odzwierciedlać preferencje i doświadczenia poszczególnych użytkowników. Szeroka gama takich narzędzi i łatwość ich użycia sprawi, że będą one najtańszą częścią wdrożenia projektu hurtowni danych. Jeśli dane w hurtowni są dobrze ustrukturyzowane i mają sprawdzoną jakość, to przenoszenie ich do innych baz danych stanie się rutynową i tanią operacją.

Wykorzystanie technologii data mart, zarówno zależnych, jak i niezależnych, pozwala rozwiązać problem konsolidacji danych pochodzących z różnych źródeł w celu najefektywniejszego rozwiązywania problemów związanych z analizą danych. Jednocześnie źródłami mogą być różne systemy księgowe i referencyjne, różniące się architekturą i funkcjonalnością, w szczególności odmienne geograficznie.

Baza danych (DB) to zbiór uporządkowanych danych przechowywanych w pamięci systemu komputerowego i odzwierciedlających stan obiektów i ich relacje w rozważanym obszarze tematycznym.

Logiczna struktura danych przechowywanych w bazie danych nazywana jest modelem reprezentacji danych. Główne modele prezentacji danych (modele danych) to hierarchiczne, sieciowe, relacyjne.

System zarządzania bazą danych (DBMS) to zestaw narzędzi językowych i programowych zaprojektowanych do tworzenia, utrzymywania i udostępniania bazy danych wielu użytkownikom. RDBMS są zwykle rozróżniane na podstawie używanego modelu danych. Tak więc SZBD oparte na wykorzystaniu relacyjnego modelu danych nazywane są relacyjnym SZBD.

Do pracy z bazą danych często wystarczają narzędzia DBMS. Jeśli jednak wymagane jest zapewnienie wygody pracy z bazą danych dla niewykwalifikowanych użytkowników lub interfejs DBMS nie odpowiada użytkownikom, można tworzyć aplikacje. Ich tworzenie wymaga programowania. Aplikacja to program lub zestaw programów, które automatyzują rozwiązanie zastosowanego zadania. Aplikacje można tworzyć w środowisku DBMS lub poza nim – przy użyciu systemu programowania wykorzystującego narzędzia dostępu do baz danych, np. Delphi lub C++ Вuildeg. Aplikacje tworzone w środowisku DBMS są często określane jako aplikacje DBMS, podczas gdy aplikacje tworzone poza DBMS są często określane jako aplikacje zewnętrzne.

Słownik danych to podsystem bazy danych przeznaczony do scentralizowanego przechowywania informacji o strukturach danych, relacjach między plikami baz danych, typach danych i formatach prezentacji, własności danych przez użytkowników, kodach bezpieczeństwa i kontroli dostępu itp.

Systemy informatyczne oparte na wykorzystaniu bazy danych zazwyczaj działają w architekturze klient-serwer. W takim przypadku baza danych znajduje się na komputerze serwera i jest udostępniana.

Serwerem określonego zasobu w sieci komputerowej jest komputer (program), który zarządza tym zasobem, a klientem jest komputer (program) korzystający z tego zasobu. Jako zasób sieci komputerowej mogą działać na przykład bazy danych, pliki, usługi drukowania, usługi pocztowe.

Zaletą organizacji systemu informatycznego w architekturze klient-serwer jest udane połączenie scentralizowanego przechowywania, konserwacji i zbiorowego dostępu do wspólnych informacji firmowych z pracą indywidualnych użytkowników.

Zgodnie z podstawową zasadą architektury klient-serwer dane przetwarzane są wyłącznie na serwerze. Użytkownik lub aplikacja tworzy zapytania, które przychodzą do serwera bazy danych w postaci instrukcji języka SQL. Serwer bazy danych zapewnia wyszukiwanie i ekstrakcję niezbędnych danych, które są następnie przesyłane do komputera użytkownika. Zaletą tego podejścia w porównaniu z poprzednimi jest zauważalnie mniejsza ilość przesyłanych danych.

Istnieją następujące typy DBMS:

* w pełni funkcjonalny DBMS;

* serwery baz danych;

* narzędzia do tworzenia programów do pracy z bazą danych.

W pełni funkcjonalne DBMS to tradycyjne DBMS. Należą do nich dBaseIV, Microsoft Access, Microsoft FoxPro i inne.

Serwery bazodanowe przeznaczone są do organizowania centrów przetwarzania danych w sieciach komputerowych. Serwery baz danych zapewniają przetwarzanie żądań z programów klienckich, zwykle za pomocą instrukcji SQL. Przykładami serwerów bazodanowych są: Microsoft SQL Server, InterBase itp.

W roli programów klienckich można ogólnie używać DBMS, arkuszy kalkulacyjnych, edytorów tekstu, programów pocztowych itp.

Narzędzia do tworzenia programów bazodanowych można wykorzystać do tworzenia następujących programów:

* programy klienckie;

* serwery baz danych i ich poszczególne komponenty;

* aplikacje niestandardowe.

W zależności od charakteru wykorzystania DBMS dzielą się na wieloużytkownikowe (przemysłowe) i lokalne (osobiste).

Przemysłowe SZBD stanowią podstawę programową do tworzenia zautomatyzowanych systemów sterowania dla dużych obiektów gospodarczych. Przemysłowy DBMS musi spełniać następujące wymagania:

* możliwość zorganizowania wspólnej pracy równoległej wielu użytkowników;

* skalowalność;

* możliwość przenoszenia na różne platformy sprzętowe i programowe;

* stabilność w stosunku do różnego rodzaju awarii, w tym obecność wielopoziomowego systemu tworzenia kopii zapasowych przechowywanych informacji;

* Zapewnienie bezpieczeństwa przechowywanych danych oraz rozwinięty ustrukturyzowany system dostępu do nich.

Personal DBMS to oprogramowanie, które koncentruje się na rozwiązywaniu problemów lokalnego użytkownika lub małej grupy użytkowników i jest przeznaczone do użytku na komputerze osobistym. To wyjaśnia ich drugie imię - desktop. Charakterystyczne cechy systemów stacjonarnych to:

* względna łatwość obsługi, pozwalająca na tworzenie na ich podstawie działających aplikacji użytkownika;

* stosunkowo ograniczone wymagania dotyczące zasobów sprzętowych.

W zależności od używanego modelu danych DBMS są podzielone na hierarchiczne, sieciowe, relacyjne, obiektowe itp. Niektóre DBMS mogą jednocześnie obsługiwać kilka modeli danych.

Do pracy z danymi przechowywanymi w bazie danych wykorzystywane są następujące rodzaje języków:

· język opisu danych - język nieprocesowej struktury danych wysokiego poziomu;

· język manipulacji danymi - zbiór struktur zapewniających realizację podstawowych operacji do pracy z danymi: wprowadzanie, modyfikacja i selekcja danych na żądanie.

Nazwane języki w różnych DBMS mogą się różnić. Dwa najczęściej używane języki standardowe to QBE (wzorcowy język zapytań) i SQL (ustrukturyzowany język zapytań). QBE zasadniczo ma właściwości języka manipulacji danymi, SQL łączy właściwości obu typów języków.

DBMS realizuje następujące podstawowe funkcje niskopoziomowe:

* zarządzanie danymi w pamięci zewnętrznej;

* Zarządzanie buforem pamięci RAM;

* zarządzanie transakcjami;

* logowanie zmian w bazie danych;

* Zapewnienie integralności i bezpieczeństwa bazy danych.

Implementacja funkcji zarządzania danymi w pamięci zewnętrznej zapewnia organizację zarządzania zasobami w systemie plików OS.

Konieczność buforowania danych wynika z faktu, że ilość pamięci RAM jest mniejsza niż ilość pamięci zewnętrznej. Bufory to obszary pamięci RAM zaprojektowane w celu przyspieszenia wymiany między pamięcią zewnętrzną a pamięcią RAM. Bufory tymczasowo przechowują fragmenty bazy danych, z których dane mają być użyte podczas dostępu do DBMS lub mają zostać zapisane do bazy danych po przetworzeniu.

Mechanizm transakcji jest używany w DBMS do utrzymania integralności danych w bazie danych. Transakcja to niepodzielna sekwencja operacji na danych bazy danych, która jest śledzona przez DBMS od początku do końca. Jeżeli z jakiegokolwiek powodu (awarie i awarie sprzętu, błędy oprogramowania, w tym aplikacji) transakcja pozostaje niekompletna, to jest anulowana.

Transakcje mają trzy główne właściwości:

* niepodzielność (wszystkie operacje zawarte w transakcji są wykonywane lub żadne);

* serializowalność (nie ma wzajemnego wpływu transakcji wykonywanych w tym samym czasie);

* trwałość (nawet awaria systemu nie prowadzi do utraty wyników dokonanej transakcji).

Przykładem transakcji jest operacja przelewu pieniędzy z jednego konta na drugie w systemie bankowym. Najpierw pieniądze są pobierane z jednego konta, a następnie przekazywane na inne konto. Jeśli przynajmniej jedna z czynności nie zostanie zakończona pomyślnie, wynik operacji będzie nieprawidłowy i równowaga operacji zostanie zachwiana.

Zapis zmian jest wykonywany przez DBMS w celu zapewnienia niezawodności przechowywania danych w bazie danych w przypadku awarii sprzętu i oprogramowania.

Zapewnienie integralności bazy danych jest niezbędnym warunkiem pomyślnego funkcjonowania bazy danych, zwłaszcza gdy jest używana w sieci. Integralność bazy danych jest właściwością bazy danych, co oznacza, że ​​zawiera ona kompletne, spójne i odpowiednio odzwierciedlające informacje z obszaru tematycznego. Integralność stanu bazy danych jest opisana za pomocą ograniczeń integralności w postaci warunków, jakie muszą spełniać dane przechowywane w bazie danych.

Bezpieczeństwo w SZBD osiąga się poprzez szyfrowanie danych, ochronę hasłem, obsługę poziomów dostępu do bazy danych i jej poszczególnych elementów (tabele, formularze, raporty itp.).

Istnieje kilka sposobów udostępniania bazy danych programu Access, w zależności od potrzeb i dostępności zasobów. W tym artykule opisano dostępne opcje i zalety każdego z nich, a także udostępniono zasoby z dodatkowymi informacjami o tym, jak to działa.

Aby zmienić strukturę bazy danych, na komputerze musi być zainstalowany program Access.

W tym artykule

Udostępnianie danych za pomocą folderów sieciowych

Jest to najprostsza opcja z minimalnymi wymaganiami, ale zapewnia najmniejszą funkcjonalność. Dzięki tej metodzie plik bazy danych jest przechowywany na udostępnionym dysku sieciowym i wszyscy użytkownicy korzystają z niego w tym samym czasie. Ponieważ wszystkie obiekty bazy danych są używane w tym samym czasie, wielu użytkowników może jednocześnie zmieniać dane, co ogranicza niezawodność i dostępność. Wydajność może również ucierpieć, ponieważ wszystkie obiekty bazy danych są przesyłane przez sieć.

Ta opcja jest odpowiednia, jeśli z bazy danych będzie korzystać kilka osób jednocześnie, a użytkownicy nie muszą zmieniać struktury bazy.

Notatka: Ta metoda jest mniej bezpieczna niż inne metody udostępniania bazy danych, ponieważ każdy użytkownik ma pełną kopię pliku bazy danych, co zwiększa ryzyko nieautoryzowanego dostępu.

Udostępnianie bazy danych za pomocą folderu sieciowego

Jeśli nie ma udostępnionego folderu sieciowego, musisz go skonfigurować.

Więcej informacji na ten temat można znaleźć w pomocy systemu operacyjnego komputera, który będzie używany do udostępniania bazy danych. Jeśli udostępniony folder znajduje się na serwerze sieciowym, może być potrzebna pomoc administratora sieci.

Dostęp musi być skonfigurowany do otwierania w trybie współdzielonym na wszystkich komputerach użytkowników. Ten tryb jest używany domyślnie, ale należy to sprawdzić: jeśli użytkownik otworzy bazę danych w trybie wyłączności, inni użytkownicy nie będą mogli pracować z danymi. Wykonaj poniższe czynności na każdym komputerze.

1. Uruchom dostęp i na karcie Plik Wybierz przedmiot Parametry.

   W oknie Opcje dostępu Wybierz przedmiot Opcje klienta.

Skopiuj plik bazy danych do udostępnionego folderu. Następnie ustaw atrybuty pliku, aby umożliwić dostęp do odczytu/zapisu do pliku bazy danych. Aby korzystać z bazy danych, potrzebujesz do niej dostępu z uprawnieniami do odczytu i zapisu.

Utwórz skrót do pliku bazy danych na komputerze każdego użytkownika. W oknie dialogowym Właściwości skrótu określ ścieżkę do pliku bazy danych we właściwości Cel, używając adresu UNC zamiast litery dysku mapowanego. Na przykład zamiast ścieżki F:\przykład.accdb wskazać ścieżkę \\nazwa komputera\shared.accdb.

Notatka: Użytkownicy mogą wykonać tę czynność samodzielnie.

Udostępnianie partycjonowanej bazy danych

Ta metoda jest przydatna, jeśli nie masz witryny programu SharePoint ani serwera bazy danych. Udostępnione bazy danych można udostępniać w sieci lub za pośrednictwem witryny programu SharePoint. Kiedy baza danych jest dzielona, ​​jest reorganizowana do dwóch plików: bazy danych serwera, która zawiera tabele danych, oraz bazy danych klienta, która zawiera wszystkie inne obiekty bazy danych (np. zapytania, formularze, raporty). Każdy użytkownik wchodzi w interakcję z danymi przy użyciu lokalnej kopii zewnętrznej bazy danych.

Korzyści z partycjonowania bazy danych

Zwiększyć wydajność. W sieci udostępniane są tylko dane, a nie tabele, zapytania, formularze, raporty, makra lub moduły.

Zwiększona dostępność Transakcje bazodanowe, takie jak edytowanie rekordów, są szybsze.

Ulepszone bezpieczeństwo. Użytkownicy uzyskują dostęp do bazy danych serwera za pośrednictwem połączonych tabel; jest mniej prawdopodobne, że atakujący mogą uzyskać nieautoryzowany dostęp do danych za pośrednictwem bazy danych klienta.

Zwiększona niezawodność Jeśli użytkownik napotka problem i baza danych zostanie nieoczekiwanie zamknięta, uszkodzenie pliku bazy danych jest zwykle ograniczone do kopii bazy danych klienta, którą użytkownik otworzył.

Elastyczne środowisko programistyczne Każdy użytkownik może samodzielnie tworzyć zapytania, formularze, raporty i inne obiekty bazy danych bez wpływu na pracę innych użytkowników. Ponadto można opracowywać i rozpowszechniać nową wersję bazy danych po stronie klienta bez zakłócania dostępu do danych przechowywanych w wewnętrznej bazie danych.

Jeśli ta metoda działa, przejdź do instrukcji w artykule Partycjonowanie bazy danych programu Access.

Udostępnianie bazy danych w witrynie SharePoint

Jeśli masz serwer z SharePoint (zwłaszcza z usługami Access), istnieje kilka dobrych opcji. Integracja z SharePoint pomaga zapewnić lepszy dostęp do bazy danych. Podczas publikowania bazy danych w sieci Web Access Services tworzy witrynę programu SharePoint zawierającą tę bazę danych. Wszystkie obiekty bazy danych i same dane są przenoszone na listy programu SharePoint w tej witrynie.

Opublikowana baza danych jest hostowana w Internecie. Można tworzyć formularze i raporty internetowe uruchamiane w oknie przeglądarki, a także standardowe obiekty programu Access (czasami nazywane obiektami klienta, aby odróżnić je od obiektów sieci Web). Aby korzystać z obiektów klienta programu Access, musisz mieć zainstalowaną aplikację programu Access, ale wszystkie obiekty bazy danych przechowywane w programie SharePoint są współużytkowane.

Notatka: Jeśli na komputerze jest zainstalowany program Access, możesz używać obiektów klienckich z bazy danych sieci Web, a nie tylko obiektów bazy danych sieci Web.

Access Services zapewnia platformę do tworzenia bez danych, z której można korzystać w Internecie. Bazy danych sieci Web są budowane i publikowane przy użyciu programu Access 2010 i SharePoint, po czym można korzystać z bazy danych sieci Web za pośrednictwem przeglądarki internetowej.

Formularze, raporty i makra interfejsów działają w przeglądarce.

Jeśli korzystasz z internetowej bazy danych, dane są przechowywane na listach programu SharePoint: wszystkie tabele są konwertowane na listy programu SharePoint, a wpisy stają się elementami listy. Pozwala to kontrolować dostęp do internetowej bazy danych za pomocą uprawnień programu SharePoint.

Zapytania i makra danych są uruchamiane na serwerze: Całe przetwarzanie kodu SQL odbywa się na serwerze. Poprawia to wydajność sieci, ponieważ przesyłane są przez nią tylko zestawy wyników.

Zapisywanie bazy danych w bibliotece dokumentów

Bazę danych można zapisać w dowolnej bibliotece dokumentów SharePoint. Ta metoda jest podobna do zapisywania bazy danych w udziale sieciowym i zapewnia wygodny sposób kontrolowania dostępu do bazy danych. Łączenie z listą programu SharePoint udostępnia tylko dane, a nie obiekty bazy danych. Każdy użytkownik otrzymuje własną kopię bazy danych.

Na przykład jeśli witryna programu SharePoint zawiera listy, które śledzą problemy z obsługą klienta i przechowują dane pracowników, możesz utworzyć bazę danych w programie Access, która będzie działać jako interfejs dla tych list. Możesz tworzyć zapytania programu Access, aby analizować te problemy, oraz raporty programu Access, aby formatować i publikować pisemne raporty na spotkania zespołu. Jeśli użytkownicy mają zainstalowany program Access na swoich komputerach, możesz przyznać dostęp do zapytań i raportów programu Access dla listy programu SharePoint za pomocą menu Reprezentacja. Podczas przeglądania listy w witrynie SharePoint użytkownicy mogą wyszukiwać i otwierać zapytania, raporty i inne obiekty programu Access z menu Reprezentacja. Jeśli użytkownicy nie mają aplikacji programu Access, nadal mogą używać danych z list przy użyciu widoków programu SharePoint.

Otwórz bazę danych, którą chcesz udostępnić.

Na karcie Plik Wybierz przedmiot Zapisz jako.

Notatka: Jeśli korzystasz z programu Access 2010, wybierz elementy Plik > Zapisz i opublikuj > Zapisz bazę danych jako > SharePoint.

W oknie dialogowym Zapisz w SharePoint przejdź do odpowiedniej biblioteki dokumentów.

Sprawdź nazwę i typ pliku bazy danych, zmień je w razie potrzeby i kliknij przycisk Zapisać.

Aby uzyskać więcej informacji, zobacz Publikowanie w usługach dostępu oraz Importowanie i łączenie danych z listą programu SharePoint.

Udostępnianie bazy danych poprzez linkowanie do list SharePoint

Ta metoda ma te same zalety, co użycie podzielonej bazy danych i umożliwia każdemu użytkownikowi modyfikowanie własnej kopii bazy danych, ponieważ dane są udostępniane za pośrednictwem witryny programu SharePoint. Chociaż nie zapewnia to korzyści wynikających z publikowania bazy danych w witrynie programu SharePoint, zapewnia korzyści wynikające z centralnej lokalizacji danych. Ponieważ dane znajdują się na listach programu SharePoint, można je udostępniać w sieci za pomocą funkcji programu SharePoint.

Ta metoda obejmuje trzy główne kroki.

Przenieś dane na listy programu SharePoint.

Utwórz linki do tych list.

Dystrybucja pliku bazy danych.

Możesz użyć Kreatora migracji do witryny programu SharePoint, aby wykonać pierwsze dwa kroki, a ostatni krok możesz wykonać za pomocą dowolnego z dostępnych narzędzi.

Korzystanie z Kreatora eksportu tabeli SharePoint

Na karcie Praca z bazami danych w grupie Transfer danych kliknij element SharePoint.

Notatka: Ta pozycja jest dostępna tylko wtedy, gdy plik bazy danych jest zapisany w formacie accdb.

Postępuj zgodnie z instrukcjami Kreatora eksportu tabel do programu SharePoint; w szczególności określ lokalizację witryny programu SharePoint. Aby anulować proces, kliknij przycisk Anulować.

Aby wyświetlić więcej informacji o migracji, na ostatniej stronie kreatora zaznacz pole wyboru Detale.

Ta strona zawiera informacje o tym, które tabele są powiązane z listami, a także informacje o lokalizacji kopii zapasowych i adresie URL bazy danych. Wyświetla również ostrzeżenie w przypadku problemów z migracją i wskazuje lokalizację tabeli dziennika, w której można wyświetlić więcej informacji o problemach.

Gdy wszystkie kroki kreatora zostaną zakończone, kliknij przycisk Gotowy.

Jeśli kreator wyświetli ostrzeżenie, należy przejrzeć tabelę dziennika i podjąć niezbędne działania. Na przykład możesz chcieć cofnąć migrację niektórych pól lub przekonwertować je na inne typy danych, które są zgodne z listami programu SharePoint.

Notatka: Aby wyświetlić listy w witrynie SharePoint, kliknij przycisk w sekcji Szybkie uruchamianie Listy lub wybierz przedmiot Zobacz całą zawartość węzła. Może być konieczne odświeżenie strony w przeglądarce internetowej. Aby wyświetlić listy w Szybkim uruchamianiu w witrynie programu SharePoint lub zmienić inne ustawienia (takie jak włączanie przechowywania wersji), możesz zmienić ustawienia list w witrynie programu SharePoint. Aby uzyskać więcej informacji, zobacz pomoc do witryny programu SharePoint.

Udostępnianie bazy danych serwerowi

Bazę danych można udostępniać za pomocą aplikacji Access i serwera bazy danych (takiego jak SQL Server). Ta metoda ma wiele zalet, ale wymaga dodatkowego oprogramowania - serwera bazy danych.

Ta metoda jest podobna do partycjonowania bazy danych, ponieważ tabele są przechowywane w sieci, a każdy użytkownik ma lokalną kopię pliku bazy danych programu Microsoft Access, która zawiera łącza do tabel, zapytań, formularzy, raportów i innych obiektów bazy danych. Użyj tej opcji, jeśli serwer bazy danych jest dostępny i wszyscy użytkownicy mają zainstalowany program Access. Korzyści z tej metody zależą od używanego oprogramowania serwera bazy danych, ale generalnie obejmują konta użytkowników i selektywny dostęp do danych, doskonałą dostępność danych oraz wygodne wbudowane narzędzia do zarządzania danymi. Co więcej, większość aplikacji serwera bazy danych działa poprawnie z wcześniejszymi wersjami programu Access, więc nie chcesz, aby wszyscy użytkownicy korzystali z tej samej wersji. Udostępniane są tylko tabele.

Korzyści z udostępniania bazy danych serwerowi bazy danych

Wysoka wydajność i skalowalność W wielu przypadkach serwer bazy danych zapewnia lepszą wydajność niż pojedynczy plik bazy danych programu Access. Wiele produktów serwerowych baz danych zapewnia również obsługę bardzo dużych baz danych, których rozmiar wynosi około 500 na interwał (2 GB) dla pliku bazy danych programu Access (dwa gigabajty). Produkty serwerowe bazy danych zazwyczaj działają bardzo wydajnie, przetwarzając zapytania równolegle (używając wielu wątków natywnych w tym samym procesie do przetwarzania żądań użytkowników) i minimalizując dodatkowe wymagania dotyczące pamięci podczas dodawania nowych użytkowników.

Zwiększona dostępność Większość produktów serwerowych baz danych umożliwia tworzenie kopii zapasowych bazy danych, gdy jest ona używana. Dzięki temu użytkownicy nie muszą na siłę zamykać bazy danych, aby wykonać kopię zapasową danych. Co więcej, serwer bazy danych zazwyczaj bardzo efektywnie radzi sobie z edycją równoległą i blokowaniem rekordów.

Rozszerzona ochrona Nie ma możliwości pełnego zabezpieczenia bazy danych. Jednak produkty serwerowe bazy danych oferują silne zabezpieczenia, które pomagają chronić dane przed nieautoryzowanym użyciem. Większość produktów serwerowych baz danych oferuje zabezpieczenia oparte na kontach, co pozwala określić, kto może zobaczyć, które tabele. Nawet jeśli dostęp do interfejsu nie jest prawidłowy, nieautoryzowane wykorzystanie danych jest zabronione przez ochronę opartą na koncie.

Opcje automatycznego odzyskiwania W przypadku awarii systemu (takiej jak awaria systemu operacyjnego lub awaria zasilania) niektóre produkty serwerowe baz danych mają mechanizmy automatycznego przywracania, które przywracają bazę danych do ostatniego spójnego stanu w ciągu kilku minut, bez potrzeby korzystania z pomocy administratora bazy danych. brać udział.

Przetwarzanie serwera Korzystanie z programu Access w konfiguracji klienta i serwera pomaga zmniejszyć ruch w sieci, przetwarzając zapytania bazy danych na serwerze przed wysłaniem wyników do klienta. Przetwarzanie serwera jest zwykle bardziej wydajne, zwłaszcza w przypadku dużych zbiorów danych.

Podstawowe kroki korzystania z programu Access z serwerem bazy danych

Czynniki, które należy wziąć pod uwagę przy wyborze metody

Wymagania dotyczące metody	Partycjonowanie bazy danych	folder sieciowy	Witryna SharePoint	Serwer bazy danych
Potrzeba oprogramowanie serwera bazy danych
Potrzeba SharePoint
Potrzebować dostępność Dostęp do usług na serwerze SharePoint			Zależy od scenariusza: łączenie do list i zapisywanie w bibliotece dokumentów nie wymaga Access Services; publikowanie jako internetowej bazy danych lub aplikacji internetowej wymaga Access Services.
Dostępność danych		Nadaje się dla małych grup, jeśli dane niewiele się zmieniają	Najlepsze. Nadaje się do scenariuszy użytkowania offline.	Najlepsze
Bezpieczeństwo	Zależy od dodatkowych środków	Najmniej bezpieczny sposób	Najlepsze	Najlepsze
Elastyczność	Elastyczny sposób. Możesz łatwo tworzyć nowe funkcje bazy danych bez zakłóceń. Użytkownicy mogą modyfikować strukturę we własnej kopii.	Mniej elastyczny sposób. Rozwój można wykonać za pomocą kopii bazy danych w trybie offline, która jest następnie zastępowana. Nie ma możliwości indywidualnej zmiany struktury bazy danych przez użytkowników.	Elastyczny sposób. Używanie uprawnień SharePoint do kontrolowania dostępu i zmiany projektu. Umożliwia korzystanie z niektórych obiektów bazy danych, takich jak formularze, w oparciu o przeglądarkę.	Elastyczny sposób. Możesz łatwo tworzyć nowe funkcje bazy danych bez zakłóceń. Użytkownicy mogą zmieniać strukturę obiektów we własnej kopii.

30.03.17 3,4K

Kierując się zasadami opisanymi w tym artykule, możesz stworzyć bazę danych, która działa poprawnie i może być dostosowana do nowych wymagań w przyszłości. Przyjrzymy się podstawowym zasadom projekt bazy danych i sposoby jej optymalizacji.

Proces projektowania bazy danych

Odpowiednio ustrukturyzowana baza danych:

• Pomaga zaoszczędzić miejsce na dysku, eliminując niepotrzebne dane;
• Utrzymuje dokładność i integralność danych;
• Zapewnia łatwy dostęp do danych.

Rozwój bazy danych obejmuje następujące kroki:

1. Analiza wymagań lub określenie przeznaczenia bazy danych;
2. Organizacja danych w tabelach;
3. Wskazanie kluczy podstawowych i analiza relacji;
4. Normalizacja tabeli.

Rozważ każdy faza projektowania bazy danych jeszcze. Zauważ, że ten samouczek koncentruje się na modelu relacyjnej bazy danych Edgara Codda napisanym w SQL ( a nie model hierarchiczny, sieciowy lub obiektowy).

Analiza wymagań: Określ cel bazy danych

Na przykład, jeśli budujesz bazę danych dla biblioteki publicznej, musisz zastanowić się, w jaki sposób zarówno czytelnicy, jak i bibliotekarze powinni mieć dostęp do bazy danych.

Oto kilka sposobów zbierania informacji przed utworzeniem bazy danych:

• Ankieta osób, które będą z niej korzystać;
• Analiza formularzy biznesowych takich jak faktury, harmonogramy, ankiety;
• Uwzględnienie wszystkich istniejących systemów danych ( w tym pliki fizyczne i cyfrowe,).

Zacznij od zebrania istniejących danych, które mają zostać włączone do bazy danych. Następnie określ typy danych, które chcesz przechowywać. Jak również obiekty opisujące te dane. Na przykład:

Klienci

• Adres;
• Miasto, województwo, kod pocztowy;
• Adres e-mail.

Dobra

• Imię;
• Cena £;
• Ilość w magazynie;
• Ilość pod zamówienie.

Zamówienia

• Numer zamówienia;
• przedstawiciel handlowy;
• Data;
• Produkt;
• Ilość;
• Cena £;
• Cena £.

Podczas projektowania relacyjnej bazy danych informacje te staną się później częścią słownika danych, który opisuje tabele i pola bazy danych. Podziel informacje na możliwie najmniejsze części. Rozważ na przykład oddzielenie adresu pocztowego i pola stanu, aby można było filtrować osoby według stanu, w którym mieszkają.

Po podjęciu decyzji, jakie dane znajdą się w bazie, skąd te dane będą pochodzić i w jaki sposób zostaną wykorzystane, można przystąpić do planowania rzeczywistej bazy danych.

Struktura bazy danych: bloki konstrukcyjne

Następnym krokiem jest wizualizacja bazy danych. Aby to zrobić, musisz dokładnie wiedzieć, jak zbudowane są relacyjne bazy danych. W bazie danych powiązane dane są pogrupowane w tabele, z których każda składa się z wierszy i kolumn.

Aby przekonwertować listy danych na tabele, zacznij od utworzenia tabeli dla każdego typu obiektu, takiego jak produkty, sprzedaż, klienci i zamówienia. Oto przykład:

Każdy wiersz w tabeli nazywany jest rekordem. Rekordy zawierają informacje o czymś lub o kimś, na przykład o określonym kliencie. kolumny (zwane również polami lub atrybutami) zawierają informacje tego samego typu, które są wyświetlane dla każdego wpisu, takie jak adresy wszystkich klientów wymienionych w tabeli.

Aby zapewnić spójność między rekordami podczas projektowania modelu bazy danych, przypisz do każdej kolumny odpowiedni typ danych. Typowe typy danych obejmują:

• CHAR - określona długość tekstu;
• VARCHAR - tekst o różnej długości;
• TEKST - duża ilość tekstu;
• INT jest dodatnią lub ujemną liczbą całkowitą;
• FLOAT , DOUBLE - liczby zmiennoprzecinkowe;
• BLOB to dane binarne.

Niektóre DBMS oferują również typ danych Autonumerowanie, który automatycznie generuje unikalny numer w każdym wierszu.

W wizualnej reprezentacji bazy danych każda tabela będzie reprezentowana przez blok na diagramie. Nagłówek każdego bloku powinien wskazywać, co opisują dane w tej tabeli, a atrybuty powinny być wymienione poniżej:

Na projekt bazy danych informacji musisz zdecydować, które atrybuty, jeśli w ogóle, będą służyć jako klucz podstawowy dla każdej tabeli. główny klucz ( PK) to unikalny identyfikator tego obiektu. Dzięki niemu możesz wybrać dane konkretnego klienta, nawet jeśli znasz tylko tę wartość.

Atrybuty wybrane jako klucze podstawowe muszą być unikalne, niezmienne i nie mogą być ustawione na NULL ( nie mogą być puste). Z tego powodu numery zamówień i nazwy użytkowników są odpowiednimi kluczami podstawowymi, ale numery telefonów lub adresy nie. Możesz także użyć wielu pól jako klucza podstawowego w tym samym czasie ( nazywa się to kluczem złożonym).

Kiedy przychodzi czas na stworzenie rzeczywistej bazy danych, implementujesz zarówno logiczną, jak i fizyczną strukturę za pomocą języka definicji danych obsługiwanego przez Twój DBMS.

Musisz również oszacować rozmiar bazy danych, aby upewnić się, że możesz uzyskać żądaną wydajność i że masz wystarczającą ilość miejsca do przechowywania.

Tworzenie relacji między podmiotami

Teraz, gdy dane zostały przekonwertowane na tabele, musimy przeanalizować relacje między nimi. Złożoność bazy danych zależy od liczby elementów wchodzących w interakcje między dwiema powiązanymi tabelami. Określenie złożoności pomaga zapewnić, że dane zostały podzielone na tabele w najbardziej wydajny sposób.

Każdy obiekt można powiązać z innym za pomocą jednego z trzech typów łączy:

Komunikacja jeden-do-jednego

Gdy istnieje tylko jedno wystąpienie obiektu A dla każdego wystąpienia obiektu B, mówi się, że mają one relację jeden do jednego ( często określany jako 1:1). Możesz wskazać ten typ relacji na diagramie ER za pomocą linii z myślnikiem na każdym końcu:

Podczas projektowania i tworzenia baz danych, jeśli nie masz powodu, aby rozdzielać te dane, relacja 1:1 zwykle wskazuje, że lepiej połączyć te tabele w jedną.

Jednak w pewnych okolicznościach bardziej odpowiednie jest tworzenie tabel z relacjami 1:1. Jeśli masz pole z opcjonalnymi danymi, takimi jak „opis”, które jest puste dla wielu rekordów, możesz przenieść wszystkie opisy do osobnej tabeli, eliminując puste pola i poprawiając wydajność bazy danych.

Aby zapewnić poprawną korelację danych, w każdej tabeli należy uwzględnić co najmniej jedną identyczną kolumnę. Najprawdopodobniej będzie to klucz podstawowy.

Związek jeden-do-wielu

Te relacje występują, gdy rekord w jednej tabeli jest powiązany z wieloma rekordami w innej. Na przykład jeden klient może złożyć wiele zamówień lub czytelnik może mieć kilka książek wypożyczonych z biblioteki naraz. Relacje jeden-do-wielu (1:M ) są określane przez tak zwaną „kurzą łapkę”, jak w tym przykładzie:

Aby zaimplementować relację 1:M, dodaj klucz podstawowy z „jednej” tabeli jako atrybut do drugiej tabeli. Kiedy klucz podstawowy jest wymieniony w innej tabeli w ten sposób, nazywany jest kluczem obcym. Tabela po stronie relacji „1” jest tabelą nadrzędną dla tabeli podrzędnej po drugiej stronie.

Związek wiele-do-wielu

Gdy wiele obiektów jednej tabeli może być powiązanych z wieloma obiektami innej tabeli. Mówią, że mają połączenie wiele do wielu» ( M:N). Na przykład w przypadku studentów i kursów, ponieważ student może uczęszczać na wiele kursów, a w każdym kursie może uczestniczyć wielu studentów.

Na diagramie ER te relacje są wyświetlane za pomocą następujących wierszy:

Projektując strukturę bazy danych, nie jest możliwe zaimplementowanie tego rodzaju relacji. Zamiast tego musisz rozbić je na dwie relacje jeden-do-wielu.

Aby to zrobić, musisz utworzyć nową encję między tymi dwiema tabelami. Jeśli istnieje relacja M:N między sprzedażą a produktami, możesz nazwać ten nowy obiekt „ sprzedawane_produkty' ponieważ będzie zawierał dane dla każdej sprzedaży. Zarówno tabela sprzedaży, jak i tabela produktów będą miały relację 1:M ze sprzedanymi_produktami . Ten rodzaj obiektu pośredniego w różnych modelach nazywany jest tabelą połączeń, obiektem asocjacyjnym lub tabelą połączeń.

Każdy wpis w tabeli połączeń będzie odpowiadał dwóm podmiotom z sąsiednich tabel. Na przykład tabela relacji między uczniami i kursami może wyglądać tak:

Obowiązkowe czy nie?

Innym sposobem analizy relacji jest rozważenie, która strona relacji musi istnieć, aby istniała druga. Opcjonalną stronę można oznaczyć kółkiem na linii. Na przykład kraj musi istnieć, aby mieć przedstawiciela w ONZ, a nie odwrotnie:

Dwa obiekty mogą być współzależne ( jedno nie może istnieć bez drugiego).

Linki rekurencyjne

Czasami podczas projektowania bazy danych tabela wskazuje na siebie. Na przykład tabela pracowników może mieć atrybut „kierownik”, który odnosi się do innej osoby w tej samej tabeli. Nazywa się to linkami rekurencyjnymi.

Dodatkowe połączenia

Dodatkowe połączenia to te, które są wyrażane więcej niż raz. Zazwyczaj możesz usunąć jeden z tych linków bez utraty ważnych informacji. Na przykład, jeśli obiekt „uczniowie” ma bezpośredni związek z innym obiektem zwanym „nauczycielami”, ale ma również pośredni związek z nauczycielami poprzez „przedmioty”, należy usunąć powiązanie między „uczniami” i „nauczycielami”. Ponieważ jedynym sposobem, w jaki nauczyciele są przydzielani do uczniów, są przedmioty.

Normalizacja bazy danych

Po wstępnym zaprojektowaniu bazy danych można zastosować reguły normalizacji, aby zapewnić prawidłową strukturę tabel.

Jednocześnie nie wszystkie bazy danych wymagają normalizacji. Ogólnie rzecz biorąc, bazy danych z przetwarzaniem transakcji w czasie rzeczywistym ( OLTP) należy znormalizować.

Bazy danych z interaktywnym przetwarzaniem analitycznym ( OLAP), które umożliwiają łatwiejszą i szybszą analizę danych, mogą być wydajniejsze przy pewnym stopniu denormalizacji. Głównym kryterium jest tutaj szybkość obliczeń. Każda forma lub poziom normalizacji zawiera reguły związane z niższymi formami.

Pierwsza forma normalizacji

Pierwsza forma normalizacji ( w skrócie 1NF) mówi, że podczas logiczny projekt bazy danych każda komórka w tabeli może mieć tylko jedną wartość, a nie listę wartości. Dlatego tabela taka jak ta poniżej nie jest zgodna z 1NF :

Możesz obejść to ograniczenie, dzieląc dane na dodatkowe kolumny. Ale jest to również niezgodne z zasadami: tabela z grupami zduplikowanych lub blisko powiązanych atrybutów nie jest zgodna z pierwszą formą normalizacji. Na przykład poniższa tabela nie jest zgodna z 1NF :
Zamiast tego podczas fizycznego projektowania bazy danych podziel dane na wiele tabel lub rekordów, aż każda komórka będzie zawierała tylko jedną wartość i nie będzie żadnych dodatkowych kolumn. Takie dane są uważane za podzielone do najmniejszego użytecznego rozmiaru. W powyższej tabeli możesz utworzyć dodatkową tabelę ” Szczegóły sprzedaży”, który dopasuje określone produkty do sprzedaży. „Sprzedaż” będzie miała relację 1:M z „ Szczegóły sprzedaży».

Druga forma normalizacji

Druga forma normalizacji ( 2NF) określa, że ​​każdy z atrybutów musi całkowicie zależeć od klucza podstawowego. Każdy atrybut musi bezpośrednio zależeć od całego klucza podstawowego, a nie pośrednio przez inny atrybut.

Na przykład atrybut „wiek” zależy od „urodziny”, który z kolei zależy od „identyfikatora ucznia”, ma częściową zależność funkcjonalną. Tabela zawierająca te atrybuty nie będzie zgodna z drugą formą normalizacji.

Ponadto tabela z kluczem podstawowym składającym się z wielu pól narusza drugą formę normalizacji, jeśli jedno lub więcej pól nie zależy od każdej części klucza.

Tym samym tabela z tymi polami nie będzie pasować do drugiej formy normalizacji, ponieważ atrybut nazwy produktu zależy od identyfikatora produktu, a nie od numeru zamówienia:

• Numer zamówienia (klucz podstawowy);
• Identyfikator produktu (klucz podstawowy);
• Nazwa produktu.

Trzecia forma normalizacji

Trzecia forma normalizacji ( 3NF) : każda kolumna niekluczowa musi być niezależna od każdej innej kolumny. Jestem gruby projekt relacyjnej bazy danych zmiana wartości w jednej niekluczowej kolumnie powoduje zmianę innej wartości, ta tabela nie jest zgodna z trzecią formą normalizacji.

Zgodnie z 3NF nie można przechowywać w tabeli żadnych danych pochodnych, takich jak kolumna Podatek, która w poniższym przykładzie jest bezpośrednio powiązana z całkowitą wartością zamówienia:

Kiedyś proponowano dodatkowe formy normalizacji. W tym normalizacja postaci Boyce-Codd, forma od czwartego do szóstego i normalizacja klucza domeny, ale pierwsze trzy są najczęstsze.

Dane wielowymiarowe

Niektórzy użytkownicy mogą potrzebować dostępu do wielu widoków tego samego typu danych, zwłaszcza w bazach danych OLAP. Na przykład mogą chcieć poznać sprzedaż według klienta, kraju i miesiąca. W takiej sytuacji lepiej jest utworzyć centralną tabelę, do której mogą się odwoływać tabele klientów, krajów i miesięcy. Na przykład:

Zasady integralności danych

Używam również narzędzia do projektowania baz danych konieczne jest skonfigurowanie bazy danych z uwzględnieniem możliwości sprawdzenia danych pod kątem zgodności z określonymi regułami. Wiele DBMS, takich jak Microsoft Access, automatycznie wymusza niektóre z tych reguł.

Reguła integralności stwierdza, że ​​klucz podstawowy nigdy nie może mieć wartości NULL . Jeśli klucz ma wiele kolumn, żadna z nich nie może mieć wartości NULL . W przeciwnym razie może niejednoznacznie identyfikować wpis.

Reguła integralności referencyjnej wymaga, aby każdy klucz obcy wymieniony w jednej tabeli był mapowany na jeden klucz podstawowy w tabeli, do której się odnosi. Jeśli klucz podstawowy zostanie zmieniony lub usunięty, zmiany te muszą zostać zaimplementowane we wszystkich obiektach, do których odwołuje się ten klucz w bazie danych.

Reguły integralności logiki biznesowej zapewniają zgodność danych z określonymi parametrami logicznymi. Na przykład godzina spotkania musi mieścić się w standardowych godzinach pracy.

Dodawanie indeksów i widoków

Indeks to posortowana kopia jednej lub więcej kolumn z wartościami w porządku rosnącym lub malejącym. Dodanie indeksu pozwala szybciej znaleźć rekordy. Zamiast ponownego sortowania dla każdego zapytania, system może uzyskać dostęp do rekordów w kolejności określonej przez indeks.

Chociaż indeksy przyspieszają pobieranie danych, mogą spowolnić dodawanie, aktualizowanie i usuwanie danych, ponieważ indeks wymaga odbudowy po każdej zmianie rekordu.

Widok to zapisane zapytanie o dane. Widoki mogą zawierać dane z wielu tabel lub wyświetlać część tabeli.

Rozszerzone właściwości

Później projekt modelu bazy danych możesz udoskonalić swoją bazę danych za pomocą zaawansowanych właściwości, takich jak tekst pomocy, maski wprowadzania i reguły formatowania, które mają zastosowanie do określonego schematu, widoku lub kolumny. Zaletą tej metody jest to, że ponieważ reguły te są przechowywane w samej bazie danych, reprezentacja danych będzie spójna w wielu programach uzyskujących dostęp do danych.

SQL i UML

Ujednolicony język modelowania ( UML) to kolejny wizualny sposób wyrażania złożonych systemów utworzonych w języku obiektowym. Niektóre koncepcje wymienione w tym samouczku są znane pod różnymi nazwami w UML. Na przykład obiekt w UML jest znany jako klasa.

Teraz UML nie jest używany tak często. Obecnie jest stosowany w środowisku akademickim oraz w komunikacji między programistami a ich klientami.

Dobry zły