ЗАВДАННЯ ДО КУРСОВОГО ПРОЕКТУ
Вступ
Метою курсового проектування є розвиток навичок роботи із проектировання інформаційних систем і закріплення знань, отриманих за час вивчення дисципліни «Бази даних».
Курсовий проект передбачає створення багатотабличної бази даних (БД) і набору функцій і процедур, що забезпечують інтерфейс користувача.
Виконання курсового проекту передбачає:
- аналіз заданої предметної області;
- складання вимог для предметної області;
- складання схеми концептуальної моделі даних,
- розробку структури реляційної бази даних,
- реалізацію запитів до БД,
- розробку інтерфейсу користувача,
- програмування завдання,
- складання контрольного приклада,
- оформлення пояснювальної записки.
Завдання на курсове проектування видається на початку 5 семестру. Варіант завдання вибирається за номером студента та погоджується з керівником. Завершення курсового проектування і його захист передбачений на 14 тижні.
1 теоретичні відомості
1.1 Збір і аналіз вимог
Збір й аналіз вимог є попереднім етапом концептуального проектування бази даних, у ході якого специфікації вимог користувачів аналізуються з метою з'ясування всіх необхідних відомостей.
На самому базовому рівні вимоги можна розкласти на робочі цілі, властивості об'єктів, правила й переваги.
Робочі цілі відбивають цілі створення системи й підхід, застосовуваний для досягнення цієї мети, Мети, функції, поводження, операції - все це є синонімами робочих цілей. Цілі - це найбільш важливий вид вимог, тому що вони відбивають основне призначення системи, відповідають на запитання, навіщо все це робиться.
У міру розробки вимог до даних для системи починають обрисовуватися об'єкти (сутності, таблиці, класи й т.д. ), які будуть існувати в системі, а потім й їхньої властивості. Властивості об'єктів - це друга категорія вимог й, імовірно, найбільш важлива для розроблювача БД. Властивості можуть бути стовпцями таблиці, атрибутами об'єктів або членами даних класу.
Правила - це умовні вимоги до властивостей об'єктів. Так, наприклад, один співробітник може працювати на декількох посадах.
Перевага - це умова, яка ставиться до властивості об'єкта, що виражає кращий стан. Наприклад, керівник зволів би знати, хто повинен пройти атестацію в заданий період. Можна також використати початкові значення або значення за замовчуванням - значення, які привласнюють системою, якщо іншого не визначено - для подання переваг.
До традиційних методів виявлення вимог ставляться використання інтерв'ю й анкет, спостереження й вивчення ділових документів
Використання інтерв'ю являє собою основний метод виявлення фактів і збору інформації. Інтерв'ю із замовниками дозволяють виявити по більшій частині вимоги, які виходять із «прецедентів». Якщо розроблювач не має достатній досвід у предметній області, можна також взяти інтерв'ю у відповідних експертів.
Існують два основних типи інтерв'ю: структуроване (формальне) і неструктуроване (неформальне). Структуроване інтерв'ю готується заздалегідь, відрізняється ясністю постановки питань, а багато питань можуть бути задані заздалегідь. Неструктуроване інтерв'ю більше нагадує неформальну зустріч, який не властиві заготовлені взапас питання або заздалегідь поставлені цілі.
Анкетування - ефективний спосіб збору інформації від багатьох замовників. Звичайно анкети використаються на додаток до інтерв'ю, а не замість них. У загальному випадку, анкетування менш продуктивно, чим використання інтерв'ю, оскільки в питання або можливі відповіді не можна внести додаткову ясність.
Анкета (або запитальник) повинна бути розроблена таким чином, щоб, по можливості, полегшити відповіді на питання. Зокрема, варто уникати питань із невизначеною множиною відповідей - більшість питань повинні ставитися до питань із замкнутим списком відповідей. Подібні питання можуть приймати три форми.
Багатоальтернативні питання. При відповіді на ці питання респондент повинен вказати одну або більше відповідей, вибравши їх із прикладеного списку. Крім того, іноді допускаються додаткові коментарі до питань зі сторони респондентів.
Рейтингові питання. При відповіді на цей тип питань респондент повинен виразити свою думку щодо висловленого твердження. Для цього можуть використатися такі рейтингові значення, як «абсолютно згодний», «згодний», «ставлюся нейтрально», «не згодний», «абсолютно не згодний» й «не знаю».
Питання з ранжируванням. Цей тип питань передбачає ранжирування відповідей за допомогою присвоювання їм послідовних номерів, процентних значень й використання інших засобів упорядкування.
Спостереження може виступати у двох формах.
· пасивне спостереження, у ході якого розроблювач спостерігає за різними видами ділової діяльності без втручання або прямої участі в них;
· активне спостереження, у ході якого розроблювач бере участь у діяльності й стає фактично частиною команди.
Щоб результати спостережень були представницькими, спостереження необхідно проводити протягом тривалого періоду часу, у різні тимчасові интервали й при різному робочому навантаженні (вибіркові періоди).
Вивчення документів і програмних систем є неоціненним методом виявлення як вимог типу прецедентів, так і вимог, зв'язаних зі знанням проблемної області. Цей метод використовується завжди, хоча він може стосуватися тільки окремих сторін системи.
Вимоги, зосновані на знанні предметної області, з'ясовуються також за допомогою вивчення журналів і підручників, які ставляться до даної сфери.
1.2 Розробка концептуальної й реляционной моделі
Поетапна допомога з концептуального проектування БД.
1. Визначення типів сутностей.
Можуть виникати наступні складності: 1) використання користувачами при складанні специфікацій синонімів («відділення» й «філія»), омонімів («програма2 може позначати курс навчання або план робіт), прикладів (уживання в специфікації не узагальненого працівника, а одного або декількох імен); 2) рішення про те, чим є оп-ределенный об'єкт - сутністю, атрибутом або зв'язком (приклад - об'єкт Сімейний шлюб).
2. Визначення типів зв'язків.
Можуть виникати наступні складності: 1) можливість присутності зв'язків, які поєднують більше двох сутностей, і рекурсивних зв'язків; 2) перевірка того, чи виділені всі зв'язки.
3. Визначення атрибутів і зв'язування їх з типами сутностей і зв'язків. Найпростіший метод виділення атрибутів - після ідентифікації чергової сутності або зв'язку відповістити на запитання «Яку інформацію потрібно зберігати про...».
Можуть виникати наступні складності: 1) визначення, простим або складовим є атрибут («адреса» може зберігатися як єдине ціле або може бути розбита на складові «місто», «вулиця» і т.д.); 2) виявлення атрибутів, значення яких можуть бути обчислені за допомогою інших атрибутів, і перевірка того, чи не можуть бути змінені надалі значення атрибутів, від яких залежить значення, яке обчислюється (приклад - курс валюти).
4. Визначення доменов атрибутів.
Домены повинні містити набір припустимих значень для атрибута й відомості про розмір і формат кожного атрибута.
5. Визначення атрибутів, які є потенційними й первинними ключами. Рекомендації з вибору первинного ключа серед потенційних:
· використати потенційний ключ із мінімальною кількістю атрибутів;
· використати той потенційний ключ, імовірність зміни значень якого мінімальна;
· використати той потенційний ключ, у якого мінімальна ймовірність втрати унікальності в майбутньому;
· використати потенційний ключ із мінімальною довжиною (у випадку текстових атрибутів);
· використати той потенційний ключ, з яким простіше працювати з погляду користувача.
6. Створення діаграми «сутність-зв'язок».
7. Обговорення локальних концептуальних моделей даних з кінцевими користувачами.
Спочатку створюються локальні концептуальні моделі даних (КМД), які утримають дані, необхідні конкретному користувачеві для прийняття рішень або виконання деякого завдання.
Вибір локального представлення залежить від масштабів предметної області. Для зручності проектування в окремому локальному представленны бажано використати 6-7 сутностей. Найбільше часто локальне представлення відповідає окремій програмі, наприклад, окремому функціональному завданню або окремому користувачеві, але воно може відповідати й цілій незалежній області даних, використовуваної декількома програмами.
При об'єднанні представлень використаються три основних концепції: ідентичність, агрегація й узагальнення.
Два або більше елементи моделі ідентичні, якщо мають однакове семантичне значення.
Агрегація дозволяє розглядати зв'язок між елементами моделі як новий елемент. При об'єднанні представлень агрегація зустрічається в трьох формах:
1) в одному представленнії агрегатний об'єкт визначений як єдине ціле, а у другому розглядаються його складові частини;
2) агрегатний об'єкт як єдине ціле не визначений в жодному з представлень, але в обох предствленнях розглядаються його складові частини;
3) один агрегатний об'єкт розглядається в різних представленнях, але по складу розрізняється.
Узагальненням називається абстракція даних, що дозволяє трактувати клас різних подібних типів об'єктів як один пойменований узагальнений тип об'єкта.
Процес об'єднання носить ітеративний характер, причина цього в тім, що в процесі об'єднання виявляються протиріччя між окремими локальними представленнями.
Правила перетворення моделі «сутність-зв'язок» у реляційні таблиці:
1) об'єкт із атрибутами перетворюється в таблицю;
2) якщо деякий набір атрибутів може бути використаний як ключ, то він вибирається ключем таблиці, інакше до таблиці додається атрибут, значення якого будуть однозначно визначити екземпляри об'єкта;
3) конкретизація об'єкта представляється таблицею, що містить ключ таблиці для об'єкта, що конкретизується, і додаткові атрибути конкретизації;
4) відношення 1:1 перетворюється шляхом приміщення ключа одного з об'єктів як додаткового атрибуту в таблицю другого об'єкта;
5) у відношенні 1:М у таблицю, що описує об'єкт, потужність із боку якого рівняється «багато», включається стовпець, що відповідає ключу об'єкта, потужність із боку якого рівняється «один», цей стовпець буде зовнішнім ключем;
6) для перетворення відношення М:N створюються три таблиці - по однієї для кожного об'єкта й таблиця-перетинання, що містить ключі двох інших таблиць.
У процесі нормалізації атрибути групуються в таблиці, що представляють об'єкти і їхні взаємозв'язки. Теорія нормалізації заснована на тім, що певний набір таблиць має кращі властивості при включенні, модифікації й видаленні даних, чим всі інші набори таблиць, за допомогою яких можуть бути представлені ті ж дані.
Введення нормалізації відношень при розробці концептуальної моделі даних забезпечує її працездатність. Ненормалізована модель може викликати певні труднощі реалізації прикладних програм, що модифікують БД.
Перший крок при нормалізації полягає в утворенні двомірної таблиці, що утримає атрибути. Для цього практично потрібно лише виключити повторювані групи.
Другий крок нормалізації полягає в тому, щоб виділити ключі й залежні від них атрибути. Кожен рядок таблиці, що перебуває в першій нормальній формі (1НФ), повністю залежить від сукупності ключових атрибутів. Для того щоб привести таблицю до 2НФ, потрібно виділити групи атрибутів, що залежать від частин складеного ключа. Ці групи можуть утворити окремі таблиці. Виділення з таблиці, що перебуває в 1НФ, таких таблиць, у яких неключові атрибути залежать тільки від ключа в цілому, називається приведенням до 2НФ.
На третьому кроці нормалізації потрібно виділити з таблиць, що перебувають в 2НФ, ті атрибути, які, хоча й залежать від ключа якої-небудь таблиці, проте, можуть існувати у БД незалежно від інших атрибутів цієї таблиці. Виділення атрибутів дозволяє уводити їхнього значення поза залежністю від взаємозв'язків, у яких вони беруть участь.
Приведення таблиць до першої, другої й третьої НФ послідовно усуває аномалії при включенні, видаленні й модифікації записів відповідної БД. Процес нормалізації дозволяє із глибше зрозуміти семантику атрибутів й їхніх взаємозв'язків й упорядковує проведення аналізу даних.
Процес нормалізації базується на аналізі взаємозв'язків між типами атрибутів і ніяк не пов'язаний з можливими значеннями їхніх екземплярів.
При проведенні нормалізації розроблювач БД повинен чітко уявляти собі семантику даних, використовуваних у відповідній предметній області. Залежно від того, як буде задана структура функціональних залежностей між атрибутами, зміниться й схема таблиць, що перебувають в 3НФ, одержувана після нормалізації.
1.3 Створення запитів на SQL
Опаратор запиту на вибірку виглядає в такий спосіб:
SELECT [предикат] { * | таблиця.* | [таблиця.]поле1 [AS псевдонім1]
[, [таблиця.]поле2 [AS псевдонім2] [, ...]]}
FROM табличне вираження [, ...]
[WHERE... ]
[GROUP BY... ]
[HAVІNG... ]
[ORDER BY... ]\
Оператор SELECT містить наступні частини:
предикат - один з наступних предикатів: ALL, DІSTІNCT або TOP. Використаються для вказівки, як обробляти дублюючі записи і яка кількість записів виводити в результаті виконання запиту, за замовчуванням - ALL;
* - використається для вибору всіх полів таблиці;
таблиця - ім'я таблиці, у якій перебуває обране поле;
поле1, поле2 - імена обраних полів, перераховуються через кому, у якості поля результуючого відношення може бути зазначене будь-яке вираження, що використає набір стандартних функцій (COUNT, AVG, SUM, MІ, MAX) і функцій, убудованих у СУБД;
псевдонім, псевдонім2 - імена, використовувані для заміни оригінальних імен виведених полів;
Речення FROM є обов'язковою частиною оператора SELECT. Це речення визначає список таблиць, на які посилається запит. У якості таблиці може бути використане ім'я збереженого запиту або вираження, що з'єднує таблиці за допомогою операції ІNNER JOІN, LEFT JOІN або RІGHT JOІN.
Синтаксис операції з'єднання:
FROM таблиця1 {ІNNER|LEFT|RІGHT} JOІN таблиця2
ON таблиця1.поле1 опер_порів таблиця2.поле2
де ІNNER JOІN означає, що в результуючу таблицю потраплять комбінації тільки тих рядків першої таблиці, які мають задовольняючому заданому операторові порівняння рядок у другій таблиці;
LEFT JOІN - всі рядки з першої таблиці й тільки «співпадаючі» із другої, а ті рядки першої таблиці, для яких немає «пари», поєднуються з порожнім записом; аналогічно RІGHT, але в результат попадають всі рядки із другої таблиці;
таблиця1, таблиця2 - імена таблиць, рядки з яких комбінуються;
поле1, поле2 - імена полів, які з'єднуються, повинні мати однакові типи даних, але не обов'язково однакові імена;
опер_порів - будь-який оператор порівняння: =, <, >, <=, >=, або <>.
WHERE дозволяє вказати умову, якій повинні задовольняти значення в рядках результуючої таблиці.
GROUP BY визначає список імен полів, за однаковим значенням яких буде виконаються угруповання рядків.
HAVІNG дозволяє відібрати з множини згрупованих рядків тільки ті, які задовольняють зазначеній умові.
ORDER BY дозволяє визначити умову впорядкованості рядків у результуючій таблиці. Така умова являє собою список полів, по яких необхідно впорядкувати рядки. Для кожного з атрибутів можна вибрати убутну (DESC) або зростаючу послідовність (ASC - за замовчуванням).
1.4 Рекомендації з розробки ирнтерфейса
Нижче перераховані поради, які дозволяють одержати зручний для користувача інтерфейс.
Інформація в назві вікна повинна недвозначно ідентифікувати назву звіту або форми.
В інструкціях повинна застосовуватися звична для користувачів термінологія, інструкції повинні бути короткими, а на випадок необхідності надання додаткової інформації варто передбачити спеціальні довідкові екрани; інструкції потрібно записувати в стандартному форматі, дотримуючись єдиного граматичного стилю.
Логічно зв'язані поля варто розташовувати разом, послідовність їх повинна бути логічно обґрунтованою й погодженою.
Не повинно бути областей з дуже малою або дуже великою концентрацією полів, поля потрібно розміщати через регулярні інтервали й вирівнювати їх по вертикалі й горизонталі; якщо екранна форма має еквівалентний вигляд на папері, то їхній зовнішній вигляд повинен бути відповідний.
Назви полів повинні бути знайомі користувачам і легко впізнаватися.
Повинні використатися тільки знайомі й зрозумілі терміни або скорочення, які вибьіраються із заздалегідь погодженого списку.
Виділення кольором може застосовуватися для найважливіших полів і повідомлень і повинно бути узгоджено в різних вікнах.
Простори й границі полів уведення даних повинні візуально виділятися.
Користувач повинен легко визначати, які операції доступні йому для переміщення курсору; звичайно це клавіші табуляції, клавіші зі стрілками або покажчик миші; рух курсору відбиває логічну послідовність дій кінцевого користувача в міру того як він читає документи з вхідними даними.
Повинні бути забезпечені засоби виправлення окремих помилкових символів і цілих полів і засоби виводу повідомлень про помилки при уведенні неприпустимих повідомлень.
Необов'язкові поля повинні бути явно відзначені написом або виділенням особливим кольором, такі поля варто розташовувати після обов'язкових для уведення полів.
Коли користувач поміщає курсор миші в чергове поле, то в деякому стандартному місці (наприклад, у рядку стану) варто вивести пояснювальне повідомлення із описом цього поля.
Завершення процесу заповнення форми не повинне бути автоматичним - доцільно виводити попереджуюче повідомлення, щоб при необхідності користувач зміг ще раз переглянути уведені їм дані.
Семантика даних повинна бути графічно очевидна.
Структура форми повинна спонукати до правильних дій - повинна полегшувати виконання правильних дій й утрудняти виконання помилкових; наприклад, поля зі списком, у які не можна вводити дані, а тільки вибирати зі списку, можна виділити іншим кольором; якщо поле припускає коротке уведення, зробити його вузьким або обмежити кількість символів, що вводяться.
Дія спеціальних клавіш (ESC і функціональні клавіші) повинна бути погодженою й однаковою - якщо клавіша ESC використається для виходу з форми, то вона повинна використатися тільки для виходу з форми, якщо для видалення запису використається деяка комбінація клавіш (Ctrl+D), те ця комбінація повинна використатися для цього й в інших формах.
Шрифти типу Arіal читаються легше, ніж шрифти із зарубками (Tіmes New Roman), напівжирний шрифт варто використати для виводу написів, заголовків і підписів.
Розташування й набір інструментів навігації повинні зберігатися незмінними у всіх формах; кнопки й команди меню, які з'являються більш ніж в одній формі, завжди повинні розташовуватися в одній і тій же послідовності й у тій же позиції, якщо це можливо.
Піктограми для ідентифікації об'єктів або операцій повинні бути одними й тими ж у всіх формах.
Графічний інтерфейс користувача надає можливості спростити роботу із застосуваннями БД:
· список, що розкривається, має перевагу перед полем уведення: 1) людям легше розпізнати що-небудь, чим відтворити, 2) розпізнати простіше, ніж правильно написати, 3) запобігає влучення в БД неочевидних помилок, пов'язаних із випадковим натисканням клавіш;
· групи перемикачів - можуть використатися там, де потрібно зробити вибір з фіксованої множини значень, зберігати в БД можна як число або як текст;
· прапорці - використаються для уведення підмножини значень із фіксованої множини (наприклад, види картин - акварель, масло, графіка).
ЗАВДАННЯ ДО КУРСОВОГО ПРОЕКТУ
2.1 Аналіз предметної області
Студент вивчає запропоновану в завданні предметну область. У результаті аналізу предметної області виявляються набір вимог, розділений на мети, властивості об'єктів і правила. Предметна область повинна включати не менш 8 об'єктів, обов'язкова наявність зв'язків «один-до-багатьох» й «багато-ко-багатьох».
Наприклад, для хірургічного відділення лікарні виявлені об'єкти ЛІКАР, ПАЦІЕНТ, ПАЛАТА. Атрибути об'єктів: ЛІКАР (Код, Прізвище, Посада, ДодатковіВідомості, ...), ПАЦІЄНТ (Код, Прізвище, Адреса, Дата надходження, Діагноз, Дата операції, ...), ПАЛАТА (Номер, Тип, Кількість ліжок). Між об'єктами ПАЦІЄНТ і ПАЛАТА існує зв'язок «багато-до-одного», між ЛІКАР і ПАЦІЄНТ – «один-до-багатьох».
Визначаються первинні ключі логічних записів, що зберігають задану информацію.
Якщо таблиці, що містять ці записи, мають аномалії при обробці даних, потрібно виявити ці аномалії, проаналізувати причини їхньої появи й виконати нормалізацію.
Далі варто побудувати графічну схему концептуальної моделі даних, що включає об'єкти, їхні атрибути й зв'язки між ними.
Наступним етапом є формування реляційної моделі даних, що описує структуру конкретних таблиць БД, поля цих таблиць (назва, тип, обмеження) і зв'язки між полями таблиць.
Потім необхідно сформулювати запити й реалізувати їх на SQL. Запити повинні використати наступні можливості SQL:
1. Вибір з декількох таблиць із сортуванням (наприклад, список пацієнтів, яких лікує заданий лікар);
2. Завдання умови відбору з використанням предиката LІKE (наприклад, знайти всіх пациєнтів, чиє прізвище починається на задану букву);
3. Завдання умови відбору з використанням предиката BETEWEEN (наприклад, список пацієнтів, прооперованих у заданий період);
4. Агрегатна функція без угруповання (наприклад, скільки пацієнтів надійшло в лікарню за останній тиждень?);
5. Агрегатна функція з угрупованням (наприклад, скільки пацієнтів прооперував кожний лікар?);
6. Використання предиката ALL або ANY (наприклад, хто з лікарів прооперировал найбільшу кількість хворих?);
7. Корельований підзапит (наприклад, для кожної лікарської спеціальності визначити лікаря, що лікує максимальну кількість пацієнтів);
8. Запит на заперечення (наприклад, хто з лікарів не оперував на цьому тижні?) Запит реалізувати у трьох варіантах: з використанням LEFT JOІN, предиката ІN і предиката EXІSTS;
9. Операція об'єднання UNІON із включенням коментарю в кожен рядок (наприклад, список лікарів з коментарем «Має максимальну кількість хворих», «Не має в цей час хворих»);
10. Відновлення даних, умова відбору формується з використанням підзапита з іншої таблиці (наприклад, у поле ДодатковіВідомості для відповідного лікаря записати «Прооперував найбільшу кількість хворих»).
Для кожного пункту написати по два запита.
Множина запитів повинна відповідати набору вимог для розглянутої предметної області.
На основі запитів з п. 5, 7 й 9 необхідно реалізувати звіти.
2.2 Визначення груп користувачів
Студент повинен проаналізувати склад користувачів, які будуть працювати із проектованою системою. Користувачі повинні бути розділені мінімум на 3 групи: привілейовані користувачі, що мають можливість звертатися до структури таблиць і працювати із реєстраційними даними (admіn), користувачі, що мають можливість редагувати таблиці предметної області й виконувати задану множину запитів (user1), і користувачі, що мають можливість тільки переглядати таблиці предметної області й виконувати обмежену множину запитів (user2). Для кожної групи користувачів необхідно описати надані їм можливості по роботі в системі.
Розроблювальна інформаційна система повинна включати засоби для зберігання й обробки информації про користувачів, їхні паролі і права. Доступ до цих даних мають тільки привілейовані користувачі. Крім того, БД повинна містити таблицю (Журнал) для зберігання наступних реєстраційних даних: дата, час, ім'я користувача, виконані дії (вхід у систему, уведення даних у таблицю, виконання запиту й т.д.).
Необхідно розробити діаграму варіантів використання, що показує відповідність між акторами предметної області й виконуваними ними функціями.
Інтерфейс користувача
Підключення до системи здійснюється після вказівки правильного імені й пароля користувача, після чого відкривається головна форма застосування. Головна форма повинна мати власне меню, власну панель інструментів, за допомогою яких можна отримувати інформацію про систему, допомогу, переглядати й змінювати дані в таблицях БД, виконувати задану обробку даних, друкувати задані звіти, а також (при наявності повноважень) модифікувати інформацію про користувачів і переглядати журнал реєстрації.
Перераховані дії повинні також виконуватися за допомогою елементів керування, розташованих у головній формі.
Список доступних таблиць, запитів і звітів залежить від поточного користувача інформаційної системи (ІС). Якщо поточний користувач має права адміністратора, то в список доступних таблиць також додаються таблиці Користувач і Журнал.
Система повинна передбачати контроль даних, що вводяться, для запобігання порушення цілісності БД (наприклад, пацієнта не може лікувати лікар, даних про якого немає в таблиці Лікар).
При натисканні кожної кнопки у формах ІС у таблицю Журнал заносяться дата, час і вид дії, виконаної поточним користувачем, а також ім'я цього користувача.
Перегляд і відновлення даних у таблицях, а також перегляд результатів запитів здійснюється за допомогою спеціально розроблених форм.
Таким чином, інтерфейс системи повинен забезпечувати виконання наступних функцій:
1) поділ прав користувачів, інформація про користувачів зберігається в самій базі даних;
2) уведення й редагування даних всіх вхідних таблиць (таблиці-довідники за допомогою стандартних елементів керування, таблиці з оперативними даними - за допомогою спеціально розроблених форм);
3) зручний перегляд зв'язаних даних;
4) завдання фільтра записів, що переглядаються, по декількох умовах, які довільно комбинуються;
5) перегляд результатів запитів з попереднім уведенням значень для формування умови;
6) друк звітів (простих і з угрупованням, угруповання забезпечується не в запиті, а в самому звіті, наприклад, список пацієнтів з поділом по лікарях із вказівкою кількості пацієнтів у кожного лікаря).
3 ВАРІАНТИ ЗАВДАНЬ
Варіант 1
Предметна область "Облік устаткування на підприємстві". Можливі види діяльності: облік закупівель устаткування із вказівкою характеристик, установка встаткування на робоче місце (можливе переміщення зі збереженням історії переміщення); закріплення за матеріально відповідальним співробітником; переоцінка; ремонт.
Варіант 2
Предметна область "Фермерське господарство". Можливі види діяльності: облік посаджених культур; реалізація врожаю; закупівля добрив і розрахунок з постачальниками; облік проведених робіт, використовуваної техніки.
Варіант 3
Предметна область "Хімчистка". Можливі види діяльності: прийом у клієнтів замовлень на виконання робіт над речами; облік роботи співробітників; закупівля й витрата реактивів; оплата праці співробітників.
Варіант 4
Предметна область "Спортивна програма". Можливі види діяльності: облік програм з підготовлених співробітниками сюжетів; вихід програм в ефір; гості програми; ведення довідників про змагання і їхніх учасників (результати, досягнення, біографія, цікаві факти).
Варіант 5
Предметна область "Історичний довідник". Можливі види діяльності: ведення інформації про існувавші й існуючі у цей час держави, їхні столиці; одержання інформації про правителів й їхні правління, про війни, битви, історичні події, історичні особистості.
Варіант 6
Предметна область "Біржа праці". Можливі види діяльності: постановка на облік безробітних з описом їхнього послужного списку; виплата грошової допомоги; перенавчання; облік наявних по спеціальностях роботодавців і вакансій; облік зроблених пропозицій про роботу.
Варіант 7
Предметна область "Тестування". Можливі види діяльності: ведення бази питань, розподілених по предметах, темах і рівнях, і відповідей (можливих і правильних) із вказівкою авторів питань; облік виконаного тестування для кожного обучаємого з інформацією про отримані ним питання, надані відповіді і загальні результати; формування тестів з наявних питань.
Варіант 8
Предметна область "Реклама в комерційному виданні". Можливі види діяльності: облік прийнятих для реклами замовлень із вказівкою співробітника, що оформив замовлення; облік характеристик реклами із замовлення й додаткових умов; облік публікацій, що вийшли, і поетапної оплати замовлень; облік оплати співробітникам бонусу за принесені замовлення.
Варіант 9
Предметна область "Телефонна компанія". Можливі види діяльності: облік абонентів з можливими пільгами; облік зроблених ними дзвінків по різним напрямкам; розрахунок вартості дзвінка з урахуванням напрямку, дати й часу доби й тривалості; оплата абонентами послуг.
Варіант 10
Предметна область "Приймальна комісія ВНЗ". Можливі види діяльності: прийом заяв від абітурієнтів з обліком отриманих при зовнішньому тестуванні оцінок, пільг; облік прийнятих документів; ведення бази даних наявних спеціальностей на різних факультетах і по різних формах навчання.
Варіант 11
Предметна область "Концертний зал". Можливі види діяльності: проведення виступів у рамках гастролей різних виконавців; реклама концертів; облік продажів квитків з урахуванням розцінок по категоріях місць; розрахунок з виступаючими й забезпечуючими проведення концерту.
Варіант 12
Предметна область "Банкетний зал". Можливі види діяльності: прайс-лист можливих блюд по категоріях; прийом замовлень на проведення банкетів з описом замовлених блюд; ведення довідника витрат продуктів для блюд; закупівля продуктів; можливо, поетапна оплата замовлень; облік участі співробітників у забезпеченні банкета.
Варіант 13
Предметна область "Ремонтно-будівельна бригада". Можливі види діяльності: облік прийнятих замовлень на виконання різних робіт на об'єктах; облік виконаних робітниками робіт, оплата праці робітників; закупівля матеріалів, розрахунок з постачальниками.
Варіант 14
Предметна область "Служба таксі". Можливі види діяльності: облік роботи водіїв на різних машинах по змінах; облік зданого виторгу; ведення довідника за вартістю проїзду в різних напрямках; оплата водієм за використання рації; облік прийнятих і виконаних замовлень.
Варіант 15
Предметна область "Аварійна служба". Можливі види діяльності: облік робочих змін працівників побригадно; облік заявок на проведення робіт; облік витрачених матеріалів при ліквідації аварій; оплата праці з розрахунком преміальних залежно від тривалості й складності виконаних робіт.
Варіант 16
Предметна область "Облік програмного забезпечення на комп'ютерах організації". Можливі види діяльності: облік комп'ютерів і додаткового встаткування з описом їхніх характеристик на робочих місцях по приміщеннях; облік установлених програмних продуктів, їхніх версій і наявності ліцензії; ведення паролів на право використання різних продуктів користувачами різних категорій.
Варіант 17
Предметна область "Податкова інспекція". Можливі види діяльності: облік організацій, що займаються різними видами діяльності; облік наявності актуальної ліцензії (зберігання історії надання ліцензій); призначення інспектора для організації; облік необхідної звітності з описом періодичності; облік зданої документації; облік оплати різних податків.
Варіант 18
Предметна область "Пасажирські залізничні перевезення". Можливі види діяльності: ведення розкладу поїздів із вказівкою всіх проміжних станцій; облік фактичних відправлень і прибуттів, облік роботи співробітників на конкретних рейсах; облік проданих квитків по різних типах вагонів.
Варіант 19
Предметна область "Судочинство". Можливі види діяльності: облік прийнятых до розгляду справ з описом статей, обставин, проведених засідань й їхніх учасників; облік запитів, зроблених по кожній справі, і документів, залучених до справи.
Варіант 20
Предметна область "Митниця". Можливі види діяльності: облік проїзджаючих через границю вантажів з описом вхідних у них товарів, прикладених документів й вказівкою власника; ведення довідника розмірів мит по категоріях й обсягу товарів; облік внесеної оплати мита.
Варіант 21
Предметна область "Будинок дитячої творчості". Можливі види діяльності: облік роботи секцій із вказівкою керівників й учасників; ведення розкладу з обліком приміщень; облік фактичних занять; опис заходів за участю секцій; облік оплати занять учасниками секцій.
Варіант 22
Предметна область "Курси іноземних мов". Можливі види діяльності: облік роботи груп із вказівкою викладачів і студентів й описом мови й рівня; ведення розкладу; облік фактичних занять; облік оплати занять студентами.
Варіант 23
Предметна область "Ведення статистики захворюваності". Можливі види діяльності: облік зареєстрованих захворювань по регіонах, медустановам, ділянкам, лікарям, категоріям захворювань, пацієнтам і категоріям пацієнтів.
Варіант 24
Предметна область "Зелентрест". Можливі види діяльності: облік проведених робіт для різних об'єктів із вказівкою використаного інструмента; облік вирощених, реалізованих і висаджених на об'єктах рослин; облік закупівлі допоміжних матеріалів й їхньої витрати при проведенні робіт.
Варіант 25
Предметна область "Дорожня служба". Можливі види діяльності: облік проведених робіт працівниками побригадно на різних об'єктах із вказівкою витрачених матеріалів, використаного інструменту й транспорту; облік оплати праці працівникам.
Варіант 26
Предметна область "Школа". Можливі види діяльності: облік учнів по класам; облік роботи вчителів по різних предметах і по кабінетах; облік проведених у школі заходів; ведення розкладу; облік атестаційних категорій учителів, якы отримуються поетапно.
Варіант 27
Предметна область "Швидка допомога". Можливі види діяльності: облік роботи співробітників по бригадах, по змінах та по машинах; облік прийнятих викликів, пацієнтів, використаних ліків і встановлених діагнозів.
Варіант 28
Предметна область "Електрослужба". Можливі види діяльності: облік оформлених абонентами договорів; облік витраченої абонентами енергії; формування вартості витраченої енергії по різних тарифах; облік ліквідації аварій на підлеглихоб'єктах; оплата використаної електроенергії.
Варіант 29
Предметна область "Футбольна ліга". Можливі види діяльності: облік проведених командою ігор у різних змаганнях; облік результатів та опис голів (хто й коли забив); облік тренерської роботи різних тренеров, переходів спортсменів; облік участі спортсменів у зборах; облік отриманих травм.
Варіант 30
Предметна область "Автомайстерня". Можливі види діяльності: облік виконаних робіт з ремонту машин, їхніх окремих механізмів з розподілом робіт між працівниками; облік внесеної оплати роботи власником; ведення прайс-листа ремонтних робіт; облік інструмента.
4 ЗМІСТ ПОЯСНЮВАЛЬНОЇ ЗАПИСКИ
У записку входять:
1) титульний аркуш;
2) завдання за обраним варіантом;
3) результати аналізу предметної області з описом вимог, правил предметної області, об'єктів, їхніх атрибутів і взаємозв'язків між ними;
4) опис виконаних етапів проектування БД (обґрунтування вибору первинних ключів, аналіз аномалій, нормалізація, опис концептуальної моделі даних, опис реляційної моделі даних);
5) опис способів реалізації запитів і звітів;
6) опис груп користувачів ІС, засобів керування поділом доступу й функціональних можливостей кожної групи;
7) опис інтерфейсу ІС;
8) керівництво користувача;
9) опис контрольного приклада;
10) повідомлення програми, причини, які їх викликали, і реакція користувача на повідомлення;
11) тексти програм з необхідними коментарями;
12) список літератури.
Оформлення пояснювальної записки виконується відповідно до вимог, пропонованими до оформлення технічної документації.
5 СТРОКИ ЗДАЧІ КУРСОВОго проекту
| № п/п | Етап | Строк виконання (тиждень) | Кількість балів |
| Одержання й уточнення завдання | - | ||
| Опис вимог до предметної області | |||
| Визначення груп користувачів й їхніх прав | |||
| Розробка концептуальної моделі | |||
| Розробка реляционной моделі | |||
| Складання запитів | |||
| Реалізація інтерфейсу | 8-9 | ||
| Реалізація запитів | 10-11 | ||
| Реалізація звітів | |||
| Оформлення пояснювальної записки | |||
| Захист курсової роботи |
У випадку несвоєчасної здачі етапу кількість балів зменшується пропорційно строку запізнення.
ЗМІСТ
Вступ. 4
1 Теоретичні відомості 5
1.1 Збір і аналіз вимог. 5
1.2 Розробка концептуальної й реляционной моделі 6
1.3 Створення запитів на SQL.. 8
1.4 Рекомендації з розробки ирнтерфейса. 9
2 Завдання до курсового проекту. 11
2.1 Аналіз предметної області 11
2.2 Визначення груп користувачів. 12
2.3 Інтерфейс користувача. 12
3 Варіанти завдань. 13
4 Зміст пояснювальної записки. 17
5 Строки здачі курсового проекту. 18