Моделирование данных: Упражнение по логическому моделированию
Пытаясь изучить искусство хранения данных, я старался собрать как можно больше достоверной информации. PerformanceDBA опубликовал несколько действительно полезных руководств / примеров в следующих сообщениях, среди прочего: нормализованы ли мои данные? и Соглашение об именах реляционных таблиц . Я уже задавал подмножество вопросов этой модели здесь .
Итак, чтобы убедиться, что я понял концепции, которые он представил, и что я видел в других местах, я хотел сделать еще один или два шага и посмотреть, понимание концепций. Отсюда и цель этого поста, из которого, надеюсь, другие тоже могут поучиться. Все, что я представляю, для меня концептуально и предназначено для обучения, а не для применения в какой-либо производственной системе. Было бы здорово получить информацию от PerformanceDBA, поскольку для начала я использовал его модели, но я ценю любой вклад от кого-либо.
Поскольку я новичок в базах данных и особенно в моделировании, я буду первым, кто признаю, что я не всегда могу задавать правильные вопросы, ясно объяснять свои мысли или использовать правильные слова из-за отсутствия опыта в этой области. Так что, пожалуйста, имейте это в виду и не стесняйтесь направлять меня в правильном направлении, если я схожу с пути.
Если есть достаточный интерес к этому, я хотел бы взять это от логической к физической фазе, чтобы показать эволюцию процесса и поделиться ею здесь, в стеке. Я сохраню эту ветку для логической схемы и начну новую для дополнительных шагов. Насколько я понимаю, в конце я буду создавать базу данных MySQL, чтобы запустить несколько тестов и посмотреть, действительно ли то, что я придумал, работает.
Вот список вещей, которые я хочу зафиксировать в этой концептуальной модели. Редактировать для V1.
Так что, может быть, немного. участвуют, но могут стать отличным инструментом обучения для многих, надеюсь, по мере развития процесса и внесения вклада сообщества. Есть ввод? ИЗМЕНИТЬ v1.1 доставка, физическая)
Так что, возможно, это немного сложно, но может стать отличным инструментом обучения для многих, надеюсь, по мере развития процесса и ввода предоставлено сообществом. Есть ввод? ИЗМЕНИТЬ v1.1 доставка, физический)
Так что, возможно, это немного сложно, но может стать отличным инструментом обучения для многих, надеюсь, по мере развития процесса и ввода предоставлено сообществом. Есть ввод? ИЗМЕНИТЬ v1.1
В ответ на PerformanceDBA U.3) Это означает, что в базе данных нет товаров, кроме товаров Band. Верно?
Это была моя первоначальная мысль, но ты заставил меня задуматься. Возможно, сайт захочет продавать свои собственные товары или даже другие товары от групп. Не уверен, что для этого нужно сделать мод. Потребуется ли полная переработка раздела Каталога или только идентифицирующие отношения, существующие с Band?
Попытался продать как полные альбомы, так и песню. В любом случае они оба будут в электронном формате, доступном только для скачивания. Вот почему я перечислил альбом как состоящий из песен, а не из двух отдельных объектов. U.5) Я понимаю, что вы говорите о круговой связи с Favorite. Я хотел бы перейти к следующему: «Это либо одна сущность с некоторой формой дифференциации (FavoriteType), которая определяет ее лечение», но как это сделать, мне не ясно. Что мне здесь не хватает? u.6) «Деловые правила Это, вероятно, единственная область, в которой вы слабы». Q.1) Да, я хотел бы, чтобы были приняты, отклонены и заблокированы. Я не уверен, что вы имеете в виду относительно того, как это изменит логическую модель? Q.2) Человек не обязательно должен быть пользователем. Они могут существовать только как BandMember. Вы об этом спрашиваете? Незначительная проблема Ноль, один или более… К сожалению, я признаю, что забыл уделить этому внимание при построении модели. Я отправляю эту версию в том виде, в каком она есть, и обратимся к ней в следующей версии. Мне нужно больше узнать о проверке ограничений, чтобы убедиться, что я все понимаю. M.4) Зависит от того, планируете ли вы использовать OrderPurchase в будущем.
Не могли бы вы пояснить, что здесь имеете в виду? ИЗМЕНИТЬ V1.2
В ответ на ввод PerformanceDBA ... Извлеченные уроки. U.2) В По концепции этой модели требуется только отслеживать объект как место проведения мероприятия. Никаких дополнительных данных собирать не нужно. При этом события будут проходить в заданную дату события и будут проводиться на объекте. На объектах будет проводиться несколько мероприятий и, возможно, несколько мероприятий в определенный день. В моей новой модели я думал, что EventDate уже привязан к Event. Следовательно, Venue не будет нуждаться в связи с EventDate. Пятый и шестой маркеры, которые вы перечислили в U.2), заставляют меня сомневаться в моих мыслях. Я что-то упустил? U.3) Не пора ли вместо этого переместить связь между Предметом и Группой на Предмет и Группу? При нынешнем дизайне я не вижу возможности продавать товары, не привязанные к группе, как вы сказали. U.5) Я оставил в соответствии с вашим вводом, а не сделал это дискретным отношением супертип / подтип, поскольку я не вижу преимуществ от такого типа сворачивания. Дополнительные изменения AR.1) После выполнения упражнения для FavoriteItem, Я считаю, что элемент для обзора требует отношения «многие ко многим», так что это указано. Нужно?
Итак, приступим к версии 1.3 Я потратил несколько дней на эту версию, изучая свой дизайн. Как только логический процесс будет завершен, поскольку я хочу увидеть, на правильном ли я пути, я подробно расскажу о том, что я узнал, и о проблемах, с которыми я столкнулся как новичок, проходя этот процесс. Важным моментом для этой версии было то, что мне потребовалось добавить несколько ключей, чтобы увидеть, чего мне не хватало в прошлом. Также очень помогло прохождение процесса создания матрицы. Независимо от чего, если бы не вклад PerformanceDBA, я все равно был бы заблудшей душой, гадающей в темноте. Кто знает, что мой нынешний дизайн может подтвердить, что я остаюсь им, но я многому научился, поэтому я знаю, что у меня в руке хотя бы есть фонарик. На данный момент я признаю, что все еще не понимаю, как можно идентифицировать и не идентифицировать отношения. В моей модели мне пришлось использовать неидентифицирующие отношения с ненулевыми значениями, просто чтобы присоединиться к отношениям, которые я хотел моделировать. Когда я много читаю на эту тему, кажется, есть много разногласий и нерешительности по этому поводу, поэтому я сделал то, что, как мне казалось, представляло правильные вещи в моей модели. Когда заставить (идентифицировать), а когда быть свободным (не идентифицировать)? У кого-нибудь есть входы? РЕДАКТИРОВАТЬ V1.4 Хорошо, взял входные данные V1.3 и очистил их для этого V1.4 В настоящее время работает над V1.5, чтобы включить атрибуты. РЕДАКТИРОВАТЬ V1. 6 Хорошо, прошло некоторое время с тех пор, как я размещал здесь сообщения, но работа над этим проектом все еще продолжается. Сейчас я публикую версию 1.6, которая включает в себя ряд изменений по сравнению с последней публикацией версии 1.4. Эта версия показывает дальнейшее развитие ключей. Он по-прежнему не включает атрибуты или какие-либо AK или IE. Я начал работать над физической моделью и использовал ее, чтобы помочь проработать атрибуты и попытаться пролить свет на проблемы, которые возникают у меня с определением AK и IE. Следующая публикация логической модели будет включать эти ключи и атрибуты. 
Спасибо за честный ответ. Я переадресовал их, но я надеюсь, что сначала рассыплю некоторую путаницу в моей голове с помощью ответов, которые я отправил вам. 
