|
Объектно-ориентированная модель данных Д.Н. Носов, М.Г. Пайков, Описана объектно-ориентированная модель данных и соответствующая оболочка, предназначенная для создания сложных информационных систем В последнее время концепция объектно-ориентированных баз данных все больше привлекает внимание специалистов по обработке информации во всем мире. Однако, как правило, разработчики ставят перед собой цель создать средства поддержки объектно-ориентированного проектирования или программирования, и почти никто не пытается сделать объектно-ориентированной саму модель данных, т. е. непосредственно представлять в базе данных (БД) реальные объекты и связи описываемой предметной области. Наиболее близка к этому модель “объект—отношение” (entity-relationship model, далее ER-модель), предложенная П. Ченом [1], но даже она, по существу, представляет собой мостик, связывающий концептуальное проектирование и обычную реляционную модель. В настоящей статье авторы попытаются изложить собственное понимание объектно-ориентированной модели данных (ООМД), описав ее функционирование на примере конкретной реализации - оболочки Inform-X. Оболочка предназначена для создания сложных информационных систем в среде MSM (Micronetics Standard MUMPS) - разработанной фирмой Micronetics реализации многозадачной многопользовательской системы М. Исследование, проведенное авторами, показало, что при создании многопользовательских информационных систем на базе стандартных ПК с процессором 386 и оперативной памятью 4 Мбайт у М фактически нет конкурентов. СУБД Oгас1е, например, ориентирована на более мощную технику, а PICK в лучшем случае не дает никаких преимуществ по сравнению с М. Что касается локальных сетей, то и здесь М оказывается на высоте, явно превосходя сетевые версии распространенных СУБД для ПК. В частности, СУБД Paradox, которая в течение вот уже трех лет считается лучшей реляционной системой для ПК, оказалась совершенно непригодной для наших целей из-за неудобной организации данных и, самое главное, из-за самой реляционной модели, которую давно пора признать устаревшей. Разумеется, среда М тоже неидеальна. Иерархическая модель, на которой основана ее встроенная СУБД, не обеспечивает независимости данных [2], что, в свою очередь, делает весьма затруднительным создание динамичных прикладных систем для произвольных предметных областей. Но, к счастью, М предоставляет и средство для преодоления собственных недостатков: ее мощный язык позволяет разрабатывать инструментальные программы, ориентированные на любые способы организации информации. По убеждению авторов, современные модели данных и соответствующие оболочки выведут М на новый качественный уровень и повысят ее конкурентоспособность в сфере проектирования прикладных систем. ОБЪЕКТЫ И СВЯЗИ ООМД сочетает в себе лучшие черты ER-модели и реляционной модели [3], присоединяя к ним достоинства среды М. При проектировании и эксплуатации прикладных систем в реляционной среде и разработчикам, и пользователям приходится держать в голове перечень полей различных отношений (таблиц) для организации связей между таблицами. Иначе говоря, реляционная модель плохо поддерживает семантику данных. Кроме того, при идентификации объектов и организации связей возникают неудобства с внешними и составными первичными ключами. ООМД основана на принципиально иной технологии. Предположим, что у нас есть объект “изделия” и объект “детали”. При организации связи нас совершенно не интересует, какими характеристиками обладают указанные объекты (в терминах реляционной модели - какие поля имеются в таблицах “изделия” и “детали”). Мы просто указываем, что “изделия” “содержат” “детали”, а “детали” “входят в” “изделия” с типом связи “многие-ко-многим”. При этом всякая связь в ООМД автоматически является двусторонней - в отличие от ER-модели, где потребовалось бы организовать две разные связи и, соответственно, создать для их описания два отношения в смысле реляционной модели. Связь может иметь свои характеристики: скажем, характеристики “позиция” (т. е. позиция детали на чертеже изделия) и “количество” (количество деталей в изделии) относятся не к изделию и не к детали, а к конкретной связи между ними. Естественно, между двумя объектами разрешается установить несколько связей. Например, “оснастка” “содержит” “детали” и “оснастка” “служит для изготовления” “детали”. Или: “читатель” “читает” “книги” и “читатель” “мечтает прочитать” “книги”. Простая реализация такой технологии возможна благодаря тому, что каждому экземпляру объекта поставлено в соответствие уникальное значение некоторой автоматически поддерживаемой ключевой характеристики (идентификатора). К такому способу представления данных пришел, в конце концов, и сам автор реляционной модели [1]. ССЫЛКИ Итак, ООМД опирается на четыре основных понятия: объект, характеристика объекта, связь, характеристика связи. Если при проектировании ограничиваться рассмотренными выше бинарными связями, большинство задач можно будет решать в естественной объектной среде без дополнительного программирования. Однако существуют две ситуации, в которых для адекватного отражения в БД предметной области бинарных связей недостаточно. Ситуация 1. Связь является множественной (обычно во времени). Например, имеется два объекта: “врачи” и “пациенты”. Можно, конечно, организовать между этими объектами связь типа “многие-ко-многим” с определенной семантикой (“врачи” “лечат” “пациенты”, “пациенты” “лечатся у” “врачи”). Однако каждый конкретный врач может оказывать помощь конкретному пациенту много раз, и каждая возникающая при этом связь будет иметь собственные характеристики. Подобную картину нетрудно было бы свести к бинарным связям, но мы пошли другим путем из-за наличия второй ситуации. Ситуация 2. Необходимо связать между собой более двух объектов. Например, при формировании планов связываются “изделия”, “заказы” и “цехи”. Для описания этих ситуаций в ООМД введен специальный тип характеристики (и объекта, и связи) - ссылка. Например, вы создаете объект “визиты” и среди прочих его характеристик используете ссылки на “врачи” и на “пациенты”. Их значениями для каждого конкретного визита будут идентификаторы конкретного врача и конкретного пациента. Следует подчеркнуть, что ссылки в ООМД даются на экземпляры конкретных объектов, а не на поля других таблиц, как в реляционной модели. Любая реализация ООМД должна эффективно поддерживать все операции со ссылками точно так же, как и с бинарными связями. В примере с врачами и пациентами “визиты” - это объект, описывающий связь между другими объектами, т. е. объект-связь. Комбинация на основе ссылок бинарных связей и объектов-связей дает мощный и гибкий инструмент проектирования БД, максимально сближая этапы разработки на концептуальном и на логическом уровнях. ООМД ДЛЯ ПОЛЬЗОВАТЕЛЯ ООМД разумно применять не только при проектировании БД, но и при эксплуатации прикладной системы, ориентируясь тем самым на объектный, а не на функциональный пользовательский интерфейс. Так, одним из самых сложных навыков работы с БД не без оснований считается умение правильно составить запрос для получения нужной информации. ООМД же позволяет обойтись вообще без запросов: в Inform-X поиск реализован с помощью естественной для системы М технологии “каталоги—процедуры” (КП-технологии). Для быстрого поиска объектов в каталогах используются динамически поддерживаемые инвертированные списки по соответствующим характеристикам, благодаря чему (это очевидно для специалиста по М) скорость доступа к нужной информации слабо зависит от числа элементов в БД. Войдя в нужный каталог (например, по характеристике “номер чертежа”) объекта “изделия” и выбрав в нем интересующее вас изделие, вы можете просто нажать клавишу “связь”, найти в меню возможных и доступных в настоящий момент связей связь “содержит” с объектом “детали” и получить список деталей, входящих в соответствующее изделие. Так вы можете перемещаться по сколь угодно сложной семантической сети, совершая стандартные операции над объектами и связями (ввод, удаление, обновление) и заказывая стандартные справки и отчеты. Все это обеспечивает не прикладная система, а сама оболочка Inform-X. На этапе эксплуатации прикладных систем проявляется еще одно очень важное достоинство ООМД. Поскольку все, работающие с этой моделью, независимо от предметной области имеют дело в основном с объектами и связями между ними (и лишь изредка - со специфическими для некоторой области прикладными задачами), пользователи разных прикладных систем получают удобную возможность для обмена опытом и обучения новичков. НЕКОТОРЫЕ ВОЗМОЖНОСТИ INFORM-X В Inform-X поддерживается 12 типов характеристик: • число (можно указать допустимый диапазон, точность, шаблон вывода); Объекты с характеристикой “текст” - это не просто аналог memo-полей реляционных СУБД. В Inform-X встроен полноценный текстовый процессор, обеспечивающий структурирование текста: создание титульного листа, автоматическую печать верхнего и нижнего колонтитулов и т. п. Для работы с объектами типа “таблица” предусмотрен мощный табличный калькулятор, который можно рассматривать как разновидность текстового процессора. В системе имеется и стандартный калькулятор. Он вызывается в любой момент и может помещать результат вычислений в текущее положение маркера. У каждого пользователя есть своя личная информационная система, включающая записную книжку, ежедневник, почтовый ящик, средства отправки писем-сообщений другим пользователям и собственный каталог для хранения текстов (М-файлов). Любую справку или отчет можно вывести на системный принтер, подключенный принтер, в DOS-файл сервера, DOS-файл своего компьютера (если на рабочем месте стоит компьютер, а не терминал, и вы используете эмулятор, входящий в состав Inform-X) или в М-файл - последнее намного эффективнее. Поддерживается индивидуальная настройка рабочих мест как администратором системы (указываются доступные пользователю объекты, связи и прикладные задачи, а также параметры коллегиального доступа), так и самим пользователем (указываются в нужном порядке выводимые характеристики из списка доступных характеристик, настраиваются цвета экрана, задается периодичность обновления данных на экране, выбираются шаблоны ввода-вывода). Разработана методика создания прикладных систем и их эксплуатации в универсальной объектно-ориентированной среде (прикладная задача может быть запущена непосредственно из каталога с автоматическим контролем контекста). О ПРИМЕНЕНИИ INFORM-X В заключение попробуем, исходя из накопленного нами опыта эксплуатации Inform-X, ответить на вопрос: когда целесообразно разрабатывать информационную систему в этой среде, а когда легче запрограммировать все непосредственно на языке М? На наш взгляд, необходимость в оболочке тем острей, чем сложнее прикладная система, при достижении же определенного уровня сложности Inform-X становится просто незаменимым (и необыкновенно эффективным) инструментом. Как оценить сложность системы? Один из возможных критериев - число отношений, которое потребовалось бы ввести в реляционной модели. Если в результате проектирования вы получили БД в третьей нормальной форме, состоящую не более чем из нескольких десятков таблиц, то соответствующую систему следует считать относительно простой, если же число таблиц перевалило за сто, значит, БД оказалась довольно сложной. Среди прикладных систем, уже созданных и функционирующих в среде Inform-X, есть система “Информ-ЦТО”, разработанная для технологического отдела авиационного предприятия и рассчитанная на 19 рабочих мест. В базе данных этой системы 45 объектов и 206 связей. Если учесть еще и тот факт, что многие объекты имеют характеристики-наборы, можно с уверенностью предсказать, что при создании аналогичной системы в среде реляционной СУБД число таблиц превысило бы 500. И проектировать, и эксплуатировать такую махину нелегко! Убедившись на практике в эффективности Inform-X, мы стали использовать ее для разработки всех, даже относительно простых, прикладных систем, и в данный момент работаем над ее новой версией, которая предусматривает встроенные процедуры и ориентированный на ООМД язык запросов. ЛИТЕРАТУРА 1. Chen P.P. The Entity-Relationship Model – Toward a Unified View of data //ACM Trans. Database Syst. V. 1. №1 (March 1976). P. 9-36. 2. Codd E.F. A Relational Model of Data for Large Shared Data Banks //Comm. ASM. V. 13. № 6 (June 1970). P. 377-387. 3. Codd E.F. Extending the Database Relational Model to Capture More Meaning //ACM Trans. Database Syst. V. 4. № 4 (December 1979). P. 397-434. ОБ АВТОРАХ Авторы статьи — сотрудники лаборатории информационных технологий (ЛИТ) кафедры испытаний летательных аппаратов Московского государственного авиационного технологического университета. Дмитрий Николаевич Носов, Максим Геннадьевич Пайков и Дмитрий Вячеславович Янкин - инженеры-программисты, Андрей Леонидович Чернышев - канд. техн. наук, доцент, заведующий ЛИТ. Контактный телефон: (095) 915-23-32. Новости О компании Продукты Технологии Партнеры Проекты Обучение Пресса Контакты Цены Содержание © Copyright 2021-2022 |