Бази даних. Створення форм і звітів (на прикладі ACCESS). Опис програми
ведення електронної шкільної документації.
У дипломній роботі розглянуті загальні питання баз даних різних моделей,
принципи організації текстових, мережевих і реляційних баз. Описано підхід до
проектування баз даних. На конкретному прикладі бази даних для ведення
електронної шкільної документації показаний процес конструювання та побудови
бази даних. Розкрито прийоми створення екранних форм і звітів.
Докладно описана методика роботи з програмою. Програма може бути використана
для практичної роботи в школах та інших навчальних закладах на допомогу шкільному
адміністратора.
Розглянуто питання санітарно-гігієнічних вимог при роботі з комп'ютером.
Введення
Дипломна робота присвячена аналізу проектування баз даних, а також висвітлення
методів побудови форм і звітів на прикладі побудови програми ведення
електронної документації навчального закладу. Як інструмент побудови
бази даних використаний Microsoft Access. З самого початку цю СУБД відрізняла
простота використання в поєднанні з широкими можливостями з розробки
закінчених додатків.
Актуальність теми
В даний час, не дивлячись на підвищення комп'ютеризації суспільства, у сфері
освіти до цих пір немає засобів, що дозволяють в достатній мірі
автоматизувати процес ведення документації та звітності.
Однією з складових завдань можна розглядати проблему складання розкладу
навчального процесу, а також оперативну коригування розкладу при
виникненні необхідності в цьому.
Про своєчасності та актуальності розглянутої проблеми говорить той факт, що
більшу частину свого часу адміністратори закладів і викладачі витрачають на
оформлення різної документації та звітів. Величезна кількість навчальних
закладів та відсутність пропозицій в даній сфері гарантують високу
потреба в даному продукті.
Бази даних (БД) складають в даний час основу комп'ютерного забезпечення
інформаційних процесів, що входять практично в усі сфери людської
діяльності.
Дійсно, процеси обробки інформації мають загальну природу і спираються на
опис фрагментів реальності, виражене у вигляді сукупності взаємопов'язаних
даних. Бази даних є ефективним засобом представлення структур даних
і маніпулювання ними. Концепція баз даних припускає використання
інтегрованих засобів зберігання інформації, що дозволяють забезпечити
централізоване керування даними та обслуговування ними багатьох користувачів. При
це БД повинна підтримуватися в середовищі ЕОМ єдиним програмним забезпеченням,
званим системою управління базами даних (СУБД). СУБД разом з прикладними
програмами називають банком даних.
Одне з основних призначень СУБД - підтримка програмними засобами
уявлення, що відповідає реальності.
Предметною областю називається фрагмент реальності, що описується або
моделюється за допомогою БД і її додатків. У предметної області виділяються
інформаційні об'єкти - ідентифікуються об'єкти реального світу, процеси,
системи, поняття і т.д., відомості про які зберігаються в БД.
Деякі відомості про типи даних
Етапах реалізації баз даних відповідають рівні опису предметної області:
реальність в тому вигляді, як вона існує; концептуальне опис реальності;
подання опису у вигляді формального тексту і фізична реалізація БД на
машинних носіях.
Для введення в ПК отримане опис має бути представлено в термінах
спеціальної мови опису даних, що входить в комплекс засобів СУБД.
Просте (елементарне) дане - це найменша семантично значуща
пойменована одиниця даних (наприклад, ПІБ, посада, адреса і т.д.). Значення
простого даного описує представлену їм характеристику об'єкта для кожного
екземпляра об'єкта. Імена простих даних зберігаються в описі БД, у той час як
їх значення запам'ятовуються в самої БД.
Сукупність простих даних можна об'єднати в складений даний двома способами.
По-перше, можна з'єднати кілька різнотипних даних. Наприклад, дане АНКЕТА
складається з даних табельний номер, ПІБ, рік народження, ПОЛ, ПОСАДА, ЗАРПЛАТА.
За цим принципом утворюється структурний дане або дане типу структура.
Опис структури складається з переліку її складових частин, значення - з
значень складових її даних. По-друге, складеного дане може об'єднувати
сукупність однотипних даних (список співробітників, що послужний список співробітника і
тощо). Складений дане цього типу називається масивом. В описі масиву
достатньо вказати опис одного елемента, значення масиву представляється
однорідним списком значень його елементів.
У загальному випадку складові дані представляють собою об'єднану під одним ім'ям
сукупність даних будь-яких типів, у тому числі структур і масивів, з довільною
глибиною вкладеності складових даних (рис.1).
Елементи масиву можуть ідентифікуватися ключем - даними, значення якого
взаємно однозначно визначають примірники елементів.
Складові типи даних являють ієрархічні зв'язку значень даних у БД.
Представлення предметної області у вигляді структур даних з ієрархічними зв'язками
носить назву ієрархічної моделі даних. У загальному випадку в базі можуть бути
визначені також мережні зв'язки, що дозволяють описати мережу - орієнтований граф
довільного виду. Представлення предметної області у вигляді мережевих структур
даних загального вигляду називається мережний моделлю даних. Мережеві зв'язку реалізуються
шляхом ототожнення окремих даних БД.
Процес побудови концептуального опису з урахуванням всіх необхідних чинників
називається процесом проектування БД.
Інтерфейс з БД.
Інтерфейс визначає перехід від подання даних у БД до подання,
прийнятим серед користувачів, і назад. Вобщем випадку користувачі
представляють дані у вигляді документів різних видів, від довільних текстів
до довідок і таблиць фіксованого формату.
Інтерфейс доступу з кінцевим користувачем охоплює комплекс технічних,
організаційних і програмних рішень, що забезпечують в підсумку уніфікованість,
гарну зрозумілі і надійність взаємодії кінцевого користувача з
різними моделями персональних комп'ютерів.
Під документом розуміється довільний структурований текст, який може
бути представлений на алфавітно - цифрових друкувальних пристроях. При цьому під
структурою тексту розуміється структура взаємозв'язків даних, що складають текст.
В процесі проектування, як правило, виникає необхідність точного обліку
структур документів. Для повного уявлення цих структур можуть
використовуватися кошти опису даних БД. Тим самим полегшується процес
зіставлення БД і документів при організації інтерфейсу.
Спільна реалізація БД та інтерфейсу на єдиній концептуальній основі
передбачає зіставлення відповідних понять концептуального опису з
поняттями користувачів.
Конкретні функціональні вимоги користувачів і передбачуване їх
забезпечення відображаються поняттям користувацького подання даних. В
загальному випадку користувальницьке подання включає так зване локальне
зовнішнє представлення функцій обробки даних, а також визначення форматів
вхідних та вихідних даних.
База даних (БД) - іменована сукупність даних, яка відображає стан
об'єктів і їх відносин у розглянутій предметній області;
- Система управління базами даних (СУБД) - сукупність мовних та програмних
коштів, призначених для створення, ведення і сумісного застосування БД
багатьма користувачами;
- Банк даних (БНД) - заснована на технології БД система програмних, мовних,
організаційних і технічних засобів, призначених для централізованого
накопичення і колективного використання даних;
- Інформаційна система (ІС) - система, що реалізує автоматизований збір,
обробку та маніпулювання даними і включає технічні засоби обробки
даних, програмне забезпечення і відповідний персонал.
Функціонально - повна СУБД повинна включати до свого складу засобу,
забезпечують потреби користувачів різних категорій на всіх етапах
життєвого циклу систем БД: проектування, створення, експлуатації.
БАЗИ ДАНИХ
Текстові бази даних.
Об'єктами зберігання в текстових БД є тексти. Під текстом будуть розумітися
неструктуровані дані, побудовані з рядків.
Основною метою будь-якої текстової БД є зберігання, пошук і видача документів,
що відповідають запиту користувача. Такі документи прийнято називати
доречними. З огляду на те, що автоматизований пошук документів на
природних мовах досить ускладнений, виникає питання про проектування
деяких формальних мов, призначених для відображення основного
смислового змісту документів і запитів до БД.
Такі мови називають інформаційно-пошуковими. В даний час розроблено
досить велика кількість інформаційно-пошукових мов, які відрізняються
не тільки за своїми образотворчим властивостям, а й за ступенем семантичної
сили.
В основі підходу до побудови класифікаційних мов лежить уявлення про
те, що накопичені знання можуть бути розділені на взаємовиключні класи і
підкласи. Існує система правил, якою повинен підкорятися будь-яку мову
класифікаційного типу, зокрема:
Розподіл галузей знань на класи та підкласи проводиться по одній підставі;
Підкласи повинні виключати один одного;
При діленні класів на підкласи повинна дотримуватися безперервність.
Інформаційно - пошукові мови, що отримали назву дескріпторних, засновані на
застосування принципів координатного індексування, при якому смислове
зміст документа може бути з певним ступенем точності і повноти
задано списком ключових слів, що містяться в тексті.
Дескріпторние мови прив'язані до лексики текстів. Ключові слова з текстів
вибираються виходячи з різних цілей, відповідно, критерії вибору можуть
відрізнятися. Для побудови дескріпторного мови критерієм відбору ключових слів,
як правило, служать інформативність слова і частота його зустрічальності в тексті.
Універсальними структурами дескріпторного мови є лексичні одиниці,
парадигматичні та синтагматичні відносини.
Лексична одиниця - найменша смислова одиниця, що задається при побудові
мови.
У більшості автоматизованих інформаційних систем при індексуванні
документів і запитів застосовується контроль за допомогою тезауруса. Контроль може
здійснюватися в автоматизованому або ручному режимі. По суті справи тезаурус
являє собою словник - довідник, в якому присутні всі лексичні
одиниці дескріпторного інформаційно пошукового мови з введеними
парадигматичними відносинами. Парадигматичні відносини можуть задаватися
як:
Відносини вид - рід (вищестоящий дескриптор);
Відносини рід - вид (нижчестоящі дескриптори);
Синоніми;
Асоціативні зв'язку
У тезауруси містяться дескриптори і недескріптори, хоча існують тезауруси
тільки з дескрипторів.
Як дескриптори, так і недескріптори приводять до єдиної граматичній формі. Як
правило, дескриптори вживаються у формі іменників або іменних
словосполучень. Тезаурус може бути побудований за принципом дескріпторних статей,
складалися з заголовного дескриптора і списку дескрипторів і недескріпторов з
позначенням парадигматичних відносин. Тезаурус може бути двомовним. У цьому
разі еквівалентний дескриптор іноземною мовою повинен бути позначений.
Парадигматичні відносини являють собою внетекстовие відносини між
лексичними одиницями. На їх підставі відбувається угруповання лексичних
одиниць у парадигми.
Синтагматичні відносини являють собою відносини лексичних одиниць в
тексті, тобто вони виражають семантику контексту.
При перекладі основного смислового змісту документів і запитів з
природної мови на дескріпторний інформаційно - пошуковий мова існують
певні правила, які називаються системою індексування. Результатом перекладу
документа є пошуковий образ документа, а запиту - пошуковий образ
запиту.
З перерахованих інформаційно - пошукових мов саме дескріпторние мови
найкращим чином пристосовані для опису документів і запитів при
автоматизованому пошуку в текстових БД. Мови ці мають такий
перевагою, як гнучкість, відкритість, близькість до природної мови; це
мови дворівневі (рівень ключових слів і рівень дескрипторів).
Дескріпторние інформаційно - пошукові мови дозволяють формулювати документи
і запити в різних термінах. До основних недоліків мов даного класу можна
віднести недостатню повноту опису смислового змісту документів і
запитів.
Системи, контрольовані тезаурусом, містять процедури як морфологічного, так
і синтаксичного аналізу текстів. Однак при проектуванні ряду БД виникає
необхідність в додаванні ще одного етапу аналізу тексту природною мовою
- Аналізу його семантичної структури. Прикладом таких баз можуть бути БД,
орієнтовані на пошук за зразками. У подібних семантичних системах намагаються
моделювати процес розуміння закінчених описів фрагментів дійсності,
наприклад патентів, оповідань, епізодів та ін, виражених у вигляді текстів. Як
правило, розуміння тексту трактується як процес вилучення з нього істотною
з точки зору системи інформації. Вилучення інформації вводиться в базу
знань, що представляє собою динамічну інформаційну модель реального світу.
Потім система здатна відповідати на запити щодо подій, фактів,
явищ, викладених у текстах.
Пакети прикладних програм, призначені для введення, обробки, пошуку та
оновлення текстів, називають інформаційно-пошуковою системою (ІПС).
Мережні бази даних.
Одним з найбільш ефективних методів представлення знань є мережні
моделі.
В основі моделі лежить поняття мережі, вершинами якої є поняття,
відповідні об'єктів, подій, процесів, явищ, а дугами - відносини
між цими поняттями.
Вузли та зв'язку можна наочно зображувати у вигляді діаграм.
Якщо вершини мережі не мають своєї внутрішньої структури, то мережу буде простою.
Якщо ж вершини володіють деякою структурою у вигляді мережі, то мережа називається
ієрархічна. Якщо відносини між вершинами однакові, то мережу однорідна, в
Інакше - мережа неоднорідна. Характер відносин, що приписується дуг,
може бути різний. Відповідно до цього виділяють такі типи мереж:
Функціональні мережі відображають декомпозицію певної обчислювальної або
інформаційної процедури, а дуги показують функціональний зв'язок між
декомпонірованнимі частинами; ця мова недостатньо багатий для представлення
знань;
Сценарії, що представляють собою однорідні мережі з єдиним ставленням у вигляді
нестрогого порядку. Семантика відносин може бути різною. Відношення може
трактуватися як класифікує, тимчасове і т.п. Сценарії часто використовуються
при формуванні допустимих планів по досягненню мети;
Семантичні мережі використовують відносини різних типів, а вершини в них можуть
мати різну інтерпретацію, По суті справи семантична мережа є класом, в
який включаються як сценарії, так і функціональні мережі. Найбільш часто
використовуються в мережі зв'язку типу "це є". Вони дозволяють побудувати у вигляді мережі
ієрархію понять,в яких вузли нижчих рівнів успадковують властивості вузлів більш
високих рівнів. Саме таким механізмом переносасвойств обумовлена
ефективність семантичних мереж.
Реляційні бази даних.
Бази даних називаються реляційними, якщо керування ними засноване на
математичної моделі, що використовує методи реляційної алгебри та реляційного
обчислення. С. Дейт дає наступне неформальне визначення реляційних баз
даних:
Вся інформація в базі даних представлена у вигляді таблиць.
Підтримуються три реляційних оператора - вибору, проектування та об'єднання,
за допомогою яких можна отримати будь-які необхідні дані, закладені в
таблиці.
Доктор І.Ф. Коддом, автор реляційної моделі, розробив цілий список критеріїв,
яким повинна задовольняти реляційна модель. Опис цього списку, часто
званого "12 правилами Кодда", вимагає введення складної термінології і
виходить за рамки дипломної роботи. Проте можна назвати деякі правила
Кодда для реляційних систем. Щоб вважатися реляційної по Коддом, система
управління базами даних повинна:
Представляти всю інформацію у вигляді таблиць;
Підтримувати логічну структуру даних, незалежно від їх фізичного
подання;
Використовувати мова високого рівня для структурування, виконання запитів і
зміни інформації в базах даних;
Підтримувати основні реляційні операції (вибір, проектування і
об'єднання), а також теоретико-множинні операції, такі як об'єднання,
перетин і доповнення;
Підтримувати віртуальні таблиці, забезпечуючи користувачам альтернативний
спосіб перегляду даних у таблицях;
Розрізняти в таблицях невідомі значення (nulls), нульові значення і пропуски в
даних;
Забезпечувати механізми для підтримки цілісності, авторизації, транзакцій і
відновлення даних.
Перше правило Кодда свідчить, що вся інформація в реляційних базах даних
представляється значеннями в таблицях. У реляційних системах таблиці складаються з
горизонтальних рядків і вертикальних стовпців. Всі дані подаються в
табличному форматі - іншого способу переглянути інформацію в базі даних не
існує. Набір пов'язаних таблиць утворює базу даних. Таблиці в реляційної
базі розділені, але повністю рівноправні. Між ними не існує ніякої
ієрархії.
Кожна таблиця складається з рядків і стовпців. Кожен рядок описує окремий
об'єкт або сутність - учня, предмет, день тижня або що-небудь інше.
Кожен стовпець описує одну характеристику об'єкта - ім'я чи прізвище учня,
його адресу, оцінку, дату. Кожен елемент даних, або значення, визначається
перетином рядка і стовпця. Щоб знайти потрібний елемент даних, необхідно
знати ім'я містить його таблиці, стовпець і значення його первинного ключа, або
унікального ідентифікатора.
У реляційної бази даних існує два типи таблиць - призначені для користувача таблиці
і системні таблиці. Користувальницькі таблиці містять інформацію, для підтримки
якої власне і створювалися реляційні бази даних. Системні таблиці
звичайно підтримуються самої СУБД, проте доступ до них можна отримати так само, як
і до будь-яких інших таблиць. Можливість отримання доступу до системних таблиць,
за аналогією з будь-якими іншими таблицями, складає основу іншого правила Кодда
для реляційних систем.
Реляційна модель забезпечує незалежність даних на двох рівнях -
фізичному і логічному. Фізична незалежність даних означає з точки зору
користувача, що подання даних абсолютно не залежить від способу їх
фізичного зберігання. Як наслідок цього, фізичне переміщення даних жодним
чином не може вплинути на логічну структуру бази даних. Інший тип
незалежності, що забезпечується реляційними системами - логічна незалежність
- Означає, що зміна взаємозв'язків між таблицями і рядками не впливає на
правильне функціонування програмних додатків і поточних запитів.
У визначенні системи управління реляційними базами даних згадуються три
операції по вибірці даних - проектування, вибір і об'єднання, які
дозволяють суворо вказати системі, які дані необхідно показати. Операція
проектування вибирає стовпці, операція вибору - рядки, а операція
об'єднання збирає разом дані з пов'язаних таблиць.
Віртуальні таблиці можна розглядати як деяку переміщувану за таблицями
рамку, через яку можна побачити тільки необхідну частину інформації.
Віртуальні таблиці можна отримати з однієї або декількох таблиць бази даних (
включаючи й інші віртуальні таблиці), використовуючи будь-які операції вибору,
проектування та об'єднання. Віртуальні таблиці, на відміну від "справжніх", або
базових таблиць, фізично не зберігаються в базі даних. У той же час необхідно
усвідомлювати, що віртуальні таблиці це не копія деяких даних, що поміщаються в
іншу таблицю. Коли ви змінюєте дані у віртуальній таблиці, то тим самим
змінюєте дані в базових таблицях. В ідеальній реляційної системі з
віртуальними таблицями можна оперувати як і з будь-якими іншими таблицями. В
реальному світі на віртуальні таблиці накладаються певні обмеження, в
Зокрема на оновлення. Одне з правил Кодда свідчить, що в істинно реляційної
системі над віртуальними таблицями можна виконувати всі "теоретично" можливі
операції. Більшість сучасних систем управління реляційними базами даних
не задовольняють цього правила повністю.
У реальному світі управління інформацією дані часто є невідомими або
неповними: невідомий номер телефону, не захотіли вказати вік. Такі
пропуски інформації створюють "діри" у таблицях. Проблема, звичайно, полягає не в
простий непривабливості подібних дірок. Небезпека полягає в тому, що через них база
даних може стати суперечливою. Щоб зберегти цілісність даних в
реляційної моделі, так само, як і в правилах Кодда, для обробки пропущеної
інформації використовується поняття нуля.
"Нуль" не означає порожнє поле або звичайний математичний нуль. Він відображає
той факт, що значення невідомо, недоступне або не застосовується. Суттєво, що
використання нулів ініціює перехід з двозначної логіки (так/ні) на
тризначну (так/ні/може бути). З точки зору іншого експерта з реляційних
системам, Дейта, нулі не є повноцінним вирішенням проблеми пропусків
інформації. Тим не менше вони є складовою частиною більшості офіційних
стандартів різних реляційних СУБД.
Цілісність - дуже складний і серйозне питання при управлінні реляційними
базами даних. Неузгодженість між даними може виникати з цілої низки
причин. Неузгодженість чи суперечливість даних може виникати внаслідок
збою системи - проблеми з апаратурою, помилки в програмному
забезпеченні або логічної помилки в програмах. Реляційні системи управління
базами даних захищають дані від такого типу неузгодженості, гарантуючи, що
команда або буде виконана до кінця, або буде повністю відмінена. Цей
процес звичайно називають управлінням транзакціями.
Інший тип цілісності, званий об'єктної цілісністю, пов'язаний з коректним
проектуванням бази даних. Об'єктна цілісність вимагає, щоб ні одна
первинний ключ не мав нульового значення.
Третій тип цілісності, званої посилальної цілісністю, означає
несуперечність між частинами інформації, що повторюються в різних таблицях.
Наприклад, якщо ви змінюєте неправильно введений номер картки страхового
поліса в одній таблиці, інші таблиці, що містять цю ж інформацію, продовжують
посилатися на старий номер, тому необхідно відновити і ці таблиці.
Надзвичайно важливо, щоб при зміні інформації в одному місці, вона
відповідно змінювалась і у всіх інших місцях. Крім того, за визначенням
Кодда, обмеження на цілісність повинні:
Визначатися на мові високого рівня, що використовується в системі для всіх інших
цілей;
Зберігатися в словнику даних, а не в программнихпріложеніях.
Ці можливості в тому чи іншому вигляді реалізовані в більшості систем.
Проектування баз даних
Процес, в ході якого вирішується, який вигляд буде у новостворюваної БД,
називається проектуванням бази даних. На етапі проектування необхідно
передбачити всі можливі дії, які можуть виникнути на різних
етапах життєвого циклу БД.
На етапі аналізу концептуальних вимог та інформаційних потреб
необхідно вирішити наступні завдання:
Аналіз вимог користувачів до БД (концептуальних вимог);
Виявлення наявних завдань з обробки інформації, яка повинна бути
представлена в БД (аналіз додатків);
Виявлення перспективних завдань (перспективних програм);
Документування результатів аналізу.
Вимоги користувачів до розробляється БД являють собою список запитів
із зазначенням їх інтенсивності та обсягів даних. Ці відомості розробники
одержують в діалозі з майбутніми користувачами БД. Тут же з'ясовуються вимоги
до введення, оновлення та коригування інформації. Вимоги користувачів
уточнюються і доповнюються під час аналізу наявних і перспективних програм.
Наприклад, у разі розробки БД для ведення електронної документації навчального
закладу необхідно отримати відповіді на питання:
Скільки учнів навчається в школі?
Скільки змін і класів у школі?
Як учні розподілені по класах і змінах?
Скільки предметів дається по кожній паралелі і в яких обсягах?
Скільки є навчальних класів?
Скільки викладачів у школі їх спеціалізація і класність?
Як часто оновлюється інформація в БД?
Які існують види звітів, довідок і діаграм?
Необхідно вирішити завдання:
Ведення особистих справ учнів
Ведення класних журналів
Складання розкладу занять
Ведення табеля робочого часу викладачів
На основі інформації що зберігається в БД необхідно видавати такі звіти:
Табель успішності
Відомість успішності та відвідуваності класу
Динаміка зростання успішності по класах та школі
Звіт по успішності за рік
Таблиця моніторингу навчального процесу
Статистичні дані по кількості учнів
Результати тестування
Результати роботи вчителів
Результати випускних іспитів
Якість знань учнів
Звіт по предмету
Табель з харчування
Акт про нещасний випадок
Протокол іспиту за курс середньої школи
Відомості про травматизм за навчальний рік
Відомості подаються класним керівником за чверть
Список тих, хто вибув учнів
Рух за рік
Список що залишилися на другий рік
Графік результатів успішності з чвертей
Графік підсумків успішності за роками
Виявлення інформаційних об'єктів і зв'язків між ними
Друга фаза аналізу предметної області полягає у виборі інформаційних об'єктів,
завданні необхідних властивостей для кожного об'єкта, виявлення зв'язків між
об'єктами, визначення обмежень, що накладаються на інформаційні об'єкти,
типи зв'язків між ним, характеристики інформаційних об'єктів.
При виборі інформаційних об'єктів необхідно відповісти на ряд питань:
На які таблиці можна розбити дані, що підлягають зберіганню в БД?
Яке ім'я можна присвоїти кожній таблиці?
Які найбільш цікаві характеристики (з точки зору користувача) можна
виділити?
Які імена можна присвоїти обраним ознаками?
У нашому випадку передбачається завести наступні таблиці (рис. 4):
      ШколаКлассПредметиУченікіУчітеляОценкі
      НомерКлассПредметКлассФаміліяКласс
      ТелефонСменаФаміліяІмя ОтчестПредмет
      ДіректорІмяПредметФамілія
      Назва
      Дата
      Оцінка

Виділимо зв'язку між інформаційними об'єктами (мал. 5)
У ході цього процесу необхідно відповісти на наступні питання:
Які типи зв'язків між інформаційними об'єктами?
Яке ім'я можна присвоїти кожному типу зв'язків?
Які можливі типи зв'язків, які можуть бути використані згодом?
Спроба поставити обмеження на об'єкти, їх характеристики та зв'язку призводить до
необхідність відповіді на наступні питання:
Яка область значень для числових характеристик?
Які функціональні залежності між характеристиками одного інформаційного
об'єкта?
Який тип відображення відповідає кожному типу зв'язків?
При проектуванні БД існують взаємозв'язки між інформаційними об'єктами
трьох типів: "один до одного", "один до багатьох", "багато до багатьох" (рис.6).
Побудова концептуальної моделі
У простих випадках для побудови концептуальної схеми використовують традиційні
методи агрегації і узагальнення. При агрегації об'єднуються інформаційні об'єкти
(елементи даних) в один у відповідності із семантичними зв'язками між
об'єктами. Наприклад, урок історії в 10 "а" класі проводиться в кабінеті № 7,
початок о 9-30. Методом агрегації створюємо інформаційний об'єкт (сутність)
РОЗКЛАД з наступними атрибутами: "клас", "предмет", "кабінет", "час". При
узагальненні інформаційні об'єкти (елементи даних) об'єднуються в родовий об'єкт
(рис.7):
Вибір моделі диктується перш за все характером предметної області та вимогами
до БД. Іншим важливим обставиною є незалежність концептуальної
моделі від СУБД, яка повинна бути вибрана після побудови концептуальної
схеми.
Моделі "сутність-зв'язок", що дають можливість представляти структуру і обмеження
реального світу, а потім трансформувати їх у відповідності з можливостями
промислових СУБД, є досить поширеними.
Під сутністю розуміють основний зміст того явища, процесу або об'єкта, про
якому збирають інформацію для БД. Як суті можуть виступати місце,
річ, особистість, явище і т.д. При цьому розрізняють тип сутності й екземпляр
сутності. Під типом сутності звичайно розуміють набір однорідних об'єктів,
що виступають як ціле. Поняття "екземпляр сутності" відноситься до конкретного
предмету. Наприклад:
Тип сутності - учень
Примірник суті - Іванов, Петров, Сидоров та ін
У нашому прикладі Школа, Клас, Предмети, Учні, Вчителі, Оцінки - сутності.
Логічне проектування
Логічне проектування являє собою необхідний етап при створенні БД.
Основним завданням логічного проектування є розробка логічної
схеми, орієнтованої на обрану систему управління базами даних. Процес
логічного проектування складається з наступних етапів:
Вибір конкретної СУБД;
Відображення концептуальної схеми на логічну схему;
Вибір мови маніпулювання даними.
Вибір конкретної СУБД
Одним з основних критеріїв вибору СУБД є оцінка того, наскільки
ефективно внутрішня модель даних, що підтримується системою, здатна описати
концептуальну схему. Системи управління базами даних, орієнтовані на
персональні комп'ютери, як правило підтримують реляційну або мережеву модель
даних. Переважна більшість сучасних СУБД - реляційні.
Конструювання баз даних на основі реляційної моделі має ряд важливих
переваг перед іншими моделями
Незалежність логічної структури від фізичного і призначеного для користувача
подання.
Гнучкість структури бази даних - конструктивні рішення не обмежують
можливості розробника БД виконувати в майбутньому найрізноманітніші запити.
Так як реляційна модель не вимагає опису всіх можливих зв'язків між
даними, згодом розробник може задавати запити про будь-яких логічних
взаємозв'язках, що містяться в базі, а не тільки про тих, які планувалися
спочатку.
Відображення концептуальної схеми на логічну схему
При відображенні інформаційної схеми, кожен прямокутник схеми ото?? ражается в
таблицю, яка є одним відношенням. При цьому слід враховувати
обмеження на розмір таблиць, які накладає конкретна СУБД.
Вибір мови маніпулювання даними
Важливою складовою частиною СУБД є мова маніпулювання даними, який
використовується при роботі різних додатків з БД. Як правило, мова
маніпулювання даними вбудовується в мову програмування. Крім того, при
виборі СУБД, що реалізує конкретну БД, необхідно оцінити і технічну сторону
справи, яка безпосередньо пов'язана з продуктивністю системи. У цілому
необхідно оцінити сім груп параметрів для вибору СУБД:
Характеристики ПК: тип, модель, фірма виробник, наявність гарантії.
Керування файлами і пошук: тип зв'язку, модифікація декількох файлів,
двонаправлене підключення таблиць, мова маніпулювання даними, варіант пошуку.
Засоби підтримки додатків: каталог даних, генератор додатків, процедурний
мова, підпрограми, макроси, відладчик, система підтримки виконання, шифровка
програм і даних, розмежування доступу, графіка, текстовий редактор,
статистика.
Написання та підтримка цілісності: управління за допомогою команд, управління за допомогою
меню, перевірка цілісності за таблицею, перевірка унікальності ключа, перевірка за
датами, незалежність даних.
Звіти: звіти з кількох файлів, збереження форматів звітів, видача звіту
на екран, видача звіту на магнітний носій, обчислювані поля, групи,
перевизначення формату дати, заголовки звітів, генератор звітів, підсумкові
поля, максимальна ширина звіту.
Операційне середовище: тип операційної системи, обсяг необхідної оперативної
пам'яті, необхідність використання постійної пам'яті, об'єм необхідної
постійній пам'яті, мова підсистеми.
Додаткова інформація: наявність мережевого варіанту, вартість, примітка,
джерела.
ACCESS
СУБД Access є системою управління базами даних реляційного типу. Дані
зберігаються в такій базі у вигляді таблиць, рядки (записи) яких складаються з наборів
полів певних типів. З кожною таблицею можуть бути пов'язані індекси (ключі),
що задають потрібні користувачу порядки на безлічі рядків. Таблиці можуть мати
однотипні поля (стовпці), і це дозволяє встановлювати між ними зв'язку,
виконувати операції реляційної алгебри. Типовими операціями над базами даних
є визначення, створення і видалення таблиць, модифікація визначень
(структур, схем) існуючих таблиць, пошук даних в таблицях за певними
критеріями (виконання запитів), створення звітів про вміст бази даних.
Для роботи з СУБД Access 2.0 потрібні:
IBM PC або сумісний комп'ютер з процесором 386 або вище
DOS 3.3 або вище
Microsoft Windows 3.1 або вище
Не менш 6 МВ оперативної пам'яті (рекомендується 8 МВ)
20 МВ вільної пам'яті на жорсткому диску
Миша
СУБД дозволяє задавати типи даних і способи їх зберігання. Можна також задати
критерії