Повна версія

Головна arrow Інформатика arrow Бази даних: проектування

  • Увеличить шрифт
  • Уменьшить шрифт


<<   ЗМІСТ   >>

Перехід до фізичної базі даних

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

  • - Створення програмного коду і збереження його в файл на магнітному носії;
  • - Виконання програмного коду в фізичної базі даних.

Якщо модель бази даних розробляється на комп'ютері, де не встановлена ​​потрібна СУБД, або потрібно виконати програмний код на різних комп'ютерах, то вибирають перший варіант, який в даному розділі і буде розглянуто.

Для створення програмного коду (скрипта) об'єктів бази даних розробнику необхідно викликати контекстне меню окремо об'єкта в фізичної моделі (таблиця, індекс, обмеження і т.д.) або схеми (ролі) бази даних, де розміщені всі об'єкти майбутньої бази даних, і вказати пункт меню "Generate DDL ..." (Створити DDL [1] ), що викликає вікно налаштувань щодо формування SQL-програми.

У першій частині налаштувань розробнику належить визначити загальні характеристики майбутнього програмного коду, які, зокрема, включають (рис. 4.91):

  • • Check model (перевірити модель) - властивість, що позначає необхідність перевірки коректності складеної моделі бази даних, для можливості її подання у фізичній базі даних;
  • • DROP statement (знищувати елементи) - властивість забезпечує створення в програмному коді команд, які до створення потрібних об'єктів спочатку їх знищать, забезпечуючи однозначність відповідності моделі бази даних і її фізичної реалізації;
  • • CREATE statement (Створити елементи) - властивість, що вимагає створення зазначених об'єктів бази даних.

image301

Мал. 4.91. Базові настройки програмного коду


Вказівка ​​цих та інших властивостей програмного коду визначає можливий набір операцій, команди по яким повинні бути представлені в програмному коді. Наприклад, якщо вказати властивість "DROP statement" і не вказувати інші властивості, то буде створений програмний код, який реалізує очищення бази даних від об'єктів, зазначених в інших частинах налаштувань.

Друга частина налаштувань забезпечує можливість вказівки конкретних типів об'єктів, по яким необхідно визначити запити програмного коду (рис. 4.92). У цій частині налаштувань показані всі можливі, відповідно до обраної СУБД, типи об'єктів, серед яких табличні простору (Tablespace), таблиці (Tables), перевірочні обмеження (Check constraint), індекси (Index), лічильники (Sequence) та ін.

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

image302

Puc. 4.92. Виділення об'єктів для програмного коду


У третій частині створення програмного коду інструментальне засіб пропонує розробнику визначити місце збереження програми, а також визначитися з подальшими діями по роботі ній (рис. 4.93):

  • • Run DDL on server (Виконати DDL на сервері) - дана вказівка ​​визначає необхідність не тільки зберегти па магнітному носії програмний код, а й виконати його в СУБД, відповідно до вказуються властивості підключення до неї;
  • • Edit and run DDL in the SQL editor (редагувати і виконати DDL в редакторі SQL) - дана вказівка ​​передбачає, що розробник бажає провести коригування програмного коду і тільки після коригування, використовуючи спеціальний редактор, виконати створений програмний код.

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

Процедура створення програмного коду з використанням СА ERWin Data Modeler трохи відрізняється, даючи кілька більш розгорнуті можливості настройки програми і се реалізації в СУБД. Якщо в продукті від 1ВМ більшість налаштувань заздалегідь визначено або створення програмного коду орієнтоване на настройки для конкретного об'єкта, то в засобі від С А розробник спочатку визначає всі налаштування і тільки в кінці визначається з процедурою створення програмного коду по окремих об'єктах.

image303

Мал. 4.93. Перегляд і визначення подальших дій з програмним кодом


Виклик майстра установки синхронізації моделі з базою даних і формування програмного коду створення об'єктів бази даних в інструментальному засобі СА ERWin Data Modeler виконується через пункт меню "Actions / Complete Compare" (Дії / Повне порівняння), що викликає діалогове вікно налаштувань правил зіставлення (синхронізації) моделей . Важливо розуміти, що процедура синхронізації передбачає вказівку двох моделей або баз даних, які потрібно порівняти. Тому даний інструмент доцільно застосовувати при необхідності створення бази даних або синхронізації (встановлення ідентичності) двох моделей бази даних, в деяких випадках різних рівнів.

Оскільки синхронізацію виконують при відкритій моделі бази даних, то першу частину налаштувань засоби моделювання пропускають, автоматично визначивши "лівої" моделлю ту, яка в момент виклику майстра відкрита. Проте, розробник може повернутися на цей крок і змінити модель, завантаживши її з файлу (рис. 4.94), або вибрати базу даних, також завантаживши се з СУБД.

image304


Puc. 4.94. Визначення першої моделі для синхронізації

На другому кроці розробником вказується друга модель або база даних для синхронізації. Якщо необхідно згенерувати програмний код для виконання в базі даних, то вибирається варіант "Database / Script" (База даних / Програмний код) і визначаються параметри її використання (рис. 4.95). У разі, коли ставиться завдання генерування програмного коду, друга модель може бути представлена ​​порожній моделлю, але важливо модель вказати, щоб засіб синхронізації розуміло необхідність відновлення ідентичності моделей.

image305


Puc. 4.95. Вибір моделі або бази даних для синхронізації

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

Наступні два кроки налаштувань визначають об'єкти обох моделей або баз даних, які необхідно порівняти і, при вказівці розробником, синхронізувати, створивши необхідні об'єкти в іншої моделі (рис. 4.97). Результатом зазначених виборів є конструктор програмного коду, що викликається за допомогою кнопки "Compare" (Порівняти), де вказуються конкретні елементи моделі бази даних або самої бази даних.

image306


Мал. 4.96. Визначення типів об'єктів, що підлягають синхронізації

image307


Мал. 4.97. Вибір об'єктів для синхронізації

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

За підсумками вказівки правил синхронізації, використовуючи піктограму <®>. можна зберегти програмний код у вигляді набору команд мови 5 () Ь, доступний для подальшого використання в СУБД, для якої синхронізація моделей і проводилася. Піктограм для створення програмного коду є дві, де одна формує програмний код але зміни "лівої" моделі, а друга - відповідно для правої моделі. При створенні повного програмного коду, коли друга модель є порожньою, формується програмний код правої моделі, оскільки він буде містити відомості про створення необхідних елементів вихідної моделі бази даних.

image308

Мал. 4.98. Налаштування програмного коду або синхронізації


  • [1] DDL - Data Definition Language, мова опису даних, який використовується для управління структурними елементами (об'єктами) бази даних.
 
<<   ЗМІСТ   >>