Реферат: Програмирование на Visual Basic
5.2. РЕЛЯЦИОННАЯ СТРУКТУРА ДАННЫХ
В подавляющем большинстве существующие СУБД построены на основе реляционной модели данных, которая, несмотря на свою внешнюю простоту, базируется на прочном фундаменте масштабных теоретических исследовании, основы которых были заложены Э. Коддом в 1969 г. Результаты этих теоретических исследований позволяют сделать данные полными непротиворечивыми и не избыточными, чтобы все факты оказав лись учтены, но при этом каждый из них хранился только один' раз. Специалисты в области создания и сопровождения баз данных должны знать и уметь использовать эту теорию.
Реляционная база данных это такая база данных, которая состоит из таблиц (и ничего иного, кроме таблиц). Ссылка из одной таблицы на другую через какое-нибудь общее поле (common field) называется отношением (relation) ( отсюда и название реляционная).
Рассмотрим пример реляционной базы данных состоящей из трех таблиц или отношений, таблица поставщиков, таблица деталей и таблица поставки деталей.
Таблица поставщиков
| Номер постав щика | Фамилия | Состояние | Город |
| si | Смит | 20 | Лондон |
| s2 | Джонс | 10 | Париж |
| s3 | Блеик | 30 | Париж |
| s4 | Кларк | 20 | Лондон |
| s5 | Адаме | 30 | Атенс |
Каждый поставщик имеет уникальный номер, фамилии могут повторяться. Каждый поставщик находится только в одном городе.
Таблица деталей
| Номер детали | Название | Цвет | Вес | Город |
| Pi | Гайка | Красный | 12 | Лондон |
| р2 | Болт | Зеленый | 17 | Париж |
| РЗ | Винт | Голубой | 17 | Рим |
| р4 | Винт | Красный | 14 | Лондон |
| р5 | Кулачок | Голубой | 12 | Париж |
| Р5 | Заклепка | Красный | 19 | Лондон |
Каждый вид детали имеет уникальный номер. Город — место хранения детали. Предполагается, что каждый вид детали имеет только один цвет и хранится на складе только одного города.
Таблица поставки деталей
| Номер поставщика | Номер детали | Количесшо |
| Si | Pi | 300 |
| Si | Р2 | 200 |
| si | РЭ | 400 |
| sl | Р4 | 200 |
| si | Р5 | 100 |
| sl | р6 | 100 |
| s2 | Р' | 300 |
| s2 | Р2 | 400 |
| s3 | Р2 | 200 |
| s4 | Р2 | 200 |
| s4 | Р4 | 300 |
| s4 | Р5 | 400 |
Таблица поставки деталей служит для связи между собой двух первых таблиц. Например, первая строка этой таблицы связывает поставщика “sl” из таблицы поставщиков с деталью “р1” из таблицы деталей (представляет поставку детали вида “р1” поставщиком с номером “sl” в количестве 300 деталей). Предполагается, что в каждый момент существует только одна поставка для заданного поставщика и заданной детали, т.е. комбинация Но-мер_поставщика, Номер_детали является уникальной для заданной поставки относительно множества поставок в данный момент.
Принципиальной особенностью таблиц является следующее:
- данные в таблицах имеют только явные значения, т.е. не существует каких-либо связей или указателей, соединяющих одну таблицу с другой. Связь, например, между поставщиком и деталью задана наличием конкретного номера поставщика (sl) и конкретного номера детали (р1). Такие ссылки из одной таблицы на Другую через какое-нибудь общее поле (Common field) называется отношением;
- таблица состоит из строки заголовков столбцов и нуля или более строк значений данных;
- строка заголовков столбцов специфицирует один или более столбцов, определяя также тип данных для каждого из них (все значения в данном столбце одного типа. Например, имя поставщика типа строки символов, число деталей некоторого арифметического типа и т.п.);
- значения данных являются атомарными, т.е. в каждой ячейке таблицы всегда только одно значение.
Строка таблицы также называется записью. Элемент записи называется полем (наименьшая единица информации в базе данных)
Прикладная информация может по-разному задаваться таблицами (т.е количество таблиц и их содержание могут быть различными для одной и той же прикладной информации). Например, можно было бы вместо трех таблиц “Таблица поставщиков” “Таблица деталей” и “Таблица поставки деталей” сделать одну объединенную таблицу. В этом случае происходило бы дублирование информации (для каждой детали повторялась бы информация о поставщике). Если бы изменилась какая-либо информация по поставщику (например, состояние), то эту информацию необходимо бы было изменить во всех записях.
Для правильной организации данных в таблицы используется понятие нормализации. Нормализация данных — процесс исключения избыточной информации, при которой достигается то что каждый элемент информации запоминается только один раз. Теория и практические рекомендации по нормализации рассматриваются в книгах по реляционным базам данных.
Связь между таблицами реализуется с использованием ключей данных. Ключи обычно называют первичными и внешними ключами. Первичный ключ однозначно определяет запись в таблице (в таблице поставщиков таким первичным ключом является номер поставщика) и должен быть уникальным. Внешним ключом является ключ, используемый для связи с первичным ключом другой таблицы (в таблице поставок такими внешними ключами являются номер поставщика и номер детали, которые используются для связи с другими таблицами). Таблицы связываются между собой с помощью ключевых полей.
Ключевое поле может иметь содержательный смысл (например, фамилия, но в этом случае фамилии не могут повторяться) или полем, которое служит специальной цели обеспечения уникальности записи (например, номер поставщика или счетчик для первичного ключа). Поле счетчика является целочисленным полем, которое автоматически увеличивается на единицу системой управления базами данных, когда добавляется новая запись. При этом механизм создания уникальных полей перекладывается на систему.
Страницы: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37
