Обсуждение:ER-модель

О тире и дефисах

Создаю тему для коллеги Cherkash, хотя по правилам это именно он должен был открыть обсуждение после отмены своей правки.

Касательно этого: Crow's foot — это не просто термин, это ещё и название, то есть имя собственное. А их их надо обычно передавать с заглавных букв. «Inverted arrow» и «fork» — да, можно с маленькой и в кавычках. В статье Terry Halpin эти термины пишутся как The crow’s foot notation (с маленькой и без кавычек), “inverted arrow” и “fork” (с маленькой и в кавычках). Но в современной специальной литературе всё же чаще пишут «The Crow’s Foot notation» или «the Crow's foot notation» (см. пример в монографии и пример в документации по программе моделирования).

Что до написания «Entity-Relationship model» и «Entity-Relationship diaram», особенно в названиях статей, то вам проще всего заглянуть в первоисточник, где вы довольно быстро увидите, что эти термины пишутся строго через дефис, как в тексте, так и в названии статьи. Этот источник у меня вообще не открылся, не смог перепроверить]. Здесь и здесь вообще всё безграмотно названо (вместо тире — дефис, «Entity Relationship» через пробел), но зачем исправлять, пусть будет как в оригинале.

Касательно этого: как раз в русском тут дефис, что отлично видно по имеющейся ссылке на источник (статья в osp.ru).

Касательно этого: Нетрудно открыть текст по ссылке и убедиться, что в оригинале написано именно «E-R», а не «E–R», как вы исправили.

Выводы пока такие: большая часть ваших исправлений не соответствует источникам. Можно вполне согласиться лишь с «inverted arrow» и «fork», а также с тире в интервалах. Касательно «The crow’s foot notation» / «The Crow’s Foot notation» / «the Crow’s foot notation» ситуация как минимум спорная, возможно, следует сослаться на все варианты. Нужно обсуждать, и не вносить много спорных правок скопом, тем более, после их отмены. Евгений Мирошниченко 19:08, 27 июня 2020 (UTC)

Всё просто: все эти исправления (заглавные/строчные, пунктуации и т.д.) — суть, правки стиля. Такие правки не руководствуются источниками и цитатами, а используют, в идеале, единый стиль, выбранный именно в википедии, причём эти стили могут различаться (и различаются!) в зависимости от языка (например, для русского используем ВП:ОС, а для английского — WP:MOS). Поэтому ссылаться на стиль, выбранный в цитируемых источниках — бессмысленно. Это не имеет отношения к тому, какого стиля мы придерживаемся в википедии. Как Вы верно подметили, разные источники могут иметь стилистическую редактуру разного качества, подчас, достаточно сомнительного — но это не повод копировать всё слово в слово (или символ в символ) ;) Cherkash (обс.) 23:31, 29 июня 2020 (UTC)

Если речь идёт о названиях источников, я сторонник того, что их исправлять не нужно. Такое название им дал автор, и править его — всё равно, что править чужие цитаты. Точно так же не нужно исправлять сложивишиеся термины. Всё это — уже не элемент стиля. Стиль относится к тексту статей. Цитаты и названия обычно передают как есть. Тем более, что широко распространено мнение о том, что правила пунктуации английского языка менее строгие, чем русского, и их использование часто зависит от самого автора. Евгений Мирошниченко 05:20, 30 июня 2020 (UTC)

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

Сложившиеся же термины не становятся именами собственными просто от того, что они "сложились" как термины. Поэтому заглавные буквы в Crow's Foot ничем не оправданы. Cherkash (обс.) 14:17, 30 июня 2020 (UTC)

>можно смело считать это творчеством редактора/корректора, а вовсе не автора. Это ваше личное мнение, впрочем, даже если это творчество редактора/корректора, то данный факт делает такое написание ещё более веским. Редакторы/корректоры лучше знают, как правильно.

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

Что касается последнего абзаца, то это ваше личное мнение, которое противоречит англоязычным источникам, я приводил примеры. И да, термины нередко становятся именами собственными, как названия. Та же «Entity-Relationship model» в пример тому. Слова entity и relationship -- нарицательные, посему пишутся с маленьклй буквы, а «Entity-Relationship model» — уже название, в котором эти слова пишутся с заглавной. Евгений Мирошниченко 15:55, 30 июня 2020 (UTC)

Что-то сдаётся мне, Вы перепутали имена собственные, которые всегда пишутся с заглавной буквы, с именами нарицательными, которые иногда пишутся с заглавной буквы некоторыми авторами (особенно в технических текстах), чтобы выделить часто использующиеся и/или важные в конкретном тексте термины. Т.е. последнее — вопрос чисто стилистический. И, кстати, если уж на то пошло, то entity–relationship model пишется с маленькой буквы (ср. здесь) ;) Cherkash (обс.) 20:48, 30 июня 2020 (UTC)

Проектирование базы данных

Во время проектирования баз данных происходит преобразование ER-модели в конкретную схему базы данных на основе выбранной модели данных (реляционной, объектной, сетевой или др.).

Интересно, только мне эта фраза режет слух? Если "происходит преобразование ER-модели в конкретную схему базы данных", это УЖЕ означает, что в качестве модели выбрана ER-модель, и поэтому не требуется уточнять, что это осуществляется на основании выбранной модели данных. Но я так чувствую, этот "тянитолкай" получился не случайно. Очевидно, автор подразумевает, что ER-модель - это более общая модель данных, если сравнивать ее с более конкретными моделями данных: реляционной, объектной, сетевой. Но при этом и реляционная модель, и ER-модель - это МОДЕЛЬ ДАННЫХ. И даже ссылки ведут на одну и ту же страницу - собственно, модель данных. (К слову, также считает, например, и Дейт: пишет об этом в своей книге "Введение в СУБД". ) Таким образом, непонятно, почему невозможен, например, такой вариант: во время проектирования баз данных происходит преобразование реляционной модели в конкретную схему базы данных на основе выбранной модели данных (ER, объектной, сетевой или др.). А что, почему бы и нет? Логика в точности та же самая. Исправьте кто-нибудь это досадное недоразумение.Clothclub (обс.) 08:38, 31 января 2021 (UTC)

Да, в предложении действительно была корявость. Я подправил.

По сути дела. Да, ER-модель была задумана своим автором как модель данных, там даже какое-то манипулирование предполагалось. Но это информация из разряда "мало кто знает, что...", так как не существует ни одной СУБД на основе ER-модели.

По факту десятки лет ER-модель используется не как модель данных, а просто как средство (формализм) семантического моделирования. Кроме того, ER-нотация Чена для ER-модели не прижилась, и все используют варианты нотаций а-ля Crow's foot / IE с бинарными связями (n-арные связи тоже не прижились). Конкуренты типа UML есть, но они применяются очень редко.

Таким образом, на уровне семантического (концептуального) моделирования/проектирования с помощью формализма ER-модели строится достаточно абстрактная схема предметной области. Она настолько абстрактна, что не использует специфику ни одной модели данных, ни реляционной, ни объектной, никакой. Собственно говоря, так и положено для семантической модели.

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

Уровни моделирования / проектирования

Схема (результат моделирования / проектирования)	Уровень абстракции	Формализм (средство моделирования)	Какую специфику СУБД учитывает
Концептуальная / семантическая схема БД, она же концептуальная / семантическая модель предметной области	Высокий (концептуальное/семантическое моделирование)	ER-модель, диаграмма классов (UML) и т.д.	Никакую
Логическая схема БД	Средний (логическое моделирование)	Модель данных (например, реляционная)	Учитывает специфику модели данных (например, отношения, внешние ключи и т.д.), но не конкретной СУБД
Физическая схема БД	Низкий (физическое моделирование)	Требования конкретной СУБД	Система типов данных, требования к именованию объектов, поддерживаемые механизмы ограничений целостности и т.д.

Прошу заметить, что я специально стараюсь использовать слова «схема» для результата моделирования, а «модель» для инструмента моделирования. Иначе нас подстерегает чудовищная путаница («спасибо» учёным и инженерам прошлого), где вы не отличите "ER-модель" как формализм (средство моделирования) от "ER-модель" как результат моделирования конкретной БД. Современные CASE-средства для проектирования БД только подбавляют жару в этот хаос, изобретая чудовищных терминологических уродцев вроде "conceptual data model" ,"logical data model" и "physical data model". Евгений Мирошниченко 13:16, 31 января 2021 (UTC)

Евгений Мирошниченко, я так понимаю, вы автор статьи. Ок, спасибо, что так быстро и еще и столь подробно ответили. И за исправление - тоже. Правда, на мой взгляд, вы не то исправили, что следовало. Надо было тогда так и написать, что есть концептуальная модель данных, а есть логическая модель данных. Но так исторически сложилось, что и то, и другое называют моделью данных, без уточнения. Короче, то, что вы сюда написали, надо было и написать в статью. С другой стороны, я не уверен, что это на самом деле так. Дейт, например, рассматривает модель "сущность-связь" (в самой первой главе). А затем говорит, что существует и другой подход, реляционный, где данные хранятся в виде высказываний. И ни один из подходов не "выше" и не "ниже" другого, условно говоря. Иными словами, эти две модели существуют как бы параллельно друг другу, поскольку это разные подходы к моделированию данных. Соответственно, нигде не сказано, что проектирование БД нужно начинать с построения ее ER-модели. Дейт, например, пишет, что при проектировании (реляционной) базы данных нужно решить вопрос, какие необходимы базовые переменные отношения и какой набор атрибутов они должны включать. При этом слова концептуальный и логический (уровень проектирования) он считает синонимами. Правда, затем он пишет, что бывает еще и семантическое моделирование, которое заключается в построении модели "сущность-связь", которую затем можно использовать на практике для "нисходящего проектирования систем". Ну не знаю, я не профессионал, скорее, любитель. Со своего любительского уровня могу сказать, что очень трудно разобраться по таким невнятным книгам (и соответствующим статьям в википедии). Что касается СУБД на основе ER-модели - вроде бы в MS Access именно такая была. Правда, там были не сущности, а таблицы, но вот связи "один-ко-многим", "один-к-одному" там точно были.Clothclub (обс.) 03:24, 1 февраля 2021 (UTC)

Нет, я не автор статьи. В Википедии вообще такого понятия нет, ведь статьи редактируют все желающие.

Вы много написали, и довольно хаотически. Поэтому я прокомментирую некоторые моменты.

> Надо было тогда так и написать, что есть концептуальная модель данных, а есть логическая модель данных. Таких моделей данных не существует. Существуют только такие термины в некоторых программных средствах для проектирования БД, но это на совести безграмотных создателей. Правильно говорить «концептуальная модель базы данных», «логическая модель базы данных», словами «концептуальная» и «логическая» уточняя уровень абстракции моделирования, как я нарисовал в табличке выше.

> Дейт, например, рассматривает модель "сущность-связь" (в самой первой главе). Нет, Дейт в первой главе не рассматривает модель «сущность-связь». Он пользуется только графической нотацией (ER-диаграммой) и очень кратко — терминами «сущность» и «связь». ER-модель же не рассматривает и тем более моделью данных её не называет. Далее по главе Дейт (см. подраздел «Сущности и связи») как раз начинает пояснять, что сущности, связи и атрибуты надо как-то в базе данных представлять. Цитирую: «связи должны быть представлены в базе данных наравне с основными сущностями предметной области». И далее, в примечании: «Характерной особенностью реляционных баз данных является то, что основные сущности и связи между ними представлены с помощью отношений (relation)».

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

Далее (см. «Данные и модели данных») у него говорится: «Однако реляционная модель — не единственная возможная модель данных. Существуют и другие модели (раздел 1.6)». Опять же отмечу, что ER-модель здесь он к моделям данных не причисляет, хотя вроде бы её терминологию только что использовал.

> нигде не сказано, что проектирование БД нужно начинать с построения ее ER-модели. Абсолютно верно. Проектирование БД можно осуществлять на любом желаемом уровне абстракции. Можно, например, вообще сразу садится и создавать таблицы на языке SQL, я так делал. Штука в том, что необходимость в проектировании на других уровнях абстракции возникает при увеличении размера и сложности системы. Как известно, абстракция — средство борьбы со сложностью. При абстрагировании мы отбрасываем менее важное в пользу более важного.

Например, если мы захотим обсудить БД с кем-то, нам нужно хотя бы нарисовать схему БД на уровне физической модели, поскольку разбираться в деталях синтаксиса SQL-скриптов неразумно. Если мы захотим избавиться от специфики конкретной СУБД (например, она ещё не выбрана), мы можем нарисовать схему БД на логическом уровне. А если мы захотим отбросить ещё больше подробностей, мы нарисуем схему БД на концептуальном уровне, где нет, например, внешних ключей, зато есть связи многие-ко-многим. Можно подняться ещё выше, и нарисовать схему без типов данных у атрибутов, затем ещё выше — схему вообще без атрибутов.

Поэтому проектирование большой и сложной БД рациональнее бывает начинать «сверху», где минимум ненужных деталей.

> Что касается СУБД на основе ER-модели - вроде бы в MS Access именно такая была. Нет.

> Правда, там были не сущности, а таблицы, но вот связи "один-ко-многим", "один-к-одному" там точно были. Это просто многие рисовалки даже в физической схеме реляционной БД приделывают «мощность связей», хотя там по факту уже нет никаких связей, а есть внешние ключи. Для каждого FK они рисуют значок мощности «много» со стороны FK и значок «один» со стороны PK. Но, к примеру, увидеть там связь типа «многие-ко-многим» невозможно. Евгений Мирошниченко 18:29, 1 февраля 2021 (UTC)

Евгений Мирошниченко. Извините, что так медленно отвечаю, просто отвлекли некоторые дела. Я уж и вовсе хотел "забить", тем более, что более-менее разобрался, да и по большому счету я с вами согласен (считайте, что вы меня убедили). Но решил все же ответить. Евгений Мирошниченко, вы прямо-таки очень педантичный человек. И мне это даже нравится: хочется думать, что я сам хоть немного такой же. Тем не менее, на мой взгляд, в данном случае это мешает вам за деревьями увидеть лес.

>Нет, я не автор статьи. В Википедии вообще такого понятия нет, ведь статьи редактируют все желающие.

Конечно, статьи редактируют все желающие. Тем не менее, если уж говорить совсем строго, автор - это тот, кто написал самый первый вариант статьи. Остальные - только редакторы. Конечно, правка правке - рознь. Бывают такие исправления, в которых статья оказывается полностью переписанной, так что уже и не скажешь, кто тут автор. Но поскольку вы первым откликнулись, я решил, что вы эту статью как бы "курируете". А с чего вам это делать, если вы не считаете ее своей собственностью хоть в некотором смысле? Не в том смысле, что это ваша интеллектуальная собственность, а в том смысле, что вы отвечаете за написанное. Ну да бог с ним, не хочу скатываться в оффтоп, просто объясняю, что я имел в виду (хотя мне казалось, это и так очевидно). Впрочем, я уже посмотрел в "истории": статья очень старая (2006 года), а автор - действительно, кто-то другой, некто Greck (если только это не ваш собственный никнейм). Ладно, будем считать, что претензии я предъявляю не вам, а 'автору статьи'. Так что не принимайте их на свой счет. Надеюсь, это поможет избежать лишних конфликтов.

>Правильно говорить «концептуальная модель базы данных», «логическая модель базы данных», словами «концептуальная» и «логическая» уточняя уровень абстракции моделирования

Как скажете, вам виднее, конечно. Просто в данном случае вы спорите сами с собой. Потому что именно это я и предположил в самом начале обсуждения: что одна модель более абстрактна по сравнению с другой. И заодно заметил, что из статьи этого понять невозможно (поскольку везде стоит ссылка на одну и ту же статью "Модель данных"). Я вижу, что вы разделяете понятия модели данных и модели базы данных. Возможно, это как раз то, о чем говорил Дейт: нужно отличать модель данных в смысле языка программирования от модели данных в смысле программы, написанной на этом языке (конец 1.3). Первое - это модель данных, второе - модель базы данных. Тем не менее, я просто процитирую обсуждаемую статью:

Во время проектирования баз данных происходит преобразование схемы, созданной на основе ER-модели, в конкретную схему базы данных на основе выбранной модели данных (реляционной, объектной, сетевой или др.).

Я это понимаю (по аналогии с языком программирования) так: во время проектирования бд происходит преобразование программы, написанной, например, на языке Turbo Pascal, в конкретную программу, написанную на языке C++, имеющую тот же функционал. Синтаксически уже не придерёшься, хотя смысла особо не прибавилось (ибо зачем переписывать программу с одного языка на другой, более "конкретный"). Я отталкиваюсь только от того, что написано в статье: ER-модель - это модель, и реляционная модель - это модель. И если уточнить, что за модель, о какой модели идет речь, не останется ничего другого, кроме как ответить: модель данных. Получается, что ER-модель действительно более абстрактна по сравнению с реляционной моделью данных. Именно данных, а не базы данных. Что бы вы ни говорили, это следует из самой статьи. Вернее, не следует, а, скажем так, это единственная разумная трактовка написанного, единственный способ понять написанное. Если вы считаете, что так говорить ошибочно, тогда исправляйте статью. Напишите что-нибудь вроде 'ER-модель - это не модель'. Ведь именно в этом вы пытаетесь меня убедить, насколько я понимаю.

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

PS

ER-модель представляет собой формальную конструкцию

Здесь тогда тоже нужно уточнить, что это именно ER-модель БАЗЫ данных, а не просто данных.

Дейт в первой главе не рассматривает модель «сущность-связь». Он пользуется только графической нотацией (ER-диаграммой) и очень кратко — терминами «сущность» и «связь». ER-модель же не рассматривает и тем более моделью данных её не называет. Далее по главе Дейт (см. подраздел «Сущности и связи») как раз начинает пояснять, что сущности, связи и атрибуты надо как-то в базе данных представлять.

Наверное, вы правы, он рассматривает ER-модель конкретной БАЗЫ данных, а не ER-моделирование как таковое. В то же время, неправильно употреблять слова «сущность» и «связь» вне контекста. Какая сущность - эссенция? Какая связь - быть может, половая? Эти слова не имеют смысла вне рассматриваемой ER-модели, хоть имя ее и не произносится (тем не менее, очевидно, что сущность и связь образуют модель сущность-связь, тут один шаг до этого). И наоборот, если автор говорит, что в любых данных всегда можно выделить т.н. сущность и т.н. связь - это ни что иное, как начало теоретизирования или, другими словами, моделирования.

Что касается того, что связи и атрибуты надо как-то в базе данных представлять - на мой взгляд, это не более, чем неудачный перевод. Ибо, что значит, представлять что-либо в базе данных??? Наоборот, мы можем представить себе базу данных (у себя в голове) в виде сущностей и связей, и таким образом ее смоделировать. Вообще, представить себе что-либо, вообразить, осмыслить - это и значит построить модель. (Возможно, под представить имелось в виду реализовать на каком-либо языке.)

Это просто многие рисовалки даже в физической схеме реляционной БД приделывают «мощность связей», хотя там по факту уже нет никаких связей, а есть внешние ключи. Для каждого FK они рисуют значок мощности «много» со стороны FK и значок «один» со стороны PK. Но, к примеру, увидеть там связь типа «многие-ко-многим» невозможно.

Как хотите, но связи там все-таки были - я имею в виду, нарисованные в виде "ниточек". Тогда как в реляционной модели все связи реализуются только с помощью таблиц, как вы сами и заметили. Вообще, если, как вы говорите, есть чёткие правила преобразования схемы на основе ER-модели в схему на основе реляционной модели, тогда можно написать, условно говоря, "компилятор", который преобразует ER-модель в реляционную модель. И если этого еще никто пока не сделал, это же не значит, что это теоретически невозможно. Что касается связей "многие-ко-многим" - от них вроде бы принято избавляться с помощью промежуточных таблиц. А, я так понимаю, потому и принято, что невозможно построить такую связь непосредственно. Ну ок.Clothclub (обс.) 19:20, 19 февраля 2021 (UTC)

>Я вижу, что вы разделяете понятия модели данных и модели базы данных. Возможно, это как раз то, о чем говорил Дейт: нужно отличать модель данных в смысле языка программирования от модели данных в смысле программы, написанной на этом языке. Именно так.

>ибо зачем переписывать программу с одного языка на другой, более "конкретный". Это происходит постоянно. Программа с языка высокого уровня (машинно-независимого, то есть более абстрактного) преобразуется в программу в машинных кодах (низкого уровня абстракции). В некоторых системах это преобразование многоступенчатное. Например, почитайте про en:Intermediate representation. Что же касается проектирования БД, то зачем это делать я уже подробно описал выше, см. «Проектирование БД можно осуществлять на любом желаемом уровне абстракции».

>ER-модель - это модель, и реляционная модель - это модель. Слово «модель» настолько зашоркано и переиспользовано, что практически может оначать всё, что угодно. Об этом, например, Дейт подробно писал в статье "Models, models, everywhere, nor any time to think", в своей книге «Date on Database: Writings 2000-2006». Поэтому модель модели рознь. С РМД хоть проще, этот термин всегда означает «модель данных». А вот «ER-модель» может означать как название формализма, так и конкретную систему, созданную в этом формализме. Просто-напросте нет специального термина для модели базы данных, созданной в формализме «ER-модель», её тоже часто называют «ER-модель». Это путаница. А термины вроде «ER-модель базы данных» никто не использует, они не встречаются. Хотя я бы использовал.

>Что касается того, что связи и атрибуты надо как-то в базе данных представлять - на мой взгляд, это не более, чем неудачный перевод. Ну, просто вы путаете совершенно разные русские слова «представить» в смысле «вообразить» и «представить» в смысле «преобразовать, отобразить в другой форме». Первое соответствует английскому imagine, второе — английскому represent. Когда я говорю, что «статистические данные представлены на рисунке в виде круговой диаграммы», это же не значит, что их кто-то в уме «вообразил» в таком виде; это значит, что данные «преобразованы и отражены» в другой форме. Этот смысл слова «represent» словари передают так: «represent = to be a sign or symbol of something; to show someone or something in a particular way».

> Как хотите, но связи там все-таки были. Нет, не было. Линиями там отображаются внешние ключи. Это не то же самое, что связи из ER-модели. Я уже написал, что просто некоторые рисовалки зачем-то пририсовывают к таким линиями «псевдо-мощность», типа «один-ко многим». Но это совершенно бесполезно, проще нарисовать стрелку от FK к PK. И то, что на таки схемах невозможно «создать» связь «многие-ко-многим» и доказывает, что это вовсе не те связи, это просто «псевдо-мощность».

>тогда можно написать, условно говоря, "компилятор", который преобразует ER-модель в реляционную модель. Во-первых, если придираться, то надо примерно так: «преобразует модель БД на основе ER-модели в модель БД на основе РМД / в модель реляционой БД». Во-вторых, такие трансляторы встроены в каждое CASE-средство проектирования БД (data modeling tools): Toad Data Modeler, PowerDesigner и т.д., тысячи их.

>Что касается связей "многие-ко-многим" - от них вроде бы принято избавляться с помощью промежуточных таблиц. Это только при преобразовании модели БД на основе ER-модели в в модель реляционой БД. Если к примеру, преобразовывать модель БД на основе ER-модели в модель объектно-ориентированной БД, то там есть напрямую связи между объектами типа «многие-ко-многим». Евгений Мирошниченко 10:14, 20 февраля 2021 (UTC)