Студопедия

КАТЕГОРИИ:


Архитектура-(3434)Астрономия-(809)Биология-(7483)Биотехнологии-(1457)Военное дело-(14632)Высокие технологии-(1363)География-(913)Геология-(1438)Государство-(451)Демография-(1065)Дом-(47672)Журналистика и СМИ-(912)Изобретательство-(14524)Иностранные языки-(4268)Информатика-(17799)Искусство-(1338)История-(13644)Компьютеры-(11121)Косметика-(55)Кулинария-(373)Культура-(8427)Лингвистика-(374)Литература-(1642)Маркетинг-(23702)Математика-(16968)Машиностроение-(1700)Медицина-(12668)Менеджмент-(24684)Механика-(15423)Науковедение-(506)Образование-(11852)Охрана труда-(3308)Педагогика-(5571)Полиграфия-(1312)Политика-(7869)Право-(5454)Приборостроение-(1369)Программирование-(2801)Производство-(97182)Промышленность-(8706)Психология-(18388)Религия-(3217)Связь-(10668)Сельское хозяйство-(299)Социология-(6455)Спорт-(42831)Строительство-(4793)Торговля-(5050)Транспорт-(2929)Туризм-(1568)Физика-(3942)Философия-(17015)Финансы-(26596)Химия-(22929)Экология-(12095)Экономика-(9961)Электроника-(8441)Электротехника-(4623)Энергетика-(12629)Юриспруденция-(1492)Ядерная техника-(1748)

Терминология. Понятие реляционный модели связано с разработками известного американского специалиста в области баз данных ЭдгараКодда (1970 год)

Реляционные модели

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

Концепция реляционной модели была предложена при решении задачи об обеспечении независимости представления и описания данных. Было доказано, что набор таблиц может быть использован для хранения данных об объектах реального мира и моделирования связей между ними. Эта модель характеризуется простотой структуры данных.

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

Ø Один ИО к одному ИО

Ø Один ИО ко многим ИО

Ø Многие ИО ко многим ИО.

Реальные отношения " Один ИО к одному ИО" имеют место тогда, когда каждому экземпляру первого ИО соответствует только один экземпляр второго ИО и наоборот.

Реальные отношения " Один ИО ко многим ИО" " имеют место тогда, когда каждому экземпляру первого ИО соответствует несколько экземпляров другого ИО, обратное неверно.

Реальные отношения " Многие ИО ко многим ИО" " имеют место тогда, когда каждому экземпляру первого ИО соответствует несколько экземпляров другого ИО и наоборот, каждому экземпляру второго ИО соответствует несколько экземпляров первого ИО.

Теория Реляционные БД Принятые соглашения
Отношение Таблица Таблица
Кортеж Строка Запись
Атрибут Столбец Поле

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

Поле имеет следующие характеристики:

Ø Имя

Ø Тип

Ø Длину

Ø Точность для числовых данных.

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

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

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

Правило 1: Уникальность полей

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

Правило 1. Каждое поле таблицы должно представлять уникальный тип информации.

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

Правило 2: Первичные ключи

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

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

Всегда, когда это возможно, в качестве первичного ключа следует использовать самые простые данные, имеющие «естественные» уникальные значения, например код книги.

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

Правило 3: Функциональная зависимость

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

Правило 3. Для каждого значения первичного ключа значения в столбцах данных должны относиться к объекту таблицы и полностью его описывать.

Это правило используется двояко. Во-первых, в таблице не должно; быть данных, не относящихся к объекту, определяемому первичным ключом. Например, хотя в каждом заказе требуется информация о заказчике, но заказчик является самостоятельным объектом, и данные о нем должны находиться в соответствующей таблице. Подобным образом, автор может написать не одну книгу, так что полностью оправдано создание таблицы для данных об авторах отдельно от книг. Во-вторых, данные в таблице должны полностью описывать объект.

Правило 4: Независимость полей

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

<== предыдущая лекция | следующая лекция ==>
Поиск решения. При моделировании сложных задач, можно использовать диспетчер сценариев, выбрав в меню Сервис команду Сценарий | Правило 4. Нужно иметь возможность изменять значения любого поля (не входящего в первичный ключ) без воздействия на данные других полей
Поделиться с друзьями:


Дата добавления: 2014-01-11; Просмотров: 305; Нарушение авторских прав?; Мы поможем в написании вашей работы!


Нам важно ваше мнение! Был ли полезен опубликованный материал? Да | Нет



studopedia.su - Студопедия (2013 - 2024) год. Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав! Последнее добавление




Генерация страницы за: 0.016 сек.