База даних підприємства
Курсовой проект - Компьютеры, программирование
Другие курсовые по предмету Компьютеры, программирование
?ермінології дотримуються в більшості комерційних реляційних СУБД.
3.2 Визначення звязків інформаційних обєктів і побудова інформаційно - логічної моделі
Та властивість, що відносини не містять кортежів-дублікатів, треба з визначення відносини як безлічі кортежів. У класичній теорії множин по визначенню кожна безліч складається з різних елементів.
Із цієї властивості випливає наявність у шкірного відношення так називаного первинного ключа - набору атрибутів, значення яких однозначно визначають кортеж відносини. Для шкірного відношення принаймні повний набір його атрибутів має цю властивість. Однак при формальному визначенні первинного ключа потрібне забезпечення його "мінімальності", тобто в набір атрибутів первинного ключа не повинні входити такі атрибути, які можна відкинути без шкоди для основної властивості - однозначно визначати кортеж. Поняття первинного ключа є винятково важливим у звязку з поняттям цілісності баз даних.
В багатьох практичних реалізаціях СУБД допускається порушення властивості унікальності кортежів для проміжних відносин, породжуваних неявно при виконанні запитів. Такі відносини є не безліччю, а мультимножествами, що в ряді випадків дозволяє домогтися певних переваг, алі іноді приводити до серйозних проблем.
Атрибути відносин не впорядковані, оскільки по визначенню схема відносини є безліч пар {імя атрибута, імя домена}. Для посилання на значення атрибута в кортежі відносини завжди використається імя атрибута. Це властивість теоретично дозволяє, наприклад, модифікувати схеми існуючих відносин не тільки шляхом додавання нових атрибутів, алі й шляхом видалення існуючих атрибутів. Однак у більшості існуючих систем така можливість не допускається, і хоча впорядкованість набору атрибутів відносини явно не потрібно, часто як неявний порядок атрибутів використається їхній порядок у лінійній формі визначення схеми відносини.
3.3 Визначення логічної структури бази даних
Коли в попередніх розділах мі говорили про основні поняття реляційних баз даних, мі не опиралися на яку-небудь конкретну реалізацію. Ці міркування рівною мірою ставилися до будь-якої системи, при побудові якої використався реляційний підхід.
Інакше кажучи, мі використали поняття так називаної реляційної моделі даних. Модель даних описує деякий набір родових зрозуміти й ознак, якими повинні володіти всі конкретні СУБД і керовані ними бази даних, якщо смороду ґрунтуються на цій моделі. Наявність моделі даних дозволяє порівнювати конкретні реалізації, використовуючи одну загальну мову.
Хоча поняття моделі даних є загальним, і можна говорити про ієрархічної, мережний, деякої семантичну й т.д. моделях даних, потрібно відзначити, що це поняття було поведене в побут стосовно до реляційним систем і найбільше ефективно використається саме в цьому контексті. Спроби прямолінійного застосування аналогічних моделей до дореляційним організацій показують, що реляційна модель занадто "велика" для них, а для постреляційних організацій вона виявляється "мала".
Найпоширеніше трактування реляційної моделі даних, мабуть, належить Дейту, що відтворює її (з різними уточненнями) практично у всіх своїх книгах. Згідно Дейту реляційная модель складається із трьох частин, що описують різні аспекти реляційного підходу: структурної частини, манипуляційної частини й цілісній частині.
У структурній частині моделі фіксується, що єдиною структурою даних, використовуваної в реляційних БД, є нормалізоване n-арное відношення. По суті справи, у попередніх двох розділах цієї лекції мі розглядали саме поняття й властивості структурної складової реляційної моделі.
У манипуляционной частини моделі затверджуються дві фундаментальних механізми маніпулювання реляційними БД - реляційна алгебри й реляційне вирахування. Перший механізм базується в основному на класичній теорії множин (з деякими уточненнями), а другий - на класичному логічному апарату вирахування предикатів першого порядку. Мі розглянемо ці механізми більш докладно на наступній лекції, а поки лише помітимо, що основною функцією маніпуляційної частини реляційної моделі є забезпечення міри реляційності будь-якої конкретної мови реляційних БД: мова називається реляційним, якщо він має не меншу виразність і потужність, чим реляційна алгебра або реляційне вирахування.
4. Обєкти бази даних
Рис 4.1.1 Таблиця "Міцелій прихід"
Рис 4.1.2 Таблиця "витрата міцелію"
Рис 4.1.3 Таблиця "Паспорт партії"
Рис.4.1.4 Таблиця "Постачальники"
Рис 4.1.5 Таблиця "Збір"
Наведені вище таблиця, своєю структурою зобовязані вхідним даним їх яким їх сформували. Природно що серед полів є й ті які несуть результати вичислених значень, написання програми не мало змісту, не маючи кінцевого результату. Показання вище структура таблиць досить автономна, але й одночасно міцно на міцно звязана один з одним. Також хочу помітити що складно виділити головну базу й визначити залежні, тому що заповнення даннями і їх оперування в багатьох випадках мають свіязь "багато хто до багатьох"
Таблиця "прихід міцелію" рис 4.1.1 містить у собі інформацію про надходження на склад ресурсу міцелій. Має ключове поле номер партії міцелію. Це основне й унікальне значення використається із привязкою в базі паспорт партії