Классика баз данных - статьи

Заключительные замечания


В заключение позвольте мне вернуться к стаптье Кодда про "великое сражение". Кодд отмечает, что "недостаточно принимать во внимание подходы, используемые сегодня -- нам нужно ясно осознавать будущее развитие событий". Он говорит, что существенно возрастет роль "случайных" пользователей систем баз данных (в действительности, скоро они будут представлять большинство), и мы должны уделять внимание другим подходам, требуемым для поддержки таких пользователей. Вот некоторые цитаты:

  • "Таким пользователям, очевидно, требуется простое понятие организации данных, чтобы проще было формулировать запросы или операции модификации".
  • "Следует упомянуть отсутствие в сетевом подходе операций уровня алгебры или исчисления, поскольку такие операции жизненно важны для поддержки действий [случайного пользователя] … Особенно печально отсутствие в [предложениях CODASYL] каких-либо намерений по поддержке работы не-программистов".
  • "Поддержка общего назначения для таких пользователей должна обеспечивать реляционно полную возможность выборки без потребностей в ветвлениях, явных циклов или курсоров. Понятно, как можно реализовать эту возможность с использованием реляционного подхода -- неважно, с применением формального или неформального языкового интерфейса. Непонятно, каким образом этой цели можно достичь на основе сетевого подхода, поскольку принципиальная схема [с наборами CODASYL] обладает свойством информационной существенности".

    И сегодня эти наблюдения нуждаются лишь в незначительных корректировках.


    Я хотел бы завершить это обсуждение языка Кодда Alpha двумя замечаниями.

  • В статье про Alpha упоминаются несколько запланированных статей: "Цель [этой статьи] состоит в том, чтобы обеспечить основу последующих статей по принципам авторизации, тактике поиска и методов представления данных" (стр. 2). "Детальному обсуждению [каталога] будет посвящена другая статья" (стр. 35). "Желательны дополнительные возможности … [включая] блокировки, авторизацию доступа, поддержку целостности, виртуальные атрибуты, литеральные вставки … Умышленно опущены возможные типы ошибок и … информация обратной связи. Эти аспекты будут обсуждаться в следующей статье" (стр. 41). Печально, но ни одно из этих обещаний не было в действительности исполнено!
  • Вместе со своими тремя коллегами Кодд впоследствии работал над проектом низкоуровневой подсистемы Gamma-0, которая должна была стать основой реализации Alpha-подобного языка высокого уровня [2]. Более точно, Gamma-0 должна была стать основой реализации другого интерфейса, немного более высокого уровня, называвшегося Gamma-1, а уже Gamma-1 должна была явиться основой реализации Alpha-подобного языка высокого уровня. Принципиальным различием Gamma-0 и Gamma-1 было то, что Gamma-0 обеспечивала только однопользовательский интерфейс, а Gamma-1 - многопользовательский. Конечно, они проектировались согласованно: "Существенные аспекты Gamma-1 принимались во внимание и влияли на проектирование Gamma-0" [2].

    Gamma-0 и Gamma-1 совместно демонстрируют большое сходство с подсистемой хранения System R [1], называемой RSS (Relational Storage System). Поэтому не удивительно, что один из коллег Кодда Ирв Трейджер позже был менеджером проекта RSS.




    Я хотел бы завершить статью парой наблюдений:

    1. Прежде всего (и это самое главное), позиция Критиков A и B по поводу relvar остается исключительно неясной. Как кажется, они считают понятие relvar дефектным по своей сути, но в то же время желают их сохранить, по крайней мере, «неявно» (?). Они также не могут объяснить, в чем состоит логическое различие между relvar как таковыми и «изменяемыми во времени отношениями».

    2. Верно, что некоторые языки программирования – конкретно, так называемые логические языки (например, Prolog) и функциональные языки (например, LISP) – умудряются существовать без присваивания: на самом деле, вообще без понятия «постоянной памяти» («persistent memory»). Однако, насколько мне известно, все такие языки «ловчат», когда требуется обновить базу данных; в действительности, они выполняют некоторую разновидность присваивания, возможно, в качестве побочного эффекта, хотя присваивание не является частью логического или функционального стиля.




    Нельзя сказать, что проектирование баз данных на основе семантических моделей в любом случае убыстряет и/или упрощает процесс проектирования. Все зависит от сложности предметной области, квалификации проектировщика и качества вспомогательных программных средств. Но в любом случае этап диаграммного моделирования обеспечивает следующие преимущества:

  • на раннем этапе проектирования до привязки к конкретной РСУБД проектировщик может обнаружить и исправить логические огрехи проекта, руководствуясь наглядным графическим представлением концептуальной схемы;
  • окончательный вид концептуальной схемы, полученной непосредственно перед переходом к формированию реляционной схемы, а может быть, и промежуточные версии концептуальной схемы должны стать часть документации целевой реляционной БД; наличие этой документации очень полезно для сопровождения и в особенности для изменения схемы БД в связи с изменившимися требованиями;
  • при использовании CASE-средств концептуальное моделирование БД может стать частью всего процесса проектирования целевой информационной системы, что может способствовать правильной структуризации процесса, эффективности и повышению качества проекта в целом.

    Хочу еще раз подчеркнуть, что в контексте проектирования реляционных БД структурные методы проектирования, основанные на использовании ER-диаграмм, и объектно-ориентированные методы, основанные на использовании языка UML, различаются, главным образом, лишь терминологией. ER-модель концептуально проще UML, в ней меньше понятий, терминов, вариантов использования. И это понятно, поскольку разные варианты ER-моделей разрабатывались именно для поддержки проектирования реляционных БД, и ER-модели почти не содержат возможностей, выходящих за пределы реальных потребностей проектировщика реляционной БД.

    Язык UML принадлежит объектному миру. Этот мир гораздо сложнее реляционного мира. Поскольку UML может использоваться для унифицированного объектно-ориентированного моделирования всего, что угодно, в нем содержится масса различных понятий, терминов и вариантов использования, совершенно избыточных с точки зрения проектирования реляционных БД. Если вычленить из общего механизма диаграмм классов то, что действительно требуется для проектирования реляционных БД, то мы получим в точности ER-диаграммы с другой нотацией и терминологией.

    Поэтому выбор конкретной концептуальной модели – это вопрос вкуса и сложившихся обстоятельств. Понятно, что если в организации уже имеется сложившаяся инфраструктура проектирования приложений, но разумно продолжать пользоваться именно ей до тех пор, пока это не станет тормозом. При построении же новой инфраструктуры больший вес имеют стратегические соображения высшего руководства компании, чем предпочтения технических специалистов, хотя эти предпочтения, с моей точки зрения, обязательно должны учитываться.



    Содержание раздела