Logo Море(!) аналитической информации!
IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware
Архив форумов ЦИТФорума
Море(!) вопросов - Море(!) ответов
 
 FAQFAQ   ПоискПоиск   ПользователиПользователи   ГруппыГруппы   РегистрацияРегистрация 
 ПрофильПрофиль   Войти и проверить личные сообщенияВойти и проверить личные сообщения   ВходВход 
Как правильно задавать вопросы

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

 
Перейти:  
Этот форум закрыт, вы не можете писать новые сообщения и редактировать старые.   Эта тема закрыта, вы не можете писать ответы и редактировать сообщения.    Список форумов Архив форумов ЦИТФорума -> Базы данных
Предыдущая тема :: Следующая тема  
Автор Сообщение
AlexandrIvanov



Зарегистрирован: 01.08.2012
Сообщения: 2

СообщениеДобавлено: Ср Авг 01 2012 14:19    Заголовок сообщения: Связь атрибута в записи одной таб-цы и наим-ем иной таб-цы Ответить с цитатой

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



Зарегистрирован: 01.08.2012
Сообщения: 2

СообщениеДобавлено: Пт Авг 03 2012 12:17    Заголовок сообщения: Ответить с цитатой

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

 
Перейти:  
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах


Powered by phpBB © 2001, 2002 phpBB Group
Русская поддержка phpBB

 

IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware

Информация для рекламодателей PR-акции, размещение рекламы — adv@citforum.ru,
тел. +7 495 6608306, ICQ 232284597
Пресс-релизы — pr@citforum.ru
Послать комментарий
Информация для авторов
This Web server launched on February 24, 1997
Copyright © 1997-2000 CIT, © 2001-2006 CIT Forum
Внимание! Любой из материалов, опубликованных на этом сервере, не может быть воспроизведен в какой бы то ни было форме и какими бы то ни было средствами без письменного разрешения владельцев авторских прав. Подробнее...