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

Уважаемый г-н Dimitry Sibiryakov! Так вопрос именно в этом. В описанных предметных областях (ПрО) невозможно сделать единой таблицу ПРИЕМ_ВРАЧЕЙ(). Если бы можно было, то все было бы линейно и просто. Проблема в том, что у каждого врача - своя структура таблицы. Они очень отличаются - как холодильник от бутылки водки и от туристической палатки. Поэтому группируются в одну только таблица ТЕРАПЕВТ(), КАРДИОЛОГ(), УРОЛОГ() и т.п. А если же их просто принудительно примитивно состыковать между собой (не соединить, а именно состыковать!), то полученное одоробло будет очень разреженным - как разреженная матрица. А это - тоже фигня. Дикая избыточность. Так точно нельзя. Да и ворочаться такой монстр будет жутко медленно. Представьте себе табличку, в которой по 10 атрибутов умножены на 50 разнообразий - 500 атрибутов практически всегда нули. А в день проходит через регистратуру такого ателье (а что поликлиника, что ателье. что ЗАГС, что супермаркет - все едино) 1000 посетителей. Ну и что это будет за БД?
Очень прошу, подскажите - в каких статьях такое описано? Дайте ссылочку плиз. Потому что мне в этом интерсует не метод программистского решения (их - множество), а именно теоретический анализ проблемы РМД. У меня диплом на тему проектирования схем БД (а не программирования приложений). Помогите ссылочкой!

Ну так давайте просто порассуждаем. Пусть мы можем с вами скрестить ужа с ежом. Пусть в эту таблицу-решето войдут все услуги предоставляемые такой поликлиникой-ателье. И УЗИ, И вырывание зубов, и ЭКГ, и прием всех врачей. Тогда такое огромедное решето будет же очень медленно работать, если таких клиентов к нему - пару сотен врачей одновременно! Это - раз.
А второе - получается все та же нереляцоинная ссылка, что и в моем описании. Только она замаскирована в листинге запроса. Какая же разница, а? Ведь все равно же при загрузке приложения на рабочем месте скажем УЗИста процедура запроса в соответствии с значением кода услуги из справочника ИССЛЕДОВАНИЯ (КодУслуги, ...), скажем, 15 - УЗИ, врач-узист получает доступ к отфильтрованному решету. Ему то ведь сто лет в обед не нужно трогать записи в решете об посещении терапевтов, кардиологов и т.п. Что же получается? Та же нереляционная ссылка. То же самое взаимодействие данных и метаданных. Только не в явном виде прямо в справочнике, а замаскировано в листинге хранимой "на века вечные" процедуры запроса. Так что никуда от такого фильтра не деться. Хоть в лоб, хоть по лбу. Ведь так?
Поэтому прошу не отвлекаться от вопроса нереляционной ссылки. Она обязательно имеет место.
Прошу просто подсказать, где такое описано, если вообще описано...
Сейчас, после 3 дней дискуссии в 6 основных форумах, я в этом сильно засомневался...

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

И по поводу того, что любому врачу ОБЯЗАТЕЛЬНО нужен навязанный доступ ко всем данным пациента - вот это по настоящему безапеляционная глупость! Получить ответ на запрос - это само собой. Но зачем, спрашивается, "молотить" терапевту информацию о пломбе 7-го нижнего? Или знать результаты операции на мизинце? Вот это - 100 процентный бред!
И как же вы, интересно, иначе отфильтруете из вашего решета все эти сведения? Только значением кода врача (то бишь пользователя приложения). А это - что? Это и есть нереляционная ссылка. Значение кода врача ведь берется из справочника врачей данной поликлиники. А кто его формирует? Сисадмин. А какое отношение сисадмин имеет к листингу тригера фильтра решета? НИКАКОГО! Значит, запрос на это значение прошивается в тригер изначально разработчиком. А тригер, получив само значение, может фитльтровать решето на данном пользовательском месте.
Вот я и говорю - те же, только сбоку...

Словом, всем спасибо... Все мне очень помогли ... зарядом злости, который дал возможность прогнуться перед преподом "соседнего" ВУЗа, дать ему коньяк и просто по детски спросить, где такое может быть? Но при этом показать ему (посредством этих форумов), что узнать у коллег хоть что то серьезное и нестандартное практически невозможно! Но тогда, в чем смысл таких форумов, а? В забалтывании проблемы?...
Очень всем спасибо за науку о форумах...