Architektury a technika databázových systémů

Slides:



Advertisements
Podobné prezentace
Tabulky v MS ACCESS Autorem materiálu a všech jeho částí, není-li uvedeno jinak, je Mgr. Jiří Novák.
Advertisements

Obecné praktiky práce s DB
Zpracování SQL Lubomír Andrle 5. přednáška
Přednáška č. 3 Normalizace dat, Datová a funkční analýza
Aplikační a programové vybavení
Business intelligence
 Informací se data a vztahy mezi nimi stávají vhodnou interpretací pro uživatele, která odhaluje uspořádání, vztahy, tendence a trendy  Existuje celá.
DB1 – 9. cvičení Optimalizace dotazu Konkurenční přístup a deadlock Indexace Transakce.
Přednáška č. 5 Proces návrhu databáze
Fakulta elektrotechniky a informatiky
Architektury a techniky DS Tvorba efektivních příkazů I Přednáška č. 3 RNDr. David Žák, Ph.D. Fakulta elektrotechniky a informatiky
PROGRAMOVACÍ JAZYKY (c) Tralvex Yeap. All Rights Reserved.
SQL Lukáš Masopust Historie  Předchůdcem databází byly papírové kartotéky  děrný štítek  1959 konference  1960 – vytvořen jazyk COBOL.
SQL Lukáš Masopust Historie  Předchůdcem databází byly papírové kartotéky  děrný štítek  1959 konference  1960 – vytvořen jazyk COBOL.
A4B33DS & X33MIS Zdeněk Kouba
Radek Špinka Přepínače MSSQL výběr.
Vytvořil: Robert Döring
Úvod do databází Databáze.
Martin Kirschbaum 4.A,  určitá uspořádaná množina informací (dat) uložená na paměťovém médiu  Databázový program - umožňuje tvořit, editovat,
1IT Relační datový model
Databáze Jiří Kalousek.
Analýza informačního systému
Databázové systémy II Přednáška č. 8 – Pohledy (Views)
D ATOVÉ MODELY Ing. Jiří Šilhán. D ATABÁZOVÉ SYSTÉMY Patří vedle textových editorů a tabulkových kalkulátorů k nejrozšířenějším představitelům programového.
Školení správců II. Petr Pinkas RNDr. Vít Ochozka.
Vývoj aplikací pro SharePoint
Architektura databází Ing. Dagmar Vítková. Centrální architektura V této architektuře jsou data i SŘBD v centrálním počítači. Tato architektura je typická.
Relační databáze.
Vypracoval: Ondřej Dvorský Třída: VIII.A
Databázové systémy Architektury DBS.
Metainformační systém založený na XML Autor: Josef Mikloš Vedoucí práce: Ing. Jan Růžička, Ph.D. V/2004.
Informatika pro ekonomy II přednáška 10
Databázové systémy II Přednáška č. X Ing. Tomáš Váňa, Ing. Jiří Zechmeister Fakulta elektrotechniky a informatiky
Číslo šablony: III/2 VY_32_INOVACE_P4_3.8 Tematická oblast: Aplikační software pro práci s informacemi II. Databáze – základy SQL Typ: DUM - kombinovaný.
ZÁKLADY INFORMATIKY DATABÁZOVÉ SYSTÉMY Ing. Roman Danel, Ph.D. Institut ekonomiky a systémů řízení Hornicko – geologická fakulta.
Databázové systémy I Cvičení č. 8 Fakulta elektrotechniky a informatiky Univerzita Pardubice 2013.
Architektury a techniky DS Cvičení č. 9 RNDr. David Žák, Ph.D. Fakulta elektrotechniky a informatiky
Obchodní akademie, Ostrava-Poruba, příspěvková organizace Vzdělávací materiál/DUM VY_32_INOVACE_01B16 Autor Ing. Jiří Kalousek Období vytvoření březen.
Copyright (C) 2000 Vema, a. s.1 V3 klient Michal Máčel Provozní integrace G2, HR/Win a internetu.
uložené procedury (stored procedures) triggery, sekvence, pohledy, funkce, parametrické dotazy (prepared statements) komplexní agregace a SQL dotazy jiné.
organizační struktury Implementace EOS III na Olomouckém kraji Pro:Krajský rok informatiky 2005 Autor:Jan Kadlec Datum:
Databázové modelování
Access Vysvětlení pojmu databáze - 01
Databázové systémy Informatika pro ekonomy, př. 18.
Obchodní akademie, Ostrava-Poruba, příspěvková organizace Vzdělávací materiál/DUM VY_32_INOVACE_01B13 Autor Ing. Jiří Kalousek Období vytvoření březen.
ISSS IS HN/SS Softwarová architektura informačního systému hmotné nouze a sociálních služeb Jindřich Štěpánek
Analýza informačního systému. Podrobně zdokumentovaný cílový stav Paramentry spojené s provozem systému – Cena – Přínosy – Náklady a úspory – …
Delphi a databáze MS SQL Server.
Administrace Oracle Paralelní zpracování.
Databázové aplikace v Delphi
Architektura databází DBS=SŘBD+DB
Databázové systémy I Cvičení č. 8 Fakulta elektrotechniky a informatiky Univerzita Pardubice 2015.
Perzistence XML dat Kamil Toman
24 Používání relačních databází (základní pojmy a principy z oblasti relačních databází, struktura databáze,oblasti použití relačních databází, vkládání.
A jeho praktická aplikace Štěpán Vacek Univerzita Hradec Králové Liberecké informatické fórum 2010.
SOFTWAROVÁ PODPORA PRO VYTVÁŘENÍ FUZZY MODELŮ Knihovna fuzzy procedur Ing. Petr Želasko, VŠB-TU Ostrava.
Databázové systémy Roman Danel Institut ekonomiky a systémů řízení 2016.
Databázové systémy přednáška 8 – Transakce
Unix a Internet 9. SQL server
Budování Integrovaného informačního systému Národního památkového ústavu Petr Volfík, NPÚ ÚP
Databázové systémy I Přednáška 11 Databázové systémy 1 – KIT/IDAS1
Informatika pro ekonomy přednáška 8
Databázové systémy a SQL
Optimalizace SQL dotazů
Roman Péchal, Jan Čongva, Martin Durák
Přednáška 9 Triggery.
Analýza velkých dat strukturovaně či nestrukturovaně?
Vytvořil: Robert Döring
Monitor Object 1.
Transkript prezentace:

Architektury a technika databázových systémů Jiří Zechmeister jiri.zechmeister@unicornsystems.eu 10. přednáška 30.11.2016

Osnova Datová vrstva z pohledu programátora Typické úlohy a problémy SQL tipy Integrace pomocí DB

Přehled vrstev systému

Datová vrstva Služby pro ukládání a načítání dat, dotazování Většinou reprezentovaná relačním databázovým systémem Oracle MS SQL MySQL … Typické objekty Tabulky Pohledy Uložené procedury Časté využití O-R mapování pro přístup k datům z business vrstvy Mapování objektové struktury aplikace na relační strukturu databáze Objektové databáze

Datová vrstva v N-vrstvé aplikaci I

Datová vrstva v N-vrstvé aplikaci II Zajišťuje persistenci dat Zprostředkovává jednotný přístup k datům Typově jde obvykle o OLTP databázi rozšířenou o dávkové zpracování Nejčastější implementace Relační databáze Soubory Objektové databáze

Přístup k datům I. Probíhá pomocí dotazovacích jazyků SQL SQL (Standard Query Language) pro relační databáze OQL (Object Query Language) pro objektové databáze Nativním prostředky dané platformy (např. COM objekty) SQL Standardizováno ANSI normami Neustále se vyvíjí Jednotlivé relační databáze Nepokrývají standardy na 100% Obsahují specifická rozšíření Implementace jednotlivých elementů (např. transakce) nemusí být shodná

Přístup k datům II. Standardizovaná rozhraní (ovladače) Definují API mezi obchodní logikou a databází Unifikují jednotlivá API databázových systémů Případně softwarově simulují chybějící funkce

Přístup k datům III. Nejběžnější API ODBC (standard C) JDBC (Java) ADO (.NET) OLE DB Microsoft specifické řešení postavené na COM objektech Podporuje i nerelační databáze (např. MS Excel) Dosud podporováno zejména v MS SQL

Typické úlohy a problémy

Konkurenční přístup k datům I. Změny prováděné v databázi probíhají v transakcích Tyto transakce splňují tzv. ACID pravidla Atomic Consistent Isolation Durability Přístup k datům je interně řízen pomocí mechanismu zámků Implementace těchto pravidel v jednotlivých databázích není 100% shodné

Konkurenční přístup k datům II. Malé srovnání Oracle a MS SQL

Optimalizace výkonu - indexy Nástroj pro optimalizaci rychlosti přístupu k datům Databáze obvykle automaticky vytvoří index Pod primárním klíčem Pod alternativním klíčem Indexy pod cizími klíči Vhodné téměř ve všech případech, kromě odkazů na číselníkové tabulky o několika málo záznamech Je nutné definovat manuálně Databáze nabízejí specializované typy indexů kromě standardního B-Tree např. clustered, bitmap, full-text

Historická data Jak řešit historická data v tabulkách? Je nutné začít již u datového modelu Historické záznamy musí být identifikovatelné (např. datum vytvoření) Musí být možné udělat konzistentní časový řez daty Možná řešení Pravidelný přesun do historických tabulek Nastavením historizačního flagu (vhodné u menších tabulek) „Historické“ záznamy lze skrýt před BL pomocí pohledů Implementace partitioningu Pomůže eliminovat potřebu historických tabulek Nezachrání chybný návrh, stále je potřeba „partition key“ Oracle nyní podporuje automatické vytváření partition

Sql tipy

Databázové triggery Kdy ano? Pro účely komplexní validace DB scope Pro vytváření speciálních auditních záznamů (autonomními transakcemi) Pro účely komplexní validace Vylepšený check Proč jinde ne? Skryté před vývojáři BL Štěpí BL do více vrstev Obtížně debugovatelné

Funkce ve „where“ klauzuli SQL Obecně jde o „špatný nápad“ Nepředvídatelný počet provedení (závisí na prováděcím plánu). Performance dopad Může vést na skryté implicitní konverze datových typů V N-vrstvé architektuře lze funkci obvykle vyhodnotit v BL Pokud přeci jen není vyhnutí Funkce by měla být deterministická Neprovádí změny stavu db

Výčty v IN klauzuly dotazu Jak řešit dlouhé výčty hodnot v IN operátoru? Příklad: Select kódUC from tPráva where role in (role1, role2, role3, …, roleN) Nevýhody Snížený výkon (každá varianta dotazu je originál) Vede na velmi podobné dotazy (a tím pádem i hash kódy do SQL cache) Dotaz je nutné pokaždé dynamicky skládat Možná řešení Batch operace Oracle podporuje předávání seznamů (polí) Použití vnořeného dotazu může být efektivnější Select kódUC from tPráva where role in (select role from tPřiřazeníRolí where uživatel=uživ1)

Načtení hodnoty atributu do proměnné Oracle Příkaz: select attr into var from table where podmínky Podmínce vyhovuje 0 záznamů: výjimka NO_DATA_FOUND Podmínce vyhovuje více než 1 záznam: výjimka TOO_MANY_ROWS MS SQL Příkaz: select @var = attr from table where podmínky Podmínce vyhovuje 0 záznamů: vrátí hodnotu NULL Podmínce vyhovuje více než 1 záznam: vrátí hodnotu posledního záznamu! Počet nalezených záznamů nutné vyhodnocovat přes proměnnou @@ROWCOUNT ihned po provedení SQL dotazu. Jde o naprosto odlišné chování při stejné operaci!!!

SQL dotazy – filtrování a vyhledávání Co je špatně na tomto kódu? // načte hlášky z logu DataSet ds = execute(„select * from LOG_TABLE“) // vyfiltruje jen chybové hlášky return extractErrors(ds); Filtrujte a vyhledávejte výhradně na datové vrstvě Ulehčíte paměti i procesoru

Taky nezapomeňte … Řazení dat pomocí „order by“ je ovlivněno regionálním nastavením databáze a session, která operaci provádí Oracle podporuje operátor „connect by“ pro procházení stromové struktury Dávkové zpracování v jedné transakci může trvat dlouho V Oracle pouze držíte zámky (celkem levné) V MS SQL držíte serverové zdroje, může dojít k eskalaci zámků a deadlockům Dynamický datový model (vytváření tabulek online) může být možným řešením, ale nejspíš narazíte na odpor DBA

Integrace pomocí DB

Integrace na databázové úrovni Základní principy Oddělení konzumenta od interních datových struktur Každý konzument má obvykle svoje vlastní db objekty tvořící rozhraní Rozhraní používají pokud možno pouze základní datové typy Rozhraní konzument by mělo být snadno odpojitelné Možné implementace Pomocí databázových pohledů / snapshotů S využitím speciálních tabulek Za pomoci nativních prostředků databáze (např. Oracle Streams) Nutné vyřešit synchronizace přístupů k rozhraní Čtení vs zápis (obvykle nebude transakční) Lze implementovat specializovanou řídící tabulkou

Sdílená databáze Základní princip - přístup do „cizí“ DB pro data Přístup přes DB link (A) nebo dedikovaný data source (B) Dávková i online integrace Synchronní i asynchronní

Integrace na DB úrovni - příklad

Sdílená databáze – „online“ integrace „Online“ integrace – přístup na živá data Volání uložené procedury/funkce Přístup do „online“ tabulek Na co si dát pozor Nutná definice formálního rozhraní pro integraci Menší závislost na změnách vnitřních tabulek systému DB zámky na živých datech mohou blokovat online zpracování Řízení zátěže Jemné omezení: povoleny pouze konkrétní operace (přístup přes DB funkci) Hrubé omezení: profily,... Často „quick hack“ integrace Nevyžaduje žádné složité budování infrastruktury Problematický pattern z pohledu mj. škálovatelnosti a údržby … mnohde zakázané

Sdílená databáze – „offline“ integrace Data jsou připravena v dedikovaných tabulkách Přenos dat (celé nebo části) do cílového systému nebo pouze dotazování nad daty Použití Reporting - přímá podpora v reportovacích nástrojích (Cognos) Přenos dat do centralizovaného úložiště (ODS) Na co si dát pozor Stejné jako u online integrace Zamykání není většinou tak kritické

Q & A