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

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

0

Таблица РЕГИСТРАТУРА
Таблица ВРАЧИ (не мешает добавить код специализации врача)
Между ними для организации отношения многие к многим таблица-связка ПРИЕМ. От неё две внешние ссылки на РЕГИСТРАТУРА и ВРАЧИ. Плюс время, номер талона, возможно еще что-то. В каких учебниках не скажу, ни одного в глаза не видел, но на практике отношение многие к многим именно так реализуются. И не верь, что так нельзя

0

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

Добавлено через 32 минуты
Пардон, я имел ввиду таблицу ПРИЕМ().
"Между ними для организации отношения многие к многим таблица-связка ПРИЕМ"
То есть, в это ПрО никак нельзя создать сплошную и простую таблицу ПРИЕМ(). В этом же и суть проблемы! А можно работать только со ее слоями - ПРИЕМ_ТЕРАПЕВТОВ(), ПРИЕМ_КАРДИОЛОГОВ() и т.п. Если бы можно было бы работать со сплошной таблицей ПРИЕМ_ВРАЧЕЙ(), то вопроса бы не было бы. Очень прошу - вникните пожалуйста в вопрос! ПОМОГИТЕ ссылкой на литературу, где такое описано?

0

Что-то ты не то рассказываешь. Почему это ПРИЕМ нельзя делать одной таблицей? Вся информация для реализации выборок есть в двух родителях и ничего не мешает делать их (выборки) хоть по специализации врачей, хоть по времени приема и прочее.

0

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

0

Есть два варианта решения этой проблемы
Плохой - наплодить для каждой специализации свою таблицу со ссылками на ПРИЕМ и мучаться потом с запросами
Хороший - засунуть все в ПРИЕМ и не мучаться. Решето пусть не пугает, на то он и SQL, чтобы в том числе и NULL-ы хранить. В крайнем случае можно даже разные по смыслу, но одинаковые по типу данных атрибуты хранить в одном поле. Я бы так не делал

0

Понял. Я собственно это и понимал. Но мне дико не нравится решето. Это даже не решето, а монстрище какой то. Да и потом - а как же делать "вьюв" в приложение на каждом рабочем месте? Все равно получается нереляционная ситуация - в хранимую процедуру приложения впихиватеся значение ключа рабочего места, фильтрующего решето! Говнецо все это, если честно. Те же, только в профиль.
А нельзя ли подсказать ссылочку на литературу, где описано такое решето-монстр на 500 полей? (очень меткое между прочим название - метод рекурсивного решета Эйлера - это именно самое то - "вьюв").

0

На каждом рабочем месте никто не мешает свою структуру SELECT-а придумать, или свой VIEW, или хранимую процедуру. Это кому как угодно. Мне удобней динамически формировать SELECT-запрос

0

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

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

0

Не совсем понятно, к чему вы пришли в итоге? К тому от чего хотели отойти с самого начала?

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

Ваша задача - как раз классческая проблема РБД, и решать ее можно разными способами, в том числе и теми, что предлагали здесь. "Серебряной пули" тут нет и не может быть.

PS. Эта проблема, кстати, явилась одной из причин набирания популярности NoSQL баз...

0

Вот, уважаемый г-н Turbqnoff! Теперь мне уже стало понятно, что единственная "серебряная пуля" - это рассекание таблицы на слои. Я это и раньше понимал. Да только никак не мог взять в толк, почему же это такая тупая перепечатка "с чужого голоса" во всех учебниках наблюдается по стандартным вопросам, и такое молчание, если речь идет о проколах РБД. А все очень просто - их авторы в большинстве своем - обычные необъективные невежды. Вот потому то и не находил я этой классики у разных великих "перепечаников" америкосовских монографий типа знаменитого российского гуру от БД (не будем называть фамилий)...
Каждому ведь понятно. что приложение обязано работать с максимальной возможной скоростью, а разработка приложения (читай, схема РБД) должна быть максимально модифицируемой. А это значит, что монстры типа решета должны быть декомпозированы до полного изнеможения. Но Кодд такого не рассматривал. Вот потому то все и молчат, как рыба.
Правда на этот "сплит" намекнул Р. Фейджин в своей знаменитой статье о ДКНФ - он ведь первым предложил отделить "пол" пациента от всех остальных атрибутов. И он там и слова не сказал, что эта операция портит его безаномальную форму. А я просто никак не мог понять, куда же задевалась эта его знаменитая идея? А вот теперь все стало на место. Просто ее назвали странно - "денормализацией". Хотя при внимательном рассмотрении нормальность таблицы только повышается от этого. Потому, что неуправляемые случайные "паразитные" ФЗ, которые могут появляться в решетах, исключаются полностью таким сплитированием.
Так что, увы, уважаемый корифей. Сплитирование талицы - это единственно верное решение. И, как теперь очевидно, оно - строго в рамках реляционки. А вот течение "не только сиквел" - это уже другое, насколько я понял. Но тут еще нужно разбираться.
А с этой проблемой все ясно. Теперь у меня с дипломом - все ок...
Еще раз - всем большое спасибо!

0