Робота з oracle 1 початок, vr-online - безкоштовний електронний журнал для всіх
Так як обсяг статті не дозволить викласти матеріал в повній мірі (та таке завдання і не ставиться), то я буду коротко описувати необхідні мінімальні дії для створення робочого варіанту програми. В рамках статті ми спробуємо розробити програму з обліку замовлень (в якій області ви вирішите самі, тому що схема в принципі універсальна), в якій буде присутній довідник клієнтів, довідник виробів і власне сам журнал замовлень. Я вирішив взяти цю тему, так як вона досить таки типова, і дуже часто присутня в інформаційних системах.
Перш ніж писати додаток, відповідно до теорії створення інформаційних систем, а розробляється нами додаток і є міні-системою, необхідно виконати так зване фізичне проектування бази даних, тобто створити фізичну модель даних - схему, де будуть відображені створювані таблиці і зв'язку між ними. Взагалі професіонали (в моєму розумінні це люди які заробляють цим на життя), використовують для проектування баз даних так звані CASE-засобу, програми для створення схем баз даних (логічних / фізичних), які дозволяють потім згенерувати розроблену схему в обрану СУБД, т. е. спростити (прискорити) процес розробки інформаційної системи. Ми ж, як новачки, для розуміння того, що відбувається будемо малювати цю схему вручну (за допомогою Paint'а).
Для реалізації нашої бази необхідно створити чотири таблиці:
Замовлення, Позиції замовлення, Клієнт, Виріб.
Тепер визначимося зі структурою таблиць.
Таблиця "Замовлення" буде виглядати наступним чином:
Таблиця "Позиції" замовлення буде виглядати наступним чином:
Таблиця "Клієнт" буде виглядати наступним чином:
Таблиця "Виріб" буде виглядати наступним чином:
Таким чином, схема нашої бази даних буде виглядати так:
Ця схема Новомосковскется так: Клієнт виконує Замовлення, який містить Позиції, в які входять мобільного телефону. «Куряча лапка» на кінці стрілки позначає, що зв'язок Один-Ко-Багатьом, тобто один і той же виріб може входити в Позиції різних Замовлень, в той час як одна Позиція замовлення може включати тільки одне найменування мобільного телефону. Те ж саме щодо зв'язку Замовлення / Позиції замовлення: одному Замовленню відповідає багато Позицій, в той час як одна і та ж Позиція може входити тільки в один Замовлення; і зв'язку Замовлення / Клієнт: один Клієнт може робити багато Замовлень, в той час як одному Замовленню відповідає тільки один Клієнт.
Але ці правила (обмеження предметної області) можуть змінюватися в різних ситуаціях. Наприклад, замовлення можуть виконувати кілька клієнтів (буває і таке). Але в нашому проекті ми приймемо саме такий варіант, для простоти проектування.
Отже, схема нашої майбутньої бази готова, це так би мовити кістяк майбутньої «інформаційної системи».
Далі я покажу як реалізувати цю схему в СУБД Oracle.
Коротко розповім про Oracle. У цій СУБД (іноді звучить назва «сервер»), користувач працює з об'єктами, основними з яких є (точніше які необхідні нам):
- Таблиці - основні таблиці, які складають базу даних;
- Індекси - індекс створюється за стовпцем або набору стовпців;
- Уявлення - віртуальні таблиці, засновані на SQL-запитах;
- Послідовності - генератор послідовностей Oracle використовується для автоматичної вироблення унікальної послідовності чисел в кеші (лічильник);
- Функції - представляють собою набір операторів мови SQl або PL / SQL;
- Процедури - відрізняються від функцій тим, що не повертають результату;
- Тригери - це код (програма), який зберігається в базі даних і викликається подіями (наприклад, вставка даних в таблицю).
Створювати таблиці будемо в схемі SCOTT, це навчальна схема, яка створюється за замовчуванням при установці сервера, пароль для даної схеми TIGER. Здійснювати все це будемо засобами Sql Plus, я вважаю за краще графічні засоби командного рядка, хоча можливий і варіант з командного рядка. Хоча існує безліч візуальних засобів для роботи з СУБД Oracle від сторонніх розробників, я, наприклад, люблю користуватися продуктом Quest Software TOAD. У цій програмі є засоби для створення об'єктів БД, адміністрування, вивчення структур БД, конструювання запитів і т.д. і т.п. Загалом, раджу подивитися.
Отже, при запуску Sql Plus потрібно ввести ім'я користувача, пароль і базу, до якої будемо приєднуватися:
Для таблиці КЛІЄНТ:
Для таблиці ИЗДЕЛИЕ:
Для таблиці ЗАМОВЛЕННЯ:
Для таблиці ПОЗИЦІЇ ЗАМОВЛЕННЯ:
Спробую пояснити що є що. Конструкція CREATE TABLE створює таблицю (я думаю ви і без мене це зрозуміли), в дужках перераховуються стовпці створюваної таблиці, відповідно вказується найменування стовпця, тип даних (при необхідності розмір), значення за замовчуванням (default), обмеження на значення (not null - значення д.б.н. визначено), яке в даному випадку означає що в стовпець обов'язково повинно бути занесено яке-небудь значення, інакше СУБД буде матюкатися при спробі додавання рядка без даних в цьому стовпці. Таким чином, накладаючи певні обмеження ми передбачаємо ймовірність того що користувач забуде ввести дані, які обов'язково повинні бути введені, за цим буде стежити СУБД. Погодьтеся, замовлення без номера це не замовлення, принаймні там де я працюю це саме так, без номера замовлення ніхто і пальцем не поворухне.
Конструкція CREATE UNIQUE INDEX створює індекс в таблиці, він потрібен для прискореного пошуку, сортування даних в стовпці. Індексувати обов'язково ключові стовпці, і стовпці за якими найчастіше відбувається пошук, сортування даних (наприклад, в запитах).
Конструкція ALTER TABLE ім'я_таблиці ADD (CONSTRAINT імя_ограніченія PRIMARY KEY (ім'я_стовпця)) вказує базі якої стовпець є ключовим.
Конструкція ALTER TABLE ім'я_таблиці ADD (CONSTRAINT імя_ограніченія FOREIGN KEY (ім'я_стовпця) REFERENCES родітельская_табліца (ім'я_стовпця)) створює зовнішній ключ в таблиці, це стовпець через який відбуватиметься зв'язок з батьківською таблицею. Наприклад, в таблиці Замовлення зв'язок з таблицею Клієнт відбувається через стовпець ID_KL. Після створення даного ключа видалення клієнта при прив'язці його хоча б до одного замовлення буде неможливо. Таким чином реалізується забезпечення несуперечності даних в базі. Наприклад, ви створили замовлення, прив'язали до нього позиції, а після цього (випадково чи свідомо) видалили замовлення, таким чином, ці позиції втратять зв'язок з певним замовленням, і не будуть пов'язані ні з одним з них, виходить, база знаходиться в суперечливому стані - позиції є, а замовлення немає. А тепер уявіть: у додатку в формі Журналу замовлень для вибраного замовлення відображаються тільки прив'язані до нього позиції, тобто користувач не буде бачити інших позицій в базі, таким чином, у нас вийде кілька рядків в завислому стані, що не є добре. Для того щоб видалити потрібного клієнта необхідно буде видалити всі пов'язані з ним замовлення, тобто виконати зворотну послідовність введення інформації.
Завдяки таким інструментам сервер (СУБД), виконує роль контролера правильності введення інформації та її видалення, а може бути і взагалі заборони на її видалення (працював я і з такими системами, де взагалі видалення заборонено). Це і є так звані обмеження предметної області, про які я так часто згадую.
Ну ладно це все лірика, продовжимо. Далі нам необхідно буде реалізувати стовпці-лічильники, це виконується за допомогою наступних конструкцій:
Для таблиці КЛІЄНТ:
Для таблиці ИЗДЕЛИЕ:
Для таблиці ЗАМОВЛЕННЯ:
Для таблиці ПОЗИЦІЇ ЗАМОВЛЕННЯ:
Тут ми створюємо так звані послідовності, в них буде зберігатися значення для ключового стовпця, і з кожної вставкою рядки буде збільшуватися на одиницю (стовпець-лічильник). Для вставки значення послідовності застосовується тригер, який спрацьовує до вставки рядка (BEFORE INSERT). Таким чином, ми забезпечуємо унікальність вводятьсязначень в ключове поле.
Тепер ми закінчили (нарешті) з базою даних і можна приступати до створення нашого застосування, так би мовити оболонки нашої інформаційної системи.
Завантажуємо Delphi і створюємо новий додаток File-> New-> VCL Forms Application (врахуйте що це 10 версія, в 7, приміром, буде так: File-> New-> Application). Для реалізації нашої системи я буду використовувати компоненти доступу до даних розроблені фірмою Borland BDE. Як би не лаяли ці компоненти, я вважаю що вони забезпечують максимальні можливості предоставляеми цим середовищем розробки. Решта механізми зв'язку з даними накладають певні обмеження на їх використання, хоча в принципі все залежить від вирішуваних завдань, можливо в іншому випадку буде ефективніше використовувати dbExpress (наприклад, Borland рекомендує використовувати ці компоненти при створенні розподілених додатків).
Назвемо нашу головну форму «Журнал реєстрації замовлень» (властивість Caption) .Отже, на головну форму необхідно додати компонент DataBase з закладки BDE. Потім подвійним клацанням миші на даному компоненті відкриваємо вікно властивостей:
Тут в поле name пропишемо ім'я нашої бази (я написав ім'я моєї БД manuf), можна написати будь-який, і в поле Driver name вибрати драйвер ORACLE, потім натискаємо кнопку Defaults для додавання параметрів «за замовчуванням». Відповідно в вікні редагування з'явиться список параметрів, там видаляємо все крім SERVER NAME, USER NAME і PASSWORD. Для параметра SERVER NAME пишемо ім'я нашої БД в системі, USER NAME і PASSWORD відповідно SCOTT / TIGER. Також знімемо галочки зі властивостей Login prompt (запит користувача і пароля), і Keep inactive connection щоб з'єднання не було відкрито постійно і натискаємо ОК. Все, властивості з'єднання з БД налаштовані, можна встановити властивість нашого DataBase Connected в true для перевірки зв'язку, в разі якщо зв'язок налаштована неправильно, вилетить відповідне повідомлення.
За таким же принципом додаємо Table для інших таблиць, з компонентами DataSource, не забуваючи їх пов'язати з Table'амі, ну і звичайно осмислені імена Table'ов.
Тепер виконаємо остаточні дії з налаштування компонентів доступу до даних (ух як загнув): нам необхідно пов'язати таблицю Pos_zakaza з батьківської Zakaz, щоб в ній містилися дані саме для обраного замовлення. У Delphi це робиться дуже просто. У мене Table називається Pos_zakaza, вибираємо у властивості MasterSource DataSource пов'язаний з таблицею Zakaz, у мене це DataSource2. Потім у властивості MasterFields клацаємо на кнопці з трьома крапками і відкриваємо Field Link Designer, де вкажемо, через яке поле буде організована зв'язок з батьківською таблицею, тут в правому і лівому віконцях виберемо ID_ZAK і натиснемо Add, відповідно в нижньому віконці (Joined Fields), з'явиться зв'язок, натискаємо ОК. Все, тепер в таблиці Pos_zakaza будуть міститися дані відповідні вибраним замовленням. І ніякої ручної роботи.
Тут ми намагаємося відкрити нашу базу і все таблиці, при виникненні будь-якої помилки (виняткової ситуації), програма видасть повідомлення, і після цього закриє додаток. Таким чином, ми виключаємо можливість зависання програми при завантаженні в разі відсутності зв'язку, або іншої проблеми.
Потім йдемо все в той же інспектор об'єктів, шукаємо подія форми OnDestroy і прописуємо:
Тут ми програмно закриваємо з'єднання.
Тепер приступимо до приведення зовнішнього вигляду нашого застосування до належному увазі. Я не буду в подробицях описувати додавання на форму таких компонентів як панелі і гріди (думаю, ви і самі здогадаєтеся як їх розташувати), покажу лише що вийшло:
Ще хочу додати по зовнішньому вигляду нашої форми: я додав компонент MainMenu і додав в нього два пункти для відкриття довідників Клієнтів і Виробів, а також додав спліттер для можливості зміни розмірів таблиць Замовлень і Позицій замовлень, але ви можете придумати щось ще, в принципі це справа смаку.
Ну і звичайно розташуємо на формі DBNavigator'и для навігації по таблицях, зв'язавши їх з необхідними DataSource'амі. Перш ніж працювати з Журналом замовлень, необхідно додати можливість роботи з довідниками. Для цього додамо в додаток дві форми: для довідника Виробів і Клієнтів.
Заходимо в меню File-> New-> Form (або піктограма на панелі інструментів), міняємо назву (Caption) форми на Довідник клієнтів. Зберігаємо все це справа. Також чинимо до Довідника виробів.
це відкриття Довідника клієнтів
це відкриття Довідника виробів.
У вас нумерація форм може бути по-іншому. Ну і ще я постійно ставлю властивість форм Position в poScreenCenter щоб при відкритті форма з'являлася в центрі екрану.
Залишається тільки оформити нові форми наступним чином:
Для Довідника клієнтів:
Для Довідника виробів:
Тепер можете спробувати додавати клієнтів і вироби і формувати замовлення.
Ну, ось ніби і все. Наша міні-інформаційна система готова до роботи. Правда, тут не передбачені багато моментів (які в принципі не впливають на роботу), можна оформити все це справа належним чином, але це знову ж таки справа смаку (швидше за все користувачів системи).
Written by: Ronin ([email protected])