Название базы данных дизайн нотации вы предпочитаете и почему?

Question

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

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

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

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

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

Answer 1

Продлен 11 декабря 10

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

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

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

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

стандарты

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2. Реляционные базы данных
   Реляционная модель: E F Codd & C J Date

3. Знаменитые Двенадцать Правил Реляционного Соответствия
   Э. Ф. Кодд

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

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

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

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

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

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

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

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

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

Какая нотация?

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

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

Будущие обозначения и соглашения

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

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

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

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

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

   Не совсем. Ссылка IDEF1X приведет вас к организации, которая несет наибольшую ответственность за ее публикацию и информирование об этом. If you check the tabs on that page, you will find several standards. One of the great powers (beauties?) of Standards is that they are integrated:

   • IDEF stands for I ntegrated Def inition
     • 0 is for Function Modelling
     • 1 is for Information Modelling
       • X is for Relational Database Modelling
   • they are all Standards published by NIST
     ,
     I state that in my IDEF1X Notation document as well.
     ,

11 Dec 10

4. What is your attitude to design databases by UML notation (diagram)? The rationale is that it is broadly (and ubiquitously) known and to minimize the number of notations to know for this and that purposes

   First, I would ask, show me a UML "Relational Data Model" that has anywhere near the exposition of detail and subtlety of an IDEF1X model, and then we have something to discuss. Until then, it is idle speculation, pub talk by non-relational people, about what they do not know, from a framework of what they do know.

   But I won't avoid the question.

   Second, there is a big problem, with horrendous consequences, when people have a fixed mindset about an area of knowledge (Good Thing), but then they approach every other area that they do not know, with the same mindset, unwilling to learn the specialised skills. Those poor people have not read about Maslow's Hammer. The OO types are the biggest offenders. If I have answered this question once, I have answered it ten times, and I have only been here 3 weeks. They ask, as if they were the first person to find this problem, "how do I persist my object classes into a database", and they treat the database (forget Relational) like it is a rubbish bin.

   Scott Ambler and Martin Fowler have a lot to answer for when they meet their creator. Complete idiots, except for the income. First they write books on how to model objects the wrong way. Then they turn around (wait for it) and write books about how to fix the problem that they created. Sinful. And this isn't just my opinion, many other real industry leaders (as opposed to published idiots) make similar comments, they are famously written up in "Laugh or Cry" pages. Imagine "refactoring" a database. Only someone who has never read anything about databases would do that. A whole textbook on how to do that. Written by fools who have never seen a real database.

   Any serious, experienced modeller knows that if you design (model) the database correctly, it never needs refactoring.

   The only "databases" that need refactoring are those created by people who treat the db like trash, after reading said "books", and they have explicit steps, on how to keep trashing it, over and over again. You wait, next year they will have "multifactoring".

   В чем смысл? They never treated the database with respect; never learned about it; how to approach data transfers; how to model it. They just "modelled" it with a Hammer. To someone like me, who fixes these problems in a way that they never come back, "How do I model my multi-level objects classes" tells me immediately they are so clueless, they are "persisting" their Object models into the db, and have not even read enough to understand that the accurate question is "How do I model my Subtypes".

   These are the issues on the surface. The flaws are fundamental and deeper, and affect everything they do re the database. Don't believe me, wait just a small amount of time after the "app" goes into production, and it hits the famous wall. They hit it so often, they even have an OO name for it: Object Relational Impedance Mismatch. Very scientific sounding name for plain stupidity. It hasn't occurred to them that if they designed the Relational database as a Relational database, and the OO app as an OO app, with a nice defined boundary, a transport layer between them, there would never be "Object Relational Impedance Mismatch".

   The app (any language) and the db is like a good marriage. Each is completely different, they have their own needs, and they need each other. When they work together, it is a marriage made in heaven. As the great prophet Khalil Gibran wrote On Marriage:

   Fill each other's cup but drink not from one cup...
   For the pillars of the temple stand apart,
   And the oak tree and the cypress grow not in each other's shadow

   When one partner treats the other like a slave, a receptacle, like they need not be recognised and understood, divorce and domestic violence are only a short distance away. Refactoring is merely a set of steps on how to make the right choice for your next mail order bride, how to train them to do the chores. Fixes the symptom for this month, but it does not go anywhere near the causative problem.

   • you can't "persist" object classes into a database. It is 2010, we have been writing ACID transactions for 30 years, not persistence objects. If you write persistence objects, you will have a single user app, with no concurrency, massively inefficient, full of broken transactions and data integrity problems.

   • you can't "design" databases like they are "object classes", because they aren't objects or classes. So stop wasting time, and learn how to design data in a multi-user location with some integrity. Or give the job to someone who knows how.

   • using OO notation or UML notation treats the database as a collection of objects, it only reinforces the Hammer, and makes sure it is the latest hardened steel with an imported Elm handle.

   • you can have a perfectly good marriage with a mail order bride. All it takes is a bit of recognition and respect.

     • that means, learn the terminology and the notation. Even if you gave the job to someone skilled, when they give you the finished diagram, you need to understand it. that is the boundary. You can't go "EeeeK! I've never seen that before".

     • you can't have some of the features of the database, but ignore the other fundamental requirements. I am certainly not saying that it is all-or-nothing, that too is immature. But you have to have a basic understanding of the person you are marrying; the better the understanding, the better the marriage.

     • you cannot open the database box, without addressing multiple online users; concurrency (and thus data currency); transactions; data and referential integrity; etc. These idiots (Fowler and Ambler, not the readers) are re-inventing the wheel, and they have not reached the wooden spoke stage yet; they have not recognised that the fat round thing that is bolted together is the impedance itself. Their "persistence objects" suffer all the problems (such as Lost Updates, avoiding low concurrency) that we eliminated 30 years ago

   • data that is modelled correctly does not change (it is easily extended, but that which exists, does not change). Apps come and go like ships. Object classes come and go with the developer. Therefore, if there were to be an order in the hierarchy (instead of an equal relationship), then the object should be modelled after the data.

     • note also, that well written apps (to Standard) are impervious to such changes; apps which take the "database is a slave" approach are brittle, and break at the slightest change; these are grossly sub-standard apps. But the OO people do not see that, they see "Impedance Mismatch".

     • if (a) the app and the database have reasonable independence, and (b) the boundaries are clear, each side can be changed and extended without affecting the other side.

     • alternately, if the app is truly the one-and-only main event, then to make it successful (avoid "refactoring" every year or so; write it correctly, once, so that it lasts), forget about databases, keep your objects on the C:\ drive, and persist them.

   That's why, twenty years ago, some of us were saying, publishing articles, that Ambler and Fowler have it backwards. It is no wonder they keep crashing into things and refactoring themselves.

   It is noteworthy that the secret behind Agile, is that it is fully Normalised. That is a 180 degree change for Ambler, his published works, so it is no surprise that it is something he cannot herald and declare openly.

And just to make sure it doesn't get lost in the wash. The Notation is on the surface, but it is telling, of what is inside. IDEF1X tells you about the Relational mindset of the person who modelled the database. UML Notation for a "relational database" tells you the mindset of the person who factored the data heap, and who expects to refactor it many, many times. Choose carefully.

I have more than a Hammer in my toolbox.

• When I model data, I use IDEF1X
• When I model functions, I use IDEF0 or SSADM (depending on the maturity of the users)
• When I model objects, I use UML

I ride horses, shoot deer, fight fires, and chase women. Each activity has a different set of principles and rules, which I must follow in order for me to succeed reasonably. Imagine what life would be like if I mixed them up. Or if I could only shoot.

Answer 2

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

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

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

Answer 3

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

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

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

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

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

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

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

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

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

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

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

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