Нф (первая Нормальная форма). Нф (вторая Нормальная форма). Н_сотр фам. Н_сотр н_отд. Н_сотр тел

↑

⇐ ПредыдущаяСтр 7 из 11Следующая ⇒

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

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

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

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

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

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

Замечание. Если потенциальный ключ отношения является простым, то отношение автоматически находится в 2НФ.

Отношение СОТРУДНИКИ_ОТДЕЛЫ_ПРОЕКТЫ не находится в 2НФ, т.к. есть атрибуты, зависящие от части сложного ключа:

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

Н_СОТР ФАМ

Н_СОТР Н_ОТД

Н_СОТР ТЕЛ

13) Перечислите и охарактеризуйте аномалии баз данных.

После составления концептуальной (логической) схемы БД нужно проверить её на отсутствие аномалий модификации данных. Дело в том, что при некорректно спроектированной схеме БД могут появиться аномалии выполнения операций модификации данных. Эти аномалии обоснованы ограниченностью структуры РМД (отсутствием агрегатов и проч.). Разглядим эти аномалии на примере дела со последующими атрибутами (атрибуты, входящие в ключ, выделены подчёркиванием): ПОСТАВКИ (Номер поставки, Заглавие продукта, Стоимость продукта, Количество, Дата поставки, Заглавие поставщика, Адресок поставщика) Различают три вида аномалий: аномалии обновления, удаления и прибавления. Аномалия обновления может появиться в этом случае, когда информация дублируется. Другие аномалии появляются тогда, когда две и поболее сути объединены в одно отношение. К примеру: Аномалия обновления: в отношении ПОСТАВКИ она может появиться, если у какого-нибудь поставщика поменялся адресок. Конфигурации должны быть внесены во все кортежи, надлежащие поставкам этого поставщика; в неприятном случае данные будут противоречивы. Аномалия удаления: при удалении записей обо всех поставках определённого поставщика все данные об этом поставщике будут утеряны. Аномалия прибавления: в нашем примере она возникнет, если с поставщиком заключен контракт, но поставок от него ещё не было. Сведения о таком поставщике нельзя внести в таблицу ПОСТАВКИ, т.к. для него не определён ключ (номер поставки и заглавие продукта) и другие неотклонимые атрибуты. Для решения трудности аномалии модификации данных при проектировании реляционной БД проводится нормализация отношений. Читайте также: A) 1-ый ряд базы данных содержит неповторяющиеся имена полей. I. Компьютерная симуляция экспериментальных данных I. Статистическая обработка данных измерения роста I. Статистическая обработка данных измерения роста. I. Файловые структуры, применяемые для хранения данных в БД Ii. Модели страничной организации данных в современных БД II. Провести статистический анализ для последующих совокупностей данных.

14) Перечислите этапы проектирования базы данных.

Концептуальное (инфологическое) проектирование[править | править вики-текст]

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

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

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

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

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

Логическое (даталогическое) проектирование[править | править вики-текст]

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

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

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

Физическое проектирование[править | править вики-текст]

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

15) Опишите процесс и средства построения логической модели БД на основе подхода «объект – отношение».

предметной области;

определение логической структуры реляционной базы данных;

конструирование таблиц базы данных;

создание схемы данных;

ввод данных в таблицы (создание записей);

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

разработка пользовательского интерфейса.

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

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

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

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

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

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

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

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

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

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

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

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

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

19:09:45

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

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

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

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

17) Раскройте сущность понятий транзакция, журнал транзакций, откат транзакции. Перечислите свойства транзакций, уровни изолированности транзакций.

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

Свойства

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

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

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

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

Изолированность. Во время выполнения транзакции параллельные транзакции не должны оказывать влияние на её результат. Это свойство не соблюдается на уровне изолированности Repeatable Read и ниже.

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

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

Откат транзакции. Системы обработки транзакций обеспечивают целостность базы данных при помощи записи промежуточного состояния базы данных перед её изменением, а затем, используя эти записи, восстанавливают базу данных до известного состояния, если транзакция не может быть совершена. Например, копии информации в базе данных до ее изменения транзакцией, делаются системой перед транзакцией, которая может сделать любые изменения (иногда это называют before image). Если какая-либо часть транзакции не удается до ее совершения, эти копии используются для восстановления базы данных в состояние, в котором она находилась до начала транзакции (Rollback).

Журнал транзакций. Каждая база данных SQL Server имеет журнал транзакций, в котором фиксируются все изменения данных, произведенные в каждой из транзакций.

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

Read uncommitted (чтение незафиксированных данных).Низший (нулевой) уровень изоляции. Он гарантирует только отсутствие потерянных обновлений[1]. Если несколько параллельных транзакций пытаются изменять одну и ту же строку таблицы, то в окончательном варианте строка будет иметь значение, определенное всем набором успешно выполненных транзакций. При этом возможно считывание не только логически несогласованных данных, но и данных, изменения которых ещё не зафиксированы.

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

Познавательные статьи:



Психологические особенности спортивного соревнования

Приготовление дезинфицирующих растворов различной концентрации

Занятость населения и рынок труда

Социальный статус семьи и её типология