Концепция реляционных баз данных. Основы теории реляционных баз данных

Коротко о важном.

Нормализация БД

Первая нормальная форма (1НФ)

отсутствуют повторяющиеся группы данных
гарантируется элементарности(atomicity) данных (все данные являются автономными и независимыми).

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

Вторая нормальная форма (2НФ)

таблица удовлетворяет условиям 1НФ
каждый столбец зависит от всего ключа, а не от его части.

Третья нормальная форма (3НФ)

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

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

Нормальная форма Бойса-Кодда(Boyce-Codd)

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

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

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

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

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

Шестая нормальная форма (нормальная форма доменного ключа)

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

Отношения.

Однажды я услышал от женщин, что мужчины
немедленно стараются покинуть помещение, в котором
прозвучало слово "отношения". <...> ключом к успеху
отношений является осведомленность каждого о своей роли
в данном отношении, а также о правилах и ограничениях,
налагаемых данным отношением.
(С)Robert Viera, “Professional SQL Server 2000 Programming”

Типы отношений

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

Объединения

INNER JOIN

Исключающее объединение (exclusive join). В результат выборки попадают только те записи таблиц, у которых есть соответствия в парной таблице по заданному условию.

LEFT|RIGHT JOIN

Включающее объединение (inclusive join). В результат выборки попадают записи из таблицы, стоящей слева/справа от JOIN соответственно. При этом данные из недостающей «парной» записи будут заполнены NULL .
FROM left_table LEFT JOIN right_table – включены все записи из левой таблицы left_table
FROM left_table RIGHT JOIN right_table – включены все записи из правой таблицы right_table

FULL JOIN

Включающее объединение (inclusive join). В результат выборки попадают не только записи, которые имеют соответствие в другой таблице, но и записи из обоих таблиц, для которых в соответствие в другой таблице не найдено. При этом данные из недостающей «парной» записи будут заполнены NULL.

CROSS JOIN

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

Принципы упорядочивания нескольких JOIN ’ов

В случае, если необходимо произвести объединение нескольких таблиц, нужно помнить о двух принципах:

Все объединения левее JOIN воспринимаются как одиночная таблица для включения или исключения из запроса.
Все объединения ПРАВЕЕ JOIN ТАКЖЕ воспринимаются как одиночная таблица для включения или исключения из запроса.

Следствием из этих принципов является следующая рекомендация для формирования сложных объединений:

Везде, где только можно, следует использовать INNER JOIN.

Если возникает необходимость использования OUTER JOIN – их нужно ставить последними, а в начале объединения размещаются INNER JOIN.

P.S. Все вышеизложенное является общими "постулатами" теории реляционных баз данных, не привязанными к особенностям определенных СУБД.

МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ

ФГБОУ ВПО КУРГАНСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ

Кафедра алгебры, геометрии и методики преподавания математики

КУРСОВАЯ РАБОТА

Дисциплина Программное обеспечение на ЭВМ

Теория реляционных баз данных

Студент группы 5940 С

Специальность Математика

Фёдорова Е. А.

Руководитель

Ст. преподаватель: Тетюшева С.Г.

Курган 2013

Введение

Глава 1. Теория реляционных баз данных

1 Реляционные базы данных

2 Понятие таблицы (отношения), поля, записи, домена, ключа (первичного, составного первичного и внешнего)

3 Имена и типы полей

4 Свойства полей в зависимости от типа данных полей

5 Основные требования к реляционной таблице

6 Метаданные

Глава 2. Таблицы. Индексы

1 Понятие главной и дочерней таблиц

2 Виды отношений между таблицами

3 Понятие ссылочной целостности

5 Сортировка записей

Заключение

Введение

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

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

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

Данная тема направлена на формирование представления о базах данных (БД), возможностях систем управления базами данных (СУБД) и их использовании.

Глава 1. Теория реляционных баз данных

.1 Реляционные базы данных

Информация в базах данных может быть организована по разному. Чаще всего используется табличный способ.

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

В чем же их преимущество?

Главное достоинство таблиц - в их понятности. С табличной информацией мы имеем дело практически каждый день. Загляните, например в свой дневник: расписание занятий там представлено в виде таблицы, ведомость с оценками за четверти имеет табличный вид. Когда мы приходим на вокзал, смотрим расписание электричек. Какой вид оно имеет? Это таблица! А еще есть таблица футбольного чемпионата. И журнал учителя, куда он ставит вам оценки - тоже таблица.

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

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

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

Каждое поле таблицы имеет имя. Например, в таблице «Игрушки» имена полей такие: НАЗВАНИЕ, МАТЕРИАЛ, ЦВЕТ, КОЛИЧЕСТВО.

Одна запись содержит информацию об одном объекте той реальной системы, модель которой представлена в таблице.

Например, одна запись о каком либо объекте - это информация об одной игрушке.

1.2 Понятие таблицы (отношения), поля, записи, домена, ключа (первичного, составного первичного и внешнего)

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

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

Домен имеет уникальное имя (в пределах базы данных).

Домен определен на некотором простом типе данных или на другом домене.

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

Домен несет определенную смысловую нагрузку.

Например, домен , имеющий смысл "возраст сотрудника" можно описать как следующее подмножество множества натуральных чисел:

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

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

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

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

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

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

Внешний ключ (foreign key) - ключевой элемент подчиненной (внешней, дочерней) таблицы, значение которого совпадает со значением первичного ключа главной (родительской) таблиц.

.3 Имена и типы полей

Каждое поле в таблице должно иметь уникальное имя, удовлетворяющее соглашениям об именах объектов в Access. Оно является комбинацией из букв, цифр, пробелов и специальных символов, за исключением точки (.), восклицательного знака ("), надстрочного знака (") и квадратных скобок (). Имя не может начинаться с пробела и содержать управляющие символы с кодами ASCII от 00 до 31. Максимальная длина имени - 64 символа.

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

Текстовый - тип данных по умолчанию. Текст или цифры, не участвующие в расчетах. Число символов в поле не должно превышать 255. Максимальное число символов, которое можно ввести в поле, задается в свойстве Размер поля . Пустые символы в неиспользуемой части поля не сохраняются.

Поле MEMO Длительный текст, например, некоторое описание или примечание. Максимальная длина - 65 535 символов.

Числовой . Числовые данные, используемые в математических вычислениях. Конкретные варианты числового типа и их длина задаются в свойстве Размер поля . Поле может иметь размер 1, 2, 4 или 8 байт (16 байт- только если для свойства Размер поля задано значение Код репликации ). Для проведения денежных расчетов определен другой тип данных - Денежный

Денежный . Денежные значения и числовые данные, используемые в расчетах, проводящихся с точностью до 15 знаков в целой и до 4 знаков - в дробной части. Длина поля 8 байт. При обработке числовых значений из денежных полей выполняются вычисления с фиксированной точкой (более быстрые, чем вычисления для полей с плавающей точкой). Кроме того, при вычислениях предотвращается округление. Учитывая эти обстоятельства, применительно к полям, в которых планируется хранить числовые значения с указанной точностью, рекомендуется использовать денежный тип данных.

Дата/время . Значения даты или времени, относящиеся к годам с 100 по 9999 включительно Длина поля 8 байт

Логический . Логические данные, которые могут иметь одно из двух возможных значений: Да/Нет, Истина/Ложь, Вкл./Выкл. Длина поля 1 бит.

Поле объекта OLE . Объект (например, электронная таблица Microsoft Excel, документ Microsoft Word, рисунок, звукозаписи или другие данные и двоичном формате), связанный или внедренный и таблицу Access. Длина поля - не более 1 Гбайт (ограничивается объемом диска).

Гиперссылка . Адрес гиперссылки, включающий путь к файлу на жестком диске в локальной сети (в формате UNC) или адрес страницы в Internet или intranet (URL). Кроме того, адрес может включать текст, выводимый в поле или в элементе управления, дополнительный адрес - расположение внутри файла или страницы, подсказку - текст, отображаемый в виде всплывающей подсказки. Если щелкнуть мышью на поле гиперссылки, Access выполнит переход на соответствующий объект, документ, Web-страницу или другое место назначения. Длина каждой из частей гиперссылки - не более 2048 знаков. Для полей типа OLE, MEMO и Гиперссылка не допускается сортировка и индексирование.

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

1.4 Свойства полей в зависимости от типа данных полей

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

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

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

Формат поля - определяет способ форматирования данных в ячейках, принадлежащих полю.

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

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

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

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

Сообщение об ошибке - текстовое сообщение, которое выдается автоматически при попытке ввода в поле ошибочных данных.

Обязательное поле - свойство, определяющее обязательность заполнения данного поля при наполнении базы.

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

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

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

Таблицы баз данных, как правило, допускают работу с гораздо большим количеством разных типов данных. Так, например, базы данных Microsoft Access работают со следующими типами данных.

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

· Числовой - тип данных для хранения действительных чисел.

· Поле Мемо - специальный тип данных для хранения больших объемов текста (до 65 535 символов). Физически текст не хранится в поле. Он храниться в другом месте базы данных, а в поле храниться указатель на него, но для пользователя такое разделение заметно не всегда.

· Дата/время - тип данных для хранения календарных дат и текущего времени.

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

· Счетчик - специальный тип данных для уникальных (не повторяющихся в поле) натуральных чисел с автоматическим наращиванием. Естественное использование - для порядковой нумерации записей.

· Логический - тип для хранения логических данных (могут принимать только два значения, например Да или Нет).

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

.5 Основные требования к реляционной таблице

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

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

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

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

· При выполнении операций над данными не должно возникать трудностей.

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

· Отношение представляется в виде полоски, содержащей имена всех атрибутов. Имя отношения пишется над ней.

· Первичный ключ отношения должен быть выделен жирной рамкой.

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

1.6 Метаданные

Классификация и структура метаданных

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

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

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

Метаданные состоят из элементов, объединенных в наборы. Широко известным примером набора элементов метаданных является т.н. Дублинское ядро (Dublin Core, DC). Такие наборы разрабатываются с различными целями (например, для описания различных информационных объектов) различными организациями, которые предпринимают в случае целесообразности усилия по распространению и стандартизации своих разработок. В том случае, если набор элементов метаданных рассматривается и принимается соответствующей уполномоченной организацией (например, International Standart Organisation, ISO), он становится официальным стандартом метаданных.

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

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

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

обеспечении гибких и разнообразных механизмов отбора в соответствии с требованиями пользователя (поисковым запросом);

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

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

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

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

Глава 2. Таблицы. Индексы

.1 Понятие главной и дочерней таблиц

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

Главная таблица {родительская таблица или master ) - это таблица, в которой содержатся основные данные.

Подчиненная таблица {дочерняя таблица или detail ) - таблица, значения в полях которой зависят от значений главной таблицы.

Главная таблица может иметь несколько подчиненных таблиц.

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

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

Само название связи между таблицами реляционной базы данных формируют по типу таблиц:

· главный -подчиненный,

· родительский -дочерний или master-detail.

2.2 Виды отношений между таблицами

Существует три типа связей между таблицами.

Связь "один-ко-многим"

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

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

Связь "многие-ко-многим"

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

Связь "один-к-одному"

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

.3 Понятие ссылочной целостности

реляционная база таблица индекс

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

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

«[Ссылочная целостность - это] свойство, обеспечиваемое реляционными системами управления базами данных (РСУБД), которое предотвращает ввод несогласованных данных пользователями или приложениями. В большинстве РСУБД имеются различные правила ссылочной целостности, которые можно применить при создании связи между двумя таблицами.»

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

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

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

Убыстрение разработки. Ссылочная целостность объявляется. Это гораздо продуктивнее (на один или два порядка), чем написание специального программного кода.

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

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

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

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

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

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

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

Для ускорения доступа к данным применяется несколько типов индексов.

Основные из них перечислены ниже.

Первичный индекс.

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

Индекс кластеризации.

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

Вторичный индекс.

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

Файл может иметь не больше одного первичного индекса или одного индекса кластеризации, но дополнительно к ним может иметь несколько вторичных индексов. Индекс может быть разреженным (sparse) или плотным (dense). Разреженный индекс содержит индексные записи только для некоторых значений ключа поиска в данном файле, а плотный индекс имеет индексные записи для всех значений ключа поиска в данном файле. Ключ поиска для индекса может состоять из нескольких полей.

Индексно-последовательные файлы

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

первичная область хранения;

отдельный индекс или несколько индексов;

область переполнения.

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

Вторичные индексы

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

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

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

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

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

Многоуровневые индексы

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

2.5 Сортировка записей

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

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

При сортировке по возрастанию данные различных типов выстраиваются в следующем порядке:

числа - от наименьшего отрицательного до наибольшего положительного числа;

текст - в алфавитном порядке (числа, знаки, латинский алфавит, русский алфавит);

дата и время - в хронологическом порядке.

При сортировке по убыванию данные выстраиваются в порядке, обратном вышеуказанному.

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

Например, после сортировки по возрастанию по текстовому полю "Фамилия" база данных "Записная книжка" примет вид, показанный в табл. 1.

Таблица 1. Результат сортировки базы данных "Записная книжка"

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

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

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

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

Заключение

В заключении необходимо сделать основные выводы по работе.

Реляционная модель данных состоит из трех частей:

Структурной части.

Целостной части.

Манипуляционной части.

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

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

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

Отношение обладает следующими свойствами:

В отношении нет одинаковых кортежей.

Кортежи не упорядочены (сверху вниз).

Атрибуты не упорядочены (слева направо).

Все значения атрибутов атомарны.

Реляционной базой данных называется набор отношений.

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

Отношение находится в Первой Нормальной Форме (1НФ),если оно содержит только скалярные (атомарные) значения.

Современные СУБД допускают использование null-значений, т.к. данные часто бывают неполными или неизвестными.

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

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

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

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

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

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

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

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

Целостность сущностей

Целостность внешних ключей

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

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

Для поддержания ссылочной целостности обычно используются две основные стратегии:(ОГРАНИЧИТЬ) - не разрешать выполнение операции, приводящей к нарушению ссылочной целостности.(КАСКАДИРОВАТЬ) - разрешить выполнение требуемой операции, но внести каскадные изменения в другие отношения так, чтобы не допустить нарушения ссылочной целостности.

Дополнительными стратегиями поддержания ссылочной целостности являются:NULL (УСТАНОВИТЬ В NULL) - все некорректные значения внешних ключей изменять на null-значения.DEFAULT (УСТАНОВИТЬ ПО УМОЛЧАНИЮ) - все некорректные значения внешних ключей изменять на некоторое значение, принятое по умолчанию.

В реальных СУБД можно также отказаться от использования какой-либо стратегии поддержания ссылочной целостности:(ИГНОРИРОВАТЬ) - выполнять операции, не обращая внимания на нарушения ссылочной целостности.

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

Список использованной литературы

1. «Экономическая информатика» / Под. ред. П.В. Конюховского и Д.Н. Колесова, СПб: Питер, 2000, 560 с.

Каймин В.А., «Информатика», учеб.4-е изд. М.:, 2003 - 285 с.

. «Информатика», базовый курс, 2-е издание / Под. ред. С.В. Симоновича, СПб.: 2003, 640 с.

. «Информатика» учеб. 3-е перераб. изд. / Под. ред. проф. Н.В. Макаровой, М.: 2000, 768 с.

Http://www.jetinfo.ru/.

Информатика. Базовый курс /Симонович С.В. и др. - СПб: Издательство «Питер», 2000

Модель данных - совокупность структур данных и операций по их обработке. С помощью модели данных можно наглядно представить структуру объектов и установленные между ними связи. Для терминологии моделей данных характерны понятия «элемент данных» и «правила связывания». Элемент данных описывает любой набор данных, а правила связывания определяют алгоритмы взаимосвязи элементов данных. К настоящему времени разработано множество различных моделей данных, но на практике используется три основных. Выделяют иерархическую, сетевую и реляционную модели данных. Соответственно говорят об иерархических, сетевых и реляционных СУБД.

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

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

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

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

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

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

Реляционная модель данных

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

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

Атрибут (или данное) - это некоторый показатель, который характеризует некий объект и принимает для конкретного экземпляра объекта некоторое числовое, текстовое или иное значение. Информационная система оперирует наборами объектов, спроектированными применительно к данной предметной области, используя при этом конкретные значения атрибутов (данных) тех или иных объектах. Например, возьмем в качестве набора объектов классы в школе. Число учеников в классе - это данное, которое принимает числовое значение (у одного класса 28, у другого- 32). Название класса - это данное, принимающее текстовое значение (у одного - 10А, у другого - 9Б и т. д.).

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

Основоположником теории реляционных баз данных считается сотрудник фирмы IBM доктор Э. Кодд, опубликовавший 6 (июня 1970 г. статью A Relational Model of Data for Large-Shared Data Banks (Реляционная модель данных для больших коллективных банков данных). В этой статье впервые был использован термин «реляционная модель данных. Теория реляционных баз данных, разработанная в 70-х годах в США доктором Э. Коддом, имеет под собой мощную математическую основу, описывающую правила эффективной организации данных. Разработанная Э. Коддом теоретическая база стала основой для разработки теории проектирования баз данных.

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

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

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

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

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

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

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

Так как строки в таблице не упорядочены, невозможно выбрать строку по ее позиции - среди них не существует «первой», «второй», «последней». Любая таблица имеет один или несколько столбцов, значения в которых однозначно идентифицируют каждую ее строку. Такой столбец (или комбинация столбцов) называется первичным ключом (primary key) . Часто вводят искусственное поле, предназначенное для нумерации записей в таблице. Таким полем, например, может быть его порядковый, который сможет обеспечить уникальность каждой записи в таблице. Ключ должен обладать следующими свойствами.

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

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

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

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

Взаимосвязь таблиц является важнейшим элементом реляционной модели данных. Она поддерживается внешними ключами (foreign key).

При описании модели реляционной базы данных для одного и того же понятия часто употребляют различные термины, что зависит от уровня описания (теория или практика) и системы (Access, SQL Server, dBase). В табл. 2.3 приведена сводная информация об используемых терминах.

Таблица 2.3. Терминология баз данных

Теория БД____________ Реляционные БД_________ SQL Server __________

Отношение (Relation) Таблица (Table) Таблица (Table)

Кортеж (Tuple) Запись (Record) Строка (Row)

Атрибут (Attribute)Поле (Field)_______________ Столбец или колонка (Column)

Реляционные базы данных

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

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

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

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

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

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

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

1.2 Теория реляционных баз данных

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

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

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

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

Основоположником теории реляционных баз данных считается сотрудник фирмы IBM доктор Э. Кодд, опубликовавший 6 (июня 1970 г. статью A Relational Model of Data for Large-Shared Data Banks (Реляционная модель данных для больших коллективных банков данных). В этой статье впервые был использован термин "реляционная модель данных. Теория реляционных баз данных, разработанная в 70-х годах в США доктором Э. Коддом, имеет под собой мощную математическую основу, описывающую правила эффективной организации данных. Разработанная Э. Коддом теоретическая база стала основой для разработки теории проектирования баз данных.

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

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

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

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

Так как строки в таблице не упорядочены, невозможно выбрать строку по ее позиции - среди них не существует "первой", "второй", "последней". Любая таблица имеет один или несколько столбцов, значения в которых однозначно идентифицируют каждую ее строку. Такой столбец (или комбинация столбцов) называется первичным ключом (primary key). Часто вводят искусственное поле, предназначенное для нумерации записей в таблице. Таким полем, например, может быть его порядковый, который сможет обеспечить уникальность каждой записи в таблице. Ключ должен обладать следующими свойствами :

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

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

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

Взаимосвязь таблиц является важнейшим элементом реляционной модели данных. Она поддерживается внешними ключами (foreign key).

Таблицы невозможно хранить и обрабатывать, если в базе данных отсутствуют "данные о данных", например, описатели таблиц, столбцов и т.д. Их называют обычно метаданными. Метаданные также представлены в табличной форме и хранятся в словаре данных (data dictionary).

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

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

Для того, чтобы гарантировать корректность и взаимную непротиворечивость данных, на базу данных накладываются некоторые ограничения, которые называют ограничениями целостности (data integrity constraints).

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

Категорная целостность;

Целостность на уровне ссылок;

Функциональные зависимости.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Согласно трактовке Дейта, реляционная модель состоит из трех частей, описывающих разные аспекты реляционного подхода: структурной части, манипуляционной части и целостной части (К. Дейт, 2000).

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

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

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

1. идентификация функциональных зависимостей;

2. трудоемкость идентификации всех функциональных зависимостей;

3. зависимость конечного результата проектирования от опыта и субъективного взгляда проектировщика, а не от формальной методики проектирования;

4. проблема идентификации сущностей и атрибутов сущностей.

1.3 Методы проектирования БД ИС

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

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

Соответствие создаваемой информационной системы целям и задачам предприятия, а также предъявляемым к ней требованиям по автоматизации желаемых процессов и гарантирование создания системы с заданными параметрами в течение заданного времени в рамках оговоренного заранее бюджета;

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

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

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

1. Заданной последовательности выполнения технологических операций проектирования;

2. Критериев и правил, используемых для оценки результатов выполнения технологических операций;

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

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

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

Поддерживать полный жизненный цикл информационной системы;

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

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

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

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

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

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

Под методологией быстрой разработки приложений обычно понимается процесс разработки информационных систем, основанный на трех основных элементах:

На небольшой команде программистов (обычно от 2 до 10 человек);

На тщательно проработанном производственном графике работ, рассчитанном на сравнительно короткий срок разработки;

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

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

CASE-средства (от Computer Aided Software/System Engineering) - позволяют проектировать любые системы на компьютере. Необходимый элемент системного и структурно-функционального анализа, CASE средства позволяют моделировать бизнес-процессы, базы данных, компоненты программного обеспечения, деятельность и структуру организаций

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Принцип абстрагирования - заключается в выделении существенных аспектов системы и отвлечения от несущественных;

Принцип формализации - заключается в необходимости строгого методического подхода к решению проблемы;

Принцип непротиворечивости - заключается в обоснованности и согласованности элементов;

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

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

На стадии проектирования ИС модели расширяются, уточняются и дополняются диаграммами, отражающими структуру программного обеспечения: архитектуру ПО, структурные схемы программ и диаграммы экранных форм .

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

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

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

Наиболее известным представителем класса семантических моделей является модель "сущность-связь" (ER-модель).Методология построения баз данных базируется на теоретических основах их проектирования. Для понимания концепции методологии приведем основные ее идеи в виде двух последовательно реализуемых на практике этапов:

1-й этап - обследование всех функциональных подразделений фирмы с целью:

Понять специфику и структуру ее деятельности;

Построить схему информационных потоков:

Проанализировать существующую систему;

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

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

Модель Сущность-Связь (ER-модель) (англ. entity-relationship model (ERM) или англ. entity-relationship diagram (ERD)) - модель данных, позволяющая описывать концептуальные схемы. Предоставляет собой графическую нотацию, основанную на блоках и соединяющих их линиях, с помощью которых можно описывать объекты и отношения между ними какой-либо другой модели данных. В этом смысле ER-модель является мета-моделью данных, то есть средством описания моделей данных .

Модель "сущность-связь" была предложена в 1976 году Питером Пин-Шен Ченом (англ. Peter Pin-Shen Chen) – американским профессором компьютерных наук в университете штата Луизиана. Фактически Чен не изобретал модель, он взял идеи из более ранних работ таких практиков, как А. Браун и других. Однако Питер Чен сделал больше, чем кто бы то ни было до него для формализации и популяризации ER-модели, а также для её внедрения в научную литературу.

В связи с наглядностью представления концептуальных схем баз данных ER-модели получили широкое распространение в системах CASE, поддерживающих автоматизированное проектирование реляционных баз данных. Среди множества нотаций ER-моделей одна из наиболее развитых – Unified Modeling Language (Унифицированный язык моделирования), сокр. UML – применяется в системе CASE фирмы ORACLE. Нотация UML так же используется и/или поддерживается: Borland Software Corporation, Университетом Бремена, Университетом Кента, Университетом.

Основные преимущества ER-моделей :

Наглядность;

Модели позволяют проектировать базы данных с большим количеством объектов и атрибутов;

ER-модели реализованы во многих системах автоматизированного проектирования баз данных (например, ERWin, Oracle Designer).

Основные элементы ER-моделей:

Объекты (сущности);

Атрибуты объектов;

Связи между объектами.

Сущность - любой объект предметной области, имеющий атрибуты.

Связь между сущностями характеризуется:

Типом связи (1:1, 1:М, М:М);

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

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

Основные элементы данной модели:

1. Описание объектов предметной области и связей между ними.

2. Описание информационных потребностей пользователей (описание основных запросов к БД).

3. Описание документооборота. Описание документов, используемых как исходные данные для БД и документов, составляемых на основе БД.

4. Описание алгоритмических зависимостей между данными.

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

Логическое (даталогическое) проектирование – отображение инфологической модели на модель данных, используемую в конкретной СУБД, например на реляционную модель данных. Для реляционных СУБД даталогическая модель – набор таблиц, обычно с указанием ключевых полей, связей между таблицами. Если инфологическая модель построена в виде ER-диаграмм (или других формализованных средств), то даталогическое проектирование представляет собой построение таблиц по определённым формализованным правилам, а также нормализацию этих таблиц. Этот этап может быть в значительной степени автоматизирован .

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

На этапе инфологического проектирования в ходе сбора информации о предметной области требуется выяснить:

1. основные объекты предметной области (объекты, о которых должна храниться информация в БД);

2. атрибуты объектов;

3. связи между объектами;

4. основные запросы к БД.

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

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

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

Выводы по Разделу 1

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

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

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

Выбрать концептуальную модель, с помощью которой будет построена концептуальная схема;

Построить точное описание семантических ограничений, поддерживаемых выбранной СУБД;

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

Определить, что такое хорошая схема и описать методику ее построения.

Информация о работе «Проектирование, разработка и внедрение БД ИС в экономическую деятельность предприятия (на примере ГП "Алушталифт")»

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

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

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

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

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

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

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

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

Подобная «развязка» данных задач позволила:

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

обеспечить увеличение объема хранимой информации на внешних запоминающих устройствах.

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

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

Предоставить пользователю удобный интерфейс для формирования:

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

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

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

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

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

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

Комментарий 2 . Использование языка манипулирования данными, базирующегося на математически обоснованном аппарате, обеспечивает корректность работы с данными или, по-другому, предсказуемость.

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

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

системы поддержки целостности данных, обеспечивающей непротиворечивое состояние хранимых данных;

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

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

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

В процессе научных исследований, посвященных тому, как именно должна быть устроена СУБД, предлагались различные способы реализации. Самым жизнеспособным из них оказалась предложенная американским комитетом по стандартизации ANSI (American National Standards Institute) трехуровневая система организации БД, изображенная на рис. 3:

Рис. 3. Трехуровневая модель базы данных

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

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

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

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

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