Обозначение названия базы данных, которое вы предпочитаете и почему?

Ответ 1

Extended 11 Dec 10

В ответ на Комментарии

Хороший вопрос.

Что означает этот вопрос?

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

Стандарты

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

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

Стандарты нормализованы

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

Аналогично, стандарты не конкурируют. Если человек соответствует стандарту строительства моста, нет опасности, что он нарушил стандарт связи.

Стандарты относятся к высшим принципам

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

Стандарты не являются примечаниями

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

Стандарты завершены

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

Стандарты просты

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

Ответственные, осведомленные клиенты (правительственные отделы, производители самолетов... компании, которые ожидают, что будут в следующем десятилетии) имеют разумные надежды на то, что программное обеспечение, которое оно приобретает у поставщиков, будет иметь определенное качество; легко повышается и расширяется; Хорошо выступить; легко интегрируется с другим программным обеспечением; и др.

Отсутствие стандартов в ИТ

Проблема с ИТ-отраслью, в отличие от производства автомобилей или мостостроения, поскольку она взорвалась за последние 30 лет, нас затопили поставщики, которые:

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

Это стало предметом много исследований и публикации, это не просто мое профессиональное мнение, кредит идет к академикам, которые усердно трудились, чтобы просеять и точно определить, что конкретно представляют проблемы.

Таким образом, с точки зрения всего населения ИТ-провайдеров, ИТ-компаний, а также ИТ-сотрудников в не-ИТ-компаниях, осознание качества, стандартов, необходимых для обеспечения качества и их важности, намного ниже, чем было 30 лет назад. Это менталитет "строить и забывать"; если он не работает, выбросьте его и создайте еще один. Но для большого города, ответственных клиентов, это неприемлемо.

Стандарты не являются одиночными поставщиками

По определению стандарты получают несколько поставщиков на международном уровне.

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

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

Соглашения не являются стандартами

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

Существует неверная цитата о том, что MS печально известна, сравнивая прогресс автомобильной промышленности с "прогрессом" MicroShaft, который автомобильная индустрия отреагировала публично, с оправданным негодованием и вытерла улыбку с лица billy bob. Sun Microsystems также ответила, классно, но я сомневаюсь, что это известно в кругах MS. Обратите внимание, что достоверность MS достигается благодаря общему объему: отсутствие интернет-сайтов, предоставляющих и обменивающихся постоянно меняющейся "информацией" среди преданных MS. Они изолированы от подлинных квалификаций и стандартов, и ложно полагают, что соглашения с одним поставщиком и частичная производительность, используя красивые фотографии, фактически включают "программное обеспечение".

Стандарты не дорогие

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

Стандарты re Реляционные базы данных

Стандарты или точные определения или конкретные руководящие принципы, для которых существует более 30 лет. В прогрессивном порядке, каждый из которых содержит предыдущий:

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

• Реляционные базы данных
  Реляционная модель: E F Codd и C J Дата

• Знаменитые Двенадцать правил относительного соответствия
  E F Codd

• Моделирование реляционных данных
  IDEF1X; 1980; NIST Стандарт FIPS 184 от 1993 года

Есть много поставщиков, которые практиковали эти методологии, как это предписано, тем самым соответствующие стандартам, на срок до 30 лет.

• Обратите внимание, что существует только один стандарт моделирования реляционных данных, конфликт отсутствует.

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

• Отметьте, что нормализация была предварена реляционной моделью и взята за нее; поэтому RM не имеет конкретных ссылок на нормализацию в качестве принципа и только идентифицирует нормальные формы в терминах требования к реляционным базам данных.

Если вы действительно квалифицированы как Relational Database Modeller, вы будете близко знакомы с первыми тремя; если вы являетесь стандартным модулем реляционных баз данных, вы будете близко знакомы с четвертым. Опять же, вы не можете разумно ожидать соблюдения Стандарта, просто изучив IDEF1X Notation, вам нужно действительно учиться и практиковать методологию, но изучение нотации может быть разумным введением.

[Соответствие стандарту] [Некоторые]

Известны ответственные клиенты, которые требуют соблюдения этих Стандартов.

И тогда есть остальная часть поля, как неосведомленные клиенты, так и неосведомленные поставщики, и все между ними.

Какие обозначения?

Для большинства практиков, осведомленных о стандартах, нет необходимости обсуждать "какие обозначения использовать", учитывая, что существует только один стандарт. Зачем мне рисовать диаграмму (используя либо дорогостоящий инструмент в большом проекте, либо простой инструмент рисования для ответа на вопрос о StackOverflow), используя некоторые другие обозначения, когда я использовал один стандарт более 20 лет, и нет другой стандарт? Почему я должен передавать меньше, чем стандартная информация, когда я могу передать стандартную информацию так же легко? Почему я должен избегать использования Стандарта, когда я знаю, что использование Стандарта обеспечивает официальную уверенность в правильности модели данных и будет противостоять проверке (в отличие от воображаемой уверенности, которая пробивается большинством беглых вопросов)?

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

Будущие обозначения и условные обозначения

Несколько сотен предложений одного поставщика за последние 20 лет не стоили времени, затраченного на расследование. Поэтому соглашения с одним поставщиком, если они будут обозначены "стандартами" или нет, не стоят времени, затраченного на расследование. Фактически, поскольку Стандарт существует и предваряется появлением единственного поставщика, любое предложение одного поставщика будет неявным выражением о том, что они не могут соответствовать Стандарту, и они предлагают антивирус -стандарт как замена.

Ответы на комментарии

• Самый простой способ опровергнуть утверждение любителя о том, что какой-то мусор является "стандартом", - это запрашивать его данные публикации ISO/ANSI/IEC/NIST/etc. Согласно (4) выше IDEF1X является опубликованным стандартом, легко просматривается.

• MS известна публикацией анти-стандартов и называет их "стандартами". Правильный термин - "конвенция". Билл Гейтс - любитель, который использует недостаточное образование для разработчиков. Богатый любитель, но любитель. На этой неделе Wiki может назвать стандартную нотацию MS, но я уже предупреждал вас, что wiki - это cesspit. Помните, что предложение одного поставщика по определению не является стандартом.

• IDEF1X также является стандартом моделирования бизнес-процессов

  Не совсем. Ссылка IDEF1X приведет вас к организации, которая наиболее ответственна за ее публикацию и обучение людей. Если вы проверите вкладки на этой странице, вы найдете несколько стандартов. Одна из великих держав (красавиц?) Стандартов заключается в том, что они интегрированы:

  • IDEF означает I ntegrated Def.
    • 0 предназначен для моделирования функций
    • 1 предназначен для информационного моделирования
      • X предназначен для моделирования реляционных баз данных
  • все они Стандарты, опубликованные NIST
    .
    Я утверждаю, что в документе IDEF1X Notation также. ,

11 дек. 10

4. Каково ваше отношение к разработке баз данных по нотации UML (диаграмма)? Обоснование заключается в том, что он широко (и повсеместно) известен и позволяет свести к минимуму количество обозначений, чтобы знать для этого и для этих целей

   Во-первых, я бы спросил, покажите мне UML "Реляционная модель данных", которая находится где-то рядом с изложением деталей и тонкости модели IDEF1X, а затем у нас есть что обсудить. До тех пор это пустые спекуляции, публичные разговоры нереляционных людей, о том, что они не знают, из того, что они знают.

   Но я не буду избегать вопроса.

   Во-вторых, существует большая проблема с ужасающими последствиями, когда люди имеют фиксированное мышление о области знаний (Good Thing), но затем они подходят к любой другой области, которую они не знают, с тем же мышлением, не желающим изучить специализированные навыки. Эти бедные люди не читали о Maslow Hammer. Типы ОО являются самыми крупными преступниками. Если бы я один раз ответил на этот вопрос, я ответил десять раз, и я был здесь всего 3 недели. Они спрашивают, как будто это первый человек, который нашел эту проблему: "Как я сохраняю свои классы объектов в базе данных", и они обрабатывают базу данных (забывают реляционные), как будто это мусорный ящик.

   Скотт Амблер и Мартин Фаулер могут многое ответить, когда они встречают своего создателя. Полные идиоты, за исключением дохода. Сначала они пишут книги о том, как правильно моделировать объекты. Затем они поворачиваются (ждут его) и пишут книги о том, как исправить проблему, которую они создали. Грешный. И это не только мое мнение, многие другие настоящие отраслевые лидеры (в отличие от опубликованных идиотов) делают похожие комментарии, они лихо написаны на страницах "Смех или крик". Представьте себе "рефакторинг" базы данных. Это сделает только тот, кто никогда ничего не читал о базах данных. Целый учебник о том, как это сделать. Написано дураками, которые никогда не видели реальной базы данных.

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

   Единственными "базами данных", которые нуждаются в рефакторинге, являются те, которые создаются людьми, которые рассматривают db как мусор, после прочтения сказанных "книг", и у них есть явные шаги, о том, как продолжать переделывать его снова и снова. Вы ждете, в следующем году у них будет "многофакторинг".

   Какой смысл? Они никогда не относились к базе данных с уважением; никогда не узнавал об этом; как подходить к передаче данных; как его моделировать. Они просто "смоделировали" его с помощью "Молота". Для кого-то вроде меня, который исправляет эти проблемы таким образом, что они никогда не возвращаются, "как мне моделировать классы многоуровневых объектов" сразу говорит, что они настолько невежественны, что они "сохраняют" свои модели объектов в db, и даже не читали достаточно, чтобы понять, что точный вопрос: "Как мне моделировать мои подтипы".

   Это проблемы на поверхности. Недостатки фундаментальны и глубже и влияют на все, что они делают в базе данных. Не верьте мне, подождите всего лишь небольшое количество времени после того, как "приложение" переходит в производство, и оно попадает в знаменитую стену. Они попадали так часто, у них даже есть имя OO для него: несоответствие реляционного импеданса объекта. Очень научное звучание для простой глупости. Им не приходило в голову, что если они разработали реляционную базу данных как реляционную базу данных, а приложение OO в качестве приложения OO с красивой определенной границей, транспортным уровнем между ними, никогда не было бы "несоответствие реляционных импедансов объекта",.

   Приложение (любой язык) и db - это хороший брак. Каждый из них совершенно другой, у них есть свои собственные потребности, и они нужны друг другу. Когда они работают вместе, это брак, заключенный на небесах. Как великий пророк Халил Джебран писал о браке:

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

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

   • вы не можете "сохранять" классы объектов в базе данных. В 2010 году мы писали транзакции ACID в течение 30 лет, а не объекты устойчивости. Если вы пишете объекты персистентности, у вас будет одно пользовательское приложение без concurrency, массово неэффективное, полное разбитых транзакций и проблем с целостностью данных.

   • вы не можете "создавать" базы данных, как "классы объектов", потому что они не являются объектами или классами. Поэтому прекратите тратить время и научитесь создавать данные в многопользовательском местоположении с некоторой целостностью. Или отдайте задание тому, кто знает, как это сделать.

   • с использованием нотации OO или нотации UML обрабатывает базу данных как совокупность объектов, она только усиливает Hammer и гарантирует, что это последняя закаленная сталь с импортным ручкой Elm.

   • у вас может быть совершенно хороший брак с невестой по почте. Все, что требуется, это признание и уважение.

     • Это означает, что вы узнаете терминологию и обозначение. Даже если вы отдаете работу кому-то квалифицированному, когда они дадут вам законченную диаграмму, вам нужно ее понять. что есть граница. Вы не можете пойти "EeeeK! Я никогда раньше этого не видел".

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

     • вы не можете открыть ящик базы данных, не обращаясь к нескольким онлайн-пользователям; concurrency (и, следовательно, валюта данных); сделки; данные и ссылочная целостность; и т.д. Эти идиоты (Фаулер и Амблер, а не читатели) вновь изобретают колесо, и пока они еще не достигли деревянной ступени; они не признали, что жирная круглая штука, которая соединена болтами, является самым полным сопротивлением. Их "объекты устойчивости" страдают от всех проблем (таких как "Потерянные обновления", избегая низких concurrency), которые мы устранили 30 лет назад.

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

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

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

     • поочередно, если приложение действительно является единственным и единственным основным событием, а затем сделать его успешным (избегайте "рефакторинга" каждый год или около того, напишите его правильно, один раз, чтобы он продолжался), забудьте о базах данных, сохраняйте свои объекты на диске C:\и сохраняйте их.

   Вот почему, двадцать лет назад, некоторые из нас говорили, публикуя статьи, что Амблер и Фаулер имеют его обратно. Неудивительно, что они продолжают рушиться на вещи и реорганизовывать себя.

   Следует отметить, что секрет Agile заключается в том, что он полностью нормализован. Это изменение на 180 градусов для Амблера, его опубликованные работы, поэтому неудивительно, что это то, что он не может объявить и открыто заявить.

И просто чтобы убедиться, что он не затерялся в стирке. Обозначение находится на поверхности, но это говорит о том, что внутри. IDEF1X рассказывает о реляционном мышлении человека, который моделировал базу данных. Обозначение UML для "реляционной базы данных" говорит вам о человеке, который учитывал кучу данных, и который много раз реорганизует его. Выбирайте внимательно.

У меня на панели инструментов больше, чем Hammer.

• Когда я моделирую данные, я использую IDEF1X
• Когда я моделирую функции, я использую IDEF0 или SSADM (в зависимости от зрелости пользователей).
• Когда я моделирую объекты, я использую UML

Я катаюсь на лошадях, стреляю оленями, сражаюсь с огнями и преследую женщин. У каждого вида деятельности есть другой набор принципов и правил, которым я должен следовать, чтобы я мог добиться успеха. Представьте себе, какая будет жизнь, если я их перепутаю. Или, если бы я мог стрелять.

Ответ 2

Для моделей ER я предпочитаю стиль IEM или Barker только потому, что обнаруживаю, что больше людей понимают нотацию ворона. Если вы хотите, чтобы модель была понята более широкой аудиторией, чем ваша, тогда имеет смысл использовать стандартную стандартную нотацию.

Что касается инструментов поставщика баз данных, это зависит. Я никогда не считал необходимым использовать какой-либо конкретный инструмент, за исключением случаев, когда клиент уже использовал его. Oracle и Sybase имеют достойные инструменты диаграмм. Microsoft Visio поддерживает стандартные обозначения, хотя в качестве инструмента проектирования базы данных он не так сильно, как многие другие.

Единственным действительно плохим примером, о котором я могу думать, является так называемый инструмент проектирования, встроенный в набор инструментов Microsoft SQL Server. Это просто шутка. Полностью непригодна для любых серьезных целей, и я не знаю никого, кто ее использует, кроме публикаций Microsoft.

Ответ 3

Я предпочитаю использовать трехэтапный подход: концептуальное моделирование данных, моделирование логических данных и моделирование физических данных. Использование причудливых инструментов зависит от объема проекта.

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

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

Естественные ключи идентифицируются и оцениваются, можно ли им доверять.

Обозначения включают атрибуты, домены, сущности и отношения.

Второй этап - логический дизайн. Результатом второго этапа является логическая модель данных, выраженная в терминологии SQL. Я использую терминологию SQL, такую ​​как столбцы, строки, таблицы и домены, хотя они представляют собой атрибуты, кортежи, отношения и домены. Логическая модель специфична для модели реляционных данных, но является агностиком СУБД.

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

Основное отличие заключается в том, что теперь на картинке находятся внешние ключи. Каждый объект получает таблицу. Некоторые отношения моделируются путем добавления внешних ключей к таблицам сущностей, в то время как другие отношения получают собственные таблицы. Примером последнего являются отношения "многие ко многим".

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

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

Третий этап - физический дизайн. Это приводит к модели физических данных. Модель физических данных начинается с модели логических данных и добавляет такие функции, как индексы, табличные пространства, хранимые процедуры и то, что у вас есть. Физический дизайн специфичен для СУБД и учитывает объем, трафик, цели производительности и доступные ресурсы.

Модель физических данных - это проект построения базы данных.