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

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 Атрибути до бази даних

• 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) Вивести список працівників, які отримують з/п, вищу за середню.
• 4.1) Вивести розміри річних окладів працівників.
• 4.2) Вивести данні найстаршого працівника.
• 5.1) Вивести список замовників, офіс яких розміщується в Харкові.
• 5.2) Вивести список працівників, у котрих базовою мовою програмування не є PHP.
• РОЗДІЛ 7
• РОЗРОБКА МЕХАНИЗМІВ ЗАХИСТУ ДАНИХ ВІД НЕСАНКЦІОНОВАНОГО ДОСТУПУ
• Захист даних від несанкціонованого доступу припускає введення засобів, що перешкоджають витягу й відновленню даних деякими користувачами. Основний засіб забезпечення цього різновиду захисту даних полягає в тому, що користувачеві надається доступ не до всієї БД, а лише до деяким, певним адміністратором БД, частини даних. При цьому звертання до будь-яких інших даних для зазначеного користувача стає неможливим.
• У деяких СУБД утримується додатковий засіб, що складається у визначенні для даних або груп даних замків керування доступом. Тоді звернутися до них зможуть лише ті користувачі, які знають ключі таємності, "відкриваючі" ці замки. Найпростіший варіант замка керування доступом - пароль.
• Ще одна можливість захисту даних від несанкціонованого доступу пов'язана з кодуванням даних при відновленні й декодуванні при витягах. При цьому процедури декодування повинні бути доступні не всім користувачам. Перераховані засоби захисту від несанкціонованого доступу звичайно сполучаються: наприклад, на звертання до процедури декодування накладає замок керування доступом.
• Крім цього, гарна продумана інформаційна політика безпеки разом з належним навчанням і тренуваннями поліпшать розуміння працівників про належну роботу з корпоративною бізнесом-інформацією. Політика класифікації даних допоможе здійснити належний контроль за розкриттям інформації. Без політики класифікації даних вся внутрішня інформація повинна розглядатися як конфіденційна, якщо не визначено інакше.
• Так чином, під час необмеженого допуску до бази даних можливі такі дії над нею:
• - читання існуючої інформації;
• - змінення існуючох данних;
• - добавка нових записів;
• - видалення полів із записами.
• Для захисту інформації від несанкціонованого доступу слід по-перше встановити політику компанії щодо захисту інформації з обмеженим доступом, провести з особовим складом компанії роз'яснювальну роботу щодо збереження даних для автонтифікації користувачів. Також слід розробити ранги доступу, при якому найвищі права надаються адміністратору БД та, наприклад, президенту компанії. Нижче - менеджерам, які вже будуть позбавлені деяких повноважень, ще нижче - рядові службовці, які можуть мати найнижчі права, а саме - перегляд деяких таблиць. Також, можливо примусово позбавити конкретного користувача деяких прав, або навпаки, надати їх.
• РОЗДІЛ 8
• ВИМОГИ ДО ТЕХНИЧНОГО ЗАБЕЗПЕЧЕННЯ
• Передбачається, що база даних буде працювати у режимі клієнт-серверного додатку. Це передбачає, що сама база даних буде знаходитися на сервері, а доступ до її ресурсів буде надходити з клієнтських комп'ютерів користувачів. В такому випадку, слід зазначити, що на сервері повинне бути досить потужне технічне забезпечення, бо йому буде потрібно оброблювати запити, а саме - проводити вибірку інформації з присутньої на необхідну до відповідності з отриманого запиту. Відповідно, вимоги до комп'ютерів користувачів бази даних менш вимогливі. Рекомендовані характеристики ПК наведені нижче:
• - AMD 2,0 GHz Athlon;
• - 256 Мбайта ОЗП;
• - 2,0 Гбайта зайвого місця на НЖМД;
• - мережна карта Ethernet 10/100.
• РОЗДІЛ 9 ІНСТРУКЦІЯ З ВИКОРИСТАННЯ БД
• 9.1 Виклик програми
• Розроблена база даних зберігається на сервері. Для того щоб користувач міг працювати з базою даних він повинен на своєму персональному ПК запустити утиліту SQLPLUSW.exe, яка входить до програмного комплексу Oracle. Після цього з'явиться вікно для вводу персональних даних
• Рис. 9.1 Вікно для входу до бази даних
• Після цього треба ввести ім'я, власний пароль та шлях до бази даних, які повинні бути видані адміністратором бази даних.
• 9.2 Екранні форми
• В попередньому пункті було надано вікно для входу в систему. Після того, як користувач введе необхідні данні, вікно може мати такий вигляд

• Рис. 9.2. Вікно для входу до бази даних після вводу даних
• Після цього, за умови правильно введеного паролю та шляху зв'язку до бази даних, з'являється основне вікно утиліти SQLPLUSW.exe, в якому користувач може вводити SQL-запити, які, при наявності відповідних прав у користувача, можуть бути оброблені. Основне вікно програми наведено нижче.
• Рис. 9.3 Основне вікно програми
• 9.3 Опис звітів
• Після написання в вікні програми запит на мові SQL можна отримати у разі правильного набору операторів звіт, який відповідає запиту. Набраний оператором ПК запит буде відправне до серверу. Сервер в свою чергу відпрацює запит та, у відповідності з останнім, відішле на комп'ютер користувача вибірку з бази даних у відповідності з запитом. Вибірка буде представлена у вигляді звіту та відобразиться у робочому вікні утиліти. Отриманий запит може бути отриманий оперативним шляхом, для того щоб переглянути якісь данні, а у разі потреби - збережені у виді текстового файлу. Сам запит та результат його роботи приведені нижче.
• Рис. 9.4 Основне вікно програми з запитом та звітом
• ВИСНОВОК
• На сьогоднішній день реляционные бази даних залишаються найпоширенішими, завдяки своїй простоті й наочності як у процесі створення так і на користувальницькому рівні.
• Основним достоїнством реляционных баз даних сумісність із самою популярною мовою запитів SQL. За допомогою єдиного запиту на цій мові можна з'єднати кілька таблиць у тимчасову таблицю й вирізати з її необхідні рядки й стовпці (селекція й проекція). Тому що таблична структура реляционной бази даних інтуїтивно зрозуміла користувачам, те й мова SQL є простим і легенею для вивчення. Реляционная модель має солідний теоретичний фундамент, на якому були засновані еволюція й реалізація реляционных баз даних. На хвилі популярності, викликаної успіхом реляционной моделі, SQL став основною мовою для реляционных баз даних.
• У процесі аналізу вищевикладеної інформації виявлені наступні недоліки розглянутої моделі баз даних:
• - тому що всі поля однієї таблиці повинні містити постійне число полів заздалегідь певних типів, доводиться створювати додаткові таблиці, що враховують індивідуальні особливості елементів, за допомогою зовнішніх ключів. Такий підхід сильно ускладнює створення скільки-небудь складних взаємозв'язків у базі даних;
• - висока трудомісткість маніпулювання інформацією й зміни зв'язків.
• СПИСОК ВИКОРИСТАНОЇ ЛІТЕРАТУРИ
• 1. Конноли Томас. Базы данных: проектирование, реализация и сопровождение. Теория и практика, 2-е изд.: Пер. с англ.: Уч. пос. - М.: Издательский дом "Вильямс", 2004. - 1120 с.
• 2. К. Дж. Дейт. Введение в системы баз данных, 6-е издание: Пер. с англ. - К.; М.; СПб.: Издательский дом "Вильямс", 2003. - 848 с.
• 3. Саймон А.Р. Стратегические технологи баз данных: менеджмент на 2005 год. Перевод с англ./ Под ред. и с предисл. М.Р. Когаловского. - М.:
• 4. ДСТУ 2874-05. Бази даних. Терміни та визначення. -- Київ: Держстандарт України, 2004. - 32 с.
• 5. ДСТУ 2940-94. Системи оброблення інформації. Керування процесами оброблення даних. Терміни та визначення. -- Київ: Держстандарт України, 2005. - 20 с.
• ДОДАТОК А
• Файли-скріпти
• --del.sql
• --скрипт для видалення таблиць
• prompt PL/SQL Developer import file
• prompt Created on вторник 22 Мая 2009 г. by alan
• set feedback off
• set define off
• prompt Удаление таблицы Postavshiki….
• drop table Postavshiki;
• prompt Удаление таблицы Detali...
• drop table Detali;
• prompt Удаление таблицы Zakazchik...
• drop table Zakazchik;
• prompt Удаление таблицы Postavshiki….
• drop table Postavshiki;
• prompt Удаление таблицы Detali...
• drop table Detali;
• prompt Удаление таблицы Zakazchik...
• drop table Zakazchik;
• prompt Удаление таблицы Postavshiki….
• drop table Postavshiki;
• prompt Удаление таблицы Detali...
• drop table Detali;
• prompt Удаление таблицы Zakazchik...
• drop table Zakazchik;
• --кінець
• --my_project.sql
• --скрипт для створення таблиць
• prompt PL/SQL Developer import file
• prompt Created on вторник 22 Мая 2009 г. by alan
• set feedback off
• set define off
• prompt Создаётся таблица Detali...
• CREATE TABLE Detali (
• kod_detali NUMBER(3) NOT NULL PRIMARY KEY,
• nazvanie VARCHAR(60),
• articul VARCHAR(20),
• primechanie VARCHAR(30),
• prompt Создаётся таблица Postavshiki...
• CREATE TABLE Postavshiki (
• kod_postavshika NUMBER(3) NOT NULL PRIMARY KEY,
• nazvanie VARCHAR(60),
• adress VARCHAR(20),
• telefon NUMBER(15),
• prompt Создаётся таблица Zakazchik...
• CREATE TABLE Zakazchik (
• proj_zakazchika NUMBER(3) NOT NULL PRIMARY KEY,
• trade_mark VARCHAR(30),
• dejatelnost VARCHAR(50),
• raspologenie VARCHAR(33),
• --кінець
• -add.sql
• --скрипт для додавання даних
• prompt PL/SQL Developer import file
• prompt Created on вторник 22 Мая 2009 г. by alan
• set feedback off
• set define off
• prompt Заполнение таблиц данными...
• insert into Detali values (01, Двигун', 'Імпортований', 'Присутній на складі' );
• insert into Postavshiki values (11, 'ХарківАвто', 'Пушкінська 91', '312-41-21' );
• insert into Zakazchik values (10, 'Helenvagen', 'Німеченна' );
• --кінець
• Размещено на Allbest.ru