Розробка бази данних діяльності магазину "Автозапчастин"
Курсовой проект - Компьютеры, программирование
Другие курсовые по предмету Компьютеры, программирование
товий1517aboutТекстовий6018salaryГрошовийАвто19proj_idЧисловий3NOT NULL20proj_startДатаАвто21proj_stopДатаАвто22chiefТекстовий6023costГрошовийАвто24bonus_allЧисловийАвто№Найменування атрибутівТипРозмірДопустимість невизначених значень25proj_nameТекстовий6026numЧисловийАвтоNOT NULL (Рахівник)27emp_stopДатаАвто28emp_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) Вивести список працівників, які отримують з/п, вищу за середню.
4.1) Вивести розміри річних окладів працівників.
4.2) Вивести данні найстаршого працівника.
5.1) Вивести список замовників, офіс яких розміщується в Харкові.
5.2) Вивести список працівників, у котрих базовою мовою програмування не є PHP.
РОЗДІЛ 7
РОЗРОБКА МЕХАНИЗМІВ ЗАХИСТУ ДАНИХ ВІД НЕСАНКЦІОНОВАНОГО ДОСТУПУ
Захист даних від несанкціонованого доступу припускає введення засобів, що перешкоджають витягу й відновленню даних деякими користувачами. Основний засіб забезпечення цього різновиду захисту даних полягає в тому, що користувачеві надається доступ не до всієї БД, а лише до деяким, певним адміністратором БД, частини даних. При цьому звертання до будь-яких інших даних для зазначеного користувача стає неможливим.
У деяких СУБД утримується додатковий засіб, що складається у визначенні для даних або груп даних замків керування доступом. Тоді звернутися до них зможуть лише ті користувачі, які знають ключі таємності, "відкриваючі" ці замки. Найпростіший варіант замка керування доступом - пароль.
Ще одна можливість захисту даних від несанкціонованого доступу повязана з кодуванням даних при відновленні й декодуванні при витягах. При цьому процедури декодування повинні бути доступні не всім користувачам. Перераховані засоби захисту від несанкціонованого доступу звичайно сполучаються: наприклад, на звертання до процедури декодування накладає замок керування доступом.
Крім цього, гарна продумана інформаційна політика безпеки разом з належним навчанням і тренуваннями поліпшать розуміння працівників про належну роботу з корпоративною бізнесом-інформацією. Політика класифікації даних допоможе здійснити належний контроль за розкриттям інформації. Без політики класифікації даних вся внутрішня інформація повинна розглядатися як конфіденційна, ?/p>