Заключительные замечания
В заключение позвольте мне вернуться к стаптье Кодда про "великое сражение". Кодд отмечает, что "недостаточно принимать во внимание подходы, используемые сегодня -- нам нужно ясно осознавать будущее развитие событий". Он говорит, что существенно возрастет роль "случайных" пользователей систем баз данных (в действительности, скоро они будут представлять большинство), и мы должны уделять внимание другим подходам, требуемым для поддержки таких пользователей. Вот некоторые цитаты:
И сегодня эти наблюдения нуждаются лишь в незначительных корректировках.
Я хотел бы завершить это обсуждение языка Кодда Alpha двумя замечаниями.
Gamma-0 и Gamma-1 совместно демонстрируют большое сходство с подсистемой хранения System R [1], называемой RSS (Relational Storage System). Поэтому не удивительно, что один из коллег Кодда Ирв Трейджер позже был менеджером проекта RSS.
Я хотел бы завершить статью парой наблюдений:
- Прежде всего (и это самое главное), позиция Критиков A и B по поводу relvar остается исключительно неясной. Как кажется, они считают понятие relvar дефектным по своей сути, но в то же время желают их сохранить, по крайней мере, «неявно» (?). Они также не могут объяснить, в чем состоит логическое различие между relvar как таковыми и «изменяемыми во времени отношениями».
- Верно, что некоторые языки программирования – конкретно, так называемые логические языки (например, Prolog) и функциональные языки (например, LISP) – умудряются существовать без присваивания: на самом деле, вообще без понятия «постоянной памяти» («persistent memory»). Однако, насколько мне известно, все такие языки «ловчат», когда требуется обновить базу данных; в действительности, они выполняют некоторую разновидность присваивания, возможно, в качестве побочного эффекта, хотя присваивание не является частью логического или функционального стиля.
Нельзя сказать, что проектирование баз данных на основе семантических моделей в любом случае убыстряет и/или упрощает процесс проектирования. Все зависит от сложности предметной области, квалификации проектировщика и качества вспомогательных программных средств. Но в любом случае этап диаграммного моделирования обеспечивает следующие преимущества:
Хочу еще раз подчеркнуть, что в контексте проектирования реляционных БД структурные методы проектирования, основанные на использовании ER-диаграмм, и объектно-ориентированные методы, основанные на использовании языка UML, различаются, главным образом, лишь терминологией. ER-модель концептуально проще UML, в ней меньше понятий, терминов, вариантов использования. И это понятно, поскольку разные варианты ER-моделей разрабатывались именно для поддержки проектирования реляционных БД, и ER-модели почти не содержат возможностей, выходящих за пределы реальных потребностей проектировщика реляционной БД.
Язык UML принадлежит объектному миру. Этот мир гораздо сложнее реляционного мира. Поскольку UML может использоваться для унифицированного объектно-ориентированного моделирования всего, что угодно, в нем содержится масса различных понятий, терминов и вариантов использования, совершенно избыточных с точки зрения проектирования реляционных БД. Если вычленить из общего механизма диаграмм классов то, что действительно требуется для проектирования реляционных БД, то мы получим в точности ER-диаграммы с другой нотацией и терминологией.
Поэтому выбор конкретной концептуальной модели – это вопрос вкуса и сложившихся обстоятельств. Понятно, что если в организации уже имеется сложившаяся инфраструктура проектирования приложений, но разумно продолжать пользоваться именно ей до тех пор, пока это не станет тормозом. При построении же новой инфраструктуры больший вес имеют стратегические соображения высшего руководства компании, чем предпочтения технических специалистов, хотя эти предпочтения, с моей точки зрения, обязательно должны учитываться.