Архів якісних рефератів

Знайти реферат за назвою:         Розширений пошук

Меню сайту

Головна сторінка » Інформатика, програмування

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

ВСТУП

База даних – це сукупність даних, яким властива структурованість і взаємопов'язаність, а також незалежність від прикладних програм.

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

СКБД – керівна програма, призначена для збереження, пошуку і обробки даних у базі.

СКБД повинна давати доступ до даних будь-яким користувачам, включаючи і тих, що практично не мають уявлення про:

1. Фізичне розташування в пам'яті даних і їх описів;

2. Механізми пошуку даних, що запитуються;

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

4. Способи забезпечення захисту даних від некоректного поновлення і несанкціонованого доступу;

5. Підтримку баз даних в актуальному стані і багато інших функцій СКБД.

Завдяки досягненням в області штучного інтелекту з'являються системи, що базуються на використанні знань. Систему, яка забезпечує створення, ведення і застосування баз знань, можна розглядати як інструментальну систему або прикладну систему з конкретною прикладною базою знань. Існує тісний взаємозв'язок між технологією баз даних і систем баз даних – з одного боку, і технологією систем баз знань з іншого. Виникла тенденція „інтелектуалізації” систем БД.

В даній курсовій роботі буде розроблено базу даних, що відображає Ремонт ПК.


1 АНАЛІЗ СУЧАСНОГО РОЗВИТКУ СУБД

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

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

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

1. Швидкодія.

2. Захист від будь-яких нештатних ситуацій.

3. Надійність зберігання.

4. Розмежування доступу до даних.

5. Можливість підтримки цілісності даних тощо.

У 1979 році з'явилася й перша система управління базами даних (СУБД) Oracle, що використовує SQL. Технологія ця лише набирає обертів. Саме об'єднання реляційних баз даних із клієнт-серверними технологіями дозволяє сучасному бізнесу справлятися зі зростаючими обсягами даних.

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

Система управління базами даних Microsoft Access входить до складу пакета Microsoft Office. Вона дозволяє розв'язувати широке коло завдань користувачів без програмування і доступна для широкого кола непрофесійних користувачів персональних комп'ютерів. СУБД Access розроблена для експлуатації у комп'ютерних мережах у середовищі Windows. Одна з основних переваг СУБД Ассеss полягає у тому, що вона має прості та зручні засоби обробки кількох таблиць у одній базі даних. Таблиця є основним об'єктом бази даних. У одній базі даних зберігається кілька таблиць та засоби зв'язування таблиць. За допомогою СУБД MS Access можна побудувати не лише саму базу даних, а й зручний інтерфейс доступу до даних, що полегшує доступ до даних і не вимагає додатково розробляти програму для роботи з базою даних. Також дана Access надає можливість швидко і ефективно розробити звіти, запити, та форми. На основі аналізу найпоширеніших СУБД, приходимо до висновку, що для розробки бази даних на тему „ Ремонт ПК ” доцільно використати Microsoft Access. [3].


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

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

1. Формування замовлення на ремонт ПК, сюди слід включити такі дані:

- код замовлення;

- назва замовлення.

2. Інформацію про клієнтів:

- № кредитної картки;

- ПІБ клієнта;

- статус;

- примітка.

3. Інформацію про вартість замовлення:

- код вартості;

- кількість;

- ціна;

- сума;

4. Інформацію про комплектуючі:

- код деталі;

- назва деталі;

- виробник.

Дана база даних міститиме всю інформацію необхідну користувачеві та забезпечуватиме швидкий пошук інформації по запитам.


3 РОЗРОБКА УНІВЕРСАЛЬНОГО ВІДНОШЕННЯ

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

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

Замовлення (код замовлення, назва замовлення);

Вартість (код вартості, кількість, ціна, сума);

Клієнт (№ кредитної картки, ПІБ, статус, примітка);

Комплектуючі (код деталі, назва деталі, виробник).

Перелік атрибутів вказано в таблиці 1.

Таблиця 1 – Початковий перелік атрибутів

Назва атрибута

Ім'я поля

Коментар

Код замовлення

КодЗамов

Номер коду замовлення

назва замовлення

НазваЗамов

Назва зробленого замовлення

дата

Дата

Дата замовлення на ремонт

Код вартості

КодВарт

Код вартості замовлення

кількість

Кількість

Кількість деталей в замовлені

ціна

Ціна

Ціна за одину деталь

сума

Сума

Загальна сума вартості

№ кредитної картки

№КредитКартки

Особистий номер клієнта

ПІБ

ПІБ

ПІБ клієнта

статус

Статус

Статус клієнта

примітка

Примітка

Замітка про клієнта

Код деталі

КодДеталі

Код деталі

назва деталі

НазваДеталі

Назва деталі

виробник

Виробник

Виробник деталі

Оскільки всі перераховані в таблиці атрибути являються незалежними, тобто значення одних з них не можуть бути обчислені по значенням інших, то всі вони можуть бути включеними до універсального відношення, котре при цьому приймає наступний вигляд: R(КодЗамов, НазваЗамов, Дата, КодВарт, Кількість, Ціна, Сума, №КредитКартки, ПІБ, Статус, Примітка, КодДеталі, НазваДеталі, Виробник)=14.

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


4 РОЗРОБКА ER-МОДЕЛІ ПРЕДМЕТНОЇ ОБЛАСТІ

У даному розділі розробляється інформаційна структура бази даних (її концептуальна схема). Концептуальна модель застосовується для структурування предметної області. Так як даній курсовій роботі база даних розробляється для представлення структури і обмежень реального світу, то використовується моделі типу "суть-зв'язок" або ER-модель.

Під суттю розуміють основний зміст об'єкту, явища чи процесу, про який збирають інформацію. Зв'язки – це асоціації між інформаційними об'єктами [2].

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

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

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

У якості сутей виберемо такі об'єкти:

Замовлення, вартість, клієнт, комплектуючі.

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

(КодЗамов, НазваЗамов, Дата, КодВарт, Кількість, Ціна, Сума, №КредитКартки, ПІБ, Статус, Примітка, КодДеталі, НазваДеталі, Виробник).

Замовлення <КодЗамов>(номер коду замовлення)

Вартість<КодВарт>(код вартості замовлення)

Клієнт<№КредитКартки>(Особистий номер клієнта)

Комплектуючі< КодДеталі >(код деталі)

Визначимо типи зв'язків між даними сутями за допомогою ER – діаграм (рис. 1-3):

Замовлення

Вартість

КН:Обов. ТИП ЗВ'ЯЗКУ 1 : 1 КН:Обов.

З1

З2

З3

. . .

. . .

В1

В2

В3

Має


 

Рисунок 1 – ER-діаграма сутей Замовлення та Вартість

Клієнт

Замовлення

КН:Обов. ТИП ЗВ'ЯЗКУ 1: N КН:Обов.

К1

К2

. . .

. . .

З1

З2

З3

З4

К3

Робить


 

Рисунок 2 – ER-діаграма сутей Номер коду замовлення Клієнт та Замовлення

Потребує

Замовлення

КН:Обов. ТИП ЗВ'ЯЗКУ N : M КН:Обов.

З1

З2

. . .

. . .

К1

К2

К3

З4

З3

Комплектуючі

К4


 

Рисунок 3 ER-діаграма сутей Замовлення та Комплектуючі

Результати проведеного аналізу зв'язків зведемо у наступну таблицю:

Таблиця 2 – Характеристика зв'язків сформованих сутей

Суть 1

Суть 2

Тип зв'язку

Ім'я зв'язку

Тип належності

Замовлення

Вартість

1 : 1

Має

Обов.; Обов.

Клієнт

Замовлення

1 : N

Робить

Обов.; Обов.

Замовлення

Комплектуючі

N : M

Складається

Обов.; Обов.

Рисунок 4 – Результуюча ER-модель предметної області

"Ремонт ПК”


5 ПРОЕКТУВАННЯ НОРМАЛІЗОВАНИХ ВІДНОШЕНЬ

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

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

Розглянемо форми нормалізації відношень.

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

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

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

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

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

Замовлення (<КодЗамов>, НазваЗамов);

Вартість (<КодВарт>, Кількість, Ціна, Сума);

Клієнт (<№КредитКартки>, ПІБ, Статус, Примітка);

Комплектуючі (<КодДеталі>, НазваДеталі, Виробник).

5.1 Одержання початкових відношень за методом "суть – зв'язок”

Попередні відношення формуються з діаграм ER-типу на основі аналізу класу належності і степені відношень сутей, на основі правил.

Отримавши у відношеннях типи зв'язків M:N, 1:N та 1:1, використаємо наступні правила для формування попередніх відношень:

ПРАВИЛО 1. Якщо ступінь бінарних зв'язків 1:1 і клас належності обов'язковий для обох сутей, гарантується однократне появлення кожного значення сутей в будь-якому екземплярі відношень. Тобто у відношенні ніколи не буде ні порожньої інформації, ні груп надлишкових даних, що повторюються.

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

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

ПРАВИЛО 4. Якщо степінь бінарного зв'язку 1:N, i клас належності n - зв'язаної суті є обов'язковим, то досить використати по одному відношенню на кожну суть, при умові, що ключ кожної суті служить у якості первинного ключа для відповідного відношення. Додатково, ключ 1 - зв'язної суті повинен бути добавлений як атрибут у відношення, що відводиться n - зв'язній суті.

ПРАВИЛО 6. Якщо ступінь бінарного зв'язку M:N, то для зберігання даних потрібні три відношення: по одному для кожної суті, причому ключ кожної суті служить у якості первинного ключа для відповідного відношення, та одного відношення для зв'язку. Зв'язок повинен мати серед своїх атрибутів і ключ суті кожної з зв'язуваних сутей. Виявлення в предметній області тристоронніх зв'язків приводить до необхідності використання чотирьох відношень [1].

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

Таблиця 3 – Попередні відношення для опису предметної області "Ремонт ПК”

Ім'я зв'язку

№ прав.

Попередні відношення

Додаткові атрибути

Має

1

*R1 (<КодЗамов>, …)

R2 (<КодВарт>, …)

(НазваЗамов, Дата, КодВарт)

(Кількість, Ціна, Сума)

Робить

4

R3 (<№КредитКартки>, …)

*R4(<КодЗамов>,…)

(ПІБ, Статус, Примітка)

(НазваЗамов, Дата, КодВарт, №КредитКартки)

Потребує

6

R5(<КодЗамов>,…)

R6(<КодДеталі>,…)

R7(<КодЗамов, КодДеталі>)

(НазваЗамов, Дата, КодВарт, №КредитКартки)

(НазваДеталі, Виробник)

Для організації зв'язку за 6 правилом

Знаком "*” позначені ті відношення, що дублюють інформацію, і повинні бути видалені.

Отже в результаті було отримано наступні відношення:

R2 (<КодВарт>, Кількість, Ціна, Сума),

R3(<№КредитКартки>, ПІБ, Статус, Примітка),

R5(<КодЗамов >, НазваЗамов, Дата, КодВарт, №КредитКартки),

R6(<КодДеталі >, НазваДеталі, Виробник),

R7(<КодЗамов, КодДеталі>) Для організації зв'язку за 6 правилом.

5.2 Нормалізація відношень методом декомпозиції

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

1. Розробка універсального відношення для бази даних;

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

3. Визначення того, чи знаходиться розглянуте відношення в НФБК. Якщо так, проектування закінчується; якщо ні - відношення розбивається на два відношення;

4. Повторення кроків 2 та 3 для кожного нового відношення, отриманого в результаті декомпозиції.

Універсальне відношення для даного прикладу має вигляд :

R(КодЗамов, НазваЗамов, Дата, КодВарт, Кількість, Ціна, Сума, №КредитКартки, ПІБ, Статус, Примітка, КодДеталі, НазваДеталі, Виробник).

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

R2 (<КодВарт>, Кількість, Ціна, Сума),

R3(<№КредитКартки>, ПІБ, Статус, Примітка),

R5(<КодЗамов >, НазваЗамов, Дата, КодВарт, №КредитКартки),

R6(<КодДеталі >, НазваДеталі, Виробник),

R7(<КодЗамов, КодДеталі>).

Порівнявши їх з відношеннями, які ми отримали в п. 5.1, можна помітити їх ідентичність.

Рисунок 5 − Діаграма функціональних залежностей

5.3 Оцінка спроектованих НФБК відношень

Перевірка НФБК - відношень, які розглядаються в якості кінцевого проекту на предмет наявності невиявлених проблем, включає такі основні кроки :

1. Складаються списки функціональних залежностей дня кожного відношення. Ці списки перевіряються на двох направленнях:

- одна і таж функціональна залежність не повинна з'являтися більш, чим в одному відношенні;

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

2. Здійснюється перевірка на присутність надлишкових відношень. Відношення являється надлишковим якщо :

- всі його атрибути можуть бути знайдені в одному або другому відношенні набору, що проектується;

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

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

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

Розглядаючи отримані при проектуванні бази даних "Ремонт ПК" відношення, можна помітити, що:

- ні одна ФЗ не повторюється більше одного разу;

- цей набір ФЗ являється мінімальним.

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

Кінцеві відношень приймуть наступний вигляд:

R2 (<КодВарт>, Кількість, Ціна, Сума),

R3(<№КредитКартки>, ПІБ, Статус, Примітка),

R5(<КодЗамов >, НазваЗамов, Дата, КодВарт, №КредитКартки),

R6(<КодДеталі >, НазваДеталі, Виробник),

R7(<КодЗамов, КодДеталі>).

6 РЕАЛІЗАЦІЯ ЗАПИТІВ І ВИХІДНИХ ФОРМ

6.1 Аналіз запитів, що реалізуються СКБД

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

- «Пошук замовлення». За допомогою даного запиту можна отримати список замовлень, які зробив клієнт. Сюди включають № кредитної картки клієнта, ПІБ клієнта, код замовлення, назва замовлення, вартість замовлення.

- «Пошук клієнта». За допомогою даного запиту можна знайти інформацію про клієнта (ПІБ, статус, примітки) за № кредитної картки.

- «Пошук деталі». За допомогою даного запиту можна отримати назву, шуканої за кодом, деталі і супутню інформацію до неї.

При виконанні даних запитів інформація видається в зручній для користувача формі.

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

6.2 Розробка вихідних форм

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

Форма «Замовлення» - дає можливість додати нове замовлення, яке зробив клієнт.

Форма «Клієнт» - призначена для редагування даних про існуючих в базі клієнтів, а також дозволяє додавати нові записи про клієнтів .

Форма «Комплектуючі» - дозволяє переглядати, редагувати та додавати деталі в існуючу базу.

Форма «Вартість» - дозволяє редагувати та встановлювати нові ціни на деталі.


ВИСНОВКИ

Виходячи з викладеного вище проектування і побудови бази даних "Ремонт ПК”, а також основних цілей проектування баз даних і постановки задачі можна зробити такі висновки: була спроектована і створена база даних для даної предметної області, централізоване керування даними, їхнє багатоцільове використання при дотриманні їхньої цілісності і мінімальної необхідної надмірності, реалізовано зручний та зрозумілий інтерфейс користувача. Вся робота була проведена в системі керування базами даних MS Access 2003.

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


ПЕРЕЛІК ПОСИЛАНЬ

1. Романюк О. Н., Савчук Т. О. Організація баз даних і знань. Навчальний посібник. – Вінниця: УНІВЕРСУМ-Вінниця, 2003.

2. Романюк О. Н., Денисюк А. В. Методичні вказівки до виконання курсової роботи з дисципліни «Організація баз даних і знань» для студентів напряму підготовки 6.050103 «Програмна інженерія» денної та заочної форми навчання. – Вінниця: ВНТУ, 2010.

3. Сергеев А. Access 2007. Новые возможности. – Санкт-Петербург: Питер, 2008.

4. Зарецька І.Т., Соколов О.Б. Інформатика. Підручник для 10-11 кл. загальноосвіт. навч. Закладів. – Форум, 2004.

5. Виллариал Б. Программирование Access 2002 в примерах – М.: КУДИЦ-ОБРАЗ, 2003.





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


Схожі реферати



5ka.at.ua © 2010 - 2016. Всі права застережені. При використанні матеріалів активне посилання на сайт обов'язкове.    
.