Связь между значением атрибута в записи одной таблицы и наименованием сторонней таблицы

[АлексИванов]

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

[pu4koff]

Заметил тему только сейчас, но может еще актуально.
Реализуется подобное посредством "связи категоризации". В общем, нужно ввести таблицу "Прием врача", в ней общие для всех приёмов данные и аттрибут "тип врача", по которому программа определит в какой таблице смотреть остальную информацию. Учитывая, что эта итнформация уже может быть в таблице врачей, то это поле можно опустить. Типы эти в простейшем случае жестко задаются, т.е. принимается, что 1 - терапевт, 2 - кардиолог, ...
Ну, и раз уж это диплом, то нужно всё делать в соответствии с хотя бы тремя нормальными формами. В жизни часто забивают на это, а вот в учебе не все преподаватели оценят оптимизацию, из-за которой будет нарушена столь важная 1/2/3 нормальная форма
Книжек нормальных нет или почти нет. Одни создают программы, а другие пишут как якобы их нужно создавать, в итоге всё сильно между собой отличается. Реальных примеров по проектированию сложных ИС я не видел, только теория или элементарщина.
И вообще, разве так сильно отличается информация о приёме у терапевта от приема у кардиолога, что под всё это выделяется отдельная таблица? Можно сделать одну таблицу "прием у врача", в ней реализовать общие для приемов у всех врачей аттрибуты и XML/Memo/Blob поле для всего остального, в зависимости от этого самого остального.