Допустим есть какая то задача ну или User-story и мне надо провести системный анализ по ней. вот что лучше использовать в проектировании диаграммы классов или ER диаграммы? и как разобраться что именно выбрать (по каким критериям) тот или иной вид диаграммы.

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

Мартин Грабер в Гл 19 "Проектирование баз данных" описывает два основных алгоритма создания баз данных, а именно:
1. На базе подхода ER-модели создаются ER-диаграммы, затем они преобразуются программистом в таблицы реляционной базы данных и проверяются на соответствие требованиям нормализации (то есть, фактически, не накосячил ли программист, ведь если все делать правильно, то из ER-диаграммы путем достаточно формальных процедур можно получить достаточно нормализованные таблицы).
2. Создается некая супертаблица (набор супертаблиц), то есть набор всех возможных атрибутов (столбцов) в одной куче, и затем путем её декомпозиции создаётся удобоваримый и в меру нормализованный набор таблиц - схема БД.

При это отмечается, что подход на базе ER-модели является предпочтительным и к тому же - более человечным, интуитивно более понятным (он менее формален, чем подход два).

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

P.S.
Есть конечно некий предварительный этап (очень важный и затратный по силам и времени), вплоть до разработки ТЗ, который может разниться в зависимости от рода задачи, а именно:
- Изучение предметной области
- Выявление и определение сущностей, атрибутов (столбцов), связей
и т.д.
Но это отдельная история.
Если говорить ещё и о проблеме разработки ТЗ, о проблеме общения с заказчиками и со специалистами предметной области - то это отдельная задача.
Кстати, проблемы этой задачи в чем-то общие и при разработке БД для заказчика и при разработке сайта. Особенно, если заказчик не является крупной структурой и у него нет специалистов-программистов, погруженных в предметную область и могущих компетентно разработать ТЗ.
То есть, есть проблема преодоления пропасти: программист не знает предметной области, а заказчик не понимает как поставить задачу программисту. Считаю, что для преодоления такой пропасти могло бы существовать специальное ПО. Но это постскриптум.

Добрый день. Нужен совет по проектированию БД "Баскетбол". Есть таблицы Person (общая информация о человеке: имя, дата рождения и т.д.) и Player (информация об игроке: позиция, рост и т.д.) со связью один к одному. Сейчас добавил в БД таблицу Staff (сотрудники команды и их должности, чтобы хранить информацию, например, о тренере). Поэтому теперь связь один к одному между Person-Player мне не подходит. Как реализовать логично с учетом того, что бывший игрок может стать тренером?

Прикрепил диаграмму (Person, Player, Staff, Contract) и полную диаграмму всех таблиц в БД. Буду рад получить какие-то рекомендации по вопросу и по БД в целом.

Существенной частью проектирования программно-аппаратных систем является архитектурное проектирование (наяду, например, с бизнес-анализом, системным-анализом, дизайном, …).
Наверное, для маленьких систем (на неделю-месяц человеко-дней) архитектурное проектирование не существенно. Также для небольших доработок существующих систем. Для средних и больших систем – только осознанная и проработанная архитектура дает шанс на успех проекта (примеры в статье о ). Архитектура программно-аппаратных систем – большая и сложная наука, много исследований, книг, публикаций. Множество серьезных комплексных методологий-стандартов (например, ), продвигаемых крупнейшими «игроками» в области разработки систем. Архитектура программно-аппаратных систем включает в себя множество аспектов (зачастую взаимосвязанных), включая моделирование, управление архитектурным репозиторием, обеспечение качества архитектуры, обеспечение повторного использования компонент и решений, использование архитектурных шаблонов и фреймворков, и.т.д.
В данной публикации хочу вкратце поделиться личным опытом и пониманием некоторых аспектов использования распространенных архитектурных шаблонов и фреймворков.
Конечно, начальные знания по архитектурным шаблонам отражены в публикациях по базовым (элементарным) архитектурным шаблонам (на основе элементарных шаблонов создается комплексные шаблоны и их реализации - фреймворки). Типичный и наиболее распространенный набор элементарных архитектурных шаблонов – шаблоны .
В публикации хочу обратить внимание не на базовые шаблоны, а на часто используемые шаблоны более высокого уровня, образующие инфраструктуру многих современных программно-аппаратных систем, такие как:
 Использование динамически расширяемых структур данных, основанных на метаданных (описаниях структур данных);
 Концепция сервисных шин (ESB – Enterprise Service Bus);
 Концепция сценариев выполнения (WFM – Work Flow Management);
 Концепция управления правилами обработки данных (Rule Based systems);
 Концепция встроенных бизнес и системно-ориентированных языков описания сценариев и правил обработки данных;
В перспективе:
 Использование технологий «искусственного» интеллекта;
 ETL;
 Другие

Использование динамически расширяемых структур данных, основанных на метаданных.

Есть два крайних противоречивых подхода в разработке и проектировании баз данных (на самом деле более чем два, но хочу обратить внимание на эти):
- Жесткая (статическая) структуризация данных (на основе реляционных БД, например Oracle DB, PostgreSQL);
- Динамические структуры данных при отсутствии каких-либо схем – описаний структур (базы данных неструктурированных документов, например, MongoDB, Influx)

Жесткая структуризация данных. Типично для разработчиков использующих реляционные базы данных. Основа подхода – все структуры, включая типы объектов, атрибуты типов объектов (с типами данных), связи между типами объектов. В принципе, неплохой подход, но имеет существенный недостаток - добавление или изменение типов объектов данных системы требует участия программистов-разработчиков. Это приводит к следующим проблемам:
 Удорожание и замедление процессов развития систем (любое добавление или изменение типов данных требует участия программистов разработчиков).
 Практически невозможно использовать такой подход если от системы требуется возможность для пользователей динамически создавать типы объектов данных.
Мое видение – для крупных и среднего масштаба систем использовать комбинацию статических структур данных (конечно, «квазистатических», изменяемых разработчиками), и динамических, основанных на мета описаниях, позволяющих вносить изменения в структуры администраторам системы, даже простым пользователям.
Такой подход часто используется в ИТ индустрии, хотя часто встречает жесткое сопротивление апологетов жесткого (статического) структурирования. Основные вопросы:
 Неуправляемая структура повышает риски сбоев системы;
 Существенное понижение производительности систем и времени реакции на действия пользователя из-за сложности динамической индексации новых типов данных.
Эти вопросы в большинстве случаев решаются на уровне логики системы и приемов быстрой работы с динамическими данными. Структура остается управляемой в связи с наличием описаний новых типов данных (метаданные).
Успешный пример – широко используемая система JIRA. В основе – динамические объекты. Пользователи могут создавать новые объекты данных, экранные формы ввода новых типов данных, правила обработки, сценарии обработки новых типов данных. Внутренняя структура динамических объектов – 4 таблицы реляционной БД: описание типов объектов, описание атрибутов типов объектов, экземпляров объектов, экземпляров (значений) атрибутов объектов. С учетом механизмов управления типами данных, заложенных в систему и механизмов обеспечения быстрой работы с динамическими объектами, система работает быстро и надежно (мне приходилось работать с ней на всех уровнях, включая программном).
Другие примеры из жизни (в ИТ) до сих подтверждали эффективность такого подхода.
Динамические структуры данных при отсутствии каких-либо схем (описаний структур) вызывают у меня большое опасение. Это очень похоже на «коленочную» быструю разработку – что-то «сбацать», а там трава не расти. Особенно в тех областях, где требуется точный результат. Примерный результат, типа может объект нашел по атрибутам, а может не нашел, а может атрибуты не так называются или еще что, не везде проходит, в большинстве случаев не годиться, хотя, возможно, применим при обработке BigData – надо подумать.

Концепция сервисных шин (ESB – Enterprise Service Bus)

В начале 2010х годов – модное направление, сейчас несколько стихло. Основная идея – унификация коммуникаций программно-аппаратных компонент внутри систем, а также между внутренними компонентами системы и внешними системами, компонентами, системными сервисами, также предоставления внешним системам (потребителям) сервисов на основе стабильных программных интерфейсов. Дополнительная возможность – обеспечение масштабируемости систем посредством балансировки нагрузки по экземплярам используемых сервисов.
Появились фреймворки, реализующие архитектурный шаблон ESB (IBM Integration Bus, Microsoft Azure Service Bus, Mule ESB, Oracle Enterprise Service Bus, …).
Сталкивался с использованием такого рода фреймворков в разработке системы для Министерства Финансов РФ компании ФОРС совместно с другими партнерами. В дальнейшем участвовал в подобных разработках в качестве одного из системных интеграторов в одной из крупнейших телекоммуникационных компаний РФ.
Основная проблема использования таких технологий с моей точки зрения - отсутствие системного подхода к разработке программных интерфейсов. Необходимо на начальных этапах проектирования и разработки систем прорабатывать унифицированные (минимизация и универсализация), гибкие и расширяемые программные интерфейсы. Отсутствие такой проработки часто это является следствием Agile подходов к разработке систем (см. ). В реальности часто получается, что для интеграции нового модуля с каким-либо сервисом, в среде фреймворка ESB разрабатывается новый интерфейс, по сути, новая программа. Часто в логику программы-интерфейса вносится бизнес логика самой системы, забывая, что назначение ESB – трансформация протоколов обмена данными и форматов данных (хочется вспомнить басню про обезьяну и очки). В итоге – большое количество интерфейсов, плохо контролируемые интерфейсы (что они делают, какую логику, в том числе бизнес-логику включают), удорожается и усложняется разработка системы в целом – дополнительный фреймворк, отдельные типы разработчиков, отдельный объект сопровождения.
Жаль, а идея ESB очень хорошая. В предоставляемых фреймворках (даже бесплатных, типа Mule ESB) заложено большое количество средств для трансформации протоколов, форматов, возможность настройки протоколов и форматов (а также внесения изменений) без программирования вообще (администраторами), подключения унифицированных «заглушек» и эмуляторов системных сервисов и компонент – все для снижения стоимости разработки систем, сокращению сроков выпусков, повышению гибкости, возможности динамического показа разных вариантов реализаций, включающих динамическое подключение разных видов и версий компонент и сервисов.

Концепция сценариев выполнения (WFM – Work Flow Management)

Модное направление с начала 2000х годов. Сейчас страсти утихают. Основная идея – вывести часто изменяемую часть процессов обработки данных в подсистему (фреймворк), позволяющую настраивать процессы без программирования, динамически, быстро вносить изменения в сценарии обработки данных с учетом часто меняющихся структур обрабатываемых объектов данных (учитывая, что сценарии обработки данных, бизнес транзакции могут иметь большую протяжённость по времени). Дополнительно фреймворки такого типа должны обеспечивать устойчивость работы системы в целом, быстрое восстановление после сбоев без «потерь», масштабирование систем, автоматическое журналирование процессов, возможность мониторинга процессов обработки данных.
Приходилось интенсивно использовать такой фреймворк в качестве интегратора в одной из крупнейших телекоммуникационных компаний РФ при разработке комплексной системы класса OSS/BSS (поддержка операций и бизнеса). Основные проблемы:
 Недостаточная проработка и унификация интерфейсов используемых в сценариях программных компонент и сервисов приводит к большим затратам труда разработчиков на сопряжение WFM фреймворка с компонентами и сервисами. Часто WFM берет на себя функции ESB. Возникает непонимание – где между ними граница.
 Непонимание – что надо делать в сценариях WFM, что в hardcoded программных компонентах.
 Процесс разработки сценариев WFM сильно заорганизован. В результате непонятно, что делать быстрее – разработать (или изменить) сценарий для WFM или «захардкодить» сценарий в программном компоненте (и вносить изменения в компонент).
Причина проблем, на мой взгляд, похожа на ситуацию с ESB – Agile подход (см. ) – сначала делай, потом думай.
Как результат – большой эффективности от применения WFM не было, скорее удорожало систему в целом, т.к. необходимо поддерживать еще один фреймворк и соответствующих специалистов.
Очень жаль. Фреймворк потенциально может принести очень большой эффект. Бизнес задач, для которых подходит данный фреймворк – очень много, если не большинство.

Концепция управления правилами обработки данных (Rule Based systems, BRMS)

В начале 2000х годов концепция стала активно развиваться, потом утихла. Основная идея – похожа на идею WFM - вывести часто изменяемые правила обработки данных в подсистему (фреймворк), позволяющую добавлять и изменять правила обработки данных без программирования, динамически, быстро вносить изменения в правила обработки данных с учетом часто меняющихся структур обрабатываемых объектов данных. В отличие от сценариев WFM правила выполняются не последовательно, а, в общем случае, в произвольном порядке. Система сама определяет, какие правила применять к объектам данных в зависимости от параметров объектов и параметрам других, логически связанных объектов. Подобные фреймворки часто называют экспертными системами, системами управления знаниями, а динамически расширяемые наборы правил – базами знаний. Часто такие системы относят к классу систем «искусственного» интеллекта, учитывая, что системы такого типа могут выполнять не только простые, одноступенчатые обработки данных, но и порождать новые объекты данных, к которым применяются другие правила, т.е цепочки выводов. Некоторые из них поддерживают и «обратные» цепочки выводов – когда по полученному «результирующему» объекту система (фреймворк), пытается применить правила в «обратном» порядке для определения, что же могло привести к такому результату.
Фреймворков такого типа много, например ILOG JRules, JBoss Drools
В начале 2000х в компании по разработке биллинговых систем для телекоммуникационных компаний Protek LLC (Британская компания в Москве), участвовал в попытке использовать ILOG Rules для ввода проектировщиками тарифных моделей правил обработки объектов данных по фактам предоставления телекоммуникационных услуг и далее использования этих правил для обработки входящих объектов данных. Не считаю, что это была хорошая идея, но такая тенденция была в то время в среде некоторых западных компаний-разработчиков биллинговых систем. По моим представлениям, обработка биллинговых объектов – скорее сценарий, чем набор правил.
Однако идея очень хорошая. К сожалению, в явном виде мало применяется, при том, что во многих, если не большинстве систем, с которыми приходилось сталкиваться, элементы такой функциональности используются (иногда очень существенно), но реализуются собственными силами разработчиков, без использования готовых, развитых, отработанных фреймворков.

Концепция встроенных бизнес и системно-ориентированных языков описания сценариев и правил обработки данных

Идея использования встроенных в систему бизнес ориентированных языков программирования используется давно и довольно успешно. Развитые системы, типа 1С, SAP R3 такой подход применяют.
Изначально предполагалось создавать высокоуровневые языки программирования для динамического расширения функциональности программных систем самими пользователями, которые могли добавлять свои сценарии и правила обработки данных. К сожалению, по моему мнению, со временем эти языки превратились из высокоуровневых бизнес ориентированных в полноценные языки практически общего назначения, с которыми уже не могут работать обычные бизнес пользователи, даже продвинутые, зато зародился отдельный класс программистов. Можно было не создавать новых языков программирования, а просто предоставить библиотеки процедур обработки бизнес данных для использования обычными программистами на обычных широко используемых языках программирования.
Хорошо если высокоуровневые языки программирования предоставляют пользовательский интерфейс для ввода сценариев обработки объектов данных и формул расчета, позволяющий создавать программы (скрипты) конечными пользователями без программирования. Затем эти скрипты сохраняются и используются (интерпретируются) системой при обработке объектов данных.
Я участвовал в такой разработке - биллинговая система для Deutche Telecom во время моей работы в компании Telesens AG в Германии (Кёльн 1999-2000г). Идея и реализация были очень успешными. Основные аспекты:
 Высокоуровневый язык описания тарифных планов, включающий формулы и условия (варианты - разветвления) по обработке первичной информации по предоставленным телекоммуникационным услугам;
 Экранные формы ввода элементов языковых конструкций, позволяющий бизнес пользователям самостоятельно разрабатывать тарифные планы без программирования (хотя язык программирования тоже был доступен);
 Использование автоматизированных средств генерации интерпретаторов и компиляторов языков по их формализованному описанию (например BNF – Бекусовские нормальные формы).
Кстати, проектирование бизнес ориентированных языков, создание интерпретаторов и компиляторов, что часто пугает разработчиков, на самом деле очень просто. Средства, которые мы тогда использовали типа YACC делала этот процесс очень простым. В последствии я использовал для этих целей JavaCC (для разработчиков на языке Java) – тоже очень просто, быстро и эффективно.
Пока все, надеюсь будет продолжение (если будет интерес).
Буду благодарен за замечания и предложения.

Всем привет, можете подсказать хорошую программу для создания ER-диаграммы? Пока остановился на IBM Rational Software Architect.