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


 

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

34751. Реформа Летоисчисления Петра 1 11.17 KB
  Петр же хотел чтобы подобно остальным европейским государствам новый год считали от Рождества Христова с 1 января. С этой целью 20 декабря был издан указ чтобы Новый год по примеру всех остальных христианских держав считать с 1 января через 8 дней после Рождества Христова 25 декабря по старому стилю. Кроме того повсюду где место удобное от 1 до 7 января надобно зажигать костры и смоляные бочки .
34752. Понятие о мартовском, сентябрьском и ультрамартовском годах византийской эры. Способы их перевода на современную систему летоисчисления 55.18 KB
  Перевод даты по ультрамартовскому стилю на современную систему летосчисления: Если событие приходится на период времени между мартом и декабрем включительно для перевода в современную систему счета времени необходимо от даты по эре от сотворения мира отнять 5509 лет. Задача 1:Перевести в современную систему летосчисления дату приведенную по ультрамартовскому стилю: 18 июля 6793 г. Решение:Так как дата приведена по ультрамартовскому стилю то для месяца июля вычитаем 5509. Задача 2:Перевести в современную систему летосчисления дату...
34753. Датировка событий по указаниям на церковные праздники. Датировка по астрономическим явлениям 15.25 KB
  Что касается подвижных праздников то все они зависят от Пасхи отделяясь от нее определенными постоянными сроками до Пасхи или после нее. Например Вознесение Господне четверг через 39 дней после Пасхи Вербное воскресенье за 7 дней до Пасхи Фомино воскресенье через 7 дней после Пасхи вход Господен в Иерусалим за 7 дней до Пасхи.Подвижность самой Пасхи объясняется тем что она рассчитывается по лунному календарю.Для определения дня Пасхи пользуются специальными таблицами обращения великого индиктиона.
34754. Определение дней недели с помощью формул и таблиц 15.12 KB
  Существует несколько математических формул для определения дня недели. Перевощикова: X равен остатку от деления выражения [H 1 1 4 H1 T1]:7 гдеX порядковый номер дня недели считая с воскресенья воскресенье 1 понедельник 2 и т. Черухина: X равен остатку от деления выражения [5 Н:4МТ]:7 гдеX порядковый номер дня недели считая с понедельника понедельник 1 вторник 2 и т.
34755. Предмет, цели и задачи метрологии 16.23 KB
  Задачей метрологии является обеспечение единства и необходимой точности измерений. Метрология делится на 3 самостоятельных раздела: Законодательная метрология предметом которой является установление обязательных технических и юридических требований по применению единиц физических величин эталонов методов и средств измерений направленных на обеспечение единства и необходимой точности измерений в интересах общества. Цели и задачи метрологии: Создание общей теории измерений; образование единиц физических величин и систем единиц;...
34756. Диалектика как учение о всеобщей связи и развитии. Метафизическое понимание развития. Объективная и субъективная диалектика. Софистика и эклектика. Диалектическая логика и догматизм 27 KB
  Объективная и субъективная диалектика. Диалектическая логика и догматизм Диалектика достаточно сложное учение и даже наше поверхностное учитывая дефицит времени рассмотрение ее проблематики займет у нас шесть вопросов. Начало традиционно дается определение диалектика. Учитывая что диалектика присутствовала и в дофилософские времена и разрабатывалась на протяжении всей истории философии целесообразно дать два определения диалектика.
34757. Принцип развития. Движение и развитие. Соотношение регресса и прогресса. Парадокс развития. Критерий прогресса 42 KB
  Парадокс развития. Уже на начальных этапах развития человеческого познания мыслители глубокой ревности обратили внимание на изменчивость бытия. На различных этапах развития науки и философии существовали теории абсолютизирующие одни формы движения и игнорирующие другие.
34758. Диалектика количественных и качественных изменений. Качество, количество, мера, скачок. Понятие нормы и патологии в медицине 79.5 KB
  Он предстает перед человеком не скоплением одинаковых предметов а как множество предметов явлений процессов наделенных различными свойствами. Вот почему познание предметов требует усилия мысли синтеза их многообразных проявлений. А множественность различных предметов характеризуется как качественное многообразие. Свойства обнаруживаются как проявления тех или иных черт сторон предметов в их отношениях с другими пред метами.
34759. Противоречие как источник развития. Закон единства и борьбы противоположностей. Принцип антагонистической регуляции функций 28.5 KB
  Принцип антагонистической регуляции функций Противоречие как источник развития диалектика Гераклита. О том что реальный процесс развития научного знания связан с этапами преодоления возникающих противоречий говорят многочисленные факты истории математики физики и др. Закон единства и борьбы противоположностей Движущую силу развития выражает закон единства и борьбы противоположностей.