WWW.REFERATCENTRAL.ORG.UA - Я ТУТ НАВЧАЮСЬ

... відкритий, безкоштовний архів рефератів, курсових, дипломних робіт

ГоловнаІнформатика, Компютерні науки → Розробка системи білінгу Інтернет та телефонних послуг - Пошукова робота

Розробка системи білінгу Інтернет та телефонних послуг - Пошукова робота

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

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

Правила нормалізації, подібно до принципів об'єктного моделювання, розвивалися в рамках теорії баз даних. Більшість розробників баз даних визнають, що представлення даних в третій і четвертій нормальних формах повністю задовольняє всі їх потреби.

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

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

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

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

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

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

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

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

3.1 Розробка структури БД тарифікатора

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

Таблиця Input містить вхідні дані для тарифікації, ключовий полів немає (таблиця 1).

Таблиця Output містить вихідні дані, що будуть заповнені модулем тарифікації, ключовий полів немає (таблиця 2).

Таблиця Local – це набір змінних для маніпулювання, таблиця ключових полів не має (таблиця 3).

Таблиця 1 – Структура таблиці Input

Поле

Тип

Розмір, байт

Пояснення

IN_Datetime

text

дата і час в форматі yymmddwhhmmss

IN_Abonent

text

абонент (номер внутрішньої лінії)

IN_Line

text

лінія (номер зовнішньої лінії)

IN_Number

text

номер, набраний абонентом

IN_ExtNumber

text

номер без спец. символів

IN_FieldU

text

зарезервоване поле, використовує-ться для визначення транка

IN_FieldV

text

зарезервоване поле

IN_FieldW

text

зарезервоване поле

IN_FieldX

text

зарезервоване поле

IN_FieldY

text

зарезервоване поле

IN_FieldZ

text

зарезервоване поле

Таблиця 2 – Структура таблиці Output

Поле

Тип

Розмір, байт

Пояснення

OUT_Dialtown

text

місто, куди був дзвінок

OUT_Dialdirection

text

напрямок, куди був дзвінок

OUT_Dialzone

text

географічна зона дзвінка

OUT_Timezone

text

часова зона дзвінка

OUT_Tariff

text

тариф за одиницю часу

OUT_Currency

text

валюта тарифікації

OUT_Course

text

курс валюти тарифікації до вихідної

OUT_Dialdelay

text

затримка часу при наборі номера

OUT_Timeminimum

text

часовий мінімум тарифікації

OUT_Timefree

text

максимальний безтарифний час

OUT_Timeround

text

округлення часу

OUT_Timegrid

text

часова сітка

OUT_Timeunit

text

одиниця часу

OUT_FieldU

text

зарезервоване поле

OUT_FieldV

text

зарезервоване поле

OUT_FieldW

text

зарезервоване поле

OUT_FieldX

text

зарезервоване поле

OUT_FieldY

text

зарезервоване поле

OUT_FieldZ

text

зарезервоване поле

Таблиця 3 – Структура таблиці Local

Поле

Тип

Розмір, байт

Пояснення

KindcallID

text

тип дзвінка

TariffmodelID

text

тарифна модель

TrunkID

text

транк

Numbermask

text

шаблон для видалення транка з номера

Keycode

text

ключ шифрування

DialzoneID

text

географічна зона дзвінка

TimezoneID

text

часова зона дзвінка

Currency

text

валюта тарифікації

TransferID

text

трасфер (пересилання дзвінка на іншого абонента)

Loading...

 
 

Цікаве