Практикум - темі 5 - проектування баз даних

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

Увага! Всі результати роботи необхідно зберігати в своїй мережевій теці!

1. Створення концептуальної моделі бази даних «Бібліотека» в середовищі PowerDesigner 10.0

Схема бази даних містить п'ять сутностей:

Практикум - темі 5 - проектування баз даних

Технологія виконання роботи

  1. Запустіть програму PowerDesigner командою Пуск> Програми> Sybase> PowerDesigner.
  2. Натисніть на крайню ліву піктограму на панелі інструментів і виберіть із запропонованих режимів Conceptual Data Model (концептуальна модель даних). Підтвердіть вибір, натиснувши кнопку OK.
  3. При створенні моделі використовуйте вбудовану панель інструментів і піктограми Сутність (Entity) і Зв'язок (Relationship). Для створення суті необхідно клацнути лівою кнопкою миші на піктограмі Сутність і потім, помістивши покажчик миші в область діаграми, натиснути ліву кнопку миші.
  4. Для завдання властивостей сутності необхідно скинути режим побудови сутностей, натиснувши праву кнопку миші, і двічі клацнути на суті лівою кнопкою миші. Для кожної сутності, крім імені (Name) і коду (Code), задайте короткий опис в розділі Notes:

Практикум - темі 5 - проектування баз даних

Для підтримки кирилиці необхідно налаштувати шрифти, вибравши в меню команду Tools> General Options> Fonts і вказавши шрифт з підтримкою кирилиці.

  • Для кожної сутності задайте всі необхідні атрибути. При описі атрибутів використовуються наступні знаки:
    • M # 151; обов'язковий;
    • P # 151; входить в Primary Key;
    • D # 151; видно на схемі (виведений в прямокутнику з сутністю).

    Практикум - темі 5 - проектування баз даних

    Якщо атрибут входить в Primary Key. то він автоматично стає обов'язковим. Зворотне правило не діє, тобто не кожен обов'язковий атрибут входить в первинний ключ.

    Тип даних для атрибута може бути обраний зі списку позначень стандартних типів або з переліку стандартних типів з використанням панелі стандартних типів (кнопка з трьома крапками):

    Практикум - темі 5 - проектування баз даних

    Орієнтовні назви кодів і типів даних атрибутів моделі «Бібліотека» наведені в табл. 1.

    Таблиця 1. Опис атрибутів бази даних «Бібліотека»

    Далі слід задати всі необхідні обмеження. Для написання обмежень вам можуть знадобитися функції Transact SQL. Опис основних функцій наведено в файлі TransactSQL.doc. який лежить в папці Практика на диску Free_access.

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

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

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

    Після створення і опису всіх сутностей необхідно створити зв'язки між ними. При описі зв'язку ми визначаємо обов'язковість зв'язку і її тип. У ER-моделі підтримуються три типи зв'язків:

    • зв'язок типу «один-до-одного» (1: 1);
    • зв'язок типу «один-ко-многим» (1: М);
    • зв'язок типу «багато-до-багатьох» (М: М).

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

    Практикум - темі 5 - проектування баз даних

    Після створення всіх зв'язків треба перейти до створення та опису обмежень.

    Обмеження бувають двох рівнів: обмеження для атрибутів сутності та обмеження, які задаються на рівні всієї суті. Обмеження для атрибута задаються з використанням кнопки Властивості. Далі ви можете задати обмеження на значення на закладках Standard Checks (стандартні перевірки) і Additional Checks (додаткові перевірки):

    Практикум - темі 5 - проектування баз даних

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

    Практикум - темі 5 - проектування баз даних

    Крім того, ви можете задати обмеження на атрибут у вигляді правила. Для цього треба вибрати закладку Rules:

    Практикум - темі 5 - проектування баз даних

    Спочатку треба задати ім'я правила (Name), яке, як і всі імена об'єктів в концептуальної моделі, може бути задано російською мовою, а потім задати код правила Code. який є ідентифікатором обмеження (constraint), яке буде згенеровано на мові SQL:

    Практикум - темі 5 - проектування баз даних

    Практикум - темі 5 - проектування баз даних

    • Definition # 151; це опис характеристик або властивостей атрибута на деякому природному мовою (не формалізований опис);
    • Fact # 151; опис конкретного факту; найчастіше його можна пов'язати із значенням за замовчуванням;
    • Formula # 151; обчислюється значення;
    • Requirement # 151; специфікація, яка відноситься скоріше до функціонування проектованої інформаційної системи;
    • Validation # 151; обмеження, виражене, наприклад, у вигляді логічного виразу, яке буде перевірятися на істинність при введенні даних в атрибут.

    Тільки правила типу Validation при переході до фізичної моделі можуть бути згенеровані автоматично у вигляді обмеження (Constraint) і пов'язані з даними атрибутом.

    Для введення відповідного виразу необхідно вибрати закладку Expression. На закладці Dependencies вказується, з яким атрибутом пов'язано це правило (тобто від кого воно залежить).

    Аналогічним чином, правила можуть бути пов'язані з цілою сутністю. Для цього виконайте такі дії:

    1. Ввести саме правило, вибравши у верхньому меню команду Model> Business Rules.
    2. У список правил внести нове правило, не забувши поставити його тип:

    Практикум - темі 5 - проектування баз даних

  • Перейти до властивостей правила і задати вираз для правила з урахуванням імен атрибутів, які в цьому правилі беруть участь:

    Практикум - темі 5 - проектування баз даних

  • Після того як правило введено, його треба зберегти і приєднати до відповідної сутності. Для цього треба вибрати сутність, перейти до її властивостям і вибрати закладку Rules:

    Практикум - темі 5 - проектування баз даних

  • Натиснути кнопку Додати. При цьому завантажиться повний список правил, які до цього моменту визначені в системі:

    Практикум - темі 5 - проектування баз даних

  • Встановити «галочку» навпроти потрібного правила:

    Практикум - темі 5 - проектування баз даних

  • Після вибору правила натисніть OK. Не забудьте натиснути кнопку Застосувати в вікні зі списком правил даної суті. Тільки після цього правило буде пов'язано з цією сутністю:

    Практикум - темі 5 - проектування баз даних

    Перевірка концептуальної моделі

    Після завершення створення проекту концептуальної моделі необхідно виконати її перевірку. Для цього треба натиснути відповідну кнопку в панелі інструментів або вибрати команду меню Tools> Check Model.

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

    Для виконання цього етапу необхідно вибрати в меню команду Tools> Generate Physical Data Model. Відкриється вікно налаштування режиму генерації:

    Практикум - темі 5 - проектування баз даних

    Після виконання команди генерації, якщо Result List порожній (тобто не містить зауважень), можете закрити його і під ним ви побачите отриману фізичну модель для обраного сервера:

    Практикум - темі 5 - проектування баз даних

    Для нашої моделі в ній з'явилися дві нові сутності (на малюнку вони виділені зеленим кольором). Вони розв'язали зв'язку «багато-до-багатьох» в концептуальної моделі.

    Модель можна перевірити командою Tools> Check model.

    3. Генерація SQL-скрипта для створення всіх об'єктів даталогіческой моделі

    Тепер необхідно згенерувати скрипт на мові SQL, який створює всі необхідні нам об'єкти: відносини, обмеження і зв'язку. Для цього треба виконати наступні дії:

    1. Вибрати в верхньому меню команду Databases> Generate Database для виклику вікна генерації бази даних:

    Практикум - темі 5 - проектування баз даних

  • У розділі File Name задати ім'я, відмінне від стандартного crebas. У розділі Directory вказати доступний для вас директорій, звідки потім ви зможете вважати і скопіювати даний файл.
  • У розділі установок необхідно прибрати «галочку» з операції створення бази даних Create database:

    Практикум - темі 5 - проектування баз даних

  • Скрізь прибрати операцію видалення об'єктів. У розділі Selection перевірити, чи всі сутності і правила потрапили в модель.
  • Потім натиснути кнопку Застосувати і кнопку OK. Перед вами з'явиться вікно зі скриптом:

    Практикум - темі 5 - проектування баз даних

  • Натиснути кнопку Edit для редагування скрипта:

    Практикум - темі 5 - проектування баз даних

    Отриманий на предидущемепате скрипт ви виконуєте так само, як писали запити до бази даних на попередніх практичних заняттях: підключаєтеся до MS SQL Server, встановлюйте курсор на новостворену базу даних, переходите в Query Analyzer, завантажуєте підготовлений раніше скрипт і натискаєте на кнопку із зеленим трикутником .

    Якщо в процесі виконання скрипта відбудуться помилки, необхідно проаналізувати їх, внести необхідні виправлення на рівні проекту концептуальної моделі бази даних і повторити дії по створенню скрипта. Перш ніж запускати виправлений скрипт на виконання, не забудьте видалити всі створені об'єкти: оскільки SQL # 151; інтерпретована мова, всі оператори, які транслятор міг виконати правильно, були виконані, і якісь об'єкти могли з'явитися в базі даних.

    5. Генерація звітів по концептуальної моделі в PowerDesigner 9.0

    Після налагодження моделей необхідно згенерувати звіт для концептуальної моделі. Це можна зробити наступним чином:

    1. Вибрати на панелі інструментів кнопку Створити звіт. Відкриється вікно налаштування параметрів звіту.
    2. Натиснути кнопку Новий звіт для виклику діалогового вікна створення звіту:

    Практикум - темі 5 - проектування баз даних

  • В поле вибору шаблону звіту ReportTemplate вказати Full conceptual Report.
  • Після цього ви побачите вікно конфігурації звіту. У звіт слід обов'язково включити схему у вигляді графіка (Diagrams), сутності (Entity), атрибути (Data item) і зв'язку (Relationship):

    Практикум - темі 5 - проектування баз даних

  • Зберегти звіт у форматі RTF або HTML. Для цього, знаходячись у вікні формування звіту, вибрати команду меню File> Generate> RTF або File> Generate> HTML.
  • Зберегти згенерований звіт у вашій папці на мережевому диску.
  • Звіт можна згенерувати не тільки по концептуальної, але і з фізичної моделі бази даних. Виконайте цю роботу, перебуваючи в фізичної моделі PowerDesigner. Порівняйте отримані звіти і проаналізуйте, чим вони відрізняються.

    6. Завдання для самостійної роботи

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

    Питання для самоперевірки

    1. Чому в скрипті створення об'єктів бази даних присутні оператори Alter Table. Чи не можна було обійтися без них?
    2. Чи можна створити сутність без первинного ключа?
    3. Як можна задати можливі ключі відносини?
    4. Що означає буква M при описі атрибутів сутності?
    5. Які додаткові обмеження накладає PowerDesigner при розробці ER-моделі?
    6. Що означає тип даних Serial. Як цей тип даних інтерпретується СУБД MS Access і MS SQL Server?
    7. Який порядок видалення об'єктів зі створеної бази даних? Чи може цей порядок бути довільним? Якщо не може, то чому?
    8. Чи може один і той же атрибут відносини входити і в первинний, і у зовнішній ключ? Якщо ні, то чому? Якщо може, наведіть приклади.

    Схожі статті