36589

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

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

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

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

Русский

2013-09-22

93.5 KB

17 чел.

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

  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


 

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

75305. Характер, формы и основные этапы социальной борьбы в средневековом городе 35.5 KB
  Средневековые города возникали на земле королей а также светских и духовных феодалов. Они начали борьбу за свое освобождение добиваясь превращения сеньориального города в вольный а его жителей в свободных горожан. Позднее города стали бороться за политические привилегии: право на самоуправление и собственную юрисдикцию. Но это было по силам только очень богатым городам французским английским.
75306. Средневековое цеховое ремесло и его характер 39 KB
  Средневековое цеховое ремесло и его характер. Характерной особенностью средневекового ремесла в Европе была его цеховая организация объединение ремесленников определённой профессии в пределах данного города в особые союзы цехи. Цехи появились почти одновременно с возникновением городов. хотя окончательное оформление цехов получение специальных хартий от королей запись цеховых уставов и т.
75307. Производительные силы Западной Европы в V-XV веков 43.5 KB
  Производительные силы средневекового общества это люди с присущими им особенностями сознания трудовыми навыками природная среда их обитания и созданные ими в процессе жизнедеятельности орудия технологии и формы организации труда. Его характеризовали ручные орудия и низкая производительность труда отсутствие скольконибудь значительных материальных ресурсов простое нерасширенное воспроизводство. Даже крупные владения феодалов чаще всего представляли собой конгломерат более или менее значительных усадеб деревень или их групп...
75308. Культура Западной Европы в V-XI веках 43 KB
  Культура Западной Европы в VXI вв. Искусство Западной Европы в средние века. Книга представляет собой очерки истории искусства стран Западной Европы в средние века. Сюда были приглашены наиболее образованные люди тогдашней Европы.
75309. Международные связи в Западной Европе в XI-XV веков 40.5 KB
  Однако международные отношения этого периода не приняли еще достаточно регулярного характера: не было постоянных послов и дипломатических представительств не сложилось еще и международное право; само это понятие в целом едва ли применимо к этому времени развивались лишь отдельные его элементы и прежде всего право войны и морское право например Барселонское морское право оформившееся в XII в. Однако неожиданно монголотатары основательно истощенные к этому времени героическим сопротивлением Руси повернули в степи Причерноморья и...
75310. Возникновение, сущность и эволюция средневекового государства 34.5 KB
  Возникновение сущность и эволюция средневекового государства. Процесс образования централизованного феодального государства в России имел в своей основе те же общие закономерности исторического развития что и процесс образования централизованных феодальных государств в странах Западной Европы. Формы феодального государства были различными но классовая его сущность оставалась одна и та же. Характеризуя основные черты государства в средние века В.
75311. Происхождение термина «средние века» 28 KB
  Происхождение термина средние века. Термин средние века перевод с латинского выражения medium evum средний век 1 был впервые введен итальянскими гуманистами. С позиций высоких достижений культуры Возрождения средние века им виделись как период одичания и варваризации античного мира как время испорченной кухонной латыни. Келлер ввел термин средние века в общую периодизацию всемирной истории разделив ее на античность средневековье и новое время.
75313. Отечественная историография о феодализме 39.5 KB
  Гуревича многих других исследователей продвинулось вперед выяснение отдельных явлений и событий истории средневекового мира прогрессировало теоретическое осмысление проблематики феодализма. Конрад хотя он сам как и другие востоковеды сталкивался с трудноразрешимыми проблемами при рассмотрении феодализма во всемирноисторическом масштабе. Но подобное понимание феодализма оказывается крайне обедненным сводимым к малосодержательной социологической абстракции....