Перш за все, я дуже рекомендую науковий документ, в якому доктор Едгар Френк Кодд опублікував реляційні рамки для широкої громадськості в 1970 році, тобто "Реляційна модель даних для великих спільних банків даних" . Там, у розділі 1.1, "Вступ", сам доктор Кодд заявляє, що:
Ця стаття стосується застосування елементарної теорії відношень до систем, які забезпечують спільний доступ до великих банків форматованих даних.
© Асоціація обчислювальної техніки. Комунікації ОСББ, том 13, випуск 6 (с. 377-387), червень 1970 року.
Отже, так, терміни співвідношення і (отже, реляція походять від математичного походження). Доктор Кодд, який, окрім своїх академічних та дослідницьких даних, мав близько 20 років досвіду роботи з обчислень та обробки інформації - передбачив величезні переваги застосування цього відношення (абстрактна конструкція, природно) у галузі управління даними. .
Я не математик, але, в основному, відношення - це асоціація між множинами , множина - це сукупність елементів ( цей зовнішній ресурс дає визначення математичного відношення, яке може допомогти зрозуміти це з іншого погляду). Під час роботи за допомогою системи управління базами даних SQL (СУБД для стислості) добре відомим наближенням відношення є таблиця , в цьому випадку асоціація відбувається між типами його стовпців . Очевидно, що в платформах SQL, які пропонують підтримку DOMAIN (наприклад, Firebird та PostgreSQL ), асоціація відбувається міждомени, закріплені за стовпцями відповідної таблиці; див. розділи нижче, щоб отримати більш детальну інформацію.
У цьому відношенні я знову наводжу доктора Кодда, який у розділі 1.3 "Реляційний погляд на дані" стверджує, що:
Термін відношення тут використовується в його прийнятому математичному значенні. Дані множини S 1 , S 2 , ⋯, S n , (не обов'язково виразні), R - відношення до цих n множин, якщо це набір n- пар, кожен з яких має свій перший елемент від S 1 , другий його елемент від S 2 тощо. 1 Ми будемо називати S J як J - й області з R . Як визначено вище, R, як кажуть, має ступінь n. Відносини ступеня-часто називають унарна , ступінь 2 довічних , ступінь 3 потрійних , і ступінь п п-кова .
1 Більш коротко, R є підмножиною декартового добутку S 1 × S 2 × S 3 ⋯ × S n .
© Асоціація обчислювальної техніки. Комунікації ОСББ, том 13, випуск 6 (с. 377-387), червень 1970 року.
І я погоджуюся з іншими відповідями в тому, що дуже актуально зазначити, що доктор Кодд вніс деякі адаптації в математичне відношення, щоб отримати максимальну користь від цього щодо управління даними, і вони пояснюються в документі, про який говорилося раніше і у всій його широкій бібліографії .
Відносини та стосунки
Ситуація, яку варто підкреслити, полягає в тому, що при роботі з цими предметами може виникнути плутанина через подібність, що існує щодо повсякденних (нематематичних, нетехнічних) визначень термінів співвідношення та відносини - які як не- носія англійської мови, мені здається особливо зрозумілою -.
Вид сутність-зв'язок і реляційна модель
Інший фактор, який, на мою думку, може також викликати плутанину (і тісно пов'язаний з технічними конотаціями двох викладених вище термінів) - це те, що під час навчання проектування баз даних студент або практик, як правило, спочатку знайомиться з методологією, запропонованою д-ром Пітер Пін-Шен Чен у погляді на дані про відносини між сутностями (опубліковані в 1976 р.), Який пропонує два різних реалізація (тобто сутність та взаємозв'язок ) для розмежування концептуальної схеми, і то лише після визначення зазначеної схеми. є стабільним, студент або практик знайомиться з реляційними термінами та інструментами (наприклад, відношення ) при оголошеннілогічне розташування відповідної бази даних. У концептуальній системі відліку відносини містять конотації, які набагато ближче до повсякденного сенсу цього слова.
Тоді, можливо, ця обставина також додає до питання про співвідношення та відносини - але послідовність спочатку визначення концептуальної схеми та згодом декларування відповідного логічного задуму, звичайно, цілком доречна, як я деталізую в наступних розділах.
Відповіді на кожне ваше запитання
Я вважаю, що включення цих трьох піддослідних справді доречне, оскільки вони встановлюють більш широкий контекст для посади, тому їх не можна не помічати. Таким чином, крім виключно адресації , чому терміни відносини і реляційна використовуються (що , безумовно , є дуже важливим і є назва посади, але це НЕ весь пост), сказав подвопроси може допомогти в розумінні більше обсягу ставлення і реляційна модель , коли один беруть участь в проекті управління всією інформацією (саме на часі , так як це сайт про адмініструванні баз даних) і , отже , працює на різних рівнях абстракції. Таким чином я збираюся поділитися своєю детальністю нижче.
Підпитання немає. 1
Чому, наприклад, Особу вважають "відношенням"? В англійській мові відношення - це іменник, який описує, як пов’язуються дві сутності. Це не стосується самих утворень. У контексті реляційних баз даних "відношення" відноситься до самих сутностей. Чому?
Концептуальний рівень
У даному бізнес-середовищі людину можна вважати типом сутності залежно від того, як люди, які працюють там (фахівці з бізнесу та дизайнери баз даних) концептуалізують це. І, так, в цьому бізнес - середовищі, можуть бути різні властивості , що представляють інтерес по відношенню до особистості типу об'єкта, наприклад, ім'я , BirthDate , Пол і т.д.
Крім того, тип юридичної особи Особи може мати певні типи відносин (або асоціацій або з'єднань ) із самим собою або іншими типами сутності; наприклад, особа може бути асоційована з типом сутності з назвою UserProfile , який, в свою чергу, може мати свої цікаві властивості, скажімо, ім'я користувача та пароль .
Але, (a) типи сутностей, (b) їх відповідні властивості, (c) типи відносин між типами суб'єктів господарювання та (d) відносини між самими властивостями - це поняття, які "належать" до конкретного бізнес-середовища, в якому вони перебувають вважається важливим. Це пристрої, що використовуються дизайнерами баз даних, які тісно співпрацюють з бізнес-експертами з метою визначення концептуальної схеми , що залежить від контексту , на етапі проектування.
Таким чином, на концептуальному рівні ми в основному працюємо зі структурою ідей, які виникають у реальному світовому сегменті інтересу, тобто (1) прототипи речей та (2) прототипи зв’язків між прототипами речей , з якими ми не працюємо (3) відносини - використання цього останнього терміна у значенні реляційної рамки даних.
Логічний рівень
Після того, як Особа була точно визначена як тип сутності на концептуальному рівні, і якщо хочеться реалізувати реляційну базу даних, яка передає значення Персони та всі пов'язані з нею поняття, то фактами про сутності цього типу можна керувати в силу математичного відношення на логічному рівні , і скористатися науково обгрунтованими операціями, які можна виконувати на цій абстрактній конструкції (тобто визначати її, обмежувати і маніпулювати нею).
Так, можна визначити певне відношення Людина, коли визначає логічне розташування бази даних, але це не перетворює поняття «реального світу» Особи у відношення, а підходить до неї як таке через переваги, які отримуються під час управління інформацією наприклад, застосовуючи операції з відносної алгебри на ньому для отримання нових відносин (і, отже, є отримання "нової" інформації). Зазначені переваги стають більш очевидними, враховуючи той факт, що сутності певного типу складають множину, а значення певної властивості складають також множину.
І так, як зазначено в попередніх параграфах та інших відповідях, одним із найважливіших аспектів відношення є зв’язок, що існує між його доменами - які зазвичай використовуються для представлення властивостей типів сутності або асоціації, що входять до складу концептуальна схема -. Наприклад, скажімо, що ми оголосили таке (потрійне) відношення:
Salary (PersonNumber, EffectiveDate, Amount)
… І припустимо, що у відповідному бізнес-середовищі кортеж - який (i) означає конкретну сутність , тобто екземпляр типу сутності з відповідної концептуальної схеми та (ii) чий аналог SQL є рядок -
… Матиме значення
- "Зарплата, що виплачується особі, визначеній PersonNumber
xна EffectiveDate, yвідповідає Сумі z" .
Відповідно - щоб описати речі приблизним чином - зв’язок між трьома доменами має найважливіше значення, всі вони пов'язані (і, так, унарне відношення передбачає лише один домен). Зв'язок між усіма значеннями певного домену теж дуже вагомий, оскільки вони складають набір точного типу . Також вміст кожного кордону Salaryвідносини повинен відповідати структурі твердження, проілюстрованому вище.
Концептуальний рівень відносин і логічний рівень відносини
Як було показано, я зараз мав справу з управлінням базами даних на двох різних рівнях абстрагування, а саме концептуальному та логічному, і ще є нижчий рівень, відомий як фізичний , який у SQL СУБД зазвичай включає, наприклад, індекси, сторінки, розширення, тощо.
Отже, відповідно до пояснень, що були раніше пояснені, на логічному рівні людина працює виключно з (а) математичними відносинами, де (b) концептуальні зв'язки або асоціації представлені (c) значеннями, що містяться в кордонах таких математичних відносин, і зазначені значення зазвичай розмежовуються за допомогою обмежень FOREIGN KEY, щоб вони могли точно представляти застосовні відносини.
І так, асоціативні сутності, тобто випадки типів відносин з коефіцієнтом кардинальності багато-багато (M: N), можна передати за допомогою кортежів одного математичного відношення - за допомогою відповідних обмежень, оголошених належним чином, звичайно -.
Підпитання немає. 2
Я розумію, що реляційна модель прийшла після ієрархічної та мережевої моделей. Але в цих моделях суб'єкти також мають відносини один до одного. То чому б називати цю модель реляційною моделлю? Чи є більш конкретна фраза / термін? Чи, можливо, слід сказати, що всі три моделі є реляційними моделями, але ієрархічні та мережеві моделі - це конкретні типи реляційних моделей?
Мережеві та ієрархічні СУБД передували їх формальній теоретичній підтримці
Доречно зазначити, що теоретична підтримка навколо ієрархічного та мережевого підходів насправді була створена на основі раніше існуючих СУБД, з метою, серед інших аспектів, тестування та встановлення надійності (1) зазначених видів програмного забезпечення та (2) пов'язаних практик управління даними - явище перевернуте, з моєї точки зору -.
Неповний у порівнянні з реляційною рамкою
Незважаючи на це, хоча існують ієрархічні та мережеві СУБД, які передували реляційній моделі, і навіть коли доктор Кодд називав кожен із цих підходів як "модель", жодна не визначається як така, якою є реляційна структура. Реляційна парадигма надає наукові конструкції для (i) визначення, (ii) обмеження та (iii) маніпулювання даними, а ієрархічний та мережевий підходи не мають повного теоретичного супроводу, щоб охопити всі три вищезгадані конструкції.
Мережеві та ієрархічні особливості
Крім того, як було сказано раніше, типи сутності та відносини - це пристрої на концептуальному рівні, вони не належать до ієрархічного або мережевого підходу, кожен з яких пропонує конкретні механізми для представлення зазначених аспектів:
Мережева парадигма передбачає два пристрої для представлення даних, тобто вузли та дуги (і, звичайно, ця характеристика передбачає два різні види операцій з маніпулювання даними), які, протиставляючи реляційній моделі, яка (відповідно до інформаційного принципу ) вимагає лише однієї конструкції (співвідношення), стає очевидним непотрібність, яка пов'язана з мережею. Наприклад, враховуючи, що він вдається до двох інструментів представлення, мережевий підхід накладає непрактичне зміщення запитів, що перешкоджає маніпулюванню даними.
Зі свого боку, ієрархічний вигляд пропонує представити дані за допомогою (фізичних!) Файлів, що складаються із записів (які, у свою чергу, складаються з полів ), організованих у три схожий спосіб; тобто один батьківський запис, пов’язаний ланцюжком із можливо багатьма дочірніми аналогами через покажчики , що створює фізичний шлях доступу щодо маніпулювання даними. Такий підхід також є несприятливим, оскільки представляє заплутаність між концептуальними та фізичними аспектами, тому зміни у форматі фізичного зберігання потребують реорганізації структур даних, що, в свою чергу, вимагає змін щодо операцій з обробки даних.
Як показано, ієрархічні та мережеві погляди накладають свої конструкції на дані, якими слід керувати, тоді як реляційна модель пропонує керувати даними елегантно в їх природній структурі за допомогою набору супутніх фактів (з яких n наступних типів множин, не очікуваних при фаза проектування, може бути виведена тощо!).
Реляційна модель не має підмоделей
І, що дуже важливо, ні ієрархічний, ні мережевий вигляд не є специфічними типами реляційних моделей, вони є просто іншими парадигмами, за якими хтось може дотримуватися (a) створення СУБД і (b) створення баз даних, але врахуйте, що ієрархічна а мережеві підходи вже десятиліттями вважаються застарілими.
Підпитання немає. 3
Що робити, якщо у нас є самостійні сутності, які не стосуються один одного. Скажіть, особа, двері та дерево. Чи термін "відношення (al)" все ще застосовується?
Так, він цілком застосований, якщо (1) керувати інформацією про ці типи сутності за допомогою мастила адаптованих математичних співвідношень та (2) виконувати застосовні реляційні операції на логічному рівні в певній базі даних, керованій за підтримки заданих реляційних СУБД .
Не має значення, якщо на концептуальному рівні вказані типи сутностей не мають типів відносин з іншими типами сутності (і варто зазначити, що тип сутності може мати відношення співвідношення «один до нуля-один-чи-багато») з самим собою), і таким чином не можна передавати і не нав'язувати жодної залежності між значеннями кортежів розглянутих відносин.
