Головна

Методологія проектування.

  1.  C. Різниця потенціалів, що виникає між внутрішньою і зовнішньою сторонами мембрани, виміряна в стані фізіологічного спокою.
  2.  II. МЕТОДИ (МЕТОДИКИ) Патопсихологическое дослідження МЕТОДИКИ ДЛЯ ДОСЛІДЖЕННЯ УВАГИ І сенсомоторної реакції
  3.  III. Класифікація антибіотиків по спектру біологічної дії
  4.  III. Програма соціологічного дослідження.
  5.  IV. Асіміляціі. Випадки подвійного морфологічного значення однієї функції
  6.  Quot; Реалістичні "інтерпретації феноменологічного аналізу
  7.  SMS-опитування - новий метод соціологічного дослідження

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

1) Перевірка побудови локальної логічної моделі даних для окремого подання кожного користувача

2) Створення і перевірка глобальної логічної моделі даних

Перший етап включає в себе наступне:

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

-визначення номера відносин, виходячи зі структури локальної логічної моделі

перевірка моделі за допомогою правил нормалізації

перевірка моделі щодо транзакцій користувача

-створення діаграми «сутність - зв'язок»

-визначення вимог підтримки даних

-обговорення локально логічної моделі з кінцевими користувачами

Для (1) необхідно видалити зв'язку N: M, потім видалити складні зв'язку, рекурсивні зв'язку, зв'язку з атрибутами, множинні зв'язку, перевірити ще раз відносини 1: 1 і видалити надлишкові зв'язку.

Зв'язок N: M замінюється на дві зв'язку типу 1: N, введенням додаткової сутності в моделі даних.

Приклад: Газета друкує оголошення про об'єкти, що здаються в оренду.

Щоб виключити M: N, необхідно ввести нову слабку сутність «оголошення».

Складними зв'язками називаються зв'язку, які існують між трьома і більше сутностями. Складні зв'язку замінюють необхідною кількістю бінарних зв'язків 1: N, кіт встановлюються з нововведеними сутностями. Приклад потрійний зв'язку - зв'язок здача в оренду. Тут встановлюється відношення між сутностями працівник - кімната, об'єкт оренди, орендар. Щоб виключити потрійну зв'язок, необхідно ввести сутність угоду.

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

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

Важливим є повторний огляд зв'язків 1: 1. Можуть бути створені дві сутності представляють один і той же об'єкт. Їх необхідно об'єднати в одну сутність.

Видалення надлишкових зв'язків - це зв'язку, в яких одна і та ж інформація може бути отримана за допомогою інших зв'язків. Визначення номера відносин для кожної сильної сутності в лок ЛМ створює відношення. Якщо відносно необхідно включити складовою атрибут, то їх розбивають на прості атрибути. Для кожної слабкою суті створюються відносини. Відносно включають атрибут, який є зовнішнім ключем. Зовнішній ключ відповідає первинному ключу суті власника. Первинний ключ слабкою суті повністю або частково виводить з сутності власника. Якщо сутність бере участь в зв'язку 1: 1, то вибір одного з батьків або дочірньої суті проводиться довільно. Якщо суті беруть участь в інших зв'язках їх краще об'єднати в одне відношення. Обов'язковою є перевірка моделі за допомогою правил нормалізації. Нормалізація відносин дозволяє підвищити стійкість проекту і позбавити від аномалій обновл. У процесі нормалізації дотримується компроміс між фрагментацією даних і швидкодією.

Процес нормалізації включає чотири етапи:

1) 1 НФ: усунення повторюваних атрибутів

2) 2 НФ: усунення частково залежних атрибутів від первинного ключа

3) 3 НФ: усунення транзитивної залежності від первинного ключа

4) НФБК: усунення частково залежних атрибутів від потенційного ключа

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

Використовують два підходи до перевірки ЛМ:

1) перевірка тог, що дана модель надає повну інформацію про сутності, зв'язках, і атрибутах. Для цього треба описати кожну транзакцію.

2) нанесення на ER - діаграму всіх шляхів, прохожд. яких потрібно для виконання транзакцій.

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

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

Обмеження цілісності даних:

1) Обязат. дані; 2) обмеження для доменів атрибутів; 3) цілісність сутностей; 4) посилальна цілісність; 5) вимоги даного підприємства

(1) - деякий атрибут повинен містити 1 з допустимих значень, т. Е. Атрибут не може мати порожнього значення. Ці відомості повинні заноситися в словник даних.

(2) - кожен атрибут має домен, який представляє набір його допустимих значень. Приклад: Пол (атр), домен складається з двох символьних рядків довжиною в 1 символ.

(3) первинна ключ будь-суті не може містити 0 значен. Це повинно враховуватися при визначенні первинного ключа кожної сутності.

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

(5) -При завданні обмеження цілісності необхідно проаналізувати обмеження підприємства або бізнес-правил. Наприклад, обновл. сущн. м. регламентувати прийнятий. на підприємстві правила, які визна методи вип-ня транзакцій.

Заключним моментом є обговорення з кінцевими користувачами логічної моделі даних. На цьому етапі корисно перевірити лог модель даних на соотв діагр потік дан, яка відображає обмін даними в межах підприємства. Позвол визна, яка інформація явл входить, яку необхідно помістити в сховище даних. Звідси випливає інформацій, як д / б оголошень сущ-їй і як д використовуватися транз. Слід перевірити 2 моменти:

-Кожен Сховище даних має представляти всі безліч сутностей

-Атрібути, Які використовуються в потоці даних повинні належати суті того чи іншого типу

Заключний момент логічного проектування БД явл. перевірка глобальної логічної моделі даних. На цьому етапі будується логічна модель шляхом злиття окремих лог. моделей. При злитті в єдину глобальну ЛМ необхідно перевірити виконання правил нормалізації і виконання транзакцій окремих користувачів. Будується загальна модель ER-діагр, яка відображає глобальну модель даних.




 Загальні відомості про БД та СУБД |  Рівні представлення даних в СУБД |  Узагальнена архітектура СУБД |  Мови баз даних |  Функціональна залежність і нормалізація відносин |  Використання функцій агрегування в побудові запитів |  ієрархічна модель |  мережева модель |  SQL SERVER. Характеристика об'єктів БД |  Системні бази даних |

© um.co.ua - учбові матеріали та реферати