База даних підприємства (стр. 3 из 4)

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

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

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

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

4. Об'єкти бази даних

Рис 4.1.1 Таблиця "Міцелій прихід"

Рис 4.1.2 Таблиця "витрата міцелію"

Рис 4.1.3 Таблиця "Паспорт партії"

Рис.4.1.4 Таблиця "Постачальники"

Рис 4.1.5 Таблиця "Збір"

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

Таблиця "прихід міцелію" рис 4.1.1 містить у собі інформацію про надходження на склад ресурсу міцелій. Має ключове поле номер партії міцелію. Це основне й унікальне значення використається із прив'язкою в базі паспорт партії мал.4.1.3 Маючи загальне поле вони зв'язуються по ньому в співвідношенні один до багатьох.

Таблиця "Збір", містить основну інформацію про кількості зібраного продукту й датам збору. Вона щільно взаємодіє з таблицею паспорт партії й несе в собі інформацію для подальшого аналізу, побудови звітів і графіків.

4.2 Запити

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

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

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

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

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

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

Наприклад, для того щоб отримати вибіркову інформацію за заданими критеріями, використовуючи засоби мови програмування високого рівня ObjectPascal, треба написати SQLзапит. Якийповиненмативигляд:

Select t. Nomer_Partii,t. Nazvanie from “Pasport_partii. db, Sbor. db S" t where t. Nomer= S. Nomer AND S. Nazvanie=”АК-221”

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

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

Даний запит виводить інформацію про продану партію, яка має назву "АК-221".

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

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

4.3 Екранні форми введення й редагування даних

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

Зовнішній вигляд програми показаний на рисунку 4.3.1

Рис.4.3.1 "Зовнішній вигляд програми"

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

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

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

Рис 4.3.2 "Рух міцелію"

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

4.4 Звіти

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