36589

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

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

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

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

Русский

2013-09-22

93.5 KB

19 чел.

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

  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


 

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

24074. Строение гемоглобина 82 KB
  Строение гемоглобина. В молекуле гемоглобина белковый компонент представлен белком глобином небелковый компонент гем. За счет еще одной координационной связи к атому железа может присоединяться молекула кислорода с образованием оксигемоглобина.
24075. Синтез гема 41 KB
  При восстановлении биливердина НАДФ Н2 образуется билирубин. Билирубин плохо растворимое соединение и в крови связывается с альбумином. В виде комплекса альбуминбилирубин идет транспорт билирубина кровью в клетки печени. В печени билирубин соединяется с глюкуроновой кислотой с образованием моно 20 и диклюкуронидов 80 они хорошо растворимы в воде.
24076. Распад гема 27 KB
  остающихся в сыворотке крови после осаждения белков. в сыворотке крови является ценным диагностическим показателем при многих заболеваниях. определяют в надосадочной жидкости после удаления осажденных белков сыворотки крови центрифугированием с помощью азотометрического метода Кьельдаля в его многочисленных модификациях колориметрических и гипобромитных методов. в сыворотке крови равна 2040 мг 100 мл или 143286 ммоль л.
24077. Витамины и Антиметаболиты 54.26 KB
  Согласно современным предтавлениям все клеточные и внутриклеточные мембраны устроены сходным образом: основу мембраны составляет двойной молекулярный слой липидов липидный бислой на котором и в толще которого находятся белки см. В состав липидов мембран входят в основном фосфолипиды сфингомиелины и холестерин. Например в мембранах эритроцитов человека их содержание составляет соответственно 36 30 и 22 по весу; еще 12 приходится на гликолипиды Примером амфифильной молекулы может служить молекула фосфатидилэтаноламина структура...
24078. Биохимия печени 32.5 KB
  Биохимия печени Печень самый крупный из паренхиматозных органов. Роль печени в метаболизме углеводов Печень играет ведущую роль в поддержании физиологической концентрации глюкозы в крови. При физиологической гипогликемии в печени активируется распад гликогена. В печени активно протекает глюконеогенез при котором предшественниками глюкозы являются пируват и аланин поступающий из мышц глицерол из жировой ткани и с пищей ряд глюкогенных АК.
24079. Метаболизм белков 35 KB
  Детоксицирующая функция печени Детоксикация ядовитых метаболитов и чужеродных соединений ксенобиотиков протекает в гепатоцитах в две стадии. Реакции первой стадии катализируются монооксигеназной системой компоненты которой встроены в мембраны эндоплазматического ретикулума. На первой стадии биотрансформации происходит образование или высвобождение гидрокси карбоксильных тиоловых и аминогрупп которые являются гидрофильными и молекула может подвергаться дальнейшему превращению и выведению из организма. Кроме цх Р450 в первой...
24080. Биологическая ценность белков 30 KB
  Для оценки состояния обмена белков используется понятие азотистый баланс. Азот остается в организме и расходуется на синтез белков. Встречается при голодании белковой недостаточности тяжелых заболеваниях когда происходит интенсивный распад белков тела. Биологическая ценность белков.
24081. Переваривание белков. Пути превращения аминокислот в печени 105 KB
  Расщепление белков происходит при участии нескольких групп ферментов: Экзопептидазы катализирует разрыв концевой пептидной связи с образованием одной какойлибо аминокислоты. В результате расщепления образуются свободные аминокислоты которые затем подвергаются всасыванию. Аминокислоты всасываются свободно с ионами натрия. Некоторые аминокислоты обладают способностью конкурентно тормозить всасывание других аминокислот: Лизин тормозит всасывание аргинина.
24082. Токсическое действие аммиака-инактивация альфа-кетоглутарата в цикле кребса,энергетическое голодание,к которому чувствителна очень нервная ткань 57.5 KB
  Возможны 4 типа дезаминирования: Восстановительное RCHCOOH RCH2COOH NH3 NH2 Гидролитическое RCHCOOH RCHCOOH NH3 NH2 OH Внутримолекулярное RCH2CHCOOH RCH=CHCOOH NH3 NH2 Окислительное RCHCOOH RCCOOH NH3 NH2 O Окислительное дезаминирование бывает 2 видов: прямое и непрямое трансдезаминирование. R R1 R R1 HCNH2 C=O C=O HCNH2 COOH COOH COOH COOH Реакция трансаминирования...