50406 (Розробка бази данних діяльності магазину "Автозапчастин"), страница 2

2016-07-30СтудИзба

Описание файла

Документ из архива "Розробка бази данних діяльності магазину "Автозапчастин"", который расположен в категории "". Всё это находится в предмете "информатика" из 1 семестр, которые можно найти в файловом архиве . Не смотря на прямую связь этого архива с , его также можно найти и в других разделах. Архив можно найти в разделе "курсовые/домашние работы", в предмете "информатика, программирование" в общих файлах.

Онлайн просмотр документа "50406"

Текст 2 страницы из документа "50406"

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

Свежие статьи
Популярно сейчас
Почему делать на заказ в разы дороже, чем купить готовую учебную работу на СтудИзбе? Наши учебные работы продаются каждый год, тогда как большинство заказов выполняются с нуля. Найдите подходящий учебный материал на СтудИзбе!
Ответы на популярные вопросы
Да! Наши авторы собирают и выкладывают те работы, которые сдаются в Вашем учебном заведении ежегодно и уже проверены преподавателями.
Да! У нас любой человек может выложить любую учебную работу и зарабатывать на её продажах! Но каждый учебный материал публикуется только после тщательной проверки администрацией.
Вернём деньги! А если быть более точными, то автору даётся немного времени на исправление, а если не исправит или выйдет время, то вернём деньги в полном объёме!
Нет! Мы не выполняем работы на заказ, однако Вы можете попросить что-то выложить в наших социальных сетях.
Добавляйте материалы
и зарабатывайте!
Продажи идут автоматически
4125
Авторов
на СтудИзбе
667
Средний доход
с одного платного файла
Обучение Подробнее