| Начало » Использование СУБД » Firebird, HQbird, InterBase » Нужна помощь с проектированием базы Переход к форуму:
	| 
		
			| Нужна помощь с проектированием базы [сообщение #353] | Mon, 22 August 2022 15:25  |  
			| 
				
				|  |  Док Сообщений: 101
 Зарегистрирован: June 2022
 | Senior Member |  |  |  
	| Комрады, нужна помощь. Есть табля с пациентами 
 и табли с определенными видами анализов (в реальном проекте их может быть пару десятков)CREATE TABLE PEOPLE (
    ID   INTEGER NOT NULL,
    FIO  VARCHAR(50)
);
ALTER TABLE PEOPLE ADD CONSTRAINT PK_PEOPLE PRIMARY KEY (ID);с примерно такой структурой:
 
 которые ссылаются на таблицу с пациентами.CREATE TABLE LAB_1 (
    ID          INTEGER NOT NULL,
    FK_PEOLPLE  SMALLINT,
    FLD_DATE    TIMESTAMP DEFAULT current_timestamp NOT NULL,
    FLD_STR1    VARCHAR(10)
);
ALTER TABLE LAB_1 ADD CONSTRAINT PK_LAB_1 PRIMARY KEY (ID);
ALTER TABLE LAB_1 ADD CONSTRAINT FK_LAB_1_1 FOREIGN KEY (FK_PEOLPLE) REFERENCES PEOPLE (ID);
 Вопрос такой: можно ли спроектировать текущую схему таким образом, чтобы для текущего пациента я мог выбирать не только по определенному виду анализа, а показать суммарно все анализы, которые есть в базе для этого пациента?
 
 Скрипт с базой прилагаю
 
 Upd: положил рядом непожатый файл (у кого архив не открывается)
 
	
	 Вложение: test.zip (Размер: 1.14KB, Загружено 1014 раз)
	 Вложение: test.sql (Размер: 4.46KB, Загружено 845 раз)
 
 FPC/Lazarus (trunk) | Win10 x64 Ultim/Debian 11 amd64/Darwin x86_64 Monterey | Firebird 3.0.10 x64 | IBX by TonyWhyman
 
 https://zoltanleo.blogspot.com/
 [Обновления: Mon, 22 August 2022 15:59] Известить модератора |  
	|  |  |  
	|  |  
	|  |  
	|  |  
	|  |  
	|  |  
	| 
		
			| Re: Нужна помощь с проектированием базы [сообщение #359 является ответом на сообщение #357] | Mon, 22 August 2022 16:10   |  
			| 
				
				
					|  pastor Сообщений: 100
 Зарегистрирован: June 2022
 Географическое положение: Калуга
 | Senior Member |  |  |  
	| create domain PK bigint not null; create domain D_NAME varchar(100) not null;
 create domain D_EXAM_VALUE varchar(100) not null;
 create domain D_EXAM_WARN integer;
 create domain D_COMMENT varchar(200);
 create domain D_DATE timestamp not null;
 
 
 create table PEOPLES( -- Пациенты
 ID PK,
 LNAME D_NAME,
 FNAME D_NAME,
 MNAME D_NAME,
 constraint PEOPLES
 primary key(ID)
 );
 
 
 create table EXAM_TYPES( -- Типы анализов
 ID PK,
 NAME D_NAME,
 LOW_RANGE D_EXAM_VALUE,
 HIGH_RANGE D_EXAM_VALUE,
 constraint EXAM_TYPES
 primary key(ID)
 );
 
 create table SURVEYS( -- Обследования
 ID PK,
 ID_PEOPLE PK,
 NUM D_NAME,
 DATE_SUR D_DATE,
 constraint SURVEYS
 primary key(ID),
 constraint SURVEYS_PEOPLE
 foreign key (ID_PEOPLE)
 references PEOPLES(ID)
 );
 
 create table SURVEYS_EXAMS( -- Результаты обследования
 ID PK,
 ID_SURVEYS PK,
 ID_EXAM_TYPE PK,
 EXAM_VALUE D_EXAM_VALUE,
 constraint SURVEYS_EXAMS
 primary key(ID),
 constraint SURVEYS_EXAMS_SUR
 foreign key (ID_SURVEYS)
 references SURVEYS(ID),
 constraint SURVEYS_EXAMS_TYPES
 foreign key (ID_EXAM_TYPE)
 references EXAM_TYPES(ID)
 );
 
 ЗЫ домен D_EXAM_WARN лучше сделать boolean.
 [Обновления: Mon, 22 August 2022 16:11] Известить модератора |  
	|  |  |  
	|  |  
	| 
		
			| Re: Нужна помощь с проектированием базы [сообщение #362 является ответом на сообщение #360] | Mon, 22 August 2022 22:51   |  
			| 
				
				|  |  Док Сообщений: 101
 Зарегистрирован: June 2022
 | Senior Member |  |  |  
	| sim_84 писал(а) Mon, 22 August 2022 16:31 ИХМО. Анализ может быть без обследования (просто человек пришёл сдать анализ для другой клиники), но без пациента быть не может.все верно. Анализы (лабораторные) отдельно, исследования- отдельно. Причем и те, и другие - могут проводится абсолютно вне приема.У всех анализов нужна дата-время, причем несколько. Дата взятия, дата-результата. Возможно ещё какие-нибудь отметки.
 Обследование это далеко не только анализы, там ещё осмотры у специалистов, УЗИ, томография и много чего может быть, а может не быть
 
 Сижу-думаю. Неужели на клиенте придется тупо перебирать все табли и результат в мемдатасет пихать?
  
 Update: интересно, наверное можно "достать" все нужные табли запросом через RDB$RELATION_FIELDS?
 
 
 FPC/Lazarus (trunk) | Win10 x64 Ultim/Debian 11 amd64/Darwin x86_64 Monterey | Firebird 3.0.10 x64 | IBX by TonyWhyman
 
 https://zoltanleo.blogspot.com/
 [Обновления: Mon, 22 August 2022 23:37] Известить модератора |  
	|  |  |  
	|  |  
	|  |  
	| 
		
			| Re: Нужна помощь с проектированием базы [сообщение #365 является ответом на сообщение #364] | Tue, 23 August 2022 09:50   |  
			| 
				
				|  |  Док Сообщений: 101
 Зарегистрирован: June 2022
 | Senior Member |  |  |  
	| sim_84 писал(а) Tue, 23 August 2022 09:26 Я не совсем понимаю в чём сложность вопроса. Все анализы любых типов это одна таблица. Атрибуты - другая. Вытащить всё это по пациенту не вижу сложностейя туплю, сам себе удивляюсь. Даже пытаюсь нарисовать схему на бумаге - не выходит (перетаскал за последние 2 мес 25 тонн дробленого бетона - может, поэтому?).   
 Не совсем понимаю, что подразумевается под словом "аттрибуты". И почему все анализы должны быть в одной табле? в каждом виде анализов великое множество полей. Например:
 
 В каждой табле от полусотни до сотни полей. И таких таблей более 30 шт.CREATE TABLE TBL_LS_BIOCH_CLINIC (
    ID                    INTEGER NOT NULL,
    ISSUE_DATE            DMN_DATETIME,
    CGA                   DMN_STRING_100,
    A1A                   DMN_STRING_100,
    A1AT                  DMN_STRING_100,
    A1AT_NOTE             DMN_BLOBTXT,
    <skiped> 
);
COMMENT ON COLUMN TBL_LS_BIOCH_CLINIC.CGA IS
'Хромогранин А - универсальный маркер нейроэндокринной ткани и различных нейроэндокринных опухолей, чувств 10-100% (< 3 нмоль/л)';
COMMENT ON COLUMN TBL_LS_BIOCH_CLINIC.A1A IS
'A1A - фенотип при ХОБЛ (1 - тяжелая альфа-1-антитрипсиновая недостаточность – PiZZ, Null; 2 - предрасположенность – PiMZ, PiSZ; 3 - не влияют на прогноз - PiMM, PiMS)';
COMMENT ON COLUMN TBL_LS_BIOCH_CLINIC.A1AT IS
'дефицит А1АТ коррелирует с высоким риском развития патологии легких (900-2000 мг/л (медиана около 1300 мг/л) для фенотипа PiMM) ';
COMMENT ON COLUMN TBL_LS_BIOCH_CLINIC.A1AT_NOTE IS
'комментарий к анализу  альфа-1-антитрипсин';
 FPC/Lazarus (trunk) | Win10 x64 Ultim/Debian 11 amd64/Darwin x86_64 Monterey | Firebird 3.0.10 x64 | IBX by TonyWhyman
 
 https://zoltanleo.blogspot.com/
 |  
	|  |  |  
	| 
		
			| Re: Нужна помощь с проектированием базы [сообщение #366 является ответом на сообщение #365] | Tue, 23 August 2022 10:11   |  
			| 
				
				
					|  fraks Сообщений: 152
 Зарегистрирован: June 2022
 Географическое положение: Новосибирск
 | Senior Member |  |  |  
	| Если анализы так разнообразны то в каком интересно виде должно выглядеть > "суммарно все анализы, которые есть в базе для этого пациента"?
 Я как-то себе это слабо представляю...
 
 Зато нормально представляется такое
 
 - Выбираем пациента из списка
 - Получаем список его анализов БЕЗ ДЕТАЛЕЙ, только общие поля, а именно
 - - Дата (даты)
 - - Вид анализа (из которого проистекает в какой таблице хранятся показатели по этому анализу)
 
 Ну и уже далее, когда выбрали нужный анализ - открываем отдельным запросом результаты этого анализа, которые зависят от...
 И, соответственно, на клиенте под каждый тип анализа (под каждую таблицу с деталями) делаем отдельные запросы на получение и форматирование результатов именно этой таблицы.
 
 Еще бы знать - эта структура уже существует и наполнена данными, или пока только схема БД проектируется, а данных нет?
 
 [Обновления: Tue, 23 August 2022 10:30] Известить модератора |  
	|  |  |  
	| 
		
			| Re: Нужна помощь с проектированием базы [сообщение #367 является ответом на сообщение #366] | Tue, 23 August 2022 10:38   |  
			| 
				
				|  |  Док Сообщений: 101
 Зарегистрирован: June 2022
 | Senior Member |  |  |  
	| fraks писал(а) Tue, 23 August 2022 10:11 Если анализы так разнообразны то в каком интересно виде должно выглядетьВсе просто: списочек в виде таблички/плоского дерева с двумя колонками - дата анализа  и название анализа> "суммарно все анализы, которые есть в базе для этого пациента"?
 Я как-то себе это слабо представляю...
 
 fraks писал(а) Tue, 23 August 2022 10:11
 Еще бы знать - эта структура уже существует и наполнена данными, или пока только схема БД проектируется, а данных нет?Пока проектируется. Так что простор для фантазии ничем не ограничен  
 fraks писал(а) Tue, 23 August 2022 10:11
 Зато нормально представляется такоеЯ так в предыдущих постах так и предположил
 - Выбираем пациента из списка
 - Получаем список его анализов БЕЗ ДЕТАЛЕЙ, только общие поля, а именно
 - - Дата (даты)
 - - Вид анализа (из которого проистекает в какой таблице хранятся показатели по этому анализу)
  
 Если воткнуть между таблицами еще одного посредника примерно такой структуры
 
 то запрос типаCREATE TABLE LAB_CASE (
    ID         INTEGER NOT NULL,
    FK_PEOPLE  INTEGER NOT NULL,
    FK_LAB1    INTEGER,
    FK_LAB2    INTEGER
);
ALTER TABLE LAB_CASE ADD CONSTRAINT FK_LAB_CASE_1 FOREIGN KEY (FK_PEOPLE) REFERENCES PEOPLE (ID);
ALTER TABLE LAB_CASE ADD CONSTRAINT FK_LAB_CASE_2 FOREIGN KEY (FK_LAB1) REFERENCES LAB_1 (ID);
ALTER TABLE LAB_CASE ADD CONSTRAINT FK_LAB_CASE_3 FOREIGN KEY (FK_LAB2) REFERENCES LAB_2 (ID);
 все равно вернет неудобоваримый набор с планомSELECT 
    P.FIO FIO
    , L2.FLD_DATE DATE_LAB2
    , L2.FLD_STR2
    , L1.FLD_DATE DATE_LAB1
    , L1.FLD_STR1
FROM (LAB_CASE LC
   JOIN PEOPLE P ON (LC.FK_PEOPLE = P.ID))
   LEFT JOIN LAB_1 L1 ON (LC.FK_LAB1 = L1.ID)
   LEFT JOIN LAB_2 L2 ON (LC.FK_LAB2 = L2.ID)
WHERE FIO CONTAINING 'иванов'
 , который придется конвертировать на клиенте.PLAN JOIN (JOIN (JOIN (P NATURAL, LC INDEX (FK_LAB_CASE_1)), L1 INDEX (PK_LAB_1)), L2 INDEX (PK_LAB_2))
 При текущей архитектуре базы я и подумал про системные таблицы. Вообщем, пока и идей других нет
  
 
 Пс. Интересно, а движок форума не предоставляет возможности форматированный в таблицу текст вставлять?
 
 
	
	 Вложение: scr_090.png (Размер: 7.43KB, Загружено 1439 раз)
 
 FPC/Lazarus (trunk) | Win10 x64 Ultim/Debian 11 amd64/Darwin x86_64 Monterey | Firebird 3.0.10 x64 | IBX by TonyWhyman
 
 https://zoltanleo.blogspot.com/
 [Обновления: Tue, 23 August 2022 10:40] Известить модератора |  
	|  |  |  
	|  |  
	| 
		
			| Re: Нужна помощь с проектированием базы [сообщение #369 является ответом на сообщение #368] | Tue, 23 August 2022 10:46   |  
			| 
				
				|  |  Док Сообщений: 101
 Зарегистрирован: June 2022
 | Senior Member |  |  |  
	| fraks писал(а) Tue, 23 August 2022 10:38 Если хочется одним запросом получать все анализы - то они должны быть в одной табле.Ага, подобную засаду я подозревал :-/Фокус с заранее неизвестным количеством таблиц нормально не прокатит.
 Можно только с клиента тащить из каждой таблицы отдельно.
 
 Собрать на клиенте execute block по мотивам системных таблиц рано или поздно упрется в ограничение количества контекстов в одном запросе (грубо говоря, количества упоминаний таблиц). Или на размер самого запроса.
 Путь чреват тупиком.
 
 
 Что ж, наверное придется на клиенте в цикле тупо перебирать таблицы с анализами и либо "собирать" результаты в мемдатасет, либо делать по типу мастер-деталь, как ты/я и предложили выше
   
 FPC/Lazarus (trunk) | Win10 x64 Ultim/Debian 11 amd64/Darwin x86_64 Monterey | Firebird 3.0.10 x64 | IBX by TonyWhyman
 
 https://zoltanleo.blogspot.com/
 [Обновления: Tue, 23 August 2022 11:02] Известить модератора |  
	|  |  |  
	|  |  
	| 
		
			| Re: Нужна помощь с проектированием базы [сообщение #379 является ответом на сообщение #367] | Wed, 24 August 2022 04:28   |  
			| 
				
				
					|  fraks Сообщений: 152
 Зарегистрирован: June 2022
 Географическое положение: Новосибирск
 | Senior Member |  |  |  
	| Док писал(а) Tue, 23 August 2022 14:38 fraks писал(а) Tue, 23 August 2022 10:11Хм...а тогда в чем проблема? Почему в базе нет именной такой таблички?Если анализы так разнообразны то в каком интересно виде должно выглядетьВсе просто: списочек в виде таблички/плоского дерева с двумя колонками - дата анализа  и название анализа> "суммарно все анализы, которые есть в базе для этого пациента"?
 Я как-то себе это слабо представляю...
 
 
 Док писал(а) Tue, 23 August 2022 14:38
 Посредник неполноценный. Почему в нем нету даты?fraks писал(а) Tue, 23 August 2022 10:11
 Зато нормально представляется такоеЯ так в предыдущих постах так и предположил
 - Выбираем пациента из списка
 - Получаем список его анализов БЕЗ ДЕТАЛЕЙ, только общие поля, а именно
 - - Дата (даты)
 - - Вид анализа (из которого проистекает в какой таблице хранятся показатели по этому анализу)
  
 Если воткнуть между таблицами еще одного посредника примерно такой структуры
 
 CREATE TABLE LAB_CASE (
    ID         INTEGER NOT NULL,
    FK_PEOPLE  INTEGER NOT NULL,
    FK_LAB1    INTEGER,
    FK_LAB2    INTEGER
);
ALTER TABLE LAB_CASE ADD CONSTRAINT FK_LAB_CASE_1 FOREIGN KEY (FK_PEOPLE) REFERENCES PEOPLE (ID);
ALTER TABLE LAB_CASE ADD CONSTRAINT FK_LAB_CASE_2 FOREIGN KEY (FK_LAB1) REFERENCES LAB_1 (ID);
ALTER TABLE LAB_CASE ADD CONSTRAINT FK_LAB_CASE_3 FOREIGN KEY (FK_LAB2) REFERENCES LAB_2 (ID);
 
 Док писал(а) Tue, 23 August 2022 14:38
 то запрос типаС этим запросом тоже непонятно что ты имел ввиду.
 все равно вернет неудобоваримый набор с планомSELECT 
    P.FIO FIO
    , L2.FLD_DATE DATE_LAB2
    , L2.FLD_STR2
    , L1.FLD_DATE DATE_LAB1
    , L1.FLD_STR1
FROM (LAB_CASE LC
   JOIN PEOPLE P ON (LC.FK_PEOPLE = P.ID))
   LEFT JOIN LAB_1 L1 ON (LC.FK_LAB1 = L1.ID)
   LEFT JOIN LAB_2 L2 ON (LC.FK_LAB2 = L2.ID)
WHERE FIO CONTAINING 'иванов'
 , который придется конвертировать на клиенте.PLAN JOIN (JOIN (JOIN (P NATURAL, LC INDEX (FK_LAB_CASE_1)), L1 INDEX (PK_LAB_1)), L2 INDEX (PK_LAB_2))
 При текущей архитектуре базы я и подумал про системные таблицы. Вообщем, пока и идей других нет
  
 Ибо,
 1 - ты клеишь лабы в ширину, по твоим словам этих лаб может быть штук 50, в итоге какая получится таблица? Она же необозримая!
 2 - т.к. кол-во таблиц - не константа, то запрос придется переписывать при добавлении очередной лабы
 3 - ограничение на количество контекстов никто не отменял
 
 А по плану запроса - непонятно какие претензии к плану. Для этого запроса план нормальный, я бы сказал что даже идеальный.
 Непонятно только зачем одновременно искать пациентов и сразу клеить к ним лабы. Пациентов с фамилией иванов наверняка будет много, нужно сначала выбрать пациента, получить его ID и уж потом лезть дальше.
 Соответственно, раз есть containing - то в плане имеется P NATURAL, а все остальные таблицы джойнятся по первичному ключу, максимально эффективно.
 Другой вопрос что сама структура таблиц для такого запроса неидеальна...
 
 |  
	|  |  |  
	| 
		
			| Re: Нужна помощь с проектированием базы [сообщение #380 является ответом на сообщение #379] | Wed, 24 August 2022 06:56   |  
			| 
				
				
					|  fraks Сообщений: 152
 Зарегистрирован: June 2022
 Географическое положение: Новосибирск
 | Senior Member |  |  |  
	| Добавляем справочник типов исследований и список исследований. Получаем ту самую таблицу по которой видим все исследования Иванова, точнее видим перечень исследований, и их даты, но не содержание.
 
 
 И вот так вот получаем искомое - список исследований пациента:CREATE TABLE LAB_SPR (
    ID    INTEGER NOT NULL,
    NAME  VARCHAR(50)
);
ALTER TABLE LAB_SPR ADD CONSTRAINT PK_LAB_SPR PRIMARY KEY (ID);
COMMENT ON TABLE LAB_SPR IS 'Справочник вариантов исследований (анализов)';
/******************************************************************************/
CREATE GENERATOR GEN_LAB_LST_ID;
CREATE TABLE LAB_LST (
    ID          INTEGER NOT NULL,
    ID_LAB_SPR  INTEGER NOT NULL,
    ID_PEOPLE   INTEGER NOT NULL,
    DT          TIMESTAMP NOT NULL
);
ALTER TABLE LAB_LST ADD CONSTRAINT PK_LAB_LST    PRIMARY KEY (ID);
ALTER TABLE LAB_LST ADD CONSTRAINT FK_LAB_PEOPLE FOREIGN KEY (ID_PEOPLE ) REFERENCES PEOPLE  (ID);
ALTER TABLE LAB_LST ADD CONSTRAINT FK_LAB_SPR    FOREIGN KEY (ID_LAB_SPR) REFERENCES LAB_SPR (ID);
SET TERM ^ ;
CREATE OR ALTER TRIGGER LAB_LST_BI FOR LAB_LST
ACTIVE BEFORE INSERT POSITION 0
as
begin
  if (new.id is null) then
    new.id = gen_id(gen_lab_lst_id,1);
end
^
SET TERM ; ^
COMMENT ON TABLE LAB_LST IS 'Список исследований, по всем типам';
INSERT INTO LAB_LST (ID, ID_LAB_SPR, ID_PEOPLE, DT) VALUES (1, 1, 1, '22-AUG-2022 15:21:37');
INSERT INTO LAB_LST (ID, ID_LAB_SPR, ID_PEOPLE, DT) VALUES (2, 1, 1, '16-AUG-2022 00:00:00');
INSERT INTO LAB_LST (ID, ID_LAB_SPR, ID_PEOPLE, DT) VALUES (3, 1, 2, '22-AUG-2022 15:22:08');
INSERT INTO LAB_LST (ID, ID_LAB_SPR, ID_PEOPLE, DT) VALUES (4, 1, 2, '3-AUG-2022 00:00:00');
INSERT INTO LAB_LST (ID, ID_LAB_SPR, ID_PEOPLE, DT) VALUES (5, 1, 3, '22-AUG-2022 15:22:33');
INSERT INTO LAB_LST (ID, ID_LAB_SPR, ID_PEOPLE, DT) VALUES (6, 2, 3, '22-AUG-2022 15:22:48');
INSERT INTO LAB_LST (ID, ID_LAB_SPR, ID_PEOPLE, DT) VALUES (7, 2, 3, '17-AUG-2022 00:00:00');
INSERT INTO LAB_LST (ID, ID_LAB_SPR, ID_PEOPLE, DT) VALUES (8, 2, 1, '26-AUG-2022 00:00:00');
COMMIT;
 select
  people.fio,
  lab_lst.dt,
  lab_spr.name,
  lab_lst.id
from lab_lst
  left join lab_spr on (lab_spr.id = lab_lst.id_lab_spr)
  left join people  on (people.id  = lab_lst.id_people )
where (id_people = 1) -- Иванов
order by
  lab_lst.dt
Ну а далее, соответственно, таблицы с исследованиями должны содержать вместо такого+--------+---------------------+-------+----+
| FIO    | DT                  | NAME  | ID |
+--------+---------------------+-------+----+
| Иванов | 16.08.2022 00:00:00 | LAB_1 | 2  |
| Иванов | 22.08.2022 15:21:37 | LAB_1 | 1  |
| Иванов | 26.08.2022 00:00:00 | LAB_2 | 8  |
+--------+---------------------+-------+----+
 должны быть такимиCREATE TABLE LAB_1 (
    ID          INTEGER NOT NULL,
    FK_PEOPLE   SMALLINT,
    FLD_STR1    VARCHAR(10)
);
 Но при этом придется для просмотра результатов исследований делать процедуру отдельно для каждой таблицы.CREATE TABLE LAB_1 (
    ID          INTEGER NOT NULL,
    ID_LAB_LST  INTEGER NOT NULL,
    FLD_STR1    VARCHAR(10)
);
ALTER TABLE LAB_1 ADD CONSTRAINT FK_LAB1_LST FOREIGN KEY (ID_LAB_LST ) REFERENCES LAB_LST (ID);
 |  
	|  |  |  
	|  |  
	|  |  
	| 
		
			| Re: Нужна помощь с проектированием базы [сообщение #390 является ответом на сообщение #389] | Fri, 26 August 2022 09:58   |  
			| 
				
				
					|  fraks Сообщений: 152
 Зарегистрирован: June 2022
 Географическое положение: Новосибирск
 | Senior Member |  |  |  
	| Док писал(а) Fri, 26 August 2022 12:19 @fraksЯ вообще-то не Леша, а совсем даже ВоваЛеш, спасибо за кучу идей.
  
 Док писал(а) Fri, 26 August 2022 12:19
 Собрал воедино предложенное тобой, вот, что получилось (в виде графов)
 Хотел уточнить: LAB_DAT.VAL - это что?
 
 Да... донести идею я так и не смог.
 Не владею мед. терминами, попробую на пальцах.
 
 -- Таблицы -----------------------------
 PEOPLE  - справочник пациентов
 LAB_SPR - справочник какого типа бывают анализы (ОАК, ОАМ, БиохимияКрови и т.п.)
 DAT_SPR - справочник какого типа бывают параметры в анализах (Билирубин общий, билирубин прямой, кол-во лейкоцитов и т.д.)
 
 LAB_LST - шапки анализов (листик, на котором: в такую-то дату, пациент Иванов, сдал анализы на БиохимиюКрови)
 LAB_DAT - тела анализов (строки на листике: в сданных анализах LAB_LST.ID параметр DAT_SPR.ID имеет значение LAB_DAT.VAL)
 ----------------------------------------
 
 Соответственно, даты имеют смысл только в таблице LAB_LST
 Таблицы LAB_1 и т.п. - не нужны. Эти метаданные записываются в виде записей в таблицах LAB_SPR и DAT_SPR.
 Появляются новые исследования - добавляем записи в справочник анализов LAB_SPR и в справочник параметров анализов DAT_SPR.
 При этом не меняются ни количество таблиц ни запросы.
 
 Единственное неудобство - если у параметров значения измерений не укладываются в какой-либо тип, то придется либо привести его к строке (то самый LAB_DAT.VAL) либо сделать несколько полей под разные типы, например LAB_DAT.VAL_INT INTEGER, LAB_DAT.VAL_NUM NUMERIC(X, Y) и т.п.
 При этом так же можно приводить каждое из значений к строке, что бы простой запрос выдавал это в виде текста сразу, из VAL, для любых типов параметров, а поля конкретных типов использовать только когда нужно сравнить значения на больше/меньше/равно.
 
 На схеме еще не хватает поля и связи, что бы было удобно смотреть в каких анализах какие параметры воззможны, и по каким проведено исследование а по каким не делали. (Например в биохимии, есть параметр билирубин непрямой, можно сделать а можно и не делать. И т.п.)
 DAT_SPR.ID_LAB_SPR -> LAB_SPR.ID
 
 [Обновления: Fri, 26 August 2022 10:00] Известить модератора |  
	|  |  |  
	| 
		
			| Re: Нужна помощь с проектированием базы [сообщение #391 является ответом на сообщение #390] | Fri, 26 August 2022 10:41   |  
			| 
				
				|  |  Док Сообщений: 101
 Зарегистрирован: June 2022
 | Senior Member |  |  |  
	| Прости, Володя. Торможу на каждом шагу   
 Насчет доходчивости объяснений - это целиком моя вина. Огромное спасибо за терпение. Все, что тобой написано, я внимательно читаю и пытаюсь осмыслить - пока не получается.
 
 Щас, чуть воспряну духом и возьмусь. Поглядывай в топик, плз. Ты один остался
   
 Update: все, кажись въехал о_О
 
 Щас причешу табли, наполню данными, выложу сюда графы связей и результаты для ревизии. Спасибо!
 
 FPC/Lazarus (trunk) | Win10 x64 Ultim/Debian 11 amd64/Darwin x86_64 Monterey | Firebird 3.0.10 x64 | IBX by TonyWhyman
 
 https://zoltanleo.blogspot.com/
 [Обновления: Fri, 26 August 2022 11:39] Известить модератора |  
	|  |  |  
	| 
		
			| Re: Нужна помощь с проектированием базы [сообщение #392 является ответом на сообщение #391] | Fri, 26 August 2022 15:08  |  
			| 
				
				|  |  Док Сообщений: 101
 Зарегистрирован: June 2022
 | Senior Member |  |  |  
	| Володя, огромное спасибо за помощь! Принцип понял. Сделал так 
 
  
 на скорую руку автоматически сформировал запрос в билдере
 
 Получил желаемоеSELECT 
    LS.NAME_LAB,
    LL.SEARCH_DATE,
    P.FIO,
    LD.VAL,
    TS.NAME,
    DS.DESCRIPT,
    DS.NAME
FROM PEOPLE P
   INNER JOIN LAB_LST LL ON (P.ID = LL.FK_PEOPLE)
   INNER JOIN LAB_SPR LS ON (LL.FK_LAB_SPR = LS.ID)
   INNER JOIN LAB_DAT LD ON (LL.ID = LD.FK_LAB_LST)
   INNER JOIN DAT_SPR DS ON (LD.FK_DAT_SPR = DS.ID)
   INNER JOIN TISSUE_SPR TS ON (DS.FK_TISSUE = TS.ID)
--------------------------------------------------------------------------------
PLAN JOIN (LL NATURAL, LD INDEX (FK_LAB_DAT_1), P INDEX (PK_PEOPLE), LS INDEX (PK_LAB_SPR), DS INDEX (PK_DAT_SPR), TS INDEX (PK_TISSUE_SPR))
 
  
 Самый большой затык - неинформативные названия таблей
  Пошел править основную базу. Скрипт приложил 
 
	
	 Вложение: test.sql (Размер: 8.13KB, Загружено 801 раз)
 
 FPC/Lazarus (trunk) | Win10 x64 Ultim/Debian 11 amd64/Darwin x86_64 Monterey | Firebird 3.0.10 x64 | IBX by TonyWhyman
 
 https://zoltanleo.blogspot.com/
 [Обновления: Fri, 26 August 2022 15:12] Известить модератора |  
	|  |  | 
 
 
 Текущее время: Fri Oct 31 08:10:01 GMT+3 2025 
 Общее время, затраченное на создание страницы: 0.01152 секунд |