Базы данных. Виды БД по характеру хранимой информации, по способу хранения, по структуре организации. Основные типы данных.

Стр 1 из 4Следующая ⇒

База данных — организованная совокупность данных, предназначенная для длительного хранения во внешней памяти ЭВМ и постоянного применения

Например:

- база данных книжного фонда библиотеки;

- база данных кадрового состава учреждения;

- база данных законодательных актов в области уголовного права;

- база данных современной эстрадной песни.

Фактографические

В фактографических БД содержатся краткие сведения об описываемых объек-

тах, представленные в строго определенном формате.

Например, в БД библиотеки о каждой книге хранятся библиографические сведе-

ния: год издания, автор, название и т. д.

Документальные

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

(например, различные справочники, словари )

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

Хранилище информации – база данных железнодорожной станции; процедура ввода – ввод паспортных данных клиента;

поиск – процесс обработки запроса;

обработка – выбор клиентом даты и времени отправления поезда;

выдача информации – ваш заказ принят, билет забронирован

Централизованная БД –

БД хранится на одном компьютере

Распределённая БД –различные части одной БД хранятся на мно-

жестве компьютеров, объединённых между собой сетью

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

Реляционными базами данных называются базы данных с табличной формой организации.

В реляционных БД строка таблицы называется записью, а столбец — полем. В общем виде это выглядит так:

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

ОСНОВНЫЕ ТИПЫ ДАННЫХ

текстовый	одна строка текста (до 255 символов)
поле MEMO	текст, состоящий из нескольких строк, который можно
	посмотреть при помощи полос прокрутки (до 65535 символов)
числовой	число любого типа (можно использовать в вычислениях)
денежный	поле, выраженное в денежных единицах (рубли, доллары и т.д.)
дата/время	поле, содержащее дату или время
счётчик	поле, которое вводится автоматически с вводом каждой записи
логический	содержит одно из значений True (истина) или False (ложно) и применяется в логических операциях

поле объекта OLE	содержит рисунки, звуковые файлы, таблицы Excel, документ Word и т. д.

Банк данных

Банк данных - база данных и система управления ею (СУБД). СУБД (например, FoxPro) представляет собой приложение для создания баз данных как совокупности двумерных таблиц.

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

2. Понятие БД, СУБД, ИС. Примеры использования и сферы применения баз данных

База данных ( БД ) - это структурированные знания об объектах.

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

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

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

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

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

основное назначение БД — “постоянное применение”. Говоря о применении БД, необходимо упомянуть о понятии информационная система (ИС).

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

Ядром, “сердцем” ИС как раз и является БД. Разумеется, ИС бывают достаточно сложными, в том числе и построенными на нескольких базах данных, но сути это не меняет — БД в принципе можно представить себе как нечто автономное, но невозможно представить ИС, не основанную на БД.

Структура базы данных

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

принято выделять базы данных следующих видов: иерархические, сетевые, реляционные и объектно-ориентрованные.

Ключи

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

7. Виды связей между таблицами в Реляционной модели БД

Связь позволяет моделировать отношения между объектами предметной области. Наименование связи должно быть уникально во всей модели.

Существует 4 типа связей:

1. «Один-к-одному» - любому экземпляру сущности А соответствует только один экземпляр сущности В, и наоборот.

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

2. «Один-ко-многим» - любому экземпляру сущности А соответствует 0, 1 или несколько экземпляров сущности В, но любому экземпляру сущности В соответствует только один экземпляр сущности А.

Ученику ставят много оценок; поставленная оценка принадлежит только одному ученику.

3. «Многие-к-одному» - любому экземпляру сущности А соответствует только один экземпляр сущности В, но любому экземпляру сущности В соответствует 0, 1 или несколько экземпляров сущности А.

Преподаватель работает только в одном кабинете, однако рабочий кабинет может быть закреплен за несколькими преподавателями.

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

Если при определении связи вам сложно выделить подчиненность, то вывод только один: вы плохо разобрались в предметной области.

4. «Многие-ко-многим» - любому экземпляру сущности А соответствует 0, 1 или несколько экземпляров сущности В, и любому экземпляру сущности В соответствует 0, 1 или несколько экземпляров сущности А.

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

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

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

Первая нормальная форма

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

Первая нормальная форма предписывает, что все данные, содержащиеся в таблице, должны быть атомарными (неделимыми).

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

Так как значение поля Оценки не является атомарным, таблица не соответствует требованиям 1НФ.

Вторая нормальная форма

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

Другими словами, значение каждого поля должно полностью определяться значением первичного ключа. Важно отметить, что зависимость от первичного ключа понимается именно как зависимость от ключа целиком, а не от отдельной его составляющей (в случае составного ключа).

Приведем пример таблицы, которая не находится во 2НФ.

Как мы помним, данная таблица имеет составной ключ Дата+Время суток. Поле Температура полностью зависит от первичного ключа — с ним проблем нет. А вот поле Восход зависит лишь от поля Дата, Время суток на время восхода естественным образом не влияет.

Здесь уместно задаться вопросом: а в чем практический смысл 2НФ? Какая польза от этих ограничений? Оказывается — большая. Допустим, что в приведенном выше примере разработчик проигнорирует требования 2НФ. Во-первых, скорее всего возникнет так называемая избыточность — хранение лишних данных. Ведь если для одной записи с данной датой уже хранится время восхода, то для всех других записей с данной датой оно должно быть таким же и хранить его, вообще говоря, незачем.

Третья нормальная форма

Отношение находится в третьей нормальной форме, если оно находится во второй нормальной форме и все неключевые атрибуты не зависят друг от друга.

Взаимную зависимость столбцов удобно понимать следующим образом: столбцы являются взаимно зависимыми, если нельзя изменить один из них, не изменяя другой.

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

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

Четвертая нормальная форма

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

В теории реляционных баз данных рассматриваются и формы высших порядков — нормальная форма Бойса — Кодда, 4НФ, 5НФ и даже выше. Большого практического значения эти формы не имеют, и разработчики, как правило, всегда останавливаются на 3НФ.

Индексация

Индексация — крайне важная с точки зрения практического применения.

Основное назначение индексации — оптимизация (убыстрение) поиска (и, соответственно, некоторых других операций с базой данных).

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

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

Типы данных

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

Все реляционные СУБД поддерживают данные следующих основных типов:

· числовые;

· строковые;

· логические;

· даты.

Приведенный список не является исчерпывающим. Как правило, СУБД также имеют типы для хранения больших текстовых и двоичных данных, специальные “денежные” типы и т.д. На следующем рисунке — снимке экрана конструктора таблиц Microsoft Access — показаны типы, поддерживаемые этой системой.

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

11.Правила Кодда (требования к реляционным БД)

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

Перечислим эти правила:

1) Явное представление данных.

Все данные должны быть представлены явно и их значения должны рассчитываться косвенными алгоритмами (исключение – однозначные отображения).

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

2) Гарантированный доступ к данным.

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

а) имени отношения;

б) указателя на кортеж (например, значение первичного ключа кортежа);

в) имени атрибута;

( имя_отношения, первичный ключ, атрибут)

3) Полная обработка неопределенных значений.

Неопределенные значения, отличные от любого определенного значения, должны поддерживаться для всех типов данных при выполнении всех операций.

4) Доступ к базе данных в терминах реляционной модели.

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

5) Полнота подмножества реляционного языка.

Реляционная схема может поддерживать несколько языков, по крайней мере, язык DDL и DML. Однако хотя бы один из языков должен иметь синтаксис предложений, поддерживающий следующие понятия:

- определение данных (отношения, атрибуты, домены, ключи, ограничения целостности);

- определение виртуальных (мнимых) отношений образованных с помощью реляционных выражений на основе одного или нескольких отношений (определение представлений);

- манипулирование данными (интерактивное или программное);

- ограничение целостности;

- санкционированный доступ;

- управление транзакциями (начало транзакции, фиксация выполнения, отказ от выполнения).

6) Обновляемость представлений.

Все представления (виртуальные отношения) должны автоматически обновляться при модификации данных в базовых отношениях. Если, например, A= R È S, и А – это представление, то А должно обновляться как только меняется R или S.

7) Наличие высокоуровнего языка манипулирования данными.

Операции вставки, обновления и удаления должны применяться к отношению в целом:

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

8) Физическая независимость данных.

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

Физически независимые обеспечивает работоспособность приложений при изменении расположения данных в сети.

9) Логическая независимость данных.

Прикладные программы не должны зависеть от реализации любого из используемых представлений (виртуальных отношений).

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

10) Независимость контроля целостности.

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

11) Дистрибутивная независимость.

Реляционная система должна быть распространяема и переносима. Создание разнородных компьютерных систем требует обеспечения доступа к базам данных в различных OS и на различных платформах.

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

12) Согласования языковых уровней.

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

12.Формализация даталогической модели на языке конкретной СУБД(на примере Ассess)

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

· Определение имени таблицы. Если таблица является представлением некоторой сущности, то имя обычно соответствует названию сущности. Имена таблиц связей, как правило, образуют из названий связываемых сущностей.

· Определение имен и типов полей. На этом же этапе обычно требуется установить специфические свойства конкретных полей — может ли поле содержать “пустые” (неопределенные) значения, каким должно быть значение “по умолчанию” и т.д.

· Определение первичного ключа. Несмотря на то, что реляционная модель требует наличия в каждой таблице первичного ключа, большинство СУБД позволяют не определять ключ в таблице. Этого, разумеется, следует избегать. К чести СУБД они практически всегда стараются “наставить разработчика на путь истинный” (см., например, рисунок).

· Определение (при необходимости) индексированных полей.

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

Схожие по функциям и интерфейсу средства визуального конструирования имеют и другие СУБД.

Какой бы визуальный интерфейс не предоставляла конкретная СУБД разработчикам, в подавляющем большинстве случаев за кадром находится общий для всех реляционных СУБД язык SQL ( S tructured Q uery L anguage).

Понятно, что указанную возможность можно обеспечить лишь при наличии некоторого общего системонезависимого ядра, каковым и является SQL.)

13.Объекты базы данных. Таблицы, отчеты, страницы, макросы и модули. Запросы и формы.

БД может содержать разные типы объектов. Каждая СУБД может реализовывать свои типы объектов.

Таблицы – основные объекты любой БД, в которых хранятся все данные, имеющиеся в базе, и хранится сама структура базы (поля, их типы и свойства).

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

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

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

• Запросы и формы.

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

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

Обновление БД тоже можно осуществить посредством запроса. В базовые таблицы все данные вносятся в порядке поступления, т.е. они не упорядочены. Но по соответствующему запросу можно получить отсортированные и отфильтрованные нужным образом данные.

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

14.Язык SQL ( структурированный язык запросов ).История возникновения. Подмножества языка.

Из истории SQL:

Все реляционные СУБД поддерживают специальный язык SQL ( S tuctured Q uery L anguage), на котором записываются запросы. Фактически SQL состоит из двух языков — DML ( D ata M anipulation L anguage) и DDL ( D ata D eclaration L anguage).

История языка SQL началась в 1974 г. Первый прототип языка назывался SEQUEL (название образовано от S tructured E nglish Que ry L anguage). Впоследствии переработанная версия SEQUEL получила название SQL. Первый стандарт языка был принят в 1987 г.

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

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

SQL-DDL (Data Definition Language) - язык определения структур и ограничений целостности баз данных. Сюда относятся команды создания и удаления баз данных; создания, изменения и удаления таблиц; управления пользователями и т.д.
SQL-DML (Data Manipulation Language) - язык манипулирования данными: добавление, изменение, удаление и извлечение данных, управления транзакциями