Важливість діаграм ЕР

Я студент і розробляю кілька проектів у складі моєї академії.

Розробляючи базу даних для одного з проектів, ми стикалися з ситуацією, коли ми думали про те, чи потрібен ERD чи ні. Наразі не кожен з нас домовляється про те, щоб спочатку розробити ERD, а потім розробити з нього базу даних.

Більшість людей вважає за краще розвивати базу даних на льоту словесно відповідно до системних вимог, безпосередньо вказаних на папері.

Тепер я суворо дотримуюся принципів бази даних. Я думаю, що база даних повинна бути розроблена лише з ERD. Отже, я просто хочу знати:

• Чи дотримується галузь цих принципів?
• Я просто витрачаю свій час на розробку ERD?
• Які переваги розробити ERD?

Простий і простий, подумайте розвивати базу даних без ERD як будівництво будинку без плану будівництва. Це може бути доцільним, оскільки ви вважаєте, що просто покласти цеглу один на інший достатньо, щоб щось побудувати, проте в момент, коли хтось інший візьме на себе відповідальність за проект, є потенціал катастрофи.

На мій досвід, ви не отримаєте великої користі від ERD, якщо не будете використовувати їх разом із інструментами CASE (ERWin, MySQL Workbench тощо), що додатково дозволить вам виконати деякі дійсно корисні операції, такі як пряма та зворотна інженерія. Навіть без того, щоб ці функції мали централізовану схему повної бази даних, корисні, оскільки іноді обмежень, реалізованих у самій базі даних, недостатньо, щоб розповісти про повну історію взаємозв'язків між окремими базами даних.

Ось приклад із використанням MySQL, який, як ви можете знати, реалізує декілька внутрішніх механізмів зберігання даних, зокрема, MyISAM та InnoDB. Між ними існують значні відмінності, одна з найважливіших - MyISAM не підтримує обмежень. Незважаючи на цей факт, MyISAM широко використовується для веб-додатків, а це означає, що логіку реляції потрібно реалізувати або за допомогою бізнес-логіки (код програми), або іншим способом. Проблема полягає в тому, що коли ви направляєте інженер-ERD з таблицями (сутностями) MyISAM, MySQL мовчки ігнорує обмеження, встановлені ЕРД, і ви отримаєте базу даних, яка не чітко визначає характер взаємозв'язків між сутностями. Іншими словами, після розробки макета бази даних немає можливості розробникам коду реалізувати належну бізнес-логіку без ERD.

ERDs дуже добре мати чітке уявлення про структуру вашої бази даних. Окрім того, що є важливим артефактом для вашого проекту, він полегшує, коли вам потрібно реалізувати запити, особливо приєднуючись до таблиць. Уявіть, як приємно мати подвійний конфігуратор монітора, з лівого боку у вас є ERD, а в правій - редактор запитів. Ви можете чітко бачити зв’язки між таблицями та писати свої запити на основі цього. Якщо проект вашої бази даних досить простий, а ваш проект цього не вимагає, можливо, нормально жити без нього.

ERD допоможе вам заощадити набагато більше часу, ніж ви думаєте. Якщо ви все зробите на льоту, тоді ви застрягнете, коли захочете генерувати таблиці з’єднання.

Якщо через кілька років ви натрапите на базу даних без ERD, вам доведеться витратити багато часу, щоб побачити, що відбувається у вашому проекті.

У мене є компанія, і ми розробляємо ERD, ніколи не думайте про базу даних без ERD. (Власне, це мій особистий експеримент)

ЕРД були певним часом більш популярними. ІМО вони зараз більш-менш необов’язкові.

В даний час деякі дуже успішні команди взагалі не турбуються з ERD, але вони забезпечують чудові системи: надійну, ефективну та просту в обслуговуванні в довгостроковій перспективі. Особливо це стосується розвитку Agile, коли ми починаємо з малого, з мінімалістичним набором інструментів.

ЕРД - це, звичайно, хороший спосіб спілкування, але аж ніяк не єдиний спосіб чи найкращий за будь-яких обставин. Деякі команди віддають перевагу іншим способам документації та спілкування.

У цій галузі немає правил для ковдр.

Важливо розробити перед написанням виробничого коду. Це також важливо для прототипу; Люди з бази даних розробляють прототипи, записуючи SQL. (Пам'ятаєте, що Фред Брукс сказав про прототипи?)

Графічні мови, серед яких ER лише одна, не виявились дуже хорошими у захопленні всієї семантики бази даних таким чином, щоб це було легко та просто зрозуміти.

Вони також не зарекомендували себе як дуже ефективні засоби комунікації, за винятком розробників. Але при розробці баз даних ключова комунікація не між розробниками; це між розробниками та експертами по домену (між розробниками та діловими людьми).

Об'єктно-рольове моделювання (ORM) має графічну мову, але воно засноване на "фактах" (простих реченнях). Ділові люди можуть досить легко підтвердити факти. Ділові люди не можуть легко перевірити діаграму ER або ORM.