Створення бази даних системи керування ресурсами

Размещено на http://allbest.ru

МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ

НАЦІОНАЛЬНИЙ АВІАЦІЙНИЙ УНІВЕРСИТЕТ

Інститут комп'ютерних інформаційних технологій

Кафедра інженерії програмного забезпечення

КУРСОВА РОБОТА

з дисципліни: «Бази даних»

Створення бази даних системи керування ресурсами

Виконав:

студент групи ПІ-316

Романченко Денис Сергійович

Керівник курсової роботи:

Доцент кафедри ПІ, к. ф.-м. н. Резніченко В.А.

Київ, 2014



Зміст

Вступ

1. Стратегія автоматизації предметної області

1.1 Загальні положення

1.2 Мета, цілі та задачі створення бази даних

1.3 Вимоги до інформаційного забезпечення

2. Аналіз предметної області

2.1 Загальні положення системного аналізу предметної області

2.2 Загальні положення керування ресурсами

2.3 Системний аналіз предметної області

2.4 Інформаційно-довідкові задачі

3. Моделювання предметної області

3.1 Теоретичні положення концептуального моделювання

3.2 Мова ER--моделювання ПЗ

3.3 Побудова концептуальної моделі керування ресурсами

4. Логічне та фізичне моделювання бази даних

4.1 Логічне проектування

4.2 Фізичне проектування

Висновки



Вступ

Метою курсової роботи є розробка бази даних предметної області, що відноситься до системи керування ресурсами, що необхідні підприємству для виконання проектів.

Завдання бази даних полягає в зберіганні всіх важливих даних в одному або декількох місцях, причому таким способом, який свідомо виключає непотрібну надлишковість. У добре спроектованої базі даних надмірність даних виключається, і ймовірність збереження суперечливих даних мінімізується. Таким чином, створення бази даних переслідує дві основні мети: понизити надмірність даних і підвищити їх надійність.

У курсовій роботі створюється реляційна база даних, тому що: по-перше, реляційні бази набули найбільшого поширення в світі; по-друге, вони найбільш "просунуті" в науковому плані; а по-третє, ядро баз даних Oracle Database , на основі якого працюють всі останні продукти компанії Oracle, призначене саме для роботи з реляційними базами даних/

Життєвий цикл будь-якого програмного продукту, в тому числі баз даних, складається зі стадій проектування, реалізації та експлуатації.

Природно, найбільш значним фактором в життєвому циклі, що працює з базою даних, є стадія проектування. Від того, наскільки ретельно продумана структура бази, наскільки чітко визначені зв'язки між її елементами, залежить продуктивність системи і її інформаційна насиченість, а значить - і час її життя.

У цій курсовій роботі буде використано методологію, згідно з якої життєвий цикл складається з наступних етапів:

· розробка стратегії автоматизації предметної області;

· проведення системного аналізу предметної області;

· концептуальне моделювання предметної області;

· логічне проектування.

· фізичне проектування

Предметна область має дві основні складові : завдання, що мають бути автоматизовані та інформацію, що буде використана для вирішення даних завдань. Метою курсової є розробка бази даних предметної області, тому її виконання матиме відношення лише до інформаційної складової предметної області.



1. Стратегія автоматизації предметної області

1.1 Загальні положення

данні інформаційний програмний relationship

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

У ході виконання процесів етапу розробки стратегії, мають бути виділені критичні моменти проекту, що матимуть місце на різних стадіях його розробки (аналіз, проектування, реалізація, документування, впровадження, експлуатація).

Також, на етапі розробки стратегії має відбуватися аналіз організації, що лежить в основі плану створення системи. Після виконання аналізу має бути визначена стратегія інформатизації, після чого буде створено модель прикладної області. Для того, щоб стратегія не втрачала актуальності, необхідно прийняти заходів для її розробки протягом якомога коротшого проміжку часу.

Вихідними даними етапу стратегії мають бути :

1. Визначення задач автоматизації, її мету та цілі.

2. Область застосування системи баз даних.

3. Визначення задач прикладної діяльності.

4. Визначення границь системи.

5. Можливу архітектуру системи.

6. Вимоги до системи.

7. План розробки системи, узгоджений із замовником.

У даній роботі на етапі розробки стратегії ми опишемо тільки мету та цілі автоматизації, а також деякі вимоги по створюваної бази даних.

1.2 Мета, цілі та задачі створення бази даних

Основною метою бази даних є автоматизація процесів збереження, обробки та обліку даних для системи, що займається керуванням ресурсів підприємства, що виділяються на реалізацію проектів даного підприємства. Ціллю системи є оптимізація планування та використання людських та технічних ресурсів підприємства, а також контроль розподілу ресурсів між проектами.

Система повинна будуватися таким чином, щоб у міру можливостей вона була інформаційно-сумісна з іншими системами, що мають відношення до комерційного процесу підприємства.

Мета автоматизації -- оптимізувати процеси розподілення та планування ресурсів, необхідних для реалізації того чи іншого проекту підприємства, забезпечення звітності використання даних ресурсів, а також забезпечення швидкого доступу до інформації про поточне використання ресурсів.

Цілями створення бази даних є наступні:

· Підвищення ефективності й продуктивності керування людськими ресурсами. Використання бази даних надає можливість переглядати, а також редагувати списки працівників, а також отримувати інформацію про їх роботу над поставленими задачами.

· Оптимізація розподілу ресурсів між задачами, які виконуються у рамках деякого проекту. База даних надає можливість переглядати списки етапі та задач проектів, а також ресурсів, виділених на їх використання, а саме людських ресурсів, та технічних ресурсів.

· Підвищення ефективності й продуктивності керування технічними ресурсами. Використання бази даних надає можливість переглянути, ким і коли було використано, або використовується на даний момент, технічні ресурси.

· Надання загальної інформації у вигляді, що відповідає стандартним формам статистичної звітності. Стандартизація можливостей надання та зберігання інформації для усіх існуючих систем обробки та зберігання знімає необхідність спеціалізованих знань у співробітників підприємства. Також, за її рахунок спрощується документообіг.

Досягнення зазначених цілей виконується за рахунок:

· створення комплексної інформаційної системи із централізованою базою даних;

· підвищення оперативності збору й обробки необхідної інформації;

· стандартизації інформації, що зберігаються у базі даних;

· стандартизації звітності, що надається на основі доступної інформації;

· підвищення ефективності й продуктивності роботи обслуговуючого персоналу;

· підвищення вірогідності, несуперечності, повноти й надійності інформації;

· підвищення наочності, зручності використання й інформативності одержуваних даних;

· автоматизації інформаційного пошуку, одержання інформації безпосередньо на робочих місцях.

1.3 Вимоги до інформаційного забезпечення

Рішення з використання інформаційного забезпечення повинні передбачати можливість розширення можливостей системи, без зміни елементів даного інформаційного забезпечення.

Інформаційне забезпечення системи є сукупністю системи класифікації та кодування, уніфікованої систем документації, схем інформаційних потоків, а також методологію побудови бази даних.

Вказана система класифікації і кодування має підтримувати методи класифікації та опису документів, прийняті у неавтоматизованій системі. Методи класифікації та опису документів мають відповідати прийнятій уніфікованій системі документації. Уніфікована система документації також має відповідати найбільш поширеним форматам представлення документації. Також, система класифікації і кодування має забезпечувати оптимізацію процесу накопичення та зберігання інформації, а також вирішення поставлених задач з максимальною швидкістю, та мінімальним використання пам'яті.

Інформаційне забезпечення також включає у себе поза машинну інформаційну базу та внутрішньомашинну інформаційну базу.

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

Розробка внутрішньо машинної інформаційної бази має відображати фізичний рівень зберігання інформації, тобто представлення інформації у електронному вигляді. На фізичному рівні інформація зберігається у вигляді таблиць баз даних та масивів повнотекстової інформації. При розробці внутрішньо машинної бази має бути враховано :

· розподілене збереження інформаційних ресурсів;

· динаміку актуалізації інформації;

· спосіб представлення та структуризацію інформації (реляційні БД, текстові файли, електронні документи і т. ін.).

БД має містити наступну інформацію:

Перелік проектів, якими на даний момент займається підприємство, а також клієнтів, що є замовниками конкретного проекту. Сукупність інформації про проекти містить у собі інформацію про вартість проекту, дату початку та передбачуваного закінчення проекту. Дана інформація має бути використана при плануванні задач та ресурсів, виділених на реалізацію проекту.

Перелік етапів та задач проекту. Для кожного етапу вказується перелік задач, які мають бути виконані у ході виконання даного етапу, а також відділи підприємства, що працюють над виконанням даного етапу. Кожний етап розбивається на сукупність задач, над кожною з яких працюють групи розробників, що складаються з працівників певного відділу.

Інформацію про персонал, що працює на підприємстві. Тобто особисті дані, а також дані про приналежність до певної організаційної структури, та дані посади, яку обіймає робітник. Дані посади в свою чергу містять назву посади, посилання на керівника, інформацію про заробітну плату, що отримує займаючий посаду робітник.

Інформацію про техніку, що міститься у розпорядженні підприємства. Тобто дані, про технічні ресурси, що є у наявності на підприємстві, також особу, яка на даний момент використовує даний технічний ресурс.

Інформацію, про поточні запити робітників на використання конкретних технічних ресурсів.

Інформацію про ієрархічну структуру відділів та груп, тобто, перелік їх керівників, а також керівні співвідношення між окремими посадами.

Поточних та минулих клієнтів підприємства. Тобто містити інформацію для зворотного зв'язку, таку як ім'я контактної особи, телефон, адреса клієнта, тощо.

База даних має бути спроектована таким чином, щоб задовольняти вимогам щодо швидкості обробки запитів. Швидкість відклику на запит для менеджерів, що займаються планування ресурсів, не має перевищувати трьох секунд, для усього іншого персоналу - п'яти секунд.

Інформаційне забезпечення повинно задовольняти вимозі швидкого складання необхідних звітів. Мова опису інформаційних запитів та опису вихідних документів (звітів, повідомлень, наказів та інше) повинна бути максимально простою.



2. Аналіз предметної області

2.1 Загальні положення системного аналізу предметної області

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

На етапі аналізу проводиться документування усіх сутностей та атрибуті предметної області. В процесі виконання даного етапу аналітики, на основі даних співпраці із користувачами, установлюють вимоги до системи. Виділені вимоги детально перевіряються та змінюються, у випадку невідповідності до потреб користувачів. Виділення вимог продовжується до тих пір, доки не буде проаналізовано усі можливі аспекти, тобто вимоги повністю описують усі потреби користувачів. Основні джерела інформації на етапі аналізу :

1. Дані, отримані в ході нарад, анкетування користувачів, та проведення з ними інтерв'ю;

2. Вивчення документів та аналогічних систем, що включає в себе :

2.1. Форми ділових документів.

2.2. Описи робочих процедур

2.3. Посадові обов'язки

2.4. Методичні рекомендації

2.5. Бізнес-плани

2.6. Внутрішньофісна кореспонденція

3. Аналіз розв'язуваних в організації завдань і способів їхнього рішення;

4. Фіксація правил, обмежень і законів, що діють у предметній області.

Факторами успіху проведення аналізу предметної області є наступні:

1. Участь у аналізі користувачів майбутньої системи, а також їх співпраця із аналітиками;

2. Перевірка отриманих вимог на :

2.1. Повноту.

2.2. Коректність.

2.3. Здійсненність.

2.4. Необхідність.

2.5. Пріоритетність.

2.6. Недвозначність.

2.7. Можливість перевірки.

3. Визначення критичних моментів проектування та впровадження;

4. Визначення очних об'єктно-часових характеристик даних;

5. Контроль виконання робіт та дотримання впровадження календарних планів.

2.2 Загальні положення керування ресурсами

Керування ресурсами має критичне значення у процесі керування проектами, якими займається підприємство. Під керуванням ресурсами розуміється розподіл людських та технічних ресурсів між проектами, а при більшій деталізації - між етапами проектів та задачами етапів. Від раціонального використання ресурсів можуть залежати швидкість виконання проектів, їх вартість, та прибуток, що може бути отриманий від реалізації конкретного проекту.

Метою керування ресурсами є оптимізація розподілу ресурсів між задачами, які стоять перед підприємством, таким чином, щоб кожна конкретна задача отримувала рівно стільки ресурсів, скільки необхідно для її реалізації. Виділення недостатньої кількості ресурсів може призвести до затягнення строку виконання задачі. Виділення надмірної кількості - до можливої нестачі ресурсів для виконання інших задач, а також до необов'язкового збільшення вартості виконання задачі. Отже, важливою задачею у даному випадку є планування ресурсів. Планування ресурсів передбачає наступні кроки :

1. Оцінка наявних ресурсів.

2. Оцінка майбутніх потреб.

3. Розробка програми задоволення майбутніх ресурсів.

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

Наступний етап - оцінка майбутніх потреб, тобто прогнозуванням кількості персоналу і техніки, для реалізації короткострокових та перспективних цілей. Тобто передбачення, яка кількість ресурсів може бути використана у майбутньому часі.

Після визначення наявних ресурсів та майбутніх потреб, необхідно визначити програму їх задоволення. Потреба є ціллю, яку необхідно досягти, а програма - способом її досягнення. Програма має включати у себе графік та заходи, по залученню та найму працівників, а також план використання працівниками технічних ресурсів, необхідні для досягнення поставленої цілі.

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

В календарному графіку проекту вказується, на які етапи його розбито, а також коли планується початок та завершення кожного етапу. Точність календарного графіку також є важливою частиною планування ресурсів, так як порушення графіку може призвести до необхідності повторного часткового або повного планування ресурсів, що може призвести того, що підприємство зазнає значних збитків, пов'язаних з витратами на роботу менеджерів, що займаються плануванням ресурсів, а також затримками у виконанні поставлених задач.

Кожен етап в свою чергу розбивається на конкретні задачі, які мають бути виконані у рамках його реалізації. Тобто для етапу також складається календарний графік виконання, де вказується кількість і перелік задач, які необхідно буде виконати для його досягнення.

Календарний графік має складатися з урахуванням кількості ресурсів, які є у розпорядженні підприємства на даний момент. Це обґрунтовано тим, що час, який буде затрачено на виконання конкретного етапу залежить від кількості наявних ресурсів, які буде використано під час виконання.

Складанням календарного графіку проектів, та розбиттям його на етапи має займатися аналітик, чи група аналітиків підприємства. Тобто аналітик визначає часові рамки усього проекту та етапів. Також, аналітик визначає задачі, що мають бути виконані на кожному етапі.

Після визначення задач проекту, керівник відділу, що займається реалізацією конкретного етапу має розділити обов'язки по виконанню конкретних задач між своїми підлеглими, а також сформувати групи, які будуть працювати над тією чи іншою задачею.

Аналітик підприємства:

· Визначає календарні рамки проекту;

· Визначає етапи проекту;

· Визначає календарні рамки етапів;

· Визначає задачі, що мають бути виконані на кожному етапі.;

· Керівник відділуку:

· Визначає групи, що будуть працювати над кожною задачею;

· Визначає календарні рамки виконання задач;

· Назначає керівників груп, що працюють над виконанням поставлених задач етапу;

Працівники, в свою чергу, після розподілу обов'язків, можуть запросити у керівництва певні технічні ресурси, що необхідні їм для виконання запланованої роботи. Таким чином, на кожного робітника ведеться особистий облік технічних засобів, що на даний момент знаходяться у його розпорядженні.

2.3 Системний аналіз предметної області

Інформаційна модель предметної області містить у собі наступні елементи :

· Інформаційну структуру.

· Бізнес правила.

· Інформаційно-довідкові задачі.

Інформаційна структура предметної області описується за допомогою використання таких понять, як : сутність, атрибут та зв'язок.

Під сутністю мається на увазі об'єкт предметної області, що становить певний інтерес з погляду інформаційної моделі предметної області. Сутності має відповідати одне унікальне ім'я в межах усієї предметної області. Сутність має властивості, що визначаються атрибутами та зв'язками.

Атрибути - це властивості, що характеризують сутність. Сутність має містити у собі певний набір атрибутів, що виділяється з-поміж інших, та унікально ідентифікують екземпляри сутності.

Зв'язки - це пойменовані асоціації двох сутностей.

Бізнес-правила - це правила та обмеження, що накладаються на предметну область, відносно понять інформаційної структури. Розрізняють бізнес-правила двох типів :

· Бізнес правила, що мають відношення до атрибутів однієї сутності. Тобто, бізнес правила, що визначають обмеження, накладені на атрибути однієї сутності, наприклад їх унікальність.

· Бізнес правила, що мають відношення до зв'язків між сутностями. Тобто, бізнес правила, що визначають потужність зв'язку між сутностями (один-до-одного, один-до багатьох, тощо), ступінь зв'язку.

Інформаційно-довідкові задачі -- це ті задачі, які вибирають деяку підмножину даних з інформаційної моделі предметної області.

У подальшому, предметна область описується із вказівкою сутностей їхніх атрибутів, зв'язків і діючий бізнес-правил. Опис інформаційно-довідкових задач приводиться окремо.

У результаті аналізу предметної області були визначені наступні сутності, їх атрибути та зв'язки:

Сутність Відділ

Короткий опис сутності. Відділ, що є частиною підприємства, та залучений до роботи над його проектами. До складу відділу входять декілька Працівників. Керівником відділу є один з Працівників. У складі відділу можуть бути декілька Груп. Містить інформацію про назву відділу, а також стислий опис його призначення.

Атрибути. Сутність характеризується наступними атрибутами:

· Назва відділу;

· Стислий опис призначення відділу;

Зв'язки. Сутність Відділ має наступні зв'язки з іншими сутностями:

· Відділ може виконувати один і тільки один Етап проекту;

· Відділ обов'язково має у складі одного чи більше Працівників;

· Відділ обов'язково має у складі одну чи більше Групу.

· Відділ обов'язково керується одним і тільки одним Працівником.

Бізнес-правила. Відносно сутності Задача етапу діють наступні бізнес-правила:

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

Стислий опис є факультативним атрибутом.

2.4 Інформаційно-довідкові задачі

У ході аналізу предметної області було виділено сутностей, що беруть участь у процесі керування ресурсами. Аналіз цих сутностей та їх атрибутів, дозволяє виділити декілька класів типових інформаційно-довідкових задач.

Інформація, що пов'язана із задіяними на даний момент ресурсами:

Надання повної та несуперечливої інформації про працівників, проектах, у яких вони задіяні. Для кожного окремого працівника - інформація щодо його особистих даних, та даних про проекти, у яких вони беруть участь.

Надання інформації про технічні ресурси, задіяні на даний момент працівниками. Для кожного працівника - перелік технічних засобів, які на даний момент знаходяться у його розпорядженні.

Надання інформації про запити на технічні ресурси, сформовані працівниками. Для кожного працівника - список запитів, що ним було подано.

Інформація, що пов'язана з проектами, що знаходяться на розробці у підприємства:

· Надання інформації щодо проектів, тобто переліку проектів, що було прийнято підприємством до розробки.

· Надання інформації про етапи проектів, тобто переліку етапів, на які розбитий кожен конкретний проект.

· Надання інформації про клієнтів, замовлення яких виконуються на даний момент, чи колись виконувалися підприємством.

· Інформація, що пов'язана з ієрархічною структурою підприємства:

Надання інформації про відділки підприємства та їх керівників. Для кожного відділку - перелік працівників, що до нього входять, а також діючих груп, що займаються розробкою проектів, а також етапів проектів, над якими відділ працює на даний момент.



3. Моделювання предметної області

3.1 Теоретичні положення концептуального моделювання

На етапі концептуального моделювання відбувається побудова строгого опису предметної області за допомогою певної формальної мови. Даний формальний опис створюється на основі опису предметної області, було отримано у ході аналізу.

Призначенням концептуального моделювання є створення такого опису предметної області, який буде незалежним від сприйняття окремими користувачами, чи комп'ютерній реалізації. Тобто створення загальної концептуальної моделі інформаційного забезпечення предметної області, доступної для розуміння всіма зацікавленими сторонами.

Концептуальна модель :

Концептуальна модель є основою для розуміння предметної області усіма особами, що займаються розробкою системи, а також кінцевими користувачами системи, і притому однозначного. При розробці системи, до розробки зазвичай залучена велика кількість працівників, і однозначне розуміння усіма ними предметної області є вирішальним фактором успішності, а також швидкості та якості розробки даної системи.

Концептуальна модель має відображати потреби усіх окремих користувачів та груп користувачів. Але вона має бути саме інтеграцією усіх цих потреб, а не відображати кожну окремо. Тобто, завданням моделі є фіксація такого представлення предметної області, яке б показувало вигляд предметної області в цілому, урахування зовнішнього або внутрішнього представлення даних. Таким чином, у концептуальній моделі не повинно бути відображені будь-які аспекти комп'ютерної реалізації системи, такі як способи зберігання інформації, методи доступу, ефективність виконання, оптимізація, тощо. Дані поняття мають бути введені вже після розробки концептуальної моделі, коли розробники почнуть роботу над системою, спираючись на дану модель. Отже, концептуальна модель представляє тільки концептуально релевантні аспекти предметної області.

Концептуальна модель є визначенням меж допустимої еволюціє бази даних. База даних може потребувати розширення під час експлуатації, але дане розширення має відбуватися у границях, визначених у концептуальною моделлю. При необхідності розширення бази даних за визначенні границі, необхідно починати розробку бази даних знову, починаючи з побудови нової концептуальної моделі.

Концептуальна модель забезпечує незалежність даних. Так як концептуальна модель не пов'язана із аспектами внутрішнього або зовнішнього представлення даних, вона допомагає досягти фізичну та логічну незалежність програм від даних.

Концептуальна модель забезпечує центральне адміністрування бази даних.

Концептуальна модель є стійкою. Тобто, концептуальна модель не повинна змінюватися при виникненні додаткових, чи зміні наявних вимог. Так як концептуальна модель є моделлю предметної області, вона має змінюватися лише у випадку сперечливості між нею та предметною областю.

Стійкість. Концептуальна схема жодним чином не повинна змінюватися на догоду вимог тих або інших користувачів або вимог зберігання даних. Будучи моделлю ПО, вона повинна змінюватися тільки в тому випадку, коли входить у суперечність із нею.

Ключовими результатами етапу концептуального моделювання э наступні:

· формальний опис інформаційного забезпечення предметної області.

· докладний і строгий опис сховищ даних.

· детальний опис потоків даних.

· детальний опис ієрархії розв'язуваних завдань із детальною специфікацією всіх завдань.

· детальний опис діючих у предметній області правил і обмежень.

Для опису концептуальної моделі може бути використана велика кількість формальних мов, що претендують на роль мов концептуального моделювання. У наш час особливого поширення набули графічні мови моделювання, що оперують поняттями сутність, атрибут та зв'язок. У даній роботі, для представлення концептуальної моделі було використано мову ER-моделювання предметної області. У наступному розділі коротко описано загальні положення даної мови концептуального моделювання.

3.2 Мова ER--моделювання ПЗ

Мова ER-моделювання (Entity Relationship Modeling) -- це мова визначення інформаційних потреб організації. Мова базується на концепції, відповідно до якої інформаційне забезпечення будь-якої предметної області представляється як сукупність взаємозалежних об'єктів. Процес моделювання полягає у виділенні сутностей ПО, установлення властивостей виділених сутностей і виявлення існуючих між ними зв'язків.

Далі буде коротко розглянуто основні формальні позначення, а також визначення сутностей, зв'язків та атрибутів.

Сутність - об'єкт предметної області, що становить певний інтерес з погляду інформаційної моделі предметної області. Сутності має відповідати одне унікальне ім'я в межах усієї предметної області. Сутність має властивості, що визначаються атрибутами та зв'язками.

Зв'язок -- це деяка пойменована асоціація, між двома сутностями. Зв'язок є бінарним в тому розумінні, що це завжди асоціація в точності двох сутностей або сутності із самої собою. Тобто, кожна асоціація має два закінчення, кожне з яких має свої:

· ім'я зв'язку;

· ступінь/потужність зв'язку;

· факультативність -- обов'язкова або факультативна.

Для того, щоб однозначно задати зв'язок, обидва його кінця обов'язково мають бути визначеними.

На діаграмах зв'язки представляються лініями, що з'єднують два прямокутники сутностей. Наприклад, на рисунку 1 зображено зв'язок багато-до-одного, факультативний на закінченні "один", і обов'язковий на закінченні "багато".

Рисунок 1 - Приклад зв'язків

Ступінь потужності зв'язку "багато" зображується потрійним з'єднанням лінії із прямокутником, закінчення зв'язку "один" - з'єднанням в одній точці. Обов'язкове закінчення зв'язку позначається суцільною лінією, факультативне закінчення - переривчастою лінією.

Атрибут -- це характеристика або аспект, що сприяє розумінню функції, її ідентифікації, якісному чи кількісному розумінні. Атрибутом може бути текст, число, картинка, почуття, запах. Усе, що може сприяти ідентифікації сутності. При обробці даних зазвичай обмежуються числовими і текстовими даними, через складність обробки усіх інших форматів представлення.

Атрибут відображується за допомогою свого ім'я в однині, записаного малими літерами. Атрибути не є обов'язковими при формуванні моделі, але можуть значно полегшити розуміння призначення сутності.

Атрибут описує одну сутність. Атрибут повинен описувати ту сутність, до якої він віднесений. У кожний момент часу сутність може володіти лише одним значенням атрибута.

Атрибут, значення якого є необов'язковим називається факультативним. Обов'язковість атрибуту означає, що сутність може бути визначена лише тоді, коли визначені усі обов'язкові її атрибути. Атрибути унікального ідентифікатор сутності завжди є обов'язковими.

Сутність має бути однозначно ідентифікована за допомогою певної комбінації атрибутів і/або зв'язків. Тобто, сутність має завжди містити певний атрибут, що дозволить її унікально ідентифікувати.

Важливо розрізняти поняття класу та екземпляру сутності, так як у концептуальній моделі представлено лише класи сутностей, з певними абстрактними атрибутами, а у реальній базі даних будуть представлені конкретні екземплярі, з конкретно визначеними атрибутами.

3.3 Побудова концептуальної моделі керування ресурсами

Після проведення аналізу предметної області було побудовано концептуальну модель, за допомогою мови ER-моделювання. На рисунку 2 зображено отриману концептуальну модель предметної області.

Деякі зауваження щодо побудованої моделі:

Модель не містить опису атрибутів сутностей у зв'язку з відсутністю місця для їх зображення. Атрибути сутностей разом з їх зв'язками були описані на етапі аналізу.

Мова ER-моделювання не передбачає детального представлення інформаційно-довідкових задач. Їх опис також було представлено на етапі аналізу у звичайному текстовому вигляді.

Концептуальна модель не містить інших складових, таких як докладний і суворий опис сховищ даних, та детальний опис потоків даних, через те, що дані складові концептуальної моделі не входять у рамки даної роботи.

Рисунок 2 - Концептуальна ER-модель системи керування ресурсами



4. Логічне та фізичне проектування бази даних

У ході наступного етапу буде виконано логічне та фізичне проектування бази даних.

Логічне проектування - створення логічної структури, що описує структуру бази даних у загальному вигляді - таблиці, стовпці, обмеження стовпців, тощо, але без прив'язки до конкретних систем керування базами даних, та інших фізичних аспектів зберігання даних.

Фізичне проектування - створення проекту системи бази даних для конкретної системи керування базами даних. У ході фізичного проектування, логічна структура перетворюється у схему бази даних.

4.1 Логічне проектування

Для створення логічної моделі було обрано реляційну модель, так як реляційна модель є найбільш розповсюдженою з-поміж основних систем керування базами даних.

Для перетворення концептуальної моделі, представленої у вигляді мови ER-моделювання, у реляційну модель, був використаний наступний алгоритм :

Крок 1. Перетворення сутностей у таблиці. Кожна сутність відображається у таблицю бази даних. Тобто, кількість таблиць у новоствореній базі даних має відповідати кількості сутностей, описаних на етапі концептуального моделювання.

Крок 2. Перетворення атрибутів у стовпці. Кожний атрибут сутності відображається відповідним стовпцем. Факультативні атрибути перетворюються у nullable-стовпцями. Обов'язкові атрибути стають not null-стовпцями.

Крок 3. Подання унікальних ідентифікаторів ключами таблиць. Один з унікальних ідентифікаторів перетворюється на первинний ключ таблиці. Так як сутність може мати декілька унікальних ідентифікаторів, обирається той, що використовується найбільш часто. Всі інші унікальні ідентифікатори приймають обмеження цілісності UNIQUE та NOT NULL.

Сутність може унікально ідентифікуватися комбінацією атрибутів і/або зв'язків. При використанні в ідентифікаторі сутності зв'язку до складу первинного ключа включається зовнішній ключ, який посилається на ту таблицю, з якою пов'язаний той або інший зв'язок.

Крок 4. Перетворення зв'язків багато-до-одного й один-до-одного в зовнішні ключі. Зв'язки сутностей перетворюються у зовнішні ключі таблиць. Унікальні ідентифікатори сутностей, що знаходяться на стороні зв'язку із закінченням “один” вносяться у відношення, що знаходиться на стороні “багато“, як стовпці. Факультативним зв'язкам відповідають NULL-стовпці. Обов'язковим зв'язкам відповідають NOT NULL-стовпці.

Крок 5. Введення спеціального первинного ключа, що використовується для більш адекватного перетворення логічного проекту бази даних у фізичний. Даний ідентифікатор не є атрибутом сутності, тому буде незмінним протягом усього її існування. Усі інші стовпці, які мають властивість первинного ключа згідно з концептуальною моделлю, набувають обмеження цілісності UNIQUE та NOT NULL. Повна логічна база даних на основі концептуальної моделі з урахуванням обмежень цілісності та наведеного вище алгоритму детально представлена в наступних таблицях.

Таблиця 1. Відношення сутності ВІДДІЛ DEPARTMENT

Ім'я стовпця	Тип	Довжина	Призначення	Обмеження цілісності стовпців
DEPID	ціле число	10	Унікальний ідентифікатор	Первинний ключ
Dep Name	рядок	15	Назва відділку	Обов'язковий
Dep Descr	рядок	60	Стислий опис призначення відділку	Факультативний
ChiefFK	ціле число	10	Зв'язок із керівником відділку.	Зовнішній ключ, що посилається на первинний ключ відношення WORKER. Обов'язковий, унікальний.



Таблиця 2. Відношення сутності ГРУПА DEP TEAM

Ім'я стовпця	Тип	Довжина	Призначення	Обмеження цілісності стовпців
TЕAMID	ціле число	10	Унікальний ідентифікатор	Первинний ключ
Team Name	рядок	15	Назва групи	Обов'язковий
Team Descr	рядок	60	Стислий опис призначення відділку	Факультативний
LeadFK	ціле число	10	Зв'язок із керівником групи.	Зовнішній ключ, що посилається на первинний ключ відношення WORKER. Обов'язковий.
DEPFK	ціле число	10	Зв'язок із відділом.	Зовнішній ключ, що посилається на первинний ключ відношення DEPARTMENT. Обов'язковий, унікальний.

Таблиця 3. Відношення сутності ПРАЦІВНИК WORKER

Ім'я стовпця	Тип	Довжина	Призначення	Обмеження цілісності стовпців
WRKID	ціле число	10	Унікальний ідентифікатор	Первинний ключ
Wrk Name	рядок	15	ПІБ працівника	Обов'язковий
Wrk Adress	рядок	15	Адреса працівника	Обов'язковий
Wrk Phone	рядок	15	Номер телефону працівника	Обов'язковий
Wrk Birthday	дата		Дата народження працівника	Обов'язковий
Wrk PasNum	ціле число	6	Номер паспорту працівника	Обов'язковий
Wrk PasSer	рядок	2	Серія паспорту працівника	Обов'язковий
DEPFK	ціле число	10	Зв'язок з відділом.	Зовнішній ключ, що посилається на первинний ключ відношення DEPARTMENT. Факультативний.
TEAMFK	ціле число	10	Зв'язок з групою.	Зовнішній ключ, що посилається на первинний ключ відношення DEP TEAM. Факультативний.
POSTFK	ціле число	10	Зв'язок з посадою.	Зовнішній ключ, що посилається на первинний ключ відношення POS. Обов'язковий.
Обмеження цілісності таблиці	Сукупність стовпців (Wrk PasNum, Wrk PasSer) має обмеження унікальності.

Таблиця 4. Відношення сутності ПОСАДА POST

Ім'я стовпця	Тип	Довжина	Призначення	Обмеження цілісності стовпців
POSTID	ціле число	10	Унікальний ідентифікатор	Первинний ключ
Post Name	рядок	15	Назва посади	Унікальний, обов'язковий
Salary	ціле число	8	Заробітна плата посади	Обов'язковий.
Premium	ціле число	5	Преміальні, що передбачені посадою.	Обов'язковий.
Post Descr	рядок	60	Стислий опис посади.	Факультативний.

Таблиця 5. Відношення сутності ПРОЕКТ PROJECT

Ім'я стовпця	Тип	Довжина	Призначення	Обмеження цілісності стовпців
PRJID	ціле число	10	Унікальний ідентифікатор	Первинний ключ
Proj Name	рядок	15	Назва проекту	Унікальний, обов'язковий
Start Date	дата		Дата початку	Обов'язковий
End Date	дата		Дата закінчення	Обов'язковий, значення не може бути більшим за Start Date.
CSTFK	ціле число	10	Зв'язок з замовником	Зовнішній ключ, що посилається на первинний ключ відношення CUSTOMER. Обов'язковий.

Таблиця 6. Відношення сутності ЕТАП ПРОЕКТУ PRJ STAGE

Ім'я стовпця	Тип	Довжина	Призначення	Обмеження цілісності стовпців
STGID	ціле число	10	Унікальний ідентифікатор	Первинний ключ
Part Name	рядок	15	Назва етапу проекту	Обов'язковий
Start Date	дата		Дата початку	Обов'язковий
End Date	дата		Дата закінчення	Обов'язковий, значення не може бути більшим за Start Date.
PRJFK	ціле число	10	Зв'язок з проектом.	Зовнішній ключ, що посилається на первинний ключ відношення PROJECT. Обов'язковий.
DEPFK	ціле число	10	Зв'язок з Відділом.	Зовнішній ключ, що посилається на первинний ключ відношення DEPARTMENT. Обов'язковий, унікальний.

Таблиця 7. Відношення сутності ЗАДАЧА ЕТАПУ STAGE TASK

Ім'я стовпця	Тип	Довжина	Призначення	Обмеження цілісності стовпців
TSKID	ціле число	10	Унікальний ідентифікатор	Первинний ключ
Task Name	рядок	15	Назва задачі етапу	Обов'язковий
Start Date	дата		Дата початку	Обов'язковий
End Date	дата		Дата закінчення	Обов'язковий, значення не може бути більшим за Start Date.
STGFK	ціле число	10	Зв'язок з етапом проекту.	Зовнішній ключ, що посилається на первинний ключ відношення PRJ STAGE. Обов'язковий.
TAMFK	ціле число	10	Зв'язок з групою.	Зовнішній ключ, що посилається на первинний ключ відношення DEP TEAM. Обов'язковий, унікальний.

Таблиця 8. Відношення сутності ЗАМОВНИК CUSTOMER

Ім'я стовпця	Тип	Довжина	Призначення	Обмеження цілісності стовпців
CSTID	ціле число	10	Унікальний ідентифі	Первинний ключ
Company Name	рядок	15	Назва компанії-клієнта.	Унікальний, обов'язковий
Company Adress	рядок	15	Адреса компанії-клієнта.	Обов'язковий
Contact Person	рядок	15	Ім'я контактної особи.	Обов'язковий
Contact Number	рядок	15	Номер телефону контактної особи.	Обов'язковий

Таблиця 9. Відношення сутності ТЕХНІЧНИЙ ЗАСІБ DEVICE

Ім'я стовпця	Тип	Довжина	Призначення	Обмеження цілісності стовпців
DVCID	ціле число	10	Унікальний ідентифікатор	Первинний ключ
Dev Num	ціле число	10	Інвентарний номер технічного засобу.	Унікальний,обов'язковий.
Dev Name	рядок	15	Назва технічного засобу.	Обов'язковий
Dev Type	рядок	15	Вид технічного засобу.	Обов'язковий, приймає значення : комп'ютерна техніка, офісна техніка, радіотехніка, електроінструменти, джерела живлення.
Dev Mark	рядок	15	Марка технічного засобу.	Обов'язковий.
Dev Descr	рядок	60	Стислий опис технічного засобу.	Факультативний.
WRKFK			Зв'язок із працівником, що розпоряджається технічним засобом.	Зовнішній ключ, що посилається на первинний ключ відношення WORKER. Факультативний.

Таблиця 10. Відношення сутності ЗАПИТ НА ТЕХНІЧНИЙ ЗАСІБ REQUEST

Ім'я стовпця	Тип	Довжина	Призначення	Обмеження цілісності стовпців
QUEID	ціле число	10	Унікальний ідентифікатор	Первинний ключ
Que Num	ціле число	10	Номер запиту.	Унікальний,обов'язковий.
Que Descr	рядок	60	Стислий опис запиту.	Обов'язковий
WRKFK	ціле число	10	Зв'язок із працівником, що подав запит.	Зовнішній ключ, що посилається на первинний ключ відношення WORKER. Обов'язковий.
DVCFK	ціле число	10	Зв'язок з технічним засобом.	Зовнішній ключ, що посилається на первинний ключ відношення DEVICE. Обов'язковий.

4.2 Фізичне проектування

Для збереження бази даних було обрано систему керування базами даних Oracle. Дана система керування базами даних підтримує реляційну модель даних, а також має значні можливості індексування полів, що дозволяє отримувати доступ до даних у мінімальний час. Також, дана система керування базами даних має у своєму розпорядженні функції підтримки цілісності даних між реляційними таблицями, що дозволяє розробнику витрачати мінімальний час на створення бази даних, та її таблиць, а кінцевому користувачу - гарантувати цілісність даних, що зберігаються. Для взаємодії із базою даних (створення таблиць та запитів, що вирішують інформаційно-довідкові задачі) використовується реляційна мова запитів SQL.

При відображенні логічної моделі бази даних у фізичну, не виникло жодних ускладнень, так як логічна модель була побудована на основі реляційної структури даних. Логічна модель була приведена у третю нормальну форму, тобто для кожної сутності було створено окрему таблицю бази даних. У результаті отримано десять таблиць реляційної бази даних, де кожне відношення прямо відповідає окремій таблиці, атрибути кожного відношення стають полями цієї таблиці, а первинні ключі відношень стають первинними ключами таблиць.

Інформаційно-пошукові запити

Наведемо приклади інформаційно-пошукових запитів відносно тих задач, які були окреслені в підрозділі «Інформаційно-довідкові задачі». Приклади наведемо у мові SQL Oracle з використанням бази даних, визначеної у попередньому підрозділі.

Інформаційні запити, що пов'язані з задіяними на даний момент ресурсами.

Запит 1. Вивести перелік працівників підприємства, та проектів, у розробці яких вони на даний момент задіяні.

WHERE WORKER.TAMFK DEP TEAM.TAMID AND DEP TEAM.TAMID STAGE TASK.TAMFK

STAGE TASK.STGFK RJ STAGE.STGID AND PRJ STAGE.PRJFK PROJECT.PRJID

Запит 2. Вивести перелік працівників підприємства, та технічних ресурсів, що на даний момент знаходяться у їх розпорядженні.

SELECT Wrk Name,Dev Name FROM WORKER, DEVICE WHERE WORKER.WRKID DEVICE.WRKFK

Запит 3. Вивести перелік працівників підприємства, та запитів, які вони подали на використання технічних ресурсів.

SELECT Wrk Name,Dev Name, Que Descr FROM WORKER, DEVICE, REQUEST WHERE WORKER.WRKID REQUEST.WRKFK AND DEVICE.DVCID REQUEST.DVCFK;

Інформаційні запити, що пов'язані з проектами, що знаходяться на розробці у підприємства.

Запит 1. Вивести перелік поточних проектів, якими займається підприємство, а також замовників даних проектів.

SELECT Proj Name, Company Name FROM PROJECT,CUSTOMER WHERE PROJECT.CSTFK CUSTOMER.CSTID;

Запит 2. Вивести перелік усіх етапів проектів, що знаходяться у розробці на даний момент, а також проектів, частинами яких вони є. Відсортувати по імені проекту.

SELECT Proj Name, Part Name FROM PROJECT,PRJ STAGE WHERE PROJECT.PRJID PRJ STAGE.PRJFK ORDER BY Proj Name;

Запит 3. Вивести поточних та минулих клієнтів підприємства, та кількості проектів кожного клієнта, які на даний момент знаходяться у розробці.

SELECT Company Name, (SELECT COUNT(*) FROM PROJECT WHERE CSTFK CSTID) FROM CUSTOMER;

Інформаційні запити, що пов'язані з ієрархічною структурою підприємства.

Запит 1. Вивести перелік усіх співробітників аналітичного відділку (`Analist').

SELECT Wrk Name FROM WORKER,DEPARTMENT WHERE WORKER.DEPFK DEPARTMENT.DEPID AND DEPARTMENT.Dep Name 'Analist';

Запит 2. Вивести перелік усіх відділків та їх керівників.

SELECT Wrk Name, Dep Name FROM WORKER,DEPARTMENT WHERE WORKER.DEPFK DEPARTMENT.DEPID AND DEPARTMENT. ChiefFK WORKER.WRKID;

Запит 3. Вивести перелік усіх груп аналітичного відділку (`Analist').

SELECT Team Name FROM DEP TEAM, DEPARTMENT WHERE DEP TEAM.DEPFK DEPARTMENT.DEPID AND DEPARTMENT.Dep Name 'Analist';



Висновки

Процес проектування баз даних є складним і багатокроковим процесом по перетворенню інформаційного середовища предметної області у інформаційну модель, що має біг ляд бази даних. Процес проектування розбито на декілька етапів :

1. Розробка стратегії автоматизації.

2. Аналіз предметної області.

3. Побудова концептуальної моделі предметної області.

4. Логічне проектування бази даних.

5. Фізичне проектування бази даних.

Проектування баз даних основане на теорії нормалізації, що дозволяє відповісти на питання перетворення початкової схеми предметної області, а саме - яким чином перетворити дану схему так, щоб у результаті отримати найоптимальнішу схему бази даних. У методології проектування детально описано етапи життєвого циклу створення бази даних за допомогою сучасних мов опису предметної області.

Ціллю курсової роботи було проектування бази даних системи керування ресурсами підприємства.

Першим етапом курсової роботи було дослідження можливих стратегій автоматизації, та вибору найбільш оптимальної з них. У результаті даного дослідження було отримано відповідь на принципові запитання, що стосуються автоматизації будь-якої предметної області.

Наступним етапом було проведення аналізу предметної області, результатом якого став змістовний опис даної предметної області. Для аналізу предметної області було використано літературу з описом процесів керування трудовими ресурсами у ході управління підприємства та його проектами.

Після проведення аналізу предметної області було побудовано концептуальну модель. Концептуальна модель була побудована за допомогою мови ER-опису предметної області, що оперує такими поняттями як сутність, атрибут та зв'язок. Дана мова є графічною, тобто дозволяє візуалізувати побудовану концептуальну модель предметної області. У зв'язку з неявним використанням теорії нормалізації модель представлена у третій нормальній формі, тобто модель не містить транзитивних залежностей а також багатозначних залежностей.

Після створення концептуальної моделі предметної області було виконано логічне та фізичне проектування бази даних. У основі даних етапів проектування лежало конвертування концептуальної моделі предметної області у реляційну модель даних. Для цього було використано алгоритм перетворення схеми предметної області, описаної мовою ER, в схему реляційної бази даних. Після чого реляційна база даних була представлена у фізичній формі, за допомогою реляційної мови запитів SQL ORACLE. Крім того, було також подано пошукові запити, що реалізують поставлені інформаційно-довідкові задачі.

У ході виконання курсової роботи мною було досліджено технологію проектування баз даних, та отримано практичний досвід щодо проектування баз даних для конкретної предметної області.

Размещено на Allbest.ru

...