Wlr-lСущность "Больница" - это…
Сущность "Врач" - это…
В каждой больнице может работать один или несколько врачей.
Каждый врач может работать в одной или нескольких больницах,
причем в одной и той же больнице он может работать по разным условиям.

Я-бы развил эту часть задачи до HR-системы. Больница имеет позиции. Позиция глав-врача. Позиция
завхоза. Убрщиц медсестер и так далее. Врач может занимать позицию. Или не занимать. Позиция - это сущность.
Врач помер? Ушел на пенсию? Позиция временно свободна.

Работник который ее занимает - другая сущность. Позиции могут совмещаться. 50% на 50%. Или в другой
пропорции. Пол-ставки. Треть ставки и т.д. Штатные. Интерны. Стажеры.

Задачу можно развить до регуляторных норм и законов. В каком возрасте хируг обязан уйти на пенсию?
Какую минимальную ЗП может получать уборщица? Какие позиции обязательны в городской муниципальной
больнице? Какое оборудование должен иметь ренгенолог чтобы начать работу?

Как видите.

В игре "найди в модели еще что нибудь" мы никогда не достигнем совершенства. Поэтому я настойчиво
предлагаю всем остановиться. И устаканить минимальное ТЗ.

hVosttmaytonНо беда в том что введение агрегатов - не имеет под собой четкой теоретической основы.

Как это не имеет? А количество колонок в таблицах РСУБД имеет чёткую теоретическую основу? Или количество таблиц?

Я разовью мысль. Поясню почему я лично сам так считаю.

Реляционная алгебра была предложена лет 40 назад Эдгаром Коддом. Математиком. РА определяла такие операции
как выборка. Проекция. Релациооное декартово произведение. Вычитание. И даже (!) деление. Делению
в SQL ЕМНИП нет аналога.

За эти пол-века РА обросла достаточным количеством теоретического материала. Под нее подогнали
соотв языки и стандарты и терминологию. Целая линейка SQL стандартов.

Были ведены кортежи. Домены значений. Отношения. Специальное состояние null-значение ячейки для иммитации
работы с выколотой точкой в множестве. И шесть форм нормализации. Цель которых - просто уйти от
возможных аномалий.

Были определены базовые правила и рекомендации по выбору ключей. И по их свойствам.

Ввели возможность бесконечно рекурсивно применять результат одного отношения к другому.

РА дружила с булевой логикой однако вводила специальные исключительны случаи для выколотых значений.
Правильнее сказать РА стояла поверх булевой логики. Тоесть сначала - операции с null - а уже потом сравнения.
Имела так сказать высший приоритет. Этого нет в обычных ЯП. И это очень важно в нашей дискуссии.

Вобщем к концу 2000 года РА покрывала вообще все-все теоретические потребности в проектировании баз.

Но с практической точки зрения отход от "РА" в сторону тоже полезен. Ему предшествовали
- количественный рост БД и хранилищ. Гигабайт стремительно дешевеет. Не все данные - лежат только в базах. Экономические пункты тоже имеют значение.
- рост влияния транспортных WEB форматов передачи данных (JSON/XML)
- рост internet of things.
- географическая децентрализация. Датацентры в разных странах.
- эмпирические наблюдения над ACID. CAP. пересмотр требований к консистентности.
- усиление влияния систем на базе репликации cобытий (JMS, Storm, Aktors)
- тренд на программирование сервисов которые поставляют ограниченный набор документов по ограниченному набору параметров (HTTP/REST/Restfull)
- тренд на программирование задачи не от БД к толстому клиенту. А от ORM в сторону БД. Тоесть нет никаких таблиц и реляций. А есть например Java-busines-entity которая 100% определеня в скоупе языка и всего-лишь обладает способностью сохраняться в анонимной БД. Тоесть БД используется просто как хранилище. В рамках этого тренда программисту на 99% всё равно какая БД под капотом. Он может даже не знать ее название.
- обыкновенная дороговизна лицензий на РСУБД (DB2/MSSQL/Oracle) и сложность развертывания пилотных и студенческих проектов на базе них.

Вобщем мир пошатнулся в сторону решений которые говорят - Мы - Not only SQL!

Я очень уважаю NoSQL. Я смотрю на него с интересом. Но КМК этой парадигме очень не хватает
настоящей математической красоты.

Именно той которую в своё время Эдгар Кодд заложил в РА.

Вот в данной простой задаче о поликлинике уже человек 5 схлестнулись в идейных спорах о том как разбить
задачу на сущности и связи. А ведь сущности и связи - это простые понятия которые мы можем разложить
на существительные и глаголы. Как в диаграммах Чена.

Давайте на секунду себе представим что было-бы если автор решил строить больницу на базе MongoDb, Cassandra?

Я даже представить себе о чем бы мы говорили. Скорее всего скатились-бы в глубокую конкретику. Типа там
обсуждение коллекций атомов против документов содержащих атомы. Ну вобщем как древние философы
мы-бы спорили о том сколько ангелов уместятся на кончике иглы.

Грустно это все. И главное это не приближает к решению задачи.

Wlr-lПоэтому как раз и сказал, что исходных данных вполне достаточно до курсовой работы. Важно правильно определить атрибуты сущностей и связи между ними .

Это невозможно. У нас нет данных. Всё что было придумано - фантазии. А спорить о фантазиях - контр-продуктивно.

Wlr-lНе совсем согласен с Вашим виденьем РА. Например, null:

Я не люблю ошибаться в догадках. Поэтому прошу вас прокомментировать. Что нарисовано в таблице?

Wlr-lЕсли, например, "Гигабайт стремительно дешевеет" и даже "Не все данные - лежат только в базах", то это совсем не означает, что нужно что-то делать с моделью Кодда. Да и ORM и много еще чего придумали для программистов, не способных одолеть модель Кодда. Базы данных живут гораздо дольше работающих с ними приложений.

Подпишусь. Вопрос-то в чём?

tip78maytonЯ очень уважаю NoSQL. Я смотрю на него с интересом. Но КМК этой парадигме очень не хватает
настоящей математической красоты.
красота ничто, скорость - всё!
Данный топик начинается не со скорости. Просто бы собрать логично и непротиворечиво.

А скорость - понятие расплывчатое. Обычно
закладки на скорость в будущем может заложить хороший архитектор у которого
есть "седое зрение". Особенно в части систем работающих с Disk/IO. Продумать также
базовые стратегии. Low Latency или Max Througput. Это дилемма.

Тут - дай бох просто корректно собрать. Известный теоретик Дональд Кнут тоже
советует сначала сделать просто корректно а потом уже профилировать и искать узкие
места в рабочем коде. А подход NoSQL предполагает что вы изначально уже знаете
где у вас что будет по перфрмансу. Ну... не знаю. Я-бы усомнился.

hVosttДавайте вспомним какое огромное количество теоретических материалов,
огромных разделов в книгах, посвящённых натуральным ключам. И кому это
сейчас нужно?

Я добавлю что я благополучно забыл половину теории после того как поработал DBA
в течении 5 лет. В продуктовых системах почти 100% ключей - суррогаты.

hVosttСУБД стала превращаться в комбайн, для которого потребовалось придумать
очень важную должность ДБА, с до сих пор непонятным набором ролей
и обязанностей.

Роли сильно отличались от типа производства. На мне лежали роли бэкапа.
Перформанса. И установки обновлений + сопутствующие задачи разработки.
Клонирование баз для девов.

Большее число времени и сил у меня занимали вопросы перформанса. Особенно
в условиях ограниченных возможностей девятки (Oracle 9i).

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

В ней польза примерно такая-же как в UML-диаграммах. По сути РМ нужна для
некого диалога с BA, заказчиком или другими (смежными) командами разработки.

Я часто прибегаю к коротеньким диаграммам на 1-2 таблицы когда идет какой-то
brainstorm по поводу новой задачи или резкого изменения в текущей.

Вот недавно тоже случай. Изучал Spring Batch. Рисовал для лучшего понимания. Понадобилось вбить пару гвоздей
в ихнюю дефолтную модель. Завтыкали индексы по внешним ключам. Мдя...

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

Да бизнесу пофиг. Но ему будет не пофиг когда окажется что эффективный отчот
нельзя построить. "Гранаты у них не той системы" (с)

Если честно то регистратуру надо выкинуть отсюда. Есть процесс. Называется регистрация больного.

1) У него есть начало. Пациент подошел к стойке рецепшена. И идентифицироал себя. Паспорт. Или карточка мед-страхования.
Или номер больного в базе (если этот больной уже здесь лечился).

2) Потом идет цепочка каких-то бизнес-действий. Вопросы-ответы. Какие-то решения. Жалобы. Гарантии страховой
компании или гарантии соц-страхования. Проверки.

3) В результате процесс завершится КМК двумя вариантами
3.1) пациент будет записан на приём к профильному врачу. Он получит Ticket где будет указан его следующий
визит. Дата. Время. Кабинет. И Врач который примет.
3.2) Либо пациент покинет поликлинику по разным причинам.

На этом точка. Вот такой вот я вижу минимум. Надо его реализовать. Но не более того.

[рука-лицо]

Ты втащил сюда еще один flow. Который называется экстренный вызов . Его надо по шагам описать отдельно.
Обычно экстренной частью занимаются другие врачи. У нас - врачи скорой помощи. Зарубежом - пара-медики.

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

Пример - неизвестный
гражданин иностранного происхождения (прилично одетый) резко упал в обморок в центре города.
Вызвали неотложную помощь. Ему была оказана первая помощь.Он без сознания. Документов нет.
Его доставили в интенсивную терпаию. Лежит. Спит.

Как его провести черезе вашу систему которая покрыта constraints где надо указывать ФИО и прочее?
Как списать материалы? Медикаменты? Технику? И время работы пара-медиков?

Диаграмму - не смотрел. Скажу поверхностно. Кружочков атрибутов в реальных продуктовых
системах - более 100 на каждую таблицу. Большая часть из них - технические и не особо важны для диаграмм.

На диаграмме можно нарисовать самые важные. ФИО. и прочее. А остальные просто обозначить.
Дескыть они там есть .. но их слишком много чтобы изобразить на бумаге.

Ладно делай как знаешь.

Но до того как рисовать таблицы - опиши 1-2 жизненных примера как этэто будет использовано.

Опиши не для форума. А для себя.