Введение:
Использование баз данных и информационных систем становится неотъемлемой составляющей деловой деятельности современного человека и функционирования преуспевающих организаций. В связи с этим большую актуальность приобретает освоение принципов построения и эффективного применения соответствующих технологий и программных продуктов: систем управления базами данных, CASE-систем автоматизации проектирования, средств администрирования и защиты баз данных и других.
От правильного набора инструментальных средств создания информационных систем, определения подходящей модели данных, обоснования рациональной схемы построения баз данных, организация запросов к хранимым данным и ряда других моментов во многом зависят эффективность функционирования разрабатываемых систем. Все это требует осознанного применения теоретических положений и инструментальных средств разработки баз данных и информационных систем [4].
Целью курсового проекта является описание реляционных баз данных.
Глава 3:
Существует восемь правил преобразования ER- модели в реляционную схему.
1. Каждой сущности – в соответствие отношение (таблица) реляционной модели данных.
2. Каждый атрибут сущности становится атрибутом отношения. Для каждого атрибута задается конкретный допустимый в СУБД тип данных и обязательность или необязательность данного атрибута (допустимость NULL значений).
3. Первичный ключ сущности становится Primary key соответствующего отношения. Атрибуты, входящие в первичный ключ, получают автоматически свойство NOT NULL обязательности.
4. В каждое отношение, соответствующее подчиненной сущности, добавляется набор атрибутов основной сущности, являющейся первичным ключом основной сущности. В отношении, соответствующем подчиненной сущности, этот набор атрибутов становится внешним ключом (foreign key).
5. Для моделирования необязательного типа связи на физическом уровне у атрибутов, соответствующих внешнему ключу, устанавливается свойство допустимости неопределенных значений (признак NULL). При обязательном типе связей атрибуты получают свойство отсутствия неопределенных значений (NOT NULL).
6. Для отражения категоризации сущностей при переходе к реляционной модели возможны несколько вариантов представления:
а) Возможно создать только одно отношение для всех подтипов одного супертипа. В него включают все атрибуты всех подтипов.
Тогда для ряда экземпляров ряд атрибутов не будет иметь смысла. И даже если их сделать неопределенными, то потребуются дополнительные правила различения одних подтипов от других. Зато достоинство – всего одна таблица.
б) При втором способе для каждого подтипа и для супертипа создаются свои отдельные отношения.
Недостаток – много отношений.
Достоинство – работаем только со значимыми атрибутами.
Для возможности перехода к подтипам от супертипа необходимо в супертип включить идентификатор связи.
8. Дополнительно при отношении между типом и подтипами необходимо указать тип дискриминатора. Дискриминатор может быть взаимоисключающим (mutually exclusive) или нет. Если установлен тип дискриминатора М/Е, то это значит, что один экземпляр сущности супертипа связан только с одним экземпляром сущности подтипа и для каждого экземпляра сущности супертипа существует потомок. Кроме того, для второго способа необходимо указать, наследуется ли только идентификатор супертипа в подтипы или наследуются все атрибуты супертипа.
Разрешение связей типа «многие-ко-многим» (в реляционной модели только 1:М и 1:1). Так как в реляционной модели данных только тип связи 1:М, а в E/R-есть и М: М, то необходим специальный механизм преобразования, который позволит отразить множественные связи с помощью допустимых для реляционной модели отношений. Это делается введением дополнительного связующего отношения, которое связано с каждым исходным отношением связью «один-ко-многим», атрибутами этого отношения являются первичные ключи связываемых отношений [6].
Заключение:
Проектирование базы данных представляет собой длительный и трудоемкий процесс. Качество созданной базы данных зависит от анализа предметной области и выбранной методологии проектирования. При неполном анализе предметной области в процессе эксплуатации созданной базы данных может возникать избыточное дублирование данных, а так же различные аномалии, что, скорее всего, приведет к потере необходимых данных и повторному проектированию базы данных. Процесс последующего проектирования базы данных не менее ответственный, так как необходимо четко выявить необходимые сущности и согласно связям между ними сформировать отношения. Процесс реализации базы данных средствами СУБД является преобразованием выполненного проектирования на ЭВМ.
В курсовом проекте говорилось об основных понятиях реляционных баз данных, но мы не опирались на какую-либо конкретную реализацию. Эти рассуждения в равной степени относятся к любой системе, при построении которой использовался реляционный подход.
Другими словами, мы использовали понятия так называемой реляционной модели данных. Модель данных (в контексте области баз данных) описывает некий набор родовых понятий и признаков, которыми должны обладать все конкретные СУБД и управляемые ими базы данных, если они основываются на этой модели. Наличие модели данных позволяет сравнивать конкретные реализации, используя один общий язык.
Хотя понятие модели данных является общим, и можно говорить об иерархической, сетевой, семантической и других моделях данных, нужно отметить, что в области баз данных это понятие было введено Эдгаром Коддом применительно к реляционным системам и наиболее эффективно используется именно в данном контексте. Попытки прямолинейного применения аналогичных моделей к дореляционным организациям показывают, что реляционная модель слишком «велика», а для постреляционных организаций она оказывается «мала».