Навігація
Головна
 
Головна arrow Інформатика arrow Інформатика для економістів

Проектування бази даних

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

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

У реляційній моделі допускаються тільки нормалізовані відносини.

Введемо ряд визначень.

Визначення 1. Відношення знаходиться в першій нормальній формі (1НФ) тоді і тільки тоді, коли всі вхідні в нього елементи містять тільки атомарні (неподільні) значення.

Це визначення просто встановлює, що будь-яке нормалізоване відношення знаходиться в 1НФ.

Першочергово важливим поняттям є поняття функціональної залежності (всередині відносини).

Визначення 2. Якщо задано відношення R, то атрибут Y відносини R функціонально залежить від атрибуту X відносини R тоді і тільки тоді, коли кожне значення X в R в кожен момент часу пов'язано точно з одним значенням Y.

Наприклад, дано ставлення Товари (Код товару, Найменування, Марка, Ціна). Код товара є ключовим атрибутом. Кожному значенню атрибута Код товару відповідає в точності одне значення атрибутів Найменування, Марка, Ціна. Іншими словами, знаючи значення атрибута Код товару, можна однозначно визначити значення інших атрибутів даного товару. Значить, атрибути Найменування, Марка, Ціна функціонально залежить від атрибуту Код товара. Можна уявити функціональну залежність за допомогою діаграми (рис. 10.4).

Діаграма функціональної залежності

Мал. 10.4. Діаграма функціональної залежності

У разі складного ключа вводиться поняття функціонально повної залежності.

Визначення 3. Атрибут Y знаходиться в повній функціональної залежності від атрибута X, якщо він функціонально залежить від X і не залежить функціонально від будь-якої підмножини атрибуту X (X - складовою ключ).

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

Наведемо інший приклад (рис. 10.6).

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

Мал. 10.5. Приклад повної функціональної залежності

Узагальнений приклад функціональної залежності

Мал. 10.6. Узагальнений приклад функціональної залежності

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

У такому випадку при проектуванні дане відношення розбивають на два (рис. 10.7).

Розбиття відносини на два у випадку різної функціональної залежності

Мал. 10.7. Розбиття відносини на два у випадку різної функціональної залежності

Визначення 4. Атрибут Y знаходиться в транзитивної залежності від атрибута X, якщо він знаходиться у функціональній залежності від атрибута Z, а атрибут Z - у функціональній залежності від атрибута X.

На рис. 10.8 атрибут Адреса фірми знаходиться в транзитивній залежно від атрибута Номер складу.

У такому випадку при проектуванні дане відношення розбивають на два (рис. 10.9).

Визначення 5. Ставлення R знаходиться в другій нормальній формі (2НФ), якщо воно знаходиться в 1НФ і кожен неключових атрибут функціонально повно залежить від первинного ключа.

Приклад транзитивної залежності

Мал. 10.8. Приклад транзитивної залежності

Розбиття відносини на два у разі наявності транзитивної залежності

Мал. 10.9. Розбиття відносини на два у разі наявності транзитивної залежності

Визначення 6. Ставлення R знаходиться в третій нормальній формі (ЗНФ), якщо воно знаходиться у 2НФ і при цьому будь неключових атрибут залежить від ключа нетранзитивно.

Визначення 7. Ставлення R знаходиться в четвертій нормальній формі (4НФ), якщо воно знаходиться в ЗНФ і кожен кортеж відношення складається із значення первинного ключа, яке ідентифікує деякий об'єкт, і з безлічі взаємно незалежних довільних значень атрибутів, деяким чином описують цей об'єкт.

4НФ укладає в себе дуже просту і загальнодоступну ідею. Поняття 4НΦ можна на інтуїтивному рівні сформулювати так: "один факт зберігається один раз".

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

  • 1-й крок. Довільний ставлення наводиться до першої нормальної форми (1НФ).
  • 2-й крок. Ставлення, що знаходиться в 1НФ, наводиться до еквівалентної сукупності відносин, що знаходяться в другій нормальній формі (2НФ).

Третій крок. Ставлення, що знаходиться в 2НФ, приводиться до еквівалентної сукупності відносин, що знаходяться в третій нормальній формі (3НФ).

4-й крок. Ставлення, що знаходиться в 3НФ, наводиться до еквівалентної сукупності відносин, що у четвертої нормальній формі (4НФ).

На практиці ж процес нормалізації, як правило, закінчується на етапі приведення відношення до ЗНФ.

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

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

Уточнимо кроки нормалізації.

  • 1-й крок полягає в утворенні двовимірної таблиці, яка містить елементи даних.
  • 2-й крок нормалізації полягає в тому, щоб виділити ключі і залежні від них атрибути. Для того щоб привести ставлення до 2НΦ, потрібно виділити групи атрибутів, що залежать від частин складеного ключа. Ці групи можуть утворювати окремі відносини (таблиці). Виділення з відносини, що знаходиться в 1НФ, таких відносин, у яких неключові атрибути залежать тільки від ключа в цілому, називається приведенням до 2НФ.

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

Процесу приведення відносини довільної форми до 3НФ передує велика попередня робота зі створення цього первинного або довільного відносини. Це не менш важливий момент в проектуванні бази даних.

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

Приклад 10.1 (проектування БД).

Потрібно розробити БД реалізації товарів зі складів фірмами холдинг-центру. Холдинг представляє об'єднання чотирьох фірм: Citilink, Dinikin, Elee, Lizarin. Кожна з цих фірм має кілька складів в Москві, де зберігаються товари. Номенклатура товарів єдина для холдинг-центру. Будь-який товар може зберігатися на одному або декількох складах; на кожному складі зберігаються різні товари. Зі складів здійснюється оптова торгівля. Кожна фірма здійснює продажі тільки зі своїх складів.

Рішення

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

Виділимо ключі і залежні від них атрибути:

  • • атрибути Назва фірми, Адреса фірми, Телефон фірми знаходяться у функціональній залежності від атрибута Код фірми;
  • • атрибути Адреса складу, Телефон складу, Код фірми (так як кожен склад належить конкретній фірмі) знаходяться у функціональній залежності від атрибута Номер складу;

Первинне ставлення для БД реалізації товарів зі складів

Мал. 10.10. Первинне ставлення для БД реалізації товарів зі складів

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

Таким чином, з первинного відносини утворилося п`ять відносин (рис. 10.11).

Відносини, отримані з первинного, для БД реалізації товарів зі складів

Мал. 10.11. Відносини, отримані з первинного, для БД реалізації товарів зі складів

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

Тоді остаточно матимемо наступні п'ять відносин (рис. 10.12). Після чого можна приступати до створення БД "Продажі" за допомогою СУБД MS Access.

Стосунки для БД реалізації товарів зі складів

Мал. 10.12. Стосунки для БД реалізації товарів зі складів

 
Якщо Ви помітили помилку в тексті позначте слово та натисніть Shift + Enter
< Попередня   ЗМІСТ   Наступна >
 
Дисципліни
Агропромисловість
Аудит та Бухоблік
Банківська справа
БЖД
Географія
Документознавство
Екологія
Економіка
Етика та Естетика
Журналістика
Інвестування
Інформатика
Історія
Культурологія
Література
Логіка
Логістика
Маркетинг
Медицина
Нерухомість
Менеджмент
Педагогіка
Політологія
Політекономія
Право
Природознавство
Психологія
Релігієзнавство
Риторика
Соціологія
Статистика
Техніка
Страхова справа
Товарознавство
Туризм
Філософія
Фінанси
Пошук