Розробка бази данних діяльності магазину "Автозапчастин" (стр. 2 из 4)
У даному підрозділі на основі описових моделей даних, отриманих на попередніх етапах проектування, для кожної функції, що автоматизується, будуються початкові концептуальні моделі Entity-relationship (ER-моделі) в графічній формі.
2.2 Нормалізація локальних ER-моделей
У даному підрозділі на основі аналізу та перетворення вихідних ER-моделей для кожної функції що автоматизується будуються нормалізовані ER-моделі, які не містять "прихованих" сутностей.
2.2.1 Функция 1 Облік працівників
Нормалізовану ER-модель для цієї функції, отримана на основі опису, наведеного в попередніх розділах, представлена на малюнку 2.2.1. Відомості про обмеження цілісності, наведені на цьому малюнку, пояснюються нижче в підрозділі 3.3, присвяченому обмеженням та правилам підтримки цілісності.
2.2.2 Функція 2 “ Облік кліентів ”
Нормалізовану ER-модель для цієї функції, отримано на основі опису, наведеного в попередніх розділах, представлена на малюнку 2.2.2. Відомості про обмеження цілісності, наведені на цьому малюнку, пояснюються нижче в підрозділі 2.3, присвяченому обмеженням і правилам підтримки цілосності 2.2.2 - нормалізована ER-модель для функції 2 "Надання інформації про діяльність кафедри".
2.2.2 Функція 3 “ Облік поставок ”
Нормалізовану ER-модель для цієї функції, отримано на основі опису, наведеного в попередніх розділах, представлена на малюнку 2.2.3. Відомості про обмеження цілісності, наведені на цьому малюнку, пояснюються нижче в підрозділі 2.3, присвяченому обмеженням і правилам підтримки цілосності 2.2.3 - нормалізована ER-модель для функції 2 " Облік поставок ".
2.3 Висновок
В результаті проектування локальних ER-моделей, відповідних окремим автоматизованим функціям, отримані нормалізовані локальні ER-моделі, що містять сутності в третій нормальній формі. Розроблені специфікації обмежень та правила підтримки цілісності, що містять усі обмеження та правила, отримані на попередньому етапі та трансформовані для локальних ER-моделей.
магазин база дані модель
РОЗДІЛ 3 ПРОЕКТУВАННЯ ГЛОБАЛЬНОЇ ER-МОДЕЛІ
Даний розділ присвячено проектуванню глобальної ER-моделі. В розділ виконується виявлення еквівалентних сутностей і їх злиття. Будується графічне уявлення глобальної моделі.
3.1 Виявлення та відхилення еквівалентних сутностей
В даному підрозділі були виявлені і усунені еквівалентні сутності.
3.2 Графічне уявлення глобальної ER-моделі
В даному підрозділі, в результаті виявленні еквівалентних сутностей та їх злиття, виявлення категорій і синтезу узагальнюючих сутностей, виявлення та усунення дублювання атрибутів, була розроблена глобальна ERмодель.
Рис. 3.1 Логічна схема зв’язків
Рис. 3.1 Фізична схема зв’язків
3.3 Класифікація зв'язків
Для побудови інфологічної моделі даних визначимо сутності їхнього зв'язку й атрибути.
Визначимо сутності:
1. поставщіки, які займаються постачанням;
2. замовники, котрі замовляють деталі;
3. деталі, які будуть продані замовнику;
Опишемо атрибути сутностей для кожної окремо:
- ПОСТАВЩІКИ (код постачальника, назва, адреса, телефон);
- ДЕТАЛІ (код деталі, назва, артикул примітка);
- ЗАМОВНИК (код замовника, торгова марка, діяльність, місце знаходження).
РОЗДІЛ 4 ПРОЕКТУВАННЯ РЕЛЯЦІЙНОЇ SQL-МОДЕЛІ
Даний розділ присвячений проектуванню реляційної SQL-модели. Тут виконується переклад глобальної ER-моделі в реляційну форму, специфікуються обмеження і правила підтримки цілісності на реляційному рівні, записується SQL-код для створення реляційної моделі.
4.1 Функціональні залежності між атрибутами
Наша база даних складається з трьох таблиць. Первинними серед них є DETALI. Вона заповнюються першими. У таблиці – DETALI – зберігаються данні про деталі. У другій – ZAKAZCHIK – зберігається інформація про замовників підприємства.У таблиці POSTAVSHIKI йдеться про причасність робітників магазину до продаваємих деталій. Ця таблиця залежить і від таблиці DETALI.
Установимо функціональні залежності між атрибутами.
ідентифікатор працівника → (ПІП, домашня адреса, досвіт роботи, рік народження, освіта, примітки, фото);
ідентифікатор замовника → (назва підприємства замовника, телефон, банк, номер рахунку в банку, код ЄДРОПУ, адреса, відповідальний за замовлення, телефон відповідального);
ідентифікатор замовника → ідентифікатор проекту (назва проекту, дата початку та кінця проекту, керівник, замовник проекту, вартість розробки та премія за дострокове виконання).
4.2 Вибір ключів
Постачальники (*ідентифікатор постачальника, домашня адреса, досвіт роботи, рік народження, освіта, примітки, фото); Поставка (*ідентифікатор поставки, назва поставки, дата початку та кінця поставки керівник, замовник поставки, вартість поставки); Деталі (*ідентифікатор деталі, назва деталі, артикул, вартість деталі, опис деталі).
4.3 Нормалізація відносин
Ті самі дані можуть групуватися в таблиці (відносини) різними способами, тобто можлива організація різних наборів відносин взаємозалежних інформаційних об'єктів. Угруповання атрибутів у відносинах повинна бути раціональної, тобто зменшуючи дублювання даних і процедури, що спрощує, їхньої обробки й відновлення.
Певний набір відносин має кращі властивості при включенні, модифікації, видаленні даних, чим всі інші можливі набори відносин, якщо він відповідає вимогам нормалізації відносин.
Нормалізація відносин - формальний апарат обмежень на формування відносин (таблиць), що дозволяє усунути дублювання, забезпечує несуперечність збережених у базі даних, зменшує трудозатрати на ведення (уведення, коректування) бази даних.
Поняття третьої нормальної форми ґрунтується на понятті нетранзитивної залежності. Транзитивна залежність спостерігається в тому випадку, якщо один із двох описових реквізитів залежить від ключа, а інший описовий реквізит залежить від першого описового реквізиту.
Відношення буде перебувати в третій нормальній формі, якщо воно перебуває в другій нормальній формі, і кожний не ключовий атрибут нетранзитивно залежить від первинного ключа.
Для усунення транзитивної залежності описових реквізитів необхідно провести "розщеплення" вихідного інформаційного об'єкта. У результаті розщеплення частина реквізитів віддаляється з вихідного інформаційного об'єкта й включається до складу інших (можливо, знову створених) інформаційних об'єктів.
РОЗДІЛ 5 ДАТОЛОГІЧНЕ ПРОЕКТУВАННЯ БД
5.1 Склад таблиць БД
Таблиця5.1 Атрибути до бази даних
| № | Найменування атрибутів | Тип | Розмір | Допустимість невизначених значень |
| 1 | cust_id | Числовий | 3 | NOT NULL |
| 2 | cust_name | Текстовий | 60 | |
| 3 | phone | Текстовий | 60 | |
| 4 | bank | Текстовий | 60 | |
| 5 | account | Текстовий | 20 | |
| 6 | INN | Числовий | 8 | |
| 7 | cust_address | Текстовий | 60 | |
| 8 | worker_name | Текстовий | 60 | |
| 9 | worker_phone | Текстовий | 10 | |
| 10 | emp_id | Числовий | 3 | NOT NULL |
| 11 | emp_name | Текстовий | 60 | |
| 12 | emp_address | Текстовий | 60 | |
| 13 | expeience | Числовий | 2 | |
| 14 | date_both | Дата | Авто | |
| 15 | language | Текстовий | 15 | |
| 16 | base | Текстовий | 15 | |
| 17 | about | Текстовий | 60 | |
| 18 | salary | Грошовий | Авто | |
| 19 | proj_id | Числовий | 3 | NOT NULL |
| 20 | proj_start | Дата | Авто | |
| 21 | proj_stop | Дата | Авто | |
| 22 | chief | Текстовий | 60 | |
| 23 | cost | Грошовий | Авто | |
| 24 | bonus_all | Числовий | Авто | |
| № | Найменування атрибутів | Тип | Розмір | Допустимість невизначених значень |
| 25 | proj_name | Текстовий | 60 | |
| 26 | num | Числовий | Авто | NOT NULL (Рахівник) |
| 27 | emp_stop | Дата | Авто | |
| 28 | emp_start | Дата | Авто |
5.2 Засоби підтримки цілісності
У даному підрозділі для значень атрибутів виявляються обмеження й правила на рівні атрибутів, обраних у попередньому розділі. У першу чергу шляхом аналізу окремих атрибутів визначаються характеристики доменів, з яких атрибути об'єктів, що беруть участь у виконанні автоматизуємих функцій, беруть свої значення. Далі аналізуються можливі змінення значень атрибутів з метою виявлення динамічних обмежень і операційних правил, що ставляться до окремих атрибутів.
Взагалі, у цілісній частині реляційної моделі даних фіксуються дві базових вимоги цілісності, які повинні підтримуватися в будь-який реляційної СУБД. Перша вимога називається вимогою цілісності сутностей. Об'єкту або сутності реального миру в реляційних БД відповідають кортежі відносин. Конкретна вимога полягає в тому, що будь-який кортеж будь-якого відношення відрізнимо від будь-якого іншого кортежу цього відношення, тобто інакше кажучи, будь-яке відношення повинне мати первинний ключ.
Друга вимога називається вимогою цілісності по посиланнях і є трохи більше складним. Очевидно, що при дотриманні нормалізованісті відносин складні сутності реального миру представляються в реляційної БД у вигляді декількох кортежів декількох відносин.
Так, первинним ключем у нас у таблиці «Postavshiki»є атрибут «cod_postavshika», ця таблиця є батьківською для дочірній таблиці «detali» з її первинним ключем «cod_detali»; зв’язуються вони через зовнішній ключ «cod_detali». У таблиці «zakazchiki» первинним ключем є атрибут «cod_zakazchika», звьяхується з таблицєю «Postavshiki» з її первинним ключем «cod_postavshika»; зв’язуються вони через зовнішній ключ. При заповненні полів бази даних існують такі правила.