Інформаційна система на допомогу консультанту з продажу побутової техніки (стр. 4 из 6)
Структура БД визначається покладеної в її основу моделлю даних. Існують різні моделі баз даних, наприклад реляційна модель, графова модель, мережева модель і інші. Найбільш розповсюдженої в даний час є реляційна модель даних.
При реляційному підході дані представляються у вигляді двовимірних таблиць – найбільш природному для людини. Розглянемо основні поняття реляційних баз даних.
Тип даних – це поняття має такий же зміст, як і в мовах програмування. Всі існуючі сучасні бази даних підтримують спеціальні типи даних, призначені для збереження даних цілого типу, дробового з крапкою, що плаває, символів і рядків, календарних дат.
Домен – це потенційна безліч значень простого типу даних, вона має подібність з підтипом даних у деяких мовах програмування. Домен визначається двома елементами – типом даних і логічним вираженням, що застосовується до даних. Якщо результат цього вираження дорівнює значенню «істина», то екземпляр даних належить домену[9].
Відношення – це двовимірна таблиця особливого виду, що складається з заголовка і тіла.
Заголовок – це фіксована безліч атрибутів, кожний з яких визначений на якомусь домені, причому між атрибутами і визначальними доменами існує взаємно однозначна відповідність.
Приведені вище поняття є теоретичними і використовуються при розробці мовних засобів і програмних систем реляційних СУБД. У повсякденній роботі замість них використовуються їхні неформальні еквіваленти:
· відношення – таблиця;
· атрибут – стовпчик або поле;
· кортеж – запис або рядок.
Таким чином, ступінь відношення – це число колонок у таблиці, а кардинальне число – кількість рядків.
Для даного відношення завжди існує набір атрибутів, що однозначно ідентифікують кортеж. Такий набір атрибутів називається ключем.
Ключ повинний задовольняти наступним вимогам:
• повинний бути унікальним;
• повинний бути мінімальним, тобто видалення будь-якого атрибута з ключа веде до порушення унікальності.
На практиці як первинний ключ часто застосовують спеціальний числовий атрибут – автоінкрементне поле, значення якого може генеруватися тригером або спеціальними засобами, визначеними в механізмі СУБД.
Засновник реляційного підходу Дейт установив, що реляційна модель складається з трьох частин:
• структурної;
• маніпуляційної;
• цілісної.
У структурній частині моделі фіксуються відношення, як єдина структура даних, використовувана в реляційної моделі
У маніпуляційній частині фіксуються два базових механізми маніпулювання реляційними базами – реляційна алгебра і реляційне числення.
Під цілісною частиною розуміють якийсь механізм забезпечення цілісності даних. Цілісна частина укладає в собі дві основних вимоги цілісності реляційних баз даних – цілісність сутностей і цілісність по посиланнях[4].
Вимога цілісності сутностей полягає в тому, що будь-який кортеж будь-якого відношення повинний бути відмінним від будь-якого іншого кортежу цього відношення, тобто іншими словами, будь-яке відношення повинне мати первинний ключ. Ця вимога повинна виконуватися, якщо виконуються базові властивості відносин.
Вимога цілісності по посиланнях полягає в тому, що для кожного значення зовнішнього ключа, що з'являється у відношенні, що посилається, у відношенні, на якому веде посилання, повинний найтися кортеж з таким же значенням первинного ключа, або значення зовнішнього ключа повинне бути невизначеним (тобто ні на що не вказувати).
Описані в даному пункті основні поняття не відносяться до якої-небудь конкретної реалізації бази даних, а є загальними для них усіх. Таким чином, ці поняття є основою визначеної загальної моделі, що називається реляційною моделлю даних.
На підставі моделі даних складемо словник даних. Словник даних – це система, в якій зберігаються відомості про об'єкти, їх атрибути, про значення і формати представлення даних. Опишемо призначення і властивості полів реляційної таблиці «товари».
– Найменування товару. Служить первинним ключем, по якому можна дістати доступ до будь-якого рядка таблиці. Тип даних – строковий (Character), довжина – 20 символів. Ширина поля – 20 символів. Можливі значення – назви товарів, що мають відношення до офісу.
– Ціна одиниці товару. Зберігає ціну певного виду товарів. Тип даних – грошовий (Currency) точністю до 2 знаків після коми. Ширина поля – 7 символів. Можливі значення обмежені шириною поля.
– Кількість одиниць товару. Зберігає число одиниць товару, що знаходяться в даний момент на складі. Тип даних – цілий (Integer). Ширина поля – 4 символи. Можливі значення обмежені шириною поля.
– Одиниця вимірювання. Зберігає назву одиниці вимірювання товару. Тип даних – строковий (Character), довжина – 15 символів. Ширина поля – 15 символів. Можливі значення – відповідно до першого поля таблиці.
– Дата надходження. Зберігає число, місяць і рік надходження товару. Тип даних – вираз дати (Date). Ширина поля – 8 символів. Можливі значення записуються у форматі: мм/дд/гггг, де мм – номер місяця (01..12), дд – день (01..31), гггг – номер року.
– Фірмавиробник. Зберігає назву фірми виробника товару. Тип даних – строковий (Character), довжина – 20 символів. Ширина поля – 20 символів. Можливі значення – різні’.
– Постачальник. Зберігає номер партії завозу товару. Тип даних – строковий (Character), довжина – 11 символів. Ширина поля – 11 символів. Можливі значення не обмежені.
При проектуванні реляційної бази даних необхідно вирішити питання про найбільш ефективну структуру даних. Основні цілі які при цьому наслідуються:
- забезпечення швидкого доступу до даних в таблицях
- виключення непотрібне повторення даних, яке може стати причиною помилки при вводі і нераціонального використання дискового простору
- забезпечення цілісність даних таким чином, щоб при зміні одних об’єктів автоматично відбувалися відповідні зміни в зв’язаних з ними об’єктами
Процес зменшення надлишковості інформації в базі даних називається нормалізацією. В теорії нормалізації баз даних розроблені досить формалізовані підходи до розбиття даних, які володіють складною структурою.
Теорія нормалізації оперує з п’ятьма нормальними формами таблиць. Ці форми призначені для зменшення надлишкової інформації від першої до п’ятої нормальної форми. Тому кожна наступна форма повинна задовольняти умовам попередньої і деяким додатковим умовам. При практичному проектуванні баз даних четверта і п’ята форми зазвичай не використовуються.
Перша нормальна форма таблиці
Таблиця в першій нормальній формі повинна задовольняти такі умови:
- Таблиця не повинна мати записи що повторюються
- В таблиці повинні бути відсутніми групи полів що повторюються
- Рядки повинні бути невпорядковані
- Стовпчики повинні бути не впорядковані
Для задоволення умови 1 кожна таблиця повинна мати унікальний індекс. Умова 2 поступає видалення груп що повторюються.
Друга нормальна форма таблиці
Про таблицю кажуть що вона знаходиться в другій нормальній формі, якщо:
· Вона задовольняє вимогам першої нормальної форми
· Любе не ключове поле однозначно ідентифікується повним набором ключових полів
З приведеного вище означення слідує, що поняття другої нормальної форми застосовуване тільки до таблиць, які мають складовий індекс.
Третя нормальна форма таблиці
Про таблицю кажуть, що вона знаходиться в третій нормальній формі, якщо вона задовольняє вимогам другої нормальної форми.
Жодне з не ключових полів таблиці не ідентифікується з допомогою іншого не ключового поля.
Зведення таблиці до третьої нормальної форми має на увазі розділення таблиці з ціллю розміщення в окрему таблицю (або декілька таблиць) стовпчиків, які не залежать від повного ключа. В результаті такого розбиття кожне з не ключових полів повинне стати незалежним від якого небуть іншого не ключового поля.
Структура бази містить 12 інформаційних об’єктів різних типів, що дає можливість відображати повну інформацію як про саму службу, так і про продукцію, яка реалізується.
Коди продукції та міститимуться в полі серійнийном в таблицях замовників та продукції;
Назва товару, що реалізується міститиметься в полі Товар, а ціна одиниці даного продукту (в гривнях) в полі ціна;
Назва підприємства чи установи, що виробляє продукцію міститься в полі Виробник таблиці замовників;
Кількість замовленої продукції(штук) відображена в полі кількпродаж;
Вище описані дані зручно вводяться та редагуються у відповідних формах. Крім того користувач може переглянути вже введені дані в загальному вигляді.
Середовище Microsoft Visual FoxPro 8.0 дає програмісту можливість виконувати поставлені завдання як самостійно, так і за допомогою великої кількості «помічників».
Дані в майбутню базу завантажуватимуться з 2 основних таблиць (Table1.dbf, Table2.dbf). Розглянемо структуру кожної з них.
Структура таблиці Table1.dbf
Як видно з структура таблиці Table1.dbf має вигляд:
| Ім’я поля | Тип даних | Ширина поля | Індекс | Знаків після коми | Значення поля |
| Товар | Character | 30 | + | Назва товару | |
| Виробник | Character | 20 | + | Фірма виробник техніки | |
| Параметри | Character | 10 | Розміри або параметри техніки | ||
| Номер | Numenic | 3 | + | Табельний номер | |
| Кільктовар | Numenic | 2 | + | 2 | Кількість товару |
| Ціна | Numenic | 7 | Ціна техніки | ||
| Закупці на | Numenic | 7 | 2 | Закупочна ціна техніки | |
| Дата завозу | 8 | + | Дата завозу товару |
Структура таблиці Table2.dbf