|
|
Регистрация Восстановить пароль |
Регистрация | Задать вопрос |
Заплачу за решение |
Новые сообщения |
Сообщения за день |
Расширенный поиск |
Правила |
Всё прочитано |
|
Опции темы | Поиск в этой теме |
31.07.2012, 17:18 | #1 |
Новичок
Джуниор
Регистрация: 31.07.2012
Сообщений: 1
|
Связь между значением атрибута в записи одной таблицы и наименованием сторонней таблицы
Здравствуйте, уважаемые корифеи! Не удивляйтесь моему вопросу - ответ мне нужен для дипломного проекта. Я - студент из Киева.
Не могу разобраться в очень простой ситуации. Как проектировать схему реляционной БД, если мне нужно моделировать связь между тем или иным значением конкретного атрибута в записи одной таблицы и наименованием сторонней таблицы (или даже именами группы таблиц!). Я так думаю, что такая связь выходит за рамки строгой реляционной модели. Но я никак не могу понять, как тогда моделируется примитивная ситуация, которая возникает во многих ПрО? Попытаюсь ее описать как смогу. Простите мне многословие, если что. Пусть ПрО - это регистратура в большой поликлинике в большом городе. Куча врачей, куча кабинетов, очередь стоит на регистрацию. Понятно, что все потребности больных регистрируются в одну таблицу РЕГИСТРАТУРА (КодПациента, КодВрача, КодДиагноза, …) подряд. В этой таблице сразу же формируется и их очередь в данный кабинет - или на исследования (на рентген, на УЗИ, на сдачу анализов, на ЭКГ и т.п.), или просто на прим к разным врачам (а наименований их - около 20, не говоря уже о структуре таблиц, каждая из которых отвечает за каждого врача). И что же мы имеем в итоге? Как я понял, типовую ситуацию. То, что зарегистрировано в простом списке (потоке) в таблице РЕГИСТРАТУРА(), со ссылками на справочник врачей, исследований, диагнозов и т.п. сущностей, должно строго связываться с разными сторонними таблицами. На руки больной получает сою очередь в конкретный кабинет конкретного врача - номерок. Все знают, что это - как билет на поезд. Тут все линейно и прозрачно. А вот дальше начинается самое интересное. Приложение же должно формировать подготовительные записи в куче формируемых новых таблиц! Если бы это была одна новая сводная (сплошная) таблица, то проблемы бы не было. Но это - 3-4 десятка разных таблиц! То есть, если атрибут КодВрача равен, скажем, 1 (больной пришел и зарегистрировался к простому терапевту), то нужно создать под него запись в таблице ПРИЕМ ТЕРАПЕВТА (), если атрибут КодВрача равен, скажем, 2 (больной пришел и зарегистрировался к кардиологу), то нужно создать под него запись в таблице ПРИЕМ КАРДИОЛОГА (). И так далее. И что ж получается? Получается, что ничем, кроме как наименованием (и само собой структурой-схемой), эти таблицы различить невозможно! Значит, нужно в справочник ВРАЧИ (КодВрача, Имя врача, ИмяСтороннейТаблицы) вносить нереляционную ссылку «имя сторонней таблицы». Потому, что по иному, как мне кажется, эти таблицы взаимодействовать не будут. А без этого - пролет работы приложения. Я уверен, что ситуация, описанная мною - типовая. И даже классическая. Но почему я ни в одном учебнике по РБД не могу найти ответ на этот вопрос? С чем я столкнулся? Что я еще думаю. Можно, конечно же, исходить не из таблицы-списка зарегистрированных больных при создании таблиц-приемов врачей, а наоборот. То есть, при формировании информации в приложении конкретного врача терапевта на его компе, прога может цеплять к открытой (текущей) таблице ПРИЕМ ТЕРАПЕВТА (КодВрача, ) фоновую таблицу РЕГИСТРАТУРА (КодВрача, ...) по конкретному значению атрибута КодВрача, прописанному прямо в листинг приложения. Но, как мне кажется, от этого нереляционность не отпадет - хрен редьки не слаще. А разделять «регистрационную» таблицу стразу же на кучу журналов по именам врачей (как делают, например, в ЗАГСЕ – там та же ситуация, кстати), нельзя ни в коме случае. Потому, что там работают процедуры проверки целостности и непротиворечивости очередей в кабинеты. А это можно сделать только на цельной таблице. Что это за ситуация? Где она описана, в каком учебнике? И как такое моделируют профессионалы по проектированию схем реляционных БД? Потому, что таких ПрО можно привести сотни в пример. Да, и прошу меня извинить, если совершенно аналогичный вопрос вы обнаружите на других форумах по БД. У меня горит диплом! Словом, помогите!!! |
21.08.2012, 15:37 | #2 |
Старожил
Регистрация: 22.05.2007
Сообщений: 9,085
|
Заметил тему только сейчас, но может еще актуально.
Реализуется подобное посредством "связи категоризации". В общем, нужно ввести таблицу "Прием врача", в ней общие для всех приёмов данные и аттрибут "тип врача", по которому программа определит в какой таблице смотреть остальную информацию. Учитывая, что эта итнформация уже может быть в таблице врачей, то это поле можно опустить. Типы эти в простейшем случае жестко задаются, т.е. принимается, что 1 - терапевт, 2 - кардиолог, ... Ну, и раз уж это диплом, то нужно всё делать в соответствии с хотя бы тремя нормальными формами. В жизни часто забивают на это, а вот в учебе не все преподаватели оценят оптимизацию, из-за которой будет нарушена столь важная 1/2/3 нормальная форма Книжек нормальных нет или почти нет. Одни создают программы, а другие пишут как якобы их нужно создавать, в итоге всё сильно между собой отличается. Реальных примеров по проектированию сложных ИС я не видел, только теория или элементарщина. И вообще, разве так сильно отличается информация о приёме у терапевта от приема у кардиолога, что под всё это выделяется отдельная таблица? Можно сделать одну таблицу "прием у врача", в ней реализовать общие для приемов у всех врачей аттрибуты и XML/Memo/Blob поле для всего остального, в зависимости от этого самого остального. |
Похожие темы | ||||
Тема | Автор | Раздел | Ответов | Последнее сообщение |
MS SQL SERVER 2005 копирование таблицы из ОДНОЙ БД В другую или перенести все строки из одной таблицы в другую | reihtmonbern | БД в Delphi | 4 | 17.07.2012 23:25 |
Переместить записи из одной таблицы в другую | tiktak | C/C++ Базы данных | 1 | 01.07.2011 13:50 |
Как из одной таблицы удалить записи, содержащиеся в другой | Kingson | Microsoft Office Access | 4 | 13.04.2010 22:39 |
Выбор строки в ComboBox в соответствии с выбранным значением поля записи таблицы БД | golt-andrej | Помощь студентам | 3 | 26.01.2010 11:21 |
авт. перенос данных из нескольких столбцов одной таблицы в один столбец другой таблицы | A_ALL | Microsoft Office Access | 7 | 24.08.2009 21:13 |