Базы данных

Третья часть реляционной модели, манипуляционная часть, утверждает, что доступ к реляционным данным осуществляется при помощи реляционной алгебры или эквивалентного ему реляционного исчисления.

Основы реляционной модели данных были впервые изложены в статье Е.Кодда в 1970 г. Эта работа послужила стимулом для большого количества статей и книг, в которых реляционная модель получила дальнейшее развитие. Наиболее распространенная трактовка реляционной модели данных принадлежит К.Дейту.

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

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

Motorola, Nokia, MCI, Northern Telecom, Philadelphia Stock Exchange, Bear Stearns, First National Bank of Chicago, the Money Store, the US Army, NASA, Boeing. Все эти компании, независимо от направления бизнеса, имеют одно общее: они выбрали InterBase в качестве ключевого компонента их информационных систем. Borland InterBase одинаково хорошо применяется и для "домашнего" управления ракетными системами, сбора данных для аэрокосмических исследований или хранения и обработки данных биржи. Приложения подобного рода имеют много общих требований: легкость использования и управления, производительность, масштабируемость, переносимость, использование ресурсов и восстановление после сбоя. Borland InterBase разработан именно с целью удовлетворять всем этим требованиям.

Направление объектно-ориентированных баз данных (ООБД) возникло сравнительно давно. Публикации появлялись уже в середине 1980-х годов (например, [96]). Однако наиболее активно это направление развивается в последние годы. С каждым годом увеличивается число публикаций и реализованных коммерческих и экспериментальных систем. Возникновение направления ООБД определяется прежде всего потребностями практики: необходимостью разработки сложных информационных прикладных систем, для которых технология предшествующих систем БД не была вполне удовлетворительной.

Этот документ сформирован по предложениям в конференции fido7.su.dbms.interbase. Здесь дан список того, что не надо (или категорически нельзя) делать при работе с Interbase/Firebird/Yaffil.

Во-первых, подзапрос, как правило, можно написать в том месте, где требуется получить/вычислить какое-либо одно значение. В этом случае просто на месте значения пишут подзапрос в скобках. При этом фраза select этого подзапроса должна возвращать ровно одно поле, а логика остальных частей должна обеспечивать, чтобы возвращалось не более одной записи. Если не будет сформировано ни одной, то подзапрос возвращает null, если же несколько, то возникнет ошибка. Подзапросы подобного рода могут фигурировать, в частности, в вычисляемых выражениях или в операциях сравнения.

Системные таблицы InterBase содержат метаданные базы данных. Они создаются автоматически сервером InterBase, когда создается сама база данных. Информация, содержащаяся в этих таблицах, определяет типы полей таблиц, их названия, связи между таблицами и пр. Эти таблицы сопровождаются сервером, и их, конечно, лучше не менять. Я бы сказал, что лучше принять все меры к тому, что бы они были недоступны пользователю.

Если суммировать мысли кратко, то по поводу тормозологии interbase: когда делаешь что-то серьёзное, ни одна СУБД не сделает всё за тебя. То есть наличие супер-пупер умного оптимизатора не спасает от проблем, а лишь отодвигает их. В конечном итоге это в чём-то даже хуже, потому что когда ты упрёшься в проблемы, то будет наделано уже столько, что не исправишь. И в этой ситуации начинает играть роль не интеллект оптимизатора, а возможности ручного управления отработкой запросов interbase. В конце концов, ни один оптимизатор не знает о семантике запроса столько, сколько знает разработчик interbase (иначе это не разработчик, а ...). Вот тут-то оказывается, что interbase при внешней простоте предоставляет очень широкие возможности для управления. Фактически, более крутую вещь я видел в PostgreSQL - там можно оптимизатору собственные правила подсовывать, то есть делиться опытом. А уж что касается таких попсовых вещей, как MS SQL, то они interbase в плане управляемости в подмётки не годятся.

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

Нельзя не учитывать важность эффективных SQL-операторов в основанных на использовании СУБД Oracle приложениях. Плохо написанный оператор может привести к хаосу в базе данных. Поскольку во многих организациях пользователи производят доступ к базам данных с использованием средств генерации отчетов и прямых запросов, эффективно написанный запрос на языке SQL позволяет не только улучшить производительность приложения, но и уменьшить сетевой трафик. Поэтому как пользователи, так и разработчики должны хорошо понимать работу оптимизатора запросов и возможности настройки, которая может сделать операторы более эффективными и менее рискованными.

Небрежность и невнимательность, вот две причины написания кода, уязвимого для SQL инъекций. Третья причина - незнание, должна бы побуждать программиста к углублению своих знаний или даже изменения профессии.

Целью данной статьи является выявление различий между реализацией SQL в СУБД Oracle 8 и ANSI SQL92. В частности делается анализ языка обработки данных (DML) и не рассматривается язык определения данных (DDL), также не рассматривается объектное расширение языка SQL, предназначенного для работы с объектными таблицами Oracle и отсутствующее в стандарте ANSI. Язык SQL СУБД Oracle 8 (далее Oracle SQL), по заявлению фирмы-производителя , соответствует начальному уровню ANSI SQL (entry level), однако некоторые особенности реализации его превосходят, а некоторые отличаются.

Эта тема уже рассматривалась мной ранее, но она заслуживает повторения. В специализированных конференциях я встречал слишком много вопросов о древовидных структурах и иерархии в SQL.

В статье содержатся некоторые рекомендации, направленные на то, чтобы облегчить создание мобильных прикладных информационных систем, опирающихся на использование реляционных систем управления базами данных (СУБД), которые поддерживают международный стандарт языка баз данных (БД) SQL. Чтобы лучше прояснить смысл статьи, необходимо сделать несколько предварительных замечаний.

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

Oracle, предоставляет несколько маленьких и изящных средств управления табличными пространствами

В предыдущих версиях Oracle, сделать таблицу только для чтения, для других пользователей можно было дав объектные привелегии SELECT пользователю. Но для самого владельца таблица оставалась доступной для записи. Oracle 11g позволяет создавать таблицы которые помечаются "только для чтения", используя команду ALTER TABLE.

Ручное создание базы является одним из показателей профессионализма DBA. Как правило используется мастер создания, предлагаемый Oracle.

Производительность любого приложения базы данных в большой степени опирается на выполнение им запросов. Хотя оптимизатор Oracle идеально подходит для оценки наилучшего возможного плана без какого-либо вмешательства пользователя, план выполнения SQL-оператора может неожиданно измениться по множеству причин, включая повторный сбор статистики оптимизатора, изменение параметров оптимизатора или определений схемы и/или метаданных.

Эта статья рассказывает о том, как inline-подмена, Real native compilation и использование simple_integer могут улучшить производительность кода. Oracle Database 11g представляет несколько отличных новых возможностей для повышения производительности PL/SQL-кода, однако наиболее существенные из них – это native compilation (компиляция с получением исполняемого кода) и intra-unit inlining (подмена).

Я познакомился с регулярными выражениями давным-давно, программируя на Perl или скриптовой оболочке unix с помощью команд awk и sed. Также, если Вы используете vi редактор, то можете быть знакомыми с регулярными выражениями и сравнением с образцом. Регулярные выражения в действительности представляют собой маленький язык программирования, который предназначен для поиска символьных образцов в текстовой строке. Если честно, когда я начал использовать сравнение с образцом в мои дни Perl, оно показалось мне весьма путаным. Главным образом, потому что было столь много изменений и вариантов, что я не знал, как начать. Хотя спустя некоторое время, я приобрел некоторые навыки. И Вы сможете также. Наберитесь терпения прочесть эту статью и понять, насколько мощным может быть это сравнение с образцом.

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

Новая роль SYSASM для управления экземпляром ASM, переменный размер экстента для уменьшения использования разделяемого пула (shared pool) и возможность  экземпляра читать с конкретного диска дисковой группы – вот лишь несколько замечательных новых возможностей, появившихся в базе данных Oracle 11g ASM.

Для начала вспомним старую задачу отыскания и удаления дублей в таблице Oracle. Допустим, что в таблице tab есть повторяющиеся записи, причем мы допускаем, что записи, в которых значения столбцов c1,c2,c3 совпадают, и есть дубли.

СУБД Oracle, подобно всем, реально конкурирующим с ней, является старой системой, создание которой происходило, как и продолжается ныне развитие, в рыночных условиях. В этой СУБД, как и у конкурентов, есть целый ряд конструктивных решений, принятых в свое время второпях, и со временем ставших неудовлетворительными. Что-то удается усовершенствовать: например механизмы выделения динамической памяти для текущих нужд СУБД, регулирования доступа к общим ресурсам СУБД или буферизации блоков данных. Однако некоторые заложенные на ранних стадиях развития механизмы или же не удается изменить вовсе (недоразвитое понятие схемы БД) или удается, но с большим запозданием. К числу последних относится механизм парольной защиты пользователей (user) и ролей (role). Особенности парольной защиты Oracle, способствующие несанкционированному проникновению в БД, затронуты в этой статье.

Утилита SQL*Plus позволяет выполнять команды SQL и блоки PL/SQL, а также решать ряд других задач.

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