--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модель.
Рис. 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»; зв’язуються вони через зовнішній ключ. При заповненні полів бази даних існують такі правила.
1) Поля з назвами, заповнюються українськими або англійськими буквами. Перша буква прописна, інші – рядкові); можливі подвійні назви, розділені дефісом; багатослівні назви, розділені пробілами.
2) Адреса записується в такому форматі: країна, індекс, місто, вулиця, номер будинку, номер корпусу, номер квартири.
3) Ідентифікатори розпочинаються з числа 01 та збільшуються на одиницю.
4) Можливі роздільники – пробіли.
5) Дата записується у форматі: д/м/р.
6) Номера телефонів: +(код країни – код міста) номер телефону.
7) Якщо поле розпочинається з букви, то у випадку ім’я власного – перша літера прописна, в іншому – строкова.
РОЗДІЛ 6 ЗАПИТИ ДО БД
В даному пункті відпрацюємо деякі запити, які можуть бути розроблені користувачами бази даних. Складемо такі SQL-запити:
1) Проста вибірка.
2) Вибірка з умовою.
3) Вибірка даних зі зв'язаних таблиць.
4) Вибірка з використанням оператора (природного) з'єднання.
5) Вибірка з використанням шаблона.
1.1) Вивести список робітників, відсортированих за розміром з/п.
1.2) Вивести список замовників підприємства
2.1) Вивести данні по проектам, за дострокове виконання яких замовник сплатить бонусний відсоток.
2.2) Вивести данні працівників, якім не більше 25 років.
3.1) Вивести список компаній, проекти яких знаходяться в розробці.
3.2) Вивести список працівників, які отримують з/п, вищу за середню.
продолжение
--PAGE_BREAK--