Студопедия
Случайная страница | ТОМ-1 | ТОМ-2 | ТОМ-3
АвтомобилиАстрономияБиологияГеографияДом и садДругие языкиДругоеИнформатика
ИсторияКультураЛитератураЛогикаМатематикаМедицинаМеталлургияМеханика
ОбразованиеОхрана трудаПедагогикаПолитикаПравоПсихологияРелигияРиторика
СоциологияСпортСтроительствоТехнологияТуризмФизикаФилософияФинансы
ХимияЧерчениеЭкологияЭкономикаЭлектроника

Логическое проектирование базы

Читайте также:
  1. А35 Психологическое консультирование: базовые приемы и техники / А.Н. Азарнова. — Ростов н/Д: Феникс, 2013. — 317 с. — (Психологический прак­тикум).
  2. Антропологическое направление
  3. АРИФМЕТИКО - ЛОГИЧЕСКОЕ УСТРОЙСТВО (АЛУ)
  4. Бета (минус)-распад (общая характеристика, правило смещения Содди для бета(минус)- распада, биологическое действие)
  5. БИОЛОГИЧЕСКОЕ НАПРАВЛЕНИЕ
  6. В подземном мире: психологическое нездоровье
  7. Генеалогическое древо семьи Файер

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

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

В процессе разработки реляционной структуры данных студент должен показать знания:

- методики проектирования базы данных на основе последовательного построения информационной модели;

- принципов нормализации данных.

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

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

- обеспечивать получение требуемых данных за приемлемое время, то есть отвечать заданным требованиям производительности;

- удовлетворять выявленным и вновь возникающим требованиям конечных пользователей;

- легко расширяться при реорганизации и расширении предметной области;

- легко изменяться при изменении программной и аппаратной среды.

А также:

- загруженные в базу данных корректные данные должны оставаться корректными;

- данные до включения в базу данных должны проверяться на достоверность;

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

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

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

При таком подходе определения структуры таблицы возможны проблемы с множественными атрибутами. Если количество значений атрибута у разных экземпляров сущности изменяется мало и при этом атрибут не используется для поиска сущностей, то оправдано его представление одним столбцом строкового типа. Так, например, можно хранить номера телефонов для контактов с заказчиком. В том случае, если число значений атрибута у разных объектов колеблется существенно или атрибут используется в качестве условия поиска данных, то, следуя требованию нормализации отношения, такой атрибут необходимо вынести в отдельную вспомогательную таблицу. Для поддержания соответствия между экземпляром сущности в главной таблице и его атрибутами во вспомогательной таблице создается столбец внешнего ключа, в который заносятся значения первичного ключа сущности из главной таблицы. Таким образом, вынесенные в отдельную таблицу атрибуты поддерживают связь «многие к одному» через соответствие внешнего и первичного ключей (FK – PK).



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

Загрузка...

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

При создании базы можно использовать белорусские и общероссийские классификаторы. Их количество измеряется десятками. Например, общегосударственный классификатор видов экономической деятельности (ОКЭД) Республики Беларусь, единый правовой классификатор (ЕПК) Республики Беларусь. Перечень общероссийских классификаторов можно найти по ссылке http://goskomstat.karelia.ru/uslugi/klassif.php3

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

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

Нормализация отношений

Декомпозицию отношения преобразованием к третьей нормальной форме можно в несколько этапов.

Данные, представленные в виде двумерной таблицы, являются первой нормальной формой (1NF) реляционной модели данных.

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

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

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

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

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

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

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

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

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

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

Транзитивная зависимость выявляет дублирование данных в одном отношении. Если А, В и С — три атрибута одного отношения и С зависит от В, а В от А, то говорят, что С транзитивно зависит от А, как это схематично показано на рисунке9 а).

Преобразование в третью нормальную форму происходит за счет разделения исходного отношения на два, как это показано на рисунке9 б).

Рисунок 9 – Пример транзитивной зависимости:
а) отношения между объектами с транзитивной зависимостью;
б) отношения между объектами без транзитивной зависимости


Дата добавления: 2015-07-08; просмотров: 233 | Нарушение авторских прав


Читайте в этой же книге: Цели и задачи курсового проектирования | Тема курсового проекта | Основная часть | Анализ предметной области | Разработка хранимых процедур (Stored Procedure) | Обеспечение целостности (Check Constraints) | Разработка приложения | Безопасность и защита данных | Тестирование программного продукта | Анализ предметной области |
<== предыдущая страница | следующая страница ==>
Концептуальное проектирование базы данных| Пример графического описания связей между отношениями

mybiblioteka.su - 2015-2021 год. (0.008 сек.)