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

ЛИЧНЫЙ КАБИНЕТ 

 

Здравствуйте гость!

 

Логин:

Пароль:

 

Запомнить

 

 

Забыли пароль? Регистрация

Повышение уникальности

Предлагаем нашим посетителям воспользоваться бесплатным программным обеспечением «StudentHelp», которое позволит вам всего за несколько минут, выполнить повышение уникальности любого файла в формате MS Word. После такого повышения уникальности, ваша работа легко пройдете проверку в системах антиплагиат вуз, antiplagiat.ru, etxt.ru или advego.ru. Программа «StudentHelp» работает по уникальной технологии и при повышении уникальности не вставляет в текст скрытых символов, и даже если препод скопирует текст в блокнот – не увидит ни каких отличий от текста в Word файле.

Результат поиска


Наименование:


реферат Разработка базы данных

Информация:

Тип работы: реферат. Добавлен: 20.10.2012. Сдан: 2012. Страниц: 6. Уникальность по antiplagiat.ru: < 30%

Описание (план):


МОСКОВСКИЙ  ГОСУДАРСТВЕННЫЙ
 ГОРНЫЙ  УНИВЕРСИТЕТ 
 
 
 
 

Реферат

по дисциплине «Базы данных».
Тема: «Разработка  проекта базы данных». 
 
 
 
 

                               Выполнила:
                               студентка группы САПР-1В-07
                               Варнакова Е. Е.
                               Проверил:
                               Рябов Л.П. 
           
           
           

Москва
2010г.
«Разработка проекта базы данных»
    Основные этапы разработки БД. Постановка задачи, последовательность выполнения частей, анализ данных, определение структуры данных, разработка макета решения задачи, тестирование.
    Взаимодействие задач.
    Основные принципы проектирования БД. Эффективное использование памяти. Нормализация. Уникальность полей, первичные ключи, функциональная зависимость, независимость полей. Четыре правила нормализации таблиц.
    Эффективность связей. Создание связей между таблицами.
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Введение.
Сейчас почти  нет программного обеспечения, которое  бы обходилось без хранения информации в базах данных. При разработке информационных систем значительное время  необходимо уделять правильному  проектированию архитектуры БД.
Если система  должна работать с небольшими транзакциями, но идущим постоянным потоком в реальном времени, необходимо строить архитектуру БД с сильно нормализованными моделью данных (OLTP системы).
Для систем, выполняющих  функции отчетности, аналитики, когда, например, необходимо получить информацию о «количестве товара, проданного за первый квартал текущего года в разрезе по регионам, поставщикам и т.п.» типично построение архитектуры БД с малой степенью нормализации, такие системы оптимизированы под возможность быстрого получения данных (OLAP системы).
Кроме выбора архитектуры, необходимо определиться с инструментарием. В зависимости от класса систем, от требований по доступности и по совокупной стоимости владения, может  быть выбрана СУБД Oracle, MS SQL Server, PostgreSQL, MySQL или другая, более подходящая в данном конкретном случае.
Основные  этапы разработки БД.
Удачная разработка базы данных обеспечивает простоту ее поддержки. Данные следует сохранять  в таблицах, причем каждая таблица  должна содержать информацию одного типа, например сведения о заказчиках. Тогда достаточно будет обновить конкретные данные, такие как адрес, только в одном месте, чтобы обновленная информация отображалась во всей базе данных.
Правильно спроектированная база данных обычно содержит разнообразные  запросы, позволяющие отображать нужную информацию. В запросах может выводиться подмножество данных, например перечень заказчиков из Петербурга, или комбинированные данные из нескольких таблиц, например сведения о заказах совместно со сведениями о заказчиках.

  В этом запросе отображается код  заказа, название компании, город и дата исполнения для заказчиков из определенного города, сделавших заказы, которые следует выполнить в одном месяце.
Те результаты, которые пользователю требуется  получить от базы данных — формы и страницы доступа к данным, которые предполагается использовать, и отчеты, которые требуется печатать — не всегда дают правильное представление о требуемой структуре таблиц, поскольку формы, отчеты и страницы доступа к данным часто создают на основе запросов, а не на основе таблиц.
Прежде чем  приступить в Microsoft Access к фактической  разработке таблиц, запросов, форм и  других объектов, рекомендуется предварительно спланировать структуру на бумаге. Полезно также ознакомиться с  уже разработанными базами данных, аналогичными требуемой, или открыть учебную базу данных «Борей» и изучить ее макет в окне «Схема данных». 
 

Разработка  базы данных разбивается  на следующие основные этапы.
    1.Определение цели создания базы данных. 
    На первом этапе проектирования базы данных необходимо определить цель создания базы данных, основные ее функции и информацию, которую она должна содержать. То есть нуж-но определить основные темы таблиц базы данных и информацию, которую будут содержать поля таблиц. 
    База данных должна отвечать требованиям тех, кто будет непосредственно с ней работать. Для этого нужно определить темы, которые должна покрывать база данных, отчеты, которые она должна выдавать, проанализировать формы, которые в настоящий момент используются для записи данных, сравнить создаваемую базу данных с хорошо спроектированной, подоб-ной ей базой. 
     
    2. Определение таблиц, которые должна содержать база данных. 
    Одним из наиболее сложных этапов в процессе проектирования базы данных является разра-ботка таблиц, так как результаты, которые должна выдавать база данных (отчеты, выходные формы и др.) не всегда дают полное представление о структуре таблицы. 
    При проектировании таблиц вовсе не обязательно использовать Microsoft Access. Сначала лучше разработать структуру на бумаге. При проектировке таблиц рекомендуется руково-дствоваться следующими основными принципами: 
    • Информация в таблице не должна дублироваться. Не должно быть повторений и между таблицами. 
    Когда определенная информация храниться только в одной таблице, то и изменять ее при-дется только в одном месте. Это делает работу более эффективной, а также исключает воз-можность несовпадения информации в разных таблицах.  
    • Каждая таблица должна содержать информацию только на одну тему. 
    Сведения на каждую тему обрабатываются намного легче, если содержатся они в независи-мых друг от друга таблицах. Например, адреса и заказы клиентов хранятся в разных табли-цах для того, чтобы при удалении заказа информация о клиенте осталась в базе данных. 
     
    3. Определение необходимых в таблице полей. 
    Каждая таблица содержит информацию на отдельную тему, а каждое поле в таблице содер-жит отдельные сведения по теме таблицы. Например, в таблице с данными о клиенте могут содержаться поля с названием компании, адресом, городом, страной и номером телефона. При разработке полей для каждой таблицы необходимо помнить: 
    • Каждое поле должно быть связано с темой таблицы. 
    • Не рекомендуется включать в таблицу данные, являющиеся результатом выражения. 
    • В таблице должна присутствовать вся необходимая информация. 
    • Информацию следует разбивать на наименьшие логические единицы (Например, поля «Имя» и «Фамилия», а не общее поле «ФИО»). 
     
    4. Задание первичного ключа для каждой таблицы. 
    С тем чтобы Microsoft Access мог связать данные из разных таблиц, например, данные о кли-енте и его заказы, каждая таблица должна содержать поле или набор полей, которые будут однозначно идентифицировать каждую запись в таблице. Такое поле или набор полей назы-вают первичным ключом. 
     
    5. Определение связей между таблицами. 
    После распределения данных по таблицам и определения ключевых полей необходимо определить связи между таблицами. Для этого надо служит кнопка Схема данных. Связи нужны для того, чтобы обеспечить синхронное изменение одноименных полей в разных таблицах. Самый распространенный вид связи – «один-ко-многим». 
     
    6. Обновление структуры базы данных. 
    После проектирования таблиц, полей и связей необходимо еще раз просмотреть структуру базы данных и выявить возможные недочеты. Желательно это сделать на данном этапе, пока таблицы не заполнены данными. 
    Для проверки необходимо ввести несколько записей в каждую таблицу и посмотреть, отве-чает ли база данных поставленным требованиям. Рекомендуется также создать черновые вы-ходные формы и отчеты и проверить, выдают ли они требуемую информацию. Кроме того необходимо исключить из таблиц все возможные повторения данных. 

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

Основные  принципы проектирования БД.
  Нормализация  таблиц базы данных - первый шаг на пути проектирования структуры реляционной базы данных. Строго говоря, конечно, не самый первый - сначала надо решить, что же мы вообще будем хранить в базе, то есть определиться со структурой полей, их типами и размерностью, смыслом хранимой в них информации. Но это, как говорится, подразумевается по умолчанию:).
  Теория  нормализации реляционных баз данных была разработана в конце 70-х годов 20 века. Согласно ей, выделяются шесть  нормальных форм, пять из которых так  и называются: первая, вторая, третья, четвертая, пятая нормальная форма, а также нормальная форма Бойса-Кодда, лежащая между третьей и четвертой.
  База  данных считается нормализованной, если ее таблицы (по крайней мере, большинство  таблиц) представлены как минимум  в третьей нормальной форме. Часто  многие таблицы нормализуются до четвертой нормальной формы, иногда, наоборот, производится денормализация. Использования таблиц в пятой нормальной форме (вернее сказать, сознательного приведения их к пятой нормальной форме) в реальных базах данных я лично не встречал.
  Главная цель нормализации базы данных - устранение избыточности и дублирования информации. В идеале при нормализации надо добиться, чтобы любое значение хранилось в базе в одном экземпляре, причем значение это не должно быть получено расчетным путем из других данных, хранящихся в базе.
  Наверно, нет смысла подробно рассматривать примеры нормализации таблиц. Такой информации и в Интернете, и в книгах более чем достаточно. Напомню только, каким основным требованиям должна удовлетворять каждая из нормальных форм.

Первая  нормальная форма

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

Вторая  нормальная форма

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

Третья  нормальная форма

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

Нормальная  форма Бойса-Кодда

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

Четвертая нормальная форма

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

Пятая нормальная форма

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

Краткие итоги. Зачем нужна  нормализация.

  Главное, чего мы добьемся, проведя нормализацию базы данных - это устранение (или, по крайней мере, серьезное сокращение) избыточности, дублирования данных. Как  следствие, значительно сокращается  вероятность появления противоречивых данных, облегчается администрирование базы и обновление информации в ней, сокращается объем дискового пространства.
Уникальность  полей.
Для надежной работы связей между всеми таблицами  базы данных и быстрого поиска по данным из одной таблицы всех связанных  с ними записей в других таблицах, необходимо предусмотреть так называемые уникальные поля.
Уникальное  поле это поле, значения в котором не могут повторяться.
Поле Фамилия в таблице Автор вполне может содержать нескольких Ивановых, Петровых или Сидоровых, точно также как поле Имя может пестрить различными Аланами, Эдуардами и Робертами. Это означает, что эти поля не являются уникальными и поэтому их нельзя использовать для связи между таблицами. ПолеНазвание - более удачный кандидат на почетное звание уникального поля, но не тут то было... Многие современные авторы очень любят называть свои произведения в точности так, как это делали Пушкин, Лермонтов или Толстой. Что же тогда остается делать?
Выход всегда есть! Если ни одно поле в Вашей  таблице не приемлемо как уникальное, то его можно создать искусственно. Например, введя в таблицу шифр записи. Это могут быть буквы (например, первые буквы слов названия кники), цифры или их комбинация, но самое главное - они не будут повторяться, а значит, станут уникальными для каждой записи в таблице.

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

 
 
 
 

Перви?чный  ключ (англ. primary key) — в реляционной модели данных один из потенциальных ключей отношения, выбранный в качестве основного ключа (или ключа по умолчанию).
Если  в отношении имеет единственный потенциальный ключ, он является и первичным ключом. Если потенциальных ключей несколько, один из них выбирается в качестве первичного, а другие называют «альтернативными».
С точки  зрения теории все потенциальные  ключи отношения эквивалентны, то есть обладают одинаковыми свойствами уникальности иминимальности. Однако в качестве первичного обычно выбирается тот из потенциальных ключей, который наиболее удобен для тех или иных практических целей, например для создания внешних ключей в других отношениях либо для создания кластерного индекса. Поэтому в качестве первичного ключа как правило выбирают тот, который имеет наименьший размер (физического хранения) и/или включает наименьшее количество атрибутов.
Исторически термин «первичный ключ» появился и  стал использоваться существенно ранее  термина «потенциальный ключ». Вследствие этого множество определений в реляционной теории были изначально сформулированы с упоминанием первичного (а не потенциального) ключа, например, определения нормальных форм. Так же термин «первичный ключ» вошёл в формулировку 12 правил Кодда как основной способ адресации любого значения отношения (таблицы) наряду с именем отношения (таблицы) и именем атрибута (столбца).
Использование
Первичный ключ в таблице является базовым  уникальным идентификатором для записей. Значение первичного ключа используется везде, где нужно указать на конкретную запись. На использовании первичных ключей основана организация связей между таблицами реляционной БД. Чтобы организовать между двумя таблицами связь типа «один к одному» или «один ко многим (многие к одному)» в одну из связываемых таблиц добавляют поле (поля), содержащее (-ие) значение первичного ключа записи в связанной таблице (такое поле называют внешним ключом). Для организации связи типа «многие ко многим» создают отдельную таблицу (так называемую «таблицу связи» или «таблицу ассоциации»), каждая запись которой содержит первичные ключи двух связанных записей в разных таблицах.
Понятие функциональной зависимости  в данных.
Как известно, основной единицей представления данных в реляционной модели является отношение, которое математически задается списком имен атрибутов, иначе - схемой отношения. На стадии логического проектирования реляционной базы данных проектировщик определяет и выстраивает схемы отношений в рамках некоторой предметной области, а именно - представляет сущности, группирует их атрибуты, выявляет основные связи между сущностями. Так, в самом общем смысле проектирование реляционной базы данных заключается в обоснованном выборе конкретных схем отношений из множества различных альтернативных вариантов схем.
На практике построение логической модели базы данных, независимо от используемой модели данных, выполняется с учетом двух основных требований: исключить избыточность и максимально повысить надежность данных. Эти требования вытекают из требования коллективного использования данных группой пользователей. Формальных средств описания данных, необходимых для проверки правильности заполнения конструкций моделей, явно недостаточно. Выбор сущностей, атрибутов и фиксация взаимосвязей между сущностями зависит от семантики предметной области и выполняется системным аналитиком субъективно в соответствии с его личным пониманием специфики прикладной задачи. Разные люди определяют и представляют данные по-разному.
Поэтому любое априорное знание об ограничениях предметной области, накладываемых  на взаимосвязи между данными  и значения данных, и знания об их свойствах и взаимоотношениях между ними может сыграть определенную роль в соблюдении указанных выше требований. Формализация таких априорных знаний о свойствах данных предметной области базы данных нашла свое отражение в концепции функциональной зависимости данных, т.е. ограничений на возможные взаимосвязи между данными, которые могут быть текущими значениями схемы отношений.
Кортежи отношений могут представлять экземпляры сущности предметной области или  фиксировать их взаимосвязь. Но даже если эти кортежи определены правильно, т.е. отвечают схеме отношения и выбраны из допустимых доменов, не всякий из них может быть текущим значением некоторого отношения. Например, возраст человека редко бывает более 120 лет, или один и тот же пилот не может одновременно выполнять два различных рейса. Такие ограничения семантики домена практически не влияют на выбор той или иной схемы отношений. Они представляют собой ограничения на типы данных.
Априорные ограничения предметной области  на взаимосвязь значений отдельных атрибутов оказывают наибольшее влияние на процесс проектирования схем реляционных баз данных. Соответствие по значению определенных атрибутов различных отношений базы данных, т.е. зависимость их значений друг от друга, определяет показатели надежности и корректности сохраняемых данных при их коллективном и согласованном использовании.
Вспомним  определение функции как соответствия множества аргументов определенным значениям из множества определения  функции и способы задания функций: формула, график и перечисление (таблица). Нетрудно понять, чтофункциональную зависимость (ФЗ) можно определить на довольно широком классе объектов. Определение функции не накладывает никаких ограничений на множество аргументов и множество значений функции, кроме их существования и наличия соответствия между их элементами. Поскольку ФЗ можно задать таблично, а таблица есть форма представления отношения, то становится очевидной связь между ФЗ и отношением. Отношение может задавать ФЗ. Это утверждение является первой (1) конструктивной идеей, которая положена в основу теории проектирования реляционных баз данных.
Определение 1. Пусть r (A1, A2, ..., An) - схема отношения R, a X и Y - подмножества r. Говорят, что Х функционально определяет Y, если каждому значению атрибутов кортежа отношения из Х соответствует не более одного значения атрибутов того же кортежа отношения из Y. Такая ФЗ обозначается как  .
Как видно  из определения, функциональная зависимость инвариантна к изменению состояний базы данных во времени.
Четыре  правила нормализации таблиц.
Лежащая в основе нормализации математическая теория довольно сложна, но для практического применения ее можно сформулировать в виде довольно простых правил.
Правило 1. Уникальность полей. Неэффективное использование памяти является основным недостатком ненормализованных таблиц, поэтому удаление избыточных полей из таблиц является одним из решений этой проблемы.
Правило 1: Каждое поле любой  таблицы должно быть уникальным.
Этого можно достичь созданием отдельных  таблиц для повторяющихся данных и установлением связей между  новыми таблицами и исходной. Хотя дублируются данные в связующем  поле в каждой из таблиц, общий объем хранимых данных значительно сокращается.
Правило 2. Первичные ключи. База данных хорошо спроектирована тогда, когда каждая запись в любой таблице является уникальной. Это означает, что значение некоторого поля (или нескольких полей) не повторяется ни в одной записи в таблице. Такой идентификатор называется первичным ключом (или просто ключом).
Правило 2: Каждая таблица  должна иметь уникальный идентификатор, или  первичный ключ, который  может состоять из одного или нескольких полей.
Если  вы создаете таблицу в базе данных, то Access всегда предлагает определить для  нее первичный ключ. Вы можете также  предоставить Access возможность создать  искусственный первичный ключ. В  таком случае Access добавляет к  каждой записи поле, в которое записывается содержимое счетчика записей. При добавлении новой записи содержимое счетчика увеличивается на единицу.
Правило 3. Функциональная зависимость. Если вы определили для каждой таблицы первичный ключ, то можно проверить, включены ли в таблицы все сведения, относящиеся к соответствующим объектам. Кроме того, следует убедиться, что каждое поле функционально зависит от первичного ключа таблицы.
Правило 3: Для каждого  значения первичного ключа значения в  столбцах данных должны относиться к объекту таблицы и полностью его описывать.
Это правило  используется двояко. Во-первых, в таблице  не должно быть данных, не относящихся  к объекту, определяемому первичным  ключом. Во-вторых, данные в таблице  должны полностью описывать объект.
Правило 4. Независимость полей. Последнее правило позволяет проверить, не возникнут ли у вас проблемы при изменении данных в таблицах.
Правило 4: Изменение значений любого поля (не входящего  в первичный ключ) должно выполняться  без воздействия  на данные других полей. 
 

Эффективность связей. Создание связей между таблицами.
Создание  связей между таблицами — последний  этап проектирования системы таблиц. На этом этапе фактически регистрируются связи между первичными и внешними ключами, запланированные при конструировании  таблиц. После этого можно приступать к разработке интерфейса будущего приложения (создание запросов, форм, отчетов, программ и т.д.).
Существует  две причины для создания связей между таблицами: поддержание ссылочной  целостности и задание способа  выборки данных из нескольких таблиц. Связь задает отношение между полями таблиц, имеющими одинаковые по смыслу значения, например, между первичным ключом одной таблицы и внешним ключом другой таблицы. Связи можно задать на уровне базы данных (в этом случае возможна поддержка ссылочной целостности данных) и на уровне запросов. Связи на уровне базы данных являются постоянными связями и являются актуальными при любых действиях, выполняемых с таблицами (например, запросы на обновление или удаление, макросы или программы на Visual Basic, модифицирующие данные связанных таблиц и т.д.). Связи на уровне запросов являются временными и актуальны только на момент выполнения запроса, в котором они заданы. В этом разделе мы будем рассматривать связи на уровне базы данных (постоянные связи), хотя некоторые аспекты справедливы также и для временных связей.
Между таблицами можно установить связи  одного из трех видов: один-ко-многим (one-to-many), многие-ко-многим (many-to-many) и один-к-одному (one-to-one).
    Один-ко-многим (one-to-many). Является наиболее часто употребляемым видом связи. В этом случае каждой записи таблицы А может соответствовать много записей таблицы Б (или ни одной). В свою очередь, каждой записи таблицы Б соответствует в точности одна запись таблицы А. Таблица А в такой связи называется главной, а таблица Б — связанной или подчиненной.
    Многие-ко-многим (many-to-many). Многим записям из таблицы А может соответствовать много записей из таблицы Б (и наоборот). Такую связь в Microsoft Access можно организовать при помощи третьей вспомогательной таблицы, в которой каждому первичному ключу из таблицы А сопоставлен первичный ключ из таблицы Б. По сути, связь типа многие-ко-многим (many-to-many) представляет собой две связи типа один-ко-многим (one-to-many). При этом таблицы А и Б расположены со стороны один (one), а вспомогательная таблица — со стороны многие (many). Такой тип связи используется реже, но существуют ситуации, когда без нее не обойтись. В учебной базе данных Борей (Northwind) примером связи многие-ко-многим (many-to-many) является связь между таблицами Заказы (Orders) и Товары (Products), организованная при помощи таблицы Заказано (Order Details).
    Один-к-одному (one-to-one). Одной записи таблицы А соответствует в точности одна запись таблицы Б и наоборот. Этот тип связи практически никогда не применяется. Единственный случай, когда применение этого типа связи оправданно — разбивка таблицы, содержащей очень большое количество полей, на несколько частей.
Для любого из перечисленных  выше типов связей существует три  способа объединения. Установленный тип объединения влияет на результаты выборки данных из связанных таблиц.
    Внутреннее объединение (Inner Join). Объединяются только те записи из таблиц, связанные поля которых совпадают. Остальные записи в итоговую выборку не попадут. Например, таблицы Товары (Products) и Типы (Categories) связаны между собой по полям Код Категории (CategoryW). При выборке записей из этих таблиц в итоговую выборку попадут только те записи из таблицы Типы (Categories), ссылка на которые есть в таблице Товары (Products). Этот тип объединения используется в подавляющем большинстве случаев.
    Левое внешнее объединение (Left Join). Объединяются все записи таблицы со стороны один (one) и только те записи таблицы со стороны многие (many), значения связанного поля которых совпадают со значениями соответствующего поля первой таблицы. Попросту говоря, к результатам выборки по внутреннему объединению добавятся все записи из таблицы со стороны один (one), первоначально в нее не вошедшие. Соответствующие поля этих записей второй таблицы в выборке будут иметь пустое (Null) значение.
    Правое внешнее объединение (Right Join). Аналогично левому внешнему объединению, но таблицы со стороны один (one) и со стороны многие (many) меняются ролями, т.е. к результатам выборки по внутреннему объединению добавятся не вошедшие в нее записи из таблицы со стороны многие (many).
Для связей между  таблицами на уровне базы данных лучше  использовать только внутреннее объединение. Оба внешних объединения используются в основном при построении запросов. К внешним объединениям вообще нужно относится очень осторожно — непродуманность в их применении может приводить к достаточно странным ситуациям, например, при выборке. В большинстве случаев выборка получается правильная, но в некоторых случаях вы можете получить неверный результат и разобраться в причинах ошибки малоопытный пользователь просто не в состоянии. Более подробно об этом будет рассказано в следующей главе.
Постоянные связи  между таблицами устанавливаются  в диалоговом окне Схема данных (Relationships). Доступ к этому окну можно получить, выбрав одноименный пункт в меню Сервис (Tools) (см. рис. 3.20). Прежде чем приступить к установлению связей, необходимо закрыть все открытые таблицы. Это нужно сделать для того, чтобы можно было задать обеспечение целостности данных — для открытых таблиц этого сделать не удастся.

и т.д.................


Перейти к полному тексту работы


Скачать работу с онлайн повышением уникальности до 90% по antiplagiat.ru, etxt.ru или advego.ru


Смотреть полный текст работы бесплатно


Смотреть похожие работы


* Примечание. Уникальность работы указана на дату публикации, текущее значение может отличаться от указанного.