її нащадки також повинні бути видалені.
Ієрархічні бази даних мають централізовану структуру, тобто безпека даних легко контролювати. На жаль, певні знання про фізичний порядок зберігання записів все ж необхідні, тому що відносини предок/нащадок реалізуються у вигляді фізичних покажчиків з одного запису на іншу. Це означає, що пошук запису здійснюється методом прямого обходу дерева. Записи, розташовані в одній половині дерева, шукаються швидше, ніж в іншій. p align="justify"> Звідси випливає необхідність правильно впорядковувати записи, щоб час їх пошуку було мінімальним. Це важко, тому що не всі відносини, що існують в реальному світі, можна виразити в ієрархічній базі даних. Відносини "один комногім" є природними, але практично неможливо описати відносини "багато до багатьох" або ситуації, коли запис має кілька предків. До тих пір поки в додатках будуть кодуватися відомості про фізичну структуру даних, будь-які зміни цієї структури будуть загрожувати перекомпіляцією. p align="justify"> Мережеві СУБД - Мережева модель розширює ієрархічну модель СУБД, дозволяючи групувати зв'язки між записами в безлічі. З логічної точки зору зв'язок - це не сам запис. Зв'язки лише виражають відносини між записами. Як і в ієрархічній моделі, зв'язки ведуть від батьківського запису до дочірньої, але на цей раз підтримується множинне спадкування.
Слідуючи специфікації CODASYL, мережева модель підтримує DDL (Data Definition Language - мова визначення даних) і DML (Data Manipulation Language - мова обробки даних). Це спеціальні мови, призначені для визначення структури бази даних і складання запитів. Незважаючи на їх наявність програміст як і раніше повинен знати структуру бази даних. p align="justify"> У мережевої моделі допускаються відносини "багато до багатьох", а записи не залежать один від одного. При видаленні запису віддаляються і всі її зв'язки, але не самі зв'язані записи. p align="justify"> У мережевий моделі потрібно, щоб зв'язки встановлювалися між існуючими записами щоб уникнути дублювання і спотворення цілісності. Дані можна ізолювати в соотв етствующіх таблицях і зв'язати із записами в інших таблицях.
Програмістові не потрібно, при проектуванні СУБД, дбати про те, як організовується фізичне зберігання даних на диску. Це послаблює залежність додатків і даних. Але в мережевій моделі потрібно, щоб програміст пам'ятав структуру даних при формуванні запитів. p align="justify"> Оптимальну структуру бази даних складно сформувати, а готову структуру важко міняти. Якщо вид таблиці зазнає змін, всі відносини з іншими таблицями повинні бути встановлені заново, щоб не порушилася цілісність даних. Складність такого завдання призводить до того, що програмісти часто скасовують деякі обмеження цілісності заради спрощення додатків. p align="justify"> Реляційні СУБД
