что делает жизненный цикл бд
Что делает жизненный цикл бд
ПРОЕКТИРОВАНИЕ БАЗЫ ДАННЫХ
Разработчик: доц. Оскерко В.С.
2. Этапы жизненного цикла базы данных
3. Модель «сущность–связь»
2. Этапы жизненного цикла базы данных
Жизненный цикл базы данных (ЖЦБД) – это процесс проектирования, реализации и поддержки базы данных. ЖЦБД состоит из семи этапов:
1) предварительное планирование;
2) проверка осуществимости;
3) определение требований;
4) концептуальное проектирование;
5) логическое проектирование;
6) физическое проектирование;
7) оценка работы и поддержка базы данных.
Опишем главные задачи каждого этапа.
В развитии любого экономического объекта наступает момент осознания того, что для достижения дальнейших успехов в развитии необходимо данные, находящиеся в личном пользовании работников, интегрировать для совместного использования в базе данных и воспринимать их как корпоративный ресурс.
1. Предварительное планирование базы данных – важный этап в процессе перехода от разрозненных данных к интегрированным. На этом этапе собирается информация об используемых и находящихся в процессе разработки прикладных программах и файлах, связанных с ними. Она помогает установить связи между текущими приложениями и то, как используется их информация. Кроме того, позволяет определить будущие требования к базе данных. Информация документируется в виде обобщенной концептуальной модели данных.
2. Проверка осуществимости предполагает подготовку отчетов по трем вопросам:
1) есть ли технология – необходимое оборудование и программное обеспечение – для реализации запланированной базы данных (технологическая осуществимость);
2) имеются ли персонал, средства и эксперты для успешного осуществления плана создания базы данных (операционная осуществимость);
3) окупится ли запланированная база данных (экономическая эффективность).
3. Определение требований. На этом этапе определяются:
· информационные потребности различных структурных подразделений и их руководителей;
· требования к оборудованию;
· требования к программному обеспечению.
4. Концептуальное проектирование. На этом этапе создаются подробные модели пользовательских представлений данных предметной области. Затем они интегрируются в концептуальную модель, которая фиксирует все элементы корпоративных данных, подлежащих загрузке в базу данных. Эту модель еще называют концептуальной схемой базы данных.
5. Логическое проектирование. На этом этапе осуществляется выбор типа модели данных. Концептуальная модель отображается в логическую модель, основанную уже на структурах, характерных для выбранной модели.
6. Физическое проектирование. На этом этапе логическая модель расширяется характеристиками, необходимыми для определения способов физического хранения базы данных, типа устройств для хранения, методов доступа к данным базы, требуемого объема памяти, правил сопровождения базы данных и др.
7. Оценка и поддержка базы данных. Оценка включает опрос пользователей на предмет выяснения, какие их информационные потребности остались неучтенными. При необходимости в спроектированную базу данных вносятся изменения. Пользователи обучаются работе с базой данных. По мере расширения и изменения потребностей бизнеса поддержка базы данных обеспечивается путем внесения изменений, добавления новых данных, разработки новых прикладных программ, работающих с базой данных.
Жизненный цикл БД
Вы будете перенаправлены на Автор24
Базы данных (БД) являются основным компонентом автоматизированной информационной системы (АИС), поэтому их жизненный цикл неразрывно связан с жизненным циклом АИС и жизненным циклом ее программного обеспечения.
Жизненный цикл АИС – период времени, начало которого определяется моментом принятия решений о необходимости создания АИС и заканчивается завершением её полной эксплуатации.
Этапы жизненного цикла БД
Жизненный цикл БД проходит несколько этапов:
Планирование разработки БД
Этап подготовительной работы, который позволяет максимально эффективно реализовать этапы жизненного цикла БД.
Определение требований к системе
Готовые работы на аналогичную тему
Сбор и анализ требований пользователей
К задачам данного этапа относится сбор и анализ информации, необходимой для проектирования БД, который может производится с помощью проведения опроса специалистов предприятия, наблюдения за деятельностью предприятия, изучения входных и выходных документов, за счет привлечения опыта проектирования подобных систем, анкетирования.
На данном этапе формируется и утверждается минимум документов для проектирования программной системы, среди которых название задания, организационная структура предприятия, структура входящей и исходящей документации, функции автоматизации, описание предметной области, требования к программному и техническому обеспечению АИС и т.п.
Этап проектирования (моделирования) БД
Создается проект БД, отображается словесное и естественное описание предметной области в схеме внутренней модели БД.
БД проектируется с целью:
Выбор целевой СУБД
Выбор СУБД осуществляться на любом этапе разработки БД при условии наличия всей необходимой информации о производительности системы, стратегии реализации ограничений целостности БД, уровне защищенности данных, архитектуре вычислительной среды, необходимости параллельной обработки данных.
Разработка приложений
В жизненном цикле БД этап проектирования прикладных программ и интерфейсов пользователей для работы с БД должен выполняться параллельно с проектированием БД для обмена информацией, перекрестных проверок между проектируемыми данными и выявленными функциями приложения, которое разрабатывается.
Создание БД
Физическая реализация БД в среде СУБД состоит из:
Конвертирование и загрузка данных из старой системы
Перенос существующих данных из старой системы в разработанную БД и изменение существующих приложений для организации совместной работы с новой БД в случае, когда разработанная БД заменяет или содержит информацию старой БД.
Тестирование БД
БД проверяется на корректность выполнения функций, которые объявлены в АИС. На этом этапе важно правильно подобрать данные для успешного тестирования. При исправлении всех недочетов (если такие были выявлены) БД передается на эксплуатацию.
Эксплуатация и сопровождение
Работа системы сопровождается наблюдением и поддержкой нормального функционирования:
Жизненный цикл базы данных
В наше время немыслимо представить обычную жизнь без огромных массивов информации, которые хранят данные научных исследований, личную информацию миллионов пользователей интернет пространства, корпоративные и прочие данные. С каждым годом количество информации растет с небывалой скоростью. Для того, чтобы не запутаться в огромном количестве информации и эффективно работать с ней, необходима база данных.
База данных это структурированный массив данных, необходимый для долговременного хранения и постоянного использования [1].
Доступность баз данных позволила расширить их применение от компьютеров и сложнейших технических систем до простейшей бытовой техники.
Базы данных почти всегда рассматривают вместе с СУБД и часто с информационными системами (ИС) [2].
СУБД (система управления базами данных) – совокупность программных и лингвистических средств, обеспечивающих управление созданием, ведением и эксплуатацией БД. Под ведением понимают поддержку базы данных в работоспособном состоянии. Информационной называется система, предназначенная для хранения, поиска и выборки данных по запросам пользователей [3].
1.ЖИЗНЕННЫЙ ЦИКЛ БАЗЫ ДАННЫХ
1.1 Основные этапы жизненного цикла БД
Жизненным циклом базы данных называют период от момента появления идеи создания БД до момента завершения его поддержки разработчиком или организацией, выполнявшей сопровождение.
На рисунке 1 представлены основные этапы жизненного цикла БД. Конечно, для каждого задания найдется особенность, которую необходимо будет учитывать, но на этой схеме изображены основные элементы, которые должны быть проделаны в любом проекте [4].
Рисунок 1 –Жизненный цикл проекта БД
1.2 Этап планирования разработки БД
На этапе планирования разработки БД необходимо ответить на главные вопросы:
Какой объем работы придется выполнить?
Какие средства потребуются для выполнения работ?
Сколько времени потребуется на разработку и реализацию проекта?
Сколько будет стоить весь проект?
Конечно, все вычисления будут приблизительными, но этого уже будет достаточно для дальнейших расчетов. Все показатели (объем работ, необходимые силы и средства, время и стоимость) должны в равной степени устраивать как проектировщика, так и заказчика, причем каждая из сторон должна понимать, что это всего лишь предварительные расчеты [5].
1.3 Этап определения и анализа требований к системе
Этап определения и анализа требований к системе – едва ли не самый значимый во всем жизненном цикле БД. На этом этапе должна быть собрана вся информация, необходимая для проектирования БД. Это очень важно, поэтому повторюсь: в результате выполнения этапа в распоряжении проектировщика БД должна оказаться вся информация о компании и протекающих в ней бизнес-процессах. Если будет что-то пропущено, то придется расплачиваться за некорректно отработанный этап – от бесконечных мелких переделок до полного свертывания работ.
Вне зависимости от масштабов БД необходимо получить следующую информацию:
цели и задачи компании;
организационно-штатная структура компании;
модель бизнес-процесса компании.
выделение границ и возможностей проекта;
выявление перспектив дальнейшего совершенствования БД.
Цели и задачи компании необходимы для формирования понимания направления ее основной деятельности. Зная это, можно, пусть даже пока на упрощенном уровне, предсказать, что именно захочет получить от будущей БД заказчик.
Знания организационной структуры предприятия просто необходимы при создании БД. Кому-то нужны отчеты, кому-то аналитика, кто-то хочет владеть всеми данными, кому-то достаточно знать лишь детали.
Третий пункт списка самый сложный во всем этапе определения и анализа требований. Причина тому – слабые знания в той предметной области, для обслуживания которой предназначена будущая БД. Для решения этой проблемы необходимо вовлечь в процесс проектирования максимальное число специалистов компании.
Необходимо получить всю необходимую информацию путем:
опроса основных специалистов компании;
анализа обязанностей сотрудников;
изучения документов в отделах и службах компании;
наблюдения за процессом функционирования документооборота;
анкетирования сотрудников компании.
Завершением этапа определения и анализа требований к системе должен стать проект технического задания на разработку БД. Указанный проект согласовывается с заказчиком БД. В окончательное техническое задание проект превратится в середине этапа проектирования БД [6].
1.4 Этап проектирования БД
Данный этап разделяется на три фазы (рисунок 2):
Во время концептуального проектирования окончательно формируется замысел будущей базы данных, но без учета любых физических аспектов ее реализации. На этой ступени проектирования разработчика интересует создание общей модели, отражающей представления будущих пользователей БД об автоматизируемом участке компании (складе, бухгалтерии, отделе кадров, производственных цехах и т. п.). Вся необходимая для этого информация уже должна быть собрана на предыдущем этапе жизненного цикла БД.
Рисунок 2 –Фазы проектирования БД
Фаза логического проектирования предназначена для преобразования обобщенной концептуальной модели в завершенную логическую. Разработчик уточняет все требования, выявленные на концептуальной стадии проектирования, и стремится несколько упростить решение (при этом не снижая его функциональные возможности).
На логическом этапе осуществляются следующие действия:
уточняются ограничения на данные;
вводятся корпоративные ограничения;
определяется местоположение будущих таблиц.
Переход к следующей (физической) фазе проектирования БД производится после выбора целевой СУБД, именно она определяет особенности будущего программного продукта.
Физическое проектирование – это уточнение решения с учетом имеющихся в наличии разработчика технологий, возможности реализации и требуемой производительности. Только на заключительной фазе проектирования БД приходит реальная работа на компьютере. Во время физического проектирования задачей проектировщика становится перенос логической модели на платформу целевой СУБД.
1.5 Этап тестирования и отладки
Без тестирования нельзя гарантировать правильную работу созданного продукта, поэтому для каждого проекта необходимо разработать исчерпывающий план тестирования, распространяющийся на все основные функции БД и прикладного ПО.
Тестирование – это процесс выполнения программы с целью обнаружения ошибок.
демонстрацию соответствия функций БД по их назначению;
демонстрацию реализации требований к характеристикам БД.
Все выявленные во время тестирования ошибки должны быть локализованы и исправлены.
1.6 Этап реализации
На этапе реализации осуществляется выпуск окончательной версии программного продукта. Прежде чем проектировщик переходит к выпуску БД, необходимо убедиться в выполнении следующих условий:
база данных и пользовательские приложения обладают всеми указанными в техническом задании функциональными возможностями;
программное обеспечение успешно прошло тестирование, и все выявленные критические ошибки устранены;
заказчик и проектировщик приняли совместное решение о том, что реализация всех элементов БД в целом завершена.
На завершающей стадии этапа реализации необходимо подготовить материалы, необходимые для обучения и технической поддержки пользователей.
1.7 Этап эксплуатации и сопровождения
Эксплуатация и сопровождение – это заключительный этап жизненного цикла БД. В его начальной стадии осуществляется развертывание базы данных и прикладного ПО на сервере и клиентских станциях заказчика ПО. При необходимости администратор СУБД создает учетные записи пользователей базы данных. После этого проект полностью переходит под контроль заказчика [7].
Процесс проектирования и реализации жизнеспособной БД содержит серию этапов, включающих планирование разработки, определение и анализ требований к системе, проектирование БД, создание прикладного ПО, тестирование, реализацию, эксплуатацию и сопровождение. Каждый этап необходимо качественно выполнить, иначе снижается качество всей БД. При нахождении ошибок, необходимо сделать возврат к предыдущему или даже к начальному этапу проектирования для выполнения проекта в заданном объеме и с требуемым качеством.
СПИСОК ИСПОЛЬЗОВАННОЙ ЛИТЕРАТУРЫ
Осипов, Д. Л. Технологии проектирования баз данных / Д. Л. Осипов. — Москва: ДМК Пресс, 2019. — 498 с.
Новиков, Б. А. Основы технологий баз данных / Б. А. Новиков; под редакцией Е. В. Рогова. — Москва: ДМК Пресс, 2019. — 240 с.
Каминский, В. Н. Базы данных: учебное пособие / В. Н. Каминский. — Санкт-Петербург:»Военмех» им. Д.Ф. Устинова,2017. — 106с.
Осипов, Д. Л. Технологии проектирования баз данных / Д. Л. Осипов. — Москва: ДМК Пресс, 2019. — 498 с.
Что делает жизненный цикл бд
3. Жизненный цикл базы данных.
Процесс проектирования, реализации и поддержания системы базы данных называется жизненным циклом базы данных (ЖЦБД). Процедура создания системы называется жизненным циклом системы (ЖЦС).
Понимание и правильный подход к ЖЦБД очень важен и требует детального рассмотрения, так как в его основе лежит подход, ориентированный на данные. Элементы данных более стабильны, чем выполняемые функции системы. Создание правильной структуры данных требует сложного анализа классов единиц данных и отношений между ними. Если построить логичную схему базы данных, то в дальнейшем можно создать любое количество функциональных систем, использующих эту схему. Функционально-ориентированный подход можно применять лишь для создания временных систем, которые рассчитаны на недолгое время функционирования.
ЖЦБД состоит из следующих этапов:
1. Предварительное планирование – планирование БД, выполняемое в процессе разработки стратегического плана БД. В процессе планирования собирается следующая информация:
· какие прикладные программы используются, и какие функции они выполняют;
· какие файлы связаны с каждым из этих приложений;
· какие новые приложения и файлы находятся в процессе работы.
Данная информация помогает определить, как используется информация приложений, определить будущие требования к системе БД.
Информация этого этапа документируется в виде обобщенной модели данных.
2. Проверка осуществимости. Здесь определяется технологическая, операционная и экономическая осуществимость плана создания БД, т. е.:
· технологическая осуществимость – есть ли технология для реализации запланированной БД?
· операционная осуществимость – есть ли средства и эксперты, необходимые для успешного осуществления плана создания БД?
· экономическая целесообразность – можно ли определить выводы? Окупится ли запланированная система? Можно ли оценить издержки и выгоду?
3. Определение требований включает выбор целей БД, выяснение информационных требований к системе и требований к оборудованию и программному обеспечению. Таким образом, на данном этапе сбора данных и определения требований создаётся общая информационная модель, выражающаяся в следующих задачах:
· Определяются цели системы путём анализа информационных потребностей. Здесь также обязательно указывается, какую именно БД следует создавать (распределённую, целостную) и какие коммуникационные средства необходимы. Выходной документ – комментарий, описывающий цели системы.
· Определение пользовательских требований: документация в виде обобщённой информации (комментарии, отчёты, опросы, анкеты и т. д.); фиксация функций системы и определение прикладных систем, которые будут выполнять эти требования. Данные представляются в виде соответствующих документов.
· Определение общих требований к оборудованию и программному обеспечению, связанных с поддержанием желаемого уровня быстродействия. (Выяснение количества пользователей системы, числа входных сообщений в день, количество распечаток). Данная информация используется для выбора типов компьютеров и СУБД, объёма дисков, количества принтеров. Данные этого этапа излагаются в отчёте, содержащем примерные конфигурации оборудования и программного обеспечения.
· Разработка плана поэтапного создания системы, включающий выбор исходных приложений.
4. Концептуальное проектирование – создание концептуальной схемы БД. Спецификации разрабатываются в той степени, которая необходима для перехода к реализации.
Основным выходным документом является единая инфологическая модель (или схема БД на концептуальном уровне). При разработке данной модели используются информация и функции, которые должна выполнить система, определённые на этапе сбора и определения требований к системе. На данном этапе желательно также определить: 1) правила для данных; 2) правила для процессов; 3) правила для интерфейса.
5. Реализация – процесс превращения концептуальной модели в функциональную БД. Он включает в себя следующие этапы.
1) Выбор и приобретение необходимой СУБД.
2) Преобразование концептуальной (инфологической) модели БД в логическую и физическую модель данных:
· на основе инфологической модели данных строится схема данных для конкретной СУБД, при необходимости реализуется денормализация БД с целью ускорения обработки запросов во всех критичных по времени приложениях;
· определяются, какие прикладные процессы необходимо реализовать в схеме данных как хранимые процедуры;
· реализовать ограничения, предназначенные для обеспечения целостности данных и реализации правил для данных;
· спроектировать и сгенерировать триггеры для реализации всех централизованно определённых правил для данных и правил целостности данных, которые не могут быть заданы как ограничения;
· разработать стратегию индексирования и кластеризации; выполнить оценку размеров всех таблиц, кластеров и индексов;
· определить уровни доступа пользователей, разработать и внедрить правила обеспечения безопасности и аудита. Создать роли и синонимы для обеспечения многопользовательского доступа с согласованными уровнями полномочий доступа.
· разработать сетевую топологию БД и механизм бесшовного доступа к удалённым данным (реплицированная или распределённая БД).
3) Построение словаря данных, который определяет хранение определений структуры данных БД. Словарь данных также содержит информацию о полномочиях доступа, правилах защиты данных и контроля данных.
4) Заполнение базы данных.
5) Создание прикладных программ, контроль управления.
6) Обучение пользователей.
6. Оценка и усовершенствование схемы БД. Включает опрос пользователей с целью выяснения функциональных неучтенных потребностей. При необходимости вносятся изменения, добавление новых программ и элементов данных по мере изменения и расширения потребностей.
Таким образом, ЖЦБД включает в себя:
· Изучение предметной области и представление соответствующей документации (1-3).
· Построение инфологической модели (4).
· Оценка работы и поддержка БД (6).
4. Архитектура СУБД.
 |
Рис. Главные компоненты СУБД
Данные, метаданные — содержат не только данные, но и информацию о структуре данных ( метаданные). В реляционной СУБД метаданные включают в себя системные таблицы (отношения), имена отношений, имена атрибутов этих отношений и типы данных этих атрибутов.
Часто СУБД поддерживает индексы данных. Индекс — это структура данных, которая помогает быстро найти элементы данных при наличии части их значения (например, индекс, который находит кортежи конкретного отношения, имеющие заданное значение одного из атрибутов). Индексы — часть хранимых данных, а описания, указывающие, какие атрибуты имеют индексы — часть метаданных.
Менеджер памяти — получает требуемую информацию из места хранения данных и изменяет в нем информацию по требованию расположенных выше уровней системы.
В простых системах БД менеджером памяти может служить система файлов операционной системы. Однако для повышения эффективности, СУБД обычно осуществляет прямой контроль памяти. Менеджер памяти состоит из двух компонентов:
· Менеджер файлов контролирует расположение файлов на диске и получает блок или блоки, содержащие файлы, по запросу менеджера буфера (диск в общем случае делится на дисковые блоки — смежные области памяти, содержащие от 4000 до 16000 байт).
· Менеджер буфера управляет основной памятью. Он получает блоки данных с диска через менеджер файлов и выбирает страницу основной памяти для хранения конкретного блока. Он может временно сохранять дисковый блок в основной памяти, но возвращает его на диск, когда страница в чем разница» rel=dofollow»>страница основной памяти нужна для другого блока. Страницы также возвращаются на диск по требованию менеджера транзакций.
Процессор «запроса» — обрабатывает запросы и запрашивает изменения данных или метаданных. Он предлагает лучший способ выполнения необходимой операции и выдает соответствующие команды менеджеру памяти.
Процессор (менеджер) запросов превращает запрос или действие с БД, которые могут быть выполнены на очень высоком уровне (например, в виде запроса SQL ), в последовательность запросов на хранимые данные типа отдельных кортежей отношения или частей индекса на отношении. Часто самой трудной частью обработки запроса является его организация, т. е. выбор хорошего плана запроса или последовательности запросов к системе памяти, отвечающей на запрос.
Типичные СУБД позволяют пользователю сгруппировать несколько запросов и/или изменений в одной транзакции. Транзакция — это группа операций, которые необходимо выполнить последовательно, как одно целое.
· атомарность — выполнение либо всех транзакций, либо ни одной из них (например, изъятие денег из банкомата и внесение соответственного дебета в счет клиента должны быть единственной атомарной транзакцией, не допускается выполнение каждой из этих операций по отдельности);
· непротиворечивость — состояние, при котором данные соответствуют всем возможным ожиданиям (например, условие непротиворечивости для БД авиационных линий состоит в том, что ни одно из мест в самолете не бронируется для двух пассажиров);
· изоляция — при параллельном выполнении двух или более транзакций их результаты должны быть изолированы друг от друга. Одновременное выполнение двух транзакций одновременно не должно привести к результату, которого не было бы, если они выполнялись последовательно (например, при продаже билетов на один и тот же рейс в случае свободного последнего места при одновременном запросе двух агентов, запрос одного должен быть выполнен, другого — нет);
· долговременность — после завершения транзакции результат не должен быть утрачен в случае сбоя системы, даже если этот сбой происходит сразу после завершения транзакции.
Рассмотрим также 3 типа обращения к СУБД:
1. Запросы — вопросы по поводу данных могут генерироваться двумя способами:
б) с помощью интерфейсов прикладных программ — запросы передаются через специальный интерфейс (через этот интерфейс нельзя передавать произвольные запросы);
2. Модификации — это операции по изменению данных. Они также могут выполняться либо с помощью общего интерфейса, либо через интерфейс прикладной программы;
3. Модификации схемы — это команды администраторов БД, которые имеют право изменять схему БД или создавать новую БД.
Архитектура клиент/сервер. Во многих вариантах современного ПО реализуется архитектура клиент/сервер: один процесс (клиент) посылает запрос для выполнения другому процессу (серверу). Как правило, БД часто разделяется на процесс сервера и несколько процессов клиента.
В простейшей архитектуре клиент/сервер вся СУБД является сервером, за исключением интерфейсов запроса, которые взаимодействуют с пользователем и посылают запросы или другие команды на сервер. Например, реляционная СУБД часто использует язык SQL для представления запросов от клиента к серверу. Затем сервер БД предоставляет клиенту ответ в виде таблицы (отношения). Существует тенденция увеличения нагрузки на клиента, т. к. при наличии множества одновременно работающих пользователей БД с сервером могут возникнуть проблемы.
5. Реляционная модель данных.
РМД некоторой предметной области представляет собой набор отношений, изменяющихся во времени. При создании информационной системы совокупность отношений позволяет хранить данные об объектах предметной области и моделировать связи между ними.
где D 1 
D 2 … D n – полное декартово произведение, т.е. набор всевозможных сочетаний из n элементов каждое, где каждый элемент берется их своего домена.
· Домен имеет уникальное имя (в пределах базы данных).
· Домен определен на некотором простом типе данных или на другом домене.
· Домен может иметь некоторое логическое условие, позволяющее описать подмножество данных, допустимых для данного домена.
· Домен несет определенную смысловую нагрузку.
Заголовок отношения – это фиксированное количество атрибутов отношения:
Заголовок отношения описывает декартово произведение доменов, на котором задано отношение. Заголовок статичен, он не меняется во время работы с базой данных. Если в отношении изменены, добавлены или удалены атрибуты, то в результате получим уже другое отношение (пусть даже с прежним именем).
Тело отношения содержит множество кортежей отношения. Каждый кортеж отношения представляет собой множество пар вида :
Отношение обычно записывается в виде:
,
,
.
Число атрибутов в отношении называют степенью (или —арностью) отношения. Мощность множества кортежей отношения называют мощностью отношения.
Схемой отношения называется перечень имен атрибутов данного отношения с указанием домена, к которому они относятся:
Схемы двух отношений называются эквивалентными, если они имеют одинаковую степень и возможно такое упорядочение имен атрибутов в схемах, что на одинаковых местах будут находиться сравнимые атрибуты, то есть атрибуты, принимающие значения из одного домена:
Таким образом, для эквивалентных отношений выполняются следующие условия:
· Таблицы имеют одинаковое количество столбцов.
· Таблицы содержат столбцы с одинаковыми наименованиями.
· Столбцы с одинаковыми наименованиями содержат данные из одних и тех же доменов.
· Таблицы имеют одинаковые строки с учетом того, что порядок столбцов может различаться.
Все такие таблицы есть различные изображения одного и того же отношения.
Свойства отношений. Свойства отношений непосредственно следуют из приведенного выше определения отношения. В этих свойствах в основном и состоят различия между отношениями и таблицами.
Рис. Схематическое изображение отношения
Реляционная модель представляет собой базу данных в виде множества взаимосвязанных отношений. В каждой связи одно отношение может выступать как основное, а другое отношение выступает в роли подчиненного. Таким образом, один кортеж основного отношения может быть связан с несколькими кортежами подчиненного отношения. Для поддержки этих связей оба отношения должны содержать наборы атрибутов, по которым они связаны. В основном отношении это первичный ключ отношения, который однозначно определяет кортеж основного отношения. В подчиненном отношении для моделирования связи должен присутствовать набор атрибутов, соответствующий первичному ключу основного отношения. Однако здесь этот набор атрибутов уже является вторичным ключом или внешним ключом, т.е. он определяет множество кортежей отношения, которые связаны с единственным кортежем основного отношения.
6. Проектирование реляционных баз данных.
При проектирование реляционной БД должны быть решены следующие проблемы:
2) Обеспечить эффективность выполнения запросов к базе данных (физическое проектирование БД).
После проведения этапа даталогического проектирования должны быть получены следующие результирующие документы:
· Построение корректной схемы данных ориентируясь на реляционную модель данных.
· Описание схемы БД в терминах выбранной СУБД.
· Описание внешних моделей в терминах выбранной СУБД.
· Описание декларативных правил поддержки целостности БД.
· Разработка процедур поддержки семантической целостности БД.
Итак, задача проектирования реляционной БД состоит в выборе схемы базы из множества альтернативных вариантов.
Корректной называется схема БД, в которой отсутствуют нежелательные зависимости между атрибутами отношений. Процесс разработки корректной схемы БД называется логическим проектированием.
Проектирование схемы БД можно выполнить двумя методами:
· Метод декомпозиции (разбиения) – исходное множество отношений, входящих в схему БД заменяется другим множеством отношений, являющихся проекциями исходных отношений! При этом число отношений возрастает.
· Метод синтеза – компоновка схемы БД из заданных исходных элементарных зависимостей между объектами предметной области.
Классическое проектирование БД связано с теорией нормализацией, которая основана на анализе функциональных зависимостей между атрибутами отношений. Функциональные зависимости определяют устойчивые отношения между объектами и их свойствами в рассматриваемой предметной области.
Метод декомпозиции представляет собой процесс последовательной нормализации схем отношений: каждая новая итерация соответствует нормальной форме более высокого порядка и обладает лучшими свойствами по сравнению с предыдущей. Т.о., изначально предполагается существование универсального отношения, содержащего все атрибуты БД, затем на основе анализа связей между атрибутами осуществляется (или – делается попытка осуществить) декомпозиция универсального отношения, т.е. переход к нескольким отношениям меньшей размерности, причем исходное отношение должно восстанавливаться с помощью операции естественного соединения.
Итак, каждой нормальной форме соответствует некоторый определенный набор ограничений, и отношений находится в некоторой нормальной форме, если удовлетворяет свойственному ей набору ограничений.
В теории реляционных БД обычно выделяют следующие нормальные формы:
первая нормальная форма (1 NF );
· вторая нормальная форма (2 NF );
· третья нормальная форма (3 NF );
· нормальная форма Байса-Кодда ( BCNF );
· четвертая нормальная форма (4 NF );
Основные свойства нормальных форм:
· каждая следующая нормальная форма в некотором смысле лучше предыдущей;
· при переходе к следующей нормальной форме свойства предыдущих нормальных свойств сохраняются.
Схемы БД называются эквивалентными, если содержание исходной БД можно получить естественным соединением отношений, входящих в результирующую схему, и при этом не появляется новых кортежей в исходной БД.
7. Нормальные формы отношений.
В основе процесса нормализации лежит адекватное отражение предметной области в виде таблиц, содержащих данные о моделируемом объекте, и возможность изменения состояния базы данных с течением времени. Как правило, из-за несоответствия модели данных предметной области могут возникнуть аномалии, которые проявляются при выполнении соответствующих операций:
· Аномалии вставки (INSERT) – хранение в одном отношении разнородной информации.
· Аномалии обновления (UPDATE) –избыточность данных отношения из-за хранения разнородной.
· Аномалии удаления (DELETE) – хранение разнородной информации в одном отношении.
Нормализация – разбиение таблицы на несколько, которые обладают лучшими свойствами при обновлении, вставке и удалении данных. Т.е. нормализация представляет собой процесс последовательной замены таблицы ее полными декомпозициями до тех пор, пока все они не будут находиться в 5НФ, однако, на практике достаточно привести таблицы к НФБК.
Если заменить на время нормализации коды первичных (внешних) ключей, то следует рассмотреть 2 случая:
ФЗ 
Следует заметить, что для проведения таких операций первоначально следует иметь, в качестве входных данных некоторые «большие» (универсальные) отношения.
Опр.1. Отношение 
находится в первой нормальной форме (1НФ) тогда и только тогда, когда ни одна из его строк не содержит в любом своем поле одного значения и ни одного из ключевых полей отношения не пусто.
По опр.1, любое отношение будет находиться в 1НФ, т.е. отношение, удовлетворяющее свойствам отношений: в отношении нет одинаковых кортежей; кортежи не упорядочены; атрибуты не упорядочены и различаются по наименованию; все значения атрибутов атомарны.
Опр.2. Отношение находится во второй нормальной форме (2НФ) тогда и только тогда, когда отношение находится в 1НФ и нет неключевых атрибутов, зависящих от части сложного ключа (т.е. все поля, не входящие в первичный ключ, связаны полной функциональной зависимостью с первичным ключом).
Если потенциальный ключ является простым, то отношение автоматически находится в 2НФ.
Чтобы устранить зависимость атрибутов от части сложного ключа, необходимо произвести декомпозицию отношения на несколько отношений. Атрибуты, которые зависят от части сложного ключа, выносятся в отдельное отношение.
Атрибуты отношения называются взаимно-независимыми, если ни один из них не является функционально зависимым от другого.
Опр.3. Отношение находится в третьей нормальной форме (3НФ) тогда и только тогда, когда отношение находятся в 2НФ и все неключевые атрибуты взаимно независимы (т.е. ни одно из неключевые полей отношения не зависит функционально от любого другого неключевого поля).
Чтобы устранить зависимость неключевых атрибутов, нужно произвести декомпозицию отношения на несколько отношений. При этом те неключевые атрибуты, которые являются зависимыми, выносятся в отдельное отношение.
При приведении отношений при помощи алгоритма нормализации к отношениям в 3НФ предполагается, что все отношения содержат один потенциальный ключ. Это не всегда верно. Бывают случаи, когда отношение может содержать несколько ключей.
Если отношение находится в НФБК, то оно автоматически находится в 3НФ, что следует из определения 4. Чтобы устранить зависимость от детерминантов, не являющихся потенциальными ключами, следует провести декомпозицию, вынося эти детерминанты и зависимые от них части в отдельное отношение.
Бывают случаи, когда отношение не содержит никаких функциональных зависимостей. Т.е. отношение является полностью ключевым, т.е. ключом отношения является все множество атрибутов. Т.о., мы имеем многозначную зависимость, т.к. взаимосвязь между атрибутами все-таки имеется.
Опр.5. Отношение находится в четвертой нормальной форме (4НФ) тогда и только тогда, когда отношение находится в НФБК и не содержит нетривиальных многозначных зависимостей.
Отношения с нетривиальными многозначными зависимостями возникают, как правило, в результате естественного соединения двух отношений по общему полю, которое не является ключевым ни в одном из отношений. Реально это ведет к хранению в одном отношении информации о двух независимых сущностях.
Для устранения нетривиальных многозначных зависимостей можно декомпозировать исходное отношение на несколько новых.
Опр.6. Отношение находится в пятой нормальной форме (5НФ) тогда и только тогда, когда любая имеющаяся зависимость соединения является тривиальной.
Опр.6. тождественно также следует определению.
Опр.7. Отношение не находится в 5НФ, если в отношении найдется нетривиальная зависимость соединения.
Т.о. если в каждой полной декомпозиции все проекции исходного отношения содержат возможный ключ, можно сделать вывод о том, что отношение находится в 5НФ. Отношение, не имеющее ни одной полной декомпозиции также находится в 5НФ.
Не зная ничего о том, какие потенциальные ключи имеются в отношении и как взаимосвязаны атрибуты, нельзя утверждать, что данное отношение находится в 5НФ или в других нормальных формах.
Возможным ключом отношения называется набор атрибутов отношения, который полностью и однозначно (функционально полно) определит значения всех остальных атрибутов отношения. В общем случае в отношении может быть несколько возможных ключей. Среди всех возможных ключей отношения как правило выбирают один, который считается главным и который называют первичным ключом отношения.
Взаимно-независимые атрибуты – это атрибуты, не зависящие один от другого. Если в отношение существует несколько ФЗ, то каждый атрибут или набор атрибутов, от которого зависит другой атрибут, называется детерминантом отношения.
9. Реляционная алгебра.
Реляционная алгебра представляет собой основу доступа к реляционным данным. Основная цель алгебры – обеспечить запись выражений. Выражения могут использоваться для:
· определения области выборки, т.е. определения данных для их выбора, как результата операции выборки;
· определения области обновления, т.е. определения данных для их вставки, изменения или удаления, как результата операции обновления;
· определение (именованных) виртуальных отношений, т.е. представление данных для их визуализации через представления;
· определение снимка, т.е. определение данных для сохранения в виде «мгновенного снимка» отношения;
· определение правил безопасности, т.е. определение данных, для которых осуществляется контроль доступа;
· определение требований устойчивости, т.е. определение данных, которые входят в область для некоторых операций управления одновременным доступом;
· определение правил целостности, т.е. некоторых особых правил, которым должна удовлетворять база данных, наряду с общими правилами, представляющими часть реляционной модели и применяемыми к каждой базе данных.
В реализациях конкретных реляционных СУБД сейчас не используется в чистом виде ни реляционная алгебра, ни реляционное исчисление. Фактическим стандартом доступа к реляционным данным стал язык SQL (Structured Query Language).
Реляционная алгебра, определенная Коддом состоит из 8 операторов, составляющих 2 группы:
Кроме того, в состав алгебры включается операция присваивания, позволяющая сохранить в базе данных результаты вычисления алгебраических выражений, и операция переименования атрибутов, дающая возможность корректно сформировать заголовок (схему) результирующего отношения.
Краткий обзор операторов реляционной алгебры.
Произведение – возвращает отношение, содержащее всевозможные кортежи, которые являются сочетанием двух кортежей, принадлежащих соответственно двум определенным отношениям.
Объединение – возвращает отношение, содержащее все кортежи, которые принадлежат или одному из двух определенных отношений, или обоим.
Пересечение – возвращает отношение, содержащее все кортежи, которые принадлежат одновременно двум определенным отношениям.
Вычитание – возвращает отношение, содержащее все кортежи, которые принадлежат первому из двух определенных отношений и не принадлежат второму.
Деление – для двух отношений, бинарного и унарного, возвращает отношение, содержащее все значения одного атрибута бинарного отношения, которые соответствуют (в другом атрибуте) всем значениям в унарном отношении.
1. Дейт К.Дж. Введение в системы баз данных, 6-е издание: Пер. с англ. – К.; М.; СПб.: Издательский дом «Вильямс», 2000. – 848 с.
2. Конноли Т., Бегг К., Страчан А. Базы данных: проектирование, реализация и сопровождение. Теория и практика, 2-е изд.: Пер. с англ. – М.: Издательский дом «Вильямс», 2000. – 1120 с.
3. Карпова Т.С. Базы данных: модели, разработка, реализация. – СПб.: Питер, 2001. – 304 с.
4. Фаронов В.В., Шумаков П.В. Delphi 4. Руководство разработчика баз данных. – М.: «Нолидж», 1999. – 560 с.
5. Дж. Грофф, П.Вайнберг. SQL: Полное руководство: Пер. с англ. – К.: Издательская группа BHV, 2001. – 816 с.
6. Кен Гетц, Пол Литвин, Майк Гилберт. Access 2000. Руководство разработчика. Т.1, 2. Пер. с англ. – К.: Издательская группа BHV, 2000. – 1264 с, 912 c.
7. Маклаков С.В BPwin и EPwin. CASE-средства разработки информационных систем. – М.: ДИАЛОГ-МИФИ, 2001. – 304 с.
8. Ульман Д., Уидом Д. Введение в системы баз данных / Пер. с англ. – М.: «Лори», 2000. – 374 с.
9. Хомоненко А.Д., Цыганков В.М., Мальцев М.Г. Базы данных: Учебник для высших учебных заведений / Под ред. Проф. А.Д.Хомоненко. – Спб.: КОРОНА принт, 2000. – 416 с.