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

Однак у реляційных базах даних це не прийнято. Ім'я схеми відносини в таких базах даних завжди збігається з ім'ям відповідного відношення-екземпляра. У класичних реляційних базах даних після визначення схеми бази даних змінюються тільки відношення-екземпляри. У них можуть з'являтися нові й віддалятися або модифікуватися існуючі кортежі. Однак у багатьох реалізаціях допускається й зміна схеми бази даних: визначення нових і зміна існуючих схем відносини. Це прийнято називати еволюцією схеми бази даних .

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

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

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

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

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

Атрибути відносин не впорядковані, оскільки по визначенню схема відносини є безліч пар {ім'я атрибута, ім'я домена}. Для посилання на значення атрибута в кортежі відносини завжди використається ім'я атрибута. Це властивість теоретично дозволяє, наприклад, модифікувати схеми існуючих відносин не тільки шляхом додавання нових атрибутів, алі й шляхом видалення існуючих атрибутів. Однак у більшості існуючих систем така можливість не допускається, і хоча впорядкованість набору атрибутів відносини явно не потрібно, часто як неявний порядок атрибутів використається їхній порядок у лінійній формі визначення схеми відносини.

3.3 Визначення логічної структури бази даних

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

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

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

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

У структурній частині моделі фіксується, що єдиною структурою даних, використовуваної в реляційних БД, є нормалізоване 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 Запити

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

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

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