Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Скачиваний:
51
Добавлен:
29.02.2016
Размер:
473.71 Кб
Скачать

Лекция №6-7 Основы проектирования баз данных

План:

1.Понятие базы данных. Примеры использования и сферы применения баз данных

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

3.Понятие ключа. Идентифицирующий атрибут

4.Виды связей между таблицами

5.Понятие "реляционная модель базы данных"

6.Правила нормализации

7.Понятие необходимости ввода правил, для обеспечения достоверности связи таблиц

1.Понятие базы данных. Примеры использования и сферы применения

баз данных

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

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

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

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

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

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

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

Информационные системы

Решение задач посредством СУБД приводит к созданию информационных систем (ИС).

По сферам применения различают два основных класса ИС: информационнопоисковые системы (ИПС) и системы обработки данных (СОД).

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

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

Локальные и глобальное пользовательские представления

Чтобы разобраться в задаче, нам необходимо структурировать информацию:

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

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

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

При проектировании ИС взгляды отдельных пользователей на предметную область называют локальными пользовательскими представлениями (ЛПП).

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

Завершение этапа приведет к формированию глобального пользовательского представления (ГПП), т.е. будет отражать точку зрения администратора БД.

2. Этапы и основные принципы проектирования Базы данных

Процесс проектирования ИС состоит из (см.рис):

сбора данных;

составления частных ЛПП;

унификации пересекающихся эпизодов;

составления ГПП;

формирования модели предметной области (инфологическое проектирование);

составления схемы с учетом используемого СУБД (концептуальное проектирование);

физического проектирования.

Инфологическое моделирование

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

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

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

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

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

Тип сущности - определяет набор однородных объектов.

Экземпляр сущности - конкретный объект из этого набора.

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

Атрибут - свойство сущности (объекта). Его имя должно быть уникально в рамках одной сущности.

Экземпляр атрибута - конкретное значение свойства.

Например: сущность «Ученик» определяется атрибутами: «Фамилия ученика», «Класс» и т.п. То есть для каждого конкретного ученика

(экземпляра сущности) мы должны определить экземпляры атрибутов (их конкретные значения). Продолжим с нашим примером: экземпляр сущности «Ученик» Ваня Иванов имеет экземпляр атрибута «Фамилия ученика» - «Иванов» и экземпляр атрибута «Класс» - «8А».

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

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

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

1.Модель должна давать полное представление о предметной области.

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

3.Имена сущностей должны быть уникальны.

4.Имена атрибутов в пределах одной сущности должны быть уникальны.

5.Мы должны гарантировать однозначную трактовку модели.

6.В каждой сущности должна быть выделена идентифицирующая совокупность атрибутов.

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

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

Сущность «Ученик» содержит все личные данные учащегося.

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

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

Сущность «Оценка» содержит информацию об оценке, полученной учеником по определенному предмету, выставленную преподавателем в конкретный день.

Концептуальное проектирование

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

3. Понятие ключа (Идентифицирующий атрибут)

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

То есть, как любой человек обладает набором качеств, отличающих его от себе подобных, и среди них мы можем выявить те, по которым найдем нужного человека (например, полный адрес), так и любая сущность должна обладать подобным набором . Другими словами, у нас есть несколько экземпляров одной сущности, и нам необходимо найти один или несколько атрибутов, значение которых может встречаться только один раз среди всех экземпляров этой сущности. Например: для сущности «Человек» мы можем определить атрибут «Фамилия». Но возможно ли, чтобы он был

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

4. Виды связей между таблицами

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

нормализацией.

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

Введем понятия, необходимые для понимания процесса приведения модели к реляционной схеме.

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

Экземпляр отношения - совокупность значений свойств конкретного объекта.

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

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

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

Требования к реляционным моделям

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

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

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

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

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

Графическая интерпретация реляционной схемы

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

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

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

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

6. Правила нормализации

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

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

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

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

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

Выполните практическое задание 1

При приведении отношения «Ученик» к первой нормальной форме мы выполнили два действия:

Атрибут «Адрес» состоит из значений двух свойств. Мы разбили его на атрибуты «Улица» и «Контекст адреса».

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

Полученное отношение не полностью приведено к первой нормальной форме. Придерживаясь правила, следовало бы разбить атрибуты «Фамилия ученика», «Классный руководитель», «Фамилии родителей» на «Фамилия», «Имя», «Отчество» каждый. Однако каждый из исходных атрибутов по сути нашей задачи будет использоваться целиком (т.е. атрибуты можно назвать простыми), и в данном случае формальный подход к процессу нормализации неуместен . Разбивая атрибут «Адрес» на два атрибута, мы также рассуждали неформально. Разработка ведется для районной школы, учащиеся которой живут поблизости, и, следовательно, спектр задействованных улиц невелик. Вполне вероятно возникновение задач, использующих улицу как отдельное значение, но вряд ли возникнут задачи, использующие в качестве параметра номер дома или, тем более, квартиры.

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

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

Проанализируем.

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

Значения в неключевых атрибутах «Улица», «Контекст адреса», «Фамилия ученика», «Специализация класса», «Классный руководитель», «Класс» отношения «Ученик» однозначно определяется значениями одного из

Соседние файлы в папке Лекции