49814

Розробка стратегії, аналіз, концептуальне моделювання та проектування бази даних проходження практики студентами ВНЗ

Курсовая

Информатика, кибернетика и программирование

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

Украинкский

2014-01-10

440 KB

21 чел.

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

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

ФАКУЛЬТЕТ КОМПЮТЕРНИХ НАУК

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

з дисципліни «Організація баз даних та знань»

Розробка стратегії, аналіз, концептуальне моделювання та проектування бази даних проходження практики студентами ВНЗ
(на прикладі факультету компютерних наук НАУ)

Виконав студент 3 курсу 320 групи

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

Іванов І.І.

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

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

Київ, 2006


ЗМІСТ


ВСТУП

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

  •  розробка стратегії автоматизації предметної області;
  •  проведення системного аналізу предметної області;
  •  концептуальне моделювання предметної області;
  •  логічне та фізичне проектування.

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

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

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

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

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

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

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

Основні результати цього етапу повинні включати:

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

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

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

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

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

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

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

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

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

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

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

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

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

  •  систему класифікації і кодування;
  •  поза машинну інформаційну базу (ІБ);
  •  внутрішньо–машинну ІБ.

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

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

Проектні рішення з розробки внутрішньо–машинної ІБ повинні  відображати фізичний рівень зберігання інформації в системі у вигляді баз даних (БД) і масивів повнотекстової інформації і ураховувати:

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

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

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

БД повинна бути спроектована таким чином, щоб задовольняти вимогам щодо реакції системи на запити. Для диспетчера задовільним є 1-3 секунди, а для інших користувачів бази даних 1-5 секунд.

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

2. АНАЛІЗ ПРЕДМЕТНОЇ ОБЛАСТІ

2.1. Загальні положення системного аналізу ПО

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

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

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

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

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

2.2. Загальні положення проходження практики

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

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

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

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

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

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

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

Керівник практики від вищого навчального закладу:

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

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

Студенти вищих навчальних закладів при проходженні практики зобов'язані:

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

Після закінчення терміну практики студенти звітують  про виконання програми та індивідуального завдання. Загальна і характерна форма звітності студента за практику — це подання письмового звіту, підписаного і оціненого безпосередньо керівником від бази практики.

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

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

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

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

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

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

Бізнес–правила - це правила й обмеження, що діють у ПО відносно основних понять інформаційної структури (сутностей, атрибутів і зв'язків). Виділяються бізнес правила, що мають відносини до атрибутів однієї сутності (унікальність атрибутів, ідентифікація сутності, спеціальні правила, наприклад, тривалість практики вказується в годинниках і не повинна перевищувати 500 годин), до зв'язків між сутностями (факультативність закінчення зв'язку, потужність закінчень зв'язку (1:1, 1:n, m:n), ступінь зв'язку, наприклад, на факультеті повинне бути не більше 10 кафедр).

Інформаційно–довідкові задачі  (на відміну від прикладних задач) — це ті задачі, які вибирають деяку підмножину даних з інформаційної моделі ПО.

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

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

2.3.1. Сутність Навчальний план

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

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

  •  номер;
  •  дата затвердження;
  •  особа, яка затвердила навчальний план.

Зв’язки. Сутність НАВЧАЛЬНИЙ ПЛАН має наступні зв’язки з іншими сутностями:

  •  НАВЧАЛЬНИЙ ПЛАН обов’язково відповідає однієї і тільки однієї СПЕЦІАЛЬНОСТІ;
  •  НАВЧАЛЬНИЙ ПЛАН може передбачати проходження однієї чи більше ЗАПЛАНОВАНОЇ ПРАКТИКИ.

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

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

2.3.2. Сутність Запланована практика

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

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

  •  термін проходження практики (у днях або тижнях).

Зв’язки. Сутність ЗАПЛАНОВАНА ПРАКТИКА має наступні зв’язки з іншими сутностями:

  •  ЗАПЛАНОВАНА ПРАКТИКА обов’язково необхідна для отримання одного і тільки одного КВАЛІФІКАЦІЙНОГО РІВНЯ;
  •  ЗАПЛАНОВАНА ПРАКТИКА обов’язково проходиться на одному і тільки одному КУРСІ;
  •  ЗАПЛАНОВАНА ПРАКТИКА обов’язково має один і тільки один ВИД ПРАКТИКИ;
  •  ЗАПЛАНОВАНА ПРАКТИКА обов’язково передбачається одним і тільки одним НАВЧАЛЬНИМ ПЛАНОМ;
  •  ЗАПЛАНОВАНА ПРАКТИКА може передбачати проходження однієї чи більше ПРАКТИК СТУДЕНТІВ.

Бізнес–правила. Атрибут терміну проходження практики є обов’язковим. ЗАПЛАНОВАНА ПРАКТИКА унікально ідентифікується зв’язками з сутностями НАВЧАЛЬНИЙ ПЛАН та КУРС. Тобто мається на увазі, що згідно з діючими правилами один навчальний план може передбачати проходження не більш однієї практики на одному курсі.

2.3.3. Сутність Вид практики

Короткий опис сутності. Сутність–класифікатор. Призначення — перелік можливих видів практик, які проходять студенти на факультеті. У відповідності до факультету комп’ютерних наук може приймати значення:

  •  схемотехнічна;
  •  комп’ютерна;
  •  технологічна;
  •  експлуатаційна (для спеціалістів
  •  науково-дослідна (для магістрів).

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

  •  назва виду практики;
  •  змістовний опис.

Зв’язки. Сутність ВИД ПРАКТИКИ має наступні зв’язки з іншими сутностями:

  •  ВИД ПРАКТИКИ може відповідати однієї чи більше ЗАПЛАНОВАНОЇ ПРАКТИКИ.

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

  •  вид практики визначається у відповідності до навчального плану у розділі проходження практики. Вид практики може вказуватися у будь-якому навчальному плані, але не може бути декілька практик, одного виду, у навчальному плані.
  •  назва виду практики унікально ідентифікує вид практики.
  •  термін проходження практики є обов’язковими.
  •  кожен вид практики проводиться на різних курсах навчання:
  •  після першого курсу проводиться схемотехнічна практика тривалістю 72 години;
  •  після другого курсу проводиться комп’ютера практика тривалістю 108 годин;
  •  після третього курсу проводиться технологічна практика тривалістю 108 годин;
  •  після четвертого курсу практика не проводиться;
  •  після п’ятого (якщо термін навчання 5 років) або на шостому (якщо термін навчання 5 з половиною років) проводиться два види практики – експлуатаційна для спеціалістів, науково-дослідна для магістрів тривалістю 144 години та переддипломна тривалістю 108 годин.

2.3.4. Сутність Кваліфікаційний рівень

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

Атрибути. Кваліфікується такими атрибутами:

  •  назва кваліфікаційного рівня;
  •  змістовний опис.

Зв’язки. Сутність КВАЛІФІКАЦІЙНИЙ РІВЕНЬ має наступні зв’язки з іншими сутностями:

  •  КВАЛІФІКАЦІЙНИЙ РІВЕНЬ може визначати одну чи більше ЗАПЛАНОВАНІ ПРАКТИКИ;
  •  КВАЛІФІКАЦІЙНИЙ РІВЕНЬ обов’язково надається після закінчення одного і тільки одного КУРСУ.

Бізнес–правила. Назва кваліфікаційного рівня унікально ідентифікує, сутності цього типу, так як не може існувати два рівня з однаковою назвою. Змістовний опис кваліфікаційного рівня є факультативним.

2.3.5. Сутність Спеціальність

Короткий опис сутності. Сутність-класифікатор. Призначення – перелік усіх спеціальностей, за якими навчаються студенти у ВУЗі.

Атрибути. Сутності СПЕЦІАЛЬНІСТЬ характеризується такими атрибутами:

  •  номер спеціальності;
  •  назва спеціальності – повна назва спеціальності.

Зв’язки. Сутність СПЕЦІАЛЬНІСТЬ має наступні зв’язки з іншими сутностями:

  •  СПЕЦІАЛЬНІСТЬ може викладатися на одній чи більше КАФЕДРІ;
  •  СПЕЦІАЛЬНІСТЬ може входити до складу одного чи більше НАВЧАЛЬНОГО ПЛАНУ.

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

2.3.6. Сутність Курс

Короткий опис сутності. Сутність-класифікатор. Призначення – перелік навчальних курсів ВУЗу.

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

  •  номер курсу;
  •  описова характеристика курсу.

Зв’язки. Сутність КУРС має наступні зв’язки з іншими сутностями:

  •  КУРС може передбачати одну чи більше ЗАПЛАНОВАНУ ПРАКТИКУ;
  •  КУРС може мати одну чи більше ГРУПУ;
  •  Закінчення КУРСУ може передбачати отримання одного чи більше КВАЛІФІКАЦІЙНОГО РІВНЯ.

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

2.3.7. Сутність ВНЗ

Короткий опис сутності. Сутність ВУЗ містить інформацію про навчальний заклад у цілому.

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

  •  повна назва вузу;
  •  скорочена назва вузу;
  •  юридична адреса вузу;
  •  ректор вузу.

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

  •  ВУЗ може мати в своєму складі один чи більше ІНСТИТУТІВ, або один чи більше ФАКУЛЬТЕТІВ.

Бізнес–правила. Повна назва вузу є обов’язковою та унікальною властивістю. Назва унікально ідентифікує навчальний заклад, так як у державі не може бути декілька навчальних закладів із однаковою назвою. Коротка назва є факультативною, але не обов’язково унікальною, так як можливе існування двох вузів з однаковою короткою назвою. Юридична адреса є факультативною, але унікальною. Ректор вузу є обов’язковим унікальним атрибутом.

2.3.8. Сутність Інститут

Короткий опис сутності. Сутність ІНСТИТУТ є структурним підрозділом ВУЗу. Інститут безпосередньо входить до складу ВУЗу. У Вузі може бути декілька інститутів, але інститут має входити лише до одного ВУЗу.

Інститут складається з керівництва та декількох факультетів. В інституті має бути хоч один факультет.

Атрибути. Сутності ІНСТИТУТ характеризується наступними атрибутами:

  •  повна назва інституту;
  •  скорочена назва інституту;
  •  директор інституту.

Зв’язки. Сутність ІНСТИТУТ має наступні зв’язки з іншими сутностями:

  •  ІНСТИТУТ обов’язково входить до складу одного і тільки одного ВУЗу;
  •  ІНСТИТУТ може мати у своєму складі один чи більше ФАКУЛЬТЕТІВ.

Бізнес–правила. Повна назва інституту є обов’язковою властивістю. Вона повинна бути унікальною у ВУЗі, так як у Вузі не може бути двох або більше  інститутів з однаковою назвою. Коротка назва є факультативною, але вона також має бути унікальною у ВУЗу. Директор є інституту є обов’язковою і унікальною властивістю.

2.3.9. Сутність Факультет

Короткий опис сутності. Сутність ФАКУЛЬТЕТ є підрозділом, в якому зосереджується навчальний процес. Він є структурним підрозділом інституту, або Вузу.

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

Атрибути. Сутності ФАКУЛЬТЕТ характеризується наступними атрибутами:

  •  повна назва факультету;
  •  коротка назва факультету;
  •  декан факультету;

Зв’язки. Сутність ФАКУЛЬТЕТ має наступні зв’язки з іншими сутностями:

  •  ФАКУЛЬТЕТ обов’язково входить до складу одного і тільки одного ВУЗу, або  одного і тільки одного ІНСТИТУТУ;
  •  ФАКУЛЬТЕТ може мати у своєму складі одну чи більше КАФЕДРУ;
  •  ФАКУЛЬТЕТ може заключати один чи більше ДОГОВОРІВ на проходження практики.

Бізнес–правила. Повна назва факультету є обов'язковим атрибутом яка повинна бути унікальною у ВУЗі, тобто Вузі не може бути двох або більше факультетів з однаковою назвою.

Коротка назва є факультативною властивістю. Як правило у Вузах дотримуються правила, що коротка назва (у межах Вузу) факультету є унікальною.

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

2.3.10. Сутність Кафедра

Короткий опис сутності. Сутність КАФЕДРА є структурним підрозділом одного факультету. Кафедра має безпосередньо входити до складу факультету. Кафедра може структурно складатися з груп.

Атрибути. Сутності КАФЕДРА характеризується наступними атрибутами:

  •  повна назва кафедри;
  •  скорочена назва кафедри;
  •  керівник кафедри.

Зв’язки. Сутність КАФЕДРА має наступні зв’язки з іншими сутностями:

  •  КАФЕДРА обов’язково входить до складу одного і тільки одного ФАКУЛЬТЕТУ;
  •  КАФЕДРА може навчати за однією і тільки однією СПЕЦІАЛЬНІСТЮ;
  •  КАФЕДРА може мати у своєму складі одну чи більше ГРУПУ.

Бізнес–правила. У межах факультету повна назва кафедри є унікальною. Повна назва кафедри є обов’язковою. Скорочена назва кафедри є факультативною і повинна бути унікальною у межах факультету. Керівник кафедри є факультативним атрибутом. У одному ВУЗі одна й таж особа не може бути керівником двох або більше кафедр.

2.3.11. Сутність Група

Короткий опис сутності. Сутність ГРУПА є структурною одиницею кафедри та містить дані по групам, які складають основу розподілення розкладу занять. Суть групи – об’єднання студентів по спеціальностям. Група не може бути закріплена більш ніж за однією кафедрою. До складу групи може входити від декількох студентів до декількох десятків студентів.

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

  •  номер групи;
  •  описові данні групи.

Зв’язки. Сутність ГРУПА має наступні зв’язки з іншими сутностями:

  •  ГРУПА обов’язково входить до складу однієї і тільки однієї КАФЕДРИ;
  •  ГРУПА обов’язково належить одному і тільки одному КУРСУ;
  •  ГРУПА може мати у своєму складі одного чи більше СТУДЕНТА.

Бізнес–правила. Номер групи є обов’язковим та унікальним (можливо тільки у межах факультету). Група належить одному курсу. Перша цифра номеру групи відповідає курсу.

2.3.12. Сутність Студент

Короткий опис сутності. Сутність СТУДЕНТ призначена для зберігання основних відомостей про студентів. Частина даних буде незмінною на протязі всього терміну навчання, частина даних може бути зміненою. Студенти можуть навчатися екстерном, але не залежно від цього вони обов’язково входять до складу групи.

Атрибути. Сутності СТУДЕНТ характеризується наступними атрибутами:

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

Зв’язки. Сутність СТУДЕНТ має наступні зв’язки з іншими сутностями:

  •  СТУДЕНТ обов’язково входить до складу однієї і тільки однієї ГРУПИ;
  •  СТУДЕНТ може проходити одному чи більше ПРАКТИК СТУДЕНТА.

Бізнес–правила. Номер залікової книжки є унікальним у ВУЗі. Він є обов’язковим атрибутом. Студент входить до складу тільки однієї групи. Студент може навчатися або за контрактом, або за бюджетом. Студент може навчатися екстерном, він обов’язково проходить усі практики, які передбачені навчальним планом.

2.3.13. Сутність База практики

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

Атрибути. Сутності БАЗА ПРАКТИКИ характеризується наступними атрибутами:

  •  реєстровий номер;
  •  назва підприємства, організації або установи;
  •  керівник підприємства, організації або установи;
  •  посада керівника;
  •  юридична адреса підприємства, організації або установи.

Зв’язки. Сутність БАЗА ПРАКТИКИ має наступні зв’язки з іншими сутностями:

  •  БАЗА ПРАКТИКИ може заключати однин чи більше ДОГОВІРІВ на проходження практики студентами;

Бізнес–правила. Реєстровий номер підприємства є унікальним і обов’язковим. Він унікально ідентифікує підприємство, з яким укладаються договори. З однією базою практики можуть бути підписані декілька договорів. Студенти проходять практику згідно з договором. Якщо студенти проходять практику у ВУЗі, в якому навчаються, до договори на проходження практики не заключаються. Усі інші атрибути сутності є обов’язковими, але не унікальними.

2.3.14. Сутність Договір

Короткий опис сутності. Сутність ДОГОВІР містить дані по договорам, які укладені між факультетом та базами практик. Для проходження практики групами студентів визначаються підприємства, які можуть надати таку можливість за напрямками навчання студентів. Визначаються календарні плани проходження практики, назначаються керівники від факультету та бази практики. Також складаються списки студентів, які будуть направлені на практику.

Атрибути. Сутності ДОГОВІР характеризується наступними атрибутами:

  •  номер договору;
  •  дата підписання договору;
  •  кількість студентів, які проходять практику по договору;
  •  строки проходження практики.

Зв’язки. Сутність ДОГОВІР має наступні зв’язки з іншими сутностями:

  •  ДОГОВІР обов’язково заключається з однією і тільки однією БАЗОЮ ПРАКТИКИ;
  •  ДОГОВІР обов’язково заключається з однією і тільки однією КАФЕДРОЮ;
  •  ДОГОВІР може бути основою для проходження однієї чи більше ПРАКТИК СТУДЕНТІВ.

Бізнес–правила. Номер договору є обов’язковим і унікальним атрибутом. Он унікально ідентифікує усі договори, які заключаються у ВУЗі. Усі інші атрибути є обов’язковими, але не унікальними.

2.3.15. Сутність Керівник

Короткий опис сутності. Сутність КЕРІВНИК містить інформацію по всім керівникам практик, як від факультету так і від баз практик. Для управління та контролю за процесом проходження практики назначаються по одному керівнику: від факультету та від бази практики. Безпосередньо практику на підприємстві контролює керівник від бази. Для підготовки та направлення на базу практики, а також організацію прийняття звітів та організацію заліків від факультету назначається керівник практики, який вирішує вище зазначені задачі.

Атрибути. Сутності КЕРІВНИК характеризується наступними атрибутами:

  •  прізвище, ім’я та по-батькові;
  •  посада;
  •  домашня адреса керівника;
  •  серія паспорта.

Зв’язки. Сутність КЕРІВНИК має наступні зв’язки з іншими сутностями:

  •  КЕРІВНИК може керувати однією чи більше ПРАКТИКОЮ СТУДЕНТА від бази практики;
  •  КЕРІВНИК може керувати однією чи більше ПРАКТИКОЮ СТУДЕНТА від факультету;

Бізнес–правила. Керівник унікально ідентифікується серією і номером паспорту, яку у сукупності повинні бути унікальним и і обов’язковими. Прізвище ім’я та по батькові є обов’язковими атрибутами, але не унікальними. Усі інші атрибути є факультативними і не унікальними. Якщо студент проходить практику на факультеті, то він може мати одного і того є керівника.

2.3.16. Сутність Практика студента

Короткий опис сутності. Сутність ПРАКТИКА СТУДЕНТА містить дані про проходження практики студентами згідно з учбовим планом.

Атрибути. Сутності ПРАКТИКА СТУДЕНТА характеризується наступними атрибутами:

  •  термін проходження практики;
  •  дата прибуття на базу практики;
  •  дата вибуття з бази практики;
  •  оцінка, яку отримав студент, згідно заліку.

Зв’язки. Сутність ПРАКТИКА СТУДЕНТА має наступні зв’язки з іншими сутностями:

  •  ПРАКТИКА СТУДЕНТА обов’язково проходиться одним і тільки одним СТУДЕНТОМ;
  •  ПРАКТИКА СТУДЕНТА обов’язково керується від факультету одним і тільки одним КЕРІВНИКОМ;
  •  ПРАКТИКА СТУДЕНТА обов’язково керується від базі практики одним і тільки одним КЕРІВНИКОМ;
  •  ПРАКТИКА СТУДЕНТА може проводитися згідно з одним і тільки одним ДОГОВОРОМ;
  •  ПРАКТИКА СТУДЕНТА обов’язково проходить згідно з однією і тільки однією ЗАПЛАНОВАНОЮ ПРАКТИКОЮ;

Бізнес–правила. ПРАКТИКА СТУДЕНТА унікально ідентифікується зв’язками з сутностями СТУДЕНТ та ЗАПЛАНОВАНА ПРАКТИКА. Усі атрибути крім оцінки обов’язковими але не унікальними. Відсутність оцінки свідчить, що студент не захистив результати практики і не отримав оцінки. Для одного студента терміни проходження практик не можуть перетинатися.

2.3.17. Сутність Звіт

Короткий опис сутності. Сутність ЗВІТ є текстовим документом, який містить звіт студента за результатами проходження практики. Кожен звіт має бути перевіреним та підписаним керівниками практики. Звіт є основою для здавання заліку студентом по практиці. Звіт має єдиний атрибут — текст звіту. Звіт має єдиний зв’язок з  сутністю ПРАКТИКА СТУДЕНТА. Цей зв’язок обов’язковим та має ступінь 1 і унікально ідентифікує звіт.

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

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

По-перше, інформація, що пов’язана з самою практикою:

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

По-друге, це інформація організаційного характеру:

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

По-третє, це інформація, що відноситься до процесу керування практикою:

  •  надання інформації по керівникам практики;
  •  відповідність груп студентів та керівників, під керівництвом яких проводилась практика.

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

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

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

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

Властивостями концептуальної моделі є наступні.

  •  Це основа однозначного розуміння ПО всіма зацікавленими особами. У розробку складної системи баз даних включається великий колектив: експерти, системні аналітики, проектувальники, розроблювачі, ті, хто займається впровадженням і супроводом. Всі вони повинні однозначно розуміти, що ж собою представляє ПО, що автоматизується, у який зміст використовуваних понять, як вони взаємозалежні між собою, які всілякі обмеження в ПО мають місце, які вимоги висуваються до різних функціональних компонентів ПО й т.д. Все це повинна забезпечувати концептуальна модель. Це та єдина платформа, що дозволяє всім розмовляти на одній й тіж мові й однаково розуміти один одного.
  •  Вона включає тільки концептуально релевантні аспекти ПО, крім, таким чином, БУДЬ-ЯКИХ аспектів зовнішнього або внутрішнього представлення даних. Це означає, по перше, що концептуальна модель жодним чином не повинна фіксувати конкретні потреби окремих груп користувачів або додатків. Вона повинна фіксувати, що собою представляє ПО в цілому, а не з погляду інтересів або потреб користувачів. Вона повинна інтегрувати думки, погляди й інтереси окремих користувачів, але саме інтегрувати, для одержання цілісної картини, а не виражати їхні конкретні погляди, побажання думки. По-друге, у концептуальній моделі ПО ні яким чином не повинні відбиватися які-небудь аспекти майбутньої реалізації БД у комп'ютерному середовищі. Усе, що пов'язане з такими поняттями, як способи зберігання, методи доступу, ефективність виконання, оптимізація й т.д. перебувають за межами концептуальної моделі.
  •  Це засіб визначення припустимої еволюції БД. У процесі експлуатації БД може розвиватися, однак цей розвиток може вироблятися тільки в тих межах, які припустимі з погляду концептуальної моделі. Розвиток бази даних, що вимагає змін у концептуальній схемі, означає ні що інше, як переосмислювання ПО й завдань автоматизації й побудови на цій основі нової концептуальної моделі ПО.
  •   Забезпечення незалежності даних. Наявність концептуальної моделі, яка не залежить від зовнішнього представлення користувачами ПО, та різними аспектами реалізації БД є надійна основа вирішення задач досягнення логічної та фізичної незалежності програм від даних.
  •   Централізоване адміністрування. Саме через концептуальну схему здійснюється адміністрування базами даних.
  •   Стійкість. Концептуальна схема жодним чином не повинна змінюватися на догоду вимог тих або інших користувачів  або вимог зберігання даних. Будучи моделлю ПО, вона повинна змінюватися тільки в тому випадку, коли входить у суперечність із нею.

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

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

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

3.2. Мова ER—моделювання ПО

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

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

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

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

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

  •   ім'я;
  •   ступінь/потужність;
  •   факультативність — обов'язкова або факультативна.

Ці властивості використовуються для опису асоціації з кожної зі сторін, для завдання зв'язку повинні бути визначені обидва її кінця.

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

Рис. Приклад зв'язку

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

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

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

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

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

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

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

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

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

На основі проведеного аналізу предметної області була побудована концептуальна модель з використанням мови ER–моделювання. Концептуальна модель наведена на наступному рисунку. Дамо декілька зауважень:

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

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

Завдання цього етапу полягає у проведенні логічного та фізичного проектування бази даних.

Логічне проектування — це розробка логічної структури системи баз даних без прив'язки до конкретної СУБД, структур збереження, методам доступу і т.д..

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

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

У якості логічній моделі бази даних була обрана реляційна модель, оскільки саме реляційна модель використовується у більшості розвинених СКБД.

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

  •  Крок 1. Перетворення сутностей у таблиці. Кожна сутність перетворюється у таблицю. Ім’я сутності представляється у вигляді семантично осмисленого імені у латинському алфавіті.
  •  Крок 2. Перетворення атрибутів у стовпці. Кожний атрибут перетвориться в стовпець. Ім’я атрибуту представляється у вигляді семантично осмисленого імені у латинському алфавіті. У цей момент уточнюється формат представлення значень стовпця. Факультативні атрибути стають NULL-стовпцями. Обов'язкові атрибути стають NOT NULL-стовпцями.
  •  Крок 3. Подання унікальних ідентифікаторів ключами таблиць. Складові унікального ідентифікатора сутності стають первинним ключем таблиці. Нагадаємо, що сутність може мати більш ніж один унікальний ідентифікатор Тому вибирається той, котрий використовується найбільше часто. Всі інші унікальні ідентифікатори приймають обмеження цілісності UNIQUE NOT та NOT NULL.

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

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

  •  Крок 4. Перетворення зв'язків багато-до-одного й один-до-одного в зовнішні ключі. Зв'язки типу багато-до-одного й один-до-одного породжують зовнішні ключі. Інакше кажучи, необхідно взяти унікальні ідентифікатори  кожної сутності, розташованої в закінчення зв'язку зі ступенем один, і ввести його у відношення, розташоване з боку зв'язку "багато" як стовпці. Факультативним зв'язкам відповідають NULL-стовпці. Обов'язковим зв'язкам відповідають NOT NULL-стовпці.
  •  Крок 5. Введення спеціальних первинних ключів. Для більш адекватного відображення логічного проекту бази даних у фізичний, вводимо у всі таблиці один спеціальний стовпець з обмеженням цілісності первинного ключа. Всі ті стовпці, які мають властивість первинного ключа згідно з концептуальною моделлю, набувають обмеження цілісності UNIQUE та NOT NULL.

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

Таблиця 1. Відношення сутності НАВЧАЛЬНИЙ ПЛАН

EDU_PLAN

Ім’я стовпця

Тип

Довжина

Призначення

Обмеження цілісності стовпців

EPID

ціле число

10

Унікальний ID

Первинний ключ

Num

строка

8

Номер навч. плану

Унікальний, обов’язковий

Ass_date

дата

Дата затвердження

Обов’язковий

Prs

строка

40

Особа, що затвердила

Обов’язковий

SPID

ціле число

10

Зв’язок зі спеціальністю

Зовнішній ключ, що посилається на первинний ключ відношення SPECIALITY. Обов’язковий

Таблиця 2. Відношення сутності ЗАПЛАНОВАНА ПРАКТИКА

PLAN_PRACTICE

Ім’я стовпця

Тип

Довжина

Призначення

Обмеження цілісності стовпців

PPID

ціле число

10

Унікальний ID

Первинний ключ

Dur_type

строка

1

Одиниці виміру терміну проходження практики. Приймає значення „Д”–дні, „Т”–тижні

Обов’язковий

Duration

ціле число

3

Термін проходження практики

Обов’язковий

QLID

ціле число

10

Зв’язок з кваліфікаційним рівнем

Зовнішній ключ, що посилається на первинний ключ відношення QUALI_LEVEL. Обов’язковий

CUID

ціле число

10

Зв’язок з курсом

Зовнішній ключ, що посилається на первинний ключ відношення COURSE. Обов’язковий

PTID

ціле число

10

Зв’язок з видом практики

Зовнішній ключ, що посилається на первинний ключ відношення PRAC_TYPE. Обов’язковий

EPID

ціле число

10

Зв’язок з навчальним планом

Зовнішній ключ, що посилається на первинний ключ відношення EDU_PLAN. Обов’язковий

Обмеження цілісності таблиці

Сукупність стовпців (CUID, EPID) має обмеження унікальності та обов’язковості.  

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

PRAC_TYPE

Ім’я стовпця

Тип

Довжина

Призначення

Обмеження цілісності стовпців

PTID

ціле число

10

Унікальний ID

Первинний ключ

Name

строка

15

Назва практики

Унікальний, обов’язковий. Приймає значення: схемотехнічна; комп’ютерна; технологічна; експлуатаційна (для спеціалістів науково-дослідна (для магістрів).

Descr

строка

255

Змістовний опис

Факультативний

Таблиця 4. Відношення сутності КВАЛІФІКАЦІЙНИЙ РІВЕНЬ

QUALI_LEVEL

Ім’я стовпця

Тип

Довжина

Призначення

Обмеження цілісності стовпців

QLID

ціле число

10

Унікальний ID

Первинний ключ

Name

строка

15

Назва кваліфікаційного рівня

Унікальний, обов’язковий. Приймає значення: бакалавр; спеціаліст; магістр.

Descr

строка

255

Змістовний опис

Факультативний

CUID

ціле число

10

Зв’язок з курсом

Зовнішній ключ, що посилається на первинний ключ відношення COURSE. Обов’язковий

Таблиця 5. Відношення сутності СПЕЦІАЛЬНІСТЬ

SPECIALITY

Ім’я стовпця

Тип

Довжина

Призначення

Обмеження цілісності стовпців

SPID

ціле число

10

Унікальний ID

Первинний ключ

Num

строка

20

Номер спеціальності

Унікальний, обов’язковий.

Name

строка

100

Назва спеціальності

Обов’язковий

Таблиця 6. Відношення сутності КУРС

COURSE

Ім’я стовпця

Тип

Довжина

Призначення

Обмеження цілісності стовпців

CUID

ціле число

10

Унікальний ID

Первинний ключ

Num

ціле число

1

Номер курсу

Унікальний, обов’язковий. Приймає значення: 1-6.

Descr

строка

255

Змістовний опис

Факультативний

Таблиця 7. Відношення сутності ВУЗ

UNIVERSITY

Ім’я стовпця

Тип

Довжина

Призначення

Обмеження цілісності стовпців

UNID

ціле число

10

Унікальний ID

Первинний ключ

Short_Name

строка

10

Скорочена назва ВУЗу

Факультативний.

Long_Name

строка

50

Повна назва ВУЗу

Обов’язковий, унікальний

Address

строка

50

Адреса ВУЗу

Факультативний

Rector

строка

30

ПІБ ректора

Обов’язковий, унікальний

Таблиця 8. Відношення сутності ІНСТИТУТ

INSTITUTE

Ім’я стовпця

Тип

Довжина

Призначення

Обмеження цілісності стовпців

INID

ціле число

10

Унікальний ID

Первинний ключ

Short_Name

строка

10

Скорочена назва

Факультативний.

Long_Name

строка

50

Повна назва

Обов’язковий, унікальний

Director

строка

30

ПІБ директора

Обов’язковий, унікальний

UNID

ціле число

10

Зв’язок з ВУЗом

Зовнішній ключ, що посилається на первинний ключ відношення UNIVERSITY. Обов’язковий

Таблиця 9. Відношення сутності ФАКУЛЬТЕТ

FACULTY

Ім’я стовпця

Тип

Довжина

Призначення

Обмеження цілісності стовпців

FAID

ціле число

10

Унікальний ID

Первинний ключ

Short_Name

строка

10

Скорочена назва

Факультативний.

Long_Name

строка

50

Повна назва

Обов’язковий, унікальний

Dean

строка

30

ПІБ декана

Обов’язковий, унікальний

UNID

ціле число

10

Зв’язок з ВУЗом

Зовнішній ключ, що посилається на первинний ключ відношення UNIVERSITY. Факультативний

INID

ціле число

10

Зв’язок з інститутом

Зовнішній ключ, що посилається на первинний ключ відношення INSTITUTE,. Факультативний

FKType

строка

Признак, кому належить факультет, ВУЗу або інституту

Приймає значення: „У”, якщо факультет належить UNIVERSITY, або “І”, якщо   факультет належить INSTITUTE

Таблиця 10. Відношення сутності КАФЕДРА

DEPARTMENT

Ім’я стовпця

Тип

Довжина

Призначення

Обмеження цілісності стовпців

DEID

ціле число

10

Унікальний ID

Первинний ключ

Short_Name

строка

10

Скорочена назва

Факультативний.

Long_Name

строка

50

Повна назва

Обов’язковий, унікальний

Head

строка

30

ПІБ завідувача

Обов’язковий, факультативний

FAID

ціле число

10

Зв’язок з факультетом

Зовнішній ключ, що посилається на первинний ключ відношення FACILTY. Обов’язковий

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

STGROUP

Ім’я стовпця

Тип

Довжина

Призначення

Обмеження цілісності стовпців

GRID

ціле число

10

Унікальний ID

Первинний ключ

Num

строка

5

Номер групи

Обов’язковий, унікальний у межах факультету

Descr

строка

255

Змістовний опис групи

Факультативний

DEID

ціле число

10

Зв’язок з кафедрою

Зовнішній ключ, що посилається на первинний ключ відношення DEPARTMENT. Обов’язковий

CUID

ціле число

10

Зв’язок з курсом

Зовнішній ключ, що посилається на первинний ключ відношення COURSE. Обов’язковий

Таблиця 12. Відношення сутності СТУДЕНТ

STUDENT

Ім’я стовпця

Тип

Довжина

Призначення

Обмеження цілісності стовпців

STID

ціле число

10

Унікальний ID

Первинний ключ

Last_name

строка

30

Прізвище

Обов’язковий

Name

строка

20

Ім’я

Обов’язковий

Patro_name

строка

20

По батькові

Обов’язковий

Num

строка

10

Номер студентського квитка

Обов’язковий, унікальний

Birthday

дата

Дата народження

Обов’язковий

Year

ціле число

4

Рік вступу у ВУЗ

Обов’язковий

Country

строка

20

Країна мешкання

Обов’язковий

Contract

строка

1

Навчання за контрактом

Обов’язковий. „T” – навчання за контрактом, „H” - ні

External

строка

1

Навчання екстерном

Обов’язковий. „T” – навчання екстерном, „H” - ні

GRID

ціле число

10

Зв’язок з групою

Зовнішній ключ, що посилається на первинний ключ відношення STGROUP. Обов’язковий

Таблиця 13. Відношення сутності БАЗА ПРАКТИКИ

COMPANY

Ім’я стовпця

Тип

Довжина

Призначення

Обмеження цілісності стовпців

COID

ціле число

10

Унікальний ID

Первинний ключ

Num

строка

10

Реєстровий номер

Обов’язковий, унікальний

Name

строка

40

Назва

Обов’язковий

Head

строка

20

ПІБ керівника

Обов’язковий

Post

строка

20

Посада керівника

Обов’язковий

Address

строка

50

Адреса

Факультативний

Таблиця 14. Відношення сутності ДОГОВІР

AGREEMENT

Ім’я стовпця

Тип

Довжина

Призначення

Обмеження цілісності стовпців

AGID

ціле число

10

Унікальний ID

Первинний ключ

Num

строка

10

Номер договору

Обов’язковий, унікальний

AssDate

дата

Дата підписання

Обов’язковий

St_num

ціле число

2

Кількість студентів

Обов’язковий

From_date

дата

Дата початку практики

Обов’язковий

To_date

дата

Дата закінчення практики

Обов’язковий

COID

ціле число

10

Зв’язок з базою практики

Зовнішній ключ, що посилається на первинний ключ відношення COMPANY. Обов’язковий

FAID

ціле число

10

Зв’язок з кафедрою

Зовнішній ключ, що посилається на первинний ключ відношення FACULTY. Обов’язковий

Таблиця 15. Відношення сутності КЕРІВНИК

TUTOR

Ім’я стовпця

Тип

Довжина

Призначення

Обмеження цілісності стовпців

TUID

ціле число

10

Унікальний ID

Первинний ключ

Name

строка

30

ПІБ керівника

Обов’язковий

Post

строка

20

Посада

Факультативний

Address

строка

30

Адреса

Факультативний

Pas_ser

строка

2

Серія паспорту

Обов’язковий

Pas_ num

строка

6

Номер паспорту

Обов’язковий

Обмеження цілісності таблиці

Сукупність стовпців (PasSer, PasNum) має обмеження унікальності.  

Таблиця 16. Відношення сутності ПРАКТИКА СТУДЕНТА

STUD_PRACTICE

Ім’я стовпця

Тип

Довжина

Призначення

Обмеження цілісності стовпців

SPID

ціле число

10

Унікальний ID

Первинний ключ

Duration

ціле число

2

Термін проходження практики у днях

Обов’язковий

In_date

дата

Дата початку практики

Обов’язковий

Out_date

дата

Дата закінчен. практики

Обов’язковий

Mark

ціле число

1

Оцінка

Факультативний, Приймає значення у інтервалі 1 — 5

STID

ціле число

10

Зв’язок з студентом

Зовнішній ключ, що посилається на первинний ключ відношення STUDENT. Обов’язковий

TUFID

ціле число

10

Зв’язок з керівником від факультету

Зовнішній ключ, що посилається на первинний ключ відношення TUTOR. Обов’язковий

TUCID

ціле число

10

Зв’язок з керівником від бази практики

Зовнішній ключ, що посилається на первинний ключ відношення TUTOR. Обов’язковий

AGID

ціле число

10

Зв’язок з договором, згідно з яким проходила практика

Зовнішній ключ, що посилається на первинний ключ відношення AGREEMENT. Факультативний

PPID

ціле число

10

Зв’язок з запланованою практикою

Зовнішній ключ, що посилається на первинний ключ відношення PLAN_PRACTICE. Обов’язковий

Обмеження цілісності таблиці

Сукупність стовпців (STID, PPID) має обмеження унікальності та обов’язковості.  

Таблиця 17. Відношення сутності ЗВІТ

REPORT

Ім’я стовпця

Тип

Довжина

Призначення

Обмеження цілісності стовпців

REID

ціле число

10

Унікальний ID

Первинний ключ

Text

строка

30КБ

Текст звіту

Обов’язковий

SPID

ціле число

10

Зв’язок з практикою студента

Зовнішній ключ, що посилається на первинний ключ відношення STUD_PRACTICE. Обов’язковий та унікальний

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

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

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

4.2.1. Скрипти створення бази даних

Наведемо скрипт мови SQL Oracle, який створює таблиці БД.

-- Створення таблиці SPECIALITY

CREATE TABLE SPECIALITY (

 SPID integer      CONSTRAINT spe_prk PRIMARY KEY,

 Num  char(20)     CONSTRAINT spe_num_unq UNIQUE NOT NULL,

 Name varchar(100) NOT NULL);

-- Створення таблиці EDU_PLAN

CREATE TABLE EDU_PLAN (

 EPID     integer     CONSTRAINT edp_prk PRIMARY KEY,

 Num      char(8)     CONSTRAINT edp_num_unq UNIQUE NOT NULL,

 Ass_date date        NOT NULL,

 Prs      varchar(40) NOT NULL,

 SPID     integer     CONSTRAINT edp_spc_frk REFERENCES SPECIALITY(SPID) NOT NULL);

-- Створення таблиці COURSE

CREATE TABLE COURSE (

 CUID  integer     CONSTRAINT crs_prk PRIMARY KEY,

 Num   number(1)   CONSTRAINT crs_num_unq UNIQUE NOT NULL

                   CONSTRAINT crs_num_chk CHECK (Num IN (1,2,3,4,5,6)),

 Descr varchar(255));

-- Створення таблиці QUALI_LEVEL

CREATE TABLE QUALI_LEVEL (

 QLID  integer      CONSTRAINT qlv_prk PRIMARY KEY,

 Name  varchar(15)  CONSTRAINT qvl_nam_unq UNIQUE NOT NULL

                    CONSTRAINT qvl_nam_chk CHECK

                    (Name IN (’бакалавр’, ’спеціаліст’, ’магістр’)),

 Descr varchar(255),

 CUID  integer      CONSTRAINT qvl_crs_frk REFERENCES COURSE(CUID) NOT NULL);

-- Створення таблиці PRAC_TYPE

CREATE TABLE PRAC_TYPE (

 PTID  integer      CONSTRAINT prt_prk PRIMARY KEY,

 Name  varchar(15)  CONSTRAINT prt_nam_unq UNIQUE NOT NULL

                    CONSTRAINT prt_nam_chk CHECK

                    (Name IN (’схемотехнічна’, ’комп’’ютерна’,

                     ’технологічна’, ’експлуатаційна’,
                     ’науково-дослідна’)),

 Descr varchar(255));

-- Створення таблиці PLAN_PRACTICE

CREATE TABLE PLAN_PRACTICE (

 PPID     integer   CONSTRAINT ppr_prk PRIMARY KEY,

 Dur_type char(1)   CONSTRAINT ppr_dtp_chk CHECK (Dur_type IN (’Д’,’Т’))

                    NOT NULL,

 Duration NUMBER(3) NOT NULL,

 QLID     integer   CONSTRAINT ppr_qvl_frk REFERENCES QUALI_LEVEL(QLID) NOT NULL,

 CUID     integer   CONSTRAINT ppr_crs_frk REFERENCES COURSE(CUID) NOT NULL,

 PTID     integer   CONSTRAINT ppr_prt_frk REFERENCES PRAC_TYPE(PTID) NOT NULL,

 EPID     integer   CONSTRAINT ppr_edp_frk REFERENCES EDU_PLAN (EPID) NOT NULL,

 CONSTRAINT ppr_crs_edp_unq UNIQUE (CUID, EPID);

-- Створення таблиці UNIVERSITY

CREATE TABLE UNIVERSITY (

 UNID       integer     CONSTRAINT uni_prk PRIMARY KEY,

 Short_name varchar(10),

 Long_name  varchar(50) CONSTRAINT uni_nam_unq UNIQUE NOT NULL,

 Address    varchar(50),

 Rector     varchar(30) CONSTRAINT uni_rec_unq UNIQUE NOT NULL);

-- Створення таблиці INSTITUTE

CREATE TABLE INSTITUTE (

 INID       integer     CONSTRAINT ins_prk PRIMARY KEY,

 Short_name varchar(10),

 Long_name  varchar(50) CONSTRAINT ins_nam_unq UNIQUE NOT NULL,

 Director   varchar(30) CONSTRAINT ins_rec_unq UNIQUE NOT NULL,

 UNID       integer     CONSTRAINT ins_uni_frk REFERENCES UNIVERSITY(UNID));

-- Створення таблиці FACULTY

CREATE TABLE FACULTY (

 FAID       integer     CONSTRAINT fac_prk PRIMARY KEY,

 Short_name varchar(10),

 Long_name  varchar(50) CONSTRAINT fac_nam_unq UNIQUE NOT NULL,

 Dean       varchar(30) CONSTRAINT fac_rec_unq UNIQUE NOT NULL,

 UNID       integer     CONSTRAINT fac_uni_frk REFERENCES UNIVERSITY(UNID),

 INID       integer     CONSTRAINT fac_ins_frk REFERENCES INSTITUTE(INID),

 FKType     char(1)     CONSTRAINT fac_fkt_chk CHECK (FKType IN (’У’, ’І’)));

-- Створення таблиці DEPARTMENT

CREATE TABLE DEPARTMENT (

 DEID       integer     CONSTRAINT dep_prk PRIMARY KEY,

 Short_name varchar(10),

 Long_name  varchar(50) CONSTRAINT dep_nam_unq UNIQUE NOT NULL,

 Head       varchar(30) CONSTRAINT dep_hed_unq UNIQUE NOT NULL,

 FAID       integer     CONSTRAINT dep_fac_frk REFERENCES FACULTY(FAID) NOT NULL);

-- Створення таблиці STGROUP

CREATE TABLE STGROUP (

 GRID    integer      CONSTRAINT grp_prk PRIMARY KEY,

 Num     char(5)      NOT NULL,

 Descr   varchar(255),

 DEID    integer      CONSTRAINT grp_dep_frk REFERENCES DEPARTMENT(DEID) NOT NULL,

 CUID    integer      CONSTRAINT grp_crs_frk REFERENCES COURSE(CUID) NOT NULL);

-- Створення таблиці STUDENT

CREATE TABLE STUDENT (

 STID        integer     CONSTRAINT std_prk PRIMARY KEY,

 Last_name   varchar(30) NOT NULL,

 Name        varchar(20) NOT NULL,

 Patro_name  varchar(20) NOT NULL,

 Num         char(10)    CONSTRAINT std_num_unq UNIQUE NOT NULL,

 Birthday    date        NOT NULL,

 Year        number(4)   NOT NULL,

 Country     varchar(20) NOT NULL,

 Contract    char(1)     CONSTRAINT prs_con_chk CHECK (Contract IN ( ’Т’, ’Н’)),

 External    char(1)     CONSTRAINT prs_ext_chk CHECK (External IN ( ’Т’, ’Н’)),

 GRID        integer     CONSTRAINT prs_grp_frk

                                    REFERENCES STGROUP(GRID) NOT NULL);

-- Створення таблиці COMPANY

CREATE TABLE COMPANY (

 COID     integer     CONSTRAINT com_prk PRIMARY KEY,

 Num      char(10)    CONSTRAINT com_num_unq UNIQUE NOT NULL,

 Name     varchar(40) NOT NULL,

 Head     varchar(20) NOT NULL,

 Post     varchar(20) NOT NULL,

 Address  varchar(50));

-- Створення таблиці AGREEMENT

CREATE TABLE AGREEMENT (

 AGID       integer   CONSTRAINT agr_prk PRIMARY KEY,

 Num        char(10)  CONSTRAINT agr_num_unq UNIQUE NOT NULL,

 Ass_date   date      NOT NULL,

 St_num     NUMBER(2) NOT NULL,

 From_date  date      NOT NULL,

 To_date    date      NOT NULL,

 COID       integer   CONSTRAINT agr_crs_frk REFERENCES COMPANY(COID) NOT NULL,

 FAID       integer   CONSTRAINT agr_fac_frk REFERENCES FACULTY(FAID) NOT NULL);

-- Створення таблиці TUTOR

CREATE TABLE TUTOR (

 TUID     integer     CONSTRAINT tut_prk PRIMARY KEY,

 Name     varchar(30) NOT NULL,

 Post     varchar(20),

 Address  varchar(30),

 Pas_ser  char(2)     NOT NULL,

 Pas_num  char(6)     NOT NULL,

 CONSTRAINT tut_ser_nmm_unk UNIQUE (Pas_ser, Pas_num));

-- Створення таблиці STUD_PRACTICE

CREATE TABLE STUD_PRACTICE (

 SPID      integer   CONSTRAINT stp_prk PRIMARY KEY,

 Duration  number(2) NOT NULL,

 In_date   date      NOT NULL,

 Out_date  date      NOT NULL,

 Mark      number(1) CONSTRAINT stp_mrk_chk CHECK (Mark BETWEEN 1 AND 5),

 STID      integer   CONSTRAINT stp_std_frk REFERENCES STUDENT(STID) NOT NULL,

 TUFID     integer   CONSTRAINT stp_tuf_frk REFERENCES TUTOR(TUID) NOT NULL,

 TUCID     integer   CONSTRAINT stp_tuc_frk REFERENCES TUTOR(TUID) NOT NULL,

 AGID      integer   CONSTRAINT stp_agr_frk REFERENCES AGREEMENT(AGID),

 PPID      integer   CONSTRAINT stp_prp_frk REFERENCES PLAN_PRACTICE(PPID) NOT NULL,

 CONSTRAINT stp_std_prp_unk UNIQUE (STID, PPID));

-- Створення таблиці REPORT

CREATE TABLE REPORT (

 REID      integer   CONSTRAINT rep_prk PRIMARY KEY,

 Text   CLOB (30K) NOT NULL,

 SPID integer  CONSTRAINT rep_stp_frk REFERENCES STUD_PRACTICE(SPID)

               CONSTRAINT rep_stp_unq UNIQUE NOT NULL);

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

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

4.2.2.1. Інформаційні запити, що повязані з проходженням практики

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

SELECT q.Name, c.Num, t.Name,
FROM   PLAN_PRACTICE p, COURSE c, QUALI_LEVEL q, PRAC_TYPE t
WHERE  p.CUID = c.CUID AND p.QLID = q.QLID AND p.PTID = t.PTID
ORDER BY q.Name, c.Num;

Запит 2.  Вивести назви баз практик, які є на факультеті компютерних наук.

SELECT c.Name AS ”Бази практики факультету комп’ютерних наук”
FROM   FACULTY f, COMPANY c, AGREEMENT a
WHERE  f.FAID = a.FAID AND c.COID = a.COID AND UPPER(f.ShortName) = ’CS’;

Запит 3.  Вивести роки проходження практик і оцінки студента Іванова

SELECT TO_CHAR(p.In_date,’YYYY’) AS ”Рік проходження практики”,
      
p.Mark                    AS ”Оцінка”
FROM   STUDENT s, STUD_PRACTICE p

WHERE  p.STID = s.STID AND UPPER(s.Last_name) = ’ІВАНОВ’;

      TO_CHAR(p.In_date,’YYYY’ = ’2003’;

4.2.2.2. Інформація організаційного характеру

Запит 1.  Скільки договорів було підписано на факультеті інформатики по рокам.

SELECT TO_CHAR(a.Ass_date,’YYYY) AS ”Рік підписання договору”,

      COUNT(*) AS ”Кількість підписаних договорів”
FROM   FACULTY f, COMPANY c, AGREEMENT a
WHERE  f.FAID = a.FAID AND c.COID = a.COID AND UPPER(f.ShortName) = ’CS’ 

GROUP BY TO_CHAR(a.Ass_date,’YYYY)
ORDER BY q.Name, c.Num;

Запит 2.  Хто є керівником підприємства, з яким підписано договір від 03.07.2003.

SELECT TO_CHAR(a.Ass_date,’YYYY) AS ”Рік підписання договору”,

      COUNT(*) AS ”Кількість підписаних договорів”
FROM   COMPANY c, AGREEMENT a
WHERE  c.COID = a.COID AND a.Ass_date = TO_DATE(’03/07/2003’, DD/MM/YYYY);

Запит 3.  Скільки студентів на 3 курсі факультету комп’ютерних наук

SELECT COUNT(*) AS ”Кількість студентів 3 курсу на факультеті CS

FROM   FACULTY f, DEPARTMENT a, STGROUP g, COURSE c, STUDENT s
WHERE  f.FAID = d.FAID AND d.DEID = g.DEID AND g.CUID = c.CUID AND

      g.GRID = s.GRID AND (f.ShortName) = ’CS’ AND c.Num = 3;

4.2.2.3. Інформація про керівників практики

Запит 1.  Хто був керівником від факультету практики студента Іванова з групи 401 у 2003 році.

SELECT tf.Name AS ”Керівник Іванова з групи 401 у 2003”

FROM   STUDENT s, GROUP g, STUD_PRACTICE p, TUTOR tf
WHERE  s.GRID = g.GRID AND s.STID = p.STID AND p.TUFID = tf.TUID AND
      UPPER(s.Last_name) = ’ІВАНОВ’ AND g.Num =401 AND 
      TO
_CHAR(p.In_date,’YYYY) = ’2003’;

Запит 2.  Хто був керівниками (від кафедри і від бази практики) практики студентів групи 505 у 2002 році

SELECT tf.Name AS ”Керівник від факультету”,

      tc.Name AS ”Керівник від бази практики”,
FROM   STUDENT s, GROUP g, STUD_PRACTICE p, TUTOR tf, TUTOR tc
WHERE  s.GRID = g.GRID AND s.STID = p.STID AND p.TUFID = tf.TUID AND
      p.TUCID = tc.TUID AND g.Num =505 AND TO_CHAR(p.In_date,’YYYY’ = ’2002’;

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

SELECT tf.Name AS ”Вони одночасно керували практикою від факультету і БП”

FROM   STUD_PRACTICE p, TUTOR tf, TUTOR tc
WHERE  p.TUFID = tf.TUID AND p.TUCID = tc.TUID AND p.TUFID = p.TUCID;

Висновки

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

Ціллю курсової роботи було проектування бази даних проходження практики студентами на прикладі факультету компютерних наук НАУ.

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

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

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

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

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


 

А также другие работы, которые могут Вас заинтересовать

2996. Анализ федеральной программы реформирования государственной службы 142 KB
  Государственная служба появилась в системе социальных отношений как необходимое условие для нормальной жизнедеятельности общества и как средство обеспечения других видов социальной деятельности. Вопросы управления государственной службой вк...
2997. Анализ внешней среды организации на примере ОАО Теплоизоляция 312 KB
  Объект исследования: предприятие ОАО Теплоизоляция Цель работы: дать анализ микро- и макроокружения ОАО Теплоизоляция и влияния внешней среды на организацию работы предприятия. Методы исследования: сравнение, сопоставление, анализа оценки и обоб...
2998. Установление буржуазной республики в Англии 17 века 67.5 KB
  Ситуация в Англии после первой гражданской войны. Пленением короля и падением последних роялистских опорных пунктов в Уэльсе в марте 1647 года закончилась первая гражданская война. Победа над королём вызвала рост авторитета армии Оливера Кромвеля, к...
2999. Акционерные общества и их роль в экономике 93 KB
  Приватизация в России проводилась как стратегическое преобразование, посредством которого «ничейную» якобы и потому малоэффективную собственность следовало передать действенным и эффективным собственникам, а те, обретя «чувство хозяи...
3000. Американский монетаризм, М. Фридмен и его концепция 60.5 KB
  Монетаризм представляет собой одно из наиболее влиятельных течений в современной экономической науке, относящееся к неоклассическому направлению. Он рассматривает явления хозяйственной жизни преимущественно под углом зрения процессов, протекающих в ...
3001. Основные понятия астрономии 109 KB
  Ответы к зачёту по астрономии. 1) Астрономия изучает движение небесных тел, их природу, происхождение. 2) Вселенная – часть материального мира, которая доступна исследованию астрономическими средствами, соответствующими достигнутому уровню разв...
3002. Разработка программы для решения неодномерных стационарных задач теплопроводности численным методом с использованием консервативно-разностной схемы 95 KB
  Базовый уровень подготовки инженера-энергетика в области информатики и вычислительной техники определяется необходимым набором знаний, умений и навыков в применении ЭВМ для решения различных технических задач. Специалисты этой категории, помимо умен...
3003. Повышение эффективности использования гусеничных сельско-хозяйственных тракторов тягового класса 3 путем их последова-тельного сочленения 231 KB
  Работа выполнена на кафедре Тракторы и автомобили Федерального государственного образовательного учреждения высшего профессионального образования Челябинский государственный агроинженерный университет. Научные руководители: доктор т...
3004. Азбука выживания в экстремальных ситуациях 89 KB
  Выбрав для своего  реферата эту тему, я ставила  перед собой цель создать, прежде всего, для себя, нечто, вроде самоучителя, справочника, настольного пособия для жизни в современном российском обществе. Очень часто в сложных и порой самых ...