Моделювання та проектування баз даних в інформаційних сістемах.Часть 1, CASE-засоби (моделювання), Програмування, статті

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


РОЛЬ БАЗ ДАНИХ В РОЗРОБЦІ


ДОДАТКІВ


Бази даних відіграють дуже важливу роль в процесі розробки додатків. Більшості програм необхідно зберігати певні дані для подальшого використання. Коли справа доходить до збереження цих даних, в більшості випадків вибір найлогічнішим чином падає на реляційні бази даних. Існують й інші варіанти – плоскі файли, XML, персистентності набори записів або навіть для користувача формати файлів, але, жоден з цих варіантів не володіє надійністю і захищеністю бази даних. Бази даних дозволяють аналізувати зібрану інформацію за допомогою таких інструментів, як звіти і сховища даних. Крім того, більшість реляційних систем управління базами даних (РСУБД) дозволяють відновити базу даних з резервної копії у випадку відмови і пропонують способи реалізації рішень високої готовності для мінімізації часу простою внаслідок відмови. Навіть самі по собі ці переваги можуть підштовхнути до вирішення про використання баз даних як рішення для зберігання і управління інформацією при розробці додатків.


ОСНОВИ МОДЕЛЮВАННЯ БАЗ ДАНИХ


Насправді, моделювання баз даних не відрізняється складністю – Це процес відображення реальної інформації на логічне представлення цих даних. Іншими словами, як інформація про клієнтів зберігається в моделі даних? Тут багато чого залежить від фахівця, що створює модель, але є ряд ключових концепцій, які допоможуть такому фахівцю приймати правильні рішення в процесі розробки. Отже, при моделюванні потрібно сприймати дані з точки зору логіки, не піклуючись про те, як саме будуть виглядати в базі даних таблиці і стовпчики. Такий підхід називається логічним моделюванням, і його єдине завдання – створити модель, що представляє реальні об’єкти. Після створення логічної моделі можна перейти до проектування фізичної моделі даних. Поділ логічної і фізичної моделі гарантує створення надійної бази даних.


ПРОЕКТУВАННЯ БАЗ ДАНИХ


+ В процесі розробки програми в самій ранній фазі проекту проектувальники і розробники зазвичай витрачають багато часу на збір вимог до створюваного додатком. Цю інформацію зазвичай збирають за допомогою інтерв’ювання користувачів і керівників, а також шляхом спостереження за існуючою системою (навіть якщо це абсолютно неавтоматизована система). Кінцевий результат являє собою досить деталізований набір вимог, що включає прецеденти, діаграми системи та макети інтерфейсу програми. Після того, як вимоги всіх основних зацікавлених в проекті сторін будуть задоволені, починається розробка програми. Одне з перших дій, яке доводиться виконувати більшості розробників додатків – це створення сховища для даних, з якими буде працювати новий додаток, іншими словами – бази даних програми. У багатьох випадках розробляється база даних, яка буде задовольняти фізичним вимогам інтерфейсу програми. Тобто, при наявності проекту, що описує спосіб отримання і відображення даних додатком, розробники програми можуть створити в РСУБД порожню базу даних. Якщо є таблиця або набір таблиць, які повністю визначають всі дані, одержувані від інтерфейсу, то розробник програми може почати розробку механізму зберігання даних і створення коду, за допомогою якого додаток буде взаємодіяти з тільки що створеної базою даних.


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


ПОРІВНЯННЯ МОДЕЛЕЙ ДАНИХ І БАЗ ДАНИХ


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


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


На відміну від бази даних, модель даних не є представленням фізичного сховища даних. Якщо база даних визначає спосіб зберігання даних, спосіб використання реальних відносин між ними для маніпулювання даними та забезпечує програмний доступ до даних, то модель даних просто перераховує, які дані існують і як різні біти інформації пов’язані між собою. Добре спроектована модель даних, зрештою, перетворюється в логічну схему розроблюваної бази даних. З цієї причини моделі даних обов’язково повинні бути переносних незалежними, і будь-яка модель даних може використовуватися для створення фізичної бази даних в Oracle 10g, SQL Server 2005 або MySQL. І все ж не слід думати, що при моделюванні не потрібно враховувати, з якою РСУБД працюватиме додаток. У ряді ситуацій попередня обізнаність про РСУБД, яка буде використовуватися для управління базою даних, може вплинути на процес моделювання даних.


Читати частина 2

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


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

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

Ваш отзыв

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

*

*