Проектування і управління базами даних: “як зробити правильно з першого разу”, Інтеграція додатків і даних, Бази даних, статті

У світі баз даних (БД) фраза “зробити правильно” звучить досить невизначено. Хто може судити, що таке на справді “правильно”? Чесно кажучи, назвати схему БД “поганий” або “неправильної” набагато простіше, ніж підтвердити її “правильність”. Дизайн схеми – це основа хорошої роботи БД. Якщо схема не враховує вимог до продуктивності, адміністрування, резервного копіювання і відновлення БД, то багато можливостей роботи будуть недоступні.

Можливість


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


Переваги


Моделювання та проектування БД – це основа правильного управління БД і її продуктивності. Якщо підійти до цього правильно з самого початку, то кінцевий результат буде значно краще. Ось деякі переваги правильного підходу.



РОЗДІЛ 1


Проблема: “правильний” дизайн


У світі дизайну БД фраза “зробити правильно” звучить досить невизначено. Хто може судити, що таке насправді “правильно”? У сьогоднішньому мінливому світі Інтернету традиційний “правильний” підхід, коли спочатку створювалася застаріла система, може бути неправильним. Справа ще більше ускладнюється тим, що може просто не виявитися способу зробити “неправильну” роботу способом, ефективним і “правильним” з точки зору сьогоднішньої ситуації. Чесно кажучи, назвати схему БД “поганий” або “неправильної” набагато простіше, ніж підтвердити її “правильність”. “Правильна” БД означає, що вона добре працює, її ефективність висока, а продуктивність оптимальна. Крім того, вона забезпечує підтримку корпоративної місії, а організація володіє гнучкістю і розташовує в схемі БД основою для розвитку в потрібному напрямку. “Неправильна” може означати що завгодно, починаючи з функціональних обмежень, що гальмують корпоративний ріст і розвиток, і закінчуючи конкретними транзакціями, які діють в БД. Коли мене просять дослідити “неправильну” роботу, я намагаюся отримати глобальне уявлення про ситуацію. Дизайн схеми – це основа хорошої роботи БД. Але якщо не враховувати вимоги до продуктивності, адміністрування, резервному копіюванню та аварійного відновлення БД, то я втрачу багато можливостей. Кожен проект і кожна ситуація злегка відрізняються від того, що робилося раніше. Тому, коли починається новий проект, потрібно провести підготовчу роботу. Дослідіть корпоративні цілі, стратегічні ініціативи організації та бізнес-вимоги. Зрозумійте, що процеси управління БД пов’язують дизайн схеми з налаштуванням продуктивності та адмініструванням, і навіть з резервним копіюванням і відновленням даних. Після досліджень кращих сучасних методик в управлінні продуктивністю використовуйте найкращий дизайн схеми з усіх. Переконайтеся, що використаний програмний код SQL правильно налаштований і у вас є план по його підтримці. Пройде багато часу, перш ніж середу БД, з якою ви працюєте, буде функціонувати на оптимальному рівні. В процесі роботи спробуйте забезпечити ефективну спільну роботу і узгодження дій архітекторів даних, адміністраторів БД та керівників центрів даних.


РОЗДІЛ 2


Можливість: ідентифікація існуючих проблем


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


Поганий дизайн записів буде жити вічно


Поганий формат записів існує з самого початку комп’ютерної ери. Записи, які містять занадто багато полів із занадто великою кількістю різних аспектів даних. Записи, які при повному заповненні виявляються довше блоку БД. Записи, які містять повторювані групи і які намагаються об’єднати докладні і підсумкові дані (наприклад, “Складський артикул”, “Продажі за понеділок”, “Продажі за вівторок “,” Продажі за середу “і т.д.). Всі ці умови швидко знизять продуктивність БД і зведуть нанівець цілісність даних.


Через кілька років після того, як я відкрила свій бізнес в якості консультанта по БД, і незабаром після того, як я виступила співавтором книги за новою версією популярної СУБД, зі мною зв’язався один клієнт. Він попросив мене проконсультувати його з налаштування продуктивності БД. Виявилося, що БД являє собою виробничу систему. Вона містила інвентарний опис всіх продуктів і послуг, які продавалися і були продані, всіх клієнтів, які купили будь-який з цих продуктів або послуг, історію кожної установки, умови кожної угоди і т.д. Продуктивність цієї БД, єдиною основною БД на сервері, була явно нижче стандарту. Ситуацію не виправила навіть заміна сервера на висококласний багатопроцесорний блок. Керівництво хотіло отримати відповіді на два питання. По-перше, чи буде БД краще працювати після переходу на нову версію СУБД? По-друге, чи варто їм вкладати гроші в дорогі апаратні засоби для вирішення проблем з продуктивністю?


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


За винятком декількох таблиць пошуку, що містять інформацію на зразок штату і типу клієнта, все – все пов’язані з клієнту дані, включаючи все, що клієнт колись купував – було упаковано в один запис. Ця центральна таблиця їх виробничої системи вийшла за обмеження на розмір блоку в СУБД. Вони розглядали перехід на нову версію, тому що ця нова версія дозволяла використати набагато більший розмір блоку. Вони були готові додати ще стовпці до своєї таблиці, яка вийшла з-під контролю, але зіткнулися з обмеженнями на розмір блоку.


Очевидно, що дехто не розумів концепцію нормалізації даних, або навіть вертикального сегментування і відносин “один до одного”. Використовувати СУБД в якості збільшеною електронної таблиці – це не найефективніший спосіб управління даними.


Ясно, що в подібній ситуації ніяке потужне апаратне забезпечення, збільшення розміру блоку або будь-яку кількість додаткових індексів не врятувало б цих людей від проблем з ресурсами. Враховуючи, що в цій компанії були схильні розглядати їх реляційну СУБД як звичайний сервер з неструктурованим файлом, збільшення розміру блоку тільки загострило б їхні проблеми з продуктивністю. Фізичний введення-виведення, напевно, є найбільш ресурсномісткою операцією на комп’ютері. І немає нічого, що могло б по затратності перевершити зчитування і запис одного запису при кожній фізичної або логічної операції вводу-виводу. Якщо б ці хлопці провели моніторинг своєї системи, вони б побачили виключно високу активність по запису і читання даних з жорстких дисків. Також вони побачили б “пробуксовку” – високий рівень обігу на читання і запис до файлу підкачки навіть при легкій або середній транзакційної навантаженні. Ці характеристики є симптомами проблем відповідно з фізичними і логічними операціями вводу-виводу.


Такі проблеми треба вирішувати в джерелі, навіть якщо це означає переробку схеми працює БД. За допомогою найкращих методик щодо нормалізації даних розділіть дані на набори пов’язаних таблиць, виходячи зі змісту даних і функціональності. Зв’язки між таблицями необхідно реалізувати з використанням декларативною посилальної цілісності, і створити відповідні індекси. При необхідності створіть подання, які імітують старий формат запису. Це потрібно для підтримки існуючих програм, які запитують дані з БД. Одночасно слід переписати ці програми. Вони повинні використовувати що-небудь крім “select *”. Якщо в початковому дизайні таблиць і записів є недоліки, що необхідно зробити деякі серйозні кроки з виправлення ситуації. Поганий дизайн записів – це головний приклад неправильних дій вже на початковому рівні. Від цього, як і від будь-яких інших початкових проблем, можна позбутися переробкою дизайну.


Погана продуктивність програми викликана недоліками в реалізації дизайну


Іноді навіть при правильно нормалізованої БД все одно зустрічаються проблеми з продуктивністю. Таким прикладом може служити компанія, яка безуспішно намагалася підвищити продуктивність праці, не збільшуючи кількість персоналу.


Один з основних способів збільшити продуктивність праці одного працівника – це документувати, а потім автоматизувати процеси. Можна провести аналіз процесів і визначити ті ручні процеси, які потрібно автоматизувати. Проте якщо намагатися інтегрувати нові автоматизовані процеси в застарілу систему, яка позбавлена ​​гнучкості і для якої немає вихідного коду, можна натрапити на “цегляну стіну “. У випадку з компанією, який я описую, для створеної роки назад застарілої системи не було ні вихідного коду, ні документації. Всі попередні спроби змінити схеми викликали збої в програмі, яке було основним для бізнесу.


Їх нагальною потребою був процес виставляння рахунків. У підсистемі обліку рахунків в БД зберігалося не так вже й багато даних. Але робота програми з виставляння рахунків, яку запускали кожні десять днів, займала 36 годин. Як же скоротити час, який займає процес виставляння рахунків, коли немає ні схеми БД, ні вихідного коду програми? Відповідь полягає у внутрішньому змісті даних. Схема цієї БД була спроектована досить добре. Хоча в схемі і була пара місць, які можна було б поліпшити за допомогою деякої тонкої настройки, загалом і в цілому схема була гарною. Недоліком цього дизайна була його реалізація. Не було передбачено вбудованого методу очищення БД від старих даних, і обсяг цих старих даних уповільнював обробку. Ніяке індексування, схоже, не допомогло б. Просто в БД зберігалося занадто багато старих даних.


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


У подібній ситуації, коли неможливо змінити програмний код застарілої системи або навіть її схему, необхідно підійти до вирішення з найнижчого рівня. Для фізичного поділу поточних даних від застарілих використовуйте метод горизонтального секціонування даних. Найбільшою проблемою буде визначити, що таке “застарілі” дані. Потім потрібно розробити алгоритми, які успішно визначають застарілі дані, після чого їх можна перемістити в окрему таблицю або навіть в окрему архівну БД. Для вирішення цього завдання вам потрібно зрозуміти, як визначити, що дані “застаріли”, і що становить набір поточних даних.


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


Обмежений дизайн обмежує роботу організації


Щоб все зробити правильно з самого початку, потрібно розуміти бізнес-вимоги. Цього не було зроблено в одному проекті, який включав в себе повну переробку дизайну БД, яка підтримувала роздрібну торгівлю через Інтернет. В даному випадку у компанії було чотири веб-сайту для роздрібної торгівлі через Інтернет. Планувалося збільшити цю кількість і, можливо, розвивати бізнес в сторону франчайзингу. Чотири вузла для роздрібної торгівлі спільно використовували одну БД і основу коду програми. Через особливості схеми прийняті на ранньому етапі проектування БД рішення стримували зростання організації. Схема БД, спроектована сторонньою організацією, до цього справно служила компанії. Але вона не враховувала плани розширення бізнесу. Не будучи технічними фахівцями, керівництво ніколи не усвідомлювала ці недоліки дизайну. Тим часом дизайн жорстко обмежував кількість магазинів і тип послуг, які могла пропонувати компанія. Без фундаментальної реструктуризації БД і переписування програмного коду було неможливо розширити можливості та функціональність цієї системи для підтримки ініціатив з розвитку бізнесу.


У такій ситуації слід створити для себе контрольний список речей, які потрібно зробити і врахувати. Перш за все слід визначити бізнес-вимоги, як поточні, так і майбутні. Слід врахувати їх у новій схемою БД. Скористайтеся допомогою кінцевих користувачів і переконайтеся, що ваш дизайн БД буде відповідати їх потребам і очікуванням. В даному випадку, оскільки мова йшла про БД для роздрібної торгівлі, ми вивчили поведінку реальних покупців в офісі компанії і вчили це в схемі БД. Ми додали можливості, які були унікальні для онлайн-покупок.


У другу чергу потрібно в контрольному списку врахувати фізичну реалізацію, а особливо метод розміщення файлів БД на диску. Необхідно використовувати засіб завчасного контролю та управління БД. В моєму випадку я використовувала профайлер для тестування продуктивності та швидкості виконання запитів до і після фізичного реструктуризації. Отримані мною перед реструктуризацією результати не були обнадійливими. У вихідній БД всі об’єкти зберігалися в одній групі файлів. Ця БД містила всі типи даних – як табличні (числа, текстові рядки, час і дату), так і тест із зображеннями (довгі описи продуктів і ДУЖЕ БАГАТО картинок). Єдина група файлів розміщувалася на одному фізичному / логічному диску. Така конфігурація несприятливо впливала на продуктивність і погіршувала роботу інтерфейсу для Інтернет-покупців. При реструктуризації подібної БД – яка містить великий обсяг двійкових зображень дуже довгих текстових рядків – найкращим виходом є відділення тексту і зображень від табличних даних. Збережіть текст і зображення в окремому наборі таблиць. Потім використовуйте відносини для зв’язку кожного зображення або довгою текстової рядки з відповідною табличній записом (Або записами). Також слід відокремити системні таблиці (каталог) від табличних даних і зображень. Кожен з цих трьох типів таблиць слід помістити в окрему групу файлів або табличний простір. Потім кожну з цих файлових груп помістіть на окремий диск. Використовуючи ці прості принципи фізичного дизайну, ви значно підвищите продуктивність БД.


Третім пунктом контрольного списку ставимо індексування для підвищення продуктивності. Якщо є відношення між двома таблицями виду “один до багатьох”, то на стороні “багатьох” зв’язку з цим буде зв’язок за зовнішнім ключу. У більшості систем БД первинний ключ індексується автоматично. Для зовнішнього ключа це не завжди так. Щоб забезпечити найкращу роботу об’єднань, обов’язково проіндексує кожен зовнішній ключ в БД. Наступний кандидат на індексацію – це будь-який стовпець, який буде використовуватися для сортування, тобто стовпець, який буде постійно використовуватися у виразі “order by” запиту на SQL. Також варто проіндексувати стовпці, які будуть використовуватися для обмеження повертається набору даних. Це, наприклад, ті стовпці, які постійно фігурують у виразах “where”.


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


РОЗДІЛ 3


Переваги правильного виконання


Переваги правильного виконання численні. Ніхто не буде будувати будинок без попереднього проектування і детального плану. До проектування БД слід підходити точно так же. Уявіть собі будівельного архітектора, який займається проектуванням відповідно до ваших специфікацій. Він буде ставити різні питання: “Як це будуть використовувати?”, “Які плани на майбутнє?”, “Як це повинно виглядати? “,” Як це має працювати? “. Розгляд подібних питань при створенні БД дасть у підсумку то ж зручність для використання та” життя “, що й у добре спроектованого будинку.


• Переваги хорошого підстави: коли проект готовий і плани закінчені, настає час почати створювати БД. Ви б ніколи не стали будувати будинок без міцного фундаменту, тому в першу чергу слід розглянути питання заснування. Основою для додатків і систем служить БД. Щоб БД була хорошою основою структури програм та програм, створюйте її прямо з самого початку.


• Переваги хорошого дизайну записів: добре нормалізована БД полегшує роботу з даними. Коли вам потрібно змінити дані в добре нормалізованої БД, це можна зробити відразу, правильно і швидко. В добре нормалізованої БД витяг даних відбувається швидше, оскільки відносно мала довжина записів дозволяє зчитувати з жорсткого диска або записувати на нього багато записів в одному фізичному операції вводу-виводу. Віртуальні (тобто відбуваються в пам’яті) операції теж прискорюються завдяки укороченою довжиною запису. На одній сторінці можуть розміститися більше записів, тому за один захід можна перемістити або обробити більше записів. Такі ресурсомісткі завдання, як дискові операції вводу-виводу для даних в сховище або для сторінкового файлу, значно скоротяться. Для оптимізації операцій БД і часу відгуку практикуйте хороший дизайн записів з самого початку.



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


• Переваги визначення, документування та реалізації бізнес-вимог: якщо ваша БД не підтримує бізнес-вимоги, вона буде (в кращому випадку) розчаровувати з самого початку, а в гіршому випадку може коштувати вам роботи. Щоб не мати справу з БД, яка не підтримує вимоги, переконайтеся в тому, що ви розумієте не просто сьогоднішні, а й майбутні вимоги. Дізнавайтеся, документуйте і затверджуйте бізнес-вимоги на завтра, на наступний рік і навіть на кілька років вперед. Тільки розуміючи плани компанії на майбутнє, можна правильно реалізувати дизайн для сьогоднішньої роботи.


РОЗДІЛ 4


Висновок


“Правильне” створення БД означає, що вона добре працює, її ефективність висока, а продуктивність оптимальна. Крім того, вона забезпечує підтримку корпоративних ініціатив, а організація має гнучкістю і розташовує в схемі БД основою для розвитку в потрібному напрямку.


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


РОЗДІЛ 6


Про автора


Мішель Пулі з Денверського університету – володар сертифікатів MCIS, Microsoft MCP SQL Server, Neverfail NCIE. Вона є засновником і президентом компанії Mount Vernon Data Systems. Це консалтингова компанія, яка спеціалізується на таких напрямках: СУБД, моделювання та захист даних, розробка навчальних курсів, навчання, а також стратегії забезпечення високої доступності ІТ, відновлення після аварій і забезпечення безперервної роботи бізнесу. Вона робила рефакторинг і переробку вихідного коду БД. Також Мішель Пулі проектувала, розробляла і реалізувала замовні рішення з використанням БД. Вона написала книги по Microsoft Access і SQL Server, а також співпрацювала в якості технічного і пише редактора з видавництвами Prentice-Hall Publishers, MacMillan Computer Books, WindowsNT Magazine і SQL Server Magazine. В даний час вона співпрацює в якості журналіста з SQL Server Magazine і є старшим ад’юнкт-професором в Денверському університеті. Мішель – володар сертифіката Microsoft Certified Professional за основною СУБД компанії Microsoft, SQL Server, і сертифіката Certified Implementation Engineer за рішенням Neverfail Group для забезпечення безперервної роботи бізнесу та високої доступності систем.

Схожі статті:


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

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*