Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Shpory_po_BD.doc
Скачиваний:
4
Добавлен:
22.09.2019
Размер:
1.37 Mб
Скачать

8.Логическое проектирование бд.

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

Связи между объектами, показанные в концептуальной модели, могут отображаться в логической модели либо за счет совместного расположения объектов, либо путем объявления связей между ними. Не все виды связей, существующие в предметной области, можно отобразить в логической модели. Так, большинство СУБД не поддерживают связи М:М. В этом случае в логическую модель вводится дополнительный вспомогательный элемент, отображающий эту связь, т.е. отношение М:N разбивается на два отношения 1:М между этим новым элементом и исходными элементами.

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

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

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

Модель данных определяет структуры данных и множество допустимых операций над этими структурами.

Реляционная модель данных была предложена в начале 70-х годов Коддом Э. на основе математической теории отношений. Цель реляционной модели - обеспечить независимость представления и описания данных от прикладных программ. В основе реляционной модели данных лежит понятие "отношение" (relation). Каждому объекту (сущности) предметной области ставится в соответствие отношение. Отношение удобно представлять в виде двухмерной таблицы при соблюдении определенных ограничивающих условий. Каждое отношение (таблица) представляется в виде файла. Столбцы отношения называются атрибутами, им присваиваются имена. Перечень имен атрибутов в отношении называется схемой отношения.

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

Реляционная БД - набор взаимосвязанных отношений.

Между файлом, таблицей, отношением, сущностью существует следующее соответствие терминов:

файл

таблица

отношение

сущность

запись

строка

кортеж

экземпляр сущности

поле

колонки

атрибут

атрибут

10.Идентификация объекта.

1. Каждый объект ПО должен быть отличим от других однотипных объектов. С этой целью объектам каждого типа назначается некоторый естественный идентификатор, позволяющий на них однозначно ссылаться, так называемый первичный ключ – Primary Key (помечаем #). В качестве первичного ключа можно использовать какой-либо атрибут (простой ключ) или комбинацию нескольких атрибутов (составной ключ). Например: простой ключ - название организации; составной ключ - фамилия + адрес человека, чтобы узнать его телефон). В отношении может быть несколько ключей, но в каждый момент времени активным является только один какой-либо ключ.

2. Если между объектами существует связь 1:М, то оба отношения имеют общее поле связи. Для ведущего (родительского) отношения полем связи является первичный ключ. Для подчиненного (дочернего) отношения поле связи содержит первичный ключ родительского отношения и называется внешним ключом (Foreign Key).

Примеры:

1. сотрудник - дети (ключ -табельный номер сотрудника).

2. фирма - заказанные на базе товары (ключ - название фирмы)

3. товар - фирмы, купившие его (ключ - код товара).

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

а) у объектов существуют синонимы и первичный ключ не обеспечивает уникальность (однофамильцы);

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

в) если естественный идентификатор может измениться со временем (смена фамилии).

4. Часто на практике используют и неуникальные идентификаторы, называемые вторичным ключом и обозначающие множество объектов данного типа. К этому множеству относятся объекты, имеющие одинаковое значение вторичного ключа (студенты специальности АСУ).

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