36589

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

Практическая работа

Информатика, кибернетика и программирование

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

Русский

2013-09-22

93.5 KB

21 чел.

Практическое занятие: «Основы проектирования баз данных»

  1.  Основные этапы проектирования баз данных
  2.  Нормализация баз данных

1. Основные этапы проектирования баз данных

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

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

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

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

2) Логическое (даталогическое) проектирование

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

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

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

3) Физическое проектирование

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

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


2. Нормализация баз данных

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

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

Проиллюстрируем процесс нормализации на примере:

ПродуктыЗаказы(КодЗаказа, КодПродукта, Клиент, АдресКлиента, Количество, ДатаЗаказа)

КодЗаказа

КодПродукта

Клиент

АдресКлиента

Количество

ДатаЗаказа

265

17

Карат

Советская 21

30

12.05.2010

265

70

Карат

Советская 21

20

12.05.2010

278

44

Весна

Амурская 47

23

18.09.2010

280

59

Весна

Амурская 47

44

20.10.2010

289

63

Колос

Молодежная 14

5

23.10.2010

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

Чтобы таблица соответствовала первой нормальной форме, все значения ее полей должны быть атомарными, и все записи - уникальными. То есть не должно быть для клиента «Карат» в одной ячейке два кода продукта 17 и 70 через запятую и не должно быть абсолютно одинаковых записей. Особенность реляционной модели такова, что любая реляционная БД изначально уже в первой нормальной форме.

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

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

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

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

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

Какие поля в таблице ПродуктыЗаказы могут являться ключевыми? КодЗаказа (определяет Клиента, АдресКлиента и ДатаЗаказу) и КодПродукта (определяет конкретный продукт и количество). Но такой первичный ключ из двух полей избыточен. Выделим поля Клиент, АдресКлиента и ДатаЗаказа в отдельную таблицу (назовем ее ЗаказыИнфо), при этом поле КодЗаказа станет первичным ключом новой таблицы. Таблица ПродуктыЗаказы будет иметь поля КодЗаказа, КодПродукта, Количество, причем КодЗаказа будет являться внешним ключом для таблицы ЗаказыИнфо. Связь между таблицами будет один-ко-многим, таблица ЗаказыИнфо главной, а ПродуктыЗаказы подчиненной.

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

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

Получаем две таблицы:

ПродуктыЗаказы(КодЗаказа, КодПродукта, Количество)

КодЗаказа

КодПродукта

Количество

265

17

30

265

70

20

278

44

23

280

59

44

289

63

5

ЗаказыИнфо(КодЗаказа, Клиент, АдресКлиента, ДатаЗаказа)

КодЗаказа

Клиент

АдресКлиента

ДатаЗаказа

265

Карат

Советская 21

12.05.2010

278

Весна

Амурская 47

18.09.2010

280

Весна

Амурская 47

20.10.2010

289

Колос

Молодежная 14

23.10.2010

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

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

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

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

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

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

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


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

ПродуктыЗаказы(КодЗаказа, КодПродукта, Количество)

ЗаказыИнфо(КодЗаказа, КодКлиента, ДатаЗаказа)

КодЗаказа

КодКлиента

ДатаЗаказа

265

17

12.05.2010

278

20

18.09.2010

280

20

20.10.2010

289

22

23.10.2010

Клиенты(КодКлиента, Клиент, АдресКлиента)

КодКлиента

Клиент

АдресКлиента

17

Карат

Советская 21

20

Весна

Амурская 47

22

Колос

Молодежная 14

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

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

Выводы

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

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

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

PAGE  1


 

А также другие работы, которые могут Вас заинтересовать

24408. Этика делового общения 34 KB
  Этика делового общения Умение вести себя с людьми надлежащим образом является одним из важнейших если не важнейшим фактором определяющим шансы добиться успеха в бизнесе служебной или предпринимательской деятельности. В этом контексте легко объяснимы попытки многих исследователей сформулировать и обосновать основные принципы этики делового общения Джен Ягер выделяет шесть следующих основных принципов: 1. Во втором случае оно проходит с помощью переписки или технических средств а первом при непосредственном контакте субъектов общения....
24409. Деловой этикет - это установленный порядок поведения в сфере бизнеса и деловых контактов 34.5 KB
  Деловой этикет это установленный порядок поведения в сфере бизнеса и деловых контактов. Деловой этикет включает в себя следующие разделы: Технологии невербального общения: жесты хорошего тона походка как правильно сидеть вход и выход из автомобиля рукопожатие и пр. Этикет если понимать его как установленный порядок поведения помогает избегать промахов или сгладить их доступными общепринятыми способами. Поэтому основную функцию или смысл этикета делового человека можно определить как формирование таких правил поведения в обществе...
24410. Имидж и его свойства 41 KB
  Имидж складывается в ходе личных контактов человека на основе мнений высказываемых о нем окружающими. Многие индивиды от природы обладают привлекательным имиджем наделены обаянием. Однако отсутствие внешней привлекательности не должно мешать созданию благоприятного имиджа.
24411. Архитектура безопасности. Модели безопасности ее оценки. Общие критерии 44.5 KB
  Данные файла занимают весь первый кластер и только один байт второго остальная же часть второго кластера ничем не заполнена однако недоступна для других файлов эта незанятая область поанглийски называется slack. В следующем доступном кластере могут размещаться данные другого файла. Если под данные этого файла не хватит второго кластера файл будет продолжен в следующем доступном кластере. DOS использует FAT для хранения информации необходимой для доступа к файлам записанным на диске.
24412. Типы процессов, развитие процесса в системе (ОС) 662.5 KB
  Каждый вычислительный процесс характеризуется набором действий набором информационных объектов последовательностью обработки и начальными состояниями говорят о наличии полного процесса в системе. Состояние системы определяется действиями производимыми процессами которые могут затребовать захватить или освободить ресурсы. В этом случае типы отношений предшествования которые возможны между процессами можно представить в следующем виде: Развитие процесса P представляется направленной дугой графа.
24413. Понятие семафора, назначение семафора, операции P(Q) и V(Q) 90 KB
  Ее можно проводить из любой точки Интернета в адрес любого сервера а для отслеживания злоумышленника потребуются совместные действия всех провайдеров составляющих цепочку от злоумышленника до атакуемого сервера VPN Потребительская сущность VPN виртуальный защищенный туннель или путь с помощью которого можно организовать удаленный защищенный доступ через открытые каналы Интернета к серверам баз данных FTP и почтовым серверам. VPN это: защита трафика основанная на криптографии; средство коммуникации с гарантией защиты доступа к...
24414. Понятие тупика, характеристика отношений, возникающих в системе (граф запросов и разделения ресурсов).Способ определения наличия тупиковой ситуации в системе (редукция графа) 112 KB
  К основным законам и подзаконным актам регламентирующим деятельность в области защиты информации относятся: Законы Российской Федерации: О федеральных органах правительственной связи и информации от 19.95 № 15ФЗ; Об информации информатизации и защите информации от 20.95 N 170; О лицензировании деятельности предприятий учреждений и организаций по проведению работ связанных с использованием сведений составляющих государственную тайну созданием средств защиты информации а также с осуществлением мероприятий и или оказанием услуг по...
24415. Четыре условия возможности возникновения тупика 77 KB
  Политика безопасности. Процедуры управления безопасностью также важны как и политики безопасности. Если политики безопасности определяют что должно быть защищено то процедуры безопасности определяют как защитить информационные ресурсы компании. Нескольких важных процедур безопасности: 1.
24416. Факторы сложности восстановления систем после тупика 69 KB
  Эксплуатация инфраструктуры безопасности. Эксплуатация инфраструктуры безопасности. Если такое превышение имеет место значит данная строка это одна из первоочередных целей разработки политики безопасности. Если интегральный риск превышает допустимое значение значит в системе набирается множество мелких огрешностей в системе безопасности которые в сумме не дадут предприятию эффективно работать.