Письмо в редакцию
Несколько замечаний по поводу информационного моделирования, объектного программирования и реляционных баз данных
Я прочитал статью “Кто сильнее, слон иль кит?” (PC Week/RE, № 10/98, с. 20), посвященную круглому столу о перспективе развития реляционных и объектных СУБД. Хотя тема встречи была объявлена как “Реляционная и объектная модель данных. Как сделать правильный выбор?”, речь шла в основном о реляционной модели данных, что такое объектная модель - участники так и не смогли сформулировать. Заявив, что объектные СУБД имеют право быть и у них есть своя ниша, они даже не намекнули - какая именно ниша? А на вопрос о том, как сделать правильный выбор, судя по высказываниям, есть один ответ: выбирать не из чего.
Выступление Андрея Чернышева в начале дискуссии вызвало, мягко говоря, удивление. Непонятно, зачем валить в одну кучу модели данных и стили программирования, теорию проектирования логической модели и конкретную реализацию программного пакета под названием CASE. Это все равно, что описать бассейн, в котором дружно плавают слон с китом, или прерии, где они же мирно пасутся. Видимо, влияние Чернышева на участников круглого стола, оказалось настолько сильным, что робкое высказывание Константина Сунцова в поддержку независимости интерфейса от модели данных не было поддержано остальными.
Непонятно, зачем искать у великих (Э. Кодд, П. Чен) подтверждения своих мыслей, а не обнаружив оных, обвинять их - великих - во всех смертных грехах? Возможно, ответ на это дал другой великий (наш) в своем литературном произведении, посвященном тому же животному с хоботом.
По поводу использованных понятий и терминов+
По словам г-на Чернышева, “П. Чен придумал ER-нотацию "сущность - связь", на основе которой сегодня строятся многие CASE-системы”.
Здесь есть два справедливых утверждения: Чен действительно придумал нотацию в виде графических примитивов: прямоугольники для сущностей и ромбики для отношений между ними. Но эта нотация относится к ER-модели, а не к модели “сущность - связь”.
На основе модели “сущность - связь” сегодня строятся многие современные CASE-системы. Используя их, разработчики значительно упрощают свою задачу в процессе моделирования сущностей и связей.
На самом деле Питер Шен Чен предложил описывать мир в терминах “сущность - отношение”. ER - это Entity - Relation, где слово Relation имеет значение “отношение”, а именно n-арное взаимодействие между сущностями. Это действительно чрезвычайно мощный инструмент моделирования и изучения взаимодействия сущностей, который используется в проектировании логической информационной модели.
Связь же - это просто бинарное отношение. Составить алгоритм процесса проектирования бинарных отношений гораздо проще. Поэтому одной из первых была разработана IDEF1X-нотация, основанная на модели “сущность - связь”. IDEF1X позволяет автоматически генерировать словарь данных всех популярных СУБД.
Я бы не стал обвинять Чена и в том, “что и на него давит "перспективность реляционной модели на ближайшие 20 лет"”. Ведь это он предложил отказаться от реляционной и иерархической моделей при построении информационной модели системы. Но именно модели системы, а не данных. Разработчики успешно проектируют системы при помощи ER-моделей. Физическая же реализация осуществляется в большинстве случаев на реляционной модели данных.
Кстати, сам Чен имеет некоторое отношение к созданию среды разработки конечных приложений PROGRESS, языковые средства которого (4GL PROGRESS) только начиная с восьмой версии становятся объектно-ориентированными. Вероятно, потребуется как раз лет 20, чтобы объектные СУБД смогли войти в стандартный набор инструментов разработчика информационных систем.
Отношение между интерфейсом и моделью данных
Любопытно, как воинствующие философы “реляционного тупика” пришли к выводу о том, что “модель данных оказывает существенное влияние на технологии в целом, вплоть до интерфейса пользователя...”. Так и хочется спросить: “А не слишком ли далеки они от народа?”.
Действительно, интерфейс должен быть удобен пользователю. Именно по нему он судит о качестве системы. Для того чтобы добиться этого удобства, разработчики следуют принципу: “Слона едят по частям”. Система делится на компоненты: данные, метаданные, алгоритмы и интерфейс. Для каждого из них разрабатываются свои специализированные средства: разные модели данных, языки описания данных, алгоритмические языки различных уровней, средства генерации экранных и печатных форм. Хотя эти компоненты и участвуют в одном процессе - разработке системы, они обладают достаточной степенью независимости для того, например, чтобы программе-дизайнеру экранных или печатных форм было совершенно безразлично, хранятся данные под управлением реляционной СУБД или сетевой.
Критерии выбора
Нужно ли вообще, и если да, то кому нужно делать “правильный” выбор между реляционной и объектной моделью данных?
Фирмам-производителям СУБД важно, чтобы их продукция была востребована на рынке, для этого их базы должны работать и с объектными, и с событийными средствами разработки, и с Интернет и другими проблемно-ориентированными приложениями. А что разработчики СУБД используют - B-деревья или реляционную алгебру - это их дело.
Для проектировщиков и разработчиков информационных систем, которые являются почти единственными потребителями СУБД, совершенно безразлично, какая модель данных лежит в ее основе! Для них актуально, чтобы данные можно было быстро и качественно сохранить и извлечь. На сегодняшний день надежно работать с большими объемами данных умеют многие фирмы, но самые популярные - это Oracle, IBM, Informix, PROGRESS и Microsoft. Поэтому, сколько бы ни обсуждался “реляционный тупик”, разумно делать ставку именно на SQL-сервер одной из этих фирм. А вот какая модель будет лежать в основе SQL-сервера, кроме производителя сервера, интересно разве что только узкому кругу любознательных.
Для конечных потребителей важно, чтобы их информация не пропадала и всегда была легко доступна. Они даже не задумываются, на основе какой СУБД построена их система, а порой и слов-то таких не знают.
Места ER-модели и РСУБД в табели о рангах определены достаточно конкретно - это два надежных полезных инструмента, которые вместе помогают строить хорошие информационные системы, а вот что такое объектная модель и для чего она нужна, участники круглого стола не захотели обсуждать. “Манифест систем объектно-ориентированных баз данных” (“СУБД” № 4 за 1995 год) уже был провозглашен, возможно, они в чем-то будут более эффективны, но вопрос в том, захотят ли широкие массы разработчиков систем променять интуитивно понятные родные таблицы на проблемы с наследованием и борьбу с полиморфизмом.
С глубоким уважением Иван Нестеров, начальник отдела информационных технологий, консалтинговая группа “Альфа”.
