Название базы данных дизайн нотации вы предпочитаете и почему? - PullRequest
11 голосов

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

И личный вопрос к PerformaneDBA:
Почему вы предпочитаете IDEF1X?
Разве не удобнее придерживаться инструментов, обозначений, встроенных в используемые клиентские инструменты СУБД?

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

Я обновил заголовок, включая «имя» и исключая «методологию».
Я просил имена (возможно, ссылки), а не описания.
Обозначения, например, UML, IDEF1X. Баркер, Информационный инжиниринг

Ну, я в основном разработчик SQL Server и, как упоминалось @dportas, я вижу некоторые обозначения в схемах в SSMS и MSDN документы, книги, статьи.

Ответы [ 3 ]

17 голосов
/ 10 ноября 2010

расширенный 11 декабря 10

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

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

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

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

Стандарты

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

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

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

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

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

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

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

Стандарты Не Обозначение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Условные обозначения не являются стандартами

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

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

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

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

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

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

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

  2. Реляционные базы данных
    Реляционная модель: EF Codd & CJ Дата

  3. Знаменитые Двенадцать Правил Соответствия Реляции
    EF Codd

  4. Моделирование Реляционных Данных
    IDEF1X ;1980;NIST Стандарт FIPS 184 от 1993

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

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

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

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

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

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

Есть осведомленные, ответственные клиенты, которые требуют соблюдения этих стандартов.

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

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

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

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

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

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

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

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

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

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

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

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

11 дек. 10

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

И просто чтобы убедиться, что это не такзаблудиться в стирке.Запись на поверхности, но она говорит о том, что внутри.IDEF1X рассказывает о реляционном мышлении человека, который моделировал базу данных.Нотация UML для «реляционной базы данных» рассказывает о мышлении человека, который проанализировал кучу данных и ожидает ее многократного рефакторинга.Тщательно выбирайте.

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

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

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

5 голосов
/ 09 ноября 2010

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

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

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

3 голосов
/ 10 ноября 2010

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

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

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

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

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

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

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

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

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

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

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

Физическая модель данных является планом построения базы данных.

...