Бази даних та їх порівняльні характеристики

Рис. 2.
1 2 3 4 5 6 7 1 2 3 4 5 6 7 1 2 3 пацієнта 4 5 6 7 8 9 10

Представлена

Перед Уважно

Для таблиць:

Наприклад,bsp;

CSL_ <ім'я модуля> _ <ім'я таблиці>.

Для стовпців:

<Псевдонім таблиці> _ <ім'я стовпця>.

Наприклад, як показано на рис.2. Реєстраційний номер пацієнта зберігатися в полі PT_REG_NUMBER, таблиці PATIENTS, що має псевдонім PT.

Звичайно, використання цих не хитрих правил не є обов'язковим, але дозволяє значно полегшити читаність розробленої інформаційної структуру. Припустіть, як було б все, якби поля таблиць називалися P111, P112 і т.п., а адже такі речі зустрічаються практично дуже часто, наприклад в FoxPro 2.6.

Перейдемо до розгляду питань стандартизації та забезпечення посилальної цілісності реляційних таблиць.

Перетворення відносин

Поля таблиць можуть перебувати між собою в одному з наступних відносин:

один-до-одного, один-до-багатьох, багато-до-багатьох і рекурсивних, визначення яких наведені в табл.1. Розглянемо перетворення відносин на прикладі АІС "ДОКТОР-ПАЦІЄНТ" (рис.2).

Ставлення один-до-одного являє собою таке ставлення, при якому кожного запису в таблиці А відповідає єдиний запис у таблиці В (рис.1). Застосування такого типу відносин зустрічається вкрай рідко і призначене в основному для функціонального поділу інформації на кілька таблиць, тобто коли не хочуть, щоб таблиця БД "розпухає" від другорядної інформації. На рис.10 представлено, як використовуючи відношення один-до-одного таблиця PATIENTS перетворена в дві таблиці: PATIENTS_REG і PATIENTS_KART (на малюнку показані тільки основні атрибути таблиць). Також необхідно брати до уваги, що БД використовують такі відносини не можуть бути повністю нормалізовані.

Рис.1. Відношення один до одному.

Ставлення один-ко-многим можна без перебільшення назвати основним типом відносин що використовується при проектуванні сучасних БД, так як дозволяє представляти ієрархічні структури даних. Під даним відношення розуміється таке ставлення, коли одного запису в батьківській таблиці відповідають записи в дочірній таблиці (причому число відповідних записів виражається рядом натуральних чисел 0,1,2,: N і т.п.) (рис.2). Відносини один-ко-многим можуть бути жорсткими і нежорсткими. Для жорстких відносин повинно виконувати вимогу, що кожного запису в батьківській таблиці повинна від...повідати хоча б один запис у дочірньої таблиці.

Рис.2. Ставлення один до багатьом.

Ставлення багато-до-багатьох являє собою відношення при якому записам батьківської таблиці відповідають записи дочірньої таблиці, а ряду записів дочірньої таблиці відповідають записи в батьківській таблиці (рис.13). Використання такого типу відносин вкрай обмежена, не тільки через те, що деякі БД його взагалі не підтримують на рівні індексів і посилальної цілісності, але й тому, що практично будь-яке відношення багато-до-багатьох може бути замінене одним або більше ставленням один-до-багатьох (подивіться на приклад на рис.3. й так не коли не робіть).

Рис.3. Ставлення багато до багатьом.

Іншим важливим типом відносин - є рекурсивне відношення, тобто таке ставлення яке описує зв'язки між записами всередині однієї таблиці БД, тобто воно пов'язує об'єктне безліч з ним самим. Приклад рекурсивних відносин показаний на рис.4., який ілюструє, що доктора Петров А.А. і Васін М.М. знаходяться в залежності від доктора Сидорова В.М.. В залежності від функціонального призначення цього відношення воно може ілюструвати, наприклад, що вони є пацієнтами доктора Сидорова В.М., чи Сидорова В.М. є по відношенню до них начальником і т.п. Даний тип відносин дозволять реалізувати деревоподібну структуру функціональних відносин, наприклад, структуру організації.

Рис.4. Ставлення багато до багатьом.

Враховуючи вимоги посилальної цілісності і нормалізації на основі застосування розглянутих вище типів відносин здійснюється перетворення функціональної моделі бізнес - процесів і реаляціонную модель. Підсумком етапу є діаграма "Сутність-зв'язок" (часто звана CASE діаграма, ER-діаграама, рис.2).

Результатом першого етапу проектування АІС є функціональна модель системи містить безліч об'єктів (процесів, операцій), їх атрибутів.

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

Перетворення відносин

Поля таблиць можуть перебувати між собою в обном з наступних відносин: один-до-одного, один-до-багатьох, багато-до-багатьох і рекурсивних, визначення яких представлені в табл.1. Перш ніж розглянути реалізацію та перетворення відносин більш докладно, обговоримо Риторична питання про правила іменування таблиць і стовпців. Як ми вже раніше відзначали, що практично будь-яка АІС має модульну структуру і соответствено, в кожен модель входить певне число таблиць. Нехай є модуль "Операційний День", умовно назвемо його OPDAY, тоді зручно, що всі таблиці даного модуля найменовано наступним образова OPDAY_CUSTOMERS (ТАБЛИЦЯ КЛІЄНТІВ), OPDAY_ACCOUNT (таблиця рахунків) та т.п. При Наменованіе стовпців таблиці бажано дотримуватися наступного підходу: <коротке найменування таблиці> _ <найменування стовпця>. Наприклад, для таблиці OPDAY_CUSTOMERS найменування стовпців зручно реалізувати таким чином CUST_NNN (порядковий номер запису), CUST_FIO (фио клієнта), CUST_ACCOUNT_NNN (посилання на таблицю рахунків) і т.п. Практично в кожній організації, що займається розробкою АІС існують свої норми до найменування модулів, таблиць, стовпців і об'єктів бази даних, однак загальні принципи під чому схожі з наведеними в даних прикладах. Тепер розглянемо основні принципи перетворення відносин:

Ставлення один-до-одного.

Розглянемо приклад установки відносин клієнтів і рахунків в АБС (див. рис.5).

Рис.5. Відношення один до одному.

Ставлення МАЄ ПОТОЧНИЙ РАХУНОК являє собою зв'язок один-до-одного. Це означає, що клієнт має не більше одного поточного рахунку і кожним поточним рахунком користується тільки один клієнт. Якщо ми вирішимо, що ключами є №-КЛІЄНТА для CUSTOMER (КЛІЄНТ) і №-ПОТОЧНОГО-РАХУНКУ для ACCOUNT_NUMBER (ПОТОЧНИЙ РАХУНОК), то ми отримаємо два реляційні таблиці, кожна з яких складається з одного стовпця.

CUSTOMER (CUST_NNN)

ACCOUNT (ACCOUNT_NUMBER)

Для того щоб показати зв'язок між цими двома таблицями, ми повинні включити посилання на ACCOUNT_NUMBER в таблицю CUSTOMER і і посилання на СUST_NNN в таблицю ACCOUNT. Кожен з цих стовпців буде зовнішнім ключем, що вказує на іншу таблицю.

CUSTOMER (CUST_NNN, CUST_ACCOUNT_NUMBER)

Зовнішній ключ: CUST_ACCOUNT_NUMBER посилається на ACCOUNT_NUMBER.

ACCOUNT (ACCOUNT_NUMBER, ACCOUNT_CUST_NNN)

Зовнішній ключ: ACCOUNT_CUST_NNN посилається на CUST_NNN.

Резюме: відношення один-до-одного перетвориться шляхом приміщення одного з об'єктних множин в якості атрибута в таблиця другого об'єктного безлічі. Його вибір визначається потребами конкретного додатка. У багатьох випадках обидва варіанти прийнятні.

Ставлення один-ко-многим .

Припустимо, що ставлення МАЄ-ПОТОЧНИЙ-РАХУНОК має потужність "багато" з боку ACCOUNT.

Рис.6. Ставлення один до багатьом.

Це означає, що у клієнта може бути декілька поточних рахунків, але кожним поточним рахунком і раніше користується тільки один клієнт. Таким чином, в будь-якому відношенні один-до-багатьох в. таблицю, що описує об'єкт, потужність з боку якого дорівнює "багатьом", включається стовпець, який є зовнішнім ключем, що вказує на інший об'єкт.

Ставлення багато-до-багатьох.

Ставлення МАЄ-ПОТОЧНИЙ-РАХУНОК має потужність багато-до-багатьох.

база даних реляційний

Рис.7. Ставлення багато до багатьом.

Таким чином, ми припускаємо, що у клієнта може бути декілька поточних рахунків, і що кожним поточним рахунком можуть користуватися декілька клієнтів. Для того щоб перетворити відношення багато-до-багатьох доцільно створити таблицю перетину, що представляє елементи двох інших таблиць, що знаходяться в відношенні багато-до-багатьох.

Рекурсивні відносини

Рис.8. Рекурсивні відносини.

Об'єктне безліч WORKER (РОБОЧИЙ), двічі зустрічається на діаграмі, і це одне й те ж об'єктне безліч в обох випадках. Обидві копії об'єктного безлічі WORKER (РОБОЧИЙ) мають одні й ті ж атрибути. У цій моделі два примірники об'єктного безлічі WORKER (РОБОЧИЙ) використані для зручності, щоб показати відношення SUPERVISES (КОНТРОЛЮЄ), що існує між об'єктами WORKER (РОБОЧИЙ) і WORKER (РОБОЧИЙ). Це відношення називається рекурсивним, оскільки воно пов'язує об'єктне безліч з ним самим. В даному випадку відношення потужності один-ко-многим означає, що одному працівнику підкоряються кілька інших працівників.

WORKER (WORKER-ID, NAME, HOURLY-RATE, WORKER-ID)

Щоб перетворити об'єктне безліч WORKER разом з його атрибутами і ставленням SUPERVISES в реляційну таблицю потрібно змінити ім'я другого атрибута WORKER-ID на ім'я, відповідне відношенню SUPERVISES, яке воно представляє. SUPV-ID.

WORKER (WORKER-ID, NAME, HOURLY-RАТЕ, SUPV-ID)

Зовнішній ключ: SUPV-ID посилається на WORKER

SUPV-ID - Це рекурсивний зовнішній ключ, оскільки він посилається на WORKER-ID, тобто ключ своїй власній таблиці. Таким чином, в результаті перетворення рекурсивних відносин з'являються рекурсивні зовнішні ключі.

Функціональні залежності, визначені для реляційної моделі, є атрибутами відносини один-до-одного або один-ко-многим.

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

Мова - Засіб, за допомогою якого визначається структура даних або схема, а також відбувається запам'ятовування даних і маніпуляція ними. Мова, якою визначається схема, називається мовою визначення даних (МОД), а мову, використовуваний для запам'ятовування даних і маніпуляції ними, називається мовою маніпуляції даними (ЯМД).

Процедура застосування ЯОД і визначення схеми така:

1. Створюється концептуальна модель даних.

2. Концептуальна модель даних перетворюється в діаграму мережевої структури даних.

3. Перевіряється, чи існують між типами записів відносини один-до-багатьох. Вони можуть бути безпосередньо реалізовані у вигляді наборів DBTG.

4. Якщо є відносини потужності багато-до-багатьох, то кожне з них перетвориться в два набору шляхом створення запису зв'язку.

5. Якщо є n-арні відносини, то вони перетворяться в бінарні відношення.

6. Застосовується ЯОД для реалізації схеми.

Схема складається з наступних частин:

1. Розділ схеми. Розділ схеми DBTG, задаючий ім'я схеми.

2. Розділ записів. Розділ схеми DBTG, визначає кожний запис: її елементи даних і її адресу.

3. Розділ наборів. Розділ схеми DBTG, що визначає набори, включаючи типи записів власників і членів.

подсхеме - Це в основному, підмножини схеми. У подсхеме можуть бути згруповані елементи даних, які не були згруповані в схемі; записи і набори можуть бути перейменовані і порядок описів може бути змінений.

Прийнятого стандарту DBTG для подсхеми не існує, а проте, зазвичай використовуються такі відділи:

1. Відділ заголовка, що дозволяє присвоїти ім'я подсхеме і вказати пов'язану з нею схему.

2. Відділ перетворення, в якому при бажанні проводиться заміна імен з схеми на потрібні в подсхеме.

3. Структурний відділ, в якому задається, які записи, елементи даних і набори зі схеми повинні бути присутніми в подсхеме. Цей відділ складається з розділів записів і наборів.

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

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

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

Мова маніпуляції даними (ЯМД) забезпечує ефективні команди маніпуляції мережевою системою бази даних. ЯМД дозволяє користувачам виконувати над базою даних операції в метою отримання інформації, створення звітів, а також оновлення та зміни вмісту записів.

Основні команди ЯМД можна класифікувати таким чином: команди пересування, команди вилучення, команди поновлення записів, команди поновлення наборів.

Табл.2. Основні типи команд ЯМД.

Список літератури

1. Попов І.Г., Мамонов С.Г. Інформаційні системи. М.: Инфра, 2007.

2. Абросимов А.Г. Бородінова М.А. Теорія економічних інформаційних систем. Навчальний посібник - Самара. Вид-во Самарск.гос. екон. акад., 2007.

3. Інформаційні системи. Підручник/Петров В.Н. - СПб.: Питер, 2008.

4. Інформаційне забезпечення систем управління. Навчальний посібник/Голенищев Е.П., Клименко І.В. - Ростов н/Д: Фенікс, 2009.

5. Інтелектуальні інформаційні системи в економіці. Навчальний посібник/Тельнов Ю.Ф. Видання третє, розширене і доопрацьоване. Серія В«Економіка і бізнесВ». - Москва.: СІНТЕГ, 2009.