х об'єктів, які можуть цікавити користувача. Ці об'єкти є типами сутностей, що входять в модель. Один з методів ідентифікації сутностей полягає у вивченні специфікацій по виконанню конкретних функцій користувача на даному підприємстві. З цих специфікацій слід витягти всі використовувані в них іменники чи поєднання іменника чи прикметника. Потім серед них вибираються самі значущі об'єкти або важливі концепції і виключаються всі іменники, які просто визначають інші об'єкти.
У деяких випадках виділення сутностей буває утруднено через незадовільний способу представлення в специфікаціях. Користувачі, викладаючи свої думки, часто використовують не однозначні визначення, а приклади чи аналогії.
Після виділення сутностей наступним етапом розробки стає встановлення всіх існуючих між ними зв'язків. Одним з методів визначення сутностей є вибірка всіх іменників, присутніх в специфікаціях вимог користувачів. І в цьому випадку для виявлення зв'язків необхідно провести граматичний аналіз специфікації вимог. Проектувальників цікавлять тільки ті зв'язки між сутностями, які необхідні для задоволення вимог до проекту.
У більшості випадків зв'язку є двох сторонніми, іншими словами, зв'язки існують тільки між двома сутностями. Однак слід проявляти особливу увагу і ретельно перевіряти наявність у проекті складних зв'язків, що об'єднують понад дві сутностей різних типів, а так само рекурсивних зв'язків, що існують між сутностями одного і того ж типу.
Робота проектувальника істотно спрощується, якщо є можливість вивчити структуру складної системи за допомогою схеми, а не аналізувати докладні текстові описи специфікацій вимог користувачів. Для представлення сутностей і зв'язків між ними зазвичай використовуються діаграми «сутність-зв'язок» (ER-діаграми). Це дозволяє завжди мати під рукою наочний образ модельованої частини підприємства [8].
На наступному етапі пропонованої методології необхідно виявити всі дані, що описуютьсутності й зв'язку, виділені в створюваної моделі бази даних.
Оскільки зазвичай кількість атрибутів на багато перевищує кількість сутностей і зв'язків, може виявитися корисним спочатку підготувати список всіх атрибутів, використовуваних у специфікаціях вимог користувачів. У міру зв'язування чергового атрибуту з деякою сутністю або зв'язком він викреслюється зі списку. Подібний метод дозволяє гарантувати, що кожен з атрибутів буде пов'язаний з сутністю або зв'язком тільки одного типу. Коли зі списку буде викреслять останній атрибут, все ідентифіковані в моделі атрибути виявляться пов'язаними з деякою сутністю або зв'язком.
Наступний етап - це визначення доменів атрибутів. Завдання цього типу створення локальної концептуальної моделі даних полягає у визначенні доменів атрибутів для всіх атрибутів, присутніх в моделі. Доменом називається деякий безліч значень, елементи якого вибираються для присвоєння значень одному або декільком атрибутам.
Потім необхідно визначити атрибути, що є потенційними і первинними ключами. На цьому етапі кожної сутності встановлюється потенційний ключ (або ключі), після чого здійснюється вибір первинного ключа. Потенційним ключем називається атрибут або мінімальний набір атрибутів заданої сутності, що дозволяє однозначно ідентифікувати кожен її екземпляр. Для деяких сутностей можлива наявність декількох потенційних ключів. У цьому випадку серед них потрібно вибрати один ключ, який буде називатися первинним ключем. Всі інші потенційні ключі будуть називатися альтернативними ключами.
На наступному етапі локальна концептуальна модель даних перевіряється з конкретною метою: виявити наявність в ній надлишкових даних і усунути цей недолік, якщо він буде виявлений. На цьому етапі проводиться дослідження «один до одного» і видалення надлишкових зв'язків.
Метою застосування методології логічного проектування є створення локальної логічної моделі даних на основі локальної концептуальної моделі даних, що відбиває конкретне користувальницьке уявлення про предметної області додатки, і перевірка отриманої моделі за допомогою методів нормалізації та контролю виконання транзакції.
На цьому етапі кожна локальна концептуальна модель даних, створена на першому етапі, перетворюється в локальну логічну модель даних, що складається з ER-діаграми, реляційної схеми та супровідної документації. Для спрощення цього процесу передбачений необов'язковий перший етап, на якому відбувається усунення особливостей, які не можуть бути представлені безпосередньо в реляційної моделі (таких як зв'язку «багато до багатьох»).
Отримана реляційна схема перевіряється з використанням правил нормалізації для визначення того, чи є її структура правильною. Нормалізація - це розбиття таблиці на дві або б...
