Поділитися через


Моделювання даних. проектування структури даних

Якщо у своїй програмі ви зберігаєте або переглядаєте дані, на етапі проектування велике значення має структура даних. Враховуйте не лише те, як дані використовуватимуться у одній окремій програмі або на певному екрані, але й те, як цими даними користуватимуться інші. Якщо ви пригадаєте, якими особами, завданнями, бізнес-процесами та цілями потрібно оперувати, вам буде легше визначити, які дані слід зберігати та як їх структурувати.

Порада

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

Давайте візьмемо за приклад звіт про витрати.

Приклад звіту про витрати.

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

Для зберігання даних такого типу в базі даних потрібно змоделювати структуру даних під час проектування бази даних.

Структура даних «один-до-багатьох» (1:N)

Цей тип структури даних було описано в попередньому прикладі. Головна частина звіту про видатки пов'язується з кількома позиціями прейскуранта. (Також можна розглянути цей зв'язок з точки зору позицій прейскуранта: багато позицій прейскуранта у одному звіті про витрати (N:1).)

Структура даних «багато до багатьох» (N:N)

Структура даних, у якій кілька елементів можуть бути пов’язані з кількома — це особливий тип. Він використовується для інцидентів, де багато записів можуть бути пов’язані із кількома наборами різних інших записів. Гарним прикладом може слугувати мережа ділових партнерів. Існує кілька бізнес-партнерів (клієнтів і постачальників), з якими ви працюєте, а ці ділові партнери, у свою чергу, працюють одразу із вами та кількома вашими колегами.

Кілька осіб, з’єднаних лініями.

Приклади моделювання даних

Існує кілька різновидів моделювання, які можуть використовуватися у системі. Розглянемо ж кілька прикладів.

Приклад 1: запит на затвердження вільного часу

Приклад структури даних для запиту на затвердження вільного часу.

У цьому простому прикладі ми бачимо два набори даних. Один з них — працівник, інший — запит на вільний час. Оскільки кожен працівник представлятиме кілька запитів, тут діє зв'язок «один-до-багатьох», де «один» — це працівник, а «багато» — це запити. Відомості про працівника і про запит на вільний час пов'язані, для чого номер працівника зберігається, як загальновживане поле (таке поле називають також ключ).

Приклад 2: затвердження придбання

Приклад структури даних для запиту на затвердження придбання.

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

Оскільки працівники можуть користуватися послугами різних постачальників, постачальники використовуються кількома працівниками, а кожен працівник працює з кількома постачальниками. Таким чином, зв'язок між працівниками і постачальниками — «багато-до-багатьох».

Приклад 3: звітування про витрати

Приклад структури даних для звітування про витрати.

Примітка

Розкажіть нам про свої уподобання щодо мови документації? Візьміть участь в короткому опитуванні. (зверніть увагу, що це опитування англійською мовою)

Проходження опитування займе близько семи хвилин. Персональні дані не збиратимуться (декларація про конфіденційність).