Різниця між концептуальною та логічною моделлю
Моделювання даних – це одне із завдань, яке бентежить багатьох розробників моделей через використання різних схем моделювання. Три стилі моделювання даних, які дуже популярні, є концептуальними, фізичними та логічними моделями, але через багато частково збігаючих принципів люди, які хочуть використовувати будь-яку з цих моделей, залишаються збентежені. Їхня плутанина ще більше збільшується через технічний жаргон і термінологію. У цій статті ми спробуємо з'ясувати різницю між концептуальними і логічними моделями в простих термінах, щоб усунути сумніви читачів.
Концептуальне моделювання даних
Модель відносин сутностей є основною характеристикою концептуальної моделі даних. У ERD цієї моделі об'єкти представлені як блоків, а відносини зображені як ромбів. Прикладом відносин може бути замовлення клієнта, тоді як прикладом сутності є все, що може зацікавити бізнес. Ця модель була розроблена Пітером Ченом у 1976 році. Однак з того часу ця модель була розведена і рідко використовується. у чистому вигляді сьогодні.
У концептуальній моделі даних є також елементи даних, крім сутностей та відносин. Ці елементи даних пов'язані з об'єктами як їх атрибути. Деякі елементи даних, які є спільними для всіх об'єктів, можуть бути пов'язані з багатьма об'єктами моделі. Однією з особливостей будь-якої концептуальної моделі даних є використання тієї ж термінології для сутностей, що використовується у бізнесі.Хоча концептуальна модель є відносно простою, вона не залишається такою, враховуючи складності компаній сьогодні. Щоб описати сутності та їх відносини у сучасному контексті, при концептуальному моделюванні даних потрібен дуже високий рівень абстракції.
Логічне моделювання даних
Саме коли ІТ-дані мають бути реалізовані в бізнес-даних, використовується логічна модель даних. Хоча немає необхідності мати лад при іменуванні сутностей і взаємин у концептуальної моделі, логічна модель вимагає обліку організації під час створення атрибутів. Потім можна використовувати сурогатні ключі, щоб було простіше, якщо через зовнішні ключі таблиці виглядають складними. Після завершення. Логічна модель, здається, близька до фізичної моделі. Тим не менш, він все ще має схожість із концептуальною моделлю. Логічна модель має первинні, зовнішні та альтернативні ключі, але не має нічого спільного з цільовою платформою бази даних.
У чому різниця між концептуальною та логічною моделлю даних?
Як концептуальні, і логічні моделі даних важливі для моделювання даних.
• Коли концептуальна модель даних полегшує обмін даними з описом вимог до даних, логічна модель даних дозволяє ІТ-фахівцям брати участь, не турбуючись про обмеження бази даних.
Моделювання даних – це одне із завдань, яке збиває з пантелику багатьох розробників моделей через використання різних схем моделювання.Три стилі моделювання даних, які дуже популярні, – це концептуальні, фізичні та логічні моделі, але через безліч принципів, що перетинаються, люди, які хочуть використовувати будь-яку з цих моделей, залишаються в збентеженні. Їхня плутанина ще більше збільшується через технічний жаргон і термінологію. У цій статті буде зроблено спробу з'ясувати різницю між концептуальною та логічною моделями простими словами, щоб позбавити читачів від сумнівів.
Концептуальне моделювання даних
Модель відносин сутностей – це основна функція концептуальної моделі даних. У ERD цієї моделі об'єкти представлені у вигляді прямокутників, а відносини – у вигляді ромбів. Прикладом відносин може служити клієнт, який наказує, тоді як прикладом сутності можуть бути всі речі, які можуть бути цікаві бізнесу. Ця модель була розроблена Пітером Ченом у 1976 році. Однак з того часу ця модель розмилася і рідко використовується. у чистому вигляді сьогодні.
У концептуальній моделі даних, крім сутностей і відносин, існують елементи даних. Ці елементи даних пов'язані з об'єктами як їх атрибути. Деякі елементи даних, загальні всім сутностей, можуть бути пов'язані з багатьма сутностями в моделі. Однією з особливостей будь-якої концептуальної моделі даних є використання тієї ж термінології для сутностей, що використовується у бізнесі. Хоча концептуальна модель відносно проста, вона не залишається такою з огляду на складність сучасних компаній. Для опису сутностей та його відносин у сучасному контексті потрібен дуже високий рівень абстракції у концептуальному моделюванні даних.
Логічне моделювання даних
Логічна модель даних використовується, коли ІТ-дані мають бути реалізовані в бізнес-даних. У той час як немає необхідності мати порядок за іменування сутностей і відносин у концептуальній моделі, логічна модель вимагає обліку організації при створенні атрибутів. Потім можна використовувати сурогатні ключі, щоб спростити завдання, якщо зовнішні ключі роблять складні таблиці. Після завершення. Логічна модель видається близькою до фізичної моделі. Тим не менш, він все ще має схожість із концептуальною моделлю. Логічна модель має первинний, зовнішній та альтернативний ключі, але не має нічого спільного з цільовою платформою бази даних.
У чому різниця між концептуальною та логічною моделлю даних?
• Для моделювання даних важливі як концептуальні, так і логічні моделі даних
• Коли концептуальна модель даних спрощує спілкування з описом вимог до даних, логічна модель даних дозволяє ІТ-спеціалістам втручатися, не турбуючись про обмеження бази даних.
Концептуальне проектування бази даних. Процес створення моделі використовуваної на підприємстві інформації, яка не залежить від будь-яких фізичних аспектів її уявлення.
Перша фаза процесу проектування бази даних називається концептуальним проектуванням бази даних. Вона полягає у створенні концептуальної моделі даних для аналізованої частини підприємства. Ця модель даних створюється з урахуванням інформації, записаної у специфікаціях вимог користувачів.Концептуальне проектування бази даних абсолютно не залежить від таких подробиць її реалізації, як тип обраної цільової СУБД, набір прикладних програм, що використовуються, використовувані мови програмування, тип обраної обчислювальної платформи, а також від будь-яких інших особливостей фізичної реалізації. Під час розробки концептуальна модель даних постійно піддається тестуванню та перевірці на відповідність вимогам користувачів. Створена концептуальна модель даних підприємства є джерелом інформації фази логічного проектування бази даних.
Логічне проектування баз даних. Процес створення моделі інформації, що використовується на підприємстві, з урахуванням обраної моделі організації даних, але незалежної від типу цільової СУБД та інших фізичних аспектів реалізації.
Друга фаза проектування бази даних називається логічним проектуванням бази даних. Її мета полягає у створенні логічної моделі даних для досліджуваної частини підприємства. Концептуальна модель даних, створена попередньому етапі, уточнюється і перетворюється на логічну модель даних. Логічна модель даних враховує особливості обраної моделі організації даних цільової СУБД (наприклад, реляційна чи мережева модель).
Якщо концептуальна модель даних залежить від будь-яких фізичних аспектів реалізації, то логічна модель даних створюється з урахуванням обраної моделі організації даних цільової СУБД. Інакше кажучи, на цьому етапі вже має бути відомо, яка СУБД використовуватиметься як цільова — реляційна, мережева, ієрархічна чи об'єктно-орієнтована.Однак на цьому етапі ігноруються решта аспектів обраної СУБД — наприклад, будь-які особливості фізичної організації її структур зберігання даних та побудови індексів.
У процесі розробки логічна модель даних постійно тестується та перевіряється на відповідність вимогам користувачів. Для перевірки коректності логічної моделі даних використовується метод нормалізації. Нормалізація гарантує, що виведені з існуючої моделі даних відносини не матимуть надмірності даних, здатної викликати аномалії оновлення після їх фізичної реалізації.
Побудована логічна модель даних є джерелом інформації для етапу фізичного проектування та забезпечує розробника фізичної бази даних засобами знаходження компромісів, необхідних для досягнення поставленої мети, що дуже важливо для ефективного проектування. Логічна модель даних також відіграє важливу роль на етапі експлуатації та супроводу вже готової системи. При правильно організованому супроводі модель даних, що підтримується в актуальному стані, дозволяє точно і наочно представити будь-які зміни, що вносяться в базу даних, а також оцінити їх вплив на прикладні програми і використання даних, що вже є в базі.
Концептуальне та логічне проектування — це ітеративні процеси, які починаються у певний момент часу та продовжуються у вигляді практично нескінченного ряду уточнень та покращень. Їх слід розглядати як процес вивчення. У міру поглиблення розробниками розуміння принципів роботи підприємства та сенсу використовуваних даних вони висловлюють це розуміння у вигляді тієї чи іншої моделі даних.Зібрана інформація, у свою чергу, може вимагати внесення певних змін до інших частин проекту, що створюється.
Концептуальне та логічне проектування бази даних – найважливіші фактори загального успіху системи, що розробляється. Якщо створений проект не є точним відображенням методів роботи та структури підприємства, то буде дуже складно, якщо взагалі можливо визначити всі необхідні користувачам уявлення (зовнішні схеми) або організувати підтримку цілісності бази даних. Крім того, можуть виникнути труднощі з фізичною реалізацією бази даних або забезпечення прийнятної продуктивності системи. У той самий час здатність адаптацію змін є ознакою успішно спроектованої бази даних. Отже, завжди є сенс витратити необхідний час та енергію на створення найкращого з можливих проектів.
Логічна модель, що відбиває особливості уявлення про функціонування підприємства одночасно багатьох типів користувачів, називається глобальною логічною моделлю даних. Існує два основних підходи до створення глобальної логічної моделі даних підприємства – це централізований підхід та підхід на основі інтеграції уявлень.
Централізований підхід. Злиття вимог окремих користувачів, виражених у вигляді різних уявлень, в єдиний набір вимог всіх користувачів, який використовується для створення глобальної логічної моделі даних.
При використанні першого підходу, який прийнято називати централізованим, вимоги всіх існуючих типів користувачів щодо різних областей застосування програми об'єднуються з утворенням єдиного списку вимог.Характерною особливістю цього підходу є те, що списки вимог складаються до створення глобальної логічної моделі даних Цей підхід застосовується лише за умови, що описувана база даних не надто велика чи складна.
Метод інтеграції уявлень. Злиття окремих локальних логічних моделей даних, що відображають уявлення різних груп користувачів, у єдину глобальну логічну модель даних.
При використанні другого підходу, який прийнято називати методом інтеграції уявлень, здійснюється злиття окремих моделей даних, що відображають уявлення різних груп користувачів і локальних логічних моделей даних, в єдину глобальну логічну модель даних всього підприємства. Цей підхід більш керований, оскільки вся робота попередньо поділяється на дрібніші і легко контрольовані частини. Труднощі зазвичай виникають лише при спробах злиття локальних моделей даних, створених різними розробниками, які можуть використовувати різні терміни для того самого поняття або, навпаки, пов'язувати один і той же термін з різними поняттями.
1.5. Приклад бази даних "Бібліотека".
Технологічний процес: облік видачі книжок у бібліотеці.
7. ІНВЕНТАРНІ НОМЕРИ КНИГ
1.5. № читацького квитка
1.6. Серія паспорту 4.1. Код
1.7. № паспорта 4.1. Код
1.10. Місце основної роботи
2.6. Код паспорта 4.1. Код
3.3. Автор 6.1. Код
4.7. Місце видачі паспорта
4.8. Дата видачі паспорта
4.9. Прописка (домашня адреса)
5.3. Тип телефону 10.1. Код
6.7. Коротка біографія
7. ІНВЕНТАРНІ НОМЕРИ КНИГ
7.4. Інвентарний номер
8.3. Код бібліотекаря, який видав книгу
8.4. Код інвентарного номера книги
8.8. Фактична дата повернення
8.9.Код бібліотекаря, який прийняв книгу
9. ТИПИ КНИЖКОВИХ ФОНДІВ
9.2. Найменування типу фонду
10.2 Назва типу телефону
Створимо логічну модель бази даних, що дозволяє облік видачі книг у бібліотеці.
Почнемо з суб'єктів цього процесу. Відразу можемо виділити три суб'єкти: ЧИТАЧІ, БІБЛІОТЕКАРІ та КНИГИ. Почнемо опис властивостей цих суб'єктів із читачів. Властивості кожного суб'єкта будуть назвами стовпців таблиці. Інформація про суб'єктів, які беруть участь у процесі видачі книг, будемо заносити до рядків таблиці. Отже, ЧИТАЧІ.
Назва першої колонки переважають у всіх таблицях буде одне й теж – «КОД». Це зазвичай. Але надалі ми побачимо, як і більшість правил, матиме винятки. Назва колонки в таблиці відповідає заголовку, або точніше, назві поля у таблиці, що входить до складу бази даних. Тому далі ми говоритимемо про полях таблиці, а не про її колонки.
Наступні чотири поля таблиці "ЧИТАЧІ" "Прізвище", "Ім'я", "По батькові", "№ читацького квитка" – питань не викликають. Далі йдуть два поля: «Серія паспорта» та «№ паспорта». Ці два поля мають на увазі, що у базі даних мають бути паспортні дані кожного читача. Виділимо їх зберігання окрему таблицю. "Паспортні дані". У полі "Примітка" помістимо додаткові дані щодо кожного читача, для яких не виділено окремі поля в таблиці.
Звернімо увагу на поля "Телефон". У читача в даний час може бути три типи телефонів: домашній, робочий та мобільний. Отже, цієї інформації необхідно виділити окрему таблицю: «Телефони».
Розглянемо таблицю "Паспортні дані", що складається з таких полів: "Код", "Серія паспорта", "№ паспорта", "Дата народження", "Місце народження", "Підлога", "Місце видачі паспорта", "Дата видачі паспорта" », «Прописка (домашня адреса)». Жодне з полів не має виділення під інформацію в ньому що зберігається ще однієї таблиці. Тепер нам залишилося замінити у полі «ЧИТАЧІ» поля 1.6 та 1.7 одним полем – «Код паспорта».
У цьому випадку у нас вийде, що у рядку таблиці, що відповідає одному читачеві в полі код паспорта буде знаходитись код (номер рядка таблиці «Паспортні дані») відповідний рядку таблиці «Паспортні дані», в якій зберігається номер та серія паспорта цього читача з іншого інформацією, що виписана з його паспорта.
Розглянемо таблицю "Телефони". Вона містить чотири поля: "Код", "Код читача", "Тип телефону", "№ телефону". У полі «Код» міститься унікальний номер рядка таблиці. У полі «Код читача» міститься значення поля 1.1 таблиці «ЧИТАЧІ», що відповідає рядку таблиці, в якій міститься інформація про господаря телефону. Отже, у цій таблиці поле 5.1 «Код» зайве, т.к. ми по полю 5.2 "Код читача" за таблицею 1. "ЧИТАЧІ" однозначно визначаємо господаря телефону.
Таблиця 10 Тип телефону введена виключно для того, щоб при перегляді бази даних назви типів телефонів були однакові не тільки для користувачів на екрані, але і для запитів, що забезпечують пошук за типами телефонів читачів. Вона містить лише два поля: «Код» та «Найменування типу телефону». У полі "Найменування типу телефону", швидше за все, буде лише зазначено три типи телефонів: "домашній", "робочий" та "мобільний". Як Ви вже здогадалися у таблиці 5."ТЕЛЕФОН" замість поля 5.3 "Тип телефону" буде поле "Код типу телефону", значення в якому будуть відповідати типу телефону з таблиці 10.
На цьому вважатимемо, що всю інформацію про читачів ми зможемо отримати з нашої бази даних. Займемося таблицею 2. "БІБЛІОТЕКАРІ". Вона міститиме дев'ять полів: "Код", "Табельний номер", "Прізвище", "Ім'я", "По батькові", "Код паспорта", "Посада", "Домашній телефон", "Примітка".
Зазначимо ряд особливостей даної таблиці та загальні риси з таблицею «ЧИТАЧІ». По-перше, у ряді випадків «Код» працівника підприємства збігається з його «Табельним номером», який цікавіший бухгалтерії для нарахування заробітної плати. Тоді поле «Код» не знадобилося б. По-друге, як і в таблиці «ЧИТАЧІ» виділені під прізвище, ім'я та по батькові окремі поля. У принципі, під П.І.Б. можна виділити одне поле, але досвід показує, що й прізвище, ім'я та по батькові людей перебувають у різних полях, працювати з цією інформацією легше. По-третє, паспортні дані бібліотекарів зберігаються у тій самій таблиці, як і паспортні дані читачів (див. поле 2.6. «Код паспорта»). По-четверте, зверніть увагу до полі 2.7. "Посада". У реальному завданні цю інформацію необхідно було б брати з таблиці, де зберігається штатний розпис працівників бібліотеки за відповідним кодом посади. У нашому випадку, щоб не ускладнювати завдання, ми вписуватимемо в дане поле просто назву посади. По-п'яте, поле 2.8. «Домашній телефон» припускає, що нас цікавить лише домашній телефон бібліотекаря.Якщо ми захочемо мати більше одного телефону бібліотекаря, тоді необхідно дещо модифікувати таблицю «Телефони» (наприклад, додати ще одне поле, яке б дозволило відрізняти, чи належить цей телефон читачеві, чи він належить працівникові бібліотеки) і вписувати відповідний код у поле «Код телефону», введеного замість поля «Домашній телефон» у таблицю «БІБЛІОТЕКАРІ».
Розглянемо структуру таблиці 3. "КНИГИ". Вона складається з наступних полів: Код, Назва, Автор, Рік видання, Тираж, УДК, Шифр, Примітка. Звернімо увагу на поле 3.3. "Автор". Напрошується виділення для авторів книг окремої таблиці «АВТОРИ КНИГ». У цьому випадку поле "Автор" замінимо на поле "Код автора", в якому будемо прописувати номер рядка таблиці "Автори книг", що містить інформацію про автора книги. Таке рішення продиктовано тим, що одним автором може бути написано багато книг. Поля 3.6. «УДК» та 3.7. «Шифр» можна було б розписати так, як це роблять у бібліотеці на теми, залежно від їх значень. Але цього робитимемо, тим самим спростимо завдання.
Розглянемо таблицю 6. «АВТОРИ КНИГ». Вона складається з наступних полів: "Код", "Прізвище", "Ім'я", "По батькові", "Дата народження", "Дата смерті", "Коротка біографія" та "Примітка". Звернімо увагу на два поля «Коротка біографія» та «Примітка». З назви поля Коротка біографія стає зрозумілим, що в даному полі повинен зберігатися текст. У полі "Примітка" також передбачається зберігати текст. Ці два поля мають один тип. Назвемо їх текстовими полями.
Тільки тепер ми розглянемо таблицю, в якій, власне, і ведеться облік видачі книг. Так ми її й назвали «ОБЛІК ВИДАЧІ КНИГ».У першому наближенні дана таблиця мала такі поля: "Код", "Код читача", "Код бібліотекаря, який видав книгу", "Код інвентарного номера книги", "Дата видачі", "Дата повернення", "Фактична дата повернення", " Код бібліотекаря, який прийняв книгу». Однак, перше поле «Код» нам не потрібне, якщо дана інформація не використовуватиметься надалі в жодній таблиці. Але з метою розвитку системи його можна залишити «Код читача» має значення, що відповідає значенню поля «Код» у таблиці «ЧИТАЧІ», з того рядка, в якому міститься інформація про читача, який взяв книгу. Поле "Код книги" було замінено на "Код інвентарного номера книги". Це зроблено для того, щоб в окремій таблиці «Інвентарні номери книг» врахувати кількість книг, що знаходяться у фондах та на руках читачів. Поле «Фактична дата повернення» запроваджено для того, щоб визначити сумлінних читачів та виявити тих, хто не повертає книги у визначений термін.
Розглянемо таблицю «ІНВЕНТАРНІ НОМЕРИ КНИГ». Вона містить чотири поля: "Код", "Код книги", "Код фонду", "Інвентарний номер", "Вартість". Поле «Код книги» містить номер рядка з таблиці «КНИГИ», де прописана інформація про книгу, що має інвентарний номер (поле «Інвентарний номер») з певного фонду бібліотеки (Поле «Код фонду»). У полі «Ціна» вказано ціну книги, яку має відшкодувати читач у разі її втрати.
Залишилася остання таблиця «ТИПИ КНИЖКОВИХ ФОНДІВ», що має всього два поля: «Код» та «Найменування фонду». Наприклад, для бібліотеки ДДУ відомі два фонди: «НТБ» та «Студентський». Отже, якби дана база даних створювалася для обліку видачі книг у нашій бібліотеці, то в цій таблиці було б всього два записи:
Код Найменування типу фонду
На цьому створення логічної моделі бази даних для обліку видачі книг бібліотекою вважатимемо завершеною.
КОНТРОЛЬНІ ПИТАННЯ:
1. Що таке інформаційна система організації?
2. Які компоненти включає типова інформаційна система?
3. Перерахуйте відомі вам етапи життєвого циклу бази даних.
4. Чи є життєвого циклу програми бази даних суворо послідовними. Чому?
5. Що таке концептуальне проектування бази даних?
6. Що таке логічне проектування бази даних?
7. Чим відрізняється концептуальне проектування бази даних від логічного?
8. Який метод використовується для перевірки логічної моделі даних та що він гарантує?
9. Які два підходи до створення глобальної логічної моделі підприємства Вам відомі?
10. У чому полягає централізований підхід до створення глобальної логічної моделі даних підприємства, його характерна риса?
11. У чому полягає підхід до створення глобальної логічної моделі даних підприємства з урахуванням інтеграції уявлень, у чому його характерна риса?