Dotaz: Návrh databáze

[jsk]

Zdravím,

potřebuji poradit s návrhem db. Zdrojová data jsou v tabulce o 15 sloupcích. Tři z nich se vztahují k účastníkům JMÉNO, POHLAVÍ, ČINNOST. Počet je obvykle 1–3 osoby, ale někdy i osm. Tj. pro 5 osob je 5 jmen např.:

1: Jan Novák; 2: Pavel Nový, bratr; 3: Jana Stará; 4: Jan Pil; 5: Lada Malá, sestra | 1: muž; 2: muž; 3: žena; 4: muž; 5: žena | 1: nosič; 2: tavič; 3: prodavačka; 4: vodák; 5: kuchařka

Tabulka neobsahuje primární klíč, ten bych asi generoval. Počet řádků by měl být do 100.000, sběr dat ještě probíhá.

Sloupce obvykle obsahují text poznámek, jednou příjmení, jedenkrát datum, to také ve formátu dne v týdnu (pondělí – neděle), jednou název obce.

Nemám s návrhem db zkušenosti, budu tedy moc rád pokud mne navedete rozumným směrem, děkuji předem všem.

Pepa

PS: není to žádný školní úkol, chci jen pomoci synovi zpracovat data resp. z nich něco vytáhnout, jde o jeho zájem nikoliv o školní zadání.

Odpovědi

[jiwopene]

Předpokládám, že jde třeba o záznamy účastníků na schůzi (to chápu z toho „Počet je obvykle 1–3 osoby“). Nejspíše není, takže si tabulky a sloupce dle účelu popřejmenovávejte.

Asi takto:

CREATE TABLE schuze (
  schuze_id SERIAL PRIMARY KEY,
  datum TIMESTAMP WITH TIME ZONE NOT NULL
);

CREATE TABLE osoba (
  osoba_id SERIAL PRIMARY KEY,
  jmeno TEXT NOT NULL,
  prijmeni TEXT NOT NULL,
  zena BOOLEAN NOT NULL,
  cinnost_id INTEGER REFERENCES cinnost (cinnost_id) NOT NULL,
  poznamka TEXT
);

CREATE TABLE osoba_na_schuzi (
  osoba_id INTEGER REFERENCES osoba (osoba_id) NOT NULL,
  schuze_id INTEGER REFERENCES schuze (schuze_id) NOT NULL,
  PRIMARY KEY (osoba_id, schuze_id)
);

CREATE TABLE cinnost (
  cinnost_id SERIAL PRIMARY KEY,
  nazev_cinnosti TEXT NOT NULL UNIQUE
);

Přečtěte si Database normalization na anglicé Wikipedii (popř. české, tam je také pěkný článek). V relační databázi je snaha oddělit data od prezentace, takže například Vaše „jedenkrát datum, to také ve formátu dne v týdnu“ je nerozumné. Když dáte do databáze datum (s pomoci typu TIMESTAMP WITH TIME ZONE), je netřeba určovat den v týdnu. Databáze s tím snáz pracuje a až v SELECTu nebo v aplikaci si z toho uděláte textové datum. (PostgreSQL to dělá i implicitně.)

Totéž platí pro činnosti – vyndáme je do samostatné tabulky a můžeme si tak činnost representovat číslem (tím usnadníme práci počítači) a můžeme přidávat informace k činnostem.

Osoby stejně tak máme zvlášť – pak můžeme zapsat to, že na jedné schůzce byla jedna a tatáž osoba. (Pokud to nevíte, tak použijte vazbu 1 (schůzka) : N (osob), tedy to, že se zbavíme osoba_na_schuzce a schůzku referencujeme z osoby jako činnost.)

Kód jsem netestoval, je napsaný pro PostgreSQL.

Pokud uvedete bližší podrobnosti o datech a účelu, mohu poradit dále.

[_]

zena BOOLEAN NOT NULL

Děláš si srandu? A pojmenovávat věci česky je znak amatérismu.

[jiwopene]

Čeština mi v tomto případě připadá vhodnější – tazatel potom nemusí umět cizí jazyk. Pokud by šlo o kód, o kterém předpokládám, že bude někde použit tak, jak je, budu používat anglická pojmenování.

K tomu značení pohlaví: Tazatel měl v ukázce dat v jeho příspěvku pouze hodnoty „muž“ a „žena“, takže jsem navrhnul strukturu, do které je možné uložit tato data, aniž bych po něm chtěl naučit se hned ze začátku používat výčtové typy v databázi (tvrdí, že s návrhem DB nemá zkušenosti). Pokud by se tazatel zmínil i o jiných hodnotách, samozřejmě bych použil odpovídající řešení (u předem známého počtu hodnot výčtový typ, jinak další tabulku).

[Kit]

Spíš bych měl výhrady k tomu typu boolean. Má ji/nemá ji?

[jiwopene]

Také s tím mám trochu problém (a běžně v databázi používám pro tento údaj výčtový typ, popř. (v SQLite) integer), ale předpokládám, že tazatel s databázemi moc ještě neumí a tak ho nechci zatěžovat výčtovým typem (a při použití integeru si v tom člověk snadno udělá bordel, nepoznamená-li si hodnoty).

Neříkám, že se ten sloupec musí jmenovat zena. Může to být i muz, nebo cokoliv (tedy např. i Vámi zmiňované „má ho“/„má ji“), co tazateli bude vyhovovat.

[AraxoN]

V roku 2021 a len dve pohlavia? Fujky, akí spiatočníci! Na pohlavie už len varchar!

[Kit]

Na pohlaví jen JPEG.

[AraxoN]

Nad tým sa ťažko píše SQL príkaz... ako urobíš SELECT DISTINCT z jpegu?

[Josef Kufner]

V tomto případě je DISTINCT zbytečný.

[jsk]

Příloha:

• vzorek-dat.ods (26707 bytů)

Dobrý den,

moc děkuji za pomoc, napsal bych hned, ale zdržel jsem se pár dní ve špitále .

Někdy cca před 25 lety jsem sesmolil aplikaci v Accessu a před pár roky jsem z Google kalendáře pomocí SQLite3 a hromadné korespondence v Inkscape vyráběl pro kamaráda faktury pro lektory, takže zkušenosti vlastně nulové. Data se týkají rozhodnutí pražského apelačního soudu z období raného novověku. Zvažoval jsem použít DB Maria, na PostgreSQL jsem si netroufal. Data jsou pořizována prostřednictvím MS Excel, já však uvažuji o řešení v Ubuntu. Normalizaci si musím nastudovat, už si z toho nic praktického nepamatuji .

Pepa

Autorská legenda k příloze:

• Kniha jedná o inventární číslo, pod kterým je kniha evidována ve fondu Apelační soud, Praha, který je deponovaný v Národním archivu v Praze
• Fol zkratka slova folium, jinými slovy list knihy
• Čin určení kategorie trestného činu
• Datum den vydání soudního rozhodnutí v dané věci
• Den den v týdnu, který bylo vydáno soudní rozhodnutí
• Soudce jméno soudce, který danou věc zpracovával a připravoval rozhodnutí
• Místo obec či osoba, které je rozhodnutí adresováno
• Pachatel osoba souzená pro trestný čin (může být zavádějící v případech, kdy je dotyčný osvobozen)
• Pohlaví určení pohlaví pachatele
• Předmět bližší popis trestné činu, jeho speficikace (místy velice variabilní, místy naopak bez dalšího rozlišení)
• Trest určení trestu pro pachatele trestného činu (případně osvobození)
• Missiva určení, zda k rozhodnutí soudu byla připojena missiva, či nikoli; missiva je přípis, který konkretizoval výkon trestu či stanovoval další postup ve vyšetřování
• Poznámka poznamenání dalších relevantních skutečností, které jsou méně frekventované
• Oběť jméno či jiné určení osoby, která byla obětí spáchání trestného činu
• Další zdroje a Další zdroje II prostor pro doplnění odkazu na další archivní materiály, které by se vztahovaly k danému případu (trestní spis, matriční záznamy…)

[zdenek2008]

Na analyzu pravnich dat existuje rada nastroju, ty zaznamy by se daly do nektereho importovat. Nejlepe asi hledat neco ve stylu 'free legal case management package'. Dale existoval projekt Debian-Lex (snad neco z toho prezilo dodnes) a v Kali Linuxu je sikovna aplikace CaseFile.

Namatkou:

https://tadesite.com/legal-case-management-software/

https://www.goodfirms.co/blog/best-free-open-source-legal-case-management-software-solutions

Drzim palce.

[zdenek2008]

a pak ses probudil s rukou v nocniku.

[OldFrog {Ondra Nemecek}]

Příloha:

• Snímek obrazovky pořízený 2021-05-05 16-15-37.png (118402 bytů)

Nejnázorněji je struktura databáze vidět na ER diagramu. Hned vidíte, jak jsou data uložena. V příloze posílám screenshot z DBeaver, je zdarma, funguje s většinou existujících databází a zobrazení diagramů má integrované.

[jsk]

Děkuji Vám za tip podívám se na to.