Databáze 2a - Databázové systémy
ฝัง
- เผยแพร่เมื่อ 25 ก.ค. 2024
- Teoretický úvod do databázových systémů a návrhu databáze.
00:00 - Databázové systémy
04:15 - Databázové zkratky
06:25 - Struktura databáze
11:09 - Vlastnosti databázové tabulky
13:53 - Datové modely
14:10 - Postup návrhu databáze
15:10 - ERM - Entitně-relační model (diagram)
18:25 - Transformace na relační model (textový)
20:34 - Relační datový model
21:51 - Datový model
22:59 - Relace (vztahy)
25:55 - Typy (kardinalita) vztahu
29:10 - Reprezentace jednotlivých typů vztahů
30:38 - Normalizace
32:53 - 1. NF
33:42 - 2. NF
34:41 - 3. NF
36:38 - Datové typy
44:31 - Závěr
Celá série o databázích: • Základy databází
Materiály: github.com/PetrVobornik/predn...
naucilo vic nez ctyri roky na me skole, dekuju
Super video, přehledně vysvětleno vše důležité, děkuji.
Super video, jdu zkouknout další a děkuju. :) Konečně dobrý zdroj informací, když školy budou zavřený.
Děkuji za přednášku, velmi pěkně zpracované video.
Díky
Výborné video. Těším se na další díly.
Díky, mám je v plánu, bude-li mít tento úvod úspěch.
Perfektní díky. Díky vám mi došlo dost věcí které pro mě byli španělskou vesnicí. Doufám že bude pokračování.
Díky, pokusím se.
Super video díky
Děkuji za perfektní video a těším se na další. Super!
Díky, něco už se chystá ;)
Super video hlavně srozumitelný palec nahoru
Díky
Díky !
díky moc
Nice, to se v karanténě hodí
Díky, už dělám na další části o transakcích.
Moc pěkně vysvětlené. Koukám, že nakonec v dalších videích (kromě jednoho) již nepokračujete, velká škoda..
Pokračuji, jen to teď přes další povinnosti nejde tak rychle, ale určitě zase brzy něco vydám. Předtočeného toho mám ještě spoustu, a další semestr už snad půjde nahrát i něco nového. Střih videí někdy streamuji na Twitchi.
Pěkné poučné video, díky moc. Jen bych krátce reagoval na minutu 29, kde se mluví o tom, že jedna položka nemá více faktur. Vzhledem k tomu, že je možné v některých obchodech vrátit nechtěné zboží po Vánocích (člověk obdrží dva stejné dárky), tak v podstatě přichází i varianta přesunout "Faktury -> Položky" do relace M:N.
Teoreticky máte pravdu, že jde o stejný kus zboží, ale prakticky se to takto neeviduje. Při Vašem nákupu obchod vystaví fakturu (nebo účtenku) s položkami, kde je uvedeno toto zboží. Když pak budete zboží vracet, tak Vám vystaví nový doklad, konkrétně by to měl být dobropis (faktura v mínusu) a tam se ta položka zapíše znovu (účetní doklady musí být stejné i po letech, takže se obvykle nespoléhají jen na reference jako je IdZboží, ale do položek se přepíší i veškeré jeho údaje). Maximálně se u dokladu dá reference na fakturu, aby byl zaznamenán vztah mezi těmito dvěma doklady, možná, kdyby se vracelo všechno, by se systém dal naprogramovat i tak, že dobropis jen bude zobrazovat položky této připojené faktury s mínusovými částkami, ale vztah M:N položek a faktur by to nebyl. Tedy naprogramovat by to samozřejmě šlo, ale myslím, že by to byla jen zbytečná účetně neprůchozí komplikace. Pár takových systémů už jsem vytvářel, a ještě více zkoumal, ale s takovouto variantou jsem se dosud nesetkal.
Celý semestr shrnut v jednom videu. Děkuji
Díky. Je to ale záznam jen z první úvodní přednášky v semestru ;)
A ještě bych měl dotaz. Mám programování jako koníček a momentálně programuji dle potřeby kamarádů a známých jen samostatné desktopové aplikace za pomoci Lazarusu a SQLite, ale chtěl bych zkusit vytvořit něco v architukteře client-server. Jaký databázový systém byste mi mohl doporučit? Zatím mě napadají jen Firebird nebo PostgreSQL, protože jsou zdarma, ale nevím, který z nich by mohl být pro mne vhodnější. Moc děkuji za případnou radu / doporučení.
Dříve jsem používal Firebird, který je na menší projekty skutečně úžasný, teď ale pracuji spíše s MS SQL Serverem (verze Express je zdarma). SQLite je dobrý na skutečně malé projektíky, kdy k databázi přistupuje jen jeden uživatel, čili ideální třeba pro mobilní aplikace (viz např. zde th-cam.com/video/mb8xvo9CBXM/w-d-xo.html). SQL Server už je potřeba na cílovém zařízení nainstalovat a udělat z něho jakoby DB server, byť třeba lokální, což se hodí třeba k webovým aplikacím, nebo právě k tomu client-server v nějaké vnitřní síti. Firebird nicméně toto také zvládne, pro webovou DB bych asi radil spíš ten SQL server, ale jako client-server je určitě plnohodnotný DBS. Navíc má embedded verzi, která šla s aplikací používat i bez instalace, jen s pomocí knihovny, což se také hodí, když třeba to SQLite už nedostačuje. S Firebirdem jsem vytvářel několik client-server systémů ještě v Delphi + i pár NETu, z nichž jeden stále nonstop běží už 16 let.
@@PetrVobornik Z toho tedy usuzuji, že pro mé hobby využití bude pro client-server úplně stačit Firebird. Dříve jsem si trochu pohrával s myšlenkou použít MySQL. Bohužel po informaci od WEDOSu (u většiny provozovatelů to bude asi podobné), že přístup k MYSQL je u nich z aplikací třetích stran zablokován, mě tento nápad přešel - lze ho ale uskutečnit na vlastním webovém serveru. Ještě bych měl jeden dotaz a pak už nebudu otravovat. :-) Je dle Vašeho názoru lepší na samostatnou aplikaci pro jednoho uživatele zůstat u SQLite nebo rovnou používat Firebird ve verzi embedded? Myslím si, že pak by možná bylo snadnější, kdyby se samostatná aplikace chtěla předělat na client-server.
Databáze by nikdy neměla být dostupná přímo pro celý internet, ani na vlastním serveru, byť nastavit to možné je. Pokud to má být centrální databáze pro nějaké klientské aplikace, tak se s ní obvykle komunikuje přes API, buď vlastním nebo třeba REST (representational state transfer). To by naopak mohlo fungovat na kterémkoli serveru či hostingu.
Firebird je dobrá volba pro aplikace client-server v rámci lokální sítě. Tedy například když ve firmě mají server, tam se Firebird server nainstaluje a počítače v této síti se připojují přímo k němu a pracují přímo s jeho daty (např. dispečer tam zadává zakázky, skladníci je vyskladňují a tisknou k tomu faktury, účetní účtuje, šéf to hlídá atd.). K databázi se však nejde připojit z venčí (z internetu mimo tuto lokální síť), když už, tak leda přes VPN, která zařídí, že je dotyčný do této sítě připojen přes šifrovaný tunel.
U aplikací pro jednoho uživatele přijde na to, v jaké budou konkrétně technologii. Moderní aplikace UWP či multiplatformní appky pro mobily spíš SQLite, u desktopových aplikací (WPF či Windows Forms) může být klidně Firebird embedded. Případně to lze propojit a lokální uživatelovu databázi synchronizovat s nějakou centrální (např. v této appce to tak mám: www.basic-numbers.com; SQLite na mobilní části, na serveru MS SQL), (nebo zde jsem použil Firebird jak pro lokální firemní client-server část, tak i na centrálním webovém serveru, kde to ale komunikovalo přes vlastní API: www.petrvobornik.cz/projekty/16-zakazky/18-transsyscare?showall=1).
Jeden říká, že relace není vztah, ale je to tabulka (prof. z VŠB), druhý že je to vztah, tak jak to tedy je? Začínám v tom mít pěkný guláš 🙃
Relací je obvykle označován vztah (též "vazba") mezi dvěma tabulkami. V případě kardinality 1:1 nebo 1:N se řeší cizím klíčem, v případě M:N se řeší spojovací tabulkou (třeba tím bylo myšleno toto?) se dvěma cizími klíči na obě ve skutečnosti propojované tabulky, čímž se vlastně tento typ vztahu změní na 1:N a M:1 (což je zase 1:N). Databázový systém si (většinou, některé to mohou řešit i jinak) na pozadí tyto informace o relacích ukládá do systémové tabulky, tak jestli tím nebylo myšleno třeba toto? Asi bych musel vidět tu větu či část přednášky celou, abych ji mohl potvrdit a vysvětlit, nebo vyvrátit.
@@PetrVobornik Děkuji za tak rychlou odpověď, zde je odkaz na video.
https: //youtu . be/2xvKTAKAsRo
Zmínka o relaci je v čase 53:37
Odkaz odeslán se záměrnými mezerami, jelikož je tu nejspíše nastaveno automatické mazání komentářů ve kterých se vyskytuje URL odkaz.
Aha, tak zde na to pan kolega jde trochu více teoreticky, matematicky a historicky, ale proč ne. To že relace je tabulka sahá do základních definic a matematických modelů prvotních databází z roku 1970. Tam se definovaly i vztahy mezi jednotlivými hodnotami, aby se vůbec mohlo popsat co je tabulka. Resp. ono se to děje i teď, jelikož v rámci DB souboru, je také každá hodnota ukládána samostatně a ten vztah (relace) s ostatními se tam musí nějak zajistit (ať již vzájemnou pozicí, nebo odkazem na jiné místo v souboru). Takže ano, z tohoto hlediska je relace, anglicky "relation", tabulka a odtud je i název relační databáze.
Nicméně vztahy (či vazby) mezi tabulkami se anglicky nazývají "relationships". Jelikož "vztah" či "vazba" mají v češtině více významů, a zároveň i vzhledem k tomu, že v databázových systémech se už od jejich prvních verzí neřeší vztahy mezi hodnotami (ty řeší na pozadí ty systémy) a prostě se jen "vytvoří tabulka", tak se ono "relationships" počeštilo na "relace" a v odborné veřejnosti (myšleno programátory používající databáze) se tomu tak říká. Netvrdím samozřejmě že úplně všude, ale tam kde jsem působil, tak ano. Každopádně v teoretickém akademickém prostředí lze samozřejmě bazírovat i na přesné terminologii a doslovných definicích, byť praxe má pak své vlastní názvosloví a spousta z toho je v ní irelevantní, pokud tedy nehodláte být vývojářem přímo databázových systémů. Já jsem spíše praktik, načež se to snažím vysvětlovat tak, aby to v praxi mohli používat i mí studenti, a přitom nezabředávat do úplných detailů, aby je to hned z kraje neodradilo.
@@PetrVobornik Děkuji za objasnění. 🙂