2.1 Розробка концептуальної моделі даних
Початковою стадією проектування системи баз даних є побудова семантичної моделі предметної області, яка базується на аналізі властивостей і природи обєктів предметної області та інформаційних потреб майбутніх користувачів системи, що розробляється. Цю стадію прийнято називати концептуальним проектуванням системи, а її результат - концептуальною моделлю предметної області (обєктом моделювання тут є предметна область майбутньої системи) [17]. Концептуальне проектування є центральною частиною, ядром всього процесу проектування баз даних. Для того щоб база даних адекватно відображала предметну область, проектувальник повинен добре уявляти собі всі нюанси, притаманне їй, і вміти відобразити їх в базі даних.
Концептуальна модель - це відображення предметної області, для якої розробляється база даних. Всі обєкти, які позначають речі, позначаються у вигляді прямокутника. Атрибути, що характеризують обєкт - у вигляді еліпсу, а звязки між обєктами - ромбами. Потужність звязку позначаються стрілками (у напрямку, де потужність дорівнює багатьом - подвійна стрілка, а з боку, де вона дорівнює одиниці - одинарна). Кожен обєкт має свої атрибути. Якщо предметна область обємна, то її корисно розбити на кілька локальних предметних областей. Після створення моделей кожної виділеної предметної області виробляється обєднання локальних концептуальних моделей в одну загальну, як правило, досить складну схему [18].
ER-діаграма складеться з 11 обєктів.
1) тип бібліотеки (звязок з Бібліотекою);
2) бібліотека (Звязок з Типом бібліотеки, Бібліотекарем, Читачем);
3) бібліотекар (Звязок з Бібліотекою, Замовленням);
4) книга (Звязок з Печатним виданням, серією, жанром,автором );
5) автор (Звязок з Книгою);
6) серія (Звязок з Книгою, Журналом);
7) жанр (Звязок з Книгою, Журналом).
8) печатне видання (Звязок з Книгою, Журналом, Замовленням).
9) замовлення(Звязок з Читачем, Печатним виданням, Бібліотекарем).
10) журнал(Звязок з Печатним виданням, Жанром,Серією).
11) читач (Звязок з Замовленням, Бібліотекою ).
Канонічна ER діаграма. Для обраної предметної області зображена на рисунку 2.1
Рисунок 2.1 - ER-діаграма для Про "Бібліотека"
Поява і широке застосування моделі даних типу " обєкт-звязок "(entity - relationship, ER-модель) повязане з практичними потребами системного аналізу та концептуального моделювання великих баз даних (БД) для автоматизованих інформаційних систем. Техніка побудови ER-моделі даних використовується для визначення інформаційних потреб прикладної області та представлення структури бази даних, відповідної ER-моделі, в графічній формі ER-діаграми. В життєвому циклі програмного забезпечення (ЖЦ ПЗ) техніка ER-моделювання використовується в процесах, повязаних зі специфікації вимог до розробляємого ПЗ [19]. Ці процеси виконуються на початкових етапах ЖЦ ПЗ. ER-модель даних володіє важливими властивостями, які підтверджують корисність її використання у визначенні вимог до даної розроблюваної програмної системи. По-перше, кошти ER-моделі володіють достатнім ступенем спільності, придатної для передачі розуміння інформаційних потрібностей користувача, в той же час не мають великого розриву з моделями даних комерційних СКБД. Це властивість забезпечує реалізацію інфо-логічної моделі БД, сконструйованої за правилами ER-моделювання, без великих проблем дає наочне уявлення про те, як ER-модель може бути перетворена в будь-яка модель з трьох основних видів - ієрархічну, мережеву, реляційну, які підтримуються комерційними СКБД.
По-друге, техніка ER-моделювання спирається на строгі формальні правила та угоди, включаючи концепції нормалізації даних. Отже, ER-модель може розглядатися як засіб точного вираження уявлень про реальні обєкти області додатки, що дозволяє забезпечити спілкування між аналітиком і користувачем системи, а також між аналітиком і розробниками системи.
2.2 Проектування логічної моделі бази даних
Логічна структура бази даних, а так само сама заповнена даними база даних, є відображенням реальної предметної області. Тому на вибір проектних рішень найбільше впливає специфіка відображається предметної області.
Оскільки основу будь-якої бази даних складає інформаційна структура, бази даних ділять на три типи: реляційні, мережеві, ієрархічні.Логічна модель - це абстрактний погляд на дані. На ньому дані представляються так, як виглядають у реальному світі. Обєкти і моделі, що представляються на логічному рівні, називаються сутностями і атрибутами. Логічна модель даних є універсальною і ніяк не повязана з конкретною реалізацією СКБД [20].
У реляційній моделі, обєкти представлені у вигляді таблиць (двомірних масивів). Причому таблицею можуть відображатися не тільки обєкти, але і звязки кожна таблиця складається з довільної кількості рядків і довільної кількості стовпців. Обовязковою умовою побудови реляційної моделі є наявність у кожної моделі первинного ключа. Цей вид моделі має найбільше поширення при побудові баз даних.
В основі реляційної моделі даних лежать не графічні табличні методи і засоби представлення даних і маніпулювання ними. Таблиця відображає обєкт реального світу - сутність. Кожен стовпець таблиці має унікальне для кожної таблиці імя.
Реляційні системи виключили необхідність складної навігації, оскільки дані представлені в них не у вигляді одного файлу, а незалежними наборами. У реляційній моделі всі таблиці мають бути перетворені у відносини. Відносини повязані між собою. Звязки підтримуються зовнішніми ключами. У реляційній теорії є поняття "ключ" і "ймовірний ключ". Ці поняття характеризують не предметну область, а саме таблицю реляційної бази даних.
Після створення різних таблиць, що містять дані, що відносяться до різних аспектів бази даних, необхідно забезпечити цілісність бази даних.Для даного проекту підходить найбільше реляційна модель побудови бази даних.
Для проектування логічної моделі даних використовують засіб для проектування та документування баз даних ERwin.
ERwin - потужне і просте у використанні засіб конструювання баз даних Воно забезпечує найвищу продуктивність праці при розробці та супроводі додатків з використанням баз даних [21].
Протягом усього процесу - від логічного моделювання вимог до інформації та бізнес-правил, які визначають базу даних, до оптимізації фізичної моделі у відповідності з заданими характеристиками - ERwin дозволяє наочно відобразити структуру та основні елементи БД.
ERwin - це потужний засіб проектування і інструмент розробки, здатний автоматично створювати таблиці і генерувати тисячі рядків тексту збережених процедур і тригерів для всіх популярних СКБД. Революційна технологія Complete-Compare (Завершити-Порівняти) дозволяє організувати ітеративну розробку, підтримуючи постійну узгодженість моделі та бази даних. Завдяки інтеграції з популярними середовищами розробки програм, ERwin дозволяє прискорити створення додатків для обробки даних.
ERwin полегшує проектування баз даних. Для цього досить створити графічну ER-модель, що задовольняє всім вимогам до даних і ввести бізнес-правила для створення логічної моделі, яка відображає всі елементи, атрибути, відносини і угрупування. Розвинені засоби моделювання допомагають краще спроектувати базу даних. Передбачені можливості маніпулювання атрибутами шляхом їх буксирування, внесення змін та нормалізації "на льоту". Засоби редагування безпосередньо на діаграмах дозволяють вносити в модель зміни, не відкриваючи спеціальних діалогових вікон. Навігація по відносинам забезпечує швидке переміщення у великих моделях для переходу до батьківським або дочірнім обєктах.
ERwin автоматизує процес проектування. ERwin передбачає можливість створення каталогу найбільш часто використовуваних атрибутів, що забезпечує узгодженість імен та описів з усього проекту. Уявлення БД підтримуються як інтегровані компоненти моделі, що дозволяє автоматично відображати в їх описах зміни, внесені до базові таблиці. Автоматичне перенесення ключів забезпечує посилальну цілісність бази даних.
ERwin не тільки кращий інструмент для проектування баз даних, а й засіб для їх швидкого створення. ERwin оптимізує модель відповідно з фізичними характеристиками цільової бази даних. На відміну від інших інструментальних засобів ERwin автоматично підтримує узгодженість логічної і фізичної схем і здійснює перетворення логічних конструкцій, таких як відносини багато-до-багатьох, в їх реалізацію на фізичному рівні.
ERwin встановлює природну динамічну звязок між моделлю і базою даних, що дозволяє реалізувати як прямий, так і зворотний інжиніринг. До складу ERwin включений низку оптимізованих шаблонів тригерів, які забезпечують цілісність посилань, і потужний макромова, який дозволяє створювати власні тригери і процедури. Таким чином можуть бути автоматично сформовані тисячі рядків коду, що забезпечує неперевершену продуктивність розробки на основі моделей.
Засоби розрахунку обсягу дозволяють точно оцінити первинний розмір і характер росту бази даних або сховища, полегшуючи ефективне розподіл ресурсів системи та планування потужності.
База даних може бути спроектована і створена без написання окремих SQL-пропозицій типу CREATE TABLE або INDEX. Оскільки фізична схема формується на основі описової логічної моделі, ваш додаток буде відразу ж повністю документовано. ERwin дозволяє також проводити зворотний інжиніринг існуючих баз даних шляхом побудови моделі безпосередньо на основі її таблиць.
ERwin підтримує всі найбільш популярні реляційні СКБД, включаючи Oracle, Microsoft SQL Server, Sybase, DB2 і Informix. Одна і та ж модель може бути використана для створення декількох баз даних або для перенесення програми з платформи однієї СКБД на іншу.
Зазвичай розробка моделі бази даних складається з двох етапів: складання логічної моделі і створення на її основі фізичної моделі. ERwin повністю підтримує такий процес, він має два подання моделі: логічне і фізичне. Таким чином, розробник може будувати логічну модель бази даних, не замислюючись над деталями фізичної реалізації, тобто приділяючи основну увагу вимогам до інформації та бізнес-процесам, які буде підтримувати майбутня база даних.
В ході виконання курсового проекту будо розроблено концептуальну модель даних, яку зображено на рисунку 2.2.
Рисунок 2.2 - Логічна модель даних
Таким чином у даному підрозділі показане створення концептуальної моделі даних.
2.3 Аналіз бізнес-логіки обробки даних у предметній області та визначення основних типів запитів у системі
Для роботи з базою даних використовуються запити. Запит (query) - це засіб вибору необхідної інформації з бази даних. Питання, сформований по відношенню до бази даних, і є запит. Застосовуються два типи запитів: за зразком Query by example (QBE) і структурований мова запитів - Structured Query Language (SQL). QBE - засіб для відшукання необхідної інформації в базі даних. Він формується не на спеціальній мові, а шляхом заповнення бланка запиту у вікні Конструктора запитів. SQL-запити - це запити, які складаються (програмістами) з послідовності SQL-інструкцій. Ці інструкції задають, що треба зробити з вхідним набором даних для генерації вихідного набору. Всі запити Access будує на основі SQL-запитів, щоб подивитися їх, необхідно в активному вікні проектування запиту виконати команду Вид / SQL [23].
Існує кілька типів запитів: на вибірку, на оновлення, на додавання, на видалення, перехресний запит, створення таблиць. Найбільш поширеним є запит на вибірку. Запити на вибірку використовуються для відбору потрібної користувачу інформації, що міститься в таблицях. Вони створюються тільки для повязаних таблиць. Існують такі види запитів
- на вибірку;
- на додавання;
- на видалення.
- вкладений;
- прилучений;
MySQL дозволяє включати один запит до складу іншого. Вкладені запити називають також підлеглими. Вкладений запит у складі запиту SELECT поміщається в круглі дужки. Спочатку виконується вкладений запит, a потім отримані результати використовуються при обробці головного запиту. Оператор внутрішнього сполучення INNER JOIN зєднує дві таблиці. Порядок таблиць для оператора неважливий, оскільки оператор симетричний. У випадку з left join з головної таблиці будуть вибрані всі записи, навіть якщо в таблиці немає збігів, тобто умова condition не враховує приєднувану праву табліцу.
Right join відображає всі рядки задовольняють правій частині умови condition, навіть якщо вони не мають відповідності у головній лівої таблиці
В ході виконання КП було реалізовано ряд запитів.
Запит, що виконує вибірку читача на імя Ігор.
SELECT * FROM reader WHERE first_Name_reader LIKE Ігор;
Запит що виконує збірку книг замовлених читачем з імям Ігор
SELECT Name_book FROM book WHERE Printed_matter_id IN
(SELECT Printed_matter_id FROM orderr WHERE reader_id IN
(SELECT reader_id FROM reader WHERE first_Name_reader LIKE Ігор)
Запит, що змінює імя всіх людей з фамілією Шураєв на Олег
UPDATE reader
SET first_Name_reader = Олег
WHERE last_Name_reader=Шураєв
Запит, змінює назву книги з назвою Бульба на повну назву - Тарас Бульба.
UPDATE book
SET Name_book = Тарас Бульба
WHERE Name_book = Бульба
Даний запит виконує видалення усіх читачів з імям Арес .
DELETE FROM reader
WHERE first_Name_reader LIKE %Арес
Запит, що видаляє книгу з назвою Тарас Бульба з бібліотеки.
DELETE FROM book
WHERE Name_book LIKE %Тарас Бульба
Запит, що виконує вибірку книг і їх жанрів.
SELECT
`genre`.`Name_genre`,
`book`.`Name_book`
FROM
`book`
LEFT OUTER JOIN `genre` ON (`book`.`Genre_id` = `genre`.`Genre_id`)
GROUP BY
`genre`.`Name_genre`,
`book`.`Name_book`
Запит, що виконує вибірку книг з інформацією про їх авторів, жанр та серію.
SELECT
`genre`.`Name_genre`,
`book`.`Name_book`,
`series`.`Name_series`,
`series`.`Number`,
`author`.`first_Name`,
`author`.`last_Name`
FROM
`series`
INNER JOIN `book` ON (`series`.`Series_id` = `book`.`Series_id`)
INNER JOIN `genre` ON (`book`.`Genre_id` = `genre`.`Genre_id`)
INNER JOIN `author` ON (`book`.`Author_id` = `author`.`Author_id`)
GROUP BY
`genre`.`Name_genre`,
`book`.`Name_book`,
`series`.`Name_series`,
`series`.`Number`,
`author`.`first_Name`,
`author`.`last_Name`
Запит який здійснює вибірку читачів замовивши книгу з автором на імя Дмитро.
SELECT first_Name_reader,last_Name_reader FROM reader WHERE
Reader_id IN
(SELECT Printed_matter_id FROM orderr WHERE Printed_matter_id IN
(SELECT Book_id FROM book WHERE author_id IN
(SELECT Author_id FROM author WHERE first_Name = Дмитро)
)
)
база даний автоматизація інформація собака
3. РЕАЛІЗАЦІЯ МОДЕЛІ БАЗИ ДАНИХ "БІБЛІОТЕКИ" У MYSQL 5.5. ІНСТРУМЕНТАЛЬНІ ЗАСОБИ
3.1 Мотивований вибір СКБД для реалізації проекту
Існує безліч видів СКБД. Наприклад: Oracle10g, MySQL, MS SQL Server і багато інших.
Oracle Database або Oracle RDBMS - обєктно-реляційна система управління базами даних компанії Oracle [24].
Основні характеристики СКБД Oracle
1) високa надійність;
2) можливість розбиття великих баз даних на розділи (large-database partition), що дає можливість ефективно управляти гігантськими гігабайтними базами;
3) наявність універсальних засобів захисту інформації;
4) ефективні методи максимального підвищення швидкості обробки запитів;
5) індексацію за бітовому відображенню;
6) вільні таблиці (в інших СКБД усі таблиці заповнюються відразу при створенні);
7) розпаралелювання операцій у запиті;
8) наявність широкого спектру засобів розробки, моніторингу та адміністрування;
9) орієнтація на інтернет-технології;
Microsoft Office Access або просто Microsoft Access реляційна СКБД корпорації Microsoft. Має широкий спектр функцій, включаючи повязані запити, звязок із зовнішніми таблицями і базами даних. Завдяки вбудованій мові VBA, в самому Access можна писати програми, що працюють з базами даних [25].
Основні характеристики СКБД Access:
1) володіння всіма перевагами Windows технологій;
2) у таблиці Access форми запити і звіти зберігаються в одному файлі бази даних;
3) до складу Access включений ряд спеціальних програм, таких як конструктори і майстра;
4) у Access є апарат, який називається "побудовник виразів" ;
5) у Access є мова програмування ВБА;
6) є одночасний доступ декількох користувачів до загальної бази даних;
7) у Access є кошти, необхідні для роботи з іншими базами даних різних форматів;
MySQL - вільна реляційна система управління базами даних. Розробку та підтримку MySQL здійснює корпорація Oracle, що отримала права на торговельну марку разом з поглиненої Sun Microsystems, яка раніше придбала шведську компанію MySQL AB. Продукт поширюється як під GNU General Public License, так і під власною комерційною ліцензією [26].
Основні характеристики My SQL Server:
1) багато поточність і підтримка декількох одночасних запитів;
2) оптимізація звязків з приєднанням багатьох даних за один прохід;
3) записи фіксованої і змінної довжини;
4) гнучка система привілеїв і паролів;
5) до 16 ключів в таблиці. Кожен ключ може мати до 15 полів;
6) підтримка ключових полів і спеціальних полів в операторі;
7) підтримка чисел довжиною від 1 до 4 байт, рядків змінної довжини і позначень часу;
8) заснована на потоках, швидка система памяті;
9) утиліта перевірки і ремонту таблиці (isamchk);
10) всі операції роботи з рядками не звертають уваги на регістр символів в оброблюваних рядках;
11) псевдоніми застосовні як до таблиць, так і до окремих колонок у таблиці;
12) всі поля мають значення за замовчуванням. можна використовувати на будь-якому підмножині полів;
13) легкість керування таблицею, включаючи додавання і видалення ключів і полів;
Розглядаючи особливості побудованої логічної моделі даних видно що для реалізації бази даних найкращим варіантом буде використання СКБД My SQL Server.
MySQL - компактний багато поточний сервер баз даних. Характеризується великою швидкістю, стійкістю і простотою використання. MySQL вважається гарним рішенням для малих і середніх застосувань[27].
Можливості сервера MySQL:
- простота у встановленні та використанні;
- підтримується необмежена кількість користувачів, що одночасно працюють із БД;
- кількість рядків у таблицях може досягати 50 млн.;
- висока швидкість виконання команд;
- наявність простої і ефективної системи безпеки.
3.2 Реалізація бази даних
Головна таблиця це "Library", в неї є одне ключеве поле - Bibrary_id (Номер книги). Він починається з одиниці і збільшується на один з кожним наступним пристроєм. Також в таблиці "Library" є наступні поля:
- adress (адреса бібліотеки)
- name_library (назва бібліотеки)
- telephone (телефон бібліотеки)
- type_library_id (номер виду) - ключ, з таблиці "Type_library"
Таблиця "Library" призначена для зберігання інформації про різні бібліотеки та їх телефон і адресу.
Для взаємодії таблиць "Library" і "Type_library" прописуються References - звязки між ними що забезпечує неможливість введення не існуючого ключа типу бібліотек. Кожний запис складається з наступних полів, опис яких наведено в таблиці 3.1
"right">Таблиця 3.1Таблиця "Library"
Імя поля |
Тип даних |
Опис |
|
Biblary_id |
Integer |
номер бібліотеки ключ |
|
Name_library |
Varchar |
Назва бібліотеки |
|
adress |
Varchar |
Адреса бібліотеки |
|
telephone |
Integer |
Телефон бібліотеки |
|
Type_library_id |
Integer |
Номер виду |
Таблиця "Type_library" зберігає інформацію про види бібліотек. В ній будуть зберігатися види бібліотек та їх номер. Кожен запис таблиці складається з полів, наведених у таблиці 3.2.
"right">Таблиця 3.2Таблиця "Type_library"
Імя поля |
Тип даних |
Опис |
|
Type_library_id |
Integer |
код бібліотеки, ключове поле |
|
Type_Name |
Varchar |
Назва бібліотеки |
Таблиця "Printed_matter" зберігає інформацію про наявність книги в одній з бібліотек. Кожен запис таблиці складається з полів, наведених у таблиці 3.3.
"right">Таблиця 3.3Таблиця "Printed_matter"
Імя поля |
Тип даних |
Опис |
|
Printed_matter_id |
Integer |
Номер печатного видання, ключове поле |
|
Biblary_id |
Integer |
Номер бібліотеки |
Таблиця "Orderr" Зберігає інформацію про замовлені читачами книги. Кожен запис таблиці складається з полів, наведених у таблиці 3.4.
"right">Таблиця 3.4Таблиця "Orderr"
Імя поля |
Тип даних |
Опис |
|
Order_id |
Integer |
Номер замовлення, ключове поле |
|
Printed_matter_id |
Integer |
Номер печатного видання |
|
Reader_id |
Integer |
Номер читача |
|
DateTime |
Data |
Дата замовлення |
Таблиця "Author" призначена для зберігання інформації про авторів книг. Кожний запис складається з наступних полів, опис яких наведено в таблиці 3.5
"right">Таблиця 3.5Таблиця "Author"
Імя поля |
Тип даних |
Опис |
|
Author_id |
Integer |
Номер автора, ключове поле |
|
First_Name |
Varchar |
Імя автора |
|
Last_Name |
Varchar |
Прізвище автора |
Таблиця "Series" зберігає інформацію про серії. В ній будуть зберігатися номер серії, назви серії та число книг у серії. Кожен запис таблиці складається з полів, наведених у таблиці 3.6.
"right">Таблиця 3.6Таблиця "Series"
Імя поля |
Тип даних |
Опис |
|
Series_id |
Integer |
Номер серії, ключове поле |
|
Name_series |
Varchar |
Назва серії |
|
Number |
Integer |
Число книг у серії |
Таблиця "Genre" зберігає інформацію про жанри книг. Кожен запис таблиці складається з полів, наведених у таблиці 3.7.
"right">Таблиця 3.7Таблиця "Genre"
Імя поля |
Тип даних |
Опис |
|
Genre_id |
Integer |
Номер жанру, ключове поле |
|
Name_genre |
Varchar |
Назва жанру |
Таблиця "Book" зберігає інформацію про книги. Кожен запис таблиці складається з полів, наведених у таблиці 3.8.
"right">Таблиця 3.8Таблиця "Book"
Імя поля |
Тип даних |
Опис |
|
Book_id |
Integer |
Номер книги, ключове поле |
|
Printed_matter_id |
Integer |
Номер печатного видання |
|
Name_book |
Varchar |
Назва книги |
|
Genre_id |
Integer |
Номер жанру |
|
Author_id |
Integer |
Номер автора |
|
Series_id |
Integer |
Номер серії |
Таблиця "Magazine" Зберігає журнали. Кожен запис таблиці складається з полів, наведених у таблиці 3.9.
"right">Таблиця 3.9Таблиця "Magazine"
Імя поля |
Тип даних |
Опис |
|
Magazine_id |
Integer |
Номер журналу, ключове поле |
|
Printed_matter_id |
Integer |
Номер пчатного видання |
|
Name_magazine |
Varchar |
Назва журналу |
|
Genre_id |
Integer |
Номер жанру |
Таблиця "Reader" Зберігає перелік читачів. Кожен запис таблиці складається з полів, наведених у таблиці 3.10.
"right">Таблиця 3.10Таблиця "Reader"
Імя поля |
Тип даних |
Опис |
|
Reader_id |
Integer |
Номер читача, ключове поле |
|
First_Name_reader |
Varchar |
імя читача |
|
Last_Name_reader |
Varchar |
прізвище читача |
|
Telephone_reader |
Integer |
Телефон читача |
|
Adress_reader |
Varchar |
адреса читача |
|
Biblerian_id |
Integer |
номер бібліотекаря |
|
Biblary_id |
Integer |
номер бібліотекаря |
Таблиця "Librarian" Зберігає перелік бібліотекарів. Кожен запис таблиці складається з полів, наведених у таблиці 3.11.
"right">Таблиця 3.11Таблиця "Librarian"
Імя поля |
Тип даних |
Опис |
|
Biblarian_id |
Integer |
Номер бібліотекаря ключове поле |
|
First_Name_librarian |
Varchar |
імя бібліотекаря |
|
Last_Name_librarian |
Varchar |
прізвище бібліотекаря |
|
Work_time |
Varchar |
Час роботи |
|
Biblary_id |
Integer |
Номер бібліотеки |
3.3 Результати, одержані при роботі з БД
- ПЕРЕЛІК ПОЗНАЧЕНЬ ТА СКОРОЧЕНЬ
- ВСТУП
- 1.2 Аналіз наданої предметної області
- 1.2.1 Система бізнес-правил
- 1.2.2 Глосарій проекту
- 1.3 Постановка задачі дослідження
- 2. МОДЕЛЮВАННЯ ДАНИХ ПРЕДМЕТНОЇ ОБЛАСТІ
- 2.1 Розробка концептуальної моделі даних
- 3.3.1 Розробка уявлень для відображення результатів вибірки
- 3.3.2 Проектування збережених процедур
- ВИСНОВКИ