Problémy se synchronizací databáze. Automatické sledování struktury databáze. Jak na to

Text zpracoval V.I.

Start

Dříve nebo později se s tím setká každý. No, když ne všichni, tak mnozí. Srážejí se v té či oné míře – některé v nejjednodušší verzi, některé ve složité. Někdy existují standardní prostředky, někdy se ukáže, že problém lze zjednodušit na speciální případ. Někdy ale problém nastává tak, že standardní nástroje nejsou k dispozici nebo nejsou vhodné a úloha synchronizace databáze není zjednodušena na speciální případ...

Jeden čas stál před tímto úkolem i mě. Některé DBMS mají vestavěné synchronizační nástroje (tento proces se také někdy nazývá replikace a někdy se tyto pojmy rozlišují). Za prvé jsem ale potřeboval synchronizovat databáze spravované InterBase a za druhé i ty nástroje výrobců třetích stran, které pro tento DBMS existují, mi nevyhovovaly. Potřeboval jsem synchronizační mechanismus, který nezajišťoval neustálé sledování administrátorů u všech databází – program byl napsán s ohledem na malé organizace. InterBase byl pro to ideální - lehký, spolehlivý (určitě spolehlivější než lokální databáze!), nevyžadující prakticky žádnou administraci s nepříliš velkou zátěží. Kde se dá takový replikátor sehnat? Navíc, aby to bylo jednoduché jako zástrčka - spustilo to - fungovalo to. A dokonce vložit práci do programu! Navíc, aby mohl synchronizovat databáze pod Win a Unix!

Dva dny hledání vhodných nástrojů na internetu nevedly k ničemu. Hodně reklamy, málo informací, přemrštěné ceny a co je prostě nuda, „pro administrátora velmi pohodlné nástroje, s jejichž pomocí lze velmi snadno korigovat kolize“. No, nemám správce, který by mohl sledovat každou synchronizaci (která probíhá několikrát denně) a opravovat kolize! co dělat?

Dobře, pokus není mučení, rozhodl jsem se hledat něco o algoritmech používaných při replikaci databází.
NIC.
Absolutně nic!
Pokud jsem nehledal dobře a někdo mi v tomto ohledu ukáže zajímavé a volně dostupné materiály, budu rád! Zřejmě jde ale o khow-how výrobních společností nebo dosud nebyly vyvinuty žádné známé algoritmy na toto téma. Lezu do Data. Nic. Takže diskuze na téma distribuovaných databází, ale to co potřebuji tam není.

Tak či onak, po modlitbě jsem se rozhodl o tom všem přemýšlet a uvidíme, co se stane. Brainstormed. trpěl jsem. Napsal. Opraveno. Opraveno. Opět opraveno. Fungovalo to. Je to pokazené. Opraveno - přestalo to vadit. Pořád to funguje. líbí se mi. Funguje! Problémy samozřejmě jsou. A některé jsou docela slušné. Ale... ale pořád to funguje!

Rozhodl jsem se tedy těm, kteří mají zájem, říct, co jsem si myslel a co jsem udělal.

Možnosti, terminologie

Všechny termíny jsou domácí, takže se nebuďte uraženi, pokud vám něco připadá hloupé. :)

Synchronizace- proces, kterým jsou databáze uvedeny do identického stavu. Pokud někoho napadne lepší definice, poslechnu si to.

Nejprve klasifikujme synchronizaci podle směru a načasování.

Pokud lze data měnit pouze v jedné z databází a ve zbytku je uživatelé nemění, pak se synchronizace na takových databázích bude nazývat jednosměrná nebo jednosměrná. Pokud mohou uživatelé systému přidávat/měnit/odstraňovat data v několika systémových databázích, bude se jednat o obousměrnou (obousměrnou) synchronizaci.

Pokud musí být synchronizace provedena ihned po provedení změn v databázi, nazýváme takovou synchronizaci synchronizace v reálném čase. A pokud by měly být změny z některých databází provedeny v jiných databázích POZDĚJI, příkazem/událostí/atd – pak to bude zpožděná synchronizace.

Rozdělme nyní zpožděnou synchronizaci do dvou dalších podtříd. Pokud synchronizace vyžaduje připojení k oběma databázím a iont se provádí analýzou nesrovnalostí v těchto databázích, nazýváme ji synchronizace podle aktuálního stavu. A pokud se synchronizace provádí podle protokolu - seznamu změn provedených v databázi - pak tomu říkáme - synchronizace protokolu. Obě tyto odrůdy se nacházejí v komerčním vývoji. Při pohledu do budoucna řeknu, že jsem implementoval synchronizaci na základě aktuálního stavu.

Další. Pokud lze během synchronizace zjistit a provést změny v jednotlivých polích záznamů, pak toto synchronizace podle polí. Pokud je „jednotkou“ synchronizace záznam, pak toto synchronizace podle záznamů.

Zdá se, že je to vše intuitivně jasné, ale já chci přísnost a nechci hádky kvůli rozdílům v terminologii.

Nyní existuje jedna velmi důležitá definice, jejíž existence se ukazuje, že někteří vývojáři, kteří se poprvé setkali s naším problémem, nejsou obeznámeni. Kolize- to je určitá nejistota, někdy chyba, která se vyskytuje během synchronizace a je způsobena tím, že synchronizační algoritmy nejsou ideální a samotná úloha často představuje neřešitelné problémy. Nebo dokonce zcela neřešitelné v rámci přijatého schématu synchronizace. Na různé příklady Na srážky se podíváme později.

Odříznutí přebytku

Zmínil jsem tedy několik možností synchronizace a nyní bychom se měli zbavit těch „extra“. :) Nebudeme uvažovat o synchronizaci v reálném čase, to je stále poněkud exotický úkol. Podíváme se na jednosměrnou synchronizaci, ale velmi stručně – je docela dost jednoduchý úkol, dá se to vyřešit bez kolizí (alespoň mi to tak připadá, i když se mohu mýlit). Je jasné, že jednosměrná synchronizace je snadno implementována jakoukoli obousměrnou synchronizační metodou (log nebo aktuální stav), ale bez mnoha problémů, které jsou vlastní obousměrné synchronizaci. A samozřejmě naším hlavním cílem je obousměrná zpožděná synchronizace.

Identifikace záznamu

Pro správnou synchronizaci dat jakýmkoliv způsobem je samozřejmě nutné jednoznačně identifikovat záznamy v celém systému (alespoň v rámci jedné tabulky). Pokud se to někomu nezdá samozřejmé, řekněte mi, napíšu podrobněji.

Pro sjednocení je žádoucí, aby každá tabulka zahrnutá do procesu synchronizace měla náhradní primární klíč (ID) - obvykle INTEGER. Nejčastěji to však tak bývá. Jak můžeme zajistit, aby byly záznamy jednoznačně identifikovány?

1. Do každé tabulky můžete zadat další pole - číslo databáze, ve které byl tento záznam poprvé vytvořen (DBID). V tomto případě je zřejmé, že ID již nebude primárním klíčem, ale primárním klíčem bude dvojice (DBID, ID). Nutno podotknout, že kvůli tomu toto rozhodnutí nepříliš atraktivní
2. Z primárního klíče můžete vytvořit řetězec speciálního formátu, například XXXX-YYYY-ZZZZZZZZ, kde XXXX je identifikátor databáze, kde byl záznam poprvé vytvořen, YYYY je identifikátor tabulky, ZZZZZZZZ je identifikátor záznam v rámci konkrétní tabulky v konkrétní databázi. Toto řešení je vysoce škálovatelné a umožňuje do ID „nacpat“ mnoho dalších informací, má však i nevýhody. Za prvé, existuje určitá redundance informací. Za druhé, složitější mechanismus pro generování takových ID. Také by bylo hezké omezit možné hodnoty ID v tomto formátu. To jsou také obavy.
3. Podle mého názoru je pro InterBase nejlepší možnost následující - ID pro všechny tabulky je generováno běžným spouštěčem, který vybírá hodnoty z generátoru. V tomto případě je počáteční hodnota generátoru různá pro různé databáze, což zajistí jedinečnost ID napříč všemi databázemi. Tento přístup je typický pro InterBase. Jeho použití pro jiné DBMS může být omezeno nemožností nastavit počáteční hodnotu pro automaticky se zvyšující čítač pole.

Je jasné, že jsem zvolil třetí možnost. :) Zbývá ještě jedna otázka - datový typ pro IČ. Je jasné, že pro ID je možné použít INT64 (NUMERIC(18)), pak otázka dostupného rozsahu čísel nevyvstává - rozsah je obrovský. Ale bohužel existují některé problémy, které tomu brání. Faktem je, že podpora polí Int64 v Delphi stále poněkud pokulhává. Je to způsobeno jak nedostatky v komponentách pro přístup k datům (IBX, FIBPlus), tak i počáteční nepodporou polí Int64 ve třídě TField.

Zároveň, když se podíváme pozorně na rozsah INTEGER, zjistíme, že kdy

• používat pouze kladné hodnoty
• pomocí jediného generátoru pro všechny databázové tabulky
• denní vytvoření 10 000 záznamů v systému

máme dostatečný rozsah INTEGER na 27 let provozu systému 21 databází. V tomto případě budou počáteční hodnoty generátorů různých databází určeny jako DBID * 100000000. Pro většinu systémů jsou to zcela běžné hodnoty.

Srážky

V této části se podíváme na možné možnosti změny v databázi a poznamenejte si, ve kterých případech pravděpodobně dojde ke kolizi. Rozdělme všechny provedené změny do dvou tříd – změny provedené v jednotlivých nezávislých tabulkách a změny provedené v tabulkách spojených vztahy CIZÍ KLÍČ.

Kromě toho mohou být kolize způsobeny provozem spouštěčů a omezeními aplikací.

Změny jednotlivých tabulek

Do tabulky se přidá nový záznam

Po synchronizaci by se tento záznam měl objevit ve zbývajících databázích. Prvním důvodem kolizí s touto změnou může být konflikt primárního klíče, ale tento problém lze snadno vyřešit (viz výše). Pokud se tedy do jakékoli databáze přidá hromada záznamů, měly by být všechny bez problémů duplikovány v ostatních.

Možná by také stálo za zmínku, že pokud byly tyto záznamy ihned po synchronizaci smazány ze zdrojové databáze, pak by při příští synchronizaci NEMĚLY být obnoveny. :) To však spíše odkazuje na následující podsekci:

Příčinou kolize mohou být omezení typu UNIQUE. Nech mě to vysvětlit. Nechť existují 2 databáze: A a B. Tabulka (Tabulka1) je superponována UNIKÁTNÍ omezení(Pole 1). Předpokládejme, že v počátečním okamžiku nejsou v obou databázích ŽÁDNÉ záznamy, pro které Pole1 = Hodnota1. Přidejme takový záznam nejprve do A a poté do B. Nedochází k žádným chybám – není porušena podmínka UNIQUE. Nyní se snažíme tyto databáze synchronizovat. Logicky bychom měli v každé databázi vytvořit 1 záznam. Ale nemůžeme, protože by to porušilo omezení. Samozřejmě za předpokladu, že data byla zadána správně a model byl správně sestaven, mělo by se jednat o STEJNÉ (podle předmětových polí) záznamy, měly by popisovat stejnou entitu. To nám to ale nijak neulehčuje – vznikl konflikt a je třeba ho vyřešit. Tento problém můžete vyřešit odstraněním položky z jedné databáze a opětovnou synchronizací.

Toto je skvělý příklad toho, jak může dojít ke kolizi bez ohledu na konkrétní implementaci synchronizačního mechanismu. Vzniká zásadně kvůli distribuované povaze systému a opožděné synchronizaci.

Obecně jsou takové „logické“ kolize prakticky nevysledovatelné. A to je velmi smutné.

Záznam je odstraněn z tabulky

Po synchronizaci by měl být tento záznam smazán z jiných databází, pokud existuje. Opět jsou možné „logické“ kolize – například spouštěč kontroluje přítomnost alespoň jednoho záznamu, pro který Pole1 = Hodnota1 Nejprve byly v obou databázích dva takové záznamy. Smažeme jeden záznam v obou databázích. V tomto případě nedojde k žádným chybám, protože druhá zůstane. Ale pokud jsme vymazali v různých databázích různé záznamy, pak po synchronizaci dojde k chybě, protože nakonec v databázích nebude jediný záznam Pole1 = Hodnota1. V případě omezení tohoto druhu opět zřejmě bez administrátora, který dobře zná strukturu databáze a je schopen takové kolize opravit, nic nebude :(.

Některá pole v tabulce jsou změněna

Po synchronizaci v jiných databázích by se tento záznam měl změnit stejným způsobem.

První a velmi pravděpodobnou kolizí je současná změna záznamu v různých databázích. Tato kolize má dvě možnosti - pokud se změní stejná pole a pokud se změní různá pole.

V prvním případě je zjevně jedna verze změny nesprávná – popisovaná entita má přece velmi specifický význam tento parametr. Přijetím pozdější změny nebo více „hlavní“ databáze za pravdivé můžeme problém snadno vyřešit.

A druhý případ při synchronizaci na úrovni záznamu může způsobit vážný problém – ztrátu zadaných informací. Dovolte mi uvést příklad. Výše zmíněný Ivanov I.I. opět běžel do výše zmíněných institucí. Běžel k prvnímu a tam řekl, že je nyní invalidou druhé skupiny, kterou operátor zanesl do databáze. Když ten samý den doběhl do druhého ústavu, řekl, že má trojčata (nebo prostě druhý ústav - to je porodnice a tam si to každý zjistil sám a Ivanov běžel jen do jednoho ústavu). Tam změnili pole „počet dětí“. Pozor! Pokud je synchronizace prováděna celými záznamy, pak v závislosti na době změn nebo na „hlavnosti“ databází ztratíme tu či onu zadanou informaci, pokud chytrý správce neuvidí podrobný popis toho, co se stalo, a nenapraví tuto situaci ručně. Věřím, že je to jasné.

Vidíme tedy, že synchronizace na úrovni záznamů má za následek nejen čerpání nezměněných polí, ale může být také zdrojem velmi nepříjemných chyb. Zároveň je bohužel pro implementaci synchronizace na úrovni pole zapotřebí mnohem více režijních informací a mnohem složitější datové struktury. Implementace synchronizace podle polí může být navíc omezena možnostmi DBMS - je nutné určit seznam změněných polí a často jde také o netriviální úkol.

Změny propojených tabulek

Kolize budeme uvažovat při synchronizaci tabulek TableA a TableB. TabulkaB má cizí klíč (FOREIGN KEY) odkazující na tabulkuA. Potom záznamy tabulky A budou nadřazené a odpovídající záznamy tabulky B budou potomky.

Vytvoří nový nadřazený záznam nebo nový podřízený záznam k existujícímu nadřazenému záznamu

Vytvoří se nový rodičovský záznam a jeho podřízené položky

Nadřazené i podřízené záznamy se musí objevit v jiných databázích. Už se to sem dostává důležitá objednávka vytváření záznamů ve výsledné databázi - nejprve musí být vytvořen nadřazený záznam, poté děti. Avšak v těch DBMS, ve kterých jsou omezení referenční integrity kontrolována pouze při potvrzení transakce, to není nutné. Ale ani oni nemohou vytvořit všechny nové nadřazené záznamy, potvrdit transakci a poté vytvořit nové podřízené záznamy.

Podřízený záznam je smazán

Neexistují žádné speciální funkce další problémy se nevyskytuje kvůli příbuznosti tabulek.

Rodičovský záznam a děti budou odstraněny

Ve výsledné databázi musí být nejprve vymazány podřízené záznamy, poté nadřazené.

1. V databázi A se vytvoří podřízený záznam a v databázi B se odstraní nadřazený záznam.
2. V databázi A je podřízený záznam přenesen z nadřazeného záznamu 1 do nadřazeného záznamu 2, v databázi B je nadřazený záznam 2 smazán

Smyčky ZAHRANIČNÍHO KLÍČE

Vliv spouštěčů

Synchronizace protokolů - obecné principy

Toto je nejčastěji používaná metoda. Veškeré úkony prováděné v databázi (vytváření, mazání a úprava záznamů) jsou ukládány do nějakého logu - obvykle tento samostatný stůl nebo sadu tabulek v samotné databázi.

Protokol je naplněn spouštěči, které zapisují do protokolu informace dostatečné k opětovnému provedení provedené akce. Je jasné, že v případě mazání záznamu stačí uložit identifikátor tabulky a hodnotu primárního klíče mazaného záznamu a pro změnu či vytvoření záznamu je nutné uložit i hodnoty pole. Obvykle je také uloženo časové razítko, kdy byla změna provedena.

Chcete-li synchronizovat dvě databáze, každá z nich zopakuje všechny akce provedené v jiné databázi a načte je jednu po druhé z protokolu. Z toho plyne jedna z výhod synchronizace logu - není potřeba navazovat spojení s databází - výstup logu do samostatného souboru lze přenést přes "floppynet" :) Jen je potřeba si pečlivě poznamenat, které položky logu ještě nebyly byla převedena. Tento problém se komplikuje, když existuje několik synchronizovaných databází - musíte si zapamatovat, která poslední záznam log byl přenesen do každé z databází.

Je jasné, že po úspěšné aplikaci protokolu do jiné databáze lze protokol oříznout. Ale přesto log zabírá hodně místa – v nejlepším případě duplikuje nové a změněné záznamy.

Pokud byl stejný záznam změněn několikrát za sebou, můžete buď uložit všechny mezizměny, nebo tyto změny „slepit“ do jedné. Tím se sníží velikost protokolu, ale může dojít ke zbytečným kolizím.

Synchronizace protokolů se vyznačuje nárůstem uložených dat úměrným počtu změn v synchronizačním cyklu a rychlost synchronizace je rovněž úměrná počtu změn v synchronizačním cyklu.

Je třeba také zmínit, že na základě protokolu můžete sestavit službu pro vrácení stavu databáze téměř kdykoli (pokud příslušná data nebyla z protokolu smazána).

Synchronizace protokolů je implementována poměrně jednoduše, ale je zřejmé, že kolize jsou nevyhnutelné. Pro ilustraci vám nabízím následující přirovnání. Představte si, že máte 2 pokoje se zásuvkami. Máte robota, který se dá naprogramovat tak, aby přesouval krabice. V počátečním okamžiku jsou krabice v místnosti umístěny stejným způsobem. Dáváte robotovi příkazy a on pohybuje krabicemi. Váš partner dává příkazy jinému robotovi ve druhé místnosti. Poté přikážete robotům změnit místa a opakovat všechny akce počínaje výchozím bodem. Je zřejmé, že to může vést k potížím - v první místnosti robot posunul krabici č. 5, ale ve druhé místnosti nebyl na místě, v první místnosti posunul krabici č. 54 do rohu, ale ve druhém rohu bylo obsazeno.

Je třeba poznamenat, že úspěšná aplikace protokolu 2 v DB 1 neznamená, že protokol 1 v DB 2 bude fungovat bez chyb.

Výhody

• Není nutné žádné připojení
• Databázi můžete kdykoli vrátit do minulosti
• Srovnávací snadnost implementace
• Vysoká rychlost synchronizace - úměrná počtu změn za cyklus

Nedostatky

• Velké objemy uložených dat – úměrné počtu změn za cyklus
• Kolize jsou téměř nevyhnutelné

Synchronizace na základě aktuálního stavu - obecné principy

Se synchronizací podle aktuálního stavu jsem se v různých produktech setkal mnohem méně často než se synchronizací na základě logu. Zdá se mi však, že z toho nelze vyvodit závěr o jeho použitelnosti. Je známo, že v různých problémech je lepší použít vhodnější metody.

Synchronizace na základě aktuálního stavu se tedy provádí vždy s navázáním spojení, takže tuto metodu nelze použít bez přítomnosti nějakého komunikačního kanálu mezi servery.

Proces, který provádí synchronizaci, naváže spojení s oběma databázemi (pokud existuje více než dvě databáze, pak se synchronizace provádí ve dvojicích - například „řetězec“ nebo „hvězda“) a prochází všemi synchronizovanými tabulkami a hledá rozdíly. Zde vidíme první významný nedostatek metoda - rychlost synchronizace je úměrná celkovému počtu záznamů v databázi. Připomínám, že u synchronizace protokolů byla rychlost úměrná počtu změněných dat.

Když jsou nalezeny rozdíly, řídicí proces tyto rozdíly odstraní a obě databáze přivedou do stejné podoby. V tomto případě je třeba rozhodnout - která z databází obsahuje správnější údaje o aktuálním zpracovávaném záznamu - zda záznam vymazat z databáze 1 nebo naopak vytvořit stejný v databázi B, kde ještě není k dispozici.

Na rozdíl od synchronizace žurnálu však při použití žurnálu neexistuje žádná další informace, v tomto případě může controllingový proces zadávat pomocné dotazy do obou databází, aby co nejlépe vyřešil všechny kolize - např. zjistit, zda v jiných tabulkách nejsou záznamy, které na tuto odkazují. Nastavením určitých pravidel tedy můžete automaticky vyřešit poměrně velkou část kolizí.

Pokud si připomeneme analogii s roboty, boxy a místnostmi, tak v tomto případě se robot podívá do obou místností a pokud uvidí, že box č. 15 je v různá místa Poté, co přijme jedno z umístění jako správné, pokusí se jej umístit na stejné místo v jiné místnosti. Navíc, pokud bude jeho místo obsazeno, pak je to možné dodatečná analýza- který box je obsazený? proč není první pokoj obsazený?

Je snadné vidět, že taková metoda je v zásadě správnější - místo hloupého opakování akcí z jiné databáze za nových podmínek je možné rozdíly rozebrat a co nejbezpečněji odstranit.

Pro provedení synchronizace podle stavu se obvykle pro každý záznam databáze zadává jedno nebo více dalších polí, pomocí kterých může řídící proces určit, který ze dvou záznamů obsahuje aktuálnější data. Velikost dodatečných dat je opět úměrná celkovému množství dat v databázi, nelze to však srovnávat se synchronizací deníku, protože velikost dodatečných polí je poměrně malá a nezvyšuje se s opakovanými změnami dat a záznamy v deníku nejčastěji zcela duplikují záznamy tabulky a hromadí se při postupných změnách.

Shrňme si výhody a nevýhody, které jsme uvažovali, do jediného seznamu.

Výhody

• Dobré možnosti pro korekci kolizí

Nedostatky

• Nízká rychlost synchronizace - úměrná počtu všech záznamů
• Vyžaduje připojení k oběma databázím
• Pro všechny záznamy zadejte další pole- nelze skutečně srovnávat se synchronizací žurnálu

Synchronizace nezávislých sad tabulek

Mějme tedy několik databází - A, B, C,... V tomto případě dochází ke změnám dat (bez ztráty obecnosti) pouze v DB A. Je třeba také poznamenat, že pokud databáze mají nezávislé sady tabulek, pak v V jedné takové sadě lze data měnit pouze v databázi A a v jiné - pouze v databázi B (například). Takovou strukturu lze také považovat za jednosměrný synchronizační systém, jednoduše prováděný odděleně přes několik sad tabulek.

Dovolte mi to vysvětlit na příkladu. Společnost má internetový obchod. Jedna databáze je umístěna v kanceláři společnosti, druhá je na webovém serveru. Nechť existuje několik tabulek popisujících produkty internetového obchodu a tabulky v návštěvní knize a fóru. Tyto sady jsou na sobě nezávislé a body změny dat se liší. Popisy produktů se vyplňují v kanceláři a změny je nutné přenést do databáze webových stránek. A informace od klientů - fórum a příspěvky hostů se vytvářejí na webu a jdou opačným směrem.

V tomto schématu jsou kolize prakticky vyloučeny – toky aktualizace databáze se nekříží. Takové schéma lze bez problémů implementovat téměř jakýmkoli způsobem.

Problémy začínají při zavedení funkce online nákupu zboží do internetového obchodu. V tomto případě jsou objednávky zákazníků závislé na produktových tabulkách. A data pro tento soubor se mohou měnit ve dvou databázích současně.

Pokračování...

Ve druhé části přejdeme k mému aktuálnímu řešení - implementaci obousměrné synchronizace na základě aktuálního stavu databáze.

Asi před dvěma lety jsem zrodil projekt - malý program klient, který lze nainstalovat na libovolné zařízení a jednoduše synchronizuje soubory.
Můžete například určit, že dokumenty budou synchronizovány mezi vaším domácím a pracovním počítačem. Hudba a knihy mezi domácím počítačem a telefonem. Zálohování mezi domácím počítačem, pracovním počítačem a serverem. Tento program by také mohl řídit následnou distribuci libovolného souboru v systému. To znamená, že vy jako vlastník můžete vždy zjistit historii souboru: kopírování na flash disk, do jiného počítače, e-mailem atd.

Pak jsem již téměř obdržel finanční prostředky, ale investiční fond, se kterým jsem na poslední chvíli pracoval, požadoval vážný podíl na podnikání. A rozhodl jsem se, že hra nestojí za svíčku. A pak na to nějak nebyl čas.

PS
Díky Sasha Murin za tip)

Adresář se čte pomocí příkazu get-childitem. Pro zohlednění podsložek je do ní přidána volba -recurse a pro rozlišení souborů od složek se používá funkce PSIsContainer(). Pokud vrátí True, pak je prvkem složka, jinak je to běžný soubor:

$source = ¨c:files¨

$srcfolder = get-childitem $source -recurse | kde-objekt($_.psiscontainer)

$srcfiles = get-childitem $source -recurse | kde-objekt(!$_.pciscontainer)

K vyřešení našeho jednoduchého problému potřebujeme čtyři seznamy: první dva obsahují zdrojové soubory a složky a zbývající dva jsou výsledné soubory a složky. Proces synchronizace spočívá v opakování těchto seznamů a kopírování souborů z jedné složky do druhé.

První smyčka kontroluje, zda zdrojové adresáře existují v záložní složce, a pokud ještě neexistují, jsou vytvořeny pomocí příkazu new-item.

foreach ($folder v $srcfolders)

$srcpath = $zdroj -nahradit ¨\¨,¨\¨ -nahradit ¨:¨,¨:¨

$dstpath = $folder.fullname -nahradit $srcpath,$destination

if ($dstpath -ne ¨¨) (

if (! (test-path $dstpath))

¨Vytvoření složky „$dstpath“.¨

new-item $dstpath -type adresář | out-null

Velmi podobný cyklus se provádí při porovnání výsledného a zdrojového seznamu složek, čímž se vytvoří přesná struktura podsložek. Dva další cykly zpracovávají soubory: první zkopíruje aktualizované objekty ze zdroje do výsledné složky, druhý – ty, které nejsou ve zdrojovém adresáři – z posledního. Zda byl soubor aktualizován, můžete zjistit podle jeho hash kódu. Všimněte si, že vzhledem k tomu, že soubory jsou otevírány v režimu pouze pro čtení, není blokováno jejich použití jinými programy. Podle pravidel dobré formy však musí být soubor uzavřen pomocí funkce Close() po výpočtu hash kódu:

$md5 = new-object system.security.cryptography.md5cryptoserviceprovider

$fs = new-object system.io.filestream ($file,$mode,$access)

$hash = $md5.computehash ($fs) # hash kód souboru

$fs.close()

Rýže. 1. Výsledek analýzy sledovaných složek v GoodSync

Poté můžete ručně spustit synchronizaci dat (tlačítko Synchronizace), je však pohodlnější nakonfigurovat program tak, aby operaci provedl automaticky. Za tímto účelem otevřete plánovač zabudovaný v obslužném programu a určete čas synchronizace nebo událost, při jejímž výskytu má program začít analyzovat a synchronizovat soubory (obr. 2).

Rýže. 2. Nastavení automatická synchronizace v GoodSync

Stojí za to věnovat pozornost jedné nuanci. Při automatické synchronizaci souborů na přenosné úložné zařízení (například flash disk) může dojít k problému s rozpoznáním disku. Je pohodlnější, když se zpracování souborů spustí automaticky po připojení jedinečného zařízení, nicméně jakýkoli USB disk se po připojení zobrazí pod stejným písmenem, což povede k chybám synchronizace, pokud je vložen další flash disk. Aby program správně rozpoznal požadovaný disk, musíte ručně změnit cestu k zařízení a nahradit písmeno jednotky jmenovkou svazku (=VolumeName:\folder1\folder2 - obr. 3). Ve vlastnostech pomocí Průzkumníka Windows lze snadno nastavit odpovídající jmenovku svazku pro konkrétní disk. Aplikace specifikovaná nastavení zaručuje detekci požadovaného přenosného disku bez ohledu na přiřazené písmeno jednotky.

Rýže. 3. Nahraďte písmeno jednotky štítkem svazku
v GoodSync

naopak

Vývojář: Software TGRMN

Velikost distribuce: Pro - 3,4 MB; Plus - 1,1 MB; Zdarma – 708 kB

Práce pod kontrolou: ViceVersa Pro 2.5 a ViceVersa Plus 2.4.2 - Windows (všechny verze); Naopak zdarma 1.0.5 - Windows XP/Vista/7

Cena: Pro - 59,95 $; Plus - 34,95 $; Zdarma - zdarma

ViceVersa Pro - známé řešení pro synchronizaci, zálohování a replikaci souborů a složek (obr. 4). S jeho pomocí můžete synchronizovat data mezi stolními počítači, notebooky, souborovými servery, externí média (pevné disky, USB zařízení, ZIP disky atd.), NAS atd. To je realizováno přes lokální síť, přes internet a pomocí jakýchkoliv externích úložných zařízení.

Během synchronizace jsou analyzovány parametry, jako je velikost souboru a datum/čas vytvoření souboru, kontrolní součty nebo kombinace těchto parametrů. Je možné zahrnout/vyloučit při analýze podadresářů, stejně jako samostatné soubory s ohledem na jejich atributy (skryté/systémové/pouze pro čtení) a masky. Umožňuje synchronizaci a zálohování souborů otevřených a zamčených aplikacemi, včetně poštovní databáze Outlook a Outlook Express, Word dokumenty a databáze Excel a SQL. Synchronizace dat se provádí ručně na vyžádání popř automatický režim- podle rozvrhu (například každý den v přesně stanovený čas). Za účelem úspory místa na disku a zajištění bezpečnosti dat na jakémkoli médiu poskytuje program nástroje pro kompresi a šifrování souborů.

Nástroj je k dispozici ve třech edicích: zdarma zdarma (http://www.tgrmn.com/free/) a dvou komerčních edicích – základní Plus a rozšířené Pro. Možnosti bezplatné edice jsou omezeny na porovnávání a synchronizaci souborů ve složkách (včetně podsložek) mezi disketovými jednotkami, pevnými disky, síťovými jednotkami a jednotkami ZIP a CD; synchronizace se provádí ručně. Edice Plus vám umožňuje pracovat s USB disky, pevnými a síťovými disky a také DVD/CD, poskytuje možnost synchronizace/zálohování otevřených/zamčených souborů a lze ji nakonfigurovat tak, aby pracovala podle plánu. Edice Pro podporuje všechny funkce deklarované vývojáři.

GoodSync 8.8.6

Vývojář: Společnost Siber Systems, Inc.

Velikost distribuce: 7,15 MB

Práce pod kontrolou: Windows 2000/XP/Vista/7

Cena: 29,95 dolarů

GoodSync je pohodlný a jednoduchý nástroj pro synchronizaci a zálohování souborů (obr. 5). Program umožňuje synchronizovat soubory mezi stolními a přenosnými počítači, vyměnitelnými disky a servery a také zálohovat důležitá data na různá média (včetně serverů FTP a WebDAV). Navíc je možné mezi sebou synchronizovat soubory Zařízení Windows Mobilní telefon nebo Pocket PC (Windows CE) a stolní počítač. Synchronizaci lze provádět přímo mezi počítači (v místní síť nebo přes internet ze serverů FTP, WebDAV a Secure FTP) nebo připojením libovolného externí disky(USB disk, externí HDD).

Analýza dat se provádí s ohledem na datum/čas úpravy souborů nebo jejich velikost. Během analýzy jsou skryté a systémové soubory automaticky ignorovány, můžete nakonfigurovat zahrnutí/vyloučení souborů s názvy odpovídajícími konkrétní masce a také souborů určitou velikost nebo s určitý čas změny. Zamknuté soubory je možné synchronizovat pomocí služby Stínová kopie svazku. Pro automatizaci procesu synchronizace jsou zahrnuty nástroje pro spouštění synchronizace podle plánu a při výskytu určitých událostí (například když je počítač připojen k místní síti, když je k počítači připojen vyměnitelný disk nebo když se spustí systém ), lze použít plánovač Windows. Pro zvýšení bezpečnosti při vzdálené synchronizaci dat je implementován přenos souborů přes šifrovaný kanál (FTP přes SSH a WebDAV přes SSL) a pro zálohování je možné použít šifrovaný souborový systém EFS (Encrypting File System).

Program má demo verzi, která je plně funkční po dobu 30 dnů. V budoucnu ji mohou používat domácí uživatelé a neziskové organizace zcela zdarma, ovšem s omezením – můžete vytvořit až tři synchronizační úlohy, včetně maximálně sta souborů. K dispozici je speciální přenosná edice utility – vystupuje pod názvem GoodSync2Go a je určena pro instalaci na USB disky.

Allway Sync 11.6.1

Vývojář: Botkind, Inc.

Velikost distribuce: 6,9 MB

Práce pod kontrolou: Windows 2000/XP/2003/Vista/2008/7

Cena: závisí na licenci: Pro - 29,99 $; Zdarma – zdarma (pouze pro nekomerční použití)

Allway Sync je snadno použitelná utilita určená pro synchronizaci a zálohování souborů ve složkách (obr. 6). Program poskytuje synchronizaci dat mezi stolními počítači, notebooky, externími pevnými disky, USB disky, FTP/SFTP servery a různými online zařízeními pro ukládání dat. Analýza a aktualizace informací se provádějí přes místní síť, přes internet a prostřednictvím externích úložných zařízení (flash disky, externí pevné disky atd.).

Nejnovější verze souborů jsou detekovány na základě kombinace atributů souboru, velikosti souboru a času vytvoření. Pro zúžení seznamu analyzovaných souborů je možné zahrnout/vyloučit synchronizační objekty s ohledem na umístění souboru, název a atributy (pouze zahrnout/vyloučit skryté/systémové soubory). Synchronizaci lze provádět na vyžádání a automaticky – po určité době, když je připojeno vyměnitelné zařízení, když je počítač nečinný atd.; Můžete použít plánovač úloh systému Windows.

Program je nabízen ve dvou edicích: zdarma a komerční Pro. Bezplatná edice vám umožňuje synchronizovat maximálně 40 tisíc souborů během 30 dnů. K dispozici je speciální přenosná edice utility určené pro instalaci na flash disk nebo externí HDD.

FreeFileSync 4.2

Vývojář: ZenJu

Velikost distribuce: 9,27 MB

Práce pod kontrolou: Windows 2000/XP/Vista/7

Cena: zdarma

Nezapomeňte na relevanci kopií, u kterých by měla být prováděna pravidelná synchronizace. Celý objem dat můžete samozřejmě kopírovat pokaždé znovu, ale to je vhodné pouze v případě, že je dat jen malé. Pro velké objemy to způsobí zbytečné opotřebení pevný disk a obecně ztráta času. Synchronizace je mnohem rychlejší než úplná kopie, ale je velmi důležité jej správně nakonfigurovat. V opačném případě můžete ztratit kopii i původní data! Před použitím synchronizace ji nezapomeňte otestovat na nepotřebných souborech a složkách!

Nastavení synchronizace ve FreeFileSync

Po instalaci spusťte program a vyberte složky pro synchronizaci. Vlevo bude původní složka a vpravo - zálohování na externí pevný disk.

Poté přejděte do nastavení porovnání souborů a vyberte možnosti. Ve výchozím nastavení jsou soubory porovnávány podle data a velikosti. Na kartě "Filtr" můžete nakonfigurovat složky a soubory, které chcete vyloučit ze synchronizace.

Na záložce „Synchronizace“ nakonfigurujeme režim synchronizace. K dispozici jsou celkem 4 režimy:

• Oba způsoby - změny jsou sledovány na obou stranách synchronizace.
• Zrcadlit - berou se v úvahu pouze změny na levé straně, to znamená, že soubory a složky, které neexistují na levé straně, budou během synchronizace odstraněny.
• Aktualizace - soubory se kopírují zleva doprava, a pokud jsou nalezeny nové soubory vpravo, je nutný zásah uživatele.
• Selektivní – můžete nakonfigurovat vlastní pravidla pro zpracování souborů.

Nastavení plánované synchronizace

FreeFileSync má užitečná funkce- jedná se o uložení parametrů synchronizace ve formuláři dávkový soubor. Chcete-li vytvořit tento soubor, klikněte na tlačítko „uložit jako dávkovou úlohu“. V případě potřeby můžete povolit nahrávání protokolů synchronizace.

Při spuštění tohoto souboru se synchronizace provede ve skrytém režimu, bez spuštění grafického rozhraní. Proto lze systém Windows nakonfigurovat tak, aby spouštěl tento soubor podle plánu. Chcete-li to provést, otevřete panel Správa Windows a najděte tam položku „Plán provádění úlohy“. Jako příklad nakonfigurujeme synchronizaci tak, aby se spustila při zapnutí počítače. Vytvoříme úkol pro všechny uživatele. V tomto případě musí být v počítači nastaveno heslo.

Jako spouštěč určíme „Při spuštění“. Vyplatí se také nastavit zpoždění, aby vše fungovalo správně.

Malý bezplatný synchronizátor složek a souborů pro každodenní potřeby.

Mít v sobě dva (a někdy i více) počítačů domácí použití už dávno přestal být vnímán jako něco neobvyklého. Dnes v domácí lokální síti najdete až tucet různých zařízení, a to jak samotné PC, tak různé síťové disky, DVD a Blue-Ray přehrávače, televizory s přístupem k síti atd. I když nemáte vše výše uvedené, stále pravděpodobně používáte k přenosu potřebných dat alespoň jeden flash disk. V každém případě nastávají situace, kdy se požadovaný soubor změní na místním počítači a musíte jej ručně přenést na stejný flash disk. A pokud existuje několik takových souborů, jak si můžete pamatovat „stáhnout“ aktuální kopie včas? Pro tohle všechno existuje speciální programy- synchronizátory.

Dobrý synchronizátor by měl být schopen pracovat rovnoměrně jak s lokálními složkami, tak s vyměnitelnými a vzdálenými paměťovými médii, sledovat změněné soubory v určeném adresáři a včas je aktualizovat v konečné složce, pracovat podle daného plánu v automatickém a/nebo skrytý režim... Všechny tyto (a některé další) schopnosti jsou dostupné ve velmi malém nástroji DSynchronizovat. Navzdory volnému stavu a malá velikost může snadno konkurovat na stejné úrovni komerčním programům, jako jsou ty oblíbené v zahraničí Synchromagic Pro.

Srovnání programu DSynchronize s placeným analogem Synchromagic Pro

DSynchronizovat má poměrně jednoduché rozhraní a docela dobrou funkčnost, takže jej lze bezpečně nabídnout jak pro domácí, tak i pro domácí použití firemní použití. Velké plus Další věcí je, že program může pracovat v servisním režimu, což běžnému uživateli umožňuje ani nepřemýšlet o ruční synchronizaci souborů a mít po ruce pouze nejaktuálnější verze po nastavení pracovního plánu DSynchronizovat.

K nevýhodám programu (i když záleží na kom :)) patří nemožnost DSynchronizovat archivovat zkopírované soubory pro případnou následnou obnovu. Funkce zálohování se zdá být přítomna ve formě okna "Zálohování", ale ve skutečnosti nebylo možné najít žádné kopie ani ve složce s programem, ani v synchronizovaných adresářích :(. Přesto nejsem nakloněn připisovat tuto nevýhodu nevýhodám, protože je nepravděpodobné, že bychom používali staré verze souborů , a i když použijeme , pak si pravděpodobně vytvoříme kopie sami.

Nyní tedy k práci s programem. DSynchronizovat nevyžaduje instalaci, ale pro uložení nastavení byste jej měli stále rozbalit do libovolné složky na vašem pevném disku. To je vše, můžeme se pustit do práce.

DSynchronize rozhraní

Rozhraní programu je zpočátku anglické, i když je intuitivní. Na oficiálních stránkách není žádná ruská lokalizace, ale pokusil jsem se „domestikovat“ DSynchronizovat.. Pro rusifikaci programu stačí přidat soubor do složky, ve které jste jej rozbalili DSynchronize.lng ze staženého archivu (ach, ano... je povolena jakákoliv úprava a optimalizace výše uvedeného souboru podle vašich potřeb :))). Nyní spustíme ruskou verzi DSynchronizovat.

Podmíněně rozhraní okna DSynchronizovat lze rozdělit na tři části. Nahoře jsou seznamy dvojic adresářů pro synchronizaci, níže panel nastavení všech procesů a ještě níže tři okna, která reflektují práci se soubory. Hned na začátku v seznamu úloh uvidíme dva příklady. Měly by být odstraněny pomocí odpovídajícího příkazu v kontextové nabídce (pravé tlačítko myši). Když seznam standardní úkoly budou vymazány, přidáme vlastní. Znovu vyvolejte kontextovou nabídku a vyberte položku "Přidat". Objeví se pár prázdné řádky. Do těchto řádků zadáme úplné adresy složek, ve kterých se mají soubory synchronizovat.

Nyní existuje několik nuancí. Pokud plánujete synchronizovat dvě lokální složky, pak stačí dvakrát kliknout na řádek a kliknout na tlačítko "Recenze", nejprve vyberte ze seznamu zdrojová složka(ze kterého budou soubory zkopírovány), a pak poslední. Totéž by mělo být provedeno, pokud chcete synchronizovat složku s vyměnitelné médium informace (například pomocí jednotky flash) po předchozím připojení zařízení k počítači.

Synchronizace přes FTP

Chcete-li se však připojit ke vzdálenému počítači prostřednictvím místní sítě nebo FTP, budete muset zadat cestu ručně. Pro přístup ke složce na vzdáleném PC přes místní síť budete muset zadat následující: \\Název počítače (nebo jeho IP)\Název složky (například \\192.168.1.4\Sdílené dokumenty). Jedinou výhradou je, že složka, ke které se připojujeme, musí být otevřená pro veřejný přístup. Vyvolejte kontextovou nabídku složky a vyberte "Vlastnosti". V okně, které se otevře, přejděte na kartu "Přístup" a zaškrtněte políčko "Sdílet tuto složku".

Chcete-li použít možnost synchronizace FTP, zadejte úplnou adresu serveru (například ftp://Adresa serveru/Název složky). Pokud jako odpověď obdržíte chybovou zprávu, znamená to, že pro přístup k serveru musíte zadat autorizační informace. To lze provést přidáním přihlašovacího jména před adresu serveru, poté hesla za dvojtečku a teprve poté za „@“ podepište přímou adresu serveru (viz snímek obrazovky výše).

Jakmile je pár složek, které synchronizujete, připraven, můžete nakonfigurovat některé možnosti sdílení souborů. Chcete-li to provést, klepněte na tlačítko "Filtr" vedle adresy složky nebo zavolejte příslušný příkaz z kontextové nabídky.

Zde můžeme specifikovat kopírování buď striktně určité soubory nebo jejich typy podle masky s uvedením položky "Aktivace filtru", nebo výběrem určete, které soubory (nebo typy souborů) se nemají synchronizovat "Filtrovat výjimky". Maska je nastavena standardním způsobem: zadáme část názvu souboru a vše nepotřebné označíme jako «*» . Masky můžete oddělit běžným středníkem. Dále je zde pár možností, které určují parametry pro práci s podsložkami a ještě níže je sekce "Pokročilé filtry". Zde můžete z kopírování vyloučit soubory, které byly změněny v konkrétní den.

DSynchronizujte nastavení

Podívejme se nyní panel možností, který se nachází pod seznamem složek.

Všechny možnosti jsou rozděleny do čtyř skupin. první - "Hlavní možnosti"- zahrnuje téměř vše potřebná nastavení synchronizace Stojí za to věnovat pozornost prvním dvěma možnostem. Odstavec "Pouze nejnovější" umožňuje nepřepisovat vše existující soubory a zkopírujte pouze nejnovější verze. Výrazně se tak ušetří čas strávený synchronizací. Další možností je "Dvojitá synchronizace". Pokud je aktivován, pak se v obou složkách kontrolují nové verze souborů a v důsledku toho v každé z nich zůstanou pouze nejaktuálnější kopie.

Druhá skupina nastavení - "Speciální možnosti". Zde můžete povolit antifragmentaci přidaných souborů, přeskakování chyb a také zálohování (které ve skutečnosti nefunguje:(). Ze všech možností, které jsou zde k dispozici, "Anti-fragmentace". Pokud je aktivován, pak když je nalezena nová verze souboru, stará je smazána a nová verze je přidána jako nový soubor. To umožňuje menší fragmentaci, než kdyby starý soubor právě vyměněn za nový.

Čtvrtá skupina - "týmy"- obsahuje pouze tlačítka pro ovládání procesu synchronizace, pojďme se tedy blíže podívat na třetí skupinu - "Plánování". Jedná se o jednu z nejzákladnějších sekcí, která je zodpovědná za automatizaci všech procesů v práci. DSynchronizovat. Kliknutím na první možnost - "časovač", přejdeme do okna nastavení synchronizace času:

Zde je možné nastavit synchronizaci po určité době nebo v konkrétním okamžiku (například v jednu hodinu odpoledne). Proces porovnávání souborů navíc můžeme nastavit nejen každý den, ale i přesně definované dny v měsíci či týdnu!

Je tu příležitost DSynchronizovat nastavit konstantní synchronizaci v reálném čase pomocí položky "V reálném čase". Pravda, tato funkce je zatím experimentální, na což budeme upozorněni, když se ji pokusíme povolit, takže před její aktivací bychom se měli ujistit, že program správně pracuje s vybranými složkami v normálním režimu.

Dále jsou zde dva body, které jsou zodpovědné za autorun DSynchronizovat. první - "Automatické spuštění", umožňuje stáhnout program spolu se systémem. V tomto případě bude program viditelný v zásobníku, ze kterého jej lze vždy volat. Pokud jste si jisti, že je vše správně nakonfigurováno a stálý přístup Na DSynchronizovat Pokud jej nepotřebujete, můžete program nastavit tak, aby běžel v servisním režimu. Chcete-li to provést, zaškrtněte položku "Spouštění služby...".

V okně, které se otevře, musíte nejprve kliknout na tlačítko "Instalovat službu" pro instalaci nová služba, a poté jej spusťte, poté stačí stisknout tlačítko "připraven".

Ukázka práce s programem

Nyní je vše opravdu připraveno začít pracovat, takže stiskněte tlačítko "Synchronizace" v sekci "Týmy".

Samotný proces synchronizace probíhá ve dvou fázích, které lze vidět ve stavovém řádku. První fází je porovnání a vytvoření seznamu souborů ke kopírování, druhou je přímé kopírování. Ve třech oknech pod hlavním menu vidíme seznamy všech zkopírovaných, smazaných nebo nahrazených souborů. Zde také můžeme stanovit určité zákazy nebo povolení pro relevantní akce. Pokud si chcete ponechat kontrolu nad celým procesem synchronizace, doporučuji vám před jakoukoli akcí povolit požadavek DSynchronizovat(snad kromě přidávání souborů). Takové žádosti vypadají takto:

V tomto případě máme okno pro potvrzení nahrazení souboru (Potvrdit přidání - potvrzení přidání, Potvrdit odebrání/smazání - smazání).

O dokončení procesu synchronizace se opět dozvídáme z nápisu ve stavovém řádku:

Gratuluji! Nyní můžete konečně zapomenout na ruční kopírování potřebné soubory, protože všechny starosti spojené se synchronizací souborů můžete přesunout na DSynchronizovat.

P.S. Tento článek je určen pro distribuce zdarma. Můžete si jej zkopírovat při zachování autorství. Ruslan Tertyshny a všichni P.S. a P.P.S.

P.P.S. Pokud máte rádi all-in-one řešení, pak vám doporučuji podívat se blíže na následující správce souborů, který má mimo jiné možnost synchronizovat zadané adresáře.

Asi před dvěma lety jsem vytvořil projekt – malý klientský program, který lze nainstalovat na jakékoli zařízení a jednoduše synchronizuje soubory. Můžete například určit, že dokumenty budou synchronizovány...

Asi před dvěma lety jsem vytvořil projekt – malý klientský program, který lze nainstalovat na jakékoli zařízení a jednoduše synchronizuje soubory. Můžete například určit, že dokumenty budou synchronizovány...

Synchronizace databáze Data MySQL umožňuje vytvářet a automaticky udržovat dvě nebo více databází s identickým obsahem. Synchronizace je nutná pro vytváření zrcadel, clusterů atd. Naprogramovat Praktické zálohování umožňuje plně automatizovat proces synchronizace databáze MySQL.

Metody synchronizace databáze MySQL

V MySQL může být synchronizace mezi dvěma databázemi jednosměrná nebo obousměrná.

Jednosměrná synchronizace

Obsah jedné databáze (master) se zkopíruje do jiné (slave). V MySQL je synchronizace databáze různé servery slouží k replikaci tabulek, vytváření testů a rezervní základny, zálohování MySQL atd.

Obousměrná synchronizace

Obousměrná synchronizace MySQL zajišťuje, že aktuální změny jsou zkopírovány z každé databáze do druhé. Tato technika se používá především pro distribuci výpočetní úlohy související s databázemi – vytváření clusterů a databázových zrcadel.

Výhody Handy Backup pro synchronizaci databáze MySQL

Handy Backup obsahuje vestavěný MySQL plugin, který umožňuje kopírovat stav MySQL databází a tabulek v „horkém“ režimu (bez zastavení serveru), stejně jako ve „studeném“ režimu (se zastavením). To poskytuje následující výhody:

• synchronizace dat MySQL (kopírování a obnova) podle plánu;
• Ukládání tabulek MySQL v lidsky čitelné podobě textový formát ze seznamu SQL příkazů;
• Automatické zastavení přijímacího serveru MySQL při obnově dat;
• Verzované kopírování a vytváření časových razítek na kopiích podle potřeby;
• Získání přístupu k externím serverům MySQL.

Jak synchronizovat MySQL pomocí Handy Backup?

Synchronizace databází MySQL spočívá ve vytvoření záložní kopie databáze a následném obnovení tabulek této databáze na jiném serveru pomocí pluginu "MySQL". Tento proces zahrnuje 2 po sobě jdoucí úkoly:

Zálohujte data ze zdrojové tabulky (v případě jednosměrné synchronizace) nebo obou tabulek (v případě symetrické synchronizace).

Obnovení dat na synchronizovaná MySQL tabulka, plné nebo diferenciální, v závislosti na typu synchronizace.

Podrobný popis úloh kopírování a obnovy MySQL je k dispozici v uživatelské příručce.

Automatizace úloh synchronizace tabulek MySQL

Aby byl proces synchronizace databáze MySQL zcela automatický, věnujte prosím pozornost následujícím bodům:

1. Rozdělte dobu běhu úloh zálohování a obnovy MySQL dostatečně dlouho, aby měla spuštěná úloha zálohování databáze čas dokončit před zahájením obnovy.
2. Pro středně pokročilé kopie MySQL vyberte média, která jsou dostatečně rychlá z hlediska rychlosti přístupu: místní a externí disky, NAS/SAN zařízení a FTP/SFTP/FTPS servery s širokým propustnost síťové rozhraní.
3. Využijte možnosti kroku 7 (nastavení spouštění programů před a/nebo po dokončení úlohy) k automatickému zastavení a restartování MySQL server na straně obnovy i na straně záznamu - pro „studené“ načítání dat.

1. Vzhledem k tomu, že zálohy jsou uloženy v čitelném textovém formátu, v případě potřeby použijte nástroje k opravě obnovených souborů – například ke změně mechanismu ukládání dat.

Zakoupení licence

Jak bylo uvedeno výše, synchronizace databáze MySQL nenahrazuje běžné zálohy. Doporučujeme poskytovat úlohy zálohování databáze MySQL pomocí některého z našich podnikově orientovaných softwarových řešení.

• Pokud potřebujete pracovat pouze s jedním serverem MySQL DBMS, Handy Backup Office Expert vám pomůže potřebné schopnosti pro tuto a mnoho dalších funkcí.
• Pokud potřebujete udržovat několik serverů a pracovních stanic, organizovat procesy zálohování databází MySQL a jakýchkoli dalších dat ze společné pracovní stanice, použijte naše vlajkové řešení Handy Backup Server Network.

Chcete-li porovnat ceny těchto a dalších produktů, přejděte na stránku Koupit.

Video tutoriál

Následující video tutoriál ukazuje, jak zálohovat a obnovit databázi MySQL pomocí verze Handy Backup pro Windows. V přítomný okamžik Video je dostupné pouze v angličtině.

Stáhněte si a nainstalujte náš software právě teď – první záložní kopie vašich dat bude připravena během několika minut!

Handy Backup poskytuje spolehlivý, rychlý a vysoce přizpůsobitelný nástroj pro Synchronizace MySQL na úrovni tabulky a databáze. Vyzkoušejte si to nyní stažením zdarma plnou verzi programy na 30 dní!

Pojem databáze. Klasifikace databází (podle formy prezentace informací; podle povahy organizace dat; podle typu použitého modelu; podle typu uložených informací; podle povahy organizace ukládání dat a přístupu k nim).

Databáze(DB) je soubor speciálně uspořádaných dat uložených v paměti počítačového systému a odrážející stav objektů a jejich vztahy v uvažovaném předmětová oblast.

Databáze je systém speciálně organizovaných dat ( databází), softwarové, technické, jazykové, organizační a metodické nástroje určené k zajištění centralizovaného shromažďování a hromadného víceúčelového využití dat. Ve výše uvedené definici BnD je na jedné straně zdůrazněno, že databanka je komplexní systém, který zahrnuje všechny podpůrné subsystémy nezbytné pro fungování jakéhokoli automatizovaného systému zpracování dat. Na druhou stranu tato definice také identifikuje hlavní charakteristické rysy databank:

Databáze jsou obvykle vytvářeny ne za účelem vyřešení jednoho problému pro jednoho uživatele, ale pro víceúčelové použití.

Databáze odrážejí určitou část reálného světa. Musíme usilovat o to, aby všechny informace popisující předmětnou oblast byly jednou zaznamenány v databázi, shromážděny a centrálně aktualizovány a všichni uživatelé, kteří tyto informace potřebují, by s nimi měli být schopni pracovat.

Databáze jsou data organizovaná zvláštním způsobem, tzn. systémy vzájemně propojených dat, jejichž jednota a integrita je podporována speciálním softwarem.

Pro fungování BnD je nutné mít speciální jazyk a software(nazývané DBMS), což uživatelům usnadňuje provádění všech operací souvisejících s organizací ukládání dat, aktualizací a přístupem k nim. Uživatelé BnD.

1.Koncoví uživatelé. Koncoví uživatelé by neměli mít žádné speciální počítačové nebo jazykové znalosti.

2. Zaměstnanci informačních služeb. Využívají především metainformace. Často je žádoucí, aby ostatní informace pro ně byly soukromé.

3. Správci BnD– osoby odpovědné za vytvoření BnD a její spolehlivý provoz, za dodržování předpisů pro přístup k uloženým datům, za rozvoj BnD (správci oborových oblastí, správci databází, správci aplikací).

Klasifikace databáze.

1.Podle formy prezentace informací.Ústřední složkou databanky je databáze a většina klasifikačních prvků se k ní konkrétně vztahuje. Podle formy prezentace informací odlišit vizuální A audio systémy, stejně jako systémy multimédia. Tato klasifikace ukazuje formu, ve které jsou informace uloženy v databázi a předávány z databází uživatelům: ve formě obrázků, zvuku nebo možnosti použití různé formy zobrazit informace. Je zde použit pojem „image“. v širokém slova smyslu– může to být symbolický text, statický grafický obrázek (kresby, kresby atd.), fotografie, zeměpisné mapy, pohyblivé obrázky.

2. Podle povahy organizace dat Databáze lze rozdělit na nestrukturované, polostrukturované A strukturovaný. Tento klasifikační znak odkazuje na informace prezentované v symbolické formě. Nestrukturované databáze mohou zahrnovat databáze organizované ve formuláři sémantické sítě. Databáze lze považovat za částečně strukturované ve formě prostý text nebo hypertextové systémy. Strukturované databáze vyžadují předběžný návrh a popis struktury databáze. Teprve poté lze databáze tohoto typu naplnit daty.

3. Postupně strukturované databáze podle typu použitého modelu se dělí na: hierarchické, síťové, relační, smíšené A vícemodelový.

Klasifikace podle typu modelu platí nejen pro databáze, ale i pro DBMS.

Ve strukturovaných databázích je obvykle několik úrovní informačních jednotek, které jsou vzájemně zahrnuty. Většina strukturovaných systémů podporuje úrovně polí, záznamů a souborů.

Pole odpovídá nejmenší sémantické jednotce informace; soubor polí a/nebo jiných, složitějších informačních jednotek, pokud jsou platné v konkrétní podobě DBMS záznam a sada záznamů stejného typu představuje databázový soubor. V v poslední době Většina DBMS tuto úroveň výslovně podporuje databází, jako kolekce vzájemně propojených databázových souborů.

V hierarchických a síťových modelech lze specifikovat spojení mezi informačními jednotkami (záznamy různých souborů).

Grafickým znázorněním hierarchického modelu je „stromový“ graf. V takovém modelu je jeden vrchol - kořen stromu, který je vstupem do struktury. Každý vrchol kromě kořene může mít pouze jeden zdrojový vrchol a obecně libovolný počet podřízených vrcholů.

Grafickým znázorněním modelu sítě je graf typu „síť“. Vstupem do takové struktury může být jakýkoli vrchol. Každý vrchol může mít několik generovaných a několik zdrojových vrcholů. Mezi párem vrcholů lze deklarovat několik spojení. Naprostá většina DBMS podporuje jednoduché síťové struktury, tj. mezi každou dvojicí typů záznamů je udržován vztah 1:M.

Kromě modelů sítí typu peer-to-peer existují síťové modely s různými typy souborů. V takových modelech se rozlišují hlavní (hlavní) a závislé soubory. Vstup do struktury je možný pouze přes hlavní soubory. Vzájemně lze propojit pouze záznamy různých typů.

Zvláštní místo mezi strukturovanými systémy zaujímají systémy postavené na použití převrácené soubory. Zvláštností organizace dat v nich je, že skutečná uložená data a informace o spojeních jsou od sebe logicky i fyzicky odděleny. Základní data jsou v těchto systémech uložena v souborech, jejichž evidence může mít složitou strukturu. Všechny řídicí informace jsou soustředěny v asociátoru. Logické spojení mezi soubory je vytvořeno prostřednictvím asociační komponenty zvané komunikační síť. Na Obr. Princip navazování spojení v takových systémech je schematicky představen. Ve skutečnosti se spojení nenavazují přímo s komunikačními prvky, jak je znázorněno na obrázku, ale přes převodník adres. V systémech postavených na invertovaných souborech je možné mezi záznamy souborů přenášet vztah M:M (což žádný jiný systém neumožňuje). Oddělení asociativních informací od skutečně uložených dat umožňuje měnit asociace beze změny samotných souborů.

4. Podle typu uložených informací DB se dělí na: dokumentární, faktický A lexikografický. Mezi dokumentární databáze jsou bibliografický, abstrakt A plné znění. Lexikografické databáze zahrnují různé slovníky (klasifikátory, vícejazyčné slovníky, slovníky základních slov atd.).

V systémech faktického typu ukládá databáze informace o objektech zájmu uživatele ve formě „faktů“ (například biografické informace o zaměstnancích, údaje o uvádění produktů na trh výrobci atd.). V reakci na požadavek uživatele jsou uvedeny požadované informace o objektu/objektech, o které má zájem, nebo je zaslána zpráva, že hledaná informace není v databázi.

V dokumentárních databázích je úložnou jednotkou dokument (například text zákona nebo paragrafu) a uživateli je v reakci na jeho žádost poskytnut buď odkaz na dokument, nebo na dokument samotný, ve kterém může najít informace, které ho zajímají.

Databáze typu dokumentů mohou být organizovány různými způsoby: bez ukládání as uložením samotného původního dokumentu na počítačová média. Systémy prvního typu zahrnují bibliografické a abstraktní databáze a také indexové databáze, které „odkazují“ na zdroj informací. Systémy, které poskytují úložiště plného textu dokumentu, se nazývají fulltextové.

5. Podle povaha organizace ukládání dat a přístupu k nim odlišit místní(osobní), generál(integrované, centralizované) a distribuováno databází.

Osobní databáze je databáze určená pro lokální použití jedním uživatelem. Lokální databáze může vytvářet každý uživatel samostatně, nebo je lze získat ze společné databáze.

Integrované a distribuované Databáze implikují možnost současného přístupu několika uživatelů ke stejným informacím (multi-user, paralelní přístup).

Distribuované databáze Navíc mají charakteristické rysy související s tím, že fyzicky různé části databáze mohou být umístěny na různých počítačích, ale logicky musí z pohledu uživatele představovat jeden celek.

Databanka je komplexní systém člověk-stroj a mezi síťové uzly lze distribuovat nejen databázi, ale i další součásti databáze. Navíc samotná databáze nemusí být distribuována (například při poskytování víceuživatelského přístupu k centralizované databázi v síti). Zároveň pod distribuované BnD Budeme rozumět datové bance, ve které je distribuována alespoň jedna její součást.

Rozlišovat extenzivní(EBD) a intenzionální DB. Intenzionální databáze (IDB) je vytvořena pomocí pravidel, která určují její obsah, a nikoli explicitním ukládáním dat do databáze, jako je tomu v extenzivních databázích.

Koncepce systému správy databází (DBMS).

Klasifikace systémů pro správu databází. Klasifikační seskupení týkající se databanky jako celku. Systém správy databáze(DBMS) je sada jazykových a softwarových nástrojů určených pro vytváření, údržbu a sdílení databáze s mnoha uživateli. Typicky se DBMS liší použitým datovým modelem. Tedy, DBMS na základě využití relační model

data se nazývají relační DBMS. Podle jazyků komunikace DBMS se dělí na,OTEVŘENO ZAVŘENO A.

smíšený Otevřené systémy jsou systémy, ve kterých se pro přístup k databázi používají univerzální programovací jazyky. Uzavřené systémy mají vlastní jazyky

komunikace s uživateli BnD. Podle počtu úrovní

V architektuře se rozlišují jednoúrovňové, dvouúrovňové a tříúrovňové systémy.

Architektonická úroveň DBMS je chápána jako funkční komponent, jehož mechanismy slouží k podpoře určité úrovně abstrakce dat (logická a fyzická úroveň, stejně jako uživatelský „pohled“ - externí úroveň).

Číslování úrovní na obrázku je libovolné, nicméně odráží jejich význam (interní model lze sestavit pouze na základě konceptuálního; tyto dvě úrovně lze kombinovat, ale vždy jsou podporovány DBMS; vnější v architektuře DBMS nemusí chybět). Podle jazyků komunikace Podle vykonávaných funkcí ZAVŘENO informační operační sály

. Informační DBMS vám umožňují organizovat ukládání informací a přístup k nim. Pro provedení složitějšího zpracování je nutné napsat speciální programy. Provozní DBMS provádějí poměrně složité zpracování, například automaticky umožňují získat agregované indikátory, které nejsou uloženy přímo v databázi, mohou měnit algoritmy zpracování atd. Podle rozsahu možné aplikace odlišit ZAVŘENO univerzální specializované

, obvykle problémově orientované DBMS. Podle jazyků komunikace Podle "moci" ZAVŘENO "desktop""firemní"

. Charakteristickými rysy desktopových DBMS jsou relativně nízké nároky na technické prostředky, zaměření na koncového uživatele a nízká cena.

Firemní DBMS poskytují práci v distribuovaném prostředí, vysoký výkon, podporu týmové práce při navrhování systémů, mají vyvinuté nástroje pro správu a větší možnosti pro zachování integrity. Nejznámější podnikové DBMS jsou Oracle, Informix, Sybase, MS SQL Server

, Progress a některé další.

1. generace – na základě hierarchického a síťového modelu.

2. generace – Relační systémy.

3. generace – DBMS musí podporovat složité datové struktury a rozvinutější prostředky k zajištění integrity dat a splňovat požadavky na otevřené systémy.

Klasifikační seskupení vztahující se k BnD jako celku.

Podle podmínek služby Podle rozsahu možné aplikace uvolnit ZAVŘENO zaplaceno datové banky. Placené BnD se zase dělí na neziskové ZAVŘENO komerční. Neziskové databanky fungují na principu soběstačnosti a jejich cílem není zisk.

Hlavním účelem vytváření komerčních databank je zisk z informační činnosti.

Systémy OLTP a OLAP: srovnávací charakteristiky.

Informační systémy se liší podle povahy převládajícího zpracování informací. Některé implementují hlavně velké množství poměrně jednoduchých dotazů (takové systémy se nazývají OLTP (On-Line Transaction Processing) - online systémy pro zpracování transakcí. V jiných je naopak vyžadováno složité analytické zpracování dat (pro tuto třídu systémů se začal používat termín OLAP (On-line Analytical Processing). Termín OLAP

často ztotožňován s podporou rozhodování (DSS (Decision Support Systems) - systémy pro podporu rozhodování). A jako synonymum pro poslední termín používají Data Warehousing - datové sklady (sklady), tedy soubor organizačních řešení, softwaru a hardwaru pro poskytování informací analytikům na základě dat ze systémů pro zpracování transakcí. nižší úroveň a další zdroje.

„OLAP v užším slova smyslu“ jsou systémy, které poskytují pouze výběr dat v různých sekcích, a „OLAP v širším smyslu“ nebo jednoduše OLAP, který zahrnuje:

podpora editace databáze více uživateli;

funkce modelování, včetně výpočetních mechanismů pro získávání odvozených výsledků, jakož i agregace a kombinování dat;

prognózování, identifikace trendů a statistická analýza.

Datové sklady lze rozdělit na dva typy: podnikové datové sklady a datové tržiště. Podnikové datové sklady obsahují informace, které pokrývají celou společnost a jsou agregovány z více provozních zdrojů pro konsolidovanou analýzu. Datové tržiště obsahují podmnožinu podnikových dat a jsou vytvořeny pro oddělení nebo divize v rámci organizace. Datové tržiště si často buduje oddělení samo a pokrývají specifický aspekt zájmu zaměstnanců oddělení.

Srovnávací charakteristiky systémů OLTP a OLAP:

Charakteristický
Převládající operace	Zadávání dat, vyhledávání	Analýza dat
Povaha požadavků	Spousta jednoduchých transakcí	Komplexní transakce
Uložená data	Provozní, detailní	Pokrývající velké časové období, agregované
Typ činnosti	Operační, taktické	Analytické, strategické
Typ dat	Strukturovaný	Různé typy

Relační datový model: základní pojmy. Hlavní typy vazeb mezi vztahy a jejich charakteristiky.

Relační model data (RMD) určité předmětné oblasti jsou souborem vztahů, které se v čase mění. Sada vztahů umožňuje při vytváření informačního systému ukládat data o objektech předmětné oblasti a modelovat vazby mezi nimi.

Prvek relačního modelu	Prezentační formulář
Postoj
Vztahový diagram	Řádek záhlaví sloupce tabulky (záhlaví tabulky)
	Řádek tabulky
Esence	Popis vlastností objektu
	Záhlaví sloupce tabulky
	Mnoho přijatelné hodnoty atribut
Hodnota atributu	Hodnota pole v záznamu
Primární klíč	Jeden nebo více atributů
Typ dat	Typ hodnoty prvku tabulky

Postoj je základní koncept a je to dvourozměrná tabulka obsahující některá data.

Esence Existuje objekt jakékoli povahy, o kterém jsou data uložena v databázi. Data entity jsou uložena ve vztahu.

Atributy představují vlastnosti, které charakterizují entitu. Ve struktuře tabulky je každý atribut pojmenován a odpovídá záhlaví určitého sloupce tabulky.

Matematicky lze vztah popsat následovně. Nechť je dáno n množin D1, D2, D3,..., Dn, pak relace R je množina uspořádaných n-tice, kde dk Dk, dk – atribut, Dk - doména vztah R.

Rýže. Reprezentace vztahu ZAMĚSTNANCE

Doména představuje množinu všech možných hodnot pro konkrétní atribut vztahu. Vztah EMPLOYEE K zahrnuje 4 domény. doména 1 obsahuje jména všech zaměstnanců, doména 2- čísla všech oddělení společnosti, doména 3- názvy všech pozic, doména 4 – data narození všech zaměstnanců. Každá doména vytváří hodnoty jednoho datového typu, například číselné nebo znakové.

Vztah ZAMĚSTNANEC obsahuje 3 n-tice. N-tice příslušného vztahu se skládá ze 4 prvků, z nichž každý je vybrán z odpovídající domény. Každá n-tice odpovídá řádku tabulky.

Schéma vztahu (záhlaví vztahu) je seznam názvů atributů. Například pro uvedený příklad má vztahový diagram tvar ZAMĚSTNANEC (Jméno, Oddělení, Pozice, D_Narození). Často se nazývá množina správných n-tic relace obsah (tělo) vztah.

Primární klíč (klíč vztahu, klíč atributu) je atribut relace, který jednoznačně identifikuje každou z jeho n-tic. Například ve vztahu k ZAMĚSTNANCE (celé jméno, oddělení, pozice, datum narození) je klíčovým atributem „celé jméno“. Klíč Může být složený (komplex), to znamená, že se skládá z několika atributů. Mohou nastat případy, kdy má relace několik kombinací atributů, z nichž každá jednoznačně identifikuje všechny n-tice vztahu. Všechny tyto kombinace atributů jsou možné klíče vztah. Jakýkoli z možných klíčů lze vybrat jako primární.

Pokud se vybraný primární klíč skládá z minimální požadované sady atributů, říká se, že je není nadbytečný .

Klíče se obvykle používají k dosažení následujících účelů:

1) odstranění duplikace hodnot v klíčových atributech;

2) řazení n-tic;

3) urychlení práce s relačními n-ticemi;

4)organizace propojovacích tabulek.

Nechť platí vztah R1 ne klíč atribut A, jehož hodnoty jsou hodnotami klíč atribut B jiného vztahu R2. Pak říkají, že atribut A vztahu R1 je cizí klíč .

Cizí klíče se používají k navázání spojení mezi vztahy. Například existují dva vztahy STUDENT (Jméno, Skupina, Odbornost) a PŘEDMĚT (Jméno Pr., Hodiny), které jsou spojeny vztahem STUDENT_ PŘEDMĚT (Jméno, Jméno Pr., Známka) (obr.). V propojovacím vztahu tvoří atributy Full Name a Name of Pr. Tyto atributy představují cizí klíče, které jsou primárními klíči jiných vztahů.

Rýže. Vztahové spojení

Podmínky, jejichž splnění umožňuje považovat tabulku za vztah.

1. Všechny řádky tabulky musí být jedinečné, to znamená, že zde nemohou být řádky se stejnými primárními klíči.

2. Názvy sloupců tabulky se musí lišit a jejich hodnoty musí být jednoduché, to znamená, že skupina hodnot v jednom sloupci jednoho řádku není povolena.

3. Všechny řádky jedné tabulky musí mít stejnou strukturu, odpovídající názvům a typům sloupců.

4. Pořadí řádků v tabulce může být libovolné. Nejčastěji je tabulka se vztahem umístěna v samostatném souboru.

Pokud má vztah určený tabulkou klíč, pak se má za to, že tabulka má také klíč a je volána klíč nebo tabulka s klíčovými poli.

Hlavní typy vazeb mezi vztahy a jejich charakteristiky. Mezi tabulkami lze vytvořit binární (mezi dvěma tabulkami), ternární (mezi třemi tabulkami) a obecně n-ární vztahy. Podívejme se na ty nejčastější binární komunikace.

Při propojení dvou tabulek se rozlišuje hlavní a doplňková (podřízená) tabulka. Logické propojení tabulek se provádí pomocí komunikační klíč . Klíč odkazu se skládá z jednoho nebo více polí, která se v tomto případě nazývají komunikační pole (PS).

Podstatou propojení je vytvoření korespondence mezi spojovacími poli hlavní a doplňkové tabulky. Pole vztahů hlavní tabulky mohou být běžná nebo klíčová. Klíčová pole se nejčastěji používají jako spojovací pole podřízené tabulky.

V závislosti na tom, jak jsou definována pole připojení hlavní a doplňkové tabulky (jak klíčová pole souvisí s poli připojení), lze obecně mezi dvěma tabulkami (tabulkou) vytvořit následující čtyři hlavní typy připojení:

jeden – jeden (1:1);

jeden – mnoho (1:M);

mnoho – jeden (M:1);

hodně - hodně (M:M nebo M:N).

Tabulka Charakteristika typů tabulkových vztahů

Vztah 1:1. Vztah 1:1 se vytvoří, když jsou klíčová všechna pole vztahu mezi hlavní a doplňkovou tabulkou. Protože se hodnoty v klíčových polích obou tabulek neopakují, existuje mezi záznamy z těchto tabulek vzájemná korespondence. Samotné tabulky se zde ve skutečnosti stávají rovnocennými.

Typ komunikace 1:M. Vztah 1:M nastane, když jeden záznam hlavní tabulky odpovídá několika záznamům pomocné tabulky.

Typ komunikace M:1. Ke vztahu M:1 dochází, když je jeden nebo více záznamů hlavní tabulky spojeno s jedním záznamem doplňkové tabulky.

Typ komunikace M: M. Nejběžnější typ vztahu M:M se vyskytuje v případech, kdy několik záznamů hlavní tabulky odpovídá několika záznamům doplňkové tabulky.

Komentář . V praxi vztah obvykle zahrnuje několik tabulek najednou. V tomto případě může mít jedna z tabulek různé druhy spojení s několika tabulkami. V případech, kdy související tabulky mají naopak vztahy s jinými tabulkami, je vytvořena hierarchie nebo strom vztahů.

Množinové a speciální operace relační algebra.

Algebra je množina objektů se sadou operací specifikovaných na ní, které jsou s ohledem na tuto množinu uzavřené, tzv hlavní sada.

Hlavní množinou v relační algebře je množina relací. Celý soubor operací lze rozdělit do dvou skupin: operace množinově teoretické a operace speciální. První skupina zahrnuje 4 operace. První tři operace teorie množin jsou binární, to znamená, že zahrnují dvě relace a vyžadují ekvivalentní obvody původních relací.

Sdružení dvě relace je relace obsahující množinu n-tic patřících buď do první nebo druhé původní relace, nebo do obou relací současně.

Nechť jsou dány dvě relace R 1 = ( r 1 ), R 2 = ( r 2 ), kde r 1 a r 2 jsou n-tice vztahů R 1 a R 2 , pak sjednocení R 1 R 2 = ( r | r R1Vr R2). Zde r je n-tice nového vztahu, V je operace logického sčítání „OR“.

Křížením

R 3 = R 1 R 2 = ( r | r R 1 ^ r R 2 ), zde ^ je operace logického násobení (logické „AND“).

Rozdílem

Křížením relace je relace, která obsahuje množinu n-tic, které současně patří do první i druhé relace R 1 a R 2:

R 3 = R 1 R 2 = ( r | r R 1 ^ r R 2 ), zde ^ je operace logického násobení („AND“).

Rozdílem relace R 1 a R 2 je relace obsahující množinu n-tic patřících do R 1 a nepatřících do R 2:

R 5 = R 1 \ R 2 = ( r | r R 1 ^ r R 2 )

Spojka nebo zřetězení, n-tice s = a q = .., q m > je n-tice získaná přičtením hodnot druhého na konec prvního. Vazba mezi c a q je označena jako (c, q).

(c, q) =<с 1 с 2 , ... , с n , q 1 , q 2 , .... q m >

Zde n je počet prvků v první n-tice c, m je počet prvků v druhé n-tice q.

Všechny předchozí operace nezměnily stupeň ani aritu relací - to vyplývá z definice ekvivalence relačních schémat. Operace kartézského součinu mění stupeň výsledného vztahu.

Rozšířený kartézský součin vztahy R, stupeň n s obvodem S R1 =(A 1,A 2 ...,A n) a vztahy R 2 stupně m s obvodem S R2 =(B 1,B 2,...,B m) je nazýván vztah R 3. stupeň n+m s obvodem

S R3 = (A 1, A 2, ..., A n, B 1, B 2, ..., B m), obsahující n-tice získané zřetězením každé n-tice r vztahu R 1 s každou n-tice q vztah R2.

To znamená, že pokud R1 = (r), R2 = (q)

R1R2 = ((r, q) | rR1^ qR2).

Speciální operace relační algebry.

První speciální operací relační algebry je horizontální výběr, nebo filtrační provoz, nebo operace omezení vztahu.

Nechť a je booleovský výraz složený ze srovnávacích výrazů pomocí spojovacích výrazů AND (^), OR (V), NOT (–) a případně závorek. Jako srovnávací výrazy jsou povoleny následující:

a) výraz A os a, kde A je název nějakého atributu, který přebírá hodnoty z domény D; a je konstanta převzatá ze stejné domény D, a D; oc – jedna z porovnávacích operací povolených pro danou doménu D;

b) výraz A os B, kde A, B jsou názvy některých Q-srovnatelných atributů, tedy atributů, které nabývají hodnot ze stejné domény D.

Pak výsledkem operace výběru nebo filtrování specifikované na relaci R ve formě booleovského výrazu definovaného na atributech relace R je relace R[G], která zahrnuje ty n-tice z původní relace, pro které výběr, resp. podmínka filtrování je pravdivá:

R = (r | r R ^ G(r) = "Pravda")

Další speciální operace je projektový provoz. Nechť R je relace, S R = (A 1 , ... , A n) je schéma relace R. Označme B podmnožinu [ Аi]; B ( Ai ) Navíc nechť B 1 je množina atributů z ( Ai ) nezahrnutých v B. Jestliže B = (A 1 j.A 2 j .....A k j), B 1 = (A 1 j,A 2 j,...,A k j) a r =<а 1 j, а 2 j,...,а k j >, a k j Á k ji, pak r [B], s=< a 1 j, а 2 j, ... , а m , >; а m, А m j

Projekce relace R na množinu atributů B, označovaná R[B], je relací se schématem odpovídajícím množině atributů B S R | B | = B, obsahující n-tice získané z n-tic původního vztahu R odstraněním hodnot, které nepatří do atributů z množiny B.

Podle definice relací jsou z výsledné relace odstraněny všechny duplicitní n-tice.

Operace návrhu, někdy také nazývaná operace vertikálního výběru, umožňuje získat pouze požadované vlastnosti modelovaného objektu. Nejčastěji se operace návrhu používá jako mezikrok v operacích horizontálního výběru nebo filtrování. Používá se nezávisle v konečné fázi přijetí odpovědi na požadavek.

Další speciální operací relační algebry je operace podmíněné připojení.

Na rozdíl od uvažovaných speciálních operací relační algebry: filtrování a projekce, které jsou unární, to znamená, že se provádějí na jedné relaci, operace podmíněného spojení je binární, to znamená, že jejím zdrojem jsou dvě relace a výsledkem je jedna .

Nechť R = (r), Q = (q) – počáteční vztahy, S R, S Q – schémata relací R a Q.

S R = (A 1, A 2, ..., A k): S Q = (B 1 B 2, ..., B m), kde A, B jsou názvy atributů ve schématech vztahů R a Q , resp. V tomto případě předpokládáme, že jsou dány množiny atributů A a B

A (Ai), j=l,k; V ( B j ) j=1,m a tyto množiny se skládají z Q-srovnatelných atributů.

Pak spojení relací R a Q za podmínky p bude podmnožinou kartézského součinu relací R a Q, jejichž n-tice splňují podmínku p, považované za současné splnění podmínky:

r.A j Q j В i , : i=l,k, kde k je počet atributů obsažených v množinách A a B a Qj je specifická porovnávací operace.

A j Q j B i D i Qi je i-tý srovnávací predikát, určený ze sady srovnávacích operací povolených na doméně D i.

R[P]Q = (r.q) | (r.q) | r.A Q j q.B j - “Pravda”, i=l,k)

Poslední operací zahrnutou do množiny operací relační algebry je operace divize.

Abychom mohli definovat operaci dělení, nejprve zvážíme koncept množiny obrázků.

Nechť R je relace se schématem S R = (A1, A 2 ,..., Ak);

Nechť A je určitá množina atributů A ( A i ) i=l,k , A 1 je množina atributů nezahrnutých do množiny A.

Průsečík množin A a A 1 je prázdný: A A 1 = 0; sjednocení množin je rovno množině všech atributů původního vztahu: A A 1 = S R .

Pak množina obrazů prvku v projekci R[A] je množina takových prvků v projekci R, pro které jsou zřetězení (x, y) n-tice vztahu R, tzn.

QA(x) = (y | y R ^ (x, y) R) – sada obrázků.

Nyní definujeme operaci divize. Nechť jsou dány dva vztahy R a T s diagramy: S R = (A 1, A 2, ..., Ak); ST =-(B1, B2, ..., Bm);

A a B – množiny atributů těchto relací, stejné délky (bez opakování);

A SR; V S T. Atributy A 1 jsou atributy z R, které nejsou zahrnuty v množině A.

Průsečík množin A A 1 = je prázdný a A A 1 = S R . Projekce R[A] a T[B] jsou kompatibilní asociací, to znamená, že mají ekvivalentní obvody: S R | A |~ S T [B].

Poté operace dělení spojí vztahy R a T se vztahem

Q = RT, jehož n-tice jsou ty prvky projekce R, pro které je T[B] zahrnuto v množině obrázků pro ně zkonstruovaných:

RT = (r | r R^ T[B] (y | yR [A]^ (r, y) R)).

Operace dělení je vhodná, když potřebujete porovnat určitý soubor charakteristik jednotlivých atributů.

Různé architektonická řešení, používaný při implementaci víceuživatelského DBMS. Centralizovaná architektura.

Koncept databáze původně předpokládal schopnost řešit mnoho problémů několika uživateli. Nejdůležitější charakteristika moderní DBMS je přítomnost technologie pro více uživatelů. Různé implementace takových technologií v různých dobách byly spojeny jak se základními vlastnostmi výpočetní techniky, tak s vývojem softwaru.

Centralizovaná architektura. Při použití této technologie jsou databáze, DBMS a aplikační program (aplikace) umístěny na jednom počítači (sálovém počítači nebo osobním počítači) (obr. 1). Tento způsob organizace nevyžaduje síťovou podporu a vše závisí na autonomním provozu. Práce je strukturována takto:

Databáze ve formě sady souborů je umístěna na pevném disku počítače.

DBMS a aplikace pro práci s databází jsou nainstalovány na stejném počítači.

Uživatel spustí aplikaci. Pomocí uživatelského rozhraní poskytovaného aplikací zahájí volání do databáze za účelem získání/aktualizace informací.

Všechna volání do databáze procházejí přes DBMS, která v sobě zapouzdří všechny informace o fyzické struktuře databáze.

DBMS iniciuje přístup k datům a zajišťuje plnění požadavků uživatelů.

Rýže. 1. Centralizovaná architektura

Podobná architektura byla použita v prvních verzích DB2 a Oracle. Hlavní nevýhodou tohoto modelu je, že výkon prudce klesá s rostoucím počtem uživatelů.

Technologie se sítí a souborový server(architektura souborového serveru). Technologie klient-server. Třívrstvá (vícevrstvá) architektura klient-server.

Rostoucí složitost úloh, vznik osobních počítačů a lokálních sítí byly předpoklady pro vznik nové architektury souborový server. Tato databázová architektura s přístup k síti zahrnuje přiřazení jednoho ze síťových počítačů jako vyhrazeného serveru, na kterém budou uloženy databázové soubory. Podle požadavků uživatelů soubory s souborový server jsou přenášeny na uživatelská pracovní stanice, kde probíhá převážná část zpracování dat. Centrální server plní převážně pouze roli úložiště souborů, aniž by se podílel na samotném zpracování dat (obr. 2.).

Rýže. 2. Architektura souborového serveru.

Práce je strukturována takto:

Databáze ve formě sady souborů je umístěna na pevném disku speciálně vyhrazeného počítače (souborového serveru).

Je zde lokální síť tvořená klientskými počítači, z nichž každý má nainstalovanou DBMS a aplikaci pro práci s databází.

Na každém z klientských počítačů mají uživatelé možnost spouštět aplikaci. Pomocí uživatelského rozhraní poskytovaného aplikací zahájí volání do databáze za účelem získání/aktualizace informací.

Všechna volání do databáze procházejí přes DBMS, která v sobě zapouzdří veškeré informace o fyzické struktuře databáze umístěné na souborovém serveru.

DBMS iniciuje volání dat umístěných na souborovém serveru, v důsledku čehož je část databázových souborů zkopírována na klientský počítač a zpracována, což zajišťuje splnění požadavků uživatelů (provádějí se nezbytné operace s daty).

V případě potřeby jsou data odeslána zpět na souborový server k aktualizaci databáze.

DBMS vrátí výsledek aplikaci.

Aplikace pomocí uživatelského rozhraní zobrazí výsledek dotazů.

V rámci architektury" souborový server"Byly dokončeny první verze populárních takzvaných desktopových DBMS, jako jsou dBase a Microsoft Access. Hlavní nevýhody této architektury:

Když mnoho uživatelů současně přistupuje ke stejným datům, výkon prudce klesá.

Prostředky klientského počítače a sítě nejsou využívány optimálně. V důsledku toho se zvyšuje síťový provoz a zvyšují se požadavky na hardwarovou kapacitu počítače uživatele.

Je použit navigační přístup zaměřený na práci s jednotlivými záznamy.

Nízká úroveň zabezpečení – krádež a poškození, provádění chybných změn.

Nedostatečně vyvinutý transakční aparát slouží jako zdroj chyb ve smyslu narušení sémantické a referenční integrity informace při současném zavádění změn.

Technologie klient-server. Použití technologie" klient - server" předpokládá přítomnost určitého počtu počítačů připojených k síti, z nichž jeden vykonává speciální řídicí funkce (je síťový server).

Architektura" klient - server"odděluje funkce uživatelské aplikace (klienta) a serveru. Klientská aplikace vygeneruje požadavek na server, na kterém je databáze umístěna, ve strukturním dotazovacím jazyce SQL. Vzdálený server přijme požadavek a předá jej SQL server databáze SQL server je speciální program, který řídí vzdálenou databázi SQL server provede dotaz v databázi, vygeneruje výsledek dotazu a odešle jej klientský počítač pouze na server databázi a obdrží výsledek, poté jej potřebným způsobem interpretuje a předloží uživateli Výsledek požadavku je odeslán do klientské aplikace, sítí tak putují pouze data, která klient potřebuje. Sníží se zatížení sítě Vzhledem k tomu, že požadavek probíhá na stejném místě, kde jsou data uložena (na serveru), není potřeba odesílat velké datové pakety SQL server optimalizuje přijatý dotaz tak, aby byl proveden v minimálním čase s nejmenší režií. Architektura systému je znázorněna na obr. 3.

To vše zvyšuje výkon systému a zkracuje dobu čekání na výsledek požadavku. Když jsou dotazy prováděny serverem, stupeň zabezpečení dat se výrazně zvyšuje, protože pravidla integrity dat jsou definována v databázi na serveru a jsou stejná pro všechny aplikace, které tuto databázi používají. To eliminuje možnost definování konfliktních pravidel pro zachování integrity.

Rýže. 3. Architektura klient-server.

Databáze ve formě sady souborů je umístěna na pevném disku speciálně vyhrazeného počítače (síťový server).

Existuje lokální síť složená z klientských počítačů, z nichž každý má nainstalovanou klientskou aplikaci pro práci s databází.

Na každém z klientských počítačů mají uživatelé možnost spouštět aplikaci. Pomocí uživatelského rozhraní poskytovaného aplikací zahájí volání do DBMS umístěného na serveru za účelem získání/aktualizace informací. Pro komunikaci se používá speciální dotazovací jazyk SQL, tzn. Z klienta na server je po síti přenášen pouze text požadavku.

DBMS v sobě zapouzdřuje veškeré informace o fyzické struktuře databáze umístěné na serveru.

DBMS iniciuje volání dat umístěných na serveru, v důsledku čehož veškeré zpracování dat probíhá na serveru a pouze výsledek požadavku je zkopírován do klientského počítače. DBMS tedy vrátí výsledek aplikaci.

Aplikace pomocí uživatelského rozhraní zobrazí výsledek dotazů.

Funkce klientské aplikace: odesílání požadavků; výklad žádostí; prezentace výsledků.

Funkce části serveru: příjem požadavků; zajištění bezpečnostního systému a kontroly vstupu; správa integrity databáze; implementace stability víceuživatelského provozního režimu.

V architektuře" klient - server„Fungují takzvané „industriální“ DBMS Říká se jim průmyslové, protože právě DBMS této třídy dokážou zajistit provoz informačních systémů v měřítku středního a velkého podniku, organizace, banky (MS SQL Server, Oracle. , InterBase atd.).

SQL server spravuje jednotlivý zaměstnanec nebo skupina zaměstnanců. Spravují fyzické vlastnosti databáze, optimalizují, konfigurují a předefinují různé databázové komponenty, vytvářejí nové databáze, upravují stávající atd.

Podívejme se na hlavní výhody této architektury ve srovnání s architekturou souborového serveru:

Síťový provoz je výrazně snížen.

Snižuje se složitost klientských aplikací (většina zátěže připadá na serverovou část) a následně se snižují požadavky na hardwarovou kapacitu klientských počítačů.

Přítomnost speciálního softwarového nástroje - SQL serveru - vede k tomu, že značná část návrhových a programovacích úloh je již vyřešena.

Integrita a bezpečnost databáze je výrazně zvýšena.

Mezi nevýhody patří vyšší finanční náklady na hardware a software a také určité potíže s včasnou aktualizací klientských aplikací na všech klientských počítačích.

Třívrstvá (vícevrstvá) architektura klient-server.Tříčlánkový(v některých případech multi-link)architektura představuje další zdokonalení technologie" klient - server". Po zvážení architektury" klient - server", můžeme dojít k závěru, že se jedná o 2-vrstvý systém: první odkaz je klientská aplikace, druhý odkaz je databázový server + samotná databáze. B třívrstvá architektura veškerá obchodní logika (obchodní logika), dříve zahrnutá v klientských aplikacích, je oddělena do samostatné jednotky zvané aplikační server. Klientským aplikacím v tomto případě zůstane pouze uživatelské rozhraní. Ve výše popsaném příkladu tedy webový prohlížeč funguje jako klientská aplikace Nyní, když se změní obchodní logika, již není potřeba měnit klientské aplikace a aktualizovat je pro všechny uživatele. Navíc jsou maximálně sníženy požadavky na uživatelské vybavení.

V důsledku toho je práce strukturována takto:

Databáze ve formě sady souborů je uložena na pevném disku speciálně vyhrazeného počítače (síťový server).

DBMS je také umístěn na síťovém serveru.

Existuje speciálně vyhrazený aplikační server, na kterém je umístěn software pro obchodní analýzu (obchodní logika).

Existuje mnoho klientských počítačů, z nichž každý má tzv. tenký klient" je klientská aplikace, která implementuje uživatelské rozhraní.

Na každém z klientských počítačů mají uživatelé možnost spustit aplikaci – tenkého klienta. Pomocí uživatelského rozhraní poskytovaného aplikací zahájí volání softwaru business intelligence umístěného na aplikačním serveru.

Aplikační server analyzuje požadavky uživatelů a generuje dotazy do databáze. Používá se pro komunikaci speciální jazyk SQL dotazy, tzn. Z aplikačního serveru do databázového serveru se po síti přenáší pouze text požadavku.

DBMS v sobě zapouzdřuje veškeré informace o fyzické struktuře databáze.

DBMS iniciuje volání dat umístěných na serveru, v důsledku čehož je výsledek dotazu zkopírován na aplikační server.

Aplikační server vrátí výsledek klientské aplikaci (uživateli).

Aplikace pomocí uživatelského rozhraní zobrazí výsledek dotazů.

Koncept integrity databáze. Logická a fyzická integrita databáze. Klasifikace integritních omezení.

Zajištění integrity dat je nejdůležitějším úkolem při návrhu a provozu systémů zpracování dat (DPS). Problémem integrity je zajistit... že data v databázi jsou vždy správná.“ Integrita – relevance a konzistence informací, jejich ochrana před zničením a neoprávněnými změnami.

Integrita je jedním z aspektů informační bezpečnosti spolu s dostupností – schopností získat požadovanou informační službu za přijatelnou cenu, a důvěrností – ochranou před neoprávněným čtením.

Integrita dat je nedílnou vlastností databáze a její zajištění je nejdůležitějším úkolem při návrhu BnD. Integrita dat je popsána sadou speciálních klauzulí nazývaných omezení integrity. Omezení integrity jsou prohlášení o přijatelných hodnotách jednotlivých informačních jednotek a vztazích mezi nimi. Tato omezení jsou ve většině případů dána charakteristikou předmětné oblasti. Při provádění operací s databází se kontroluje splnění omezení integrity. Omezení integrity lze klasifikovat podle různá znamení(rýže.).

Logická integrita – stav databáze, charakterizovaný absencí porušení omezení integrity, která jsou vlastní logickému datovému modelu (tj. implicitní omezení), a explicitních omezení specifikovaných deklarativně nebo procedurálně. Fyzická integrita – absence porušení specifikací schématu úložiště a fyzické zničení dat na médiu.

Ke kontrole integrity databáze se také používá spouštěcí mechanismus. Spoušť– jedná se o akci, která se aktivuje při výskytu zadané události (vložení, smazání, aktualizace záznamu). Spouštěče jsou specifikovány ve schématu databáze. Širší pojem ve vztahu k spoušť je koncept uložená procedura. Uložené procedury popisují části aplikační logiky, jsou uloženy a spouštěny na serveru, což umožňuje lepší výkonnostní charakteristiky.

Integrita dat je nedílnou vlastností databáze a její poskytování je nejdůležitějším úkolem návrhu databáze. Integrita dat je popsána sadou speciálních klauzulí nazývaných omezení integrity. Omezení integrity jsou prohlášení o přijatelných hodnotách jednotlivých informačních jednotek a vztazích mezi nimi. Tato omezení jsou ve většině případů dána charakteristikou předmětné oblasti. Při provádění operací s databází se kontroluje splnění omezení integrity. Omezení integrity lze klasifikovat podle různých kritérií (obr. níže).

Existují logické a fyzická integrita DB. Logická integrita– stav databáze, charakterizovaný absencí porušení omezení integrity, která jsou vlastní logickému datovému modelu (tj. implicitní omezení), a explicitních omezení specifikovaných deklarativně nebo procedurálně. Fyzická integrita– absence porušení specifikací schématu ukládání a fyzické zničení dat na médiu.

9. Problém integrity databáze. Transakce a zámky. Synchronizace uživatelské práce.

Integrita je jedním z aspektů informační bezpečnosti spolu s dostupností – schopností získat požadovanou informační službu za přijatelnou cenu, a důvěrností – ochranou před neoprávněným čtením.

Zajištění integrity dat je nejdůležitějším úkolem při návrhu a provozu systémů zpracování dat (DPS). Problémem integrity je zajistit, aby data v databázi byla vždy správná.“ Integrita – relevance a konzistence informací, jejich ochrana před zničením a neoprávněnými změnami.

Používá se také ke sledování integrity databáze. spoušťový mechanismus. Spoušť– jedná se o akci, která se aktivuje při výskytu zadané události (vložení, smazání, aktualizace záznamu). Spouštěče jsou specifikovány ve schématu databáze. Širším pojmem ve vztahu ke spouštěči je pojem uložená procedura. Uložené procedury popisují části aplikační logiky, jsou uloženy a spouštěny na serveru, což umožňuje lepší výkonnostní charakteristiky.

Transakce. Transakce je kompletní sada akcí v databázi, která ji přenáší z jednoho stavu, který je v logickém smyslu integrální, do jiného. Transakce podléhají souboru požadavků známých jako ACID (Atomicity, Consistency, Isolation, Durability). Tyto požadavky vyplývají z definice transakce.

Atomicita. Transakce je určitý soubor dokončených akcí.

Systém zajišťuje jejich provedení na principu „všechno nebo nic“ – buď jsou provedeny všechny akce, pak je transakce „opravena“; nebo pokud není možné provést všechny akce, například v případě selhání, je transakce „vrácena zpět“ a databáze zůstává v původním stavu.

Konzistence. Předpokládá se, že v důsledku transakce se systém přesune z jednoho správného stavu do druhého.

Izolace. Během transakce mohou být data dočasně v nekonzistentním stavu. Tato data by neměla být viditelná pro jiné transakce, dokud nebudou změny dokončeny (tj. dokud nebude formálně potvrzena váha modifikace).

Trvanlivost. Jakmile je transakce potvrzena, její výsledky musí být trvalé. Nejpopulárnější algoritmy řízení souběžnosti jsou založeny na zamykacím mechanismu. Blokování je zákaz určitých operací s údaji, pokud je zpracovává jiný uživatel. V tomto návrhu, kdykoli se transakce pokusí o přístup k jakékoli jednotce dat, je na tuto jednotku umístěn zámek.

Zámky se používají v souladu s pravidly kompatibility zámků, která zabraňují konfliktům číst-psát, zapisovat-číst A záznam-záznam.

Serializovatelnost transakcí je zaručena, pokud zámky na souběžně prováděné transakce splňují následující pravidlo: „Žádný zámek jménem žádné transakce nelze získat, dokud nebude dříve uvolněn. nastavit zámek" Toto pravidlo je známé jako dvoufázové blokování , protože transakce nejprve prochází fází růst, když nastaví zámky, a poté fázi komprese, když se zámky uvolní. Blokování lze provést automaticky a možná ovládané uživatelem.

V závislosti na blokovaných informačních jednotkách lze rozlišit následující: úrovně blokování : databáze, kolekce souvisejících tabulek, tabulka, kolekce souvisejících záznamů, záznam, pole. Blokujícími objekty může být stránka, skupina stránek nebo oblast databáze.

Některé systémy poskytují dynamický schéma blokování, ve kterém transakce nejprve zablokuje velkou část informace, jako je stránka.

Rozlišovat pesimistický Aoptimistický blokování. Pesimistické zámky zabraňují přístupu k datům jiných transakcí, když už na nich nějaká transakce pracuje. Optimistické zámky umožňují souběžné transakce, monitorují konflikty a řeší je.

Synchronizace uživatelské práce.Replikace – technologie používaná v DDB (distribuovaná databáze), která poskytuje podporu pro kopie celé databáze nebo jejích částí v několika síťových uzlech. Kopie databáze, která je členem sady dalších kopií, které lze vzájemně synchronizovat, se nazývá replika. Kopie databáze jsou obvykle blízko míst, kde se informace používají. Termín „replikace“ se používá jako synonymum pro pojem „replikace“. Proces aktualizace replik, během kterého se přenášejí aktualizované záznamy a další objekty a slučují se duplicitní data, se nazývásynchronizace . Výměna dat mezi replikami může být jednosměrná nebo obousměrná. Navíc je možné repliky synchronizovat pod kontrolou synchronizátoru. Na rozdíl od skutečně distribuovaných systémů, ve kterých je při provádění distribuovaných požadavků implementován protokol dvoufázová fixace Systémy s replikovanými databázemi obvykle používají asynchronní replikační nástroje.

V současné době mnoho známých DBMS nabízí uživatelům replikační schopnosti. Některé systémy využívají metafory z publikování (vydavatel, publikace, předplatitel). Kolekce dat, která lze replikovat, se nazývá vydání.