Migracija podataka zahtijeva pažljivu pripremu. Migracija verzije strukture baze podataka: osnovni pristupi Pohranjivanje povijesti verzija

Suvremene tvrtke često se suočavaju s potrebom migracije svojih informacijskih sustava. Međutim, ovom postupku mora prethoditi pažljiva priprema, jer na tom putu postoje mnoge prepreke.

Razloga za početak prijelaza na novi informacijski sustav (IS) može biti jako puno, uključujući smanjenje rizika povezanih s radom zastarjelih platformi, dovođenje informacijskih sustava na međunarodne standarde te povećanje učinkovitosti poslovnih procesa. No bez obzira na zadatak s kojim se tvrtka suočava, prijelaz s jednog IP-a na drugi mora biti pažljivo planiran i pripremljen.

Problemi migracije

Kada je riječ o migraciji transakcijskih sustava kao što su ERP, naplata, obrada ili core banking, prijelaz na novi sustav vrlo je problematičan. Činjenica je da IT stručnjaci trebaju osigurati točnu migraciju velikih količina podataka, održavajući paralelni rad starih i novih sustava za usklađivanje i analizu rezultata.

Primjerice, imao sam projektno iskustvo u jednoj od najvećih banaka gdje se transakcijski sustav prenosio s više nepodržane Informix platforme na Oracle platformu. Pritom je bilo potrebno provesti temeljitu analizu poslovnih procesa, višekratno prebacivati ​​podatke iz starog sustava u novi te provjeriti konzistentnost rezultata novog i starog sustava, uzimajući u obzir trajanje procesni propisi. Zato je razdoblje migracije bilo 14 mjeseci. Ponekad se paralelni rad dvaju sustava može nastaviti dulje vrijeme, no čak i kada je ograničen na nekoliko mjeseci, osiguranje rada novog IS-a zahtijeva alokaciju dodatne računalne snage i značajnog vremena zaposlenika poduzeća za istovremeno obavljanje zadataka u dva sustava .

Od sustava odjela do razine poduzeća

Ažuriranje IP-a često se događa u okviru globalizacije i centralizacije. To vam omogućuje značajno smanjenje troškova podrške i ažuriranja softverskih sustava. Doista, održavanje jedinstvene platforme koja služi svim zaposlenicima puno je lakše nego održavanje zasebnih alata za svaki odjel. Na primjer, uspješna migracija računovodstvenog sustava inventara omogućuje vam prijenos nekoliko tisuća odjela velike organizacije na jednu platformu i osigurava ozbiljno smanjenje IT troškova. No, treba imati na umu da najveći dio priprema u ovom slučaju otpada na koordinaciju podataka u različitim formatima i reprezentacijama, razvoj novih propisa i izgradnju novih modela interakcije zaposlenika.

Drugi važan aspekt su integracijska sučelja s drugim informacijskim sustavima poduzeća, posebno onima koje sami pišu i specifičnima. Problemi povezani s njima možda nisu toliko uočljivi u prvoj fazi, ali se identificiraju prilikom uspostavljanja interakcije između različitih odjela i cjelokupnog sustava. A ako su za stari sustav takva sučelja već implementirana programski ili organizacijski, tada će se za novi sustav možda morati razviti iznova.

Treba imati na umu da misli o proširenju funkcionalnosti sustava mogu doći već tijekom provedbe projekta, baš kao što apetit dolazi tijekom obroka. To znači da će biti potreban cijeli niz dodatnih radova.

Plan akcije

Iskustvo projektnih aktivnosti na migraciji sustava pokazuje da svaki takav projekt zahtijeva pažljivu pripremu i mora biti popraćen individualnim planom. Međutim, bez obzira na vrstu sustava koji se migriraju, softver, volumen baze podataka itd., opća shema izgleda gotovo identično.

U prvoj fazi potrebno je provesti detaljnu reviziju, utvrditi sve zahtjeve za način rada novog sustava, intervjuirati sve ključne korisnike. Važno je razumjeti o kojim količinama podataka i kakvom opterećenju govorimo, tek tada će stručnjaci moći predložiti pravu strategiju migracije.

Sami postupci također moraju biti pažljivo osmišljeni i uključivati ​​tako važne elemente kao što su pravila za korisnički pristup sustavima tijekom migracije, postupci za vraćanje na prethodno stanje u slučaju kvarova i interakcija različitih stručnjaka uključenih u te procese .

Nakon dogovora s naručiteljem obično se izrađuje detaljan plan koji uključuje nekoliko faza, a to su: kopiranje podataka, verifikacija, paralelni rad dva sustava i potpuni prijelaz na novu platformu. Po mom mišljenju, glavna stvar u profesionalno organiziranoj migraciji sustava je glatkoća procesa za korisnike koji mogu postupno, bez stresa, početi raditi u novom automatiziranom sustavu.

Međutim, čak ni pažljiva priprema ne može vas uvijek spasiti od podcjenjivanja troškova rada prilikom prebacivanja korisnika na "nove tračnice". Ovaj proces uključuje kako obuku zaposlenika tvrtke tako i njihovu podršku u razdoblju prilagodbe na novi sustav.

Leif Poulsen za InTech

Sustavi za automatizaciju proizvodnje i prikupljanje informacija o proizvodnim procesima relativno su kratkog vijeka. Često se moraju nadograditi ili zamijeniti prije nego procesna oprema dođe do kraja svog životnog vijeka. Za mnoge tvrtke, upravljanje zamjenom ili nadogradnjom takvih sustava automatizacije bez zaustavljanja proizvodnje pravi je izazov. Stoga se objektivna potreba za modernizacijom ili zamjenom zanemaruje dok se nešto ne dogodi. Ovaj članak govori o tome kako možete uspješno izvršiti ovaj zadatak kroz pažljivo planiranje i organizaciju.

Dva glavna čimbenika stoje iza potrebe modernizacije i zamjene sustava industrijske automatizacije i industrijskih IT sustava: tehnička degradacija ovih sustava, kao i promjene u zahtjevima poslovnih procesa koje ti sustavi podržavaju.

Pouzdanost tehničkih sustava s vremenom će se smanjivati ​​ako tvrtke ignoriraju potrebu za modernizacijom operativnih sustava, baza podataka i aplikacijskog softvera. U skladu s tim povećava se operativni rizik od kvara opreme.

Pažljivim planiranjem, operativni rizik može se održati na prihvatljivoj razini, istovremeno štiteći ulaganja i minimizirajući troškove životnog ciklusa. Za tipičan automatizirani ili IT sustav, samo 20-40% investicije odlazi na kupnju sustava. Preostalih 60-80% odlazi na održavanje visoke dostupnosti i prilagođavanje zahtjevima koji se povremeno mijenjaju.

Uz procjenu aktivnosti potrebnih za sprječavanje tehničke degradacije, potrebno je razmotriti nove izazove kao i potencijalne poslovne prilike. Poslovno okruženje se neprestano mijenja i uvijek se moraju razmatrati sve prilike za poboljšanje postojećih ili uvođenje novih tehnologija. Tipične poslovne prilike koje mogu potaknuti migraciju skupih sustava automatizacije su brzina izlaska na tržište, konkurentnost, rast, kvaliteta i usklađenost s propisima.

Dugoročni plan migracije

Razvijanje dugoročnog plana migracije sustava omogućuje tvrtkama održavanje sistemskih operativnih rizika na prihvatljivoj razini. Osim toga, osigurava upravljanje rizicima i pravovremenu podršku poslovnim ciljevima. Plan migracije mora uzeti u obzir ograničenja kao što su "najbolja proizvodna praksa", tehnološka funkcionalnost i neizbježni zastoji u proizvodnji.

Općenito, pristup dugoročnom planiranju prikazan je na slici 1. Plan migracije se razvija kako bi se odredilo gdje tvrtka želi biti za pet godina, koje radnje treba poduzeti da bi se tamo stiglo i jesu li dostupni resursi potrebni za to. Ovaj se pristup temelji na načelima arhitektonskog dizajna navedenim u TOGAF standardu, koji se široko koristi u razvoju arhitekture sustava za industrijska poduzeća.

Slika 1. Opći pristup izradi dugoročnog plana migracije.

Potrebno je razlikovati postojeću arhitekturu od ciljane, željene. Razlika između njih odražava razliku između trenutnog položaja poduzeća i položaja koji želi zauzeti u budućnosti. Plan migracije ucrtava put od postojeće arhitekture do ciljane arhitekture - moguće kroz nekoliko prijelaznih faza.

Svaka se arhitektura može opisati kao niz "slojeva" koji premošćuju jaz između poslovanja i tehnologije - kao što je prikazano na slici 1. 1. Mora se obratiti pozornost na sljedeće "slojeve":

  • Poslovni ciljevi to je dio cjelokupnog napora planiranja strategije. Omogućuju vam da odaberete pravi smjer procesa.
  • Poslovni model pruža kontekst u kojem se razumiju proizvodni i poslovni procesi. Obično uključuje opis tokova materijala i procesa na visokoj razini.
  • Opis proizvodnih i poslovnih procesa važan je za uspješnu primjenu tehnologija i ispravnu procjenu njihove vrijednosti s poslovnog gledišta.
  • Informacije, podaci i dokumenti važni za povezivanje procesa i aplikacija. Interoperabilnost i upravljanje protokom informacija između aplikacija posebno su važni.
  • Opisi aplikacije omogućuju vam formuliranje zahtjeva visoke razine i definiranje sučelja.
  • Definicija infrastruktura, računalstvo i mreža zahtjevi (hardver, tolerancija grešaka, performanse).
  • Pod uvjetom usluge definirati zahtjeve za osiguranje učinkovitog operativnog upravljanja i podrške odlučivanju.

Izrada plana migracije

Razvijanje plana migracije za cijelu organizaciju ili čak jednu proizvodnu lokaciju može biti uistinu složen zadatak koji uključuje mnogo ljudi. Preporuča se podijeliti proces razvoja u nekoliko faza, opisanih u nastavku.

Dio II

Faza 1: Mobilizacija

Osnovni ciljevi:

  • postići zajedničko razumijevanje zadataka i ciljeva
  • mobilizirati organizaciju u kojoj je projekt planiran
  • detaljno opisati plan opisujući prekretnice i rezultate faza projekta
  • prikupiti sve potrebne/raspoložive informacije
  • pružiti ispravno razumijevanje koncepata, praksi i teorije
  • zakazani sastanci
  • radionica posvećena početku projekta

Rezultati:

  • detaljan plan konzultacija
  • zajednički ciljevi
  • pregled procesa

Faza 2: Analiza

Ciljevi faze analize su:

  • analiza poslovnih i proizvodnih procesa kako bi se:

Procijeniti spremnost osoblja koje servisira IT i automatizirane sustave

Razumijevanje podataka i funkcionalnih potreba za buduću arhitekturu

Identificirajte ključne prednosti buduće arhitekture kako biste postavili ciljeve i implementirali poslovni slučaj

  • analiza postojeće arhitekture

Utvrđivanje postojećih proizvodnih procesa u njihovoj povezanosti sa sustavima automatizacije, prikupljanjem podataka, sustavima upravljanja proizvodnjom

Identifikacija postojećih poslovnih procesa i njihova povezanost sa sustavima automatizacije proizvodnje

Identificirajte postojeće aplikacije, podatke, logičku i fizičku infrastrukturu i usluge tehničke podrške

Tijekom ove faze provode se sljedeće aktivnosti:

  • seminari i rasprave o raznim procesima
  • posjete stranicama radi dobivanja kontekstualnih informacija
  • seminari i rasprave o postojećim sustavima
  • procjena usluga kako bi se utvrdila njihova zrelost i usklađenost s regulatornim zahtjevima

Rezultati:

  • identifikacija postojeće infrastrukture
  • analiza dokumentacije
  • popis ideja o izazovima i mogućnostima nove arhitekture popis ideja o izazovima i mogućnostima nove arhitekture

Faza 3: Cilj

Svrha ove faze je identificirati i opisati potrebe formulirane tijekom faze analize.

Rješenje ili ciljna arhitektura opisat će:

  • buduće poslovne procese i funkcionalnost
  • ciljne vrste aplikacija, s njihovom funkcionalnošću, korisnicima, informacijama i sučeljima
  • infrastrukturne potrebe i revidirane standarde podrške

Tijekom ove faze provode se sljedeće aktivnosti:

  • seminari i rasprave o poboljšanju procesa
  • radionice i rasprave o unapređenju arhitekture

Rezultati:

  • buduća arhitektura (prezentacija)
  • Kratak opis vrsta aplikacija

Faza 4: Opravdanje

Svrha faze opravdanja je pružiti početni poslovni slučaj temeljen na grubim procjenama troškova i koristi projekta.

Raskorak između postojećeg i željenog stanja obično dovodi do pojave niza ideja. Opravdanost ideja omogućit će vam da razlikujete “potrebno” od “poželjnog”, a nakon toga prezentirate i razvijate ideje najvišem menadžmentu.

Tijekom ove faze provode se sljedeće aktivnosti:

  • gruba procjena troškova i koristi
  • prva verzija prezentacije

Rezultati:

  • zajednički ciljevi
  • prioritizacija poslovnih ideja
  • procjena potrebnih resursa

Faza 5: Plan

Svrha ove faze je planiranje projekta na temelju prioriteta, resursa i ovisnosti:

  • planiranje slijeda provedbe faza konsolidiranog projekta
  • osiguravanje resursa i kompetencija potrebnih za sljedeće korake
  • iniciranje aktivnosti upravljanja projektom
  • završetak savjetovanja i prijenos rezultata svih faza do kupca

Tijekom ove faze provode se sljedeće aktivnosti:

  • izrada plana provedbe
  • izrada investicijskog plana
  • procjena rizika

Rezultati:

  • Plan implementacije
  • procjena opterećenja osoblja uključenog u projekt
  • procjena rizika projekta
  • investicijski plan (kao prva aproksimacija)
  • konačna verzija prezentacije projekta

Studija slučaja

Sljedeći primjer ilustrira primjenu opisanog pristupa u stvarnim uvjetima. Kako bi se poštivali uvjeti povjerljivosti, u opisu se održava anonimnost. Riječ je o prilično velikom poduzeću koje proizvodi aktivne sastojke za farmaceutske proizvode. Proizvodni pogoni pušteni su u pogon prije više od 20 godina i iako je od tada izvršena određena modernizacija, potrebno je zamijeniti niz zastarjelih sustava. Sustavi automatizacije zgrada i DCS su na prvom mjestu, jer se temelje na zastarjelim tehnologijama koje je teško održavati. Osim toga, proizvodnja se mora prilagoditi novim poslovnim zahtjevima, uključujući ukidanje jednih proizvoda i lansiranje drugih. Općenito, postoji potreba za radom na planu migracije koji pokriva tehničke i poslovne zahtjeve.

Prvo morate napraviti glavni popis opreme koja se trenutno koristi u cijelom poduzeću. Te su informacije često “skrivene” u raznim dokumentima (i sjećanjima zaposlenika). Mora se izdvojiti i vizualizirati tako da postane osnova za planiranje migracije. U tu svrhu obično izrađujemo dijagram procesnog modula koji prikazuje kretanje glavne opreme i sirovina u svakoj proizvodnoj jedinici. Kao zasebni slojevi "na vrhu" hardvera, prikazujemo koji sustavi podržavaju koji hardver.

Primjer je prikazan na sl. 2. Podaci o instaliranim sustavima također se nalaze u memoriji sustava (ili jednostavno u Excel datotekama), te se mogu koristiti za daljnju analizu i planiranje.

Slika 2. "Sloj" automatizacije omogućuje procjenu postojećih sustava

Prije rasprave o planu migracije potrebno je identificirati glavne poslovne razloge promjena u proizvodnji. U ovom slučaju, menadžment je identificirao sljedeće motive:

1. Dosljedna usklađenost s regulatornim zahtjevima bez grešaka

2. Minimalno vrijeme potrebno za ulazak na tržište, fleksibilnost

3. Uspjeh, konkurentnost, operativna izvrsnost

4. Beskompromisna kvaliteta

5. Rast obujma proizvodnje

Ove ciljeve potrebno je pretočiti u konkretnije zadatke čija se provedba može kvantificirati.

Zatim moramo saznati koliko dobro postojeći sustavi podržavaju sadašnje i buduće poslovne procese. Da bismo to učinili, koristimo standardni referentni model (temeljen na seriji standarda ANSI/ISA-95). Uključuje 19 poslovnih procesa na visokoj razini, detaljiziranih do te mjere da omogućuje uvid u slabosti u njihovoj praktičnoj implementaciji i potrebu za promjenama radi učinkovitog poslovanja.

Osim toga, također moramo procijeniti tehničke mogućnosti postojećih sustava za podršku poslovnim procesima u budućnosti. To se radi sustavno, korištenjem gore opisanih informacija iz pohrane sustava. Za svaki sustav za koji se podaci nalaze u repozitoriju (u našem slučaju oko 70 sustava) potrebno je procijeniti sljedeće aspekte:

  • Stanje opreme (povijest kvarova, srednje vrijeme između kvarova, starost opreme, dostupnost rezervnih dijelova)
  • Status softvera (podrška dobavljača, dostupnost dokumentacije, osoblje s potrebnim kompetencijama)
  • Mogućnosti oporavka sustava (redundancija, prosječni vijek trajanja prije popravka)
  • Procjena učinka na poslovanje (pružanje informacija, pogreške u podacima, nedostupnost)
  • Indikativni pokazatelji (pouzdanost sustava, kritičnost sustava, itd.)

Tehničkom procjenom utvrđena je potreba za modernizacijom i zamjenom niza sustava:

  • Sustavi upravljanja procesima temelje se na konvencionalnom, zastarjelom DCS-u i mnogo različitih PLC-ova, od kojih su neki već „zreli“ za zamjenu.
  • Sustav automatizacije zgrade temelji se na novijoj platformi, ali također zahtijeva nadogradnju kako bi zadovoljio nove zahtjeve.
  • Određeni broj sekundarnih sustava također zahtijeva modernizaciju ili čak zamjenu.
  • Infrastruktura koja opslužuje sve sustave zahtijeva bolju segmentaciju i zaštitu kako bi zadovoljila današnje sigurnosne zahtjeve.

Dio III

Nakon analize poslovnih ciljeva za budućnost, pokazalo se da nijedan od postojećih sustava u potpunosti ne zadovoljava buduće potrebe. Ovakvo shvaćanje iznjedrilo je niz ideja o uvođenju novih tehnologija, kao i sustavu izvođenja proizvodnje. Kao rezultat analize predloženo je 16 različitih projekata koji će, ako se dosljedno provode, pomoći tvrtki da ispuni buduće tehničke i komercijalne zahtjeve.

Procjenjuje se sadržaj tehničkog rada i trošak svakog projekta; Za svaki projekt priprema se kratak sažetak na jednoj stranici o kojem menadžment raspravlja. (Pogledajte sliku 3).

Riža. 3. Opis na jednoj stranici potencijalnog projekta migracije

Kako bi se odabrali prioritetni projekti, procjenjuju se potencijalni rezultati svakog od njih. Rezultati se ocjenjuju s obzirom na poslovne ciljeve, kao i pouzdanost sustava upravljanja procesima.

Obično ćete trebati procijeniti višestruke scenarije provedbe kako biste procijenili ukupne potrebe za resursima i financiranjem za svaki plan (Slika 7). Jedno od glavnih ograničenja koje treba uzeti u obzir su prozori u proizvodnom procesu tijekom kojih se sustavi mogu zamijeniti ili modificirati. U pravilu se ti "prozori" pojavljuju vikendom - a to je ozbiljno usko grlo.

Riža. 7. Konsolidirani pregled rasporeda migracija

Budući da uvijek ima malo vremena za zamjenu sustava i njihovo postavljanje, priprema mora biti vrlo temeljita. Sve mora biti detaljno isplanirano. Važan aspekt planiranja je testiranje implementiranih sustava.

U slučaju koji opisujemo, provedba dugoročnog plana migracije provedena je u šest različitih tokova, vidi sl. 8.

Riža. 8. Organiziranje migracijskih projekata u šest različitih tokova

Dio pripreme je i temeljita procjena i prevencija rizika projekta. Na sl. Slika 9 prikazuje tipične rizike povezane s projektima migracije.

Riža. 9. Procjena tipičnih rizika migracijskih projekata

Procesi poslovne podrške

Upravljanje životnim ciklusom i pristup dugoročnom planiranju migracije opisan u ovom članku vođen je poslovnim potrebama. Uključuje procjenu sadašnjih i budućih poslovnih ciljeva, kao i temeljitu analizu načina na koji će se tehnički sustavi održavati ili zamijeniti da najbolje podrže te ciljeve. Pristup se temelji na načelima TOGAF-a, koji predviđaju sekvencijalnu implementaciju projekta ovisno o raspoloživosti proračuna i kvalificiranog osoblja. Procjena sadašnjih i budućih arhitektura sustava ključni je element u određivanju budućih migracijskih projekata. Konačno, potrebno je pridržavati se načela upravljanja organizacijskim promjenama koja osiguravaju pravovremeno uključivanje ključnih dionika projekta, što je toliko važno za uspjeh migracijskih projekata. Učinkovitost ovog pristupa više puta je dokazana u praksi.

Leif Poulsen) ( ), vodeći stručnjak za automatizaciju i IT u NNE Pharmaplan. Magistar je upravljanja procesima. U NNE Pharmaplanu Poulsen je odgovoran za razvoj tehnologija, metoda i kompetencija u području industrijske automatizacije i IT-a te radi kao viši poslovni savjetnik.

Zadnja izmjena: 31.10.2015

Često se javlja situacija kada se model promijeni. Na primjer, odlučili smo u njega uvesti nove nekretnine. Ali u isto vrijeme već imamo postojeću bazu podataka koja sadrži neke podatke. A kako bismo ažurirali bazu podataka bez gubitka, ASP.NET MVC nudi nam takav mehanizam kao što su migracije. Na primjer, imamo jednostavan korisnički model:

Javna klasa Korisnik ( public int Id ( get; set; ) public string Name ( get; set; ) )

Sukladno tome, postoji podatkovni kontekst kroz koji radimo s bazom podataka:

Korisnici(dobi;postavi;))

I recimo da imamo svu infrastrukturu za rad s ovim modelom - poglede, kontrolere i već imamo nekoliko objekata ovog modela u bazi podataka. Ali u jednom smo trenutku odlučili promijeniti bazu modela aplikacije. Na primjer, dodali smo još jedno polje u korisnički model:

Javna klasa Korisnik ( public int Id ( get; set; ) public string Name ( get; set; ) public int Age ( get; set; ) )

Osim toga, odlučili smo dodati još jedan model, na primjer:

Javna klasa Tvrtka ( public int Id ( get; set; ) public string Name ( get; set; ) )

Stoga se kontekst naših podataka već mijenja kako slijedi:

Javna klasa UserContext: DbContext ( public UserContext() : base("DefaultConnection") ( ) public DbSet Korisnici ( get; set; ) public DbSet Tvrtke ( dobiti; postaviti; ) )

Možemo dodati dodatno polje za svojstvo Age pogledima za korisnički model, možemo kreirati kontroler i poglede za novi model, ali kada pokušamo dodati novi objekt u bazu podataka, dobit ćemo pogrešku:

Kontekst podataka se promijenio i sada moramo migrirati sa stare sheme baze podataka na novu. I prije svega pronađite prozor Package Manager Console na dnu Visual Studija, unesite naredbu u njega: enable-migrations i pritisnite Enter:

Nakon pokretanja ove naredbe Visual Studio, u projektu će se stvoriti mapa Migracije u kojoj možete pronaći datoteku Konfiguracija.cs. Ova datoteka sadrži deklaraciju istoimene klase konfiguracije koja postavlja konfiguracijske postavke:

Namespace MigrationApp.Migrations ( koristeći System; koristeći System.Data.Entity; koristeći System.Data.Entity.Migrations; koristeći System.Linq; interna zapečaćena klasa Konfiguracija: DbMigrationsConfiguration ( public Configuration() ( AutomaticMigrationsEnabled = false; ContextKey = "MigrationApp.Models.UserContext"; ) protected override void Seed(MigrationApp.Models.UserContext context) ( ) ) )

U Seed metodi možete inicijalizirati bazu podataka s početnim podacima. Sada moramo kreirati samu migraciju. Tamo, u konzoli upravitelja paketa, unesite naredbu:

PM Add-Migracija "MigrateDB"

Visual Studio će tada automatski generirati klasu migracije:

Namespace MigrationApp.Migrations ( using System; using System.Data.Entity.Migrations; public partial class MigrateDB: DbMigration ( public override void Up() ( CreateTable("dbo.Companies", c => new ( Id = c.Int() nullable: false, identity: true), Name = c.String(), )).PrimaryKey(t => t.Id); AddColumn("dbo.Users", "Age", c => c.Int(nullable) : false)); public override void Down() ( DropColumn("dbo.Users", "Age"); DropTable("dbo.Companies"); ) )

U metodi Up pozivom metode CreateTable kreira se tablica "dbo.Companies" te se vrši njezino konfiguriranje: kreiranje stupaca, postavljanje ključeva. I novi stupac Dob također se dodaje postojećoj tablici. Metoda Down uklanja stupac i tablicu ako postoje. Zapravo, ove su metode ekvivalentne izrazu ALTER u SQL-u, koji mijenja strukturu baze podataka i njezinih tablica.

I konačno, da bismo izvršili migraciju, primijenit ćemo ovu klasu upisivanjem naredbe u istoj konzoli:

PM Update-Baza podataka

Nakon toga, ako pogledamo sastav baze podataka, vidjet ćemo da su na nju primijenjene promjene u skladu s izvršenom migracijom:

Dakle, migracija je gotova i već možemo koristiti ažurirane modele i kontekst podataka.

U ovom članku želimo sistematizirati naše iskustvo u provedbi migracije podataka u velikim korporativnim projektima koji se odnose na prijelaz kupaca na rad u konfiguracijama 1C:Enterprise 8.

Pritom će glavni naglasak u članku biti stavljen, prije svega, na tehnološku komponentu migracijskog procesa. Organizacijska komponenta također je pogođena, ali u manjoj mjeri.

Pojmovi i definicije

Migracija podataka obično se shvaća kao završni slijed rada, projekt usmjeren na jednokratno masovno kretanje podataka od izvornih sustava (povijesnih sustava) do odredišnog sustava. Istodobno prestaje iskorištavanje tih podataka u izvornim sustavima.

Migraciju podataka treba razlikovati od integracije podataka. Integracija je, za razliku od migracije, stalni dio IT arhitekture i odgovorna je za protok podataka između različitih sustava i pohrana podataka – te je proces, a ne projektna aktivnost.

Shema migracije općenito izgleda ovako:

Riža. 1

Povijesni sustavi- baze podataka tvrtke Naručitelja, koje se planiraju potpuno ili djelomično zamijeniti prilikom implementacije novog sustava.

Prijemni sustav- ciljni sustav, proizvoljna konfiguracija "1C: Enterprise 8".

Početni podaci- podaci preuzeti iz povijesnih sustava u prilagođeni format datoteke xls. U ovom slučaju, čini se da je xls format jedan od najprikladnijih, budući da je mogućnost učitavanja u xls datoteku prisutna u mnogim računovodstvenim sustavima "prethodnih generacija".

Kao modernu alternativu kao transport, moguće je razmotriti xml format datoteke.

Postoje i opcije za korištenje srednje baze podataka.

Preobrazba, obraćenje- proces pretvaranja izvornih podataka u podatke za učitavanje. Transformacija podataka odvija se u skladu s predlošcima učitavanja. Rezultat transformacije su podaci koji se učitavaju.

Preuzimanje podataka- podatke namijenjene učitavanju u prijamni sustav. Ovaj članak, kao i izvor podataka, razmatra xls format.

Predlošci podataka za učitavanje- opis podatkovnih tablica koje se učitavaju u ciljni sustav.

Faze migracije

Razmotrimo proces pripreme i provođenja migracije korak po korak.

Organizacijske faze migracije uključuju sljedeće točke:

· Definiranje strategije migracije. U ovoj fazi Izvođač i Kupac dogovaraju tehnologiju izvođenja radova migracije;

· Određivanje sastava radne skupine za migracije. Radna skupina treba uključivati ​​stručnjake i Izvođača i Naručitelja koji su dovoljno upoznati s radom povijesnih sustava (na strani Naručitelja) i ciljnog sustava (na strani Izvođača);

· Preliminarni plan migracije. Plan migracije će se prilagođavati nekoliko puta kako projekt napreduje;

· Razdoblja datuma za preuzimanje podataka iz povijesnih sustava, količine podataka. Razdoblja prekida podataka za migracije, datumi testiranja i konačnih migracija. Ove informacije mogu se pripisati planu migracije;

· Sastav podataka koji se migriraju. Referentni podaci, klasifikatori, podaci o transakcijama, stanja, promet itd.;

· Pitanja provjere kvalitete, ispravnosti i cjelovitosti podataka tijekom procesa migracije i na kraju;

· Problemi vraćanja na prethodno stanje u slučaju kvarova.

Pogledajmo pobliže tehnološke faze migracije.

Riža. 2

1. Priprema predložaka za učitavanje podataka

Predložak za učitavanje podataka sadrži tehničke opise podatkovnih tablica koje se učitavaju, algoritme i pravila učitavanja za trenutni predložak.

Svaki predložak općenito cilja na jednu ili više povezanih tablica na ciljnom ciljnom sustavu.

Predložak navodi:

· Opis svih polja xls podatkovne datoteke za preuzimanje, uključujući:

o Naziv polja

o Indikator da polje mora biti popunjeno

o Primjer popunjavanja polja

o Napomena

· Opis pravila za učitavanje ciljne tablice sustava na temelju podataka koji se učitavaju (red u slučaju nekoliko povezanih tablica, algoritmi pretraživanja ključnih polja, itd.)

· Opis izravnog popunjavanja polja tablica ciljnog sustava ako je omogućeno bilo što osim prijenosa podataka "jedan na jedan" iz podatkovne datoteke za učitavanje. Relevantno za referentna polja, na primjer.

Tijekom rada u ovoj fazi, Izvođač također mora pripremiti učitavač podatkovne datoteke za učitavanje. Kada radite s xls datotekama, ovaj zadatak nije osobito težak.

2. Identifikacija izvora podataka

Ova faza može započeti zajedno s prethodnom fazom “1. Priprema predložaka za učitavanje podataka."

U ovoj fazi stručnjaci Kupca određuju iz kojih se sustava i koji podaci mogu preuzeti. Također biste trebali odrediti koje podatke Može biti može biti potrebno.

U pravilu, u velikim migracijskim projektima, identificiranje potpunog iscrpnog popisa izvora podataka može potrajati prilično dugo i događa se kako se rad nastavlja u sljedećim fazama.

Česte su situacije kada se, kako bi se dodatno osigurala cjelovitost informacija, neki podaci moraju prenijeti iz tiskanih izvora (digitalizirati) ili čak unijeti u tablice prema riječima ključnih zaposlenika Naručitelja.

Međutim, u ovoj fazi trebali biste pokušati identificirati što više potrebnih podataka.

3.Učitavanje izvornih podataka

Proces preuzimanja podataka iz povijesnih sustava može potrajati prilično dugo, pogotovo ako postoji mnogo sustava, različiti su i za njih su odgovorni različiti odjeli Korisnika. Ovu točku treba uzeti u obzir tijekom testnih i konačnih migracija.

Čini se da je najprikladnija opcija učitavanje u xls datoteke. Mnogi stariji IT sustavi podržavaju ovu opciju.

Mogu postojati i opcije za učitavanje u csv format, dbf, xml format i druge.

Važno je napomenuti da iz ovog ili onog razloga (sigurnosna pitanja, na primjer), Kupac ne može uvijek osigurati preuzimanje podataka u cijelosti u ovoj fazi! Samo struktura podataka i nekoliko testnih pozicija. Stoga se može dogoditi da se tijekom testnih i završnih učitavanja u izvornim tablicama otkriju podaci niske kvalitete, što će dovesti do neplaniranih pogrešaka.

Kako bi se ovaj problem sveo na najmanju moguću mjeru, potrebno je unaprijed dogovoriti količinu testnih preuzimanja iz povijesnih sustava.

4.Mapiranje podataka

Mapiranje (mapiranje podataka) – općenito, proces usporedbe podataka iz povijesnih sustava i sustava primatelja. To jest, izvorni podaci i podaci koji se učitavaju.

Faza mapiranja najzahtjevnija je faza i može zauzeti više od 50% cjelokupnog posla na zadatku migracije.

U ovoj je fazi cijela radna skupina projekta migracije u potpunosti uključena.

U procesu mapiranja podataka potrebno je razlikovati podstupnjeve mapiranja tablice i mapiranja polja.

· Mapiranje tablica, odnosno mapiranje predložaka - usporedba tablica izvornih podataka i predložaka podataka za učitavanje. Utakmica može biti 1:1 ili N:N. Kao rezultat ovog rada, sastavlja se i održava registar mapiranja tablice. Ova podfaza je neophodna za sljedeću podfazu kartiranja terena i za praćenje općeg stanja kartiranja.

Skupina 1C predložaka

Naziv 1C predloška

Naziv datoteke-

izvor

Pravila za generiranje izvorne datoteke

Odgovoran

Status

Bilješka

NSI

Uzorak_

Nomenklatura

Nomenk

latura.xls

Izbor skupa u sustavu N
. Spremi u txt
. Otvoreno u xls, stupci su tekst
. Prvi redak je zaglavlje
. Broj stupaca - 15
. Provjerite broj redaka u txt i xls
. Naziv lista uvijek je "Sheet1"

Ivanov I.I.

na poslu

· Mapiranje polja - mapiranje polja tablice unutar već definiranog mapiranja tablice. Rezultat ovog rada je registar kartiranja terena.

№pp

Cl. polje

Potreban

Naziv polja predloška 1C "Nomenklatura_predloška"

Opis

Naziv polja "Nomenklatura.xls"

Algoritam za punjenje

Kodirati

Kod elementa imenika

Kodirati

Ime

Ime

Da

Ova grupa

Sadrži jednu od sljedećih vrijednosti:
. 1 - za grupe
. 0 - za elemente

Ako je duljina koda=11 znakova i zadnja 4 znaka<>"0000", tada je ovaj element "0", inače je grupa "1".

Puno ime

Ime elementa imenika

Ime

If ThisGroup = 1, then "", ElseIf ThisGroup = 0, then Name.

U sklopu ove faze trebali bi se provesti i eventualni radovi na normalizaciji podataka.

5. Priprema pravila transformacije

Za razliku od prethodnih faza, ova faza je tehnička i uključuje rad Izvođača programera.

Na temelju dogovorenih registara kartiranja terena, stručnjaci Izvođača razvijaju pravila za transformaciju podataka.

Za operativni rad tijekom pripremnih faza migracije i dalje, tijekom testnih i završnih migracija, važno je da postoji pogodno okruženje za razvoj pravila (skripti) za transformaciju podataka i okruženje za pretvaranje izvornih podataka u podatke za učitavanje.

Zahtjevi za ovo okruženje uključuju:

· Pogodnost i brzina razvoja pravila transformacije;

· Brzina konverzije podataka. Ulazne i izlazne datoteke mogu biti dugačke stotine tisuća redaka!

· Sposobnost rada s nekoliko ulaznih datoteka istovremeno;

· Sposobnost spremanja pravila transformacije u zasebne datoteke.

Za naše migracijske projekte razvili smo specijaliziranu radnu stanicu za programere, koristeći standardnu ​​obradu 1C Query Console kao osnovu.

Obrada Query Console poboljšana je kako bi se omogućili izravni upiti u xls datoteke.

Ovdje je primjer kombiniranja dviju izvornih xls datoteka Zaposlenici.xls


Šifra zaposlenika

Prezime

Ime

Prezime

Datum rođenja

2423

Ivanov

Ivana

Ivanoviču

17.11.1992

1523

Petrov

Bosiljak

Aleksandrovič

04.02.1991

4363

Sidorov

Kiril

Nikolajeviču

01.05.1995

Denisov

Denis

Denisovich

01.01.1990

I Operacije.xls sa stranicama:

Otpisi

Šifra zaposlenika

datum

Iznos

2423

01.02.2014

1523

02.02.2014

4363

03.02.2014

04.02.2014

100000

2423

05.02.2014

1523

06.02.2014

4363

07.02.2014

2356

08.02.2014

140000

2423

09.02.2014

1523

10.02.2014

4363

11.02.2014

23523

12.02.2014

80000

I Primici:

Šifra zaposlenika

datum

Iznos

01.05.2004

02.05.2004

03.05.2004

04.05.2004

2423Datum rođenja

Iznos primitka

Otpisani iznos

Ivanov Ivan Ivanovič

2423

17.11.1992

1341234

1010

Petrov Vasilij Aleksandrovič

1523

04.02.1991

245245

Denisov Denis Denisovič

01.01.1990

380000

320000

Sidorov Kiril Nikolajevič

4363

01.05.1995

613382

26336

UKUPNO:

2579861

347842

Imajte na umu da je primjer umjetan, posebno odabran da pokaže sve moguće faze transformacije izvora podataka.

Tehnološki slijed operacija transformacije ovdje je sljedeći:

Koristeći Access SQL upitni jezik (koji pruža značajne dodatne mogućnosti u usporedbi s 1C upitnim jezikom), kreira se početni upit koji izvlači podatke iz xls datoteke u 1C okruženje. Pritom su već u ovoj fazi moguće različite provjere i normalizacija podataka.

ADO tehnologija pristupa podacima omogućuje veliku brzinu.

Riža. 3

2. Upit u 1C jeziku - glavni upit koji implementira algoritam mapiranja polja. I također: obogaćivanje preuzetih podataka podacima iz baze podataka 1C, pregrupiranje, spajanje s rezultatima upita na druge izvorne xls datoteke itd.

3. Naknadna obrada rezultata zahtjeva 1C ako je potrebno. Implementirano pomoću skripte na 1C jeziku.

Na primjer, ovdje implementiramo dodavanje retka "UKUPNO" u stupce iznosa.

4. Zapišite konačni skup podataka u xls datoteku.

Općenito, izlaz su konačne datoteke za učitavanje u ciljanu 1C bazu podataka.

Ovaj vam alat također omogućuje spremanje pravila pretvorbe podataka u zasebnu xml datoteku:

Osim toga, moguće je raditi V skupni način rada, što je posebno važno kada postoji velika količina heterogenih podataka o migraciji.

Tijekom prethodnih faza uglavnom završava pripremni dio rada - identificiraju se svi izvori podataka, preuzimaju izvorni podaci iz izvora, pripremaju se predlošci za preuzimanje u ciljnu bazu podataka, priprema se mapiranje podataka i, na kraju, razvijaju se skripte za transformaciju podataka .

Treba napomenuti da prije konačne migracije svakako trebate provesti nekoliko testova. Tijekom testnih migracija, Izvođač, zajedno s Kupcima, identificira:

Pogreške pretvorbe, pogreške učitavanja podataka

Provedite preliminarnu procjenu kvalitete podataka učitanih u ciljni sustav

Na temelju rezultata testnih migracija izrađuju/ažuriraju konačni plan migracije

7. Usklađivanje podataka

Kvalitetu preuzetih podataka treba provjeriti i nakon testnih migracija i na kraju konačne migracije. Tijekom usklađivanja mogu se provjeriti sljedeći pokazatelji:

· Podudarnost ukupnih iznosa za stanja, prema dokumentima;

· Kvantitativna podudaranja, na primjer broj OS-a;

· Ispravno popunjavanje pojedinih odabranih entiteta;

Imajte na umu da se određene provjere podataka o migraciji i problemi normalizacije podataka moraju riješiti tijekom svih procesa migracije. Uvijek se morate zapitati što treba učiniti u trenutnoj fazi kako biste izbjegli pogreške u sljedećim fazama.

Na primjer:

· Provjerite duplikate po ključnim poljima. Može se i treba provesti na izvornim podacima;

· Prisilnost tipova polja;

· Referentni integritet;

· Matematičke nedosljednosti. Na primjer, provjera praznih numeričkih polja u koja se planira dijeljenje tijekom transformacije;

· Općenito, provjera jesu li obvezna polja ispunjena;

· Zamjena netočnih znakova. Na primjer, engleski znakovi u ćiriličnim poljima (“o”, “a”, “e” itd.) Ovo posebno vrijedi za ključna polja!

· Provjera usklađenosti vrijednosti nizovnih polja s vrstama prijemnog sustava (ograničenja duljine)

Nakon završetka konačne migracije, prema unaprijed utvrđenoj migracijskoj strategiji i planu migracije, donosi se odluka o daljnjem djelovanju povijesnih sustava.

Često se operacija završi odmah nakon konačnog usklađivanja podataka i evidentiranja uspješnosti migracije – korisnici novog sustava više ne vode evidenciju u dva paralelna sustava, već potpuno prelaze na novi sustav. Istodobno, pristup starom sustavu održava se u načinu čitanja.

U nekim slučajevima može doći do paralelnog rada dvaju sustava tijekom trajanja probnog rada (TE), pa čak i nakon tog razdoblja. Pitanje paralelnog rada korisnika u dva sustava usko je povezano s pitanjem mogućnosti vraćanja na stari sustav ako se migracija (ili, općenito, rad novog sustava!) ocijeni nezadovoljavajućim.

Zaključak

Zaključno, želio bih napomenuti da kada je u pitanju migracija velikih transakcijskih sustava, koji uključuju mnoge konfiguracije 1C:Enterprise, prijelaz na novi sustav može biti vrlo naporan.

Stoga treba imati na umu da svaki takav projekt zahtijeva pažljivu pripremu i mora biti popraćen individualnim planom. Međutim, bez obzira na vrstu sustava koji se migriraju, volumene baze podataka itd., opća shema migracije izgleda gotovo identično.

  • prenijeti postojeće resursne domene u organizacijske jedinice novih domena, čime će se pojednostaviti upravljanje mrežnim resursima;
  • “simulirajte” napredak migracije, a da pritom ne dođe do stvarnog prijenosa podataka;
  • poništi poduzete radnje u vezi s migracijom;
  • premjestiti servisne račune;
  • vratiti odnos pun povjerenja između izvorne i ciljne domene;
  • Pretvorite više domena u jednu ili više velikih domena u već stvorenom okruženju Active Directoryja;
  • restrukturirati postojeće grupe ili spojiti nekoliko grupa u jednu u ciljnoj domeni;
  • analizirati proces prijenosa podataka bilježeći događaje migracije.

Migracija korisnika i radnih stanica u jedinstvenu Active Directory strukturu provodi se uz očuvanje postojećih prava pristupa.

Mogućnosti nadogradnje

Postoje dvije glavne opcije za nadogradnju infrastrukture domene [4]:

  • Ažuriranje domene. Ova metoda je najčešća i najlakša za implementaciju kod migracije domena. Ova metoda vam omogućuje da spremite trenutnu strukturu domene, postavke sustava, strukturu korisnika i grupa. Ažuriranje domene (ažuriranje na mjestu) uključuje prijenos postojećih kontrolera domene na novostvorenu domenu.
  • Restrukturiranje domene. Ova metoda omogućuje promjenu postojeće strukture domena, spajanje domena ili pretvaranje domena u organizacijske jedinice.

Osim gore navedenih opcija, postoji i mješovita opcija koja se temelji na njima - ažuriranje domena s njihovim naknadnim restrukturiranjem [13].

Ove opcije se nazivaju Prijelazni putovi za implementaciju Active Directoryja. Put tranzicije odabran od njih bit će glavna poveznica u cjelokupnoj strategiji za ažuriranje infrastrukture domene. Ova strategija će uključivati ​​opis koji objekti imeničke usluge trebaju biti premješteni i kojim redoslijedom. Najbolja praksa za bilo koje premještanje aplikacije tijekom implementacije Active Directoryja je dokumentiranje svakog detalja u radnom dokumentu koji se zove plan prijelaza.

Kriteriji za odabir prijelaznog puta

Prilikom odabira tranzicijskog puta pretpostavlja se da se odluka odnosi samo na jednu domenu, što znači da je savršeno pravedno koristiti različite tranzicijske staze za različite domene unutar iste organizacije.

Razmotrimo glavne kriterije koji se koriste pri odabiru najprikladnijeg prijelaznog puta [13], dane u tablicama 12.1, 12.2, 12.3, 12.4, 12.5, 12.6.

  • Kriterij 1. Zadovoljstvo postojećim modelom postojeće domene. Tablica 12.1. Odabir prijelaznog puta na temelju kriterija 1
    Prijelazni put Kriterij prihvatljivosti
    Ažuriranje domene Ako nema značajnih promjena koje biste željeli napraviti u modelu domene, tada će ažuriranje domene pružiti najlakši put. Naziv domene ostat će isti, kao i postojanje svih korisničkih i grupnih računa
    Restrukturiranje domene Ako trenutni model domene više ne zadovoljava potrebe organizacije ili više ne odgovara odjelima organizacije, restrukturiranje domene može biti najbolji izbor.
  • Kriterij 2. Stupanj rizika pri prelasku na novi model domene. Tablica 12.2. Odabir prijelaznog puta na temelju kriterija 2
    Prijelazni put Kriterij prihvatljivosti
    Ažuriranje domene Nadogradnja domene je metoda niskog rizika. Proces nadogradnje kontrolera domene je automatski, tako da nema mnogo mjesta za pogreške bez interakcije korisnika. Metodologija oporavka od neuspjele nadogradnje domene također je relativno jednostavna: ako nadogradnja ne uspije, trebate isključiti primarni kontroler domene (PDC), dodijeliti bilo koji rezervni kontroler domene (BDC) koji ima svježe podatke PDC ulozi i ponovno pokrenite postupak
    Restrukturiranje domene Restrukturiranje domene put je većeg rizika od obnove domene. Ima više zadataka koje treba izvršiti, pa stoga mnogi procesi mogu poći po zlu. Kao rezultat toga, raste frustracija među korisnicima koji se ne mogu prijaviti, pristupiti potrebnim resursima ili pristupiti svojim poštanskim sandučićima.
  • Kriterij 3. Prijelaz 1 vrijeme izvršenja Vrijeme prijelaza nije odlučujući čimbenik u odabiru putanje prijelaza, ali može biti odlučujući čimbenik za male organizacije s ograničenim resursima. .Tablica 12.3. Odabir prijelaznog puta na temelju kriterija 3
    Prijelazni put Kriterij prihvatljivosti
    Ažuriranje domene Obnova domene je linearan proces: jednom kada je započet, mora se završiti. Zahtijeva manje koraka od restrukturiranja i stoga je potrebno manje vremena da se dovrši cijela tranzicija
    Restrukturiranje domene Restrukturiranje domene uvijek traje duže. Na primjer, tijekom restrukturiranja puno se vremena troši na izgradnju i provjeru valjanosti infrastrukture ciljne domene, premještanje svih računa s izvorne domene na ciljnu domenu. Velike organizacije možda neće moći premjestiti sve objekte odjednom, pa se restrukturiranje domene vrlo često provodi u nekoliko faza
  • Kriterij 4: Vrijeme usluge imenika potrebno za dovršetak procesa migracije. Tablica 12.4. Odabir prijelaznog puta na temelju kriterija 4
    Prijelazni put Kriterij prihvatljivosti
    Ažuriranje domene Objekti računa nisu dostupni tijekom procesa migracije jer se sami ažuriraju kada se domena nadogradi
    Restrukturiranje domene Dobar izbor za organizacije u kojima je radno vrijeme sustava kritična vrijednost. Budući da uključuje stvaranje nenaseljene, "čiste" šume i ostavlja izvorno okruženje u biti nepromijenjeno, funkcionalnost imeničke usluge je očuvana dok korisnici nastavljaju funkcionirati u svom postojećem okruženju. Možete migrirati velike ili male skupine korisnika tijekom sati izvan vršnog prometa i ostaviti te nove račune u mirovanju dok ne budete spremni napustiti stari sustav
  • Kriterij 5. Dostupnost resursa za dovršetak prijelaza. Tablica 12.5. Odabir prijelaznog puta na temelju kriterija 5
    Prijelazni put Kriterij prihvatljivosti
    Ažuriranje domene Budući da je ažuriranje domene automatizirana operacija, ovaj će prijelazni put zahtijevati manje ljudskih resursa
    Restrukturiranje domene Restrukturiranje domene podrazumijeva više zadataka od obnove domene i stoga zahtijeva više resursa, što znači da mora imati odgovarajuće osoblje za podnošenje dodatnog opterećenja povezanog s restrukturiranjem domene. Alternativa je vanjskim suradnicima za dio ili cijeli projekt: postoje mnoge konzultantske skupine koje su specijalizirane za takve projekte, čime se štedi vrijeme i novac potreban za obuku internog osoblja
  • Kriterij 6. Proračun prijelaznog projekta. Tablica 12.6. Odabir prijelaznog puta na temelju kriterija 5
    Prijelazni put Kriterij prihvatljivosti
    Ažuriranje domene Čimbenici koji doprinose smanjenju potrebnih proračunskih sredstava:
    • mogućnost korištenja postojećeg poslužiteljskog hardvera;
    • manji troškovi ljudskih resursa;
    • smanjeni troškovi testiranja jer će biti potrebno testirati manje zadataka nadogradnje
    Restrukturiranje domene Iz mnogo razloga, restrukturiranje domene će zahtijevati veći proračun od obnove domene. Hardverske zahtjeve potrebne za izgradnju gole šumske okoline u koju se moraju migrirati objekti imeničke usluge treba razmotriti iz proračunske perspektive

Ako tvrtka ne ispunjava sasvim uvjete da sa sigurnošću odabere obnovu ili restrukturiranje domene kao put obnove, ili ako joj oba puta odgovaraju, tada može izabrati treći put - obnovu domene nakon koje slijedi restrukturiranje.

Ovaj put do Active Directoryja će pružiti trenutne prednosti (delegiranje administracije, pravila grupe, objavljivanje aplikacija i drugo), kao i dugoročne prednosti restrukturiranja domene (manje domena s povećanim volumenom domene, dizajn domene u skladu s poslovnim i organizacijskim ciljevima tvrtke).