sql >> Databáze >  >> RDS >> Database

Databázové modelování

Napsal jsem píseň o dentální niti, ale vyčistily se někomu zuby?

Frank Zappa

Když přemýšlíme o zubní ordinaci, naše první asociace jsou vrtačka, bolest a strach. Dobře, to zní špatně. Kromě péče o zuby má zubař mnoho dalších povinností, které jsou profesionální, právní nebo obojí. Všechny vyžadují správnou správu dat.

Ke splnění tohoto požadavku na dokumentaci používá mnoho zubních a lékařských ordinací papírové záznamy. Pomalu, ale jistě však existuje trend směrem k digitálním záznamům a správě 21. století.

Uvnitř ordinace zubního lékařství

Návštěva zubaře není něco, na co obvykle vzpomínáme s radostí. Když jsme měli štěstí, uhnuli jsme bolesti, ale naše peněženka pravděpodobně těžce utrpěla. Poté, co vstoupíme do zubní ordinace, postup je obvykle následující:

  • Oba se zapojíte do krátkého rozhovoru. (Často nepříjemné, protože jste svému zubaři slíbili, že ho navštívíte příští týden a uplynuly 2 roky. Pak řeknete, že jste zapomněli, on souhlasí a je zase vše v pořádku.)
  • Vy sedíte na židli a on si prohlíží vaše záznamy o předchozí léčbě. Zeptá se, zda se něco stalo od poslední návštěvy, a zda došlo k aktualizaci vašeho zdravotního záznamu.
  • Podívá se do vašich úst, aby zjistil, co se pokazilo, a řekne vám, co to napraví.
  • Můžete souhlasit s jeho léčebným plánem nebo zvolit jinou možnost.
  • O několik měsíců později máte na tváři opět hollywoodský úsměv. Bylo by to dříve, ale nemohli jste se usmívat, dokud jste konečně nezaplatili celý účet za svou zubní práci.

V tuto chvíli si ani ten nejoddanější databázový profesionál pravděpodobně nemyslí:‚Páni, kéž by pro tuto zkušenost existoval datový model!‘ . Ale existuje a stojí za to to prozkoumat. Vytiskli jsme jej tedy níže.

Představujeme model naší databáze zubní ordinace




Myšlenkou tohoto modelu je pokrýt každý postup od chvíle, kdy poprvé vstoupíme do zubní ordinace, až do vyřešení problému. Součástí tohoto modelu (tabulky označené user_account , status , user_has_status , role , user_has_role ) byl představen a popsán v předchozích článcích. Možná se zde role a statusy zdají zbytečné, ale nezapomeňte, že v ordinaci může být i sestra pro zpracování anamnézy (záznam), recepční, student zubního lékařství, několik vyškolených zubních asistentů nebo dokonce návštěva specialisty či hygienistky. Platební údaje však nebudou v tomto článku brány v úvahu.

Tabulky v zubní databázi

patient tabulka je jednou ze dvou nejdůležitějších tabulek v databázi. Uchovává data pacientů a je propojen s dokumenty a návštěvami pacientů. S výjimkou mail , všechny atributy v tabulce jsou povinné:

  • name – jméno pacienta
  • surname – příjmení pacienta
  • identification_number – toto pole se používá k uložení jedinečného ID klienta, které se používá v reálném světě
  • address – adresa pacienta
  • phone – telefonní číslo pacienta
  • mail – e-mailovou adresu pacienta

Druhá nejdůležitější tabulka v databázi je visit . Při kombinaci s tabulkou patient , ukládá informace o události, která spustila všechny následující akce. Atributy v tabulce jsou:

  • visit_date – obsahuje skutečné datum a čas návštěvy
  • patient_id – souvisí id pacienta s jeho návštěvou
  • dentist_id – je odkaz na user_has_role stůl, za předpokladu, že role je zubař

Další na řadě je anamnesis stůl. V medicíně je anamnéza postup, kdy shromažďujeme a uchováváme historii lékařských údajů, jako je aktuální stav pacienta. anamnesis tabulka tato data ukládá. Vzhledem k tomu, že k tomu dojde brzy po našem příchodu do kanceláře, budeme mít maximálně jednu anamnézu na událost. Atributy v tabulce jsou:

  • anamnesis_id – je primárním klíčem anamnesis tabulka, která také odkazuje na visit stůl
  • user_anamnesis_id – to se týká user_has_role stůl. Všimněte si, že zubař nemusí být tím, kdo provedl anamnézu.
  • notes – obsahuje textové poznámky ke konkrétní anamnéze. Není to povinné pole.

anamnesis_type tabulka je jednoduchý slovník, který se používá k uložení všech možných hodnot, na které se odkazuje v anamnesis_catalog . Jediný atribut je type_name a může obsahovat hodnoty jako „nemoc“, „alergie“, „použitý lék“. Tento jediný atribut je samozřejmě povinný.

anamnesis_catalog tabulka je slovník, který poskytuje konkrétnější informace než hodnoty uložené v anamnesis_type stůl. Použijeme jej k uchování údajů o konkrétních onemocněních, alergiích a lécích. Všechny atributy jsou povinné a zahrnují:

  • catalog_name – je název konkrétního anamnesis_type podkategorie
  • anamnesis_type_id – je odkaz na anamnesis_type stůl

visit_anamnesis tabulka slouží k propojení údajů o návštěvách s hodnotami z katalogu anamnéz. Každý atribut v tabulce je povinný:

  • anamnesis_anamnesis_id – je odkaz na anamnesis stůl
  • anamnesis_catalog_id – je odkaz na anamnesis_catalog stůl

Všimněte si, že visit_anamnesis tabulka je relace many-to-many spojující tabulky označené anamnesis a anamnesis_catalog . Tento pár nemá smysl ukládat (anamnesis_anamnesis_id &anamnesis_catalog_id ) dvakrát. Tento pár použijeme jako primární klíč.

document tabulka je jednoduchý katalog obsahující místa, kam jsme uložili dokumenty pacientů. Příklady takových dokumentů mohou být skeny tabulek pacientů, rentgenové snímky a faktury. Tyto dokumenty samozřejmě nebudeme ukládat přímo do databáze. Toto je hrubé zjednodušení systému správy dokumentů. Atributy v document tabulka jsou (všechny jsou povinné):

  • description – je krátký popis dokumentu
  • location – obsahuje přesné umístění dokumentu
  • patient_id – je odkaz na patient stůl

tooth tabulka je jednoduchý slovník, který se používá později, když zubař určí, který zub byl problém. Všechny atributy v této tabulce jsou povinné. Jsou to:

  • is_baby_tooth – je booleovská hodnota, která jednoduše označuje, zda je zub mléčný nebo ne. Samozřejmě budeme mít duplicitní hodnoty pro zuby, které mohou být obojí. To je důležité, protože postup se může lišit podle typu zubu.
  • tooth – je popis používaný pro práci zubu – obecně se tato hodnota zobrazí na obrazovce.

problem_catalog tabulka je další jednoduchý slovník. Obsahuje seznam všech možných problémů, které se běžně vyskytují na zubech nebo v ústech. Příklady možných hodnot pro tento katalog jsou:„zubní kaz“, „eroze zubů“, „gingivitida“, „vředy v ústech“ nebo „neatraktivní úsměv“. Pouze problem_name atribut je povinný.

problem_detected tabulka propojuje data o návštěvách, zubech a problémech s treatment stůl. Obsahuje odkazy na tooth , problem_catalog a visit tabulky. Všechny atributy jsou povinné kromě tooth_id . Důvodem této výjimky je, že některé problémy se nevztahují pouze na jeden zub (např. zánět dásní se týká dásní). Tyto tři atributy dohromady tvoří alternativní klíč (UNIQUE). Další dva atributy jsou:

  • suggested_treatment_id je odkaz na treatment stůl (léčba navržená zubním lékařem). Může to být hodnota NULL, když je vše v pořádku a nepotřebujeme žádnou léčbu.
  • selected_treatment_id je další odkaz na treatment stůl. Obsahuje údaje o ošetření zubního lékaře a pacienta, který souhlasil s použitím. To může být NULL, možná proto, že pacient potřebuje čas na rozmyšlenou navrženou léčbu a další možnosti.

Všimněte si, že atributy suggested_treatment_id a selected_treatment_id oba odkazují na treatment stůl. Můžeme to udělat, protože potřebujeme uložit maximálně dvě hodnoty. Samozřejmě, pokud předem nevíme, kolik hodnot chceme uložit, měli bychom zde použít vztah many-to-many.

step tabulka je jednoduchý slovník obsahující všechny možné kroky ve všech ošetřeních. Atributy (všechny jsou povinné) v tabulce jsou:

  • step_name – je krátký název kroku používaný na obrazovce
  • description – je popis akcí provedených během tohoto kroku

treatment tabulka je ve skutečnosti slovníkem všech ošetření, která zubní ordinace poskytuje. Protože většina ošetření se obvykle skládá z několika kroků, musíme vědět, který krok je konečný. Všechny atributy v tabulce jsou povinné:

  • treatment_name – je název ošetření v rámci systému
  • description – je krátký popis léčby
  • final_step_id – je odkaz na step stůl. Tyto informace můžeme použít ke zjištění, zda léčba skončila a zahájit automatickou akci, nebo můžeme tyto informace jednoduše ukázat uživateli a nechat ho vybrat si další akci.

treatment_steps tabulka je vztah mnoho k mnoha, který spojuje kroky s léčbou. Povinné atributy v tabulce jsou:

  • treatment_id – je odkaz na treatment stůl
  • step_id – je odkaz na step stůl
  • step_order – je číslo, které definuje pořadí kroků v léčbě

V této tabulce jsou definovány dva alternativní klíče (UNIQUE):

  • spárovat (treatment_id &step_id ) – tento krok lze přiřadit k ošetření pouze jednou
  • spárovat (treatment_id &step_order ) – ošetření nemůže mít dva kroky se stejným objednacím číslem

visit_steps tabulka je seznam všech kroků, které byly po této návštěvě skutečně provedeny. Jsou dva důvody, proč je chceme ukládat do samostatných tabulek:

  1. Možná jsme zvolili léčbu, ale nepotřebujeme pro ni definované všechny kroky a
  2. Tímto způsobem uložíme skutečný čas, kdy byl krok proveden.

Atributy v tabulce (všechny jsou povinné kromě problem_detected_id a notes ) jsou následující:

  • visit_id – je odkaz na visit stůl
  • treatment_steps_id – je odkaz na treatment_steps stůl
  • problem_detected_id – je odkaz na problem_detected stůl. Tento vztah nám poskytuje informace o tom, jaký problém tuto akci inicioval. Může být NULL, když se zubař rozhodne provést nějakou akci, která nesouvisí s žádným zjištěným problémem.
  • step_time – je datum a/nebo čas, kdy byl krok skutečně proveden
  • notes – jsou poznámky k tomuto kroku, pokud je to potřeba

visit_status tabulka je jednoduchý slovník používaný k ukládání všech možných stavů, které by návštěva mohla mít. Mohli bychom použít stavy jako „první návštěva v ordinaci vůbec“, „první návštěva“, „probíhá léčba“, „léčba úspěšně dokončena“. Obsahuje pouze jeden atribut, status_name , což je povinné.

visit_status_history tabulka slouží k ukládání dat o stavech, kterými návštěva prošla. Myšlenka je taková, že stav přidáme ručně po dokončení určitých akcí (např. po anamnéze, po dokončení několika kroků nějaké léčby). Atributy, které jsou všechny povinné, následují:

  • status_time – je datum/čas, kdy byl vložen stav
  • visit_status_id – je odkaz na visit_status stůl
  • visit_id – je odkaz na visit stůl

Možná vylepšení modelu dentální databáze

Náš model je na dobré cestě, ale mohl by být vylepšen. Nevztahuje se například na následující položky:

  • platební metody a faktury
  • plánování schůzek (i když to lze provést vložením dat do visit_steps tabulka pro budoucí události)
  • zpracování dokumentů

Přesto vás to nutí přemýšlet o své zubní ordinaci a jejích postupech jinak, že?


  1. Jak mohu zastavit skript Postgres, když narazí na chybu?

  2. Shromažďování přírůstkových statistik v 11g

  3. Porozumění cloudovému sledování výkonu SQL Serveru

  4. Oracle PL/SQL:Příklad UTL_FILE.FCOPY