Розробка бази данних діяльності магазину "Автозапчастин"
Курсовой проект - Компьютеры, программирование
Другие курсовые по предмету Компьютеры, программирование
ям і правилам підтримки цілосності 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 Атрибути до бази даних
№Найменування атрибутівТипРозмірДопустимість невизначених значень1cust_idЧисловий3NOT NULL2cust_nameТекстовий603phoneТекстовий604bankТекстовий605accountТекстовий206INNЧисловий87cust_addressТекстовий608worker_nameТекстовий609worker_phoneТекстовий1010emp_idЧисловий3NOT NULL11emp_nameТекстовий6012emp_addressТекстовий6013expeienceЧисловий214date_bothДатаАвто15languageТекстовий1516baseТекс