Абстракції в проектуванні БД

1. Математична модель
2. Рівні моделювання в процесах проектування
3. Логічна модель даних
4. Фізична модель даних
5. інструментарій
6. Конкретні моделі даних
7. Об'єктна схема - схема БД конкретної об'єктної СУБД
8. перспективи моделювання
9. рекомендована література

Серед розробників баз даних і пов'язаних з ними інформаційних систем нерідко практикується "технологічно-конструктивістський" підхід до своєї діяльності. Наприклад, часто (але не виключно) це відбувається, коли розробник перейшов від використання настільних систем типу Paradox або Clipper до більш розвиненим системам типу Oracle. Люди захоплюються технічними рішеннями і знахідками типу "як отримати такий-то ефект в новій версії", "як стикувати одне з іншим" і т.п., і часто знаходять в цих пошуках своє основне заняття. Створення інформаційної системи при такому підході часто бачиться як підбір комбінації і організація взаємодії технологічних рішень, укупі надають можливість виконання необхідного завдання. Не заперечуючи такої діяльності тотально, мені б хотілося тут поговорити про зовсім протилежні речі, а саме не про технічну конкретику, а про абстракціях в проектуванні БД. І ось аргументи на користь такої розмови.

Але ось як раз стан з моделюванням в базах даних в останні роки здатне викликати у розробників певне занепокоєння. Воно дещо нагадує вже існувало 20 років тому: так само як тоді йшли суперечки про взаємні переваги та перспективи трьох технологій організації БД, ієрархічної, мережевої і реляційної, так і сьогодні, і, по крайней мере на слуху, є (але поки що не обговорюється в настільки ж активному порівнянні) нова технологічна трійка: реляційна, об'єктна і багатовимірна. Реляційна, по суті справи, монополія в СУБД, що не викликала сумніву ще 10 років тому, похитнулася, а деякі навіть говорять про глухий кут реляційного підходу в якості перспективи. Це кілька нервує користувачів СУБД, оскільки перед ними знову починає маячити питання "куди бігти?". А дійсно, куди? Де "будуть всі" через 10 років?

Вказати пряме напрямок, як це часто буває, зараз важко, а спробувати розібратися можна, і як раз за допомогою абстракцій. Адже хоче це розуміти разработчік- "конструктивіст", чи ні, його діяльність з проектування БД завжди самим безпосереднім чином вплетена в канву не однієї, а відразу багатьох абстракцій. Розуміння їх, крім перспектив руху, має, до того ж, і самостійну цінність, як передумова грамотної роботи.

Тут будуть розглянуті тільки деякі види абстракцій, які в тій чи іншій мірі, явно чи неявно, але обов'язково (можливі лише комбінаційні відмінності) присутні в розробці конкретної БД. По-перше, це "концептуальна трійка", три рівня моделей БД: концептуальний, логічний і фізичний. По-друге, це група конкретних моделей, частина з яких реалізована в ЕОМ інструментально, а частина - ні, наприклад реляційна, яка мається на увазі SQL, об'єктна схема БД і деякі інші. Однак почати перерахування правильно було б з "самої загальної" абстракції, з якої тільки можна мати справу, а саме з математичної моделі.

Математична модель

Мені невідомо жодної прикладної системи, розробленої з явним використанням математичної моделі. Тоді навіщо говорити про неї в технічному журналі? Справа в тому, що хоча б загальне уявлення про те, що вона є таке, вже дає певне розуміння цілей, техніки і змісту процесів проектування БД.

Модель взагалі найтіснішим чином пов'язана з абстракцією. "Абстракція" - це, буквально, "відволікання", тобто виключення з розгляду чогось. (Вже тут можна помітити, що виключатися "щось" може або як несуттєве, або ж через незнання, забудькуватості і т.д., і наслідки в різних випадках різні.) Будь-яка модель - це абстракція, тобто відволікання від тих явищ реального або ідеального світу, які нас не цікавлять. Ще одне зауваження: всупереч інтуїтивним при проектуванні інформаційної системи (ІС) очікуванням, відволікання не рівнозначно виділенню явищ, що представляють інтерес (так би мовити "модель завжди" менше "і" простіше "реальності"). Наприклад, відволікання від наявних обмежень може призвести до появи у моделі властивостей, не порівнянні з дійсністю.

Моделі в інформатиці призначені для спільного використання різними людьми, і, крім того, їх повинна "розуміти" ЕОМ, а тому вони повинні бути щонайменше чітко сформульовані. Найбільш загальне і суворе ( "однозначне") поняття моделі придумано в математиці. Там модель, кажучи спрощено, є (а) основне безліч об'єктів і (б) безліч відносин на ньому: M =, і моделі складають предмет самостійного вивчення. Однак баз даних ближче по духу дещо інше математичне поняття, а саме алгебри, розвиток теорії яких тісно пов'язане з роботами академіка Мальцева в 50-х роках. Алгебраїчні системи об'єднують в собі крім (а) і (б), як і в моделі, крім того ще й (в) безліч операцій (функцій), що задаються на основному, дуже багато! A =. Математична модель і алгебраїчна система - це настільки близькі поняття, що для ступеня Нестрогие справжнього цього тексту вони невиразні, і в подальшому буде використовуватися тільки один термін: "модель", що має на увазі трійку. Спільність математичного поняття моделі означає, що з його допомогою можна описати будь-яку математичну, тобто формальну, структуру.

Вже на загальному рівні сказаного можна зробити деякі цікаві для розробника спостереження:

1. Будь-яка формальна система формальна остільки оскільки для неї існує модель. Наприклад, база даних - це модель, і значить, проектування бази даних є побудова моделі.

2. Чи не правда, трійка нагадує тріаду?

3. Безліч відносин R і функцій F в математичної моделі "взаємозамінні", тобто можна підібрати такі відносини R1, що потреба в F1 відпаде, і навпаки. Розподіл правил, які задають безлічі об'єктів моделі, між R-визначеннями (наприклад, шляхом перерахування) і F-визначеннями є питання зручності роботи з ними, і принципово нічого не збавляє і не додає до цього безлічі (будучи, звичайно, зроблено коректно). Хіба не те саме можна сказати про декларативних і процедурних обмеженнях цілісності в базах даних?

В математиці моделі добре вивчені на рівні строгості і ретельності, недосяжне в інших областях знань, а в якості описового кошти вони універсальні. Більш того, вони завжди "незримо присутні" у всякому процесі проектування ІС. Так чому ж їх не використовуються при розробках БД явно? Є ряд причин, і одна з них в тому, що математична модель - надто вже абстрактне поняття, позбавлене семантичної забарвлення, часто-пронизує прикладну область. Інакше кажучи, їй невідомий прикладної сенс об'єктів з S, R і F, тобто якраз те, що весь час на думці у розробника БД, і це ускладнювало б роботу останнього з нею. Крім того, моделі, в тому вигляді, в якому вони існують в математиці, "не розуміє" жодна комп'ютерна програма. Реально в проектуванні між математичною моделлю (умоглядною) і базою даних (теж моделлю, але "виконаної в комп'ютері") присутні кілька моделей різних рівнів абстракції, пов'язаних між собою. Математична модель і база даних утворюють як би два полюси, між якими знаходяться інші моделі, які тяжіють до одного чи іншого "полюсу"; при цьому "полюс" математичної моделі принципово недосяжний, і цінний, скоріше, як "точка відліку", свого роду "реперна точка", а "полюс" БД, навпаки, завжди реалізуємо. Можна навести три рівня моделей, що заповнюють "проміжок": концептуальної моделі прикладної області і два інших, про які, як і про концептуальний, відомо було давно, але які практично стали популярні серед розробників порівняно недавно, а саме рівні логічної і фізичної моделі БД.

Рівні моделювання в процесах проектування

Концептуальна модель даних

Це найбільш загальний вигляд моделі, з яким має справу розробник - в тому сенсі, що моделі цього виду практично не прив'язані до комп'ютерних реалій (абстраговані від них). Концептуальні моделі вже не є математичними моделями з їх універсальністю, але вони ще й не БД-моделі. Для читачів, незатишно почувають себе в давньоримській лінгвістичної середовищі, можна нагадати, що мова йде про "понятійної моделі", про моделі понять предметної області, і ніякого іншого сенсу в словах "концептуальна модель" немає. Хоч це може і ускладнювати розуміння сказаного, далі для дотримання традиції буде використаний все ж латинсько-американський термін1. В літературі зустрічається ще назву "семантична модель".

Таким чином, в концептуальному моделюванні проектується схема понять прикладної області в їх взаємозв'язку. Пропонувалися і пропонуються різні шляхи такого моделювання. Ось наприклад, які (мета-) поняття розглядали для концептуального моделювання в кінці 70-х років Сміт і Сміт.

Вихідними базовими поняттями в трактуванні цих двох фахівців є об'єкти і зв'язки між об'єктами. Зв'язки можуть бути двох видів: узагальнення і агрегація. Узагальнення інтуїтивно ясно, і пов'язує одні об'єкти з іншими, за змістом більш загальними. Наприклад, об'єкт "тварина" є узагальнення для об'єктів "собака" і "кінь". Агрегація пов'язує різнорідні об'єкти за ознакою компонентного входження в інші об'єкти, як наприклад, "колеса" і "кузов" пов'язані з "автомобілем" тим, що останній складається з перших. Незалежно, обидва види зв'язків утворюють кожен свою ієрархію серед об'єктів моделі (див. Малюнок 1).

Крім цих базових є і інші поняття концептуальної моделі, як-то атрибут, відношення, екземпляр, індивід. Саме чудове в "моделі Смитов" - зто відносність перерахованих понять. Одне і те ж явище може бути і об'єктом, і ставленням, і атрибутом, і екземпляром, і індивідом, і все визначається точкою зору на явище. Залежність інтерпретації від точки зору на явище (а точніше - можливість вибору точок зору з різною інтерпретацією) - це дуже потужний властивість, що додає концептуальної моделі велику гнучкість і пристосовність в описі проектованої ІС. Це властивість, наприклад, якщо буде реалізовано, дозволило б в інформаційній системі дивитися на "адреса" то як на об'єкт реєстру адрес, то як на атрибут "особи", то як на ставлення, що зв'язує власника з іншими мешканцями - коли, де і кому як треба. Найближче до концептуальної в цьому відношенні підійшла (теоретична) реляційна модель даних (див. Нижче), а ось об'єктний підхід з його фіксованої інтерпретацією структури відстоїть від реляційного на крок назад.

Незважаючи на очевидну привабливість концептуального проектування, воно існує лише в статтях і не реалізовано безпосередньо ні в одній комп'ютерній системі. Виняток становить лише (не так давно з'явилася) заслужила високу оцінку серед фахівців система InfoModeler фірми Visio, яка використовує концептуальну модель "об'єкт-роль", дещо відмінну від "моделі Смитов". Ще одним відомим прикладом "умоглядного" підходу може служити широко відома система RM / T описана Коддом в 1979 році, і що володіє високою насиченістю семантичних конструкцій, але разом з тим і складністю. Пік робіт по концептуальному моделюванню припав на кінець 70-х років. На жаль, з того часу ця тема активно не обговорюється в літературі, але на щастя роботи тих років по цій темі не втратили своєї значущості.

Логічна модель даних

Логічний рівень моделювання - це той, який реально використовують багато з сьогоднішніх розробників завдяки доступності на ринку CASE-систем. На відміну від концептуального, логічне моделювання несе в собі порівняно малу семантичне навантаження, і часто розуміється вже як "логічне моделювання бази даних" (а не прикладної області). В такому розумінні мета його полягає в тому, щоб описати базу даних безвідносно до конкретної СУБД та архітектури БД (вважається, що проектується як би "логічно одна" база даних всієї автоматизованої системи). У найбільш поширеному випадку (реляційний підхід) логічне проектування зводиться до того, щоб правильно сформувати об'єкти, їх атрибути і взаємозв'язку з урахуванням методологічних вимог ліквідації надмірності, нормалізації, цілісності та ін., А також з урахуванням вимог прикладної постановки і незалежності даних (а вони можуть суперечити один одному).

Моделі цього рівня для реляційного підходу зазвичай не підтримують хоч трохи розвинену семантику межоб'ектних відносин, обмежуючись, як правило, конструкціями "тип / підтип". З іншого боку логічні схеми об'єктної БД можуть мати трохи багатший апарат обліку смисловий забарвлення, зазвичай вичерпується можливостями розрізняти типи узагальнення, асоціації та успадкування для зв'язків.

"Академічно" в проекті з розробки ІС правильним вважається створення логічної моделі БД на стадії аналізу, коли за основу можна взяти результати концептуального моделювання прикладної області; результати логічного проектування БД, в свою чергу, слід використовувати при побудові фізичної моделі. Практично, однак, концептуальне проектування часто відсутня (або зовсім, або в комп'ютеризованому вигляді), а логічна модель відчуває "зворотне" вплив з боку фізичної моделі, окремі елементи якої розробляються самостійно, виходячи з міркувань ефективності роботи СУБД.

Найбільш популярними видами моделей БД логічного рівня є ER-модель, реляційна модель, а останнім часом і об'єктна "модель" (в неформальному сенсі).

Фізична модель даних

Фізична модель даних відповідає опису даних в БД конкретної СУБД, тобто схемою даних, і з нею добре знайомі вже всі розробники без винятку. Вона безпосередньо враховує такі аспекти, як архітектуру, безпеку, ефективність доступу та інші. Можна ще помітити, що поняття "фізична модель" щодо, так як має тенденцію до зміни в часі, і те, що колись належало до логічної моделі, сьогодні можуть приписувати фізичної.

інструментарій

Трьом наведеним рівням моделювання при розробці що базується на використанні СУБД прикладної системи відповідає досить великий мовний інструментарій (див. Малюнок 2), що дозволяє організувати роботу з відповідними моделями на ЕОМ. З малюнка очевидна нерівномірність розподілу подібного інструментарію за категоріями "підхід / рівень": наприклад, при реляционном підході комп'ютерний інструментарій для концептуального проектування відсутня, а для логічного проектування він досить багатий (на малюнку не вказана ще численність конкретних CASE-систем, що реалізують ER- і IDEF-підходи).

Конкретні моделі даних

Отже, у своїй практиці розробник ІС може стикатися з безліччю різних конкретних моделей прикладної області або БД. Взаємовідносини між деякими найбільш відомими з них показано на малюнках (див. Малюнок 3 і Малюнок 4). Нижче наводяться пояснення до використаних в малюнках назвами моделей.

Математична модель - абстракція поняття моделі, прийнята в математичній логіці. Про неї йшлося вище.

Реляційна модель - класична реляційна модель даних. Як така, вона не реалізована жодної існуючої СУБД, але оскільки вона (а) математично сувора і досліджена і (б) послужила основою для більшості сучасних СУБД, то вона має велику методологічну цінність.

RM / T - розширена реляційна модель, запропонована в 1979 році Коддом для "кращого обліку семантики" прикладної області. На відміну від реляційної моделі, RM / T взагалі не отримала ніякого втілення в комп'ютері, але вона також має велике методологічне значення.

Модель даних SQL - мається на увазі модель даних, яка існує в рамках SQL-діалекту тієї чи іншої СУБД, тобто, наприклад, для Oracle це модель даних, що задається описом, складеним на реалізації SQL, прийнятої в Oracle.

"Модель Смитов" - методика концептуального моделювання, запропонована в статтях Сміт і Сміта в 1977 році.

ER-модель - тут мається на увазі не класична модель, запроваджена Ченем (вона в такому вигляді ніде не використовується), а той її спрощений варіант, який вживемо в більшості сьогоднішніх CASE-систем.

Об'єктна "модель" - логічна схема об'єктної БД в одній із загальноприйнятих систем опису (позначень). Хоча, за висловом Дейта, "не існує загальноприйнятої, абстрактної і формально певної" об'єктної моделі даних "" і стосовно "об'єктної" моделі "" правильніше говорити про "зручним ярлику для цілої сукупності деяких взаємопов'язаних ідей", конкретні CASE-системи, що реалізують на свій лад деякі з цих ідей, все ж існують.

Об'єктна схема - схема БД конкретної об'єктної СУБД

Багатовимірна схема - схема даних в одній з багатовимірних систем представлення даних, наприклад, в Oracle Express. Багатовимірні моделі використовуються не для опису даних, а для їх подання, так як "універсалізація" відносин призводить до "втрати точності" опису, але зате і до зручності сприйняття інформації кінцевим користувачем. Таким чином, значення багатовимірних схем - переважно "частиною інтерфейсу" (вони зручні кінцевим користувачам), а не описовий.

"Об'єкт-роль" - модель концептуального опису, прийнята в системі InfoModeler фірми Visio. У цій системі для моделі "об'єкт-роль" використовується дві мови: графічний і [умовно] природний.

перспективи моделювання

Тепер, коли за допомогою поняття абстракції вдалося кілька систематизувати наявне різноманіття моделей і систем, можна повернутися до початку статті, де говорилося, що похитнулася реляційної монополії і виникла в зв'язку з цим проблеми вибору моделі.

Говорячи про "реляционном кризі" (якщо про це доречно говорити), не слід забувати, що він був спочатку запрограмований самим підходом. Дійсно, реляційна модель принципово побудована нереалізованим чином. Вона вимагає повної нормалізації даних, а це недосяжно. Будь-яка використовується на ЕОМ модель необхідно має деякий певний рівень абстракції по відношенню до модельованої області, а це суперечить нормалізації.

Нехай в таблиці SQL-СУБД ми зберігаємо такі атрибути особи, як телефон і адресу. У 99% випадків реальної практики номер телефону буде описаний рядком, інакше кажучи, буде неструктурованих (в 90% випадків і адреса буде описаний рядком, а в інших 10% випадків адреса буде структурований, але тільки частково, і ніколи повністю!). Але ж в такій ситуації ми отримаємо денормалізованную таблицю. Всі номери телефонів видаються АТС, а вони обслуговують цілком певні райони, тобто між номером телефону та адресою в житті існує залежність, неврахована схемою БД. Людина знає про цей зв'язок, а машина - немає, і коли-небудь людина задасть машині питання, що має на увазі наявність зв'язку і отримає неправильну відповідь. Інша ситуація не менш підступна: неправильна відповідь може виникнути не в результаті прямого запиту користувача, а як наслідок закладеної в систему на стадії розробки "людської" логіки. Коли подібна накладка може стати відчутно вірогідною? Коли даних стане багато, а система складною.

Останнім часом пропонують семантично більш просунуту об'єктну технологію організації даних в БД. Але ж і вона принципово нереалізована в її "ортодоксальному" вигляді, тому що механізми "регулювання" рівня абстракції в ній неможливі для виконання. Об'єктний підхід вимагає унікального системного ключа для кожного екземпляра об'єкта в БД. Це не особлива проблема, якщо об'єктна база даних працює на одній установці для конкретного завдання. Але як йдуть справи з reusability? Ми з'єднуємо дві установки, і хочемо взаємно користуватися об'єктами. Як зробити так, щоб не виникло конфліктів з OID? У перспективі більшість машин світу з'єднуватися один з одним за допомогою Інтернету. Можливо, при цьому знадобиться якась єдина служба видачі OID, на зразок існуючої для адреси IP. Але верхня оцінка числа адрес IP порівнянна з числом комп'ютерів на Землі, а скільки може бути на них заведено об'єктів? Згідно з різноманітністю модельованих явищ і з рівнем їх моделювання число ідентифікаторів об'єктів свідомо нескінченно. Коли ця нескінченність проявить себе реально лімітуючим фактором для ІС? Коли об'єктів в різних БД стане багато, і вони почнуть використовуватися спільно.

Вказуючи на сотні тисяч працюючих БД в світі, і при тому, що серед них багато -Велика обсягу, можна поставити запитання: як же "не реалізовується", адже "працює"? Ми-то з вами знаємо як, і що справа тут в абстракціях, а точніше в їх рівні. Не знаю, як в іншому світі, але в Російській Федерації відсутня вичерпна система (хоча б тільки) поштових адрес, і розробка її ... як би це сказати ... щонайменше, відніме багато часу. А інформаційні системи потрібно робити "вже вчора". Протиріччя дозволяється відомим всім способом: приймається рішення вважати адресу [фактично] атомарним символьним значенням, і, це означає, що вольовим рішенням фіксується конкретний рівень абстракції. Він цілком достатній для маленьких баз (де список адрес можна переглянути очима), і терпимо для середніх (можна поставити більш потужний сервер, і робити вибірки в реальному часі) - і перший рівень комп'ютеризації підприємства виявляється закритий на рік, на кілька років, можливо , набагато. Але ж не назавжди!

Слово "назавжди" в попередньому абзаці та уявлення про "загальносвітовому универсуме" об'єктів і "позамежної складності" "великих" ІС в парі абзаців вище можуть здатися тут недоречними, проте заперечує "прагматику" - "конструктивістів" (див. Початок статті), можна запропонувати всього один приклад: так звану "проблему 2000-го року". Обраний десятки років назад в тисячах систем рівень абстракції для поняття "рік" раптом несподівано став неадекватний і привів зараз до однієї їх найбільш дорогих проблем за всю історію створення ІС, даючи заробіток різноманітним авторам технічних рішень і не залишаючи почуття гарантованої впевненості у замовника. Зрозуміло, що 30 років тому проблема 2000-го року мало кого з розробників турбувала, але якби раптом тодішні системи проектувалися з можливістю регулювання рівня абстракції поняття "рік", нинішніх жахливих витрат вдалося б уникнути.

Очевидно, що в міру збільшення обсягів і складності збережених даних і в міру їх інтеграції буде рости потреба в коштах моделювання, що забезпечують (а) різноманіття рівнів абстракції і (б) можливість їх (рівнів) зміни як в межах прикладної області, так і безлічі СУБД . При роботі з одними і тими ж загальновживаними даними рівень абстракції, достатній для однієї програми, може бути незадовільний для іншого. Системі реєстрації дзвінків клієнтів на фірму знати структуру телефонного номера ні до чого, а системі для АТС - потрібно. У тій же системі реєстрації сьогодні досить працювати з адресою-рядком, а завтра знадобиться мати структуру адреси. Вимоги різних рівнів абстракції даних можуть виникати навіть у рамках однієї автоматизованої системи підприємства, якщо остання досить складна.

У загальній перспективі очевидна бажаність комп'ютерної підтримки концептуального проектування, що дає дійсно семантично насичений, теоретично перевірений і адаптується за формою і за рівнем абстрагування інструмент моделювання (позначена еліпсами верхня частина зони "концептуальний рівень", див. Малюнок 3 і Малюнок 4). Приклад з "проблемою 2000-го року" свідчить, що бажаність цієї перспективи зовсім маніловські-умоглядно. Але для неї знадобиться повернутися до напрямку, позначеному важко давати роботу з концептуального проектування, значною мірою залишеним дослідниками з початку 80-х років. Подібні повернення не нові для такої інтенсивно динамічною області діяльності, як комп'ютерна. Вони час від часу спостерігаються і в базах даних, і в інших розділах інформатики, і в них як таких немає незвичайного. Повернення до концептуального моделювання в ІС представляється очевидним. Коли ж він відбудеться саме, і в якій саме формі, загадувати важко: це залежить від усіх, хто працює в цій галузі ІВ, тобто в тому числі і від читали цей текст.

рекомендована література

Кріс Дейт. Введення в бази даних. Шосте видання. Київ, Діалектика, 1998..

М. Ш. Цаленко. Моделювання семантики в базах даних. М., Наука, 1989.

Дж. Сміт, Д. Сміт. Принципи концептуального проектування баз даних.

В зб. "Вимоги та специфікації в розробці програм". М., Мир, 1984.

П. Чень. Модель "Сутність-зв'язок" - крок до єдиної поданням даних. СУБД № 3/1995.

Е. Кодд. Розширення реляційної моделі для Краще відображення семантики. СУБД №5-6 / 1996.

Бази даних: досягнення і перспективи на порозі 21-го століття. Під ред. Аві Зільбершатца, Майка Стоунбрейкера і Джеффа Ульмана, СУБД № 3/1996

Х.Дарвін, К.Дейт. Третій маніфест. СУБД № 1/1996

М. Аткінсон, Ф. Бансілон, Д. Девітт, К. Діттріх, Д. Майер, С. Здонік. Маніфест систем об'єктно-орієнтованих баз даних. СУБД № 4/1995

Системи баз даних третього покоління: Маніфест. СУБД № 2 1995

С.Д.Кузнецов. Напрями досліджень в галузі управління базами даних: короткий огляд. СУБД № 1/1995