Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Otvety_po_informatike.doc
Скачиваний:
2
Добавлен:
01.07.2025
Размер:
2.09 Mб
Скачать
  1. Иерархическая структура

Рассмотрим пример из промышленности:

Имеются фирмы А и В. Фирма А изготавливает 2 вида продукции (трубы медные и трубки латунные), обозначаемые кодами 3980 и 1250.

Продукция 3980 изготавливается по двум технологическим схемам с кодами 01 и 02, каждая из которых обеспечивает себестоимость продукции соответственно 578 и 612 руб / т. Продукция 1250 имеет 3 схемы: 01, 02 и 03 и себестоимости 380, 345 и 410 руб / т.

Фирма В изготавливает 3 вида продукции с кодами 1250, 1640 и 1930, для каждого из которых также имеются схемы и себестоимости.

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

1

Для фирмы В аналогичная структура:

Это типичная иерархическая структура, в которой исходные элементы порождают другие элементы, а те, в свою очередь- следующие и т.д.

Чтобы поместить эту схему в компьютер в виде таблицы нужно пройти от каждого начального узла по всем веткам до каждого «листочка» и каждый такой проход (соответствующий листочку) займет отдельную строку таблицы

  1. Реляционная модель данных

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

Термин реляционная является кратким синонимом словосочетания «простые двумерные таблицы».

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

____________________________________________________________________

Модели данных(точно что именно надо – не знаю!)

В классической теории баз данных, модель данных есть формальная теория представления и обработки данных в системе управления базами данных (СУБД), которая включает, по меньшей мере, три аспекта:

1) аспект структуры: методы описания типов и логических структур данных в базе данных;

2) аспект манипуляции: методы манипулирования данными;

3) аспект целостности: методы описания и поддержки целостности базы данных.

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

Модель данных — это абстрактное, самодостаточное, логическое определение объектов, операторов и прочих элементов, в совокупности составляющих абстрактную машину доступа к данным, с которой взаимодействует пользователь. Эти объекты позволяют моделировать структуру данных, а операторы — поведение данных[1].

Каждая БД и СУБД строится на основе некоторой явной или неявной модели данных. Все СУБД, построенные на одной и той же модели данных, относят к одному типу. Например, основой реляционных СУБД является реляционная модель данных, сетевых СУБД — сетевая модель данных, иерархических СУБД — иерархическая модель данных и т.д.

В литературе, статьях и в обиходной речи иногда встречается использование термина «модель данных» в смысле «схема базы данных» («модель базы данных»). Такое использование является неверным, на что указывают многие авторитетные специалисты, в том числе К. Дж. Дейт, М. Р. Когаловский, С. Д. Кузнецов. Модель данных есть теория, или инструмент моделирования, в то время как модель базы данных (схема базы данных) есть результат моделирования. По выражению К. Дейта соотношение между этими понятиями аналогично соотношению между языком программирования и конкретной программой на этом языке[1].

М. Р. Когаловский поясняет эволюцию смысла термина следующим образом. Первоначально понятие модели данных употреблялось как синоним структуры данных в конкретной базе данных. В процессе развития теории систем баз данных термин «модель данных» приобрел новое содержание. Возникла потребность в термине, который обозначал бы инструмент, а не результат моделирования, и воплощал бы, таким образом, множество всевозможных баз данных некоторого класса. Во второй половине 1970-х годов во многих публикациях, посвященных указанным проблемам, для этих целей стал использоваться все тот же термин «модель данных». В настоящее время в научной литературе термин «модель данных» трактуется в подавляющем большинстве случаев в инструментальном смысле (как инструмент моделирования)[2].

Тем не менее, длительное время термин «модель данных» использовался без формального определения. Одним из первых специалистов, который достаточно формально определил это понятие, был Э. Кодд. В статье «Модели данных в управлении базами данных»[3] он определил модель данных как комбинацию трех компонентов:

  1. Коллекции типов объектов данных, образующих базовые строительные блоки для любой базы данных, соответствующей модели

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

  3. Коллекции операций, применимых к таким экземплярам объектов для выборки и других целей[4].

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]