Простейшие базы данных

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

6.
Сетевая модель данных

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

7.
Иерархическая модель данных — это модель данных, где используется представление базы данных в виде древовидной (иерархической) структуры, состоящей из объектов (данных) различных уровней.

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

 

 

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

В этой модели запрос, направленный вниз по иерархии, прост (например, какие заказы принадлежат этому покупателю); однако запрос, направленный вверх по иерархии, более сложен (например, какой покупатель поместил этот заказ). Также, трудно представить не-иерархические данные при использовании этой модели.

Иерархической базой данных является файловая система, состоящая из корневого каталога, в котором имеется иерархия подкаталогов и файлов.

 

8.
Реляционная модель данных (РМД) — логическая модель данных, прикладная теория построения баз данных, которая является приложением к задачам обработки данных таких разделов математики, как теория множеств и логика первого порядка.

На реляционной модели данных строятся реляционные базы данных.

Реляционная модель данных включает следующие компоненты:

· Структурный аспект (составляющая) — данные в базе данных представляют собой набор отношений.

· Аспект (составляющая) целостности — отношения (таблицы) отвечают определенным условиям целостности. РМД поддерживает декларативныеограничения целостности уровня домена (типа данных), уровня отношения и уровня базы данных.

· Аспект (составляющая) обработки (манипулирования) — РМД поддерживает операторы манипулирования отношениями (реляционная алгебра,реляционное исчисление).

 

9.
Реляционная модель данных (РМД) — логическая модель данных, прикладная теория построения баз данных, которая является приложением к задачам обработки данных таких разделов математики, как теория множеств и логика первого порядка.

На реляционной модели данных строятся реляционные базы данных.

Реляционная модель данных включает следующие компоненты:

· Структурный аспект (составляющая) — данные в базе данных представляют собой набор отношений.

· Аспект (составляющая) целостности — отношения (таблицы) отвечают определенным условиям целостности. РМД поддерживает декларативныеограничения целостности уровня домена (типа данных), уровня отношения и уровня базы данных.

· Аспект (составляющая) обработки (манипулирования) — РМД поддерживает операторы манипулирования отношениями (реляционная алгебра,реляционное исчисление).

·

·

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

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

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

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

Отношения реляционной базы данных обладают следующими свойствами:

• в отношениях не должно быть кортежей-дубликатов,

• кортежи отношений не упорядочены,

• атрибуты отношений также не упорядочены.

Из этих свойств отношения вытекают важные следствия.

Уникальность кортежей определяет, что в отношении всегда имеется атрибут или набор атрибутов, позволяющих

11
ЭЛЕМЕНТЫ ПРОЕКТИРОВАНИЯ БАЗ ДАННЫХ

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

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

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

1. Корректность схемы БД, т.е. база должна быть гомоморфным образом моделируемой ПО, где каждому объекту ПО соответствуют данные в памяти ЭВМ, а каждому процессу – адекватные процедуры обработки данных.

2. Обеспечение ограничений (на объёмы внешней и оперативной памяти и другие ресурсы вычислительной системы).

3. Эффективность функционирования (соблюдение ограничений на время реакции системы на запрос и обновление данных).

4. Защита данных (от сбоев и несанкционированного доступа).

5. Простота и удобство эксплуатации.

6. Гибкость, т.е. возможность развития и адаптации к изменениям ПО и/или требований пользователей.

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

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

 

1. 12.
СУБД «dBase»:

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

1. УБД «Approach»:

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

3. Достоинства: Простота использования при формировании запроса и отчета для разнообразных баз данных; SmartMasters позволяют конечному пользователю быстро приступить к разработке приложений; простые инструментальные средства анализа
СУБД «Clipper»:

Clipper — это созданная фирмой Nantucket Corp. система программирования приложений в среде БД, включающая в себя быстрый компилятор программ, написанных на языке, близком к языку СУБД dBaseIII PLUS, редактор связей, развитый интерактивный символический отладчик, обладающий пользовательским интерфейсом в стиле меню, который можно связать с разрабатываемой программой для облегчения ее отладки, большую библиотеку объектных модулей системных функций, а также ряд служебных программ (утилит).

1. СУБД «MS Access»:

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

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

13
Логическое проектирование БД

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

14
1. Аномалия обновления: в отношении ПОСТАВКИ она может возникнуть, если у какого-либо поставщика изменился адрес. Изменения должны быть внесены во все кортежи, соответствующие поставкам этого поставщика; в противном случае данные будут противоречивы.

2. Аномалия удаления: при удалении записей обо всех поставках одного поставщика все данные о поставщике будут утеряны.

3. Аномалия добавления: в нашем примере она возникнет, если с поставщиком заключен договор, но поставок от него еще не было. Информация о таком поставщике не может быть внесена в отношение ПОСТАВКИ, т.к. для него не определён ключ (номер поставки и название товара) и другие обязательные поля.

Для решения проблемы аномалии модификации данных при проектировании РБД проводится нормализация отношений.

Нормализация отношений

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

Декомпозицией схемы отношения R называется замена её совокупностью схем отношений А_i таких, что

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

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

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

 

15
СИСТЕМЫ УПРАВЛЕНИЯ БАЗАМИ ДАННЫХ

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

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

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

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

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

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

По степени универсальности СУБД делят на два класса: СУБД общего назначения (СУБД ОН) и специализированныеСУБД (СпСУБД).

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

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

• за счёт знания особенностей конкретной предметной области,
• путём сокращения функциональной полноты системы.

Создание СпСУБД – дело весьма трудоемкое, поэтому для того, чтобы выбрать этот путь, надо иметь действительно веские основания. В дальнейшем будут рассматриваться только СУБД общего назначения.

16
Физическая организация баз данных определяет способы размещения данных в среде хранения и способы физического доступа к этим данным. Исторически первыми системами хранения и доступа были файлы (см. главу 1. Базы данных и модели данных), являвшиеся частью операционной системы. По мере роста объема данных и требований, предъявляемых к СУБД, механизмы буферизации и управления файлами оказались неэффективны. Тогда произошел переход от файлов к непосредственному управлению размещением данных на носителях, осуществляемому самой СУБД. При этом пространство внешней памяти предоставляется СУБД полностью для управления, а операционная система не получа- ет доступа к этому пространству.

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

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

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

17
Структура хранимых данных

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

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

2. Информационная часть. Содержит значения элементов данных.

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

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

В сетевых и иерархических БД ассоциации между данными поддерживаются групповыми отношениями. Наиболее распространённый способ поддержания групповых отношений – создание цепного списка. Для этого запись-владелец в служебной части содержит адресную ссылку (ключ базы данных) на первую подчиненную запись, а каждая подчиненная запись содержит ссылку на следующую (рис. 5.3,б). Последняя подчиненная запись содержит либо признак конца списка (разомкнутый список), либо ссылку на владельца (замкнутый список).

Ссылки могут быть однонаправленными (только на следующую запись) или двунаправленными (на следующую и на предыдущую записи). В последнем случае запись владелец кроме ссылки на начало списка подчинённых записей также содержит ссылку на последнюю подчиненную запись (рис. 5.3,в).

Двунаправленный список удобен при удалении записи. Для корректности удаления подчиненной записи нужно, чтобы предыдущая запись содержала ссылку на последующую запись (по отношению к удаленной). Например, при удалении записи В2 (рис. 5.3,в) запись В1 должна ссылаться на запись В3. Имея ссылку на предыдущую запись, можно сразу выполнить шаг назад и изменить значение ссылки у записи В1, не проходя заново по всему списку.

 

18
Рассмотрим правила преобразования ER-модели в реляционную.

 

1. Каждой сущности ставится в соответствие отношение реляционной модели данных.

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