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