3.4. Пример проектирования даталогической модели: Спроектировать даталогичеекую структуру БД означает установить все

Даталогическое проектирование

3.4. Пример проектирования даталогической модели: Спроектировать даталогичеекую структуру БД означает установить все

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

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

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

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

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

Корректной назовем схему БД, в которой отсутствуют нежелательные зависимости между атрибутами отношении.

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

Проектирование схемы БД может быть выполнено двумя путями:

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

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

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

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

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

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

В теории реляционных БД обычно выделяется следующая последовательность нормальных форм:

  • первая нормальная форма (1NF);
  • вторая нормальная форма (2NF);
  • третья нормальная форма (3NF);
  • нормальная форма Бойса— Кодда (BCNF);
  • четвертая нормальная форма (4NF);
  • пятая нормальная форма, или форма проекции-соединения (5NF или PJNF).

Основные свойства нормальных форм:

  • каждая следующая нормальная форма в некотором смысле улучшает свойства предыдущей;
  • при переходе к следующей нормальной форме свойства предыдущих нормальных форм сохраняются.

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

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

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

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

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

Приведем ряд основных определений.

Функциональной зависимостью набора атрибутов В отношения R от набора атрибутов А того же отношения, обозначаемой как

R.A -> R.B или А -> В

называется такое соотношение проекций R[A] и R[B], при котором в каждый момент времени любому элементу проекции R[A] соответствует только один элемент проекции R[B] , входящий вместе с ним в какой-либо кортеж отношения R.

Функциональная зависимость R.A -> R.B называется полной, если набор атрибутов В функционально зависит от А и не зависит функционально от любого подмножества А, то есть R.A -> R.B называется полной, если:

любое А1 с А=> R.A -/-> R.B, что читается следующим образом:

для любого А1, являющегося подмножеством A, R.B функционально не зависит от R.A, в противном случае зависимость R.A -> R.B называется неполной.

Функциональная зависимость R.A -> R.B называется транзитивной, если существует набор атрибутов С такой, что:

  1. С не является подмножеством А.
  2. С не включает в себя В.
  3. Существует функциональная зависимость R.A -> R.C.
  4. Не существует функциональной зависимости R.C -> R.A.
  5. Существует функциональная зависимость R.C -> R.B.

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

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

Значит, обязательно для каждого отношения всегда существует набор атрибутов, по которому можно однозначно определить кортеж отношения. В .

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

В общем случае в отношении может быть несколько возможных ключей.

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

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

Взаимно-независимые атрибуты — это такие атрибуты, которые не зависят функционально один от другого.

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

Для функциональных зависимостей как фундаментальной основы проекта БД

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

  1. Рефлексивность: если В является подмножеством А, то А->В
  2. Дополнение: если. А->В , то АС->ВС
  3. Транзитивность: если А->В и В->С , то А->С.

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

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

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

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

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

Соответственно, ненормализованные отношения могут интерпретироваться как таблицы с неравномерным заполнением, например таблица «Расписание», которая имеет вид:

Препода- ватель День недели Номер пары Название дисциплины Тип занятий   Группа  
Петров В. И. Поиед. Теор. выч. проц. Лекция
Вторник Коми, графика Лаб. раб.
Вторник Комн. графика Лаб. раб.
Киров В. А. Понед. Теор. ииформ. Лекция
Вторник Пр-е па C++ Лаб. раб.
Вторник Пр-е на C++ Ллб. раб.
Ссргш А. А. Понед. Защита ииф. Лекция
Среда Пр-е на VB Лаб. раб.
Четверг Пр-е на VB Лаб. раб.

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

Для приведения отношения «Расписание» к первой нормальной форме необходимо дополнить каждую строку фамилией преподавателя.

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

Препода- ватель День недели Номер пары Название дисциплины Тип занятий   Группа  
Петров В. И Понед. Теор. выч. проц. Лекция
Петров В. И Вторник Комм, графика Лаб. раб.
Петров В. И Вторник Коми, графика Лаб. раб.
Киров В. А. Понед. Теор. информ. Лекция
Киров В. А. Вторник Пр-е на C++ Лаб. раб.
Киров В. А. Вторник Пр-е на C++ Лаб. раб.
Серов А. А. Поиед. Защита инф. Лекция
Серов А. А. Среда Пр-е на VB Лаб. раб.
Серов А. А. Четверг Пр-е на VB Лаб. раб.

Рассмотрим отношение, моделирующее сдачу студентами текущей сессии. Структура этого отношения определяется следующим набором атрибутов:

(ФИО. Номер зач.кн.. Группа. Дисциплина. Оценка)

Так как каждый студент сдает целый набор дисциплин в процессе сессии, то первичным ключом отношения может быть (Номер, зач.кн.. Дисциплина), который однозначно определяет каждую стоку, отношения. С другой стороны, атрибуты ФИО и Группа зависят только от части первичного ключа — от значения атрибута Номер зач, кн.

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

Такими проекциями могут быть два отношения:

(ФИО, Номер.зач.кн.. Группа) (Номер зач.кн.. Дисциплина. Оценка)

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

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

Тогда в первом случае (если мы не разбивали исходное отношение на два) мы должны найти все записи с данным студентом и в них изменить значение атрибута Группа на новое. Во втором же случае меняется только один кортеж в первом отношении. И конечно, опасность нарушения корректности (непротиворечивости содержания) БД в первом случае выше.

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

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

Если же мы перешли ко второй нормальной форме, то мы меняем только один кортеж.

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

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

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

(ФИО. Номер зач.кн.. Группа. Факультет, Специальность, Выпускающая кафедра)

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

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

В этом случае у нас есть следующие функциональные зависимости:

Номер зач .кн. -> ФИО

Номер зач.кн. -> Группа

Номер зач.кн. -> Факультет

Номер зач.кн. -> Специальность

Номер зач.кн. -> Выпускающая кафедра

Группа -> Факультет

Группа -> Специальность

Группа -> Выпускающая кафедра

Выпускающая кафедра -> Факультет

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

(Номер. зач. кн., ФИО. Специальность. Группа) (Группа. Выпускающая кафедра) (Выпускащая кафедра, Факультет)

Первичные ключи отношений выделены.

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

Полученный набор отношений находится в третьей нормальной форме.

Отношение находится в нормальной форме Болса—Кодла, если оно находится в третьей нормальной форме и каждый детерминант отношения является возможным ключом отношения.

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

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

(Номер зач.кн.. Идентификатор_студента. Дисциплина. Дата. Оценка)

Возможными ключами отношения являются Нонер_зач.кн, Дисциплина, Дата и Идеитификатор_студента, Дисциплина, Дата.

Какие функциональные зависимости у нас имеются?

Номер_зач.кн, Дисциплина. Дата -> Оценка;

Идентификатор_студента, Дисциплина. Дата -> Оценка;

Номер зач.кн. -> Идентификатор_студента;

Идентификатор_студента -> Номер зач.кн.

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

(Идентификатор_студента. Дисциплина. Дата. Оценка)

(Номер зач.кн.. Идентификатор_студента)

или наоборот:

(Номер зач.кн., Дисциплина. Дата, Оценка)

(Номер зач.кн.. Идентификатор_студента)

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

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

В отношении R (А, В, С) существует многозначная зависимость (multi valid dependence, MVD) R.A -» R.B в том и только в том случае, если множество значений В, соответствующее паре значений А и С, зависит только от А к не зависит от С.

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

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

Пусть дано отношение, которое моделирует предстоящую сдачу экзаменов на сессии. Допустим, оно имеет вид:

(Номер зач.кн.. Группа. Дисциплина)

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

В данном отношении существуют следующие две многозначные зависимости: Группа -» Дисциплина Группа -» Номер зач.кн.

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

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

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

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

В теории реляционных баз данных доказывается, что в общем случае в отношении R (А, В, С) существует многозначная зависимость R.A -» R.B в том и только в том случае, когда существует многозначная зависимость R.A -» R.C.

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

Не нашли то, что искали? Воспользуйтесь поиском:

Источник: https://studopedia.ru/7_32698_datalogicheskoe-proektirovanie.html

Даталогическое проектирование базы данных

3.4. Пример проектирования даталогической модели: Спроектировать даталогичеекую структуру БД означает установить все

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

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

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

Такимобразом, исходными данными для разработкидаталогической модели являются:

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

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

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

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

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

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

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

В современныхреляционных СУБД наиболее распространеннымЯОД являются подмножества языка SQL(StructuredQueryLanguage).

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

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

  • Получение спецификаций внутренней схемы: перевод структурных спецификаций схемы базы данных с полноатрибутного IDEF1X-представления в описание на языке конкретной СУБД.
  • Получение спецификаций ограничений целостности: перевод спецификаций ограничений целостности данных с языков IDEF1X, предикатов и естественного в описание на языке описания данных и программы на языке разработки приложений.

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

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

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

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

Каждой сущности ставится в соответствиеодно отношение. Этому отношениюприсваивается имя соответствующейсущности. Каждое отношения наследуетот сущности все ее атрибуты с их именамии типами данных.

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

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

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

  • правила построения имен отношений в используемой СУБД;
  • правила построения имен атрибутов в используемой СУБД;
  • типы данных, поддерживаемые используемой СУБД.

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

Источник: https://studfile.net/preview/1047355/page:10/

Курсовая работа: Проектирование базы данных 4

3.4. Пример проектирования даталогической модели: Спроектировать даталогичеекую структуру БД означает установить все

Федеральное Агентство Железнодорожного Транспорта

УрГУПС

Кафедра «Связь»

Курсовая работа.

Проектирование базы данных.

Работу выполнил:

студент гр. Ит-314

Медведев Н.В.

Работу проверил:

преподаватель

Пащенко М.А.

Екатеринбург,

2006 г.

Введение 3

    Инфологическое проектирование 5

1.1. Описание предметной области 5

1.2. Описание информационных потребностей пользователей 5

1.3. Построение инфологической модели 6

    Даталогическое проектирование 7

2.1. Выбор и характеристика СУБД 7

2.2. Построение даталогической модели 9

2.3. Создание базы данных 11

2.4. Заполнение БД 12

2.5. Запросы к БД 14

Заключение 17

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

Введение.

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

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

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

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

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

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

Проектирование внешних и концептуальной инфологических моделей
Предварительное планирование

Этапы проектирования базы данных.

Рис.1 Этапы проектирования БД

    Инфологическое проектирование

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

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

— Объект

— Свойство

— Связь

— Время

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

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

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

1.2. Описание информационных потребностей пользователей

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

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

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

Основными понятиями ER-модели являются сущность, связь и атрибут:

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

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

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

Связь представляется в виде линии. При этом над местом «стыковки» связи с сущностью ставится знак «∞» или буква «M», если для этой сущности в связи могут использоваться много (many) экземпляров сущности, и цифра «1», если в связи может участвовать только один экземпляр сущности.

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

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

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

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

Построение инфологической модели

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

Сущность – это класс однотипных объектов. Процесс деятельности фирмы идентифицирует такие сущности: Команда, Тренер, Члены команды, Матчи, Чемпионат.

Каждая из сущностей имеет свой набор атрибутов.

Рисунок 1. Диаграмма ER – типов.

Описание сущностей:

Команда, Тренер, Члены команды, Матчи, Чемпионат.

2. Даталогическое проектирование.

2.1. Выбор и характеристика СУБД

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

К числу основных функций СУБД принято относить следующие:

1. Непосредственное управление данными во внешней памяти.

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

2. Управление буферами оперативной памяти.

СУБД обычно работают с БД значительного размера. Этот размер существенно превышает доступный объем оперативной памяти.

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

Единственным способом увеличения этой скорости является буферизация данных в оперативной памяти. Поэтому в СУБД поддерживается набор буферов оперативной памяти с дисциплинами замены буферов.

3. Управление транзакциями.

Транзакция – это последовательность операций над БД, рассматриваемых СУБД как единое целое. Либо транзакция успешно выполняется и СУБД фиксирует (COMMIT) изменения БД, произведенные ею во внешней памяти, либо ни одно из этих изменений никак не отражается на состоянии БД.

4. Журнализация.

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

5. Поддержка языков БД.

Для работы с БД используются специальные языки баз данных. Чаще всего выделяются 2 языка – язык определения данных (DDL) и язык манипулирования данными (DML). DDL служит, главным образом, для определения логической структуры БД, а DML, содержит набор операторов манипулирования данными.

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

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

INTEGER — целое число (обычно до 10 значащих цифр и знак);

SMALLINT — «короткое целое» (обычно до 5 значащих цифр и знак);

DECIMAL(p,q) — десятичное число, имеющее p цифр (0

Источник: https://www.bestreferat.ru/referat-263099.html

ПОСМОТРЕТЬ ЁЩЕ:

Источник: https://helpiks.org/7-77827.html

Лабораторная работа №1. Описание предметной области базы данных. Концептуальное проектирование. Определение сущностей и атрибутов разработка инфологической модели в виде er – диаграммы. Физическое проектирование. Создание даталогической модели. Цель работы

3.4. Пример проектирования даталогической модели: Спроектировать даталогичеекую структуру БД означает установить все

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

Структура проектирования БД

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

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

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

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

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

Ключи принято разделять на первичные, внешние и вспомогательные.

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

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

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

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

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

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

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

II. ПОРЯДОК ВЫПОЛНЕНИЯ РАБОТЫ

Лабораторная работа №1 выполняется письменно и в конце занятия сдается на проверку, после проверки которой будут в дальнейшем выставлены оценки.

2.1. Выбор задания

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

2.2. Анализ предметной области.

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

2.3. Описание основных сущностей ПО.

Здесь следует привести описание основных сущностей (объектов) ПО. Отбор сущностей производится на основе анализа информационных потребностей. Необходимо привести таблицы описания сущностей (сущностей должно быть не менее 3-х) Таблица 1.1. Список сущностей предметной области.

N п.п. Наименование сущности Краткое описание

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

N п.п. Наименование атрибута Краткое описание

На основе анализа информационных запросов следует выявить связи между сущностями. Для выявленных связей также нужно заполнить таблицу 1.3. Таблица 1.3. Список связей ПО.

N п.п. Наименование связи Сущности, участвующие в связи Краткое описание

2.4. Построение инфологической модели. На основании ранее выбранного варианта и таблиц 1.1-1.3:

  • описать классы объектов (сущностей) и их свойства,
  • расставить существующие связи между ними,
  • на основании табл. 1.3. в письменной форме обосновать типы связей (1:1, 1:М и т.д.).

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

2.5. Построение даталогической модели.

На основании ранее выбранного варианта и таблиц 1.1-1.3, инфологической модели и нормализации БД необходимо:

  • провести соответствие ключей для каждой таблицы 1.1-1.3,
  • заполнить для каждой таблицы БД форму, согласно табл. 1.4.

Таблица 1.4. Структура таблицы для даталогической модели.

N п.п. Наименование реквизита Иденти-фикатор Тип Длина Формат изобра-жения

Источник: http://razom.znaimo.com.ua/docs/34115/index-2529-6.html?page=4

Scicenter1
Добавить комментарий