Это типичная иерархическая структура, в которой исходные элементы порождают другие элементы, а те, в свою очередь - следующие и т. д.
Чтобы поместить эту схему в компьютер в виде таблицы нужно пройти от каждого начального узла по всем веткам до каждого «листочка» и каждый такой проход (соответствующий листочку) займет отдельную строку таблицы
3. Реляционная модель данных
Доказано, что любую структуру данных можно преобразовать в структуру двумерной таблицы. Цель такого преобразования- получение стандартной структуры наиболее пригодной для компьютерной обработки и для проектирования человеком.
Термин реляционная является кратким синонимом словосочетания «простые двумерные таблицы».
Основная идея реляционного подхода состоит в том, чтобы представить произвольную структуру данных в виде простой двумерной таблицы (нормализовать структуру).
____________________________________________________________________
Модели данных(точно что именно надо – не знаю!)
В классической теории баз данных, модель данных есть формальная теория представления и обработки данных в системе управления базами данных (СУБД), которая включает, по меньшей мере, три аспекта:
1) аспект структуры: методы описания типов и логических структур данных в базе данных;
2) аспект манипуляции: методы манипулирования данными;
3) аспект целостности: методы описания и поддержки целостности базы данных.
Аспект структуры определяет, что из себя логически представляет база данных, аспект манипуляции определяет способы перехода между состояниями базы данных (то есть способымодификации данных) и способы извлечения данных из базы данных, аспект целостности определяет средства описаний корректных состояний базы данных.
Модель данных — это абстрактное, самодостаточное, логическое определение объектов, операторов и прочих элементов, в совокупности составляющих абстрактную машину доступа к данным, с которой взаимодействует пользователь. Эти объекты позволяют моделировать структуру данных, а операторы — поведение данных[1].
Каждая БД и СУБД строится на основе некоторой явной или неявной модели данных. Все СУБД, построенные на одной и той же модели данных, относят к одному типу. Например, основой реляционных СУБД является реляционная модель данных, сетевых СУБД — сетевая модель данных, иерархических СУБД — иерархическая модель данных и т. д.
В литературе, статьях и в обиходной речи иногда встречается использование термина «модель данных» в смысле «схема базы данных» («модель базы данных»). Такое использование является неверным, на что указывают многие авторитетные специалисты, в том числе К. Дж. Дейт, , . Модель данных есть теория, или инструмент моделирования, в то время как модель базы данных (схема базы данных) есть результат моделирования. По выражению К. Дейта соотношение между этими понятиями аналогично соотношению между языком программирования и конкретной программой на этом языке[1].
поясняет эволюцию смысла термина следующим образом. Первоначально понятие модели данных употреблялось как синоним структуры данных в конкретной базе данных. В процессе развития теории систем баз данных термин «модель данных» приобрел новое содержание. Возникла потребность в термине, который обозначал бы инструмент, а не результат моделирования, и воплощал бы, таким образом, множество всевозможных баз данных некоторого класса. Во второй половине 1970-х годов во многих публикациях, посвященных указанным проблемам, для этих целей стал использоваться все тот же термин «модель данных». В настоящее время в научной литературе термин «модель данных» трактуется в подавляющем большинстве случаев в инструментальном смысле (как инструмент моделирования)[2].
Тем не менее, длительное время термин «модель данных» использовался без формального определения. Одним из первых специалистов, который достаточно формально определил это понятие, был Э. Кодд. В статье «Модели данных в управлении базами данных»[3] он определил модель данных как комбинацию трех компонентов:
1. Коллекции типов объектов данных, образующих базовые строительные блоки для любой базы данных, соответствующей модели
2. Коллекции общих правил целостности, ограничивающих набор экземпляров тех типов объектов, которые законным образом могут появиться в любой такой базе данных
3. Коллекции операций, применимых к таким экземплярам объектов для выборки и других целей[4].
22.Реляционные базы данных. Сущности, атрибуты, связи. Ключевые поля.
Реляционная модель данных
Доказано, что любую структуру данных можно преобразовать в структуру двумерной таблицы. Цель такого преобразования - получение стандартной структуры наиболее пригодной для компьютерной обработки и для проектирования человеком.
Термин реляционная является кратким синонимом словосочетания «простые двумерные таблицы».
Основная идея реляционного подхода состоит в том, чтобы представить произвольную структуру данных в виде простой двумерной таблицы (нормализовать структуру).
Например, для иерархической структуры нормализация - это переход от корня дерева до каждого листочка и укладывание таких путей в строки таблицы.
Существуют математические теории, описывающие свойства реляционной модели. Там введены такие термины как предикаты, отношение, домен, кортеж и т. д., однако сфера их использования - развитие математических основ. В практике достаточно более простых терминов.
1. В реляционных БД совокупности данных представляются в виде двумерных таблиц (подобных описанному выше примеру).
2. Каждая таблица состоит из фиксированного числа столбцов (доменов). Количество строк - переменное число.
3. Каждый столбец представляет конкретное данное (код фирмы, код продукции и т. д.). На языке БД столбцы называются полями (естественно при этом рассматривать одну запись- строку). Для каждого поля разработчик должен определить:
- уникальное имя поля;
- тип поля;
- длину поля.
Например, поле «Себест» может иметь тип «Числовое» и длину 7 (4 знака до точки и 2 знака после точки).
«Поле»- это наиболее распространенный термин, заменяющий слово «данное».
4. Каждая строка таблицы на языке БД называется записью. Записи нумеруются по порядку 1, 2, …., n, где n - число на данный момент. Добавление записей - нормальная рабочая операция. Добавление полей - реорганизация БД – сфера действий системного программиста.
5. Каждое поле может входить в несколько таблиц, например «Катег.»
Рассмотрим еще пару типичных примеров.
Пример 1. Учет заказов на продукцию завода.
ZAKAZ
1. Ном_зак - номер заказа.
2. Код_зак - код заказчика.
3. Банк_рек - банковские реквизиты заказчика.
4. Код_прод - код продукции.
5. Объем - объем заказа в кг.
6. Дат_исп - дата исполнения заказа (ДД / ММ / ГГ).
7. Цена - цена продукции (руб/кг).
Пример 2.
KADR
1. ФИО
2. Год_рожд
3. Образов
4. Должность
5. Оклад
Рассматривая эти таблицы, замечаем, что в них используется код, а не прямо имя завода заказчика. В связи с этим возникает вопрос - почему используется код, хотя компьютер может обрабатывать и символы? Первый очевидный ответ - из экономии. Но есть и более важный аспект - проблема одинаковости ввода. Например, название «Тульский механический завод» могут разные люди вводить как Тульск. мех. завод, Тульск. мех. з-д и т. п. Проблема решается также как и в примере с телефонным справочником - КАТЕГ, то есть в базу вводят словарь, в котором для этого конкретного случая будет строка, например:
708 Тульский механический завод.
Если словарь уже существует, то значения уже не вводятся оператором, а выбираются из списка путем их выделения или набора первых нескольких букв. Если нужно пополнить словарь (появился новый заказчик), то тогда ему дают новый уникальный код и само наименование. Уникальность кода здесь очевидна (иначе - некорректно выбирать). Количество знаков кода зависит от диапазона значений данного.
Каковы рекомендации по кодированию? Способ генерирования кодов придумывает разработчик БД в тех случаях, когда на данный вид информации не существует государственного классификатора.
Главный ключ системы
Для выполнения операций над данными необходимо иметь для каждой записи (строки) таблицы уникальный идентификатор, значение которого однозначно определяет только эту запись. Этот идентификатор называют Главный ключ (primary key). Он может состоять из одного или нескольких полей. Например, в TELEF (телефонный справочник, см. пример)- роль ключа выполняет одно поле - Номер телефона, а в SEBEST - 3 поля: Фирма, Прод., Сх.
Главный ключ должен обладать двумя свойствами:
1. Однозначной идентификацией записи.
2. Отсутствием избыточности - никакое поле нельзя удалить из ключа, не нарушая при этом однозначности (первого свойства).
В примере ZAKAZ - главным ключом является номер завода (поскольку бессмысленно иметь иначе).
Главным ключом в таблице KADR «просится» быть Ф. И.О…. (посмотрим далее).
Таким образом, указание главного ключа - это и есть единственный способ отличить один экземпляр объекта от другого.
Вернемся к Ф. И.О.- это не надежный ключ. Более надежным является в пределах предприятия - табельный номер; в пределах страны - номер и серия паспорта или просто один номер (как в США - social secuirity number).
Слово «главный» предполагает и наличие неглавного или простого (вторичного) ключа. Этот термин возникает в операции, подразумевающей просмотр по какому-либо полю. Например, по полю «Катег» в примере с телефонным справочником. Т. е. при этом «Катег»- это простой ключ и его значение может быть неуникальным.
|
Из за большого объема этот материал размещен на нескольких страницах:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
