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

--PAGE_BREAK--Даний розділ присвячено проектуванню локальних ER-МОДЕЛЕЙ, які відповідають окремим функціям що автоматизуються. У розділ проводиться нормалізація локальних ER-моделей, розробляються специфікація обмежень і правил підтримки цілісності для локальных ER-моделей.


2.1Складання локальної ER-моделі
У даному підрозділі на основі описових моделей даних, отриманих на попередніх етапах проектування, для кожної функції, що автоматизується, будуються початкові концептуальні моделі 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модель.
<img width=«359» height=«217» src=«ref-1_1681071582-9554.coolpic» v:shapes="_x0000_i1025">

Рис. 3.1 Логічна схема зв’язків




<img width=«359» height=«207» src=«ref-1_1681081136-13272.coolpic» v:shapes="_x0000_i1026">

Рис. 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»; зв’язуються вони через зовнішній ключ. При заповненні полів бази даних існують такі правила.

1) Поля з назвами, заповнюються українськими або англійськими буквами. Перша буква прописна, інші – рядкові); можливі подвійні назви, розділені дефісом; багатослівні назви, розділені пробілами.

2) Адреса записується в такому форматі: країна, індекс, місто, вулиця, номер будинку, номер корпусу, номер квартири.

3) Ідентифікатори розпочинаються з числа 01 та збільшуються на одиницю.

4) Можливі роздільники – пробіли.

5) Дата записується у форматі: д/м/р.

6) Номера телефонів: +(код країни – код міста) номер телефону.

7) Якщо поле розпочинається з букви, то у випадку ім’я власного – перша літера прописна, в іншому – строкова.




РОЗДІЛ 6 ЗАПИТИ ДО БД
В даному пункті відпрацюємо деякі запити, які можуть бути розроблені користувачами бази даних. Складемо такі SQL-запити:

1)  Проста вибірка.

2)  Вибірка з умовою.

3)  Вибірка даних зі зв'язаних таблиць.

4)  Вибірка з використанням оператора (природного) з'єднання.

5)  Вибірка з використанням шаблона.
1.1) Вивести список робітників, відсортированих за розміром з/п.
<img border=«0» width=«412» height=«190» src=«ref-1_1681094408-23515.coolpic» v:shapes="_x0000_i1027">
1.2) Вивести список замовників підприємства
<img border=«0» width=«541» height=«147» src=«ref-1_1681117923-19059.coolpic» v:shapes="_x0000_i1028">




2.1) Вивести данні по проектам, за дострокове виконання яких замовник сплатить бонусний відсоток.
<img border=«0» width=«452» height=«129» src=«ref-1_1681136982-12581.coolpic» v:shapes="_x0000_i1029">
2.2) Вивести данні працівників, якім не більше 25 років.
<img border=«0» width=«413» height=«134» src=«ref-1_1681149563-11749.coolpic» v:shapes="_x0000_i1030">
3.1) Вивести список компаній, проекти яких знаходяться в розробці.
<img border=«0» width=«492» height=«132» src=«ref-1_1681161312-16296.coolpic» v:shapes="_x0000_i1031">
3.2) Вивести список працівників, які отримують з/п, вищу за середню.
<img border=«0» width=«563» height=«131» src=«ref-1_1681177608-15220.coolpic» v:shapes="_x0000_i1032">    продолжение
--PAGE_BREAK--