Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 21
Целостность данных – это свойство способности по одним данным восстанавливать другие, при этом не теряя семантическое и реляционное единство этих данных.
Вообще-то, целостность данных — это всего лишь отсутствие ошибок в них.
Информацию в таблицах можно разделить на два вида. На информацию, которая описывает объекты (субъекты), связи и информацию, которая описывает действия, процессы, события, иное.
В справочниках содержатся сведения об объектах и субъектах, связях. В связках содержатся сведения о действиях, процессах, событиях и так далее.
Откуда вы взяли это деление?
Статично-динамичный справочник – справочник, в котором хранятся данные о связях.
Связях чего с чем?
Необходимо пояснить, что это за поля, которые образуют справочник, но не могут быть выделены в отдельную таблицу-справочник. Примером таких полей являются поля «комментарий», «жалоба», «описание», «предложение». Словом, если приводить популярный пример, то поле «сообщение» в таблице базы данных любой социальной сети…
Что в этих полях «справочного»? Что вы вообще понимаете под «справочником»?
А теперь простой встречный вопрос: чем вам не угодило стандартное разделение на сущности и связи?
Откуда вы взяли это деление?
Опытно-экспериментальным путём, маленьким теоретическим исследованием. Понимаю, что есть много теорий, которые могут объяснить лучше и эффективнее. Думаю, что данное деление — это вариант, который просто имеет права существовать.
Связях чего с чем?
Сущностей с друг другом через какое либо взаимодействие. Описывается таблица, в которой хранятся внешние ключи и иные данные. Через ключи идёт связь с сущностями, которые перечислены в справочниках.
Что в этих полях «справочного»? Что вы вообще понимаете под «справочником»?
Под справочником понимаю данные, которые кратко описывают сущность и служат для её однозначной идентификации (речь не идёт об уникальных идентификаторах). Говоря об однозначной идентификации, я имею в виду данные, которые позволяют описать сущность, чтобы её можно было найти, взаимодействовать с ней, иное.
Касаемо полей, которые являются справочными, но в таблицу-справочник не выделены. Иногда из таких полей получаются полноценные справочники. Например, есть таблица, в которой присутствует поле «жалоба». Бывают ситуации, когда в такое поле начинают вписывать одно и то же (смысл одинаковый — конструкции разные), но, естественно, разными синтаксическими конструкциями. Если замечена тенденция по уменьшению частоты появления новых данных в таком поле, то данные, которые в нём существуют, систематизируют и выделяют в отдельный справочник. В дальнейшем для хранения данных по жалобам используются уже внешние ключи. Такое бывает…
А теперь простой встречный вопрос: чем вам не угодило стандартное разделение на сущности и связи?
Ещё как угодило! На основе этого разделения эта классификация и описана.
Под справочником понимаю данные, которые кратко описывают сущность и служат для её однозначной идентификации (речь не идёт об уникальных идентификаторах).
Зачем нужно это определение? Почему просто не говорить «сущность»?
На основе этого разделения эта классификация и описана.
Нет. Вы оперируете «справочниками». А в сущностях такого понятия нет.
Действительно, такого понятия в сущностях нет. Зато есть само понятие «сущность».
А справочники здесь описываются, как списки, в которых эти сущности перечисляются.
А справочники здесь описываются, как списки, в которых эти сущности перечисляются.
А справочники здесь описываются, как списки, в которых эти сущности перечисляются.
Зачем вводить это понятие?
И да, то, что у вас называется «связками» — внезапно, тоже сущности в парадигме сущностей-связей.
Согласен с Вами.
А понятия вводятся для разделения сущностей. Ведь, если брать в общем, то каждая таблица описывает сущность.
Но в одних таблицах описываются действия, а в других сущности, которые в этих действиях принимают участие. И так далее…
А понятия вводятся для разделения сущностей. Ведь, если брать в общем, то каждая таблица описывает сущность.
Но в одних таблицах описываются действия, а в других сущности, которые в этих действиях принимают участие. И так далее…
Это разделение надумано и только запутывает. В терминах модели не существует «действий, в которых принимает участие сущность», там есть только сущности, описывающие предметную область (в том числе и то, что вы считаете действиями). Как следствие, парадигма сущность-связь прекрасно на это ложится.
А в вашей парадигме немедленно возникает вопрос: почему транзакция — это «связка» (а вес — справочник)?
(кстати, нет, не каждая таблица описывает сущность).
А в вашей парадигме немедленно возникает вопрос: почему транзакция — это «связка» (а вес — справочник)?
(кстати, нет, не каждая таблица описывает сущность).
Связях чего с чем?
Сущностей с друг другом через какое либо взаимодействие.
У вас в качестве примера приводится справочник окладов. Это связь каких сущностей друг с другом?
Виноват, не уточнил у Вас, что Вы имели в виду, когда задавали вопрос «Связях чего с чем?».
Если речь о справочниках, то они связи не хранят. Связи (согласно классификации, о которой сейчас говорим) описываются в таблицах-связках.
Если речь о справочниках, то они связи не хранят. Связи (согласно классификации, о которой сейчас говорим) описываются в таблицах-связках.
Вообще-то, это была цитата из вашего текста.
Так справочники хранят связи или нет?
Статично-динамичный справочник – справочник, в котором хранятся данные о связях.
Так справочники хранят связи или нет?
Здесь следует уточнить, чтобы не было такой путаницы.
Вполне вероятно, что мне не следовало выбирать в качестве понятия слово «связка» или уточнять, то есть, очень аккуратно описывать.
Мы с Вами говорим немного о разных видах связей. И виной здесь мои неточные формулировки.
Немного поправлю сам себя. Справочники хранят связи, но только тогда, когда эти связи (данные об этих связях) носят именно справочный характер. Пример таких связей — это связь этажа с кабинетом (на каком этаже какой кабинет находится).
И да, действительно, по данной классификации, это способен хранить только статично-динамичный справочник.
Вообще, любая таблица может связи хранить. Достаточным подтверждением этому является то, что в справочнике могут храниться внешние ключи (при чём в любом). Примером такого может быть внешний ключ — идентификатор пользователя, который модифицировал данные. Но это, опять же, немного другое…
Вполне вероятно, что мне не следовало выбирать в качестве понятия слово «связка» или уточнять, то есть, очень аккуратно описывать.
Мы с Вами говорим немного о разных видах связей. И виной здесь мои неточные формулировки.
Немного поправлю сам себя. Справочники хранят связи, но только тогда, когда эти связи (данные об этих связях) носят именно справочный характер. Пример таких связей — это связь этажа с кабинетом (на каком этаже какой кабинет находится).
И да, действительно, по данной классификации, это способен хранить только статично-динамичный справочник.
Вообще, любая таблица может связи хранить. Достаточным подтверждением этому является то, что в справочнике могут храниться внешние ключи (при чём в любом). Примером такого может быть внешний ключ — идентификатор пользователя, который модифицировал данные. Но это, опять же, немного другое…
А как вы отличаете «справочный» характер от «несправочного»?
Понимаете, ваше деление надумано, и никакой пользы не несет (приведите контраргумент, если я не прав); зато в нем существенно больше одной неоднозначности, которая только усугубляет путаницу.
Понимаете, ваше деление надумано, и никакой пользы не несет (приведите контраргумент, если я не прав); зато в нем существенно больше одной неоднозначности, которая только усугубляет путаницу.
Как раз сейчас дописал различие в статью:
Я не могу сказать, что Вы не правы или правы. Потому что все воспринимают всё по разному, именно поэтому не существует идеальных теорий. Прошу прощения за лишние буквы в ответе.
Могу лишь сказать, чем это полезно мне и тем, кому я это демонстрировал. И как это пригодилось.
Польза заключена в том, что, определяя, что является справочником, а что связкой, можно выбрать правильно структуру таблицы для хранения данных (естественно, что это один из многих критериев).
Почему структура не является надуманной? Потому что она взята на основе существующей. Понял, что смущает использование терминов «связи», «связка». И вообще пересечение терминов, которые отличаются друг от друга значениями…
Можно привести хороший пример. Сущность может описывать связь между сущностями (менеджер, клиент, продажа). Продажа является сущностью, описывающей связь менеджера и клиента.
Если брать данную классификацию, то был бы справочник менеджеров, справочник клиентов и связка «продажи».
Менеджеры и клиенты были бы в динамичном справочнике. Продажи в справочнике-связке (напомню, справочник-связка справочником в данной классификации не является!).
Кто-то поймёт про сущность, которая описывает связь между сущностями.
А кому-то будет легче сообразить, что менеджер — это субъект, клиент — это субъект. А продажи — это действия, в которых участвуют менеджер и клиент, они же образуют их связку.
Повторюсь, что эта классификация всего лишь один из вариантов описания… Кого-то она запутает, а кому поможет.
Признаюсь честно, когда начинал изучать базы данных, путался, и мозг отчаянно не хотел понимать, как это сущность может описывать связи между сущностями.
Классификация, если хотите, маленько уточняет, какие виды сущностей бывают (частично).
Отличие справочника от связки выражается в том, что таблицы-справочники могут быть самостоятельными и независимыми (то есть, при чтении данных некоторых справочников можно в целом понять семантику), а таблицы-связки практически никогда.
Я не могу сказать, что Вы не правы или правы. Потому что все воспринимают всё по разному, именно поэтому не существует идеальных теорий. Прошу прощения за лишние буквы в ответе.
Могу лишь сказать, чем это полезно мне и тем, кому я это демонстрировал. И как это пригодилось.
Польза заключена в том, что, определяя, что является справочником, а что связкой, можно выбрать правильно структуру таблицы для хранения данных (естественно, что это один из многих критериев).
Почему структура не является надуманной? Потому что она взята на основе существующей. Понял, что смущает использование терминов «связи», «связка». И вообще пересечение терминов, которые отличаются друг от друга значениями…
Можно привести хороший пример. Сущность может описывать связь между сущностями (менеджер, клиент, продажа). Продажа является сущностью, описывающей связь менеджера и клиента.
Если брать данную классификацию, то был бы справочник менеджеров, справочник клиентов и связка «продажи».
Менеджеры и клиенты были бы в динамичном справочнике. Продажи в справочнике-связке (напомню, справочник-связка справочником в данной классификации не является!).
Кто-то поймёт про сущность, которая описывает связь между сущностями.
А кому-то будет легче сообразить, что менеджер — это субъект, клиент — это субъект. А продажи — это действия, в которых участвуют менеджер и клиент, они же образуют их связку.
Повторюсь, что эта классификация всего лишь один из вариантов описания… Кого-то она запутает, а кому поможет.
Признаюсь честно, когда начинал изучать базы данных, путался, и мозг отчаянно не хотел понимать, как это сущность может описывать связи между сущностями.
Классификация, если хотите, маленько уточняет, какие виды сущностей бывают (частично).
Польза заключена в том, что, определяя, что является справочником, а что связкой, можно выбрать правильно структуру таблицы для хранения данных (естественно, что это один из многих критериев).
Приведите конкретный пример.
Продажа является сущностью, описывающей связь менеджера и клиента.
Эта трактовка ошибочна. Продажа — это сущность, описывающая событие. В числе атрибутов этого события есть менеджер и клиент.
Если брать данную классификацию, то был бы справочник менеджеров, справочник клиентов
Это только в том случае, если клиенты — это сущности, что далеко не всегда так.
как это сущность может описывать связи между сущностями.
Никак. Есть сущности, есть связи. Сущность не описывает связи.
какую структуру таблиц можно делать, чтобы [...] добиваться целостности в реляционных базах данных.
И ни слова про встроенные механизмы СУБД по поддержанию целостности?
По вашей статье же справочник-связка/связка одно и тоже. В первом случае плательщик + получатель — внешние ключи и в то же время первичный ключ, во второй код + код клиента — внешние ключи и в то же время первичный ключ. Если же у вас в первом случае первичным ключом является код транзакции, а плательщик + получатель лишь как внешние ключи, то не понимаю, зачем так делать.
Во время обучения мною было замечено, что трудности возникают уже на этапе понимания таблиц и того, как ими пользоваться.
Совсем неудевительно что у людей возникают трудности в понимании :) Это-ж надо умудриться так сложно написать про простые вещи.
Как часто должен меняться мой вес, чтобы начать его записывать в статично-динамичные справочники вместо статичных справочников? Серьезно, я последние лет 10 занимаюсь (в том числе) проектированием БД, но ни хрена в вашей статье не понял, кроме первого абзаца. К людям и правда приходит просветление после определений вроде «Избыточность данных – это состояние базы данных, при котором в таблицах присутствуют лишние данные.»?
Ладно бы еще «Избыточность данных – это состояние базы данных, при котором в таблицах присутствуют избыточные данные.», по прежнему определение не содержит новой информации, но по крайней мере не ошибочное (если в текущей структуре БД дублируются данные это не делает их лишними, говорить так ошибка). Может на практике вы как-то ловко все это комментируете, но сам по себе текст по моему ничего кроме каши в голове не создаст.
Ладно бы еще «Избыточность данных – это состояние базы данных, при котором в таблицах присутствуют избыточные данные.», по прежнему определение не содержит новой информации, но по крайней мере не ошибочное (если в текущей структуре БД дублируются данные это не делает их лишними, говорить так ошибка). Может на практике вы как-то ловко все это комментируете, но сам по себе текст по моему ничего кроме каши в голове не создаст.
Один-к-одному, один-ко-многим, многие-ко-многим.
Уникальные ключи, первичные ключи, внешние ключи.
1NF, 2NF, 3NF, BCNF, 4NF и др.
Этого достаточно.
«Просто, понятно, вольготно» (с) Высоцкий
Вы больше запутываете, чем классифицируете.
Уникальные ключи, первичные ключи, внешние ключи.
1NF, 2NF, 3NF, BCNF, 4NF и др.
Этого достаточно.
«Просто, понятно, вольготно» (с) Высоцкий
Вы больше запутываете, чем классифицируете.
Преподаю базы данных в университете лет 15. У Вас какая-то странная классификация, мягко выражаясь. Существует методология ER(Entity-Relation), где есть весьма понятная классификация, как таблиц, так и связей. Студенты ее с первого раза легко усваивают.
И определения у Вас просто атас! Что такое «реляционное единство»?
И определения у Вас просто атас! Что такое «реляционное единство»?
Согласен с Вами, что определение было дано «размытое». Поправил.
Фразу «реляционное единство» заменил на «отношения».
Под семантическим единством здесь понимается смысловая связь (как раз связь сущностей).
А под отношениями понимаются уже выраженные в логических (математических) закономерностях связи между данными (в реляционных СУБД — отношения между таблицами).
Фразу «реляционное единство» заменил на «отношения».
Под семантическим единством здесь понимается смысловая связь (как раз связь сущностей).
А под отношениями понимаются уже выраженные в логических (математических) закономерностях связи между данными (в реляционных СУБД — отношения между таблицами).
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Классификация таблиц в реляционных базах данных по признакам целостности и избыточности данных