Розробка програмного забезпечення курсового проектування

Этапы выбора эффективного цикла

Рисунок 1.

Задание 2.

Составить программу для одной задачи из ниже приведенного списка (номер задания получить у преподавателя). Программу набрать и отладить с помощью системы программирования Turbo Pascal. Исходный текст программы сохранить в своей папке.

Задания для программирования:

1. Вывести 20 одинаковых символов на экран.

2. Вывести на экран числа от 20 до 1.

3. Найти сумму ряда: 1, 2, ...20.

4. Вывести на экран таблицу функции Y=sin(х),где х изменяется от 10 до 90 с шагом 5 градусов.

5. Получить таблицу функции y=cos(5∙х), где х изменяется от 1 до 10 с шагом 0.5

6. Найти произведение чисел от 6.7 до 7.9 с шагом 0.4

Задание 1:

Рисунок 2.

Задание 2:

Рисунок 3.

Рисунок 4.

Вывод: Научился применять при решении задач определенный тип циклической конструкции.

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

Першим етапомє вибір СУБД, що задовольняє вимогам даної інформаційної системи.

Другийетап - розробка інтерфейса користувача. Інтерфейс повинен мати такі властивості: природність, узгодженість, дружність, принцип “зворотнього зв’язку”, простота, гнучкість, естетична привабливість, чіткість.

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

Інтерфейс може бути узгоджений в трьох аспектах: фізичному, синтаксичному і семантичному.

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

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

Семантична узгодженість відноситься до значення елементів, складових інтерфейсу. Наприклад, що означає “Вихід”? Де користувачі роблять запит на “Вихід” і що потім відбувається?

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

Використання знайомих користувачеві понять і образів (метафор) забезпечує інтуїтивно зрозумілий інтерфейс при виконанні його завдань. Разом з тим вони не повинні обмежувати їх машинну реалізацію повною аналогією з однойменними об’єктами реального часу. Користувачі зазвичай вивчають особливості роботи з новим програмним продуктом методом спроб і помилок. Ефективний інтерфейс повинен враховувати такий підхід. На кожному етапі роботи він повинен виконувати тільки відповідний набір дій і попереджати користувачів про ті ситуації, де вони можуть зашкодити системі або даним; ще краще, якщо у користувача є можливість відмінити або виправити виконані дії. Навіть за наявності добре спроектованого інтерфейсу користувачі можуть робити ті або інші помилки. Ці помилки можуть бути як “фізичного” типу (випадковий вибір неправильної команди або даних) так і “логічного” (ухвалення неправильного рішення на вибір команди або даних). Ефективний інтерфейс повинен дозволяти запобігати ситуаціям, які, ймовірно, закінчаться помилками. Він також повинен уміти адаптуватися до потенційних помилок користувача і полегшувати йому процес усунення наслідків таких помилок.

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

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

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

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

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

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

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

До візуальних атрибутів інформації, що відображається, відносяться:

· взаємне розташування і розмір об’єктів, що відображаються;

· палітра;

· засоби привертання уваги користувача.

Проектування розміщення даних на екрані передбачає виконання наступних дій:

· визначення складу інформації (елементів, компонентів, об’єктів тощо), яка повинна з’являтись на екрані;

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

· визначення взаємного розташування даних (чи об’єктів) на екрані;

· вибір засобів привертання уваги користувача;

· розробка макету розміщення даних на екрані;

· оцінка ефективності розміщення інформації.

Загальні принципи розташування інформації на екрані повинні забезпечувати для користувача:

· можливість переглядання екрану в логічній послідовності;

· простоту вибору потрібної інформації;

· можливість ідентифікації зв’язаних груп інформації;

· помітність виключних ситуацій (повідомлень про помилки або попередженя);

· можливість визначити, яка дія з боку користувача потрібна (і чи потрібна взагалі) для продовження виконання завдання.

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

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

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

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

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

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

Обов’язковим компонентом програмного забезпечення є меню “Допомога” (“Довідка”, “Help”), в якому розміщується інструкція користувача (з детальним описом принципів роботи з програмою). Крім того, необхідно додати меню “Автор”, що містить довідникову інформацію про розробника програмного забезпечення (прізвище, ім’я, по батькові, назва ВНЗ, факультет, група, рік розробки тощо).

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

8 Вказівки щодо розробки інформаційно-логічної моделі даних

База даних СУБД є реляційною базою даних. Така база даних складається з взаємозв'язаних реляційних таблиць. Реляційна таблиця є найпростішою двовимірною таблицею, яка складається з однотипних рядків (записів). Структура таблиці визначається сукупністю стовпців (полів), типом і розміром даних кожного стовпця, а також унікальним ключем таблиці. Значення унікального (первинного) ключа не можуть повторюватися в записах таблиці. Рядки таблиці однозначно ідентифікуються значенням ключа. Ключ може бути простим, складатися з одного поля, або складеним. Логічні зв'язки між таблицями в реляційній базі даних реалізуються за рахунок однакових полів в таблицях ,що зв'язуються.

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

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

8.1 Етапи проектування та побудови бази даних.

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

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

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

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

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

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

Мал.8.1

8.2Побудова інформаційно-логічної моделі даних

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

8.3 Інформаційні об'єкти

Інформаційний об'єкт — це інформаційний опис деякої суттєвості реального об'єкту, процесу, явища або події. Інформаційний об'єкт утворюється сукупністю логічно взаємозв'язаних реквізитів, що встановлюють якісні і кількісні характеристики деякої суттєвості предметної області. Прикладами інформаційних об'єктів можуть бути — ТОВАР, ПОСТАЧАЛЬНИК, ЗАМОВНИК, ПОСТАВКА, ВІДВАНТАЖЕННЯ СПІВРОБІТНИК, ВІДДІЛ, СТУДЕНТ, ВИКЛАДАЧ, КАФЕДРА і т.п.

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

Кожному інформаційному об'єкту потрібно присвоїти унікальне ім'я, наприклад, СТУДЕНТ, ПРЕДМЕТ, ВИКЛАДАЧ, КАФЕДРА.

Інформаційний об'єкт має безліч реалізацій — примірників. Наприклад, кожний примірник об'єкту СТУДЕНТ представляє конкретного студента. Примірник утворюється сукупністю конкретних значень реквізитів і повинен однозначно визначатися (ідентифікуватися) значенням ключа інформаційного об'єкту, що складається з одного або декількох ключових реквізитів. Таким чином реквізити поділяються на ключові і описові. Останні є функціонально залежними від ключа.

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

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

При графічному зображенні моделі даних кожний інформаційний об'єкт представляється прямокутником з позначенням його імені і ідентифікатора- ключа. Приклад такого зображення для інформаційних об'єктів ТОВАР і ПОСТАЧАННЯ показаний на мал. 7.2. Тут КОDТ (код товару) — простий ключ об'єкту ТОВАР, а КОDТ+КРOSТ (код постачальника) — складний ключ об'єкту ПОСТАЧАННЯ.

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

Реквізити кожного інформаційного об'єкту повинні відповідати вимогам нормалізації:

1) інформаційний об'єкт повинен містити унікальний ідентифікатор (ключ); Ключ є простим, якщо він складається з одного реквізиту або складеним, якщо з декількох;

2) всі описові реквізити повинні бути взаємозалежними, тобто між ними не може бути функціональних залежностей;

3) всі реквізити, що входять в складений ключ, повинні бути також взаємозалежні;

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

5) при складеному ключі описові реквізити повинні залежати цілком від всієї сукупності реквізитів, що утворюють ключ;

6) кожний описовий реквізит не може залежати від ключа транзитивно,тобто через інший проміжний реквізит.

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

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

8.4 Виділення інформаційних об'єктів предметної області.

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

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

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

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

2. Визначити функціональні залежності між реквізитами.

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

3. Вибрати всі залежні реквізити і вказати для них ключові реквізити (один або декілька).

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

4. Згрупувати реквізити, залежні від однакових ключових реквізитів. Отримані групи залежних реквізитів разом з ключовими реквізитами утворюють інформаційні об'єкти.

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

8.5 Приклади виділення інформаційних об'єктів

Розглянемо виділення інформаційних об'єктів на прикладі предметної області "Облік успішності та відвідування студентів".

8.6 Опис предметної області.

Нехай необхідно побудувати базу даних, що містить інформацію про відвідування на успішність учнів:

· Список факультетів закладу;

· Список кафедр;

· Список груп;

· Список існуючих спеціальностей;

· Списки студентів груп;

· Перелік предметів, що вивчаються;

· Викладацький склад кафедр, що забезпечують навчальний процес;

· Дані про відвідування студентами занять;

· Результати здачі іспитів (заліків) по кожному з проведених занять.

В результаті аналізу предметної області виявляються документи-джерела даних для створення бази даних.

8.7 Зв'язки інформаційних об'єктів.

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

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

.

8.8 Типи зв'язку інформаційних об'єктів

Зв'язки інформаційних об'єктів можуть бути різного типу:

• Одно-однозначні(1:1),

• Одно-багатозначні (1: М),

• Багато-багатозначні (M:М).

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

Мал.8.3 Графічне зображення одне-однозначного зв'язку

Одне-багатозначні зв'язки (1: М) — це такі зв'язки, коли кожному примірнику одного об'єкту (А) може відповідати декілька примірників іншого об'єкту (В), а кожному примірнику другого об'єкту (В) може відповідати тільки один примірник першого об'єкту (А). Графічне зображення одно- багатозначного зв'язку наведено на мал. 7.9

Головний об'єкт Підлеглий об'єкт

Мал.8.4.а Графічне зображення одне-багатозначного зв'язку

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

Багато-багатозначні зв'язки (М: М) — це такі зв'язки, коли кожному примірнику одного об'єкту (А) можуть відповідати декільком примірників другого об'єкту (В) і навпаки, кожному примірнику другого об'єкту (В) може відповідати теж декількох примірників першого об'єкту (А).

Графічне зображення зв'язку типуM : N показане на мал. 8.4.

Мал.8.4.б Графічне зображення багато-багатозначного зв'язку

Приклади визначення зв'язків між інформаційними об'єктами

Навчальний заклад містить декілька факультетів. Кожному факультетові належить декілька кафедр. Тому між об’єктами ФАКУЛЬТЕТ та КАФЕДРА можна встановити зв’язок “один до багатьох”.

Точно такий одно-багатозначний зв’язок буде між об’єктами ГРУПА та СТУДЕНТ, КАФЕДРА та ВИКЛАДАЧ, КАФЕДРА та СПЕЦІАЛЬНІСТЬ та ін.

У кожному факультеті є декан. Декан є викладачем, який викладає на цьому факультеті. Тому між об’єктами ВИКЛАДАЧ та ФАКУЛЬТЕТ можна встановити зв’язок “один до одного“. Точно такий зв’язок буде між об’єктами КАФЕДРА та ВИКЛАДАЧ (Зав. Кафедрою), ГРУПА та СТУДЕНТ (Староста Групи) або ГРУПА та ВИКЛАДАЧ (Куратор Групи).

Зв’язок “багато до багатьох” буде встановлено, наприклад, між об’єктами ПРЕДМЕТ_ДЛЯ_СПЕЦІАЛЬНОСТІ та УСПІШНІСТЬ. Кожному ПРЕДМЕТУ буде відповідати багато записів у об’єкту УСПІШНІСТЬ (студентів багато ж).

Також такий зв’язок буде між об’єктами ПРЕДМЕТ_ ДЛЯ_СПЕЦІАЛЬНОСТІ та ПРЕДМЕТ. Об’єкт ПРЕДМЕТ описує всі предмети, що читаються на даній кафедрі, а об’єкт ПРЕДМЕТ_ ДЛЯ_СПЕЦІАЛЬНОСТІ описує предмети, що читаються для конкретної спеціальності у конкретному семестрі.

У наведеній нижче таблиці представлено голові на підлеглі об’єкти в зв’язках між ними.

Інформаційно-логічна модель предметної області “Система обліку відвідування та успішності студентів”

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

Мал. 8.5. Інформаційно-логічна модель предметной області

“Система обліку відвідування та успішності студентів”

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

8.9 Логічна структура реляційної бази даних

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

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

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

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

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

Мал.8.6 Логічна структура реляційної бази даних предметної області

“Система обліку відвідування та успішності студентів”

9 Зміст розділів пояснювальної записки