Логічна модель описує поняття предметної області, їх взаємозв'язок, а також обмеження на дані, що накладаються предметною областю.
Приклади понять - "співробітник", "відділ", "проект", "зарплата". Приклади взаємозв'язків між поняттями - "співробітник числиться рівно в одному відділі", "співробітник може виконувати кілька проектів", "над одним проектом може працювати кілька співробітників". Приклади обмежень - "вік співробітника не менше 16 і не більше 60 років".
Логічна модель даних є початковим прототипом майбутньої бази даних. Логічна модель будується в термінах інформаційних одиниць, але без прив'язки до конкретної СУБД. Більш того, логічна модель даних необов'язково повинна бути виражена засобами саме реляційної моделі даних. Основним засобом розробки логічної моделі даних в даний момент є різні варіанти ER-діаграм (Entity-Relationship, діаграми сутність-зв'язок).
Одну і ту ж ER-модель можна перетворити як в реляційну модель даних, так і в модель даних для ієрархічних і мережевих СУБД, або в постреляціонних модель даних. Рішення, прийняті на попередньому рівні, при розробці моделі предметної області, визначають деякі межі, в межах яких можна розвивати логічну модель даних, в межах же цих кордонів можна приймати різні рішення. Наприклад, модель предметної області складського обліку містить поняття "склад", "накладна", "товар". При розробці відповідної реляційної моделі ці терміни обов'язково повинні бути використані, але різних способів реалізації тут багато - можна створити одне ставлення, в якому будуть присутні в якості атрибутів "склад", "накладна", "товар", а можна створити три окремих відносини, по одному на кожне поняття.
При розробці логічної моделі даних виникають питання: чи добре спроектовані відносини? Чи правильно вони відображають модель предметної області, а, отже, і саму предметну область?
Для того щоб оцінити якість прийнятих рішень на рівні логічної моделі даних, необхідно сформулювати деякі критерії якості в термінах фізичної моделі і конкретної реалізації і подивитися, як різні рішення, прийняті в процесі логічного моделювання, впливають на якість фізичної моделі і на швидкість роботи бази даних.
Таких критеріїв може бути дуже багато і вибір їх довільний. Деякі з таких критеріїв є важливими з точки зору отримання якісної бази даних: адекватність бази даних предметної області, легкість розробки і супроводу бази даних, швидкість виконання операцій оновлення даних (вставка, оновлення, видалення кортежів), швидкість виконання операцій вибірки даних.
База даних повинна адекватно відображати предметну область. Це означає, що повинні бути виконані такі умови.
1. Стан бази даних в кожен момент часу має відповідати стану предметної області.
2. Зміна стану предметної області має приводити до відповідної зміни стану бази даних.
3. Обмеження предметної області, відображені в моделі предметної області, повинні деяким чином відбиватися і враховуватися базі даних.
Практично будь-яка база даних, за винятком зовсім елементарних, містить певну кількість програмного коду у вигляді тригерів і збережених процедур.
Збережені процедури - це процедури і функції, що зберігаються безпосередньо в базі даних в відкомпілювався вигляді і які можуть запускатися користувачами або додатками, що працюють з базою даних. Основне призначення процедур -Реалізація бізнес-процесів предметної області.
Тригери - це збережені процедури, пов'язані з деякими подіями, що відбуваються під час роботи бази даних. В якості таких подій виступають операції вставки, оновлення та видалення рядків таблиць. Якщо в базі даних визначено певний тригер, то він запускається автоматично завжди при виникненні події, з яким цей тригер пов'язаний. Тригер спрацьовує незалежно від того, хто з користувачів і яким способом ініціював подія, яка викликала запуск тригера. Таким чином, основне призначення тригерів - автоматична підтримка цілісності бази даних.
Очевидно, що чим більше програмного коду у вигляді тригерів і збережених процедур містить база даних, тим складніше її розробка і подальший супровід.
На рівні логічного моделювання визначаються реляційні відносини і атрибути цих відносин. На цьому рівні можна визначати будь-які фізичні структури зберігання (індекси, хешування і т.п.). Єдине, чим можна управляти - це розподіл атрибутів з різних відносин.
Можна описати трохи відносин з великою кількістю атрибутів, або сформувати велику кількість відносин, кожне з яких містить мало атрибутів. Таким чином, необхідно спробувати відповісти на питання - чи впливає кількість відносин і кількість атрибутів у відносинах на швидкість виконання операцій оновлення даних. Така постановка не є досить коректною, тому що швидкість виконання операцій з базою даних залежить від фізичної реалізації бази даних. Проте, доцільно якісно оцінити цей вплив при однакових підходах до фізичного моделювання.
Основними операціями, що змінюють стан бази даних, є операції вставки, оновлення та видалення записів. У базах даних, які потребують постійних змін (складський облік, системи продажів квитків і т.п.) продуктивність визначається швидкістю виконання великої кількості невеликих операцій вставки, оновлення та видалення.
Зазвичай, вставка запису провадиться в одну з вільних сторінок пам'яті, виділеної для даної таблиці. СУБД постійно зберігає інформацію про наявність і розташування вільних сторінок. Якщо для таблиці не створені індекси, то операція вставки виконується фактично з однаковою швидкістю незалежно від розміру таблиці і від кількості атрибутів в таблиці. Якщо в таблиці є індекси, то при виконанні операції вставки записи індекси повинні бути перебудовані. Таким чином, швидкість виконання операції вставки зменшується при збільшенні кількості індексів у таблиці і мало залежить від числа рядків в таблиці.
Для операції оновлення та видалення записів з таблиці, перш, ніж оновити або видалити запис, її необхідно знайти. Якщо таблиці не індексована, то єдиним способом пошуку є послідовне сканування таблиці в пошуку потрібного запису. В цьому випадку, швидкість операцій оновлення і видалення істотно збільшується зі збільшенням кількості записів в таблиці і не залежить від кількості атрибутів. Але насправді неіндексовані таблиці практично ніколи не використовуються. Для кожної таблиці зазвичай оголошується один або кілька індексів, відповідний потенційним джерелам. За допомогою цих індексів пошук запису провадиться дуже швидко і практично не залежить від кількості рядків і атрибутів в таблиці (хоча, звичайно, деяка залежність є). Якщо для таблиці оголошено кілька індексів, то при виконанні операцій оновлення і видалення ці індекси повинні бути перебудовані, на що витрачається додатковий час. Таким чином, швидкість виконання операцій оновлення і видалення також зменшується при збільшенні кількості індексів у таблиці і мало залежить від числа рядків в таблиці.
Одне з призначень бази даних - надання інформації користувачам. Інформація витягується з реляційної бази даних за допомогою оператора SQL -SELECT. Однією з найбільш дорогих операцій при виконанні оператора SELECT є операція з'єднання таблиць. Таким чином, чим більше взаємопов'язаних відносин було створено в ході логічного моделювання, тим більша ймовірність того, що при виконанні запитів ці відносини будуть з'єднуватися, і, отже, тим повільніше будуть виконуватися запити. Таким чином, збільшення кількості відносин призводить до уповільнення виконання операцій вибірки даних, особливо, якщо запити заздалегідь невідомі.