Моделювання та проектування баз даних в інформаційних системах. Частина 2, CASE-засоби (моделювання), Програмування, статті

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

ВАЖЛИВІСТЬ МОДЕЛЮВАННЯ ДАНИХ


Чому так важливо мати ефективні моделі даних? По-перше, ефективна модель даних здатна забезпечити більш високу продуктивність, особливо для систем оперативної обробки транзакцій (online transactional systems, OLTP). По-друге, ефективна модель даних гарантує створення добре документованої, масштабованої бази даних. Якщо знехтувати розробкою ефективної моделі даних, то вам доведеться помучитися, коли справа дійде до додавання в модель нових даних; в кінці кінців, постраждає ваша фізична база даних.


ПРОДУКТИВНІСТЬ


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


ДОСТУПНІСТЬ ДАНИХ


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


СТВОРЕННЯ МОДЕЛІ ДАНИХ


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


СУТНОСТІ


Сутності – це головні об’єкти, які використовуються в моделі даних. Сутність – це подання, або результат класифікації, окремого типу даних. Клієнти, замовлення, продаж, вироби – все це приклади сутностей. Логічно кожна сутність являє собою набір примірників певного типу даних. Примірник – це одне входження згаданого фрагмента даних. Щоб краще розібратися в цих поняттях, згадайте ставлення рядків до таблиць у фізичній базі даних: рядки належать до таблиць так само, як екземпляри до сутностей.


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


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


АТРИБУТИ


Атрибут – це дескриптор конкретного екземпляра по суті. Сутність зазвичай має декілька атрибутів. Припустимо, наприклад, що ми створили сутність з ім’ям ОшейнікДляСобак, що представляє нашийники для собак, які продає магазин товарів для тварин. Кожен нашийник має набір фізичних атрибутів (ознак): колір, довжина, ширина і т. п. Ці атрибути будуть атрибутами і для даної сутності: Колір, Довжина, Ширина, Торгова Марка і т. д. У процесі конструювання моделі даних для кожної сутності буде визначений набір атрибутів, що описують дані, які зберігає ця сутність.


З атрибутами пов’язана вельми специфічна проблема, яку необхідно вирішити – який саме сутності “належить” даний атрибут. Цю помилку роблять, в основному, при проектуванні програми (і його моделі даних / бази даних) на основі фізичного процесу (який в даний час не пов’язаний ні з яким додатком). У класичному прикладі з роздрібною торгівлею інформація про клієнта (номер телефону та адреса) часто зберігається разом з кожним записом, яку робить клієнт. При створенні моделі даних неважко помилково перетворити її в фізичну документацію (наприклад, у вигляді таблиці) безпосередньо в сутності. У прикладі з замовленнями сутність Замовлення може мати приєднані атрибути клієнта. З логічної точки зору це неправильно. Замовлення – це логічний фрагмент даних, або об’єкт, а клієнт – логічний об’єкт. Атрибути Номер Телефону та Адреса повинні асоціюватися з клієнтом, а не із замовленням.


Читати частина 3

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*