Здравствуйте, уважаемые корифеи! Не удивляйтесь моему вопросу - ответ мне СРОЧНО нужен для дипломного проекта. Я - студент из Киева. Вы или ваши коллеги мне так и не ответили год тому неа этот же вопрос. Думал, разбирусь сам. Но, увы... Прошу ответить сегодня. Я уже поднимал эту тему ранее. Но, опять же - увы...  Прошел год, но так вопрос и не проянился - а ситуация очень простая. 

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

Никак. Желаемое вами не описывается реляционной моделью.

Я не совсем понял таблицы "Прием терапевта" и "прием кардиолога" имеют разный набор аттрибутов?
Если нет, то смысла их разделять нет.
Если да, то смысл их разделять есть и в какую таблицу необходимо совершить запись должен знать прикладной слой(rtfm Трёхуровневая архитектура). Именно он реализует логику. База данных лишь определяет структуру даных и контроллирует целостность. Соответственно при добавлении новых типов приема, если они не вписываются в общую структуру, требуется модификация не только схемы данных, но и прикладного слоя

Не помечайте свой вопрос как "Срочный", даже если для вас он именно такой

+1

А если разный, но с базовым стержнем, то в ОСУБД для таких случаев предусмотрено наследование. Но для моего сознания оно чужно, я бы предпочел "разрулить" вводом дополнительного атрибута "ТипПриема", и плевать, что при этом таблица примет вид разреженной матрицы.

Добавлено через 2 минуты и 23 секунды
  

Сходил по ссылке - ничего не понял... Про каких-то хакеров... Пушистых тюленят...

я часто применяю такой подход
псевдо DDL:


Жаль подход не гарантирует что связь будет строго 1:1, зато не допускает не однозначности, за счет FK, у нас не может быть два расширенных набора атрибутов

Это сообщение отредактировал(а) Zloxa - 1.8.2012, 02:07

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

Ну и что нового я вам рассказал? Ровным счето - НИЧЕГО!!! Так почему же этого нельзя моделировать в РМБ? Что крамольного в том, что куча таблиц запрашивается из одной таблицы по разным значениям атрибута? А если Э. Кодд это запретил, то как он это предлгает делать? Должны же быть альтернатива!
Очень проршу - подскажите точнее - где я могу почитать о таком? И как там рекомендуется такое моделировать в РМД?

Добавлено через 5 минут и 14 секунд
"... я бы предпочел "разрулить" вводом дополнительного атрибута "ТипПриема", и плевать, что при этом таблица примет вид разреженной матрицы."

Не-не! Так точно будет очень плохо! Вот так - это неверно не только для РМД, но и для просто здравого смысла - дикая избыточность. Это - не альтернатива. Должно быть что о иное...

Добавлено через 10 минут и 39 секунд
"я часто применяю такой подход
псевдо DDL"

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

Примените EAV .


Ну как не вопрос по составлению запросто - то обязательно "... что бы выполнялось за один запрос", а если вопрос по проектированию, то "... что бы вся логика выполнялась на SQL-сервере".
На императивном языке динамически составляйте запросы к БД или динамически формируйте параметры к хранимым процедурам - это должно помочь...


Тогда предлагаю начать с формального описания задания (так сказать ТЗ). И проектирования БД на концептуальном уровне.

В РМД такое не рекомендуется моделировать
РМД предназначена для другого

Потому что тогда она перестанет быть РМД

Мы сказали очень честно. 
На реляционную базу это не натянуть. Может какая не реляционная может, но вы настойчиво циклитесь именно на реляционной. 

Вы так употребляете термин, будто он широко употребим. Я с этим термином не знаком.


Не припомню, но то не суть. Мой пост был обращен не вам.


Я бы не рекомендовал исползовать EAV человеку, который врядли сможет оценить риски ее применения и сопоставить с целесообразностью. Больно уж она по душе приходится неокрепшим мозгам.


ппкс


Это сообщение отредактировал(а) Zloxa - 1.8.2012, 17:09

Однако, все же, через это надо пройти.  Но Александр Иванов явно не готов к этому пути 

Да просто на этом же форуме я поднимал этот ж вопрос год тому для бакалаврского диплома. Его же можно запросто найти по моему нику. Вы тогда тодже ответили мне листингом. Но я попросил расшифровать ответ. А вы сказали, что квадратики рисовать не будете. 

А вообще то вы мне уже очень помогли. Но если бы еще нашлась и ссылка на какой то учебник, в которм было бы написано, что РМД не может моделировать такие ситауции, то я смог бы спокойно вписать это в диплом. 

Но теперь возникает уже вопрос принципа. Если мощная РМД не может моделировать такую пустяковую ситуацию, то в чем причина? Ведь в теории множеств, да и в любой алгебре, не составляет проблем проводить операции по соответствию между элементом одного множества и его связью с именем иных множетств. Что тут нового? Имя множества - это такой же нормальный операнд любой алгебры, как и любой его элемент. 

Кто конретно запрещает ставить соответствие емежду данными и метаданными на уровень данных (то есть вносить ссылки на метаданные в таблицы данных)? Э. Кодд? А как он тогда предлагает моделировать такие ситуации? Ведь это - типовая ситуация. Повторюсь - таких предметных областей (ПрО) - сотни!

УМОЛЯЮ - не отписывайтиесь листингами! Мне правда нужна помощь!!! Листингом тут не отделаешься. Меня ведь допрашивать будут с пристрастием. Парой слов не отделаться...  Подскажите пожалуйста, вы встречались с такими ситуациями? Они где то описаны?
Извините мне мое занудство..

Добавлено через 3 минуты и 7 секунд
Ну то есть речь идет не о прогркаммном решении (я ведь уже описал одно из них), а о схеме реляционной БД! В это же и смысл проектирования БД - моего диплома. Знанием языков и программированием сейчас никого не удивишь. А мой диплом - это проект схемы РБД большущей ПрО. 
Вот в чем вопрос...

Вобщета - никто. Используйте нереляционные базы и будьте счастливы.
Если очень хочется, можно даже реляционную базу попробовать использовать как нереляционную. Хранить данные в XML или JSON и баста. У оракла, слышал, есть какието средства в XMLDB, позволяющие идексировать хранимые XML, формировать запросы.

В реляционных же базах изменение структуры данных всегда влечет за собой изменение логики работы с ними, изменение экранных форм, отчетов и пр, пр. Все ранее написанные запросы к данным, хранимые процедуры требуют ревалидации, перекомпиляции, которое могут требовать монопольного доступа к метаданным. В нагруженной многопользовательской среде это будет проиводить к взаимным блокировкам и может остановить всю систему полностью. Для реляционной базы изменение структуры данных это очень серьезная операция.



Чем я могу помочь? Пересадить вам свой головной мозг? 


Это сообщение отредактировал(а) Zloxa - 2.8.2012, 03:37

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

Третья ссыль выдачи гугла по "нереляционные базы данных" статья на хабре - перевод статьи англоязычного автора. Вроде там есть какой-никакой анализ проблем реляционных баз, обосновывающий применение не реляционных. Беглым взглядом на статью откровенной чуши не увидал, вроде похожа на правду.

Только те проблемы, которые вы описываете в топикстарте там не упомянуты. Потому что это не проблемы реляционной модели. Это проблемы вашего ее не понимания. Навевает пикчу:


Не могли бы вы ве же попытаться объяснить, что именно вас не устраивает в схеме, когда данные, собранные при осмотре разных специалистов сохранялись бы в разных структурах данных. Это вполне нормлаьная практика. Совершенно не понятно, что вызывает у вас недоумения и зачем вам связь данных с метаданными.

Это сообщение отредактировал(а) Zloxa - 2.8.2012, 13:15

Хорошо. Пусть я тупой студент. Нет проблем.
Тогда давайте просто порассуждаем. Пусть мы хотим скрестить ужа с ежом - делаем сводную таблицу-монстера. Хотя она будет слабозаполненной. Решетом, как метско сказал один из собеседников на другом форуме. Пусть в эту таблицу-решето ежеминутно входит информация обо всех-всех услугах, предоставляемые такой поликлиникой-ателье. И УЗИ, и вырывание зубов, и ЭКГ, и прием всех врачей, и езе куча-куча.... Тогда такое огромедное решето будет же очень медленно работать, если таких клиентов к нему - пару сотен врачей одновременно! Это - раз.

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

Ссылка как раз таки очень реляционная. А разница в том, что решето вписывается в реляционную модель и реализуемо, а ваше описание сферическое и в вакууме.

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