At være sund og rask er en livsstil, ikke en mode. Folk, der indser værdien af sundhed, gør det til en prioritet, idet de holder optegnelser over alle deres fitness-relaterede fakta. I denne artikel vil vi undersøge designet af databasen bag en sundheds- og fitnessapplikation.
Der er mange applikationer, som lader brugere logge deres helbreds- og fitnessoplysninger. Et par store spillere som Apple, Google og Microsoft har lanceret deres egne udviklings-API'er specifikt til dette marked. For eksempel har Google 'Fit', og Microsoft har 'HealthVault'.
I denne artikel vil jeg forklare datamodellen bag en ansøgning om sundhedsjournaler. Lad os først diskutere præcis, hvad vi forventer, at sådan en app gør.
Projektkrav til en Health Info App
Nedenfor er nogle funktioner, som en sundhedsinfo-app bør understøtte:
- Brugere kan oprette en konto og gemme helbredsoplysninger for flere profiler, dvs. en person kan gemme helbredsoplysninger for alle deres familiemedlemmer.
- Brugere kan registrere hele deres helbredshistorie, inklusive immuniseringer, tidligere laboratorieresultater, allergier og familiehistorie .
- Brugere kan gemme forskellige målinger af sundhed og kondition, såsom blodsukkerniveauer (blodsukker), blodtryk, kropssammensætning og dimensioner, herunder kropsmasseindeks (BMI), kolesterol, højde, vægt, reproduktiv sundhed osv.
- Information kan registreres ved hjælp af forskellige metoder og måleenheder . Som et eksempel kan blodsukker måles i mg/dL eller mmol/L.
- Der er ingen grænser for, hvor meget information brugere kan gemme.
- Systemet vil også holde accepterede sundhedsstandarder, såsom blodtryk eller BMI-tal, og vil advare brugere, hvis deres tal falder uden for "sikre" eller "normale" områder.
- Brugere kan også vælge oplysninger (såsom blodsukker, højde, vægt osv.), der skal vises på deres personlige dashboard. På denne måde kan de overvåge, hvad de har brug for.
I stedet for blot at forklare, hvad hver sektion og tabel gør i datamodellen, lad os besvare nogle spørgsmål om det. Funktionen af de forskellige borde bliver tydelige efterhånden.
Først kan du se på den komplette datamodel, hvis du vil.
Datamodellen
Besvarelse af spørgsmål om Health Info Data Model
Hvordan kan brugere gemme helbredsoplysninger for alle deres familiemedlemmer individuelt?
Lad os først tale om Konto- og profilstyring . Dette kan opnås ved at have to forskellige borde; én (user_account ) for at logge detaljerne for personer, der registrerer sig med applikationen, og en (user_profile ) for at logge detaljer for alle de forskellige profiler, som en registreret bruger opretter. Folk kan oprette en række profiler – f.eks. en for hver af deres familiemedlemmer.
Lad os se på de forskellige tabeller, der gør dette muligt.
user_account tabel indeholder grundlæggende detaljer om den person, der tilmelder sig applikationen. Dens kolonner er:
id– En surrogatnøglekolonne for denne tabel, der identificerer hver bruger unikt.login_name– Navnet eller andet ID, som brugeren vælger som deres login-navn. En unik begrænsning skal pålægges denne kolonne for at sikre, at hvert loginnavn er forskelligt.enc_password– Den brugervalgte kontoadgangskode i krypteret form.- adressekolonner – Gemmer adresse og kontaktoplysninger for brugere på tidspunktet for registrering. Disse kolonner inkluderer
street_address,city,state,countryogzip. Da disse felter er valgfrie i registreringsprocessen, har jeg beholdt disse kolonner som nullable. contact_numberogemail– Gemmer brugerens kontaktnummer (dvs. telefonnummer) og deres e-mailadresse. Disse felter er også en del af registreringsprocessen, men de kan ikke nulstilles.is_active– Indeholder enten et 'Y' eller et 'N' for at angive, om en konto er aktiv i øjeblikket.account_image– Brugere har lov til at uploade deres egne billeder. Da en bruger kan uploade nul eller (maks.) ét billede pr. konto, er dette en nullbar BLOB-type kolonne.
user_profile tabel gemmer detaljer om alle profiler oprettet af registrerede brugere. Kolonnerne i denne tabel er:
id– Et unikt nummer tildelt hver ny profil.user_account_id– Angiver, hvilken bruger der har oprettet profilen.user_profile_name– Gemmer navnet på personen i profilen. (Vi kalder denne person for "profilpersonen", og brugeren, der opretter profilerne, "kontoindehaveren".)relationship_id– Angiver forholdet mellem kontohaveren og profilpersonen. Denne kolonne henviser tilrelationshiptabel, som indeholder alle mulige typer relationer (såsom selv , mor , far , søster , bror , søn , datter , kæledyr osv.).email– Denne kolonne indeholder profilpersonens e-mailadresse. Rapporter eller andre oplysninger vil blive delt med dem via denne e-mail; oplysninger vil også blive sendt til kontohaveren. For eksempel, hvis Melissa oprettede en profil for sin datter Eva, ville Evas oplysninger blive sendt til Melissas e-mail og muligvis til Evas e-mail - se nedenfor.is_report_sharing_enabled– Indberetninger deles altid med kontohaveren, men det er valgfrit at dele disse data med profilpersonen. Denne kolonne viser, om oplysninger vil blive delt med profilpersonen.is_active– Identificerer, om en profil er aktiv i øjeblikket. Dette er en blød sletningsfunktion i tilfælde af at profiler slettes ved et uheld.profile_image– Gemmer et billede af profilpersonen. Denne attribut er valgfri og kan derfor nulstilles.
characteristic_data tabel indeholder individuelle profildetaljer (som blodgruppe), der aldrig ændrer sig over tid. Alle kolonnerne i denne tabel er selvforklarende undtagen fitzpatrick_skin_type , som klassificerer karakteren af ens hud startende fra I (altid brænder, bliver aldrig brun) til VI (brænder aldrig, ingen ændring i udseende, når den bliver solbrun).
Jeg har tilføjet to kolonner for køn; biological_gender betegner ens køn på fødselstidspunktet og current_gender angiver profilpersonens nuværende køn. Denne anden spalte gælder kun for transkønnede, og derfor har jeg holdt den ugyldig.
Hvilke vitale oplysninger kan gemmes i dette system? Hvordan opbevares det?
Nu går vi videre til Sundhedsdatastyring . Kropssammensætning, blodsukkerniveauer og kropsdimensioner er gemt i separate tabeller. Men folk kan indtaste mere end én type oplysninger ad gangen, så vi bruger body_vitals_log tabel for at holde styr på, hvilke oplysninger der er logget ind på en profil, og hvornår de indtastes.
Alle vitale statistikker opbevares i følgende tabeller:
body_composition– Gemmer detaljer om forskellige kropssammensætningsprocenter som fedt, mager masse, knogler eller vand. Den indeholder også BMI-værdier (body mass index) for enkeltpersoner.blood_cholesterol– Indeholder kolesteroldetaljer som LDL, HDL, triglycerider og total.body_dimension– Registrerer dimensionerne af forskellige kropsområder, såsom målene på taljen eller brystet.body_weight– Gemmer værdier for kropsvægt.body_height– Indeholder værdier for en persons højde.blood_pressure– Holder blodtrykstal (systolisk og diastolisk).blood_glucose– Registrerer blodsukkerniveauer.
De fleste af kolonnerne i ovenstående tabeller er selvforklarende med nogle få undtagelser. Du vil bemærke nogle yderligere kolonner såsom measurement_method_id , compare_to_normal_id , measurement_unit_id og measurement_context i næsten hver eneste af disse tabeller. Jeg vil forklare disse kolonner senere.
body_vitals_log holder styr på, hvilke oplysninger der logges på et givet tidspunkt for en profil. Kolonnerne i denne tabel er:
user_profile_id– Viser, hvilken profil der logger oplysningerne.dt_created– Gemmer dato og klokkeslæt, når oplysningerne indtastes.data_source_id– Angiver kilden til dataene, såsom en manual, en elektronisk enhed osv.- ID'er af forskellige vitale statistikker – Jeg har holdt alle disse kolonner nullable, da brugere har lov til at logge et eller flere emner ad gangen. Ikke alle brugere vil spore de samme sundhedsstatistikker.
Hvordan kan vi få systemet til at fungere i forskellige regioner?
Nogle oplysninger måles i forskellige enheder i forskellige områder. For eksempel måles kropsvægten i kilogram i Asien, men den måles i pund i Nordamerika. Så for at gøre dette brugbart i vores database, har vi brug for en måde at spore måleenheder på.
id– Fungerer som den primære nøgle i denne tabel, og det er den, som andre tabeller henviser til.measurement_parameter– Angiver typen af vital information (såsom vægt, højde, blodtryk osv.), som en enhed måler.unit_name– Gemmer navnet på enheden. Tænk på kilogram og pund for vægt, mg/dL og mmol/L for blodsukker.
Hvordan ved folk, om deres tal er gode?
Vores system er ikke megen hjælp, medmindre det advarer folk om sundhedsrisici eller sårbarheder. Vi aktiverer denne funktion ved at tilføje comparison_to_normal_id kolonne i alle vitale informationsdatatabeller.
Når enhver ny vital information logges ind i systemet, vil registreringer blive sammenlignet med deres tilsvarende benchmarkværdier, og denne kolonne vil blive sat i overensstemmelse hermed.
Mulige værdier for denne tabel er:
| I | Tekst |
|---|---|
| 1 | Ved ikke |
| 2 | Meget lavere |
| 3 | Sænke |
| 4 | Normal |
| 5 | Højere |
| 6 | Meget højere |
Kan brugere registrere, hvornår der blev foretaget målinger?
For eksempel kan brugere have brug for at oplyse, hvornår deres blodsukker blev målt - dvs. før eller efter et måltid. Eller de kan veje sig selv og registrere resultaterne før og efter træning. For at lette dette har jeg tilføjet en kolonne, measurement_context , i de vitale informationstabeller, der kan have brug for kontekstuel information. Nogle mulige værdier for denne kolonne er vist nedenfor:
| Før morgenmad |
| Efter morgenmad |
| Før frokost |
| Efter frokost |
| Før middag |
| Efter middag |
| Før træning |
| Efter træning |
| Fastende |
| Ikke-fastende |
| Efter måltid |
| Før måltid |
| Før sengetid |
Hvad hvis en person er diabetiker og har behov for at overvåge deres blodsukkerniveauer?
Det system, jeg foreslår, vil have et dashboard, der kan vise vital statistik i et grafisk format. Brugere har lov til at vælge, hvad de gerne vil se på deres profil-dashboard, og hver profil har sit eget dashboard. Kontoindehavere har tilladelse til at se alle de profil-dashboards, de har oprettet.
Jeg har tilføjet en CHAR(1) kolonne for hver parameter, der kan vises på et dashboard. Som standard vil alle kolonner være udfyldt med 'N' (visning er slået fra), når en ny profil oprettes. Brugere kan senere ændre deres dashboard-konfiguration fra en mulighed i appens brugergrænseflade.
Hvordan hjælper dette system folk med at holde sig i form?
Med andre ord, vi taler om Fitness Data Storage . Udover helbredsoplysninger giver systemet også deres brugere mulighed for at logge oplysninger om deres fitness- og træningsrutiner.
activity_log tabel er hovedtabellen i dette emneområde. Det fanger detaljer om enhver form for aktivitetsprofil personer udfører.
Hver aktivitet kan måles med en eller flere af følgende tre parametre:
- Start- og sluttidspunkt – Aktiviteter som at dyrke sport eller spil, stå i kø osv. måles på start- og sluttidspunkt. Dette gøres via
start_timeogend_timekolonner iactivity_log. - Tillagt afstand – Aktiviteter som løb eller cykling måles i forhold til tilbagelagt distance. Dette er gemt i
distance_coveredkolonne. - Trintal – Aktiviteter som at gå måles i antal skridt, og værdierne gemmes i
steps_countkolonne.
Du må undre dig over, hvorfor calories_burnt kolonnen er i activity_log bord. Som navnet antyder, indeholder denne kolonne værdien af kalorier forbrændt af profilpersonen, mens han udfører en bestemt aktivitet. Jeg vil forklare, hvordan vi kan beregne disse værdier i et senere afsnit.
Jeg har oprettet en tabel ved navn activity at føre en liste over alle mulige aktiviteter. Kolonnerne i denne tabel er:
id– Tildeler et unikt ID-nummer til hver aktivitet.activity_name– Gemmer aktivitetsnavne.activity_multiplier– Denne kolonne spiller en nøglerolle i beregningen af antallet af kalorier, der forbrændes af folk, der udøver aktiviteter.
Hvordan beregner du de forbrændte kalorier for hver aktivitet?
For at forstå, hvordan man beregner kalorieforbrænding, skal vi først forstå en persons BMR eller basalstofskifte. Dette fortæller os, hvor mange kalorier en krop forbrænder i hvile. Hver persons BMR afhænger af deres køn, alder, vægt og højde. Fra et datamodelleringsperspektiv er en BMR en langsomt skiftende dimension, og som sådan bliver den ved med at ændre sig med tiden. Vi gemmer de seneste individuelle BMR-værdier i user_bmr bord.
Der er forskellige metoder, der bruges til at beregne BMR-værdier:
Metode # 1:Harris-Benedict-metoden
BMR Mænd:66+ (6,23 X vægt i pund) + (12,7 X højde i tommer) – (6,8 X alder)
BMR Kvinder:655+ (4,35 X vægt i pund) + (4,7 X højde i tommer) – (4,7 X alder)
Metode# 2:Katch-McArdle-metoden
BMR (mænd + kvinder):370+ (21,6 * mager masse i kilogram)
Lean Mass =vægt i kilogram – (vægt i kilogram * kropsfedt %)
Vi kan bruge en persons BMR og aktivitetsmultiplikatoren nævnt ovenfor til at finde ud af, hvor mange kalorier en person forbrænder, når han laver en given aktivitet. Formlen er:
Forbrændte kalorier =aktivitetsmultiplikator * BMR
Bemærk:Begge ovenstående BMR-beregningsmetoder bruger de samme multiplikatorværdier for aktiviteter. For mere information, se denne artikel.
Kan vi beholde profilernes historiske BMR-værdier?
Ja. Vi kan arkivere BMR-værdier i user_bmr_archive bord.
Vi starter med at tilføje én kolonne, id_version , til den eksisterende user_bmr bord. Vi bliver ved med at øge denne værdi med 1, hver gang en profilpersons BMR-værdi opdateres.
user_bmr_archive tabellen er næsten en replika af user_bmr bord. Den eneste forskel er, at den har en dt_expired kolonnen i stedet for dt_created og dt_modified kolonner. dt_expired kolonnen gemmer datoen, hvor versionen blev ugyldig, dvs. når BMR-værdien opdateres i user_bmr .
Hvad hvis brugere ønsker at føre et register over deres vaccinationer, familiehistorie og allergier?
Dette system udnytter følgende tabeller til at give brugerne mulighed for at gemme yderligere helbredsoplysninger.
immunization tabel gemmer detaljer om immuniseringer modtaget af profilpersoner. Efter eksemplet vil du se en kort beskrivelse af de kolonner, som denne tabel indeholder:
Eksempel – John Soo modtog den anden af tre doser af en hepatitis B-vaccine. Den blev administreret af Dr. David Moore den 28. november 2016. Vaccinationen blev givet ved en indsprøjtning i venstre hånd. Det er fremstillet af Cipla (et medicinalfirma).
id– Denne tabels primære nøgleuser_profile_id– Refererer tiluser_profile_IDaf John Soovaccination_name– "Hepatitis B"dt_received– "28. november 2016"number_in_sequence– "02"body_area_id– Id'et på venstre hånd, henvist frabody_areabordprovider_name– "Dr. David Moore"how_administered– "Injiceret" (andre mulige værdier omfatter næsespray, tablet, dråber, sirup )manufacturer– "Cipla"
allergy tabel gemmer detaljer om eventuelle allergier oplevet af profilpersoner. Nedenfor er listen over kolonner med de relevante værdier angivet for hver i eksemplet:
Eksempel – Alison D’Souza oplever en hoste, når hun spiser yoghurt. Hun havde første gang denne reaktion, da hun var 8 år gammel. Hun konsulterer Dr. Bill Smith, som ordinerer noget medicin og rådgiver om visse forholdsregler. Denne allergi fortsætter stadig, men dens intensitet er lavere nu.
id– Tabellens primære nøgleuser_profile_id– Rrefererer tiluser_profile_idaf Alison D’Souzaallergy_type_id– Refererer til ID'et for "Fødevare"-allergitypen iallergy_typebord. (allergy_typetabel definerer forskellige allergityper som mad, medicin, miljø, dyr, planter osv.)allergy_reaction_id– Refererer til ID'et for 'Hoste'-allergireaktionen iallergy_reactiontabel.first_observed– Datoen, hvor denne reaktion først blev observeret, dvs. da Alison var 8 år gammel.consulting_doctor_name– "Dr. Bill Smith”treatment_brief– En kort beskrivelse af de ordinerede lægemidler og anbefalede forholdsregler.does_treatment_cure_allergy– “Delvist helbredt. Nedsat reaktionsintensitet.”
family_history tabel gemmer detaljer om brugernes medicinske familiehistorie. Igen har vi angivet kolonnerne og typen af information, der ville blive gemt i dem baseret på følgende eksempel.
Eksempel – Dianas mor Lisa har Parkinsons sygdom (en neurologisk lidelse). Hun har været i behandling, men har ikke fået nogen mærkbar bedring.
id– tabellens primære nøgleuser_profile_id– Dianasuser_profile_IDfrauser_profilebordRelationship_id– 'mor'-id'et frarelationshipbordRelative_name– "Lisa"Date_of_birth– Lisas fødselsdatoDate_of_death– NULL (Lisa er stadig i live og kæmper hårdt mod sygdommen.)Condition_brief– En kort beskrivelse af hvordan, hvornår og hvor tilstanden startede, konsultationer, eventuel lindring osv.Current_status– 'Nuværende' (Andre mulige statusser er 'Intermitterende' og 'Fortid'.)How_it_ended– NULL
Hvad ville du tilføje til denne datamodel?
Systemet lader folk vide, hvor mange kalorier de forbrænder, mens de udfører forskellige aktiviteter, men det sporer ikke, hvor mange kalorier de indtager, eller hvor nærende deres madvalg er. Desuden giver systemet dem mulighed for at registrere deres fitnessdata på daglig basis, men det lader dem ikke sætte et mål, formulere en plan og spore deres fremskridt, så de forbliver motiverede.
Skal vi overveje at bygge disse funktioner ind i det? Hvilke ændringer skal der foretages for at tilføje disse funktioner?
Fortæl os dine ideer!