Привет,

Рисую физическую модель данных в PowerDesigner. Стал искать нотацию IDEF1x (таблицы — прямоугольниками с прямыми и скошенными углами, связи — линиями со стороны множественности с закрашенными кругами). Нашел лишь частично. И тут задумался, можно ли применять эту нотацию не для логической, а для физической модели?

Даже более того, может быть связь, показанная стрелочками от таблицы к таблице, это и есть общепринятая нотация для случаев описания физической модели? Подскажите, пожалуйста. Возможно, я зря ищу IDEF1x или другие нотации, поскольку нужно применять обычные стрелочки?

Коллега ant. IDEF1x - стандарт информационного моделирования или моделирования данных, который изначально ориентирован на реляционную модель данных. В соответствии с этим в стандарте приняты некоторые ограничения, упрощения и добавления, которых нет в нотации-прародителе, а именно нотации "сущность-связь" Чена или лучше говорить о расширенной нотации "сущность-связь". Очень советую взять и почитать книгу Крёнке (думаю можно найти в библиотеке). И брать лучше 9-е издание. Написано доходчиво и очень понятно.

Если использовать ERWin, то помимо нотации IDEF1x там можно использовать нотацию IE - information engineering. Хотя внешнее отличие только в рисовании связей: там используется так называемые птичьи лапки для отображение максимальной кардинальности много. Надо сказать довольно удобное и быстро понимаемое средство отображение минимальных и максимальных кардинальностей связей.

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

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

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

Надеюсь, я пояснил ситуацию?

Спасибо за развёрнутый ответ и за рекомендацию книги. Из всего вышесказанного я сделал вывод, что использовать IDEF1x для описания физической модели некорректно. Буду использовать то, что предлагает PowerDesigner. Я не специалист в проектировании БД, поэтому спасибо за терпение.

Из всего вышесказанного я сделал вывод, что использовать IDEF1x для описания физической модели некорректно.

Оригинальный вывод Вы сделали. Я совершенно этого не утверждал, более того IDEF1x будучи стандратом нужен именно для описания физической модели в конечном итоге.

Правда, что Вы понимаете под физической моделью?

Оригинальный вывод Вы сделали. Я совершенно этого не утверждал, более того IDEF1x будучи стандратом нужен именно для описания физической модели в конечном итоге.

Тогда я сдаюсь. Из вашего предыдущего поста это не следует.

Правда, что Вы понимаете под физической моделью?

Сущности с атрибутами, которые представляют собой таблицы с полями, с указанием типа данных у полей, первичных и внешних ключей, а так же NULL/NOT NULL. И соответственно связи между таблицами...

Сущности с атрибутами, которые представляют собой таблицы с полями, с указанием типа данных у полей, первичных и внешних ключей, а так же NULL/NOT NULL. И соответственно связи между таблицами...

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

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

Нотации позволяют представить схему данных наглядно и в удобной для проектирования форме. Поскольку правила трансформации логической модули в физическую определены и алгоритмизированы достаточно жестко, то Case-средства позволяют нам без потерь смысла преобразовать логическую модель, сделанную в той или иной нотации, которую поддерживает case, в физическую.

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

Спасибо за ликбез. Что вы думаете об этих стрелочках? Есть ли среди них более правильные или неправильные? Какие вы порекомендуете использовать?

Ну что тут сказать.
1. Нижняя часть картинки несовсем точное использование стандарта IDEF1x. Если показана идентифицирующая связь принадлежности (сплошная линия с точкой на сторонне зависимой таблицы или сущности), то таблица(или сущность) User должна быть зависимой, т.е. с кругленными углами. Семантика тут такова. Запись в User не может появится пока отсутствует родитель Style. А так же, если удаляются все записи Style, то возникает нарушение целостности, т.е. нельзя удалить все записи Style пока существуют записи User (если только не назначен триггер каскадного удаления)
Другой вариант - связь таки судя из сигнатры таблицы User неидентифицирующая (ключевое поле user_id - по сути суррогатный первичный ключ) Дело в том, что при идентифицирующей связи, внешний ключ от таблицы Style должен стать частью ключа таблицы User. Что у вас как раз не отображается, поскольку внешний ключ является простым атрибутом, хотя и передает семантику обязательности родителя (Not Null)

2. Что касается верхней части. То тут показано, что реализация таблицы User зависит от таблицы Style.
Поскольку кардинальности на концах связи не показано, то можно сказать с уверенностью, что на стороне родителя Style минимальная и максимальная кардинальность 1, а вот на стороне User минимальная 0, а максимальная может быть как 1 так и N, т.е. много

Спасибо. Про неточное отображение таблицы по IDEF1x я знал, просто не нашел где это в PowerDesigner сделать (Похоже нигде. Может можно как-то?). Относительно верхней стрелки, не подскажете, где можно узнать больше теории об этом? (если вам ещё не надоело отвечать

P. S. Ещё увидел, что на рисунке у полей style, стояли null, в том числе и у style_id, который я хотел сделать PK. Это я просто забыл указать, когда делал этот пример.

Относительно верхней стрелки, не подскажете, где можно узнать больше теории об этом? (если вам ещё не надоело отвечать

Не совсем понял насчет какой теории? Теории стрелочек или теории БД?

Насчет последнего литуретуры много как в интернете, так и на книжных полках.

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

Насчет же стрелочек - ну не забивайте себе голову. Возьмите за основу стандарт, который вам покажется удобным и пользуйтесь. Главное, чтобы вас и другие понимали.

Если человек имеет отличное представление о базах данных, он даже с вашим сильным "акцентом" поймет