Основні характеристики моделей даних

смотреть на реферати схожі на «До основних рис моделей даних «.

|1. |Запровадження… |2 | |2. |Бази даних, і системи управління ними … |4 | |2.1. |Бази даних… |4 | |2.2. |Структурні елементи бази даних… |4 | |2.3. |Системи управління базами даних… |5 | |3. |Моделі даних, і їх види… |6 | |4. |Ієрархічна модель даних… |7 | |5. |Мережевий модель даних… |9 | |6. |Реляційна модель даних… |11 | |7. |Информационно-логическая модель даних… |16 | |8. |Укладання… |18 | |10. |Список використовуваної літератури… |19 |.

1.

ВВЕДЕНИЕ

.

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

— забезпечувати отримання загальних і/або деталізованих звітів за підсумками работы,.

— дозволяти легко визначати тенденції зміни найважливіших показателей,.

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

— виконувати точний і майже цілковитий аналіз данных.

Сучасні системи управління базами даних (СУБД) переважно є додатками Windows, оскільки дана середовище дозволяє повніше скористатися наявними можливостями персональної ЕОМ, ніж середовище DOS. Зниження вартості високопродуктивних ПК зумовив як широкий перехід до середовищі Windows, де розробник програмного забезпечення може у менше ступеня турбуватися про розподілі ресурсів, але й зробив програмне забезпечення ПК загалом і СУБД зокрема менш критичними до апаратним ресурсів ЭВМ.

Серед найяскравіших представників системам управління базами даних можна назвати: Lotus Approach, Microsoft Access, Borland dBase, Borland Paradox, Microsoft Visual FoxPro, Microsoft Visual Basic, і навіть баз даних Microsoft SQL Server і Oracle, використовувані в додатках, побудованих за технологією «клієнт-сервер». Фактично, в кожної сучасної СУБД існує аналог, що його випускає інший компанією, має аналогічну сферу застосування й можливості, будь-яке додаток здатне працювати з багатьма форматами уявлення даних, здійснювати експорт нафти й імпорт даних наявністю значної частини конвертерів. Узвичаєними, також, є технології, дозволяють скористатися наявними можливостями інших додатків, наприклад, текстових процесорів, пакетів побудови графіків і т.п., і вбудовані версії мов високого рівня (частіше — діалекти SQL і/або VBA) і кошти візуального програмування інтерфейсів розроблюваних додатків. Тому немає істотного значення якою мовою і основі якого пакета написано конкретне додаток, і який формат даних у ньому використовується. Понад те, стандартом «де-факто» стала «швидка розробка додатків» чи RAD (від англійського Rapid Application Development), джерело якої в широко декларованому у літературі «відкритому підході», тобто необхідність, і зокрема можливість використання різних прикладних програм, тож технології розробки більш гнучких і потужних систем обробки даних. Тож у одному ряду з «класичними» СУБД все частіше згадуються мови програмування Visual Basic 4.0 і Visual З++, що дозволяють швидко створювати необхідні компоненти додатків, критичні за швидкістю роботи, які важко, інколи ж неможливо розробити засобами «класичних» СУБД. Сучасний підхід до управління базами даних передбачає і широке використання технології «клієнтсервер».

Отже, нині розробник не пов’язаний рамками будь-якого конкретного пакета, а залежність від поставленого завдання може використовувати найрізноманітніші докладання. Тому, важливішим представляється загальне напрям розвитку СУБД та інших засобів розробки додатків у справжнє время.

2. БАЗИ ДАННЫХ.

І СИСТЕМИ УПРАВЛІННЯ ИМИ.

2.1. Бази данных.

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

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

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

Перші БД виникли біля підніжжя 1-го покоління ЕОМ бувши окремі файли даних чи його прості coвокупности.

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

Структурування — це запровадження угод про засоби уявлення данных.

Неструктурированными називають дані, записані, наприклад, в текстовому файле.

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

2.1. Структурні елементи бази данных.

Поняття бази даних був із такими поняттями структурних елементів, як полі, запис, файл (таблица).

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

— ім'я, наприклад. Прізвище, Ім'я, По батькові, Дата рождения,.

— тип, наприклад, символьний, числової, календарный,.

— довжина, наприклад, 15 байт, причому визначатиметься максимально можливим кількістю символов,.

— точність для числових даних, наприклад два десяткових знака для відображення дробової частини числа.

Запис — сукупність логічно пов’язаних полів. Примірник записи — окрема реалізація записи, яка містить конкретні значення її полей.

Файл (таблиця) — сукупність примірників записів однієї структуры.

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

2.2. Системи управління базами данных.

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

Систему керування базами даних (СУБД) — це комплекс програмних і мовних коштів, необхідні створення баз даних, підтримання їхньої в актуальному стані перебуває й організації пошуку них необхідної информации.

Перші СУБД, підтримують opганизацию і ведення БД, з’явилися торік у кінці 60-х годов.

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

3. МОДЕЛІ ДАННЫХ.

ТА ЇХНІ ВИДЫ.

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

Модель даних — сукупність структур даних, і операцій їх обработки.

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

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

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

4. ИЕРАРХИЧЕСКАЯ.

МОДЕЛЬ ДАННЫХ.

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

До основним поняттям ієрархічної структури ставляться: рівень, елемент (вузол), связь.

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

До кожного записи бази даних є тільки один (ієрархічний) шлях від кореневої записи.

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

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

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

5. СЕТЕВАЯ.

МОДЕЛЬ ДАННЫХ.

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

Мережевий модель СУБД багато в чому подібна ієрархічної: тоді як ієрархічної моделі кожному за сегмента записи можлива тільки один вхідний сегмент при N вихідних, то мережевий моделі для сегментів допускається кілька вхідних сегментів поруч із можливістю наявності сегментів без входів з погляду ієрархічної структуры.

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

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

У межах мережевих СУБД легко реалізуються і ієрархічні даталогические модели.

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

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

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

6. РЕЛЯЦИОННАЯ.

МОДЕЛЬ ДАННЫХ.

Поняття реляционный (анг. relation — ставлення) пов’язані з розробками відомого американського фахівця у галузі систем баз даних, співробітника фірми IBM д-ра Є. Кодда (Codd E.F., A Relational Model of Data for Large Shared Data Banks. CACM 13: 6, June 1970), яким був уперше застосований термін «реляційна модель даних » .

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

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

Реляційна модель орієнтована на організацію даних як двовимірні таблиць. Кожна реляційна таблиця є двомірний масив й володіє такими свойствами:

— кожен елемент таблиці - один елемент даних, повторювані групи отсутствуют,.

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

— кожен стовпець має унікальне имя,.

— однакові рядки у таблиці отсутствуют,.

— порядок прямування рядків і шпальт то, можливо произвольным.

Таблиця що така називається отношением.

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

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

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

Щоб зв’язати дві реляционные таблиці, необхідно ключ першої таблиці увести до складу ключа другий таблиці (можливо збіг ключів), в іншому разі слід впровадити до структури першої таблиці зовнішній ключ — ключ другий таблицы.

Запропонувавши реляционную модель даних, Э. Ф. Кодд створив і інструмент для зручною роботи із гармонійними стосунками — реляционную алгебру. Кожна операція цієї алгебри використовує одну чи кілька таблиць (відносин) як її операндов і продукує внаслідок нову таблицю, тобто. дозволяє «розрізати «чи «склеювати «таблицы.

[pic].

Деякі операції реляційної алгебры.

А чим принципово різняться реляционные моделі від мережевих і ієрархічних? Коротенько це можна відповісти так: ієрархічні і мережні моделі даних — пов’язані структурою, а реляционные — пов’язані по значению.

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

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

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

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

Ця модель дозволяє определять:

— операції з запам’ятовування та пошуку данных,.

— обмеження, пов’язані із забезпеченням цілісності данных.

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

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

Основною перевагою реляционных СУБД є можливість зв’язування з урахуванням певних співвідношень файлів БД.

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

СУБД вважається реляційної і під час наступних дві умови, запропонованих ще Еге. Коддом:

— підтримує реляционную структуру данных,.

— реалізує по крайнього заходу операції селекції, проекції і з'єднання отношений.

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

Суть реляційної СУБД можна пояснити ось на чому простому примере.

|Файл авторів публікацій БД | |№ п/п |Автор |Адреса |Телефон |Кількість | | | | | |публ. | | |… |… |… |… | |6 |Купців |Москва|635−6078|140 | |7 |Бухтяк |Томськ |637−2050|140 | |8 |Терпуго|Томск |538−584 |250 | | |в | | | |.

|Файл публікацій РБД | |№ п/п |Назв. |Тип |Дата |Обсяг| | |Публікації |публ.| | | | | | | |в п. | | | | | |л. | |6 |Основи … |Стать|2.95 |2.5 | | | |я | | | |7 |Проблема … |Книга|3.97 |35 | |8 |Теорія … |Стать|6.96 |3.8 | | | |я | | | | |… |… |… |… |.

У деякою реляційної БД (РБД) є файла авторів, і публікацій, кожен із яких містить певна кількість записів, які з фіксованого числа полів (відповідно 4 і п’яти), які мають дані про відповідним елементам предметної області. Можна сміливо сказати, які визначені два відносини (фaйла), мають загальний елемент — значення поля № п/п. Операції реляцианной алгебри можуть об'єднувати два типу записів у цій загальному елементу. Наприклад, внаслідок сполуки запис Бухтяк може випаде наступного виде:

Бухтяк…

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

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

Основним гідністю реляционных баз даних є сумісність з найпопулярнішим мовою запитів SQL.

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

Але виявлено й недоліки розглянутим моделі баз данных:

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

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

7. ИНФОРМАЦИОННО-ЛОГИЧЕСКАЯ.

МОДЕЛЬ ДАННЫХ.

Проектування бази даних полягає у побудові комплексу взаємозалежних моделей данных.

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

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

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

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

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

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

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

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

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

9.

ЗАКЛЮЧЕНИЕ

.

Користувачами БД є чотири основних категорії споживачів її інформації і/або постачальників інформації для нее:

— кінцеві пользователи,.

— програмісти й системніші аналитики,.

— персонал підтримки БД в актуальному состоянии,.

— адміністратор БД.

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

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

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

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

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

10. СПИСОК.

ВИКОРИСТОВУВАНОЇ ЛИТЕРАТУРЫ.

1. А. А Жуков, Л. А Федякина «Система контролю за навчанням TSTST», Інформатика й освіту, 1997 р., № 2.

2. В. В. Аладьев, Ю. Я. Хунт, М.Л. Шишаків «Основи інформатики», Навчальний посібник, М., 1999 г.

3. А. А. Ездов, «Лабораторні роботи з фізики з допомогою комп’ютерної моделі», Інформатика й освіту, 1996 р., № 1.

4. Авт. Єрмаков, Л.Є. Андрєєва, «Питання розробки що тестують програм», Інформатика й освіту, 1997 р., № 3.

5. В. В. Бойко, В. М. Савинков, «Проектування баз даних інформаційних систем», М., Фінанси і статистика, 1989 г.

6. Д. Цикритизис, Ф. Лоховски, «Моделі даних», М., Фінанси і статистика,.

1985 г.

7. До. Дейт, «Введення ЄІАС у системи баз даних», М., Наука, 1980 г.

8. До. Дейт, «Посібник із реляційної СУБД», М., Фінанси і статистика,.

1988 г.

9. Д. Мейєр, «Теорія реляционных баз даних», М., Світ, 1987 г.

———————————;

СУБД Даталогическая модель.

Фізична модель База даних (БД).

Предмет.

Іспит 2.

Информатика.

Іспит 1.

К/р 2.

К/р 1.

К/р 3.

К/р 2.

К/р 1.

К/р 3.

К/р 2.

К/р 1.

Математика.

Физика.

Математика.

Информатика.

К/р 2.

К/р 1.

К/р 3.

К/р 2.

К/р 1.

К/р 3.

К/р 2.

К/р 1.

Физика.

Инфологическая модель предметної области.

Предметна область.