Všechny výše uvedené nevýhody schématu soubor-server jsou tedy v architektuře klient-server eliminovány. Technologie klient-server

Dříve se uvažovalo o lokálních databázích, kdy se databáze i aplikace, která s ní komunikuje, nacházejí na stejném počítači. Tato část se bude zabývat některými funkcemi práce se vzdálenými databázemi používanými v síti, kde jsou aplikace a databáze umístěny na různých počítačích.

V zásadě lze pro sdílený přístup využít i lokální databázi, tedy v síťové verzi. V tomto případě jsou databázové soubory a aplikace pro práci s nimi umístěny na síťovém serveru. Uživatel spustí ze svého počítače aplikaci umístěnou na serveru a spustí se mu kopie aplikace. Aplikaci můžete také nainstalovat přímo na počítač uživatele, v takovém případě musí aplikace znát umístění sdílené databáze zadané například přes alias. Taková síťová možnost pro použití lokální databáze odpovídá architektuře souborového serveru.

Výhodou síťové architektury „file-server“ je snadný vývoj a provoz databáze a aplikace. Vývojář vlastně vytvoří lokální databázi a aplikaci, které se pak jednoduše použijí v síťové verzi. Nevyžaduje další software pro organizaci práce s databází. Architektura souborového serveru má však také významné nevýhody. Pro práci s daty se používá metoda navigačního přístupu, přičemž po síti cirkuluje velké množství dat. Tím dochází k přetížení sítě, což je důvodem její nízké rychlosti a špatného výkonu při práci s databází. Je vyžadována synchronizace jednotlivých uživatelů, spojené se zámkem v tabulkách těch záznamů, které upravuje jiný uživatel. Aplikace nejen zpracovávají data, ale spravují i ​​samotnou databázi. Vzhledem k tomu, že databáze je spravována z různých počítačů, je obtížné kontrolovat přístup, důvěrnost a zachování integrity databáze.

Kvůli těmto nedostatkům se architektura souborového serveru obvykle používá v malých sítích. Pro sítě s velké množství Pro uživatele je preferovanou možností (a někdy jedinou možnou) architektura „klient-server". V síťové architektuře „klient-server" je databáze umístěna na počítači síťového serveru (server nebo vzdálený server) a je také nazývaná vzdálená databáze. Aplikace, která s touto databází pracuje, je umístěna na počítači uživatele. Uživatelská aplikace je klient, také známý jako klientská aplikace. Klient a server spolupracují následovně. Klient vytvoří a odešle požadavek na server, který je hostitelem databáze. Server provede požadavek a vrátí požadovaná data klientovi. V architektuře klient-server tedy klient odešle požadavek a obdrží pouze data, která skutečně potřebuje. Veškeré zpracování požadavků probíhá na vzdáleném serveru. Mezi výhody takové architektury patří následující faktory. Pro práci s daty se používá metoda relačního přístupu, která snižuje zatížení sítě. Aplikace nespravují přímo databázi, na správě se podílí pouze server. V tomto ohledu lze zajistit vysoký stupeň ochrany údajů. V aplikaci není žádný kód pro správu databáze, takže aplikace jsou zjednodušené.

Všimněte si, že nejen počítač se nazývá server, ale také speciální program, který spravuje databázi. Protože organizace výměny dat mezi klientem a serverem je založena na jazyk SQL takový program se také nazývá SQL server a databáze se také nazývá SQL databáze. V širokém slova smyslu je server chápán jako počítač, program a samotná databáze. SQL servery jsou průmyslové DBMS, jako je InterBase, Oracle atd. Každý ze serverů má své výhody a vlastnosti spojené např. se strukturou databáze a implementací jazyka SQL, které je třeba vzít v úvahu při vývoj aplikace. Dále budeme server chápat jako program (tj. SQL server) a databázi nainstalovanou na serverovém počítači budeme nazývat vzdálená databáze.

Při práci v architektuře klient-server musí aplikace:

· navázat spojení se serverem a ukončit jej;

· vytvořit a odeslat požadavek na server, přičemž od něj obdrží výsledky požadavku;

· zpracovat přijatá data.

Zpracování údajů však ne zásadní rozdíly ve srovnání se zpracováním dat v lokálních databázích.

Vzdálená databáze, stejně jako lokální, je kolekce vzájemně propojených tabulek. Údaje v těchto tabulkách jsou však obvykle obsaženy v jedné společný soubor. Stejně jako v případě lokální databáze mohou mít tabulky vzdálené databáze spojení (relace), omezení referenční integrita, omezení hodnot sloupců atd. U vzdálených databází se pole nazývá sloupec. Pro správu databáze server používá:

· spouštěče;

· generátory;

· uložené procedury;

· uživatelsky definované funkce;

· transakční mechanismus;

· mechanismus změn uložených v mezipaměti;

Mnoho z uvedených prvků je zajištěno jazykovými funkcemi. SQL Server, která má ve srovnání s lokální verzí výrazné vlastnosti rozebrané níže.

Systém Delphi zajišťuje vývoj aplikací pro různé servery a poskytuje k tomu vhodné nástroje. Všimněte si, že mnohé z dříve popsaných principů vývoje aplikací a nástrojů pro práci s lokálními databázemi platí také pro práci se vzdálenými databázemi. Pro vývoj aplikací se používají zejména komponenty jako DataSource, DatasetsTable, ADOTable, SQLTable, IBTable, Query, ADOQuery, SQLQuery, DBGrid grid atd.

Chcete-li implementovat relační způsob přístupu ke vzdálené databázi pomocí BDE, musíte používat pouze nástroje jazyka SQL. Proto by jako komponenty měly být vybrány jako Query, StoredProc, UpdateSQL. Kromě toho nelze v sadě dat použít metody specifické pro metodu navigačního přístupu.

Připomeňme, že pokud výsledná datová sada není potřebná při provádění dotazu upravujícího databázi pomocí komponenty Query, pak je vhodnější provést tento dotaz pomocí metody ExecSQL. Pro práci s tabulkami a dotazy můžete stále používat programy jako Database Desktop a SQL Explorer.

Nástroje Delphi navržené pro práci se vzdálenými databázemi lze rozdělit do dvou typů: nástroje a komponenty.

Mezi nástroje patří speciální programy a balíčky, které zajišťují údržbu databáze mimo vyvíjené aplikace. Mezi nimi:

· InterBase Server Manager - program pro správu spouštění serveru InterBase;

· IBConsole - konzola serveru InterBase;

· SQL Monitor je program pro sledování pořadí provádění SQL dotazů do vzdálených databází.

Komponenty jsou navrženy tak, aby vytvářely aplikace, které provádějí operace se vzdálenou databází. Uvádíme ty nejdůležitější z nich:

· Databáze (připojení k databázi);

· Session (aktuální relace s databází);

· StoredProc (volání uložené procedury);

· UpdateSQL (úprava datové sady na základě SQL dotazu);

· DCOMConnection(DCOM připojení);

· ADO, dbExpress, komponenty stránky Interbase Palety komponent.

Všimněte si, že mnoho z pojmenovaných komponent, například Database, Session, UpdateSQL, se také používá při práci s lokálními databázemi. Komponenta Databáze vám tedy umožňuje implementovat transakční mechanismus s navigační metodou přístupu k datům pomocí mechanismu BDE. Nejčastěji se však tyto komponenty používají při práci se vzdálenými databázemi. Některé komponenty, například sada klientských dat ClientDataSet a připojení k serveru DCOMConnection, jsou navrženy tak, aby fungovaly v třívrstvé (třívrstvé) architektuře „klient-server“ („tenký“ klient) a používají se k vybudování aplikačního serveru.

Operace prováděné se vzdálenými databázemi, jak pomocí nástrojů, tak i programově, jsou založeny na jazyku SQL. Například při vytváření tabulky pomocí programu IBConsole musíte zadat a spustit dotaz SQL (instrukce) Create Table. Pokud se vytvoření tabulky pomocí mechanismu BDE provádí z uživatelské aplikace, pak se pro tento účel použije datová sada Query, která provede stejný dotaz. Hlavní rozdíl je v tom, jak se SQL dotaz provádí proti vzdálené databázi.

Takže u vzdálených databází je rozdíl mezi nástroji používanými v aplikaci a nástroji mnohem menší než u lokálních databází.

Interbase server.Všechny servery mají podobné principy organizace a správy dat. Jako příklad zvažte práci se serverem InterBase 6.x, který je "nativní" pro_Delphi. Společně s Delphi jsou dodávány dvě části serveru InterBase 6.x: server a klient. Serverová část InterBase je lokální verzí serveru InterBase a používá se k ladění aplikací určených pro práci se vzdálenými databázemi, což umožňuje jejich kontrolu na stejném počítači v síťové verzi. Po odladění na místním počítači lze aplikaci beze změn přenést na síťové počítače, k čemuž je třeba:

· zkopírujte databázi na server;

· nastavit nové parametry připojení pro aplikaci se vzdálenou databází.

Databázi můžete kopírovat pomocí programů jako Průzkumník Windows. Klientská část je potřebná pro poskytování aplikačního přístupu ke vzdálené databázi. Při vývoji databází a aplikací pomocí lokální verze serveru InterBase je třeba mít na paměti, že má řadu omezení a nemusí podporovat např. mechanismus událostí serveru nebo uživatelem definované funkce. Plnohodnotná verze serveru InterBase se kupuje a instaluje samostatně od Delphi Jak již bylo zmíněno, práce se vzdálenou databází je založena na schopnostech jazyka SQL, které zajišťují příslušné operace. Účel a možnosti jazyka SQL pro vzdálené databáze se v zásadě shodují s účelem a možnostmi tohoto jazyka pro lokální databáze.

Obchodní pravidla. Jak bylo uvedeno, obchodní pravidla jsou mechanismy správy databáze a jsou navrženy tak, aby udržovaly databázi v konzistentním stavu. Kromě toho jsou potřebné k implementaci omezení databáze a také k provádění řady dalších akcí, například shromažďování statistik provozu databáze.

Obchodní pravidla lze implementovat na fyzické i softwarové úrovni. V prvním případě jsou tato pravidla (například omezení referenční integrity pro související tabulky) nastavena při vytváření tabulek a jsou zahrnuta do struktury databáze. K tomu jsou v syntaxi příkazu Create Table zahrnuty příslušné operandy, například Default (výchozí hodnota). V další práci není možné porušit nebo obejít omezení stanovená na fyzické úrovni.

Na programové úrovni mohou být obchodní pravidla implementována na serveru a v aplikaci. Navíc tato obchodní pravidla nemusí být definována na fyzické vrstvě. Spouštěče se obvykle používají k implementaci obchodních pravidel na serveru. Výhodou tohoto přístupu je, že výpočetní zátěž pro správu databáze leží výhradně na serveru, což snižuje zátěž aplikace a sítě, a že omezení platí pro všechny aplikace přistupující k databázi. Zároveň se však snižuje flexibilita správy databáze. Kromě toho mějte na paměti, že ladicí nástroje pro spouštěče serveru a uložené procedury nejsou dobře vyvinuty.

Komponenty a jejich nástroje se používají k programování obchodních pravidel v aplikaci. Výhoda tohoto přístupu spočívá ve snadné změně obchodních pravidel a možnosti definovat pravidla „své“ aplikace. Nevýhodou je snížení bezpečnosti databáze spojené s tím, že každá aplikace si může nastavit vlastní pravidla pro správu databáze.

Informace o celé databázi serveru InterBase jsou uloženy v jednom souboru s příponou gdb. Velikost tohoto souboru může být jednotek a dokonce i desítek gigabajtů. Všimněte si, že Microsoft SOL Server DBMS má podobnou velikost databáze, zatímco u výkonnějších Oracle a SyBase DBMS dosahuje velikost databáze desítek a stovek gigabajtů.

Na rozdíl od lokální databáze, jejíž struktura byla tvořena tabulkami (samostatnými nebo propojenými), má vzdálená databáze složitější strukturu, která zahrnuje následující prvky: tabulky, spouštěče, indexy, uživatelské funkce. omezení, uložené procedury, domény, pohledy, generátory, výjimky, oprávnění.

Prvky struktury vzdálené databáze se také nazývají metadata. Slovo „meta“ má význam „výše“, tj. metadata jsou data, která popisují strukturu databáze. Pro InterBase je maximální počet tabulek v databázi 65 536 a maximální počet sloupců v tabulce je 1000. Všimněte si, že tabulky InterBase mají méně povolených typů sloupců (polí) než tabulky lokální databáze Paradox.

Doména je pojmenovaný popis sloupce. Jakmile je doména definována, lze její název použít k popisu dalších sloupců Analogou domény je datový typ.

Pohled je logická (virtuální) tabulka, jejíž záznamy se vybírají pomocí příkazu Select. Výhodou procházení je, že jakmile záznamy vyberete, můžete je později použít, aniž byste museli znovu spouštět Select. To je výhodné, pokud často spouštíte stejné dotazy.

Uložené procedury je podprogram umístěný na serveru a volaný z klientské aplikace. Použití těchto objektů zvyšuje rychlost přístupu k databázi z následujících důvodů:

· místo textu požadavku je na server po síti odesláno krátké volání uložené procedury;

· uložená procedura nevyžaduje předchozí kontrolu syntaxe.

Spoušť je procedura, která se nachází na databázovém serveru a je volána automaticky při úpravě databázových záznamů, tzn. při změně sloupců nebo při odebrání a přidání sloupců. Na rozdíl od uložených procedur nelze spouštěče volat z klientské aplikace, ani jim nemůžete předávat parametry ani z nich přijímat výsledky.

Uživatelem definovaná funkce je běžná funkce napsaná v algoritmickém jazyce, jako je Pascal. Vytvořená funkce je formátována jako dynamická DLL, odkud lze volat obvyklým způsobem. Aby bylo zajištěno, že je funkce volána, musí systém Windows znát cestu k příslušné knihovně. Použití takových funkcí rozšiřuje sadu funkcí jazyka SQL.

Mechanismus změn v mezipaměti spočívá v tom, že se v mezipaměti (bufferu) na klientském počítači vytvoří místní kopie dat a v této kopii se provedou všechny změny dat. Pro uložení lokální kopie se používá speciální vyrovnávací paměť (cache). Provedené změny lze potvrdit jejich přenesením do hlavní databáze uložené na serveru nebo je lze zahodit. Tento mechanismus připomíná transakční mechanismus, ale na rozdíl od něj snižuje zatížení sítě, protože všechny změny se přenášejí do hlavní databáze v jednom paketu. Mějte na paměti, že všechny položky v místní kopii nemají zámky na změnu jejich hodnot. Zámky mohou být nastaveny jinými aplikacemi pro hlavní databázi umístěnou na serveru Mechanismus cacheovaných změn je implementován v aplikaci, pro kterou mají komponenty, především Database, Table a Query (používané při přístupu pomocí BDE), odpovídající prostředek. Mechanismus cachovaných změn je navíc podporován k tomu určenou komponentou UpdateSQL.Hlavní výhody uvažovaného mechanismu se projevují u vzdálených databází, ale lze jej využít i při práci s lokálními databázemi.

Privilegium představují přístupová práva k databázi. Správa oprávnění spočívá v nastavení a odebrání oprávnění. Po vytvoření databázového objektu (například tabulky) k němu má přístup pouze tvůrce a správce systému jménem SYSDBA. Pro přístup k databázi pro ostatní uživatele je třeba jim přidělit příslušná oprávnění. Bezprostředně po objevení se nového uživatele, vytvořeného např. pomocí programu InterBase Manager Server, má tento uživatel minimální přístupová práva: do databáze smí vstoupit (připojit se k ní) pouze zadáním svého jména a hesla, nikoli však má k dispozici jediný objekt této databáze. Pro zajištění možnosti aktivní práce s databází je potřeba definovat (předefinovat) oprávnění.

Oprávnění jsou stanovena pokynem Grant. Oprávnění vám umožňují omezit přístup uživatelů k tabulkám a pohledům. V tomto případě „uživatel“ označuje jakýkoli objekt, který k datům přistupuje. Kromě samotného uživatele (aplikace) mohou být takovými objekty tabulky, pohledy, uložené procedury a spouštěče. Pokud je oprávnění uděleno několika uživatelům současně, jsou jejich jména uvedena oddělená čárkami.

V tomto příkladu vyvineme jednoduchý server a jednoduchý klientský program, mezi nimiž bude „pomalý“ dialog. Postavíme klienta podle technologie Windows Forms a server je Služba Windows . Server bude mít připravenou sadu označených odpovědí, počká na označené požadavky klientů a odpoví na ně příslušnými zprávami. To nás nastaví na vytvoření ještě složitějšího systému – prohlížení vzdálených výkresů z databáze, kterým se budeme věnovat později.

Vytvořte klienta

Začněme klientským programem, který lze spustit ve více instancích ("http://msdn.microsoft.com/en-us/library/system.net.sockets.tcplistener.accepttcpclient.aspx")

Odpočinek požadovaná nastavení přidat prvky formuláře programově.

pomocí systému; pomocí System.Collections.Generic; pomocí System.ComponentModel; pomocí System.Data; pomocí System.Drawing; pomocí System.Text; pomocí System.Windows.Forms; // Další jmenné prostory pomocí System.IO; pomocí System.Net; pomocí System.Net.Sockets; pomocí System.Threading; jmenný prostor SimpleClient ( veřejná částečná třída Form1: Form ( int port = 12000; String hostName = "127.0.0.1";// local TcpClient client = null;// Reference klienta public Form1() ( InitializeComponent(); // Vyberte první položka seznamu listBox.SelectedIndex = 0; listBox.Focus(); // Kontextová nabídka pro vymazání TextBox ContextMenuStrip contextMenu = new ContextMenuStrip(); textBox.ContextMenuStrip = contextMenu; ToolStripMenuItem item = new ToolStripMenuItem("Clear"); context.Menu.Item Add(item); item.MouseDown += new MouseEventHandler(item_MouseDown); ) // Odeslat požadavek a získat odpověď private void btnSubmit_Click(object sender, EventArgs e) ( if (listBox.SelectedIndices.Count == 0) ( MessageBox.Show ("Vyberte zprávu"); return; ) zkuste ( // Vytvořte klienta připojeného k serveru client = new TcpClient(hostName, port); // Nastavte velikosti schránky sami (Volitelné!) client.SendBufferSize = client.ReceiveBufferSize = 1024; ) catch ( MessageBox.Show("Server není připraven!"); vrátit se; ) // Zapište požadavek do protokolu AddString("Client: " + listBox.SelectedItem.ToString()); // Vytvoří NetworkStreams připojené k serveru NetworkStream streamIn = client.GetStream(); NetworkStream streamOut = client.GetStream(); StreamReader readerStream = new StreamReader(streamIn); StreamWriter WriterStream = new StreamWriter(streamOut); // Odešle požadavek na server writeStream.WriteLine(listBox.SelectedItem.ToString()); spisovatelStream.Flush(); // Přečtení odpovědi String receiverData = readerStream.ReadLine(); // Zapíše odpověď do protokolu AddString("Server: " + receiverData); // Zavře připojení a streamy, na pořadí nezáleží client.Close(); spisovatelStream.Close(); readerStream.Close(); ) // Přidání řádku, když je TextBox povolen ve víceřádkovém režimu private void AddString(Řetězec) ( StringBuilder sb = new StringBuilder(textBox.Text); StringWriter sw = new StringWriter(sb); sw.WriteLine(řádek); textBox .Text = sw.ToString(); ) // Vymazání seznamu pomocí kontextové nabídky void item_MouseDown(object sender, MouseEventArgs e) ( textBox.Clear(); listBox.Focus(); ) ) )

Po přijetí připojení k serveru vytvoříme dvě vlákna NetworkStream a zabalte je do shellů, které jsou vhodné pro ovládání čtení/zápisu. Výměna se serverem je zobrazena v protokolu Textové pole. Pro vymazání protokolu dynamicky vytvořena kontextová nabídka.

Třída TcpClient, který jsme použili v kódu, je vysokoúrovňový (a zjednodušený) zábal soketů (třída Zásuvka). Pokud je vyžadována více nízkoúrovňová správa soketů (podrobnější), pak je odkaz na ni uložen ve vlastnosti TcpClient.Client. Ale protože je tato vlastnost chráněna ( chráněný), pak je k němu přístup možný pouze z derivátu TcpClient třída.

Pokud nyní spustíte aplikaci SimpleClient, pak to bude fungovat, ale když se pokusíte něco odeslat na server, dostanete zprávu, že server není připraven. Zatím neexistuje žádný server, pojďme ho vytvořit.

Vytvoření serveru

Udělejme program serveru rezidentní podle šablony Služba Windows, jak jsme to udělali v předchozím příkladu, i když to lze provést také pomocí rozhraní, hlavní věcí je, že by mělo být spuštěno v jediné instanci na místním počítači. Pokud je serverový program součástí globální sítě, pak s IP a musí to být jediný port v této síti. Proto použití sítě IP pro globální síť musíte získat povolení.

pomocí systému; pomocí System.ComponentModel; pomocí System.Configuration.Install; pomocí System.ServiceProcess; jmenný prostor SimpleServer ( // Při instalaci sestavení zavolejte instalačnímu programu veřejnou částečnou třídu Installer1: Installer ( private ServiceInstaller serviceInstaller; private ServiceProcessInstaller serviceProcessInstaller; public Installer1() ( // Vytvořte nastavení pro Service ServiceInstaller = new ServiceInstaller(); serviceProcessInstaller = new ServiceProcessInstaller(); // Název služby pro počítač a uživatele serviceInstaller.ServiceName = "SimpleServerServiceName"; serviceInstaller.DisplayName = "SimpleServer"; serviceInstaller.StartType = ServiceStartMode.Manual;// Spustit ručně // Jak bude tato služba spuštěna. serviceProcessInstaller.Account = ServiceAccount.LocalService; this.serviceProcessInstaller.Password = null; this.serviceProcessInstaller.Username = null; // Přidání nastavení do kolekce aktuálního objektu this.Installers.AddRange(new Installer ( serviceInstaller, serviceProcessInstaller )); )))

pomocí systému; pomocí System.Collections.Generic; pomocí System.Text; // Další jmenné prostory pomocí System.IO; pomocí System.Net; pomocí System.Net.Sockets; pomocí System.Threading; pomocí System.ServiceProcess; pomocí System.Collections; jmenný prostor SimpleServer ( třída Service1: ServiceBase ( TcpListener server = null;// Server link int port = 12000; String hostName = "127.0.0.1";// local IPAddress localAddr; Řetězec odpovědi = ( "1. Kdo jsi?", "2. Ahoj, Leliku!", "3. Nejlepší!", "4. Samozřejmě naplno", "5. Do večera!" ); // Konstruktor public Service1() ( localAddr = IPAddress .Parse( hostName);// Převést na jiný formát vlákno = new Thread(ExecuteLoop); thread.IsBackground = true; thread.Start(); ) private void ExecuteLoop() ( try ( server = new TcpListener(localAddr, port) );/ / Vytvořit server posluchače server.Start();// Spustit data řetězce serveru; // Nekonečný koloběh while (true) ( ​​if (!server.Pending())// Fronta požadavků je prázdná pokračovat; TcpClient client = server.AcceptTcpClient();// Aktuální klient // Nastavte velikosti schránky sami (Volitelné!) / / Ve výchozím nastavení jsou obě vyrovnávací paměti nastaveny na 8192 bajtů o velikosti client.SendBufferSize = client.ReceiveBufferSize = 1024; // Připojte NetworkStream a zabalte jej pro pohodlí NetworkStream streamIn = client.GetStream(); NetworkStream streamOut = client.GetStream() ; StreamReader readerStream = nový StreamReader(streamIn); StreamWriter WriterStream = nový StreamWriter(streamOut); // Data požadavku na čtení = readerStream.ReadLine(); // Odeslání int indexu odpovědi; if (int.TryParse(data.Substring(0, data.IndexOf(" .")), out index)) data = odpovědi; jinak data = data.ToUpper();writeStream.WriteLine(data);writeStream.Flush(); // Zavřete připojení a streamy, objednávka 't záleží client.Close(); readerStream.Close();writeStream.Close(); ) ) catch (SocketException) ( ) nakonec ( // Zastavení serveru server.Stop(); )))))

Chcete-li odeslat data a přijmout odpověď, klientská aplikace vytvoří obousměrný soket (nebo dva jednosměrné sokety), ve kterém specifikuje adresu připojení k soketu jiné, serveru, aplikace. Pokud je spojení navázáno (server běží), pak klientská aplikace připojí síťový proud k soketu NetworkStream a jeho prostřednictvím provádí přenos a příjem dat.

Server na druhé straně připojení TcpListener poslouchat v nekonečné smyčce fronta připojení s klienty. Pokud se k němu připojil nějaký klient ( server.Pending()!=false), pak server načte tohoto klienta pomocí metody AcceptTcpClient()- vytvoří soket pro příjem / vysílání s připravenou návratovou adresou, vytvoří obousměrný stream (nebo dva jednosměrné), poté přečte požadavek a odešle odpověď.

Vezměte prosím na vědomí, že pokud kód pro práci našeho serverového programu není zabalen do samostatného vlákna Vlákno(prováděcí vlákno), pak v okně služeb tento program operační systém nespustí (zkuste to!). Důvodem je to v kódu metody ExecuteLoop() server používá nekonečnou smyčku k naslouchání frontě požadavků klientů. Pokud je tato smyčka ponechána v hlavním vláknu provádění ( Vlákno) aplikace, pak se jednoduše zasekne ve smyčce a nebude se moci normálně dokončit. Kód se smyčkou tedy umístíme do samostatného vlákna (vlákna) a uděláme mu pozadí tak, aby se uzavíral společně s hlavním aplikačním vláknem (vláknem serveru).

Důležitá poznámka

Tok NetworkStream je oboustranná pevná délka. metoda GetStream() vytváří pouze přímé spojení mezi klientskými a serverovými sokety. Jeho skutečná délka je ale určena zprávou odesílající strany. Pro příjem/odesílání je možné použít jeden stream, ale pak by délka zprávy odesílané serverem neměla překročit délku jím přijaté zprávy od klienta (skoro jsem si sedl oči!). Proto používáme dva streamy na každé straně pro samostatný jednosměrný přenos mezi dvěma uzly síťového spojení.

Příklad 3. Aplikace klient-server pro prohlížení obrázků z databáze

V předchozím jednoduchém příkladu jsme se seznámili (nepatrně) s principy tvorby síťových aplikací. A nyní sestavme složitější příklad, kdy klient požaduje obrázky a server je načte z úložiště a odešle je klientovi. V Cvičení 7 vyvinuli jsme tři různá úložiště obrázků a tři prohlížeče. V tento příklad použijme databázi Obrázky.my2.mdb s hotovými výkresy a na jeho základě vytvoříme síťová aplikace(pro ty, kteří ne Cvičení 7, databáze je přiložena v katalogu zdrojová data).

Budování klienta

Pro klienta sestavíme okenní aplikaci typu WPF S uživatelské rozhraní, částečně zapůjčené z Příklad 6 Cvičení 7.

Server není připraven, čekejte prosím! Snažíme se spojit omluvám se za nepříjemnost...

Pro zobrazení úvodní obrazovky s textem o nedostupnosti serveru jsme aplikovali prvek Viewbox, do kterého byl umístěn další prvek okraj s textovým obsahem. Taková „zahrada“ vám umožní zvětšit úvodní obrazovku úměrně velikosti okna. Nicméně zavedení prvku Viewbox začne znatelně zpomalovat překreslování rozhraní při pohybu okna, protože se snaží neustále přepočítávat měřítka svých podřízených prvků. Názvy jsme přiřadili pouze těm prvkům rozhraní, které budeme spravovat v procedurálním kódu.

pomocí systému; pomocí System.Collections.Generic; pomocí System.Text; pomocí System.Windows; pomocí System.Windows.Controls; pomocí System.Windows.Data; pomocí System.Windows.Documents; pomocí System.Windows.Input; pomocí System.Windows.Media; pomocí System.Windows.Media.Animation; pomocí System.Windows.Media.Imaging; pomocí System.Windows.Shapes; // Další jmenné prostory pro Stream using System.IO; pomocí IO = System.IO; // Alias ​​pro adresu Path using System.Windows.Threading; // Pro DispatcherTimer // Další jmenné prostory pro Socket //pomocí System.Net; pomocí System.Net.Sockets; pomocí System.Collections; // Seznam jmenný prostor PicturesClientDB ( veřejná částečná třída Window1: Window ( int port = 12000; String hostName = "127.0.0.1"; // local TcpClient client = null; // Reference klienta String sendMessage = "!!!GetNames!!!"; / / Žádost o seznam (pozakovyristy) Oddělovač znaků = ( "#" ); // Převedení odpovědi na pole názvů Časovač DispatcherTimer; // Časovač // Konstruktor public Window1() ( InitializeComponent(); // Vytvořte a spustit časovač časovače = new DispatcherTimer(); timer.Tick += new EventHandler(timer_Tick); timer.Interval = TimeSpan.FromSeconds(1); timer.Start(); ) // Inicializuje volání serveru void timer_Tick( object sender, EventArgs e) ( Execute(listBox); ) private void listBox_SelectionChanged(object sender, SelectionChangedEventArgs e) ( Execute((ListBox)sender); ) void Execute(ListBox lst) ( // Vyplňte seznam názvy obrázků zkuste ( // Pokud je server dostupný, vytvořte klienta klienta = new TcpClient(název_hostitele, port); ) catch ( // Server není připraven, spusťte časovač a ukončete, pokud (Prompt.Visibility != Visibility.Visible) ( Prompt.Visibility = Viditelnost.Viditelný; časovač.Start(); ) vrátit se; ) switch (sendMessage) ( case "!!!GetNames!!!": // Získání a svázání názvů obrázků se seznamem lst.ItemsSource = GetNames(); // Vyberte první položku v seznamu pro volání SelectionChanged lst.SelectedIndex = 0; lst.Focus(); sendMessage = ""; break; default: // Skryjte zprávu a zastavte časovač, pokud (Prompt.Visibility == Visibility.Visible) ( Prompt.Visibility = Visibility.Hidden; timer.Stop (); ) / / Získejte obrázek a zobrazte jej uživateli pomocí štětce String name = lst.SelectedValue.ToString(); BitmapImage bi = new BitmapImage(); bi.BeginInit(); // Získejte obrázek z serveru a zabalte jej do paměťového toku bi.StreamSource = new MemoryStream (GetPicture(název)); bi.EndInit(); Pictures.picture.ImageSource = bi;// Předání obrázku na pozadí Border break; ) ) private String GetNames() ( Názvy řetězců; // Vytváření proudů síťového připojení StreamReader readerStream = new StreamReader(client.GetStream()); StreamWriter WriterStream = new StreamWriter(client.GetStream()); // Odešle požadavek na server writeStream.WriteLine(sendMessage); spisovatelStream.Flush(); // Přečtení odpovědi String receiverData = readerStream.ReadLine(); names = receiverData.Split(separator);// Převod na pole řetězců // Uzavřete spojení a streamy, pořadí je nedůležité client.Close(); spisovatelStream. zavřít(); readerStream.Close(); návratová jména; ) Byte GetPicture(název řetězce) ( // Vytvořit streamy síťového připojení NetworkStream readerStream = client.GetStream(); StreamWriterwriteStream = new StreamWriter(client.GetStream()); // Odeslání požadavku na server WriterStream.WriteLine(name) ;writeStream. Flush(); // Čtení odpovědi // ReceiveBufferSize - velikost vyrovnávací paměti pro příchozí data // SendBufferSize - velikost vyrovnávací paměti pro odchozí data Seznam seznam = nový seznam (client.ReceiveBufferSize);// Přírůstková kapacita Byte bytes = nový Byte; // Velikost vyrovnávací paměti soketu int pocet = 0; // Části příchozích dat while ((count = readerStream.Read(bytes, 0, bytes.Length)) != 0) for (int i = 0; i< count; i++) list.Add(bytes[i]); // Преобразуем в массив результата bytes = new Byte; list.CopyTo(bytes); // Закрываем соединение и потоки, порядок неважен client.Close(); writerStream.Close(); readerStream.Close(); return bytes; } } // Для привязки к ресурсу class Pictures { // Поле public static ImageBrush picture = new ImageBrush(); static Pictures() { // Дежурный рисунок заставки picture.ImageSource = new BitmapImage(new Uri(@"flower2.jpg", UriKind.Relative)); picture.Stretch = Stretch.Fill; picture.Opacity = 1.0D; } // Привязываемое в интерфейсе свойство public static ImageBrush Picture { get { return picture; } } } }

Upozorňujeme, že při zobrazování obrázků jsme opustili tradiční prvek obraz jako jsme to udělali v předchozím cvičení. A oni si pro změnu počínali zcela netradičně (turecky). Nyní zobrazíme kresby štětcem ImageBrush na pozadí obdélníku okraj přes objekt k němu připojený obrázky. V životě je samozřejmě nepravděpodobné, že budete muset takto zvrhnout, ale tato možnost se může někde hodit.

Úvodní obrazovka se objeví, jakmile je zjištěna nepřítomnost nebo zastavení serveru. A po nalezení serveru úvodní obrazovka zmizí. Tento mechanismus bude fungovat okamžitě díky systémový časovač. Zatím však neexistuje žádný server a měl by být vytvořen.

Budování databázového serveru jako služby

• tým Soubor/Přidat/Nový projekt přidat do roztoku NetworkStream nový projekt pojmenovaný PicturesServerDB typ Služba Windows

pomocí systému; pomocí System.Collections.Generic; pomocí System.ComponentModel; pomocí System.Data; pomocí System.Diagnostics; pomocí System.ServiceProcess; pomocí System.Text; // Další jmenné prostory pro ADO.NET pomocí System.Data.OleDb; pomocí System.Data.Common; // Další jmenné prostory pomocí System.IO; pomocí System.Net; pomocí System.Net.Sockets; pomocí System.Threading; pomocí System.Collections; jmenný prostor PicturesServerDB ( veřejná částečná třída Service1: ServiceBase ( int port = 12000; String hostName = "127.0.0.1"; // místní IPAddress localAddr; TcpListener server = null; // Odkaz na server Oddělovač řetězce = "#"; // Názvy oddělovačů v řetězci odpovědi String connectionString; // Řetězec připojení DB public Service1() ( // Načte řetězec připojení DB ze souboru App.config do pole connectionString = System.Configuration.ConfigurationManager. ConnectionStrings["PicturesDB"].ConnectionString; / / Převést IP do jiného formátu localAddr = IPAddress.Parse(hostName); // Spustit v novém vláknu (vláknu) Thread thread = new Thread(ExecuteLoop); thread.IsBackground = true; thread.Start(); ) private void ExecuteLoop() ( try ( server = new TcpListener(localAddr, port);// Vytvořte server posluchače serveru.Start();// Spusťte server // Nekonečná smyčka naslouchání klientům, zatímco (true) ( ​​​​ / / Zkontrolujte frontu připojení, pokud (!server .Pending())// Fronta požadavků je prázdná pokračovat; TcpClient client = server.AcceptTcpClient();// Aktuální klient // Vytvořit proudy síťového připojení StreamReader readerStream = new StreamReader(client.GetStream()); NetworkStream streamOut = client.GetStream(); StreamWriter WriterStream = new StreamWriter(streamOut); // Přečtení příkazu klienta String receiverData = readerStream.ReadLine(); // Rozpoznejte a spusťte přepínač (receiverData) ( case "!!!GetNames!!!":// Odesílejte názvy oddělené oddělovačem String names = GetNames();writeStream.WriteLine(names); // Použití prostřednictvím obálky WriteStream.Flush (); break; default:// Odeslat obrázek Byte bytes = GetPicture(receiverData); streamOut.Write(bytes, 0, bytes.Length);// Přímo použijte streamOut.Flush(); break; ) // Zavřete připojení a streamy, pořadí není důležité client.Close(); readerStream.Close(); spisovatelStream.Close(); ) ) nakonec ( // Zastavení serveru server.Stop(); ) ) // Načtení názvů obrázků z databáze a jejich zabalení do jednoho řetězce pro odeslání klientskému řetězci GetNames() ( // Vytvoření a konfigurace infrastruktury ADO . NET OleDbConnection conn = new OleDbConnection(connectionString); OleDbCommand cmd = new OleDbCommand("SELECT FileName FROM MyTable"); cmd.Connection = připojení; conn.open(); // Načtení názvů výkresů OleDbDataReader reader = cmd.ExecuteReader(CommandBehavior.CloseConnection); // Vytvoření řetězce odchozích dat StringBuilder sb = new StringBuilder(); foreach (záznam DbDataRecord ve čtečce)// Ekvivalent ke čtení reader.Read() sb.Append(((string)record["NázevSouboru"]).Trim() + oddělovač); // Spojení zde uzavře samotný objekt DataReader po načtení všech dat // podle konvence při jeho vytvoření CommandBehavior.CloseConnection // Odebere poslední znak navíc oddělovače sb.Replace(separator, String.Empty, sb .ToString(). LastIndexOf(separator ), separator.Length); return sb.ToString(); ) // Načtěte samotný obrázek z databáze a odešlete jej do klientského bajtu GetPicture(String name) ( // Vytvoření a konfigurace infrastruktury ADO.NET OleDbConnection conn = new OleDbConnection(); conn.ConnectionString = connectionString; // Create a nakonfigurujte objekt příkazu, parametrizovaný názvem obrázku OleDbCommand cmd = new OleDbCommand(); cmd.Connection = conn; cmd.CommandType = CommandType.Text; // Volitelné! Výchozí cmd.CommandText = "SELECT Picture FROM MyTable WHERE FileName=? "; cmd.Parameters .Add(new OleDbParameter()); cmd.Parameters.Value = název;// Název obrázku OleDbDataAdapter adapter = new OleDbDataAdapter(cmd); // Načtení obrázku z databáze DataTable table = new DataTable() ; adapter.Fill(table) ;byte bytes = (byte)table.Rows["Picture"]; // Připojení k obrázku vrátí bajty; ) ) )

Aplikací klient-server rozumíme informační systém založený na využití databázových serverů (viz dlouhá poznámka na konci kapitoly 2.1). Obecné znázornění informačního systému v architektuře "klient-server" je na obrázku 2.3.

• Na straně klienta se spouští aplikační kód, který nutně zahrnuje komponenty, které podporují rozhraní koncového uživatele, produkují sestavy a provádějí další funkce specifické pro aplikaci (prozatím nás nebude zajímat, jak je sestaven kód aplikace).
• Klientská strana aplikace spolupracuje s klientskou stranou softwaru pro správu databází, což je ve skutečnosti individuální zástupce DBMS pro aplikaci.

(Zde jsou opět nedostatky v terminologii. Obvykle, když společnost oznámí vydání dalšího databázového serveru, je implicitně chápáno, že existuje také klientská komponenta tohoto produktu. Kombinace "klientská část databázového serveru" se zdá trochu zvláštní, ale budeme muset použít tento termín.)

Rýže. 2.3. Obecná reprezentace informačního systému v architektuře "klient-server".

Všimněte si, že rozhraní mezi klientskou stranou aplikace a klientskou stranou databázového serveru je obvykle založeno na použití jazyka SQL. V kódu aplikace se tedy provádějí funkce jako například předzpracování formulářů určených pro databázové dotazy nebo generování výsledných sestav.

Nakonec klientská strana databázového serveru pomocí nástrojů přístup k síti, odkazuje na databázový server a předává mu text SQL příkazu.

Zde je třeba uvést ještě dvě poznámky.

1. Společnosti vyrábějící pokročilé databázové servery se obvykle snaží zajistit, aby jejich produkty bylo možné používat nejen v dnešních standardních sítích orientovaných na TCP/IP, ale i v sítích založených na jiných protokolech (například SNA nebo IPX/SPX). Proto se při organizování síťových interakcí mezi klientskou a serverovou částí DBMS často používají nestandardní prostředky. vysoká úroveň(například softwarové sokety nebo vzdálená volání procedur) a jejich vlastní funkčně podobné nástroje, které jsou méně závislé na zvláštnostech sítě transportní protokoly.
2. Když mluvíme o rozhraní založeném na jazyku SQL, je třeba si uvědomit, že i přes titánské snahy o standardizaci tohoto jazyka neexistuje žádná taková implementace, ve které by nebyly rozšířeny standardní vlastnosti jazyka. Bezohledné používání jazykových rozšíření vede k úplné závislosti aplikace na konkrétním výrobci databázového serveru.

Podrobněji se těmto otázkám budeme věnovat ve čtvrté části kurzu.

Nyní se podívejme, co se děje na straně databázového serveru. V produktech téměř všech společností server dostává od klienta text operátora v jazyce SQL.

• Server sestaví přijatý výpis. Nebudeme se zde zabývat tím, který cílový jazyk konkrétní kompilátor používá; používané v různých implementacích. různé přístupy(příklady viz část 4). Jde hlavně o to, že v každém případě se na základě informací obsažených v tabulkách databázového katalogu neprocedurální reprezentace operátora převede do nějaké procedury pro její provedení.
• Poté (pokud byla kompilace úspěšná) se příkaz provede. Opět nebudeme diskutovat o technických detailech, protože se liší v implementacích. Zvážit možné akce SQL příkazy.
• Operátor může odkazovat na třídu operátorů pro definování (nebo vytváření) databázových objektů (přesnější a správnější by bylo hovořit o prvcích databázového schématu nebo o objektech metadatabáze). Zejména lze definovat domény, tabulky, omezení integrity, spouštěče, uživatelská oprávnění, uložené procedury. V každém případě, když se provede příkaz vytvoření prvku schématu databáze, odpovídající informace se umístí do tabulek katalogu databáze (v tabulkách metadatabáze). Omezení integrity jsou obvykle uložena v metabázi databáze přímo v textové reprezentaci. Pro akce definované v triggerech a uložených procedurách se generuje procedurální spustitelný kód a ukládá se do katalogových tabulek. Všimněte si, že integritní omezení, spouštěče a uložené procedury jsou v jistém smyslu reprezentativní pro aplikaci v databázi podporované serverem; tvoří páteř back-endu aplikace (viz níže).
• Při provádění příkazů pro výběr dat na základě obsahu tabulek ovlivněných dotazem a případně pomocí indexů udržovaných v databázi se vytvoří výsledná datová sada (záměrně zde nepoužíváme termín „tabulka výsledků“, protože v závislosti na na konkrétním typu operátoru lze seřadit výsledek a tabulky, tj. vztahy, jsou neuspořádané podle definice). Serverová část DBMS odešle výsledek klientské části a konečné zpracování se provádí v klientské části aplikace.
• Při provádění příkazů úpravy obsahu databáze (INSERT, UPDATE, DELETE) se kontroluje, zda nebudou porušena dosud definovaná omezení integrity (ta, která patří do třídy okamžitě zkontrolovaných), načež se provede příslušná akce (s doprovodem úpravy všech relevantních indexů a změn protokolování). Dále server zkontroluje, zda změna ovlivní podmínky spuštění některého spouštěče, a pokud je takový spouštěč nalezen, provede svou akci. Tento postup může zahrnovat další příkazy úpravy databáze, které mohou způsobit aktivaci jiných aktivačních událostí a tak dále. Můžeme uvažovat, že akce, které jsou prováděny na databázovém serveru při kontrole splnění omezení integrity a při spouštění triggerů, představují akce back-endu aplikace.

Při provádění příkazů úpravy schématu databáze (přidání nebo odstranění sloupců existujících tabulek, změna datového typu existujícího sloupce existující tabulky atd.) lze také spouštět spouštěče, tj. jinými slovy, backend aplikace může být popraven.

Obecně platí, že v architektuře souborového serveru máme „tlustého“ klienta a velmi „tenký“ server v tom smyslu, že téměř veškerá práce se provádí na straně klienta a ze serveru je vyžadována pouze dostatečná kapacita. diskové úložiště(Obrázek 2.2).

Rýže. 2.2. "Tlustý" klient a "tenký" server v architektuře souborového serveru

Stručné závěry. Aplikaci souborového serveru lze snadno navrhnout, vyvinout a odladit velmi rychle a je navržena pro použití jedním uživatelem. Velmi často malé firmě k vedení např. personální evidence stačí mít izolovaný systém běžící na samostatném PC. Samozřejmě i v tomto případě je ze strany koncových uživatelů (nebo administrátorů, jejichž přítomnost je v tomto případě pochybná) vyžadována velká péče, aby byla data bezpečně uložena a zachována integrita dat. Nicméně v trochu více těžké případy(například při organizaci informačního systému na podporu projektu realizovaného skupinou) se architektury souborových serverů stávají nedostatečnými.

Jsou nerovné složky informační síť. Někteří vlastní nějaký druh zdroje, proto se jim říká servery, jiní k těmto zdrojům přistupují a nazývají se klienti. Podívejme se, jak se vzájemně ovlivňují a jaká je architektura klient-server.

Architektura „klient-server“ je interakce strukturálních komponent v síti založené na určité dané síti, kde strukturálními komponentami jsou server a uzly-poskytovatelé určitých specializovaných funkcí (služeb), stejně jako klienti, kteří toto využívají. servis. Specifické funkce jsou obvykle rozděleny do tří skupin na základě řešení určitých úkolů:

• funkce zadávání dat a prezentace jsou určeny pro interakci uživatele se systémem;
• funkce aplikace - každá má svou vlastní sadu;
• funkce správy zdrojů jsou navrženy pro správu systému souborů, různých databází a dalších komponent.

Například počítač bez internetové připojení, představuje komponenty prezentace, aplikace a ovládání na různé úrovně. Za takové úrovně se považuje operační systém, aplikační a servisní software a různé utility. Stejně tak jsou v síti přítomny všechny výše uvedené komponenty. Hlavní věcí je správně zajistit síťovou interakci mezi těmito komponentami.

Architektura klient-server se nejčastěji využívá k vytváření podnikových databází, ve kterých se informace nejen ukládají, ale také periodicky zpracovávají. různé metody. Právě databáze je hlavním prvkem každého podnikového informačního systému a jádro této databáze je umístěno na serveru. Na serveru tak probíhají nejsložitější operace související se vstupem, uložením, zpracováním a úpravou dat. Když uživatel (klient) přistupuje k databázi (serveru), požadavek je zpracován: databáze je přímo zpřístupněna a je vrácena odpověď (výsledek zpracování). Výsledkem zpracování je síťová zpráva o úspěchu operace nebo chybě. Serverové počítače mohou obsluhovat více klientů přistupujících ke stejnému souboru současně. Taková práce po síti umožňuje urychlit práci vámi používaných aplikací.

Tato architektura se používá pro přístup k různým zdrojům pomocí síťových technologií: databáze, poštovní servery, firewally, proxy servery. Vývoj aplikací klient-server vám umožňuje zlepšit bezpečnost, spolehlivost a výkon vašich aplikací a sítě jako celku. Nejčastěji se pro automatizaci podnikání používají aplikace klient-server.

Moderní DBMS musí splňovat řadu požadavků, z nichž nejdůležitější je vysoce výkonný inteligentní databázový server. Dále zvážíme hlavní trendy v jeho vývoji a probereme konkrétní mechanismy, v nichž jsou ztělesněny.

Proces technického zdokonalování databázového serveru je pro většinu uživatelů moderních DBMS stále neviditelný. Při výběru konkrétního systému proto zpravidla nezohledňují ani technickou úroveň řešení zabudovaných do mechanismu jeho fungování, ani dopad těchto rozhodnutí na celkový výkon SŘB. Jeho kvalita přitom není určována bohatostí uživatelských rozhraní, nikoli rozmanitostí nástrojů pro podporu vývoje, ale především závisí na architektuře databázového serveru. Dále budou zváženy modely technologie "klient-server", bude určeno místo databázového serveru v těchto modelech a budou popsány nejdůležitější mechanismy databázového serveru - procedury, pravidla (spouštěče), události. stručně popsáno. Ten bude ilustrován příklady, které používají dialekt SQL přijatý v Ingres DBMS.

Technologie a modely klient-server.

"Klient-server" je model interakce mezi počítači v síti. Počítače si zpravidla nejsou rovny. Každý z nich má svůj vlastní, od ostatních odlišný, účel, hraje svou roli. Některé počítače v síti vlastní a spravují informace a výpočetní zdroje, jako jsou procesory, souborový systém, poštovní služba, tisková služba, databáze. Ostatní počítače mají možnost přístupu k těmto službám pomocí služeb prvního počítače. Počítač, který spravuje ten či onen prostředek, se obvykle nazývá server tohoto prostředku a počítač, který jej chce používat, se nazývá klient. Konkrétní server je určen typem zdroje, který vlastní. Pokud jsou tedy databáze zdrojem, pak mluvíme o databázový server, jejímž účelem je obsluhovat požadavky zákazníků související se zpracováním údajů; pokud je zdrojem souborový systém, pak se mluví o souborový server nebo souborový server atd.

V síti může stejný počítač fungovat jako klient i jako server. Například v informačním systému, který zahrnuje osobní počítače, sálový počítač a minipočítač s operačním systémem UNIX, může tento minipočítač fungovat jak jako databázový server obsluhující požadavky klientů – osobních počítačů, tak jako klient, který odesílá požadavky na sálový počítač.

Stejný princip platí pro interakci programů. Pokud jeden z nich vykonává nějaké funkce a poskytuje ostatním vhodnou sadu služeb, pak takový program funguje jako server. Programy, které tyto služby využívají, se nazývají klienti. Takže jádro relačního SQL-orientovaného DBMS se často nazývá databázový server nebo SQL server a program, který k němu přistupuje pro služby zpracování dat, se nazývá SQL klient.

Zpočátku měl DBMS centralizovanou architekturu (obrázek 10). V něm samotný DBMS a aplikační programy, které s databázemi pracovaly, fungovaly na centrálním počítači (hlavním počítači nebo minipočítači). Nechyběly ani databáze. Terminály byly připojeny k centrálnímu počítači a fungovaly jako uživatelské pracovní stanice. Veškeré procesy související se zpracováním dat, jako jsou: podpora uživatelského vstupu, tvorba, optimalizace a provádění dotazů, výměna s externími paměťovými zařízeními atd., byly prováděny na centrálním počítači, což kladlo přísné požadavky na jeho výkon. Vlastnosti první generace DBMS přímo souvisí s architekturou sálových a minipočítačových systémů a adekvátně odrážejí všechny jejich výhody a nevýhody. Nás však spíše zajímá současný stav víceuživatelských DBMS, pro které se architektura klient-server stala de facto standardem.

Obrázek 10 - Systémy s centralizovanou architekturou

Pro jasnější představu o jeho vlastnostech je nutné zvážit několik modelů technologie „klient-server“, které budou provedeny.

Pokud se předpokládá, že návrh Informační systém(IS) bude disponovat technologií „klient-server“, to znamená, že aplikační programy implementované v jejím rámci budou distribuovány. Jinými slovy, některé funkce aplikačního programu (nebo jednodušeji aplikace) budou implementovány v klientském programu, jiné - v programu serveru a pro jejich interakci bude definován nějaký protokol.

Základním principem technologie „klient-server“ je oddělení funkcí standardu interaktivní aplikace do čtyř odlišných skupin. První skupinou jsou funkce zadávání dat a zobrazování. Druhá skupina kombinuje čistě aplikované funkce, které jsou specifické pro danou oblast (např bankovní systém- otevření účtu, převod peněz z jednoho účtu na druhý atd.). Třetí skupina zahrnuje základní funkce ukládání a správy informačních zdrojů (databází, souborových systémů atd.). Konečně funkcemi čtvrté skupiny jsou funkce služeb (hrající roli vazeb mezi funkcemi prvních tří skupin.

V souladu s tím se v každé aplikaci rozlišují následující logické komponenty:

Komponenta View, která implementuje funkce první skupiny;

Aplikační komponenta, která podporuje funkce druhé skupiny;

Komponenta přístupu k informačním zdrojům, která podporuje funkce třetích skupin a také zavádí a zpřesňuje dohody o jejich vzájemné interakci (protokol interakce).

Rozdíly v implementacích technologie klient-server jsou určeny čtyřmi faktory. Za prvé, jaké typy softwaru jsou integrovány do každé z těchto součástí. Za druhé, jaké softwarové mechanismy se používají k implementaci funkcí všech tří skupin. Za třetí, jak jsou logické komponenty distribuovány mezi počítači v síti. Za čtvrté, jaké mechanismy se používají ke vzájemnému spojení součástí.

V modelech jsou implementovány čtyři přístupy:

model souborového serveru (File Server - FS);

Model přístupu ke vzdáleným datům (Remote Data Access - RDA);

model databázového serveru (DataBase Server - DBS);

Model aplikačního serveru (Application Server - AS).

Model FS je základem pro lokální sítě osobních počítačů. Není to tak dávno, co byl extrémně populární mezi domácími vývojáři používajícími systémy jako FoxPRO, Clipper, Clarion, Paradox atd. Podstata modelu je jednoduchá a známá všem. Uvažuje se o jednom z počítačů v síti souborový server a poskytuje služby zpracování souborů dalším počítačům. Souborový server je spravován sítí operační systém(Například, Novell NetWare) a plní roli přístupové komponenty k informačním zdrojům (tedy k souborům). Na ostatních počítačích v síti běží aplikace, v jejíchž kódech je kombinována komponenta prezentace a komponenta aplikace (obrázek 11). Protokol výměny je sada nízkoúrovňových volání, která poskytují aplikaci přístup k systému souborů na souborovém serveru.

Obrázek 11 - Model souborového serveru

Model FS sloužil jako základ pro rozšíření možností osobních DBMS směrem k podpoře víceuživatelského režimu. V takových systémech na více osobních počítačích běží jak aplikační program, tak kopie DBMS, a databáze jsou obsaženy ve sdílených souborech, které jsou umístěny na souborovém serveru. Když aplikace přistupuje k databázi, DBMS odešle požadavek na souborový server. Tento požadavek specifikuje soubory, kde jsou požadovaná data umístěna. V reakci na požadavek souborový server odešle požadovaný blok dat přes síť. DBMS poté, co je obdrží, provede s daty akce, které byly deklarovány aplikačního programu.

Mezi technologické nevýhody modelu patří vysoký síťový provoz (přenos mnoha souborů, požadované aplikací), úzký rozsah operací manipulace s daty („data jsou soubory“), nedostatek adekvátních prostředků pro zabezpečení přístupu k datům (ochrana je pouze na úrovni souborový systém) atd. Ve skutečnosti výše uvedené nejsou nedostatky, ale jsou důsledkem omezení obsažených v modelu FS, určených jeho povahou. K nedorozuměním dochází, když se FS-model používá pro jiné účely, například se ho snaží interpretovat jako model databázového serveru. Místo modelu FS v hierarchii modelů klient-server je místo modelu souborového serveru a nic víc. Proto jsou pokusy vytvořit rozsáhlé projekty založené na modelu FS odsouzeny k neúspěchu. podnikové systémy- pokusy, které byly učiněny v nedávné minulosti a často k nim dochází i nyní.

Technologicky vyspělejší model RDA se od modelu FS výrazně liší povahou složky přístupu k informačním zdrojům. Obvykle se jedná o SQL Server. V modelu RDA jsou kódy prezentační komponenty a komponenty aplikace kombinovány a spuštěny na klientském počítači. Ten podporuje jak funkce zadávání dat a zobrazování, tak i čistě aplikační funkce. Přístup k informačním zdrojům je zajišťován buď operátory speciálního jazyka (např. SQL, pokud jde o databáze), nebo voláním funkcí speciální knihovny (pokud existuje vhodné aplikační programovací rozhraní - API).

Klient odesílá požadavky na informační zdroje (například databáze) přes síť do vzdáleného počítače. Funguje na něm jádro DBMS, které zpracovává požadavky, provádí v nich předepsané akce a výsledek vrací klientovi naformátovaný jako datový blok (obrázek 12). Programy běžící na klientských počítačích přitom vystupují jako iniciátor manipulace s daty, přičemž jádru DBMS je přidělena pasivní role – obsluhování požadavků a zpracování dat.

Obrázek 12 - Model přístupu ke vzdáleným datům

Model RDA odstraňuje nevýhody spojené s centralizovanou architekturou i systémy souborových serverů.

Za prvé, přenos prezentační komponenty a komponenty aplikace na klientské počítače výrazně odlehčuje databázový server a minimalizuje celkový počet procesů operačního systému. Databázový server je uvolněn ze svých neobvyklých funkcí; procesor nebo procesory serveru jsou zcela zatíženy operacemi zpracování dat, dotazů a transakcí. To je umožněno eliminací terminálů a vybavením pracovních stanic počítači, které mají své vlastní místní výpočetní zdroje, plně využívané programy v popředí. Na druhou stranu zatížení sítě prudce klesá, protože z klienta na server nejsou přenášeny I/O požadavky (jako u systémů se souborovým serverem), ale SQL požadavky, jejich objem je mnohem menší.

Hlavní výhodou modelu RDA je sjednocení rozhraní „klient-server“ v podobě jazyka SQL. Interakce aplikační komponenty s jádrem DBMS je skutečně nemožná bez standardizovaných prostředků komunikace. Žádosti zaslané programem do jádra musí oba rozumět. K tomu by měly být formulovány speciální jazyk. Ale jazyk SQL již existuje v DBMS, o čemž již byla řeč. Proto je vhodné jej používat nejen jako prostředek pro přístup k datům, ale také jako standard pro komunikaci mezi klientem a serverem.

Takovou komunikaci lze přirovnat k rozhovoru více lidí, kdy jeden odpovídá na otázky ostatních (otázky jsou kladeny současně). A dělá to tak rychle, že se čekací doba na odpověď blíží nule. Vysoké rychlosti komunikace je dosaženo především díky jasné formulaci otázky, kdy tazatel a respondent nepotřebují další konzultace k podstatě problematiky. Tazatelé prohodí pár krátkých jednoznačných frází, nepotřebují si nic vysvětlovat.

Bohužel model RDA není bez řady nedostatků. Za prvé, interakce mezi klientem a serverem prostřednictvím SQL dotazů výrazně zatěžuje síť. Za druhé, uspokojivá správa aplikací v modelu RDA je prakticky nemožná kvůli kombinaci funkcí různé povahy (prezentační a aplikační funkce) v jednom programu.

Spolu s modelem RDA je stále populárnější nadějný model DBS (obrázek 13). Poslední jmenovaný byl v některých implementován relační DBMS(Informix, Ingres, Sybase, Oracle). Je založen na mechanismu uložené procedury- SQL server programovací nástroj. Procedury jsou uloženy v databázovém slovníku, sdíleny mezi více klienty a spouštěny na stejném počítači, kde běží SQL server. Jazyk, ve kterém jsou vyvíjeny uložené procedury, je procedurálním rozšířením jazyka SQL dotazy a je jedinečný pro každý konkrétní DBMS.

Obrázek 13 - Model databázového serveru

V modelu DBS komponenta zobrazení běží na klientském počítači, zatímco komponenta aplikace je navržena jako sada uložených procedur a funguje na počítači databázového serveru. Tam se také spouští komponenta přístupu k datům, tedy jádro DBMS. Výhody modelu DBS jsou zřejmé: je to možnost centralizované správy funkcí aplikace a snížení provozu (místo SQL dotazů jsou po síti odesílána volání uložených procedur) a možnost rozdělení procedury mezi několik aplikací a úspora počítačových prostředků pomocí jednou vytvořeného plánu provádění procedury. Mezi nevýhody modelu patří omezené prostředky používané k zápisu uložených procedur, což jsou různá procedurální rozšíření SQL, která nelze z hlediska vizuálních prostředků a funkčnosti srovnávat s jazyky třetí generace, jako je C nebo Pascal. Rozsah jejich použití je omezen na konkrétní DBMS, většina DBMS postrádá schopnost ladit a testovat vyvinuté uložené procedury.

V praxi se často používají smíšené modely, kdy podpora integrity databáze a některé jednoduché aplikační funkce jsou podporovány uloženými procedurami (model DBS) a další komplexní funkce jsou implementovány přímo v aplikačním programu, který běží na klientském počítači (model RDA). Tak či onak jsou moderní víceuživatelské DBMS založeny na modelech RDA a DBS a při vytváření IS, který zahrnuje použití pouze DBMS, je zvolen jeden z těchto dvou modelů nebo jejich rozumná kombinace.

Obrázek 14.

Model aplikačního serveru.

V AS-modelu (obrázek 14) je proces běžící na klientském počítači odpovědný jako obvykle za uživatelské rozhraní (to znamená, že plní funkce první skupiny). Tento proces hraje roli tím, že požaduje provedení služeb pro komponentu aplikace aplikačního klienta(Aplikace Client-AC). Aplikační komponenta je implementována jako skupina procesů, které provádějí aplikační funkce a nazývá se aplikační server ( Aplikační server - AS). Veškeré operace s informačními zdroji provádí příslušná komponenta, vůči které AS hraje roli klienta. Zdroje dostupné z komponent aplikace různé typy- databáze, fronty, poštovní služby atd.

Modely RDA a DBS jsou založeny na dvouvrstvém schématu rozdělení funkcí. V modelu RDA jsou aplikační funkce přiřazeny klientskému programu, v modelu DBS přebírá odpovědnost za jejich implementaci jádro DBMS. V prvním případě je komponenta aplikace sloučena s komponentou prezentace a ve druhém případě je integrována do komponenty přístupu k informačnímu zdroji. AS-model implementuje třívrstvé schéma oddělení funkcí, kde je komponenta aplikace vyčleněna jako nejdůležitější izolovaný prvek aplikace, k jejímu určení jsou použity univerzální mechanismy multitaskingového operačního systému a rozhraní s dalšími dvěma komponentami jsou standardizované. AS-model je základem pro monitory zpracování transakcí ( Monitory zpracování transakcí – TPM), nebo jednodušeji transakční monitory, které vynikají jako zvláštní druh softwaru.

Na závěr si všimneme, že když mluvíme o databázovém serveru, často se myslí jak počítač, tak software - jádro DBMS. Při popisu architektury "Client-Server" jsme databázovým serverem mysleli počítač. Dále bude databázový server chápán jako software - jádro DBMS.

Podobné informace.