Ключевые слова для гугления: нормализация, звезды и снежинки.

Проще говоря, делать классическую звезду (и снежинку как ее развитие) намного выгоднее с точки зрения производительности, и обновления и выборок, для задач подсчета количества.
Это уже с точки зрения выдачи результата проще писать запрос к одной таблице чем помнить что у тебя их две и правильно делать связку таблиц на каждый запрос, но это обычно решается вьюшками.

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

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

Ну у тебя типичный OLAP куб уже же строится. Список сущностей (udp пакеты) имеющих атрибут (адрес), и надо подсчитать количество появления атрибута. Так что две таблицы для минимального куба идеально. Одно-лучевая звезда просто напрашивается!
И тут действительно nosql база будет хорошо работать и любые объемы съест не подавившись.

Наоборот. Есть три атрибута? Расценивай их как три сущности. А потом уже смотри как они между собой взаимодействуют, что есть атрибут чего.

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

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

Разница между реляционной и не-реляционной базой на самом деле очень маленькая. И заключается она всего-лишь в том, что в "реляционной" можно определить связи (внешние ключи которые) и сам движок БД будет отслеживать их целостность при изменении данных. А в не-реляционной такой возможности нет, там за целостностью данных надо следить на уровне приложения. И все.
Вся остальная разница чисто косметическая. Другой язык запросов, другие возможности-ограничения на конкретные плюшки (в смысле что именно движок БД способен автоматизировать). Но и только.


Вот смотри, ты сейчас используешь Кассандру которая хочет держать счетчики в отдельных таблицах и не мешать их с полями другого типа. Это плюшка. А Оракл вообще не имеет счетчиков, нет у него такой плюшки в движке, поэтому ораклисты вынужденны использовать обычное целочисленное поле. А еще чтобы сделать автоматическую нумерацию записей ораклистам надо создать sequence. А mssql-овцам не надо, им хватает просто определить поле как autoincrement. А sqlite-овцам нет нужды определять текстовое это поле или числовое, чрезвычайно удобно, очень непривычно и может привести к потерям производительности, но очень удобно. А в IQ нет нужды делать индексы, там каждое поле автоматически индексировано потому что у БД колоночный метод хранения таблиц - очень тормознуто на обновлениях, но для выборок - конфетка.

Это все плюшки, уникальные и местами загадочные, но плюшки конкретных движков и технических решений примененных в них.
Но разве это отменяет принципы организации данных? Ты в любой базе можешь сделать как 0nf простынь, так и снежинку в 5nf (которая теоретический идеал, но никто не видел на практике).

Не, я конечно понимаю что некоторые местные люди считают что data structures в java и data structures в c++ это очень разные data structures и читать книжки использующие "вражеский язык" для понимания самих data structures это уголовно наказуемое деяние. Но ...


Повторюсь: инструментом надо уметь пользоваться. От человеческой глупости никакой инструмент спасти не может.
Мало ли ты встречал приложений завязанных на Oracle/MSSQL/etc которые сами следят за связностью данных в разных таблицах? А ведь это типичные RDBMS используемые в модели NR-DBMS и то что они используют язык запросов наследованный от SQL-92 не делает их реляционными.
С другой стороны, я сейчас работаю с nosql базой (разработанной в начале 80-х), совершенно другой язык запросов, таблицы называют файлами и хранят структуру таблиц во внешних текстовых файлах... Но при этом весь доступ к БД организован через одну единственную билиотеку, которая читает те текстовые файлы и самостоятельно следит за целостностью ссылок. Так что несмотря на то что это "библиотека" - на практике получается классический embedded rdbms. При этом она считается и описывается как nosql, потом что там нет вообще ни грамма от sql :) Там конечно тоже не мало странностей и идиотизмов (в первую очередь из-за "встроенности" с которой надо уметь работать), но...