Система організації вуличних змагань . Курсова робота з Інші. Робота № 527500

Перехід до торгівельного партнера Binance

Система організації вуличних змагань

Інформація про навчальний заклад

ВУЗ:

Інші

Інститут:

Факультет:

Комп'ютерна інженерія

Кафедра:

Кафедра обчислювальної техніки

Інформація про роботу

Рік:

2015

Тип роботи:

Курсова робота

Предмет:

Інші

Завантажити

Частина тексту файла (без зображень, графіків і формул):

НАЦІОНАЛЬНИЙ ТЕХНІЧНИЙ УНІВЕРСИТЕТ УКРАЇНИ «КПІ» Кафедра Обчислювальної техніки КУРСОВА РОБОТА з «ПРОЕКТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ» на тему: «Система організації вуличних змагань «WorkOUT» » Студента 2 курсу групи ІО-32 напряму підготовки 6.050102 «Комп’ютерна інженерія» Попенко Руслан Леонідович Керівник Болдак Андрій Олександрович (прізвище та ініціали) Доцент кафедри ОТ (посада, вчене звання, науковий ступінь) Національна шкала_______________ Кількість балів: __________________Оцінка: ECTS ___________________ м. Київ - 2015 рік РОЗДІЛ 1 3 ЗАПИТИ ЗАЦІКАВЛЕНИХ ОСІБ 3 1.1. Введення 3 1.2. Короткий огляд продукту 3 1.4. Функціональність системи 6 1.5. Надійність. 7 РОЗДІЛ 2 8 РОЗРОБКА ІНФОРМАЦІЙНОГО ЗАБЕЗПЕЧЕННЯ 8 2.1. Загальна схема прецедентів 8 2.2. Прецеденти для ролі головного адміністратора 8 2.3. Діаграма бізнес-сутностей 16 2.4. Реляційна модель бази даних 16 2.5. Специфікація таблиць бази даних 17 РОЗДІЛ 3 23 РОЗРОБКА ПРОГРАМНОГО ПРОДУКТУ 23 3.1. Реляційно-об’єктне відображення 23 3.2. Специфікація Service класів 36 3.3. Специфікація DAO-класів 36 3.4. Класи контролерів та їх специфікація 37 РОЗДІЛ 4 38 ІЛЮСТРАЦІЯ РОБОТИ ПРОГРАМИ 38 4.1. Пошук співробітника та перегляд його дій в системі. 38 СПИСОК ІНФОРМАЦІЙНИХ ДЖЕРЕЛ 41 ДОДАТОК А 42 ДОДАТОК Б 43 ДОДАТОК В 58 ЗАПИТИ ЗАЦІКАВЛЕНИХ ОСІБ Введення У даному документі описуються запити зацікавлених осіб, у якості яких виступає: клієнт - правоохоронні органи України. Мета Метою документа є визначення основних вимог щодо функціональності та експлуатаційної придатності, а також визначення бізнес-правил та технологічних обмежень стосовно предмета розробки - «Системи збору та аналізу інформації». Контекст Перелік вимог, перерахованих у цьому документі, є основою технічного завдання на розробку «Системи збору та аналізу інформації». Короткий огляд продукту Правоохоронні органи - державні органи, які на підставі Конституції та законів України здійснюють правоохоронну діяльність. Діяльність правоохоронних органів спрямована на забезпечення законності і правопорядку, захист прав та інтересів громадян, попередження, припинення правопорушень, застосування державного примусу або заходів громадського впливу до осіб, які порушили закон і правопорядок. Ділові правила і приписи Призначення системи Система призначена для збору, зберігання і показу інформації про підозрюваних, злочинців та інших осіб, які тим чи іншим чином причетні до правоохоронних розглядів. Політика взаємодії з клієнтом Клієнтами системи можуть бути прокурори, слідчі, судді, криміналісти та інші співробітники правоохоронних органів України. Політика взаємин системи з клієнтом складається в наданні клієнту інформації про обличчя, які його цікавлять. Характеристика ділового процесу Управління системою і її контроль здійснюється головним та регіональними адміністраторами, які взаємодіють з керівництвом правоохоронних «органів.»»» Співробітники правоохоронних органів мають доступ до запису, зміни, читання або видалення інформації з системи відповідно до свого службового становища. Сценарій призначення / видалення регіонального адміністратора Назва: призначення / видалення регіонального адміністратора. Учасники: головний адміністратор, керівництво. Попередні умови: заявка від керівництва правоохоронних органів на призначення / видалення регіонального адміністратора. Результат: призначення / видалення регіонального адміністратора. Основний сценарій: 1. Головний адміністратор отримує заявку від керівництва правоохоронних органів на призначення / видалення регіонального адміністратора. 2. Головний адміністратор призначає / видаляє регіонального адміністратора. Сценарій реєстрації користувача Назва: Реєстрація користувача. Учасники: головний адміністратор, користувач, керівництво правоохоронних органів. Попередні умови: заявка від керівництва правоохоронних органів на реєстрацію нового користувача в системі. Результат: реєстрація користувача. Основний сценарій: 1. Головний адміністратор / регіональний адміністратор отримує заявку від керівництва правоохоронних органів на реєстрацію користувача в системі. 2. Головний адміністратор реєструє користувача. Сценарій видалення користувача Назва: Видалення користувача. Учасники: головний адміністратор, користувач. Попередні умови: заявка від керівництва правоохоронних органів на видалення користувача. Результат: видалення користувача. Основний сценарій: 1. Головний адміністратор отримує заявку від керівництва правоохоронних органів на видалення користувача; 2. Головний адміністратор видаляє користувача. Сценарій створення / видалення групи Назва: Створення / видалення групи. Учасники: головний адміністратор, група користувачів. Попередні умови: заявка від керівництва правоохоронних органів на створення / видалення групи. Результат: створення / видалення групи. Основний сценарій: 1. Головний адміністратор отримує заявку від керівництва правоохоронних органів на створення / видалення групи. 2. Головний адміністратор створює / видаляє групу. 3. У разі створення групи, головний адміністратор призначає права доступу для групи. Сценарій додавання користувача в групу (видалення користувача з групи Назва: Додавання користувача в групу (видалення користувача з групи). Учасники: головний адміністратор, користувач. Попередні умови: заявка від керівництва про додавання користувача в групу (видалення користувача з групи). Результат: додавання користувача в групу (видалення користувача з групи). Основний сценарій: 1. Головний адміністратор отримує заявку від керівництва про додавання користувача в групу (видалення користувача з групи). 2. Головний адміністратор додає користувача в групу (видаляє користувача з групи). Сценарій тимчасового розширення / отримання прав доступу до даних Назва: тимчасове розширення / отримання прав доступу до даних. Учасники: начальство, головний адміністратор; Попередні умови: потрібне залучення нових співробітників у рамках даного правоохоронного розгляду з видачею часткового / повного доступу до даних. Результат: розширення / отримання прав доступу співробітника / групи співробітників. Основний сценарій: 1. Звернення начальства до головного адміністратора з метою розширення / видачі прав доступу до даних співробітнику / групі співробітників. 2. Головний адміністратор розширює / видає права доступу співробітнику / групі співробітників. Функціональність системи Основні вимоги до функціональності, пропоновані зацікавленими особами до предмета розробки, відносяться до трьох категоріях: • Головний адміністратор. • Регіональний адміністратор. • Співробітник правоохоронних органів. Можливості головного адміністратора: • реєстрація та видалення користувачів в системі; • створення і видалення груп користувачів із системи; • призначення групам користувачів прав доступу до даних; • призначення та зміну прав груп у системі; • запис, зміна та видалення даних у системі. Можливості регіонального адміністратора: • створення та видалення груп користувачів; • реєстрація та видалення користувачів в системі; • призначення групам користувачів прав доступу до даних. Можливості співробітника правоохоронних органів • реєстрація в системі нового досьє; • запис, зміна та редагування даних в системі (можливість або неможливість даних дій для даного користувача залежить від групи, до якої він належить); • звернення до начальства про тимчасове / перманентне розширення прав доступу до даних. Можливості начальства, як окремої групи співробітників • звернення до головного / регіонального адміністратора з проханням зареєструвати нового / видалити користувача в системі; • звернення до головного / регіонального адміністратора з проханням видати права новому співробітнику або розширити права зареєстрованого в системі співробітника правоохоронних органів. Надійність. Резервне копіювання і відновлення даних. Має здійснюватися резервне копіювання баз даних. Реєстрація дій користувачів в системі. В цілях безпеки та для забезпечення контролю використання даних і внесень змін, дії всіх користувачів в системі реєструються. РОЗРОБКА ІНФОРМАЦІЙНОГО ЗАБЕЗПЕЧЕННЯ Загальна схема прецедентів Загальна схема прецедентів для ролі головного адміністратора показує можливі послідовності дій актора. Основним видом діяльності головного адміністратора є створення, видалення та редагування груп користувачів. Також головний адміністратор може здійснювати пошук серед окремих користувачів та переглядати історію дій кожного користувача. Схема прецедентів представлена на рис. 2.1. / Рис. 2.1 – Загальна схема прецедентів для ролі головного адміністратора Прецеденти для ролі головного адміністратора Нижче описані процедури для ролі користувача з вказаними передумовами, результатом, виключними ситуаціями та детальним описом послідовності дій. Перецент №1. Призначення/видалення регіонального адміністратора. Назва: призначення / видалення регіонального адміністратора. Учасники: Головний адміністратор, система. Передумови: Головний адміністратор отримав заявку від керівництва на призначення / видалення регіонального адміністратора. Результат: призначення / видалення регіонального адміністратора. Основний сценарій: 1. Головний адміністратор подає запит на призначення / видалення регіонального адміністратора. 2. Система реєструє видаляє регіонального адміністратора. 3. Система видає звіт про успішність операції. Виняткові ситуації: 1. Відсутність даного регіонального адміністратора в системі, при запиті його видалення. / Рис. 2.2 – Схема призначення / видалення регіонального адміністратора Прецедент №2. Видалення користувача. Назва: Видалення користувача. Учасники: головний адміністратор, система. Попередні умови: заявка від керівництва правоохоронних органів на видалення користувача. Результат: видалення користувача із системи. Основний сценарій: 1. Головний адміністратор отримує заявку від керівництва правоохоронних органів на видалення користувача. 2. Головний адміністратор, користувач подає запит на видалення користувача. 3. Система отримує запит, перевіряє права на виконання даної операції. 4. Система видаляє користувача. 5. Система повертає звіт про успішність операції. Виняткові ситуації: 1. Такого користувача не існує. 2. Не пройдена перевірка прав. / Рис. 2.3 – Схема видалення користувача Прецедент №3. Створення групи. Назва: Створення групи. Учасники: головний адміністратор, система. Попередні умови: заявка від керівництва правоохоронних органів на створення групи. Результат: створення групи. Основний сценарій: 1. Головний адміністратор отримує заявку від керівництва правоохоронних органів на створення групи. 2. Головний адміністратор подає запит на реєстрацію групи користувачів. 3. Система отримує запит, перевіряє права на виконання даної операції. 4. Система надає форму для заповнення інформації про нову групу користувачів. 5. Головний адміністратор заповнює інформацію про нову групу користувачів. 6. Головний адміністратор відправляє форму системі. 7. Система реєструє нову групу користувачів системи. 8. Система повертає звіт про успішність операції. / Рис. 2.4 – Схема створення групи Прецедент №4. Видалення групи. Назва: Видалення групи. Учасники: головний адміністратор / регіональний адміністратор, система. Попередні умови: заявка від керівництва правоохоронних органів на Видалення групи. Результат: Видалення групи. Основний сценарій: 1. Головний / регіональний адміністратор отримує заявку від керівництва правоохоронних органів на видалення групи. 2. Головний / регіональний адміністратор подає запит на видалення групи користувачів. 3. Система отримує запит, перевіряє права на виконання даної операції. 4. Система видаляє групу користувачів. 5. Система повертає звіт про успішність операції. / Рис. 2.5 – Схема видалення групи Прецедент №5. Додавання користувача в групу. Назва: Додавання користувача в групу. Учасники: головний адміністратор / регіональний адміністратор, система. Попередні умови: заявка від керівництва про додавання користувача в групу. Результат: додавання користувача в групу. Основний сценарій: 1. Головний / регіональний адміністратор отримує заявку від керівництва про додавання користувача в групу. 2. Головний / регіональний адміністратор подає запит на додавання користувача в групу. 3. Система отримує запит, перевіряє права на виконання даної операції. 4. Система додає користувача в групу. 5. Система повертає звіт про успішність операції. / Рис. 2.6 – Схема додавання користувача в групу Прецедент №6. Видалення користувача з групи. Назва: Видалення користувача з групи. Учасники: головний адміністратор / регіональний адміністратор, система. Попередні умови: заявка від керівництва про видалення користувача з групи. Результат: видалення користувача з групи. Основний сценарій: 1. Головний / регіональний адміністратор подає запит на видалення користувача з групи. 2. Система отримує запит, перевіряє права на виконання даної операції. 3. Система видаляє користувача з групи. 4. Система повертає звіт про успішність операції. Виняткові ситуації: 1. Даний користувач не зареєстрована в системі. / Рис. 2.7 – Схема видалення користувача з групи Діаграма бізнес-сутностей Дана діаграма створюється на етапі бізнес моделювання. Вона відображає основні сутності та взаємозв’язки між ними. В даному випадку основними сутностями є Employee, Action, Artifact та Dossier, які взаємодіють між собою та включають у себе допоміжні бізнес-сутності. Діаграма бізнес-сутностей проекту зображена на рис. 2.8. / Рис. 2.8 – Діаграма бізнес-сутностей Реляційна модель бази даних Реляційна модель бази даних (рис 2.3) зображує структуру таблиць бази даних, взаємозв’язки між ними та поля кожної з таблиць. Наведена діаграма має багато схожого з діаграмою бізнес-сутностей. Кожній основній бізнес-сутності відповідає таблиця баз даних. Рис 2.9 – Реляційна модель Специфікація таблиць бази даних Специфікація таблиць бази даних включає в себе інформацію про назви колонок таблиці, їхній тип, інформацію про те, чи є ця колонка первинним ключем, чи поле може бути пустим, чи значення поля автоматично збільшується та коментар щодо призначення колонки. Таблиці зі специфікаціями наведені нижче. Таблиця 2.1 Таблиця artifacts Назва Тип даних Ключ Не пуста Авто-інкремент Опис Id Int Так Так Так Ідентифікатор артефакту Artifact_type_id int Ні Так Ні Ідентифікатор типу артефакту Таблиця 2.2 Таблиця groups Назва Тип даних Ключ Не пуста Авто-інкремент Опис Id INT Так Так Так Ідентифікатор групи Name VARCHAR Ні Так Ні Назва групи Таблиця 2.3 Таблиця artifact_types Назва Тип даних Ключ Не пуста Авто-інкремент Опис id INT Так Так Так Ідентифіактор типу артефакта name VARCHAR Ні Так Ні Назва артефакта group_id INT Ні Так Ні Ідентифіактор групи артефакта Таблиця 2.4 Таблиця fields Назва Тип даних Ключ Не пуста Авто-інкремент Опис id INT Так Так Так Ідентифіактор поля name VARCHAR Ні Так Ні Назва поля is_required TINYINT Ні Так Ні Чи обов’язкове поле artifact_type_id INT Ні Так Ні Ідентифіактор типу артефакта Таблиця 2.5 Таблиця field_values Назва Тип даних Ключ Не пуста Авто-інкремент Опис id INT Так Так Так Ідентифікатор значення поля artifact_id INT Ні Так Ні Ідентифікатор артефакту value VARCHAR Ні Так Ні Значення поля field_id INT Ні Так НІ Ідентифікатор поля Таблиця 2.6 Таблиця actions Назва Тип даних Ключ Не пуста Авто-інкремент Опис id INT Так Так Так Ідентифікатор дії action_type_id INT Ні Так Ні Ідентифікатор типу дії artifact_id INT Ні Так Ні Ідентифікатор артефакту dossier_id INT Ні Так Ні Ідентифікатор досьє employee_id INT Ні Так Ні Ідентифікатор співробітника date DATETIME Ні Так Ні Дата створення запису Таблиця 2.7 Таблиця artif_action_types Назва Тип даних Ключ Не пуста Авто-інкремент Опис id INT Так Так Так Ідентифікатор типу дії name VARCHAR Ні Так Ні Назва дії Таблиця 2.8 Таблиця dossiers Назва Тип даних Ключ Не пуста Авто-інкремент Опис id INT Так Так Так Ідентифікатор досьє Таблиця 2.9 Таблиця dossier_action_types Назва Тип даних Ключ Не пуста Авто-інкремент Опис id INT Так Так Так Ідентифікатор типу дії з досьє name VARCHAR Ні Так НІ Назва типу дії з досьє Таблиця 2.10 Таблиця dossiers_log Назва Тип даних Ключ Не пуста Авто-інкремент Опис id INT Так Так Так Ідентифікатор запису логу dossier_id INT Ні Так Ні Ідентифікатор досьє action_type INT Ні Так Ні Ідентифікатор типу дії employee_id INT Ні Так Ні Ідентифікатор співробітника date DATETIME Ні Так Ні Дата створення запису логу Таблиця 2.11 Таблиця employees Назва Тип даних Ключ Не пуста Авто-інкремент Опис id INT Так Так Так Ідентифікатор співробітника first_name VARCHAR Ні Так Ні Ім’я співробітника last_name VARCHAR Ні Так Ні Прізвище співробітника empl_group_id INT Ні Так Ні Ідентифікатор групи співробітника Таблиця 2.12 Таблиця login_data Назва Тип даних Ключ Не пуста Авто-інкремент Опис employee_id INT Ні Так Ні Ідентифікатор співробітника login VARCHAR Ні Так Ні Логін співробітника password VARCHAR Ні Так Ні Пароль співробітника Таблиця 2.13 Таблиця employee_group Назва Тип даних Ключ Не пуста Авто-інкремент Опис id INT Так Так Так Ідентифікатор групи співробітника name VARCHAR Ні Так Ні Назва групи співробітника Таблиця 2.14 Таблиця group_actions Назва Тип даних Ключ Не пуста Авто-інкремент Опис id INT Так Так Так Ідентифікатор дії групи співробітників name VARCHAR Ні Так Ні Назва дії групи співробітників class_name VARCHAR Ні Так Ні Url-адреса для дії групи співробітників Таблиця 2.15 Таблиця empl_groups_actions Назва Тип даних Ключ Не пуста Авто-інкремент Опис group_id INT Так Так Ні Ідентифікатор групи співробітників action_id INT Так Так Ні Ідентифікатор дії групи співробітників РОЗРОБКА ПРОГРАМНОГО ПРОДУКТУ Реляційно-об’єктне відображення Для реляційно-об’єктного відображення в програмі використовується бібліотека Hibernate. Вона надає можливість легко встановити зв’язок з будь-якою базою даних та створити відображення між об’єктно-орієнтованою моделлю та традиційною реляційною моделлю баз даних. На рис. 3.1 зображено діаграму Entity класів. Детальна специфікація (JavaDoc) наведена нижче. / Рис 3.1 – Діаграма entity класів Клас «» / Клас «ArtifActionType» Клас «Dossier» / Клас «Employee» Клас «EmployeeGroup» / / Клас «GroupActions» Клас «LoginData» Клас «Artifact» Клас «ArtifactType» Клас «Group» Клас «Field» Клас «FieldValue» Специфікація Service класів Класи, що тут представлені, містять service методи програми. В них закладена вся бізнес логіка роботи програми. Діаграму цих класів можна побачити на рис. 3.2. Детальна специфікація наведена в додатку В. Рис. 3.2 – Діаграма service класів Специфікація DAO-класів Класи, що тут представлені, містять методи для роботи з базою даних. Ці методи використовують бібліотеку Hibernate. Діаграму цих класів можна побачити на рис. 3.3. Детальна специфікація наведена в додатку В. Рис 3.3 – Діаграма DAO класів Класи контролерів та їх специфікація Дані класи призначені для створення зв’язку між сервером та клієнтом. Діаграму цих класів можна побачити на рис. 3.4. Детальна специфікація наведена в додатку В. Рис. 3.4 – Діаграма класів контролерів ІЛЮСТРАЦІЯ РОБОТИ ПРОГРАМИ Для ілюстрації роботи програми в цьому розділі наведено графічні сценарії роботи проекту. Пошук співробітника та перегляд його дій в системі. При заході на сайт без попередньої авторизації, система видає користувачеві форму для введення логіну та паролю. Користувач заповнює поля та натискає кнопку Війти. Після авторизації система показує користувачу сторінку зі списком дозволених користувачеві дій. Користувач обирає необхідну й натискає на неї. Кожна дія має свою власну сторінку. В даному випадку, після вибору дії «Пошук співробітників» користувач потрапляє на сторінку з формою. В цій формі користувач вводить дані, по яким бажає провести пошук. Далі користувач повинен натиснути кнопку Шукати. Далі користувач потрапляє на сторінку з результатами пошуку. Тут відображається список знайдених співробітників, відповідно до введених вище даних. Кожен елемент цього списку є посиланням на сторінку співробітника. Користувач обирає необхідне посилання й натискає на нього. На сторінці співробітника відображається список дій, які зробив співробітник в системі. / СПИСОК ІНФОРМАЦІЙНИХ ДЖЕРЕЛ Apache Tomcat. – Посилання: http://tomcat.apache.org Hibernate. – Посилання: http://hibernate.org Maven. – Посилання: https://maven.apache.org Git. – Посилання: http://git-scm.com GitHub. – Посилання: https://github.com ДОДАТОК А Діаграма класів ДОДАТОК Б SQL код для створення таблиць бази даних: CREATE SCHEMA IF NOT EXISTS `informationdb` DEFAULT CHARACTER SET utf8 ; DROP SCHEMA IF EXISTS `test_informationdb` ; CREATE SCHEMA IF NOT EXISTS `test_informationdb` DEFAULT CHARACTER SET utf8 ; USE `informationdb` ; DROP TABLE IF EXISTS `informationdb`.`artif_action_types` ; CREATE TABLE IF NOT EXISTS `informationdb`.`artif_action_types` ( `id` INT(11) NOT NULL AUTO_INCREMENT, `name` VARCHAR(45) NOT NULL, PRIMARY KEY (`id`)) ENGINE = InnoDB AUTO_INCREMENT = 4 DEFAULT CHARACTER SET = utf8; DROP TABLE IF EXISTS `informationdb`.`groups` ; CREATE TABLE IF NOT EXISTS `informationdb`.`groups` ( `id` INT(11) NOT NULL AUTO_INCREMENT, `name` VARCHAR(45) NOT NULL, PRIMARY KEY (`id`)) ENGINE = InnoDB DEFAULT CHARACTER SET = utf8; DROP TABLE IF EXISTS `informationdb`.`artifact_types` ; CREATE TABLE IF NOT EXISTS `informationdb`.`artifact_types` ( `id` INT(11) NOT NULL AUTO_INCREMENT, `name` VARCHAR(45) NOT NULL, `group_id` INT(11) NOT NULL, PRIMARY KEY (`id`), CONSTRAINT `group_id` FOREIGN KEY (`group_id`) REFERENCES `informationdb`.`groups` (`id`) ON DELETE NO ACTION ON UPDATE NO ACTION) ENGINE = InnoDB DEFAULT CHARACTER SET = utf8; CREATE INDEX `group_id_idx` ON `informationdb`.`artifact_types` (`group_id` ASC); DROP TABLE IF EXISTS `informationdb`.`artifacts` ; CREATE TABLE IF NOT EXISTS `informationdb`.`artifacts` ( `id` INT(11) NOT NULL AUTO_INCREMENT, `artifact_type_id` INT(11) NOT NULL, PRIMARY KEY (`id`), CONSTRAINT `artifact_to_type` FOREIGN KEY (`artifact_type_id`) REFERENCES `informationdb`.`artifact_types` (`id`) ON DELETE NO ACTION ON UPDATE NO ACTION) ENGINE = InnoDB DEFAULT CHARACTER SET = utf8; CREATE INDEX `artifact_to_type_idx` ON `informationdb`.`artifacts` (`artifact_type_id` ASC); DROP TABLE IF EXISTS `informationdb`.`dossiers` ; CREATE TABLE IF NOT EXISTS `informationdb`.`dossiers` ( `id` INT(11) NOT NULL AUTO_INCREMENT, PRIMARY KEY (`id`)) ENGINE = InnoDB DEFAULT CHARACTER SET = utf8; DROP TABLE IF EXISTS `informationdb`.`employee_group` ; CREATE TABLE IF NOT EXISTS `informationdb`.`employee_group` ( `id` INT NOT NULL AUTO_INCREMENT, `name` VARCHAR(45) NOT NULL, PRIMARY KEY (`id`)) ENGINE = InnoDB DROP TABLE IF EXISTS `informationdb`.`employees` ; CREATE TABLE IF NOT EXISTS `informationdb`.`employees` ( `id` INT(11) NOT NULL AUTO_INCREMENT, `first_name` VARCHAR(45) NOT NULL, `last_name` VARCHAR(45) NOT NULL, `empl_group_id` INT NOT NULL, PRIMARY KEY (`id`), CONSTRAINT `to_empl_type` FOREIGN KEY (`empl_group_id`) REFERENCES `informationdb`.`employee_group` (`id`) ON DELETE NO ACTION ON UPDATE NO ACTION) ENGINE = InnoDB DEFAULT CHARACTER SET = utf8; CREATE INDEX `to_empl_type_idx` ON `informationdb`.`employees` (`empl_group_id` ASC); DROP TABLE IF EXISTS `informationdb`.`actions` ; CREATE TABLE IF NOT EXISTS `informationdb`.`actions` ( `action_type_id` INT(11) NOT NULL, `artifact_id` INT(11) NOT NULL, `dossier_id` INT(11) NOT NULL, `employee_id` INT(11) NOT NULL, `date` DATETIME NOT NULL, `id` INT NOT NULL AUTO_INCREMENT, PRIMARY KEY (`id`), CONSTRAINT `to_action_type_id` FOREIGN KEY (`action_type_id`) REFERENCES `informationdb`.`artif_action_types` (`id`) ON DELETE NO ACTION ON UPDATE NO ACTION, CONSTRAINT `to_artifact_id` FOREIGN KEY (`artifact_id`) REFERENCES `informationdb`.`artifacts` (`id`) ON DELETE NO ACTION ON UPDATE NO ACTION, CONSTRAINT `to_dossier_id` FOREIGN KEY (`dossier_id`) REFERENCES `informationdb`.`dossiers` (`id`) ON DELETE NO ACTION ON UPDATE NO ACTION, CONSTRAINT `to_employee_id` FOREIGN KEY (`employee_id`) REFERENCES `informationdb`.`employees` (`id`) ON DELETE NO ACTION ON UPDATE NO ACTION) ENGINE = InnoDB DEFAULT CHARACTER SET = utf8; CREATE INDEX `action_type_id_idx` ON `informationdb`.`actions` (`action_type_id` ASC); CREATE INDEX `artifact_d_idx` ON `informationdb`.`actions` (`artifact_id` ASC); CREATE INDEX `dossier_id_idx` ON `informationdb`.`actions` (`dossier_id` ASC); CREATE INDEX `employee_id_idx` ON `informationdb`.`actions` (`employee_id` ASC); DROP TABLE IF EXISTS `informationdb`.`fields` ; CREATE TABLE IF NOT EXISTS `informationdb`.`fields` ( `id` INT(11) NOT NULL AUTO_INCREMENT, `name` VARCHAR(45) NOT NULL, `is_required` TINYINT(1) NOT NULL, `artifact_type_id` INT(11) NOT NULL, PRIMARY KEY (`id`), CONSTRAINT `artifact_type` FOREIGN KEY (`artifact_type_id`) REFERENCES `informationdb`.`artifact_types` (`id`) ON DELETE NO ACTION ON UPDATE NO ACTION) ENGINE = InnoDB DEFAULT CHARACTER SET = utf8; CREATE INDEX `artifact_type_idx` ON `informationdb`.`fields` (`artifact_type_id` ASC); DROP TABLE IF EXISTS `informationdb`.`field_values` ; CREATE TABLE IF NOT EXISTS `informationdb`.`field_values` ( `artifact_id` INT(11) NOT NULL, `value` VARCHAR(45) NOT NULL, `field_id` INT(11) NOT NULL, `id` INT NOT NULL AUTO_INCREMENT, PRIMARY KEY (`id`), CONSTRAINT `artifact_id` FOREIGN KEY (`artifact_id`) REFERENCES `informationdb`.`artifacts` (`id`) ON DELETE NO ACTION ON UPDATE NO ACTION, CONSTRAINT `field_id` FOREIGN KEY (`field_id`) REFERENCES `informationdb`.`fields` (`id`) ON DELETE NO ACTION ON UPDATE NO ACTION) ENGINE = InnoDB DEFAULT CHARACTER SET = utf8; CREATE INDEX `field_id_idx` ON `informationdb`.`field_values` (`field_id` ASC); CREATE INDEX `artifact_id_idx` ON `informationdb`.`field_values` (`artifact_id` ASC); DROP TABLE IF EXISTS `informationdb`.`group_actions` ; CREATE TABLE IF NOT EXISTS `informationdb`.`group_actions` ( `id` INT NOT NULL AUTO_INCREMENT, `name` VARCHAR(45) NOT NULL, `class_name` VARCHAR(45) NOT NULL, PRIMARY KEY (`id`)) ENGINE = InnoDB; DROP TABLE IF EXISTS `informationdb`.`empl_groups_actions` ; CREATE TABLE IF NOT EXISTS `informationdb`.`empl_groups_actions` ( `group_id` INT NOT NULL, `action_id` INT NOT NULL, PRIMARY KEY (`group_id`, `action_id`), CONSTRAINT `type_to_id` FOREIGN KEY (`action_id`) REFERENCES `informationdb`.`group_actions` (`id`) ON DELETE NO ACTION ON UPDATE NO ACTION, CONSTRAINT `to_type_id` FOREIGN KEY (`group_id`) REFERENCES `informationdb`.`employee_group` (`id`) ON DELETE NO ACTION ON UPDATE NO ACTION) ENGINE = InnoDB; CREATE INDEX `to_type_id_idx` ON `informationdb`.`empl_groups_actions` (`group_id` ASC); CREATE INDEX `type_to_id_idx` ON `informationdb`.`empl_groups_actions` (`action_id` ASC); DROP TABLE IF EXISTS `informationdb`.`login_data` ; CREATE TABLE IF NOT EXISTS `informationdb`.`login_data` ( `employee_id` INT NOT NULL, `login` VARCHAR(45) NOT NULL, `password` VARCHAR(45) NOT NULL, CONSTRAINT `to_employee`

Курсова робота Інші

ruslan_rules_924

15.12.2015 18:12-

Коментарі

Ви не можете залишити коментар. Для цього, будь ласка, або зареєструйтесь.

Ділись своїми роботами та отримуй миттєві бонуси!

Маєш корисні навчальні матеріали, які припадають пилом на твоєму комп'ютері? Розрахункові, лабораторні, практичні чи контрольні роботи — завантажуй їх прямо зараз і одразу отримуй бали на свій рахунок! Заархівуй всі файли в один .zip (до 100 МБ) або завантажуй кожен файл окремо. Внесок у спільноту – це легкий спосіб допомогти іншим та отримати додаткові можливості на сайті. Твої старі роботи можуть приносити тобі нові нагороди!

поділитись