--- pl:dydaktyka:ztb:2011:projekty:migracja_crm:start [2011/09/28 11:36]
ztb2011
+++ pl:dydaktyka:ztb:2011:projekty:migracja_crm:start [2019/06/27 15:50] (aktualna)
@@ Linia 1: / Linia 1: @@
-===== Wdrażanie systemów CRM czyli  udoskonalenie procesów zarządzania przepływu danych w firmie.=====
+======  Wdrażanie systemów CRM czyli  udoskonalenie procesów zarządzania przepływu danych w firmie. ======
@@ Linia 99: / Linia 99: @@
 **Relacje: nauczyciel-szkoła-podręcznik:**
-^Schemat docelowy^^Schenat obecny^
+^Schemat docelowy^^Schemat obecny^
 |{{:pl:dydaktyka:ztb:2011:projekty:migracja_crm:dsc03414.jpg|}}||{{:pl:dydaktyka:ztb:2011:projekty:migracja_crm:n-s-p.jpg|}}|
-== ==
 **Role osoby w instytucji:**
-^Schemat docelowy^^Schenat obecny^
+^Schemat docelowy^^Schemat obecny^
-||||
+|{{:pl:dydaktyka:ztb:2011:projekty:migracja_crm:dsc03415.jpg|}}||{{:pl:dydaktyka:ztb:2011:projekty:migracja_crm:role.jpg|}}|
+**Uogólniony model reakcji marketingowych:**
+^Schemat docelowy^^Schemat obecny^
+|{{:pl:dydaktyka:ztb:2011:projekty:migracja_crm:dsc03416.jpg|}}||BRAK FUNKCJONALNOŚCI|
+Jak widać na załączonych przykładach, rzeczywisty obraz bazy danych znacznie różni się od jego idealnego modelu. Jest to spowodowane głównie tym, że na etapie projektowania ciężko przewidzieć wszystkie element, które powinny znaleźć sie w bazie danych, jak również niełatwym zadaniem jest odwzorowanie wszystkich zależności i procesów zachodzących w przedsiębiorstwie. Niektóre podstawowe elementy systemu CRM zostały też pominięte tj. opis reakcji marketingowych.
+Tworząc, lub wdrążając nowy system CRM, konieczne będzie dopasowanie i ujednolicenie schematów, a także przeprowadzenie odpowiednich migracji ze starej bazy na nową. Z racji niekompletności części danych do pełnego wdrożenia nowego systemu, należałoby utrzymywać działającą stara bazę zsynchronizowana z nową, tak by dane były na bieżąco aktualizowane i jednocześnie wprowadzać nowe systemy pozyskiwania danych, określać procesy biznesowe i szablony postępowań w pozyskiwaniu i wprowadzaniu danych tak by w momencie przejścia na nowy system nie wystąpił problem niekonsystencji danych.
+===== 7. Migracje w MSSQL: =====
+Migracja bazy danych może odbywać się na kilka sposobów w zależności od systemu jaki obsługujemy, rodzaju bazy danych, producenta, oraz potrzeb naszego nowego systemu.
+Najprostszym sposobem przeniesienia danych w układzie 1:1 jest sporządzenie backupu bazy źródłowej  – pełna kopia – następnie przywracamy backup na nowej bazie. Ważne by pamiętać o niekompatybilności "w dół" niektórych wersji systemów bazodanowych, dlatego np. backup z MS SQL SERVERa w wersji 2008 nie otworzy się na wersji 2005. Jest to o tyle niepokojące, że niekiedy nie mamy możliwości przejścia na nowsze oprogramowanie w nowym systemie (np. naleciałości konfiguracyjne). Ewentualnym rozwiązaniem, tudzież obejściem tego problemu mogłoby być tzw. "skryptowanie" –czyli utworzenie skryptu, który odtworzy bazę od początku. Niestety bywa, że rozmiary plików skryptowych mogą być zbyt duże do klasycznego otworzenia nawet przez  system operacyjny .
+Jeśli chcemy przeprowadzić migrację bez używania backupów i baza źródłowanie znajduje się na naszym lokalnym serwerze musimy (w przypadku MS SQL) podlinkować serwer na którym jest nasze źródło (lokalnie nie ma tego problemu - domyślnie wszystkie bazy są widoczne.). Może się to odbywać przez sterowniki ODBC w przypadku różnych typów baz danych.
+Do najprostszych przykładów migracji możemy zaliczyć synchronizację dwóch baz. Może odbywa się np. za pomocą triggerów. Częstym problem s synchronizacji zwrotnej (dwustronnej) jest zapętlanie. Podczas zmiany (np. UPDATE) jednej z tabel uruchomi się trigger synchronizujący , który wykona update na drugiej bazie, gdzie tak samo uruchomione zostanie plecenie updateu. Najbardziej oczywistym rozwiązaniem będzie zastosowanie tzw. TIMESTAMPSów i na ich podstawie dokonywanie kolejnych operacji. Cały trik polega na tym by podczas aktualizacji zapisywać TIMESTAMP z bazy która wysłała dane do uaktualnienia wtedy ryzyko zapętlenia znika, gdyż podczas zmiany wiadomo, która wersja jest aktualna. Należy także unikać modyfikacji tych samych danych w obu bazach jednocześnie - powstaje problem która wersja jest bardziej aktualna?
+Do kopiowanie większych bloków danych możemy użyć polecenia [[http://technet.microsoft.com/en-us/library/aa225219%28SQL.80%29.aspx|SELECT INTO]]
+<code>
+SELECT INTO <new model>
+USING <algorithm> [(<parameter list>)] [WITH DRILLTHROUGH[,] [FILTER(<expression>)]]
+FROM <existing model>
+</code>
+Działa tylko wtedy, gdy struktura istniejącego modelu jest zgodna z algorytmem nowego modelu. Najbardziej przydatne do szybkiego tworzenia i testowania modeli, które są oparte na tym samym algorytmie.
+W przypadku gdy nie chcemy by  wszystkie danie przechodziły do drugiej bazy możemy użyć widoków do tzw. filtracji danych, co znacznie zmniejsza ilość przeglądanych i kopiowanych danych.
+Do najczęstszych przypadków migracji nalezą te w których struktura jednaj bazy różni się od drugiej. Jest to głównie spowodowane zmiana części funkcjonalności, bądź rozbudową systemu który operuje na naszej bazie. W takiej sytuacji, gdy tabele nie pasują do siebie w prosty sposób najlepiej jest użyć polecenia MERGE. Wykonuje ono wstawiania (INSERT), aktualizacje(UPDATE) lub operacji usuwania tabeli docelowej(DELETE) w oparciu o wyniki JOINów z tabeli źródłowej. Na przykład, można synchronizować dwie tabele przez wstawianie, aktualizowanie lub usuwanie wierszy w jednej tabeli na podstawie stwierdzonych różnic w innej tabeli. Ponieważ MERGE jest stanie przenosić dane na podstawie zadanych warunków, mamy pełna kontrolę nad tym co znajdzie się w naszej nowej bazie.
+== Składnia polecenia MERGE: ==
+Opis pełnej składni znajdziesz na srtonie [[http://technet.microsoft.com/en-us/library/bb510625.aspx|technet.microsoft.com]]
+== Opis niektórych argumentów: ==
+**WITH** - określa tymczasowym zestaw wyników lub widok, znane również jako "//common table expression//".
+**TOP** - liczbowy lub procentowy wskaźnik na jaką liczbę wyników wpłynie operacje MERGE. np. ustawiając TOP(10)  operacja wykona się dla pierwszych 10 z czego nie musza to być te same operacje, możemy wykonać UPDATE dla 7 i np. deldete dla 3.
+**//database_name//**  - jest nazwą bazy danych, w którym znajduje się target_table.
+**//schema_name//**  - to nazwa schematu, do której należy target_table.
+**//target_table//** - tabela lub widok, który służy za wzór dopasowania danych w <//table_source//> na podstawie <//clause_search_condition//>. Target_table jest celem każdego wstawiania, aktualizacji lub usuwania określonych przez klauzule WHEN .target_table nie może być  tabelą zdalną, nie może też mieć żadnych wczesniej zdefiniowanych warunków.
+**USING** - określa źródło danych, które są dopasowywane do wierszy danych w target_table na podstawie <//merge_search condition//>.
+**ON** - określa warunki, na jakich <//table_source//> jest połączona z target_table, by zweryfikować w których miejscach do siebie pasują
+**WHEN MATCHED THEN** - kiedy wszystkie wiersze target_table pasują do wierszy zwracanych przez <//table_source//> ON <//merge_search_condition//>, i spełnione są wszystkie pozostałe warunki zapytania zwrócone rekordy są updateowane, bądź usuwane zgodnie z klauzulą <//merge_matched//>.
+**WHEN NOT MATCHED BY SOURCE THEN** - określa wszystkie wiersze target_table nie pasujące do wierszy zwracanych przez <//table_source//> ON <//merge_search_condition//>, są one albo zaktualizowane albo usunięte zgodnie z klauzulą <//merge_matched//>.

pl/dydaktyka/ztb/2011/projekty/migracja_crm/start.1317202617.txt.gz · ostatnio zmienione: 2019/06/27 15:57 (edycja zewnętrzna)

Pokaż stronę Poprzednie wersje

Menadżer multimediów Do góry

AIwiki

Menu

Dla Studentów

Old specialized AI courses

SMaDA/SMaIDA/AIDA

Informatyka (EAIiIB)

Studia Dr

Inne materialy dydaktyczne

Archiwum

Dyplomanci

Geist Season of Code

HeKatE

Public

Różnice