Да бъдеш здрав и във форма е начин на живот, а не мода. Хората, които осъзнават стойността на здравето, го правят приоритет, като водят записи на всичките си факти, свързани с фитнеса. В тази статия ще разгледаме дизайна на базата данни зад приложение за здраве и фитнес.
Има много приложения, които позволяват на потребителите да регистрират информацията си за здравето и фитнеса си. Няколко големи играчи като Apple, Google и Microsoft пуснаха свои собствени API за разработка специално за този пазар. Например Google има „Fit“, а Microsoft има „HealthVault“.
В тази статия ще обясня модела на данни зад приложението за здравни досиета. Първо, нека обсъдим какво точно очакваме да прави такова приложение.
Изисквания за проекта за приложение за здравна информация
По-долу са дадени някои функции, които приложението за здравна информация трябва да поддържа:
- Потребителите могат да създават акаунт и да съхраняват здравна информация за множество профили, т.е. отделно лице може да съхранява здравна информация за всички членове на семейството си.
- Потребителите могат да записват цялата си здравна история, включително имунизации, минали лабораторни резултати, алергии и семейна медицинска история .
- Потребителите могат да съхраняват различни измервания на здравето и фитнеса, като нива на кръвна глюкоза (кръвна захар), кръвно налягане, телесен състав и размери, включително индекс на телесна маса (ИТМ), холестерол, височина, тегло, репродуктивно здраве и др. li>
- Информацията може да бъде записана с помощта на различни методи и мерни единици . Като пример, кръвната глюкоза може да бъде измерена в mg/dL или mmol/L.
- Няма ограничения за това колко информация могат да съхраняват потребителите.
- Системата също така ще поддържа приети здравни стандарти, като например стойности на кръвното налягане или ИТМ, и ще предупреждава потребителите, ако техните числа са извън „безопасни“ или „нормални“ диапазони.
- Потребителите могат също да избират информация (като кръвна глюкоза, височина, тегло и т.н.), която да се показва на личното им табло. По този начин те могат да наблюдават каквото им трябва.
Вместо просто да обясняваме какво прави всеки раздел и таблица в модела на данни, нека да отговорим на някои въпроси за него. Функцията на различните таблици ще стане ясна, докато вървим напред.
Първо, можете да разгледате пълния модел на данни, ако желаете.
Моделът на данните
Отговаряне на въпроси относно модела на данни за здравна информация
Как потребителите могат да съхраняват здравна информация за всички членове на семейството си поотделно?
Първо, нека поговорим за Управление на акаунти и профили . Това може да се постигне с две различни таблици; един (user_account ) за регистриране на данните за хората, които се регистрират с приложението, и един (user_profile ) за регистриране на подробности за всички различни профили, създадени от регистриран потребител. Хората могат да създават редица профили – напр. по едно за всеки от членовете на семейството им.
Нека разгледаме различните таблици, които правят това възможно.
user_account таблицата съдържа основни данни за лицето, което се регистрира с приложението. Неговите колони са:
id– Колона с сурогатен ключ за тази таблица, която идентифицира всеки потребител уникално.login_name– Името или друг идентификатор, който потребителят избира като свое име за вход. На тази колона трябва да се наложи уникално ограничение, за да се гарантира, че всяко име за вход е различно.enc_password– Избраната от потребителя парола за акаунт, в криптирана форма.- адресни колони – Съхранява адрес и данни за контакт за потребителите в момента на регистрация. Тези колони включват
street_address,city,state,countryиzip. Тъй като тези полета са незадължителни в процеса на регистрация, запазих тези колони като нулеви. contact_numberиemail– Съхранява номера за контакт на потребителя (т.е. телефонен номер) и неговия имейл адрес. Тези полета също са част от процеса на регистрация, но не могат да бъдат нулирани.is_active– Задържа „Y“ или „N“, за да посочи дали акаунтът е активен в момента.account_image– На потребителите е разрешено да качват свои собствени изображения. Тъй като потребителят може да качи нула или (максимум) едно изображение на акаунт, това е колона от тип BLOB с нула.
user_profile таблицата съхранява подробности за всички профили, създадени от регистрирани потребители. Колоните в тази таблица са:
id– Уникален номер, присвоен на всеки нов профил.user_account_id– Означава кой потребител е създал профила.user_profile_name– Съхранява името на човека в профила. (Ще наречем това лице „лице с профил“, а потребителят, който създава профилите, „притежател на акаунт“.)relationship_id– Показва връзката между титуляра на акаунта и лицето в профила. Тази колона се отнася доrelationshipтаблица, която съдържа всички възможни видове връзки (като self , майка , баща , сестра , брат , син , дъщеря , домашен любимец и др.).email– Тази колона съдържа имейл адреса на лицето в профила. Отчетите или друга информация ще бъдат споделени с тях чрез този имейл; информация също ще бъде изпратена на титуляра на сметката. Например, ако Мелиса създаде профил за дъщеря си Ева, информацията на Ева ще бъде изпратена до имейла на Мелиса и евентуално до имейла на Ева – вижте по-долу.is_report_sharing_enabled– Отчетите винаги се споделят с притежателя на акаунта, но не е задължително тези данни да се споделят с лицето в профила. Тази колона показва дали информацията ще бъде споделена с лицето в профила.is_active– Идентифицира дали даден профил е активен в момента. Това е мека функция за изтриване в случай, че профилите бъдат изтрити случайно.profile_image– Съхранява изображение на лицето в профила. Този атрибут не е задължителен и следователно може да се нулира.
characteristic_data таблицата съдържа индивидуални данни за профила (като кръвна група), които никога не се променят с течение на времето. Всички колони в тази таблица са обясними сами по себе си с изключение на fitzpatrick_skin_type , който класифицира естеството на нечия кожа, като се започне от I (винаги изгаря, никога не почернява) до VI (никога не изгаря, няма промяна във външния вид при тен).
Добавих две колони за пол; biological_gender означава нечий пол към момента на раждане и current_gender означава текущия пол на лицето от профила. Тази втора колона е приложима само за транссексуални хора и затова я запазих нулева.
Каква жизненоважна информация може да се съхранява в тази система? Как се съхранява?
Сега преминаваме към Управление на здравните данни . Съставът на тялото, нивата на кръвната захар и размерите на тялото се съхраняват в отделни таблици. Въпреки това хората могат да въвеждат повече от един тип информация наведнъж, затова използваме body_vitals_log таблица, за да следите каква информация е влязла в профил и кога е въведена.
Всички жизненоважни статистически данни се съхраняват в следните таблици:
body_composition– Съхранява подробности за различни проценти на телесния състав като мазнини, чиста маса, кости или вода. Също така съдържа стойности на ИТМ (индекс на телесна маса) за индивиди.blood_cholesterol– Съдържа подробности за холестерола като LDL, HDL, триглицериди и общ.body_dimension– Записва размерите на различни области на тялото, като например измерванията на талията или гърдите.body_weight– Съхранява стойности за телесно тегло.body_height– Съдържа стойности за ръста на човек.blood_pressure– Поддържа стойностите на кръвното налягане (систолично и диастолично).blood_glucose– Отчита нивата на кръвната захар.
Повечето от колоните в горните таблици се обясняват сами, с малки изключения. Ще забележите някои допълнителни колони като measurement_method_id , compare_to_normal_id , measurement_unit_id и measurement_context в почти всяка една от тези таблици. Ще обясня тези колони по-късно.
body_vitals_log следи каква информация се записва в даден момент за даден профил. Колоните в тази таблица са:
user_profile_id– Показва кой профил записва информацията.dt_created– Съхранява датата и часа, когато е въведена информацията.data_source_id– Означава източника на данните, като ръководство, електронно устройство и др.- IDs на различни жизнени статистически данни – Запазих всички тези колони с нула, тъй като на потребителите е разрешено да регистрират един или повече елемент наведнъж. Не всички потребители ще искат да проследяват една и съща здравна статистика.
Как можем да накараме системата да работи в различни региони?
Част от информацията се измерва в различни единици в различни области. Например телесното тегло се измерва в килограми в Азия, но се измерва в паундове в Северна Америка. Така че, за да направим това работещо в нашата база данни, се нуждаем от начин за проследяване на мерни единици.
id– Служи като първичен ключ на тази таблица и е този, към който се отнасят другите таблици.measurement_parameter– Означава вида на жизненоважна информация (като тегло, височина, кръвно налягане и др.), която единица измерва.unit_name– Съхранява името на уреда. Помислете за килограм и паунд за тегло, mg/dL и mmol/L за кръвна глюкоза.
Как хората ще разберат дали номерата им са добри?
Нашата система не е много полезна, освен ако не предупреждава хората за рискове за здравето или уязвимости. Ние активираме тази функция, като добавим comparison_to_normal_id колона във всички таблици с данни от жизненоважна информация.
Когато всяка нова жизненоважна информация бъде влязла в системата, записите ще бъдат сравнени със съответните им еталонни стойности и тази колона ще бъде зададена съответно.
Възможните стойности за тази таблица са:
| I | Текст |
|---|---|
| 1 | Не знам |
| 2 | Много по-ниска |
| 3 | Долен |
| 4 | Нормално |
| 5 | По-високо |
| 6 | Много по-високо |
Могат ли потребителите да записват кога са били направени измервания?
Например, потребителите може да се наложи да посочат кога е била измерена кръвната им глюкоза – т.е. преди или след хранене. Или могат да се претеглят и да записват резултатите преди и след тренировка. За да улесня това, добавих колона, measurement_context , в таблиците с жизненоважна информация, които може да се нуждаят от контекстуална информация. Някои възможни стойности за тази колона са показани по-долу:
| Преди закуска |
| След закуска |
| Преди обяд |
| След обяд |
| Преди вечеря |
| След вечеря |
| Преди упражнение |
| След упражнение |
| Гладуване |
| Не на гладно |
| След хранене |
| Преди хранене |
| Преди лягане |
Ами ако човек е диабетик и трябва да следи нивата на кръвната си глюкоза?
Системата, която предлагам, ще има табло, което може да показва жизненоважни статистически данни в графичен формат. Потребителите имат право да избират какво биха искали да виждат на таблото за управление на своя профил и всеки профил има свое собствено табло. Притежателите на акаунти имат право да виждат всички табла за управление на профили, които са създали.
Добавих една колона CHAR(1) за всеки параметър, който може да бъде показан на табло. По подразбиране всички колони ще бъдат попълнени с „N“ (дисплеят е изключен), когато се създаде нов профил. По-късно потребителите могат да променят конфигурацията на таблото си за управление от опция в потребителския интерфейс на приложението.
Как тази система помага на хората да останат във форма?
С други думи, говорим за Съхранение на фитнес данни . Освен здравна информация, системата също така позволява на своите потребители да регистрират информация за тяхната фитнес и рутинни упражнения.
activity_log таблицата е основната таблица в тази предметна област. Той улавя подробности за всякакъв вид профили на дейност, извършвани от хората.
Всяка дейност може да бъде измерена с един или повече от следните три параметъра:
- Начален и краен час – Дейности като спортуване или игри, стоене на опашка и т.н. се измерват по отношение на началния и крайния час. Това се прави чрез
start_timeиend_timeколони вactivity_log. - Изминато разстояние – Дейности като бягане или колоездене се измерват по отношение на изминатото разстояние. Това се съхранява в
distance_coveredколона. - Брой стъпки – Дейности като ходене се измерват по отношение на броя на стъпките, а стойностите се съхраняват в
steps_countколона.
Сигурно се чудите защо calories_burnt колоната е в activity_log маса. Както подсказва името й, тази колона съдържа стойността на калориите, изгорени от лицето в профила, докато извършва определена дейност. Ще обясня как можем да изчислим тези стойности в по-късен раздел.
Създадох една таблица с име activity да поддържате списък на всички възможни дейности. Колоните в тази таблица са:
id– Присвоява уникален идентификационен номер на всяка дейност.activity_name– Съхранява имена на дейности.activity_multiplier– Тази колона играе ключова роля при изчисляването на броя на изгорените калории от хората, извършващи дейности.
Как изчислявате изгорените калории за всяка дейност?
За да разберем как да изчислим изгарянето на калории, първо трябва да разберем BMR на човек или основния метаболизъм. Това ни казва колко калории изгаря тялото в покой. BMR на всеки човек зависи от неговия пол, възраст, тегло и височина. От гледна точка на моделирането на данни, BMR е бавно променящо се измерение и като такова продължава да се променя с времето. Ще съхраняваме най-новите индивидуални стойности на BMR в user_bmr маса.
Има различни методи, използвани за изчисляване на BMR стойности:
Метод № 1:Метод на Харис-Бенедикт
BMR мъже:66 + (6,23 X тегло в паундове) + (12,7 X височина в инчове) – (6,8 X възраст)
BMR жени:655 + (4,35 X тегло в паундове) + (4,7 X височина в инчове) – (4,7 X възраст)
Метод № 2:Метод на Katch-McArdle
BMR (мъже + жени):370 + (21,6 * постна маса в килограм)
Чистна маса =тегло в килограм – (тегло в килограм * телесна мазнина %)
Можем да използваме BMR на човек и споменатия по-горе множител на активността, за да разберем колко калории изгаря човек, когато извършва дадена дейност. Формулата е:
Изгорени калории =множител на активност * BMR
Забележка:И двата по-горе метода за изчисляване на BMR използват едни и същи стойности на множител за дейности. За повече информация вижте тази статия.
Можем ли да запазим историческите BMR стойности на профилите?
да. Можем да архивираме BMR стойности в user_bmr_archive маса.
Започваме с добавяне на една колона, id_version , към съществуващия user_bmr маса. Продължаваме да увеличаваме тази стойност с 1 всеки път, когато се актуализира стойността на BMR на потребител в профила.
user_bmr_archive таблицата е почти реплика на user_bmr маса. Единствената разлика е, че има dt_expired колона вместо dt_created и dt_modified колони. dt_expired колоната съхранява датата, когато версията е станала невалидна, т.е. когато стойността на BMR се актуализира в user_bmr .
Какво, ако потребителите искат да водят запис за своите имунизации, семейна медицинска история и алергии?
Тази система използва следните таблици, за да даде на потребителите възможност да съхраняват допълнителна здравна информация.
immunization таблицата съхранява подробности за имунизациите, получени от хора в профила. След примера ще видите кратко описание на колоните, които тази таблица съдържа:
Пример – Джон Су получи втората от трите дози ваксина срещу хепатит В. Приложена е от д-р Дейвид Мур на 28 ноември 2016 г. Ваксината е направена чрез инжекция в лявата ръка. Произвежда се от Cipla (фармацевтична компания).
id– Първичният ключ на тази таблицаuser_profile_id– Отнася се заuser_profile_IDна Джон Суvaccination_name– „Хепатит В”dt_received– „28 ноември 2016 г.“number_in_sequence– „02“body_area_id– Идентификационният номер на лявата ръка, препратен отbody_areaмасаprovider_name– „Др. Дейвид Мур“how_administered– „Injected“ (другите възможни стойности включват спрей за нос, таблетка, капки, сироп )manufacturer– „Cipla”
allergy таблицата съхранява подробности за всички алергии, изпитани от лицата в профила. По-долу е даден списък с колони, като съответните стойности са дадени за всяка според примера:
Пример – Алисън Д’Суза изпитва кашлица, когато яде кисело мляко. Тя за първи път получи тази реакция, когато беше на 8 години. Тя се консултира с д-р Бил Смит, който предписва някои лекарства и съветва определени предпазни мерки. Тази алергия продължава да съществува, но интензивността й вече е по-ниска.
id– Първичният ключ на таблицатаuser_profile_id– Rотнася се доuser_profile_idна Алисън Д’Сузаallergy_type_id– Отнася се до идентификатора за типа алергия „Храна“ вallergy_typeмаса. (allergy_typeтаблицата определя различни видове алергии като храна, лекарства, околната среда, животински, растителни и др.)allergy_reaction_id– Отнася се до идентификатора на алергичната реакция „кашлица“ вallergy_reactionмаса.first_observed– Дата, на която тази реакция е била наблюдавана за първи път, т.е. когато Алисън е била на 8 години.consulting_doctor_name– „Др. Бил Смит“treatment_brief– Кратко описание на предписаните лекарства и препоръчаните предпазни мерки.does_treatment_cure_allergy– „Частично излекуван. Понижен интензитет на реакцията.”
family_history таблицата съхранява подробности за медицинската семейна история на потребителите. Отново изброихме колоните и типа информация, която ще се съхранява в тях въз основа на следния пример.
Пример – Майката на Даяна Лиза има болест на Паркинсон (неврологично разстройство). Тя е подложена на лечение, но не е получила осезаемо подобрение.
id– първичния ключ на таблицатаuser_profile_id–user_profile_IDна Даяна отuser_profileмасаRelationship_id– Идентификационният номер на „майката“ отrelationshipмасаRelative_name– „Лиза“Date_of_birth– Дата на раждане на ЛизаDate_of_death– NULL (Лиза е все още жива и се бори усилено срещу болестта.)Condition_brief– Кратко описание как, кога и къде е започнало състоянието, консултации, евентуално облекчение и т.н.Current_status– „Текущ“ (Други възможни състояния са „Прекъснато“ и „Минало“.)How_it_ended– NULL
Какво бихте добавили към този модел на данни?
Системата позволява на хората да знаят колко калории изгарят, докато извършват различни дейности, но не проследява колко калории консумират или колко питателен е изборът им на храна. Освен това системата им позволява да записват своите фитнес данни на дневна база, но не им позволява да си поставят цел, да формулират план и да проследяват напредъка си, така че да останат мотивирани.
Трябва ли да обмислим вграждането на тези функции в него? Какви промени трябва да се направят, за да се добавят тези функции?
Кажете ни вашите идеи!
