Додаток

База даних "Продаж товарів" містить наступні таблиці

CLIENTS (CLIENT_ID, COMPANY, CUSTOMER__REP, CREDIT_LIMIT)

PRIMARY_KEY CLIENT_ID

FOREIGN KEY CUSTOMER__REP ДО ТАБЛИЦІ EMPLOYEE (EMP_ID)

EMPLOYEE (EMP_ID, NAME, AGE, REP_OFFICE, APPOINTMENT, HIRE_DATE, MANAGER_ID, PLAN, SALES)

primary_key EMP_ID

foreign key REP_OFFICE до таблиці OFFICES (OFFICE)

foreign key MANAGER_ID до таблиці employee (EMP_ID)

OFFICES (OFFICE, CITY, REGION, MANAGER, OFFICE__PLAN, OFFICE_SALES);

primary_key OFFICE

foreign key MANAGER до таблиці EMPLOYEE (EMP_ID)

PRODUCTS (MANUFACTURER_ID, PRODUCT_ID, DESCRIPTION, PRICE, QTY_ON_HAND);

primary_key MANUFACTURER_ID, PRODUCT_ID

ORDERS (ORDER_ID, ORDER_DATE, CUSTOMER, ЕМР, MANUFACTURER, PRODUCT, QUANTITY, COST);

primary_key clients;

foreign key CUSTOMER до таблиці clients(client_id);

foreign key MANUFACTURER до таблиці PRODUCTS (MANUFACTURER_ID);

Пояснення до бази даних "Продаж товарів".

□ CLIENTS (КЛІЄНТИ) — інформація про клієнтів, які купують товари компанії (CLIENT_ID (номер клієнта) — primary_key, company (юридична назва), CUSTOMER__REP (номер_продавця_клієнта) — foreign key до таблиці EMPLOYEE (emp_id), CREDIT_LIMIT (лиміт_кредиту))

□ employee (СЛУЖБОВЦІ) — інформація про службовців, що працюють в компанії і продають товари клієнтам (emp_id (номер_службовця) — primary_key, name (ПІБ_ службовця), age (вік), rep_office (номер_офису) — foreign key до таблиці offices (office), appointment (посада), hire_date (дата_найму), manager_id (номер_ менеджера) — foreign key до таблиці employee (emp_id), plan (план), sales (продажі));

□ offices (ОФІСИ) — офіси компанії, в яких працюють службовці (office (номер офису) — primary__key, city (місто), region (регіон), manager (номер_менеджеру) — foreign key до таблиці employee (emp_id), office__plan,(план_офісу), office_sAles (продажі_офісу));

□ products (ТОВАРИ) — інформація про товари, що продаються компанією (manufacturer_id (номер_виробника) — primary__key, product_id (номер_товару) — primary_key, description (опис), price (ціна), QTY_on_hANd (кількість на складі));

□ orders (ЗАМОВЛЕННЯ) — інформація про замовлення, зроблені клієнтом (order_id (номер_замовлення) — primary_key, order_date (дата_ замовлення), customer (клієнт) — foreign key до таблиці clients (client_id), емр (службовець) —

foreign key до таблиці employee (emp_id), manufacturer (виробник) — foreign key до таблиці products (manufacturer_id), product (товар) — foreign key до таблиці products (product_id), quantity (кількість), cost (вартість)).

2. [3, стр.411]

Мал. 1. Діаграма призначення привілеїв

3 [3, стр.413]

Мал. 2. Діаграма мал. 1 після видалення привілеїв користувача User 2

Приклад 4 [ ] Існує декілька тонких моментів, пов'язаних з процесами анулювання привілеїв, і для їх ілюстрації ми удамося до декількох абстрактних прикладів. Перш за все, якщо видаляється загальний привілей р, це не означає, що має бути відкликаний і призначений привілей, що є окремим випадком р. Розглянемо ситуацію, коли користувач U, що володіє відношенням R, спочатку призначає користувачеві V загальний привілей insert для R, а потім більш приватний привілей, insert (а), для того V відношення R.

Коли користувач U анулює привілей insert у V, привілей insert (а) залишається в силі. Діаграми призначення привілеїв після виконання операцій 2 і 3 показані на мал.3.

Зверніть увагу, що після операції 2 граф містить дві схожі, але окремі вершини, відповідні привілеям, отриманим користувачем V. Візьміть до відома і те, що опція restrict не перешкоджає анулюванню, оскільки користувач V не передавав отримані ним привілеї кому б то не було ще (втім, він і не зміг би цього зробити, оскільки отримав привілеї без права передачі).

Мал..3. Анулювання загального привілею не зачіпає приватний привілей

Приклад 5. Тепер розглянемо ситуацію, коли користувач U призначає користувачу V привілей р з правом його передачі, а потім анулює тільки це право, але не привілей як такий. В цьому випадку доведеться відобразити на діаграмі факт втрати права передачі, а також видалити дуги, які виходять з вершини V/p і ілюструють можливі операції передачі користувачем V привілею р якимнебудь іншим користувачам. Приблизна послідовність операцій може виглядати так, як показано в таблиці.

Операція 1 припускає призначення користувачем U користувачеві V привілею р з правом її передачі. Виконуючи операцію 2, користувач V передає привілей р користувачеві W. Відповідна діаграма призначення привілеїв приведена на мал. 8.29(a).

а) після операції 2 в) після операції 3

Мал..4. Анулювання права передачі не відміняє привілей

При виконанні операції 3 користувач U анулює право передачі привілею р користувачем V, але не відбирає сам привілей р. Символ зірочки, яким помічена вершина V/p, тепер необхідно вилучити. Вершина, не позначена таким символом (*), не може, виступати як джерело ("дарувальника") привілеїв, тому витікаючі з неї дуги (зокрема, дуга, зв'язуюча V/p з W/p) також мають бути видалені. Тепер до вершини W/p не можна "добратися" з вершини V/p, поміченої двома зірочками, тому W/p підлягає видаленню. Вершина V/p, проте, залишається на місці — правда, вже без зірочки, оскільки право передачі привілею анулюване. Підсумкова діаграма призначення привілеїв показана на мал. 8.4(b). Х

Вправа 5. Накресліть діаграми призначення привілеїв після виконання операцій 4—6 з таблиці, (передбачається, що користувач А є власником відношення, до якого відноситься привілей р).

Послідовність операцій до вправи 5

Вправа 6. Накресліть діаграми призначення привілеїв після виконання операцій 5, 6 з таблиці, показаної на мал. 8.31 (передбачається, що користувач А є власником відношення, до якого відноситься привілей р).

Мал. 8.31. Послідовність операцій до вправи 8.7.3

Вправа 7. Накресліть підсумкову діаграму призначення привілеїв після виконання операцій з таблиці, показаної нижче (передбачається, що користувач А є власником відношення, до якого відноситься привілей р).

Список літератури

1. Астахова И.Ф., Мельников В.М., Толстобров А.П., Фертиков В.В., СУБД: язык SQL в примерах и задачах. – М.: ФИЗМАТЛИТ, 2007. – 168 с.

2. Базы данных: модели, разработка, реализация / Т. С. Карпова. _ Спб.: Питер, 2001. – 304 с.

3. Гарсия-Молина Г., Ульман Д., Уидом Д. Системы баз данных. Полный курс.: пер. с англ. – М.: Издательский дом «Вильямс», 2003. – 1088 с.

4. Гайна Г.А. Основи проектування баз даних: Навчальний посібник. –К.:Кондор, 2008. 200 с.

5. Дейт К. Введение в системы баз данных, 6е издание: Пер.с англ. – К.; М.; СПб.: Издательский дом «Вильямс», 1999. – 848с.

6. Коннолли Т., Бегг К., Страчан А. Базы данных: проектирование, реализация, сопровождение. Теория и практика, 2е изд.: Пер. с англ.: Уч. Пос. М.; СПб.: Издательский дом «Вильямс», 2000. – 1120с.

7. Марков А.С., Лисовских К.Ю. Базы данных. Введение в теорию и методологию: Учебник. М.: Финансы и статистика, 2004. – 512 с.

8. Рудикова Л.В. Базы данных. Разработка приложений. – СПб.:БХВПетербург,2006. – 496 с.

9. Советов Б.Я. Базы данных: Теория и практика: Учебник для вузов/ Б.Я. Советов, В.В. Цехановский, В.Д. Чертовской. – М.: Высш. шк., 2005. – 463 с.

10. Хансен Г., Хансен Д. Базы данных: разработка и управление; Пер. с англ. – М.: ЗАО «Издательство БИНОМ», 1999. – 704с.

11. Хомоненко А.Д., Цыганков В.М., Мальцев М.Г. Базы данных: Учебник для высших учебных заведений. Под редакцией проф. А.Д Хомоненко. – Издание второе, дополненное и переработанное – СПб.: КОРОНА принт, 2002. – 672 с.

Частина V. Завдання до самостійної роботи

Поиск по сайту: