Архив форумов ЦИТФорума

[AlexandrIvanov]

Здравствуйте, уважаемые корифеи! Не удивляйтесь моему вопросу - ответ мне нужен для дипломного проекта. Я - студент из Киева.
Вполне возможно, что я его уже тут задавал. Попытался восстановить свой прошлогодний пароль и старую регистрацию, но знания только почты не достаточно. Так, что если я повторяюсь - не судите строго. Тем более, что на этот вопрос я так нигде ответ и не нашел.
Вопрос: как проектировать схему реляционной БД, если нужно моделировать связь между тем или иным значением конкретного атрибута в записи одной таблицы и наименованием сторонней таблицы (или даже именами группы таблиц!)? Думается, что такая связь выходит за рамки строгой реляционной модели. Но я никак не могу понять, а как тогда моделируется такая примитивная ситуация, которая возникает во многих ПрО? Попытаюсь ее описать на примере, как смогу. Простите многословие, если что.
Пусть ПрО - это регистратура в большой поликлинике в большом городе. Куча врачей, куча кабинетов, очередь стоит на регистрацию. Понятно, что все потребности пациентов регистрируются и оплачиваются в одном окошке. А это значит, что все сведения вносятся в одну таблицу РЕГИСТРАТУРА (КодПациента, КодВрача, КодДиагноза, …) подряд. Из этой же таблицы тут же распечатывается, например, счет к оплате в соответствии с типом заказанной медицинской услуги. В этой таблице сразу же формируются и очереди пациентов по конкретным кабинетам - или на исследования (на рентген, на УЗИ, на сдачу анализов, на ЭКГ и т.п.), или просто на прием к разным врачам (а наименований этих врачей - около 20, не говоря уже о структуре таблиц, каждая из которых отвечает за каждого врача). Из этой же таблицы распечатывается номерок на очередь в конкретный кабинет конкретного врача, который пациент получает тут же. Все знают, что это - как билет на поезд. Тут все линейно и прозрачно. А вот дальше начинается самое интересное. Записи, которые внесены простым потоком в таблицу РЕГИСТРАТУРА(), со ссылками на справочник врачей, исследований, диагнозов и т.п., должны строго связываться с разными сторонними таблицами. Как я понял, это - типовая ситуация.
При этом приложение должно формировать подготовительные записи в куче формируемых новых таблиц. Если бы это была одна новая сводная (сплошная) таблица, то проблемы бы не было. Но это - 30 - 40 разных таблиц! То есть, если атрибут КодВрача равен, скажем, 1 (больной пришел и зарегистрировался к простому терапевту), то нужно создать под него запись в таблице ПРИЕМ ТЕРАПЕВТА (), если атрибут КодВрача равен, скажем, 2 (больной пришел и зарегистрировался к кардиологу), то нужно создать под него запись в таблице ПРИЕМ КАРДИОЛОГА (). И так далее. И что ж получается? Получается, что это связь данных и метаданных - ничем, кроме как наименованием (ну или их номером, что одно и то же) эти таблицы различить невозможно. Значит, нужно в справочник ВРАЧИ (КодВрача, Имя врача, КодСтороннейТаблицы) вносить нереляционную ссылку на «стороннюю таблицу». Потому, что по иному, как мне кажется, эти таблицы взаимодействовать не будут. А без этого - пролет работы приложения. Я уверен, что ситуация, описанная мною - типовая. И даже классическая. Но почему я ни в одном учебнике по РБД не могу найти ответ на этот вопрос? С чем я столкнулся?
Что я еще думаю. Можно, конечно же, исходить не из таблицы-списка зарегистрированных больных (более старшей таблицы по иерархии таблиц) при создании таблиц-приемов врачей, а наоборот. То есть, при формировании информации в приложении конкретного врача терапевта на его компе, прога может цеплять к открытой (более низкой по иерархии) таблице ПРИЕМ ТЕРАПЕВТА (КодВрача, ) фоновую таблицу РЕГИСТРАТУРА (КодВрача, ...), отражающую список пациентов на сегодня, по конкретному значению атрибута КодВрача, прописанному или прямо в листинг приложения, или в хранимую процедуру, или еще куда то. Но, как мне кажется, от этого нереляционность такой связи не отпадет - "хрен редьки не слаще". А разделять «регистрационную» таблицу стразу же на кучу журналов по именам врачей (как делают, например, в ЗАГСЕ – там та же ситуация, кстати), нельзя ни в коме случае. Потому, что в приложении работают процедуры проверки целостности и непротиворечивости очередей в кабинеты. А также исключительно бухгалтерские процедуры формирования счетов и подготовки других таблиц к регистрации получения денег. Поэтому, о рассечении регистрационной таблицы стразу же на таблицы с типами услуг не может быть речи.
Что это за ситуация? Где она описана, в каком учебнике? И как такое моделируют профессионалы по проектированию схем реляционных БД? Потому, что примеров таких ПрО можно привести сотни.
Да, и прошу меня извинить, если совершенно аналогичный вопрос вы обнаружите на других форумах по БД. У меня горит диплом!
Словом, помогите!!!

[AlexandrIvanov]

Я решил свою проблему.
Описанный мною процесс - это действительно классика. Только назван он денормализацией. И ни о каком выходе за пределы РМД речь не идет.
http://www.lcard.ru/~nail/sybase/perf/1088.htm
"Как правило, горизонтальное разделение ... требует различные имена таблиц в запросах, в зависимости от значений в таблице"
Оказалось, что таких статей в инете - куча. Но помощь эту я получил не от форумов России. Везде одна и та же картина. Жаль, что корифеи оказались столь не начитанными...