обхідності цей зв'язок вводити в модель не слід. У даному випадку цей зв'язок необхідна, оскільки передбачається, що в системі можуть бути запити, спрямовані від викладача до студента і навпаки. Це означає, що може знадобитися інформація про викладачів, навчальних конкретного студента, або про студентів, що навчаються у даного викладача. br/>
Між об'єктами СТУДЕНТ і ПРЕДМЕТ також існує двостороння множинна зв'язок. Але в цьому випадку зв'язок, спрямовану від об'єкта ПРЕДМЕТ до об'єкта ПРЕДМЕТ в модель даних вводити не будемо, так як передбачається, що запитів, спрямованих від предмета до студента не буде. br/>
Між об'єктами ВИКЛАДАЧ і ПРЕДМЕТ існує двостороння множинна зв'язок. Враховуючи, що можливі запити від викладача до предмета і навпаки, цей зв'язок введемо в модель даних. p align="justify"> У концептуальній схемі ці зв'язки відображаються відповідною структурою даних (моделлю даних). Зв'язки 1: М відображаються ієрархічної або, інакше, деревовидної моделлю, а зв'язки М: М - мережевий або графовой моделлю. Існують СУБД, що підтримують ці моделі даних: ієрархічні і мережеві СУБД. Однак такі СКБД розроблялися для використання їх на великих ЕОМ. p align="justify"> Переважна більшість СУБД для персональних ЕОМ підтримують реляційну модель даних. Існують прийоми, що дозволяють перетворити ієрархічну і мережеву моделі в реляційну. p align="justify"> Тепер необхідно проаналізувати зв'язки, що існують між властивостями об'єктів. У процесі такого аналізу для кожного з властивостей визначається тип зв'язку, що існує між даними властивістю і кожним з інших властивостей об'єкта. p align="justify"> Так, наприклад, можна встановити, що для об'єкта СТУДЕНТ між властивістю № залікової книжки і кожним з інших властивостей існує зв'язок 1:1. Це означає, що кожному конкретному номеру залікової книжки відповідає єдине значення властивостей ПІБ, Група та Середній бал, тобто конкретний номер залікової книжки унікальним чином ідентифікує конкретний екземпляр об'єкта типу СТУДЕНТ. Справді, кожен із студентів має залікову книжку з унікальним номером. p align="justify"> Надалі ми дізнаємося, що таке властивість можна вибрати в якості первинного ключа для запису типу СТУДЕНТ.
Подібний аналіз необхідно провести для кожного з властивостей. Якщо виявиться, що ще яке-небудь з властивостей знаходиться у зв'язку 1:1 з одним або декількома властивостями, можливо, що сукупність цих властивостей належить об'єкту іншого типу. Розглянутий об'єкт доведеться розділити на два об'єкти, кожен з яких має власний первинний ключ. br/>
. Обмеження, що накладаються на дані
У логічній структурі даних неможливо вичерпно описати всі властивості об'єктів предметної області. Так в ...
