Кращі практики для перепроектування бази даних

Мені відомі деякі загальні найкращі практики при розробці бази даних для програми, але як бути з перепроектуванням?

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

Поточна програма знаходиться у форматі Oracle Forms, розкиданій по купі ненормованих таблиць, іноді з декількома майже дублюючими таблицями, що містять незначні варіанти даних про один одного. Обмеження часто бувають у вигляді погано забезпечених зберігаються процедур. Навіть типи, здається, не зберігаються правильно. Я стикався з усілякими поганими даними, які, як видається, Oracle ігнорували, але відповідали (і це правильно) майстру імпорту / експорту SQL Server. (Наприклад, двоцифрові цілі числа не складають повний час дати!)

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

Кінцевим результатом перезапису стане веб-версія, що працює на ASP.NET з MS SQL Server для зворотного кінця.

Інші два моїх товаришів по розробникам набагато, набагато старші за мене, обидва з бізнесом / MIS-фоном, тоді як мій - CS. Досвід старшого члена був майже виключно формами Oracle, а інший член здебільшого робив бізнес-програми в Visual Basic. Хоча фон моєї бази даних обмежений розробкою нових баз даних для проектів в MySQL або SQLite, в основному для моїх нижчих класів, я, здається, єдиний, хто взагалі має досвід проектування баз даних.

Я вже написав невелику програму на C #, яка читає всі існуючі дані до нейтрального формату, готова до повторної передачі та розміщення в новій базі даних. Я планую записати код для завантаження після створення бази даних призначення, щоб дані могли бути належним чином розділені на нові нормалізовані таблиці, додані у правильному порядку для наступних нових обмежень і т. Д. Цю ж програму потім можна запустити знову пізніше скопіювати виробничі дані в реально нещодавно розгорнуте готове перепроектування. Це залишає власне перероблення бази даних як головне, що слід з'ясувати.

Отже, суть мого запитання: які найкращі практики для перепроектування з рівня бази даних до існуючої програми?

Я думаю, ви вже знаєте, як нормалізувати базу даних.

Вам потрібні стратегії мінімізації ризику при переміщенні всього програмного забезпечення до нової бази даних.

Те, що я пропоную, - це більше працювати як компроміс за менший ризик.

Нормалізуйте базу даних і створіть процес заповнення нормованої бази даних даними з вихідної бази даних. Оригінальною базою даних буде база даних для вставок, оновлень та видалень. Нормалізована база даних буде базою запитів лише під час перетворення.

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

Побудуйте частину запитів вашої нової системи ASP.NET, вказуючи на нову нормалізовану базу даних.

Результати запитів у вашій новій системі повинні порівнюватися з результатами запитів у вихідній системі.

Ви могли зупинитися на цьому етапі. Це ділове рішення, а не технічне рішення.

У вільний час ви створюєте нову функцію вставки / оновлення / видалення у вашій новій системі ASP.NET. Під час створення нового функціоналу ви вимикаєте частини оригінальної системи, які відповідають. У якийсь момент від оригінальної системи нічого не залишається.

Перевагами перетворення таким чином є зниження ризику, спочатку будуючи частину запиту. Як правило, функції запиту прості порівняно з бізнес-логікою, вбудованою у функцію вставлення / оновлення / видалення.

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

Само собою зрозуміло, що процес вашого заселення краще бути абсолютно послідовним.

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

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

Створіть необхідну вам нормовану базу даних із потрібними типами даних. Тоді найважча частина - це переміщення даних. Спочатку вам потрібно скласти план того, як ви збираєтеся робити карту від старого до нового і що ви збираєтеся робити з даними, які не відповідають новій структурі. Наприклад, у вас можуть бути дані, які зараз неможливо визначити, якщо у вас не було належних обмежень цілісності. Ви можете просто не переміщувати ці дані або вам потрібно буде їх перемістити, але прикріпити їх до нової батьківської записи під назвою "Невідомо". Якщо дата не є справжньою датою, чи можете ви вказати нуль у полі під час міграції? Вам знадобляться відповіді на такі питання. Я б радив, щоб у вас хтось із розробників працював над зміною Gui, щоб використовувати нову структуру бази даних, а інші - строго працювати над міграцією. Міграція - це величезне завдання, це забирає багато майстерності та багато часу. Не залишайте це як думка.

Оскільки ви використовуєте SQL Server, ви можете зробити фактичну міграцію через SSIS.

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

Оскільки у вас є стільки років даних, ви можете перенести їх у двох частинах. Спочатку переносять більшу частину даних, а потім, коли прийшов час жити, лише мігрувати змінили дані. Звичайно, вам потрібно буде встановити елементи керування в базі даних, щоб можна було знайти змінені дані, яких у вас, можливо, ще немає. У цей час ви також можете проаналізувати, якщо хочете заархівувати деякі дані.

Я щодня стикаюся з перепроектуванням схеми баз даних через підтримку та подальший розвиток декількох застарілих додатків, які народилися у вигляді файлів MS Access (.mdb), а потім виросли до великих баз даних з декількома сотнями таблиць, які зараз знаходяться в MS SQL Сервер, але все ще мав "немовляти занепокоєння" оригінального дизайну. Ось деякі практики, які мені здаються корисними:

Спробуйте мінімізувати загальнодоступну поверхню схеми вашої бази даних.

Це означає, що вам слід спробувати розробити деякий публічний API, який ви робите доступним для зовнішніх програм. Я зазвичай намагаюся реалізувати статичні дані у вигляді подань (навіть якщо вони просто базуються на одній таблиці) та динамічних даних у вигляді параметризованих подань або як збережених процедур. Для запитів даних, де достатньо лише одного значення, можна також використовувати скалярні функції.

Тільки ці (перегляди, збережені процедури та скалярні функції) видимі для зовнішніх програм (через ORM або безпосередньо) та використовуються для всіх операцій CRUD. Потім ця схема повністю заморожена, тоді як внутрішньо ви можете змінити основні таблиці, покращити свої процедури тощо - це не порушить сумісність із вашою програмою.

Спробуйте оптимізувати критерії реального світу, а не ті, що з книг.

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

Запишіть сеанс профілювання та проаналізуйте їх.

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

Ось моя відповідь:

1. Спочатку зрозумійте поточну систему баз даних наскільки це можливо. Вам потрібно знати всі способи використання цієї системи, а також користувачів. Вам потрібно знати всі джерела в системі, а також системи, які можуть слугувати їх джерельною системою.

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

3. Також проаналізуйте та зрозумійте поточний процес ETL, який завантажує дані в базу даних та витягує дані з бази даних.

4. Зрозумійте всі елементи даних бази даних, і якщо ви можете побудувати матрицю вікон, яка допоможе вам визначити повторювані елементи.

5. Отримавши всю інформацію, ви можете підійти до перероблення так, ніби вперше розробляєте базу даних з інформацією, яку ви зібрали в рамках збору ваших вимог.

6. Удачі!