Базы данных и субд

MVCC — MultiVersion Concurrency Control

zr₁(y)yyy

Как это работает?

• Когда мы пошли исполнять транзакцию t₁, имеется чтение x, т.е. самой изначальной версии.
• Дальше в t₂ мы начинаем записывать y другой версии, потому что он был изменен.
• В транзакции t₁, которая началась раньше, чем мы начали записывать y, до сих пор видно предыдущую версию y, поскольку t₂ еще не завершилась, и мы и спокойно начать с ней работать.
• Поскольку транзакция t₁ заканчивается раньше, чем w₂(y₂), то произойдет перечитываниеy,и после этого в транзакции t ₂ выполнится нормальная работа, а другая транзакция просто нормально завершится.

yw₂yt₁xy

• В MySQL он внутри InnoDB,
• В PostgreSQL это отдельная директория, которая наконец в версии 10 стала называться WAL вместо PGX-Log;
• В Oracle это называется Redo Log;
• В DB2 — WAL.

Структурная таблица

Таблица — это логическая структура, состоящая из строк и столбцов. Строки не имеют фиксированного порядка, поэтому, если извлекаются данные, может понадобиться отсортировать их. Порядок столбцов указывается при создании таблицы администратором БД. На пересечении каждого столбца и строки находится определенный элемент данных, называемый значением, или, точнее, атомарным значением. Таблица именуется высокоуровневым классификатором идентификатора пользователя владельца, за которым следует имя таблицы, например TEST.DEPT или PROD.DEPT.

Существует нескольких типов таблиц:

1. Базовая, которая создается и содержит постоянные данные.
2. Временная, в которой хранятся промежуточные результаты запроса.

Элементы таблиц:

1. Столбцы имеют упорядоченный набор: DEPTNO, DEPTNAME, MGR и ADMK DEPT. Все они должны быть однотипными данными.
2. Строки — каждая содержит данные для одного отдела.
3. Значения на пересечении столбца и строки. Например, PLANNING — это значение столбца DEPT NAME в строке для отдела B01.

Индекс — это упорядоченный набор указателей на строки таблицы. В отличие от строк таблицы, которые не находятся в определенном порядке, индекс DB2 должен всегда поддерживать порядок.

Индекс используется для двух целей:

1. Для повышения быстродействия получения значений данных.
2. Для уникальности.

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

Мультимедиа данные

Определение 1

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

Реляционные системы могут только хранить мультимедиа-данные, а создавать и редактировать такие данные способны только специализированные программы.

В реляционных системах для хранения данных предназначены таблицы. Для возможности хранения мультимедиа-данных в таблицах предусматриваются соответствующие поля. Также мультимедиа-данные могут быть сохранены в отчетах и экранных формах.

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

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

Различные СУБД содержат разные механизмы поддержки мультимедиа-данных. Зачастую для их размещения и хранения используют BLOB-поля (Binary Large OBject – большие двоичные объекты). Т.к. мультимедиа-данные могут быть различных видов (графические, аудио-, видео- и т.д.), а каждый вид может иметь разные форматы (например, графическая информация хранится в файлах с расширениями gif, tif, bmp и др.), удобно привязывать их к средствам обработки с помощью механизма OLE.

Поэтому наиболее распространенным типом BLOB-полей являются поля OLE.

Пример 1

Например, MS Access поддерживает поле объекта OLE, система Paradox позволяет создавать кроме того поля типа binary и graphic.

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

Примеры реляционных СУБД

SQLite — это популярная БД SQL с открытым исходным кодом. ПО может хранить всю БД в одном файле. Самым значительным преимуществом, которое она обеспечивает, является то, что все данные могут храниться локально без подключения к серверу. SQLite стала популярной для БД в мобильных телефонах, КПК, MP3-плеерах, телевизионных приставках и других электронных гаджетах.

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

PostgreSQL — это реляционная модель данных СУБД SQL с использованием открытого исходного кода, которая не контролируется какой-либо корпорацией. Обычно ее используют для разработки веб-приложений. PostgreSQL — простая, надежная и бюджетная программа с большим сообществом разработчиков. Имеет дополнительные функции в виде поддержки внешнего ключа, не требуя сложной настройки. Главный ее недостаток — она работает медленнее, чем иные БД, такие как MySQL. Она также менее популярна, чем MySQL, что затрудняет доступ хостов или поставщиков услуг, которые предлагают управляемые экземпляры PostgreSQL.

Виды баз данных

Существует огромное количество разновидностей баз данных, отличающихся по различным критериям. Например, в «Энциклопедии технологий баз данных», по материалам которой написан данный раздел, определяются свыше 50 видов БД.

Основные классификации приведены ниже.

Классификация по модели данных

Примеры:

• Иерархическая
• Объектная и объектно-ориентированная
• Объектно-реляционная
• Реляционная
• Сетевая
• Функциональная.

Классификация по среде постоянного хранения

• Во вторичной памяти, или традиционная (англ. conventional database): средой постоянного хранения является периферийная энергонезависимая память (вторичная память) — как правило жёсткий диск.В оперативную память СУБД помещает лишь кэш и данные для текущей обработки.
• В оперативной памяти (англ. in-memory database, memory-resident database, main memory database): все данные на стадии исполнения находятся в оперативной памяти.
• В третичной памяти (англ. tertiary database): средой постоянного хранения является отсоединяемое от сервера устройство массового хранения (третичная память), как правило на основе магнитных лент или оптических дисков.Во вторичной памяти сервера хранится лишь каталог данных третичной памяти, файловый кэш и данные для текущей обработки; загрузка же самих данных требует специальной процедуры.

Примеры:

• Географическая
• Историческая
• Научная
• Мультимедийная
• Клиентская.

Классификация по степени распределённости

• Централизованная, или сосредоточенная (англ. centralized database): БД, полностью поддерживаемая на одном компьютере.
• Распределённая БД (англ. distributed database) — составные части которой размещаются в различных узлах компьютерной сети в соответствии с каким-либо критерием.
  • Неоднородная (англ. heterogeneous distributed database): фрагменты распределённой БД в разных узлах сети поддерживаются средствами более одной СУБД.
  • Однородная (англ. homogeneous distributed database): фрагменты распределённой БД в разных узлах сети поддерживаются средствами одной и той же СУБД.
  • Фрагментированная, или секционированная (англ. partitioned database): методом распределения данных является фрагментирование (партиционирование, секционирование), вертикальное или горизонтальное.
  • Тиражированная (англ. replicated database): методом распределения данных является тиражирование (репликация).

Другие виды БД

• Пространственная (англ. spatial database): БД, в которой поддерживаются пространственные свойства сущностей предметной области. Такие БД широко используются в геоинформационных системах.
• Временная, или темпоральная (англ. temporal database): БД, в которой поддерживается какой-либо аспект времени, не считая времени, определяемого пользователем.
• Пространственно-временная (англ. spatial-temporal database) БД: БД, в которой одновременно поддерживается одно или более измерений в аспектах как пространства, так и времени.
• Циклическая (англ. round-robin database): БД, объём хранимых данных которой не меняется со временем, поскольку в процессе сохранения новых данных они заменяют более старые данные. Одни и те же ячейки для данных используются циклически.

Области применения

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

Области применения СУБД:

1. Банковское дело — для информации о клиентах, счетов и займов, а также банковских операций.
2. Авиакомпании — для бронирования и информации о расписании. Авиакомпании были одними из первых, кто использовал базы данных в географически распределенном порядке: терминалы, расположенные по всему миру, обращались к центральной системе баз данных через телефонные линии и другие сети передачи данных.
3. Университеты — для информации о студентах, регистрации курсов и оценок.
4. Операции с кредитными картами — для покупок по кредитным картам и формирования ежемесячных выписок.
5. Телекоммуникации — для ведения записей о совершенных вызовах, составления ежемесячных счетов, поддержания баланса на телефонных карточках с предоплатой и хранения информации о сетях связи.
6. Финансы — для хранения информации о запасах, продажах и покупках финансовых инструментов, таких, как акции и облигации.
7. Продажи — информация о клиенте, продукте и покупке.
8. Производство — для управления цепочкой поставок и для отслеживания производства товаров на фабриках, запасов товаров на складах, в магазинах и заказов на товары.
9. Человеческие ресурсы — для получения информации о сотрудниках, заработной плате, налогах на заработную плату и льготах, а также для получения зарплат.

Преимущества и недостатки

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

Модель базы данных	Год создания	Преимущества	Недостатки
Иерархическая	1960-й	Очень быстрый доступ для чтения, четкая структура, технически простой.	Исправлена ​​структура в дереве, которая не допускает связи между деревьями.
Сетевая	Начало 1970-х	Поддерживает несколько способов доступа к записи, без строгой иерархии.	Плохой обзор с большими базами данных.
Реляционная	1970-й	Простое, гибкое создание и редактирование, легко расширяемое, быстрый ввод в эксплуатацию, простое расширение, быстрый запуск, очень динамичный контекст.	Неуправляемый с большими объемами данных, плохой сегментацией, атрибутами искусственного ключа, внешним интерфейсом программирования, плохо отражает свойства и поведение объектов.
Ориентирована на объекты	Конец 1980-х	Лучшая поддержка объектноориентированных языков программирования, хранение мультимедийного контента. Поддерживает объектноориентированные языки программирования, позволяет хранить мультимедийный контент.	Более низкая производительность с большими объемами данных, мало совместимых интерфейсов.
Ориентирована на документы	1980-е	Соответствующие данные хранятся централизованно в независимых документах, свободной структуре, концепции мультимедиа, относится к классификации сущностей БД.	Организационная работа относительно высока, часто требует навыков программирования.

Приведём пример

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

В теории всё можно расположить в одной таблице, а именно:

Однако такое расположение противоречит атомарности, причём в столбцах «Созданные сообщения» и «Созданные темы» возможно неограниченное число значений. Целесообразнее всего разбить таблицу на три:

Теперь таблица «Пользователи» соответствует правилам. Но вот таблицы «Сообщения» и «Темы» — нет, т. к. не должно быть 2-х одинаковых строк. В нашем же случае один и тот же пользователь может написать 2 одинаковых сообщения:

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

Модель сетевой базы данных

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

Преимущества сетевой БД:

1. Концептуально проста и легка в разработке.
2. Доступ к данным проще и гибче по отношению к иерархической модели и не позволяет члену существовать без родителя.
3. Может обрабатывать сложные данные из-за своего отношения «многие ко многим». Это позволяет более естественное моделирование отношений между записями или объектами реляционной СУБД в отличие от иерархической.
4. Благодаря своей гибкости легче перемещается и находит информацию в сетевой БД.
5. Такая структура изолирует управляющие программы от сложных физических данных.

Таблица как важная часть реляционной БД

Всем известно, что реляционная база данных состоит из таблиц. При этом каждая таблица включает в себя столбцы (поля либо атрибуты) и строки (записи либо кортежи).

Таблицы в таких БД обладают следующими свойствами:
— столбцы размещаются в определённом порядке, формируемом при создании таблицы. Таблица может не иметь ни одной строки, однако хотя бы один столбец должен быть обязательно;
— в таблице не может быть 2-х одинаковых строк. Если вспомнить математику, то такие таблицы называют отношениями (relation). Именно поэтому данные БД и считаются реляционными;
— каждый столбец в пределах таблицы имеет уникальное имя, а все значения в одном столбце должны быть одного типа (дата, текст, число и т. п.);
— на пересечении строки и столбца может быть только атомарное значение (значение, не состоящее из группы значений). Таблицы, которые удовлетворяют этим условиям, считаются нормализованными.

Расчет массы дома

История

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

В широком смысле понятие истории баз данных обобщается до истории любых средств, с помощью которых человечество хранило и обрабатывало данные. В таком контексте упоминаются, например, средства учёта царской казны и налогов в древнем Шумере (4000 г. до н. э.), узелковая письменность инков — кипу, клинописи, содержащие документы Ассирийского царства и т. п. Следует помнить, что недостатком этого подхода является размывание понятия «база данных» и фактическое его слияние с понятиями «архив» и даже «письменность».

История баз данных в узком смысле рассматривает базы данных в традиционном (современном) понимании. Эта история начинается с 1955 года, когда появилось программируемое оборудование обработки записей. Программное обеспечение этого времени поддерживало модель обработки записей на основе файлов. Для хранения данных использовались перфокарты.

Оперативные сетевые базы данных появились в середине 1960-х. Операции над оперативными базами данных обрабатывались в интерактивном режиме с помощью терминалов. Простые индексно-последовательные организации записей быстро развились к более мощной модели записей, ориентированной на наборы. За руководство работой Data Base Task Group (DBTG), разработавшей стандартный язык описания данных и манипулирования данными, Чарльз Бахман получил Тьюринговскую премию.

В это же время в сообществе баз данных Кобол была проработана концепция схем баз данных и концепция независимости данных.

Следующий важный этап связан с появлением в начале 1970-х реляционной модели данных, благодаря работам Эдгара Кодда.
Работы Кодда открыли путь к тесной связи прикладной технологии баз данных с математикой и логикой. За свой вклад в теорию и практику Эдгар Ф. Кодд также получил премию Тьюринга.

Сам термин база данных (англ. database) появился в начале 1960-х годов, и был введён в употребление на симпозиумах, организованных компанией SDC в и 1965 годах, хотя понимался сначала в довольно узком смысле, в контексте систем искусственного интеллекта. В широкое употребление в современном понимании термин вошёл лишь в 1970-е годы.

Объектно-ориентированная система

В объектно-ориентированных БД все данные являются объектами. Они могут быть связаны друг с другом отношением «является частью» для представления более крупных составных элементов.

Например, данные, описывающие автомобиль, могут храниться как составная часть конкретного двигателя, шасси, коробки передач, системы рулевого управления и др. Классы объектов могут образовывать иерархию, в которой отдельные объекты наследуют свойства от объектов выше. Например, все объекты класса «моторный транспорт» будут иметь двигатель (грузовик, автомобиль или самолет). Аналогично двигатели также являются объектами данных, и атрибут двигателя конкретного транспортного средства будет являться ссылкой на конкретный объект двигателя.

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

Реляционная структура данных

В конце 60-х годов появились работы, в которых обсуждались возможности применения различных табличных даталогических моделей данных, т.е. возможности использования привычных и естественных способов представления данных. Наиболее значительной из них была статья сотрудника фирмы IBM д-ра Э. Кодда (Codd E.F., A Relational Model ofData for LargeShared Data Banks. CACM 13:6, June 1970), где, вероятно, впервые был применен термин «реляционная модель данных».

Будучи математиком по образованию, Э. Кодд предложил использовать для обработкиданных аппарат теории множеств (объединение, пересечение, разность, декартово произведение). Он показал, что любое представление данных сводится к совокупности двумерных таблиц особого вида, известного в математике какотношение – relation (англ.).

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

Доменом называется множество атомарных значений одного и того же типа. Отношение на доменах D1, D2, …, Dn (не обязательно, чтобы все они были различны) состоит из заголовка и тела. На рис. 2.6 приведен пример отношения для расписания движения самолетов.

Заголовок (интерпретация) состоит из такого фиксированного множества атрибутов A1, A2, …, An, что существует взаимно однозначное соответствие между этими атрибутами Ai и определяющими их доменами Di (i=1,2,…,n).

Рис. 2.6. Отношение с математической точки зрения (Ai — атрибуты, Vi — значения атрибутов)

Тело состоит из меняющегося во времени множества кортежей, где каждый кор теж со стоит в свою очер едь из множества пар атрибут-значение (Ai:Vi), (i=1,2,…,n), по одной такой паре для каждого атрибута Ai в заголовке. Для любой заданной пары атрибут-значение (Ai:Vi) Vi является значением из единственного домена Di, который связан с атрибутом Ai.

Степень отношения – это число его атрибутов. Отношение степени один называют унарным, степени два – бинарным, степени три – тернарным, …, а степени n – n-арным.

Кардинальное число или мощность отношения – это число его кортежей. Кардинальное число отношения изменяется во времени в отличие от его степени.

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

Классификация СУБД

По модели данных

По типу управляемой базы данных СУБД разделяются на:

§  Иерархические (система FAT, Серверы каталогов)

§  Сетевые (интернет)

§  Реляционные (MS Access)

§  Объектно-реляционные ( Oracle Database, Microsoft SQL Server 2005, PostgreSQL)

По архитектуре организации хранения данных

§  локальные СУБД (все части локальной СУБД размещаются на одном компьютере)

§  распределенные СУБД (части СУБД могут размещаться на двух и более компьютерах)

По способу доступа к БД

§  Файл-серверные

В файл-серверных СУБД файлы данных располагаются централизованно на файл-сервере. Ядро СУБД располагается на каждом клиентском компьютере. Доступ к данным осуществляется через локальную сеть. Синхронизация чтений и обновлений осуществляется посредством файловых блокировок. Преимуществом этой архитектуры является низкая нагрузка на ЦП сервера, а недостатком — высокая загрузка локальной сети.

На данный момент файл-серверные СУБД считаются устаревшими.

Примеры: Microsoft Access (Microsoft Access — реляционная СУБД корпорации Microsoft. Имеет широкий спектр функций, включая связанные запросы, сортировку по разным полям, связь с внешними таблицами и базами данных. Благодаря встроенному языку VBA, в самом Access можно писать приложения, работающие с базами данных. Основные компоненты MS Access:просмотр таблиц; построитель экранных форм; построитель SQL-запросов (язык SQL в MS Access не соответствует стандарту ANSI); построитель отчётов, выводимых на печать.), Borland Paradox.

§  Клиент-серверные

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

Примеры: Firebird, Interbase, MS SQL Server, Sybase, Oracle, PostgreSQL, MySQL, ЛИНТЕР.

§  Встраиваемые

Примеры: OpenEdge, SQLite, BerkeleyDB, один из вариантов Firebird, один из вариантов MySQL, Sav Zigzag, Microsoft SQL Server Compact, ЛИНТЕР.

6. Виды нормализации (1-3-нормальная форма).

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

Процесс преобразования базы данных к виду, отвечающему нормальным формам, называется нормализацией. Нормализация предназначена для приведения структуры базы данных к виду, обеспечивающему минимальную избыточность, то есть нормализация не имеет целью уменьшение или увеличение производительности работы или же уменьшение или увеличение объёма БД. Конечной целью нормализации является уменьшение потенциальной противоречивости хранимой в БД информации.

Устранение избыточности производится, как правило, за счёт отношений таким образом, чтобы в каждом отношении хранились только первичные факты (то есть факты, не выводимые из других хранимых фактов).

Всего в реляционной теории насчитывается 6 НФ:

1.  1-я НФ (обычно обозначается также 1НФ).

2.  2НФ.

3.  3НФ.

4.  НФ Бойса-Кодда (НФБК).

5.  4НФ.

6.  5НФ.

1НФ

Таблица находится в первой нормальной форме, если каждый её атрибут атомарен. Под выражением «атрибут атомарен» понимается, что атрибут может содержать только одно значение. Таким образом, не существует 1NF таблицы, в полях которых могут храниться списки значений. Для приведения таблицы к 1NF обычно требуется разбить таблицу на несколько отдельных таблиц.

Замечание: в реляционной модели отношение всегда находится в 1 (или более высокой) нормальной форме в том смысле, что иные отношения не рассматриваются в реляционной модели. То есть само определение понятия отношение заведомо подразумевает наличие 1NF.

Ключи в БД

Первичный ключ (РК, primary key) — столбец, значения которого различны во всех строках. РК бывают логические (естественные) и суррогатные (искусственные).

Суррогатный ключ — это дополнительное поле в БД. Обычно это уникальный id (порядковый номер записи), хотя принцип может быть и другой, главное — уникальность.

Вносим первичные ключи в наши таблицы:

Заметьте, что каждая запись в таблице уникальна. Осталось лишь установить соответствие между сообщениями и темами, используя первичные ключи. Добавляем в таблицу с сообщениями ещё одно поле:

Теперь становится ясно, что сообщение id=2 относится к теме «О рыбалке» (id=4), которая создана Васей, а остальные принадлежат теме «О рыбалке», созданной Кириллом (id=1). Такое поле будет называться внешний ключ (FK, foreign key). При этом каждое значение данного поля сопоставляется с каким-либо первичным ключом из таблицы «Темы». В результате устанавливается однозначное соответствие между темами и сообщениями.

Ещё момент: допустим, добавляется новый пользователь по имени Вася.

Как узнать, какой же из «Васей» оставил сообщение? Для этого поля «Автор» в наших таблицах «Сообщения» и «Темы» мы тоже сделаем внешними ключами:

Итак, наша база данных фактически готова. Схематично она выглядит так:

В этой небольшой базе данных лишь 3 таблицы. А что делать, если их 10 либо 200? Ясно, что всё не так просто. Именно поэтому любое проектирование реляционных баз данных начинается с разработки концептуальной модели данных.

Объектно-реляционные субд

Разница между объектно-реляционными и объектными СУБД: первые являют собой надстройку над реляционной схемой, вторые же изначально объектно-ориентированы. Главная особенность и отличие объектно-реляционных, как и объектных, СУБД от реляционных заключается в том, что О(Р)СУБД интегрированы с Объектно-Ориентированным (OO) языком программирования, внутренним или внешним как C++, Java. Характерные свойства OРСУБД:

• комплексные данные,
• наследование типа,
• объектное поведение.

Комплексные данные могут быть реализованы через постоянно-хранимые объекты (persistent objects). Создание комплексных данных в большинстве существующих ОРСУБД основано на предварительном определении схемы через определяемый пользователем тип (UDT — user-defined type). Используются также встроенные конструкторы составных типов, например массив (ARRAY).

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

Объектное поведение закладывается через описание программных объектов. Такие объекты должны быть сохраняемыми и переносимыми для обработки в базе данных, поэтому они называются обычно как постоянные (или долговременные) объекты. Внутри базы данных все отношения с постоянным программным объектом есть отношения с его объектным идентификатором (OID).

Объектно-реляционными СУБД являются, к примеру, широко известные Oracle Database, Microsoft SQL Server 2005, PostgreSQL, а также Sav Zigzag, IBM Cloudscape,

Понятие БД и классификация БД

Сегодня системы баз данных имеют важное значение во многих областях науки, техники и пользовательского применения. Любой тип программного обеспечения, разработанный для компаний, основан на надежных БД с большим количеством опций и инструментов для системных администраторов

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

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

В зависимости от изменчивости базы данных ее тип относят по классификации БД к статическому или динамическому.

Функции статических БД:

1. Позволяют только чтение данных, исключая модификацию.
2. Применяются для биографий и исторических фактов или сценариев, к которым можно обращаться для исследования, без необходимости изменения содержания.
3. Они безопасны и просты в использовании при подключении к сети.

Функции динамических БД:

1. Они обладают понятием самоуправления.
2. Могут быть связаны с динамическими сетями.
3. Эта структурная ассоциация позволяет хранить и обновлять информацию базы данных.
4. Использует HTML в качестве языка связи между сетью и динамической БД.
5. Наиболее используемые языки для создания динамических сетей, связанных с BBDD: Perl, CGI, PHP, JSP и ASP.

Основными СУБД, которые работают с динамическими веб-страницами, являются PostgresQL, MySQL, Oracle и Microsoft SQL.

Для того чтобы понять, какие существуют варианты классификации БД, используемых в научной и образовательной среде, рассматривают:

• библиографические;
• документальные;
• специализированные;
• справочники.

Функциональные возможности библиографических БД:

1. Связаны со старыми записями, которые содержат информацию о местонахождении книги или документа.
2. Не содержат полный текст, только ссылку.
3. Благодаря таким форматам, как PDF, позволяет получать доступ к оригинальным статьям, на которые есть ссылки.
4. С развитием технологий включаются ссылки из других СМИ.

Особенности специализированных БД:

1. Содержат точную информацию и ориентированы на конкретную тему.
2. Используются в академической и научной среде.
3. Для некоторых случаев не рассматриваются как правильные BBDD: например, телефонный справочник, список контактов компании или международной компании.