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

т.е. есть сущности(услуги), которые в зависимости от типа имеют разные атрибуты("куча разных таблиц"). и структура различна, и обрабатывать хочется универсально.
пожалуй, простейшее решение - EAV-модель
возможно также все ж хранить услуги отдельно друг от друга в таблицах разной структуры(считая их различными сущностями), и объединять в единый список сугубо в read-only представлении(view).
даже не знаю, что тебе больше подходит, так как не знаю, на чем упор в твоей модели: на схожей обработке разных услуг(единое управление услугами, сводная статистика) или на различиях в структуре(вплоть до того, что каждый производственный отдел управляет своими услугами через уникальный вариант интерфейса)

Если знаешь что нельзя но очень нужно, то - можно.©

Если честно, я так и не смог понять что именно вас смущает.

Расширенные атрибуты различных услуг представлены отдельными сущностями. Есть справочник типов услуг. Возможно гдето есть,но Вами не упомянут, какойто единый реестр, имеющий измерения код_услуги, тип услуги. Возможно гдето есть какието документы, определяющие кому, какая услуга оказана. Это вполне можно описать ER моделью.




skyboy, о EAV пытливым юным умам лучше не задумываться - до поры, до времени 

Это сообщение отредактировал(а) Zloxa - 11.11.2010, 10:18

да, пожалуй. мне оно жизнь поламало   

  не выйдет!

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

Добавлено через 8 минут и 32 секунды
Ну да, конечно же - имеется справочник услуг. Это - само собой. И по умолчанию понимается, что все очень прозрачно и просто - клиент пришел, назвал тип (смысл) своей бумажки, которую хочет купить, заплатил по коду заказа, передал нужные первичные документы, подождал несколько дней, пришел, обнаружил свой заказ выполненным, получил (купил по предоплате) нужный документ, ушел. Все. Поэтому и БД должна быть сплошной - от окошка визита и до главной книги бухгалтера и всех видов отчетности не только в бухгалтерии, но и во все министерства. И для меня важно (в этом смысл проект), что все это укладывалось только в НФБК - строго. Никаких ООБД-ных наследований, никаких «программистских» штучек. Использования любого конкретного языка программирования вне реляционной схемы - это двойка на защите. Во как!... Так что помогите пожалуйста, а?...

И все же не ясно чем вас не устраивает предложенная мною структура.
Быть может вас смущает что я ее не квадратиками изобразил?

Да, "нарисуйте" пожалуйста квадратиками. Меня интересует логика, а не листинг

Всенепременно.
Все брошу и начну рисовать.   

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

В результате визита поциент получает одну или несколько услуг из реестра услуг.


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