Розробка бази данних діяльності магазину "Автозапчастин" (стр. 3 из 4)
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 с.