повій схемі SQL-орієнтованої БД можуть міститися визначення багатьох об'єктів (обмежень цілісності загального вигляду, тригерів і збережених процедур і т. д.), які неможливо згенерувати автоматично на основі концептуальної схеми. Тому на завершальному етапі проектування реляційної схеми знову потрібно ручна робота проектувальника. p align="justify"> Ще раз зверніть увагу на те, який хід міркувань привів нас до висновку про можливість автоматизації процесу перетворення концептуальної схеми БД в реляційну схему. Якщо творці семантичної моделі даних надають методику перетворення концептуальних схем у реляційні, то чому б не реалізувати програму, яка виробляє ті ж перетворення, слідуючи тією ж методикою? Задамося тепер іншим, але, по суті, схожим питанням. Якщо творці семантичної моделі даних надають мова (наприклад, діаграмний), використовуючи який проектувальники БД на основі вихідної інформації про предметну область можуть сформувати концептуальну схему БД, то чому б не реалізувати програму, яка сама генерує концептуальну схему БД у відповідній семантичної моделі, використовуючи вихідну інформацію про предметну область? Хоча нам не відомі комерційні CASE-засоби проектування БД, що підтримують такий підхід, експериментальні системи успішно існували. Вони представляли собою інтегровані системи проектування з автоматизованим створенням концептуальної схеми на основі інтерв'ю з експертами предметної області і подальшим перетворенням концептуальної схеми в реляційну. p align="justify"> Як правило, CASE-засоби, що автоматизують перетворення концептуальної схеми БД в реляційну, виробляють реляційну схему бази даних у третій нормальній формі. Нормалізація більш високого рівня ускладнює програмну реалізацію та рідко потрібно на практиці. p align="justify"> Нарешті, третя можливість, яку слід згадати, хоча вона ще не вийшла (або тільки виходить, а може бути, так ніколи і не вийде) за межі дослідницьких і експериментальних проектів, - це робота з базою даних у семантичній моделі, тобто СУБД, засновані на семантичних моделях даних. При цьому знову розглядаються два варіанти: забезпечення інтерфейсу користувача на основі семантичної моделі даних з автоматичним відображенням конструкцій цього інтерфейсу в реляційну модель даних (це завдання приблизно того ж рівня складності, що і автоматична компіляція концептуальної схеми бази даних в реляційну схему) і пряма реалізація СУБД , заснована на який-небудь семантичної моделі даних. Багато авторитетних фахівці вважають, що найближче до другого підходу об'єктно-орієнтовані СУБД, чиї моделі даних за багатьма параметрами близькі до семантичним моделям (хоча в деяких аспектах вони більш могутні, а в деяких - більше слабкі). br/>
.1 Семантичне моделювання даних
Широке поширення реляційних СУБД та їх використання в найрізноманітніших додатках показує, що реляційна модель даних достатня для моделювання предметних областей. Однак проектування реляці...
