Направление объектно-ориентированных баз данных (ООБД) возникло сравнительно давно. Публикации появлялись уже в середине 1980-х гг. Однако наиболее активно это направление развивается в последние годы. С каждым годом увеличивается число публикаций и реализованных коммерческих и экспериментальных систем.
Возникновение направления ООБД определяется прежде всего потребностями практики: необходимостью разработки сложных информационных прикладных систем, для которых технология предшествующих систем БД не была вполне удовлетворительной.
Конечно, ООБД возникли не на пустом месте. Соответствующий базис обеспечивают как предыдущие работы в области БД, так и давно развивающиеся направления языков программирования с абстрактными типами данных и объектно-ориентированных языков программирования.
Обычные БД хранят мгновенный снимок модели предметной области. Любое изменение в момент времени t некоторого объекта приводит к недоступности состояния этого объекта в предыдущий момент времени. Самое интересное, что на самом деле в большинстве развитых СУБД предыдущее состояние объекта сохраняется в журнале изменений, но возможности доступа со стороны пользователя нет.
Конечно, можно явно ввести в хранимые отношения явный временной атрибут и поддерживать его значения на уровне приложений. Более того, в большинстве случаев так и поступают. Недаром в стандарте SQL появились специальные типы данных date и time. Но в таком подходе имеются несколько недостатков: СУБД не знает семантики временного поля отношения и не может контролировать корректность его значений; появляется дополнительная избыточность хранения (предыдущее состояние объекта данных хранится и в основной БД, и в журнале изменений); языки запросов реляционных СУБД не приспособлены для работы со временем.
По определению, дедуктивная БД состоит из двух частей: экстенциональной, содержащей факты, и интенциональной, содержащей правила для логического вывода новых фактов на основе экстенциональной части и запроса пользователя.
Легко видеть, что при таком общем определении SQL-ориентированную реляционную СУБД можно отнести к дедуктивным системам. Действительно, что есть определенные в схеме реляционной БД представления как не интенциональная часть БД.
Основным отличием реальной дедуктивной СУБД от реляционной является то, что и правила интенциональной части БД, и запросы пользователей могут содержать рекурсию. Именно возможность рекурсии делает реализацию дедуктивной СУБД очень сложной и во многих случаях эффективно неразрешимой проблемой.
По определению БД называется активной, если СУБД по отношению к ней выполняет не только те действия, которые явно указывает пользователь, но и дополнительные действия в соответствии с правилами, заложенными в саму БД.
Легко видеть, что основа этой идеи содержалась в языке SQL времени System R. На самом деле, что есть определение триггера или условного воздействия как не введение в БД правила, в соответствии с которым СУБД должна производить дополнительные действия? Плохо лишь то, что на самом деле триггеры не были полностью реализованы ни в одной из известных систем, даже и в System R. И это не случайно, потому что реализация такого аппарата в СУБД очень сложна, накладна и не полностью понятна.
Одним из основных положений реляционной модели данных является требование нормализации отношений: поля кортежей могут содержать лишь атомарные значения. Для традиционных приложений реляционных СУБД — банковских систем, систем резервирования и т.д. — это вовсе не ограничение, а даже преимущество, позволяющее проектировать экономные по памяти БД с предельно понятной структурой. Запросы с соединениями в таких системах сравнительно редки, для динамической поддержки целостности используются соответствующие средства SQL.
Ввиду почти наступившего лета, если кто заметил, на блоге местного автора произошли некие малозаметные пертурбации, ввиду чего читателю с того полагается очевидная польза информационного характера. Вы можете задавать вопросы армянскому радио, а также по мотивам оных квесченов читать несомненно полезные посты наподобие сегодняшнего. Которые бы никогда не родились без настойчивого желания узнать то, о чём никто не говорит.
В этом месте в Рунете принято молвить какие-нибудь волшебные слова, постигнув смысл которых, все бросаются чуть ли не конспектировать дальнейшее. Но местный автор настолько витиеват в своих речах, что он лучше уж пару весёлых картинок разместит:
Мужики тут же опознают в этих силуэтах лупоглазый сто седьмой Пежо и Рено Логан. Которые объединяет то, что они являются младшенькими в линейках соответствующих торговых марок, и, соответственно, стоят где-то 350 в среднем килорублей.
Слушатели армянского радио некоторое время тому назад массово спрашивали местного автора про разного рода блогуны и SEO-ссылки, на каковые вопросы сразу ответа не последовало. Тогда сочлось, что Гугл велик, и про такого рода вещи имеет смысл спрашивать всё-таки у него.
Но потом подумалось, что этой теме стоит посвятить отдельный разговор, возможно, приводящий к правильному пониманию простых вещей. Ибо, когда в голове выстроена логически стройная и непротиворечивая система, жить намного легче.
Ну а чтоб с логикой всё было очевидно, к этой самой формальной логике сразу и обратимся. Ничего при этом не подчёркивая в тексте и не выделяя цветом, так как изначально апеллируем к умственным способностям читателя — что постигнет, то его.
Про ритуал отбора кандидатур.
В России Microsoft Foxpro долгое время был самым популярным инструментом для создания баз данных. В настоящее время его несколько потеснили такие средства разработки как Delphi, MS Access и MS Visual Basic. Но и сейчас Foxpro остается самым популярным инструментом для разработки баз. На нем написано БОЛЬШЕ ВСЕГО бухгалтерских, экономических и других приложений, связанных с расчетами и хранением информации. И вот почти вышла очередная, седьмая версия Visual Foxpro (сейчас идет тестирование beta-версии). Чем Visual FoxPro 7 отличается от предыдущих версий ?
В седьмую версию Visual Foxpro добавлено множество дополнений как в среду разработки (имеется ввиду редактор, окна отладки и другие визуальные элементы), так и собственно в синтаксис языка, которые намного увеличивают производительность работы. Все дополнения нацелены на уменьшение количества кода, которое разработчик должен набирать,а так же на предоставление дополнительного контроля над действиями пользователя.
Если вам повезло провести неделю в Калифорнийской пустыне в начале июня, то возможно, довелось присутствовать на первой публичной демонстрации Visual FoxPro 7.0. Если вас там не было или если вы слишком прикладывались к бокалу с Маргаритой, я уверен, что вам будет интересно прочитать об инструменте, который в недалеком будущем займет место на вашем столе.
Нам показали новые возможности редактора, расширения среды разработки, технологию IntelliSence. Вместо того чтобы пересказывать интересный монолог — новые возможности гораздо лучше демонстрировать «вживую», я просто перечислю то что видел сам.
Возможность закрепления (dock) окна команд и различных окон отладчика.
В прежние времена, новой функциональности, представленной в этом «наборе обновлений» хватило бы на новую версию или уж как минимум на промежуточную, которая кладется в самостоятельную коробку, снабжается документаций и пр. Так что можно считать что с выходом Visual Studio Service Pack 3 (SP3) на рынке появился Visual FoxPro 6.5.
Что же там такого. Ну, как обычно исправление довольно большого числа ошибок самого Visual FoxPro. Исправление неправильно работчающего кода в примерах. Но это мелочи и ради них я не стал бы тратить ваше время.
