Презентация на тему "Проектирование Базы данных"

Ваша оценка презентации
Оцените презентацию по шкале от 1 до 5 баллов
  • 1
  • 2
  • 3
  • 4
  • 5

Рецензии

Добавить свою рецензию

Аннотация к презентации

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

Краткое содержание

  1. Предварительное планирование
  2. Проверка осуществимости
  3. Определение требований
  4. Концептуальное проектирование
  5. Реализация
  6. Оценка работы и поддержка БД

Содержание

  • Слайд 1

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

    • Автор:
    • Преподаватель МБОУ СОШ №2, г.Томск Мышкина Татьяна Владимирвна

  • Слайд 2

     

    Схема создания модели

  • Слайд 3

     

    • Предварительное планирование
    • Проверка осуществимости
    • Определение требований
    • Концептуальное проектирование
    • Реализация
    • Оценка работы и поддержка БД
    • Процедура создания любой системы, в данном случае БД состоит из шести этапов:

  • Слайд 4

     

    • Мужчина
    • Женщина
    • Брак
    • Студент
    • Стипен-дия
    • Назначение
    • Кварти-ра
    • Жилец
    • Назначение
    • Инспек-тор
    • Рабочий
    • Контролирует
    • Врач
    • Пациент
    • Лечащий врач
    • А
    • В
    • АВ
    • Примеры отношений

  • Слайд 5

     

    • Типы связей
    • Мужчина
    • Брак
    • Женщина
    • 1
    • М
    • Мужчина
    • Брак
    • Женщина
    • 1
    • М
    • Мужчина
    • Брак
    • Женщина
    • М
    • N
    • Традиционный брак
    • Один – к – одному:
    • Многоженство
    • Один – ко – многим:
    • Многомужие
    • Многие – к – одному:
    • Групповой брак
    • Многие - ко – многим:
    • Мужчина
    • Женщина
    • Брак
    • 1
    • 1

  • Слайд 6

     

    • Геометрическое изображение типов сущностей
    • Стержень
    • Ассоциация
    • Атрибут
    • Ключ
    • Характерис-
    • тика
    • Обозначения
    • - независимая сущность
    • - связь «многие-ко-многим»(«-ко-многим»), между двумя или более сущностями
    • Связь «многие-к-одной»,»одна-к-одной»,описание или уточнение некоторой сущности
    • Связь «многие-к-одной»,»одна-к-одной»,не зависит от обозначаемой сущности

  • Слайд 7

     

    • Язык моделирования (ЯМ)
    • СУЩНОСТЬ (атрибут 1, атрибут 2,…, атрибут n)
    • АССОЦИАЦИЯ [ СУЩНОСТЬ S1, СУЩНОСТЬ S2,…]
    • ХАРАКТЕРИСТИКА (атрибут 1, атрибут 2,…)
    • {СПИСОК ХАРАКТЕРИЗУЕМЫХ СУЩНОСТЕЙ}
    • ОБОЗНАЧЕНИЕ (атрибут 1, атрибут 2,…)
    • [ СПИСОК ОБОЗНАЧАЕМЫХ СУЩНОСТЕЙ ]

  • Слайд 8

     

    • Третья нормальная форма
    • Таблица "Посещение"
    • Фамилия (ПК)
    • Дата посещения (ПК)
    • Диагноз
    • Таблица "Пациент"
    • Фамилия (ПК, ВК)
    • Дата рождения
    • Номер участка (ПК)
    • Таблица "Врач"
    • Номер участка (ПК,ВК)
    • Фамилия врача

  • Слайд 9

     

    • «Таблица – связь»
    • Таблица «Пациент»
    • (стержень)
    • Таблица «Врач»
    • (характеристика)
    • Фамилия(ВК)
    • Дата посещения
    • Диагноз
    • Номер участка(ВК)
    • Фамилияврача
    • Фамилия(ПК)
    • Номер участка(ПК)
    • Дата рождения
    • Таблица «Посещение»
    • (характеристи-ка)

  • Слайд 10

     

    • Три класса сущностей на языке моделирования «Таблица-связь» можно изобразить в виде следующих блоков:
    • Такое представление может облегчить изображение схемы «Таблица-связь».

  • Слайд 11

     

    Вопросы

  • Слайд 12

     

    • Документы Word:
    • Методика БД
    • Примерная программа по Access
    • Что необходимо уметь делать в СУБД Access
    • Создание формы
    • Индексирование полей
    • Лабораторные работа №1 (Класс, простые запросы)
    • 10 лабораторных работ по БД «Школа»
    • Табель успеваемости
    • Документ в Excel:
    • Табель (Аттестация, файл –Excel)
    • Образец базы данных (архив)«школа.rar»

  • Слайд 13

    Литература

    • Дейт К. Руководство по реляционной СУБД DB2. – М.: Финансы и статистика, 1988. – 320 с.
    • БАЗЫ ДАННЫХ, РАЗРАБОТКА И УПРАВЛЕНИЕ. Г. Хансен, Д. Хансен. Издательство «БИНОМ», 1999.
    • БАЗЫ ДАННЫХ, Учебное пособие, Томский межвузовский центр дистанционного образования. Красина.
    • ИНФОРМАТИКА и ИНФОРМАЦИОННЫЕ ТЕХНОЛОГИИ, 10-11. Н. Угринович, ЛБЗ,
    • 2002.
    • Н.В. Макарова. Информатика. Учебник, 10-11, Питер, 2000
    • КирилловВ.В. Учебное пособие.
    • Основы проектирования реляционной БД. Санкт-Петербургский Государственный институтточной механики и оптики (технический университет). Кафедра вычислительной техники

Посмотреть все слайды

Конспект

�PAGE �13� �PAGE �17�

Содержание:

2Актуальность темы:

3Создание БД �

5Основы концептуального моделирования данных �

6Характеристика связей и язык моделирования �

11Реляционная структура данных �

12О первичных и внешних ключах ...

�PAGE �13� �PAGE �17�

Содержание:

2Актуальность темы:

3Создание БД �

5Основы концептуального моделирования данных �

6Характеристика связей и язык моделирования �

11Реляционная структура данных �

12О первичных и внешних ключах �

13Процесс нормализации �

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

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

15Третья нормальная форма �

16Процедура проектирования �

17ЛИТЕРАТУРА: �

Актуальность темы:

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

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

Разработана модель и база данных "Администрирование школы", "Провизор" и создана информационная модель "Библиотека" и "Питание".

Основные понятия:

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

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

Моделирование – это метод познания, состоящий в создании и исследовании моделей.

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

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

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

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

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

Создание БД

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

image1.png

Рис. 1. Уровни моделей данных

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

Процедура создания любой системы, в данном случае БД состоит из шести этапов:

Предварительное планирование

Проверка осуществимости

Определение требований

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

Реализация

Оценка работы и поддержка БД

Стандартная структура БД состоит из трех уровней:

Концептуальный

Внешний

Внутренний.

На концептуальном уровне выполняется концептуальное проектирование БД. Что включает это проектирование:

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

определение нужных элементов данных.

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

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

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

При разработке концептуальной модели можно использовать любую из трех моделей: РЕЛЯЦИОННАЯ, СЕТЕВАЯ, ИЕРАРХИЧЕСКАЯ (

Основы концептуального моделирования данных

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

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

Атрибут – поименованная характеристика сущности. Его наименование должно быть уникальным для конкретного типа сущности, но может быть одинаковым для различного типа сущностей (например, ЦВЕТ может быть определен для многих сущностей: СОБАКА, АВТОМОБИЛЬ, ДЫМ и т.д.). Атрибуты используются для определения того, какая информация должна быть собрана о сущности. Примерами атрибутов для сущности АВТОМОБИЛЬ являются ТИП, МАРКА, НОМЕРНОЙ ЗНАК, ЦВЕТ и т.д. Здесь также существует различие между типом и экземпляром. Тип атрибута ЦВЕТ имеет много экземпляров или значений: �Красный, Синий, Банановый, Белая ночь и т.д., однако каждому экземпляру сущности присваивается только одно значение атрибута. Абсолютное различие между типами сущностей и атрибутами отсутствует. Атрибут является таковым только в связи с типом сущности. В другом контексте атрибут может выступать как самостоятельная сущность. Например, для автомобильного завода цвет – это только атрибут продукта производства, а для лакокрасочной фабрики цвет – тип сущности.

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

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

Характеристика связей и язык моделирования

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

Между двумя сущностям, например, А и В возможны четыре вида связей.

Первый тип – связь ОДИН-К-ОДНОМУ (1:1): в каждый момент времени каждому представителю (экземпляру) сущности А соответствует 1 или 0 представителей сущности В:

image2.png

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

Второй тип – связь ОДИН-КО-МНОГИМ (1:М): одному представителю сущности А соответствуют 0, 1 или несколько представителей сущности В.

image3.png

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

Так как между двумя сущностями возможны связи в обоих направлениях, то существует еще два типа связи МНОГИЕ-К-ОДНОМУ (М:1) и МНОГИЕ-КО-МНОГИМ (М:N).

Пример 1. Если связь между сущностями МУЖЧИНЫ и ЖЕНЩИНЫ называется БРАК, то существует четыре возможных представления такой связи:

image4.png

Характер связей между сущностями не ограничивается перечисленными. Существуют и более сложные связи:

множество связей между одними и теми же сущностями

image5.png

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

тренарные связи

image6.png

(врач может назначить несколько пациентов на несколько анализов, анализ может быть назначен несколькими врачами нескольким пациентам и пациент может быть назначен на несколько анализов несколькими врачами);

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

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

СУЩНОСТЬ (атрибут 1, атрибут 2 , ..., атрибут n)

АССОЦИАЦИЯ [СУЩНОСТЬ S1, СУЩНОСТЬ S2, ...]

(атрибут 1, атрибут 2, ..., атрибут n)

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

Так, рассмотренный выше пример множества связей между сущностями, может быть описан на ЯМ следующим образом:

Врач (Номер врача, Фамилия, Имя, Отчество, Специальность)

Пациент (Регистрационный номер, Номер койки, Фамилия,

Имя, Отчество, Адрес, Дата рождения, Пол)

Лечащий врач [Врач 1, Пациент M]

(номер врача, регистрационный номер)

Консультант [Врач M,Пациент N]

(номер врача, регистрационный номер).

Настал момент разобраться в терминологии. К.Дейт [1] определяет три основные класса сущностей: стержневые, ассоциативные и характеристические, а также подкласс ассоциативных сущностей – обозначения.

Стержневая сущность (стержень) – это независимая сущность (несколько подробнее она будет определена ниже).

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

Ассоциативная сущность (ассоциация) – это связь вида "многие-ко-многим" ("-ко-многим" и т.д.) между двумя или более сущностями или экземплярами сущности.

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

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

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

ХАРАКТЕРИСТИКА (атрибут 1, атрибут 2, ...)

{СПИСОК ХАРАКТЕРИЗУЕМЫХ СУЩНОСТЕЙ}.

Расширим также язык ER-диаграмм, введя для изображения характеристики трапецию (рис. 2).

image7.png

Рис. 2. Элементы расширенного языка ER-диаграмм

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

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

При отсутствии жестких правил (сотрудник может одновременно зачисляться в несколько отделов или не зачисляться ни в один отдел) необходимо создать описание с ассоциацией Зачисление:

Отделы (Номер отдела, Название отдела, ...)

Служащие (Табельный номер, Фамилия, ...)

Зачисление [Отделы M, Служащие N]

(Номер отдела, Табельный номер, Дата зачисления).

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

Отделы (Номер отдела, Название отдела, ...)

Служащие (Табельный номер, Фамилия, ... , Номер отдела,

Дата зачисления)[Отделы]

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

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

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

ОБОЗНАЧЕНИЕ (атрибут 1, атрибут 2, ...)[СПИСОК

ОБОЗНАЧАЕМЫХ СУЩНОСТЕЙ].

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

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

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

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

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

Реляционная структура данных

В конце 60-х годов появились работы, в которых обсуждались возможности применения различных табличных моделей данных, т.е. возможности использования привычных и естественных способов представления данных. Наиболее значительной из них была статья сотрудника фирмы IBM д-ра Э.Кодда (Codd E.F., A Relational Model of Data for Large Shared Data Banks. CACM 13: 6, June 1970), где, вероятно, впервые был применен термин "реляционная модель данных".

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

Отношение – Таблица (иногда Файл),�Кортеж – Строка (иногда Запись),�Атрибут – Столбец, Поле.

Свойства таблицы:

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

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

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

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

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

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

О первичных и внешних ключах

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

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

Теперь о внешних ключах(ВК):

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

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

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

ПК и ВК имеют свойства:

NULL-значения не допустимы (пустое содержимое)

УДАЛЕНИЕ записей ИЗ (цель) КАСКАДИРУЕТСЯ на связанные таблицы с ВК.

ОБНОВЛЕНИЕ записей(первичный ключ цели) КАСКАДИРУЕТСЯ на связанные таблицы с ВК.

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

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

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

Запрещается удалять записи в ГТ, если есть записи в ПТ.

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

Условия целостности:

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

Связанные поля в обеих таблицах должны иметь один размер и тип данных.

Обе таблицы принадлежат одной БД.

Процесс нормализации

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

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

Первая нормальная форма (1НФ) – Все значения атрибутов должны быть атомарными или уникальными. Атомарное значение – значение, которое не является множеством значений или повторяющейся группой.

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

Вторая нормальная форма (2НФ) – Говорят, что реляционная БД находится во 2НФ, если она находится в 1НФ и ее неключевые поля полностью зависят от всего ПК.

Чтобы перейти от 1НФ ко 2НФ, необходимо выполнить следующие шаги:

Определить, на какие части можно разбить ПК, так, чтобы некоторые из неключевых полей зависели от одной из этих частей (эти части не обязаны состоять из одной колонки!!).

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

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

Все же таблица, находясь во 2НФ тоже имеет аномалии, поэтому ее переводят в 3НФ.

Говорят, что реляционная таблица находится в 3НФ, если она находится во 2НФ и все неключевые поля зависят только от ПК. Чтобы перейти от 2НФ к 3НФ, нужно выполнить следующие шаги:

Определить все поля, от которых зависят другие поля.

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

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

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

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

Пример:

Спроектировать БД "Поликлиника". В ней должны храниться сведения о посещении пациентами врачей-терапевтов районной поликлиники. БД состоит из полей

image8.wmf

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

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

Определить главный ключ.

Все поля должны быть атомарными и уникальными. Реляционная модель уже находится в первой нормальной форме. Тем не менее данная БД имеет недостаток.

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

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

Фамилия (ПК)

Дата посещения (ПК)

Дата рождения

Номер участка

Фамилия врача

Номер участка

Диагноз

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

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

В данной таблице имеем:

image12.wmf

image9.wmf

Фамилия – ПК и ВК

Дата посещения – ПК

Недостатки этой таблицы:

Если пациент сменит врача, то придется менять и номер участка

Удаление в первой таблице поля фамилия приведет к удалению поля фамилии врача во второй таблице.

Устранить эти аномалии, если перейдем к третьей форме

Третья нормальная форма

Таблица "Посещение" Таблица "Пациент" Таблица "Врач"

Фамилия (ПК) Фамилия (ПК, ВК) Номер участка (ПК,ВК)

Дата посещения (ПК) Дата рождения Фамилия врача

Диагноз Номер участка (ПК)

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

Процедура проектирования

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

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

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

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

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

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

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

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

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

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

image10.png

Рис. 3. Концептуальная модель базы данных "Поликлиника", построенная с помощью языка "Таблицы-связи"

Три класса сущностей на языке моделирования «Таблица-связь» можно изобразить в виде следующих блоков:

image11.png

Такое представление может облегчить изображение схемы «Таблица-связь».

ЛИТЕРАТУРА:

Дейт К. Руководство по реляционной СУБД DB2. – М.: Финансы и статистика, 1988. – 320 с.

БАЗЫ ДАННЫХ, РАЗРАБОТКА И УПРАВЛЕНИЕ. Г. Хансен, Д. Хансен. Издательство «БИНОМ», 1999.

БАЗЫ ДАННЫХ, Учебное пособие, Томский межвузовский центр дистанционного образования. Красина.

ИНФОРМАТИКА и ИНФОРМАЦИОННЫЕ ТЕХНОЛОГИИ, 10-11. Н. Угринович, ЛБЗ,

2002.

� EMBED Excel.Sheet.8 ���

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

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

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

Сегодня наиболее распространены реляционные модели, которые будут подробно рассмотрены ниже.

image13.wmf

_1136126633/ole-[42, 4D, 36, 28, 01, 00, 00, 00]

_1136127847/ole-[42, 4D, D6, F5, 03, 00, 00, 00]

_1136129132/ole-[42, 4D, 2E, F7, 01, 00, 00, 00]

_1136129882/ole-[42, 4D, BA, E2, 02, 00, 00, 00]

_1136128509/ole-[42, 4D, 76, 64, 01, 00, 00, 00]

_1136126927/ole-[42, 4D, E6, 3D, 01, 00, 00, 00]

_1068814767.xls

Лист1

фамилия пациента дата посещения диагноз
Лосев 4/11/98 грипп
Орлов 5/5/98 орз
Лосев 7/26/98 бронхит
Дуров 3/14/98 стенокардия
Жукова 4/11/98 ангина
Орлова 7/11/98 гастрит
Быкова 6/15/98 орз
Дуров 7/26/98 орз

_1136048278/ole-[42, 4D, F6, 6F, 04, 00, 00, 00]

_1136124298/ole-[42, 4D, 4E, 2A, 0F, 00, 00, 00]

_1136046060/ole-[42, 4D, 06, F1, 02, 00, 00, 00]

_1136043346.xls

Лист1

фамилия пациента дата рождения номер участка фамилия врача
Лосев 4/13/65 2 Петрова
Орлова 1/25/47 1 Андреева
Дуров 3/5/30 2 Петрова
Жукова 1/30/70 2 Петрова
Быкова 4/1/75 1 Андреева

_1068809715.xls

Лист1

фамилия пациента дата рождения номер участка фамилия врача дата посещения диагноз
Лосев 4/20/65 2 Петрова 4/11/98 грипп
Орлов 1/25/47 1 Андоеева 5/5/98 орз
Лосев 4/20/65 2 Петрова 7/26/98 бронхит
Дуров 3/5/30 2 Петрова 3/14/98 стенокардия
Жуков 1/30/70 2 Петрова 4/11/98 ангина
Орлова 1/25/47 1 Андреева 7/11/98 гастрит
Быкова 4/1/75 1 Андреева 6/15/98 орз
Дуров 3/5/30 2 Петрова 7/26/98 орз
Скачать конспект
Презентация будет доступна через 45 секунд