2020-01-14
86
Поддержание бизнес-логики является еще одной задачей при разработке базы данных. Бизнес-логика - логика выполнения бизнес-процесса по определённым правилам, называемым еще бизнес-правилами. Так, при анализе предметной области из главного процесса «Учесть затраты на оказанные медицинские услуги» было выделено 5 подпроцессов:
Ø Фиксировать полученную документацию;
Ø Получить документацию;
Ø Сформировать заявку;
Ø Оформить платёжное поручение;
Ø Получить извещение об оплате.
База данных строилась таким образом, чтобы хранить всю входную и формировать выходную документацию, полученную в результате выполнения основного бизнес-процесса. В этой главе мы рассмотрим, какие объекты базы данных были созданы для обеспечения этого требования.
При рассмотрении первого подпроцесса (Фиксировать полученную документацию) появилась необходимость создания отношений, соответствующих входным потокам данных. Так появились отношения Talon и Karta с атрибутами, входящими в словарь данных (Курсовой проект по дисциплине ИТ). Создание отношения Talon осуществлялось следующим образом:
|
|
|
CREATE TABLE Talon
(Number INT PRIMARY KEY NOT NULL,
Date DATETIME,
Type varchar(30),
IDLPU INT,
IDVrach INT,
IDPacient INT,
IDType INT,
CONSTRAINT TalonLPUforeign FOREIGN KEY(IDLPU) REFERENCES LPU,
CONSTRAINT TalonVrachforeign FOREIGN KEY(IDVrach) REFERENCES Vrach,
CONSTRAINT TalonTypeforeign FOREIGN KEY(IDType) REFERENCES Type,
CONSTRAINT TalonPacientforeign FOREIGN KEY(IDPacient) REFERENCES Pacient)
Зесь следует отметить, что каждый статистический талон может содержать несколько диагнозов, таким образом появилось отношение DiagnTalon (Диагноз в талоне):
CREATE TABLE DiagnTalon
(IDTalon INT,
IDDiagnos INT,
Ishod varchar(30),
Type varchar(30),
CONSTRAINT PK_Foreign PRIMARY KEY(IDTalon,IDDiagnos),
CONSTRAINT TalonDiagnforeign FOREIGN KEY(IDTalon) REFERENCES Talon ON DELETE CASCADE,
CONSTRAINT DiagnTalonforeign FOREIGN KEY(IDDiagnos) REFERENCES Diagnos)
Особенностью этого отношения является опция ON DELETE CASCADE при ограничении внешнего ключа. Это позволяет автоматически удалить все диагнозы при удалении какого-либо статистического талона. Такое удаление подобно реальному удалению документа, при этом все данные, связанные с ним, также удаляются. Конечно же, использование этой опции необходимо не особенно часто, лучшее применение она находит именно в слабых сущностях, как и в этом случае.
Аналогичным образом были созданы отношения Karta, Prikas и Isveshenie, которые предназначены для хранения информации из входной следующей документации - карта выбывшего больного, приказ и извещение об оплате. Входной поток информации Нормы на лечение материализовался в виде отношения Diagnos, где стала храниться информация о диагнозах и сроках их лечения. Создание отношения Diagnos:
CREATE TABLE Diagnos
(IDDiagnos INT IDENTITY PRIMARY KEY,
NameDiagnos varchar(50),
ShifrDiagnos varchar(20),
Norma INT)
Документ Прейскурант цен на медицинские услуги нашел свое выражение в отношениях Type (Специальность врача) и Otdel (Отделение), в которые в качестве атрибутов вошли тарифы по определённой специальности и отделению.
|
|
|
CREATE TABLE Otdel
(IDOtdel INT IDENTITY PRIMARY KEY,
Name varchar(30),
IDLPU INT,
TarifOtdel MONEY,
CONSTRAINT OtdelLPUforeign FOREIGN KEY(IDLPU) REFERENCES OtdelLPU)
Выходной документ Платежное поручение формируется с помощью хранимой процедуры на основании определённого приказа об оплате. Входными параметрами для процедуры являются NameLPU (Наименование ЛПУ) и Date (Дата приказа об оплате).
CREATE PROC Poruchenie
@NameLPU varchar(50),
@Date DateTime
AS
SELECT NameLPU,MestoLPU,Date,BeginPer,EndPer,Summa
FROM Prikas
INNER JOIN LPU
ON Prikas.IDLPU=LPU.IDLPU
WHERE LPU.NameLPU=@NameLPU AND Prikas.Date=@Date
Еще одним выходным документов автоматизируемого процесса является З аявка на финансирование, в которую входят суммы для финансирования отдельных ЛПУ за период. Входными параметрами для процедуры являются даты начала и конца периода. Сама же процедура реализована следующим образом: считаются суммы отдельно для стационара (в подзапросе) и для поликлиники, затем две полученные суммы складываются и дают таким образом окончательный результат. Для формирования заявки был написан следующий сценарий, создающий хранимую процедуру:
CREATE PROC GetZayavka
@Begin DateTime,
@End DateTime
AS
SELECT LPU.NameLPU,LPU.MestoLPU,SUM(TarifType)+Stacionar.Summa[Summa]
FROM Talon
INNER JOIN Type
ON Talon.IDType=Type.IDType
INNER JOIN LPU
ON Talon.IDLPU=LPU.IDLPU
INNER JOIN (SELECT LPU.IDLPU,SUM(TarifOtdel*(Norma*1.15))[Summa]
FROM Karta
INNER JOIN LPU
ON Karta.IDLPU=LPU.IDLPU
INNER JOIN OtdelLPU
ON OtdelLPU.IDLPU=LPU.IDLPU
INNER JOIN Otdel
ON Otdel.IDOtdel=OtdelLPU.IDOtdel
INNER JOIN DiagnKarta
ON Karta.IDKarta=DiagnKarta.IDKarta
INNER JOIN Diagnos
ON Diagnos.IDDiagnos=DiagnKarta.IDDiagnos
WHERE Karta.DateEnd BETWEEN @Begin AND @End AND DiagnKarta.Type='основной'
GROUP BY LPU.IDLPU) Stacionar
ON LPU.IDLPU=Stacionar.IDLPU
WHERE Talon.Date BETWEEN @Begin AND @End
GROUP BY LPU.NameLPU,LPU.MestoLPU,Stacionar.Summa
В ходе написания курсового проекта по дисциплине «Управление данными» были написаны запросы к базе данных. Часть из них нашла свое отражение при создании базы данных в виде хранимых процедур. Все запросы перечислять не имеет смысла, поэтому поясним одну из них. Приведённая ниже процедура возвращает фамилии, имена и отчества всех пациентов конкретного ЛПУ за период. Таким образом, входными параметрами являются наименование ЛПУ и даты начала и конца периода. В процедуре происходит объединение 3 выборок - выборки по дате начала из карты выбывшего больного, по дате конца из карты и по дате статистического талона. Понятно, что кроме этого в предложение WHERE включено условие отсева пациентов только по конкретному ЛПУ.
CREATE PROC PacientLPU
@NameLPU varchar(50),
@Begin DateTime,
@End DateTime
AS
SELECT Fam,Im,Otch
FROM Pacient
INNER JOIN Karta
ON Pacient.IDPacient=Karta.IDPacient
INNER JOIN LPU
ON Karta.IDLPU=LPU.IDLPU
WHERE LPU.NameLPU=@NameLPU AND Karta.DateEnd BETWEEN @Begin AND @End
UNION
SELECT Fam,Im,Otch
FROM Pacient
INNER JOIN Karta
ON Pacient.IDPacient=Karta.IDPacient
INNER JOIN LPU
ON Karta.IDLPU=LPU.IDLPU
WHERE LPU.NameLPU=@NameLPU AND Karta.DateBegin BETWEEN @Begin AND @End
UNION
SELECT Fam,Im,Otch
FROM Pacient
INNER JOIN Talon
ON Pacient.IDPacient=Talon.IDPacient
INNER JOIN LPU
ON Talon.IDLPU=LPU.IDLPU
WHERE LPU.NameLPU=@NameLPU AND Talon.Date BETWEEN @Begin AND @End
После написания этой процедуры появилась потребность написать подобные процедуры, а именно вывод пациентов за период без указания ЛПУ, с указанием отделения и ЛПУ, с указанием только отделения. Создание этих процедур позволило сделать первоначальный запрос гораздо более гибким и удобным для конечного пользователя.
Таким образом, с помощью созданных отношений, хранимых процедур и триггеров обеспечивается бизнес-логика, подобная логике выполнения реального бизнес-процесса.
